Testing dan Implementasi Sistem Pertemuan 6

Unit Testing

Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain software – komponen atau modul software. Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur kendali yang penting dites untuk menemukan errors, terbatas pada modul tersebut. Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh batasan-batasan dari cakupan yang telah ditetapkan pada unit testing. Unit testing berorientasi white box, dan tahapan dapat dilakukan secara paralel pada banyak komponen.

Hal-hal yang perlu diperhatikan pada unit testing :

• Tes yang terdapat pada unit testing
• Tes aliran data antar modul dibutuhkan sebelum inisialisasi tes lainnya.
• Pemilihan jalur eksekusi testing adalah tugas yang esensial selama unit test.
• Kesalahan komputasi yang umum terjadi
• Komparasi dan alur kendali merupakan satu kesatuan
• Batasan testing adalah tugas terakhir dari unit testing
• Disain yang baik meliputi kondisi kesalahan yang diantisipasi dan jalur penanganan kesalahan diset untuk dapat digunakan kembali atau proses pembersihan pada terminasi saat kesalahan terjadi.

Prosedur-prosedur unit test :

• Setelah kode dikembangkan, dan diverifikasi terhadap tingkat disain komponen
  bersangkutan, disain test case dari unit test dimulai
• Review informasi disain menyediakan tuntunan untuk menetapkan test cases agar dapat
  mendekati keseluruhan cakupan kesalahan di tiap kategori sebagaimana didiskusikan
  sebelumnya
• Tiap test case harus dihubungkan dengan hasil yang diharapkan
• Karena komponen bukan program yang berdiri sendiri, drivers dan atau stubs software
  harus dikembangkan untuk tiap unit test.
• Drivers –> program utama yg menerima data test case, memasukkan data ke komponen yg dites dan mencetak hasil yg bersangkutan.
• Stubs –> untuk menggantikan modul-modul yg merupakan subordinat (dipanggil oleh) komponen yg dites.

Penerapan dari driver dan stubs dapat dilihat pada gambar dibawah ini:

Testing dan Implementasi Sistem Pertemuan 5

State Transition Testing

State transition testing menggunakan model sistem, yang terdiri dari:

• Status yang terdapat di dalam program.
• Transisi antar status-status tersebut.
• Kejadian yang merupakan sebab dari transisi - transisi tersebut.
• Aksi - Aksi yang akan dihasilkan

Misal terdapat suatu state transition diagram yang menangani masukan permintaan untuk
mode tampilan terhadap waktu tampilan dari suatu device, sebagai berikut:

State transition diagram di atas terdiri dari:

• Status, seperti displaying time (S1)
• Transisi, seperti antara S1 dan S3
• Kejadian yang menyebabkan transisi, seperti "reset" selama status S1 akan menyebabkan transisi ke S3.
• Aksi yang merupakan hasil dari transisi, seperti selama transisi dari S1 ke S3 sebagai hasil dari kejadian “reset”, aksi “display time” akan terjadi.

Test cases didisain untuk memeriksa transisi-transisi yang valid.
Untuk tiap test case, terdapat spesifikasi sebagai berikut:

• Status mulai.
• Masukan.
• Keluaran yang diharapkan.
• Status akhir yang diharapkan.

Berdasarkan contoh di atas, terdapat 6 test cases:

Testing dan Implementasi Sistem Pertemuan 4

Lines of Code

Pengukuran sederhana: menghitung jumlah baris kode dalam program dan menggunakan perhitungan ini untuk mengukur kompleksitas.

Berdasarkan studi yang telah dilakukan :

• Program kecil mempunyai error rata-rata 1,3 % sampai 1,8 %.
  
• Program besar mempunyai kenaikan error rata-rata dari 2,7 % sampai 3,2 %.

