BAB I PENDAHULUAN

1.1 Latar belakang Masalah Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik seperti UML. Pemodelan perangkat lunak notasi untuk mengeskpresikan model. UML bukan metodologi. UML independent terhadap proses, independen terhadap bahasa pemrograman

1.2 Tujuan Tujuan dalam pembuatan makalah ini adalah untuk menambah pengetahuan kita dalam mengenali UML. Juga diharapkan dalam pengerjaan makalah ini dapat bermamfaat bagi semua orang.

1.3 Metode penulisan Penulis menggunakan metode observasi dan mencari di internet

|1

BAB II PEMBAHASAN

2.1

Pengertian Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

2.2

Sejarah UML Pada tahun 1994 dua orang bekerja pada perusahaan Rational software yaitu James Rumbaugh yang mengembangkan OOD(Object Oriented Diagram) dan Grady Broach yang mengembangkan OMT(Object Modelling Language). Kemudian pada bulan oktober 1995 mereka berdua menciptakan Unified method versi 0.8. Kemudian pada musim gugur 1995 Ivan Jacobson bergabung dengan mereka berdua dengan memperkenalkan Tool Use Case. Pada bulan Juni 1996 mereka bertiga menciptakan UML(Unified Modelling Language) versi 0.9. Akhirnya pada bulan Januari 1997 terciptalah UML versi 1.0 yang sebelumnya dibetuklah konsersium dari beberapa perusahaan software. Pada bulan September 1997 lahirlah UML versi 1.1 dengan 8 buah diagram, yaitu Sequence diagram, activity diagram, collaboration diagram, class diagram, use diagram, statechart diagram, component diagram dan deployment diagram. Pada tahun 1999 lahirlah UML versi 1.3 dengan penambahan bussiness use case diagram. Pada bulan Mei 2001 lahirlah UML versi 1.4 dengan penambahan object diagram. Pada bulan Maret 2003 lahirlah UML versi 1.5. Pada akhir 2003 lahirlah UML versi 2.0 dengan penambahan composite structure diagram, interaction overflow diagram, package diagram dan timming diagram. Serta perubahan dari collaboration diagram menjadi communication

diagram(collaboration diagram + state chart diagram) dan state chart diagram menjadi state machine diagram.

|2

2.3

Komponen UML

a. Diagram Use case Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah apa yang diperbuat sistem, dan bukan bagaimana. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan system.

b. Diagram Class 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

Atribut dan metoda dapat memiliki salah satu sifat berikut : Private, tidak dapat dipanggil dari luar class yang bersangkutan
|3

Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya Public, dapat dipanggil oleh siapa saja.

c. Diagram StateChart Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

d. Diagram Activity Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan
|4

sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

e. Diagram Sequence Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait) Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan

|5

f. Diagram Collaboration 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

g. Diagram Component Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time,

|6

link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain

h. Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen dideploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

Komponen Client

Ethernal

Komponen Server

|7

2.4

Berikut contoh kasus UML tentang Perparkiran Mobil a. Diagram Use case Saat masuk

Saat Keluar

b. Diagram class

|8

c. Diagram Statechart

d. Diagram Activity Saat Masuk

Saat Keluar

|9

e. Diagram Sequence Saat Masuk

Saat Keluar

f. Diagram Collaboration Saat Masuk

| 10

Saat Keluar

g. Diagram Component

h. Deployment Diagram

| 11

BAB III PENUTUP

Demikian makalah tentang contoh kasus UML perparkiran mobil yang berisi tentang tahapan-tahapan dalam pembuatan kasus UML dari Diagram Use case, Diagram Class, Diagram StateChart, Diagram Activity, Diagram Sequence, Diagram Collaboration, Diagram Component, sampai dengan Deployment Diagram.

3.1 Kesimpulan UML atau Unified Modelling Language adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan

mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Seperti contoh kasus perperkiran mobil yang dari wal masuk mobil sampai mobil tersebut keluar.

3.2 Saran Kami mengharapkan makalah ini mendapat tanggapan yang positif dari para pembaca makalah ini juga kami mengharapkan saran dan kritik yang membangun agar dalam pengerjaan makalah seperti ini menjadi lebih baik dari yang sebelumsebelumnya.

| 12