Sejarah Singkat UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah menjadi standar dalam
industri untuk menentukan, visualisasi, merancang dan mendokumentasikan artifact dari sistem
software, untuk memodelkan bisnis dan sistem non software lainnya. UML merupakan suatu
kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan sistem yang besar dan
kompleks.

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, 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, metodologi Coad , metodologi OOSE, metodologi OMT, metodologi Shlaer-
Mellor, metodologi Wirfs-Brock, dan sebagainya. 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 bekerja
sama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh
yang boleh dikatakan 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. Sejak saat itulah UML telah menjelma menjadi
standar bahasa pemodelan untuk aplikasi berorientasi objek.

Object Management Group, Inc. (OMG) adalah sebuah organisasi international yang dibentuk
pada 1989, didukung lebih dari 800 anggota, terdiri dari perusahaan sistem informasi, software
developer, dan pada user system komputer. organisasi ini salah satunya bertugas membuat
spesifikasi “manajemen objek” untuk menetapkan kerangka bersama dalam rekayasa software.
Sasaran OMG adalah membantu perkembangan object-oriented technology dan mengarahkannya
dengan mendirikan Object Management Architecture (OMA). OMA menentukan infrastruktur
konseptual yang didasarkan pada seluruh spesifikasi yang dikeluarkan OMG. OMG kemudian
mengeluarkan UML, dimana dengan adanya UML ini diharapkan dapat mengurangi kekacauan
dalam bahasa pemodelan yang selama ini terjadi dalam lingkungan industri. UML diharapkan juga
dapat menjawab masalah penotasian dan mekanisme tukar menukar model yang terjadi selama ini.
Pengertian UML

Unified Modeling Language ( UML ) adalah “suatu bahasa yang telah menjadi standar dalam
industri untuk merancang, visualisasi dan mendokumentasikan sistem perangkat lunak”[1]. Dalam
pengertian lain UML merupakan graphical language untuk specifying, visualizing, construction,
dan documenting hal-hal yang ada dalam sistem perangkat lunak. UML diaplikasikan untuk
penyelesaian masalah dengan menggunakan konsep object oriented. Siapapun yang akan
mempelajari UML harus mengenal prinsip-prinsip yang digunakan dalam penyelesaian masalah
object oriented, dimana semuanya dimulai dengan pembuatan model. Sebuah model adalah
abstraksi dari sebuah masalah. Domain merupakan lingkungan nyata dimana sebuah masalah
datang. Model terdiri dari objek-objek yang berinteraksi dengan mengirim message satu sama lain.
Objek memiliki hal-hal yang mereka ketahui (attrribute) dan hal-hal yang dapat mereka lakukan
(behavior atau operation). Nilai dari atribut-atribut sebuah objek digambarkan dalam bentuk state.
Class merupakan ‘blueprints’ dari objek. Class membungkus atribut-atribut (data) dan behavior
(method dan fungsi) dalam sebuah entiti tunggal yang jelas.

Tujuan UML :

a. Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk
mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.

b. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses
rekayasa.

c. Menyatukan praktik-praktik terbaik yang terdapat dalam pemodelan.

Artifak UML

UML menyediakan beberapa notasi dan artifact standar yang bisa digunakan sebagai alat
komunikasi bagi para pelaku dalam proses analisis dan desain. Artifact didalam UML
didefinisikan sebagai informasi dalam bentuk yang digunakan atau dihasilkan dalam proses
pengembangan perangkat. Contohnya adalah source code yang dihasilkan oleh proses
Pemrograman yang harus diperhatikan untuk menjaga konsistensi antar artifact selama proses
analisis dan desain adalah bahwa setiap perubahan yang terjadi pada satu artifact harus juga
dilakukan pada atifact sebelumnya.

Untuk membuat suatu model, UML memiliki diagram grafis sebagai berikut :

• use case diagram

Use-case diagram merupakan suatu bentuk diagram yang

menggambarkan fungsi-fungsi yang diharapkan dari
sebuah sistem yang dirancang. Dalam Use-case diagram
penekanannya adalah “apa” yag diperbuat oleh sistem, dan
bukan “bagaimana”. Sebuah use-case akan
merepresentasikan sebuah interaksi antara pelaku atau
actor dengan sistem. Use-case diagram yang digunakan
dalam merancang suatu sistem dapat sangat membantu
pada saat kita menyusun requirement sebuah sistem,
mengomunikasikannya dengan klien, dan merancang pengujian untuk semua fitur yang terdapat
dalam sistem. Dalam suatu sistem aplikasi database, use-case diagram sangat membantu
requierement apa saja yang diperlukan.

