Introduction to Object-Oriented Systems Analysis & Design with Unified Modeling Language, Version 2.0

DAFTAR ISI

2.1 TUJUAN

2.2 INTRODUCTION

2.3 BASIC CHARACTERISTICS OF OBJECT-ORIENTED SYSTEMS

2.3.1 Pendahuluan

2.3.2 Konsep

2.3.2.1 Modularitas

2.3.2.2 Enkapsulasi

2.3.2.3 Terminologi

2.3.2.4 Kelebihan dan Kelemahan Object Oriented Programming dibanding Structural Programming

2.3.2.5 Karakteristik Dasar Sistem Berorientasi Objek

2.3.2.6 Object Oriented Development (OOD)

2.3.2.7 Pemodelan perancangan

2.3.2.8 Pertanyaan Pendukung

2.4 THE UNIFIED MODELING LANGUAGE, VERSION 2.0

2.4.1 Sejarah Singkat UML

2.4.2 Apa itu UML

2.4.3 Diagram Pemodelan

2.4.4 Extension Mechanisms

2.4.5 Kasus yang Sering Terjadi

2.1 TUJUAN

  • Mengerti tentang karakteristik dasar dari sistem berorientasi objek.
  • Mengenal lebih dekat Unified Modelling Language (UML), Versi 2.0.
  • Mengenal lebih dekat Unified Process.
  • Mengenal setidaknya pendekatan tentang sistem analisis dan perancangan berbasis objek.

Kembali ke daftar isi

2.2 INTRODUCTION
Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat tanpa memperhatikan unsur-unsur pentingnya yang dapat mendukung. Seharusnya piranti lunak  dirancang dengan memperhatikan hal-hal seperti scalability, security, dan eksekusi yang handal walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama.

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.

Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya.

Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuah segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.


Ilustrasi 2.1 Segitiga sukses

Sampai tahun terakhir, analis terfokus pada data atau proses bisnis saat mengembangkan sistem. Ketika mereka bergerak melalui SDLC, mereka menekankan baik data untuk sistem (pendekatan data-sentris) atau proses yang akan mendukung (pendekatan proses-sentris). Pada pertengahan 1980-an, pengembang mampu membangun sistem yang lebih efisien jika analis itu bekerja dengan data sistem dan proses secara simultan, dan terfokus pada mengintegrasikan keduanya. Dengan demikian, tim proyek mulai menggunakan pendekatan berorientasi obyek, dimana modul yang mengandung komponen itu disebut objek (yang mengandung data dan proses) digunakan sebagai blok bangunan untuk sistem.

Ide dibalik pendekatan berorientasi obyek bukanlah hal baru. Mereka dapat ditelusuri kembali ke bahasa pemrograman berorientasi objek, Simula, diciptakan pada tahun 1960, dan Smalltalk, dibuat pada awal tahun 1970. Hingga pertengahan 1980-an, pengembang harus menyimpan data dan proses terpisah agar dapat membangun sistem yang dapat berjalan pada komputer mainframe pada saat itu. Hari ini, karena kenaikan daya prosesor dan penurunan biaya prosesor, pendekatan berorientasi objek layak digunakan. Salah satu kendala utama dari pembelajaran pendekatan berorientasi objek untuk sistem informasi yang sedang berkembang adalah volume dari terminologi baru. Dalam bab ini kita akan memperoleh gambaran tentang karakteristik dasar dari suatu sistem berorientasi objek, memberikan gambaran tentang Unified Modeling Language (UML, 2.0), memperkenalkan analisis dasar sistem berorientasi objek dan desain dan Proses Unified, dan menyajikan pendekatan minimalis untuk analisis sistem berorientasi objek dan desain dengan UML 2.0.

Kembali ke daftar isi

2.3 BASIC CHARACTERISTICS OF OBJECT-ORIENTED SYSTEMS

2.3.1 Pendahuluan

Pemrograman Berorientasi Objek merupakan perbaikan dari pemrograman structural (atau disebut juga fungsional). Kelemahan dari pemrograman structural adalah kurangnya modularitas dari data yang ada. Sebuah perubahan pada sebuah data yang tersimpan menyebabkan banyaknya perubahan yang harus dilakukan pada data – data lain yang berhubungan.  Salah satu contoh permasalahan yang timbul akibat dari pemrograman structural ini adalah permasalahan Y2K (bug yang terjadi pada tahun 2000) yang menyebabkan kerugian materi dalam jumlah yang besar. OO memberikan sebuah metode untuk membangun perangkat lunak yang lebih handal (robust) dengan semakin besar dan kompleksnya sistem.

2.3.2 Konsep

2.3.2.1 Modularitas

Sistem berorientasi objek terdiri dari modul – modul. Modularitas adalah sebuah konsep yang menekankan penggabungan data – data dan fungsi – fungsi yang berhubungan ke dalam sebuah kesatuan (modul) yang sama.

Ada 2 hal yang yang perlu diketahui tentang modul :

- Untuk setiap modul yang ada, mungkin terdapat beberapa variabel. Setiap variabel memiliki nilai tersendiri.

- Sebuah modul berkomunikasi dengan modul lain dengan cara saling memanggil fungsi yang ada.

2.3.2.2 Enkapsulasi

Enkapsulasi adalah sebuah konsep yang menekankan bahwa hanya setiap variabel yang memiliki data itu sendirilah yang dapat melakukan perubahan (modifikasi) terhadap data tersebut ataupun membaca data tersebut. Konsep ini memberikan struktur yang handal (robust) tetapi menyebabkan perubahan lebih mudah bisa dilakukan terhadap sistem.

2.3.2.3 Terminologi

Setiap modul pada sistem berorientasi objek disebut juga sebagai objek. Pada dunia nyata, objek memiliki 2 karakteristik, yaitu : data dan kelakuan.

Data untuk setiap objek secara umum disebut atribut dari objek. Kelakuan yang berbeda dari setiap objek disebut juga metode dari objek. Metode adalah analogi langsung dari fungsi atau prosedur pada bahasa pemograman.

Kelas adalah template dari sebuah objek. Sebuah kelas mendeskripsikan atribut dan metode yang akan ada untuk semua variabel dari kelas.

