Pengantar UML

Pengenalan UML
Pengenalan UML
UML (Unified Modeling Language) merupakan pengganti dari metode analisis
berorientasi objek dan design berorientasi objek(OOA&D) yang dimunculkan sekitar akhir tahun
80-an dan awal tahun 90-an.
UML merupakan gabungan dari metode Booch, Rumbaugh(OMT) dan Jacobson. Tetapi
UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan pengembangan UML
dilakukan standarisasi proses dengan OMG(Object Management Group) dengan harapan UML
akan menjadi bahasa standar pemodelan pada masa yang akan datang.
UML disebut sebagai bahasa pemodelan bukan metode. Kebanyakan metode terdiri
paling sedikit prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (sebagian besar grafik)
merupakan notasi dari metode yang digunakan untuk mendesain secara cepat.
Bahasa pemodelan merupakan bagian terpenting dari metode. Ini merupakan bagian
kunci tertentu untuk komunikasi. Jika anda ingin berdiskusi tentang desain dengan seseorang,
maka anda hanya membutuhkan bahasa pemodelan bukan proses yang digunakan untuk
mendapatkan desain.
UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan
untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari sistem software.

Sejarah Singkat UML

Bahasa pemodelan berorientasi objek muncul antara sekitar pertengahan tahun 1970-an
dan akhir tahun 1980-an yang dikenal dengan bahasa pemograman berorientasi objek dan
aplikasi komplek yang berkembang, yang dimulai untuk eksperimen dengan pendekatan
alternatif untuk analisis dan desain. Sejumlah metode berorientasi objek bertambah dari kurang
lebih 10 sampai lebih dari 50 selama periode 1989 dan 1994. Beberapa user pengguna metode ini
menemukan permasalahan dalam bahasa pemodelan ini yang dibutuhkan mereka untuk
kelengkapan, sehingga timbul yang dinamakan perang metode. Belajar dari pengalaman, metode
generasi baru mulai muncul dengan metode yang terkemuka, seperti Booch, Jacobsons
OOSE(Object Oriented Software Engineering) dan Rumbaughs OMT(Object Modelling
Technique). Metode penting lainya seperti Fusion, Shler_mellor dan Coad-Yourdan. Setiap
metode ini merupakan metode yang lengkap, meskipun setiap metode diakui memiliki kelebihan
dan kekurangan. Dalam waktu yang singkat metode Booch paling terasa dalam mendesain dan
membangun tahapan project,OOSE memberikan dukungan yang baik untuk use cases seperti
cara untuk menjalankan permintaan, analisis dan desain level tinggi, dan OMT-2 sangat berguna
untuk analisis dan sistem informasi data intensif.

O-1

Pengantar UML

Banyak ide-ide yang kritis dimulai dari pertengahan tahun 1990-an ketika Grady Booch
(Relational Software Corporation), Ivar Jacobson(Objectory) dan James Rumbaugh(General
Electric) mulai mengadopsi ide-ide dari metode lainnya yang dikumpulkan yang akhirnya diakui
sebagai Metode Object Oriented yang mudah diseluruh dunia. Kemudian mereka termotivasi
untuk membangun UML(Unified Modelling Language).
Ada tiga tujuan dibangunnya penyatuan metode tersebut yaitu :
1. Untuk memodelkan sistem, dari konsep ke bentuk yang cocok dengan menggunakan
teknik berorientasi objek.
2. Untuk menunjukkan skala persoalan yang komplek.
3. Untuk membangun bahasa pemodelan yang berguna bagi manusia dan mesin.
Perencanaan bahasa untuk digunakan pada analisa dan desain yang berorientasi objek
tidak seperti mendesain bahasa pemograman. Pertama, kita harus mengetahui masalah seperti
dapatkah bahasa mencakup spesikasi permintaan? Dapatkah bahasa penting untuk pemograman
visual? Kedua, kita harus menemukan keseimbangan antara komplek dan kesederhanaan. Bahasa
yang terlalu sederhana akan terbatas untuk problem yang luas yang akan dipecahkan. Sedangkan
untuk bahasa yang komplek akan berakibat terlalu pengembang pada sistem yang sederhana.
UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung dengan
Booch pada Relational Software Coorporation. Proyek ini mengfokuskan pada penyatuan
metode Booch dan OMT. Versi 0.8 merupakan Metode Penyatuan yang direlease pada bulan
oktober 1995. Dalam waktu yang sama Jacobson bergabung dengan Ralational dan cakupan dari
UML semakin luas sampai diluar perusahaan OOSE. Dokumentasi UML versi 0.9 akhirnya
direlease pada bulan Juni 1996. Meskipun pada tahun 1996 ini melihat dan menerima feedback
dari komunitas Software Engineering. Dalam waktu tersebut menjadi lebih jelas bahwa beberapa
organisasi software melihat kalau UML merupakan strategi dari bisnisnya. Kemudian
dibangunlah UML Consortium dengan beberapa organisasi yang akan menyumbangkan sumber
dayanya untuk bekerja mengembangkan dan melengkapi UML.
Disini beberapa patner yang berkontribusi pada UML 1.0 diantaranya Digital Equipment
Corporation, Hewlett-packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse,
Microsoft, Oracle, Relational, Texas Instruments dan Unisys. Dari Colaboration ini dihasilkan
UML 1.0 yang merupakan bahasa pemodelan yang ditetapkan secara baik, Expressive, kuat dan
cocok untuk lingkungan masalah yang luas. UML 1.0 ditawarkan menjadi standarisasi dari
Object Management Group(OMG). Dan pada januari 1997 sebagai standar bahasa pemodelan.

