10/15/2007

ƒ OMT = Object Modeling Technique, 
merupakan salah saru object‐oriented 
(software engineering) methodology.
ƒ Metodologi : proses untuk menghasilkan PL 
terorganisir dengan menggunakan sejumlah
Oleh teknik dan konversi notasi yang terdefinisi.
Ir. I Gede Made Karma, MT
ƒ Merupakan sebuah proses iteratif.

ƒ Terdiri dari beberapa fase : ƒ 3 sudut pandang (model) OMT :

ƒ Analysis : memahami dan memodelkan aplikasi
dan ranah tempatnya beroperasi.
ƒ System Design : arsitektur sistem keseluruhan
(lojik).
ƒ Object Design : penerjemahan konsep‐konsep
aplikasi kepada konsep komputer (fisik)
1. Object Model : objek pada sistem dan
keterhubungannya.
2. Dynamic Model : reaksi objek pada sistem
terhadap event dan interaksi antar objek.
3. Functional Model : transformasi nilai (status) 
objek dan batasan transformasinya.

ƒ Tujuan
Menghasilkan model dunia nyata yang benar, 
dapat dipahami, padat, dan tepat.
ƒ Masukan/Sumber
k b
ƒ Requirement yang diberikan user (TOR – term of 
reference, RFP – request for proposal, dll).
ƒ Tambahan requirement (asumsi) dari pihak
pengembang (developer) sendiri atau manajer.

MBO - OMT : Ir. I Gede Made Karma, MT

1
 10/15/2007

ƒ Untuk membangun object model ƒ Terdiri dari beberapa langkah yang dilakukan

ƒ Object model = struktur data statis dari objek
sistem dunia nyata dan hubungan antar
objeknya.
ƒ Tujuan object model pada fase analysis adalah
komunikasi antara pengembang dengan ahli
pada ranah aplikasi (application‐domain  6. Verifikasi jalur akses untuk query (alamiah)
expert).
secara iteratif :
1. Identifikasi objek dan kelasnya.
2. Siapkan kamus data.
3. Identifikasi asosiasi antar objek (termasuk agregasi).
4. Identifikasi atribut dari objek dan link (alamiah)
5. Atur dan sederhanakan kelas objek dengan konsep
pewarisan (inheritance)
7. Iterasi dan perhalus model
8. Kelompokkan kelas‐kelas pada modul‐modul.

ƒ Identifikasi objek‐objek yang terkait

ƒ Identifikasi kelas‐kelas dari objek‐objek yang 
relevan.
ƒ Kelas
l yang diidentifikasikan
d d f k k adalahd l h kelas
k l
pada ranah aplikasi :
ƒ eksplisit pada problem statement
ƒ Implisit pada ranah aplikasi atau pengetahuan
atas ranah.

ƒ Abaikan kelas objek yang tidak tepat, karena ƒ Penjelasan untuk setiap kelas objek yang 
teridentifkasi
ƒ redudan ƒ Mencantumkan dan menjelaskan :
ƒ tidak relevan ƒ Lingkup/peran kelas pada sistem
ƒ samar ƒ Asumsi
ƒ Batasan
ƒ lebih tepat berupa atribut ▪ Pada keanggotaan objek
ƒ lebih tepat berupa operasi ▪ Pada penggunaan
ƒ Asosiasi
ƒ lebih tepat berupa peran
ƒ Atribut
ƒ lebih merupakan konstruksi implikasi ƒ Operasi

MBO - OMT : Ir. I Gede Made Karma, MT

2
 10/15/2007

Contoh ƒ Identifikasi asosiasi = kebergantungan antara

ƒ Account
satu kelas atau lebih.
ƒ Asosiasi dapat berbentuk :
▪ Adalah suatu rekening pada bank tempat suatu
transaksi
t k i diterapkan.
dit k ƒ Lokasi fisik (misal: next to, part of, contained in)
▪ Batasan keanggotaan: ƒ Aksi terarah (misal : drives)
▪ Checking account ƒ Komunikasi (misal: talks to, reports to)
▪ Saving account ƒ Kepemilikan (misal: has, part of)
▪ Asosiasi: ƒ Pemenuhan kondisi (misal: works for, married to, 
▪ Satu nasabah dapat punya lebih dari satu account. manages)
ƒ Agregasi adalah asosiasi dengan konotasi khusus: 
hubungan part‐whole atau part‐of.