Use case(s) diagram menjelaskan manfaat sistem jika dilihat menurut pandangan orang yang
berada di luar sistem (actor). Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan
bagaimana sistem berinteraksi dengan dunia luar. Pada tahap analisa, Use case(s) Diagram sangat
berperan untuk menemukan requirement-requirement sistem dan untuk memahami bagaimana
sistem seharusnya bekerja. Dalam sebuah model mungkin terdapat satu atau beberapa use case(s)
diagram.Sebuah use case(s) diagram melukiskan :

Actor

Aktor merupakan istilah yang digunakan untuk menggambarkan pengguna aplikasi. Aktor bisa
berupa orang, hardware, atau sistem informasi lai yang berinteraksi dengan use.

Use case

Use case menggambarkan perilaku software aplikasi, termasuk didalamnya interaksi antara aktor
dengan software aplikasi.Use case dibuat berdasarkan proses-proses yang dilakukan untuk
kepentingan aktor untuk menggambarkan apa yang dikerjakan oleh aplikasi, bukan bagaimana
aplikasi mengerjakannya (logical)

Association

Asosiasi merupakan komunikasi antara aktor dengan use case, digambarkan sebagai sebuah garis
lurus tanpa putus antara aktor dan use case. Gambar di bawah melukiskan asosiasi (hubungan)
antara aktor admin dalam melakukan proses setup (usecase setup)

Extend

Extend digunakan untuk menggambarkan hubungan antar use case yang menunjukkan bahwa satu
use case merupakan fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu dipenuhi.

Include

Hubungan includemenggambarkan bahwa satu use case seluruhnya meliputi fungsionalitas dari
use case lainnya.
Setiap use case pada use case diagram dijelaskan secara detail di use case specification dengan
format:

1. Nama use case : Nama use case untuk setiap simbol elips yang ada.

2. Aktor yg terlibat : Aktor yang terlibat di dalam use case.

3. Purpose : Tujuan use case

4. Description : Deskripsi singkat use case

5. Type : Tipe use case

6. Pre-condition : Kondisi atau syarat awal sebelum use case dilakukan.

7. Post condition : Kondisi setelah use case dilakukan.

8. Typical course of event : Penjelasan interaksi aktor dan sistem dalam use case.

Contoh use case diagram :

• class diagram
Sebuah Class Diagram menunjukkan struktur yang statis dari beberapa class dalam suatu sistem.
Class-class merepresentasikan suatu keadaan (atribut/properti) dan yang akan dikerjakan oleh
sistem (metoda/fungsi)

Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut

3. Metoda
Atribut dan metoda dalam class diagram dapat memiliki salah satu sifat seperti berikut di bawah
ini :

• Private, hanya dapat diakses oleh class itu sendiri.

• Protected, hanya dapat diakses oleh class itu sendiri dan turunan dari class tersebut.

• Public, dapat diakses oleh class selain dari class yang bersangkutan.

Class dapat direpresentasikan dalam sebuah interface atau sebaliknya merupakan implementasi
dari sebuah interface yang berupa class abstrak yang hanya tidak memiliki attribute dan hanya
memiliki metoda.
Berikut merupakan bentuk class diagram secara umum :

Class diagram digunakan untuk memvisualisasikan struktur kelas-kelas dari suatu sistem. Ada tiga
jenis relasi penting yang menghubungkan obyek, yaitu:

1. Association

Association merupakan suatu relationship antar dua atau lebih classifier yang menyangkut
hubungan antar instance. Jenis hubungan association digambarkan pada gambar di bawah ini.

2. Agregation

Agregation merupakan bentuk lain dari association yang menerangkan hubungan whole-part
antara agregate class (whole) dan component part. Jenis hubungan agregation digambarkan pada
di bawah ini.

3. Generalization

Generalization merupakan sebuah taxonomic relationship antara class yang lebih umum dengan
class yang lebih khusus. Jenis hubungan generalization digambarkan pada gambar di bawah ini.

