oop gaul

METODOLOGI BERORIENTASI OBJEK

Penyusun

Yuda Syahidin, S.T

of 38

MATERI 1

PENGANTAR MODOLOGI BERORIENTASI OBJEK

Melihat laju perkembangan teknologi informatika yang demikian pesat

dewasa ini, maka pendekatan berarah objek diperkirakan akan menggantikan

pendekatan Struktural dalam merancang sistem di masa yang akan datang. Hal

ini dikarenakan pendekatan berarah objek memiliki beberapa kelebihan

diantaranya:

Aplikasi yang akan dibangun didukung oleh perkembangan teknologi

Software Engineering yang baru menuju ke konsep Object Oriented.

1. Tehnologi dengan pendekatan object-oriented ini memungkinkan

komponen dari program dapat dipakai ulang sehingga memper-

mudah dalam pengembangan sistem selanjutnya serta program yang

dihasilkan pun makin berkualitas baik.

2. Aplikasi yang dibangun dengan pendekatan ini mudah dalam

perawatan karena strukturnya mengalami proses inheritance.

Sehingga teknologi dengan pendekatan object-oriented ini dapat

mengurangi efek samping atau resiko ketika terjadi perubahan pada

struktur.

Sampai saat ini dikenal dua pendekatan yang utama dalam

pengembangan sistem dengan metode berarah objek yaitu:

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

perancangan sistem dalam metode berarah objek dimana pendesain

sistem langsung mendesain objek-objek yang diperlukan sistem.

Kelemahan dari pendekatan ini adalah karena seorang pendesain

diberi kebebasan dalam membuat objek sehingga untuk meng-

hasilkan objek yang benar-benar baik maka diperlukan pengulangan

proses untuk perbaikan objek.

2. Pendekatan Sintesis (Synthesis Approach), adalah suatu pendekatan

dalam perancangan sistem dengan metode berarah objek dimana

objek–objek yang dihasilkan diperoleh dari penerapan metode

struktural. Kelemahan dari pendekatan ini adalah seorang pendesain

melakukan tahapan kerja lebih banyak yaitu harus merancang sistem

of 38

secara struktural terlebih dahulu kemudian mentransfernya ke dalam

bentuk objek.

2.1. Pendekatan Sintesis (Synthesis Approach)

Pendekatan sintesis adalah pendekatan metode berarah objek secara

tidak langsung. Maksud tidak langsung disini adalah bahwa objek-objek

diperoleh dari hasil pendesainan secara struktural. Jadi dalam pendekatan ini,

langkah pertama adalah membangun terlebih dahulu data dan proses,

kemudian menyatukan data dan proses tersebut menjadi objek–objek dengan

aturan-aturan tertentu.

2.2. Pendekatan Langsung (Direct Approach)

Pendekatan secara langsung adalah metode berarah objek yang meliputi:

analisis berarah objek (OOA), perancangan berarah objek (OOD), pemrograman

berarah objek (OOP) dan pengujian berarah objek (OOT).

Istilah “objek” telah digunakan dalam cara yang berbeda dari dua

disiplin ilmu yang berbeda.

1. Dari permodelan Informasi adalah:

“suatu representasi dari beberapa dunia nyata dan sejumlah kejadian”; dan

2. Dari bahasa pemrograman berarah objek adalah:

“suatu runtime beberapa proses dan nilai yang ditentukan dengan deskripsi

yang disebut kelas”.

Objek juga didefinisikan sebagai berikut:

“Objek dapat didefinisikan sebagai suatu encapsulation atau

penggabungan dari data (yang diwakilkan oleh atribut-atribut) dan

operasi–operasi (disebut juga metode/prosedur) yang akan melakukan

proses terhadap data-data tersebut.”

Persamaan dari pendekatan object oriented :

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

Analisis berarah objek dibangun sebagian besar diatas konsep

permodelan Informasi, bahasa pemrograman berarah objek dan sistem berbasis

of 38

pengetahuan (konsep yang mempunyai basis yang baku dan pengertian prinsip-

prinsip untuk menangani kerumitan).

Dari model Informasi secara analogi mengambil bentuk attribute,

instance connection, generalize-specification dan whole-part. Dari bahasa

pemrograman berarah objek dan sistem berbasis pengetahuan secara analogi

mengambil bentuk pembungkusan dari atribut dan service, communication with

massages, gen-spec dan inheritance.

Object-OrientedProgramming Languages &Knowledge-Based Systems

ObjectOrientedAnalysis

Entity Relationship

Diagrams

SemanticData

Modeling

(Information Modeling)

AttributesInstance ConnectionsGeneralization-SpecializationWhole-Part

Attributes and Exclusive ServiceCommunication with MessagesGeneralization-SpecializationInheritance

Gambar 1 OOA Gabungan dari beberapa Disiplin Ilmu

Metode pembangunan perangkat lunak berarah objek adalah suatu

strategi pembangunan perangkat lunak yang mengorganisasikan perangkat lunak

sebagai kumpulan objek yang berisi data aksi yang dilakukan terhadapnya.

Penggabungan proses dan data didalam suatu objek dikenal sebagai

pembungkusan. Ditambah dengan konsep infohiding, object class or instant

connection dan polymorphism merupakan dasar dari metode berarah objek.

Adapun komunikasi antar proses yang dapat berarti komunikasi antar objek

dilakukan dengan melalui pesan (communication with massages).

2.3. Prinsip-prinsip

Prinsip-prinsip pengelolaan kompleksi tersebut terdiri atas abstraksi

(prosedural dan data), pembungkusan, asosiasi, komunikasi dengan pesan,

metode organisasi, penskalaan, dan pengelompokan prilaku [COA90].

