RATIONAL ROSE dan NOTASI UML

Rational Rose adalah tools pemodelan visual untuk pengembangan system berbasis objek yang handal untuk digunakan sebagai bantuan bagi para pengembang dalam melakukan analisis dan perancangan system. Rational rose mendukung permodelan bisnis yang membantu para pengembang memahami system secara komprehensif. Ia juga membantu analisis system dengan cara pengembang membuat diagram use case untuk melihat fungsionalitas system secara keseluruhan sesuai dengan harapan dan keinginan pengguna. Kemudian, ia juga menuntut pengembang untuk mengambangkan Interaction Diagram untuk melihat bagaimana objek-objek saling bekerjasama dalam menyediakan fungsionalitas yang diperlukan.

Dalam Rational rose, pemodelan adalah cara melihat system dari berbagai sudut pandang. Ia mencakup semua diagram yang dikenal dalam UML, actor-aktor yang terlibat dalam system, use-case, objek-objek, kelas-kelas, komponen-komponen, serta simpul-simpul penyebaran. Model juga mendeskripsikan rincian yang diperlukan system dan bagaimana ia akan bekerja, sehingga para pengembang dapat menggunakan model itu sebagai blue print untuk system yang akan dikembangkan.

Pengantar Unified Modelliing Language (UML)

Pendahuluan

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability , security , dan eksekusi yang robust 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 sebuan 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.

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). 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.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

use case , actor, dan relasi

Use Case Diagram

Pengertian :

● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.
● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.
● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.

Karakteristik :

– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.
– Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.
– Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.
– Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.

Komponen Pembentuk Use Case Diagram :

1. Actor

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship
2. Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use Case dalam suatu sistem:

a. Pola perilaku perangkat lunak aplikasi.

b. Gambaran tugas dari sebuah actor.

c. Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.

d.   Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).

Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram:

1. Association, menghubungkan link antar element.

2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.

4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:

1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

UML

pengantar UML

Pada awal mula rekayasa perangkat lunak dibuat pemrograman terstruktur menjadi mainstream. Para programmer mulai mengembangkan blok-blok kode yang baku untuk melaksanakan operasi seperti misalnya operasi pembuatan laporan, pencetakan, dan operasi lainnya yang kemudian diduplikasikan dan disisipkan di dalam program-program aplikasi. Dengan demikian dapat mengurangi waktu pengembangan aplikasi yang baru, hal ini akan akan menjadi rumit apabila perubahan harus dilakukan pada blok kode program. Sebab pengembang harus lebih dulu membuat perubahan dimana kode tersebut nantinya akan di gunakan kembali pada aplikasi yang berbeda.

Pemrograman terstruktur (menggunakan bahasa pemrograman terstruktur seperti bahasa pascal, basic, foxpro dan lainya) memberikan beberapa tantangan dalam pengembangan perangkat lunak kedepan, dan tantangan tersebut dijawab dengan pemrograman berorientasi objek (bahasa C++, Java, Visual Basic) untuk memecahkan permasalahan yang dihadapi.

Pada Object Oriented Programming, pengembang aplikasi membuat blok-blok kode yang disebut dengan Class atau Object dimana Class dan Objek ini digunakan oleh berbagai macam program aplikasi untuk kebutuhan yang berbeda. Jika salah satu Class atau Object dimodifikasi maka pengembang hanya membuat satu perubahan saja pada Class atau Object tersebut sehingga instan class akan mengikuti perubahan yang terjadi. Didalam paradigma berorientasi objek pengembang mempunyai sudut pandang yang berbeda terhadap applikasi. Dengan pendekatan berorientasi objek, aplikasi dibagi menjadi bagian-bagian kecil object (berupa Class) yang tidak terikat satu sama lain. Selanjutnya aplikasi dibangun dengan menyatukan object-object kecil ini menjadi aplikasi yang lengkap dan siap untuk digunakan. Sebagai contoh object dalam pemrograman berorientasi objek adalah kontrol server seperti Textbox, Combobox, Button dan kontrol-kontrol lainya, atau programmer dapat membuat definisi class tersendiri secara khusus.

Pada pemrograman terstruktur untuk merancang sebuah form dengan kontrol listbox, textbox dan button di dalamnya, programmer harus menuliskan baris kode yang panjang untuk membuat tampilan form dan masing-masing kontrol tersebut kedalam struktur kode program yang terdiri dapat terdiri dari record, prosedur dan fungsi. Contoh yang lainya apabila programmer ingin menampilkan tombol Ok dan Cancel yang dapat menerima masukan melalui event klick mouse, maka programer menulis kode program untuk menampilkan bentuk tombol OK dan Cancel tersebut dengan menggunakan unit grafis, kemudian menuliskan kode untuk kejadian (event) klik mouse pada tombol tersebut untuk menjalankan fungsi tertentu didalam aplikasi.

