Diagram UML

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 dari perspektif/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 merupakan tambahan 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.
 Contoh : Use Case Diagram
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

4.       Diagram Class
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 :

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.
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.