BAB 2 LANDASAN TEORI

dokumen-dokumen yang mirip
Unified Modelling Language UML

MAKALAH ANALISIS & PERANCANGAN SISTEM II USE CASE DIAGRAM

BAB II LANDASAN TEORI

Yuli Purwati, M.Kom USE CASE DIAGRAM

UNIFIED MODELING LANGUAGE

U M L. Unified Modeling Language

DAFTAR SIMBOL. case. Dependency 2. Generalization 3. 4 Include. 5 Extend. 6 Associaton

OOAD (Object Oriented Analysis and Design) UML part 2 (Activity diagram, Class diagram, Sequence diagram)

BAB II TINJAUAN PUSTAKA. yang ditandai dengan saling berhubungan dan mempunyai satu fungsi atau tujuan

Notasi Unified Modeling Language (UML) Versi 2.0

DAFTAR SIMBOL. Notasi Keterangan Simbol. Titik awal, untuk memulai suatu aktivitas. Titik akhir, untuk mengakhiri aktivitas.

DAFTAR SIMBOL. Notasi Keterangan Simbol. Actor adalah pengguna sistem. Actor. tidak terbatas hanya manusia saja, jika

DAFTAR SIMBOL 1. CLASS DIAGRAM. Nama Komponen Class

BAB II DASAR TEORI. Sebuah sistem adalah seperangkat komponen yang saling berhubungan dan bekerja

BAB II TINJAUAN PUSTAKA

Citra Noviyasari, S.Si, MT SI - UNIKOM

DAFTAR SIMBOL. Tabel Notasi Use Case Diagram

DAFTAR ISI. KATA PENGANTAR... i. DAFTAR ISI... iii. DAFTAR GAMBAR... xi. DAFTAR TABEL... xvii. DAFTAR SIMBOL... xx BAB I PENDAHULUAN...

SEJARAH UML DAN JENISNYA

BAB III METODOLOGI PENELITIAN. dalam pengumpulan data atau informasi guna memecahkan permasalahan dan

BAB II TINJAUAN PUSTAKA

BAB II LANDASAN TEORI

Notasi dalam UML. Actor

DAFTAR SIMBOL. Yaitu Memperlihatkan Hubungan-hubungan yang terjadi antara actor-aktor SIMBOL NAMA KETERANGAN. Aktor. Use Case.

BAB II TINJAUAN PUSTAKA. 2.1 Komponen Sumber Daya Manusia dalam Ruang Lingkup Fakultas. Nuraeny (2010) mengemuckakan bahwa Sumber Daya Manusia

Sistem Informasi OOAD dengan UML (1) Teknik Informatika UNIKOM

PEMBANGUNAN APLIKASI PENCATATAN PENANGANAN GANGGUAN PT. TELKOM REGIONAL BANDUNG

BAB II LANDASAN TEORI

Kebutuhan dan Spesifikasi Perangkat Lunak

Gambar Use Case Diagram

PEMANFAATAN ARDUINO DALAM PENGEMBANGAN SISTEM RUMAH PINTAR BERBASIS MOBILE DAN WEB (Studi Kasus : Penjadwalan Lampu Rumah)

DAFTAR SIMBOL. Fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor.

BAB III OBJEK DAN METODOLOGI PENELITIAN. sesuai dengan pendapat Sugiyono (2003:58) mendefinisikan bahwa:

Lampiran 1 - Pengenalan terhadap UML (Unified Model Language)

Unified Modeling Language

BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI

DAFTAR ISTILAH. Activity Diagram

Kegunaan tahap ini adalah untuk memobilisasi dan mengorganisir g SDM yang akan melakukan Reengineering

BAB II LANDASAN TEORI

MEMAHAMI PENGGUNAAN UML

1. Penggunaan Pemodelan

BAB II DASAR TEORI an dan sekitar awal 1960-an. Pada tahun 1968, NATO menyelenggarakan

