Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 6

Diagram Interaksi

Diagram interaksi adalah model yang mendeskripsikan bagaimana sekelompok objek berkolaborasi dalam satu perilaku yang biasanya berkaitan dalam satu use case. Pada UML, diagram interaksi terdiri dari dua yaitu diagram sekuen/sequence diagram dan diagram kolaborasi/collaboration diagram. Pada diagram sekuen , objek-objek ditunjukkan sebagai garis vertical dengan pesannya garis horizontal di antara objek-objek. Bentuk ini dipopulekan oleh Jacobson, dengan cara membaca dari atas ke bawah dari kiri ke kanan.

Pada diagram kolaborasi, objek ditunjukkan sebagai icon. Anak panah mengindikasikan pesan-pesan yang dikirim. Pewaktuan atau urutan ditunjukkan dengan penomoran.

Elemen model interaksi

Elemen model interaksi terdiri dari :

• Objek
• Link
• Pesan

Objek

Objek yang berpartisipasi dapat berupa sesuatu yang konkret atau prototype. Sesuatu yang konkret adalah sesuatu yang merepresentasikan pada dunia nyata. Misalnya kelas Dosen. Pada kolaborasi kita menggunakan sesuatu yang prototype yang memainkan pesan tertentu.

Link

Link adalah koneksi semantic di antara objek-objek. Link adalah instan dari asosiasi. Ketika kelas mempunyai link dengan kelas maka bisa terdapat link di antara dua objek., maka satu objek dapat mengirim pesan objek yang lain.

Pesan

Merupakan spesifikasi komunikasi di antara objek-objek yang memuat informasi dengan aktivitas yang diharapkan. Beberapa jenis aksi diantaraya:

• Call
• Return
• Send
• Create
• Destroy

Kegunaan diagram interaksi adalah:

• Memodelkan aliran kendali
• Memodelkan aliran kendali berdasarkan waktu
• Memodelkan aliran kendali berdasarkan organisasi

Diagram sekuens

Untuk membuat statechart kita dapat dibantu dengan terlebih dahulu menggambarkan urutan kejadian (event trace diagram) suatu kegiatan/scenario. Urutan kejadian ini digambarkan dengan diagram sekuen / diagram lacak kejadian. Diagram sekuen mendeskripsikan komunikasi di antara objek-objek, meliputi pesan-pesan yang ada dan urutan pesan tersebut muncul. Sequence diagram dapat berasosiasi dengan realisasi usecase digunakan untuk menunjukkan flow dari fungsionalitas di dalam suatu use case.

Diagram sekuen digunakan untuk:

• Overview perilaku objek
• Menunjukkan objek-objek yang diperlukan
• Mendokumentasikan scenario dari suatu diagram use case
• Memeriksa jalur-jalur pengaksesan

Diagram sekuen menunjukkan objek sebagai garis vertical dan tiap kejadian sebagai panah horizontal dari objek pengirim ke objek penerima. Diagram ini hanya menunjukkan urutan waktu kejadian tetapi tidak menunjukkan pewaktuan yang nyata.

Perbedaan diagram sekuen dengan diagram kolaborasi

1. Terdapat lifeline objek. Garis putus-putus vertical mempresentasikan keberadaan suatu objek di satu periode waktu
2. Focus diagram sekuen adalah kendali

Kita memerlukan sedikitnya satu diagram sekuen untuk masing-masing use case. Jika kita kesulitan dalam membuat diagram sekuen atas suatu use case berarti terdapat kekeliruan dalam pembuatan use case, pertimbangkan untuk mengkaji ulang pemodelan use case

Notasi dalam sekuen diagram

Notasi objek

Objek digambarkan sebagai segiempat berisikan

- nama objek saja

- Nama objek dan nama kelas

- Nama kelas saja

Notasi Timeline

Garis waktu setiap object digambarkan sebagai garis terputus-putus di bawah masing-masing object.

Notasi message

Aliran message digambarkan sebagai garis berpanah dari satu titik di timeline object pengirim ke titik di timeline object penerima. Nama message dan argumen dituliskan di atas garis message tsb

• Jenis-jenis message

– Simple, Procedure call, Return, Synchronous, Asynchronous, Balking, Timeout

• Frekuensi message

– Periodic, Aperiodic

Contoh diagram sequence kasus "membuka rekening baru" :

Diagram kolaborasi

Pada dasarnya memberikan informasi yang mirip dengan sequence diagram namun dengan sudut pandang interaksinya (sementara sequence diagram pada sudut pandang timeline) , digunakan oleh QA dan System Architect untuk melihat distribusi proses antara object-object

– Misalnya pada diagram berbentuk star menunjukkan sistem yang sangat dependent pada object sentral sehingga perlu redesign untuk distribusi processing power

Notasi

• Object digambarkan sebagai segiempat dengan nama:

– Jika hanya nama class maka dituliskan setelah tanda ”:”

– Jika dengan nama object (serta nama class) maka kedua nama dituliskan dipisahkan tanda “:” sebagai “: ”

• Link antara object digambarkan dengan garis yang menghubungkannya

