Pada akhir tahun 1980-an dan pada awal tahun 1990-an, sudah terdapat metode pemodelan berorientasi objek yang digunakan oleh industri-industri, di antaranya adalah Booch Method, Object Modeling Technique (OM T) yang diperkenalkan oleh James Rumbaugh, dan Object-Oriented Software Engineering (OOSE) yang diperkenalkan oleh Ivar Jacobson. Keberadaan metode yang beragam tersebut justru menimbulkan masalah utama dalam pengembangan berorientasi objek, karena dengan banyaknya metode tersebut akan membatasi kemampuan untuk berbagi model antar proyek dan antar tim pengembang. Kesulitan dalam berbagi tersebut disebabkan karena perbedaan konsep dalam tiap metode pemodelan sehingga akan menghambat komunikasi antar anggota tim dengan user sehingga menyebabkan munculnya banyak kesalahan atau error dalam proyek. Karena masalah-masalah tersebut, maka standarisasi diperlukan dalam penggunaan bahasa pemodelan.
Pada tahun 1994, Grady Booch dan James Rumbaugh bekerja sama dan berusaha menyatukan metode pengembangan berorientasi objek yang mereka perkenalkan dengan tujuan untuk menciptakan sebuah sistem pengembangan berorientasi objek yang standar. Pada tahun 1995, Ivar Jacobson ikut bergabung dan ketiganya memusatkan perhatian
untuk menciptakan bahasa pemodelan yang standar dan tidak lagi memusatkan perhatiannya pada metode atau pendekatan berorientasi onjek. Berdasarkan pemikiran ketiga tokoh tersebut, pada tahun 1997 bahasa pemodelan objek standar Unified Modeling Language (UM L) versi 1.0 mulai diperkenalkan kepada masyarakat luas.
UM L bukan merupakan metode untuk mengembangkan sistem, tetapi hanya merupakan notasi yang diterima dengan luas sebagai bahasa pemodelan objek yang standar. Object Management Group (OMG) mengadopsi UM L pada bulan November 1997 dan sejak saat itu terus dikembangkan berdasarkan kebutuhan industri. Pada tahun 2004, diluncurkan UM L versi 1.4 dan pada saat itu OMG telah merencanakan pengembangan UM L versi 2.0.
2.21.2 Notasi UML
Notasi (M athiassen, 2000, p237) adalah bahasa tekstual dan graphical untuk menggambarkan sebuah sistem dan konteksnya yang diformalisasikan secara terpisah. Tujuan dari notasi UM L adalah untuk menyederhanakan komunikasi dan dokumentasi.
2.21.3 Class Diagram
Class Diagram menggambarkan hubungan struktur objek dari sistem. Class diagram menunjukkan class objek yang membentuk sistem dan hubungan struktural di antara class (Mathiassen, 2000, p336). Terdapat tiga hubungan antar class yang biasa digunakan dalam class diagram yaitu:
• Asosiasi
Asosiasi merupakan hubungan antara dua objek atau class. Hubungan ini menggambarkan apa yang perlu diketahui oleh sebuah class mengenai class
lainnya. Hubungan ini memungkinkan sebuah objek atau class mereferensikan objek atau class lain dan saling mengirimkan pesan.
Gambar 2.20 Contoh Hubungan Asosiasi
• Generalisasi atau Spesialisasi
Dalam hubungan generalisasi, terdapat dua jenis class, yaitu class supertype dan class subtype. Class supertype atau class induk memiliki atribut dan behavior yang umum dari hirarki tersebut. Class subtype atau class anak memiliki atribut dan behavior yang unik dan juga memiliki atribut dan behavior milik class induknya. Class induk merupakan generalisasi dari class anaknya, sedangkan class anak merupakan spesialisai dari class induknya.
Gambar 2.21 Contoh Hubungan Generalisasi
• Agregasi
Agregasi merupakan hubungan yang unik dimana sebuah objek merupakan bagian dari objek lain. Hubungan agregasi tidak simetris dimana jika objek B merupakan bagian dari objek A, namun objek A bukan merupakan bagian dari objek B. Pada
hubungan ini, objek yang menjadi bagian dari objek tertentu tidak akan memiliki atribut atau behavior dari objek tersebut.
Gambar 2.22 Contoh Hubungan A gregasi
2.21.4 Statechart Diagram
Statechart diagram merupakan diagram yang memodelkan perilaku dinamis dari objek dalam sebuah class spesifik yang berisi state dan transition (M athiassen, 2000, p341). Statechart diagram mengilustrasikan siklus hidup dari objek yaitu berbagai status yang dimiliki objek dan event yang menyebabkan status suatu objek berubah menjadi status lain. Statechart diagram dibuat dengan langkah-langkah sebagai berikut:
• M engidentifikasi initial dan final state.
• M engidentifikasi status objek selama masa hidup objek tersebut.
• M engidentifikasi event pemicu perubahan status objek.
Sumber: M athiassen (2000, p425) Gambar 2.23 Contoh Statechart Diagram
2.21.5 Use Case Diagram
Use Case diagram mendeskripsikan fungsi secara grafis hubungan antara aktor dan use case. (Mathiassen, 2000, p343). Penjelasan use case biasa ditambahkan untuk menghentikan langkah-langkah interaksi.
Sumber : M athiassen (2000, p129) Gambar 2.24 Contoh Use Case Diagram
2.21.6 Sequence Diagram
Sequence Diagram mendeskripsikan interaksi di antara objek yang diatur berdasarkan urutan waktu (Bennet, 2006, p253). Sequence diagram dapat digambarkan dalam berbagai tingkat kedetilan yang berbeda-beda untuk memenuhi tujuan yang berbeda-beda pula dalam daur hidup pengembangan sistem. Sequence diagram yang paling umum digunakan untuk menggambarkan interaksi yang terjadi pada sebuah use case atau sebuah operation.
Gambar 2.25 Contoh Sequence Diagram
2.21.7 Navigation Diagram
Navigation Diagram merupakan suatu bentuk statechart diagram yang memfokuskan pada user interface (Mathiassen, 2000, p344). Navigation diagram menunjukkan window-window dan transisi di antara window tersebut. Sebuah window digambarkan sebagai sebuah state. State ini memiliki nama dan gambar miniatur window. Transisi yang terjadi dipacu karena adanya ditekannya salah satu tombol yang menghubungkan sebuah window ke window lainnya.
2.21.8 Component Diagram
Component Diagram merupakan diagram implementasi yang digunakan untuk menggambarkan arsitektur fisik dari sebuah sistem. Diagram ini menunjukkan bagaimana coding pemrograman terbagi menjadi komponen dan juga ketergantungan di antara komponen-komponen tersebut.
Sumber: M athiassen (2000, p201) Gambar 2.26 Contoh Component Diagram
2.21.9 Deployment Diagram
Deployment Diagram juga merupakan diagram implementasi yang menggambarkan arsitektur fisik dari sistem. Yang membedakan deployment diagram dan component diagram adalah deployment diagram tidak hanya menggambarkan arsitektur fisik software saja, tetapi juga software dan hardware. Diagram ini menggambarkan komponen, software, prosesor, dan peralatan lainnya yang digunakan oleh sistem. M enurut M athiassen (2000, p340) deployment diagram menunjukkan konfigurasi sistem dalam bentuk prosesor dan objek yang terhubung ke prosesor tersebut.
Setiap kotak dalam deployment diagram menggambarkan sebuah node yang menunjukkan hardware. Hardware dapat berupa PC, mainframe, printer, ataupun sensor. Software yang terdapat di dalam node digambarkan dengan simbol komponen. Garis menghubungkan node menunjukkan jalur komunikasi antar peralatan.
Sumber: M athiassen (2000, p217) Gambar 2.27 Contoh Deployment Diagram