Nurokhim, Case Tool Pengembangan Perangkat Lunak Berorientasi Objek Menggunakan UML

Case Tool Pengembangan Perangkat Lunak Berorientasi-objek

menggunakan Unified Modeling Language (UML)

Nurokhim
P2PLR - Badan Tenaga Nuklir Nasional
Puspiptek Serpong Tangerang

Ratnasari Nur Rohmah

Teknik Elektro Universitas Muhammadiyah Surakarta

Abstrak
Metode objek-oriented banyak digunakan dalam pengembangan perangkat
lunak. Unified Modeling Language (UML) adalah bahasa yang dapat digunakan
untuk spesifikasi, visualisasi dan dokumentasi sistem software pada fase
pengembangan. UML merupakan unifikasi metode-metode Booch, OMT dan
Objectory serta beberapa metode lainnya, de facto UML merupakan standar bidang
analisis dan desain sistem objek-oriented. View adalah jendela (window) yang
merupakan aspek pandang UML terhadap 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. Tahap pengembangan sistem perang kat lunak didalam UML meliputi:
Analisis Kebutuhan (Requirement Analysis), Analisis Sistem (Analysis), Desain
(Design), Implementasi (Implementation) dan Testing.

Kata Kunci: Unified Modeling Languge, orientasi-objek.

diharapkan menggunakan program-program

1. Pendahuluan
Teknologi rancang bangun perangkat lunak telah
berkembang pesat, dari peran-cangan struktur-
prosedural berbasis fungsi-onal menuju perancangan
berorientasi-objek yang didukung oleh perkembangan
visual modeling dengan implementasi pemro-graman
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 pena-
nganan 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
(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 ber-
orientasi-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 objek-
oriented atau bukan.
Eriksson dan Panker (1998), memberikan
pandangan bahwa model perangkat lunak objek-
oriented, jika disusun dengan benar, akan mudah
dipahami, diubah, dikembangkan, dilakukan verifikasi
dan validasi. Jika dilakukan dengan benar, sistem yang
dibangun dengan menggunakan teknologi objek-
oriented akan fleksibel untuk diubah, mempunyai

39
JURNAL TEKNIK ELEKTRO EMITOR Vol. 2, No. 1, Maret 2002
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 dokumen-
tasi 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 kedalamUML.
40
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 fungsi-
fungsi 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 modul-
modul 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)
 Nurokhim, Case Tool Pengembangan Perangkat Lunak Berorientasi Objek Menggunakan UML
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 pe-
ngembang, 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 kelas-
kelas 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 pro-
gramming 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 kelas-
kelas 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,
41
JURNAL TEKNIK ELEKTRO EMITOR Vol. 2, No. 1, Maret 2002

menggunakan objek-objek yang berkolaborasi
mengerjakan use case melalui model dinamik diagram
sekuen dan diagram kolaborasi. Pada tahap desain,
UML menyediakan detail desain spesifikasi klas-
klas/komponen-komponen hasil analisis untuk solusi
teknik. Pada tahap implementasi, UML menyediakan
fasilitas untuk generate program (code) dari kelas-
kelas 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.

Daftar Pustaka
[1] Booch G. (1998), Architectural Patterns, whitepapers, Rational Rose, www.rational.com.
[2] Eriksson H-E and Penker M. (1998), UML Toolkit, John Wiley & Son Inc.
[3] Heinckiens Peter M. (1998), Building Scalable Database Applications, Object-Oriented Design,
Architectures, and Implementations, Addison-Weslay Longman, Inc.
[4] Meyer B. (1997), Object-oriented Software construction, 2nd, prentice Hall PTR Upper Saddle River
New Jersey 07458.
[5] Nurokhim (2001), Penggunaan Unified Modeling Languagepada Rancang Bangun Sistem Inventori
Bahan Radioaktif. Tesis Magister Teknik Informatika Institut teknologi Sepuluh November Surabaya.
[6] Priestley M. (1997), Practical Object-Oriented design, The McGraw-Hill Company, USA.
[7] Rumbough J., et. al. (1991), Object-Oriented Modeling and Design, prentice-Hall, Englewood Cliffs,
New Jersey.
[8] Quatrani Terry (1998), Visual Modeling With Rational Rose and UML, Addison wesley Longman, Inc.
[9] Rational Rose (1998), Integrating Object and Relational Technologies, whitepapers,
www.rational.com.
[10] Rational Rose (1998), A Rational Approach to Software Development Using Rational Rose 4.0,
whitepapers, www.rational.com.
[11] Richter Charles (1999), Designing Flexible Object-Oriented System with UML, Macmillan Technical
Publishing, 201 West 103rd street, Indianapolis, IN 46290 USA.

42