• Tidak ada hasil yang ditemukan

Unified Modelling Languange (UML)

1. Pengertian Yii Framework

2.2.9. Unified Modelling Languange (UML)

1) Pengertian Unified Modelling Languange (UML)

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik atau gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software

[21]. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi

dan syntax/semantik.

Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch - Object-Oriented Design (OOD), Jim Rumbaugh - Object Modeling Technique (OMT), dan Ivar Jacobson - Object-Oriented Software Engineering (OOSE). Didalam UML terdapat Use Case Diagram, Class Diagram, Sequence Diagram, Collaboration Diagram, dan Deployment Diagram.

a. Use-Case Diagram

Use-case diagram adalah gambaran graphical dari beberapa atau semua actor, use-case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use-case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.

Use-case diagram dapat digunakan selama proses analisis untuk menangkap requirement sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use-case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use-case diagram. Kebutuhan atau requirements system adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use-case yang menggambarkan fungsi sistem yang diharapkan (use-case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use-case (use-case diagram) itu sendiri.

2) Komponen Pembentuk Use-case Diagram a) Actor

Pada dasarnya actor bukanlah bagian dari case diagram, namun untuk dapat terciptanya suatu use-case diagram diperlukan beberapa actor. 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 kita dapat menggunakan relationship.

Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem antara lain:

(1) Yang berkepentingan terhadap sistem dimana adanya arus informasi, baik yang diterimanya maupun yang dia inputkan ke sistem.

(2) Orang ataupun pihak yang akan mengelola sistem tersebut

(3) External resource yang digunakan oleh sistem. (4) Sistem lain yang berinteraksi dengan sistem yang

akan dibuat. b) Use-case

Use-case adalah gambaran fungsionalitas dari suatu sistem, pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun. Use-case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use-case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use-case dalam suatu sistem: (1) Pola perilaku perangkat lunak aplikasi.

(2) Gambaran tugas dari sebuah actor.

(3) Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.

Gambar 2.3 Use Case Dashboard Web BAPSI c) Relasi dalam Use-case

Ada beberapa relasi yang terdapat pada use-case diagram :

(1) Association, menghubungkan link antar elemen. (2) Generalization, disebut juga inheritance

(pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

(3) Dependency, sebuah element bergantung dalam beberapa cara ke elemen lainnya.

(4) Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi atau 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 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.

b. Class

Diagram yang menunjukkan sekumpulan class, interface dan collaboration serta relationships. Diagram ini biasa ditemukan pada pemodelan object oriented system. Class diagram menunjukkan view desain statik dari sebuah sistem. Class diagram yang termasuk active class menunjukkan view proses statik sebuah sistem.

c. Object

Object diagram adalah bentuk lain dari class diagram tetapi menggunakan cara yang berbeda. Perbedaan diantara keduanya adalah pada object diagram memperlihatkan beberapa object yang merupakan instansi dari sebuah class. Sebuah object diagram menggunakan notasi penggambaran yang sama dengan class diagram kecuali dalam penulisan nama dan hubungan antar object. Object diagram dapat digunakan untuk menggambarkan class diagram yang kompleks meskipun penggunaannya tidak sepenting class diagram.

d. Sequence

Diagram interaksi yang menekankan pada waktu pengiriman message. Sequence diagram menunjukkan sekumpulan objek dan pengiriman serta penerimaan message antar objek. Objek yang umumnya memiliki nama atau instansiasi dari class, tapi dapat pula merupakan turunan dari things lain, seperti collaboration, component dan node. Diagram ini digunakan untuk mengilustrasikan dynamic view dari system.

e. Collaboration

Diagram interaksi yang menekankan pada struktur organisasi dari objek yang menerima dan megirim message. Collaboration diagram menunjukkan sekumpulan objek dan hubungan diantaranya serta pengiriman dan penerimaan message. Objek yang umumnya memiliki nama atau instansiasi dari class, tapi dapat pula merupakan turunan dari things lain, seperti collaboration, component dan node. Diagram ini digunakan untuk mengilustrasikan dynamic view dari system.

f. Activity

Activity diagram menggambarkan urutan aktifitas yang digunakan untuk menjelaskan aktifitas dari sebuah operasi. Pada activity diagram terdapat keadaan aksi yang berisi spesifikasi dari aktifitas tertentu. Diagram ini berisi, pilihan keputusan dan kondisi serta spesifikasi message yang dikirim atau diterima sebagai gambaran dari aksi.

Gambar 2.4 Activity Diagram Login Dashboard

g. State

Sebuah state diagram menggambarkan keadaan mesin, transisi, event dan activity. Diagram ini adalah pelengkap khusus untuk mendeskripsikan sebuah class yang menggambarkan state dari objek dari class dan event yang menyebabkan state berubah. Event tersebt dapat berasal dari

objek yang mengirimkan suatu message atau dari kondisi yang terpenuhi.

h. Component

Component diagram menjelaskan struktur fisik kode pada komponen kodede. Sebuah komponen dapat berupa komponen source code, komponen binary atau komponen executable. Komponen berisi informasi tentang logical class. Ketergantungan diantara komponen dapat memudahkan untuk menganalisa bagaimana komponen yang lain terpengaruh dengan perubahan pada sebuah component.

i. Deployment

Deployment diagram menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak pada sebuah system. Kita dapat memperlihatkan computer dan alat yang terhubung (nodes), serta ketergantungan antar component. Dengan model yang baik, kita dapat memakai semua cara dari sebuah node pada arsitektur fisik ke komponen ke class implementasi ke objek yang berinteraksi dan terakhir ke dalam use case.

Dokumen terkait