METODOLOGI BERORIENTASI OBJEK

MATERI 1
PENGANTAR MODOLOGI BERORIENTASI OBJEK

Melihat laju perkembangan teknologi informatika yang demikian pesat

dewasa ini, maka pendekatan berarah objek diperkirakan akan menggantikan
pendekatan Struktural dalam merancang sistem di masa yang akan datang. Hal
ini dikarenakan pendekatan berarah objek memiliki beberapa kelebihan
diantaranya:

Aplikasi yang akan dibangun didukung oleh perkembangan teknologi

Software Engineering yang baru menuju ke konsep Object Oriented.
1. Tehnologi dengan pendekatan object-oriented ini memungkinkan
komponen dari program dapat dipakai ulang sehingga memper-
mudah dalam pengembangan sistem selanjutnya serta program yang
dihasilkan pun makin berkualitas baik.
2. Aplikasi yang dibangun dengan pendekatan ini mudah dalam
perawatan karena strukturnya mengalami proses inheritance.
Sehingga teknologi dengan pendekatan object-oriented ini dapat
mengurangi efek samping atau resiko ketika terjadi perubahan pada
struktur.

Sampai saat ini dikenal dua pendekatan yang utama dalam

pengembangan sistem dengan metode berarah objek yaitu:

1. Pendekatan Langsung (Direct Approach), adalah suatu pendekatan

perancangan sistem dalam metode berarah objek dimana pendesain
sistem langsung mendesain objek-objek yang diperlukan sistem.
Kelemahan dari pendekatan ini adalah karena seorang pendesain
diberi kebebasan dalam membuat objek sehingga untuk meng-
hasilkan objek yang benar-benar baik maka diperlukan pengulangan
proses untuk perbaikan objek.
2. Pendekatan Sintesis (Synthesis Approach), adalah suatu pendekatan
dalam perancangan sistem dengan metode berarah objek dimana
objek–objek yang dihasilkan diperoleh dari penerapan metode
struktural. Kelemahan dari pendekatan ini adalah seorang pendesain
melakukan tahapan kerja lebih banyak yaitu harus merancang sistem
Page 2 of 38
 secara struktural terlebih dahulu kemudian mentransfernya ke dalam
bentuk objek.
2.1. Pendekatan Sintesis (Synthesis Approach)
Pendekatan sintesis adalah pendekatan metode berarah objek secara
tidak langsung. Maksud tidak langsung disini adalah bahwa objek-objek
diperoleh dari hasil pendesainan secara struktural. Jadi dalam pendekatan ini,
langkah pertama adalah membangun terlebih dahulu data dan proses,
kemudian menyatukan data dan proses tersebut menjadi objek–objek dengan
aturan-aturan tertentu.

2.2. Pendekatan Langsung (Direct Approach)

Pendekatan secara langsung adalah metode berarah objek yang meliputi:

analisis berarah objek (OOA), perancangan berarah objek (OOD), pemrograman
berarah objek (OOP) dan pengujian berarah objek (OOT).

Istilah “objek” telah digunakan dalam cara yang berbeda dari dua
disiplin ilmu yang berbeda.
1. Dari permodelan Informasi adalah:
“suatu representasi dari beberapa dunia nyata dan sejumlah kejadian”; dan
2. Dari bahasa pemrograman berarah objek adalah:
“suatu runtime beberapa proses dan nilai yang ditentukan dengan deskripsi
yang disebut kelas”.

Objek juga didefinisikan sebagai berikut:

“Objek dapat didefinisikan sebagai suatu encapsulation atau
penggabungan dari data (yang diwakilkan oleh atribut-atribut) dan
operasi–operasi (disebut juga metode/prosedur) yang akan melakukan
proses terhadap data-data tersebut.”

Persamaan dari pendekatan object oriented :

Object oriented = Class-&-Object + Inheritance + Communication with Massage

Analisis berarah objek dibangun sebagian besar diatas konsep

permodelan Informasi, bahasa pemrograman berarah objek dan sistem berbasis

Page 3 of 38
pengetahuan (konsep yang mempunyai basis yang baku dan pengertian prinsip-
prinsip untuk menangani kerumitan).
Dari model Informasi secara analogi mengambil bentuk attribute,
instance connection, generalize-specification dan whole-part. Dari bahasa
pemrograman berarah objek dan sistem berbasis pengetahuan secara analogi
mengambil bentuk pembungkusan dari atribut dan service, communication with
massages, gen-spec dan inheritance.

Entity Semantic y Attributes

Relationship Data y Instance Connections
Diagrams Modeling y Generalization-Specialization
y Whole-Part

(Information Modeling) Object

Oriented
Analysis

y Attributes and Exclusive Service

Object-Oriented y Communication with Messages
Programming Languages & y Generalization-Specialization
Knowledge-Based Systems y Inheritance

Gambar 1 OOA Gabungan dari beberapa Disiplin Ilmu

Metode pembangunan perangkat lunak berarah objek adalah suatu
strategi pembangunan perangkat lunak yang mengorganisasikan perangkat lunak
sebagai kumpulan objek yang berisi data aksi yang dilakukan terhadapnya.
Penggabungan proses dan data didalam suatu objek dikenal sebagai
pembungkusan. Ditambah dengan konsep infohiding, object class or instant
connection dan polymorphism merupakan dasar dari metode berarah objek.
Adapun komunikasi antar proses yang dapat berarti komunikasi antar objek
dilakukan dengan melalui pesan (communication with massages).
2.3. Prinsip-prinsip
Prinsip-prinsip pengelolaan kompleksi tersebut terdiri atas abstraksi
(prosedural dan data), pembungkusan, asosiasi, komunikasi dengan pesan,
metode organisasi, penskalaan, dan pengelompokan prilaku [COA90].
1. Abstraksi (Abstraction)
Abstraksi: prinsip yang menganggap bahwa aspek-aspek dari suatu objek
yang tidak relevan dengan tujuan sekarang, digunakan untuk melengkapi
tujuan tsb.
Mekanisme abstraksi:
a. Abstraksi Prosedural: sering dikarakteristikkan sebagai abstraksi fungsi
atau subfungsi. Pemecahan proses kedalam tahapan-tahapan merupakan
suatu metode dasar dalam penanganan kekomplekan suatu proses.
Page 4 of 38
 b. Abstraksi Data: prinsip pendefinisian suatu type data dalam istilah-