• statechart diagram
State Diagram mengambarkan seluruh state yang memungkinkan yang mana obyek-obyek dalam
class dapat dimiliki dan kejadian-kejadian yang menyebabkan state berubah. Perubahan dalam
suatu state disebut juga transisi (transition). Suatu transisi juga dapat memiliki sebuah aksi yang
dihubungkan pada state, lebih spesifik apa yang harus dilakukan dalam hubungannya dengan
transisi state.
 • activity diagram
Diagram ini memodelkan alur kerja (workflow)sebuah proses bisnis dan urutan aktivitas dalam
suatu proses untuk dapat memahami proses secara keseluruhan. Activity diagram juga sangat
berguna ketika ingin menggambarkan perilaku pararel atau menjelaskan bagaimana prilaku dalam
berbagai use case berinteraksi. Sebuah Activity Diagram menunjukkan suatu alur kegiatan secara
berurutan. Activity Diagram digunakan untuk mendiskripsikan kegiatan-kegiatan dalam sebuah
operasi meskipun juga dapat digunakan untuk mendeskripsikan alur kegiatan yang lainnya seperti
use case atau suatu interaksi.

• sequence diagram
Sequence Diagram merupakan diagram yang mengambarkan kolaborasi yang dinamis antara
obyek satu dengan yang lain. Kolaborasi

ditunjukkan dengan adanya interaksi antar obyek di dalam dan di sekitar sistem yang berupa pesan
atau instruksi yang berurutan.

Sequence diagram umumnya digunakan untuk menggambarkan suatu skenario atau urutan
langkah-langkah yang dilakukan baik oleh actor maupun sistem yang merupakan respon dari
sebuah kejadian untuk mendapatkan hasil atau output.

Sebuah sequence diagram merupakan gambaran secara grafis dari sebuah skenario yang
menunjukkan interaksi obyek dalam sebuah urutan waktu – apa yang terjadi pertama kali dan apa
yang terjadi berikutnya. Diagram ini secara khusus berasosiasi dengan use case. Sequence diagram
memperlihatkan tahap demi tahap apa yang seharusnya dilakukan untuk menghasilkan sesuatu di
dalam use case. Diagram ini sangat diperlukan pada tahap analisis atau tahap awal desain sistem.

• collaboration diagram
Sebuah collaboration diagram menunjukkan kolaborasi yang dinamis yang mirip dengan sequence
diagram. Collaboration diagram digambarkan sebagai sebuah obiject diagram dimana sejumlah
obyek ditunjukkan disekitarnya dengan hubungan-hubungannya.
 • component diagram
Component Diagram menunjukkan struktur dan hubungan antar komponen software termasuk
ketergantungan (dependency) diantara komponen-komponen tersebut.

Komponen pada piranti lunak adalah berupa modul-modul yang berisikan code, baik library
maupun executable. Umumnya komponen yang terbentuk dari beberapa class dan/atau package,
atau juga dapat dari komponen-komponen yang lebih kecil.

• deployment diagram
Deployment Diagram menunjukkan arsitektur fisik pada hardware dan software pada suatu sistem
yang dirancang. Deployment diagram juga dapat menunjukkan perngkat-perangkat dan nodes
diantara hubungan yang dimilikinya antar komponen.

Diagram-diagram tersebut diberi nama berdasarkan sudut pandang yang berbeda-beda terhadap
sistem dalam proses analisis atau rekayasa.

Dibuatnya berbagai jenis diagram diatas karena :

o Setiap sistem yang kompleks selalu paling baik jika didekati melalui himpunan berbagai
sudut pandang yang kecil yang satu sama lain hampir saling bebas (independent). Sudut
pandang tunggal senantiasa tidak mencukupi untuk melihat sistem yang besar dan
kompleks.

o Diagram yang berbeda-beda tersebut dapat menyatakan tingkatan yang berbeda-beda

dalam proses rekayasa.

o Diagram-diagram tersebut dibuat agar model yang dibuat semakin mendekati realitas.
Semantik Dalam UML
OMG telah menetapkan semantik (makna istilah) semua notasi UML dalam model struktural dan
model behavior. Model struktural (model statis), menekankan stuktur obyek dalam sebuah sistem,
menyangkut kelas-kelas, interface, atribut dan hubungan antar komponen. Model behavioral
(model dinamis), menekankan perilaku obyek dalam sebuah sistem, termasuk metode, interaksi,
kolaborasi dan state history.

Cakupan UML
Pertama, UML menggabungkan konsep Booch, OMT dan OOSE, sehingga UML merupakan suatu
bahasa pemodelan tunggal yang umum dan digunakan secara luas oleh para user ketiga metode
tersebut dan bahkan para user metode lainnya.