Bagian 7 ANALISIS DESAIN PADA PEMROGRAMAN BERORIENTASI OBJECT DENGAN UML

BAB IV ANALISA DAN PERANCANGAN SISTEM. Adapun analisis sistem akan dilakukan pada bagian gudang ruang lingkup

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

PEMBUATAN APLIKASI PENERIMAAN OUTSOURCING BERBASIS WEB

Diagram Use Case. Pertemuan 3

2.6 Cool Record Edit Pro Adobe Photoshop Star Uml Pengertian Uml BAB III OBJEK DAN METODE PENELITIAN...

Kuliah#3 TSK-612 Sistem Embedded Terdistribusi - TA 2011/2012. Eko Didik Widianto

PENGEMBANGAN WEBSITE KOMUNITAS STUDI KASUS : KOMUNITAS FOTOGRAFI

Class Diagram Class diagram mendeskripsikan jenis-jenis objek dalam system dan berbagai macam hubungan statis yang terdapat di antara mereka.

SOAL PRA UTS PSBO. 1.SIMULA di perkenalkan pertama kali pada tahun.. a d b e c. 1970

LEMBARAN SOAL ULANGAN KENAIKAN KELAS Tahun 2014/ Komunikasi Paket Keahlian

PRAKTIKUM REKAYASA PERANGKAT LUNAK MODUL KE - 2 PENGENALAN UML dengan RATIONAL ROSE OLEH: ANISA ISTIQOMAH (KELAS 5 B)

SURAT PERNYATAAN ABSTRACT ABSTRAK KATA PENGANTAR


BAB II LANDASAN TEORI

BAB 2 TINJAUAN PUSTAKA

CLASS DIAGRAM. Jerri Agus W ( ) Gendra Budiarti ( )

BAB II LANDASAN TEORI

BAB II LANDASAN TEORI. Definisi sistem menurut Jogiyanto HM (1995 : 5) adalah sebagai berikut :

DAFTAR SIMBOL. Gambar Nama Fungsi

BAB II LANDASAN TEORI

PERANCANGAN BERORIENTASI OBJEK

Unified Modelling Language (UML)

Oleh : RAHMADY LIYANTANTO

BAB III METODOLOGI PENELITIAN

Pendahuluan Rekayasa Perangkat Lunak II. Alif Finandhita. Teknik Informatika UNIKOM

BAB III ANALISIS DAN PERANCANGAN APLIKASI. Aplikasi chatting mobile phone yang menggunakan NetBeans IDE 6.0 yang di

REKAYASA PERANGKAT LUNAK II

OOAD (Object Oriented Analysis and Design) UML part 1 (Usecase) Gentisya Tri Mardiani, S.Kom., M.Kom ADSI-2015

BAB III BAB IV Class Diagram... II Sequence Diagram... II Colaboration Digram... II Activity Diagram... II S

RANCANGAN APLIKASI LATIHAN BELAJAR TENSES DENGAN METODE OBJECT ORIENTED DESIGN

BAB II LANDASAN TEORI

DAFTAR ISI. ABSTRAK... i. ABSTRACT... ii. KATA PENGANTAR... iii. DAFTAR ISI... v. DAFTAR GAMBAR... xvi. DAFTAR TABEL... xxiii. DAFTAR SIMBOL...

Pemodelan Berorientasi Objek

BAB II LANDASAN TEORI

BAB III OBJEK DAN METODE PENELITIAN. domain & Web Hosting. Untuk lebih jelas mengenai gambaran umum perusahaan,

DAFTAR ISI LEMBAR PENGESAHAN SURAT PERNYATAAN

Review Rekayasa Perangkat Lunak. Nisa ul Hafidhoh

2. Fungsi di dalam kelas yang dikombinasikan bentuk tingkah laku kelas dinamakan dengan. c.operasi

BAB II LANDASAN TEORI

1. SIMULA di perkenalkan pertama kali pada tahun.. a d b e c. 1970

