UML Dan Waterfall Process

UML

1) Pengertian

Ialah bahasa pemodelan grafis yang membantu mendeskripsikan dan mendesain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemograman berorientasi objek (OO). Namun pada kenyataannya, pendapat dan penggunaannya tentang UML memiliki persepsi dan cara-cara yang berbeda satu sama lain dalam membuat sebuah proses pengembangan perangkat lunak. UML mempunyai 3 karakter, yaitu:

1. Sketsa

Sebagai sebuah sketsa, UML bisa berfungi sebagai jembatan dalam mengkomunikasikan beberapa aspek dari sistem. Dengan demikian, semua anggota tim akan mempunyai gambaran yang sama tentang suatu sistem.

2. Blueprint

Berfungsi untuk mendapatkan informasi yang detil dan lengkap. Terdapat 2 teknik, baik secara forward engineering (menggambar sebuah diagram UML sebelum membuat kode) maupun reverse engineering (membuat diagram dari kode yang sudah ada untuk membantu memahaminya).
Contoh : >> Dalam forward engineering, blueprint dibuat oleh seorang desainer untuk membuat desain yang detail untuk dikodekan oleh seorang programmer. Desain ini harus cukup lengkap, dalam artian seluruh keputusan desain telah dijabarkan dan programmer harus dapat mengikutinya tanpa perlu berpikir keras. Desainer bisa jadi merupakan orang sama dengan programmer, tetapi biasanya desainer adalah developer yang lebih senior yang mendesain sistem bersama tim programmer. Langkah umum desainer adalah membuat model blueprint sampai tingkat interface subsistem dan menyerahkan kepada developer untuk mengerjakan detil penerapannya tersebut.
>> Sedangkan dalam reverse engineering, blueprint bertujuan untuk menyampaikan informasi detil tentang kode baik dalam dokumen cetak atau sebagai browser grafis interaktif atau dinamis. Dengan cara yang dinamis akan sangat membantu untuk menunjukkan setiap detil sebuah class di sebuah bentuk grafis yang memudahkan developer dalam memahaminya. Namun, jika digunakan untuk membuat dokumen yang besar, blueprint akan menghapus cabang-cabangnya. 

3. Bahasa Pemograman 

UML sebagai bahasa pemograman, yaitu dapat menerjemahkan diagram yang ada di UML menjadi kode program yang siap dijalankan. Di dalam UML 2.0, menawarkan 3 cara pemodelan logika behaviour : interaction diagram, state diagram, dan activity diagram. Semuanya mempunyai kelebihan dalam pemograman. Jika UML menjadi terkenal sebagai bahasa pemograman, akan menjadi menarik untuk melihat teknik mana yang akan berhasil. 

2) Model dan Diagram 

Di proyek pengembangan sistem apapun, fokus utama dalam analisis dan perancangan adalah model. Hal ini berlaku umum tidak hanya untuk perangkat lunak. Dengan model kita bisa mempresentasikan sesuatu karena: 

• Model mudah dan cepat untuk dibuat 
• Model bisa digunakan sebagai simulasi untuk mempelajari lebih detil tentan sesuatu 
• Model bisa dikembangkan sejalan dengan pemahaman kita tentang sesuatu 
• Kita bisa memberikan penjelasan lebih rinci tentang sesuatu dengan model 
• Model bisa mewakili sesuatu yang nyata maupun yang tidak nyata 

Disisi lain ada alat bantu lain yang sangat sering dipakai oleh sistem analis dan desainer yaitu diagram. Diagram digunakan untuk: 

• Mengkomunikasikan ide 
• Melahirkan ide-ide baru dan peluang-peluang baru 
• Menguji ide dan membuat prediksi 
• Memahami struktur dan relasi-relasinya 

Jadi perbedaan antara model dan diagram adalah segi penggambaran suatu sistem atau lain hal. Diagram menggambarkan atau mendokumendasikan beberapa aspek dari sebuah sistem. Sedangkan sebuah model menggambarkan pandangan yang lengkap tentang suatu sistem pada suatu tahapan tertentu dan dari perspektif tertentu. Sebuah model mungkin mengandung satu atau lebih diagram. Untuk model sederhana, satu diagram mungkin akan mencukupi. Akan tetapi biasanya sebuah model terdiri dari banyak diagram. Ketika kita merancang sebuah sistem untuk seorang pelanggan, maka akan sangat berbeda ketika sistem tersebut kita terapkan untuk banyak pelanggan. Dari sini jelas kita sangat membutuhkan banyak diagram dari berbagai sudut pandang. 

~ Class Diagram 

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 

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 yangmenghubungkan dua kelas.

*Aggregation 