O-2

Pengantar UML

Antara Januari Juli 1997 Gabungan group tersebut memperluas kontribusinya sebagai
hasil respon dari OMG dengan memasukkan Adersen Consulting, Ericsson, ObjectTimeLimeted,
Platinum Technology,Ptech, Reich Technologies, Softeam, Sterling Software dan Taskon. Revisi
dari versi UML(versi 1.1) ditawarkan kepada OMG sebagai standarisasi pada bulan juli 1997.
Dan pada bulan September 1997 versi ini dierima oleh OMG Analysis dan Design Task
Force(ADTF) dan OMG ArchitectureBoard. Dan Akhirnya pada Juli 1997 UML versi 1.1
menjadi standarisasi.
Pemeliharaan UML terus dipegang oleh OMG Revision Task Force(RTF) yang dipimpin
oleh Cris Kobryn. RTP merilis editorial dari UML 1.2 pada Juni 1998. Dan pada tahun 1998 RTF
juga merilis UML 3.1 dengan disertai dengan user guide dan memberikan technical cleanup.

Gambaran dari UML

UML sebagai Bahasa Pemodelan

UML merupakan Bahasa pemodelan yang memiliki pembendaharaan kata dan cara untuk
mempresentasikan secara fokus pada konseptual dan fisik dari suatu sistem. Contoh untuk
sistem software yang intensive membutuhkan bahasa yang menunjukkan pandangan yang
berbeda dari arsitektur sistem, ini sama seperti menyusun/mengembangkan software
development life cycle. Dengan UML akan memberitahukan kita bagaimana untuk
membuat dan membaca bentuk model yang baik, tetapi UML tidak dapat memberitahukan
model apa yang akan dibangun dan kapan akan membangun model tersebut. Ini merupakan
aturan dalam software development process.
UML sebagai bahasa untuk Menggambarkan Sistem(Visualizing)
UML tidak hanya merupakan rangkaian simbol grafikal, cukup dengan tiap simbol
pada notasi UML merupakan penetapan simantik yang baik. Dengan cara ini, satu
pengembang dapat menulis model UML dan pengembang lain atau perangkat yang sama
lainnya dapat mengartikan bahwa model tersebut tidak ambigu. Hal ini akan mengurangi
error yang terjadi karena perbedaan bahasa dalam komunikasi model konseptual dengan
model lainnya.
UML menggambarkan model yang dapat dimengerti dan dipresentasikan ke dalam
model tekstual bahasa pemograman. Contohnya kita dapat menduga suatu model dari
sistem yang berbasis web tetapi tidak secara langsung dipegang dengan mempelajari code
dari sistem. Dengan model UML maka kita dapat memodelkan suatu sistem web tersebut
dan dipresentasikan ke bahasa pemogranan.
UML merupakan suatu model ekaplisit yang menggambarkan komunikasi informasi
pada sistem. Sehingga kita tidak kehilangan informasi code implementasi yang hilang
dikarenakan developer memotong coding dari implementasi.
UML sebagai bahasa untuk Menspesifikasikan Sistem (Specifying)
Maksudnya membangun model yang sesuai, tidak ambigu dan lengkap. Pada faktanya
UML menunjukan semua spesifikasi keputusan analisis, desin dan implementasi yang
penting yang harus dibuat pada saat pengembangan dan penyebaran dari sistem software
intensif.
UML sebagai bahasa untuk Membangun Sistem(Constructing)
UML bukan bahasa pemograman visual, tetapi model UML dapat dikoneksikan secara
langsung pada bahasa pemograman visual.

