2. BAB II LANDASAN TEORI
2.9 Unified Modeling Language(UML)
2.9.2 Diagram-Diagram UML
Terdapat sembilan diagram pada UML. Kesembilan diagram ini tidak mutlak harus digunakan dalam pengembangan perangkat lunak, semuanya dibuat sesuai kebutuhan. Pada UML dimungkinkan juga menggunakan diagram lain, seperti DFD (Data Flow Diagram) atau ERD (Entity Relationship Diagram). Kesembilan digram yang terdapat pada UML antara lain (Widodo dan Herlawati, 2011:10) :
1. Diagram Kelas (Class Diagram)
Class diagram adalah static model yang mendukung pandangan statis dari susunan sistem. Class diagram menunjukkan kelas-kelas dan hubungan antara kelas-kelas yang tetap konstan dalam sistem dari waktu ke waktu. Class diagram sangat mirip dengan entity relationship diagram (ERD), bagaimanapun, class diagram menggambarkan kelas-kelas, yang mana termasuk attributes, behavior, dan states, ketika entitas pada ERD hanya berupa atribut. Cakupan dari class diagram, seperti ERD, yaitu sistem yang luas (Dennis, dkk: 2010;510).
Pembangunan blok utama dari class diagram adalah class, yang mana ditempatkan dan diatur dalam sistem informasi. (Lihat gambar 2.4) Selama analisis, class mengacu ke orang, tempat, kejadian, dan hal-hal mengenai sistem yang akan menangkap informasi. Kemudian, selama desain dan implementasi, kelas-kelas dapat mengacu pada artefak implementasi yang spesifik seperti windows, form, dan object lainnya yang digunakan untuk membangun sistem. Setiap class digambarkan dengan menggunakan tiga bagian kotak dengan nama class di atas, atribut di tengah, dan method (juga disebut operasi) di bawah (Dennis, dkk: 2010;512).
Beberapa pendekatan berbeda telah disarankan untuk menolong analis dalam mengidentifikasi sekumpulan kandidat kelas-kelas untuk class diagram. Pendekatan yang paling umum adalah textual analysis, analisis dari isi di dalam use case. Seorang analis mulai meninjau ulang use case dan use case diagram. Isi deskripsi di dalam use case diperiksa untuk mengidentifikasi potensial object, attribute, method, dan association. Kata benda pada use case mengusulkan kemungkinan kelas-kelas, ketika kata kerja mengusulkan kemungkinan operasi atau Gambar 2.4 Contoh Class Diagram untuk Holiday Travel Vehicles
asosiasi. Gambar 2.5 menampilkan suatu ringkasan dari pedoman yang telah kita temukan berguna (Dennis, dkk: 2010;517).
Gambar 2.5 Textual Analysis Guidelines
Tujuan utama dari diagram adalah untuk menunjukkan association atau relationship yang dimiliki oleh satu class dengan dengan class lainnya. Ini digambarkan pada diagram dengan menggambarkan garis di antara kelas-kelas (Lihat gambar 2.6.). Association ini sangat mirip dengan relationship yang ditemukan pada ERD. Association dipelihara oleh references yang mana mirip seperti pointer dan dipelihara secara internal oleh sistem (tidak seperti model relasional di mana relationship dipelihara oleh foreign key dan primary key) (Dennis, dkk: 2010;514).
2. Diagram Use Case
Diagram ini memperlihatkan himpunan use case dan aktor-aktor yang berfungsi untuk mengorganisasi dan memodelkan perilaku suatu sistem yang dibutuhkan serta diharapkan pengguna.
Potongan gambar orang yang diberi label pada diagram menunjukkan actor (Lihat gambar 2.7). Seorang actor sama dengan sebuah entitas eksternal yang ditemukan pada DFD—ini merupakan orang atau sistem lain yang berinteraksi dengannya dan mendapat
nilai dari sistem. Seorang actor bukanlah pengguna spesifik, tetapi suatu peran yang dapat dimainkan oleh pengguna ketika berinteraksi dengan sistem. Actor adalah eksternal sistem dan menginisiasi sebuah use case (Dennis, dkk:2010;506).
Use case dihubungkan kepada actor melalui association relationship. Ini menunjukkan dengan mana use case dan actor berinteraksi. (Lihat gambar 2.8) Sebuah garis digambarkan dari seorang actor ke sebuah use case yang menggambarkan sebuah association. Association secara umum menggambarkan dua cara berkomunikasi antara use case dan actor (Dennis, dkk:2010;506).
Sebuah use case, digambarkan oleh sebuah oval, yaitu proses utama yang akan dilakukan oleh sistem yang memberikan keuntungan
seorang actor dalam beberapa cara (Lihat gambar 2.8), dan ini dilabelkan oleh sebuah pendeskripsian frase kata kerja (banyak seperti proses DFD). Ada waktu ketika satu use case salah satunya akan menggunakan fungsionalitas atau meng-extends fungsionalitas dari use case lain pada diagram, dan ini ditunjukkan oleh includes atau extends relationship. (Dennis, dkk:2010;507).
Use case dilampirkan di dalam sebuah system boundary, yang mana sebuah kotak yang menggambarkan sistem dan secara jelas melukiskan bagian apa-apa saja dari diagram, baik itu eksternal maupun internal. (Lihat gambar 2.8) Nama dari sistem dapat terlihat di dalam ataupun di atas dari kotak (Dennis, dkk: 2010;507).
Gambar 2.8 Contoh Use Case Diagram untuk Vehicle Sales System
3. Diagram Interaksi dan Urutan (Sequence Diagram)
Sequence diagram mengilustrasikan objek yang berpartisipasi dalam sebuah use case dan message yang melewatinya dari waktu ke waktu untuk satu use case. Sequence diagram adalah dynamic model yang mendukung tampilan dinamis dari sistem yang berkembang. Ini jelas menunjukkan urutan dari message yang lewat di antara objek-objek dalam mendefinisikan suatu interaksi. Sejak sequence diagram menekankan time-based ordering pada aktivitas yang terjadi di antara sekumpulan object, sequence diagram sangat membantu untuk mengerti spesifikasi secara real time dan use case yang rumit (Dennis, dkk: 2010;519).
Sequence diagram dapat menjadi sebuah generic sequence diagram yang menunjukkan semua kemungkinan scenario. Scenario adalah suatu jalur tunggal yang dapat dieksekusi yang melalui sebuah use case. Tetapi biasanya setiap analis mengembangkan sekumpulan instance sequence diagram, yang mana menggambarkan satu scenario tunggal dalam use case. Jika analis tertarik dalam mengerti aliran kontrol suatu scenario oleh waktu, analis harus menggunakan sequence diagram untuk menggambarkan informasi ini. Diagram digunakan selama fase analisis dan desain, bagaimanapun, desain diagram diimplementasikan dengan sangat spesifik, sering termasuk database objek atau komponen spesifik GUI (General User Interface) sebagai kelas-kelas. Bagian berikut pertama menyajikan syntax dari
sebuah sequence diagram dan kemudian mendemonstrasikan bagaimana sequence diagram harus digambarkan (Dennis, dkk: 2010;519).
Actor dan object yang berpartisipasi pada sequence diagram ditempatkan di seberang atas dari diagram, digambarkan dengan simbol actor dari use case diagram atau persegi panjang tidak berlabel (Dennis, dkk: 2010;520).
Gambar 2.10 Sequence Diagram
Garis putus-putus berjalan secara vertikal di bawah tiap actor dan object untuk menunjukkan lifeline (garis hidup) dari actor/object dari waktu ke waktu. (Lihat gambar 2.10) Kadang-kadang sebuah object membuat sebuah temporary object, dan pada kasus ini sebuah X ditempatkan pada akhir dari lifeline pada titik di mana object dihancurkan atau tidak digambarkan (Dennis, dkk: 2010;521).
Sebuah kotak tipis persegi panjang, disebut execution occurrence (eksekusi kejadian), yang dilapisi ke lifeline untuk menunjukkan ketika kelas-kelas mengirim dan menerima message. (Dennis, dkk: 2010;521).
Sebuah message adalah komunikasi antara objek-objek yang menyampaikan informasi, dengan harapan bahwa aktivitas yang akan terjadi, dan message yang lewat di antara objek ditunjukkan oleh garis padat yang menghubungkan dua objek, disebut link. Panah pada link
menunjukkan ke arah mana message berlalu, dan nilai argumen untuk message ditempatkan ke dalam tanda kurung sesudah nama message. Urutan message berjalan dari atas ke bawah pada satu halaman, maka message ditempatkan lebih tinggi pada diagram yang menunjukkan message terjadi di awal urutan, berlawanan dari message yang lebih rendah yang terjadi kemudian. Ada waktu ketika message yang dikirim hanya jika suatu kondisi bertemu. Pada kasus tersebut, kondisi ditempatkan di antara kumpulan dari [], kondisi ditempatkan di depan nama message (Dennis, dkk: 2010;521).
4. Diagram Aktitas (Activity Diagram)
Beberapa dari kelas-kelas dalam class diagram cukup dinamis pada yang mana kelas-kelasitu melalui berbagai macam keadaan selama keberadaan kelas-kelas tersebut. Suatu activity diagram adalah dynamic model yang menunjukkan perbedaan keadaan-keadaan yang mana suatu class tunggal lewat melalui selama hidupnya dalam merespon kejadian, bersamaan dengan respon dan aksinya. Secara khusus, activity diagram tidak digunakan untuk seluruh kelas-kelas, tetapi hanya untuk mendefinisikan kelas-kelas kompleks yang lebih lanjut membantu menyederhanakan desain dari algoritma untuk method classes tersebut. activity diagram menunjukkan perbedaan state (keadaan) dari class dan event apa yang menyebabkan sebuah class untuk berubah dari satu state ke state yang lain. Dibandingkan sequence diagram, activity diagram harusnya digunakan jika
pengembang tertarik dalam memahami aspek dinamis dari sebuah class tunggal dan bagaimana instances-nya berkembang seiring waktu, dan tidak dengan bagaimana sebuah use case scenario tertentu dieksekusi lebih dari satu set kelas-kelas (Dennis, dkk:2010;524).
Sebuah state adalah sekumpulan nilai-nilai yang mendeskripsikan sebuah objek pada sebuah titik spesifik dalam waktu dan itu merepresentasikan sebuah titik di dalam sebuah kehidupan objek pada yang mana itu memenuhi beberapa kondisi, menampilkan beberapa aksi, atau menunggu sesuatu terjadi. Sebuah state digambarkan oleh sebuah state symbol, yang mana sebuah kotak dengan sudut berbentuk bulat dengan sebuah label deskriptif yang mengomunikasikan suatu keadaan tertentu. Ada dua pengecualian. Sebuah initial state yang
digambarkan oleh sebuah lingkaran kecil, padat, berisi dan sebuah objek milik final state digambarkan sebagai sebuah lingkaran mengelilingi lingkaran yang kecil, padat, berisi. Pengecualian-pengecualian ini digambarkan ketika sebuah objek dimulai dan diakhiri (Dennis, dkk:2010;524).
Attributes atau properties dari sebuah objek mengakibatkan keadaan yang berada di dalam, bagaimanapun, tidak semua attribute atau perubahan attribute akan membuat suatu perbedaan (Dennis, dkk:2010;526).
Sebuah event adalah sesuatu yang mengambil tempat pada titik tertentu dalam waktu dan merubah suatu nilai yang mendeskripsikan sebuah objek, yang mana membalikkan perubahan keadaan objek. Hal ini bisa menjadi kondisi yang ditunjuk menjadi benar, tanda terima dari pemanggilan sebuah method oleh sebuah objek, atau bagian dari berlalunya waktu yang telah ditetapkan. State dari objek menentukan secara pasti apa respon yang akan terjadi (Dennis, dkk:2010;526).
Anak panah digunakan untuk menghubungkan state symbol, merepresentasikan sebuah transisi di antara states. Sebuah transisi adalah hubungan yang mereprersentasikan pergerakan sebuah objek dari satu state ke state lainnya. Beberapa transisi akan memiliki suatu ‘guard condition’. Suatu ‘guard condition’ adalah sebuah ekspresi Boolean yang termasuk nilai-nilai attribute, yang mana memperbolehkan suatu transisi hanya jika kondisinya benar. Setiap anak panah dilabelkan dengan nama eventyang sesuai dan dengan bebrapa parameter atau kondisi yang mungkin berlaku (Dennis, dkk:2010;526).
5. Diagram Komunikasi (Communication Diagram)
Diagram sebagai pengganti diagram kolabrasi UML yang menekankan organisasi struktural dari objek-objek yang menerima serta mengirim pesan.
6. Diagram Status (Statechart Diagram)
Diagram status memperlihatkan keadaan-keadaan pada sistem, memuat status (state), transisi, kejadian serta aktifitas.
7. Diagram Komponen (Component Diagram)
Diagram komponen memperlihatkan organisasi serta kebergantungan sistem pada komponen-komponen yang telah ada sebelumnya.
8. Diagram Deployment
Diagram ini memperlihatkan konfigurasi saat aplikasi dijalankan. Diagram deployment berhubungan erat dengan diagram komponen dimana diagram ini memuat satu atau lebih komponen-komponen. Diagram ini berguna saat aplikasi yang dikembangkan, dijalankan pada banyak mesin.
9. Diagram Paket (Package Diagram)
Diagram ini memerlihatkan kumpulan kelas-kelas yang merupakan bagian dari diagram komponen.