1. Abstraksi (Abstraction)

Abstraksi: prinsip yang menganggap bahwa aspek-aspek dari suatu objek

yang tidak relevan dengan tujuan sekarang, digunakan untuk melengkapi

tujuan tsb.

Mekanisme abstraksi:

a. Abstraksi Prosedural: sering dikarakteristikkan sebagai abstraksi fungsi

atau subfungsi. Pemecahan proses kedalam tahapan-tahapan merupakan

suatu metode dasar dalam penanganan kekomplekan suatu proses.

of 38

b. Abstraksi Data: prinsip pendefinisian suatu type data dalam istilah-

istilah pengoperasian yang menggunakan type tersebut dengan

pembatasan terhadap nilai-nilai objek yang dapat dimodifikasi dan

hanya dijalankan dengan menggunakan operasi, prinsip ini dapat

menjadi suatu dasar untuk pengaturan tanggungjawab suatu sistem

secara spesifik.

2. Pembungkusan (Encapsulation)

Pembungkusan adalah suatu prinsip yang digunakan ketika pengembangan

struktur program secara keseluruhan, dimana tiap-tiap komponen program

harus disimpan/disembunyikan dalam satu perancangan interaksi. Untuk

tiap-tiap modul ditentukan dengan cara mengungkapkan sebagian kecil

tentang informasi kerja secara pasti. Pembungkusan membantu

memperkecil pekerja-an ketika pengembangan suatu sistem baru. Jika

seorang perancang “mem-bungkus” bagian dari hasil analisis yang sering

berubah-ubah, kemudian mengganti sesuai dengan kebutuhan, jika ada

masalah, maka masalah tersebut lebih kecil resikonya bila dibandingkan

dengan tanpa “pembungkusan”.

3. Pewarisan (Inheritance)

Pewarisan adalah suatu cara kerja yang menyatakan kesamaan diantara

kelas-kelas, penyederhanaan definisi kelas yang mirip ke suatu definisi yang

telah ada sebelumnya. Pewarisan terdiri dari generalisasi dan spesialisasi.

4. Asosiasi (Association)

Asosiasi adalah penyatuan atau pengembangan ide-ide. Digunakan untuk

me-nyatukan sesuatu secara bersama-sama dalam keadaan yang mirip.

5. Komunikasi dengan Pesan (Communication with Massages)

Pesan adalah suatu komunikasi, berupa tulisan atau ucapan, pengiriman

pesan antar orang-orang. Hal ini dihubungkan dengan "pembungkusan",

rincian itu merupakan kegiatan yang dilakukan dengan menerima pesan.

6. Metode Pengorganisasian (Pervading Methods of Organization)

Metode Pengorganisasian ini meliputi tiga bagian yaitu:

a. Perbedaan pengalaman kedalam bagian objek dan atributnya. (object

and attributes)

b. Perbedaan antara keseluruhan objek dan komponen bagiannya. (whole

and parts)

c. Formasi dan perbedaan antara kelas-kelas objek yang berbeda. (classes,

members and distinguishing between them)

of 38

7. Skala (Scale)

Skala adalah suatu prinsip yang menerapkan whole-part untuk membantu

menghubungkan sesuatu yang berukuran besar tanpa perlu meliputi

semuanya.

8. Klasifikasi Tingkah Laku (Behavior Classification)

Jenis klasifikasi tingkah laku yang digunakan secara umum yaitu:

a. Berdasarkan kepada kebutuhan yang mendesak

b. Berdasarkan perjalanan waktu (historis)

c. Berdasarkan fungsi

2.2.4. Keuntungan Metode Berarah Objek

Keuntungan Metoda Berarah Objek diantaranya adalah [COA91]:

1. meningkatkan produktivitas,

karena kelas dan objek yang diketemukan pada suatu kasus masih dapat

dipakai ulang untuk kasus lainnya yang melibatkan objek tersebut

(reusable);

2. meningkatkan kualitas,

karena sistem yang dibangun dengan baik dan benar pada saat analisis dan

perancangannya akan menyebabkan berkurangnya kesalahan pada saat

pengkodean;

3. mempermudah perawatan,

karena dengan model objek pola-pola yang cenderung tetap dan stabil

dapat dipisahkan dari pola-pola yang mungkin sering berubah-ubah; dan

4. adanya konsistensi;

karena sifat pewarisan dan penggunaan notasi yang sama pada saat analisis,

perancangan, maupun pengkodean.

of 38

MATERI 2

ANALISIS BERORIENTASI OBJEK

Pendekatan analisa berarah objek terdiri dari lima pokok aktivitas, yaitu:

a. Menentukan Kelas-&-Objek (finding class-&-objects)

b. Identifikasi Struktur (identifying structures)

c. Identifikasi Subjek (identifying subject)

d. Pendefinisian Atribut (defining attributes)

e. Pendefinisian Service (defining services)

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

Pengertian objek adalah suatu abstraksi dari suatu lingkup

permasalahan / implementasi yang menggambarkan kemampuan dari sistem

untuk menangkap informasi tentang objek tersebut, berinteraksi dengan atau

keduanya; "pembung-kusan" pada nilai atribut dan service-nya.

Kelas adalah suatu gambaran dari satu atau lebih objek, penggambaran

dengan sekumpulan atribut dan service yang sama. Menggambarkan bagaimana

untuk menciptakan objek-objek baru dalam suatu kelas.

Class

Attribute

Service

Gambar 2.1 Simbol Kelas

Simbol ini digunakan untuk merepresentasikan generalisasi kelas dari

lingkup permasalahan yang berhubungan dengan objek-objeknya yang

digambar-kan dengan spesialisasi objek tersebut.