O-3

Pengantar UML

Maksudnya membangun model yang dapat dimapping ke bahasa pemograman seperti java,
C++, VB atau tabel pada database relational atau penyimpanan tetap pada database
berorientasi objek.
UML sebagai bahasa untuk Pendokumentasian Sistem (Documenting)
Maksudnya UML menunjukan dokumentasi dari arsitektur sistem dan detail dari
semuanya.UML hanya memberikan bahsa untuk memperlihatkan permintaan dan untuk tes.
UML menyediakan bahasa untuk memodelkan aktifitas dari perencanaan project dan
menejemen pelepasan (release management).

Area Penggunaan UML

UML digunakan paling efektif pada domain seperti :
- Sistem Informasi Perusahaan
- Sistem Perbankan dan Perekonomian
- Bidang Telekomunikasi
- Bidang Transportasi
- Bidang Penerbangan
- Bidang Perdagangan
- Bidang Pelayanan Elekronik
- Bidang Pengetahuan
- Bidang Pelayanan Berbasis Web Terdistribusi
Namun UML tidak terbatas untuk pemodelan software. Pada faktanya UML banyak untuk
memodelkan sistem nonsoftware seperti:
- Aliran kerja pada sistem perundangan.
- Struktur dan Kelakuakn dari sistem Kepedulian Kesehatan Pasien
- Desain Hardware dll.

Tujuan Penggunaan UML

1. memodelkan suatu sistem (bukan hanya perangkat lunak) yang menggunakan konsep
berorientasi objek.
2. menciptakan suatu bahasa pemodelan yang dapat digunakan baik oleh manusia maupun
mesin.

Diagram dalam UML

Diagram berbentuk grafik yang menunjukan simbol elemen model yang disusun utuk
mengilustrasikan bagain atau aspek tertentu dari sistem. Sebuah model sistem biasanya
mempunyai beberapa diagram untuk setiap jenisnya.
Adapun jenis jenis diagram antara lain :
1. Use Case Diagram
Menggambarkan sejumlah eksternal actor dan hubungannya ke Use Case yang diberikan oleh
sistem. Use Case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan
sistem yang dilihat user) dan bagaimana fungsi yang ada didalam sistem.
2. Class Diagram

O-4

Pengantar UML

Menggambarkan struktur statis class dalam sistem. Class merepresentsikan sesuatu yang
ditangani oleh sistem. Class dapat dihubungkan dengan lainnya melalui sejumlah cara :
assasiated (terhubung satu dengan yang lain), dependent (satu class tergantung / menggunakan
class yang lainnya), specialiized (satu class merupakan spesialisasi dari class lainnya), atau
packaged (grup bersama sebagai suatu unit).
3. Sequence Diagram
Menggambarkan kolaborasi dinamis antar sejumlah object. Kegunaanya untuk menunjukkan
rangkaian pesan yang dikirim antara objek juga interaksi antara object.
4. Collaboration Diagram
Menggambarkan kolaborasi dinamis seperti sequence diagram. Dalam menjukkan pertukaran
pesan, collaboration diagram menggambarkan object dan hubungannya (mengacu ke konteks).
Jika penekanannya pada waktu atau urutan gunakkan sequence diagram, tetapi jika
penekanannya pada konteks gunakan collaboration diagram.
5. State Chart Diagram
Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan
kejadian yang menyebabkan state berubah secara dinamis
6. Activity Diagram
Menggambarkan rangkaian aliran dari aktivitas, digunakkan untuk mendeskripsikan aktivitas
yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktivitas lainnya seperti
use case atau interaksi.
7. Component Diagram
Menggambarkan struktur fisik kode dari komponen. Komponen dapat berupa source code,
komponen biner, atau executable component. Sebuah komponen berisi tenatang logic class atau
class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component
view.
8. Deployment Diagram
Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan
hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam
nodes, executable, component dan object yang dialokasikan untuk memperlihatkan unit
perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