2.3.2.4 Kelebihan dan Kelemahan Object Oriented Programming dibanding Structural Programming

Pengembangan perangkat lunak menuntut keahlian teknis yang tinggi, ketekunan luar biasa, serta kemampuan mengelola proyek yang memadai. Di masa lalu, pengembangan perangkat lunak memakan waktu yang lama, biaya yang melebihi perkiraan, kurang memenuhi harapan dan kebutuhan pengguna dan yang paling parah banak perangkat lunak yang tidak bisa digunakan setelah selesai dikembangkan karena jauh dari apa yang diharapkan pengguna.

Pada saat ini, perangkat lunak yang dikembangkan harus mampu mengakomodasi perubahan-perubahan yang terjadi sangat cepat terutama untuk merespon perubahan lingkungan bisnis dan kebutuhan pengguna yang berubah dengan cepat. Oleh karena itu diperlukan metode pengembangan perangkat lunak yang lebih sesuai. Metode terstruktur yang selama ini digunakan dirasakan kurang memadai lagi.

Dalam pengembangan perangkat lunak dengan metode terstruktur, para perancang mulai dengan mengembangkan blok-blok standar kode untuk melakukan operasi tertentu, kemudian menyalinnya ke aplikasi lain yang ditulis. Hal tersebut menyulitkan saat terjadi perubahan pada blok-blok kode awal, sebab pengembang harus menyalinnya dimanapun kode awal tersebut disalin, yang pada akhirnya menjadikan waktu pengembangan lebih lama.

Pemrograman berorientasi obyek (Object Oriented Programming-OOP) dipandang merupakan kerangka kerja yang paling baik saat ini untuk menggantikan metode terstruktur. Dengan OOP para pengembang menciptakan blokblok kode yang dinamakan objek. Objek-objek ini kemudian digunakan oleh berbagai aplikasi. Dan apabila suatu saat terjadi perubahan, para pengembang hanya melakukan perubahan sekali saja dan dengan mudah mewariskannya ke objek lain yang menjadi turunannya.

Paradigma OOP adalah para pengembang membagi aplikasi-aplikasi yang besar menjadi objek-objek yang mandiri satu terhadap lainnya. Karena OOP menggunakan paradigma yang berbeda dengan pemrograman terstruktur, maka dibutuhkan tool yang berbeda pula. Salahsatu tool tersebut adalah UML (Unified Modelling Language). UML merupakan tool yang sangat sesuai karena konsep dasarnya adalah memodelkan kelas-kelas beserta atribut di dalamnya bersamaan dengan relasi-relasi yang terjadi antar kelas yang bersangkutan. Selain itu, UML memungkinkan pengembang sistem untuk melakukan perancangan hingga ke model fisik perangkat keras (misalnya pada jaringan komputer).

Kelebihan pada umumnya

- Sistem yang dibangun lebih handal (robust).

- Memiliki gambaran yang lebih baik tentang dunia nyata.

Kelemahan pada umumnya

- Sulit untuk menggambarkan kelakuan dari sistem secara keseluruhan disebabkan oleh karena kelas adalah kesatuan yang bersifat low-level.

2.3.2.5 Karakteristik Dasar Sistem Berorientasi Objek

Sistem berorientasi objek berfokus untuk menangkap struktur dan perilaku dari sistem informasi dalam modul kecil yang mencakup baik data dan proses. Modul-modul kecil ini dikenal sebagai objek. Pada bagian ini bab, kita menjelaskan karakteristik dasar sistem berorientasi objek, yang meliputi kelas, objek, metode, pesan, enkapsulasi, menyembunyikan informasi, pewarisan, polimorfisme, dan dynamic binding.

Classes and Objects

Kelas adalah template umum kita gunakan untuk mendefinisikan dan membuat variabel tertentu, atau bisa disebut benda. Setiap objek berhubungan dengan kelas. Sebagai contoh, semua objek yang menangkap informasi mengenai pasien dapat masuk ke dalam kelas yang disebut Pasien, karena ada atribut (misalnya, nama, alamat, dan tanggal lahir) dan metode (contoh menyisipkan misalnya, menginputkan pasien baru, memelihara informasi, dan menghapus entri ) semua itu adalah apa yang pasien bagikan (lihat Gambar 2.1).

Sebuah objek adalah variabel dari kelas. Dengan kata lain, sebuah objek adalah orang, tempat, peristiwa, atau hal yang ingin kita peroleh sebagai informasi. Jika kita membangun sebuah sistem pendaftaran untuk kantor dokter, kelas mungkin termasuk dokter, pasien, dan perjanjian. Para pasien tertentu seperti Jim Maloney, Mary Wilson, dan Theresa Marks dianggap contoh, atau objek, dari kelas pasien.
Setiap objek memiliki atribut yang mendeskripsikan informasi tentang objek, seperti nama pasien, tanggal lahir, alamat, dan nomor telepon. Keadaan suatu obyek ditentukan oleh nilai atribut dan hubungan dengan obyek lain pada suatu titik waktu tertentu. Sebagai contoh, pasien mungkin memiliki kondisi “baru” atau “sekarang” atau “telah berobat.”

Setiap objek juga memiliki behaviors. Behaviors adalah sifat yang menentukan apa yang dapat dilakukan oleh objek. Sebagai contoh, objek perjanjian dapat berupa menjadwalkan janji baru, menghapus janji, dan mencari janji yang tersedia berikutnya.


Gambar 2.1 Classes And Object

Salah satu aspek yang lebih membingungkan pengembangan sistem berorientasi objek adalah kenyataan bahwa di kebanyakan bahasa pemrograman berorientasi objek, baik kelas dan variabel dari kelas masing-masing dapat memiliki atribut dan metode. Atribut dari kelas dan metode cenderung digunakan untuk atribut model (atau metode) yang berhubungan dengan isu-isu terkait dengan semua variabel kelas. Misalnya, untuk membuat objek pasien baru, pesan dikirim ke kelas pasien untuk membuat sebuah keterangan yang baru untuk kelas itu sendiri. Dari sudut pandang seorang analisis sistem dan desain, maka kita akan berfokus pada atribut dan metode dari objek dan bukan dari kelas.

