ANALISIS DAN PEMODELAN BERORIENTASI OBJEK

MENGGUNAKAN UML

A. Pengantar ke Pemodelan Objek

Pendekatan pemodelan objek selama analisis dan desain sistem tersebut object-
oriented analysis/OOA/analisis berorientasi objek.

Object-oriented analysis (OOA) adalah pendekatan yang digunakan untuk

mempelajari objek yang sudah ada untuk mengetahui apakah mereka dapat digunakan
kembali atau diadaptasi untuk pemakaian baru, atau menentukan suatu objek baru atau yang
dimodifikasi yang akan digabung dengan objek yang sudah ada kedalam suatu aplikasi
komputasi bisnis yang sangat berharga.

Teknik analisis berorientasi objek merupakan alat terbaik yang dapat digunakan untuk
sebuah proyek yang akan mengimplementasikan sistem yang menggunakan teknologi objek
untuk membangun, mengelola, dan merakit objek-objek itu menjadi aplikasi komputer yang
berguna. Pendekatan berorientasi objek dipusatkan pada sebuah teknik yang sering disebut
object modeling/pemodelan objek.

Object modeling adalah teknik untuk mengidentifikasi objek didalam lingkungan

sistem dan mengidentifikasi hubungan antara objek-objek tersebut.

Teknik pemodelan objek menyajikan penggunaan metodologi dan notasi diagram

yang sama sekali berbeda dangan teknik lainnyayang biasa digunakan untuk pemodelan
datadan pemodelan proses. Pada akhir tahun 80-an dan awal tahun 90-an, digunakan
beberapa metode berorientasi objek yang berbeda-beda. Yang paling terkenal adalah Metode
Booch dari Grady Booch, Object Modeling Technique (OMT) dari James Rumbaugh (OMT),
dan Object Oriented Software Engineering (OOSE), dari Ivar Jacobson.

Pada tahun 1994, Grady Booch dan James Rymbaugh sepakat bergabung untuk
menggunakan metode pengembangan berorientasi objek dangan tujuan membuat proses
standar tunggal untuk mengembangkan sistem berorientasi objek. Ivar Jacobson bergabung
pada tahun 1995, dan mereka bertiga fokus membuat sebuah bahasa pemodelan objek standar
 sebagai ganti dari pendekatan atau metode berorientasi objek standar. Berdasar kerja mereka
dan hasil kerja lainnya pada industri , Unified Modeling Language (UML) versi 1.0 dirilis
pada tahun 1997. Unified Modeling Language adalah satu kumpulan konvensi pemodelan
yang digunakan untuk menentukan atau menggambarkan sebuah sistem software yang terkait
dengan objek.

UML tidak menentukan metode untuk sistem-sistem pengembangan, hanya catatan

saat ini telah diterima luasa senbagai standar untuk pemodelan objek. Object Management
Group/OMG, badan standar industri, mengadopsi UML pada bulan November 1997 dan
terus bekerja untuk meningkatkannya berdasarkan kebutuhan industri.

B. Konsep Sistem untuk Pemodelan Objek

Analisis sistem berorientasi objek didasarkan beberapa konsep. Sebagian konsep ini
membutuhkan cara pemikiran baru untuk sistem dan proses pengembangannya. Konsep
OOA memberikan tantangan besar bagi para veteran developer, yang harus belajar kembali
begaimana mereka melihat sistem itu secara tradisional.

Objek, Atribut, Metode, dan Enkapsulasi

Pendekatan berorientasi objek pada pengembangan sistem didasarkan pada konsep tentang
objek yang telah ada didalam sebuah lingkungan sistem. Perhatikan defenisi dalam Webster’s
Dictionary mengenai objek: “sesuatu yanga ada atau mampu untuk dilihat, dipegang, atau
sebaliknya dirasakan.

Object adalah sesuatu yang ada atau dapat dilihat, disentuh , atau dirasakan dan user
menyimpan data serta mencatat perilaku mengenai sesuatu itu.