BAB II TINJAUAN PUSTAKA. uang, dan informasi. Sumber daya tersebut bekerjasama menuju

BAB II LANDASAN TEORI. hanya dapat berjalan pada server yang hasilnya dapat ditampilkan pada klien.

2. Dibawah ini yang bukan merupakan bentuk bentuk objek adalah

UML UNIFIED MODELLING LANGUAGE

BAB II LANDASAN TEORI

Gambar 1.1. User Interface ATM

BAB III OBJEK DAN METODE PENELITIAN. tempat sanggar seni mayang sari di bandung dimana terletak di jalan Moch Toha

PEMANFAATAN ARDUINO DALAM PENGEMBANGAN SISTEM KEAMANAN RUMAH BERBASIS WEB

DASAR REKAYASA PERANGKAT LUNAK

PertemuanI. Object Oriented

BAB II TINJAUAN PUSTAKA

Disain System Berorientasi Objek (Unified Modeling Language) ( Studi Kasus : Sistem Informasi Manajemen Perpustakaan )

UML Class Diagram 1 UML??? 2 UML Diagram

Gambar L.37 Form Print Laporan Absensi Harian Gambar L.38 Form Print Laporan Absensi Periode

BAB III LANDASAN TEORI

DAFTAR ISI. ABSTRACT... i. ABSTRAK... ii. KATA PENGANTAR... iii. DAFTAR ISI... vi. DAFTAR GAMBAR... x. DAFTAR TABEL... xii. DAFTAR SIMBOL...

model abstrak grafis teks memahami fungsionalitas sistem media komunikasi

Transkripsi:

7 BAB 2 LANDASAN TEORI 2.1 Konsep Pemodelan Objek Pemodelan objek merupakan suatu metode untuk menggambarkan struktur sistem yang memperlihatkan semua objek yang ada pada sistem. (Nugroho, 2005, hal:37). Beberapa konsep dasar dalam pemodelan objek adalah objek, kelas, atribut, operasi, dan hubungan. 2.1.1 Objek dan Kelas Objek merupakan sesuatu, sebuah entitas, sebuah benda, sesuatu yang dapat diangkat, atau apapun yang dapat kamu bayangkan yang memiliki identitas masing-masing. (O Docherty, 2005, hal:13). Ada beberapa objek yang hidup dan ada yang tidak. Contoh objek dalam dunia nyata yaitu orang, nomor, kucing, dan mobil. Objek adalah orang, tempat, benda, kejadian, atau konsep-konsep yang ada di dunia nyata yang penting bagi suatu perangkat lunak. (Nugroho, 2005, hal:38). Objek orang misalnya mahasiswa, dosen, ibu, ayah, dan sebagainya. Objek tempat misalnya kampus, negara, jalan, kota, dan sebagainya. Objek benda misalnya mesin, buku, mobil, komputer, dan sebagainya. Objek kejadian misalnya pembayaran, registrasi kuliah, mengikuti kuliah, dan sebagainya. Kelas seperti juga objek, adalah sesuatu yang membungkus (encapsulate) informasi (atribut) dan perilaku (operasi) dalam dirinya. Dalam pengembangan sistem tradisional, dilakukan pendekatan dengan cara memisahkan atribut pada sisi basis data dan operasi pada sisi aplikasi pengakses. Namun hal ini berbeda pada pendekatan