Methods and Messages

Metode menerapkan perilaku obyek. Sebuah metode tidak lebih dari suatu tindakan yang dapat objek lakukan. Dengan demikian, mereka bersifat analog dengan fungsi atau prosedur dalam bahasa pemrograman tradisional seperti C, COBOL, atau Pascal. Message adalah informasi yang dikirim ke objek untuk memicu metode. Pada dasarnya, pesan adalah fungsi atau prosedur yang dipanggil dari satu objek ke objek lain. Misalnya, jika seorang pasien, baru mendaftar ke kantor dokter, sistem akan mengirim pesan untuk memasukkan informasi ke aplikasi tersebut. Objek pasien akan menerima pesan (instruksi) dan melakukan apa yang perlu untuk dilakukan, tentang memasukkan pasien baru ke dalam sistem (execute adalah metode yang dipakai). Lihat Gambar 2.2.

Encapsulation and Information Hiding

Ide-ide enkapsulasi dan menyembunyikan informasi sangat berhubungan dalam sistem berorientasi objek. Walaupun tidak ada satu pun penjelasan yang baru. Enkapsulasi hanyalah kombinasi sederhana dari proses dan data ke dalam satu kesatuan. Pendekatan tradisional untuk pengembangan sistem informasi cenderung untuk menjadi proses-sentris (misalnya, sistem terstruktur) ataupun data-sentris (misalnya, teknik informasi). Pendekatan berorientasi objek menggabungkan proses dan data ke dalam (objek) secara keseluruhan yang bisa hadir secara bebas tanpa terpengaruh (objek) lain.

Gambar 2.2 Messages and Methods

Information hiding pertama kali diperkenalkan dalam pengembangan sistem terstruktur. Prinsip menyembunyikan informasi menunjukkan bahwa hanya informasi yang dibutuhkan untuk menggunakan sebuah modul perangkat lunak yang akan diterbitkan kepada pengguna modul. Biasanya, hal ini berarti informasi yang dibutuhkan untuk diteruskan ke modul, dan informasi yang kembali dari modul yang telah diterbitkan. Persisnya bagaimana modul dalam menerapkan fungsi yang dibutuhkan adalah tidak relevan. Kita benar-benar tidak peduli bagaimana benda melakukan fungsinya, selama fungsinya bisa terjadi. Dalam sistem berorientasi objek, menggabungkan enkapsulasi dengan prinsip menyembunyikan informasi, menunjukkan bahwa prinsip menyembunyikan informasi diterapkan pada objek bukan hanya menerapkannya pada fungsi atau proses. Dengan demikian, objek diperlakukan seperti kotak hitam.

Secara fakta, bahwa kita bisa menggunakan objek dengan metode memanggil adalah kunci untuk penggunaan ulang karena hal ini melindungi kerja internal objek dari perubahan yang terjadi di sistem luar, dan menjaga sistem dari keterpengaruhan ketika ada perubahan dilakukan terhadap suatu objek. Pada Gambar 2.2, perhatikan bagaimana sebuah pesan (insert pasien baru) akan dikirim kepada suatu objek, namun algoritma internal yang diperlukan untuk menanggapi pesan, tersembunyi dari bagian yang lain dari sistem. Satu-satunya informasi yang objek perlu tahu adalah seperangkat operasi, atau metode, yang objek lain dapat lakukan dan apa pesan yang perlu dikirim untuk memicunya.

Inheritance

Pewarisan, sebagai karakteristik pengembangan sistem informasi, diusulkan dalam pemodelan data di akhir 1970-an dan awal 1980-an. Literatur pemodelan data menyarankan menggunakan pewarisan untuk mengidentifikasi tingkat yang lebih tinggi, atau lebih umum, seperti kelas dari objek. Setting umum dari atribut dan metode dapat diatur menjadi superclasses. Biasanya, kelas diatur dalam hirarki dimana superclasses, atau kelas umum, berada di atas, dan subkelas, atau kelas tertentu, di bagian bawah. Pada Gambar 2.3, seseorang adalah superclass daripada kelas Dokter dan kelas Pasien. Dokter, pada gilirannya, adalah superclass untuk dokter umum dan spesialis. Perhatikan bagaimana kelas (misalnya, dokter) dapat berfungsi sebagai superclass dan subclass secara bersamaan. Hubungan antara kelas dan superclass dikenal sebagai hubungan A-Kind-Of (AKO). Sebagai contoh, pada Gambar 2.3, seorang dokter umum adalah A-Kind dari dokter, dan merupakan A-Kind-Of dari orang.
Subclass mewarisi atribut dan metode yang sesuai dari superclasses di atas mereka. Artinya, setiap subclass berisi atribut dan metode dari superclass induknya. Sebagai contoh, Gambar 2.3 menunjukkan bahwa baik dokter dan pasien adalah subclass orang dan karena itu akan mewarisi atribut dan metode dari class orang. Pewarisan akan membuatnya pendefinisian kelas lebih sederhana. Alih-alih seperti mengulang atribut dan metode di dokter dan pasien yang kelasnya terpisah, atribut dan metode pada umumnya ditempatkan di kelas orang dan diwarisi oleh kelas-kelas di bawahnya. Perhatikan bagaimana jauh lebih efisien hirarki dari kelas objek daripada objek yang sama tanpa hirarki pada Gambar 2.4.

Gambar 2.3 Hirarki Class

Kebanyakan kelas di seluruh hirarki akan mengakibatkan kasus, setiap kelas yang memiliki variabel disebut kelas konkret. Misalnya, jika Mary Wilson dan Jim Maloney adalah attribut nama dari kelas pasien, pasien akan dianggap sebagai kelas konkret. Beberapa kelas tidak menghasilkan kasus karena mereka digunakan hanya sebagai template untuk kelas yang lebih spesifik lain (terutama kelas yang berlokasi tinggi pada sebuah hirarki). Kelas-kelas yang disebut sebagai kelas abstrak. Orang akan menjadi contoh dari kelas abstrak. Daripada membuat objek dari orang, kita akan menciptakan contoh yang mewakili kelas-kelas yang lebih spesifik dari Dokter dan Pasien, kedua jenis orang (lihat Gambar 2.3). Apa jenis kelas adalah kelas dokter umum? Mengapa?

