Model-Model Diagram UML
UML terdiri atas banyak elemen-elemen grafis yang digabungkan membentuk
diagram. Tujuan representasi elemen-elemen grafis ke dalam diagram adalah untuk
menyajikan beragam sudut pandang dari sebuah sistem berdasarkan fungsi
masing-masing diagram tersebut. Kumpulan dari beragam sudut pandang inilah yang
disebut sebuah model. Diagram diklasifikasikan berdasarkan tiga jenis diagram
sebagai berikut.
1.
Diagram Use Case
Diagram use case adalah deskripsi fungsi dari sebuah sistem
dariperspektif/sudut pandang para pengguna sistem. Use case mendefinisikan
“apa”yang dilakukan oleh sistem dan elemen elemennya, bukan “bagaimana” sistemdan
elemen-elemennya saling berinteraksi. Use case bekerja denganmenggunakan
“scenario”, yaitu deskripsi urutan-urutan langkah yang menerangkan apa
yang dilakukan pengguna terhadap sistem maupun sebaliknya. Diagram use case mengidentifikasikan
fungsionalitas yang dipunyai oleh sistem(use case), user yang
berinteraksi dengan sistem (actor) dan asosiasi/keterhubungan antara
user dengan fungsionalitas sistem. Komponen notasi dasar yang dipunyai oleh
diagram use case adalah actor, use-case, dan association.
Berikut adalah notasi yang terdapat pada diagram use case. Diagram use
case memiliki sebuah model khusus yang terbatas untuk kondisi tertentu yang
disebut stereotype. Untuk menunjukkan stereotype digunakan symbol
“<<” diawalnya dan ditutup dengan “>>”
diakhirnya. Terdapat dua stereotype paling sering digunakan dalam use
case diagram yaitu <<extend>> dan <<include>> <<extend>>
digunakan untuk menunjukkan bahwa satu use case merupakantambahan
fungsional dari use case yang lain jika kondisi atau syarat tertentu dipenuhi.
Sedangkan <<include>> digunakan untuk menggambarkan bahwa suatu use
case seluruhnya merupakan fungsionalitas dari use case lainnya.
2.
Diagram Activity
Diagram activity digunakan untuk mendokumentasikan alur
kerja pada sebuah sistem, yang dimulai dari pandangan business level hingga
ke operational level. Pada dasarnya, diagram activity merupakan
variasi dari diagram state machine. Diagram activity mempunyai
peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart
adalah diagram activity bisa mendukung perilaku parallel sedangkan
flowchart tidak bisa.
Contoh : Activity Diagram
3.
Diagram Sequence
Diagram Sequence mendokumentasikan komunikasi/interaksi
antar kelaskelas. Diagram ini menunjukkan sejumlah objek dan message (pesan)
– yang diletakkan diantara objek-objek didalam use case. Perlu diingat
bahwa di dalam diagram ini, kelas-kelas dan aktor-aktor diletakkan dibagian
atas diagram dengan urutan dari kiri ke kanan dengan garis lifeline yang
diletakkan secara vertical terhadap kelas dan aktor.
Contoh : Sequence Diagram
Diagram Class adalah sebuah spesifikasi yang jika
diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari
pengembangan dan desain berorientasi objek. Class diagram
mendeskripsikan jenis-jenis objek dalam sistem dan berbagai macam hubungan
statis yang terdapat pada mereka. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk
memanipulasi keadaan tersebut (metoda/fungsi).
Contoh : Class Diagram
5.
Diagram Component
Komponen perangkat lunak adalah bagian fisik dari sebuah sistem
yang menetap di komputer. komponen merupakan implementasi software dari sebuah class.
Komponen bisa berupa tabel, file data, file exe, file DLL,
dokumen, dll. Diagram component mengandung komponen, interface dan
relationship. Komponen diagram ini digunakan pada saat pengembang ingin
memecah sistem menjadi komponen-komponen dan ingin menampilkan
hubungan-hubungan mereka dengan antarmuka atau pemecahan komponen menjadi
struktur yang lebih rendah. Secara umum dapat disimpulkan bahwa component diagram
yang digunakan untuk menjelaskan kebergantungan antar beragam komponenkomponen software
seperti misalnya kebergantungan antara file-file executable dengan file-file
sumbernya (source file) dll.
Contoh : Component Diagram
6.
Diagram Deployment
Diagram deployment menunjukkan tata letak sebuah sistem
secara fisik, menampakkan bagian-bagian software yang berjalan pada
bagian-bagian hardware yang digunakan untuk mengimplementasikan sebuah
sistem dan keterhubungan antara komponen-komponen hardware tersebut.
Diagram deployment dapat digunakan pada bagian-bagian awal proses
perancangan sistem untuk mendokumentasikan arsitektur fisik sebuah sistem.
Contoh : Deployment Diagram
7.
Diagram State(State Machine Diagram)
State Machine Diagram
menelusuri individu-individu objek melalui keseluruhan daur hidupnya,
menspesifikasi semua urutan yang mungkin dari pesan-pesan yang akan diterima
objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut. Diagram
State menggambarkan transisi dan perubahan keadaan suatu objek dalam
sistem sebagai akibat dari stimuli yang diterima. Pada umumnya diagram ini
menggambarkan class tertentu. State diagram membantu analis,
perancang dan pengembang untuk memahami perilaku objek dalam sistem.
Contoh : Diagram State(State Machine Diagram)
8.
Diagram Composite (Composite
Structure Diagram)
Composite Structure Diagram
adalah diagram untuk menunjukkan dekomposisi secara hierarkis sebuah class ke
sebuah struktur internal. Hal ini memungkinkan untuk memecah objek yang
kompleks menjadi bagian-bagian yang kecil.
Contoh : Composite Structure Diagram
9.
Diagram Object
Object diagram merupakan sebuah gambaran
tentang objek-objek dalam sebuah sistem pada satu titik waktu. Karena lebih
menonjolkan perintah-perintah daripada class, object diagram
lebih sering disebut sebagai sebuah diagram perintah.
Contoh : Object Diagram
10. Diagram
Package
Package diagram adalah sebuah bentuk
pengelompokan yang memungkinkan untuk mengambil setiap bentuk di UML dan
mengelompokkan elemen-elemen dalam tingkatan unit yang lebih tinggi. Kegunaan
package yang paling umum adalah untuk mengelompokkan class.
Contoh : Package Diagram
11. Diagram
Communication
Collaboration diagram juga menggambarkan interaksi
antar objek seperti sequence diagram, tetapi lebih menekankan pada peran
masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence
number, di mana message dari level tertinggi memiliki nomor 1. Messages
dari level yang sama memiliki prefiks yang sama..
Contoh : Communication Diagram
12. Diagram
Interaction Overview
Interaction Overview Diagram
adalah pencangkokan secara bersama antara activity diagram dengan sequence
diagram. Interaction Overview Diagram dapat dianggap sebagai activity
diagram dimana semua aktivitas diganti dengan sedikit sequence diagram,
atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan
notasi activity diagram yang digunakan untuk menunjukkan aliran
pengawasan.
Contoh : Interacion Overview Diagram
13. Diagram
Timing
Timing Diagram adalah bentuk lain dari interaction
diagram, dimana focus utamanya lebih ke waktu. Timing diagram sangat
berdaya guna dalam menunjukkan faktor pembatas waktu diantara perubahan state pada objek yang berbeda.
Contoh : Timing Diagram
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 :
·
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.
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.
