BAB II TINJAUAN PUSTAKA
2.3 Landasan Teori
2.3.5 Unified Modelling Language (UML)
1) Sejarah UML
Grady Booch dan Jim Rumbaugh memulai penelitian di Rational Software Co. sekitar tahun 1994. Tujuan mereka yakni menciptakan sebuah metode baru yang dapat menciptakan metode-metode sebelumnya yang dapat digunakan pada semua kalangan. Sekitar tahun 1995 Ivar Jacobson, seorang tokoh yang menciptakan OOSE and Objectory Methode bergabung. Selain itu, perusahaan Rational Software Co. Membeli lisensi Objectory System
dari Swedish Company sebagai pengembang dan pendistribusinya.
Maka lahirnya sebuah metode baru yang mereka beri nama “Unified Modeling Languange” yang diharapkan dapat menjadi sebuah bahasa pemodelan standar seperti yang terlihat pada Gambar 2.10 Unsur-unsur pembentuk UML.
2) Definisi Unified Modelling Language
Unified Modelling Language merupakan sebuah notasi grafis standar untuk menggambarkan sistem berorientasi objek yang merupakan hasil kerjasama dari Grady Booch, James Rumbaugh dan Ivar Jacobson. Dan didefinisikan sebagai berikut:
“Unified Modeling Language (UML) adalah suatu bahasa untuk menetapkan, membangun, memvisualisasikan, dan mendokumentasikan sistem perangkat lunak dan komponen-komponennya”, (Bahrami, 1999).”
Dari definisi diatas UML merupakan sebuah bahasa pemodelan suatu sistem berdasarkan grafik atau gambar untuk menspesifikasikan, membangun, menvisualisasikan dan mendokumentasikan suatu sistem perangkat lunak berorientasi objek. UML memberikan standar penulisan sebuah sistem yang meliputi konsep bisnis proses, penulisan kelas, skema database, dan komponen yang diperlukan dalam sistem perangkat lunak.
3) View Dalam UML
UML dibangun atas model 4+1 view. Model ini didasarkan pada fakta bahwa struktur sebuah sistem dideskripsikan dalam 5 view dimana salah satu diantaranya use case view. Use case view ini memegang peran untuk
mengintegrasikan content ke view yang lain seperti yang terlihat pada Gambar 2.11 Model 4+1 View.
Gambar 2.11 Model 4+1 View, (Munawar, 2005)
Use case View mendefinisikan perilaku eksternal sistem. Hal ini menjadi daya tarik bagi end-user, analis dan tester. Pandangan ini mendefinisikan kebutuhan sistem karena mengandung semua view yang lain yang mendeskripsikan aspek-aspek tertentu dan rancangan sistem. Itulah sebabnya use case view menjadi pusat peran yang dan sering dikatakan yang men-drive proses pengembangan perangkat lunak.
Selanjutnya Design view mendeskripsikan struktur logika yang mendukung fungsi-fungsi yang dibutuhkan di use case. Design view berisi definisi komponen program, class-class utama bersama-sama dengan spesifikasi data, perilaku dan interaksinya. Implementation view menjelaskan komponen-komponen fisik dari sistem yangakan dibangun. Hal ini berbeda dengan komponen logic yang dideskripsikan pada design view. Termasuk disini diantaranya file exe, library dan database. Informasi yang ada di view
ini relevan dengan aktifitas-aktifitas seperti manajemen konfigurasi dan integrasi sistem.
Process view berhubungan dengan hal-hal yang berkaitan dengan
concurrency di dalam sistem. Sedangkan deployment view menjelaskan bagaimana Design Implementation Process Deployment Use Case
komponen-komponen fisik didistribusikan ke lingkungan fisik. Kedua view
ini menunjukan kebutuhan non-fungsional dari sistem.
Deployment View menjelaskan bagaimana komponen-komponen fisik didistribusikan ke lingkungan fisik seperti jaringan komputer, printer dan peralatan lainnya serta bagaimana peralatan tersebut dihubungkan dengan peralatan yang lainnya dimana sistem akan dijalankan.
4) Diagram-diagram Unified Modelling Language
Setiap sistem yang komplek memiliki pendekatan yang terbaik melalui suatu himpunan kecil dalam pandangan semua view dalam suatu model, tidak ada single view yang terpenuhi. Setiap model bisa dinyatakan pada tingkat yang berbeda dari ketepatannya.
Diagram-diagram yang terdapat pada UML seperti yang terlihat pada Gambar 2.12 Klasifikasi Jenis Diagram UML Versi 1.3. Diagram kelas bersifat statis, diagram ini memperlihatkan himpunan kelas-kelas, serta relasi-relasi. Diagram ini umum dijumpai pada pemodelan sistem berorientasi objek. Meskipun bersifat statis, sering pula diagram kelas memuat kelas-kelas aktif. Diagram Objek bersifat statis, diagram ini memperlihatkan objek-objek serta relasi-relasi antar objek. Diagram objek memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas. Use Case Diagram bersifat statis, diagram ini memperlihatkan himpunan use case dan aktor-aktor (suatu jenis khusus dari kelas). Diagram ini terutama sangat penting untuk mengorganisasi dan memodelkan perilaku dari suatu sistem yang dibutuhkan serta diharapkan pengguna. Sequence diagram bersifat dinamis, diagram urutan adalah diagram interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu. Collaboration diagram Bersifat dinamis, diagram kolaborasi adalah diagram interaksi yang menekankan organisasi structural dari objek-objek yang menerima serta mengirim pesan (message). Statechart diagram bersifat dinamis, diagram state ini memperlihatkan state-state pada sistem; memuat state, transisi, even, serta aktivitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka (interface), kelas, kolaborasi dan terutama penting pada pemodelan sistem-sistem reaktif.
Aktivity diagram bersifat dinamis, diagram aktivitas ini adalah tipe khusus dari diagram state yang memperlihatkan aliran dari suatu aktivitas ke aktivitas lainnya dalam suatu sistem. Diagram ini terutama penting dalam
pemodelan fungsi-fungsi dalam suatu sistem yang memberi tekanan pada aliran kendali antar objek.
Component diagram bersifat statis, diagram komponen ini memperlihatkan organisasi serta kebergantungan sistem/perangkat lunak pada komponen-komponen yang telah ada sebelumnya. Diagram ini berhubungan dengan diagram kelas dimana komponen secara tipikal dipetakan kedalam satu atau lebih kelas-kelas, antarmuka-antarmuka (interfaces), serta kolaborasi-kolaborasi. Deployment diagram bersifat statis, diagram ini memperlihatkan konfigurasi saat aplikasi dijalankan (saat run-time). Diagram ini memuat simpul-simpul (node) beserta komponen-komponen yang ada di dalamnya. Deployment diagram berhubungan erat dengan diagram komponen dimana deployment diagram memuat satu atau lebih komponen-komponen. Diagram ini sangat berguna saat aplikasi kita berlaku sebagai aplikasi yang dijalankan pada banyak mesin (distributed computing). Class diagram, juga dikenal sebagai objek modeling, adalah diagram analisis statis yang utama. Diagram ini menunjukkan struktur yang statis dari suatu model. Suatu class diagram adalah suatu koleksi unsur-unsur
modeling yang statis, seperti kelas-kelas dan relationship yang dihubungkan sebagai suatu grafik antara yang satu dengan yang lainnya beserta isi-isinya. Sebagai contoh, hal yang ada (seperti kelas-kelas), struktur-struktur class diagram internal, dan hubungan class diagram dengan kelas-kelas yang lain.
Class diagram tidak menunjukkan informasi yang temporal, yang diperlukan di dalam pemodelan yang dinamis.
Class diagram memodelkan struktur kelas dan isinya dengan menggunakan elemen-elemen model seperti class, package, dan objek. Kelas terdiri dari tiga bagian yaitu nama kelas, attribut dan operations. Kelas didefinisikan secara global dapat diakses oleh objek diluar kelas tersebut seperti yang terlihat pada Tabel 2.1 Notasi pada Class Diagram
Tabel 2.1 Notasi pada Class Diagram
Fungsi Pengertian Simbol
Class Class adalah blok - blok pembangun pada
pemrograman berorientasi objek.
Sebuah class digambarkan sebagai sebuah kotak yang terbagi atas 3 bagian.Bagian atas adalah bagian nama dari class. Bagian tengah mendefinisikan property/atribut
class. Bagian akhir mendefinisikan method-method dari sebuah class.
Assosiation Sebuah asosiasi merupakan sebuah
relationship paling umum antara 2 class, dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship
dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship
(Contoh: One-to-one, one-to-many, many-to-many).
Dependency Kadangkala sebuah class menggunakan
class yang lain. Hal ini disebut dependency. Umumnya penggunaan dependency
digunakan untuk menunjukkan operasi pada suatu class yang menggunakan class yang lain. Sebuah dependency dilambangkan sebagai sebuah panah bertitik-titik.
Aggregation Aggregation mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi “mempunyai sebuah” atau “bagian dari”. Sebuah aggregation
digambarkan sebagai sebuah garis dengan sebuah jajaran genjang yang tidak berisi/tidak solid.
Fungsi Pengertian Simbol
Generalization Sebuah relasi generalization sepadan dengan sebuah relasi inheritance pada konsep berorientasi objek. Sebuah
generalization dilambangkan dengan sebuah panah dengan kepala panah yang tidak solid yang mengarah ke kelas “parent”-nya/induknya.
Sumber : http://resources.visual-paradigm.com/
Diagram kelas memodelkan struktur kelas dan isinya. Kelas terdiri dari Nama Kelas, Atribut dan Operasi seperti yang terlihat pada Gambar 2.13 Diagram Kelas.
Gambar 2.13 Diagram Kelas (Munawar, 2005)
Class name bagian yang paling atas berisi nama kelas, nama kelas diambil dari domain permasalahan dan harus sejelas mungkin. Oleh karena itu, nama kelas harus lah berupa kata benda. Attribute kelas memiliki attribut yang menggambarkan karakteristik dari objek. Attribut kelas yang benar adalah yang dapat mencakup informasi yang dilukiskan dan mengenali
instance tertentu dari kelas. Tipe attribut dapat berupa primitive attribut atau tipe lainnya. Method / Operations operations digunakan untuk memanipulasi attribut atau menjalankan aksi-aksi. Class diagram terdiri dari beberapa
relationship, diantaranya Generalization, Diagram objek, Aggregation dan
Association. Generalisasi adalah hubungan antara suatu kelas secara umum dengan suatu kelas yang lebih spesifik. Generalisasi adalah suatu yang
dipertunjukkan sebagai suatu garis berarah dengan tertutup. UML
membiarkan suatu label diskriminator untuk dihubungkan dengan suatu
Generalization superclass. Sebagai contoh, kelas boeing-airplane
mempunyai kejadian-kejadian dari kelas boeing 737, boeing 747, boeing 757, dan boeing 767, yang merupakan subclass dari kelas boeing-airplane. Seprti yang terlihat pada gambar 2.14 Contoh Generalisasi. Elipsis tunjukkan bahwa Generalization itu adalah tidak lengkap dan lebih banyak subclass
yang tidak ditunjukkan. Pembangun melengkapi menunjukkan bahwa
Generalization itu sudah lengkap dan tidak memerlukan lagi subclass. Jika suatu label teks ditempatkan di segi tiga yang berongga yang dibagi dengan beberapa alur generalization kepada subclass, label berlaku bagi semua alur. Dengan kata lain, semua subclass berbagi property yang diberi.
Gambar 2.14 Contoh Generalisasi (Bahrami, 1999).
Diagram objek, suatu diagram objek yang statis adalah satu kejadian dari suatu diagram kelas. Itu menunjukkan suatu snapshot dari status yang terperinci dari sistem pada suatu momen yang tepat. Notasi adalah sama selama satu diagram objek dan suatu diagram kelas. Diagram kelas dapat berisi objek, maka suatu diagram kelas dengan objek dan tidak ada kelas-kelas adalah satu diagram objek.Aggregation,Aggregasi adalah suatu bentuk asosiasi. Komposisi, juga yang dikenal sebagai a-part-of adalah suatu wujud
aggregation dengan kepemilikan yang kuat untuk menunjukkan komponen dari suatu objek yang kompleks. Komposisi juga dikenal sebagai suatu part-whole relationship. notasi UML untuk komposisi adalah suatu berlian yang padat pada akhir suatu alur. Sebagai alternatif, UML menyediakan suatu wujud dengan nyata bersarang itu, dalam banyak kesempatan, lebih menyenangkan karena adanya komposisi. Seperti yang terlihat pada gambar 2.15 Contoh Aggregasi.
Gambar 2.15 Contoh Aggregasi (Nugroho, 2005).
Tabel 2.2 Notasi Multiplisitas
Multiplitas Arti
* Banyak
0 Nol
1 Satu
0…* Nol atau banyak 1…* Satu atau banyak
0…1 Nol atau satu
1…1 Hanya satu
Association, Asosiasi didefinisikan sebagai penghubung objek-objek pada kelas yang sama. Multiplisitas (Multiplicity), Multiplicity atau multiplisitas adalah jumlah banyaknya objek sebuah class yang berelasi dengan sebuah objek lain pada class lain yang berasosiasi dengan class
tersebut. Untuk menyatakan multiplisitas anda dapat meletakkannya diatas garis asosiasi berdekatan dengan class yang sesuai. notasi – notasi yang ada pada multiplisitas seperti yang terlihat pada Tabel 2.2 Notasi Multiplisitas.
Konsep use case diperkenalkan oleh ivan Jacobson di dalam Object Oriented Software Engineering (OOSE). Kemampuan suatu sistem menguraikan sejumlah use case yang berbeda, masing-masing menunjukkan secara spesifik suatu arus kejadian yang spesifik di dalam sistem.
Use case adalah deskripsi fungsi dari sebuah sistem dari prespektif pengguna. Use case akan menggambarkan cara kerja suatu software dengan aktor. Dalam use case diagram akan digambarkan hubungan antara aktor dengan use case. Aktor adalah orang atau subsistem lain yang akan berinteraksi dengan sistem. Sementara use case menggambarkan proses yang akan dilakukan oleh aktor terhadap sistem seperti yang terlihat pada Gambar 2.16 Use Case Diagram.
Gambar 2.17 Contoh Kondisi Uses,(Munawar, 2005)
Uraian suatu use case menggambarkan apa yang terjadi di dalam sistem ketika use case dilaksanakan. Pada intinya hubungan-hubungan ini ditunjukkan di suatu diagram use case diantaranya Communication, hubungan komunikasi dari suatu aktor di suatu use case, ditunjukkan dengan menghubungkan simbol aktor kepada simbol use case dengan suatu alur yang padat. Aktor itu dikatakan “komunikasi” dengan use case. Uses, menggunakan hubungan antara use case ditunjukkan oleh panah generalisasi dari use case seperti yang terlihat pada Gambar 2.17 Contoh Kondisi Uses.
Extends, perluasan hubungan digunakan ketika kita mempunyai satu
use case yang serupa dengan use case yang lain tetapi lebih banyak. Pada intinya, itu seperti suatu subclass seperti yang terlihat pada Gambar 2.18 Contoh Kondisi Extends.
Berikut merupakan notasi-notasi untuk use case diagram seperti yang terlihat pada Tabel 2.3 Notasi Use Case Diagram dibawah.
Tabel 2.3 Notasi Use Case Diagram
Fungsi Kegunaan Simbol
Actor Actor adalah pengguna sistem. Actor tidak terbatas hanya manusia saja, jika sebuah sistem berkomunikasi dengan aplikasi lain dan membutuhkan input atau memberikan
output, maka aplikasi tersebut juga bisa dianggap sebagai actor.
Use Case Use case digambarkan sebagai lingkaran elips dengan nama use case dituliskan didalam elips tersebut.
Association Asosiasi digunakan untuk menghubungkan
actor dengan use case. Asosiasi digambarkan dengan sebuah garis yang menghubungkan antara Actor dengan Use Case.
Depends on Menyatakan hubungan ketergantungan antar
Use Case, yakni pelaksanaan suatu use case
baru bisa dilakukan setelah pelaksanaan use case lain selesai.
Sumber : http://resources.visual-paradigm.com/
Sequence diagram menggambarkan interaksi antar 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 biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah
sumbu vertikal putus-putus yang merepresentasikan “lifetime” objek dan sumbu horizontal yang menunjukan sekumpulan objek yang saling berinteraksi dalam sistem.
Diagram ini menjelaskan bagaimana objek berinteraksi dengan objek yang lainnya yaitu dengan cara mengirim dan menerima pesan. Komunikasi antar objek tersebut ditandai dengan garis horizontal yang disertai dengan nama operasinya. Berikut adalah notasi-notasinya seperti yang terlihat pada Tabel 2.4 Notasi Sequence Diagram.
Tabel 2.4 Notasi Sequence Diagram
Fungsi Pengertian Simbol
Object
Object merupakan instance dari sebuah class dan dituliskan tersusun secara horizontal. Digambarkan sebagai sebuah class (kotak) dengan nama objek didalamnya yang diawali dengan sebuah titik koma.
Actor
Actor juga dapat berkomunikasi dengan objek, maka actor juga dapat diurutkan sebagai kolom. Simbol Actor sama dengan simbol pada Actor Use Case Diagram.
Lifeline
Lifeline mengindikasikan keberadaan sebuah objek dalam basis waktu. Notasi untuk Lifeline adalah garis putus-putus vertikal yang ditarik dari sebuah objek.
Fungsi Pengertian Simbol
Activation
Activation dinotasikan sebagai sebuah kotak segi empat yang gambar pada sebuah lifeline. Activation mengindikasikan sebuah objek yang akan melakukan sebuah aksi.
Message
Message, digambarkan dengan anak panah horizontal antara Activation. Message mengindikasikan komunikasi antara objek-objek
Sumber : http://resources.visual-paradigm.com/
Berikut ini adalah contoh dari Sequence Diagram seperti yang terlihat pada Gambar 2.19 Contoh Sequence Diagram.
Activity diagram menggambarkan berbagai alur aktifitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, keputusan 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, dimana sebagian besar state adalah aksi dan sebagian besar transisi di-trigger oleh selesainya
state sebelumya (internal processing). Oleh karena itu, Activity diagram
tidak menggambarkan behavior internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktifitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktifitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana actor
mengguanakan sistem untuk melakukan aktifitas. Berikut adalah notasi
activity diagram seperti yang terlihat pada Tabel 2.5 Notasi Activity Diagram.
Tabel 2.5 Notasi Activity Diagram
Simbol Keterangan
Titik Awal Titik Akhir
Simbol Keterangan
Pilihan Untuk mengambil Keputusan
Fork; Digunakan untuk menunjukkan kegiatan yang dilakukan secara parallel / menggabungkan dua kegiatan peralel menjadi satu.
Rake; Menunjukkan adanya dekomposisi Tanda Waktu
Tanda pengiriman
Tanda penerimaan
Aliran akhir (Flow Final)
Sumber: http://resources.visual-paradigm.com/