41
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
42
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 dimulainya sebuah proses software yang bertujuan untuk membentuk cakupan dari
43
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.
44
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,
45
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.
46
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:
47
Gambar 3.1 Aktivitas Utama OOAD
48
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 kebutuhan sistem. 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 secara keseluruhan 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 :
49
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).
50
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 dalam problem domain baik itu struktur abstrak statik diantara kelas, atau dinamik,
51
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.
Gambar 3.3 Aktivitas dalam problem-domain model
52
Tabel 3.1 Aktivitas dalam problem-domain analysis Activity Classes
Content Object and events in part
Concepts Class, object, and event
of problem domain Structure
How classes and objects
Generalization,
conceptually tied
aggregation, association, and cluster
Behavior
Dynamic properties in
Event trace, behavioral
objects
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
53
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.
Gambar 3.4 Aktivitas dalam application-domain model
54
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 Usage
Content Who system interact with
Concepts Use case and actor
people and systems in the context Function
What are the system’s
Function
information processing capabilities Interfaces
What are the target
Interface, user interface,
system’s interface
and system interface
requirements
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
55
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 yang kompleks.
56
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 Model Component
Content
Concepts
How the model
Model component and
represented as classes in
attribute
the system Function component
How are the functions
Function component and
57
Connecting Component
implemented
operation
How are components
Component and
connected
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 tersedia pada prosesor untuk mendefinisikan struktur fisik dari sistem. Hasil dari
58
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 Criteria
Content Condition and criteria for
Concepts Criterion
design Components
Processes
System structured into
Component architecture
components
and component
Distributed and
Process architecture and
coordinated system
process
59
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.
Gambar 3.7 Persistent Design
60
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 dalam database. Oleh karenanya komponen ini sifatnya selalu ada, baik
61
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.
62
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 berhubungan dan atribut salah satu object harus memiliki akses operation
63
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 association direalisasikan didalam persistence component.
64
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.
65
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 itu sendiri. Untuk lebih jelasnya, ilustrasi dibawah ini dapat menjelaskan
66
bagaimana rancangan N-ary association direalisasikan di dalam persistence component.
Document -DocID -TableID -ImageID -TextID +Document()
Table -TableID -Position +Table()
Text
0..*
0..*
-TextID * -Position +Text()
Image -ImageID -Position +Image()
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.
67
Document
Paragraph
1 1
0..*
1..* Image
Text
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 dapat memiliki banyak Folder.
68
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 objectoriented. Dua hal yang berkait dengan inheritance adalah:
69
•
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:
70
•
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.
•
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 berlebihlebihan 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
71
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. 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 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:
72
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.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
73
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.
Gambar 3.16 Struktur Data Array di Dalam Class
74
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.
Gambar 3.17 Struktur Data Collection of Object di Dalam Class
75
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. AoBManager -MyBlob : AoBHandler +DeleteAoBData() +DefragDatabase() +CheckFileName() +ChangeFileName()
-End1 -End2
AbsAoB -FileName : String
1
1
+SetFileName() +GetFileName()
AoBHandler -DataGambar : byte +SetFileName() +GetFileName() +ReadFileToDB() +WriteFileImage()
Gambar 3.18 Array of Byte Handler (AoB Handler)
76
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.