8 berorientasi objek yang menggabungkan atribut dengan operasi yang akan mengaksesnya dalam apa yang dinamakan kelas. Kelas didefinisikan sebagai kumpulan objek dengan atribut yang mirip, operasi yang mirip, serta hubungan dengan objek yang lain dengan cara yang mirip. (Nugroho, 2005). Gambar berikut memperlihatkan suatu kelas dan objek yang mungkin dihasilkan dengan prosedur instansiasi. Suatu objek merupakan instansiasi dari suatu kelas jika objek itu merupakan keturunan yang nyata dari suatu kelas. Manusia Instansiasi (Manusia) Adi (Manusia) Ani Kelas Objek Gambar 2.1 Kelas dan Objek 2.1.2 Atribut dan Operasi Setiap objek memiliki identitas dan masing-masing dapat dibedakan. (Nugroho, 2005, hal:38). Setiap objek memiliki atribut, misalnya sebuah mobil memiliki produsen, jenis, warna, dan harga, sedangkan seekor kucing memiliki jenis kelamin, jenis, berat, dan warna. Setiap objek juga memiliki operasi, misalnya mobil dapat bergerak dari satu tempat ke tempat lain, sedangkan kucing dapat berlari, minum, dan makan. Atribut adalah informasi-informasi yang dimiliki suatu objek dalam kelas. Dari contoh di atas dapat ditambahkan, untuk objek Adi dan Ani dapat memiliki atribut jenis kelamin, usia, berat badan, tinggi badan, dan lain-lain. Dari fakta-fakta ini dapat dipahami bahwa nilai dari suatu atribut adalah karakteristik yang membedakan satu objek dengan objek lainnya dalam kelas yang sama.

9 Instansiasi Manusia (Manusia) (Manusia) Nama: String Usia: Integer Adi 21 Ani 23 Kelas dengan atribut Objek dengan nilai pada atribut Gambar 2.2 Atribut dan Nilai Operasi atau metode berhubungan dengan perilaku yang berhubungan dengan suatu kelas. Operasi adalah fungsi atau transformasi yang mungkin dapat diaplikasikan ke/oleh suatu objek dalam kelas. Contohnya suatu objek dalam kelas manusia dapat memiliki operasi-operasi seperti tersenyum, berbicara, makan, minum, dan sebagainya. Contoh lainnya yaitu suatu objek lingkaran memiliki atribut warna, posisi, dan jari-jari, serta memiliki operasi geser dan pilih. Algoritma dari suatu operasi dapat dirincikan dengan menggunakan pseudocode yang memiliki bagianbagian yaitu nama metode, kamus yang berisi semua nama yang ada dan tipe datanya, serta algoritma yang berisi uraian langkah-langkah penyelesaian masalah. Manusia -Nama -Usia +Makan() +Berpindah_alamat() Lingkaran -Warna -Posisi -Jari-jari +Geser(in Delta : bool) +Pilih(in Point : object) : bool Gambar 2.3 Operasi 2.1.3 Hubungan (Relationship) Ketika menggambarkan kelas-kelas dan objek-objek, akan terlihat bahwa kebanyakan kelas dan objek adalah berdiri sendiri. Pada kenyataannya, hampir semua kelas dan objek saling bekerja sama satu sama lain sehingga pada pemodelan kelas dan objek, setelah kelas dan objek didefinisikan, juga dimodelkan bagaimana kelas-kelas dan objek-objek saling berhubungan.

10 2.2 UML UML adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek. (Fowler, 2005, hal: 1). UML merupakan standar yang relatif terbuka yang dikontrol oleh Object Management Group (OMG), yang terdiri dari banyak perusahaan. UML lahir dari penggabungan banyak bahasa pemodelan grafis berorientasi objek antara lain metode Booch oleh Graddy Booch, metode Object Modelling Technique (OMT) oleh DR. James Rumbaugh, dan metode Object Oriented Software Engineering (OOSE) oleh Ivar Jacobson. Dengan UML, dapat dibuat model untuk perangkat lunak, dimana perangkat lunak tersebut dapat berjalan pada perangkat keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Namun, karena UML juga menggunakan kelas dan operasi dalam konsep dasarnya, maka UML lebih cocok untuk pemodelan perangkat lunak dalam bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. 2.2.1 Analisis Persyaratan dengan UML Analisis persyaratan meliputi usaha untuk mengetahui apa kemampuan sebuah sistem yang diinginkan pengguna dan pelanggan dari sebuah pengembangan perangkat lunak. Beberapa diagram yang digunakan dalam analisis persyaratan yaitu: 1. Use case diagram yang digunakan untuk menggambarkan bagaimana orang-orang berinteraksi dengan sistem tersebut. 2. Activity diagram yang berfungsi menunjukkan aliran kerja organisasi tersebut yang dapat menunjukkan bagaimana aktivitas interaksi antara perangkat lunak dan manusia. Activity diagram dapat menunjukkan konteks use case dan juga rincian bagaimana sebuah use case berjalan. 3. Class diagram yang diambil dari sudut pandang konseptual, dapat berfungsi untuk membangun kosakata yang besar mengenai domain tersebut. 4. Package diagram untuk mengelompokkan kelas-kelas.

