• Tidak ada hasil yang ditemukan

Unified Modelling Language (UML)

Dalam dokumen Pengembangan Sistem Tutorial Adaptif Ber (Halaman 45-51)

AGILE SOF TWARE DEVELOPMENT

2.2.3.2 Unified Modelling Language (UML)

UML adalah bahasa untuk menspesifikasi, memvisualisasi, membangun dan mendokumentasikan artifacts (bagian dari informasi yang digunakan atau dihasilkan oleh proses pembuatan perangkat lunak, artifact tersebut dapat berupa model, deskripsi atau perangkat lunak) dari sistem perangkat lunak, seperti pada pemodelan bisnis dan sistem non perangkat lunak lainnya. Selain itu UML adalah bahasa pemodelan yang menggunakan konsep orientasi obyek. UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivar Jacobson di bawah bendera Rational Software Corp. UML menyediakan notasi-notasi yang membantu memodelkan

sistem dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan (Riyadi, 2004).

Menurut Riyadi (2004) Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

1. View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram. Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view, dan deployment view. Use case view mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya. View ini digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. View ini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester) (Riyadi, 2004).

Logical view mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object, dan relationship) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu. View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer) (Riyadi, 2004).

Component view mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administratif lainnya. View ini digambarkan dalam component view dan digunakan untuk pengembang (developer) (Riyadi, 2004)

Concurrency view membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity

diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester) (Riyadi, 2004)

Deployment view mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya. View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester) (Riyadi, 2004). 2. Diagram

Menurut Riyadi (2004) diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain:

Use Case Diagram

Menggambarkan sejumlah external actors dan hubungannya ke use case yang diberikan oleh sistem. Use case adalah deskripsi fungsi yang disediakan oleh sistem dalam bentuk teks sebagai dokumentasi dari use case symbol namun dapat juga dilakukan dalam activity diagrams. Use case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan sistem yang dilihat user) dan bukan bagaimana fungsi yang ada di dalam sistem. Komponen-komponen yang terlibat dalam use case diagram:

a. Actor

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor dimana actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima dan memberi informasi pada sistem, actor hanya berinteraksi dengan use case tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man. Actor dapat digambarkan

secara secara umum atau spesifik, dimana untuk membedakannya dapat digunakan relationship.

b. Use Case

Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.

c. Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram:

- Association, menghubungkan link antar element.

- Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

- Dependency, sebuah element bergantung dalam beberapa cara ke

element lainnya.

- Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi/stereotype yang mungkin terjadi pada use case diagram:

1. <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association. Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

State Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua

class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda.

Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use case atau interaksi.

Entity Relationship Diagram

Kusnawi (2013) menunjukan Entity Relationship Diagram (ERD), “mendokumentasikan data perusahaan dengan mengidentifikasikan jenis dan hubungannya”. Komponen-komponen ERD terlihat pada Tabel 2.3.

Tabel 2.3 Komponen ERD

Cardinality Ration.

Cardinality Ration adalah batasan yang menjelaskan jumlah

keterhubungan satu entitas dengan entitas lainnya. Jenis Cardinality Ration antara lain:

- One to one relationship ____________ 1:1.

Hubungan antara file pertama dengan file kedua adalah satu berbanding satu, hubungan tersebut dapat digambarkan dengan tanda lingkaran untuk

menunjukkan tabel atau relasi antara keduanya yang diwakilkan dengan tanda panah tunggal seperti terlihat pada Gambar 2.13.

Gambar 2.13 Simbol one to one relationship - One to many relationship ____________ 1:M/M:1.

Hubungan antara file pertama dengan file kedua adalah berbanding banyak atau dapat pula dibalik banyak lawan satu. Hubungan tersebut dapat digambarkan dengan tanda lingkaran untuk menunjukkan tabel dan relasi antara keduanya diwakilkan dengan tanda panah ganda untuk menunjukkan hubungan banyak tersebut seperti terlihat pada Gambar 2.14.

Gambar 2.14 Simbol one to many relationship

- Many to many relationship ___________ M:N/N:M.

Hubungan antara file pertama dengan file kedua adalah banyak berbanding banyak. Hubungan tersebut digambarkan dengan tanda lingkaran untuk menunjukkan tabel dan relasi antara keduanya diwakilkan dengan tanda panah ganda untuk menunjukkan hubungan banyak seperti terlihat pada Gambar 2.15.

Dalam dokumen Pengembangan Sistem Tutorial Adaptif Ber (Halaman 45-51)

Dokumen terkait