3.14. Unified Modelling Language (UML) 1. Sejarah UML
3.14.3. Diagram UML
Berikut ini merupakan standarisasi diagram-diagram yang terdapat dalam UML, yang digunakan untuk memodelkan sistem itu sendiri, yaitu :
1. Class Diagram
Menurut Sri Dharwiyanti dan Romi Satria Wahono (http://ikc.tuxed.org/ umum/yanti-uml.php, 2003), class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class memiliki tiga area pokok, yaitu nama, atribut dan metoda. Atribut dan metoda dapat memiliki salah satu sifat berikut, yaitu :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan.
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.
• Public, dapat dipanggil oleh siapa saja.
Menurut Heru Irman (http://www.gematel.com/Edisi28/Artikel%20Lepas/ lepas3.html), antar class memiliki hubungan-hubungan, yang dapat dilihat pada berikut ini, yaitu :
a. Asosiasi menampilkan keterhubungan struktural antar objek dari kelas yang berbeda, informasi yang harus dipersiapkan untuk jangka waktu tertentu dan keterhubungan dependesi prosedural yang mudah (misalnya, satu objek punya asosiasi yang permanen terhadap objek lainnya).
Sumber : Spring, 2002, http://www.ics.uci.edu/~abhor/ics125/1.
Gambar 3.18. Hubungan Asosiasi
b. Dependensi adalah menggunakan keterhubungan yang menampilkan keterhubungan antara pengguna dengan penyedia dimana perubahan spesifikasi pada sisi penyedia akan mempengaruhi pengguna.
Sumber : Spring, 2002, http://www.ics.uci.edu/~abhor/ics125/1.
Gambar 3.19. Hubungan Dependensi
c. Generalisasi adalah keterhubungan membuat khusus ataupun umum dimana elemen-elemen dari elemen yang lebih khusus (subtipe atau child) dapat mengganti elemen dari elemen yang lebih umum, misalnya (parent).
Sumber : Spring, 2002, http://www.ics.uci.edu/~abhor/ics125/1.
Gambar 3.20. Hubungan Generalisasi
d. Agregasi adalah bentuk asosiasi khusus yang secara kuat memodelkan seluruh bagian dari asosiasi antara hubungan satu bagian kelas secara keseluruhan dengan bagian tertentu dari kelas lainnya, contohnya keterhubungan dari kelas siswa
dengan kelas jadwalnya, semua pada kelas siswa pasti memiliki sebuah kelas jadwal masing-masing, jadi setiap siswa salah satunya harus terdiri dari jadwalnya.
Sumber : Spring, 2002, http://www.ics.uci.edu/~abhor/ics125/1.
Gambar 3.21. Hubungan Agregasi
e. Komposisi adalah bentuk keterhubungan agregasi yang lebih kuat lagi kepemilikannya dan mempunyai jangka waktu yang timbul sesuai kebutuhan. Dari contoh agregasi dimana kelas siswa dapat berdiri sendiri, sedangkan adanya kelas jadwal harus bergantung dan hanya bergantung kepada kemunculan kelas siswanya, dan hanya merupakan bagian dari kelas siswa. Kelas jadwal tidak dapat selalu muncul, tapi sewaktu-waktu dapat dimunculkan melalui kelas siswa.
Sumber : Spring, 2002, http://www.ics.uci.edu/~abhor/ics125/1.
Gambar 3.22. Hubungan Komposisi
f. Multiplicity adalah hubungan satu kelas dengan banyak kelas, seperti hubungan
Sumber : Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003.
Diagram 3.4. Contoh Class Diagram
Menurut Adi Nugroho (2002, p33-34), Class dapat dibedakan atas dua jenis, yaitu kelas abstrak dan kelas konkret. Kelas abstrak adalah kelas yang tidak punya objek hasil instansiasi langsung, tetapi kelas turunannya dapat memiliki objek hasil instansiasi langsung. Sedangkan kelas konkret adalah kelas yang dari padanya dapat diperoleh suatu objek tertentu melalui proses instansiasi. Bagaimanapun juga, peringkat terendah pada suatu diagram hierarki generalisasi-spesialisasi dengan peringkat teratas suatu kelas abstrak haruslah sebuah kelas konkret, meskipun arah sebaliknya tidaklah harus demikian.
Orang (abstrak) Manager Kontributor individual Status Managerial Kelas Konkret Kelas Abstrak Sumber : Nugroho, 2002.
Gambar 3.23. Kelas Abstrak dan Kelas Konkret
2. State Chart Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu
state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang
diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu
class dapat memiliki lebih dari satu statechart diagram). Sebuah state diagram
menunjukkan urutan-urutan state dari sebuah objek selama masa hidupnya (life time-nya), sekaligus dengan event-event yang menyebabkan perubahan dari state tersebut. Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat
dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan
berbentuk lingkaran berwarna penuh dan berwarna setengah. (Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003).
Sumber : UPT Perangkat Lunak Anapersis, 2003-2004.
Diagram 3.5. Contoh State Chart Diagram
3. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem
untuk melakukan pekerjaan-pekerjaan tertentu. Aktor adalah pengguna, pemeran (role), yang bisa berupa sistem eksternal maupun orang.
Actor Use Case
Sumber : Transparansi Pengembangan Sistem Informasi (SF 102), 2001.
Gambar 3.24. Gambar Actor dan Use Case
Notasi-notasi atau hubungan yang terdapat pada use case diagram, dapat dilihat pada tabel berikut ini :
Tabel 3.7. Use Case Relationship
Relationship Purpose Notation
Association Menunjukkan hubungan antara aktor dan use case.
Generalitation Menunjukkan inheritance di antara use
case.
Include Meliputi fungsionalitas dari satu use
case terhadap use case lainnya. <<include>>
Extend Memperluas fungsionalitas dari satu use
case terhadap use case lainnya dalam
kondisi tertentu.
<<Extend>>
Sumber : Certified Internet Webmaster, 2000.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan
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. 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. (Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003).
Sumber : Bruegge,Dutoit, http://www.utdallas.edu/~kcooper/teaching/6354/6354sum mer03/39.
Diagram 3.6. Contoh Use Case Diagram
Menurut Whitten et al. (Transparansi Pengembangan Sistem Informasi (SF
a. Sebagai dasar untuk membantu mengidentifikasi objek-objek dan hubungan tingkat tinggi, serta tanggung jawab masing-masing.
b. Sebagai gambaran dari behavior sistem yang akan dibuat dari sisi pengguna eksternal.
c. Sebagai alat yang efektif untuk memvalidasi kebutuhan. d. Sebagai alat komunikasi yang efektif.
e. Sebagai dasar untuk melakukan perencanaan testing. f. Sebagai dasar untuk melakukan pembuatan user manual.
Menurut Whitten et al. (Transparansi Pengembangan Sistem Informasi (SF
102), 2001), langkah-langkah yang dilakukan untuk membuat use case modelling adalah :
a. Mengidentifikasi aktor-aktor tambahan dan use case-use case. b. Buatlah model use case.
c. Dokumentasikan kejadian-kejadian dalam use case. d. Definisikan Use Case Analysis.
4. Activity Diagram
Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram
merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal
processing). Oleh karena itu activity diagram tidak menggambarkan behaviour
internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.(Dharwiyanti, Wahono,http://ikc.tuxed.org/umum/yanti-uml.php,2003). Activity diagram digunakan untuk menggambarkan secara grafis urutan dari aliran aktivitas dari proses bisnis atau
use case. Mereka dapat juga menggambarkan aksi-aksi yang akan dilakukan ketika
suatu operasi dikerjakan dan juga hasil-hasil dari aksi tersebut. Berikut ini merupakan contoh dari activity diagram, yaitu :
Sumber : Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003.
Diagram 3.7. Contoh Activity Diagram
5. Interaction Diagram
Interaction diagram menggambarkan interaksi yang terdiri dari sekumpulan objek-objek dan hubungan-hubungannya, termasuk pesan-pesan yang dikirim diantara kesua objek tersebut. Interaction diagram terdiri atas sequence diagram dan
Sequence diagram
Sequence diagram adalah sebuah interaction diagram yang menekankan pada urutan waktu penyampaian dari suatu pesan. 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).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi atau metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. (Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003). Berikut ini merupakan contoh dari sequence diagram, yaitu :
Sumber : Palmkvist et al., http://www-edlab.cs.umass.edu/cs520/OMG-Tutorials/51.
Diagram 3.8. Contoh Sequence Diagram
6. Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik
library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi
dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa
interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk
komponen lain. (Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003). Berikut ini adalah contoh dari component diagram, yaitu :
Sumber : UPT Perangkat Lunak Anapersis, 2003-2004.
Diagram 3.9. Contoh Component Diagram
7. Deployment Diagram
Deployment (physical) diagram menggambarkan secara jelas bagaimana
komponen di-deploy dalam infrastruktur sistem, di mana komponen akan diletakkan (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node
adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini. (Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003).
Sumber : UPT Perangkat Lunak Anapersis, 2003-2004.