Aggregation memiliki titik pusat yang mencakup keseluruhan bagian. Sebagai contoh : OrderDetail merupakan kumpulan dari Order. 

*Generalization 

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

Untuk tambahan bahwa association mempunyai 2 titik. Salah satu titik bisa memiliki label untuk menjelaskan association tersebut, contoh : OrderDetail adalah line item untuk setiap permintaan. Panah navigability (pengatur alur arah) dalam suatu association menggambarkan arah mana association dapat ditransfer atau disusun. Seperti dalam contoh : OrderDetail dapat disusun dari item-nya, namun tidak bisa sebaliknya. Panah ini juga menjelaskan siapa “memiliki” implementasi dari association; dalam kasus ini OrderDetail memiliki Item. Association tanpa arah panah merupakan bidirectional (bolak-balik). 

Multiplicity dari suatu titik association adalah angka kemungkinan bagian dari hubungan kelas dengan single instance (bagian) pada titik yang lain. Multiplicity berupa single number (angka tunggal) atau range number (angka batasan). Pada contoh, hanya bisa satu ‘Customer’ untuk setiap ‘Order’, tapi satu ‘Customer’ hanya bisa memiliki beberapa ‘Order’. Di bawah mengenai multiplicity yang sering digunakan : 

• 0..1 = Nol atau satu bagian. Notasi n . . m menerangkan n sampai m 
• 0..* or * = Tak hingga pada jangkauan bagian (termasuk kosong)
• 1 = Tepat satu bagian 
• 1..* = Sedikitnya hanya satu bagian 

Contoh Class Diagram: 

                                   

~ Object Diagram

Gambaran obyek-obyek secara ringkas di sebuah sistem pada suatu waktu. Diagram ini bisa digunakan untuk menunjukkan contoh konfigurasi dari obyek-obyek. Secara umum Object Diagram mengandung obyek dan link atau bisa juga mengandung package atau sub sistem. Diagram ini sangat berguna dalam menunjukkan contoh-contoh obyek yang saling berhubungan satu sama lain. Dalam banyak kasus struktur yang tepat bisa digambarkan secara tepat dengan class diagram, akan tetapi struktur tersebut mungkin makin susah untuk dimengerti. Pada situasi seperti ini pembuatan contoh dengan DiagramObject akan sangat membantu sekali. 

Contoh Object Diagram: 

                                            

~ Component Diagram 

Component Diagram mengandung component, interface dan relationship. Diagram ini menggambarkan alokasi semua class dan obyek ke dalam komponen-komponen fisik di sebuah sistem software. Diagram ini memperlihatkan pengaturan dan ketergantungan di antara komponen-komponen software seperti dynamic library link (dll), executable component (exe, binnner, jar, assembly) dan lain-lain. Manfaat nyata dari penggunaan component ini adalah penggunaan kembali (reusable) suatu component pada proyek lain tanpa harus melakukan usaha yang berarti. Dengan demikian akan bisa menghemat waktu dan biaya dalam pengembangannya. Contoh Component Diagram:

                                             

~ Deployment Diagram 

