i

KATA PENGANTAR

Puji syukur kita panjatkan kehadirat Allah SWT. karena atas limpahan
Rahmat dan Hidayah-Nya, penulis dapat menyelesaikan Makalah dengan judul
“ANALISIS DAN PERANCANGAN SISTEM”. Salawat serta salam selalu
tercurahkan kepada Rasulullah SAW, para keluarga, sahabat-sahabat, dan para
pengikutnya sampai hari penghabisan. Makalah ini di buat bertujuan untuk
memenuhi tugas mata kuliah, dengan adanya makalah ini diharapkan dapat
bermanfaat untuk menambah pengetahuan bagi para pembaca dan dapat
digunakan sebagai salah satu pedoman dalam proses pembelajaran.

Penulis menyadari bahwa dalam penyusunan makalah ini masih terdapat

banyak kekurangan baik materi maupun penulisannya. Untuk itu penulis
berharap kritik dan saran dari pembaca yang bersifat membangun untuk
perbaikan langkah- langkah selanjutnya. Akhir kata penulis mengucapkan terima
kasih. Sesungguhnya hanya kepada Allah SWT. kita kembalikan semua, karena
kesempurnaan hanya milik Allah SWT.semat

Palopo, 9 November 2023

Gita Widi

ii
 DAFTAR ISI

KATA PENGANTAR ................................................................................................... ii

DAFTAR ISI................................................................................................................ iii
DAFTAR GAMBAR .................................................................................................... iv

BAB I PENDAHULUAN .............................................................................................. 1

BAB II PEMBAHASAN ................................................................................................ 2

2.1 Konsep Dasar OOD (Object Oriented Design) ................................................... 2

Karakteristik dari Object ....................................................................................... 5

2.2 Teknik Pemodelan dalam OOD ......................................................................... 6

Tentag Pola Desain ............................................................................................. 7

UML (Unified Modelling Language) ..................................................................... 9

Jenis-Jenis Diagram UML ................................................................................. 10

Langkah-Langkah menggunakan UML .............................................................. 14

Tool yang mendukung UML ............................................................................... 15

BAB III PENUTUP .................................................................................................... 16

3.1. Kesimpulan ....................................................................................................16

REFERENSI ............................................................................................................. 17

iii
 DAFTAR GAMBAR

1. Hubungan antara OOA dengan OOD .......................................... 5

2. Analisis Model Dan Desain .......................................................... 5
3. Interface ....................................................................................... 6
4. Objek Poligon ............................................................................... 7

1
 BAB I
PENDAHULUAN

Secara tradisional rekayasa perangkat lunak dan manajemen basis data yang
ada merupakan disiplin ilmu yang terpisah. Teknologi basis data momfokuskan pada
aspek-aspek statik media penyimpanan informasi, sedangkan rekayasa perangkat
lunak merupakan model aspek dinamik dari perangkat lunak.
Dengan adanya generasi ketiga dari sistem manajemen basis data yang
disebut Object Database Management Systems (ODBMSs), dua disiplin ilmu tadi
telah dikombinasikan untuk menyediakan modelling yang dapat berjalan bersama
yaitu data dan aksi pemrosesan terhadap data. ODBMSs sering disebut Object
Oriented DBMSs atau Object Data Management Systems.
Object oriented merupakan suatu pendekatan baru dari pembuatan perangkat
lunak yang sangat menjanjikan untuk memecahkan beberapa masalah klasik dari
pengembangan perangkat lunak. Konsep yang mendasari teknik objek ini adalah
bahwa seluruh software sebaiknya dapat dibangun melebihi standar, komponen-
komponen dapat digunakan kembali apabila dimungkinkan.
OOD mengubah model konseptual yang dihasilkan dalam analisis berorientasi
objek memperhitungkan kendala yang dipaksakan oleh arsitektur yang dipilih dan
setiap non- fungsional – teknologi atau lingkungan – kendala, seperti transaksi
throughput, response time, run – waktu platform, lingkungan pengembangan, atau
bahasa pemrograman.
Analisis dan desain berorientasi objek adalah cara baru dalam memikirkan
suatu masalah dengan menggunakan model yang dibuat menurut konsep sekitar
dunia nyata. Dasar pembuatan adalah objek, yang merupakan kombinasi antara
struktur data dan perilaku dalam satu entitas. Model berorientasi objek bermanfaat
untuk memahami masalah, komunikasi dengan ahli aplikasi, pemodelan suatu
organisasi, menyiapkan dokumentasi serta perancangan program dan basis data.
Pertama-tama suatu model analisis dibuat untuk menggambarkan aspek dasar dari
domain aplikasi, di mana model tersebut berisi objek yang terdapat dalam domain

2
aplikasi termasuk deskripsi dari keterangan objek dan perilakunya.

3
 BAB II
PEMBAHASAN

1.1 Konsep Dasar OOD (Object Oriented Design)

Desain berorientasi object adalah sebuah teknik yang memusatkan desain
pada object dan class berdasarkan pada skenario dunia nyata. Hal ini menegaskan
keadaan(state), behaviour dan interaksi dari object. Selain itu juga menyediakan
manfaat akan kebebasan pengembangan, meningkatkan kualitas, mempermudah
pemeliharaan, mempertinggi kemampuan dalam modifikasi dan meningkatkan
penggunaan kembali software.
OOD mengubah model konseptual yang dihasilkan dalam analisis berorientasi
objek memperhitungkan kendala yang dipaksakan oleh arsitektur yang dipilih dan
setiap non- fungsional – teknologi atau lingkungan – kendala, seperti transaksi
throughput, response time, run – waktu platform, lingkungan pengembangan, atau
bahasa pemrograman.
Desain berorientasi objek (object oriented design(OOD) ) mempergunakan
desain data ketika atribut direpresentasikan, desain interface ketika messaging model
dikembangkan, dan component level (procedural) design untuk desain operasi-
operasi. Translasi model OOA ke dalam model OOD dapat dilihat pada gambar.
Desain subsistem diturunkan dengan mempertimbangkan kebutuhan
customer secara keseluruhan (yang direpresentasikan dengan use-case), even dan
state yang diobservasi secara eksternal (object behavior model). Desain klas dan
objek dipetakan berdasarkan deskripsi dari atribut, operasi, dan kolaborasi yang
terdapat dalam model CRC. Desain message diturunkan dari object-relationship
model. Dan desain responsibilities diturunkan menggunakan atribut, operasi, dan
kolaborasi yang digambarkan dalam model CRC.
Ada berbagai macam metoda OOD yang dibuat, seperti Booch, Rumbaugh,
Jacobson, Coad & Yourdon dan Wirfs-Brock. Meskipun terminologi dan proses untuk
setiap metoda OOD tersebut berbeda, secara keseluruhan proses OOD termasuk
konsisten. Untuk melaksanakan object-oriented design, ada beberapa langkah
umum yang seharusnya dilakukan :
a. Gambarkan setiap subsistem dan alokasinya pada processor dan task.
b. Pilih sebuah strategi desain untuk mengimplementasikan manajemen data,
4
 interface support, dan manajemen task.
c. Desain suatu mekanisme kontrol yang tepat untuk sistem
d. Lakukan desain objek dengan membuat suatu representasi prosedural untuk
setiap operasi dan struktur data untuk setiap atribut klas.Lakukan desain
message menggunakan kolaborasi di antara objek-objek dan hubungan objek
(object relationships).
e. Buat messaging model.
f. Tinjau model desain dan ulangi jika dibutuhkan.
Dalam OOD, motivasi utama untuk mengidentifikasi Class dan Object adalah
untuk menyesuaikan gambaran teknikal dari sebuah sistem lebih dekatnya pada
gambaran conceptual dan domain implementasinya. Kata berikutnya yang
berhubungan dengan OOD adalah design dan analysis.
Analysis. Suatu practice/ kegiatan yang mempelajari sebuah domain
masalah, menuntun ke sebuah spesifikasi dari perilaku pengamatan secara
eksternal; sebuah statement/ pernyataan yang lengkap, konsisten dan bisa diterima
dari apa yang diperlukan. Sebuah ulasan dari kedua secara fungsional dan
karakteristik operasional terukur(e.g., reliability, availability, performance)
Design. Kegiatan dari pengambilan sebuah spesifikasi dari perilaku luar
yang bisa diamati dan menambahkan detail yang dibutuhkan untuk implementasi
sistem komputer terkini, termasuk interkasi antar manusia, menejemen tugas/fungsi,
dan detail manajemen data.
Desain perangkat lunak berada pada inti teknik dari rekayasa perangkat
lunak dan diaplikasikan tanpa memperhatikan model proses perangkat lunak yang
digunakan. Begitu persyaratan/ requirement pearngkat lunak telah mulai dianlisis
dan ditentukan, maka desain perangkat lunak menjadi yang pertama dari tiga
aktivitas teknik—desain, pembuatan kode, dan pengujian—yang diperlukan untuk
membangun dan menguji perangkat lunak. Masing masing aktivitas memindahkan
informasi dengan suatu cara untuk menghasilkan software komputer yang
tervalidasi. Desain berfungsi untuk menentukan bagaimana sistem beroperasi,
dalam hal ini termasuk pada hardware, software, dan infrastuktur network; user
interface, forms dan reports; dan program yang dibuat, database, dan files yang
akan dibutuhkan. Fase desain memiliki empat langkah: desain arsitektur, desain
interface, spesifikasi database dan file, dan desain program. Pada fase desain
terdapat fase merancang class dan methods individual. Sistem object-oriented bisa
5
sedikit kompleks, maka analis harus membuat intruksi dan petunjuk untuk
programer yang secara jelas menggambarkan bagaimana sistem itu bekerja.
Hubungan antara OOA, OOD dan OOP adalah: hasil pemodelan atau
pengumpulan objek dari OOA akan digunakan oleh OOD dan hasil dari OOD akan
digunakan sebagai blueprint untuk membangun sistem dengan menggunakan OOP.

Gambar 1. Hubungan antara OOA dengan OOD

Gambar 2. Analisis model dan desain

OOAD adalah metode analisis yang memerikasa requirements dari sudut

pandang kelas kelas dan objek yang ditemui dalam ruang lingkup permasalahan
yang mengarahkan arsitektur software yang didasarkan pada manipulasi objek-
objek system atau subsistem.OOAD merupakan cara baru dalam memikirkan suatu
masalah dengan menggunakan model yang dibuat menurut konsep sekitar dunia
nyata. Dasar pembuatan adalah objek,yang merupakan kombinasi antara struktur
data dan perilaku dalam satu entitas.
OOAD memandang bahwa pemodelan objek terdiri dari beberapa
prinsip, yaitu: abstraction, encapsulation, modularity, hierarchy, typing,
concurrency, dan persistence.
Untuk mengelola kompleksitas sistem object-oriented dengan menggunakan

6
prinsip antara lain[Coad and Yourdon]: 4 (empat) prinsip yang pertama, yaitu:
abstraction, encapsulation, modularity dan hierarchy merupakan prinsip utama yang
harus dimiliki oleh sebuah objek, sedangkan 3 (tiga) prinsip yang terakhir, yaitu:
typing, concurrency, dan persistence merupakan prinsip yang mendukung (optional)
ke empat prinsip utama tersebut.
OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan
objek, yaiut
analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). OOA
adalah metode analisis yang memerika requirement (syarat/keperluan) yang harus
dipenuhi sebuah sistem) dari sudut pandang kelas-kelas dan objek-objek yang
ditemui dalam ruang lingkup perusahaan. Sedangkan OOD adalah metode untuk
mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek
sistem atau subsistem.

1.2 Analisis Dan Desain Berorientasi Objek

1. Objek
Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita.
Sebuah objek memiliki keadaan sesaat yang disebut state. Objek dapat kongkrit,
seperti halnya arsip dalam sistem, atau konseptual seperti kebijakan penjadwalan
dalam multiprocessing pada sistem operasi. Dua objek dapat berbeda walaupun
bila semua nilai atributnya identik.
State dari sebuah objek adalah kondisi dari objek atau himpunan keadaan
yang menggambarkan objek tersebut. State dinyatakan dengan nilai dari atribut
objeknya.
Atribut adalah nilai internal suatu objek yang mencerminkan karakteristik
objek, kondisi sesaat, koneksi dengan objek lain dan identitas.
Behaviour (perilaku objek) mendefinisikan bagaimana sebuah objek bertindak
dan memberi reaksi. Behaviour ditentukan oleh himpunan semua atau beberapa
operasi yang dapat dilakukan oleh objek tersebut, yang dicerminkan oleh interface,
service, dan method dari objek tersebut.
Interface adalah pintu untuk mengakses service dari objek. Service adalah
fungsi yang dapat dikerjakan oleh sebuah objek. Method adalah mekanisme internal
objek yang mencerminkan perilaku objek tersebut

7
 Gambar 3. Interface
Kelas Objek
Kelas merupakan gambaran sekumpulan Objek yang terbagi dalam atribut,
operasi, metode, hubungan, dan makna yang sama. Suatu kegiatan
mengumpulkan data (atribut) dan perilaku (operasi) yang mempunyai struktur
data sama ke dalam satu grup. Kelas Objek merupakan wadah bagi Objek. Dapat
digunakan untuk menciptakan Objek. Objek mewakili fakta/keterangan dari
sebuah kelas.

Gambar 4. Objek poligon

Istilah-istilah Objek
Atribut : Data item yang menegaskan Objek.
Operasi : Fungsi di dalam kelas yang dikombinasikan ke bentuk tingkah laku
kelas.
Metode : Pelaksanaan prosedur (badan dari kode yang mengeksekusi respon
terhadap permintaan objek lain di dalam sistem).

8
 Teknik Pemodelan dalam OOD
Model Objek :
 Model objek Menggambarkan struktur statis dari suatu objek dalam sistem dan
relasinya
 Model objek berisi diagram objek. Diagram objek adalah graph dimana
nodenya adalah kelas yang mempunyai relasi antar kelas.

Model Dinamik
 Model dinamik menggambarkan aspek dari sistem yang berubah setiap saat.
 Model dinamik dipergunakan untuk menyatakan aspek kontrol dari sistem.
 Model dinamik berisi state diagram. State diagram adalah graph dimana
nodenya adalah state dan arc adalah tarnsisi antara state yang
disebabkan oleh event.
Model Fungsional
 Model fungsional menggambrakan transformasi nilai data di dalam sistem.
 Model fungsional berisi data flow diagram. DFD adalah suatu graph
dimananodenya menyatakan proses dan arcnya adalah aliran data.

Tentang Pola Desain

Setiap pola menjelaskan berulang kali terjadi di sekitar kita, juga
sebagai solusi untuk masalah inti. - Christopher Alexander. Pola desain
Perangkat Lunak menjelaskan proses desain, masalah umum kelas solusi
umum. Pola desain berorientasi objek menggambarkan proses desain
berorientasi obyek, adegan-adegan tertentu, objek kelas untuk berkomunikasi
satu sama lain antara hubungan organisasi umum.
Desain pola dan berorientasi obyek
Pola desain berorientasi objek untuk memecahkan objek "kelas untuk
berkomunikasi dengan setiap hubungan lain antara organisasi, termasuk peran
mereka, tanggung jawab, beberapa aspek pendekatan kolaboratif. Pola desain
berorientasi objek adalah "desain berorientasi objek yang baik", yang disebut
"desain berorientasi obyek yang bagus," yang memenuhi jawaban "untuk
mengubah, memperbaiki ulang" desain. Perangkat lunak berorientasi objek pola
desain menggambarkan desain, sehingga tidak tergantung pada bahasa
pemrograman, pola desain berorientasi obyek, tetapi implementasi akhir masih
menggunakan bahasa pemrograman berorientasi objek untuk mengekspresikan.

9
 Algoritma untuk teknik berorientasi objek seperti pola desain, Anda dapat
menyalin foto yang digunakan, didasarkan pada "object-oriented," terampil dan
pemahaman mendalam tentang dasar pengetahuan empiris. Pegang premis pola
desain berorientasi obyek adalah yang pertama untuk menguasai "berorientasi
objek!"
Dari pemahaman intuitif bahasa pemrograman berorientasi obyek antara
berbagai bahasa pemrograman berorientasi obyek yang berbeda, tetapi mereka
dapat melihat tiga mekanisme utama dukungan berorientasi objek, yaitu:
"enkapsulasi, pewarisan, polimorfisme,"
- Paket, pelaksanaan internal yang tersembunyi
- Warisan, menggunakan kembali kode yang sudah ada
- Multi-state, ditulis ulang objek perilaku

Pembungkusan
Dalam istilah berorientasi-objek, pembungkusan berkaitan dengan
penyembunyian informasi. System-sistem yang tidak berorientasi-objek
berdasarkan pada rutin dan subprogram yang berbagi-pakai data global, atau
yang menerima data yang dikirimkan oleh pemanggil.Pendekatan berorientasi-
objek, di pihak lain, mengadopsi konsep bahwa

data dan fungsi mestinya dipaketkan bersama ke dalam sebuah kapsul

tunggal. Bentuk kelas ini melayani maksud tersebut. Sebuah kelas terdiri dari
elemen data dan elemen

pemrosesan. Elemen data sebuah kelas disebut attribute, dan operasi

pemrosesan disebut metodenya. Atribut dan metode merupakan anggota kelas:
atribut adalah anggota data dan metode adalah fungsi anggota.
Maksud enkapsulasi disini adalah menyembunyikan detail implementasi
sementara memusatkan pada antarmuka. Tujuannya adalah membuat sebuah
abstraksi yang memaksa programmer berpikir secara konseptual. Biasanya,
anggota – anggota data dari sebuah kelas terlihat oleh penggunanya. Jika
sebuah anggota data harus dibuat agar dapat diakses oleh client kelas, maka
kelas tersebut menyediakan sebuah metode yang memeriksanya dan
mengembalikan nilainya. Saat sebuah kelas mengekspos anggota data, ia
dikatakan memecahkan enkapsulasi.

10
2. Pewarisan
pewarisan adalah keuntungan besar dalam pemrograman berbasis object
karena suatu sifat atau method didefinisikan dalam superclass, sifat ini secara
otomatis diwariskan dari semua subclasses. Jadi, Anda dapat menuliskan kode
method hanya sekali dan mereka dapat digunakan oleh semua subclass.
Dari konsep penurunan ini suatu kelas bisa diturunkan menjadi kelas baru
yang masih mewarisi sifat-sifat kelas orangtuanya. Hal ini dapat dianalogikan
dengan kelas manusia. Manusia merupakan turunan dari orang tuanya dan sifat-
sifat orang tua diwarisi olehnya. Bisa ditarik kesimpulan bahwa semua kelas di
dunia selalu memiliki hirarki yang menggambarkan silsilah kelas tersebut.
3. Polimorfisme
Polimorfisme (polymorphism) erat kaitannya dengan Pewarisan.
Polimorfisme adalah pemikiran bahwa objek dinamis suatu kelas dasar dapat
berperilaku seperti kelas turunan. Ketika objek tersebut menunjuk kelas dasar,
objek tersebut berperilaku seperti kelas dasar, tetapi ketika objek tersebut
menunjuk kelas turunan, objek tersebut berperilaku seperti kelas turunan. Dalam
hal ini objek dapat memiliki beberapa bentuk, tergantung pada saat itu kelas
mana yang ditunjuk. Yang perlu menjadi catatan, bahwa perubahan perilaku ini
dari kelas dasar kepada kelas turunan, tidak dapat objek kelas turunan menunjuk
kelas dasar.
Polimorfisme dimungkinkan karena adanya mekanisme ikatan dinamis
(dynamic binding). Ikatan dinamis adalah ikatan yang terjadi pada saat program
dijalankan (run-
time). Ikatan yang terjadi pada saat kompile disebut ikatan statis. Ikatan
dinamis hanya dapat terjadi antara suatu objek dinamis dengan metode yang
dinamis juga, dalam hal ini metode virtualnya (maya).
1.3 UML (Unified Modelling Language)
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
11
 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, metodologi coad, metodologi OOSE,

metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, 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.

Jenis-jenis Diagram UML :

A. 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.

12
 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 . 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.

B. 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 yangmewarisinya

Public , dapat dipanggil oleh siapa saja

13
 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

- 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 m enunjukkan arah query antar class .

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

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

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.

C. 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

14
 berwarna penuh dan berwarna setengah.

D. 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.

E. 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

15
 desain
berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation baru 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 .

F. 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.

G. 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.

H. 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 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.
16
Langkah-Langkah Penggunaan UML
Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

- Buatlah daftar business process dari level tertinggi untuk mendefinisikan

aktivitas dan proses yang mungkin muncul.

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

- Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik

sistem.

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

yang juga harus disediakan oleh sistem.

- Berdasarkan use case diagram , mulailah membuat activity diagram .

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

- Buatlah rancangan user interface model yang menyediakan antarmuka bagi

pengguna untuk menjalankan skenario use case .

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

package atau domain d ipecah 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.

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

- Perhalus deployment diagram yang sudah dibuat. Detilkan

kemampuan dan requirement piranti lunak, sistem operasi, jaringan,

17
 dan sebagainya. Petakan komponen ke dalam node.

- 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.
Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool
komersial maupun opensource. Beberapa diantaranya adalah:

- Rational Rose (www.rational.com)

- Together (www.togethersoft.com)

- Object Domain (www.objectdomain.com)

- Jvision (www.object-insight.com)

- Objecteering (www.objecteering.com)

- MagicDraw (www.nomagic.com/magicdrawuml)

- Visual Object Modeller (www.visualobject.com)

Diagram use case adalah representasi grafis dari interaksi antara sistem
dan aktor-aktor yang berpartisipasi dalam suatu sistem atau proses
bisnis. Diagram ini digunakan dalam analisis dan perancangan sistem
untuk memodelkan fungsionalitas yang diinginkan dari perspektif
pengguna atau aktor.
Berikut adalah elemen-elemen utama dalam diagram use case:
1. Aktor: Aktor adalah entitas eksternal yang berinteraksi dengan
sistem. Aktor dapat berupa pengguna manusia, perangkat keras, atau
sistem lain yang berinteraksi dengan sistem yang sedang dianalisis.
Aktor tidak terlibat dalam proses internal sistem, tetapi mempengaruhi

18
 atau menerima pengaruh dari sistem. Aktor direpresentasikan
sebagai bentuk persegi panjang dalam diagram.
2. Use Case: Use case adalah suatu fungsi atau tugas yang dapat
dilakukan oleh sistem. Use case adalah representasi dari satu tugas
atau fitur yang diinginkan oleh aktor dalam sistem. Use case
direpresentasikan sebagai bentuk oval dalam diagram.
3. Hubungan Antara Aktor dan Use Case: Garis panah yang
menghubungkan aktor dengan use case menunjukkan keterlibatan
aktor dalam use case tertentu. Ini menunjukkan bahwa aktor tertentu
terlibat dalam eksekusi atau penggunaan fitur atau tugas tersebut.
4. Hubungan Antara Use Case: Garis hubungan antara use case
menunjukkan keterkaitan atau hubungan antara berbagai use case
dalam sistem. Ini dapat mengindikasikan urutan atau hubungan logis
antara use case.
5. Include Relationship: Hubungan "include" menunjukkan bahwa satu
use case membutuhkan atau memasukkan fungsionalitas dari use
case lain. Use case yang memasukkan fungsionalitas disebut use
case induk, sementara use case yang memberikan fungsionalitas
disebut use case inklusi.
6. Extend Relationship: Hubungan "extend" menunjukkan bahwa satu
use case dapat memperluas atau mengembangkan fungsionalitas
dari use case lain. Use case yang memperluas fungsionalitas disebut
use case induk, sementara use case yang diperluas disebut use case
ekstensi.
7. Diagram use case membantu dalam memahami kebutuhan pengguna
dan fungsionalitas sistem dari sudut pandang pengguna. Ini adalah
alat yang berguna dalam analisis dan perancangan sistem karena
memungkinkan tim pengembangan untuk fokus pada apa yang harus
dicapai oleh sistem dan bagaimana pengguna akan berinteraksi
dengannya.

19
 BAB III
PENUTUP

3.1. Soal Beserta Jawaban

Berikut adalah 10 pertanyaan dan jawaban yang dapat diambil dari materi "Teknik
Pemodelan dalam OOD dan UML":

1. Pertanyaan: Apa yang dimaksud dengan Desain Berorientasi Objek (OOD) dan
mengapa penting dalam pengembangan perangkat lunak?

Jawaban: Desain Berorientasi Objek (OOD) adalah sebuah teknik yang memusatkan
desain pada object dan class berdasarkan skenario dunia nyata. Penting dalam
pengembangan perangkat lunak karena memungkinkan representasi yang lebih dekat
dengan domain implementasi, meningkatkan kebebasan pengembangan,
mempermudah pemeliharaan, dan meningkatkan penggunaan kembali software.

2. Pertanyaan: Bagaimana langkah-langkah umum yang seharusnya dilakukan untuk

melaksanakan object-oriented design?

Jawaban: Langkah-langkah umum meliputi:

a. Gambarkan setiap subsistem dan alokasinya pada processor dan task.
b. Pilih strategi desain untuk mengimplementasikan manajemen data, interface support,
dan manajemen task.
c. Desain suatu mekanisme kontrol yang tepat untuk sistem.
d. Lakukan desain objek dengan membuat representasi prosedural untuk setiap operasi
dan struktur data untuk setiap atribut kelas.
e. Buat messaging model.
f. Tinjau model desain dan ulangi jika dibutuhkan.

3. Pertanyaan: Apa hubungan antara Object-Oriented Analysis (OOA), Object-Oriented

Design (OOD), dan Object-Oriented Programming (OOP)?

Jawaban: Hasil pemodelan atau pengumpulan objek dari OOA digunakan oleh OOD,
dan hasil dari OOD digunakan sebagai basis untuk OOP.
20
4. Pertanyaan: Apa itu Unified Modeling Language (UML) dan mengapa digunakan
dalam pengembangan perangkat lunak?

Jawaban: UML adalah bahasa standar industri untuk visualisasi, merancang, dan
mendokumentasikan sistem perangkat lunak. Digunakan untuk membuat model sistem
secara grafis dan memberikan representasi yang jelas dari berbagai aspek
pengembangan perangkat lunak.

5. Pertanyaan: Apa peran Model Objek dalam Object-Oriented Design?

Jawaban: Model Objek menggambarkan struktur statis dari objek dalam sistem dan
relasinya. Ini termasuk diagram objek yang merupakan graph dengan node kelas yang
memiliki relasi antar kelas.

6. Pertanyaan: Jelaskan konsep Enkapsulasi dalam berorientasi objek.

Jawaban: Enkapsulasi berkaitan dengan penyembunyian informasi dalam berorientasi

objek. Data dan fungsi dipaketkan bersama ke dalam kapsul tunggal, menciptakan
abstraksi yang memaksa pemrogram berpikir secara konseptual.

7. Pertanyaan: Apa itu Pewarisan dalam berorientasi objek dan mengapa itu penting?

Jawaban: Pewarisan adalah keuntungan besar dalam pemrograman berbasis objek

karena sifat atau metode yang didefinisikan dalam superclass secara otomatis
diwariskan oleh semua subclasses. Ini mendukung penggunaan kembali kode.

8. Pertanyaan: Apa yang dimaksud dengan Polimorfisme dalam berorientasi objek?

Jawaban: Polimorfisme adalah pemikiran bahwa objek dari suatu kelas dasar dapat
berperilaku seperti kelas turunan. Objek dapat memiliki beberapa bentuk tergantung
pada kelas mana yang ditunjuk.

9. Pertanyaan: Bagaimana Desain Pola (Design Patterns) terkait dengan berorientasi

objek?

Jawaban: Desain Pola menggambarkan solusi untuk masalah umum dan menjelaskan
proses desain berorientasi objek. Pola desain berorientasi objek memodelkan desain

21
dan menggambarkan solusi umum untuk masalah kelas.

10. Pertanyaan: Apa fungsi dari Diagram Use Case dalam UML?

Jawaban: Diagram Use Case dalam UML adalah representasi grafis dari interaksi antara
sistem dan aktor-aktor yang berpartisipasi dalam suatu sistem atau proses bisnis. Ini
membantu dalam memodelkan fungsionalitas dari perspektif pengguna atau aktor.

22
 REFERENSI

Booch Grady, et al. Object Oriented Analysis & Design With Applications,
3rd Edition.2007.Pearson Education
http://aimyaya.com/id/komputer/desain-berorientasi-objek/
http://eprints.ums.ac.id/778/1/Emitor_RNR_CaseTool.pdf
http://tanzir.staff.gunadarma.ac.id/Downloads/files/6970/OOSysDev.ppt
http://www.softcov.com/id/design-and-optimization/object--oriented-design-
patterns-and- principles-1.html
http://id.wikipedia.org/wiki/UML
http://sa3o.net/ringkasan-tentang-
ooad/
http://iirc.ipb.ac.id/jspui/bitstream/123456789/17981/1/G08rha_abstract.pdf
http://www.softcov.com/id/design-and-optimization/object-oriented-relational-
database- design.html
http://bimoananto.students-blog.undip.ac.id/
http://adesta2008.wordpress.com/
http://repository.usu.ac.id/bitstream/123456789/16461/5/Chapter%
20I.pdf http://ariefnote.blogspot.com/2009/03/diagram-object-object-
oriented.html
http://www.softcov.com/id/design-and-optimization/new--perspective-on-object-oriented-
design.html
ratih.staff.gunadarma.ac.id/Downloads/files/.../OBJECT+ORIENTED.ppt
ayuliana_st.staff.gunadarma.ac.id/.../Pertemuan+07+-
++(OOA+and+OOD+Testing).pdf http://wibisoni.students-
blog.undip.ac.id/2010/02/09/object-oriented-design-and- quality-software/
http://zulvani.wordpress.com/2010/08/16/metodologi-booch%E2%80%99s-object-
oriented- analysis-design-ooad/
lecturer.eepis-
its.edu/~arna/.../8.%20Desain%20Object%20Oriented.pdf
http://dewa-hendra.blogspot.com/2010/04/i.html
http://blog.unsri.ac.id/destyrodiah/object-oriented-analysis-design-ooad/resume-
ooad/pdf/7415/ http://sa3o.net/ringkasan-tentang-ooad/
http://trista-dears.blogspot.com/2010/05/object-oriented-database-ood.html
23
http://saiiamilla.wordpress.com/2010/06/04/ooad-object-oriented-analysis-dan-design/
http://logsmylife.wordpress.com/2010/04/28/konsep-dasar-object-oriented-programming-
oop-di- java/

24