Gambar 2.4 Pewarisan

Polymorphism and Dynamic Binding

Polimorfisme berarti bahwa pesan yang sama dapat diartikan berbeda oleh kelas yang berbeda dari objek. Sebagai contoh, memasukkan pasien berarti sesuatu yang berbeda dari memasukkan janji. Dengan demikian, bagian yang berbeda informasi yang perlu dikumpulkan dan disimpan. Untungnya, kita tidak perlu khawatir tentang bagaimana sesuatu diselesaikan saat menggunakan objek. Kita hanya mengirim pesan ke objek, dan objek yang akan bertanggung jawab untuk menafsirkan pesan secara tepat. Sebagai contoh, jika kita mengirim pesan “Gambarkan bentukmu” untuk objek persegi, objek lingkaran, dan objek segitiga, hasilnya akan sangat berbeda, walaupun pesan tersebut adalah sama. Perhatikan pada Gambar 2.5 bagaimana setiap objek merespon dengan tepat (dan berbeda) meskipun pesan adalah identik.

Polimorfisme bisa dibentuk melalui dynamic binding. Dinamis, atau terlambat, binding adalah teknik yang menunda untuk menentukan tipe objek sampai waktu running. Dengan demikian, metode khusus yang biasa disebut tidak dipilih oleh sistem berorientasi objek sampai sistem berjalan. Hal ini berbeda untuk binding statis. Dalam sistem statis terikat, jenis objek akan ditentukan pada waktu kompilasi. Oleh karena itu, pengembang harus memilih metode mana yang harus dipanggil disamping mengijinkan sistem untuk melakukannya. Inilah sebabnya mengapa di sebagian besar bahasa pemrograman tradisional anda akan menemukan logika yang rumit dalam mengambil keputusan berdasarkan berbagai jenis objek dalam sistem. Sebagai contoh, dalam bahasa pemrograman tradisional, daripada mengirim pesan “Gambarlah bentukmu” ke berbagai jenis objek grafis pada Gambar 2.5, Anda akan harus menulis logika keputusan menggunakan pernyataan case atau satu set pernyataan untuk menentukan objek grafis apa yang ingin anda gambar, dan anda harus menamai setiap fungsi gambar secara berbeda (misalnya, menggambar-persegi, menggambar lingkaran, atau menggambar-segitiga). Hal ini jelas akan membuat sistem yang jauh lebih rumit dan lebih sulit untuk dipahami.

Gambar 2.5 Polimorfisme dan Enkapsulasi

2.3.2.6 Object Oriented Development (OOD)

Dewasa ini konsep object oriented telah mendominasi hampir seluruh aspek komputerisasi. Mulai dari software game, aplikasi bisnis, DBMS, bahkan sampai ke sistem operasi. Hal tersebut terjadi karena konsep object oriented dipandang sebagai suatu konsep yang maju dan dianggap mampu memodelkan hampir semua fenomena yang ada di dunia ini. Hal lain yang menarik adalah kemampuannya untuk mengembangkan perangkat lunak secara incremental dan mengurangi biaya yang sulit dicapai oleh meodologi sebelumnya.

Membangun sistem perangkat lunak dapat diibatkan dengan membangun gedung bertingkat. Gedung bertingkat tidak mungkin dibangun tanpa memiliki cetak biru arsitektur yang lengkap. Proses tradisional untuk melakukan pengembangan sistem informasi dinamakan System Development Life Cycle (SDLC), yang memuat langkah-langkah yang seharusnya diikuti oleh para profesional dalam pengembangan sistem informasi untuk menetapkan spesifikasi, mengembangkan, dan memelihara sistem informasi. Beberapa metode yang cukup dikenal adalah metode air terjun (waterfalls) dan prototyping.

2.3.2.7 Pemodelan perancangan

Untuk memodelkan aplikasi dunia nyata (real world) menggunakan metodologi berorientasi objek, kita perlu memodelkan data maupun proses yang berjalan pada objek yang bersangkutan. Dalam konteks pengembangan sistem berorientasi objek (Object Oriented Development – OOD), terdapat beberapa keuntungan dari penggunaan pemodelan berorientasi objek, yaitu :

-           Kemampuan untuk menangani tipe-tipe data dan masalah-masalah yang lebih kompleks dan rumit

-           Memperbaiki komunikasi antara pengguna, analis, perancang, dan pemrogram

-           Meningkatkan derajad konsistensi antara tahap analisis, perancangan, serta kegiatan pemrograman karena menggunakan model yang sama untuk setiap tahap

-           Ketangguhan sistem (robustness)

-           Kemampuan untuk menggunakan ulang hasil analisis, perancangan, serta pemrograman (reusable component) pada suatu proyek ke proyek lainnya.

Untuk mengembangkan model perancangan, kita harus mengidentifikasi dan menyelidiki konsekuensi pada lingkungan implementasi akibat langkah-langkah perancangan. Semua keputusan strategis, misalnya penanganan kesalahan dan pustaka komponen yang akan dipakai berulang-ulang harus dibuat. Selanjutnya kita menggunakan keputusan itu untuk beradaptasi dengan lingkungan implementasi. Langkah terakhir adalah membuat formalisasi model perancangan untuk mendeskripsikan bagaimana objek-objek berinteraksi satu sama lain lewat suatu skenario (use case) yang telah dikembangkan sebelumnya.

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. Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.

UML (Unified Modelling Language) adalah bahasa pemodelan standar pada rekayasa perangkat lunak. Dengan menggunakan UML akan berdampak pada peningkatan produktifitas dan dan kualitas serta pengurangan biaya dan waktu. Kerumitan arsitektur dalam pengembangan perangkat lunak bisa diatasi dengan menggambarkan cetak biru sistem tersebut. Di sinilah UML bisa banyak berperan.

2.3.2.8 Pertanyaan Pendukung

Dalam membangun sistem berorientasi objek, ada beberapa pertanyaan yang harus dijawab :