ƒ Abaikan asosiasi yang tidak tepat, karena : ƒ Tambahkan semantik asosiasi:

ƒ Asosiasi antara kelas yang diabaikan ƒ Penamaan asosiasi yang salah Æ what not how
ƒ Asosiasi implementatif atau tidak relevan ƒ Penambahan nama peran
ƒ Asosiasi berupa aksi ƒ Penambahan asosiasi berkualifikasi
ƒ Asosiasi ternary Æ asosiasi binary atau asosiasi ▪ membedakan objek pada sisi ‘many’ dari asosiasi
qualified. ƒ Penambahan multiplicity
ƒ Asosiasi turunan ƒ Penambahan asosiasi yang belum terdefinisi
sebelumnya.

ƒ Identifikasi atribut objek dan atribut link
ƒ Atribut = ciri dari sebuah objek
ƒ Atribut bukan objek
ƒ gunakan asosiasi bila ciri objek adalah objek lain.
ƒ Nyatakan bila atribut adalah atribut turunan
(misal: age =to‐date – birth of date)
ƒ Abaikan atribut yang tidak tepat karena:
ƒ Berupa objek
ƒ Berupa qualifier
ƒ Berupa nama
ƒ Berupa identifier pada implementasi
ƒ Menyatakan status internal objek
ƒ Minor atau atribut yang sangat detail
ƒ Bertentangan dengan atribut lain Æ pemisahan
kelas menjadi dua kelas yang berbeda.

MBO - OMT : Ir. I Gede Made Karma, MT

3

ƒ Pewarisan didapat dari dua arah:
ƒ Generalisasi aspek‐aspek yang sama dari sejumlah
kelas menjadi kelas‐super (bottom‐up)
ƒ Penghapusan
g p j sub‐kelas yyang 
sebuah kelas menjadi g
lebih khusus – spesialisasi (top‐down)
ƒ Multiple inheritance
ƒ Mempertinggi kompleksitas konsep dan
implementasi
ƒ Dasar pewarisan:
ƒ Ciri objek
ƒ Asosiasi yang sama
ƒ Proses iterasi diperlukan untuk memastikan
kebenaran dan kelengkapan model Æ
menguji ulang/silang model
ƒ Kriteria pemodelan ulang:
ƒ Tanda‐tanda perlu penciptaan objek baru:
▪ Asosiasi & generalisasi asimetris
▪ Atribut/operasi yang bertentangan/berlainan
▪ Operasi tanpa kelas target
▪ Duplikasi asumsi
▪ Peran yang menentukan semantik kelas
ƒ Modul = sejumlah kelas (terdiri dari satu atau
lebih lembar gambar diagram) yang menangkap
subset lojik dari keseluruhan model sistem.
ƒ Cari cut‐point
cut point (bridge) class:
(bridge) class
ƒ Kelas yang merupakan satu‐satunya hubungan antara
dua sub‐sistem.
ƒ Batasan antar modul:
ƒ Konsep ranah aplikasi
ƒ Minimasi kelas jembatan
▪ Jumlah hubungan/asoisasi antar kelas
MBO - OMT : Ir. I Gede Made Karma, MT
10/15/2007
ƒ Mencoba menjawab pertanyaan (query) dari
perunutan akses lewat asosiasi‐asosiasi yang 
ada.
ƒ Kemungkinan perlu menciptakan objek baru
ƒ Tanda‐tanda kelas yang tidak perlu:
▪ Tidak punya atribut, operasi dan asosiasi.
ƒ Tanda‐tanda perlu asosiasi baru:
▪ Jalur akses untuk operasi kurang.
ƒ Tanda‐tanda asosiasi yang tidak perlu:
▪ Informasi redudan pada asosiasi
▪ Tidak ada operasi yang menggunakan asosiasi
ƒ Tanda‐tanda penempatan asosiasi yang salah:
▪ Nama peran terlalu luas/sempit untuk kelas
ƒ Tanda‐tanda penempatan atribut yang salah:
▪ Perlu mengakses objek dengan nilai atributnya Æ qualified 
association
ƒ Untuk membangun dynamic model
ƒ Dynamic model = kelakuan sistem yang 
bergantung pada waktu dan objek‐objek
yang ada
d pada
d sistem tersebut.
b
ƒ Tahapan umum:
ƒ Pencarian event – stimuli dan responses eksternal
yang nyata.
ƒ Menyusun urutan event untuk tiap objek dengan
state diagram.
4

