UML (Unified Modelling Language) DEFINISI UML UML adalah bahasa standar untuk pengembangan sebuah sistem yang dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi tidak dapat menyampaikan kapan dan apa model yang seharusnya dibuat . UML bukan saja merupakan bahasa visual saja, namun juga dapat secara langsung dihubungkan ke berbagai bahasa pemrograman, seperti JAVA, C++, Visual Basic atau bahkan dihubungkan secara langsung kedalam OODB. Pendokumentasiannya : requirement, arsitektur, design, source code, project plan, test dan prototype.

Sejarah UML Pendekatan analisa dan rancangan dengan model OO diperkenalkan sejak 1970-akhir 1980. Jumlah yang menggunakan metode OO mulai diuji coba dan diaplikasikan antara 1989 hingga 1994. OOSE (Object Oriented Software Engineering) oleh Grady Booch dari Rational Software Co, dan James Rumbaugh dari General Electric yang dikenal dengan OMT (Object Modelling Language) Standarasisasi -> UML (Oktober 1994) UML di standarisasi oleh OMG (Object Management Group)

Copyright © 1997 by Rational Software Corporation Sejarah Singkat UML Nov ‘97 UML approved by the OMG Walk the audience through the timeline. Point out that the UML is the natural successor to the notations. 1. Late ‘80s and early ‘90 - there are many (50+) OO methodologies 2. Among the first generation methodologies, Booch and OMT stood out 3. Around 1993, second generation methodologies came out - Booch ‘93 and OMT-II. Methodologist borrowed good concepts from each others so many concepts were the same across the methodologies, but different notations. 4. Oct. 1994 - Dr. James Rumbaugh joined Rational to unify Booch & OMT. 5. At OOPSLA ‘95, Grady and Jim announced Unified Method 0.8. 6. Use Case technique developed by Dr. Ivar Jacobson was adapted by all methodologies by then. 7. Rational acquires Objectory in fall of ‘95 - Dr. Ivar Jaconson joins Rational. 8. Jun of ‘96 - Rational submits UML 0.9 to OMG. 9. UML gains industry support from HP, Microsoft, Oracle + 16 others 10. UML is the defacto standard for OO and component technologies 11. The final submission goes in Sep. ‘97 - expect the announcement in Dec. Copyright © 1997 by Rational Software Corporation 10

Bangunan Dasar UML Sesuatu (Things) Relasi (Relationship) Diagram Ada 4 Macam Things dalam UML : Structural Things Behavioral Things Grouping Things Annotational Things

A. Structural Things Merupakan Bagian yang bersifat statis dalam model UML Dapat berupa elemen-elemen yang bersifat fisik maupun konseptual Ada 7 macam structural things, yaitu Kelas, Antarmuka, Kolaborasi, Use Case, Kelas Aktif, Komponen dan Simpul

1. Kelas - Himpunan dari objek-objek yang berbagi atribut serta operasi yang sama - Digambarkan dengan empat-persegi-panjang yang memuat nama, atribut, serta operasi yang dimilikinya 2. Antarmuka (Interfaces) - Kumpulan dari operasi-operasi yang menspesifikasi layanan (service) suatu kelas atau komponen/objek - Mendeskripsikan perilaku yang tampak dari luar dari suatu elemen - Jarang berdiri sendiri. - Biasanya dilampirkan pada kelas atau komponen yang merealisasikan antarmuka - secara grafis digambarkan dengan lingkaran kecil dengan namanya didahului dengan garis tegak (|) 3. Kolaborasi (Collaboration) - Mendefinisikan interaksi aturan-aturan dan elemen lain yang bekerjasama untuk menyediakan perilaku yang lebih besar dari jumlah dari elemen-elemennya (sinergi) - Merepresentasikan pola implementasi yang memperbaiki sistem - secara grafis digambarkan dengan elipsi bergaris putus-putus yang memuat nama kolaborasi itu.

4. Use Case - Deskripsi dari urutan aksi-aksi yang ditampilkan sistem yang menghasilkan suatu hasil yang terukur bagi suatu actor - Digunakan untuk menstrukturkan perilaku pada suatu model - Digambarkan dengan elips tegas yang berisi namanya 5.Kelas Aktif (Active Class) - Kelas dimana Objek-objek yang dimilikinya memiliki satu atau lebih proses dan lebih jauh menginisialisasi suatu objek kendali. - Merupakan kelas biasa namun objek-objek yang dimilikinya menampilkan elemen-elemen yang memiliki perilaku konkuren. - secara grafis digambarkan seperti kelas biasa tetapi dengan batas yang lebih tebal, yang memuat nama, atribut, serta operasi yang dimilikinya. 6. Komponen (Component) -Bagian fisik dan bagian yang dapat digantikan pada suatu sistem. - Secara grafis digambarkan dengan empat-persegi-panjang seperti kelas tetapi ditambahi tab. 7.Simpul (Node) - Elemen fisik yang eksis saat aplikasi dijalankan dan mencerminkan suatu sumber daya komputasi. - Kumpulan komponen mungkin hadir dalam simpul dan mungkin juga berpindah-pindah dari suatu simpul ke simpul yang lain. - secara grafis digambarkan sebagai kubus yang berisi namanya.