Halstead’s metric adalah pengukuran yang berdasarkan pada penggunaan operator-operator
atabase) yang ada
(seperti kata kunci) dan operan-operan (seperti nama variabel, obyek d
dalam suatu program.
n1 = jumlah operator yang unik (distinct) dalam program
n2 = jumlah operan yang unik (distinct) dalam program.
Panjang program: H = n1 log2 n1 + n2 log2 n2.
N1 = perhitungan jumlah keseluruhan operator program. N2 = perhitungan jumlah keseluruhan operan program.
Prediksi bug: B = (N1 + N2) log2 (n1 + n2) / 3000

Black Box Testing

Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari sistem atau komponen yang dites. juga disebut sebagai behavioral testing, specification-based testing, input/output testing atau functional testing.

Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software.

Black box testing bukan teknik alternatif daripada white box testing. Lebih daripada itu, ia merupakan pendekatan pelengkap dalam mencakup error dengan kelas yang berbeda dari metode white box testing. Kategori error yang akan diketahui melalui black box testing:

• Fungsi yang hilang atau tak benar
• Error dari antar-muka
• Error dari struktur data atau akses eksternal database
• Error dari kinerja atau tingkah laku
• Error dari inisialisasi dan terminasi

Tak seperti white box testing, yang dipakai pada awal proses testing. Black box testing digunakan pada tahap akhir dan berfokus pada domain informasi. Tes didisain untuk menjawab pertanyaan sebagai berikut:

• Bagaimana validasi fungsi yang akan dites?
• Bagaimana tingkah laku dan kinerja sistem dites?
• Kategori masukan apa saja yang bagus digunakan untuk test cases?
• Apakah sebagian sistem sensitif terhadap suatu nilai masukan tertentu?
• Bagaimana batasan suatu kategori masukan ditetapkan?
• Sistem mempunyai toleransi jenjang dan volume data apa saja?
• Apa saja akibat dari kombinasi data tertentu yang akan terjadi pada operasi sistem?

Terdapat banyak jenis teknik disa
akan digunakan [BCS97A], yaitu:

• Equivalence Class Partitioning
  
• Boundary Value Analysis
  
• State Transitions Testing
• Cause-Effect Graphing
  

Testing dan Implementasi Sistem Pertemuan 3

Desain Test Case

Tiap produk hasil rekayasa dapat di tes dalam dua cara:

• Dengan berdasarkan pada fungsi yang dispesifikasikan dari produk, tes dapat dilakukan dengan mendemonstrasikan tiap fungsi telah beroperasi secara penuh sesuai dengan yang diharapkan, dan sementara itu, pada saat yang bersamaan, dilakukan pencarian error pada tiap fungsi.

• Dengan mengetahui operasi internal dari produk, tes dapat dilakukan untuk memastikan semua komponen berjalan sebagaimana mestinya, operasi internal berlaku berdasarkan pada spesifikasi dan semua komponen internal telah cukup diperiksa.

Pendekatan cara pertama biasa disebut dengan black box testing, dan pendekatan cara kedua disebut white box testing.

Definisi Test Case

Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya.
Adapun kegunaan dari test case ini, adalah sebagai berikut:

• Untuk melakukan testing kesesuaian suatu komponen terhadap spesifikasi – Black Box Testing.

• Untuk melakukan testing kesesuaian suatu komponen terhadap disain – White Box Testing.

Hal yang perlu diingat bahwa testing tidak dapat membuktikan kebenaran semua kemungkinan eksekusi dari suatu program. Namun dapat didekati dengan melakukan perencanaan dan disain tes case yang baik sehingga dapat memberikan jaminan efektifitas dari software sampai pada tingkat tertentu sesuai dengan yang diharapkan.
White Box Testing

White Box Testing disebut juga glass box testing atau clear box testing, adalah suatu metode disain test case yang menggunakan struktur kendali dari disain prosedural.
Metode disain test case ini dapat menjamin:

• Semua jalur (path) yang independen / terpisah dapat dites setidaknya sekali tes.
• Semua logika keputusan dapat dites dengan jalur yang salah dan atau jalur yang benar.
• Semua loop dapat dites terhadap batasannya dan ikatan operasionalnya.
• Semua struktur internal data dapat dites untuk memastikan validitasnya.

Mengapa melakukan white box testing bilamana black box testing berfungsi untuk testing pemenuhan terhadap kebutuhan / spesifikasi?

• Kesalahan logika dan asumsi yang tidak benar kebanyakan dilakukan ketika coding untuk “kasus tertentu”. Dibutuhkan kepastian bahwa eksekusi jalur ini telah dites.

• Asumsi bahwa adanya kemungkinan terhadap eksekusi jalur yang tidak benar. Dengan white box testing dapat ditemukan kesalahan ini

• Kesalahan penulisan yang acak. Seperti berada pada jalur logika yang membingungkan pada jalur normal.

Argumen di atas adalah kesalahan-kesalahan yang tak dapat ditemukan dengan menggunakan black box testing yang terbaik sekalipun.

Cakupan pernyataan, cabang dan jalur

Cakupan pernyataan, cabang dan jalur adalah suatu teknik white box testing yang menggunakan alur logika dari program untuk membuat test cases. Yang dimaksud dengan alur logika adalah cara dimana suatu bagian dari program tertentu dieksekusi saat menjalankan program. Alur logika suatu program dapat direpresentasikan dengan flow graph.

Suatu flow graph terbentuk dari:

• Nodes (titik), mewakili pernyataan (atau sub program) yang akan ditinjau saat eksekusi program.

• Edges (anak panah), mewakili jalur alur logika program untuk menghubungkan satu pernyataan (atau sub program) dengan yang lainnya.

• Branch nodes (titik cabang), titik-titik yang mempunyai lebih dari satu anak panah keluaran.

• Branch edges (anak panah cabang), anak panah yang keluar dari suatu cabang

• Paths (jalur), jalur yang mungkin untuk bergerak dari satu titik ke lainnya sejalan dengan keberadaan arah anak panah.

Disain cakupan tes

Untuk mendisain cakupan dari tes, perlu diketahui tahap-tahap sebagai berikut:

1. Menganalisa source code untuk membuat flow graph.
2. Mengidentifikasi jalur tes untuk mencapai pemenuhan tes berdasarkan pada flow graph.
3. Mengevaluasi kondisi tes yang akan dicapai dalam tiap tes.
4. Memberikan nilai masukan dan keluaran berdasarkan pada kondisi.

Basis Path Testing

Merupakan teknik white box testing yang dikenalkan oleh Tom McCabe [MC76]. Metode ini memungkinkan pendisain test cases untuk melakukan pengukuran terhadap kompleksitas logika dari disain prosedural dan menggunakannya sebagai panduan dalam menentukan kelompok basis dari jalur eksekusi, dimana hal ini akan menjamin eksekusi tiap pernyataan dalam program sekurangnya sekali selama testing berlangsung.

Basis path hadir dalam 2 bentuk, yaitu:

• Zero Path: Jalur penghubung yang tidak penting atau jalur pintas yang ada pada suatu
  sistem.
• One Path: Jalur penghubung yang penting atau berupa proses pada suatu sistem.

Cyclomatic Complexity

Adalah pengukuran software yang memberikan pengukuran kuantitatif dari kompleksitas
logika program.

Pada konteks metode basis path testing, nilai yang dihitung bagi cyclomatic complexity menentukan jumlah jalur - jalur yang independen dalam kumpulan basis suatu program dan memberikan jumlah tes minimal yang harus dilakukan untuk memastikan bahwa semua
pernyataan telah dieksekusi sekurangnya satu kali. Jalur independen adalah tiap jalur pada program yang memperlihatkan 1 kelompok baru dari pernyataan proses atau kondisi baru.

[Region / Complexity] V(G) = E (edges) – N (nodes) + 2

V(G) = P (predicate node) + 1

Graph Matrix

Adalah matrik berbentuk segi empat sama sisi, dimana jumlah baris dan kolom sama dengan lah node, jum dan identifikasi baris dan kolom sama dengan identifikasi node, serta isi data adalah keberadaan penghubung antar node (edges).

Berikut contohnya :

Testing dan Implementasi Sistem Pertemuan 2

Obyektifitas Testing

Secara umum obyektifitas dari testing adalah untuk melakukan verifikasi, validasi dan deteksi error untuk menemukan masalah dan tujuan dari penemuan ini adalah untuk membenahinya.
Namun terdapat pula beberapa pendapat dari praktisi yang dapat pula dipandang sebagai bagian dari obyektifitas testing, antara lain:

• Meningkatkan kepercayaan bahwa sistem dapat digunakan dengan tingkat resiko yang dapat diterima.
• Menyediakan informasi yang dapat mencegah terulangnya error yang pernah terjadi.
• Menyediakan informasi yang membantu untuk deteksi error secara dini.
• Mencari error dan kelemahan atau keterbatasan sistem.
• Mencari sejauh apa kemampuan dari sistem.
• Menyediakan informasi untuk kualitas dari produk software.

Misi dari Tim Testing

Misi dari tim testing tidak hanya untuk melakukan testing, tapi juga untuk membantu meminimalkan resiko kegagalan proyek.
Tester mencari manifestasi masalah dari produk, masalah yang potensial, dan kehadiran dari masalah. Mereka mengeksplorasi, mengevaluasi, melacak, dan melaporkan kualitas produk, sehingga tim lainnya dari proyek dapat membuat keputusan terhadap pengembangan produk.
Penting diingat bahwa tester tidak melakukan pembenahan atau pembedahan kode, tidak mempermalukan atau melakukan komplain pada suatu individu atau tim, hanya menginformasikan.
Tester adalah individu yang memberikan hasil pengukuran dari kualitas produk.

Prinsip-Prinsip Testing

Terdapat 6 kunci prinsip-prinsip testing, yaitu:

• Testing yang komplit tidak mungkin.
• Testing merupakan pekerjaan yang kreatif dan sulit.
• Alasan yang penting diadakannya testing adalah untuk mencegah terjadinya errors.
• Testing berbasis pada resiko.
• Testing harus direncanakan.
• Testing membutuhkan independensi.

Testing dan Implementasi Sistem Pertemuan 1

Definisi Testing

Beberapa definisi tentang testing:

1. Menurut Hetzel 1973:
   Testing adalah proses pemantapan kepercayaan akan kinerja program atau sistem sebagaimana yang diharapkan.
2. Menurut Myers 1979:
   Testing adalah proses eksekusi program atau sistem secara intens untuk menemukan error.
3. Menurut Hetzel 1983 (Revisi):
   Testing adalah tiap aktivitas yang digunakan untuk dapat melakukan evaluasi suatu atribut atau kemampuan dari program atau sistem dan menentukan apakah telah memenuhi kebutuhan atau hasil yang diharapkan.
   
4. Menurut Standar ANSI/IEEE 1059:
   Testing adalah proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan (defects / errors / bugs) dan mengevaluasi fitur-fitur dari entitas software.

Beberapa pandangan praktisi tentang testing, adalah sebagai berikut:

• Melakukan cek pada program terhadap spesifikasi.
• Menemukan bug pada program.
• Menentukan penerimaan dari pengguna.
• Memastikan suatu sistem siap digunakan.
• Meningkatkan kepercayaan terhadap kinerja program.
• Memperlihatkan bahwa program berkerja dengan benar.
• Membuktikan bahwa error tidak terjadi.
• Mengetahui akan keterbatasan sistem.
• Mempelajari apa yang tak dapat dilakukan oleh sistem.
• Melakukan evaluasi kemampuan sistem.
• Verifikasi dokumen.
• Memastikan bahwa pekerjaan telah diselesaikan.

Berikut ini adalah pengertian testing yang dihubungkan dengan proses verifikasi dan validasi software:
Testing software adalah proses mengoperasikan software dalam suatu kondisi yang di kendalikan, untuk (1) verifikasi apakah telah berlaku sebagaimana telah ditetapkan (menurut spesifikasi), (2) mendeteksi error, dan (3) validasi apakah spesifikasi yang telah ditetapkan sudah memenuhi keinginan atau kebutuhan dari pengguna yang sebenarnya.

• Verifikasi adalah pengecekan atau pengetesan entitas-entitas, termasuk software, untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan. (Are we building the system right ?)
• Validasi melihat kebenaran sistem, apakah proses yang telah ditulis dalam spesifikasi adalah apa yang sebenarnya diinginkan atau dibutuhkan oleh pengguna. (Are we building the right system?)
• Deteksi error: Testing seharusnya berorientasi untuk membuat kesalahan secara intensif, untuk menentukan apakah suatu hal tersebut terjadi bilamana tidak seharusnya terjadi atau suatu hal tersebut tidak terjadi dimana seharusnya mereka ada.

Dari beberapa definisi di atas, dapat kita lihat akan adanya banyak perbedaan pandangan dari praktisi terhadap definisi testing.
Namun secara garis besar didapatkan bahwa testing harus dilihat sebagai suatu aktifitas yang menyeluruh dan terus-menerus sepanjang proses pengembangan.
Testing merupakan aktifitas pengumpulan informasi yang dibutuhkan untuk melakukan evaluasi efektifitas kerja.
Jadi tiap aktifitas yang digunakan dengan obyektifitas untuk menolong kita dalam mengevaluasi atau mengukur suatu atribut software dapat disebut sebagai suatu aktifitas testing. Termasuk di dalamnya review, walk-through, inspeksi, dan penilaian serta analisa yang ada selama proses pengembangan. Dimana tujuan akhirnya adalah untuk mendapatkan informasi yang dapat diulang secara konsisten (reliable) tentang hal yang mungkin sekitar software dengan cara termudah dan paling efektif, antara lain:

• Apakah software telah siap digunakan?
• Apa saja resikonya?
• Apa saja kemampuannya?
• Apa saja keterbatasannya?
• Apa saja masalahnya?
• Apakah telah berlaku seperti yang diharapkan?

Definisi Sederhana Kualitas

Berikut ini beberapa definisi sederhana tentang kualitas:

1. Menurut CROSBY:
   Kualitas adalah pemenuhan terhadap kebutuhan.
2. Menurut ISO-8402:
   Kualitas adalah keseluruhan dari fitur yang menjadikan produk dapat memuaskan atau dipakai sesuai kebutuhan dengan harga yang terjangkau.
3. Menurut W.E. Perry:
   Kualitas adalah pemenuhan terhadap standar.
4. Menurut R. Glass:
   Kualitas adalah tingkat kesempurnaan.

Hubungan Testing dan Kualitas

Definisi software berkualitas adalah software yang bebas error dan bug secara obyektif, tepat waktu dan dana, sesuai dengan kebutuhan atau keinginan dan dapat dirawat (maintainable).
Pengertian kata obyektif adalah suatu proses pembuktian yang terstruktur, terencana dan tercatat / terdokumentasi dengan baik.
Pendekatan yang obyektif sangat diperlukan karena kualitas adalah suatu hal yang tidak nyata dan subyektif. Ia tergantung pada pelanggan dan hal-hal lain yang mempengaruhinya secara keseluruhan.
Pelanggan pada proyek pengembangan software dapat meliputi pengguna akhir (end-users), tester dari pelanggan, petugas kontrak dari pelanggan, pihak manajemen dari pelanggan, pemilik saham, reviewer dari majalah, dan lain-lain, dimana tiap tipe pelanggan akan mempunyai sudut pandang sendiri terhadap kualitas.
Testing membuat kualitas dapat dilihat secara obyektif, karena testing merupakan pengukuran dari kualitas software. Dengan kata lain testing berarti pengendalian kualitas (Quality Control - QC), dan QC mengukur kualitas produk, sedangkan jaminan kualitas (Quality Assurance – QA) mengukur kualitas proses yang digunakan untuk membuat produk berkualitas.

Faktor-faktor kualitas software secara umum dapat dibedakan menjadi tiga faktor, yaitu fungsionalitas, rekayasa, dan adaptabilitas. Berikut contoh yang mengilustrasikan beberapa faktor-faktor komponen yang sering digunakan:

1. Fungsionalitas (Kualitas Luar)

• Kebenaran (Correctness)
• Reliabilitas (Reliability)
• Kegunaan (Usability)
• Integritas (Integrity)

2. Rekayasa (Kualitas Dalam)

• Efisiensi (Efficiency)
• Testabilitas (Testability)
• Dokumentasi (Documentation)
• Struktur (Structure)

3. Adaptabilitas (Kualitas ke Depan)

• Fleksibilitas (Flexibility)
• Reusabilitas (Reusability)
• Maintainabilitas (Maintainability)

Karena itu testing yang bagus harus dapat mengukur semua faktor-faktor yang berhubungan, yang tentunya tiap faktor komponen akan mempunyai tingkat kepentingan berbeda-beda antar satu aplikasi dengan aplikasi yang lain. Contohnya pada sistem bisnis yang umum komponen faktor kegunaan dan maintainabilitas merupakan faktor-faktor kunci, dimana untuk program yang bersifat teknik mungkin tidak menjadi faktor kunci.
Jadi agar testing dapat sepenuhnya efektif, maka harus dijalankan untuk melakukan pengukuran tiap faktor yang berhubungan dan juga menjadikan kualitas menjadi nyata dan terlihat.

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 :