Dengan pendekatan Object-Oriented Analysis and Design (OOAD), baik eksekusi yang sudah ada maupun pengaturan kerja baru dideskripsikan. Pada OOAD ditekankan adalah sudut pandang dari user. Pada OOAD setidaknya ada dua hal penting di dalamnya yaitu (M athiassen, 2000, p135-136):
• OOAD adalah metode untuk menganalisis dan merancang sistem.
M etode harus dilengkapi dengan teori dan metode yang berkaitan dengan perancangan dari pengaturan proses kerja.
• OOAD adalah metode object oriented.
Jika penting, metode harus dilengkapi dengan metode pengembangan sistem lainnya yang akan mendukung fokus yang lebih kuat pada penggunaan analisis dan perancangan..
Dalam penggunaan OOAD menurut M athiassen (2000, p14-44) terdapat empat aktivitas utama dan digambarkan seperti berikut ini:
Model Requirement for use Spesification of architecture Spesification of component Problem-domain analysis Application-domain analysis Architectural Design Component Design Sumber : M athiassen (2000, p15). Gambar 2 11 Aktivitas Utama OOAD
Dalam prakteknya sebelum kita memulai keempat kegiatan utama dalam OOAD, terlebih dahulu kita melakukan langkah-langkah pendahuluan. Beberapa langkah yang dilakukan adalah mengumpulkan ide-ide yang akan dikembangkan berdasarkan pada pemahaman terhadap masalah yang sedang dihadapi, solusi-solusi yang mungkin diterapkan untuk mengatasi masalah tersebut, dan lain-lain. Hasil dari langkah pendahuluan ini adalah system definition yaitu deskripsi singkat dari sistem komputer dalam natural language. System definition menjelaskan mengenai konteks sistem, informasi yang harus ada di dalam sistem, fungsi-fungs i yang harus dimiliki, dimana akan digunakan dan kondisi serta batasan yang harus diperhatikan.
Dalam pembuatan system definition, kita harus memperhatikan pendekatan kriteria FACTOR untuk dapat melengkapi informasi yang terkandung dalam definisi sistem yang akan dibuat. Dengan menggunakan pendekatan FACTOR, system definition akan berisi tentang (M athiassen, 2000, p39-40):
• Functionality: Fungsi yang dimiliki sistem yang akan membantu kegiatan yang
dilakukan dalam application domain.
• Application Domain: Bagian dari organisasi yang akan mengawasi,
mengendalikan problem domain.
• Condotions: Kondisi dimana sistem akan dikembangkan dan digunakan.
• Technology: Teknologi yang akan digunakan baik dalam pengembangan sistem
dan teknologi yang mendukung pengoperasian dari sistem.
• Objects: Objek utama dalam problem domain.
• Responsibility: Tanggung jawab dari sistem dalam hubungan dengan konteks
sistem itu sendiri.
Setelah melakukan langkah pendahuluan, kita akan melakukan empat kegiatan utama dalam OOAD. M asing-masing kegiatan utama dalam OOAD adalah (M athiassen, 2000, p14-15):
• Analisis Problem Domain.
Sumber : M athiassen (2000, p46)
Gambar 2.12 Aktivitas Analisis Problem Domain
Tujuan dari kegiatan ini adalah untuk mengidentifikasi dan memodelkan problem domain. Problem domain adalah bagian dari konteks yang diatur, diawasi, dan dikendalikan oleh sistem (M athiassen, 2000, p45). Hasil dari analisis problem domain adalah model sistem yang berisi informasi mengenai kebutuhan sistem. M odel adalah deskripsi dari class, objek, struktur dan behavior di dalam problem domain. Dalam kegiatan ini dapat dibagi menjadi tiga aktivitas utama, yaitu memilih class, objek dan event yang menjadi elemen model, membangun hubungan di antara class dan objek, dan menentukan properti dari atribut masing-masing class. Aktivitas utama dari problem domain analysis menurut M athiassen (2000, p48) adalah:
¾ Classes
Class adalah deskripsi dari sekumpulan objek yang memiliki struktur, pola behavior dan atribut yang sama (M athiassen, 2000, p49). Hasil dari aktivitas ini adalah berupa event table yang menunjukkan class yang dipilih dan
event-event yang berhubungan dengan class tersebut. M enurut M athiassen (2000, p55) terdapat tiga subaktivitas di dalam kegiatan ini, yaitu:
Menentukan kandidat class
Langkah ini merupakan kunci utama dalam menentukan problem domain. Pada umumnya cara mencarinya adalah dengan mencari sebanyak-banyaknya kata benda yang terdapat dalam rich picture, ataupun system definition.
Menentukan kandidat event
Selain class, event juga merupakan bagian penting dalam problem domain. Cara untuk mencari event adalah dengan mencari sebanyak-banyaknya kata kerja yang berkaitan dengan behavior dari objek yang telah terpilih
Mengevaluasi dan memilih secara sistematik
Jika daftar class dan event yang ditentukan telah lengkap, maka kita akan mengevaluasinya secara sistematik. Kriteria umum yang digunakan dalam proses evaluasi adalah sebagai berikut:
o class dan event ada dalam system definition
o class dan event relevan untuk problem domain
¾ Structure
Pada aktivitas ini, kita melakukan pendefinisian terhadap class dan objek yag ada dalam problem domain. Konsep hubungan struktural yang digunakan dalam langkah ini, yaitu:
Class Structure
Pada generalization, class-class umum menjelaskan properties dari suatu grup class yang khusus
o Cluster Structure
Pada cluster, class-class yang saling berhubungan dikelompokkan ke dalam satu kelompok.
Object Structure
o Aggregation Structure
Pada aggregation, kita mendefinisikan superior objek yang mengandung beberapa objek.
o Association Structure
Pada association, kita menunjukkan relasi yang penting di antara objek-objek. Hasil dari aktivitas ini adalah class diagram dengan class-class dan struktur-struktur..
¾ Behavior
Aktivitas ini mendeskripsikan properti yang dinamik dan atribut dari setiap class yang dipilih. Konsep dari behavior (M athassen, 2000, p89) adalah sebagai berikut:
Event Trace
Event Trace adalah serangkaian kejadian yang melibatkan objek tertentu
Behavioral Pattern
Behavior Pattern adalah deskripsi dari penelusuran event yang mungkin untuk seluruh objek di dalam class.
Attribute
Attribute adalah deskripsi dari properti sebuah class atau sebuah event. Hasil dari aktivitas ini adalah behavior pattern dan atribut bagi class-class di dalam class-class diagram.
• Analisis Application Domain.
Sumber: M athiassen (2000, p117)
Gambar 2.13 Aktivitas Analisis Application Domain
Tujuan dari kegiatan ini adalah menentukan kebutuhan penggunaan sistem. Application domain adalah sebuah organisasi yang mengatur, mengawasi dan mengendalikan problem domain. Application domain berfokus pada fungsi dan interface dari sistem dan bagaimana suatu sistem akan digunakan oleh user. Aktivitas utama dalam application domain analysis menurut M athiassen (2000, p117) adalah :
¾ Usage
M enurut M athiassen (2000, p119-120) kegiatan usage merupakan kegiatan pertama dalam analisis application domain. Pada kegiatan ini kita menggambarkan bagaimana aktor akan berinteraksi dengan sistem. Yang dimaksud dengan aktor adalah penggambaran dari user maupun sistem lain
yang akan berinteraksi dengan sistem tersebut. Pada aktivitas ini kita akan menggambarkan interaksi antara sistem dengan aktornya di dalam use case. Use case adalah pola interaksi antara sistem dengan aktor di dalam application domain. Use case ini pada umumnya digambarkan dalam bentuk diagram. Selain dalam bentuk diagram, use case juga dapat digambarkan menggunakan use case specification yang menjelaskan use case secara singkat dan jelas. Hasil dari aktivitas ini merupakan deskripsi semua use case dan aktornya.
¾ Function
Pada kegiatan ini kita menjelaskan bagaimana kemampuan dari proses dan informasi dalam sistem. Function adalah fasilitas untuk membuat sebuah model berguna untuk aktor. Tujuan dari function adalah menentukan kemampuan sistem untuk memproses informasi. Cara untuk mengidentifikasi function adalah dengan melihat deskripsi problem domain yang dinyatakan dalam class dan event, dan melihat deskripsi application domain yang dinyatakan dalam use case. Hasil dari aktivitas ini berupa daftar lengkap dari function dengan spesifikasi dari function yang kompleks. Function memiliki empat tipe berbeda yaitu:
Update
Fungsi ini diaktifkan oleh event problem domain dan menghasilkan perubahan status model.
U pd a te * I F M A D P D *
Gambar 2 14 Fungsi Update Signal
Fungsi ini diaktifkan oleh perubahan status model dan menghasilkan reaksi di dalam konteks.
S ig na l *
I F M
A D
P D
Gambar 2.15 Fungsi Signal Read
Fungsi ini diaktifkan oleh kebutuhan aktor akan informasi dan menghasilkan tampilan model sistem yang relevan.
R e a d *
I F M
A D
P D
Gambar 2.16 Fungsi Read
Compute
Fungsi ini diaktifkan oleh kebutuhan aktor akan informasi dan berisi perhitungan yang dilakukan baik oleh aktor maupun oleh model. .
Gambar 2 17 Fungsi Compute ¾ Interface
Pada kegiatan ini menggambarkan interface dari sistem yang akan dibuat. Interface adalah fasilitas yang memungkinkan model sistem dan function dapat digunakan oleh user. User interface adalah sebuah interface yang dibuat untuk digunakan oleh user, sedangkan system interface adalah suatu interface yang dibuat untuk digunakan oleh sistem lainnya. Sebuah user interface yang baik harus dapat beradaptasi dengan pekerjaan dan pemahaman user terhadap sistem. Kualitas interface pengguna ditentukan oleh kegunaan atau usability interface tersebut bagi pengguna. Usability bergantung pada siapa yang menggunakan dan situasi pada saat sistem tersebut digunakan. Oleh sebab itu, usability bukan sebuah ukuran yang pasti dan objektif. Kegiatan analisis user interface ini berdasarkan pada hasil dari kegiatan analisis lainnya, seperti model problem domain, kebutuhan functional dan use case. Hasil yang diperoleh dari aktivitas ini adalah:
User Interface
Berupa dialogue style dan bentuk presentasi, elemen-elemen dalam user interface, windows diagram yang dipilih dan navigation diagram.
Compute *
I F M
AD
System Interface
Berupa class diagram untuk peralatan eksternal dan protokol untuk berinteraksi dengan sistem lainnya..
• Architectural Design.
Sumber: M athiassen (2000, p176) Gambar 2.18 Aktivitas Architectural Design
Tujuan dari kegiatan ini adalah mengatur ulang struktur sebuah sistem yang terkomputerisasi. Architectural design memiliki fungsi sebagai kerangka kerja dalam aktivitas pengembangan sistem dan mengjasilkan struktur komponen dari proses sistem. Aktivitas utama dalam architectural design menurut M athiassen (2000, p176) adalah :
¾ Criteria
Pada kegiatan ini, kita mendefinisikan kondisi dan rancangan seperti apakah yang digunakan pada perancangan. Kondisi adalah peluang dan batasan teknikal, organisasional dan manusia yang terlibat dalam pelaksanaan tugas. Criteria yang digunakan dalam menentukan kualitas dari software yang akan dibuat ditunjukkan melalui tabel di bawah ini:
Tabel 2.3 Criteria untuk M enentukan Kualitas Software Sumber: M athiassen (2000, p178)
Criterion Ukuran
Usable Kemampuan sistem beradaptasi dengan konteks teknikal dan
organisasional.
Secure Pencegahan akses ilegal terhadap data dan fasilitas
perusahaan
Efficient Eksploitasi ekonomis dari fasilitas technical platform
Correct Kesesuaian dengan kebutuhan
Reliable Fungsi dapat dijalankan secara tepat
Maintainable Biaya untuk mencari dan memperbaiki kerusakan sistem
Testable Biaya untuk menjamin bahwa sistem melakukan fungsinya
Flexible Biaya memodifikasi sistem
Comprehensible Usaha yang diperlukan untuk memahami sistem
Reusable Penggunaan bagian dari sistem ke dalam sistem lain yang
berkaitan
Portable Biaya memindahkan sistem ke technical platform lain
Interoperable Biaya pemasangan sistem dengan sistem lain
Terdapat tiga kriteria dasar yang harus dimiliki dalam perancangan OOAD menurut M athiassen (2000, p179) yaitu:
Usability: menjelaskan bahwa kualitas sistem yang paling baik adalah bergantung pada bagaimana sistem dapat bekerja memenuhi konteks dari sistem tersebut.
Flexibility: menjelaskan bahwa arsitektur sistem harus mampu mengakomodasi perubahan secara menyeluruh dan kondisi teknisnya. Comprehensibility: menjelaskan bahwa dengan semakin
berkembangnya kompleksitas dari sistem komputer, model dan deskripsi harus mudah dimengerti.
¾ Component
Pada kegiatan ini, kita mendefinisikan bagaimana sebuah sistem dibangun menjadi komponen. Arsitektur komponen adalah struktur sistem dari komponen yang saling terkait, sedangkan komponen merupakan kumpulan dari bagian program yang mencakup keseluruhan tanggung jawab. Pola-pola arsitektur komponen antara lain:
Layered Architecture Pattern Generic Architecture Pattern Client-Server Architecture Pattern
Hasil dari kegiatan ini adalah component diagram berupa class diagram yang dilengkapi dengan spesifikasi komponen yang kompleks.
¾ Processes
Pada kegiatan ini, kita menjelaskan strukturisasi fisik dari sistem. Arsitektur proses adalah struktur sistem eksekusi yang terdiri dari proses-proses yang saling tergantung satu sama lain. Dalam aktivitas ini, kita juga menentukan pola distribusi yang sesuai dengan model sistem. Pola-pola distribusi yang ada antara lain:
Centralized Pattern Distributed Pattern
Decentralized Pattern
Hasil dari kegiatan ini adalah deployment diagram yang menunjukkan processor dengan komponen program dan active objects..
• Component Design.
Sumber: M athiassen (2000, p232) Gambar 2.19 Aktivitas Component Design
Komponen adalah sekumpulan bagian program yang membentuk suatu keseluruhan dan memiliki tanggung jawab yang jelas. Tujuan dari kegiatan ini adalah untuk menentukan implementasi dari kebutuhan dalam sebuah kerangka arsitektur. Aktivitas utama dalam component design menurut M athiassen (2000, p232) adalah :
¾ Model Component
Model component merupakan bagian dari sistem yang mengimplementasikan model dari problem domain. Dengan kata lain, model component menggambarkan model dari problem domain dan bertujuan menyampaikan data saat ini pada saat ini atau yang telah lalu kepada function, interface, dan
ke pengguna maupun sistem yang lain. M elalui kegiatan ini, dapat dihasilkan class diagram yang telah direvisi (revised class diagram).
¾ Function Component
Function component merupakan bagian dari sistem yang mengimplementasikan kebutuhan fungsional. Tujuan dari function component adalah memberikan kepada user interface dan komponen dari sistem lain untuk dapat mengakses model. Sebuah function menggambarkan secara eksternal behavior yang dapat diamati secara langsung dan mempunyai arti bagi pekerjaan user. Hasil dari kegiatan ini adalah class diagram dengan operasi dan fungsi-fungsinya. Terdapat empat pola eksplorasi di dalam function component yaitu:
Model-Class Placement Function-Class Placement Startegy
Active Function ¾ Connecting Component
Connecting component merupakan bagian dari sistem yang menghubungkan komponen-komponen dari sistem. Dalam connecting component terdapat dua konsep yaitu:
Coupling
Coupling merupakan ukuran untuk mengukur berapa dekat hubungan di antara dua kelas atau komponen. Coupling memiliki sifat yang merugikan sehingga sebaiknya diminimalisasi.
Cohession
Cohession nerupakan ukuran untuk mengukur seberapa baik ikatan dari sebuah class atau komponen. Cohession memiliki sifat yang menguntungkan sehingga sebaiknya penggunaannya dalam rancangan class harus tinggi.
2.21 Unified Modelling Language (UML).