istilah pengoperasian yang menggunakan type tersebut dengan
pembatasan terhadap nilai-nilai objek yang dapat dimodifikasi dan
hanya dijalankan dengan menggunakan operasi, prinsip ini dapat
menjadi suatu dasar untuk pengaturan tanggungjawab suatu sistem
secara spesifik.
2. Pembungkusan (Encapsulation)
Pembungkusan adalah suatu prinsip yang digunakan ketika pengembangan
struktur program secara keseluruhan, dimana tiap-tiap komponen program
harus disimpan/disembunyikan dalam satu perancangan interaksi. Untuk
tiap-tiap modul ditentukan dengan cara mengungkapkan sebagian kecil
tentang informasi kerja secara pasti. Pembungkusan membantu
memperkecil pekerja-an ketika pengembangan suatu sistem baru. Jika
seorang perancang “mem-bungkus” bagian dari hasil analisis yang sering
berubah-ubah, kemudian mengganti sesuai dengan kebutuhan, jika ada
masalah, maka masalah tersebut lebih kecil resikonya bila dibandingkan
dengan tanpa “pembungkusan”.
3. Pewarisan (Inheritance)
Pewarisan adalah suatu cara kerja yang menyatakan kesamaan diantara
kelas-kelas, penyederhanaan definisi kelas yang mirip ke suatu definisi yang
telah ada sebelumnya. Pewarisan terdiri dari generalisasi dan spesialisasi.
4. Asosiasi (Association)
Asosiasi adalah penyatuan atau pengembangan ide-ide. Digunakan untuk
me-nyatukan sesuatu secara bersama-sama dalam keadaan yang mirip.
5. Komunikasi dengan Pesan (Communication with Massages)
Pesan adalah suatu komunikasi, berupa tulisan atau ucapan, pengiriman
pesan antar orang-orang. Hal ini dihubungkan dengan "pembungkusan",
rincian itu merupakan kegiatan yang dilakukan dengan menerima pesan.
6. Metode Pengorganisasian (Pervading Methods of Organization)
Metode Pengorganisasian ini meliputi tiga bagian yaitu:
a. Perbedaan pengalaman kedalam bagian objek dan atributnya. (object
and attributes)
b. Perbedaan antara keseluruhan objek dan komponen bagiannya. (whole
and parts)
c. Formasi dan perbedaan antara kelas-kelas objek yang berbeda. (classes,
members and distinguishing between them)
Page 5 of 38
7. Skala (Scale)
Skala adalah suatu prinsip yang menerapkan whole-part untuk membantu
menghubungkan sesuatu yang berukuran besar tanpa perlu meliputi
semuanya.
8. Klasifikasi Tingkah Laku (Behavior Classification)
Jenis klasifikasi tingkah laku yang digunakan secara umum yaitu:
a. Berdasarkan kepada kebutuhan yang mendesak
b. Berdasarkan perjalanan waktu (historis)
c. Berdasarkan fungsi

2.2.4. Keuntungan Metode Berarah Objek

Keuntungan Metoda Berarah Objek diantaranya adalah [COA91]:

1. meningkatkan produktivitas,
karena kelas dan objek yang diketemukan pada suatu kasus masih dapat
dipakai ulang untuk kasus lainnya yang melibatkan objek tersebut
(reusable);
2. meningkatkan kualitas,
karena sistem yang dibangun dengan baik dan benar pada saat analisis dan
perancangannya akan menyebabkan berkurangnya kesalahan pada saat
pengkodean;
3. mempermudah perawatan,
karena dengan model objek pola-pola yang cenderung tetap dan stabil
dapat dipisahkan dari pola-pola yang mungkin sering berubah-ubah; dan
4. adanya konsistensi;
karena sifat pewarisan dan penggunaan notasi yang sama pada saat analisis,
perancangan, maupun pengkodean.

Page 6 of 38
 MATERI 2
ANALISIS BERORIENTASI OBJEK

Pendekatan analisa berarah objek terdiri dari lima pokok aktivitas, yaitu:
a. Menentukan Kelas-&-Objek (finding class-&-objects)
b. Identifikasi Struktur (identifying structures)
c. Identifikasi Subjek (identifying subject)
d. Pendefinisian Atribut (defining attributes)
e. Pendefinisian Service (defining services)

2.1. Penentuan Kelas-&-Objek (class-&-object)

Pengertian objek adalah suatu abstraksi dari suatu lingkup
permasalahan / implementasi yang menggambarkan kemampuan dari sistem
untuk menangkap informasi tentang objek tersebut, berinteraksi dengan atau
keduanya; "pembung-kusan" pada nilai atribut dan service-nya.
Kelas adalah suatu gambaran dari satu atau lebih objek, penggambaran
dengan sekumpulan atribut dan service yang sama. Menggambarkan bagaimana
untuk menciptakan objek-objek baru dalam suatu kelas.

Class

Attribute

Service

Gambar 2.1 Simbol Kelas

Simbol ini digunakan untuk merepresentasikan generalisasi kelas dari
lingkup permasalahan yang berhubungan dengan objek-objeknya yang
digambar-kan dengan spesialisasi objek tersebut.
Kelas-&-objek adalah suatu istilah yang berarti suatu kelas-&-objek
yang ada di kelas tersebut.

Class & Object

Attribute

Service

Gambar 2.2 Simbol Kelas-&-Objek