Kedua, UML menekankan pada apa yang dapat dikerjakan dengan metode-meode tersebut.

Ketiga, UML berfokus pada suatu bahasa pemodelan standar, bahkan pada proses standar.
Meskipun UML harus diaplikasikan dalam konteks sebuah proses, dari pengalaman, bahwa
organisasi dan masalah yang berbeda juga memerlukan proses yang berbeda pula.

UML tidak mencakup :

� Bahasa Pemrograman UML adalah bahasa pemodelan visual, bukan dimaksudkan untuk
menjadi suatu bahasa pemrograman visual, tetapi UML memberikan arah untuk bergerak kearah
kode.

� Tool (software aplikasi) pemodelan

Membuat standar sebuah bahasa diperlukan oleh tool-tool dan proses. UML mendefinisikan
semantik dan notasi, bukan sebuah tool. Contoh tool yang menggunakan UML sebagai bahasanya
adalah Rational Rose dan Enterprise Architect.

� Proses rekayasa
UML digunakan sebagai bahasa dalam proyek dengan proses yang berbeda-beda. UML bebas dari
proses dan mendefinisikan sebuah proses standar bukan tujuan UML atau RFP dari OMG. Dalam
pembahasan ini kita akan menggunakan sebuah proses yang dikeluarkan Rational Software, yaitu
Rational Unified Process (RUP)

Notasi Dalam UML

Actor

Actor menggambarkan segala pengguna software aplikasi (user). Actor memberikan suatu
gambaran jelas tentang apa yang harus dikerjakan software aplikasi. Sebagai contoh sebuah actor
dapat memberikan input kedalam dan menerima informasi dari software aplikasi, perlu dicatat
bahwa sebuah actor berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case.
Sebuah actor mungkin seorang manusia, satu device, hardware atau sistem informasi lainnya.

Use Case
Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai suatu
tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case hanya menjelaskan apa yang
dilakukan oleh actor dan sistem bukan bagaimana actor dan sistem melakukan kegiatan tersebut.

Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor. Actor dapat
melihat dan berinisiatif terhadapnya

� Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case abstrak senantiasa
termasuk didalam (include), diperluas dari (extend) atau memperumum (generalize) use case
lainnya. Untuk menggambarkannya dalam use case model biasanya digunakan association
relationship yang memiliki stereotype include, extend atau generalization relationship. Hubungan
include menggambarkan bahwa suatu use case seluruhnya meliputi fungsionalitas dari use case
lainnya. Hubungan extend antar use case berarti bahwa satu use case merupakan tambahan
fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu terpenuhi.

Class

Class merupakan pembentuk utama dari sistem berorientasi obyek, karena class menunjukkan
kumpulan obyek yang memiliki atribut dan operasi yang sama. Class digunakan untuk
mengimplementasikan interface.
Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang dibangun. Class
bisa merepresentasikan baik perangkat lunak maupun perangkat keras, baik konsep maupun benda
nyata.

Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling atas untuk nama
class, persegi panjang paling bawah untuk operasi, dan persegi panjang ditengah untuk atribut.

Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata benda yang bisa
dengan jelas merepresentasikan informasi yang tersimpan didalamnya. Operasi menunjukkan
sesuatu yang bisa dilakukan oleh obyek dan menggunakan kata kerja.

Interface

Interface merupakan kumpulan operasi tanpa implementasi dari suatu class. Implementasi operasi
dalam interface dijabarkan oleh operasi didalam class. Oleh karena itu keberadaan interface selalu
disertai oleh class yang mengimplementasikan operasinya. Interface ini merupakan salah satu cara
mewujudkan prinsip enkapsulasi dalam obyek.

Interaction
Interaction digunakan untuk menunjukkan baik aliran pesan atau informasi antar obyek maupun
hubungan antar obyek. Biasanya interaction ini dilengkapi juga dengan teks bernama operation
signature yang tersusun dari nama operasi, parameter yang dikirim dan tipe parameter yang
dikembalikan.

Note

Note digunakan untuk memberikan keterangan atau komentar tambahan dari suatu elemen
sehingga bisa langsung terlampir dalam model. Note ini bisa disertakan ke semua elemen notasi
yang lain.

Dependency

