Unified Modeling Language
Dalam suatu proses pengembangan software, analisa dan rancangan
telah merupakan terminologi yang sangat tua. Pada saat masalah ditelusuri dan
spesifikasi dinegoisasikan, dapat dikatakan kita berada pada tahap rancangan.
Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah satu
tool / model untuk merancang pengembangan software yang berbasis object
oriented adalah UML.
Konsep Objek
Obyek dalam software
analysis & design adalah sesuatu berupa konsep, benda dan sesuatu
yang membedakannya dengan lingkungannya. Secara sederhana obyek adalah mobil,
manusia, alarm dan
lain-lainnya. Tapi obyek dapat pula merupakan sesuatu yang abstrak yang hidup
didalam sistem seperti tabel, database,
event, system messages.
Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh
sebuah mobil dikenali dari warnanya, bentuknya, sedangkan manusia dari
suaranya. Ciri-ciri ini yang akan membedakan obyek tersebut dari obyek lainnya.
Alasan mengapa saat ini pendekatan dalam pengembangan software
dengan object-oriented, pertama
adalah scalability dimana obyek
lebih mudah dipakai untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat
dipakai untuk permodelan sistem dinamis dan real time.
Teknik Dasar OOA/D (Object-Oriented
Analysis/Design)
Dalam dunia pemodelan, metodologi implementasi obyek walaupun
terikat kaidah-kaidah standar, namun teknik pemilihan obyek tidak terlepas pada
subyektifitas software analyst & designer. Beberapa obyek akan diabaikan
dan beberapa obyek menjadi perhatian untuk diimplementasikan di dalam sistem.
Hal ini sah-sah saja karena kenyataan bahwa suatu permasalahan sudah tentu
memiliki lebih dari satu solusi. Ada 3 (tiga) teknik/konsep dasar dalam OOA/D,
yaitu pemodulan (encapsulation),
penurunan (inheritance) dan polymorphism.
a. Pemodulan (Encapsulation)
Pada dunia nyata, seorang ibu rumah tangga menanak nasi dengan menggunakan rice cooker, ibu tersebut
menggunakannya hanya dengan menekan tombol. Tanpa harus tahu bagaimana proses
itu sebenarnya terjadi. Disini terdapat penyembunyian informasi milik rice cooker, sehingga tidak perlu
diketahui seorang ibu. Dengan demikian menanak nasi oleh si ibu menjadi sesuatu
yang menjadi dasar bagi konsep information
hiding.
b. Penurunan (Inheritance)
Obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedan.
Contoh dengan beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda.
Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus.
Walaupun demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi
sebagai obyek mobil, obyek ini dapat dikatakan sebagai obyek induk (parent). Sedangkan minibus dikatakan
sebagai obyek anak (child), hal
ini juga berarti semua operasi yang berlaku pada mobil berlaku juga pada
minibus.
c. Polymorphism
Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek
mobil yang sama, namun memiliki juga perbedaan. Misalnya suara truk lebih keras
dari pada minibus, hal ini juga berlaku pada obyek anak (child) melakukan metoda yang sama
dengan algoritma berbeda dari obyek induknya. Hal ini yang disebut polymorphism, teknik atau konsep
dasar lainnya adalah ruang lingkup / pembatasan. Artinya setiap obyek mempunyai
ruang lingkup kelas, atribut, dan metoda yang dibatasi.
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 cobakandan diaplikasikan antara 1989 hingga
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 metoda 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 Booch untuk membuat sebuah project pendekatan metoda yang
uniform/seragam dari masing-masing metoda mereka. Saat itu baru dikembangkan
draft metoda UML version 0.8 dan diselesaikan serta di release 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 di
pelihara 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 object-
oriented dan software component.
Pengenalan UML
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi.
Sebuah bahasa model adalah sebuah bahasa yang mempunyai vocabulary dan konsep
tatanan / aturan penulisan serta secara fisik mempresentasikan dari sebuah
sistem. Seperti halnya UML adalah sebuah bahasa standard untuk pengembangan
sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk
model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya
dibuat yang merupakan salah satu proses implementasi pengembangan software.
UML tidak hanya merupakan sebuah bahasa pemograman visual saja,
namun juga dapat secara langsing dihubungkan ke berbagai bagasa pemrograman,
seperti JAVA, C++, Visual Basic atau bahkan dihubungkan secara langsung kedalam
sebuah object-oriented database. Begitu juga mengenai pendokumentasian dapat
dilakukan seperti requirements, arsitektur, design, source code, project plan,
tests dan prototypes.
Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah
bahasa model, dan mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang
menyatakan bagaimana building block diletakkan
secara bersamaan, dan beberapa mekanisme umum (common).
Building blocks
3 (tiga) macam yang terdapat dalam building block adalah katagori
benda/things, hubungan, dan diagram. Benda/things adalah abstraksi yang pertama
dalam sebuah model, hubungan sebagai alat komunikasi dari benda- benda, dan
diagram sebagai kumpulan/group dari benda-benda/things.
a. Benda/Things
Adalah hal yang sangat mendasar dalam model UML, juga merupakan
bagian paling statik dari sebuah model, serta menjelaskan elemen-elemen lainnya
dari sebuah konsep dan atau fisik. Bentuk dari beberapa benda/thing adalah
sebagai berikut:
Pertama, adalah sebuah
kelas yang diuraikan sebagai sekelompok dari object yang mempunyai atribute,
operasi, hubungan yang semantik. Sebuah kelas mengimplementasikan 1 atau lebih
interfaces. Sebuah kelas dapat digambarkan sebagai sebuah persegi panjang, yang
mempunyai sebuah nama, atribute, dan metoda pengoperasiannya.
Kedua, yang
menggambarkan interface merupakan
sebuah antarmuka yang menghubungkan dan melayani antar kelas dan atau elemen. Interface/antarmuka mendefinisikan
sebuah set/kelompok dari spesifikasi pengoperasian, umumnya digambarkan dengan
sebuah lingkaran yang disertai dengan namanya. Sebuah antar-muka berdiri
sendiri dan umumnya merupakan pelengkap dari kelas atau komponen.
Ketiga, adalah collaboration yang didefinisikan
dengan interaksi dan sebuah kumpulan/kelompok dari kelas-kelas/elemen-elemen
yang bekerja secara bersama-sama. Collaborations
mempunyai struktura dan dimensi. Pemberian sebuah kelas memungkinkan
berpartisipasi didalam beberapa collaborations
dan digambarkan dengan sebuah elips dengan garis terpotong-potong.
Keempat, sebuah use case adalah rangkaian/uraian
sekelompok yang saling terkait dan membentuk sistem secara teratur yang
dilakukan atau diawasi oleh sebuah aktor. Use case digunakan untuk membentuk tingkah-laku benda/things dalam sebuah model serta di
realisasikan oleh sebuah collaboration. Umumnya use case digambarkan dengan sebuah elips dengan garis yang solid, biasanya mengandung nama.
Kelima, sebuah node
merupakan fisik dari elemen-elemen yang ada pada saat dijalankannya sebuah
sistem, contohnya adalaha sebuah komputer, umumnya mempunyai sedikitnya memory dan processor. Sekelompok komponen mungkin terletak pada sebuah node dan juga mungkin akan berpindah
dari node satu ke node lainnya. Umumnya node ini digambarkan seperti kubus
serta hanya mengandung namanya.
b. Hubungan/Relationship
Ada 4 macam hubungan didalam penggunaan UML, yaitu; dependency, association, generalization,
dan realization.
Pertama, sebuah dependency adalah hubungan semantik
antara dua benda/things yang mana sebuah benda berubah mengakibatkan benda
satunya akan berubah pula. Umumnya sebuah dependency digambarkan sebuah panah dengan garis terputus-putus.
Dependency
Kedua, sebuah association adalah hubungan antar
benda struktural yang terhubung diantara obyek. Kesatuan obyek yang terhubung
merupakan hubungan khusus, yang menggambarkan sebuah hubungan struktural
diantara seluruh atau sebagian. Umumnya assosiation digambarkan dengan sebuah
garis yang dilengkapi dengan sebuah label, nama, dan status hubungannya.
Ketiga, sebuah generalization adalah menggambarkan
hubungan khusus dalam obyek anak/child
yang menggantikan obyek parent /
induk . Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal struktur dan
tingkah lakunya kepada obyek induk. Digambarkan dengan garis panah.
Keempat, sebuah realization merupakan hubungan
semantik antara pengelompokkan yang menjamin adanya ikatan diantaranya.
Hubungan ini dapat diwujudkan diantara interface
dan kelas atau elements,
serta antara use cases dan collaborations.
c. Diagram
UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut aspek atau sudut pandang
tertentu. Diagram adalah yang menggambarkan permasalahan maupun solusi dari
permasalahan suatu model. UML mempunyai 9 diagram, yaitu use-case, class, object, state, sequence,
collaboration, activity, component, dan deployment diagram.
Pertama, use case diagram. Use case diagram menggambarkan fungsionalitas yang
diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat
sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah
interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan
tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan
sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang
berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu.
Use
case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah
sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk
semua feature yang ada pada sistem.
Sebuah use case dapat meng-include
fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara
umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use
case yang meng-include dieksekusi secara normal. Sebuah use case dapat
di-include oleh lebih dari satu use case lain, sehingga duplikasi
fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang
common.
Use Case Diagram
Kedua, class diagram. Class adalah sebuah spesifikasi yang jika
diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari
pengembangan dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk
memanipulasi keadaan tersebut
(metoda/fungsi).
Class diagram menggambarkan
struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain
seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga
area pokok, yaitu nama (dan stereotype), atribut
dan metoda. Tahap pengembangan
sistem perangkat lunak didalam UML meliputi analisis kebutuhan (requirement
analysis), analisis sistem (analysis),
desain (design), implementasi (implementation) dan testing.
Class Diagram
Ketiga, object diagram. Object diagram adalah
diagram yang menunjukkan pandangan yang lengkap atau sebagian dari struktur
sebuah sistem yang dimodelkan pada waktu tertentu.
Object diagram berfokus pada beberapa set contoh objek dan atribut
tertentu dan hubungan antar contoh. Object diagram memberikan wawasan tentang
bagaimana pandangan sewenang-wenang dari suatu sistem diharapkan berkembang
dari waktu ke waktu. Object diagram lebih konkret dari diagram kelas dan sering
digunakan untuk memberikan contoh atau bertindak sebagai kasus uji untuk
diagram kelas.
Object Diagram
Keempat, state diagram. State diagram adalah diagram untuk menggambarkan behavior, yaitu perubahan state di suatu class berdasarkan event dan message yang dikirimkan dan diterima oleh class tersebut. Setiap state diagram
hanya boleh memiliki satu start state
(initial state) dan boleh memiliki satu atau lebih dari satu stop states (final state).
State Diagram
Kelima, sequence diagram. Sequence
Diagram adalah suatu diagram yang memperlihatkan/menampilkan
interaksi-interaksi antar objek di dalam sistem yang disusun pada sebuah urutan
atau rangkaian waktu. Interaksi antar objek tersebut termasuk pengguna, display, dan sebagainya berupa pesan/message. Sequence Diagram digunakan
untuk menggambarkan skrenario atau rangkaian langkah-langkah yang dilakukan
sebagai sebuah respon dari suatu kejadian/even untuk menghasilkan output
tertentu. Sequence Diagram diawali dari apa yang me-trigger aktivitas tersebut, proses dan perubahan apa saja yang
terjadi secara internal dan output
apa yang dihasilkan.
Keenam, collaboration diagram. Collaboration
Diagram adalah suatu diagram yang memperlihatkan/menampilkan pengorganisasian
interaksi yang terdapat disekitar objek (seperti halnya sequence diagram) dan hubungannya terhadap yang lainnya.
Collaboration Diagram lebih menekankan kepada peran setiap objek dan bukan pada
waktu penyampaian pesan/message.
Collaboration Diagram
Ketujuh, activity diagram. Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang
sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin
terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat
menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state
adalah action dan sebagian besar transisi di-trigger oleh selesainya state
sebelumnya (internal processing). Oleh karena itu activity diagram tidak
menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem)
secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur
aktivitas dari level atas secara umum.
Kedelapan, component diagram. Component
diagram berfungsi untuk menggambarkan komponen run-time dan executable yang
dibuat untuk sistem. Komponen saling berelasi menggunakan depedecy relation
(Hubungan ketergantungan, yang ditandai dengan garis putus-putus). Komponen
run-time memperlihatkan pengelompokan kelas untuk run-time library seperti Java
Applet, Active-X Component dan Dynamic Libraries. Komponen executable
memperlihatkan interface dan memanggil dependencies beberapa executable.
Interface kelas diperlihatkan seperti lollypop.
Kesembilan, deployment diagram. Deployment Diagram
memperlihatkan konfigurasi pada jalannya proses run-time elements dan
proses software yang ada pada diagram. Run-time elements menggambarkan node
yang berkoneksi menandakan adanya komunikasi diantaranya. Diagram ini membantu
tim untuk mengerti sistem topology.
Deployment Diagram
Perbedaan
UML dan DFD
Data Flow Diagram (DFD)
adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus
dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem
secara logika, tersruktur dan jelas. DFD merupakan alat bantu dalam
menggambarkan atau menjelaskan sistem yang sedang berjalan logis.
StarUML dengan DFD keduanya berkaitan tetapi berbeda. StarUML merupakan
alat yang digunakan untuk memodelkan suatu sistem/software, sedangkan DFD
merupakan salah satu dari model yang terdapat di dalam StarUML.
Sumber :
Web StarUML
Wikipedia
