Ini adalah salah satu konsep yang perlu kita terapkan pada setiap tahap pembangunan perangkat lunak, terutama tahap analisis dan perancangan. Dengan menerapkan konsep ini, kita belajar memodelkan persoalan dan solusi dalam beberapa level abstraksi. Makin lama makin detil, sehingga makin siap untuk di-coding.

Dari kuesioner peserta kuliah RPLL, kesulitan yang sering dihadapi adalah mendetilkan model. Misalnya, menurunkan suatu proses di DFD ke level berikutnya. Kenapa ini sulit ? Salah satu penyebabnya adalah karena kita belum banyak tahu tentang persoalan yang harus dimodelkan. Tentu saja jadi sulit. Untuk itu, komunikasi yang intensif dengan customer atau user perlu dilakukan untuk menggali lebih dalam persoalan yang akan diselesaikan. Jika kita tidak berhasil mendapatkan informasi tentang sesuatu hal, maka berbagai asumsi harus ditetapkan. Tentu saja asumsi yang masuk akal…

Ya, refinement bisa kita lakukan apabila kita sudah lebih paham tentang apa yang ingin dimodelkan…

Kesulitan dalam menentukan ‘ukuran’ use case -menurut saya- mirip dengan kesulitan untuk menentukan ‘ukuran’ class. Apakah suatu fitur X cukup dijadikan sebuah use case atau harus dipecah menjadi beberapa use case ?

Menentukan use case untuk software yang akan kita buat tidak bisa dilakukan sekali jadi. Perlu iterasi yang mungkin lebih dari dua kali. Bisa jadi, saat awal kita mendefinisikan sebuah use case X, tetapi di iterasi berikutnya kita memutuskan untuk memecahnya menjadi use case X1 dan X2 (atau sebaliknya: menggabung beberapa use case menjadi sebuah use case saja). Keputusan tersebut biasanya dibuat setelah kita lebih detil menurunkan skenario use
case atau saat kita sudah mulai melakukan analisis use case (lihat realisasi use case).

Salah satu pedoman yang bisa digunakan adalah dengan melihat kelas-kelas yang berhasil diidentifikasi untuk use case tersebut, serta melihat kolaborasi antar class untuk setiap skenario use case. Jika skenario-skenario use case memperlihatkan kolaborasi class yang berbeda, mungkin itu adalah pertanda bahwa use case bisa dipecah. Jika hasil identifikasi class menunjukkan jumlahnya yang terlalu sedikit (kurang dari 3 misalnya), mungkin itu pertanda bahwa ‘ukuran’ use case kita terlalu kecil.

Kecil atau besar ?  Mana yang lebih baik ? Seperti class jika use case kita terlalu kecil, use case kita memang jadi lebih generik, tetapi kita akan kesulitan mengelola sekian banyak use case. Jika use case terlalu besar, fitur yang dimodelkan jadi terlalu spesifik sehingga akan sulit di-reuse. Jadi, carilah ‘ukuran’ yang paling optimal, yang sedang-sedang saja…

Setelah mendefinisikan kebutuhan dalam bentuk use case, bagaimana merealisasikannya ? Setiap use case harus dibuat deskripsinya lengkap dengan berbagai kemungkinan skenarionya. Skenario memberi gambaran bagaimana interaksi actor dan sistem. Selanjutnya, kita bisa mulai mengidentifikasi objek-objek apa saja yang akan terlibat dalam suatu use case (breakdown dari ’sistem’). Tentu saja dengan mengacu deskripsi skenario yang telah dibuat. Kemudian gambarkan dalam bentuk diagram interaksi (boleh collaboration diagram atau sequence diagram) agar lebih jelas bagaimana sebuah skenario berjalan dalam terminologi kolaborasi antar objek. Ya, pada paradigma berorientasi-objek, suatu skenario berjalan melalui kolaborasi antar objek. Dari diagram interaksi tersebut, selanjutnya kita gambarkan diagram kelas. Diagram ini menunjukkan kelas-kelas yang harus ada agar objek-objek yang dibutuhkan bisa diinstansiasi dari kelas-kelas tersebut. Diagram kelas menunjukkan berbagai jenis relasi antar kelas. Relasi ini harus konsisten dengan diagram interaksi objek yang sudah kita buat sebelumnya.

Realisasi use case dilakukan di tahap analisis dan berlanjut di tahap design. Bedanya, realisasi use case tahap analisis melibatkan objek dan kelas  tahap analisis, sedangkan realisasi use case tahap design melibatkan objek dan kelas tahap design. Apa bedanya ? Lihat lagi posting OOA vs OOA…