- Bagaimana cara mendefinisikan objek yang kita perlukan ketika melakukan perancangan sistem?

- Apa metode dari atribut yang harus dimiliki?

- Seberapa besar sebuah kelas harus dibuat?

Referensi

  1. Dennis, Wixom, Tegarden: Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, 2nd Edition
  2. Grady Booch, Object-Oriented Analysis and Design with Application, Benjamin/Cummings, 1991.
  3. Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.
  4. Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
  5. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorenson, Object-Oriented Modeling and Design, Prentice Hall, 1991.
  6. Sally Shlaer and Stephen J. Mellor, Object-Oriented System Analysis: Modeling the World in Data, Yourdon Press, 1988.
  7. Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.
  8. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.
  9. Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.
  10. James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.
  11. Unified Modeling Language Specification, Object Management Group, www.omg.org, 1999.
  12. Introduction to OMG UML [http://www.omg.org/gettingstarted/what_is_uml.htm]
  13. UML Tutorial [http://www.sparxsystems.com.au/UML_Tutorial.htm]
  14. Embarcadero Tech Support [http://www.embarcadero.com/support/uml_central.asp]
  15. Practical UML A Hands-On Introduction for Developers, http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html]
  16. Architecture and Design: Unified Modeling Language (UML), [http://www.cetuslinks. org/oo_uml.html]

Kembali ke daftar isi

2.4 THE UNIFIED MODELING LANGUAGE, VERSION 2.0

2.4.1 Sejarah Singkat UML

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented).

UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software.

Pendekatan analisa & rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah yang menggunakaan metoda OO mulai diuji cobakan dan diaplikasikan antara 1989 – 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh dari General Electric, dikenal dengan OMT (Object Modelling Technique).

Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang berbasis OO, ketika mereka bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk mengadopsi masing-masing pendekatan metode OO untuk membuat suatu model bahasa yang uniform / seragam yang disebut UML (Unified Modeling Language) dan dapat digunakan oleh seluruh dunia.

Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh bergabung dengan Booch untuk membuat sebuah project pendekatan metode yang uniform/seragam dari masing-masing metode mereka. Saat itu baru dikembangkan draft metode UML version 0.8 dan diselesaikan serta direlease pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta dipelihara oleh OMG yang dipimpin oleh Cris Kobryn.

UML adalah standar dunia yang dibuat oleh Object Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-standar teknologi objectoriented dan software component.

2.4.2 Apa itu UML

Unified Modelling Language (UML) 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.

Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun.

Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

Ilustrasi 2.2 Object Management Group

Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1],  metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

Sampai tahun 1995, konsep objek menjadi populer tetapi dilaksanakan dengan berbagai cara oleh pengembang yang berbeda. Setiap pengembang memiliki metodologi sendiri dan notasi (misalnya, Booch, Coad, Moses, OMT, OOSE, dan SOMA1).

1 Lihat Grady Booch, Object-Oriented Analysis and Design with Applications, 2nd Ed.(Redwood City, CA: Benjamin/Cummings, 1994); Peter Coad and Edward Yourdon, Object-Oriented Analysis, 2nd Ed. (Englewood Cliffs, NJ: Yourdon Press, 1991); Peter Coad and Edward Yourdon, Object-Oriented Design (Englewood Cliffs, NJ: Yourdon Press, 1991); Brian Henderson-Sellers and Julian Edwards, BookTwo of Object-Oriented Knowledge: The Working Object (Sydney, Australia: Prentice Hall, 1994); James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design (Englewood Cliffs, NJ, 1991); Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Approach (Wokingham, England: Addison-Wesley, 1992); Ian Graham, Migrating to Object Technology (Wokingham, England: Addison-Wesley, 1994).

Kemudian pada tahun 1995, Rational Software membawa tiga pemimpin industri bersama-sama untuk menciptakan sebuah pendekatan tunggal untuk perkembangan sistem berorientasi objek. Grady Booch, Ivar Jacobson, dan James Rumbaugh bekerja dengan orang lain untuk menciptakan satu set standar teknik diagram dikenal sebagai Unified Modeling Language (UML). Tujuan dari UML adalah untuk menyediakan kosakata umum untuk istilah berorientasi objek dan teknik diagram yang cukup kaya untuk model setiap proyek pengembangan sistem dari analisis melalui implementasi. Pada November 1997, Object Management Group (OMG) secara resmi diterima UML sebagai standar untuk semua pengembang objek. Selama bertahun-tahun sejak itu, UML telah melalui beberapa revisi minor.
Versi saat ini dari UML, Versi 2.0, diterima oleh anggota OMG ketika musim semi dan pertemuan musim panas 2003.

2.4.3 Diagram Pemodelan

Versi 2.0 dari UML mendefinisikan satu set dari empat belas teknik diagram yang digunakan untuk memodelkan sistem. Diagram yang digunakan dipecah menjadi dua kelompok utama: satu untuk pemodelan struktur dari sistem dan satu untuk pemodelan sifat. Diagram pemodelan struktur termasuk kelas, objek, paket, penyebaran, komponen, dan diagram struktur komposit.
Diagram pemodelan sifat meliputi aktifitas, sequence, komunikasi, tinjauan interaksi, waktu, mesin perilaku negara, mesin penentu sifat, dan diagram use case2.

2 Material yang terdapat pada bab ini diambil dari Unified Modeling Language: Superstructure Version 2.0, ptc/03-08-02 (www.uml.org). Referensi tambahan termasuk Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies (Indianapolis, IN: Wiley, 2003), Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado, UML 2 Toolkit (Indianapolis, IN: Wiley, 2004), and Kendall Scott, Fast Track UML 2.0 (Berkeley, CA:Apress, 2004). Untuk deskripsi lengkap dari masing-masing diagaram bisa dilihat di www.uml.org.

Gambar 2.6 menyediakan gambaran dari diagram ini. Tergantung di mana pengembangan proses berada di dalam sistem ini, diagram yang berbeda akan memainkan peran yang lebih penting. Dalam beberapa kasus, teknik diagram yang sama digunakan selama pengembangan proses. Dalam hal ini, diagram bermula sebagai sesuatu yang sangat konseptual dan abstrak. Karena sistem dikembangkan, diagram berevolusi untuk menyertakan rincian yang pada akhirnya akan menghasilkan kode dan pengembangannya. Dengan kata lain, diagram bergerak dari mendokumentasikan persyaratan untuk menentukan desain. Secara keseluruhan, notasi yang konsisten, integrasi antara teknik diagram, dan penerapan diagram di seluruh proses pengembangan membuat UML menjadi bahasa yang kuat dan fleksibel untuk analis dan pengembang. Dalam sisa bagian ini, akan diberikan gambaran tentang teknik diagram yang didukung oleh UML. Dalam bab-bab selanjutnya, akan menyediakan detail lebih lanjut tentang menggunakan subset dari UML dalam analisis dan desain sistem berorientasi objek.

Structure Diagrams

Pada bagian bab ini, akan diperkenalkan structure diagram yang statis, dari UML 2.0. Seperti disebutkan di atas, diagram struktur termasuk kelas, objek, paket, penyebaran, komponen, dan diagram struktur komposit. Diagram struktur menyediakan cara untuk mewakili data dan hubungan statis yang berada dalam sistem informasi. Di bawah ini, akan digambarkan tujuan dasar dari masing-masing diagram struktur.

Class Diagram

Tujuan utama dari class diagram adalah untuk menciptakan sebuah kosa kata yang digunakan oleh analis dan pengguna. Diagram kelas biasanya merupakan hal-hal, ide-ide atau konsep yang terkandung dalam aplikasi. Misalnya, jika anda sedang membangun sebuah aplikasi penggajian, diagram kelas mungkin akan berisi kelas yang mewakili hal-hal seperti karyawan, cek, dan pendaftaran gaji. Diagram kelas juga akan menggambarkan hubungan antara kelas. Sintaks sebenarnya dari class diagram disajikan dalam Bab 7.

Object Diagram

Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, penyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat. Seperti diagram kelas, sintaks yang aktual dan penggunaan diagram objek disajikan dalam Bab 7.

Gambar 2.6 Kesimpulan dari Diagram UML Versi 2.0

Package Diagram

Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas. Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. Akan disediakan rincian lebih lanjut dalam menggunakan diagram paket di Bab 6 sampai 9.

Deployment Diagram

Deployment diagram digunakan untuk mewakili hubungan antara komponen-komponen hardware yang digunakan dalam infrastruktur fisik sistem informasi. Misalnya, ketika merancang suatu sistem informasi terdistribusi yang akan menggunakan jaringan luas, diagram penyebaran dapat digunakan untuk menunjukkan hubungan komunikasi antara node yang berbeda dalam jaringan. Mereka juga dapat digunakan untuk mewakili komponen perangkat lunak dan bagaimana mereka ditempatkan di atas arsitektur fisik atau infrastruktur sistem informasi. Dalam hal ini, diagram penyebaran merupakan lingkungan pelaksanaan perangkat lunak. Dalam Bab 13, kami menjelaskan merancang arsitektur fisik sistem informasi dan menggunakan ekstensi ke diagram deployment untuk mewakili desain.

Component Diagram

Component diagram memungkinkan desainer untuk memodelkan hubungan fisik antara modul fisik dari kode. Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server. Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena bab ini berfokus pada analisis sistem berorientasi objek dan desain, kita tidak akan membahas lebih lanjut menggunakan diagram komponen.

Composite Structure Diagram

UML 2.0 menyediakan diagram baru ketika struktur internal dari kelas bersifat kompleks maka disediakan composite structure diagram. Diagram struktur komposit ini digunakan untuk model hubungan antara bagian-bagian dari sebuah kelas. Sebagai contoh, ketika pemodelan pendaftaran penggajian, analis mungkin ingin kelas yang mewakili seluruh laporan serta kelas-kelas yang mewakili header, footer, dan garis-garis detail laporan. Dalam sebuah diagram kelas standar, ini akan membutuhkan analis untuk memodelkan pendaftaran penggajian menjadi empat kelas terpisah yang memiliki hubungan, kemudian menghubungkan mereka bersama-sama. Sebaliknya, diagram struktur komposit akan berisi tiga subclass: header, footer, dan garis detail. Diagram struktur komposit juga berguna ketika dilakukan pemodelan struktur internal komponen untuk sistem berbasis komponen. Seringkali, diagram struktur komposit merupakan mekanisme pemodelan yang kurang efektif karena pemodelan juga bisa dilakukan dengan mengkomunikasikan penggunaan paket dan diagram paket. Karena ketidakefektifan ini, dan karena kita tidak mencakup pengembangan sistem berbasis komponen, maka kita tidak akan membahas lebih lanjut dalam bab ini.

Behavior Diagram

Pada bagian bab ini, akan diperkenalkan behavior diagram yang dinamis, dari UML 2.0. Diagram sifat yang termasuk dalam UML 2.0 adalah aktifitas, sequence, komunikasi, gambaran interaksi, waktu, mesin penentu sifat, mesin penentu protokol, dan diagram use case. Diagram pemodel sifat menyediakan analis dengan cara menggambarkan hubungan dinamis antara instansi atau benda yang mewakili sistem informasi bisnis. Diagram pemodel sifat juga memungkinkan pemodelan perilaku dinamik dari objek individu sepanjang masa aktifnya. Diagram sifat mendukung analis dalam memodelkan
persyaratan fungsional agar sistem informasi berkembang.

Activity Diagram

Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut diuraikan dalam Bab 6.

3 Bagi mereka yang akrab dengan analisis dan desain struktur tradisional, diagram aktifitas menggabungkan ide-ide yang mendasari diagram alir data dan diagram alur sistem. Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets. Namun, diagram aktifitas UML 2.0 lebih umum menggunakan Petri Nets daripada teknik pemodelan proses lainnya. Untuk penjelasan penggunaan Petri Nets dengan model alur kerja bisnis dapat dilihat di Wil van der Aalst and Kees van Hee, Workflow Management: Model, Metode, and System (Cambridge, MA: MIT Press, 2002).

Interaction Diagram

Interaction diagram menggambarkan interaksi antara objek dari suatu sistem informasi berorientasi objek. UML 2.0 menyediakan empat diagram interaksi yang berbeda: sequence, komunikasi, gambaran interaksi, dan diagram waktu. Masing-masing diagram diperkenalkan di sini.

1. Sequence diagram memungkinkan analis untuk menggambarkan interaksi dinamis antara objek-objek dalam suatu sistem informasi. Sequence diagram sejauh ini merupakan jenis interaksi yang paling umum digunakan dalam pemodelan berorientasi objek. Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat digunakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek. Dengan demikian, mereka berguna dalam kedua kegiatan analisis dan desain. Akan dijelaskan diagram urutan lebih rinci dalam Bab 8.

2. Communication Diagram memberikan pandangan alternatif dari interaksi dinamis yang terjadi di antara objek dalam suatu sistem informasi berorientasi objek. Dimana sequence diagram menekankan penyusunan berbasis waktu dari suatu kegiatan, diagram komunikasi lebih berfokus pada suatu set pesan yang disampaikan dalam sekumpulan objek yang berkolaborasi. Dengan kata lain, diagram komunikasi menggambarkan bagaimana objek dapat berkolaborasi untuk mendukung beberapa aspek dari fungsi yang diperlukan dari sistem. Urutan atau penyusunan berdasarkan waktu dari pesan ditunjukkan melalui skema urutan penomoran. Dari sudut pandang praktis, diagram komunikasi dan sequence diagram menyediakan informasi yang sama. Dengan demikian, diagram komunikasi dengan sequence diagram akan dijelaskan secara lebih rinci dalam Bab 8.

3. Interaction overview diagram membantu analis memahami use case yang kompleks. Mereka memberikan gambaran aliran proses dari kontrol. Diagram gambaran interaksi memperluas diagram aktifitas melalui penambahan fragmen sequence dari sequence diagram. Akibatnya, urutan fragmen diperlakukan seolah-olah fragmen merupakan aktifitas dalam diagram aktifitas. Keuntungan utama menggunakan diagram gambaran interaksi adalah bahwa anda dapat dengan mudah memodelkan aliran urutan alternatif. Walaupun, dalam prakteknya, hal ini bisa dicapai dengan menggunakan diagram aktifitas disamping diagram use case. Karena keterbatasan dalam penggunaannya, diagram gambaran interaksi tidak dijelaskan secara lebih rinci dalam bab ini.

4. Timing diagram menggambarkan interaksi antara objek sepanjang sumbu waktu. Tujuan utama dari diagram waktu adalah untuk menunjukkan perubahan keadaan objek dalam menanggapi peristiwa-peristiwa yang terjadi dari waktu ke waktu. Diagram waktu cenderung sangat berguna ketika mengembangkan sistem real-time atau embedded. Namun, seperti diagram gambaran interaksi, karena digunakan secara terbatas, maka tidak dijelaskan diagram waktu secara lebih rinci dalam bab ini.

State Machines

Dalam UML 2.0, ada dua state machines yang berbeda yaitu sifat dan protokol.4 Mesin penentu sifat digunakan untuk menjelaskan perubahan yang dialami objek selama masa aktifnya. Mesin penentu protokol menggambarkan urutan peristiwa tertentu yang objek dapat respon.
1. Mesin penentu sifat menyediakan metode untuk memodelkan keadaan yang berbeda, atau set dari nilainya, bahwa variabel dari kelas bisa pergi selama masa aktifnya. Sebagai contoh, seorang pasien bisa berubah statusnya dari waktu ke waktu misalnya seorang yang sebelumnya pasien baru bisa berubah menjadi pasien sekarang. Masing-masing “tipe” pasien benar-benar menunjukkan keadaan yang berbeda dari pasien yang sama. Keadaan yang berbeda dihubungkan dengan peristiwa yang menyebabkan dalam contoh yaitu pasien untuk berubah dari satu keadaan ke keadaan lainnya. Akan digambarkan mesin penentu sifat secara lebih rinci dalam Bab 8.
2. Mesin penentu protokol mendukung analis dalam merancang hubungan antara unsur-unsur antarmuka pada kelas. Sebagai contoh, biasanya anda harus membuka file atau database sebelum query atau memperbarui itu. Tidak seperti mesin penentu sifat, mesin penentu protokol bisa dikaitkan dengan port pada komponen atau interface pada kelas. Mesin penentu protokol sangat khusus. Dengan demikian, tidak akan dijelaskan secara lebih rinci dalam bab ini.

Use Case Diagram

Use case diagram memungkinkan analis untuk memodelkan interaksi antara sistem informasi dan lingkungannya. Lingkungan sistem informasi akan mencakup baik pengguna akhir dan setiap sistem eksternal yang berinteraksi dengan sistem informasi. Penggunaan utama dari diagram use case adalah untuk menyediakan sarana dalam mendokumentasikan dan memahami persyaratan sistem informasi yang sedang berkembang. Use case dan diagram use case adalah beberapa alat yang paling penting untuk digunakan dalam analisis dan desain sistem berorientasi objek. Akan dijelaskan use case dan diagram use case secara lebih rinci dalam bab ini dan dalam Bab 6.

2.4.4 Extension Mechanisms

Karena UML sangat luas dan lengkap, maka mustahil bagi pencipta UML untuk mengantisipasi semua penggunaan secara potensial. Untungnya, pembuat UML juga telah menyediakan satu set mekanisme ekstensi. Yaitu termasuk stereotip, nilai tag, kendala, dan profil. Masing-masing akan dijelaskan berikutnya.

Stereotype

Sebuah stereotype mempersiapkan analis dengan kemampuan secara bertahap memperluas UML menggunakan elemen model yang sudah ada dalam UML. Stereotip akan ditampilkan sebagai teks tertutup dalam guillemets (<<>>) atau sudut kurung (<<>>). Stereotip dapat dikaitkan dengan unsur model (misalnya, kelas, objek, use case, hubungan) dalam suatu diagram UML. Stereotip akan digunakan pada Bab 12 dalam hubungannya dengan bentuk khusus dari mesin penentu sifat yaitu jendela diagram navigasi.

Tagged Values

Dalam UML, semua elemen model memiliki sifat yang menggambarkan mereka. Sebagai contoh, semua elemen memiliki nama. Ada saat-saat yang sangat berguna untuk menambah properti pada elemen-elemen dasar. Tagged values digunakan untuk menambah properti baru ke elemen dasar. Sebagai contoh, jika sebuah tim proyek tertarik dalam menelusuri kepengarangan setiap kelas dalam diagram kelas, tim proyek bisa menambahkan elemen kelas untuk menyertakan sebuah properti penulis. Hal ini juga memungkinkan untuk nilai tag berhubungan dengan stereotip tertentu. Dengan cara ini, ketika analis mengaplikasikan stereotipe ke elemen model, semua nilai tag tambahan yang terkait dengan stereotip juga diterapkan. Tidak akan digambarkan nilai-nilai dalam setiap tag secara lebih rinci dalam bab ini.

Constraints

Constraint memungkinkan analis untuk memodelkan domain masalah ke istilah yang berhubungan secara spesifik dengan menempatkan batasan-batasan tambahan pada penggunaan elemen model. Kendala biasanya dimodelkan menggunakan Object Constraint Language (OCL).5 Hal ini akan didiskusikan kembali dalam bab kendala dalam analisis dan perancangan berorientasi objek pada Bab 10.

Profiles

Profiles mengijinkan pengembang untuk mengelompokkan satu set elemen model yang telah diperluas menggunakan stereotip, nilai tag, dan atau kendala ke dalam satu paket. Profil telah digunakan untuk menciptakan ekstensi pemodelan yang dapat mengatasi jenis-jenis platform implementasi, seperti .NET, atau domain pemodelan spesifik, seperti sistem embedded. Profil hanya kenyamanan. Dalam teks ini, tidak akan digambarkan lebih lanjut tentang penggunaan profil.

5 Untuk pembahasan OCL yang lebih spesifik, lihat Jos Warmer and Anneke Kleppe, The Object Constraint Language: Precise Modeling with UML (Reading, MA: Addison-Wesley, 1999) and the UML 2.0 OCL Specification, ptc/03-10-14 (www.uml.org <http://www.uml.org/>).

Kasus 2.1 Enkapsulasi dan Penyembunyian Informasi

Datang dengan satu set contoh menggunakan enkapsulasi dan menyembunyikan informasi dalam kehidupan sehari-hari. Sebagai contoh, apakah ada informasi tentang diri Anda bahwa Anda tidak akan keberatan jika semua orang tahu? Bagaimana seseorang mengambil informasi ini? Bagaimana dengan informasi pribadi yang Anda inginkan untuk menjadi pribadi? Bagaimana Anda mencegah seseorang dari mengambilnya?

2.3.5 Kasus yang Sering Terjadi

Kasus 2.2 Pewarisan

Lihat jika Anda bisa datang dengan setidaknya tiga kelas yang berbeda yang mungkin Anda temukan dalam situasi bisnis yang khas. Pilih salah satu kelas dan ciptakan setidaknya hirarki pewarisan tiga tingkat menggunakan kelas. Manakah yang merupakan kelas abstrak, jika ada, dan mana yang konkrit?

Kasus 2.3 Polimorfisme dan Dynamic Binding

Dapatkah Anda memikirkan cara di mana anda menggunakan polimorfisme dan atau dynamic binding dalam kehidupan sehari-hari anda? Sebagai contoh, ketika anda diminta untuk melakukan beberapa tugas, apakah anda selalu melakukan tugas seperti orang lain yang anda kenal? Apakah Anda selalu melakukan tugas dengan cara yang sama, atau metode kinerja tergantung pada tempat Anda berada ketika Anda melakukan tugas?

Kasus 2.4 Diagram Struktur
Mengapa diagram struktur dianggap statis? Pertimbangkan implementasi sistem untuk departemen layanan karir universitas anda yang akan mendukung wawancara siswa dan proses penempatan kerja. Jelaskan secara singkat untuk kontak utama anda di bagian layanan karir, jenis informasi yang diagram struktur berikut akan komunikasikan: A) kelas, B) objek, C) paket, D) penyebaran, E) komponen, dan F) struktur komposit . Pastikan untuk menyertakan contoh-contoh dari departemen layanan karir sehingga pengguna non-teknis akan dapat memahami penjelasan anda!