Kelas-&-objek adalah suatu istilah yang berarti suatu kelas-&-objek

yang ada di kelas tersebut.

Class & Object

Attribute

Service

Gambar 2.2 Simbol Kelas-&-Objek

Simbol "kelas-&-objek" merepresentasikan suatu kelas dan objek-objek-

nya. Simbol kelas digambarkan dengan segiempat yang dicetak tebal dan di

of 38

bagi ke dalam tiga bagian. Simbol objek-objeknya digambarkan dengan

segiempat yang ada disebelah luar dari simbol kelas. Hubungan dari satu objek

ke objek lain atau hubungan satu kelas ke kelas lain atau hubungan satu objek

ke suatu kelas, merupakan hal yang dapat dilakukan terhadap simbol tersebut.

Simbol diberi nama dengan kelas-&-objeknya. Atribut dan service dapat

digunakan untuk tiap-tiap objek disuatu kelas. Nama kelas-&-objek adalah

suatu kata kerja atau kata sifat. Nama kelas-&-objek harus menggambarkan

suatu objek tunggal dengan kelasnya. Contoh: ketika tiap objek

menggambarkan sesuatu yang berhubungan dengan "meja" maka nama kelas-&-

objeknya: "anggota_meja". Tiap objek minimal mempunyai satu item.

2.2. Identifikasi Lapisan Struktur

Struktur adalah suatu ekspresi dari lingkup permasalahan yang komplek,

berhubungan dengan tanggungjawab terhadap sistem. Istilah struktur digunakan

sebagai sebuah istilah yang menggambarkan struktur generalisasi-spesialisasi

(gen-spec) dan struktur keseluruhan dan bagiannya (whole-part).

Struktur gen-spec termasuk kebagian "perbedaan antar kelas" dalam tiga

aspek dasar metode pengorganisasian. Struktur gen-spec dikenal sebagai

struktur "is a" atau "is a kind of".

Specialization 2

Attribute

Service

Generalization

Attribute

Service

Specialization 1

Attribute

Service

Gambar 2.3 Simbol Generalize-Specification

Dengan struktur gen-spec, pewarisan digambar secara eksplisit terhadap

atribut dan servisnya. Gen-spec digambarkan dengan kelas atas generalisasi dan

kelas dibawahnya adalah spesialisasi dengan penghubung diantaranya.setengah

lingkaran membedakan antara kelas-kelas dalam gen-spec.

Struktur Whole-parts digambarkan dengan objek pada bagian atas dan

objek pada bagian bawah (dari simbol kelas-&-objek) dengan garis penghubung

diantaranya, whole-parts dikenal sebagai struktur "has a".

of 38

Part 1

Attribute

Service

WholeAttribute

Service

1,m

1

1,m

1

Part 2

Attribute

Service

Gambar 2.4 Simbol Whole-parts

2.3. Identifikasi Lapisan Subjek

Subjek adalah suatu mekanisme yang membantu pembaca untuk meng-

analisa model permasalahan dari yang kecil hingga ke yang besar dan komplek.

Pada lapisan subjek, gambarkan setiap subjek sebagai kotak persegi

yang sederhana, dengan nama subjek dan nomor didalamnya sebagai tambahan,

daftarkan kelas-kelas yang termasuk didalam subjek tersebut. Pada lapisan

yang lain indikasikan subjek dengan label subjek pada sekat pemisah kotak

subjek untuk memandu pembaca dari subjek ke subjek lainnya. Dalam model

yang besar dan membutuhkan fasilitas komunikasi, pertimbangkan penggunaan

"set" dari lapisan secara terpisah untuk setiap subjek. Sebuah kelas dari subjek

berada didalam lebih dari satu subjek. Subjek boleh berisi subjek lainnya.

Persiapkan pemetaan multi level untuk membantu pembaca dalam suatu model

yang besar.

2. Subject2

Class-&-Object3Class-&-Object4

1. Subject1

Class-&-Object1Class-&-Object2

Gambar 2.5 Simbol Subject

of 38

Penggambaran dari simbol diatas dengan lapisan yang berbeda dapat

dilihat dalam gambar dibawah ini.

1 1

11 2 2

2 2

Gambar 2.6 Simbol Subject dengan Lapisan Berbeda

2.4. Pendefinisian Lapisan Atribut

Atribut adalah beberapa data (state information) dimana setiap objek di

dalam suatu kelas mempunyai nilai tersendiri.

Mendefinisikan atribut dengan cara:

a. Identifikasi atribut

b. Mencari posisi atribut

c. Identifikasi instance connection

Untuk identifikasi atribut perlu menjawab beberapa pertanyaan:

1. Bagaimana kita mendeskripsikannya secara umum?

2. Bagaimana kita pada permasalahannya

3. Bagaimana kita mendeskripsikannya pada bentuk tanggungjawab thd.

sistem?

4. Apa yang harus diketahui?

5. Apa acuan untuk pelaksanaannya?

Periksalah kembali hasil analisis pada permasalahan yang sama/serupa.

Pertimbangkan penggunaan atribut untuk merancang keputusan dalam segi

waktu dengan memori yag dipergunakan. Buatlah tiap-tiap atribut dalam

konsep atomic. Tambahkan "id" (identifier) dan "cid" (connection identifier),

sehingga dapat dipergunakan pada spesifikasi teks jika diperlukan.

Masukan setiap atribut kedalam kelas dan objeknya (periksa permasalah-

annya). Daftarkan inheritance pada struktur gen-spec. posisi atribut yang

bersifat umum letakan di tingkat yang lebih atas, sedangkan posisi atribut yang

lebih spesifik diletakan ditingkat yang berikutnya.