UML dan RUP

Unified Modelling Language (UML) adalah bahasa pemodelan yang menggunakan
konsep orientasi objek. UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivar Jacobson di
bawah bendera Rational Software Corp [ERI98]. UML menyediakan notasi-notasi yang
membantu memodelkan sistem dari berbagai perspektif. UML tidak hanya digunakan dalam
pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan.

O-5

Pengantar UML

Rational Unified Process (RUP) adalah metodologi pengembangan perangkat lunak yang
dibangun dengan visi memudahkan pengontrolan dan meningkatkan kualitas perangkat lunak
yang dibangun. RUP memanfaatkan sepenuhnya notasi yang ada dalam UML [WEI01].
Hubungan antara UML dan RUP adalah UML menyediakan notasi-notasi pemodelan,
sedangkan RUP menggunakan notasi-notasi yang disediakan dalam UML tersebut.
Tahap-Tahap Pengembangan dalam RUP [WEI01]

Dimensi kandungan aktivitas

Dimensi waktu pengembangan

Gambar 1 Tahap-Tahap Pengembangan dalam RUP

Pada RUP, tahap pengembangan dideskripsikan dalam dua dimensi, yaitu

Sumbu horisontal, merepresentasikan waktu dan aspek dinamis dari proses, dan
diekspresikan dalam bentuk siklus, tahap, iterasi, dan tonggak (milestone)

Sumbu vertikal, merepresentasikan aspek statis dari proses, bagaimana proses

dideskripsikan dalam bentuk aktivitas, artifak, pekerja, dan alur kerja.

Tujuan dan sasaran tiap tahap pengembangan :

a. Tahap Permulaan (Inception)

Mendapatkan kesepahaman dari stakeholder terhadap sasaran siklus pengembangan

Menetapkan ruang lingkup dan batas dari proyek pengembangan, memperkirakan

total biaya dan jadwal untuk keseluruhan proyek, serta memperkirakan semua resiko
potensial proyek pengembangan

O-6

Pengantar UML

b. Tahap Perluasan (Elaboration)

Membuat garis dasar arsitektur sistem untuk menyediakan landasan yang stabil bagi
upaya perancangan dan implementasi dalam tahap konstruksi.

c. Tahap Konstruksi (Construction)

Melakukan klarifikasi kebutuhan yang masih tersisa dan melengkapi pembangunan

sistem berdasarkan arsitektur yang ditetapkan.

Secara berulang dan bertambah (iterative and incremental) membangun produk yang
lengkap, yang siap dialihkan kepada komunitas penggunanya.

d. Tahap Peralihan (Transition)

Memastikan bahwa perangkat lunak telah tersedia bagi para pengguna akhir (end
user), termasuk pengujian untuk persiapan. Pada tahap ini, umpan-balik pengguna
harus berfokus pada isu-isu fine-tuning, konfigurasi, dan ketergunaan

Rekayasa spesifik-penyebaran, seperti cut over, pengemasan komersial, pelatihan

personil lapangan, serta berbagai aktivitas perbaikan, seperti pembetulan bug,
peningkatan kinerja dan ketergunaan, dan sebagainya

Secara umum effort dan jadwal pengerjaan untuk setiap tahap pengembangan adalah sebagai
berikut :
Effort
Schedul
e

Inception
5%
10 %

Elaboration
20 %
30 %

Construction
65 %
50 %

Transition
10 %
10 %

TABEL 1 Effort dan schedule setiap tahap pengembangan

Alur Utama Pengembangan dalam RUP [WEI01]

Alur utama pengembangan petangkat lunak dalam RUP serta model yang digunakan
dalam setiap alur utama tersebut adalah sebagai berikut :

O-7

Pengantar UML

Gambar 2 Alur Utama Pengembangan dalam RUP

Secara umum effort pengerjaan untuk setiap alur utama pengembangan adalah sebagai berikut :

Effort

Business
Engineerin
g
8,75 %

Requiremen
t Analysis

Analysis and
Design

Implementatio
n

19,75 %

27,75 %

43,75 %

TABEL 2 Effort pengerjaan untuk setiap alur utama pengembangan

Beberapa Alat Bantu dalam RUP [WEI01]

Beberapa alat bantu yang digunakan dalam RUP adalah :
a. Tahap Business Engineering/Business Modelling

Business Use Case Model