Simbol "kelas-&-objek" merepresentasikan suatu kelas dan objek-objek-
nya. Simbol kelas digambarkan dengan segiempat yang dicetak tebal dan di
Page 7 of 38
bagi ke dalam tiga bagian. Simbol objek-objeknya digambarkan dengan
segiempat yang ada disebelah luar dari simbol kelas. Hubungan dari satu objek
ke objek lain atau hubungan satu kelas ke kelas lain atau hubungan satu objek
ke suatu kelas, merupakan hal yang dapat dilakukan terhadap simbol tersebut.
Simbol diberi nama dengan kelas-&-objeknya. Atribut dan service dapat
digunakan untuk tiap-tiap objek disuatu kelas. Nama kelas-&-objek adalah
suatu kata kerja atau kata sifat. Nama kelas-&-objek harus menggambarkan
suatu objek tunggal dengan kelasnya. Contoh: ketika tiap objek
menggambarkan sesuatu yang berhubungan dengan "meja" maka nama kelas-&-
objeknya: "anggota_meja". Tiap objek minimal mempunyai satu item.
2.2. Identifikasi Lapisan Struktur
Struktur adalah suatu ekspresi dari lingkup permasalahan yang komplek,
berhubungan dengan tanggungjawab terhadap sistem. Istilah struktur digunakan
sebagai sebuah istilah yang menggambarkan struktur generalisasi-spesialisasi
(gen-spec) dan struktur keseluruhan dan bagiannya (whole-part).
Struktur gen-spec termasuk kebagian "perbedaan antar kelas" dalam tiga
aspek dasar metode pengorganisasian. Struktur gen-spec dikenal sebagai
struktur "is a" atau "is a kind of".

Generalization

Attribute

Service

Specialization 1 Specialization 2

Attribute Attribute

Service Service

Gambar 2.3 Simbol Generalize-Specification

Dengan struktur gen-spec, pewarisan digambar secara eksplisit terhadap
atribut dan servisnya. Gen-spec digambarkan dengan kelas atas generalisasi dan
kelas dibawahnya adalah spesialisasi dengan penghubung diantaranya.setengah
lingkaran membedakan antara kelas-kelas dalam gen-spec.
Struktur Whole-parts digambarkan dengan objek pada bagian atas dan
objek pada bagian bawah (dari simbol kelas-&-objek) dengan garis penghubung
diantaranya, whole-parts dikenal sebagai struktur "has a".
Page 8 of 38
 Whole
Attribute

Service

1,m 1,m

1 1

Part 1 Part 2

Attribute Attribute

Service Service

Gambar 2.4 Simbol Whole-parts

2.3. Identifikasi Lapisan Subjek
Subjek adalah suatu mekanisme yang membantu pembaca untuk meng-
analisa model permasalahan dari yang kecil hingga ke yang besar dan komplek.
Pada lapisan subjek, gambarkan setiap subjek sebagai kotak persegi
yang sederhana, dengan nama subjek dan nomor didalamnya sebagai tambahan,
daftarkan kelas-kelas yang termasuk didalam subjek tersebut. Pada lapisan
yang lain indikasikan subjek dengan label subjek pada sekat pemisah kotak
subjek untuk memandu pembaca dari subjek ke subjek lainnya. Dalam model
yang besar dan membutuhkan fasilitas komunikasi, pertimbangkan penggunaan
"set" dari lapisan secara terpisah untuk setiap subjek. Sebuah kelas dari subjek
berada didalam lebih dari satu subjek. Subjek boleh berisi subjek lainnya.
Persiapkan pemetaan multi level untuk membantu pembaca dalam suatu model
yang besar.

1. Subject1

Class-&-Object1
Class-&-Object2

2. Subject2

Class-&-Object3
Class-&-Object4

Gambar 2.5 Simbol Subject

Page 9 of 38
 Penggambaran dari simbol diatas dengan lapisan yang berbeda dapat
dilihat dalam gambar dibawah ini.
1 1 2 2

1 1 2 2

Gambar 2.6 Simbol Subject dengan Lapisan Berbeda

2.4. Pendefinisian Lapisan Atribut
Atribut adalah beberapa data (state information) dimana setiap objek di
dalam suatu kelas mempunyai nilai tersendiri.
Mendefinisikan atribut dengan cara:
a. Identifikasi atribut
b. Mencari posisi atribut
c. Identifikasi instance connection
Untuk identifikasi atribut perlu menjawab beberapa pertanyaan:
1. Bagaimana kita mendeskripsikannya secara umum?
2. Bagaimana kita pada permasalahannya
3. Bagaimana kita mendeskripsikannya pada bentuk tanggungjawab thd.
sistem?
4. Apa yang harus diketahui?
5. Apa acuan untuk pelaksanaannya?

Periksalah kembali hasil analisis pada permasalahan yang sama/serupa.

Pertimbangkan penggunaan atribut untuk merancang keputusan dalam segi
waktu dengan memori yag dipergunakan. Buatlah tiap-tiap atribut dalam
konsep atomic. Tambahkan "id" (identifier) dan "cid" (connection identifier),
sehingga dapat dipergunakan pada spesifikasi teks jika diperlukan.
Masukan setiap atribut kedalam kelas dan objeknya (periksa permasalah-
annya). Daftarkan inheritance pada struktur gen-spec. posisi atribut yang
bersifat umum letakan di tingkat yang lebih atas, sedangkan posisi atribut yang
lebih spesifik diletakan ditingkat yang berikutnya.
Instance connection: suatu model pemetaan lingkup permasalahan pada
satu objek yang memerlukan objek lainnya, untuk memenuhi "tanggungjawab"
terhadap proses yang harus dilakukannya. Instance connection
merepresentasikan bagian dari state information yang diperlukan oleh sebuah
objek.

Page 10 of 38
 Periksa hasil analisis pada permasalahan yang sama. Untuk setiap objek,
tambahkan garis koneksi. Tambahkan subjek-bahan pemetaan (subject-matter
mappings) diantara objek, perhatikan keterhubungan dengan struktur gen-spec.

Class & Object Class

Attribute 1 Attribute 1
Atribute 2 Attribute 2

Service Service

Gambar 2.7 Simbol Attributes

Atribut ditempatkan dibagian tengah dari kelas-&-objek dan dari kelas.

Class & Object Class & Object

Attribute 0, m 1 Attribute

Service Service

Gambar 2.8 Simbol Instance Connection