ƒ Terdiri atas beberapa langkah yang dilakukan
secara iteratif:
1. Persiapkan skenario dari urutan interaksi tipikal.
2. Identifikasi event antar objek.
3. Persiapkan event trace untuk tiap skenario.
4. Bangun state diagram.
5. Verifikasi konsistensi dengan mencocokkan
event antar objek.
ƒ Event adalah :
1. Event eksternal (sinyal, input, keputusan, interupsi, 
transisi, aksi) yang berasal atau menuju pengguna
dari piranti eksternal.
2. Aksi yang dilakukan sebuah objek uang
menyampaikan informasi : interaksi/operasi objek ke
objek.
ƒ Buat :
ƒ Event‐trace untuk setiap skenario : interaksi antar
objek (termasuk agen eksternal) berupa event yang  ƒ
terurut waktu.
ƒ Diagram event‐flow : rekapitulasi interaksi antar
objek.
ƒ Gabungkan semua state diagram kelas
menjadi satu state diagram :
ƒ Pencabangan event dari satu state
ƒ Penggabungan event menuju satu state
ƒ Penggabungan state
ƒ Uji kelengkapan dan konsistensi sistem saat
semua state diagram kelas selesai
ƒ Tiap event harus punya pengirim maupun
penerima.
MBO - OMT : Ir. I Gede Made Karma, MT
10/15/2007
ƒ Skenario = urutan kejadian yang mungkin
terjadi.
ƒ Dua macam skenario yang harus dibuat :
1. Skenario normal : urutan interaksi tanpa kesalahan
input atau
i t  t kondisi.
k di i
2. Skenario eksepsional : urutan interaksi yang 
memiliki ketidaklengkapan, penanganan nilai
maksimum/minimum, penanganan nilai berulang‐
ulang, dsb.
ƒ Identifikasi pula aktor (sistem, pengguna, atau
agent eksternal lain) yang mengakibatkan
kejadian terjadi dan parameter kejadian
tersebut.
ƒ State diagram dibuat untuk tiap objek (kelas) 
yang memiliki kelakuan dinamis Æ iteratif.
ƒ Memperlihatkan event yang diterima dan
dk
dikirim oleh
l h objek
b k tersebut, dibangun
b db
berdasarkan event‐trace.
ƒ Interval antar dua event adalah state.
Tidak semua kelas perlu state diagram.
ƒ Dibuat berdasarkan semua skenario : normal 
dan eksepsional.
ƒ Memperlihatkan bagaimana nilai‐nilai objek
dihitung tanpa memperhatikan urutan, 
keputusan, atau struktur objek.
ƒ Proses padad data flow diagram (DFD) adalah
d fl d d l h
aktifitas atau aksi yang ada pada state 
diagram kelas.
ƒ Data flow pada DFD adalah nilai objek atau
atribut pada object diagram.
5

ƒ Terdiri dari beberapa langkah yang dilakukan
secara iteratif :
1. Identifikasi nilai masukan dan keluaran
2. Bangun DFD
3. Jelaskan fungsi‐fungsi
4. Identifikasi batasan (constraint)
5. Spesifikasikan kriteria optimasi.
ƒ System Design = strategi aras tinggi untuk
menyelesaikan persoalan dan membangun
solusi.
ƒ Menentukan
k gaya arsitektur
k dand arsitektur
k
sistem keseluruhan.
ƒ Pembagian sistem solusi atas komponen‐komponen
yang lebih kecil yang disebut sebagai subsistem‐
subsistem.
ƒ Sub‐sistem = sebuah paket berisi kelas‐kelas beserta
asosiasi, operasi, event, dan
i i  i  t  d batasan
b t lainnya
l i yang  
berkaitan dan mempunyai antarmuka yang wajar dan
terdefinisi dengan sub‐sistem lainnya.
ƒ Sub‐sistem ditandai dengan service yaitu kumpulan
fungsi yang mempunyai tujuan serupa.
ƒ Suatu sistem dibagi atas beberapa sub‐sistem, tiap
sub‐sistem dapat mempunyai sub‐sistemnya sendiri
pula Æ paling kecil = modul.
MBO - OMT : Ir. I Gede Made Karma, MT
10/15/2007
ƒ Operasi‐operasi untuk melengkapi tiap objek
diidentifikasi setelah 3 model terbentuk.
ƒ Operasi tersebut berasal dari:
ƒ Object model: pembacaan & penulisan nilai atribut
dan
d tuntutan
t t t asosiasi.
i i
ƒ Event: event yang dikirimkan ke suatu objek menjadi
operasi pada objek tersebut.
ƒ State actions/activities: menjadi fungsi
ƒ Functions pada DFD
ƒ Shopping List Operation: fungsi‐fungsi yang berasal
dari kelakukan dunia nyata (alamiah)
ƒ Penyederhanaan operasi : 
ƒ pembentukan struktur pewarisan
Perancang harus menentukan keputusan atas :
1. Organisasi sistem dalam sub‐sistem
2. Identifikasi konkurensi alamiah persoalan
3
3. Alokasi sub‐sistem pada prosesor dan task
4. Pemilihan ancangan manajemen penyimpanan data
5. Penanganan akses sumber daya global
6. Pemilihan implementasi kontrol pada perangkat
lunak
7. Penanganan kondisi batas
8. Penentuan prioritas pengorbanan (trade‐off)
ƒ Pola hubungan antara dua sub‐sistem:
ƒ Client‐supplier (client‐server)
▪ Client memanggil supplier yang menjalankan layanan
tertentu dan memberikan hasil kembali ke client.
client
▪ Client harus tahu antarmuka supplier.
ƒ Peer‐to‐peer
▪ Tiap sub‐sistem dapat memanggil sub‐sistem lainnya
▪ Tiap sub‐sistem mengetahui antarmuka sub‐sistem lainnya.
ƒ Pola hubungan client‐supplier memperkecil
tingkat kompleksitas.
6
 10/15/2007