Deployment Diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat. Sistem terdiri dari node-node dimana setiap node diwakili untuk sebuah kubus. Garis yang menghbungkan antara 2 kubus menunjukkan hubungan diantara kedua node tersebut. Tipe node bisa berupa device yang berwujud hardware dan bisa juga processor (yang mengeksekusi component) atau execution environment (software yang menjadi host atau mengandung software lain). Node mengandung artifact, dimana artifact adalah manifestasi dari software; biasanya file. File-file ini biasaya bisa di eksekusi atau executable (seperti: exe, binner, dll, jar, assembly atau script, file-file data, file-file konfigurasi, html, dan lain-lain. Contoh Deployment Diagram: 

                                               

~ Composite Structure Diagram 

Yaitu diagram yang menunjukkan dekomposisi secara hirarki sebah class ke sebuah struktur internal. Hal ini memungkinkan untuk memecah obyek yang kompleks menjadi bagian-bagian kecil. Adapun perbedaan antra Package Diagram dengan Composite Structure Diagram adalah package digunakan untuk pengelompokkan saat kompilasi (compile time), sedangkan composite structure digunakan untuk pengelompokkan saat dijalankan (runtime). Contoh Composite Structure Diagram : 

                                             

~ Package Diagram 

Memperlihatkan bagaimana elemen model diorganisasikan/dikelompokkan ke dalam packages. Contoh Package Diagram :

                                                

~ Use Case Diagram 

Yaitu diagram yang menyajikan interaksi antara use case dan actor pada suatu sistem atau boundary. Use case merupakan keperluan dari aktor (berupa orang, peralatan, atau sistem lain yang berinterkasi dengan sistem yang sedang dibangun). Use case harus merupakan ‘apa’ yang dikerjakan software aplikasi, bukan ‘bagaimana’ software aplikasi mengerjakannya. Setiap use case harus diberi nama yang menyatakan apa yang akan dilakukan dari interaksinya dengan aktor. Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama. 

Di dalam use case terdapat 2 stereotype (model khusus) untuk kondisi tertentu, yaitu <<include>> dan <<extend>>. <<include>> digunakan untuk menggambarkan suatu use case yang merupakan fungsional atau ketergantungan dengan use case lainnya. Sedangkan <<extend>> digunakan untuk menunjukkan bahwa 1 atau beberapa use case merupakan tambahan fungsional dari use case lain jika kondisi atau syarat tertentu dipenuhi. Simbol-simbol yang digunakan dalam tahap pembuatan Use Case Diagram : 

= Aktor = Pengguna sistem atau yang berinteraksi langsung dengan sistem, bisa manusia, aplikasi, ataupun objek lain

= Use Case = Digambarkan dengan lingkaran elips dengan nama use case nya tertulis di tengah lingkaran

= Association = Digambarkan dengan sebuah garis yang berfungsi menghubungkan actor dengan use case

Contoh Use Case Diagram dengan <<include>> : Sistem informasi rental film 

                                

Contoh Use Case Diagram dengan <<extend>> : Sistem informasi rental film

                                      

~ Activity Diagram 

Yaitu diagram yang mendeskripsikan logika prosedural, proses bisnis, aliran kerja, aliran kejadian dalam banyak kasus (use case). Diagram ini mempunyai peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah Activity Diagram bisa mendukung perilaku parallel sedangkan flowchart tidak bisa. Simbol-simbol yang digunakan dalam tahap pembuatan Activity Diagram :

                                            

Contoh Activity Diagram : 

                                              

~ State Machine Diagram 

State Machine Diagram atau State Chart diagram, atau yang biasa juga disebut State Diagram digunakan untuk mendokumentasikan beragam kondisi atau keadaan yang bisa terjadi terhadap sebuah class dan kegiatan apa saja yang dapat merubah kondisi atau keadaan tersebut. Tidak seperti diagram-diagram behaviour lainnya yang memodelkan interaksi diantara beberapa class, State Diagram justru biasanya hanya memodelkan transisi yang terjadi hanya pada sebuah class. Contoh State Machine Diagram : 

                                           

~ Communication Diagram 

Communication Diagram menunjukkan aliran pesan antara objek dalam aplikasi OO dan juga menyiratkan asosiasi dasar (hubungan) antara kelas. Contoh Communication Diagram:

                             

~ Interaction Overview Diagram

Interaksi overview diagram berfokus pada gambaran aliran kendali interaksi dimana node adalah interaksi atau kejadian interaksi. Contoh Interaction Overview Diagram: 

~ Sequence Diagram 

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Contoh Sequence Diagram: 

~ Timing Diagram 

Timing diagram UML digunakan untuk menampilkan perubahan di negara atau nilai dari satu atau lebih elemen dari waktu ke waktu. Hal ini juga dapat menunjukkan interaksi antara peristiwa waktunya dan kendala waktu dan durasi yang mengaturnya. Contoh Timing Diagram: 

Model Proses Waterfall

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman: System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

• Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
• Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
• Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
• Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
• Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Mengapa model ini sangat populer??? Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:

• Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
• Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
• Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

Menurut saya, tahapan-tahapan model ini sudah cukup baik dalam artian minimal untuk melakukan SE, maka harus ada tahapan-tahapan ini. Tahapan-tahapan ini jugalah yang digunakan oleh model-model yang lain pada umumnya. Ada filosofi yang mengatakan sesuatu yang sukses diciptakan pertama kali, maka akan terus dipakai di dalam pengembangannya. Hal ini juga berlaku pada waterfall model ini. Mungkin dapat dikatakan bahwa inilah standar untuk melakukan SE.

Akan tetapi, yang mungkin menjadi banyak pertimbangan mengenai penggunaan dari model ini adalah metode sequential-nya. Mungkin untuk awal-awal software diciptakan, hal ini tidak menjadi masalah, karena dengan berjalan secara berurutan, maka model ini menjadi mudah dilakukan. Sesuatu yang mudah biasanya hasilnya bagus. Oleh karena itu model ini sangat populer. Akan tetapi, seiring perkembangan software, model ini tentu tidak bisa mengikutinya. Yang menjadi kelemahan adalah pada pengrjaan secara berurutan tadi, seperti yang sudah saya utarakan sebelumnya. Kelemahan-kelemahan yang lain juga sudah saya utarakan di atas, atau bahkan masih ada yang lainnya.

Dari sini, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.