2.4 Metode Analisis dan Perancangan Berorientasi Objek
2.4.7 Architectural Design
Tujuan dari desain arsitektur adalah untuk men-strukturkan sistem yang terkomputerisasi. Keberhasilan suatu sistem ditentukan dari kekuatan desain arsitekturnya. Desain arsitektur dibedakan menjadi 2 (dua) konsep, yaitu Component architecture dan Process architecture. Menurut Mathiassen, et al. (2000), ”Desain arsitektur memiliki 3 (tiga) prinsip dasar, yaitu define and prioritize criteria, bridge criteria and technical platform, and evaluate design early.” (p.175). Kegiatan-kegiatan yang dilakukan dalam desain arsitektur dapat dilihat pada Gambar 2.5 dibawah ini.
Component architecture Criteria Process architecture Analysis document Architectural specification
Gambar 2.5 Activities in architectural design Sumber: Mathiassen,et al. (2000, 176)
2.4.7.1 Criteria
Criteria bertujuan untuk mengatur prioritas suatu desain. Menurut Mathiassen, et al. (2000), ”Criterion adalah properti yang paling diinginkan dalam sebuah arsitektur.” (p.177). Sebuah panduan yang berguna untuk mendesain sistem harus sederhana, yang merupakan kriteria penting, yang juga harus menggambarkan kondisi desain yang khusus. Conditions adalah teknikal, organisasi, dan peluang manusia dan batasan yang berkaitan dalam menampilkan sebuah tugas. Hasil dari kegiatan kriteria adalah sekumpulan prioritas kriteria. Menurut Mathiassen, et al. (2000), ”Terdapat beberapa prinsip utama dari kriteria desain yang baik yaitu :
1. Tidak memiliki kelemahan
Sistem digambarkan dengan mengeliminasi beberapa kriteria yang tidak penting. Beberapa kriteria untuk menilai
software yang berkualitas yaitu tampak pada Tabel 2.3 dibawah ini.
Criterion Measure of
Usable Kemampuan sistem untuk menyesuaikan diri dengan konteks, organisasi yang berhubungan dengan pekerjaan dan teknis
Secure Ukuran keamanan sistem dalam menghadapi akses yang tidak terotorisasi terhadap data dan fasilitas
Efficient Eksploitasi ekonomis terhadap fasilitas platform teknis Correct Pemenuhan dari kebutuhan
Reliable Pemenuhan ketepatan yang dibutuhkan dalam melaksanakan fungsi Maintainable Biaya untuk menemukan dan memperbaiki kerusakan
Testable Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fungsi yang diinginkan
Flexible Biaya untuk mengubah sistem yang dibentuk
Comprehensible Usaha yang diperlukan untuk mendapatkan pemahaman terhadap sistem
Reusable Kemungkinan untuk menggunakan bagian sistem pada sistem lain yang berhubungan
Portable Biaya untuk memindahkan sistem ke platform teknis yang berbeda Interoperable Biaya untuk menggabungkan sistem ke sistem yang lain
Tabel 2.3 Classical criteria for software quality Sumber: mathiassen, et al. (2000, p178)
2. Menyeimbangkan beberapa kriteria
Desain yang baik harus memuat beberapa kriteria. Karena kriteria dapat menyebabkan terjadinya konflik, maka memprioritaskan seluruh kriteria yang ada itu penting;
3. Dapat digunakan, fleksibel, dan komprehensibel
Kriteria-kriteria diatas bersifat universal dan dapat digunakan hampir pada setiap proyek pengembangan sistem, bagaimanapun mengorganisasikannya, menunjukkan tiga kriteria ideal dalam proyek pengembangan sistem.
Kriteria usable menspesifikasikan bahwa kualitas sistem yang pokok tergantung pada bagaimana cara kerjanya. Flexibility menspesifikasikan bahwa sistem arsitektur mengakomodasi perubahan organisasi dan kondisi teknik. Sedangkan comprehensibility menspesifikasikan peningkatan pada sistem komputerisasi, model dan deskripsi harus mudah untuk dipahami.
Mengacu pada pendapat Mathiassen, et al. (2000), sebuah desain yang baik memerlukan pertimbangan mengenai kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain, antara lain tampak pada Tabel 2.4 dibawah ini.
Teknikal penggunaan hardware, software, dan sistem
penggunaan kembali pola dan komponen yang sudah ada menggunakan komponen standar yang telah dibeli Organisasi pertimbangan perjanjian kontrak
rencana untuk pengembangan lanjutan pembagian kerja diantara pengembang
Manusia Desain kompetensi
pengalaman dengan sistem yang sama pengalaman dengan technical platform
Tabel 2.4 Conditions for design of an architecture Sumber: Mathiassen, et al. (2000, p184)
2.4.7.2 Component Architecture
Component Architecture adalah sebuah struktur sistem yang terdiri dari komponen yang saling berhubungan. Component Architecture yang baik membuat sistem lebih mudah dimengerti, mengorganisasikan desain kerja dan menggambarkan kestabilan
sistem. Komponen adalah sekumpulan bagian-bagian program yang membentuk suatu kesatuan dan memiliki fungsi yang jelas.
Tujuan dari kegiatan ini adalah untuk membuat struktur sistem yang fleksibel dan mudah dimengerti. Mengacu pada pendapat Mathiassen, et al. (2000), suatu arsitektur komponen yang baik menunjukkan beberapa prinsip, yaitu mengurangi kompleksitas dengan membagi menjadi beberapa tugas, menggambarkan stabilitas dari isi sistem, dan memungkinkan suatu komponen dapat digunakan pada bagian lain.(p.189).
Beberapa pola yang dapat digunakan untuk merancang Component Architecture adalah sebagai berikut :
1. Layered architecture pattern
Merupakan bentuk pola yang paling umum dalam software, yaitu terdiri dari beberapa komponen yang dibentuk menjadi beberapa lapisan-lapisan yang mirip dengan prinsip OSI Layer pada model jaringan, dimana lapisan yang berada diatas bergantung pada lapisan yang berada dibawahnya, begitu pula sebaliknya. Arsitektur ini sangat berguna untuk memecah sistem menjadi komponen-komponen;
2. Generic architecture pattern
Pola ini dapat digunakan untuk mengelaborasikan sistem dasar yang terdiri dari interface, function, dan model component. Model component berada di lapisan yang paling
bawah yang kemudian dilanjutkan oleh function layer dan yang paling atas adalah interface layer;
3. Client server architecture pattern
Pola ini dibangun untuk mengatasi sistem yang terdistribusi di beberapa proses yang tersebar. Arsitektur ini terdiri dari sebuah server dan beberapa client. Server memiliki kumpulan operasi yang dapat digunakan oleh client. Client menggunakan server secara independen.
Berikut ini adalah Tabel 2.55 yang menunjukkan beberapa jenis distribusi dalam arsitektur client-server dimana U adalah User Interface, F adalah Function, dan M adalah Model.
Client Server Architecture U U U+F U+F U+F+M U+F+M F+M F+M M M Distributed presentation Local presentation Distributed functionality Centralized data Distributed data Tabel 2.5 Jenis Arsitektur client-server
Sumber: Mathiassen, et al. (2000, p200)
Hasil dari component architecture adalah component diagram yang menunjukkan hubungan antara komponen (dalam hal ini adalah server dan beberapa client).
2.4.7.3 Process Architecture
Mengacu pada Mathiassen, et al. (2000), Proses arsitektur adalah struktur dari eksekusi sistem yang terdiri dari proses-proses yang saling bergantung. Untuk menjalankan sebuah sistem dibutuhkan processor. Sedangkan external device adalah
processor khusus yang tidak dapat menjalankan program. Proses arsitektur harus dapat memastikan bahwa sistem dapat dijalankan secara baik dengan menggunakan processor yang telah tersedia. (p.211).
Kegiatan proses arsitektur bermula dari komponen logik yang dihasilkan oleh kegiatan komponen dan bertujuan untuk menentukan struktur fisik dari sebuah sistem dengan mendistribusikan komponen-komponen program ke processor yang akan digunakan untuk eksekusi sistem, mengkoordinasikan pembagian sumber daya dengan active object dan menghasilkan arsitektur yang tidak memiliki hambatan.
Menurut Mathiassen, et al. (2000), “Sumber daya yang umumnya dipakai secara bersamaan yang mampu menghasilkan bottlenecks adalah :
1. Processor
Terjadi apabila ada dua atau lebih proses yang dieksekusi secara bersamaan pada satu processor;
2. Program component
Terjadi bila terdapat dua atau lebih proses yang secara bersama memanggil operasi pada komponen;
3. External device
Tampak pada penggunaan printer yang terhubung melalui jaringan.” (p.220-222).
Hasil dari process architecture adalah membuat Deployment Diagram.
2.4.8 Component Design
Menurut Mathiassen, et al. (2000), tujuan dari kegiatan desain komponen ini adalah untuk menentukan implementasi kebutuhan dalam kerangka arsitektur. Kegiatan component design bermula dari spesifikasi arsitektural dan kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi dari komponen yang saling berhubungan. (p.231).
Beberapa kegiatan dari desain komponen tampak pada Tabel 2.6 dibawah ini :
Kerangka Isi Konsep
Model Component
Bagaimana suatu model digambarkan sebagai kelas dalam sebuah sistem
Model Component dan atribut
Function Component
Bagaimana suatu function dimplementasikan Function Component Connecting Component Bagaimana komponen-komponen dihubungkan Operation component dan connection
Tabel 2.6 Activities in Component Design Sumber: Mathiassen, et al. (2000, p232)
2.4.8.1 Model Component
Mengacu pada Mathiassen, et al. (2000) model analisis problem-domain menggambarkan kebutuhan sistem. Kebutuhan sistem kemudian diimplementasikan dalam model component. Oleh karena itu, komponen model adalah bagian dari sistem yang mengimplementasikan model problem-domain. Tujuan dari komponen model adalah untuk mengirimkan data sekarang dan historis ke function, interface dan pengguna ataupun sistem lain. (p.235).
Hasil dari kegiatan komponen model adalah revisi dari class diagram dari kegiatan analisis. Kegiatan revisi biasanya terdiri dari kegiatan menambahkan kelas, atribut dan sturktur baru yang mewakili event.
2.4.8.2 Function Component
Mengacu pada Mathiassen, et al. (2000) komponen fungsi adalah bagian dari sistem yang mengimplementasikan kebutuhan fungsional. Tujuan dari komponen fungsi ini adalah untuk memberikan akses ke model bagi user interface dan komponen sistem lainnya. Oleh karena itu, komponen fungsi adalah penghubung antara model dan usage. (p.251).
Function didesain dan diimplementasikan dengan menggunakan operasi dari kelas sistem. Operasi adalah proses
yang dispesifikasikan dalam sebuah kelas dan dijalankan melalui objek dari kelas tersebut. (p.252).
Hasil utama dari kegiatan ini adalah class diagram untuk komponen fungsi dan perpanjangan dari class diagram komponen model. Sub kegiatan dalam perancangan komponen fungsi tampak pada Gambar 2.6 berikut ini :
Design functions as operations
Explore patterns Function list, class
diagram,and component specification. Function-component specification Specify complex operations Model-component specification
Gambar 2.6 Sub activities in function-component design Sumber: Mathiassen, et al. (2000, p252)
Sub kegiatan ini menghasilkan kumpulan operasi yang dapat mengimplementasikan fungsi sistem seperti yang ditentukan dalam analysis problem domain dan function list.
1. Merancang function sebagai operation;
2. Menelusuri pola yang dapat membantu dalam implementasi function sebagai operation;