BAB III
METODOLOGI
3.1 Rangkaian Metodologi Untuk Membentuk Standar Dokumen
Multimedia Baru
Dokumen primitif pada awalnya hanya berupa teks dan strukturnya sangat sederhana. Semakin berkembangnya jaman, kebutuhan dokumen dari semulanya hanya teks saja juga semakin berkembang. Dimulai dengan penambahan hyperlink untuk kemudahan referensi, penambahan image agar dapat semakin memudahkan penyampaian informasi sampai pada penambahan audio dan video agar dokumen semakin interaktif dan kemudahan penyampaian informasi menjadi semakin baik.
Dokumen saat ini walau telah memenuhi kebutuhan untuk menyampaikan informasi, dari sisi keamanan, konten yang terdapat di dalam dokumen masih dapat dengan mudah dibajak, format HTML misalnya dapat dibajak dengan menampilkan
source (view source) dari dokumen. Dokumen word atau PDF juga masih belum
dapat melindungi dokumen dengan baik (lihat contoh pada bab I) ketika dokumen telah ditampilkan di komputer client.
Pada tesis ini diambil studi kasus perpustakaan binus yang memberikan layanan untuk menampilkan dokumen melalui web bowser. Format dokumen yang ada saat ini masih belum dapat menjaga konten dari dokumen yang ditampilkan. Oleh karena itu perpustakaan mebutuhkan suaatu dokumen yang dapat menampilkan isi
dokumen dan dokumen tersebut hanya dapat dibaca tanpa bisa di modifikasi, dihapus atau di-copy ke tempat lain.
Untuk memenuhi dan mencapai keinginan tersebut kiranya diperlukan upaya membuat standard dokumen yang baru. Format dokumen baru yang akan dibuat menggunakan Object Data Model (ODM) karena dengan penggunaan ODM maka seluruh framework dan teknologi yang ada dalam sebuah platform dapat digunakan untuk mengembangkan dan mendukung format dokumen ini. Disamping itu, dengan adanya dukungan dari semua framework dan teknologi yang ada didalam suatu platform memungkinkan dilakukannya proses perlindungan terhadap dokumen lebih baik dan maksimal.
Dalam rangka membangun dan memodelkan standar dokumen yang baru, proses capturing requirment, analisa dan perancangan dokumen dengan pendekatan
Object Oriented, serta implementation dilaksanakan dengan sebaik-baiknya. Untuk
visualisasi dokumen digunakan Java 2D API yang sangat baik dalam pencitraan dua dimensi dan untuk keperluan penyimpanan digunakan database berorientasi obyek (OODB) sebagai media persistensi obyek dokumen multimedia. Oleh karena itu metode perancangan object oriented database merupakan rangkaian penting dalam tesis ini bersama object oriented analysis and design untuk mewujudkan standar dokumen baru yang nyata.
3.2 Capturing User Requirement
Capturing user requirement adalah hal yang dilakukan pada saat awal
software. Sasaran dari kegiatan ini adalah untuk memahami software dari sudut pandang user dan mengetahui kebutuhan dan harapan dari user. Capturing user
requirement sangat berguna untuk memvalidasi cakupan dari software dari sudut
pandang user sehingga software tersebut dapat dibangun sesuai dengan kebutuhan. Hasil dari Capturing requirement akan sangat berperan dalam mendukung
keberhasilan dari sebuah software
Proses user requirement capture dapat berupa berbagai jenis metodologi penelitian seperti survey, interview, usability test, atau analisa kompetitor. Pada umumnya proses ini dilakukan satu metodologi pada suatu saat terhadap user atau pihak lainnya yang berperan dalam proses ini.
Keuntungan utama dalam melakukan proses capturing user requirement adalah menghemat waktu dan uang dalam melakukan validasi cakupan software terhadap kebutuhan dan harapan dari user sebelum proses lainnya dilakukan. Dari proses ini, beberapa hal dapat diperoleh sehingga dapat memperbaiki kualitas dari
software yaitu :
1. Menentukan resiko dan cara untuk mengatasinya dalam mengembangkan
software.
2. Target dari software akan menjadi lebih fokus.
3. Semakin memperdalam pengetahuan tim dan individu yang terlibat mengenai software yang akan dibangun.
Kelemahan dari proses capturing user requirement ini adalah meningkatnya jangka waktu pengembangan software karena proses ini cukup memakan banyak waktu dan tenaga agar dapat memberi hasil yang optimal
Pada umumnya, spesifikasi yang dilakukan pada tahap ini mencakup dua kategori yaitu:
1. Functional Specification, menspesifikasikan apa yang harus dicapai oleh software dari sudut pandang user. Pada functional specification
menjelaskan arsitektur dari software (alur proses, fitur-fitur dari sistem, desain software dll) yang berisi diagram, flowchart atau use case / skenario yang menjelaskan tentang arsitektur software.
2. Design Specification, menggambarkan bagaimana software mencapai kebutuhan dari functional specification. Pada design specification menjelaskan tampilan dari software, user interface, detail dari desain sistem (fungsi, batasan, tipe dari software dll) dan kebutuhan dari software yang dibangun (misalnya sistem operasi, besar memori yang dibutuhkan dll)
Sumber : http://www.projectsmart.co.uk/what-is-user-requirements-capture.html\ http://articles.techrepublic.com.com/5100-10878_11-6094986.html
3.3 Object Oriented Analysis and Design
Hal yang paling penting dalam metode OOA&D (selanjutnya akan disebut OOAD) menggunakan obyek dan kelas sebagai konsep dasar dan terbentuk pada empat prinsip dasar untuk analisa dan desain: memodelkan konteks sistem,
menekankan pada pertimbangan arsitektural, penggunaan kembali pola yang mengekspresikan ide desain yang telaih dibangun dengan baik, dan menyatukan metode untuk setiap situasi pengembangan. Prisinp ini adalah dasar dari OOAD dan turunannya (Mathiassen et al 2000).
OOAD adalah pendekatan software engineering yang memodelkan sistem sebagai sekelompok obyek yang saling berinteraksi. Setiap obyek mewakili entity dalam sistem yang dimodelkan, dan dikarakteristikkan oleh kelasnya, state (elemen data), dan behavior-nya. Banyak model dapat dibuat untuk menunjukkan struktur statik, sifat yang dinamis, dan run-time deployment dari obyek yang berkolaborasi. Ada sejumlah notasi untuk merepresentasikan model ini, contohnya Unified Modeling
Language (UML).
Object-Oriented analysis (OOA) menggunakan teknik memodelkan obyek
untuk menganalisa kebutuhan fungsional pada sebuah sistem. Object-oriented design (OOD) memperinci model analisis untuk menghasilkan spesifikasi implementasi. OOA fokus pada apa yang akan dilakukan sistem, sementara OOD fokus pada bagaimana sistem melakukannya (http://en.wikipedia.org/wiki/OOAD).
3.3.1 Aktivitas Utama Dalam OOAD
OOAD adalah sekumpulan panduan umum untuk melakukan analisa dan desain. Oleh karena itu harus dipadukan pada organisasi dan proyek. Untuk membuat metode lebih berguna, beradaptasi, perbaikan, dan pergantian bagian akan mudah diimplementasikan.
OOAD menggambarkan empat sudut pandang utama pada sistem dan konteksnya: Isi sistem informasi, bagaimana sistem akan digunakan, sistem secara keseluruhan dan komponen-komponen sistem. Sudut pandang ini di sambungkan pada analisa, desain arsitektural, dan desain komponen secara berurutan. Setiap aktivitas memberi hasil yang spesifik, yang nantinya akan dimasukkan dalam dokumentasi analisa dan desain. Dokumen aktivitas ini akan tergantung pada bagaimana OOAD dipadukan sesuai dengan kebutuhan proyek.
Hal utama yang harus dilakukan sebelum mendesain sistem software adalah mengerti problem domain dan application domain. Setelah melewati beberapa analisis, aktivitas dapat maju ke desain sistem software object-oriented lalu desain aplikasi. Menurut Mathiassen et al (2000) dan Irwanto (2006), secara keseluruhan aktivitas OOAD adalah sebagai berikut ini:
Keterangan :
• Problem Domain Analysis is aktivitas untuk mengidentifikasi problem
domain. Hasil dari aktivitas ini adalah model yang sesuai dengan problem domain
•
Application Domain Analysis adalah aktivitas untuk menentukan kebutuhansistem. Hasil dari aktivitas ini adalah daftar lengkap dari kebutuhan sistem secara keseluruhan
• Component Design adalah aktivitas untuk mendesain semua komponen yang dibutuhkan sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen • Persistence Design adalah aktivitas mendesain seluruh transient object
menjadi persistence object ketika proses komputasi berlangsung. Hasil dari aktivitas ini adalah specification of persistence
•
Architectural Design adalah aktivitas untuk menggambarkan sistem secarakeseluruhan dan koneksinya diantara komponen utama dari sistem dan interaksinya. Hasil dari aktivitas ini adalah spesifikasi arsitektur.
3.4 Metodologi
Metodologi yang digunakan tesis ini berdasarkan OOAD untuk analisa dan desain standar baru untuk format dokumen multimedia menggunakan database berorientasi obyek adalah :
Gambar 3.2 Metodologi
3.4.1 Aktivitas Analisis
Keberhasilan dalam pengembangan sistem tergantung pada pengertian developer pada aplikasi sistem. Sistem dapat dilihat dari dua sudut pandang yang saling melengkapi: sistem memodelkan sesuatu (problem domain) dan dioperasikan oleh user (application domain).
Problem domain adalah bagian dari konteks yang diatur, dimonitor atau dikontrol oleh sistem. Problem domain menggambarkan tujuan sistem, sebagai bagian dari realita bahwa sistem membantu mengatur, memonitor atau mengontrol.
Application domain adalah kelompok yang mengatur, memonitor atau
mengontrol problem domain. Application domain adalah bagian daru kelompok user. Kesuksesan (atau kegagalan) sistem tergantung pada seberapa baik koneksi antara
application domain dan problem domain bersama berfungsi secara keseluruhan
3.4.1.1 Problem Domain Analysis
Problem Domain Analysis fokus pada sistem untuk multimedia dokumen.
Mendesain class, struktur dan sifat dari multimedia dokumen. Hasil dari tahap ini adalah model yang sesuai pada dokumen multimedia.
Titik awal untuk analisa problem domain adalah definisi sistem. Elemen “obyek” dari definisi sistem memberi patokan untuk memilih obyek, kelas dan event.
Class menggambarkan pendekatan pada tugas dari mendefinisikan isi dari
sebuah sistem informasi. Problem domain didefinisikan dan dikarakteristikkan dengan memilih kelas dan event. Kelas mendefinisikan bagian yang berhubungan dengan problem domain dan event sebagai elemen dasar dari object behavior karena event berasosiasi langsung dengan obyek. Hasil dari class activity adalah tabel event yang berisi kelas yang terpilih dan event yang berhubungan.
Structure mengatur hubungan struktrual diantara kelas dan obyek. Hubungan
struktur konkrit diantara obyek. Hasil aktivitas struktur dalam class diagram menunjukkan kelas yang dipilih dan hubungan struktural yang relevan diantara class dan object.
Behavior mengatur sifat (behavior) dan interaksi obyek. Aktivitas ini
menggambarkan properti dan atribut yang dinamis untuk setiap kelas yang dipilih. Deskripsi behavior dan atribut membuat karakteristik lebih tepat untuk setiap obyek dalam problem domain. Hasil dari aktivitas ini adalah state diagram yang menggambarkan sifat umum dan atribut dari setiap kelas.
Tabel 3.1 Aktivitas dalam problem-domain analysis
Activity Content Concepts
Classes Object and events in part of problem domain
Class, object, and event
Structure How classes and objects conceptually tied
Generalization,
aggregation, association, and cluster
Behavior Dynamic properties in objects
Event trace, behavioral pattern, and attribute
3.4.1.2 Application Domain Analysis
Application domain analysis fokus ada bagaimana target sistem digunakan,
mendefinisikan kebutuhan untuk fungsi dan antarmuka sistem. Hasil dari aktivitas ini adalah daftar lengkap dari kebutuhan sistem secara keseluruhan.
Spesifikasi kebutuhan bukan pekerjaan yang muda, user mungkin tidak mengerti pilihan teknis untuk langsung menulis kebutuhan yang optimal, oleh karena itu, kerjasama diantara developer dan user dibutuhkan mengenai kebutuhan pengguna, fungsi dan antarmuka yang harus di evaluasi.
Usage mengatur bagaimana menentukan sistem agar sesuai dengan
application domain. Cara untuk melakukannya adalah dengan menggambarkan aktor dan use case berdasarkan pengertian dari aktivitas application domain. Use Case menyediakan gambaran dari kebutuhan sistem yang berasal dari sudut pandang user
dan menyediakan dasar untuk mendefinisikan dan evaluasi kebutuhan fungsi dan antarmuka dasar.
Function fokus pada apa yang dapat sistem lakukan untuk mendukung aktor /
user dan menentukan kapabilitas pemrosesan informasi. Karena usage fokus pada “apa yang akan dilakukan sistem?” maka function fokus pada “bagaimana sistem akan digunakan”, itulah sebabnya usage dan function sangat erat terhubung
Interfaces digunakan oleh aktor untuk berinteraksi dengan sistem dan
menentukan antarmuka sistem. Analisis dimulai dari use case, problem model dan kebutuhan fungsional, hasilnya adalah penentuan pada elemen antarmuka.
Mendefinisikan kebutuhan adalah pekerjaan yang berulang antara usage, function dan interface. Analisa kebutuhan fokus pada setiap aktivitas secara bergantian seperti gambar 3.4 tunjukkan diatas. Untuk membuat hasil yang sesuai dan konsisten, tabel 3.2 dibawah memberi gambaran aktivitas analisis application domain.
Tabel 3.2 Aktivitas dalam analisis problem-domain
Activity Content Concepts
Usage Who system interact with
people and systems in the context
Use case and actor
Function What are the system’s
information processing capabilities
Function
Interfaces What are the target
system’s interface requirements
Interface, user interface, and system interface
3.4.2 Aktivitas Desain
Selama analisis dan desain, sangat penting untuk mengerti sistem secara keseluruhan. OOAD menekankan pada arsitektur sistem sebagai kunci utama, fokus pada pengertian, fleksibilitas dan kegunaan sebagai kualitas desain yang penting. Arsitektur sistem harus mudah dimengerti karena merupakan dasar untuk keputusan
dan sebagai komunikasi dan perangkat kerja dalam pekerjaan ke depan. Harus fleksibel karena pengembangan sistem berada dalam lingkungan yang berubah-ubah.
3.4.2.1 Component Design
Component Design fokus pada menentukan implementasi dari kebutuhan di
dalam framework arsitektural. Titik awal Component design adalah spesifikasi aplikasi dan kebutuhan sistem. Hasil dari aktivitas ini adalah spesifikasi dari komponen yang tersambung.
Component design dibagi menjadi tiga sub-aktivitas yaitu model component, function component, dan connecting component.
Tujuan dari Model Component adalah untuk memberi histori dan data saat ini
pada fungsi, antarmuka, penggunaan dan sistem lainnya dan untuk mewakili model dari problem domain. Informasi yang tersimpan berhubungan dengan problem domain sistem merupakan bagian dari lingkungan dimana sistem digunakan untuk mengadministrasi, monitor, atau kontrol. Hasil dari model component activity adalah
class diagram dari model component.
Tujuan function component adalah memberi antarmuka dan akses pada
komponen sistem lainnya pada model dan untuk menentukan implementasi dari
function. Function component adalah jalur antara model dan usage. Hasil dari function component adalah class diagram dengan operasi dan spesifikasi dari operasi
Aktivitas connecting component adalah untuk mendesain koneksi antara komponen-komponen agar mendapatkan desain yang fleksibel dan komprehensif. Hasil dari aktivitas ini adalah class diagram dari komponen-komponen yang terlibat.
Gambar 3.5 Component Design Table 3.3 Aktivitas dalam Component Design
Activity Content Concepts
Model Component How the model
represented as classes in the system
Model component and attribute
implemented operation Connecting Component How are components
connected
Component and connection
3.4.2.2 Architectural Design
Architectural design fokus pada struktur sebuah sistem yang terkomputerisasi.
Hasil dari aktivitas architectural design dalam sebuah arsitektur adalah mendefinisikan komponen-komponen sistem dan relasinya, distribusi sistem pada perangkat fisikal teknis dan mekanisme yang dibutuhkan untuk mengkoordinasi proses sistem.
Architectural design dibagi menjadi tiga sub-aktivitas yaitu Criteria, Components dan Processes
Criteria fokus pada kondisi dan kriteria pada desain untuk mengatur prioritas
desain. Aktivitas Criteria membantu mengintegrasikan standar dan prosedur untuk jaminan kualitas pada proyek tertentu. Hasil dari aktivitas ini adalah kumpulan dari kriteria yang terprioritaskan.
Components fokus pada bagaimana sistem dapta dipecah menjadi bagian yang
lebih kecil untuk membuat struktur sistem yang komprehensif dan fleksibel. Hasil dari aktivitas ini adalah class diagram dengan spesifikasi dari komponen-komponen yang kompleks.
Processes mengatur eksekusi sistem dan alokasi dari proses sistem yang
aktivitas ini adalah deployment diagram yang menunjukkan prosesor dengan komponen program yang diberikan dan obyek aktif.
Gambar 3.6 Architectural Design
Table 3.4 Aktivitas dalam Architectural design.
Activity Content Concepts
Criteria Condition and criteria for
design
Criterion
Components System structured into
components
Component architecture and component
Processes Distributed and
coordinated system
Process architecture and process
processes
3.4.2.3 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 obyek ke dalam media penyimpanan. Yang dimaksud dengan persistensi obyek adalah proses penyimpanan objek ke dalam file atau database. Oleh karena persistensi obyek berelasi dengan penyimpanan obyek kedalam database, maka aktivitas persistence
design ekuifalen dengan aktivitas object oriented database design.
3.4.2.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 di-load 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 masing-masing). 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. Menurut Irwanto (2007), Komponen problem domain model ada dua jenis yaitu:
• Transient 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 component problem domain model
Persistence komponen PDM adalah komponen PDM yang residence di
selama proses komputasi berlangsung, maupun saat proses komputasi dihentikan.
Gambar 3.8 Transient & Persistent Komponen PDM (Irwanto, 2007)
Agar supaya obyek dapat persistent, dibutuhkan suatu storage yang digunakan untuk menyimpan entity obyek yang sedang berjalan dalam proses komputasi. Tahapan yang dilakukan adalah membuat classifier component problem domain
model di dalam skema database, sehingga obyek database dapat menyimpan semua
transient entity object untuk kemudian dapat digunakan kembali pada saat proses komputasi dijalankan. Menurut Irwanto (2007, P48 - 108), rangkaian methode perancangan object oriented database untuk membuat komponent PDM dapat persistence kedalam object database dibahas didalam tujuh subbab dibawah ini.
3.4.2.5 Persistensi Obyek yang Memiliki Hubungan Struktur
Sederhana
Bentuk hubungan struktur sederhana antar objek terbagi atas tiga bentuk: • Hubungan struktur association
• Hubungan struktur aggregation • Hubungan struktur generalization
3.4.2.6 Persistensi Obyek 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 obyek yang memiliki navigation
association direalisasikan dengan korespondensi atribut dari object key yang
terhadap object yang satunya lagi. untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan navigational association direalisasikan didalam persistence component.
Gambar 3.9 Navigational Association
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 obyek 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 operasi terhadap masing-masing obyek. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan bidirectional
Gambar 3.10 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: • Didalam persistence component, hubungan object yang memiliki hubungan
entity class dengan dirinya sendiri ini direalisasikan dengan teknik persistensi obyek ke dalam database pada prinsipnya sama dengan teknik bidirectional di atas. Yang harus diperhatikan adalah constructor
object member. Ketika sebuah member instance dibuat, pastikan atribut
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.11 Self Containing Class Patterns
Ternary Association dan N-ary Association
Di dalam class diagram bentuk hubungan struktur assosiasi N-ary association adalah sebuah bentuk asosiasi yang memungkinkan hubungan lebih dari dua obyek.
Ternary association adalah N-ary association yang menggantikan nilai N dengan
nilai tiga (pada contoh gambar 3.13). Untuk merealisasikan N-ary Association didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut:
• Didalam persistence component, hubungan object yang memiliki N-ary association direalisasikan dengan korespondensi atribut dari object key yang berhubungan dengan atribut beberapa obyek. Karena memiliki hubungan beberapa arah, maka beberapa obyek bisa saling memiliki akses operasi terhadap obyek-obyek 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
bagaimana rancangan N-ary association direalisasikan di dalam persistence component. 0..* 0..* +Document() -DocID -TableID -ImageID -TextID Document +Table() -TableID -Position Table +Image() -ImageID -Position Image +Text() -TextID -Position Text
Gambar 3.12 N-ary Association
3.4.2.7 Persistensi Obyek dengan Hubungan Aggregation
Di dalam UML, agregasi terdiri dari dua jenis, yaitu: agregasi yang memiliki kepemilikan yang kuat dan yang lemah. Agregasi yang memiliki kepemilikan yang kuat yang kuat diistilahkan dengan komposisi. Secara notasi, agregasi dan komposisi juga dibedakan.
Document Image 1 1..* Paragraph Text 1 0..*
Gambar 3.13 Agregasi dan Komposisi
Untuk merealisasikan agregasi dan komposisi didalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut:
• Pada agregasi menyatakan kepemilikan suatu part, sedangkan komposisi menyatakan suatu object sebagai container dari object partnya. Inilah hal yang harus diperhatikan dalam proses persistensi. Perbedaan antara aggregation dan composition dalam implementasi hanya terletak pada konsepnya saja.
Salah satu bentuk struktur agregasi 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
Gambar 3.14 Self Containing Class dengan Aggregation Structure
3.4.2.8 Persistensi Obyek 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.15 Struktur Generalisasi
Inheritance merupakan sebuah konsep yang fundamental di dalam object-oriented. Dua hal yang berkait dengan inheritance adalah:
• 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 dari obyek abstract class tidak diperbolehkan. Abstract class harus tetap dimasukkan ke dalam skema database obyek.
Selanjutnya, polymorphism adalah ciri khas dari object-oriented yang menjelaskan kumpulan object dapat memiliki behavior yang berbeda dari fungsi yang sama.
3.4.2.9 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 varian yang setiap variannya memiliki banyak jenis. Keempat varian itu adalah:
• Binding
Binding dependency mempunyai hanya sebuah stereotype, yaitu <<bind>>. Dependency ini menghubungkan unsur yang terikat ke template class yang akan
melengkapi definisi dari class yang dihasilkan. • 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. <<realization>> dependency stereotype menetapkan hubungan antara elemen di dalam implementasi model dan elemen di dalam spesifikasi model.
3. <<refine>> dependency stereotype menetapkan hubungan antara model elemen pada tingkat perbedaan abstraksi.
4. <<trace>> dependency stereotype menetapkan hubungan antara dua elemen yang mempresentasikan konsep yang sama di dalam model yang berbeda.
• Usage
disajikan untuk kehadiran model elemen yang lain. Usage dependency mempunyai enam buah stereotype, yakni:
1. <<call>> dependency stereotype menetapkan kolaborasi antara dua buah operasi. Operasi yang satu memanggil operasi yang lain.
2. <<create>> dependency stereotype menyiratkan bahwa penciptaan sebuah instance dari dependent class akan mengakibatkan penciptaan dari instance class tersebut merupakan target dari dependency.
3. <<instantiate>> 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 implementasi 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. <<access>> dependency stereotype menyatakan bahwa dependent package dapat menggunakan elemen dari package yang menjadi target dependency. 2. <<import>> dependency stereotype menyatakan bahwa dependent package
menyertakan model elemen dari package yang menjadi target dari
dependency.
3. <<permit>> dependency stereotype mengesampingkan normal visibility
constraints dan membiarkan dependent elemen untuk mengakses target
elemen tanpa memperhatikan visibilitas yang telah ditetapkan.
3.4.2.10 Persistensi Obyek yang Memiliki Struktur Data
Kompleks
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.3.2.11 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 logikal 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.
3.3.2.12 Persistensi Obyek Kompleks yang Memiliki Struktur
Data Collection of Object
Untuk mengatasi pemodelan problem domain yang kompleks dan dinamis, database obyek memperkenankan untuk membuat struktur data collection of object di dalam obyek. Untuk merealisasikan struktur data collection of object di dalam OODB, maka metode perancangan yang harus dilakukan adalah sebagai berikut:
• Didalam persistence component, obyek kompleks yang memiliki struktur data collection of object direalisasikan dengan menempatkan obyek tersebut di dalam class dengan menggunakan referensi terhadap obyek ini. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan bagaimana rancangan complex object yang memiliki struktur data collection of object direalisasikan didalam persistence component.
3.3.2.13 Menangani Array of Byte ke dalam Database Obyek
Tipe data Array of Byte digunakan untuk menyimpan data image ke dalam database tidak disediakan khusus oleh Db4o sehingga penanganan tipe data ini dibuat khusus untuk standar dokumen ini.
Metode dalam menangani tipe data Array of Byte ke dalam database perlu memperhatikan beberapa hal yaitu :
• Instansiasi dari class AoB
• Pada saat object disimpan ke dalam class, database dapat langsung menangani field AoB yang telah di atur
• Penanganan AoB ketika disimpan / dibaca / dihapus dari atau ke dalam database
• Pembersihan database dari space yang dipakai oleh AoB ketika dihapus
• Pengecekan FileName AoB agar tidak terjadi duplikasi nama file di dalam database walaupun gambar yang disimpan itu sama.
+SetFileName() +GetFileName() -FileName : String AbsAoB +SetFileName() +GetFileName() +ReadFileToDB() +WriteFileImage() -DataGambar : byte AoBHandler +DeleteAoBData() +DefragDatabase() +CheckFileName() +ChangeFileName() -MyBlob : AoBHandler AoBManager -End1 1 -End2 1
Pada gambar diatas merupakan kelas diagram untuk penanganan Array of
Byte. Berikut penjelasan mengenai operasi yang ada dari kelas-kelas diatas:
• SetFileName : Mengatur nama file dari AoB
• GetFileName : Mengembalikan nama file dari AoB
• ReadFileToDB : Membaca file gambar yang telah di atur, menyimpannya dalam bentuk Byte.
• WriteFile : Membaca data gambar dari database dan menulis data tersebut pada file.
• DeleteAoBData : Menghapus data gambar dari database
• DefragDatabase : Membersihkan ruang yang tidak terpakai setelah data gambar terhapus dari database.
• CheckFileName : Melakukan pengecekan ke database agar tidak terjadi duplikasi nama file
• ChangeFileName : Mengganti nama file bila terjadi duplikasi nama file dengan menambahkan angka di depan nama file.