Instance connection: suatu model pemetaan lingkup permasalahan pada

satu objek yang memerlukan objek lainnya, untuk memenuhi "tanggungjawab"

terhadap proses yang harus dilakukannya. Instance connection

merepresentasikan bagian dari state information yang diperlukan oleh sebuah

objek.

of 38

Periksa hasil analisis pada permasalahan yang sama. Untuk setiap objek,

tambahkan garis koneksi. Tambahkan subjek-bahan pemetaan (subject-matter

mappings) diantara objek, perhatikan keterhubungan dengan struktur gen-spec.

Class & Object

Attribute 1Atribute 2

Service

Class

Attribute 1Attribute 2

Service

Gambar 2.7 Simbol Attributes

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

Class & Object

Attribute

Service

Class & Object

Attribute

Service

0, m 1

Gambar 2.8 Simbol Instance Connection

Instance connection digambarkan dengan garis yang mehubungkan antar

objek. Garis tersebut menghubungkan antar individu objek dari pada antar

kelas. Tiap objek mempunyai jumlah atau batas penandaan (m, n) untuk

Instance connection-nya.

2.5. Pendefinisian Lapisan Service

Service adalah tingkah laku yang spesifik, yaitu tingkah laku yang mem-

perlihatkan "tanggungjawabnya" terhadap sebuah objek.

Identifikasi uraian objek (object state):

1. Ujilah nilai yang potensial dari atribut

2. Bedakan apakah tanggungjawab sistem termasuk perbedaan kelakuan

(behavior) untuk masing-masing nilai yang potensial

3. Periksa dengan hasil analisis terhadap permasalahan

4. Deskripsikan kedalam diagram objek (object state diagram)

Class & Object

Attribute

Service 1Service 2

Class

Attribute

Service 1Service 2

Gambar 2.9 Simbol Service

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

of 38

Message connection adalah model yang memproses ketergantungan dari

sebuah objek, indikasi yang diperlukan untuk service dalam melaksanakan

pekerjaan yang berhubungan dengan "tanggungjawabnya".

SenderAttribute

Service

ReceiverAttribute

Service

Gambar 2.10 Simbol Message Connection

Simbol message connection merupakan sebuah anak panah dari pengirim

ke penerima. Anak panah berarti pengirim mengirim sebuah pesan, sedangkan

penerima menerima pesan tersebut dan mengembalikan pesan tersebut setelah

diproses terlebih dahulu. Biasanya message connection menghubungkan antar

objek dari pada antar kelas.

of 38

MATERI 3

PERANCANGAN BERARAH OBJEK

Didalam perancangan berarah objek, prinsip whole-part diterapkan ke

dalam empat komponen utama, yaitu:

a. Komponen Lingkup Permasalahan (Problem Domain Component)

b. Komponen Interaksi Manusia (Human Interaction Component)

c. Komponen Manajemen Kerja (Task Management Component)

d. Komponen Manajemen Data (Data Management Component)

Hubungan empat aktifitas utama dalam perancangan berarah objek

dengan lima aktifitas dalam analisis dapat dilihat dalam gambar berikut:

Subject layer

Class & object

layer

Structure

layer

Attribute layer

Service layer

Human

Interaction

Component

Problem

Domain

Component

Task

Managemen

t

Component

Data

Management

Component

Gambar 3.1 Hubungan Analisis dengan Perancangan

Empat komponen utama tersebut berhubungan dengan empat aktifitas

utama dalam perancangan berarah objek, yaitu:

a. Perancangan Lingkup Permasalahan (Problem Domain Design)

b. Perancangan Interaksi Manusia (Human Interaction Design)

c. Perancangan Manajemen Kerja (Task Management Design)

d. Perancangan Manajemen Data (Data Management Design)

3.1. Perancangan Lingkup Permasalahan

Dalam perancangan berarah objek, hasil analisis berarah objek dimasuk-

kan kedalam komponen lingkup permasalahan. Hasil analisis secara menyeluruh

merupakan bagian dari model perancangan. Dengan langkah ini, penelusuran

dari analisis, perancangan sampai pemrograman menjadi jelas sehingga setiap

kegiatan diorganisasikan sebagai lingkup permasalahan itu sendiri. Hal ini

of 38

mengacu kepada keseimbangan yang diperlukan untuk pengorganisasian

analisis, perancangan, pemrograman setiap saat.

Keseimbangan adalah kunci utama untuk pemakaian kembali (reuse)

hasil analisis, perancangan dan pemrograman yang berkaitan dengan lingkup

per-masalahan. Keseimbangan dalam analisis dan perancangan memberikan

dasar yang benar-benar cocok dalam mengajukan perubahan secara sistematik.

Dalam perancangan lingkup permasalahan ini, mengikuti langkah-langkah

berikut:

1. Penerapan hasil analisis

2. Menggunakan hasil analisis dan memperbaikinya selama perancangan

3. Menggunakan hasil analisis dan penambahannya selama perancangan

Dari model objek hasil analisis dilakukan:

a. Pendalaman hasil analisis untuk menghasilkan model yang lebih mendekati

kenyataan (real world)

b. Penambahan kriteria pada model hasil analisis dengan cara:

∗ Penggunaan kembali (reuse) kelas-&-objek hasil analisis rancangan dan

pemrograman sebelumnya

∗ Pengelompokan kelas-kelas yang spesifik terhadap lingkup permasalahan

∗ Pembuatan sebuah protokol dengan penambahan kelas-&-objek yang

bersifat umum

∗ Penerapan tingkatan pewarisan

∗ Peningkatan performansi

∗ Mendukung komponen manajemen data

∗ Penambahan komponen tingkat bawah

3.2. Perancangan Interaksi dengan Manusia

