METODOLOGI BERORIENTASI OBJEK
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 mempermudah 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 menghasilkan 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 Page 2 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
Page 3 of 38
pengetahuan (konsep yang mempunyai basis yang baku dan pengertian prinsipprinsip 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. Entity Relationship Diagrams
Semantic Data Modeling
y y y y
Attributes Instance Connections Generalization-Specialization Whole-Part Object Oriented Analysis
(Information Modeling)
y y y y
Object-Oriented Programming Languages & Knowledge-Based Systems
Attributes and Exclusive Service Communication with Messages Generalization-Specialization Inheritance
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. Page 4 of 38
b. Abstraksi Data: prinsip pendefinisian suatu type data dalam istilahistilah
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) Page 5 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.
Page 6 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-objeknya. Simbol kelas digambarkan dengan segiempat yang dicetak tebal dan di Page 7 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". Generalization Attribute Service
Specialization 1
Specialization 2
Attribute
Attribute
Service
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". Page 8 of 38
Whole Attribute Service 1,m
1,m
1
1
Part 1
Part 2
Attribute
Attribute
Service
Service
Gambar 2.4 Simbol Whole-parts 2.3. Identifikasi Lapisan Subjek Subjek adalah suatu mekanisme yang membantu pembaca untuk menganalisa 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.
1. Subject1 Class-&-Object1 Class-&-Object2
2. Subject2 Class-&-Object3 Class-&-Object4
Gambar 2.5 Simbol Subject Page 9 of 38
Penggambaran dari simbol diatas dengan lapisan yang berbeda dapat dilihat dalam gambar dibawah ini. 1
1
2
2
1
1
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 permasalahannya). 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. Page 10 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
Class & Object Attribute 1 Atribute 2
Attribute 1 Attribute 2
Service
Service
Gambar 2.7 Simbol Attributes Atribut ditempatkan dibagian tengah dari kelas-&-objek dan dari kelas. Class & Object Attribute
Class & Object 0, m
Service
1
Attribute Service
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 memperlihatkan "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
Class
Attribute
Attribute
Service 1 Service 2
Service 1 Service 2
Gambar 2.9 Simbol Service Service ditempatkan dibagian bawah dari simbol kelas-&-objek dan kelas.
Page 11 of 38
Message connection adalah model yang memproses ketergantungan dari sebuah objek, indikasi yang diperlukan untuk service dalam melaksanakan pekerjaan yang berhubungan dengan "tanggungjawabnya".
Sender
Receiver
Attribute
Attribute
Service
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.
Page 12 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
Human
Problem
Interaction Domain
Structure
Component Component
layer
Task Managemen t Component
Data Management Component
Attribute layer Service layer 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 dimasukkan 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
Page 13 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 berinteraksi 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,
Page 14 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 menghasilkan 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.
Page 15 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 Page 16 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
Page 17 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.
Page 18 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 Page 19 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 // Hubungan dengan kelas lain Class X // Nama Kelas // feature: Atribut // feature: Method // invarian kelas End Class X;
Contoh Kelas Sederhana Point
Class Point // atribut x,y : integer End class 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 Page 20 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 Page 21 of 38
·
Interface
Hubungan antar kelas Antara sebuah kelas dengan kelas yang lain ada hubungan : ClientSupplier 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
Page 22 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, Page 23 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 Page 24 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-implementedusing 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 Page 25 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.
Page 26 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 wirfsbrock [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.
Page 27 of 38
Rumbaugh Booch
Jacobson
OMG
Odell
(Object Management Group)
Meyer
Shlaer and Mellor Gamma
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.
Page 28 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 diagramdiagram 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 diinclude 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.
Page 29 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 Page 30 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 :
Page 31 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 : Page 32 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 jalurjalur 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:
Page 33 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.
Page 34 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.
Page 35 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 dideploy 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
Page 36 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. Page 37 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.
Page 38 of 38