Tiga aspek defenisi harus diselidiki secara lebih mendalam. Pertama, perhatikan
konteks sesuatu (something), yang dapat dikategorikan sebagai tipe objek yang mirip dengan
objek yang telah kita identifikasi di dalam lingkungan Anda saat ini. Tipe objek mungkin
termasuk orang (person), tempat, benda (thing), atau peristiwa/ kejadian(event).

Sekarang kita pelajari aspek data dalam defenisi kita. Dalam siklus berorientasi
objek, bagian defenisi ini sering disebut attibute/atribut. Attribute adalah data yang mewakili
karakteristik interes tentang sebuah objek. Pendekatan berorientasi objek pada
pengembangan sistem berhubungan dengan identifikasi atribut yang merupakan hal penting
yang terkait dengan objek. Dengan kemajuan teknologi, atribut yang lebih baru, seperti
gambar, suara, atau bahkan video.

Sekarang kita pelajari aspek defenisi objek-behavior/prilaku sebuah objek.

Behavior mewakili cara yang berbeda dalam melihat suatu objek. Behavior adalah kumpulan
dari suatu yang dapat dilakukan oleh objek dan terkait dengan fungsi-fungsi yang bertindak
pada data objek (atau atribut). Pada siklus berorientasi objek, perilaku objek merujuk kepada
metode, operasi, atau fungsi. Behvior mewakili cara yang berbeda dalam melihat suatu objek.

Jadi pendekatan berorientasi objek pada pengembangan sistem membutuhkan

penyesuaian bagaimana kita menerima objek tersebut. Prinsip lainnya yang penting dari
berorientasi objek adalah sebuah objek semata-mata bertanggung jawab terhadap fungsi-
fungsinya atau behavior yang bertindak berdasarka datanya sendiri (atau atribut). Konsep
penting dalam pemahaman objek : encapsulation/enkapsulasi. Encapsulation adalah
pengemasan beberapa item kedalam satu unit. Diterapkan pada satu objek, atribut dan
behavior objek dipaketkan bersama-sama. Mereka dipertimbangkan sebagai bagian objek itu.
Satu-satunya cara untuk mengakses atau mengubah stribut objek adalah melalui behavior
objek spesifik tersebut.
Kelas, generalisasi, dan spesialisasi

Konsep penting lain mengenai pemodelan objek adalah konsep pengkategorian objek
menjadi class/kelas. Class adalah satu objek yang memiliki atribut dan behavior yang sama.
Kadang-kadang disebut object class. Ada beberapa objek lain dalam lingkungan kita yang
dapat dikategorikan karena kemiripannya.

Bagaimana kelas digambarkan dalam pemodelan objek yang menggunakan notasi

UML? Seperti ditunjukkan dalam gambar 11-2 (b), kelas digambarkan sebagai objek yang
sangat mirip, keciuali nilai-nilai dalam atribut itu dihilangkan dan nama kelas tidak
digarisbawahi. Selain itu simbol kelas dapat dimasukkan seperangkat behavior. Seperti
ditunjukkan pada gambar 11-2 (b), untuk menyederhanakan penggambaran diagram yang
terdiri dari beberapa simbol kelas, kadang-kadang kelas digambarkan tanpa daftar behavior
dan atribut.

Level-level kelas diidentifikasi dengan menerapkan konsep inheritance/pewarisan.

Inheritance adalah konsep dimana metode dan atau atribut yang ditentukan didalam sebuah
object class dapat diwariskan atau digunakan lagi oleh objek class lainnya.

Pendekatan yang bertujuan untuk menemukan dan mengekploitasi hal-hal umum

antara objek dan kelas disebut generalization/specialization/generalisasi/spesialisasi pada
gambar 11-3(b), perhatikan bahwa kelas STUDENT dan TEACHERS terdiri dari atribut dan
behavior yang menunjukkan keunikannya (membuat kelas tersebut lebih spesial), tetapi
mereka juga punya akses ke atribut dan behavior generalisasi dari kelas PERSON melalui
inheritance (pewarisan). Generalization/ specialozation adalah sebuah teknik dimana atribut
dan behabior yang umum pada beberapa tipe kelas objek, dikelompokkan (atau diabstraksi)
kedalam kelasnya sendiri, disebut supertype. Atribut dan metode kelas objek supertype
kemudian diwariskan oleh kelas objek tersebut.