ƒ Pola dekomposisi sub‐sistem: ƒ Partisi

ƒ Lapisan ▪ Membagi subsistem secara vertikal
▪ Membagi subsistem secara horizontal ▪ Jenis layanan yang berbeda‐beda
▪ Lapisan bawah merupakan basis implementasi lapisan ƒ Topologi sistem
atasnya.
▪ Pembagian subsistem sesuai dengan suatu pola
▪ Subsistem tahu tentang layanan di lapisan bawahnya
tertentu:
tetapi tidak tahu di lapisan atasnya.
▪ Star
▪ Terdapat dua bentuk
▪ Pipeline, dll.
▪ Close architecture: tiap lapisan dibangun atas dasar lapisan di
bawahnya langsung.
▪ Open architecture: tiap lapisan dapat menggunakan layanan
lapisan di bawahnya sampai sedalam apapun.

ƒ Identifikasi konkurensi alamiah ƒ Identifikasi konkurensi persoalan

ƒ Gunakan model dinamis sebagai dasar ƒ Pada dasarnya semua objek konkuren
ƒ Bila dua objek menerima event pada saat yang  ƒ Penemuan thread of control ditentukan oleh
sama tanpa saling berinteraksi urutan event yang terjadi antar objek yang saling
bergantung
ƒ Thread of control = jalur kontrol melalui sejumlah
state (pada state of diagram) dimana pada satu
saat hanya satu objek yang aktif.
ƒ Satu thread of control dinyatakan sebagai task
pada sistem komputer.

ƒ Tiap subsistem konkuren dialokasi pada satu ƒ Alokasi task ke prosesor

unit perangkat keras tertentu: ƒ Penentuan hubungan fisik (physical connectivity)
ƒ General purposes processor ▪ Topologi untuk menghubungkan unit fisik
▪ Topologi
T l i untuk
t k unit‐unit yang sama
it it   
ƒ Specialized function unit
▪ Kanal komunikasi dan protokol komunikasi
ƒ Pengalokasian didasarkan atas:
ƒ Penentuan hubungan lojik
ƒ Perkiraan kebutuhan kinerja & sumber daya
▪ Komunikasi antar task secara lojik:
ƒ Bandingkan pengorbanan (trade‐off) ▪ IPC – sinkronisasi antar proses coarse‐grained
▪ Perangkat keras dibanding perangkat lunak ▪ Thread – sinkronisasi antar proses fine‐grained.
▪ Perangkat lunak dibanding perangkat keras

MBO - OMT : Ir. I Gede Made Karma, MT

7
 10/15/2007

ƒ Penyimpanan data adalah kombinasi dari : ƒ Manajemen penyimpanan data menentukan:

ƒ Struktur data ƒ Kapan menggunakan media penyimpanan data yang 
mana
ƒ Files ƒ Khususnya
y untuk media penyimpanan
p y p basis data, ,
ƒ Basis data pada : harus ditentukan:
▪ Memory ▪ Model data (relasional, OO, hirarki, network, atau gabungan)
▪ Penerjemahan data pada model terdahulu (model objek) 
▪ Penyimpanan sekunder pada basis data
▪ DBMS yang dipilih berdasarkan:
▪ Kinerja
▪ Jenis aplikasi
▪ Antarmuka pemrograman

ƒ Sumber daya global menyangkut semua item  ƒ Pola penanganan sumber daya:

konfigurasi sistem: ƒ Terpusat: satu penjaga untuk satu satu sumber
ƒ Unit fisik: prosesor, drive, satelit komunikasi,  daya
saluran telepon, space (disk space), layar, dll. ƒ Delegasi: satu penjaga mendelegasikan bagian
ƒ Unit lojik: ID, nama file, nama kelas, basis data, dll sumber daya pada penjaga lain
▪ Mekanisme partisi: hanya berhak atas sebagian sumber
daya tertentu
ƒ Tiap sumber daya harus memiliki penyangga
▪ Mekanisme lock: penerima lock dapat langsung
mengakses sumber daya

ƒ Jenis kontrol perangkat lunak : ƒ Penanganan kondisi batas harus dirancang

ƒ Eksternal = alir event yang terlihat secara agar sistem tetap stabil
eksternal antar objek pada sistem. Jenisnya : ƒ Penanganan dilakukan terhadap :
▪ Procedural
Procedural‐driven sequential
driven sequential
▪ Event‐driven sequential ƒ System, 
▪ Concurrent ƒ Objek, dan
ƒ Internal : ƒ Operasi.
▪ Dibangkitkan oleh objek sebagai bagian dari
implementasi algoritma
▪ Bergantung pada paradigma bahasa yang digunakan.

MBO - OMT : Ir. I Gede Made Karma, MT

8
 10/15/2007

ƒ Jenis kondisi yang harus ditangani: ƒ Pengorbanan dilakukan atas:

ƒ Inisialisasi ƒ Space
ƒ Terminasi ƒ Speed
ƒ Failure
F il ƒ Solution
▪ Identifikasi titik failure
▪ Memperkecil software defect
▪ Exception handling
▪ Informasi sebanyak‐banyaknya tentang kegagalan yang 
terjadi sebelum terminasi.
▪ Terminasi dengan anggun.

ƒ Penerapan arsitektur sistem yang terdefinisi ƒ Dynamic simulation

berdasarkan karakteristik tertentu Sistem mensimulasikan objek‐objek dunia nyata beserta
ƒ Jenis : kelakuannya.
ƒ Batch transformation ƒ Real‐time system
Transformasi data yang dieksekusi hanya sekali pada Sistem didominasi oleh batasan waktu yang tegas.
keseluruhan himpunan masukan.
ƒ Continuous transformation ƒ Transaction manager
Transformasi data yang dilakukan secara kontinu menuruti Sistem yang berkaitan dengan penyimpanan dan
perubahan input. pemutakhiran data digabungkan dengan akses konkuren
ƒ Interactive interface dari berbagai lokasi fisik.
Sistem didominasi oleh interaksi eksternal.

ƒ Menentukan: ƒ Perancang harus:

ƒ Definisi lengkap kelas dan asosiasi yang  1. Mengkombinasikan 3 model
digunakan pada implementasi 2. Merancangan algoritma (implementasi operasi)
ƒ Antarmuka 3. M
Mengoptimalkan
ti lk jalur
j l akses
k d t
data
ƒ Algoritma object methods sebagai operasi. 4. Implementasi kontrol interaksi eksternal
ƒ Optimasi perancangan untuk kemudahan: 5. Mengatur ulang struktur kelas
6. Merancang asosiasi
ƒ Implementasi
7. Menentukan representasi objek
ƒ Perawatan
8. Memaketkan kelas dan asosiasi dalam modul
ƒ Pengembangan

MBO - OMT : Ir. I Gede Made Karma, MT

9
 10/15/2007

ƒ Setiap operasi pada model fungsional harus ƒ Mendefinisikan kelas‐kelas internal dan operasi

diformulasikan sebagai algoritma. baru bila perlu
ƒ Perancang algoritma harus : ƒ Menetapkan tanggung jawab operasi pada kelas‐
y g p
kelas yang tepat
ƒ Memilih
M ilih algoritma
l i yang meminimasi
  i i i cost dari
