Fase Design

Pada phase disain tim pengembang perangkat lunak melakukan aktivitas untuk menjawab pertanyaan "how to build the system". Tim pengembang akan membuat "system requirements". System requirements menjelaskan aspek-aspek teknik untuk membangun perangkat lunak. Sudah tentu, system requirements ini sangat erat kaitannya dengan functional requirements dan user requirements (yang telah dimodelkan sebelumnya pada fase modelling). Selain melakukan aktivitas yang berhubungan dengan system requirements, maka tim pengembang juga menghasilkan apa yang disebut system specification. Yakni berupa artifak yang terkait dengan pembangunan aplikasi/sistem informasi. 

Beberapa aktivitas umum yang dilakukan di fase disain diantaranya adalah:

1) Menentukan alternatif pilihan apakah akan membuat sendiri, membeli aplikasi jadi atau di-outsource

2) Menerjemahkan model logical (yang telah dibuat pada fase modelling) menjadi physical models.

3) Mendisain "the architecture" dari sistem aplikasi 

4) Menentukan lingkunga implementasi hardware dan software

5) Mendisain sistem masukan dan keluaran, yakni antar-muka penggunanya.

6) Mendisain basis data

7) Mendisain struktur program

8) Membuat laporan dokumentasi (misalnya dokumen SRS)

Saat fase disain berlangsung, biasanya ada beberapa "masalah" yang harus diwaspadai oleh Tim Pengembang, diantaranya adalah ...

1) Feature Creep
ini adalah masalah yang sering terjadi, yakni bertambahnya fitur yang menjadi requirement fungsional dari aplikasi.

2) Silver bullet syndrome
Penjelasan mengenai hal ini sudah saya kupas tuntas disini.

Pengalaman saya dalam mengembangkan aplikasi dan sistem informasi selama ini, menunjukkan bahwa feature creep dan silver bullet syndrome adalah "masalah" yang SELALU terjadi saat fase disain berlangsung. Hal ini tentu saja, harus menjadi perhatian serius dari Tim Pengembang.

Beberapa catatan saya yang terkait pembahasan kuliah Pengantar Fase Disain dapat diklik disini:
1) Tentang Silver Bullet Syndrome
2) Tentang Mengerjakan Proyek Perangkat Lunak
3) Tentang e-Journal Universitas Sam Ratulangi

Catatan:

Slide Kuliah tentang Pengantar Fase Design dapat diunduh disini. 
Pertanyaan dapat diposting sebagai komentar dibawah tulisan ini.

Business Use-case Model

Menggambar Business Use-case Model
 

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. Model ini diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat (kadang bersifat optional, dimana dapat diilustrasikan dalam satu atau beberapa business use-case diagram).

Dalam prakteknya Business Use-case Model digunakan bersamaan dengan UML Activity Diagram untuk menggambarkan proses bisnis. Menggunakan model Business Use-case sebenarnya dapat mempertajam pemahaman tim pengembang dan user terkait model bisnis sistem informasi yang akan dikembangkan.
 

Business use-case model dibangun dengan elemen-elemen: Business Actor, Business Use-case, dan Activity Diagram untuk menjelaskan model business use-case
 

Business Actor:
Business actor (aktor bisnis) mengambarkan peran yang dimainkan oleh seorang atau sesuatu yang berinteraksi dengan bisnis. Sebuah business actor mengambarkan seorang customer , partner bisnis, atau sebuah sistem informasi yang berhubungan dengan bisnis kita

Gambar dari Business Actor

 

Business Use-case
Business use-case merupakan urutan tindakan yang dimainkan suatu bisnis yang menghasilkan sebuah nilai yang dapat dilihat dan ditunjukan untuk suatu business actor tertentu. Satu business use-case mewakili satu proses bisnis

Gambar dari Business Use-case

Berikut adalah sebuh Contoh Gambar Business use-case Model dari studi kasus sebelumnya disini

UML Use-case Diagram

Menggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
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.

Contoh Use-case (include)

 

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
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.