Sistem berbasis komputer selalu mempunyai elemen orang yang ber-

interaksi langsung dengan perangkat keras dan lunak, mengelola dialog

terhadap fungsi-fungsi dari sistem, pada semua kasus manusia

bertanggungjawab untuk pekerjaan pembangunan dan perawatan sistem

Untuk itu perlu diketahui keinginan dari pemakai terhadap sistem agar

seluruh proses kegiatan manusia dan antarmuka (human interface) yang

berdasar-kan hubungan sebab akibat dapat diimplementasikan dengan mudah,

of 38

cepat dengan menjalankan dan menerapkan aplikasi yang dibangun. Tahap

perancangan HIC dapat dilihat dalam pembahasan berikut.

3.2.1. Klasifikasi Pemakai

Langkah-langkah untuk mengklasifikasikan pemakai:

1. Tempatkan diri kitasebagai pemakai sistem

2. Klasifikasikan berdasarkan level keahlian

3. Klasifikasikan berdasarkan level organisasi

4. Klasifikasikan berdasarkan keanggotaan pada group yang berbeda

3.2.2. Deskripsi Pemakai

Langkah-langkah untuk mengdeskripsikan pemakai:

1. Tentukan siapa yang akan menggunakan sistem ini

2. Apa tujuan orang tersebut berhubungan deng sistem

3. Bagaimana karakteristik pemakai sistem

4. Faktor-faktor kesuksesan meliputi perlu/tidak, suka/tidak

5. Tentukan level keahlian dari orang tersebut

6. Tentukan skenario kegiatan yang harus dilakukan oleh orang tersebut

3.3. Perancangan Manajemen Kerja

Kegiatan atau kerja (task) merupakan komponen inti suatu objek dalam

berinteraksi dengan objek lain, keterhubungan dan keterkaitan antar objek ini

ditentukan dulu oleh manajemen kerja. Dengan adanya manajemen kerja yang

baik, tentunya akan membentuk struktur keterkaitan antar objek lebih terarah,

dimana keterkaitan antar objek ini merupakan komponen utama dalam

perancang-an berarah objek dalam membentuk suatu sistem yang multiuser.

3.4. Perancangan Manajemen Data

Data merupakan komponen penting dalam suatu sistem untuk menghasil-

kan suatu informasi. Untuk itu, diperlukan pengelolaan data yang teratur dan

terarah sehingga jika diperlukan dapat diakses dengan cepat dan tepat. Maka

dalam perancangan berarah objek, permasalahan mengenai manajemen data

masuk dalam permasalahan inti dalam perancangan. Hal ini dikarenakan,

dengan manajemen data yang baik maka sistem yang dihasilkan akan lebih baik

serta pemanfaatan data dapat dilakukan dengan lebih efektif dan efesien.

of 38

MATERI 4

PEMROGRAMAN BERORIENTASI OBJEK

Definisi [Meyer-97]

Sebuah sistem yang dibangun berdasarkan metoda berorientasi objek adalah

sebuah sistem yang komponennya di-enkapsulasi menjadi kelompok data

dan fungsi, yang dapat mewarisi atribut dan sifat dari komponen lainnya,

dan komponen-komponen tersebut saling berinteraksi satu sama lain.

Beberapa definisi lain

Object orientation:

1.a. the paradigm that use objects with identity that encapsulate

properties and oeprations, message passing, class, inheritance,

polymorphism, and dynamic binding to develop solution that model

problem domains [Firesmith, Lorenz]

1.b. any technique based on the concept of object, class, instances and

inheritance

[Jacobson]

2. the use of objects as the atom of modeling [Coleman]

Object adalah abstraksi dari sesuatu yang mewakili sesuatu pada dunia

nyata. Pada pemrograman berorientasi objek, Objek adalah entitas pada saat

run time . Objek mempunyai siklus hidup : diciptakan, dimanipulasi,

dihancurkan. Sebuah objek dapat diacu lewat namanya atau lewat

referensinya (addressnya)

Class adalah kumpulan objek yang mempunyai atribut yang sama. Class

adalah definisi statik dari entitas.

Entitas :

Entitas adalah salah satu dari berikut ini:

- atribut kelas

- variabel lokal

- parameter formal

- hasil fungsi

of 38

Tujuh langkah untuk mendapatkan hasil (SW) yang memuaskan [Meyer-97]:

1. Object based modular structure, sistem dimodularisasi berdasarkan

struktur objek

2. Data abstraction, objek harus dideskripsikan sebagai implementasi dari

ADT

3. Automatic memory management , objek yang sudah tidak dibutuhkan

lagi harus di-dealokasi oleh sistem pemroses bahasa tanpa perlu

intervensi pemrogram

4. Classes, setiap type yang tidak sederhana adalah sebuah modul,

setiap modul adalah type tingkat tinggi

5. Inheritance, sebuah Class dapat didefinisikan berdasarkan ekstensi atau

restriksi dari kelas lain

6. Polymorphism and dynamic binding, entitas program harus dimungkinkan

untuk mengacu kepada lebih dari satu kelas dan operasi harus

dimungkinkan untuk lebih dari satu kelas

7. Multiple and repeated inheritance, harus dimungkinkan untuk membuat

deklarasi kelas sebagai pewaris dari banyak kelas, dan lebih dari satu jika

pewarisnya sebuah kelas

Karakteristik utama sistem beorientasi objek [Meyer-97]

· abstraksi

· enkapsulasi

· pewarisan (inheritance)

· reuseability

· spesialisasi

· generalisasi

· komunikasi antar objek

· polymorphisme

Pengembangan sistem dengan metoda OO dapat meningkatkan :

· produktifitas

