Jumat, 03 Juni 2011

Interaksi Manusia dan Komputer

Pengertian Interaksi
Interaksi adalah komunikasi dua arah antara manusia (user) dan sistem komputer.
Pengertian Interaksi Manusia dan Komputer
Interaksi manusia dan komputer adalah sebuah hubungan atau komunikasi antara manusia dengan komputer untuk berinteraksi, yang keduanya saling memberikan masukan dan umpan balik melalui sebuah antarmuka untuk memperoleh hasil akhir yang diharapkan.
Tanpa disadari, kita sebagai manusia setiap harinya pasti berinteraksi dengan komputer.
Contohnya apa?
Dengan menekan tombol baik berupa angka ataupun huruf di keyboard, atau meng-klik mouse untuk membuka menu tertentu di komputer, sehingga komputer dapat merespon kita untuk menjalankan apa  yang kita inginkan. Itu salah satunya :) .

Terdapat beberapa model atau jenis interaksi manusia dan komputer :
  1. Command Line Interface (Berinteraksi menggunakan satu baris perintah)
    Contoh : Unix, Linux, DOS
    undefined
  2. Menu (Pilihan yang disediakan oleh suatu perangkat lunak)
    Contoh : Semua software yang menggunakan menu.
  3. Natural Language (bahasa alami)
    Contoh : bahasa pemrograman terstruktur.
  4. Question/answer and query dialogue
    contoh : mysql, dbase interaktif, dll
  5. Form-fills and spreadsheets
    contoh : excel, lotus, openoffice spreadsheet
  6. WIMP
    Windows Icon Menu Pointer
    Windows Icon Mouse Pulldown Menu
    yang termasuk komponen WIMP : button, dialogue boxes, pallettes, dll

Pemograman Berorientasi Objek


konsep dasar dari Pemrograman Berorientasi Objek



Pemrograman orientasi-objek menekankan konsep berikut:
  • kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh 'class of dog' adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.
  • Abstraksi - Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari "pelaku" abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.
  • Enkapsulasi - Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi izin untuk mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.
  • Polimorfisme melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim. Contohnya, bila sebuah burung menerima pesan "gerak cepat", dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.
  • Inheritas- Mengatur polimorfisme dan enkapsulasi dengan mengijinkan objek didefinisikan dan diciptakan dengan jenis khusus dari objek yang sudah ada - objek-objek ini dapat membagi (dan memperluas) perilaku mereka tanpa haru mengimplementasi ulang perilaku tersebut (bahasa berbasis-objek tidak selalu memiliki inheritas.)
  • Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.


Dibawah ini adalah sebuah gambaran tentang objek yang berisi data dan fungsi yang memanipulasi data.
objek yang berisi data dan fungsi yang memanipulasi data
Sedangkan gambar dibawah adalah gambar yang melukiskan hubungan antar-objek yang menganalogikan struktur di perusahaan.
hubungan antar-objek yang menganalogikan struktur di perusahaan
Pada Bahasa Pemrograman Berorientasi Objek, data yang melekat dalam suatu objek biasanya disebut variabel instans. Pada C++, istilah yang digunakan adalah data atau anggota data. Adapun fungsi yang melekat pada suatu objek disebut fungsi anggota (member function). Fungsi ini merupakan satu-satunya cara untuk mengakses anggota data data dari objek.
Untuk membaca suatu anggota data, kita diharuskan memanggil fungsi anggota. Dengan kata lain, data bersifat tersembunyi dari fungsi-fungsi yang ada diluar fungsi anggota. Istilah yang umum untuk fungsi anggota pada Bahasa Pemrograman Berorientasi Objek adalah metode (misalnya pada SmallTalk). Adapun pemanggilan fungsi anggota sering disebut pengiriman pesan ke objek.
Dalam terminologi Pemrograman Berorientas Objek (PBO), objek sebenarnya adalah anggota dari kelas (class). Dengan kata lain, kelas adalah kumpulan dari beberapa objek yang sama. Sebagai analogi hal ini, anda pasti tahu Aceh, Sumatera Utara, Sulawesi Selatan, Papua, Maluku, DKi Jakarta itu adalah sebuah provinsi. Secara sendiri-sendiri provinsi tersebut diibaratkan sebagai objek. Adapun “Provinsi Di Indonesia” menyatakan sebagai kelas.

Selasa, 24 Mei 2011

Cara Membuat Diagram Use Case

Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar dan menjelaskan sistem secara fungsional yang terlihat user. Biasanya dibuat pada awal pengembangan. Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

Use case diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.
Use case diagram dapat digunakan selama proses analisis untuk menangkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use case diagram. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use case yang menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri.

1. Actor
Seorang / sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.
2. Communication.
Sebuah penghubung antara Actor/Orang dengan Case.
3. Case.
Menggambarkan deskripsi yang melibatkan Actor/Orang.


4. Extend.
Relasi yang digunakan jika use case yang satu mirip dengan use case yang lain.
5.Include.
Relasi jika terdapat perilaku yang mirip dengan beberapa use case.

Cara Menemukan Use Case
  • Pola perilaku perangkat lunak aplikasi.
  • Gambaran tugas dari sebuah actor.
  • Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.
  • Apa yang dikerjakan oleh suatu perangkat lunak (bukan bagaimana cara mengerjakannya).
Komponen Pembentuk Use Case.

Actor.

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man. Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship.
Contoh:
Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem, antara lain:
  • Yang berkepentingan terhadap sistem dimana adanya arus informasi, baik yang diterimanya maupun yang dia inputkan ke sistem.
  • Orang ataupun pihak yang akan mengelola sistem tersebut.
  • External resource yang digunakan oleh sistem.
  • Sistem lain yang berinteraksi dengan sistem yang akan dibuat.
Use Case.

Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.
Cara menentukan Use Case dalam suatu sistem:
  • Pola perilaku peringkat lunak aplikasi
  • Gambaran tugas dari sebuah actor
  • Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor
  • Apa yang dikerjakan oleh suatu perangkat lunak (bukan bagaimana cara mengerjakannya).
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case diagram:
  1. Association, menghubungkan link antar element.
  2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.
  3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.
  4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.
Tipe relasi / stereotype yang mungkin terjadi pada Use Case diagram:
  1. <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.
  2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.
  3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
 contoh diagram use case :


Use Case Specification
  • Nama
  • Deskripsi Singkat
  • Aliran event (flow of event)
  • Relationship
  • Activity Diagram
  • Kebutuhan khusus (special requirement)
  • Pre-Condition
  • Post-Condition
Use Case Specification

Use Case Specification Table
Activity Diagram
Aliran Event Use Case
  • Memiliki sebuah flow normal dan dasar
  • Beberapa flow alternatif
    • Regular variant
    • Kasus-kasus ganjil
    • Exceptional flows, penanganan error
      Aliran Event Use Case
  • Scenario adalah sebuah instance dari sebuah use case
    Aliran Event Use Case
  • Activity diagram didalam model use case dapat digunakan untuk meng-capture aktifitas-aktifitas dalam sebuah use case
  • Sebenarnya merupakan flowchart, yang menunjukkan aliran kontrol activity ke activity.