d i
▪ Asosiasikan operasi pada target dari operasi bukan
implementasi operasi, berdasarkan: inisiator
▪ Kompleksitas komputasi ▪ Objek yang berubah adalah target dari operasi
▪ Kemudahan implementasi dan pemahaman ▪ Kelas pusat pada topologi star adalah target dari operasi
▪ Fleksibelitas Æ tapi ingat, perlu pendelegasian.
ƒ Memilih struktur data yang tepat untuk tiap algoritma ▪ Asosiasikan operasi dengan kejadian dunia nyata bila
▪ Menggunakan kelas container yang telah ada. objek adalah representasi dunia nyata.

ƒ Mengoptimalkan jalur akses = mengoptimalkan ƒ Implementasi kontrol = mengimplementasikan

rancangan untuk mendukung akses informasi
yang efisien.
ƒ Yang harus dilakukan adalah :
ƒ Menambahkan asosiasi redudan untuk meminimalkan
biaya akses dan memaksimalkan kenyamanan akses.
ƒ Mengatur ulang komputasi untuk meningkatkan
efisiensi
ƒ Menyimpan atribut turunan untuk menghindari
komputasi ulang dari ekspresi kompleks.
model dinamis
ƒ Ancangan untuk mengimplementasikan model 
dinamis :
ƒ Menggunakan lokasi dalam program untuk
menyimpan state (procedure‐driven system)
ƒ Implementasi langsung dari mekanisme mesin state
ƒ Menggunakan task‐task yang konkuren.

ƒ Pengaturan struktur kelas (definisi kelas dan ƒ Mengabstraksikan lebih tinggi kelakuan yang 
operasinya) diatur ulang untuk meningkatkan mirip
pewarisan. ƒ Mendelegasikan kelakuan (bukan pewarisan)
ƒ Dilakukan dengan cara:
ƒ Mengatur ulang kelas dan operasinya dengan:
▪ Mencari operasi yang sama/serupa
▪ Operasi dengan argumen yang lebih sedikit
▪ Operasi dengan argumen yang lebih sedikit karena berupa kasus
spesialisasi
▪ Atribut serupa dengan nama berbeda
▪ Operasi hanya terdefinisi pada sejumlah kelas dan tidak
terdefinisi pada kelas lain yang serupa.

MBO - OMT : Ir. I Gede Made Karma, MT

10
 10/15/2007

ƒ Untuk mendefinisikan implementasi yang  ƒ Tranversal bidirectional, ada 3 ancangan:

tepat untuk menyatakan asosiasi ▪ Uni‐directional + pencarian (pada arah balik)
ƒ Analisis tranversal asosiasi ▪ Pointer di dua tempat, yang menunjuk ke ‘many’ 
dinyatakan sebagai set
ƒ Tranversal uni‐directional

ƒ Asosiasi dinyatakan sebagai objek tersendiri ƒ Menyatakan link attribute:

ƒ Untuk asosiasi 1‐1 disimpan sebagai atribut salah
satu objek
ƒ Untuk asosiasi m‐1 disimpan sebagai atribut dari
objek ‘many’, karena tiap objek many hanya
muncul satu kali pada tiap asosiasi
ƒ Untuk asosiasi m‐n asosiasi harus dinyatakan
sebagai objek tersendiri dan atribut link disimpan
sebagai atribut dari objek tersebut.

ƒ Menentukan representasi tiap kelas: ƒ Yang harus diperhatikan:

ƒ Menyembunyikan informasi internal dari pandangan
ƒ Merupakan susunan dari tipe‐tipe primitif luar
ƒ Merupakan susunan dari tipe primitif dan kelas ▪ Penentuan antarmuka yang baik Æ seperlunya
lain ƒ Koherensi
K h i entitas
tit
▪ Satu method bertindak sebagai
ƒ Merupakan susunan dari kelas‐kelas lain. ▪ Policy method saja atau,
▪ Implementation method saja
ƒ Pemaketan modul fisik merupakan ▪ Satu kelas harus punya satu tujuan saja
penerjemahan dari definisi kelas menjadi ƒ Pembangunan modul‐modul fisik
sejumlah kode sumber bahasa target ▪ Perhatikan coupling antar kelas
▪ Functional cohesiveness
▪ Asosiasi tingkat couplingnya lebih tinggi dari pada pola pemanggilan
client‐supplier

MBO - OMT : Ir. I Gede Made Karma, MT

11