1. Pendahuluan
Teknologi rancang bangun perangkat lunak telah berkembang pesat, dari peran-cangan strukturprosedural berbasis fungsional menuju perancangan berorientasi objek yang didukung oleh perkembangan visual modeling dengan implementasi pemrograman berbasis/berorientasi-objek. Meyer (1997) menyatakan bahwa rancang bangun berorientasi-objek merupakan komplemen dan dalam banyak kasus menggantikan kedudukan rancang bangun terstruktur sebagai teknologi tinggi yang bagus (“good”). Seiring dengan per-kembangan itu literatur dan alat bantu (case tool) untuk rancang bangun ber-orientasi-objek juga telah banyak di rilis para pakar teknologi objek-oriented. Dengan prasarana yang tersedia, para desainer perangkat lunak diharapkan dapat “meninggalkan” kerumitan user inter-face, misalnya penanganan menu, penga-turan frame untuk tampilan, ataupun penanganan event driven, klik button, dan lain-lain. Disainer dapat lebih berkonsentrasi pada penanganan persoalan utama (problem domain).
Di sisi pemrograman, programmer tidak lagi diharapkan untuk menuliskan program record per record, tetapi diharapkan menggunakan program-program (komponen) yang sudah ada (reuse), dapat dikatakan bahwa pemrograman mengarah ke ‘perakitan pogram’. Namun demikian ke-mudahan yang diberikan bahasa pemro-graman berorientasi-objek khususnya visual programing tidak otomatis menjamin bahwa produk yang dihasilkan dari pemrograman merupakan perangkat lunak yang objek-oriented. Booch (1998) pada journal (whitepaper) Rational Rose secara implisit menyatakan bahwa aplikasi/software berorientasi- objek bersifat arsitektur driven, hal ini berarti objek oriented atau tidaknya software yang telah dibuat sangat tergantung pada disain rancang bangun atau arsitek-turnya. Oleh karena itu proses pengem-bangan perangkat lunak akan menentukan apakah perangkat lunak yang dihasilkan objekoriented atau bukan.
Eriksson dan Panker (1998), memberikan pandangan bahwa model perangkat lunak objekoriented, jika disusun dengan benar, akan mudah dipahami, diubah, dikembangkan, dilakukan verifikasi dan validasi. Jika dilakukan dengan benar, sistem yang dibangun dengan menggunakan teknologi objekoriented akan fleksibel untuk diubah, mempunyai arsitektur yang terdefinisi dengan baik dan memungkinkan untuk membentuk reusable component. Jauh sebelumnya Taylor (1992) menyatakan bahwa membangun software menggunaan pendekatan teknologi objek memberikan beberapa keuntungan, antara lain: memungkinkan penggunaan kembali objek yang ada (reusable), memungkinkan software yang baru dengan konstruksi yang lebih besar, software berorientasi objek secara umum lebih mudah dimodifikasi dan dirawat karena sebuah objek dapat dimodifikasi tanpa banyak berpengaruh pada objek yang lain.
Unified Modeling Language (UML) merupakan alat bantu, bahasa pemodelan yang dapat digunakan untuk rancang bangun berorientsi-objek. UML dapat digunakan untuk spesifikasi, visualisasi dan dokumentasi sistem pada fase pengembangan (Eriksson dan Panker,1998). Walaupun banyak alat bantu pemodelan berorientasi-objek lain, UML dapat dikatakan merupakan alat bantu standar dalam bahasa pemodelan. Hal ini terbukti dengan diterimanya UML sebagai standar oleh Object Management Group (OMG), konsorsium terbesar dibidang bisnis-objek, sehingga UML banyak diadop-si dan digunakan oleh banyak produsen perangkat lunak. UML (Rational Rose 2000) menyediakan implementasi desain pada pemrograman C++, Java, CORBA, dan Visual Basic. Disamping itu UML menyedia-kan tool revers engineering, untuk mem-bentuk model (kelas dan komponen) dari software yang telah jadi.
2. Unified Modeling Language (UML)
Unified Modeling Language (UML) adalah alat bantu (tool) untuk pemodelan sistem, “UML adalah bahasa yang dapat digunakan untuk spesifikasi, visualisasi, dan dokumentasi sistem objek-oriented software pada fase pengembangan. UML merupakan unifikasi dari metode Booch, OMT, dan notasi Objectory, serta ide-ide terbaik metodologi lainnya seperti terlihat pada Gambar 1. Dengan menyatukan notasi metode-metode objek oriented tersebut, UML merupakan standar dasar dalam bidang analisis dan desain berorientasi-objek” (Quatrani, 1998).
Gambar 1. Unifikasi berbagai metode
Pengembangan objek kedalam UML
3. View dan Diagram UML
View adalah jendela (window) yang merupakan aspek pandang UML terhadap sistem. Sebuah sistem harus dijelaskan dengan sejumlah aspek/pandangan yang berbeda, misalnya aspek fungsional (struktur statik dan interaksi dinamik), aspek non-fungsional (timing requirement, reliability, deployment), dan aspek organisasional (pengorganisasian pekerjaan, mapping ke kode, dan modul). Sistem dijelaskan oleh sejumlah view, dimana masing-masing view merupakan proyeksi dari sistem secara komplit yang memperlihatkan aspek tertentu dari sistem. UML memperkenalkan lima buah view untuk memandang sistem yaitu: Use-Case View, Logical View, Component view, Deployment View dan Concurrency View (Eriksson dan Penker, 1998). Booch (1998) menyebut view ini sebagai “Arsitektur 4+1” dan menyebut Concurrency View sebagai Process View.
1. Use-Case View.
Untuk menampilkan fungsifungsi dari sistem berkaitan dengan aktor eksternal. Aktor yang ber-interaksi dengan sistem dapat berupa seorang user atau sistem lainnya. Use-case view ditujukan untuk para cus-tomer, designer, developer, dan tester. Use-case view merupakan bagian sentral dari view karena isinya menjadi pengen-dali view yang lain. Tujuan akhir dari sebuah sistem adalah untuk menyedia-kan fungsi-fungsi yang dijelaskan dalam use-case view, karena itu use-case view mempengaruhi seluruh view lainnya. Use-case View juga digunakan untuk validasi dan verifikasi sistem
2. Logical View.
Untuk menampilkan bagaimana fungsi-fungsi didisain didalam sistem , dalam kaitannya dengan struktur statik dan perilaku dinamik sistem. Logical view menjelaskan bagaimana fungsi-fungsi sistem di sediakan, terutama berguna bagi para designer dan developer. Berbeda dengan use case view, logical view melihat bagian dalam dari sistem. Sistem dijelaskan dengan struktur statik (kelas, objek, dan relasi) dan kolaborasi dinamik yang terjadi ketika objek-objek mengirim pesan satu sama lain. Struktur statik di visualisasikan dalam diagram kelas dan objek, sedang model dinamiknya divisualisasi dalam diagram state, diagram sekuen, diagram kola-borasi dan diagram aktivity.
3. Component View.
Untuk menampilkan pengorganisasian program (code) dari komponen code, menjelaskan implementasi dari modulmodul yang tersedia dan dependensinya. Component View terutama untuk para pengembang, view berisi diagram komponen.
4. Concurrency/Process View.
Untuk menampilkan concurrency di dalam sistem, khususnya pada persoalan yang berhubungan dengan komunikasi dan sinkronisasi yang muncul dalam sistem concurrent. Concurrency/Prosess view ditujukan bagi para pengembang dan integrator sistem, berisi diagram dinamik (state, sekuen, kolaborasi, dan aktivity) dan diagram implementasi (diagram komponen dan deployment).
Tabel 1. Penempatan diagram dalam view UML
5. Deployment View. Memperlihatkan deployment sistem pada arsitektur fisik dengan komputer dan piranti pendukung yang diperkenalkan sebagai nodes. Deploymen view ditujukan bagi pengembang, integrator, dan tester, isi view berupa diagram deployment. View ini juga mencakup mapping yang memperlihatkan bagaimana komponen-komponen di-deployment pada arsitektur fisik; misalnya program atau objek yang mana di eksekusi pada komputer tertentu. Diagram adalah visualisasi grafik yang memperlihatkan susunan dari simbol-simbol elemen yang disusun untuk menggambarkan bagian atau aspek tertentu dari sistem. Sebuah model sistem secara tipikal mem-punyai beberapa diagram. Sebuah diagram adalah bagian spesifik dari view, apabila digambarkan akan mengambil tempat pada view tertentu. Beberapa jenis diagram dapat menjadi bagian dari beberapa view, tergantung pada isi diagram. UML memperkenalkan sembilan macam diagram yaitu: diagram Use Case, Kelas, Objek, State, Sekuen, kolaborasi, Aktivity, Kom-ponen dan diagram Deployment. Tabel 1 memperlihatkan penempatan diagram dalam view UML.
4. Tahap Pengembangan Perangkat Lunak
Tahap pengembangan sistem perangkat lunak didalam UML meliputi: Analisis Kebutuhan (Requirement Analysis), Analisis Sistem (Analysis), Desain (Design), Implementasi ( Implementation) dan Testing.
1. Analisis Kebutuhan: UML menggunakan Use cases untuk menangkap kebutuhan customer/user. Melalui Use cases aktor luar yang berinteraksi dengan sistem dimodelkan bersama dengan fungsi-fungsi yang mereka perlukan dari sistem (use cases). Aktor dan use cases dihubungkan dengan suatu relasi (relationship). Actor dan use cases ditampilkan dalam bentuk diagram beserta dokumentasinya pada view diagram Use case. Dokumentasi use cases dalam bentuk text diberikan secara terpisah (file) untuk memperjelas use cases.
2. Analisis sistem: Fase analisis konsen dengan abstraksi primer (kelas dan objek) dan mekanisme yang muncul dalam problem domain. Kelas-kelas diidentifikasi bersama dengan relasinya satu sama lain, dan ditampilkan pada diagram kelas. Kolaborasi antar kelas untuk mengerjakan use case juga dijelaskan melalui model dinamik UML. Pada fase analisis ini hanya kelas-kelas dalam problem domain yang dimodelkan, bukan kelaskelas implementasi teknik.
3. Desain: Pada tahap desain hasil analisis didetailkan untuk solusi teknik. Kelas-kelas baru ditambahkan untuk menyediakan infrastruktur teknik: user interface, penanganan database untuk menyimpan objek kedalam database, komunikasi dengan sistem lain, interfacing dengan peralatan dalam sistem ditambahkan.
4. Implementasi/programming: Pada tahap programming kelas-kelas yang dibentuk pada tahap desain dikonversi menjadi code sesungguhnya dalam bahasa pemrograman objek-oriented melalui proses generate. Hasil generate berupa skeleton dari program. Selanjutnya menjadi tugas programmer untuk menyelesaikan program hasil generate. Editing yang dilakukan oleh programmer tidak akan di dihapus (ditimpa) saat model di generate ulang.
5. Testing: Testing terhadap sistem software biasanya berupa tes unit, tes integrasi, tes sistem, dan tes acceptance. Tes unit adalah tes terhadap kelas individual atau terhadap sekelompok kelas, biasanya dilakukan oleh programmer. Tes integrasi mengintegrasikan komponen dan kelaskelas dalam rangka verifikasi. Tes sistem memandang sistem sebagai kotak hitam (black box) dalam rangka validasi bahwa sistem berfungsi sesuai dengan harapan end user. Tes acceptance dilakukan oleh customer untuk verifikasi bahwa sistem sesuai dengan kebutuhan, sama seperti tes sistem. Test unit menggunakan diagram kelas dan spesifikasi kelas, test integrasi menggunakan diagram komponen dan diagram kolaborasi, dan tes sistem menggunakan diagram use-case untuk melakukan validasi.
5. Model Desain dan Implementasi
Model desain (diagram kelas, komponen, deployment) ditampilkan dalam view-view UML seperti telah dibicarakan diatas. Sedangkan implementasi desain dila-kukan dengan ‘generate’ program dari diagram kelas atau diagram komponen ke bahasa pemrograman yang diinginkan. Bahasa pemrogaraman yang bisa digunakan diantaranya Java, C++, dan Visual Basic.
6. Penutup
Secara umum proses pengembangan perangkat lunak mencakup lima tahap, yaitu: analisis kebutuhan, analisis sistem, desain, implementasi dan testing. UML menye-diakan notasi dan diagram untuk menjelaskan masing-masing tahap proses pengembangan. Pada tahap analisis kebutuhan, UML mengunakan model Use Case untuk menangkap kebutuhan Customer/ User. Pada tahap analisis sistem, UML menyediakan abstraksi untuk pembentukan klas serta diagram klas, menggunakan objek-objek yang berkolaborasi mengerjakan use case melalui model dinamik diagram sekuen dan diagram kolaborasi. Pada tahap desain, UML menyediakan detail desain spesifikasi klasklas/ komponen-komponen hasil analisis untuk solusi teknik. Pada tahap implementasi, UML menyediakan fasilitas untuk generate program (code) dari kelaskelas atau komponen-komponen detail desain. Sedangkan pada tahap testing, diagram dan spesifikasi klas dapat digunakan untuk verifikasi/tes unit, diagram komponen dan kolaborasi untuk tes integrasi dan use case untuk tes sistem.
Sumber :
JURNAL TEKNIK ELEKTRO EMITOR Vol. 2, No. 1, Maret 2002
Nurokhim
P2PLR – Badan Tenaga Nuklir Nasional
Puspiptek Serpong Tangerang
Ratnasari Nur Rohmah
Teknik Elektro Universitas Muhammadiyah Surakarta
Adesta2008's UML 