diagram uml

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

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.