Model ini digunakan untuk menggambarkan atau mendeskripsikan bagaimana proses

bisnis dari sistem yang akan dikembangkan (existing system) dalam terminologi use case.
Diagram yang digunakan dalam pemodelan ini adalah Business Use Case Diagram.

Business Object Model

Model ini digunakan untuk menggambarkan bagaimana realisasi dari setiap business use
case pada business use case diagram. Dari setiap business use case dibreakdown
sehingga dapat diketahui entitas apa saja yang ada dalam business use case tersebut.
Entitas-entitas ini akan menjadi kandidat kelas dalam Class Diagram.
b. Tahap Requirement Analysis

Use Case Model

O-8

Pengantar UML

Model ini digunakan untuk menggambarkan kebutuhan-kebutuhan atau fitur-fitur yang

harus dimiliki oleh sistem yang baru. Diagram yang digunakan dalam pemodelan ini
adalah Use Case Diagram.
c. Tahap Analysis and Design

Design Model

Model ini digunakan untuk menggambarkan bagaimana analisis dan desain sistem yang
baru. Dari setiap use case pada use case diagram dibreakdown untuk mengetahui
bagaimana realisasi dari use case tersebut. Realisasi use case dapat dimodelkan dengan
beberapa diagram, yaitu Class Diagram (own by Use Case Realization) serta Interaction
Diagram. Sedangkan desain sistem digambarkan dengan Class Diagram.
d. Tahap Implementation

Implementation Model

Model ini digunakan untuk menggambarkan bagaimana implementasi terhadap desain

dari sistem yang baru. Salah satu diagram yang digunakan dalam pemodelan ini adalah
Database Diagram.

Bagaimana modul ini digunakan?

Modul ini tersusun atas teori mengenai UML, petunjuk pemakaian Rational Rose untuk
membuat diagram-diagram pada UML, contoh kasus UML ( Sistem Registrasi STT Telkom ),
jurnal praktikum dan proyek UML.
1. Praktikan diharapkan mempersiapkan diri mempelajari dan memahami teori atau konsep
UML.
2. Langkah selanjutnya adalah praktikan memilih salah satu metodologi pengembangan
perangkat lunak yang menggunakan UML sebagai visual modelling-nya. Dalam modul ini
diperkenalkan Rational Unified Process sebagai salah satu metodologi pengembangan
perangkat lunak yang menggunakan UML sebagai visual modelling-nya. Praktikan
diperkenankan menggunakan metodologi lainnya.
3. Pada setiap modul praktikan akan dibimbing untuk memakai Rational Rose sebagai salah
satu tools pemodelan UML.
4. Pada setiap modul, praktikan akan mengerjakan jurnal praktikum dimana pertanyaan yang
diajukan berasal dari study kasus yang digunakan sebagai contoh dalam setiap modul dan
kasus khusus yang telah ditentukan.

O-9

Pengantar UML

5. Pada akhir praktikum, semua praktikan akan mempresentasikan proyek/tugas besar

praktikum berupa hasil rekayasa pengembangan perangkat lunak menggunakan UML sampai
dengan tahap design perangkat lunak.

Check Model (Tools Menu)

Perhatian : Pada beberapa kasus tidak dilakukan check model, hal ini didasari atas adanya
perbedaan antara konsep UML dengan Check Model ? Kesimpulannya, tidak harus dilakukan
check model.
Check Model dibuat untuk memeriksa apakah model yang dibuat pada banyak unit konsisten
satu dengan yang lainnya. Hal ini khususnya berguna ketika parallel development berjalan pada
banyak unit, karena sangat mungkin unit-unit yang berbeda tidak sinkron satu dengan yang lain.
Check Model akan memeriksa referensi sebagai berikut :
Ke supplier ( lihat anonim supplier pada package relationship di modul 2 ) dari sembarang
relationship, has, uses, instantiation, metaclass, logical package import, module visibility,
connection, dsb.
Dari sebuah view pada sebuah diagram ke sebuah item di model
Dari sebuah logical package ke component package yang berasosiasi dengannya dan dari
sebuah modul ke class yang berasosiasi dengannya.
Dari sebuah object ke class yang berasosiasi dengannya.
Dari sebuah message pada sebuah object diagram ke sebuah operasi dalam sebuah class.
Dari dynamic semantic dalam sebuah operasi ke scenario diagram

O - 10