Salah satu keuntungan pendekatan berorientasi objek adalah kemampuan untuk membangun komponen secara seketika dan langsung dapat digunakan secara berulang-ulang. Misalnya dengan menambahkan kontrol combobox didalam form dan mengatur nilai properti dari combobox tersebut sesuai dengan kebutuhan dalam aplikasi. Sehingga memanfaatkan form yang mengandung object yang sama pada kebutuhan lainya sangat dimungkinkan, hanya dengan merubah nilai properti dari objek tersebut dan kode program.

Lalu bagaimana paradigma berorientasi objek ini berbeda dengan pendekatan terstruktur dalam pengembangan perangkat lunak ?.

Pada pendekatan terstruktur, aktivitas-aktivitas yang dilakukan oleh tim pengembang perangkat lunak adalah :

1. Bertanya kepada user, informasi apa saja yang mereka butuhkan.

2. Mendesain basisdata untuk menyimpan informasi tersebut.

3. Mendesain tampilan layar untuk memasukkan informasi yang akan disimpan didalam basis data dan pembuatan laporan yang dapat dicetak.

Dari aktivitas diatas dapat disimpulkan bahwa pada pendekatan terstruktur lebih terpusat pada informasi, bukan pada perilaku sistem, maka pendekatan semacam ini disebut dengan pendekatan data-centric. Pendekatan data-centric sangat sesuai untuk desain program untuk penyimpanan informasi dalam basisdata dan pengolahannya. Namun akan muncul permasalahan jika digunakan untuk mendesain aplikasi bisnis, dimana perubahan aturan bisnis dan perilaku suatu sistem tidak mudah untuk diterapkan.

Pendekatan berorientasi objek telah dikembangkan untuk menjawab permasalahan tersebut, pendekatan berorientasi objek tidak hanya pada informasi namun juga melibatkan perilaku sistem yang satu sama lain berbeda. Maka diterapkanlah prinsip-prinsip berorientasi objek yaitu encapsulation, polymorphisme dan inheritance.

1.2. Prinsip-prinsip Berorientasi Objek (Object Oriented).

a. Encapsulation.

Pada konsep object oriented, kombinasi antara informasi dengan perilaku yang spesifik yang selanjutnya dibungkus (disatukan) menjadi suatu object disebut dengan encapsulation. Definisi object secara umum disebut dengan Class. Cara lain untuk melihat sebuah encapsulation adalah dengan membagi aplikasi ke dalam bagian-bagian kecil dari fungsi yang memiliki keterkaitan.

Sebagai contoh, sebuah informasi yang berkenaan dengan suatu rekening bank (sebagai nama object), memiliki informasi nomor rekening, saldo, nama nasabah, alamat jenis rekening, suku bunga, dan tanggal buka rekening (sebagai atribut objek). Perilaku dari sebuah rekening bank misalnya membuka dan menutup tabungan, menarik uang, dan perubahan alamat nasabah (sebagai methoda, operasi objek rekening bank).

Selanjutnya object, atribut dan perilaku disatukan dan dibungkus (encapsulation) bersama-sama ke dalam suatu obyek dengan nama rekening. Dengan demikian terbentuklah sebuah Class dengan nama Rekening dengan atribut dan methodanya.

Rekening Nama Class

Nomor rekening

Nama nasabah

Alamat nasabah

Jenis rekening

Suku bunga

Tanggal pembukaan

Saldo

Atribut-atribut Class

Membuka tabungan

Menutup tabungan Menarik uang

Perubahan alamat nasabah

Methoda Class

Sehingga apabila terjadi perubahan pada sistem perbankan yang berhubungan dengan rekening dapat dengan mudah diterapkan kedalam objek rekening tersebut. Keuntungan lain dari encapsulation adalah membatasi efek perubahan sistem secara keseluruhan. encapsulation dapat dianalogikan sebagai suatu sistem air di danau, dan kebutuhan akan suatu perubahan sebagai batu karang yang besar, apabila batu karang tersebut di jatuhkan kedalam air danau maka akan menyebabkan :

1. Munculnya riak air ke segala arah sampai ke tepi danau dan terjadi tumbukan antar riak air.