· kecepatan pengembangan

· kualitas perangkat lunak

· kemudahan pemeliharaan

of 38

Catatan : pada kuliah ini sangat dibedakan aspek statik dan aspek dinamik

(program pada saat run time)

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

mati

(dihancurkan)

Objek merupakan model eksekusi

Objek mengalamai dynamic creation

- program mmenciptakan sejumlah objek menurut pola yang tidak

mungkin diprediksi pada saat kompilasi

- pada saat operasi, objek baru mungkin saja diciptakan, reference

sebuah objek diubah ke objek yang lain atau tidak lagi mengacu ke

objek apapun

- nilai yang disimpan dalam sebuah field objek diubah

Perbedaan Kelas dan Objek

Adalah sangat penting untuk membedakan antara Kelas dan Objek . Objek

adalah elemen pada saat runtime yang akan diciptakan, dimanipulasi dan

dihancurkan saat eksekusi

Kelas adalah deskripsi statik dari himpunan objek yang mungkin

lahir/diciptakan yang merupakan instansiasi dari Kelas

Pada saat runtime, yang kita punyai adalah objek. Di dalam teks program,

yang kita lihat hanyalah kelas.

KELAS , definisi statik :

Pada lingkungan program berorientasi objek, pemrogram mendefinisikan

kelas secara statik. Pada saat run time, kelas akan diinstansiasi menjadi

objek (lihat dinamika). Objek yang merupakan instansiasi dari suatu kelas

selalu dapat diacu lewat Current Object, apapun nama instantnya.

Untuk menjamin bahwa setiap instans yang lahir dari kelas sesuai dengan

definisi kelas, bebrapa bahasa menyediakan fasilitas untuk menentukan

class invariant, yaitu berupa asersi yang menjamin kebenaran objek.

of 38

Untuk menciptakan (menghidupkan) objek, diperlukan konstruktor. Untuk

mematikan

(menghancurkan) objek, diperlukan destruktor

Kelas mempunyai:

· atribut (data, konstanta, properti). Nilai atribut pada saat run time

menyatakan

“keadaan” (state) dari objek yang merupakan instans dari kelas ybs.

Beberapa bahasa pemrograman mendefinisikan atribut harus sebuah Kelas,

atau beberapa bahasa memperbolehkan atribut dideklarasi sebagai kelas

atau type dasar

(numerik: integer/float, character, boolean)

· method (service, prosedur, fungsi). Pada saar run time, method akan

dieksekusi sesuai dengan kode programnya, atas permintaan (lewat pesan,

message) objek lain. Method mempunyai spesifikasi, signature (nama dan

parameter), dan mempunyai body (kode program yang akan dieksekusi).

Signature adalah informasi bagi kelas yang akan menggunakan kelas ini,

sedangkan body merupakan kode program yang akan dieksekusi.

Sebenarnya body tidak perlu diketahui oleh kelas pemakai asalkan

spesifikasinya jelas. Spesifikasi : Prekondisi

(initial state), post kondisi (Final State) dan “proses” apa yang akan

dikerjakan ketika mehod dieksekusi. Prekondisi dan Post kondisi dapat

dituliskan sebagai asersi (pada beberapa bahasa), sedangkan proses

dinyatakan dalam komentar. Parameter prosedur/fungsi dalam OOP

selalu parameter input, tidak pernah ada parameter output atau

parameter input/output:

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

dari objek input. Parameter fungsi selalu merupakan parameter

input, karena fungsi akan memetakan semua objek input (domain)

menjadi sebuah objek

lain (range), tanpa mengganggu state dari objek input

· Prosedur dirancang untuk mengubah state dari Current objek,

tanpa melahirkan objek baru. Parameter prosedur selalu

parameter input yang mewakili informasi perubahan dari Current

Objek. Current objek merupakan parameter input/output secara

implisit, sehingga tidak pernah dimunculkan dalam signature

of 38

[Meyer-97] menyebut atribut dan method sebagai feature. Selanjutnya

istilah feature akan dipakai dalam kuliah ini untuk mewakili atribut dan/atau

method

Deklarasi Kelas

Contoh Kelas Sederhana Point

Lingkup akses terhadap Feature didefinisikan mulai dari yang umum sampai

dengan yang sangat restriktif:

· public : dapat diakses/dipakai kelas apapun

· friend, hanya kelas tertentu yang boleh mengakses

· private : hanya kelas yang bersangkutan yang boleh memakai

Penentuan lingkup akses terhadap feature merupakan bagian yang harus

dirancang. Sebenarnya, dalam perancangan yang murni OO, sebaiknya “friend”

tidak digunakan

Klasifikasi kelas

Model program berorientasi objek yang termasuk paling “lama” dan mendasar

adalah model MVC dari Smalltalk, dimana setiap aplikasi dipandang terdiri

dari tiga jenis kelas : M (Modeler), V (Viewer), C( Controller) dengan

hubungan sebagai berikut:

Modeler adalah representasi dari domain persoalan yang akan diprogram.

Viewer bertugas untuk menampilkan objek “domain” sesuai dengan jenis

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

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

of 38

objek ke antarmuka pengguna (misalnya di lingkungan GUI : layar/windows),

sedangkan Controller bertugas untuk mengatur interaksi dan aliran

data/pesan antara Modeler dan Viewer. Objek dilahirkan berdasarkan definisi

kelas, dan ketika eksekusi program akan

“hlang”. Jika objek harus dapat disimpan secara permanen, maka modeler

juga harus merepresentasi persistent objek (pada pemrograman prosedural

menjadi arsip eksternal, external file) .

Klasifikasi kelas dari sudut pandang instansiasinya:

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

· kelas abstrak : instance bukan objek.