Instance connection digambarkan dengan garis yang mehubungkan antar
objek. Garis tersebut menghubungkan antar individu objek dari pada antar
kelas. Tiap objek mempunyai jumlah atau batas penandaan (m, n) untuk
Instance connection-nya.
2.5. Pendefinisian Lapisan Service
Service adalah tingkah laku yang spesifik, yaitu tingkah laku yang mem-
perlihatkan "tanggungjawabnya" terhadap sebuah objek.
Identifikasi uraian objek (object state):
1. Ujilah nilai yang potensial dari atribut
2. Bedakan apakah tanggungjawab sistem termasuk perbedaan kelakuan
(behavior) untuk masing-masing nilai yang potensial
3. Periksa dengan hasil analisis terhadap permasalahan
4. Deskripsikan kedalam diagram objek (object state diagram)

Class & Object Class

Attribute Attribute

Service 1 Service 1
Service 2 Service 2

Gambar 2.9 Simbol Service

Service ditempatkan dibagian bawah dari simbol kelas-&-objek dan kelas.

Page 11 of 38
 Message connection adalah model yang memproses ketergantungan dari
sebuah objek, indikasi yang diperlukan untuk service dalam melaksanakan
pekerjaan yang berhubungan dengan "tanggungjawabnya".

Sender Receiver
Attribute Attribute

Service Service

Gambar 2.10 Simbol Message Connection

Simbol message connection merupakan sebuah anak panah dari pengirim
ke penerima. Anak panah berarti pengirim mengirim sebuah pesan, sedangkan
penerima menerima pesan tersebut dan mengembalikan pesan tersebut setelah
diproses terlebih dahulu. Biasanya message connection menghubungkan antar
objek dari pada antar kelas.

Page 12 of 38
 MATERI 3
PERANCANGAN BERARAH OBJEK

Didalam perancangan berarah objek, prinsip whole-part diterapkan ke

dalam empat komponen utama, yaitu:
a. Komponen Lingkup Permasalahan (Problem Domain Component)
b. Komponen Interaksi Manusia (Human Interaction Component)
c. Komponen Manajemen Kerja (Task Management Component)
d. Komponen Manajemen Data (Data Management Component)
Hubungan empat aktifitas utama dalam perancangan berarah objek
dengan lima aktifitas dalam analisis dapat dilihat dalam gambar berikut:
Subject layer
Class & object Task
Human Problem Data
layer Managemen
Interaction Domain Management
Structure t
Component Component Component
layer Component
Attribute layer
Service layer

Gambar 3.1 Hubungan Analisis dengan Perancangan

Empat komponen utama tersebut berhubungan dengan empat aktifitas

utama dalam perancangan berarah objek, yaitu:
a. Perancangan Lingkup Permasalahan (Problem Domain Design)
b. Perancangan Interaksi Manusia (Human Interaction Design)
c. Perancangan Manajemen Kerja (Task Management Design)
d. Perancangan Manajemen Data (Data Management Design)
3.1. Perancangan Lingkup Permasalahan
Dalam perancangan berarah objek, hasil analisis berarah objek dimasuk-
kan kedalam komponen lingkup permasalahan. Hasil analisis secara menyeluruh
merupakan bagian dari model perancangan. Dengan langkah ini, penelusuran
dari analisis, perancangan sampai pemrograman menjadi jelas sehingga setiap
kegiatan diorganisasikan sebagai lingkup permasalahan itu sendiri. Hal ini

Page 13 of 38
mengacu kepada keseimbangan yang diperlukan untuk pengorganisasian
analisis, perancangan, pemrograman setiap saat.
Keseimbangan adalah kunci utama untuk pemakaian kembali (reuse)
hasil analisis, perancangan dan pemrograman yang berkaitan dengan lingkup
per-masalahan. Keseimbangan dalam analisis dan perancangan memberikan
dasar yang benar-benar cocok dalam mengajukan perubahan secara sistematik.
Dalam perancangan lingkup permasalahan ini, mengikuti langkah-langkah
berikut:

1. Penerapan hasil analisis

2. Menggunakan hasil analisis dan memperbaikinya selama perancangan
3. Menggunakan hasil analisis dan penambahannya selama perancangan
Dari model objek hasil analisis dilakukan:
a. Pendalaman hasil analisis untuk menghasilkan model yang lebih mendekati
kenyataan (real world)
b. Penambahan kriteria pada model hasil analisis dengan cara:
∗ Penggunaan kembali (reuse) kelas-&-objek hasil analisis rancangan dan
pemrograman sebelumnya
∗ Pengelompokan kelas-kelas yang spesifik terhadap lingkup permasalahan
∗ Pembuatan sebuah protokol dengan penambahan kelas-&-objek yang
bersifat umum
∗ Penerapan tingkatan pewarisan
∗ Peningkatan performansi
∗ Mendukung komponen manajemen data
∗ Penambahan komponen tingkat bawah

3.2. Perancangan Interaksi dengan Manusia

Sistem berbasis komputer selalu mempunyai elemen orang yang ber-
interaksi langsung dengan perangkat keras dan lunak, mengelola dialog
terhadap fungsi-fungsi dari sistem, pada semua kasus manusia
bertanggungjawab untuk pekerjaan pembangunan dan perawatan sistem
Untuk itu perlu diketahui keinginan dari pemakai terhadap sistem agar
seluruh proses kegiatan manusia dan antarmuka (human interface) yang
berdasar-kan hubungan sebab akibat dapat diimplementasikan dengan mudah,

Page 14 of 38
cepat dengan menjalankan dan menerapkan aplikasi yang dibangun. Tahap
perancangan HIC dapat dilihat dalam pembahasan berikut.
3.2.1. Klasifikasi Pemakai
Langkah-langkah untuk mengklasifikasikan pemakai:
1. Tempatkan diri kitasebagai pemakai sistem
2. Klasifikasikan berdasarkan level keahlian
3. Klasifikasikan berdasarkan level organisasi
4. Klasifikasikan berdasarkan keanggotaan pada group yang berbeda

3.2.2. Deskripsi Pemakai

Langkah-langkah untuk mengdeskripsikan pemakai:
1. Tentukan siapa yang akan menggunakan sistem ini
2. Apa tujuan orang tersebut berhubungan deng sistem
3. Bagaimana karakteristik pemakai sistem
4. Faktor-faktor kesuksesan meliputi perlu/tidak, suka/tidak
5. Tentukan level keahlian dari orang tersebut
6. Tentukan skenario kegiatan yang harus dilakukan oleh orang tersebut

3.3. Perancangan Manajemen Kerja