Pada contoh kita, kelas objek PERSON disebut supertype (atau kelas generalisasi)
sedangkan STUDENT dan TEACHERS disebut subtype. subtype adalah sebuah kelas objek
yang mewaiskan atribut dan behavior dari sebuah kelas supertype dan kemudian mengisikan
atribut dan behavior lain yang unik kedalamnya. Juga disebut kelas child, dan jika berada di
level terendah dari hierarki pewarisan, maka disebut kelas concrete.
Hubungan Objek/Kelas

Secara konseptual, objek dan kelas tidak dipisahkan. Hal-hala yang mereka
representasikan berinteraksi dengan dan berdampak satu dengan yang lainnya untuk
mendukung misi bisnis. Jadi, object/class relationship/hubungan objek/kelas tidak dapat
dielakkan. Object/class relationship adalah asosiasi bisnis biasa yang ada diantara satu atau
lebih objek dan kelas. Serupa dengan itu, objek berinteraksi dengan objek lain di dalam suatu
lingkungan sistem. Perhatikan, sebagai contoh, kelas objek CUSTOMER dan ORDER yang
mungkin ada dalam sistem informasi tipikal. Kita dapat membuat penonjolan bisnis berikut
ini mengenai bagaimana customer dan pesanan diasosiasikan (atau berinteraksi):

 SEORANG CUSTOMER MENEMPATKAN nol atau lebih pesanan.

 SEBUAH PESANAN DITEMPATKAN oleh satu dan hanya satu CUSTOMER.

Kita menamakan konsep konsep ini multiplicity/keanekaragaman. Multiplicity

adalah jumlah kejadian minimum dan maksimum dari satu objek/kelas untuk satu kejadian
tunggal dari objek/kelas yang terkait.
 Sekarang mari kita perhatikan jenis hubungan khusus yang mungkin ada diantara
objek dan kelas. Terkadang objek/kelas dibuat unukt objek/kelas lain. Tipe hubungan khusus
ini disebut aggregation/agregasi. Agregasi adalah hubungan dimana satu kelas “whole”
yang lebih besar berisi satu atau lebih kelas “part” yang lebih kecil. Atau, kelas “part” yang
lebih kecil adalah bagian dari kelas “whole” yang lebih besar. Kadang-kadang juga disebut
“bagian-keseluruhan” (whole-part) atau “bagian-dari” (part-of) suatu hubungan.
Dengan mengidentifikasi hubungan agregasi, kita dapat membagi objek ke dalam hal
yang paling kompleks serta menetapkan behavior dan atribut pada objek individual dengan
hubungan agregasi. Gambar 11-6 menggambarkan notasi grafis UML untuk menentukan dua
bentuk agregasi. Gambar 11-6 (a) menggambarkan tipe dasar agregasi(diidentifikasi oleh
diamond berlubang yang terkoneksi kekelas “Whole”).
Gambar 11-6 (b) adalah sebuah contoh agregasi composition / komposisi
(diidentifikasi dengan diamond berwarna hitam yang dihubungkan ke kelas “whole”).
Komposisi adalah bentuk agregasi yang kuat dimana objek “whole” sama sekali bertanggung
jawab untuk objek “part” dan objek “part” dapat diasosiasikan hanya pada satu objek
“whole”.

Pesan dan Mengirim Pesan

Objek/kelas berinteraksi atau “berkomunikasi” satu dengan lainnya dengan melewatkan

message/pesan. Ingat konsep enkapsulasinyang objeknya merupakan sebuah paket atribut
dan behavior. Hanya objek itu yang dapat melakukan behavior-nya dan bekerja pada data.
Jadi, jika anda ingin mengemankan ruangan dimana Anda duduk, objek pintu harus
melakukan behavior berikut.: tutup dan kunci . Jadi, jika YOU (sebuah objek) ingion ROOM
menjadi aman, maka YOU harus mengirim sebuah pesan kepada DOOR(sebuah objek) yang
meminta ia mengeksekusi behavior close dan lock.
 Polymorphism

Konsep penting yang berkaitan erat dengan pesan adalah polymorphism/polimorfisme.