11 2.2.2 Desain dengan UML Beberapa diagram yang digunakan dalam mendesain sistem yaitu: 1. Use case diagram yang digunakan untuk menggambarkan bagaimana orang-orang berinteraksi dengan sistem tersebut. 2. Sequence diagram untuk mengetahui apa yang terjadi dalam perangkat lunak. 3. Class diagram dari sudut perangkat lunak. Diagram ini menunjukkan kelas yang terdapat di dalam perangkat lunak dan bagaimana mereka saling berhubungan. 4. Package diagram untuk menunjukkan organisasi berskala besar perangkat lunak tersebut. 5. Penggunaan deployment diagram untuk menunjukkan susunan fisik perangkat lunak tersebut. 2.2.3 Teknik Analisis dan Desain Sistem dengan UML Teknik yang digunakan dalam pemodelan analisis dan desain sistem menggunakan UML diantaranya: 1. Pengidentifikasian proses bisnis sistem yang terjadi di lapangan. 2. Pengidentifikasian fungsionalitas sistem dengan penggunaan use case diagram. 3. Pengidentifikasian skenario sistem berdasarkan use case diagram dengan penggunaan activity diagram. 4. Pengidentifikasian kelas-kelas yang terdapat dalam sistem dengan penggunaan class diagram. 5. Pengidentifikasian hubungan inheritance antara kelas. 6. Pengidentifikasian atribut-atribut yang dimiliki setiap kelas. 7. Pengelompokan kelas-kelas dalam package-package tertentu dengan penggunaan package diagram. 8. Pada setiap use case, dilakukan pengidentifikasian operasi-operasi yang dimiliki setiap kelas yang terlibat dalam use case tersebut. 9. Pengidentifikasian objek-objek, serta penggunaan sequence diagram untuk mendeskripsikan aliran komunikasi antara objek-objek pada setiap use case. 10. Desain antarmuka sistem dan spesifikasi detail dari bagian-bagian antarmuka yang berhubungan dengan fungsi sistem.

12 11. Pengidentifikasian arsitektur fisik sistem dan kebutuhan sistem dengan penggunaan deployment diagram. Teknik yang digunakan tidak terbatas pada teori yang diperoleh, namun berdasarkan kebutuhan pada saat analisis dan desain sistem. Dalam pembangunan suatu sistem, jenis diagram yang digunakan disesuaikan dengan kebutuhannya. 2.2.4 Diagram-Diagram dalam UML Dalam UML, dikenal diagram-diagram yang digunakan untuk membantu dalam analisis dan desain sistem. Dalam skripsi ini, ada beberapa diagram yang digunakan, yaitu use case diagram, activity diagram, class diagram, sequence diagram, package diagram, dan deployment diagram. 2.2.4.1 Use Case Diagram Use case diagram mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem tersebut digunakan. (Fowler, 2005). Use case diagram menampilkan aktor, use case, dan hubungan diantara mereka yang dijabarkan sebagai berikut: 1. Aktor Aktor adalah seseorang atau sesuatu yang berinteraksi dengan sistem yang sedang dikembangkan. Aktor bersifat eksternal, yaitu berada di luar lingkup sistem yang sedang dikembangkan. (Nugroho, 2005). Pengguna sistem merupakan aktor yang umum di setiap sistem. Aktor disimbolkan dengan: Aktor Gambar 2.4 Aktor