· deferred class : kelas yang belum seluruhnya diimplementasi

Klasifikasi kelas dari sudut pandang Booch:

· ADT : definisi type dan method

· Mesin : punya state dan behavior, pasif

· Proses: objek aktif

Klasifikasi kelas dari sudut pandang UML:

· Boundary entity

· Domain entity

· Controller

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

antarmuka interaksi, domain entity merepresentasi persoalan yang

dimodelkan (pada saat runtime menjadi objek) sedangkan controller adalah

objek pengendali yang mengendalikan semua objek yang ada.

Klasifikasi kelas dari sudut pandang Coadd:

· Domain problem

· Interface

Klasifikasi "kelas" pada bahasa Java

· CLASS

of 38

· Interface

Hubungan antar kelas

Antara sebuah kelas dengan kelas yang lain ada hubungan : Client-

Supplier atau inheritance.

Hubungan Client-Supplier

Pada hubungan Client-Suplier, sebuah kelas Client memakai kelas Supplier.

Hubungannya adalah hubungan “kontrak”. Supplier menyediakan sejumlah

services yang dapat dipakai oleh Client, dan menjanjikan akan memenuhi

“kontrak”, yaitu memenuhi prekondisi yang ditentukan. Client wajib

mentaati aturan (prekondisi) yang tertulis sebelum memakai services yang

disediakan oleh Supplier.

Hubungan yang lebih simple, sederhana ini lebih disarankan untuk dipakai!

Definisi :

Kelas A adalah Client dari kelas B dan B adalah Supplier dari Kelas A jika A

Mengandung definisi Entitas e: B Entitas adalah :

- atribut

- argumen formal dari rutin

- hasil evaluasi fungsi

Hubungan inheritance

Pada hubungan Inheritance, sebuah kelas turunan (descendant, heir,

child,…) mewarisi kelas leluhur (parent, …). Karena mewarisi, maka

“semua” atribut dan method kelas bapak akan “dibawa”, secara intrinsik

menjadi bagian dari kelas anak. Dalam beberapa keadaan, membawa secara

intrinsik semua atribut dan method tidak dikehendaki. Maka pemroses

bahasa menyediakan sarana untuk:

· menambah feature baru,

· mengubah atau menggantikan feature yang diwarisi ,

· menghapus feature yang diwarisi,

· menentukan feauture yang masih deferred (belum terdefinisi)

Ini menimbulkan persoalan yang tidak sederhana. Karena penghapusan

menimbulkan beberapa konsekuensi berbahaya, maka sedikit sekali

of 38

metodologi/bahasa yang membolehkan penghapusan feature yang diwarisi.

Feature visibility dalam sebuah kelas ("scope" dalam

pemrograman prosedural):

· private, feature yang "visible" hanya untuk kelas dimana feature

tersebut didefinisikan

· protected, feature yang "disembunyikan" terhadap kelas Client,

tetapi "visible" untuk kelas turunan.

· public, feature yang "visible", dapat dipakai oleh semua kelas lain

(Client, turunan).

· friend: dalam bahasa C++, memberikan hak akses ke kelas-kelas tertentu

untuk dapat mengakses semua feature yang sebenarnya private. Ini

merupakan pelanggaran terhadap prinsip information hiding. Jadi

beberapa feature yang sebenarnya "private" diijinkan untuk menjasi

"visible" hanya untuk kelas tertentu. Sebenarnya pemakaian friend tidak

terlalu dianjurkan karena menyalahi kaidah inkapsulasi.

Visibility dari feature yang diwarisi pada kelas turunan sehubungan

dengan inheritance:

Private inheritance : semua feature yang diwarisi menjadi private dalam

kelas anak, tanpa peduli visibility pada Parent. Pemakaiannya mendukung

information hiding dan maintainability dari feauture yang diwarisi karena

dengan cara ini, perubahan pada ancestor tidak mempengaruhi anak. Tetapi,

penggunaannya harus hati-hati sebab menimbulkan nonconformity terhadap

parent, sebab apa yang visible di parent : menyalahi subtyping, spesialisasi

dan substitusi polimorfik.

Protected inheritance : semua feature yang mempunyai visibility

protected pada parent, tetap protected pada Child, sedangkan yang

public pada parents, menjadi protected pada Child.

Public inheritance : semua feature yang diwarisi mempunyai visibility yang

sama dengan visibility pada parent (jika public maka tetap public; jika private

tetap private; dst)

Jenis inheritance :

Single inheritance : sebuah kelas turunan merupakan turunan dari sebuah

kelas bapak. Jika simbol lingkaran/elips merupakan simbol sebuah kelas,

of 38

maka hubungan inheritance digambarkan sebagai berikut [Meyer-97]. Arti

dari gambar tersebut: B mewarisi A. B adalah turunan dari A.

A

B

Multiple inheritance :sebuah kelas turunan mewarisi lebih dari satu kelas

bapak (Join)

B A

C

Multiple inheriance menimbulkan beberapa persoalan : jika ternyata ada

feature di kelas-kelas leluhur yang ternyata “konflik”. Konflik yang terjadi

mungkin adalah :

· konflik nama

· konflik “body” (untuk method)

Tidak semua bahasa mensupport repeated inheritance, tetapi menyediakan

mekanisme lain untuk merealisasi konsep ini.

Repeated inheritance : sebuah kelas turunan mewarisi lebih dari satu

kelas bapak, dan kelas bapak tersebut mempunyai leluhur yang sama.

A

B C

D

of 38

Repeated inheritance menimbulkan beberapa persoalan :

· Konflik pada D, seperti halnya multiple inheriance.

· konflik pada D, jika ternyata beberapa feature di B dan C sudah