Kegiatan atau kerja (task) merupakan komponen inti suatu objek dalam
berinteraksi dengan objek lain, keterhubungan dan keterkaitan antar objek ini
ditentukan dulu oleh manajemen kerja. Dengan adanya manajemen kerja yang
baik, tentunya akan membentuk struktur keterkaitan antar objek lebih terarah,
dimana keterkaitan antar objek ini merupakan komponen utama dalam
perancang-an berarah objek dalam membentuk suatu sistem yang multiuser.

3.4. Perancangan Manajemen Data

Data merupakan komponen penting dalam suatu sistem untuk menghasil-
kan suatu informasi. Untuk itu, diperlukan pengelolaan data yang teratur dan
terarah sehingga jika diperlukan dapat diakses dengan cepat dan tepat. Maka
dalam perancangan berarah objek, permasalahan mengenai manajemen data
masuk dalam permasalahan inti dalam perancangan. Hal ini dikarenakan,
dengan manajemen data yang baik maka sistem yang dihasilkan akan lebih baik
serta pemanfaatan data dapat dilakukan dengan lebih efektif dan efesien.

Page 15 of 38
 MATERI 4
PEMROGRAMAN BERORIENTASI OBJEK

Definisi [Meyer-97]
Sebuah sistem yang dibangun berdasarkan metoda berorientasi objek adalah
sebuah sistem yang komponennya di-enkapsulasi menjadi kelompok data
dan fungsi, yang dapat mewarisi atribut dan sifat dari komponen lainnya,
dan komponen-komponen tersebut saling berinteraksi satu sama lain.

Beberapa definisi lain

Object orientation:
1.a. the paradigm that use objects with identity that encapsulate
properties and oeprations, message passing, class, inheritance,
polymorphism, and dynamic binding to develop solution that model
problem domains [Firesmith, Lorenz]
1.b. any technique based on the concept of object, class, instances and
inheritance
[Jacobson]
2. the use of objects as the atom of modeling [Coleman]

Object adalah abstraksi dari sesuatu yang mewakili sesuatu pada dunia
nyata. Pada pemrograman berorientasi objek, Objek adalah entitas pada saat
run time . Objek mempunyai siklus hidup : diciptakan, dimanipulasi,
dihancurkan. Sebuah objek dapat diacu lewat namanya atau lewat
referensinya (addressnya)

Class adalah kumpulan objek yang mempunyai atribut yang sama. Class
adalah definisi statik dari entitas.

Entitas :
Entitas adalah salah satu dari berikut ini:
- atribut kelas
- variabel lokal
- parameter formal
- hasil fungsi
Page 16 of 38
Tujuh langkah untuk mendapatkan hasil (SW) yang memuaskan [Meyer-97]:
1. Object based modular structure, sistem dimodularisasi berdasarkan
struktur objek
2. Data abstraction, objek harus dideskripsikan sebagai implementasi dari
ADT
3. Automatic memory management , objek yang sudah tidak dibutuhkan
lagi harus di-dealokasi oleh sistem pemroses bahasa tanpa perlu
intervensi pemrogram
4. Classes, setiap type yang tidak sederhana adalah sebuah modul,
setiap modul adalah type tingkat tinggi
5. Inheritance, sebuah Class dapat didefinisikan berdasarkan ekstensi atau
restriksi dari kelas lain
6. Polymorphism and dynamic binding, entitas program harus dimungkinkan
untuk mengacu kepada lebih dari satu kelas dan operasi harus
dimungkinkan untuk lebih dari satu kelas
7. Multiple and repeated inheritance, harus dimungkinkan untuk membuat
deklarasi kelas sebagai pewaris dari banyak kelas, dan lebih dari satu jika
pewarisnya sebuah kelas

Karakteristik utama sistem beorientasi objek [Meyer-97]

· abstraksi
· enkapsulasi
· pewarisan (inheritance)
· reuseability
· spesialisasi
· generalisasi
· komunikasi antar objek
· polymorphisme

Pengembangan sistem dengan metoda OO dapat meningkatkan :

· produktifitas
· kecepatan pengembangan
· kualitas perangkat lunak
· kemudahan pemeliharaan

Page 17 of 38
Catatan : pada kuliah ini sangat dibedakan aspek statik dan aspek dinamik
(program pada saat run time)

Dinamika kehidupan objek : lahir (diciptakan), dimanipulasi/memanipulasi,

mati
(dihancurkan)

Objek merupakan model eksekusi

Objek mengalamai dynamic creation
- program mmenciptakan sejumlah objek menurut pola yang tidak
mungkin diprediksi pada saat kompilasi
- pada saat operasi, objek baru mungkin saja diciptakan, reference
sebuah objek diubah ke objek yang lain atau tidak lagi mengacu ke
objek apapun
- nilai yang disimpan dalam sebuah field objek diubah

Perbedaan Kelas dan Objek

Adalah sangat penting untuk membedakan antara Kelas dan Objek . Objek
adalah elemen pada saat runtime yang akan diciptakan, dimanipulasi dan
dihancurkan saat eksekusi
Kelas adalah deskripsi statik dari himpunan objek yang mungkin
lahir/diciptakan yang merupakan instansiasi dari Kelas
Pada saat runtime, yang kita punyai adalah objek. Di dalam teks program,
yang kita lihat hanyalah kelas.

KELAS , definisi statik :

Pada lingkungan program berorientasi objek, pemrogram mendefinisikan
kelas secara statik. Pada saat run time, kelas akan diinstansiasi menjadi
objek (lihat dinamika). Objek yang merupakan instansiasi dari suatu kelas
selalu dapat diacu lewat Current Object, apapun nama instantnya.
Untuk menjamin bahwa setiap instans yang lahir dari kelas sesuai dengan
definisi kelas, bebrapa bahasa menyediakan fasilitas untuk menentukan
class invariant, yaitu berupa asersi yang menjamin kebenaran objek.