Kasus 2.5 Diagram Sifat
Mengapa diagram sifat dianggap statis? Pertimbangkan implementasi sistem untuk departemen layanan karir universitas anda yang akan mendukung wawancara siswa dan proses penempatan kerja. Jelaskan secara singkat untuk menghubungi kontak utama di bagian layanan karir, jenis informasi yang dapat dikomunikasikan diagram struktur berikut: A) aktivitas, B) sequence, C) komunikasi, D) gambaran interaksi, E) waktu, F) mesing penentu sifat, G) mesin penentu protokol, dan H) use case. Pastikan untuk menyertakan contoh-contoh dari departemen layanan karir anda sehingga pengguna non-teknis akan dapat memahami penjelasan Anda!

Referensi

1. Alistair Cockburn :  http://members.aol.com/acockburn/2001

2. Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML:A Practical Approach Addison-Wesley

3. Ivar Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach.Addison-Wesley, 1994

4. Martin Fowler with Kendall Scott: UML Distilled.Addison-Wesley, 1997

5. Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide.Addison-Wesley, 1999

6. Terry Quatrani: Visual Modeling with Rational Rose and UML.Addison-Wesley, 1998

7. Daniel Tkach, Walter Fang and Andrew So: Visual Modeling Technique, 1996

8. Alistair Cockburn’s Web: http://members.aol.com/acockburn

9. Rational software: http://www.rational.com/uml/documentation.html

10. Dennis, Wixom, Tegarden: Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, 2nd Edition

Kembali ke daftar isi

Materi Selanjutnya bisa dilihat di http://outofthebox.students-blog.undip.ac.id/2010/09/29/apbo-chapter-2-introduction-to-object-oriented-systems-analysis-design-with-unified-modeling-language-version-2-0/