Contoh Use-case (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

Sebuah Video Tutorial tentang UML Use Case Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=Zk-580BqSNY&feature=relmfu

UML Activity Diagram

Langkah pertama yang HARUS dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak.

Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. Pada bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis. Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun. Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak.

Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun.

Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram. 

Pada bagian tulisan ini, saya akan menuliskan tentang memodelkan proses bisnis dengan Activity Diagram. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang: awal proses, decision, akhir proses, proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu

Notasi dalam Activity Diagram

Cara menggambarkan activity diagram:

1. Menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. 

2. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

3. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

4. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya.

Tentang Activity Diagram:

Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan. Activity diagram di bawah ini memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.

Contoh pada Studi Kasus:

Pada sebuah Foodcourt. Pembeli datang ke foodcourt, menuju stand penjual makanan yang dinginkan. Pembeli memesan makanan, jika makanan tersebut ada, maka pesanan disiapkan, jika makanan tersebut tidak ada maka pembeli tidak jadi memesan makanan. Setelah memesan, petugas stand menyiapkan bon dua rangkap dan memberikan bon tersebut kepada pembeli.

Pembeli kemudian membayar makanan yang dibeli di kasir stand dengan menyerahkan bon pembelian. Kasir menghitung jumlah yang harus dibayar pembeli dan menginformasikannya ke pembeli. Pembeli menyiapkan uang dan memberikan kepada kasir. Jika ada kembalian, kasir menghitung kembalian tersebut dan memberikan kembalian beserta bukti pembayaran (struk) serta bon yang sudah ditandai lunas.

Pembeli mencari tempat duduk, penjual stand makanan memberikan makanan kepada pembeli dengan mengambil bon yang sudah ditandai lunas tersebut.

Activity Diagram Pembayaran

Activity Diagram Pemesanan

Sebuah Video Tutorial tentang Activity Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=yAihwmczqsk&feature=related

UML dan Pemodelan Software

Pemodelan pada dasarnya merupakan kegiatan untuk menyederhanakan. Seperti misalnya kita ingin memahami tentang bentuk bumi yang seperti bola. Alih-alih kita melihat bumi dari luar angkasa, maka kita mengambil benda yang “menyerupai” bola, dan kemudian mulai memodelkan bumi yang sebenarnya.

Kegiatan pemodelan perangkat lunak berorientasi obyek adalah kegiatan untuk mencoba menyederhanakan perangkat lunak yang akan kita kembangkan dengan terlebih dahulu membuat model visualisasi (penggambaran model) perangkat lunak yang akan dikembangkan. Pembuatan model visualisasi perangkat lunak dilakukan dengan menggunakan kakas yang disebut Unified Modelling Language atau disingkat UML. 

Jadi, sebenarnya UML adalah:

1. sebuah "bahasa" pemodelan perangkat lunak standar yang dapat digunakan untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-komponen perangkat lunak.
2. bahasa pemodelan visual yang notasi grafis yang ekspresif dalam arti lengkap dan mudah dipahami, baik oleh pengembang maupun user.
3. menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi obyek seperti C++, Java, C# atau VB.NET.

Tiga hal yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:

1. Memahami maksud dan tujuan digunakannya UML
2. Memahami apa yang akan dimodelkan dalam UML
3. Menguasai langkah-langkah pembuatan diagram UML

Ada beberapa notasi grafis dalam UML yang dapat digunakan untuk memodelkan aplikasi perangkat lunak berorientasi obyek. Notasi grafis atau disebut juga diagram tersebut memiliki bermacam-macam sudut-pandang (atau disebut perspektif) untuk menunjukkan model perangkat lunak. Diagram-diagram tersebut juga menunjukkan tingkat abstraksi pemodelan berorientasi obyek yang berbeda-beda. Berikut adalah Ringkasan Diagram UML ver 2.0 yang diambil dari buku System Analysis and Design with UML version 2; An Object-Oriented Approach,2nd Ed. By Allan Dennis, Barbara Wixon, David Tegarden. © John Wiley&Sons, 2010

Bagaimana memodelkan perangkat lunak dengan UML?

Terdapat banyak variasi dalam memodelkan perangkat lunak dengan menggunakan UML. Dibawah ini saya memberikan saran untuk memodelkan perangkat lunak dengan menggunakan UML. Tidak berarti bahwa saran saya ini adalah yang paling tepat, penyesuaian terhadap langkah-langkah pemodelan itu sangat terbuka. Masing-masing pengembang dapat menemukan "best practices"-nya sendiri. Urutan langkah yang disarankan untuk memodelkan perangkat lunak dengan menggunakan UML adalah:

1. Buatlah daftar proses business dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. Langkah ini dapat dilakukan dengan membuat FDD (functional decomposition diagram) ataupun dengan membuat Business Use Case Model dan Business Object Model (BOM).
2. Petakan use case untuk tiap proses business untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem dengan mengisi use case table.
4. Berdasarkan use case table, highlight semua potensial obyek dan dari situ pilihlah obyek yang dapat dijadikan sebuah kelas. Kemudian, gambarkan high-level class digram dan detailed class diagram.
5. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Oleh karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
6. Berdasarkan use case diagram, mulailah membuat activity diagram.
7. Setelah activity diagram selesai dibuat, maka langkah selanjutnya yaitu mendefinisikan objek-objek level atas (package atau domain). Lalu buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
8. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
9. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
10. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan:
11. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
12. Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
13. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
14. Piranti lunak siap dirilis.

Sebuah Video Tutorial tentang Introduction to UML, bisa dilihat disini:
http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel