Konsep dan Metode

Berorientasi Objek
 Kebutuhan Pengembang
Pendekatan baru dalam membangun perangkat
lunak yang menghasilkan PL yang lebih
• maintainable
• testable
• reusable
• dapat mengatasi system yang besar dan kompleks
 Kebutuhan Klien
Pendekatan baru dalam membangun perangkat
lunak yang menghasilkan PL yang lebih
• memenuhi kebutuhan fungsional
• mampu beradaptasi dengan lingkungan bisnis yang
berubah dengan cepat
• memiliki waktu proses yang cepat dan tidak boros
space
• mudah dipelihara
• dikembangkan dengan sumber daya yang minimal
(waktu/space/material/orang)
• dapat dipakai dalam jangka waktu yang lama
 Pemeliharaan PL
3 penyebab masalah pemeliharaan:
• Dekomposisi fungsional: Penambahan/pengurangan
fungsionalitas PL akan menyebabkan perubahan yang
besar pada PL bahkan arsitektur awal PL bisa menjadi
hilang.
• Modularitas yang rendah: modul-modul yang tidak
otonom (kohesiv rendah) akan mempersulit pemrogram
melakukan pengubahan pada sebuah modul.
• Visibility data yang tinggi: Data yang terlalu visible
dimana hampir setiap modul dapat mengakses data
tersebut akan mempersulit perubahan pada data.
 Keuntungan OO
• Titik berat pengembangan perangkat lunak ada di tahap
analisis tetapi mudah di bagian implementasi karena
model-model yang dihasilkan mudah diadaptasi ke dalam
program.
• Mengorganisasikan sistem berdasarkan objek dan bukan
fungsi menghasilkan model yang lebih stabil dari
perubahan yang terjadi kemudian, dan pada tahap
implementasi menghasilkan program yang lebih modular.
• Merupakan proses pengembangan berkesinambungan.
Model-model yang dihasilkan pada tahap analisis
digunakan pada tahap perancangan dan implementasi.
Tahap perancangan dan implementasi mengkonsentrasikan
pada memperbaiki model.
Konsep OOT:
Objek
• Konstruksi dasar pemodelan berorientasi objek,
merepresentasikan konsep, abstraksi, dan
benda di dunia nyata.
• Objek memiliki status, identitas, dan perilaku.
• Unit PL yang terdiri dari data dan metode
(method) untuk memanipulasi data.
• Contoh, objek: a person
identity: ’Hussain Pervez’
behaviour: speak, walk, read
states: studying, resting, unqualified
 Konsep OOT:

Kelas, Atribut, Operasi, Method

• Kelas: abstraksi dari objek-objek sejenis. Objek
merupakan instans dari kelas
• Atribut: data yang didefinisikan sebagai bagian dari
kelas/objek
• Operasi: Prosedur atau fungsi yang didefinisikan
sebagai bagian dari objek/kelas. Istilah ini digunakan
pada tahap-tahap awal pengembangan PL.
• Metode: Prosedur atau fungsi yang didefinisikan
sebagai bagian dari objek atau kelas. Istilah ini
digunakan pada tahap implementasi.
Konsep OOT:

Enkapsulasi, Information Hiding

Enkapsulasi
Konsep OO yang memandang Objek sebagai sesuatu
yang berisi data dan metode untuk memanipulasi data
tersebut.

Data Hiding
Adalah penyembunyian detil implementasi internal
data dan method/operasi dari objek-objek lain.
Information hiding mencegah perubahan program
akibat adanya sedikit perubahan pada implementasi
objek.
Konsep OOT:
Message Passing
mekanisme komunikasi antar objek dimana objek
yang mengirimkan pesan kepada objek lain agar
objek penerima menjalankan metode tertentu.
Fungsi

message
Data

Fungsi
message

Data

message

Fungsi

Data
Konsep OOT:

Pewarisan, Polimorfisme
Pewarisan
Pewarisan adalah sharing atribut dan operasi yang
sama di antara kelas-kelas yang berelasi secara
hierarki. Dikenali istilah superclass dan subclass
(kelas turunan). Keuntungan: menghindari
pengulangan properti pada pendefinisian kelas.

Polimorfisme
Mekanisme untuk menyembunyikan implementasi
yang berbeda di belakang antarmuka yang sama.
 Konsep OOT:
Relasi
• Link : relasi antar objek dimana sebuah objek berhubungan
dengan sebuah objek lainnya untuk servis tertentu.
• Asosiasi : sekelompok link dengan struktur dan semantik yang
sama. Jenis asosiasi : biner dan tersier
• Generalisasi/Spesialisasi : pewarisan
• Agregasi : bentuk khusus dari asosiasi dimana sebuah objek
(whole) berasosiasi dengan sekumpulan objek lain yang menjadi
komponennya (parts). Karakteristik :
- Transitif : jika objek A bagian dari objek B dan objek B bagian
dari objek C maka objek A bagian dari objek C.
- Anti simetris : jika objek A bagian dari objek B maka objek B
tidak bisa menjadi bagian dari objek A.
Agregasi

Assembly-parts composition
Objek whole dibangun dari objek-objek parts yang
tetap memiliki identitasnya walaupun menjadi bagian
dari objek whole. Whole tidak akan terdefinisi tanpa
part.

Contoh :
• sebuah monitor adalah bagian dari sebuah komputer
• fisika nuklir adalah bagian dari fisika
• jendela adalah bagian dari sebuah rumah
• kursi adalah bagian dari kantor
• sebuah orkestra dibangun dari berbagai instrumen musik
Agregasi

Material-object composition
Objek whole dibangun dari objek-objek parts yang
kehilangan identitasnya setelah menjadi bagian dari
objek whole.

Contoh :
• permen dibuat dari gula
• meja dibuat dari kayu
• roti dibuat dari terigu
Agregasi

Portion-object composition
Objek whole sejenis dengan objek parts
(homeomorfis).

Contoh :
Sesendok sereal adalah sebuah porsi dari semangkuk sereal
Sedetik adalah bagian dari sehari
Semeter adalah bagian dari sekilometer
 Agregasi

Place-area composition
Mendefinisikan relasi yang homeomorfis antara parts
dan whole. Place tidak bisa dipisahkan dari areanya.

Contoh :
• New York city adalah bagian dari NewYork State
• sebuah puncak adalah bagian dari sebuah gunung
Agregasi

Collection-members composition
Sama dengan place-area composition tetapi objek-
objek parts terurut menurut spesifikasi tertentu.

Contoh :
• Shift kerja bulanan terdiri dari shift kerja harian
Agregasi

Container-content composition
Mendefinisikan koleksi parts sebagai whole. Relasi
tidak homeomorfis dan dapat dihapus sementara
container dapat tetap terdefinisi walaupun tanpa
content.

Contoh :
• perusahaan – pegawai
• organisasi – anggota
Agregasi

Member-partnership composition

Mendefinisikan koleksi objek sejenis sebagai whole.

Member pada relasi ini tidak bisa dihapus tanpa
menghapus relasinya.

Contoh :
• Laurel and Hardy as a comedy team
• Booch, Rumbaugh, and Jacobson as authors of the UML
book
 Histori
• Tahun 1960-an:
– Pengembang PL mengembangkan
aplikasi-aplikasi sederhana tanpa
metoda RPL
– Aplikasi dikembangkan berdasarkan
kreativitas pengembang
– Menghasilkan “spaghetti code” dengan
banyak skema GOTO di dalamnya
 Histori PL
• Tahun 1970-an:
– Al Constantine & Ed Yourdon mencetuskan analisis –
desain terstruktur
 Menghasilkan aplikasi yang modular, dimana fungsi
sebagai pembangun PL
 Kelemahan :
• Tidak mengelola data
• Cocok untuk scientific application, tidak cocok untuk
business application
• Biaya pemeliharaan besar untuk business application
• Menghasilkan PL dengan derajat coupling yang tinggi
 Histori PL
• Tahun 1980-an:
– Peter Chen mencetuskan metoda pemodelan
data dimana data sebagai blok pembangun PL
 Alasan: data (entitas) adalah bagian PL yang stabil
• Kelemahan : menangani pengelolaan data tetapi
tidak mengelola fungsi

 Dibutuhkan metoda yang mendukung

pengembangan PL berdasarkan berbagai sudut
pandang terhadap sistem
 Metodologi Object Modeling