Page 18 of 38
Untuk menciptakan (menghidupkan) objek, diperlukan konstruktor. Untuk
mematikan
(menghancurkan) objek, diperlukan destruktor
Kelas mempunyai:
· atribut (data, konstanta, properti). Nilai atribut pada saat run time
menyatakan
“keadaan” (state) dari objek yang merupakan instans dari kelas ybs.
Beberapa bahasa pemrograman mendefinisikan atribut harus sebuah Kelas,
atau beberapa bahasa memperbolehkan atribut dideklarasi sebagai kelas
atau type dasar
(numerik: integer/float, character, boolean)
· method (service, prosedur, fungsi). Pada saar run time, method akan
dieksekusi sesuai dengan kode programnya, atas permintaan (lewat pesan,
message) objek lain. Method mempunyai spesifikasi, signature (nama dan
parameter), dan mempunyai body (kode program yang akan dieksekusi).
Signature adalah informasi bagi kelas yang akan menggunakan kelas ini,
sedangkan body merupakan kode program yang akan dieksekusi.
Sebenarnya body tidak perlu diketahui oleh kelas pemakai asalkan
spesifikasinya jelas. Spesifikasi : Prekondisi
(initial state), post kondisi (Final State) dan “proses” apa yang akan
dikerjakan ketika mehod dieksekusi. Prekondisi dan Post kondisi dapat
dituliskan sebagai asersi (pada beberapa bahasa), sedangkan proses
dinyatakan dalam komentar. Parameter prosedur/fungsi dalam OOP
selalu parameter input, tidak pernah ada parameter output atau
parameter input/output:

· Fungsi dirancang untuk melahirkan sebuah objek baru (range, hasil)

dari objek input. Parameter fungsi selalu merupakan parameter
input, karena fungsi akan memetakan semua objek input (domain)
menjadi sebuah objek
lain (range), tanpa mengganggu state dari objek input
· Prosedur dirancang untuk mengubah state dari Current objek,
tanpa melahirkan objek baru. Parameter prosedur selalu
parameter input yang mewakili informasi perubahan dari Current
Objek. Current objek merupakan parameter input/output secara
implisit, sehingga tidak pernah dimunculkan dalam signature
Page 19 of 38
 [Meyer-97] menyebut atribut dan method sebagai feature. Selanjutnya
istilah feature akan dipakai dalam kuliah ini untuk mewakili atribut dan/atau
method

Deklarasi Kelas

// Hubungan dengan kelas lain

Class X // Nama Kelas
// feature: Atribut
// feature: Method
// invarian kelas
End Class X;

Contoh Kelas Sederhana Point

Class Point
// atribut
x,y : integer
End class Point

Lingkup akses terhadap Feature didefinisikan mulai dari yang umum sampai
dengan yang sangat restriktif:
· public : dapat diakses/dipakai kelas apapun
· friend, hanya kelas tertentu yang boleh mengakses
· private : hanya kelas yang bersangkutan yang boleh memakai
Penentuan lingkup akses terhadap feature merupakan bagian yang harus
dirancang. Sebenarnya, dalam perancangan yang murni OO, sebaiknya “friend”
tidak digunakan

Klasifikasi kelas
Model program berorientasi objek yang termasuk paling “lama” dan mendasar
adalah model MVC dari Smalltalk, dimana setiap aplikasi dipandang terdiri
dari tiga jenis kelas : M (Modeler), V (Viewer), C( Controller) dengan
hubungan sebagai berikut:

Modeler adalah representasi dari domain persoalan yang akan diprogram.

Viewer bertugas untuk menampilkan objek “domain” sesuai dengan jenis

Page 20 of 38
objek ke antarmuka pengguna (misalnya di lingkungan GUI : layar/windows),
sedangkan Controller bertugas untuk mengatur interaksi dan aliran
data/pesan antara Modeler dan Viewer. Objek dilahirkan berdasarkan definisi
kelas, dan ketika eksekusi program akan
“hlang”. Jika objek harus dapat disimpan secara permanen, maka modeler
juga harus merepresentasi persistent objek (pada pemrograman prosedural
menjadi arsip eksternal, external file) .

Klasifikasi kelas dari sudut pandang instansiasinya:

· kelas “biasa”, instansnya adalah objek, siap dipakai semua featurenya

· kelas abstrak : instance bukan objek.
· deferred class : kelas yang belum seluruhnya diimplementasi

Klasifikasi kelas dari sudut pandang Booch:

· ADT : definisi type dan method
· Mesin : punya state dan behavior, pasif
· Proses: objek aktif

Klasifikasi kelas dari sudut pandang UML:

· Boundary entity
· Domain entity
· Controller

Pada metodologi ini, boundary entity merupakan objek-objek yang menjadi

antarmuka interaksi, domain entity merepresentasi persoalan yang
dimodelkan (pada saat runtime menjadi objek) sedangkan controller adalah
objek pengendali yang mengendalikan semua objek yang ada.

Klasifikasi kelas dari sudut pandang Coadd:

· Domain problem
· Interface

Klasifikasi "kelas" pada bahasa Java

· CLASS
Page 21 of 38
· Interface

Hubungan antar kelas

Antara sebuah kelas dengan kelas yang lain ada hubungan : Client-
Supplier atau inheritance.

Hubungan Client-Supplier
Pada hubungan Client-Suplier, sebuah kelas Client memakai kelas Supplier.
Hubungannya adalah hubungan “kontrak”. Supplier menyediakan sejumlah
services yang dapat dipakai oleh Client, dan menjanjikan akan memenuhi
“kontrak”, yaitu memenuhi prekondisi yang ditentukan. Client wajib
mentaati aturan (prekondisi) yang tertulis sebelum memakai services yang
disediakan oleh Supplier.
Hubungan yang lebih simple, sederhana ini lebih disarankan untuk dipakai!

Definisi :
Kelas A adalah Client dari kelas B dan B adalah Supplier dari Kelas A jika A
Mengandung definisi Entitas e: B Entitas adalah :

- atribut
- argumen formal dari rutin
- hasil evaluasi fungsi