Polymorphism secara harfiah berarti “banyak bentuk” , konsep bahwa objek yang berbeda
dapat merespons pesan yang sama dalam cara yang berbeda.

Polimorfisme diaplikasikan pada aplikasi berorientasi objek saat sebuah behavior

dalam supertype harus dikesampingkan (overridden) oleh sebuah behavior dalam subtype.
Overddide adalah teknik dimana satu sub kelas (subtype) menggunakan sebuah atribut atau
behavior miliknya daripada menggunakan atribut atau behavior yang diwariskan dari kelas
(aupertype). Selidikilah generlisasi/spesialisasi hubungan pada Gambar 11-8. Kelas
EMPLOYEE terdiri dari sebuah behavior yang dinamakan “compute pay” untuk menghitung
berapa banyak tiap EMPLOYEE akan dibayar. Karena FULL-TIME EMPLOYEE dan
PERT-TIME EMPLOYEE mendapatkan upah berbada (pekerja full-time menerima upah
tahunan dalam 52 minggu, dan pekerja part-time mendapatkan upah hanya berdasarkan jam
mereka bekerja), maka diperlukan dua behavior yang melakukan kalkulasi yang berbeda.
Tetapi karena polimorfisme, maka behavior dapat diberi nama yang sama untuk
memudahkan mengirim pesan. Subtype yang membutuhkan behavior unik akan berisi daftar
behavior yang sama dengan dengan daftar behavior untuk induknya (supertype). Saat objek
PART-TIME EMPLOYEE menerima sebuah pesan untuk “compute pey”, ia akan segara
otomatis menggunakan behavior compute-pay dalam daftar behaviornya sendiri karena ia
mengesampingkan apa yang ia warisi dari induknya. Polimorfisme sangat berguna untuk
memperbaiki sistem yang sudah untuk memenuhi persyaratan atau aturan bisnis baru
merupakan hal yang tak mungkin atau tidak praktis.

C. Diagram UML
UML menawarkan diagram yang dikelompokkan menjadi lima persfektif berbeda untuk
memodelakan suatu sistem; seperti satu set blueprint yang digunakan untuk membangun
sebuah rumah. Blueprint umumnya menyediakan perfektif mengenai plumbing, listrik
pemanasan, air conditioning, dan semacamnya, namun diagram UML menyajikan perfektif
yang berbeda mengenai sistem infprmasi. Bagian berikut menjelaskan bebagai diagram UML
serta tujuannya.
Grup 1: Diagram Model Use-Case
Diagram use-case, diperkenalkan pada Bab 7 secara grafis menggambarkan interaksi antara
sistem, sistem eksternal, dan pengguna. Dengan kata lain, secara grafis mendeskripsikan
siapa yang akan menggunakan sistem san dalam cara apa pengguna mengharapkan interaksi
dengan sistem itu. Use-case naratif digunakan untuk secara tekstual menggambarkan
sekuensi langkah-langkah dari setiap interaksi.
Grup 2: Diagram Struktur Statis
UML menawarkan dua diagram untuk memodelkan struktur sistem informasi statis, yaitu:
1. Diagram kelas menggambarkan struktur objek sistem. Diagram ini menunjukkan
kelas objek yang menyusun sistem dan juga hubungan antara kelas objek tersebut.
2. Diagram objek, memodelkan intence objek aktual dengan menunjukkan nilai-nilai
sat ini sari atribut intance.

Grup 3: Diagram Interaksi

Diagram interaksi memodelkan sebuah interaksi, terdiri dari satu set objek, hubungan-
hubungannya, dan pesan yang terkirim diantara objek. Model diagram ini memodelkan
behavior sistem yang dinamis dan UML memiliki dua diagram untuk tujuan ini, yaitu:

1. Diagram rangkaian/sekuensi secara grafis menggambarkan bagaimana objek

berorientasi dengan satu sama lain melalui pesan pada eksekusi sebuah use case atau
operasi.
2. Diagram kolaborasi serupa dengan diagram rangkaian/sekuensi, tetapi tidak fokus
pada timing atau “sekuensi” pesan. Diagram ini malahan menggambarkan interaksi
(atau kolaborasi) antara objek dalam sebuah format jaringan.

Grup 4: Diagram State (state diagram)

Diagram bagian juga memodelkan behavior dinamis dari sistem. UML memiliki sebuah
diagram untuk memodelknan behavior objek khusus yang kompleks (diagram statechart) dan
sebuah diagram untuk memodelkan bahavior dari sebuah use case atau sebuah metode, yaitu:

1. Diagram statechart, digunakan untuk memodelkan behavior objke khusus yang

dinamis.
2. Diagram sktivitas secara grafis digunakan untuk menggambarkan rangkaian aliran
aktivitas baik proses bisnis atau use case.

Grup 5: Diagram Implementasi

Diagram implementasi juga memodelkan struktur sistem informasi, yakni:

1. Diagram komponen digunakan untuk menggambarkan organisasi dan ketergantungan

komponen-komponen software sistem.diagram ini dapat digunakan untuk
menunjukkan bagaimana kode pemograman dibagi menjadi model-model (atau
komponen).
2. Diagram penguraian/deployment mendeskripsikan arsitektur fisik dalam istilah
“node” untuk hardware dan software dalam sistem. Diagram ini menggambarkan
konfigurasi komponen-komponen software run-time, processor, dan peralatan yang
membentuk arsitektur sistem.
D. Proses pemodelan objek
Analisis berorientasi objek (OOA) dilakukan untuk mendapatkan pemahaman yang lebih
baik mengenai sistem dan persyaratan fungsionalnya. Dengan kata lain, OOA mengharuskan
kita untuk mengidentifikasi kebutuhan fungsionalitas sistem dari persfektif pengguna, dan
mengidentifikasi objek, atribut data objek, behavior yang diasosiasikan, dan hubungan, yang
mendukung fungsionalitas sistem yang dibutuhkan.
Ada tiga kegiatan umum dalam melakukan analisis berorientasi objek:
1. Memodelkan fungsi sistem
2. Menemukan dan mengidentifikasi objek bisnis
3. Mengorganisasi objek dan mengidentifikasi hubungan objek

Memodelkan Deskripsi Fungsional Sistem

Dalam melakukan analisis berorientasi objek, tiap use case yang didefinisikan sebelumnya
akan diseleksi untuk memasukkan lebih banyak detail berdasarkan fakta-fakta yang telah kita
pelajari di sepanjang proses pengembangan, seperti persyaratan interface pengguna. Untuk
persiapan melakukan pemodelan objek, kita perlu memperluas model use case persyaratan
bisnis menjadi model use-case analisis.

Membangun Model Use-Case Analisis

Pada analisis berorientasi objek, kita memperluas model use-case persyaratan menjadi model
use-case analisis dengan melakukan langkah-langkah berikut:

1. Mengidentifikasi, mendefenisikan, dan mendokumentasikan pelaku-pelaku baru

antara waktu model use-case persyaratan bisnis dibuat dan waktu dimana model tersebut
disetujui oleh pemilik sistem, analisis sistem dan sebagian tim pengembang bekerjasama
dengan para stkeholder dan artifak proyek penenlitian, melanjutkan untuk mempelajari
lebih lanjut mengenai apa yang dibtuhkan supaya sistem itu berhasil. Selama usha ini
dilakukan, mungkin akan ada pelaku baru yang ditemukan sehingga pelaku bari tersebut
perlu didefenisikan daan didokumentasikan. Contohnya, saat menganalisis use case Place
Order yang diawali oleh CLUB MEMBER, kita mengidentifikasi perlunya CLUB
MEMBER untuk memasukkan informasi order melalui Internet, tetapi anggota juga dapat
menyerahkan order melalui mail. Supaya informasi order di inputkan kedalam sistem,
 maka perlu ada orang lain berinteraksi dengan sistem itu untuk melkukan hal tersebut.
Jadi, perlu pelaku lain,. Pelaku yang baru saja diidentifikasikan ini disebut member
service assiciate, dan bersama-sama dengan semua aktor bari lain, perlu didefenisikan
kedalam glosary pelaku yang sebelumnya telah disiapkan.
2. Mengidentifikasi, mendefenisikan, dan mendokumentasikan Use-Case baru pelaku
baru MEMBER SERVICE ASSOCIATE, ditemukan pada langkah 1, memandu ke
interaksi baru dengan sistem-menjadi sebuah use case baru. Seperti sebuah aturan umum
yang sudah disetujui, setiap tipe interfsce pengguna yang digunakan untuk memproses
sebuah event bisnis, akan memerlukan use casenya sendiri. Dengan menggunakan
industri bangking sebagai contoh sebagai contoh, use case pembuatan sebuah deposito
pada mesin ATM akan berbeda dengan use case pembuatan sebuah deposito yang
menggunakan bank teller. Tujuan proses ini adalah sama dan beberapa langkah akan
sama, tetapi pengguna sistem sebenarnya mungkin berbeda atau bagaimana pengguna
berinteraksi dengan sistem yang menggunakan teknologi khusus (mesin ATM versus
workstation dengan sebuah GUI yang didesain untuk bank teller) mungkin berbeda. Use
case yang diidentifikasi secara baru perlu didefenisikan dlam glossary pelaku use case
sebelumnya telah disiapkan.
3. Mengidentifikasi semua sistem Rause yang mungkin seperti dinyatakan pada langkah
2, saat anda memiliki dua use case yang memilki tujuan bisnis yang sama tetapi teknologi
interface atau pengguna sistem sebernarnya berbeda, maka kedua use case tersebut
mungkin menggunakan langkah-langkah yang sudah umum. Seperti anfda ingat dari Bab
7, untuk mengeliminasi langkah-langkah redundan, kita dapat mengekstrak langkah-
langkah umum ini menjadi use case terpisah yang disebut abstract use case. Selain itu,
saat anda menganalisis use case dan menemukan sebuah use case yang terdiri dari
beberapa langkah, sehingga sulit untuk dipahami, maka kita dapat mengekstrak langkah-
langkah yang lebih kompleks menjadi use case tersendiri yang disebut extension case.
Use case ini juga akan didefenisikan dalam glossary use case yang sebelumnya telah
disipakan.
4. Memperbaiki diagram model use caae (jika perlu) dengan ditemukannya pelaku baru
dan atau use case baru, sekarang kita akan mengupdatediagram model use case yang telah
dibuat sebelumnya untuk memesukkan item-item tersebut. Gambar 11-9 adalah diagram
 model use case yang baru saja diidentifikasi: enter New Member Order dan Appropriate
Distributon Center and Release Oerder to be Filledi.

5. Mendokumentasikan Narratif Use Case Analisis Sistem sekali semua use cases
persyaratan bisnis ditinjau kembali dan disetujui oleh para pengguan, tiap use case akan
diseleksi untuk menyertakan lebih banyak informasi untuk menentukan fungsionalitas
sistem secara mendetail. Hasil use case disebut system analisis use case/ use case
analisis sistem, dan harus bebas dari detail-detail implementasi kecuali informasi tingkat
tinggi yang mendeskripsikan peralatan (Windows GUI, Internet browser, telepon, dan
lain sebagainya) yang akan digunakan oleh pengguna sistem untuk berinteraksi dengan
sistem sistem tersebut.
System analisis use case adalah use case yang mendokumentasikan interaksi antara user
sistem dan sistem. Sangat detail dalam menggambarkan apa yang diperlukan, tetapi bebas
dari datail-detail dan batasan implementasi.
Perhatikan elemen tambahan yang ditemukan pada use case analisis sistem,
a. Tipe use-case – tipe use-case ini adalah berorientasi bisnis dan merefleksikan
sebuah tinjauan bertingkat tinggi terhadap behavior yang diinginkan dari sistem
ini. Use case ini bebas dari rinvian teknis dan dapat menyertakan baik kegiatan
manual maupun kegiatan-kegiatan yang akan diotomatiskan. Untuk merefleksikan
 rincian implemtasi seperti batasan-batasan user interface, maka diperlukan use
case taktikal yang disebut system use case yang diperoleh dari use case bisnis.
Satu atau lebih use case analisis sistem dapat dikembangkan dari satu use case
bisnis tunggal.
b. Pelaku sistem utama – pelaku sistem utama adalah stakeholder yangs ebenarnya
menggunakan dan berinterface denga subuah sistem. Untuk stakeholder inilah
interface tersebut didesain.
c. Use case abstract – contoh dari penyebutan use case abstrak.

Mendokumentasikan Naratif Use Case Abstrak dan Ekstansion mendokumentasikan

naratif use case abstrak dan ekstension serupa dengan mendokumentasikan use case regular,
tetapi ada sedikit perbedaan utama. Use case abstrack dan ekstension tidak diawali oleh para
pelaku; use case ini diminta oleh use case lain. Selain itu, use case abstrak dan ekstension
cenderung menjadi lebih pendek dan tidak memerlukan banyak field data. Perhatikan
perbedaan pada elemn naratif.

a. Tipe Use-case – sebuah use caseabstrak yang digunakan use case ini diminta oleh dua
atau lebih use case. Use case ekstension digunakan saat use case ini memperluas
fungsionalitas sebuah use case tunggal.
b. Invoked by – ID atau nama-nama use case yang meminta use case khusus ini

Pemodelan Aktivitas Use case

UML menawarkan sebuah diagram tambahan yang disebtu activity diagram/diagram

aktivitas untuk memodelkan langkah-langkah proses atau kegiatan sistem. Diagram ini
serupa dengan flowchart dimana secara grafis diagram ini menggambarkan aliran sekuensial
dari kegiatan entah itu proses bisnis atau sebuah use case. Activity diagram adalah sebuah
diagram yang dapat digunakan untuk menggambarkan secara grafis aliran proses bisnis,
langkah-langkah sebuah use case atau logika behvior (metode) object. Analisis sistem
menggunakan diagram kegiatan untuk memahami secara lebih baik aliran dan rangkaian
lengkah-langkah use case.
 1. Titik solid menggambrkan awal sebuah proses.
2. Segi empat bersudut tumpul menggambarkan sebuah kegiatan atau tugas yang perlu
dilakukan.
3. Panah menggambarkan sasaran yang mengawali kegiatan.
4. Bar hitam solid adalah sebuah bar sinkronisasi. Sombol ini memperbolehkan anda
untuk menggambarkan kegiatan yang dapat muncul secara peralel
5. Teks di dalam [ ] mengambarkan sebuah sasaran yang merupakan sebuah hasil dari
kegiatan keputusan.
6. Diamond menggambarkan sebuah kegiatan keputusan.
7. Titik solid di dalam sebuah lingkaran berlubang menggambarkan akhir sari sebuah
proses.

Panduan untuk Membangun Diagram Aktivitas daftar berikut menggambarkan

sebuah proses yang unggul untuk membangun diagram kegiatan:

 Tambah poin awal dan akhir pada sebuah use case

 Tambahkan sebuah kegiatan untuk tiap langkah uttama pada use case (atau tiap
langkah utama seorang pelaku yang menginisiasi).
 Tambahkan transisi dari setiap kegiatan ke kegiatan lain, poin keputusan, atau poin
akhir.
 Tambahkan bar sinkronisasi dimana kegiatan dilakukan secara paralel.

Menemukan dan Mengidentifikasi Objek Bisnis

Langkah yang disertakan untuk mengidentifikasi dan menemukan objek bisnis untuk
pemodelan objek selama analisis sistem.

Langkah1: menemukan objek potensial diselesaikan dengan cara meninjau setiap use case
untuk menemukan kata-kata benda yang berhubungan dengan keseluruhan bisnis atau event.

Langkah 2: menyeleksi objek yang diusulkan tidk semua kandidat (kata benda) pada
daftar kita menggambarkan objek bisnis yang ada didalam lingkup domain masalha kita.
Mengorganisir Objek dan Mengidentifikasi Hubungan Objek-Objek