Technique (OMT)
• Dibuat oleh James Rumbaugh
• Memodelkan sistem ke dalam 3 buah model

1. Model objek,
Direpresentasikan dalam model objek dan kamus
data
2. Model dinamik
Digambarkan dengan state diagram
3. Model fungsional
Digambarkan dengan DFD
OMT
Tahapan
1. Analisis sistem.
Output: model objek, model dinamik, dan model
fungsional
2. Perancangan sistem.
Output: arsitektur sistem, performansi, alokasi sumber
daya, strategi antisipasi problem, dan lain-lain.
3. Perancangan objek
Output: dokumen perancangan yang berisi detil model
objek, model dinamik, model fungsional. (struktur
data, algorima, kelas-kelas baru).
4. Implementasi
Output: kode program.
OMT
Model Objek
Menggambarkan struktur objek pada sebuah sistem
meliputi identitas objek, relasinya dengan objek-objek
lain, atribut-atribut yang dimiliki, dan operasi-operasinya.

Rekening
Transaksi
Nasabah Nomor
Jumlah Mengakses Tanggal
Nama Mempunyai
Waktu
Alamat HitungJumlah Jumlah
No_KTP (jmlTrans)

Penarikan
Identitas Penyetoran
OMT
Model Dinamik
Menggambarkan interaksi antar objek pada sistem,
berbentuk graf yang node-nya merepresentasikan status
dan busurnya transisi antar status

Jumlah uang
Tidak ada Account Transaksi
telah
yang dipilih telah dipilih telah dipilih
diinputkan

Menghitung
postBalance

postBalance
telah dicetak
OMT
Model Fungsional
Digambarkan dengan DFD yang terdiri dari proses, data
flow, data store, dan entitas eksternal
 Metodologi Booch
• Menangani fase analisis dan perancangan
• Menyediakan simbol: diagram kelas, diagram objek,
diagram transisi status, diagram modul, diagram
proses, dan diagram interaksi
• Terdiri dari 2 tahap, yaitu:

- Tahap pengembangan makro

- Tahap pengembangan mikro
Booch

Proses Pengembangan Makro

1. Konseptualisasi
Menentukan tujuan dan prototype
2. Analisis dan pengembangan
Mendefinisikan kelas & objek, diagram interaksi objek
(skenario fungsi), diagram transisi status
3. Perancangan arsitektur sistem
Mendefinisikan diagram kelas/objek, diagram modul,
diagram proses
4. Evolusi/Implementasi
Merupakan proses iteratif. Output: kode program.
5. Pemeliharaan
Booch

Contoh Diagram Kelas

BangunD2
luas
keliling
hitungLuas()

Lingkaran
jari2 Segitiga
hitungLuas() alas
tinggi
hitungLuas()
Booch

Proses Pengembangan Mikro

• Setiap proses makro mempunyai proses mikro
masing-masing
• Proses mikro adalah sebuah deskripsi aktivitas
harian oleh seorang atau sekelompok kecil
pengembang
• Langkah:
1. Identifikasi kelas dan objek
2. Identifikasi semantik kelas dan objek
3. Identifikasi relasi kelas dan objek
4. Identifikasi antarmuka dan implementasi kelas
dan objek
Object Oriented Software Engineering
(OOSE)
• Dibuat oleh Ivar Jacobson
• Sering disebut juga ‘Objectory’
• Digunakan untuk pengembangan PL yang besar
dan real time
• Inti: konsep use case
• Output model:
– Model use case
– Model domain objek
– Model analisa objek
– Model implementasi
– Model test
OOSE
Use Case
• Merupakan skenario untuk memahami
kebutuhan sistem
• Menggambarkan interaksi antara pengguna
dengan sistem
• Menggambarkan tujuan dan tanggung jawab
sistem pada pengguna
• Dapat digambarkan dengan:
– Teks tanpa aliran kejadian yang jelas
– Teks dengan aliran data yang jelas
– Formal dengan pseudo code
OOSE
Use Case
• Bagaimana dan kapan use case mulai dan selesai
• Interaksi antara use case dan aktor, termasuk
kapan interaksi terjadi dan apa yang
dipertukarkan
• Bagaimana dan kapan use case menyimpan data
• Exception pada aliran kejadian
• Bagaimana dan kapan konsep persoalan
ditangani