B. Behavioral Things Merupakan bagian yang dinamis pada model UML Mencerminkan perilaku sepanjang ruang dan waktu. Ada 2 macam behavioral things : 1. Interaksi 2. State Interaksi Suatu perilaku yang mencakup himpunan pesan-pesan yang diperlukan untuk menyelesaikan suatu fungsi tertentu Terdiri dari pesan-pesan, urutan aksi (perilaku yang dihasilkan oleh sebuah pesan), link (hubungan antar objek-objek) Secara grafis, pesan digambarkan dengan tanda panah tegas yang sering memuat nama operasinya

Behavioral Things State - Perilaku yang menspesifikasi unsur kedudukan suatu objek atau interaksi-interaksi sepanjang waktu dalam menanggapi event-event yang terjadi. Penggambaran suatu state memuat beberapa unsur yaitu state itu sendiri, transisi (perubahan dari suatu state ke state lainnya), event (suatu keadaan yang memicu sebuah transisi, serta aktivitas (tanggapan terhadap transisi) Digambarkan sebagai empat-persegi-panjang yang sudut-sudutnya melengkung, yang memuat namanya (serta substate didalamnya, jika ada)

Bagian yang memperjelas model UML C. Grouping Things Bagian pengorganisasi dalam UML Dalam penggambaran model UML yang rumit kadang diperlukan penggambaran paket yang menyederhanakan model Paket berguna bagi pengelompokkan sesuatu, misalnya model-model serta subsistem-subsistem. D. Annotational Things Bagian yang memperjelas model UML Dapat berupa komentar yang memperjelas fungsi serta ciri-ciri tiap elemen dalam model UML

RELATIONSHIP Hubungan-hubungan yang terjadi antarelemen dalam UML Ada 4 macam relationship dalam UML, yaitu Dependency, Asosiasi, Generalisasi, Realisasi

Dependency (Kebergantungan) Hubungan dimana perubahan yang terjadi pada suatu elemen independen (mandiri) akan mempengaruhi elemen yang bergantung padanya (elemen yang tidak mandiri – independen). Secara grafis digambarkan dengan tanda panah putus-putus.

Asosiasi Menghubungkan antara objek satu dengan objek yang lainnya; bagaimana hubungan suatu objek dengan objek lainnya. Suatu bentuk asosiasi adalah agregasi yang menampilkan hubungan suatu objek dengan bagian-bagiannya. Secara grafis digambarkan dengan garis tegas tanpa tanda panah.

Generalisasi Hubungan dimana objek anak (descendent) berbagi perilaku dan struktur data dari objek yang ada diatasnya (objek induk – ancestor). Arah dari atas ke bawah (dari objek induk ke objek anak disebut spesialisasi) Arah dari bawah ke atas disebut generalisasi Secara grafis digambarkan sebagai garis yang ujungnya berkepala panah (atau bentuk segitiga) yang kosong, yang mengarah ke objek induk.

Realisasi Operasi yang benar-benar dilakukan oleh suatu objek Secara grafis digambarkan dengan tanda panah bergaris putus-putus dengan kepala panah kosong.

Konsep Dasar UML Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Diagram Ada 9 jenis diagram, yaitu : Use Case Diagram Diagram Kelas Diagram Objek Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram

USE CASE DIAGRAM Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Menggambarkan kebutuhan system dari sudut pandang user Mengfokuskan pada proses komputerisasi (automated processes) Menggambarkan hubungan antara use case dan actor Use case menggambarkan proses system (kebutuhan system dari sudut pandang user) Secara umum use case adalah: Pola perilaku system Urutan transaksi yang berhubungan yang dilakukan oleh satu actor Use case diagram terdiri dari Use case Actors Relationship System boundary boxes (optional) Packages (optional)

USE CASE Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Use case dinotasikan dengan gambar (horizontal ellipse) Use case biasanya menggunakan kata kerja Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama

ACTOR Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Kata benda Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) Letakkan actor utama anda pada pojok kiri atas dari diagram