13 Setiap use case diagram memiliki aktor utama yang meminta sistem untuk memberi sebuah layanan. Aktor utama adalah aktor dengan tujuan yang akan dipenuhi oleh use case diagram. Aktor selain aktor utama dikenal sebagai aktor sekunder. 2. Use Case Use case menggambarkan bagaimana seseorang akan mengunakan atau memanfaatkan sistem. Use case dapat membantu untuk berfokus pada apa yang penting, yaitu menentukan apa yang dibutuhkan serta harapan pengguna terhadap sistem yang dikembangkan. Pengidentifikasian use case dapat dilakukan dengan melakukan identifikasi pekerjaan-pekerjaan dan fungsi-fungsi apa yang dilakukan aktor untuk sistem. Use case disimbolkan dengan: Use case Gambar 2.5 Use Case 3. Hubungan (relationship) Aktor dan use case masing-masing tidak berdiri sendiri, melainkan saling terhubung dengan apa yang dinamakan hubungan. Ada beberapa hubungan yang dikenal dalam use case diagram, yaitu: a. Hubungan asosiasi (association relationship) Hubungan asosiasi merupakan hubungan yang biasa terjadi antara aktor dan use case yang menggambarkan bahwa aktor melakukan apa yang dinyatakan dalam use case. Hubungan disimbolkan dengan: Aktor Use case Gambar 2.6 Hubungan Asosiasi

14 b. Hubungan cakupan (include relationship) Hubungan cakupan memungkinkan suatu use case untuk menggunakan fungsionalitas yang disediakan oleh use case lainnya. Hubungan ini dapat membantu dalam beberapa kasus seperti pada kasus dimana dua atau lebih use case memiliki sejumlah besar fungsi yang identik, maka fungsi-fungsi yang sama dapat dipisahkan menjadi suatu use case tersendiri, sehingga use case lain dapat memiliki hubungan cakupan dengan use case yang baru. Hubungan cakupan disimbolkan dengan: <<include>> NewUseCase1 NewUseCase2 Gambar 2.7 Hubungan Cakupan c. Hubungan perluasan (extends relationship) Hubungan perluasan memungkinkan suatu use case memiliki kemungkinan untuk memperluas fungsionalitas yang disediakan use case lainnya. Hubungan perluasan disimbolkan dengan: <<extend>> NewUseCase1 NewUseCase2 Gambar 2.8 Hubungan Perluasan d. Hubungan generalisasi (generalization relationship) Hubungan generalisasi digunakan untuk memperlihatkan bahwa beberapa aktor atau use case memiliki sesuatu hal yang bersifat umum. Generalisasi berguna untuk mengelompokkan sifat-sifat yang umum dari sejumlah aktor

15 atau use case menjadi aktor atau use case tunggal, kemudian bisa mewariskan sifat-sifat umum tadi ke sejumlah aktor atau use case yang lain. Hubungan generalisasi disimbolkan dengan: Gambar 2.9 Hubungan generalisasi 2.2.4.2 Activity Diagram Activity diagram secara sepintas mirip dengan diagram alir (flowchart) yang memperlihatkan aliran kendali dari suatu activity ke activity lainnya. Activity diagram juga dapat digunakan untuk memodelkan langkah-langkah dalam sebuah use case. (Reed, 2001). Dalam membangun activity diagram dikenal beberapa komponen, yaitu: 1. Awal dan akhir activity Simbol yang digunakan untuk awal activity yaitu: Mulai Gambar 2. 10 Simbol Awal Activity Mirip dengan simbol awal activity, simbol yang digunakan untuk menandakan akhir dari activity diagram yaitu:

16 Gambar 2. 11 Simbol Akhir Activity 2. Action state dan activity state Action state merupakan langkah-langkah dalam activity diagram, dimana state mencerminkan eksekusi dari suatu aksi pada objek. Misalnya pemanggilan operasi pada sebuah objek, menciptakan objek, atau menghancurkan objek. Pekerjaan suatu action state secara umum dipertimbangkan mengambil waktu eksekusi yang tidak signifikan. Action state pada umumnya bersifat atomik, pekerjaannya tidak dapat didekomposisi lebih lanjut. Action state pada activity diagram disimbolkan dengan: X = X + 1 Gambar 2.12 Action State Activity state dapat didekomposisi lebih lanjut, activity state dapat ditampilkan dengan activity diagram yang lain. Activity state tidak bersifat atomik, yang secara umum berarti membutuhkan beberapa waktu untuk terselesaikan dengan tuntas. Activity state pada activity diagram disimbolkan dengan:

17

18 keluar. Pada joining, aliran konkuren yang masuk akan saling menunggu satu sama lain sebelum melanjutkan ke titik-titik selanjutnya. Forking dan joining dilambangkan dengan:

19 Gambar 2.17 Kelas, atribut, dan operasi 2. Hubungan Hubungan memiliki beberapa bentuk, yaitu: a. Asosiasi Asosiasi merupakan hubungan antara dua atau lebih kelas yang menspesifikasikan hubungan antara bagian-bagian mereka. Hubungan antara dua buah kelas mengindikasikan bahwa objek pada kelas yang satu mengenali objek pada kelas yang lain dan dapat mengirimkan pesan kepada objek tersebut. Asosiasi memiliki multiplisitas yang memberi petunjuk tentang banyaknya instansi dari suatu kelas berhubungan dengan satu instansi kelas yang lain pada satu waktu tertentu. Dalam UML, notasi-notasi multiplisitas yang dapat digunakan yaitu: Tabel 2.1 Multiplisitas Multiplisitas Arti Satu 1 Nol atau banyak (tak terbatas) * (0..*) Satu atau banyak 1..* Nol atau satu (asosiasi pilihan) 0..1 Jangkauan tertentu 2..4 Multiple, jangkauan disjoint 2, 4..6, 8 Asosiasi biasanya diberi nama untuk menggambarkan artinya. Asosiasi juga memiliki role, yaitu ujung dari suatu asosiasi yang terhubung ke kelas.

20 Gambar 2.18 Asosiasi b. Agregasi dan komposisi Agregasi merupakan bentuk hubungan antara suatu keseluruhan ke bagianbagiannya. Gambar 2.19 Agregasi Komposisi adalah bentuk yang lebih kuat dari agregasi. Bagiannya merupakan milik satu-satunya dari keseluruhan. Gambar 2.20 Komposisi c. Generalisasi Generalisasi diperlukan untuk memperlihatkan hubungan pewarisan (inheritance) antarunsur dalam class diagram. Pewarisan memungkinkan suatu

21 kelas mewarisi semua atau sebagian atribut, operasi, hubungan, serta semantik dari kelas yang berada di atasnya dalam hierarki pewarisan. Gambar 2.21 Generalisasi d. Dependency Dependency menghubungkan dua kelas atau lebih dimana jika terdapat perubahan pada kelas yang satu, maka akan memaksa terjadinya perubahan pada kelas yang lainnya walaupun tidak terdapat asosiasi yang jelas diantara mereka. e. Realisasi Hubungan realisasi digunakan untuk memperlihatkan hubungan antara suatu kelas dengan interface-nya, antara package dengan interface-nya, antara komponen dengan interface-nya, atau antara use case dengan realisasi use case yang bersangkutan. Gambar 2.22 Hubungan Realisasi 3. Constraint dan notes Constraint dan notes memberikan keterangan pada bagian-bagian seperti asosiasi, atribut, operasi, dan kelas. Constraint merupakan batasan semantik yang ditandai dengan ekspresi boolean.

