BAB II LANDASAN TEORI
2.12 Unified Modeling Language (UML)
Pada musim gugur 1995, Ivar Jacobson bergabung dengan perusahaan Rational. Dengan menggunakan use case dan model interaksi antara objek, meredukasi kekurangan dan sebelumnya serta membawa beberapa ide baru. Ivar Jacobson menyumbangkan pemikiran baru terhadap Unified Method dan kemudian barulah Unified Method berganti nama menjadi Unified Modelling Language (UML), versi 0.9 dan 0.91 diliris pada bulan Juni dan Oktober 1996.
UML sendiri pada akhirnya bukan merupakan suatu metode, karena metode sekurang-kuangnya terdiri atas sebuah bahasa pemodelan dan sebuah proses. Bahasa pemodelan merupakan suatu cara menuliskan (terutama dengan gambar metode-metode itu dalam mengekspesikan rancangan-rancangan. Sedangkan proses adalah petunjuk dalam menentukan langkah-langkah apa yang dilakukan dalam mengerjakan sebuah rancangan. UML tidak tergantung dari proses.
Pendekatan dalam analisis berorientasi objek dilengkapi dengan alat-alat dan teknik-teknik yang dibutuhkan dalam pengembangan sistem, sehingga hasil akhir dari sistem yang dapat terdefinisi dengan baik dan jelas. Maka analisis berorientasi objek akan dilengkapi dengan alat dan teknik di dalam mengembangkan. (Hariyanto, 2004).
Komponen UML ada 9 diagram yaitu:
A. Use Case Diagram.
B. Class Diagram. C. Activity Diagram. D. Component Diagram. E. Deployment Diagram. F. Sequence Diagram. G. Collaboration Diagram H. Statechart Diagram
2.12.1 Use Case Diagram
Use case dibuat berdasarkan keperluan aktor, merupakan “apa” yang dikerjakan sistem, bukan “bagaimana” sistem mengerjakannya. use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan aktor dan dinotasikan dengan gambar (horizontal ellipse).
Gambar 2.4 Notasi Use Case (Nugroho, 2005)
Use case biasanya menggunakan nama use case boleh terdiri atas beberapa kata dan tidak boleh ada use case yang memiliki nama yang sama. Use case diagram tidak boleh terpengaruh urutan waktu, meskipun demikian supaya mudah dibaca penyusunan use case (Nugroho, 2005).
a. Aktor
Aktor menggambarkan orang, sistem atau ekstensial entitas/ stakeholder yang menyediakan atau menerima informasi dari sistem. Aktor adalah entity ekstenal yang berhubungan dengan sistem yang berpartisipasi dalam use case. Seorang aktor secara khusus menggambarkan sistem dengan input atau masukan kejadian-kejadian atau menerima sesuatu dari sistem. Tidak boleh ada komunikasi langsung antar aktor dan sebuah aktor jangan digambarkan di tengah-tengah use case. Dan letakan aktor utama pada pojok kiri atas dari diagram.
Aktor dilukiskan dengan peran yang mereka mainkan dalam use case, seperti pelanggan, admin, dan lain-lain. Simbol aktor dalam UML digambarkan seperti Gambar 2.4.
Petugas Penjualan
Gambar 2.5 Notasi Aktor (Nugroho, 2005)
Dalam use case terdapat satu aktor pemulai dalam awal sistem. Aktor akan sangat berguna untuk mengetahui siapa aktor pemulai tersebut (Nugroho, 2005).
Biasanya, aktor merupakan peranan yang dibawa oleh manusia, tetapi tidak menunup kemungkinan bahwa aktor itu adalah sebuah hal dari sebuah sistem, jenis-jenis aktor meliputi:
1. Peranan-peranan yang dimulai oleh orang-orang yang berhubungan dengan sistem.
b. Relasi Assosiasi Antar Use Case
1. <<Include>>
Digunakan ketika dalam penulisan use case yang berbeda terdapat deskripsi-deskripsi yang sama, maka relasi ini dapat digunakan untuk menghindari penulisan deskripsi yang berulang-ulang. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include dieksekusi secara normal. Sebuah use case dapat di include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas (Sholiq, 2006).
2. <<extend>>
Sebuah use case juga dapat mengextend use case lain dengan behavior-nya sendiri. Sementara hubungan generalisasi antar use case menunjukan bahwa use case yang satu merupakan spesifikasi dari yang lain. Ini sedikit mirip dengan Include tetapi jika Extend tidak harus terjadi apa yang diharapkan (Sholiq, 2006).
2.12.2 Activity Diagram (Diagram Aktivitas)
Activity Diagram menggambarkan urutan aktivitas-aktivitas, yang mendukung penggambaran tindakan sistem baik yang bersifat kondisional maupun pararel. Tindakan kondisional dilukiskan dengan cabang (branch) dan penyatuan (merge).
Sebuah branch (cabang) memiliki sebuah transition masuk atau yang disebut dengan incoming transition dari branch (cabang) yang berupa
keputusan-keputusan. Hanya satu dari outgoing transition yang dapat diambil, maka keputusan-keputusan tersebut harus menunjukan bahwa transition”else” tersebut harus digunakan jika semua keputusan yang ada pada branch (cabang) .
Sebuah merge (penyatuan) memiliki banyak input transition dan sebuah output. Marge (penyatuan) menandakan akhir dari suatu kondisi yang diawali dengan sebuah branch (cabang). Selain branch (cabang) dan marge (penyatuan), di dalam diagram aktivitas terdapat pula fork dan join. Fork memiliki satu incoming transition dan beberapa outgoing transition. Sedangkan semua state pada incoming transition telah menyelesaikan aktivitasnya (Sholiq, 2006).
2.12.3 Sequence Diagram (Diagram Sequensial)
Sequence diagram menggambarkan interaksi antara objek didalam dan disekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
Sequence diagram bisa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk manghasilkan output tertentu. Diawali dari apa yang aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek termasuk aktor memiliki life line vertikal. Message digambarkan sebagai garis berpanah dari satu objek lainya. Pada fase desain berikutnya, massage akan dipetakan menjadi operasi/metode dari garis class (Suhendar, 2002).
2.12.4 Class Diagram (Diagram Kelas)
Diagram class menjelaskan sekumpulan kelas-kelas dan hubungan strukturalnya. Dalam UML, diagram class merupakan penjelasan sentral analisis dan desain object oriented. Kelas menggambarkan keadaan (atribut/property) suatu sistem sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut.
Kelas memiliki tiga area pokok: 1. Nama.
2. Atribut. 3. Metoda.
Dalam class dapat diimplementasikan menjadi basisdata. Model-model kelas pada dasarnya diwakili oleh tabel yang mengambil nama kelas. Masing-masing atribut kelas menjadi kolom tabel, dan Masing-masing-Masing-masing objek diwakili sebagai baris tabel. Terkadang sering ditambahkan kolom yang mengandung referensi unik/primary key setiap objek. Untuk setiap atribut harus diberikan property wilayah nilai, legalitas nilai yang kosong dan kemungkinan menggunakan key (foreign key) (Suhendar, 2002).
2.12.5 Statechart Diagram (Diagram Statechart)
Diagram Statechart adalah satu jalan untuk mengkarakterisasi perubahan dalam sistem dalam hal ini adalah objek-objeknya berubah status dalam merespon kejadian dan waktu. Diagram Statechart penting untuk diterapkan, sebab diagram statechart akan membantu analisis, desainer dan pengembang
untuk mengerti behaviour objek-objek yang ada didalam sistem. Diagram class hanya menunjukkan aspek statis dari sistem. Diagram class menunjukan hirarki dan asosiasi dan juga behaviour, akan tetapi tidak menunjukan detail dinamis dari behavior. Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai dengan kondisi saat itu. Transisi antara state umumnya memiliki kondisi yang merupakan syarat terjadinya transisi yang bersangkutan, ditulis dalam kurung siku. Aksi yang dilakukan dari kejadian tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambar berbentuk lingkaran berwarna penuh dan berwarna setengah (Suhendar, 2002).
2.12.6 Component Diagram (Diagram Komponen)
Diagram komponen menunjukkan model secara fisik komponen perangkat lunak pada sistem dan hubungannya antar mereka. Ada dua tipe komponen dalam diagram yaitu komponen exutable dan kode pustaka (libraries code). Masing–
masing kelas dalam model akan dipetakan ke sebuah komponen kode pustaka. Setelah komponen dibuat, mereka ditambahkan dalam diagram komponen dengan memberi relasi antar komponen. Relasi yang terjadi antara komponen hanya satu tipe relasi yaitu dependensi yang menunjukkan ketergantungan compile-time dan run-time antara komponen-komponen tersebut (Suhendar, 2002).
2.12.7 Deployment Diagram
Diagram deployment menampilkan rancangan fisik jaringan dimana berbagai komponen akan terdapat di sana. Deployment/ physical diagram
menggambarkan detail bagaimana komponen di sebar 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 mennyebar komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini (Suhendar, 2002).