Hubungan inheritance
Pada hubungan Inheritance, sebuah kelas turunan (descendant, heir,
child,…) mewarisi kelas leluhur (parent, …). Karena mewarisi, maka
“semua” atribut dan method kelas bapak akan “dibawa”, secara intrinsik
menjadi bagian dari kelas anak. Dalam beberapa keadaan, membawa secara
intrinsik semua atribut dan method tidak dikehendaki. Maka pemroses
bahasa menyediakan sarana untuk:
· menambah feature baru,
· mengubah atau menggantikan feature yang diwarisi ,
· menghapus feature yang diwarisi,
· menentukan feauture yang masih deferred (belum terdefinisi)
Ini menimbulkan persoalan yang tidak sederhana. Karena penghapusan
menimbulkan beberapa konsekuensi berbahaya, maka sedikit sekali
Page 22 of 38
metodologi/bahasa yang membolehkan penghapusan feature yang diwarisi.

Feature visibility dalam sebuah kelas ("scope" dalam

pemrograman prosedural):
· private, feature yang "visible" hanya untuk kelas dimana feature
tersebut didefinisikan
· protected, feature yang "disembunyikan" terhadap kelas Client,
tetapi "visible" untuk kelas turunan.
· public, feature yang "visible", dapat dipakai oleh semua kelas lain
(Client, turunan).
· friend: dalam bahasa C++, memberikan hak akses ke kelas-kelas tertentu
untuk dapat mengakses semua feature yang sebenarnya private. Ini
merupakan pelanggaran terhadap prinsip information hiding. Jadi
beberapa feature yang sebenarnya "private" diijinkan untuk menjasi
"visible" hanya untuk kelas tertentu. Sebenarnya pemakaian friend tidak
terlalu dianjurkan karena menyalahi kaidah inkapsulasi.

Visibility dari feature yang diwarisi pada kelas turunan sehubungan

dengan inheritance:
Private inheritance : semua feature yang diwarisi menjadi private dalam
kelas anak, tanpa peduli visibility pada Parent. Pemakaiannya mendukung
information hiding dan maintainability dari feauture yang diwarisi karena
dengan cara ini, perubahan pada ancestor tidak mempengaruhi anak. Tetapi,
penggunaannya harus hati-hati sebab menimbulkan nonconformity terhadap
parent, sebab apa yang visible di parent : menyalahi subtyping, spesialisasi
dan substitusi polimorfik.
Protected inheritance : semua feature yang mempunyai visibility
protected pada parent, tetap protected pada Child, sedangkan yang
public pada parents, menjadi protected pada Child.
Public inheritance : semua feature yang diwarisi mempunyai visibility yang
sama dengan visibility pada parent (jika public maka tetap public; jika private
tetap private; dst)

Jenis inheritance :
Single inheritance : sebuah kelas turunan merupakan turunan dari sebuah
kelas bapak. Jika simbol lingkaran/elips merupakan simbol sebuah kelas,
Page 23 of 38
maka hubungan inheritance digambarkan sebagai berikut [Meyer-97]. Arti
dari gambar tersebut: B mewarisi A. B adalah turunan dari A.

Multiple inheritance :sebuah kelas turunan mewarisi lebih dari satu kelas
bapak (Join)

B A

Multiple inheriance menimbulkan beberapa persoalan : jika ternyata ada

feature di kelas-kelas leluhur yang ternyata “konflik”. Konflik yang terjadi
mungkin adalah :
· konflik nama
· konflik “body” (untuk method)
Tidak semua bahasa mensupport repeated inheritance, tetapi menyediakan
mekanisme lain untuk merealisasi konsep ini.
Repeated inheritance : sebuah kelas turunan mewarisi lebih dari satu
kelas bapak, dan kelas bapak tersebut mempunyai leluhur yang sama.
A

B C

D
Page 24 of 38
Repeated inheritance menimbulkan beberapa persoalan :
· Konflik pada D, seperti halnya multiple inheriance.
· konflik pada D, jika ternyata beberapa feature di B dan C sudah
dimodifikasi

Sangat sedikit bahasa yang mensupport repeated inheritance.

Replicated repeated inheritance : Sebuah feature yang diwarisi dari
common anscestor dengan nama yang sama menjadi lebih dari satu buah
feature dalam Current Class. Jadi dalam hal ini, feature yang diwarisi muncul
lebih dari satu kali. Dalam beberapa bahasa, permogram harus mengubah
nama sehingga feature menjadi unik. Shared repeated inheritance (virtual
inheritance) : Sebuah feature yang diwarisi dari common anscestor dengan
nama yang sama menjadi hanya satu buah feature dalam Current Class. Jadi
dalam hal ini, feature yang diwarisi muncul hanya satu kali, dan dipakai
bersama.

Pemakaian inheritance perlu dikaji secara baik, dan dirancang dari awal.
Perancangan inheritance yang tambal sulam dan tidak tepat akan
menimbulkan banyak kesulitan pada saat implementasi. Pada “top level”
inheritance, biasanya dibuat kelas abstrak, yang merupakan spesifikasi dari
kelas-kelas turunannya. Makin ke “bawah”, definisi kelas menjadi makin
spesifik, dan dapat diinstansiasi menjadi objek yang “jelas”.
[Meyer-97] bahkan mendefinisikan hubungan inheritance dalam beberapa
tipologi. Buku [Webster-95] menyebutkan tiga macam hubungan antar kelas,
yaitu : has, is-a, is-implemented-using. Hubungan has dan is-implemented-
using sering dikacaukan menjadi hubungan inheritance.

Hubungan is-a adalah hubungan antara kelas general (umum) dengan

subkelas yang lebih spesifik. Ingat bahwa objek pada subkelas harus tetap
merupakan objek superkelasnya. Contoh : reptil adalah binatang.
Perhatikanlah instans dari kelas tsb: seekor cicak adalah reptile, tetapi
belum tentu semua reptile adalah cicak. Demikian pula dengan kelas :
reptile termasuk binatang, tidak semua binatang adalah reptile. Hubungan
Page 25 of 38
is-a adalah konsep inheritance.

Hubungan has-a (mempunyai) merefleksikan keseluruhan dengan

komponennya. Contoh : Sebuah mobil mempunyai mesin, mempunyai roda, ..
dst. Pemula dalam bidang OO sering mengimplementasikan hubungan ini
dengan inheritance. Yang lebih benar adalah : Kelas Mesin, Roda merupakan
data member dari kelas Mobil. Hubungan is -implemented-using
(diimplementasi menggunakan) termasuk di antara kedua hubungan itu.