Dengan metode terstruktur (di buku Pressman disebut metode konvensional) pada tahap analisis kita memodelkan PROBLEM dari tiga sudut pandang:

1. pemodelan fungsional; kita memodelkan fungsional P/L dalam terminologi proses dan aliran data antar proses; kita membuat DFD (data flow diagram)
2. pemodelan data; kita memodelkan kebutuhan data yang yang harus dikelola P/L dalam terminologi entitas data dan relasi antar-entitas; kita membuat ERD (entity-relationship diagram)
3. pemodelan kelakuan (behaviour); kita memodelkan aspek dinamis P/L dalam terminologi state, event, dan action; kita amembuat STD (state transition diagram)

Kenapa harus dari tiga sudut pandang ?

Ya, untuk mendapatkan gambaran yang lengkap tentang suatu hal, akan lebih baik kalau kita memotretnya dari berbagai sudut pandang. Tapi jangan lupa, kita harus memastikan bahwa model yang kita buat dari berbagai sudut pandang tersebut harus dikelola dengan baik sehingga konsisten.

Ingat cerita tentang tiga orang buta yang ingin memahami gajah ? Satu orang meraba belalai gajah sehingga dia mendapat gambaran bahwa gajah itu panjang. Satu orang lagi meraba kupingnya, sehingga dia mendapat gambaran bahwa gajah itu lebar dan pipih. Satu orang lagi meraba badannya, sehingga dia memperolah gambaran bahwa gajah itu besar dan berkulit kasar. Jika informasi-informasi tersebut tidak dikelola dan dikoordinasikan, gambaran akhir tentang gajah akan jadi salah kan ??

Jadi, pastikan ketiga model di atas juga saling melengkapi dan konsisten. Misalnya, proses pada DFD harus didukung dengan adanya action di STD. Data store di DFD harus didukung dengan adanya entitas/relasi di ERD. Dst…

SRS (Software Requirement Specification) yang baik adalah yang memenuhi kriteria berikut:

• correct; setiap pernyataan kebutuhan yang disebutkan adalah benar-benar merupakan fitur yang akan disediankan S/W
• unambiguous; setiap pernyataan kebutuhan hanya punya satu interpretasi
• complete; mencakup seluruh kebutuhan (fungsional, performansi, dll), definisi respon S/W terhadap seluruh data masukan (valid dan tidak valid) dalam berbagai situasi
• consistent; konsisten dengan dokumen di level yang lebih atas (mis. system requirement)
• ranked for importance and/or stability; setiap pernyataan kebutuhan diberi identitas yang menunjukkan tingkat importance/stability-nya (misalnya: essensial, conditional, optional)
• verifiable; untuk setiap pernyataan kebutuhan, harus ada proses yang cost-effective untuk memverifikasi bahwa S/W sudah memenuhi kebutuhan tersebut
• modifiable; struktur dokumen harus sedemikian rupa sehingga pengubahan yang terjadi dapat dilakukan dengan mudah, lengkap, dan konsisten
• traceable; setiap pernyataan kebutuhan harus jelas sumbernya dan mudah diacu

(Dari IEEE Std 830-1998)

Berikut adalah beberapa kesalahan umum yang sering terjadi pada pemodelan DFD:

• magic; sebuah proses (bubble) hanya mempunyai output (tidak punya input); proses tersebut tiba-tiba berjalan tanpa ada trigger apapun ?
• black hole; sebuah proses (bubble) hanya mempunyai input (tidak punya output); buat apa diproses kalau tidak dibutuhkan suatu keluarannya ?
• data store yang hanya diisi saja, tidak pernah dibaca; buat apa menyimpan data kalau tidak diperlukan?
• data store yang hanya dibaca saja, tidak pernah diisi; seringkali alasannya adalah data hanya diisi di awal saja, manual… Jika kasusnya seperti ini, ubah data store jadi entitas eksternal
• data masukan (input) suatu proses sama namanya dengan data keluaran (output) dari proses tersebut; data hanya ‘jalan-jalan’ keluar masuk proses ?
• tidak balanced; jumlah data masukan dan keluaran suatu proses -A, misalnya- tidak sama dengan jumlah data masukan dan keluaran pada DFD level berikutnya untuk proses A; gunakan tool agar terhindar dari kesalahan ini…
• data dari entitas eksternal ‘nyelonong’ masuk ke data store; harusnya ada proses yang menuliskannya ke data store
• data dari sebuah data store pindah sendiri ke data store lain; harusnya ada proses yang memindahkannya…

Apa lagi ya ?