BAB III METODOLOGI
3.1
Rangkaian
Metodologi
Perancangan
Multimedia
Database Aplikasi internet radio merupakan aplikasi broadcasting data audio melalui teknologi internet. Aplikasi ini menggunakan multimedia database untuk mengelola data audio yang akan disiarkan tersebut. Pada hakikatnya sebuah applikasi internet radio merupakan salah satu jenis multimedia application, oleh karenanya secara makro positioning-nya berada di dalam application domain di dalam Multimedia Global Structure. Multimedia Global Structure secara garis besar memiliki tiga buah domain yaitu: 1. Application Domain 2. System Domain 3. Device Domain
xcvii
Application Domain
Tools and Applications
Communication Systems
System Domain
Operating System
Database Management System
Computer Technology
Compression
Device Domain
Storage
Network Audio
Image
Video Animation
Gambar 3.12 Multimedia Global Structure
Pada gambar 3.1, ditampilkan interaksi antara application domain, system domain dan device domain, serta komponen-komponen yang membentuk masing-masing domain tersebut. Device domain berhubungan dengan perangkat keras yang digunakan seperti storage, network, dan sebagainya. Di atas device domain, terletak system domain yang terdiri dari komponen-komponen communication systems, operating systems dan database
management
systems.
Interface
yang
menghubungkan
komponen-komponen dalam system domain adalah computer technology. Application domain yang terletak di atas system domain, terdiri dari tools dan aplikasi-aplikasi multimedia yang digunakan dalam mengelola data multimedia. Dalam membangun aplikasi piranti lunak, teknik yang populer digunakan
sekarang ini adalah dengan menggunakan pemrograman
berorientasi objek (object-oriented programming (OOP)). Dalam OOP
xcviii
digunakan object-oriented programming language (OOPL) (bahasa pemrograman berorientasi objek). OOPL yang digunakan dalam membangun aplikasi internet radio adalah bahasa pemrograman Java, yang dikembangkan oleh Sun Microsystems. OOPL tidak memiliki kemampuan mengelola database secara built-in, sehingga diperlukan object-oriented database (OODB) yang menambahkan kemampuan pengelolaan database ke dalam OOPL. Alasan digunakannya OODB daripada relational database adalah masalah impedance mismatch yang menyebabkan turunnya kinerja piranti lunak. Object oriented database management system (OODBMS) yang digunakan dalam aplikasi internet radio ini, adalah db4o. Seperti yang digambarkan dalam gambar 3.1, DBMS berada dalam system domain, yang nantinya digunakan oleh aplikasi yang berada dalam application domain untuk dapat mengelola data multimedia secara fisik yang berada dalam device domain.
Gambar 3.13 Hubungan MMDB Design dengan OODB Design OODBMS untuk dapat menangani data multimedia, maka data multimedia ini diperlakukan sebagai suatu object. Multimedia object ini
xcix
berasosiasi dengan audio dalam format mp3. Karena multimedia object ini adalah suatu object, maka teknik-teknik yang digunakan dalam perancangan object oriented database (OODB design) dapat digunakan dalam merancang multimedia database (MMDB design). Sehingga hubungan antara OODB design dengan MMDB design adalah OODB design merupakan generalisasi dari MMDB design yang dapat dinyatakan melalui pemodelan dengan diagram UML seperti pada gambar 3.2. Karena perancangan multimedia database (MMDB design) merupakan OODB design yang secara spesifik ditujukan untuk mengelola multimedia database, maka metode object oriented analysis and design (OOAD) yang akan digunakan dalam merancang aplikasi internet radio dan digunakan juga dalam merancang multimedia database yang nantinya akan digunakan dalam aplikasi internet radio yang dibangun.
3.2 Object Oriented Analysis and Design Object Oriented Analysis and Design (OOAD) adalah sekumpulan panduan secara umum dalam menjalankan analisa dan perancangan. Karena merupakan panduan secara umum, maka perlu dilakukan modifikasi sesuai dengan kebutuhan organisasi dan proyek. OOAD mencerminkan perspektif atau sudut pandang utama pada sistem dan lingkungannya, yaitu: isi dari sistem informasi, bagaimana sistem akan digunakan, sistem secara keseluruhan dan komponenkomponen dari sistem. Perspektif ini dihubungkan ke dalam lima aktivitas utama dalam OOAD yaitu:
c
1. Problem Domain Analysis 2. Application Domain Analysis 3. Component Design 4. Persistence Design 5. Architectural Design Sebelum membahas lebih mendalam mengenai lima aktivitas utama di atas, perlu dipahami apa itu problem domain dan application domain. Problem domain adalah suatu konteks atau bisnis proses yang ada pada dunia nyata, yang diadministrasi, dikontrol, dan dimonitor oleh sistem (Mathiassen et al 2000: 6). Sedangkan application domain adalah organisasi yang mengadministrasi, mengontrol, dan memonitor problem domain (Mathiassen et al 2000: 6). Selama proses analisa dan perancangan ini pemahaman terhadap kedua domain ini sangat diperlukan. Kembali kepada lima aktivitas utama dalam OOAD, aktivitasaktivitas ini dapat digambarkan saling berinteraksi lewat diagram di bawah ini:
ci
Model Requirements for Use Problem Domain Analysis Component Design
Application Domain Analysis
Persistence Design
Specification of Persistence
Specification of Component
Architectural Design
Specification of Architecture
Gambar 14.3 Aktivitas Utama dan Hasil dari OOAD Analisa dan perancangan selalu iteratif, di mana penambahan ide dalam satu perspektif akan menimbulkan ide baru dalam perspektif lainnya. Proses iteratif ini digambarkan dalam diagram dengan panah dua arah dalam menghubungkan aktivitas-aktivitas di atas. Penjelasan dari ke-lima aktivitas di atas adalah: •
Problem Domain Analysis adalah aktivitas dalam mengidentifikasi dan memodelkan suatu problem domain. Hasil dari aktivitas ini adalah model dari problem domain.
cii
•
Application Domain Analysis adalah suatu aktivitas yang menentukan requirement dari sistem. Hasil dari aktivitas ini adalah keseluruhan requirement dari sistem.
•
Component Design adalah suatu aktivitas mendesain seluruh komponen yang dibutuhkan oleh sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen.
•
Persistence Design adalah suatu aktivitas mendesain seluruh transient object untuk menjadi persistence object ketika proses komputasi berlangsung. Hasil dari aktivitas ini adalah spesifikasi dari persistensi (specification of persistence)..
•
Architecture Design adalah suatu aktivitas dalam menjabarkan keseluruhan sistem dan hubungan antar komponen-komponen dari sistem dan interaksinya. Hasil dari aktivitas ini adalah spesifikasi dari arsitektur.
3.2.1 System Definition Sebelum di bahas lebih detail masing-masing aktivitas di atas, akan dibahas mengenai penentuan sistem. Tugas dari seorang pengembang
adalah
merancang
solusi
yang
akan
diimplementasikan secara teknikal dan secara sosial. Untuk itu diperlukan pemahaman terhadap struktur, relasi dan detil dari organisasi user dan mengevaluasi dan mengelola teknologi yang relevan secara profesional.
ciii
Karena perbedaan cara pandang dari masing-masing orang, pengembang sistem harus mencoba mencari interprestasi yang paling penting. System definition diartikan sebagai deskripsi secara ringkas dari sistem yang terkomputerisasi dan dinyatakan dalam bahasa natural. Penggambaran aktivitas dalam menghasilkan system definition dapat dilihat pada gambar di bawah ini:
Ideas
Situation
Systems
System definition
Gambar 3.15 Sub-aktivitas dalam Pemilihan Sistem Pada gambar 3.4 ditampilkan tiga sub-aktivitas. Subaktivitas pertama berfokus pada: mendapatkan cara pandang keseluruhan dari situasi dan interpretasi dari masing-masing orang. Sub-aktivitas kedua menciptakan ide dan mengevaluasi ide-ide untuk
rancangan
sistem.
Dalam
sub-aktivitas
ketiga,
diformulasikan dan dipilih system definition, didiskusikan dan dievaluasi beberapa alternatif dari system definition ini dikaitkan dalam situasi tertentu.
civ
Mathiassen et al 2000, membuat suatu kriteria dari system definition yang baik yaitu FACTOR, untuk menggambarkan apa saja yang harus ada dalam definisi sistem yang dibuat: Functionality:
Fungsi sistem dalam mendukung tugas-tugas dari application domain.
Application domain: Bagian-bagian dari organisasi yang mengadministrasi, memonitor atau mengontrol suatu problem domain. Condition:
Kondisi di mana sistem akan dibangun dan digunakan.
Technology:
Berhubungan dengan teknologi yang digunakan dalam membangun sistem dan teknologi di mana sistem akan dijalankan.
Objects:
Objek utama dalam problem domain.
Responsibility:
Tanggung jawab sistem secara keseluruhan dalam hubungannya dengan lingkungannya.
3.2.2 Problem Domain Analysis Problem domain adalah bagian dari konteks yang diatur, dimonitor atau dikontrol oleh sistem. Problem domain analysis memodelkan sistem yang dilihat oleh user dalam dunia nyata. Setelah dibuat sebuah system definition, saatnya dilakukan aktivitas dalam problem domain analysis.
cv
Fokus pada proses analisa ini pada cara pandang user pada sistem di masa depan terhadap problem domain. Setelah didapatkan model yang baik, model ini dapat digunakan dalam merancang
dan
mengimplementasikan
sistem
yang
dapat
melakukan proses, berkomunikasi dan menampilkan informasi mengenai problem domain secara tepat guna dan tepat sasaran. Tujuan dari problem-domain analysis adalah membangun suatu model. Dalam pemodelan ini digunakan fokus objectoriented pada konsep inti untuk mendeskripsikan bagaimana user mengadministrasi, memonitor atau mengontrol sistem. Aktivitas pemodelan problem domain analysis terbagi menjadi tiga aktivitas yang digambarkan pada gambar 3.5. System Definition
Classes
Behavior
Structure Model
Gambar 3.16 Aktivitas dalam Modeling Problem-Domain Langkah pertama adalah memilih objects, classes dan events yang akan dijadikan elemen dari model problem-domain.
cvi
Selanjutnya, dibangun model dengan berfokus pada relasi secara struktural antara class dan object yang telah dipilih. Ini menampilkan perubahan dari level objek ke dalam level model. Akhirnya, difokuskan pada properti dinamik dari objek, yang merepresentasikan pergerakan kembali ke level objek. Jadi dapat disimpulkan bahwa dalam pemodelan ini analisa dilakukan dari bagian-bagian ke arah keseluruhan dan kembali ke bagian-bagian lagi. Secara detail, bagian-bagian dari pemodelan problem domain dijelaskan sebagai berikut: •
Classes menjelaskan pendekatan dalam mendefinisikan konten dari sistem informasi. Class menentukan bagian yang relevan dalam problem domain, karena domain dipandang sebagai dinamik, maka di sini juga diperhatikan even-even yang berhubungan dengan objek. Even di sini dipandang sebagai elemen dasar dari object behavior.
•
Structure berhubungan dengan hubungan struktural antara classes dan objects. Relasi ini digambarkan dalam class diagram yang menampilkan hubungan terstruktur antar class dan object.
•
Behavior menggambarkan perilaku objek dan interaksinya. Bagian-bagian dari behavior adalah event trace, behavioral pattern (deskripsi dari even yang mungkin dikerjakan dari
cvii
semua objek dalam class) dan attribute. Hasil dari aktivitas ini adalah statechart diagram.
3.2.3 Application Domain Analysis Application domain analysis berfokus pada bagaimana suatu sistem akan digunakan, mendefinisikan kebutuhan dari fungsi sistem dan interface. Hasil dari aktivitas ini adalah sistem requirement
secara
lengkap.
Mendefinisikan
requirement
memerlukan proses iteratif. Kerjasama antara pengembang dan user atau pemakai dibutuhkan. Requirement untuk usage, functions, dan interfaces harus dievaluasi. Requirement perlu divalidasi dengan melakukan eksperimen bersama dengan user. Ada tiga aktivitas utama dalam application domain analysis, yang dapat digambarkan pada gambar 3.6
System Definition
Usage
Interfaces
Functions Requirements
cviii
Gambar 3.17 Aktivitas dalam Application Domain Analysis Bagian-bagian dalam aktivitas ini adalah: •
Usage menggambarkan bagaimana suatu sistem berinteraksi dengan orang dalam konteks. Konsep yang digunakan adalah use case dan actor.
•
Functions menggambarkan kemampuan proses dari sistem informasi, suatu fasilitas untuk membuat suatu sistem berguna bagi aktor. Konsep yang digunakan function.
•
Interfaces menggambarkan kebutuhan system interface dari sistem, suatu fasilitas yang membuat model sistem dan function tersedia bagi actor. Konsep yang digunakan adalah interface, user interface dan sistem interface.
3.3 Object Oriented Design Setelah dibuat model yang tepat pada rancangan desain melalui proses application domain analysis dan problem domain analysis, dilanjutkan dengan membuat desain arstitektur sistem ini. Secara keseluruhan aktivitas pada object oriented software system design terbagi atas tiga buah aktivitas utama, yaitu:
• Component Design Aktivitas merancang komponen adalah suatu kegiatan yang merancang seluruh komponen-komponen yang dibutuhkan oleh sistem. Hasil yang
cix
diperoleh dari pelaksanaan aktivitas tersebut adalah spesifikasi komponen (specification of component).
• Persistence Design Persistence design adalah suatu kegiatan desain yang membuat keberadaan transient object dapat menjadi persistence object ketika proses komputasi berlangsung. Proses desain penting sekali untuk kebutuhan pemuatan kembali (requirement of loading) persistence object menjadi transient object ketika dibutuhkan sistem pada saat komputasi berlangsung. Hasil yang diperoleh dari pelaksanaan aktivitas ini adalah spesifikasi persistensi (specification of persistence).
• Architecture Design Aktivitas merancang arsitektur sistem adalah suatu kegiatan yang bertujuan mendeskripsikan keseluruhan struktur sistem dan hubungan antar komponen-komponen utama dari sistem tersebut beserta interaksinya. Hasil yang diperoleh dari aktivitas ini adalah spesifikasi arsitektur (specification of architecture)
cx
Analysis Model Component Design
Persistence Design
Specifications of Persistence
Specifications of Component Architecture Design
Specifications of Architecture
Gambar 3.18 Aktivitas Software System Design Aktivitas pada desain sistem berawal dari merancang komponen sistem. Aktivitas tersebut diawali dengan menerima input berupa dokumen analisa model (analysis model). Setelah aktivitas merancang komponen selesai dilakukan, kemudian dibuat spesifikasi komponen (specifications of component). Proses merancang komponen dapat memberikan umpan balik terhadap hasil dari kegiatan analisis. Setelah proses perancangan komponen telah diselesaikan dengan baik, maka selanjutnya dilaksanakan aktivitas persistence design. Aktivitas tersebut menerima input spesifikasi komponen dan dokumen analisa model. Sewaktu aktivitas persistensi dilakukan, proses iterasi dengan aktivitas merancang komponen dapat dilakukan untuk memvalidasi dan mengoreksi spesifikasi komponen yang telah dihasilkan. Selanjutnya dilaksanakan aktivitas merancang arsitektur
cxi
sistem. Aktivitas ini menerima input spesifikasi komponen, spesifikasi persistensi, dan dokumen analisa model. Untuk merancang arsitektur sistem, proses iterasi dengan aktivitas merancang komponen dan persistensi dapat dilakukan untuk memvalidasi dan mengoreksi jika pada dua aktivitas sebelumnya masih terdapat kekurangan. Hasil akhir yang didapat adalah spesifikasi arsitektur sistem. Dalam sub bab selanjutnya akan dibahas secara mendetail ketiga aktivitas dalam desain software.
3.3.1 Component Design Untuk merancang komponen sistem piranti lunak, dimulai dengan mengkonstruksi komponen problem domain model, dilanjutkan dengan komponen functional system, dan setelahnya baru komponen interface. Urutan ini didasarkan pada perbedaan sifat stabilitas dari tiap-tiap komponen. Urutan ini dipengaruhi oleh tingkat stabilitas dari komponen-komponen ini.
Stable Properties
Transient Properties
Problem Domain Model
Functional System
Interface
Gambar 3.19 Sifat Stabilitas Komponen Sistem Piranti Lunak Pada gambar 3.8, terlihat bahwa dari ketiga komponen tersebut, komponen problem domain-lah yang memiliki tingkat
cxii
stabilitas yang paling tinggi, disusul komponen functional system, dan terakhir komponen interface yang paling mudah berubah. Sifat stabilitas yang tinggi menunjukkan bahwa komponen tersebut tidak mudah berubah. Selanjutnya, aktivitas-aktivitas yang dilakukan dalam merancang komponen sistem piranti lunak dapat digambarkan pada gambar 3.9.
Dokumen Pemodelan Domain
Problem Domain Component Design
PDM Component
Functional Component
Functional System Component Design
Interface Component Design
Interface Component & Sequence Diagram
Gambar 3.20 Aktivitas pada Desain Komponen
cxiii
Dokumen pemodelan domain yang berfungsi sebagai input dari kegiatan ini meliputi: class diagram, pola behavior objek, use case diagram dan spesifikasinya, serta CRC Card. Dokumen di atas digunakan sebagai input pada domain model component design, dan hasilnya diperoleh komponen problem domain model. Selanjutnya dilakukan aktivitas functional system component design dengan input dokumen pemodelan domain dan komponen problem domain yang telah dihasilkan. Setelah aktivitas ini selesai dilakukan, diperoleh komponen functional system. Terakhir, dilakukan aktivitas interface component design, dengan input dokumen pemodelan domain, komponen problem domain model, komponen sistem fungsional. Hasil yang diperoleh adalah komponen interface dan sequence diagram yang menggambarkan seluruh interaksi objek-objek yang terdapat di dalam sistem.
3.3.2 Persistence Design Aktivitas persistence design
adalah aktivitas yang
dilakukan pertama kali dalam pembuatan piranti lunak. Ini dibutuhkan karena semua piranti lunak yang menjalankan proses komputasi pada umumnya membutuhkan persistensi object ke dalam media penyimpanan. Yang dimaksud dengan persistensi object adalah proses penyimpanan objek ke dalam file atau database.
Oleh
karena
persistensi
object
berelasi
dengan
penyimpanan object kedalam database, maka aktivitas persistence design equivalence dengan aktivitas object oriented database design.
cxiv
3.4 Object Oriented Database Design Dalam konsep object-oriented, suatu piranti lunak dibangun oleh sekumpulan komponen yang saling berinteraksi satu dengan lainnya. Setiap komponen yang terdapat di dalam piranti lunak tersebut memiliki tanggung jawab yang telah dirumuskan dengan baik. Ketika piranti lunak ini dijalankan di atas sistem operasi, maka komponen-komponen ini diload ke dalam memori. Setelah komponen telah transient dalam memori, ada komponen yang mempunyai fixed object, ada juga komponen yang mempunyai dynamic object (sesuai dengan tanggung jawabnya masingmasing). Cara membuat komponen itu persistence antara satu dengan lainnya tidaklah sama. Setelah komponen problem domain model selesai dirancang, selanjutnya komponen ini dikonstruksi menjadi piranti lunak dalam bentuk kode program. Komponen problem domain model ada dua jenis yaitu: •
Transient komponen problem domain model
•
Persistence komponen problem domain model
Transient komponen PDM adalah komponen PDM yang sifatnya selalu ada dalam CPU selama proses komputasi berlangsung. Komponen ini berada di dalam executable file aplikasi dan dikonstruksi melalui proses kompilasi. Komponen ini bersifat biner. Persistence komponen PDM adalah komponen PDM yang residence di dalam database. Oleh karenanya kompoenen ini sifatnya selalu ada, baik selama proses komputasi berlangsung, maupun saat proses komputasi dihentikan.
cxv
Gambar 3.21 Transient & Persistent Komponen Problem Domain Model
Supaya persistent, dibutuhkan suatu storage yang digunakan untuk menyimpan entity object yang sedang berjalan dalam proses komputasi. Tahapan yang dilakukan adalah membuat classifier komponen problem domain model di dalam database schema. Sehingga object database dapat menyimpan semua transient entity object untuk kemudian dapat digunakan kembali pada saat proses komputasi dijalankan.
3.4.1 Persistensi Object yang Memiliki Hubungan Struktur Sederhana Bentuk hubungan struktur sederhana antar objek terbagi atas tiga bentuk: •
Hubungan struktur association
•
Hubungan struktur aggregation
cxvi
•
Hubungan struktur generalization
3.4.1.1 Persistensi Object dengan Hubungan Association Di dalam UML, hubungan association memiliki banyak jenis, yakni: navigational association, bidirectional association, ternary association dan N-ary association. Pembahasannya sebagai berikut:
Navigational Association Di dalam class diagram bentuk hubungan struktur assosiasi adalah yang paling sering ditemukan. Navigational association adalah salah satunya. Bentuk hubungan asosiasi ini sifatnya satu arah. Untuk merealisasikan Navigational Association didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: •
Didalam persistence component, hubungan object yang memiliki navigation association direalisasikan dengan korespondensi atribut dari object key yang berhubungan dan atribut salah satu object harus memiliki akses operation terhadap object yang satunya lagi. untuk lebih jelasnya,
ilustrasi
bagaimana
dibawah
rancangan
ini
dapat
menjelaskan
navigational
association
direalisasikan didalam persistence component.
Gambar 3.22 Navigational Association
cxvii
Bidirectional Association Di dalam class diagram bentuk hubungan struktur assosiasi Bidirectional Association adalah bentuk hubungan asosiasi yang sifatnya dua arah. Untuk merealisasikan Bidirectional Association didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: Di dalam persistence component, hubungan object yang memiliki
bidirectional
association
direalisasikan
dengan
korespondensi atribut dari object key yang berhubungan dengan atribut salah satu object, karena memiliki hubungan dua arah, maka kedua object saling memiliki akses operation terhadap masing-masing object. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan bidirectional association direalisasikan didalam persistence component.
Gambar 3.23 Bidirectional Association Salah satu bentuk lain dari bidirectional association adalah hubungan entity class dengan dirinya sendiri. Hubungan ini di dalam design pattern sering diistilahkan dengan self containing class pattern dan masuk ke dalam golongan structural pattern. Untuk merealisasikan self containing class pattern di dalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut:
Di dalam persistence component, hubungan object yang memiliki hubungan entity class dengan dirinya sendiri ini
cxviii
direalisasikan dengan teknik persistensi objek ke dalam database
pada
prinsipnya
sama
dengan
teknik
bidirectional di atas. Yang harus diperhatikan adalah constructor object member. Ketika sebuah member instance di-create, pastikan attribute LineupID merujuk ke
attribute
MemberID
milik
upline.
Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan
bagaimana
rancangan
bidirectional
association direalisasikan didalam persistence component.
Gambar 3.24 Self Containing Class Patterns Ternary Association dan N-ary Association Di dalam class diagram bentuk hubungan struktur assosiasi N-ary
association
adalah
sebuah
memungkinkan hubungan lebih
bentuk
dari dua
asosiasi
yang
object. Ternary
association adalah N-ary association yang menggantikan nilai N dengan nilai tiga. Untuk merealisasikan N-ary Association didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: Di dalam persistence component, hubungan object yang memiliki N-ary association direalisasikan dengan korespondensi atribut dari object key yang berhubungan dengan atribut beberapa object. Karena memiliki hubungan beberapa arah, maka beberapa
cxix
object bisa saling memiliki akses operation terhadap object-object yang berasosiasi ini. Hal yang penting harus diperhatikan adalah sebuah
association
class
tidak
bisa
dihubungkan
dengan
association relationship yang lain, karena association class adalah asosiasi itu sendiri. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan N-ary association direalisasikan di dalam persistence component.
*
Gambar 3.25 N-ary Association
3.4.1.2 Persistensi Object dengan Hubungan Aggregation Di dalam UML, aggregation terdiri dari dua jenis, yaitu: aggregation yang memiliki ownership yang kuat dan yang lemah. Aggregation yang memiliki ownership yang kuat diistilahkan dengan composition. Secara notasi, aggregation dan composition juga dibedakan.
cxx
Gambar 3.26 Aggregation dan Composition Untuk merealisasikan aggregation dan compositon didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: •
Pada aggregation menyatakan kepemilikan suatu part, sedangkan composition menyatakan suatu object sebagai container dari object part-nya. Inilah hal yang harus diperhatikan dalam proses persistensi. Perbedaan antara aggregation dan composition dalam implementasi hanya terletak pada konsepnya saja.
Salah satu bentuk aggregation structure adalah hubungan entity class dengan dirinya sendiri. Hubungan ini dalam design pattern diistilahkan dengan nama self containing class pattern. Seperti pada gambar di bawah ini terlihat sebuah Folder dapat memiliki banyak Folder.
cxxi
Gambar 3.27 Containing Class dengan Aggregation Structure
3.4.1.3 Persistensi Object dengan Hubungan Generalization Generalization mengekspresikan inheritance (pewarisan sifat) dari super class ke sub class. Dalam generalization, semua common properties yang dimiliki super class akan diwariskan ke sub class-nya, kecuali properties yang dideklarasikan private.
Gambar 3.28 Generalization Structure Inheritance merupakan sebuah konsep yang fundamental di dalam object-oriented. Dua hal yang berkait dengan inheritance adalah:
cxxii
•
Abstract Class
•
Polymorphism
Abstract class adalah class yang tidak punya object. Eksistensinya di dalam class diagram adalah untuk mendefinisikan suatu frame. Object dari sebuah abstract class direalisasikan melalui sub class-nya. Instansiasi object dari abstract class tidak diperbolehkan. Abstract class harus tetap dimasukkan ke dalam object database schema. Selanjutnya, polymorphism adalah ciri khas dari objectoriented yang menjelaskan kumpulan object dapat memiliki behavior yang berbeda dari fungsi yang sama.
3.4.1.4 Persistensi Interdependent Partition Component Yang dimaksud dengan hubungan struktur dependency adalah bahwa sebuah model elemen memerlukan kehadiran dari model elemen yang lain. Sebagai implikasinya jika sebuah model elemen yang telah dispesifikasikan berubah, maka model elemen lain yang dependent dengan model elemen tersebut berpotensi ikut berubah. Di dalam UML, dependency itu memiliki banyak sekali stereotype. Penulisan stereotype pada notasi dependency bertujuan untuk menjelaskan secara tepat jenis dari dependency yang terjadi. Secara garis besar, dependency terdiri atas empat variant yang setiap variant-nya memiliki banyak jenis. Keempat variant itu adalah: •
Binding Binding dependency mempunyai hanya sebuah stereotype, yaitu <
>. Dependency ini menghubungkan unsur yang terikat ke template class yang akan melengkapi definisi dari class yang dihasilkan.
cxxiii
•
Abstraction Abstraction dependency mendefinisikan hubungan antara dua elemen atau sekumpulan elemen yang mempresentasikan konsep yang sama pada tingkat abstraksi yang berbeda. Abstraction dependency mempunyai empat buah stereotype yaitu:
1. <<derive>> dependency stereotype menyatakan spesifikasi yang berlebih-lebihan di dalam model sebagai nilai dari elemen yang diperoleh dari elemen yang diperlukan. 2. <>
dependency
stereotype
menetapkan
hubungan antara elemen di dalam implementasi model dan elemen di dalam spesifikasi model. 3. <> dependency stereotype menetapkan hubungan antara model elemen pada tingkat perbedaan abstraksi. 4. <> dependency stereotype menetapkan hubungan antara dua elemen yang mempresentasikan konsep yang sama di dalam model yang berbeda. •
Usage Usage dependency menetapkan suatu kebutuhan, di mana sebuah model elemen disajikan untuk kehadiran model elemen yang lain. Usage dependency mempunyai enam buah stereotype, yakni: 1. <> dependency stereotype menetapkan kolaborasi antara dua buah operasi. Operasi yang satu memanggil operasi yang lain. 2. <> dependency stereotype menyiratkan bahwa penciptaan sebuah instance dari dependent class akan mengakibatkan penciptaan dari instance class tersebut merupakan target dari dependency.
cxxiv
3. <> dependency stereotype menyatakan bahwa operasi pada dependent class akan men-create instance dari class yang merupakan target dari dependency. 4. <<send>> dependency stereotype menetapkan bahwa operasi mengirim signal. 5. <<use>> dependency stereotype mengindikasikan sebuah class dependent terhadap class lain dalam rangka untuk merealisasikan implementation secara lengkap. 6. <<substitute>> dependency stereotype digunakan untuk mengindikasikan bahwa sebuah class dapat disubstitusi oleh class yang lain, dengan syarat tidak ada hubungan inheritance •
secara
langsung
antara
class
tersebut
Permission Permission
dependency
digunakan
untuk
menetapkan
accessibility dari model eleman di dalam suatu namespace yang berbeda. Permission dependency memiliki tiga buah stereotype, yakni: 1. <> dependency stereotype menyatakan bahwa dependent package dapat menggunakan elemen dari package yang menjadi target dependency. 2. <> dependency stereotype menyatakan bahwa dependent package menyertakan model elemen dari package yang menjadi target dari dependency. 3. <> dependency stereotype mengesampingkan normal visibility constraints dan membiarkan dependent elemen
untuk
mengakses
target
elemen
tanpa
memperhatikan visibilitas yang telah ditetapkan.
3.4.2 Persistensi Object yang Memiliki Struktur Data Kompleks
cxxv
Saat memodelkan suatu problem domain yang kompleks, maka akan memicu timbulnya class-class dengan struktur data yang kompleks. Class-class ini tidak hanya memiliki data-data dengan tipe data primitive seperti integer, string atau object type, tetapi juga data array atau collection object.
3.4.2.1 Persistensi Complex Object yang Memiliki Struktur Data Array Struktur data array adalah struktur data yang umumnya ada dan digunakan untuk memodelkan hal-hal yang tidak simpel atau spesifik yang terjadi di dalam problem
domain.
Struktur
data
ini
secara
logical
menyediakan suatu buffer dalam wujud seperti slot di dalam sebuah object. Slot ini menampung data yang sifatnya homogen dan ukuran dari slot ini sifatnya tetap. Untuk
merealisasikan
complex
object
yang
memiliki struktur data array di dalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: •
Didalam persistence component, complex object yang memiliki struktur data array direalisasikan dengan menempatkan object array di dalam class dengan menggunakan attribute array. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan complex object yang memiliki struktur data array direalisasikan didalam persistence component.
cxxvi
Gambar 3.29 Struktur Data Array di Dalam Class
3.4.2.2 Persistensi Complex Object yang Memiliki Struktur Data Collection of Object Untuk mengatasi pemodelan problem domain yang kompleks dan dinamis, object database memperkenankan untuk membuat struktur data collection of object di dalam object. Untuk merealisasikan struktur data collection of object di dalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut: •
Didalam persistence component, complex object yang memiliki struktur data collection of object direalisasikan dengan menempatkan object tersebut di dalam class dengan menggunakan referensi terhadap object ini. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan complex object yang memiliki struktur data collection of object direalisasikan didalam persistence component.
cxxvii
Gambar 3.30 Struktur Data Collection of Object di Dalam Class
3.4.3 Persistensi Binary Large Object (BLOB) Ke Dalam Object Database Untuk menangani binary large object (BLOB) yang berupa data audio dalam aplikasi internet radio ini, object database menyediakan tipe data Blob. Object database dalam hal ini OODBMS db4o, melalui tipe data Blob, menyimpan data multimedia ke dalam satu direktori tertentu, terpisah dari file database utama dan menyediakan fasilitas upload dan download secara asynchronous dan dalam thread yang berbeda. Metoda dalam
menangani
blob
dalam
object
database
dengan
menggunakan tipe data Blob ada beberapa hal yang perlu diperhatikan di antaranya: •
Definisikan field Blob dalam class.
•
Pada saat object dalam class disimpan, db40 secara otomatis menangani field Blob yang telah diset.
•
Untuk membaca suatu file blob ke dalam db4o system, digunakan metode readFrom.
•
Untuk menulis suatu file blob di dalam db4o system, digunakan metode writeTo.
cxxviii
•
Untuk mengetahui status apakah suatu data telah tersimpan, digunakan metode getStatus, yang juga dapat digunakan untuk mengetahui status penyelesaian proses yang sedang berjalan.
Langkah-langkah dalam menangani Blob yaitu: 1. Mendefinisikan Blob Storage (tempat penyimpanan file Blob). Java: Db4o.configure().setBlobPath(storageFolder); Variabel storageFolder adalah suatu tipe data String yang merepresentasikan
local
path
atau
server
path
untuk
menyimpan BLOB. Jika ini tidak didefinisikan, db4o akan menggunakan folder default yaitu "blobs" dalam direktori user. 2. Menyimpan BLOB ke dalam database. Dalam menyimpan BLOB digunakan method readFile. Method ini
membaca
blob
dari
suatu
lokasi
tertentu
dan
memasukkannya ke dalam database. Java: Blob.readFrom( File ) Selama proses penyimpanan dalam thread yang telah didedikasikan
untuk
proses
ini,
dapat
digunakan
Blob#getStatus() di dalam suatu loop untuk mengetahui progress dari proses penyimpanan tersebut. 3. Membaca BLOB dari dalam database. Dalam membaca BLOB dari dalam database digunakan metode writeFile. Metode ini membaca blob dari dalam database dan menaruhnya ke suatu lokasi tertentu. Java: Blob.writeFrom( File ) Selama
proses
didedikasikan
pembacaan untuk
dalam
proses
ini,
thread dapat
yang
telah
digunakan
Blob#getStatus() di dalam suatu loop untuk mengetahui progress dari proses pembacaan tersebut.
cxxix
3.5 Architecture Design Bagian terpenting dalam sistem desain adalah membuat arsitektur sistem, karena arsitektur sistem menentukan apa yang mungkin dan tidak mungkin dilakukan oleh sistem. Menurut Mathiassen et al (2000), arsitektur suatu sistem terdiri atas dua bagian, yaitu: •
Arsitektur komponen Arsitektur komponen adalah struktur sistem yang terdiri atas komponen yang saling berhubungan. Dalam arsitektur komponen kita melihat aspek yang stabil dari sistem, yaitu class, komponen dan hubungannya. Oleh karena itu, arsitektur kompoenen mendeskripsikan struktur sistem pada tingkatan logis (logical level).
•
Arsitektur proses Arsitektur proses adalah struktur eksekusi sistem yang terdiri atas proses-proses yang satu sama lain saling bergantung (interdependent processes). Dalam arsitektur proses kita melihat aspek dinamis dari sistem, di mana objek-objek saling berinteraksi pada tingkat physical process. Penentuan koordinasi proses adalah salah satu aspek penting yang harus diperhatikan, khususnya untuk proses concurrent yang terjadi di dalam sistem. Inti dari aktivitas desain adalah merancang arsitektur piranti lunak.
Arsitektur ini mendeskripsikan solusi logis secara menyeluruh dari piranti lunak yang hendak dibangun tanpa harus benar-benar membangunnya. Aktivitas pada architecture design digambarkan pada gambar di bawah ini:
cxxx
Component Specification Deployment Diagram
Component Architecture Design
Process Architecture Design
Architecture Component Specification
Gambar 3.31 Aktivitas pada Architecture Design Input dari aktivitas ini adalah spesifikasi komponen yang telah dihasilkan pada fase desain komponen. Selanjutnya dirancang arsitektur sebagai langkah awal. Output yang dihasilkan dari aktivitas tersebut adalah spesifikasi arsitektur komponen dari sistem piranti lunak yang dibangun. Setelah proses ini, dilanjutkan dengan input spesifikasi arsitektur komponen yang telah dihasilkan pada aktivitas sebelumnya. Proses desain komponen arsitektur dan desain proses arsitektur dilakukan secara iterasi sampai arsitektur komponen dan deployment sistem piranti lunak ini valid.
cxxxi
3.5.1 Architecture Component Design Pada aktivitas architecture component design ini, dibuat rancangan arsitektur komponen dari piranti lunak internet radio. Pada perancangan arsitektur komponen dirancang struktur sistem piranti lunak yang terdiri atas komponen-komponen yang saling berhubungan. Desain arsitektur komponen yang baik menyebabkan sistem piranti lunak menjadi lebih mudah dipahami, fleksibel, komprehensif, dan merefleksikan stabilitas piranti lunak terhadap konteks sistem (Mathiassen et al, 2000:189). Secara garis besar, komponen terdiri atas dua jenis, yaitu komponen logis dan komponen fisik. Komponen logis adalah rancangan konsep yang digunakan untuk merancang struktur suatu sistem piranti lunak. Semua komponen yang telah dibuat pada aktivitas desain komponen pada prinsipnya adalah komponen logis. Komponen logis pada piranti lunak internet radio ini dapat digambarkan pada gambar 3.21. Pada tahapan desain ini, digambarkan rancangan konsep setiap elemen yang membentuk piranti lunak internet radio dalam sebuah diagram dan menghubungkan komponen-kompenen tersebut.
cxxxii
Interface User Interface
System Interface
Domain Model
Functional
Problem Domain Model
Object DB Access
Com.Db4o
Com.Db4o.Query
Gambar 3.32 Arsitektur Komponen Logis Aplikasi Internet Radio
Sedangkan komponen fisik adalah komponen logis yang telah dikonstruksi menjadi piranti lunak dan secara fisik ada dalam bentuk file. Komponen fisik digunakan untuk menggambarkan deployment diagram. Dalam merancang arsitektur komponen pada aplikasi internet radio ini digunakan architecture pattern yang berupa client/server architecture. Distribusi komponen logis pada rancangan arsitektur yang digunakan adalah centralize model. Tabel di bawah ini menggambarkan distribusi komponen logis pada aplikasi internet radio ini.
cxxxiii
Tabel 3.3 Distribusi Komponen Logis pada Aplikasi Internet Radio Client Server Architecture I+F
M
Centralize Model
I adalah komponen Interface, F adalah komponen Functional System, dan M adalah komponen Problem Domain Model. Deployment diagram untuk aplikasi internet radio dengan menggunakan centralize model architecture dapat digambarkan seperti pada gambar 3.22.
Gambar 3.33 Deployment Diagram untuk Centralize Model
cxxxiv
3.5.2 Architecture Process Design Pada Architecture Process Design dilakukan rancangan terhadap pendistribusian component instant ke dalam prosesor yang telah tersedia, yang kemudian digambarkan dengan menggunakan deployment diagram dalam rangka membuat arsitektur proses system software tanpa adanya bottleneck. Aplikasi internet radio akan dideploy sebagai aplikasi yang berjalan dengan mengakses repository server, kemudian hasilnya akan dikirimkan ke webcast server untuk dapat dilakukan penyiaran internet radio (gambar 3.23). Aplikasi internet radio terhubung ke repository server dengan menggunakan ethernet 100 Base-T. Sedangkan dari aplikasi internet radio ke webcast server dihubungkan dengan leased line sebesar 512 kbps, webcast server diletakkan di gedung penyedia jaringan internet (internet service provider (ISP)).
Gambar 3.34 Deployment Diagram Aplikasi Internet Radio
cxxxv
Untuk aplikasi internet radio sendiri, komponen interface, domain model dan database access diimplementasi pada sisi client dan problem domain model pada sisi server. Selanjutnya, komponen-komponen tersebut dikonstruksi menjadi suatu piranti lunak. Berikut ini adalah deployment diagram selengkapnya.
Gambar 3.35 Deployment Diagram Aplikasi Internet Radio
3.6 Metode Lean Architecture untuk Agile Software Development
Kata Lean dan Agile menjadi hal yang sering dibicarakan dalam hal pengembangan piranti lunak belakangan ini. Menurut James Coplien et al (2010), berbicara tentang membawa management style dan development style ke dalam pengambangan piranti lunak. Arsitektur adalah gambaran besar dari sistem atau bentuk dari sistem. Dalam hal ini arsitektur piranti lunak harus mendukung value stream dari perusahaan. Inti dari lean architecture adalah suatu tim: “all hands on deck” semua orang turun tangan secara mental yaitu bahwa semua orang adalah bagian dari arsitek
cxxxvi
dan tiap-tiap orang memegang peranan penting dalam proyek sejak permulaan. Lean membawa perencanaan secara hati-hati di depan dan Agile berbicara mengenai umpan balik. Keduanya menampilkan nilai dari arsitektur: Lean, dalam hal bagaimana arsistektur akan mengurangi pemborosan, inkonsistensi dan pengembangan yang tidak biasa; dan Agile, pada bagaimana keterlibatan end user dan umpan balik dapat menekan biaya dalam jangka panjang. Lean architecture secara hati-hati membagi-bagi bagian desain yang menghasilkan artifak secara tepat yang mendukung proses pengembangan dalam jangka panjang. Dalam hal ini menghindari koding yang tidak berguna yang akan lebih baik ditulis pada saat kebutuhan akan hal ini muncul dan tepat saat akan menghasilkan keuntungan dalam pasar. Dalam cara pandang programmer, ini memberikan jalan dalam menangkap konsep desain yang paling penting dan keputusan yang perlu diingat selama proses produksi. Dengan penempatan pondasi Lean, proyek akan mendukung prinsip Agile dengan lebih baik dan mengaspirasikan kepada Agile yang ideal. Jika semua tangan ikut bekerja sama, dalam hal ini bergantung lebih pada orang dan interaksi-interaksinya dibandingkan pada proses-proses atau alat-alat bantu. Jika nilai-milai ini menjadi penggerak dan bukannya proses-proses atau alat-alat bantu maka akan didapatkan ikatan yang erat dengan customer. Jika end user mental model bisa ditampilkan secara nyata dalam kode, maka dipastikan akan dicapai piranti lunak yang
cxxxvii
berjalan sesuai dengan kebutuhan customer dan pastinya dapat pula melayani kebutuhan dan keinginan dari user. Prinsip Lean berada pada jantung dari arsitektur di belakang proyek Agile. Agile dalam hal menghadapi perubahan. Standard dapat meningkatkan kecepatan dalam pengambilan keputusan dan menurunkan pekerjaan maupun pekerjaan yang harus diulang. Lean architecture harus ditelusur lebih dalam sebagai proses berpikir dalam analisis domain yang baik, dalam spesialisasi dari pengetahuan domain expert secara mendalam, dan dalam komunitas atau standard-standard dunia. Aturan utama dari Lean adalah: “Everybody, All Together, Early On”, atau “all hands on decks”, semua orang, secara bersama-sama, dari sejak awal. Elemen “every body”, menggambarkan hubungan dengan seluruh pihak yang berkepentingan dalam proyek seperti customer, stake holder, dan end user. Pengertian “early on”, dalam hal pengambilan keputusan dan untuk memutuskan pada suatu keputusan itu sendiri dengan konsekuensi-konsekuensinya. Dalam Agile Software Development, aturan yang menjadi pegangan adalah “the code is the design”, yang menjadi desain adalah kode itu sendiri. Dokumentasi dapat memberikan konteks secara luas yang sukar untuk dilihat dalam bagian lokal dari cuplikan kode. Dokumentasi yang terbaik, mungkin didapatkan secara otomatis dari kode dengan menggunakan alat bantu reverse engeineering. Ini dapat menyediakan cara pandang tingkat tinggi dari lanskap dengan minimum interpretasi dan filterisasi. Ini mengangkat perspektif bahwa kode adalah desain itu sendiri
cxxxviii
dengan mengangkat kode ke cara pandang ke level yang lebih tinggi. Koding adalah artifak yang selalu muncul dalam inti dari Agile development. Jika secara tepat dikerjakan, ini merupakan hasil akhir dari model konsepsual dari end-user. Ini secara terus menerus mengingatkan programmer kepada kebutuhan dan imajinasi dari end-user, bahkan pada saat customer tidak berada bersama dengannya. Pada akhirnya itu kembali pada kode, dan itu karena kode adalah kendaraan yang membawa kualitas hidup kepada end-user.
cxxxix