22 Gambar 2.23 Constraint dan Notes 4. Stereotype Kelas mempunyai stereotype, yang menyediakan kemampuan untuk membuat elemen pemodelan yang baru. Beberapa stereotype yang umum untuk suatu kelas adalah : entiti, boundary, dan control. Kelas entiti merefleksikan entiti dunia nyata. Kelas entiti biasanya independent dari sekitarnya, dan tidak tahu bagaimana cara sekitarnya berkomunikasi dengan sistem. Aplikasinya independent, artinya bisa digunakan untuk lebih dari satu aplikasi. Kelas entiti disebut dengan kelas domain karena berhubungan dengan abstraksi entiti dunia nyata. Kelas boundary menangani komunikasi antara lingkungan sistem dan yang ada di dalam sistem, menyediakan interface bagi user atau sistem lain (misalnya interface ke aktor). Kelas control memodelkan urutan behavior spesifik terhadap satu atau lebih use case. Kelas control mengkoordinasi event yang diperlukan untuk merealisasikan behavior spesifik dalam use case. Kelas control biasanya merupakan kelas yang tergantung pada aplikasi. Kelas control bertanggung jawab terhadap arus event dalam use case. 2.2.4.4 Sequence Diagram Sequence diagram digunakan untuk melihat behavior beberapa objek di dalam use case tunggal. Sequence diagram baik untuk memperlihatkan kolaborasi antarobjek. Masing-masing sequence diagram menggambarkan aliran-aliran pada suatu use case. Sequence diagram dapat dibaca dengan melihat pada objek-objek dan pesan-

23 pesan (message). Objek-objek yang berperan dalam aliran diperlihatkan pada kotak empat persegi panjang yang melintas pada bagian atas diagram. Setiap objek memiliki garis hidup (lifeline), yang digambarkan sebagai garis vertikal di bawah nama suatu objek. Garis hidup dimulai pada saat objek terbentuk. Pesan-pesan digambarkan di antara garis hidup yang dimiliki dua objek untuk memperlihatkan bagaimana objekobjek itu saling berkomunikasi. objek1:class1 objek2:class2 : Aktor Gambar 2.24 Sequence Diagram 2.2.4.5 Package Diagram Kelas menunjukkan bentuk dasar penyusunan sebuah sistem borerientasi objek. Meskipun kelas berguna, dibutuhkan sesuatu yang lebih untuk menyusun sistemsistem yang lebih besar. Sebuah package adalah sebuah bentuk pengelompokan yang memungkinkan untuk mengambil setiap bentuk di UML dan mengelompokkan elemen-elemennya dalam tingkatan unit yang lebih tinggi. Kegunaan package yang umum adalah mengelompokkan kelas. Sebuah package dapat terdiri dari sub package dan kelas. Setiap kelas harus memiliki nama unik di dalam packagenya. Dalam diagram, package disimbolkan dengan sebuah folder berlabel:

24 NewPackage Gambar 2.25 Package 2.2.4.6 Deployment Diagram Deployment diagram menunjukkan susunan fisik sebuah sistem, menunjukkan bagian perangkat lunak mana yang berjalan pada perangkat keras yang mana. Deployment diagram menggambarkan simpul (node) yang saling berhubungan. Simpul adalah elemen fisik yang ada saat aplikasi dijalankan dan mencerminkan suatu sumber daya komputasi, secara umum menggunakan kapasitas memori dan kemampuan pemrosesan. Diagram dengan simpul umum digunakan pada pemodelan client server dimana komponen-komponen suatu aplikasi disebarkan pada tiap-tiap server dengan tujuan mencapai kinerja yang optimum. Simpul disimbolkan dengan kubus. Hubungan antarsimpul dilambangkan dengan garis lurus. Processor Device Gambar 2.26 Simpul-Simpul pada Deployment Diagram Processor Device Gambar 2.27 Hubungan Antarsimpul