Dependency merupakan relasi yang menunjukan bahwa perubahan pada salah satu elemen
memberi pengaruh pada elemen lain. Elemen yang ada di

bagian tanda panah adalah elemen yang tergantung pada elemen yang ada dibagian tanpa tanda
panah.

Terdapat 2 stereotype dari dependency, yaitu include dan extend. Include menunjukkan bahwa
suatu bagian dari elemen (yang ada digaris tanpa panah) memicu eksekusi bagian dari elemen lain
(yang ada di garis dengan panah).

Extend menunjukkan bahwa suatu bagian dari elemen di garis tanpa panah bisa disisipkan kedalam
elemen yang ada di garis dengan panah.

Association

Association menggambarkan navigasi antar class (navigation), berapa banyak obyek lain yang bisa
berhubungan dengan satu obyek (multiplicity antar class) dan apakah suatu class menjadi bagian
dari class lainnya (aggregation).
Navigation dilambangkan dengan penambahan tanda panah di akhir garis. Bidirectional navigation
menunjukkan bahwa dengan mengetahui salah satu class bisa didapatkan informasi dari class
lainnya. Sementara UniDirectional navigation hanya dengan mengetahui class diujung garis
association tanpa panah kita bisa mendapatkan informasi dari class di ujung dengan panah, tetapi
tidak sebaliknya.

Aggregation mengacu pada hubungan “has-a”, yaitu bahwa suatu class memiliki class lain,
misalnya Rumah memiliki class Kamar.

Generalization

Generalization menunjukkan hubungan antara elemen yang lebih umum ke elemen yang lebih
spesifik. Dengan generalization, class yang lebih spesifik (subclass) akan menurunkan atribut dan
operasi dari class yang lebih umum (superclass) atau “subclass is superclass”. Dengan
menggunakan notasi generalization ini, konsep inheritance dari prinsip hirarki dapat dimodelkan.

Realization

Realization menunjukkan hubungan bahwa elemen yang ada di bagian tanpa panah akan
merealisasikan apa yang dinyatakan oleh elemen yang ada di bagian dengan panah. Misalnya class
merealisasikan package, component merealisasikan class atau interface.

Peran UML

UML adalah bahasa untuk

● Visualisasi

– Menggambarkan ide dalam notasi dan semantic yang lebih mudah dipahami oleh siapapun

● Spesifikasi

– spesifikasi dari semua keputusan penting analisa, perancangan, dan penerapan yang harus
diambil dalam pengembangan dan deployment sistem PL
● Konstruksi

– UML bukan bahasa pemrograman visual

– Model UML dapat dihubungkan secara langsung dengan beberapa bahasa pemrograman

– Forward engineering: menghasilkan kode dari model

– Reverse engineering: membangun model dari kode

● Dokumentasi

– UML mencakup dokumentasi arsitektur sistem dan rincinya

– Sebagai suatu bahasa untuk menyatakan kebutuhan dan pengujian.

– UML menyediakan bahasa untuk aktifitas perencanaan proyek dan manajemen release

Tool Pendukung UML

Tool-tool pendukung UML Saat ini banyak sekali tool-tool pendukung UML untuk mendesain
model suatu sistem, baik tool yang bersifat komersial maupun open source. Berikut dibawah ini
adalah beberapa diantaranya tool-tool yang sering digunakan dalam UML :

• Rational Rose

• Together

• Object Domain

• Jvision

• Objecteering

• MagicDraw

• Visual ObjectModeller
Pengenalan Dasar Tool Rational Rose 2000

Rational Rose merupakan salah satu tool yang digunakan membangun model suatu sistem secara
visual yang memiliki banyak kemampuan untuk pembentukan sistem berorientasi obyek yang
menggunakan UML.

Dalam UML terdapat beberapa istilah yang sering digunakan seperti : views, diagram dan elemen
model.

1. View

Rational Rose memiliki empat view yaitu : Use Case View, Logical View, Componen View dan
Deployment View.

2. Diagram

Rational Rose 2000 memiliki delapan diagram yaitu : Use case diagram, Sequence diagram,
Collaboration diagram, Activity diagram, Class diagram, State diagram, Component diagram dan
Deployment diagram.

3. Elemen Model

Konsep-konsep yang digunakan dalam diagram merupakan elemen-elemen model yang

menyatakan konsep berorientasi obyek secara umum, seperti class, object dan message, serta
hubungan antar konsep termasuk association, dependency dan generalization