• Message ditampilkan sebagai teks dan panah berarah dari pengirim pesan ke tujuan.

• Di depan pesan dituliskan angka yang menyatakan nomor urutan dalam interaksi

Contoh diagram kolaborasi :

Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 5

Use Case diagram

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.

Notasi Gambar Yang Diapakai Use Case :

1. Actor
Seorang / sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.


2. Case
Menggambarkan deskripsi yang melibatkan actor.



contoh case yang melibatkan actor :


3. Extend
Relasi yang digunakan jika use case yang satu mirip dengan use case yang lain.

4. 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).

Contoh Use Case Diagram :

Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 4

Activity Diagram

Activity diagram adalah representasi grafis dari alur kerja tahapan aktifitas. Diagram ini mendukung pilihan tindakan, iterasi dan concurrency. Pada pemodelan UML, activity diagram dapat digunakan untuk menjelaskan bisnis dan alur kerja operasional secara step-by-step dari komponen suatu sistem. Activity diagram menunjukkan keseluruhan dari aliran kontrol.

Simbol activity diagram :

contoh activity diagram mengenai penarikan uang dari account bank melalui ATM :

Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 3

Pemodelan Bisnis

Pemodelan Bisnis, secara formal, didefinisikan sebagai segala teknik pemodelan yang digunakan untuk mengambarkan model sebuah bisnis. Pemodelan Bisnis dapat digunakan untuk meninjau, meningkatkan, dan membuat sebuah bisnis. Dengan dilakukannya pemodelan bisnis diharapkan kita:

• Memahami struktur dan dinamika organisasi
• Memahami masalah-masalah dalam mencapai target organisasi dan menemukan potensi untuk kemajuan organisasi.
• Yakin bahwa para customer, end user, dan developer mempunyai sebuah pemahaman yang benar mengenai organisasi.
• Dapat menurunkan/mendapatkan kebutuhan perangkat lunak yang akan kita buat yang diperlukan untuk mendukung pencapaian target organisasi.

Kapan membutuhkan Pemodelan Bisnis?

• Jika kelompok kerja merupakan kelompok baru dalam organisasi
• Jika organisasi mengalami re-engineering proses bisnis/ bermaksud menjalankan re-engineering proses bisnis
• Jika kita akan membangun perangkat lunak yang akan dipergunakan oleh porsi yang significant dari organisasi
• Jika terdapat aliran kerja yang kompleks dan besar yang tidak didokumentasikan
• Jika kita merupakan konsultan organisasi yang belum pernah bekerja sama

Kapan tidak memerlukan Pemodelan Bisnis?

• Jika kita telah memahami struktur, tujuan, visi dan stakeholder dari organisasi
• Jika kita membangun perangkat lunak yang akan dipergunakan hanya oleh bagian kecil dari organisasi dan tidak akan menimbulkan efek pada keseluruhan bisnis
• Jika aliran kerja organisasi telah jelas dan didokumentasikan dengan baik
• Jika tidak terdapat banyak waktu (tapi tidak boleh dijadikan alasan).

Elemen-elemen pemodelan bisnis:

• Business use-case model, dengan elemen-elemen: Business Actor dan Business Use-case, serta Activity Diagram untuk menjelaskan model business use-case. Berikut gambaran Business Use-case Diagram [Activity Diagram dapat dilihat di sini].

• Business objek model, dengan elemen-elemen: Business Worker (Pekerja Bisnis), Business Entity (Entitas Bisnis)

Business Object Model: Menggambarkan realisasi business use-case. Mengenali semua orang yang bekerja dan benda yang terlibat dalam bisnis dan bagaimana satu sama lain berhubungan

Business Use-case Model: Merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat, bersifat optional. Diilustrasikan dalam satu atau beberapa business use-case diagram.

Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 2

Visual Modeling (Pemodelan Visual)
Pemodelan visual (visual modeling) merupakan proses menggambarkan cetak biru suatu sistem informasi secara grafis, terdiri dari komponan – komponen, interface, dan koneksi – koneksi yang ada dalam sistem tersebut, agar mudah dipahami dan dikomunikasikan. Visual modeling dapat membantu untuk menampilkan elemen – elemen yang penting secara detail dari suatu masalah yang kompleks dan menyaring untuk kemudian membuang elemen – elemen yang tidak penting.

UML (Unified Modeling Language)
UML (Unified Modeling Language) adalah metode pemodelan secara visual sebagai sarana untuk merancang dan atau membuat software berorientasi objek. Karena UML ini merupakan bahasa visual untuk pemodelan bahasa berorientasi objek, maka semua elemen dan diagram berbasiskan pada paradigma object oriented.

Diagram UML

1. Diagram Use Case
Diagram Use Case menggambarkan apa saja aktifitas yang dilakukan oleh suatu sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa yang dilakukan bukan bagaimana melakukannya. Diagram Use Case dekat kaitannya dengan kejadian-kejadian.

Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirements) : Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas.
  

• Komunikas dengan klien : Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkomunikasi dengan klienkliennya.
  

• Membuat test dari kasus-kasus secara umum : Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.