dimodifikasi

Sangat sedikit bahasa yang mensupport repeated inheritance.

Replicated repeated inheritance : Sebuah feature yang diwarisi dari

common anscestor dengan nama yang sama menjadi lebih dari satu buah

feature dalam Current Class. Jadi dalam hal ini, feature yang diwarisi muncul

lebih dari satu kali. Dalam beberapa bahasa, permogram harus mengubah

nama sehingga feature menjadi unik. Shared repeated inheritance (virtual

inheritance) : Sebuah feature yang diwarisi dari common anscestor dengan

nama yang sama menjadi hanya satu buah feature dalam Current Class. Jadi

dalam hal ini, feature yang diwarisi muncul hanya satu kali, dan dipakai

bersama.

Pemakaian inheritance perlu dikaji secara baik, dan dirancang dari awal.

Perancangan inheritance yang tambal sulam dan tidak tepat akan

menimbulkan banyak kesulitan pada saat implementasi. Pada “top level”

inheritance, biasanya dibuat kelas abstrak, yang merupakan spesifikasi dari

kelas-kelas turunannya. Makin ke “bawah”, definisi kelas menjadi makin

spesifik, dan dapat diinstansiasi menjadi objek yang “jelas”.

[Meyer-97] bahkan mendefinisikan hubungan inheritance dalam beberapa

tipologi. Buku [Webster-95] menyebutkan tiga macam hubungan antar kelas,

yaitu : has, is-a, is-implemented-using. Hubungan has dan is-implemented-

using sering dikacaukan menjadi hubungan inheritance.

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

subkelas yang lebih spesifik. Ingat bahwa objek pada subkelas harus tetap

merupakan objek superkelasnya. Contoh : reptil adalah binatang.

Perhatikanlah instans dari kelas tsb: seekor cicak adalah reptile, tetapi

belum tentu semua reptile adalah cicak. Demikian pula dengan kelas :

reptile termasuk binatang, tidak semua binatang adalah reptile. Hubungan

of 38

is-a adalah konsep inheritance.

Hubungan has-a (mempunyai) merefleksikan keseluruhan dengan

komponennya. Contoh : Sebuah mobil mempunyai mesin, mempunyai roda, ..

dst. Pemula dalam bidang OO sering mengimplementasikan hubungan ini

dengan inheritance. Yang lebih benar adalah : Kelas Mesin, Roda merupakan

data member dari kelas Mobil. Hubungan is -implemented-using

(diimplementasi menggunakan) termasuk di antara kedua hubungan itu.

Contoh : sebuah Daftar Nomor Telpon (TelponList) diimplementasi

menggunakan Notebook. Hubungan itu bukan inheritance, dan juga bukan

bagian dari. Ada banyak cara untuk melakukan impelementasi dari Daftar

nomor telpon. Bahkan perancang OO yang berpengalaman banyak yang

mengimplementasi TelponList sebagai turunan dari Notebook. Sebaiknya

TelponList "memiliki" notebook, berarti Notebook adalah data member dari

telpon List.

of 38

MATERI 5

UNIFIED MODELING LANGUAGE

5.1 Apa itu UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

of 38

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek. Konsepsi Dasar UML Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Rumbaugh

Booch Jacobson

Odell

Shlaer and Mellor

Gamma

Meyer

OMG (Object Management Group)

of 38

Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan: 1. Menguasai pembuatan diagram UML 2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML Tulisan ini pada intinya akan mengupas kedua hal tersebut. Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:

• use case diagram • class diagram • statechart diagram • activity diagram • sequence diagram • collaboration diagram • component diagram • deployment diagram

5.1 Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

of 38

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain. Contoh use case diagram :

5.2 Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok : 1. Nama (dan stereotype) 2. Atribut 3. Metoda Atribut dan metoda dapat memiliki salah satu sifat berikut :

• Private, tidak dapat dipanggil dari luar class yang bersangkutan • Protected, hanya dapat dipanggil oleh class yang bersangkutan dan

anak-anak yang mewarisinya • Public, dapat dipanggil oleh siapa saja

of 38

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.

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

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

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

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

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

Contoh class diagram :

of 38

5.3 Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari

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

stimuli yang diterima. Pada umumnya statechart diagram menggambarkan

class tertentu (satu class dapat memiliki lebih dari satu statechart

diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut

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

umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi

yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan

sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan

berwarna setengah.

Contoh statechart diagram :

of 38

5.4 Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu. Contoh activity diagram tanpa swimlane:

of 38

5.5 Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.

of 38

Contoh sequence diagram :

5.6 Collaboration Diagram

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

of 38

5.7 Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain. Contoh component diagram:

5.8 Deployment Diagram

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

of 38

Sebuah node adalah server, workstation, atau piranti keras lain yang

digunakan untuk men-deploy komponen dalam lingkungan sebenarnya.

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

didefinisikan dalam diagram ini.

Contoh deployment diagram :

5.9 Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.

2. Petakan use case untuk tiap business process untuk mendefinisikan

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

3. Buatlah deployment diagram secara kasar untuk mendefinisikan

arsitektur fisik sistem.

4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.

of 38

5. Berdasarkan use case diagram, mulailah membuat activity diagram.

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

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

7. Buarlah rancangan user interface model yang menyediakan antarmuka

bagi pengguna untuk menjalankan skenario use case.

8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.

9. Setelah class diagram dibuat, kita dapat melihat kemungkinan

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

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan

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

11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan

: • Pendekatan use case, dengan meng-assign setiap use case kepada

tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.

• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.

12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta

codenya. Model harus selalu sesuai dengan code yang aktual.

13. Piranti lunak siap dirilis.

oop gaul

Documents