Contoh : sebuah Daftar Nomor Telpon (TelponList) diimplementasi

menggunakan Notebook. Hubungan itu bukan inheritance, dan juga bukan
bagian dari. Ada banyak cara untuk melakukan impelementasi dari Daftar
nomor telpon. Bahkan perancang OO yang berpengalaman banyak yang
mengimplementasi TelponList sebagai turunan dari Notebook. Sebaiknya
TelponList "memiliki" notebook, berarti Notebook adalah data member dari
telpon List.

Page 26 of 38
 MATERI 5
UNIFIED MODELING LANGUAGE

5.1 Apa itu UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi

standar dalam industri untuk visualisasi, merancang dan mendokumentasikan
sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model
sebuah sistem.

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, C# atau
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 [1], metodologi coad [2], metodologi
OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-
brock [6], dsb. 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
bekerjasama dengan group/perusahaan lain yang menggunakan metodologi
yang berlainan.

Page 27 of 38
 Rumbaugh

Booch Jacobson

Odell OMG
(Object Management Group)

Shlaer and Mellor Meyer

Gamma

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

Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML.
Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Page 28 of 38
Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic
behavior, dan model management, bisa kita pahami dengan mudah apabila kita
melihat gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai
term yang akan muncul pada saat kita membuat diagram. Dan view adalah
kategori dari diagaram tersebut.

Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal
yang harus kita perhatikan:
1. Menguasai pembuatan diagram UML
2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-

diagram sebagai berikut:
• use case diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram

5.1 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 sistem 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.

Page 29 of 38
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya
sendiri.
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case
yang satu merupakan spesialisasi dari yang lain.

Contoh use case diagram :

5.2 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 :

1. Nama (dan stereotype)
2. Atribut
3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan
anak-anak yang mewarisinya
• Public, dapat dipanggil oleh siapa saja
Page 30 of 38
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak
yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan,
tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian
interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi

package. Kita juga dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan

class yang memiliki atribut berupa class lain, atau class yang harus
mengetahui eksistensi class lain. Panah navigability menunjukkan arah
query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan

dari class lain dan mewarisi semua atribut dan metoda class asalnya dan
menambahkan fungsionalitas baru, sehingga ia disebut anak dari class
yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari

satu class kepada class lain. Hubungan dinamis dapat digambarkan
dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Contoh class diagram :

Page 31 of 38
5.3 Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari

satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari

stimuli yang diterima. Pada umumnya statechart diagram menggambarkan

class tertentu (satu class dapat memiliki lebih dari satu statechart

diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut

membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state

umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi

yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan

sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan

berwarna setengah.

Contoh statechart diagram :

Page 32 of 38
5.4 Activity Diagram

Activity diagrams 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.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas
menggambarkan proses yang berjalan, sementara use case menggambarkan
bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Sama seperti state, standar UML menggunakan segiempat dengan sudut
membulat untuk menggambarkan aktivitas. Decision digunakan untuk
menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan
proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat
berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk
menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Contoh activity diagram tanpa swimlane:

Page 33 of 38
5.5 Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di

sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message
yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi
vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau

rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event
untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger
aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal
dan output apa yang dihasilkan.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.

Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.
Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda
dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali
dengan diterimanya sebuah message.
Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon
khusus untuk objek boundary, controller dan persistent entity.

Page 34 of 38
Contoh sequence diagram :

5.6 Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti

sequence diagram, tetapi lebih menekankan pada peran masing-masing objek
dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence number, di mana message dari level
tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang
sama.

Page 35 of 38
5.7 Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen

piranti lunak, termasuk ketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik berisi source code
maupun binary code, baik library maupun executable, baik yang muncul pada
compile time, link time, maupun run time. Umumnya komponen terbentuk dari
beberapa class dan/atau package, tapi dapat juga dari komponen-komponen
yang lebih kecil.
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang
disediakan sebuah komponen untuk komponen lain.

Contoh component diagram:

5.8 Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-

deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada
mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada
lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal

Page 36 of 38
Sebuah node adalah server, workstation, atau piranti keras lain yang

digunakan untuk men-deploy komponen dalam lingkungan sebenarnya.

Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga

didefinisikan dalam diagram ini.

Contoh deployment diagram :

5.9 Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan

aktivitas dan proses yang mungkin muncul.

2. Petakan use case untuk tiap business process untuk mendefinisikan

dengan tepat fungsionalitas yang harus disediakan oleh sistem.
Kemudian perhalus use case diagram dan lengkapi dengan requirement,
constraints dan catatan-catatan lain.

3. Buatlah deployment diagram secara kasar untuk mendefinisikan

arsitektur fisik sistem.

4. Definisikan requirement lain (non-fungsional, security dan sebagainya)

yang juga harus disediakan oleh sistem.

Page 37 of 38
5. Berdasarkan use case diagram, mulailah membuat activity diagram.

6. Definisikan objek-objek level atas (package atau domain) dan buatlah

sequence dan/atau collaboration diagram untuk tiap alir pekerjaan.
Jika sebuah use case memiliki kemungkinan alir normal dan error,
buatlah satu diagram untuk masing-masing alir.

7. Buarlah rancangan user interface model yang menyediakan antarmuka

bagi pengguna untuk menjalankan skenario use case.

8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap

package atau domain dipecah menjadi hirarki class lengkap dengan
atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat
unit test untuk menguji fungsionalitas class dan interaksi dengan class
lain.

9. Setelah class diagram dibuat, kita dapat melihat kemungkinan

pengelompokan class menjadi komponen-komponen. Karena itu buatlah
component diagram pada tahap ini. Juga, definisikan tes integrasi untuk
setiap komponen meyakinkan ia berinteraksi dengan baik.

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan

dan requirement piranti lunak, sistem operasi, jaringan, dan
sebagainya. Petakan komponen ke dalam node.

11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan
:
• Pendekatan use case, dengan meng-assign setiap use case kepada
tim pengembang tertentu untuk mengembangkan unit code yang
lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen
kepada tim pengembang tertentu.

12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta
codenya. Model harus selalu sesuai dengan code yang aktual.

13. Piranti lunak siap dirilis.

Page 38 of 38