2. Diagram Class
Diagram Class memberikan pandangan secara luas dari suatu sistem dengan menunjukan kelas-kelasnya dan hubungan mereka. Diagram Class bersifat statis; menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika mereka berhubungan.

Diagram Class mempunyai 3 macam relationalships (hubungan), sebagai berikut :

• Association

Suatu hubungan antara bagian dari dua kelas. Terjadi association antara dua kelas jika salah satu bagian dari kelas mengetahui yang lainnya dalam melakukan suatu kegiatan. Di dalam diagram, sebuah association adalah penghubung yang menghubungkan dua kelas.

• Aggregation

Suatu association dimana salah satu kelasnya merupakan bagian dari suatu kumpulan. Aggregation memiliki titik pusat yang mencakup keseluruhan bagian. Sebagai contoh : OrderDetail merupakan kumpulan dari Order.

• Generalization

Suatu hubungan turunan dengan mengasumsikan satu kelas merupakan suatu superClass (kelas super) dari kelas yang lain. Generalization memiliki tingkatan yang berpusat pada superClass.
Contoh :
Payment adalah superClass dari Cash, Check, dan Credit.

3. Package dan Object
Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat dilakukan pengelompokan kelas-kelas berupa package (paketpaket). Package adalah kumpulan elemen-elemen logika UML.

4. Diagram Sequence
Diagram Class dan diagram Object merupakan suatu gambaran model statis. Namun ada juga yang bersifat dinamis, seperti Diagram Interaction.
Diagram sequence merupakan salah satu diagram Interaction yang menjelaskan bagaimana suatu operasi itu dilakukan; message (pesan) apa yang dikirim dan kapan pelaksanaannya. Diagram ini diatur berdasarkan waktu. Obyek-obyek yang berkaitan dengan proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan waktu terjadinya dalam pesan yang terurut.

5. Diagram Collaboration
Diagram Collaboration juga merupakan diagram interaction. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

6. Diagram StateChart
Behaviors dan state dimiliki oleh obyek. Keadaan dari suatu obyek bergantung pada kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart menunjukan kemungkinan dari keadaan obyek dan proses yang menyebabkan perubahan pada keadaannya.

7. Diagram Activity
Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram ini berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek yang dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi dengan kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut bergantung satu sama lain.

8. Diagram Component dan Deployment
Component adalah sebuah code module (kode-kode module). Diagram Component merupakan fisik sebenarnya dari diagram Class. Diagram Deployment menerangkan bahwa konfigurasi fisik software dan hardware.

Perencanaan Sistem Informasi Berbasis Obyek Pertemuan 1

Software Engineering

Ilmu yang mempelajari tehnik pembuatan software yang baik dengan pendekatan tehnik (Engineering ap­proach)

Definisi Software Engineering

1. Model Activity

adalah manajemen perangkat lunak yang menangani masalah domain melalui pemodelan, dengan berfokus pada satu waktu saja dan hanya mengacu pada rincian yang relevan dan mengabaikan segala sesuatu yang lain.

Alur Model Activity:

• Model – sebuah abstraksi realitas
• Analisis – membangun sebuah model dari domain masalah
• Desain – membangun sebuah model dari domain solusi

Dalam metode OOP, model domain solusi adalah perluasan dari model domain masalah, sehingga struktur perangkat lunak mencerminkan masalah sebenarnya

2. Problem Solving

adalah sebuah tahapan untuk mencari solusi yang diterima dari model activity.

Solusi didapat dengan cara:

• Melakukan Eksperimen
• Menggunakan pola solusi yang sudah ada
• Masukan yang diterima dari klien
• Revisi dalam menanggapi perubahan

3. Knowledge Acquisition

Dalam pemodelan domain aplikasi dan solusi, teknisi perangkat lunak mengumpulkan data, mengaturnya menjadi informasi, dan merumuskan menjadi pengetahuan.

Data didapat dari:

• Survey
• Wawancara
• Informasi dari isu yang ada

4. Rationale Driven

Teknisi perangkat lunak membuat keputusan harus sesuai dengan konteks yang dibuat dan alasan di balik keputusan ini dibuat untuk memahami implikasi dari perubahan yang diajukan.

Konsep OOP

1. Abstraksi

• Cara paling dasar untuk mengelola kompleksitas.
• Abstraksi juga merupakan kemampuan manusia untuk mengenali sesuatu yang komplek dengan mengabaikan
• Konsentrasi pada yang signifika.

2. Pengkapsulan
Memisahkan aspek - aspek eksternal obyek yang dapat diakses obyek - obyek lain dari rincian implementasi obyek itu sendiri.

3. Pewarisan
Sebuah class dapat mewariskan sifat - sifatnya ke class lain atau turunannya.

4. Pengiriman pesan
Obyek - obyek dalam sistem bekerja sama dengan cara mengirimkan pesan dari satu obyek ke obyek lainnya.

5. Asosiasi
Class yang saling berhubungan dan mengirim pesan.

6. Agregation
Bentuk yang lebih kuat dari asosiasi.