Association Associations bukan menggambarkan aliran data/informasi Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case Ada 4 jenis relasi yang bisa timbul pada use case diagram Association antara actor dan use case Association antara use case Generalization/Inheritance antara use case Generalization/Inheritance antara actors

Association antara actor dan use case Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda

Association antara use case <<include>> termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal Register for courses <<include>> Logon validation Maintain curriculum

Association antara use case (Lanjut) <<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami. Tanda panah terbuka harus terarah ke parent/base use case Gambarkan association extend secara vertical

Generalization/inheritance antara use case Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)

Generalization/inheritance antara actor Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case

Use case System boundary boxes Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system). Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan System boundary boxes dalam penggunaannya optional

Contoh Use Case

Contoh Use Case

ACTIVITY DIAGRAM Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram

Simbol Activity Diagram

Penarikan Uang dari Account Bank Melalui ATM CONTOH ACTIVITY DIAGRAM Penarikan Uang dari Account Bank Melalui ATM

CONTOH ACTIVITY DIAGRAM

CLASS DIAGRAM 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 diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok : 1. Nama (dan stereotype) 2. Atribut 3. Metoda

CLASS DIAGRAM (LANJUTAN) Atribut dan metoda dapat memiliki salah satu sifat berikut : 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 Nama Class Atribut Metode/operasi

HUBUNGAN ANTAR CLASS 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

CONTOH CLASS DIAGRAM

MULTIPLICITY Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges Specification of multiplicity flushes out business rules and assumptions. The lower bound is critical, as the lower bound is what determines whether or not the relationship is optional (e.g., a lower bound of 0 indicates that the relationship is optional). Multiplicity is needed on both ends of a relationship, even if you can only navigate in one direction. Even though there is no need to navigate in that direction, the multiplicity still provides valuable business information. Sometimes navigation decisions are made for performance reasons, which may change over time. The multiplicity should reflect the requirements. Navigation is discussed on later slides. The use of ‘N’ instead of ‘*’ is Booch, not UML (e.g., the use of “0..N” and ‘N’ is not UML). 1 0..* * 1..* 0..1 2..4 For each role you can specify the multiplicity of its class, how many objects of the class can be associated with one object of the other class. Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper value). A single integer is a valid range. During analysis, assume a multiplicity of 0..* (zero to many) unless there is some clear evidence of something else. A multiplicity of zero implies that the association is optional; make sure you mean this; if an object might not be there, operations which use the association will have to adjust accordingly. Narrower limits for multiplicity may be specified (such as 2..4). Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is 0..*, is expected to be between 10 and 20 in 85% of the cases, make note of it; this information will be of great importance during design. For example, if persistent storage is to be implemented using a relational database, narrower limits will help better organize the database tables. 2, 4..6

State Diagram Menggambarkan semua state yang dimiliki oleh suatu object dari suatu class dan kejadian yang menyebabkan state berubah. Meliputi seluruh pesan dari object yang dapat mengirim dan menerima. Skenario mempresentasikan satu jalur yang melewati sebuah state transition diagram. Jarak waktu antara dua pesan yang dikirim oleh suatu object mempresentasikan sebuah state.

State diagram presentasi

Sequence Diagram Menggambarkan interaksi antara sejumlah object dalam urutan waktu. Berguna untuk menunjukan rangkaian pesan yang dikirim antar object dan interaksi antar object. Digambarkan dengan segi empat yang berisi nama dari obyek yang digarisbawahi.

Sequence Diagram Bersifat dinamis Diagram yang menekankan pada pengiriman pesan dalam suatu waktu tertentu

Diagram Kolaborasi Bersifat dinamis Diagram interaksi yang menekankan organisasi struktural dari objek-objek yang menerima serta mengirim pesan

Diagram Komponen Bersifat statis Memperlihatkan organisasi serta kebergantungan pada komponen-komponen yang telah ada sebelumnya Berhubungan dengan diagram kelas.

Diagram Deployment Bersifat statis Memperlihatkan konfigurasi saat aplikasi dijalankan (saat runtime). Memuat node beserta komponen-komponen yang ada didalamnya Berhubungan dengan diagram komponen dimana deployment diagram memuat satu atau lebih komponen-komponen

Kesimpulan UML mempermudah para analis dan programmer untuk melakukan forward maupun reverse engineering. UML memudahkan meta model, sehingga pembacaan alur sebuah aplikasi dapat dipermudah. UML adalah notasi visual untuk menggambarkan konsep berorientasi object yang dewasa ini menjadi standar dalam proyek berorientasi object.