2. Batu karang tersebut membuat efek yang sangat besar pada sistem air di danau.

Apabila danau tersebut kita sekat dengan sebuah penghalang pada beberapa bagian maka efek riak oleh jatuhnya batu karang tersebut dapat kita batasi. Perhatikan ilustrasi enkapsulasi dibawah ini :

Gambar 1.2 Analogi Encapsulation.

Gambar 1.3. Encapsulation Model Sistem ATM pada Bank.

b. Inheritance

Dalam konsep object oriented, inheritance adalah suatu mekanisme yang membolehkan kita membuat atau menciptakan suatu objek baru (derived object/class) dari objek dasarnya (base object/class) disebut juga konsep parent-child. Objek anak (childI) mewarisi sifat dan kualitas yang dimiliki dari objek orangtua (parent). Contoh inheritance pada dunia nyata adalah makhluk hidup berjenis mamalia, diamana terdapat banyak sekali jenis makhluk hidup mamalia yang masing-masing memiliki karakteristik yang unik satu sama lain seperti pada ilustrasi berikut ini. Bahwa object mamalia memiliki turunan objek seperti kucing, anjing, dan paus.

Dengan inheritance maka akan mengurangi pemeliharaan, misalnya jika terjadi suatu perubahan pola perilaku, ciri-ciri atau bentuk pada makhluk hidup mamalia, maka secara otomatis objek anak akan menerima warisan perubahan itu dengan spesifikasi yang sama dengan objek parentnya. Contoh lain pada aplikasi komputer yaitu Inheritance pada model jendela (window), misalnya kita memiliki 4 buah jendela, apabila pemakai melakukan perubahan antarmuka (tampilan penampang) pada jendela, maka maka harus melakukan perubahan pada setiap jendela satu persatu. Akan berbeda apabila salah satu jendela menjadi parent dan 3 jendela yang lain menjadi child, maka dengan mengakses dan melakukan perubahan yang diinginkan pada jendela parent, maka akan secara otomatis jendela child akan melakukan perubahan yang sama.

c. Polymorphism.

Polymorphisme menggambarkan suatu kejadian/event dalam format yang berbeda baik bentuk, langkah-langkahnya maupun jenisnya. Pada dunia nyata bentuk sebuah polymorphisme seperti misalnya perintah “Bersuara !” maka masing-masing objek akan menghasilkan keluaran yang berbeda.

a. Orang akan bersuara “apa khabar”.

b. Kucing akan bersuara “ngeong”.

c. Burung akan bersuara “cuit cuit”.

Contoh lain suatu polymorphisme adalah sistem menggambar sebuah grafik atau bidang. Ketika seseorang ingin menggambarkan suatu gambar/grafik, apakah garis, lingkaran, atau kotak maka sistem akan memberikan perintah “gambarkan!”, dengan perintah yang sama setiap objek akan menghasilkan keluaran (output) yang berbeda-beda tergantung dengan jenis objek yang bersangkutan.

MBO pendahuluan

METODA BERORIENTASI OBJEK

Berorientasi Objek (Object Oriented) merupakan paradigma baru dalam rekayasa perangkat lunak yang memandang sistem sebagai sekumpulan objek-objek yang saling berinteraksi.

Metoda Berorientasi-Objek memberikan sekumpulan teknik untuk menganalisis, mendekomposisi dan memodularisasi arsitektur sistem perangkat lunak.

Sistem sendiri didefinisikan sebagai kumpulan dari beberapa elemen (modul) yang saling berhubungan (berinteraksi) untuk mencapai suatu tujuan/output (output disesuaikan dengan kebutuhan pengguna).

Sedangkan sistem yang berorientasi objek diurai kedalam sejumlah/sekumpulan obyek(konsep, abstrak, benda) dalam dunia nyata yang saling berkomunikasi dan melaksanakan sejumlah pelayanan secara desentralisasi.
Setiap obyek membungkus (encapsulate) sejumlah prosedur dan data yang berinteraksi dengan obyek lainnya melalui suatu pesan (message).

PEMBAHASAN

1.   Konsep Dasar

Konsep dasar dari Pemrograman Berorientasi Objek Pemrograman orientasi-objek menekankan konsep berikut:

Kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh 'class of dog' adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.

Objek - membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.

Abstraksi - Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari "pelaku" abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.

Enkapsulasi - Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi izin untuk mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.

Polimorfisme melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim. Contohnya, bila sebuah burung menerima pesan "gerak cepat", dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.

Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.