Class Diagram/ diagram kelas adalah gambar grafis mengenai struktur objek statis dari
suatu sistem, menunjukkan kelas-kelas objek yang menyusun sebuah sistem dan juga
hubungan antara kelas objek tersebut. Class diagram digunakan secara grafis untuk
menggambarkan objek dan asosiasinya, pada diagram ini kita juga akan menyisipkan
multiplicity, hubungan generalisasi/ spesialisasi, dan hubungan agregasi.

Langkah 1: mengidentifikasi Asosiasi dan Multiplicity, kita perlu mengidentifikasi

asosiasi yang ada diantara objek dan kelompok. Ingat bahwa sebuah asosiasi antara dua objek
atau kelompok adalah satu objek atau kelas “perlu mengetahui” mengenai yang lain. Sangat
penting bahwa analis mengidentifikasi tidak hhanya asosiasi yang jelas atau dikenali oleh
para pengguna. Satu cara untuk membantu memastikan bahwa hubungan dapat diidentifikasi
adalah dengan menggunakan sebuah matriks objek/kelas.

Langkah 2: Mengidentifikasi Hubungan Generalisasi/ Spesialisasi sekali kita telah

mengidentifikasi dasar asosiasi dan multiplicity mereka, kita harus menentukan apakan ada
hubungan generalisasi/spesialisasi. Ingat bahwa hubungan generalisasi/spesialisasi, juga
dikenal sebagai hierarki klasifikasi atau “adalah sebuah” hubungan, yang terdiri dari
supertype kelas (abstrak atau induk) dan subtype kelas (anak atau konkret). Kelas supertipe
adalah umum karena didalamnya terdiri dari atribut umum dan behavior dari hierarki.
Hubungan generalisasi/spesialisasi dapat ditemukan dengan melihat diagram kelas.

Saat menganalisis diagram kelas, kita mengidentifikasi tiga hierarki

generalisasi/spesialisasi:
 1) Hierarki PRODUCK memperbolehkan kita melacak semua produk SoundStage yang
dapat dibeli dan memampukan kita untuk nentinya menambahkan tipe produk
berbeda, seperti BOOK TITLES.
2) Hierarki CUSTOMER yang memperbolehkan kita untuk mengirimkan promosi
khusus ke anggota yang tidak aktif untuk mendorong mereka memulai memesan
produk lagi. Juga memperbolehkan kita untuk mengidentifikasi para anggota tetap
yang mengekhiri keanggotaan mereka atau keanggotaan siapa yang diakhiri karena
rekeningnya buruk.
3) Hierarki TRANSACTION memperbolehkan kita melacak berbagai macam transaksi
CUSTOMER. Saat ini, MEMBER ORDERS, PREORDERS, dan RETUNS dicatat,
tetapi hierarki dapat dimodofikasi dengan nebyisipkan syarat TITLES untuk dimasa
mendatang.

Langkah 3: Mengidentifikasi Hubungan Agregasi pada langkah ini, kita harus

menentukan agregasi atau komposisi dasar. Ingat bahwa agrgasi adalah tipe hubungan unik
dimana satu objek satu “adalah bagian dari” objek lain. Hubungan ini sering disebut
whole/part relationship dan dapat dibaca sebagai “Objek A terdiri dari objek B dan objek B
adalah bagian dari objek A”. Hubungan agregasi adaalah asimetrik, yang didalamnya objek B
adalah bagian dari objek A tetapi objek A bukan bagian dari objek B.
Langkah 4: menyiapkan Diagram Kelas

Model ini merefleksikan asosiasi objek/kelas dan multiplicity yang diidentifikasi pada
langkah 1, tiga hubungan generalisasi/spesialisasi yang ditemukan pada langkah 2, dan satu
hubungan agregasi (komposisi) yang ditemukan pada langkah 3.perhatikan dibawah tiap
kelas muncul kata persistent. Umumnya, ini berarti objek-objek yang digambarkan oleh
kelas tersebut akan disimpan secara permanen pada sebuah database. Objek yang dibuat
secara sementara dengan sebuah program software disebut trasnsient objects

Persistent class adalah kelas yang menggambarkan sebuah objek yang mempertahankan
eksekusi program yang membuatnya.
Transient object cllas adalah kelas yang menggambarkan sebuah objek yang dibuat secara
temporer oleh program dan hidup hanya selama eksekusi program.