Pada tahap ini, akan dirancang arsitektur hubungan antara client dan
server yang memadai untuk sistem agar dapat berjalan dengan baik.
Laporan yang dihasilkan adalah Diagram Deployment. Perancangan di sini akan menentukan bagaimana struktur sistem fisik akan dibuat dan bagaimana distribusi sistem informasi pada rancangan fisik tersebut. 4. Desain Komponen ( Component Design )
Desain komponen merupakan sistem struktur yang menghubungkan antar komponen. Laporan yang dihasilkan oleh desain komponen adalah diagram komponen, yaitu diagram yang menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan ( dependency ) di antaranya. Pada tahap ini akan terlihat bagaimana sistem bekerja dan interaksi yang terjadi antara sistem dengan pengguna.
3.4.6.4.Dokumentasi
Dalam pengembangan sistem, dokumen memainkan peran penting dan melayani kebutuhan yang berbeda sebagai alat kerja yang mengumpulkan dan mengatur sub hasil ketika diproduksi, alat kontrol untuk mengukur kemajuan kerja, dan sebagai alat yang menetapkan persetujuan mengenai persyaratan dan rancangan sistem. ( Mathiassen et al., 2000, p300 ).
Dokumentasi analisa adalah presentasi koheren dari hasil analisa, termasuk laporan pra - analisa dan definisi sistem. Menurut Mathiassen et al. ( 2000, pp 301 - 302 ) standar dokumentasi analisa adalah :
1. Tugas, berisikan deskripsi singkat latar belakang dan hubungan dokumen a. Tujuan, berisikan tujuan keseluruhan dari proyek pengembangan
sistem
b. Definisi Sistem, yaitu deskripsi singkat suatu sistem yang terkomputerisasi yang diekspresikan dalam bahasa sehari - hari. Suatu definisi sistem menggambarkan secara dasar sifat - sifat dari pengembangan dan penggunaaan sistem dengan tujuan meniadakan intepretasi dan kemungkinan - kemungkinan yang berbeda.
Definisi sistem ini dapat diuji dengan kriteria FACTOR, yaitu
Functionality Fungsi sistem yang mendukung tugas - tugas
Application Domain Bagian suatu organisasi yang menjalankan,
memonitor, atau mengontrol problem domain ( bagian dari konteks yang dijalankan, dimonitor, atau dikontrol oleh sebuah sistem ).
Conditions Kondisi di mana sistem akan dikembangkan dan digunakan.
Technology Teknologi baik digunakan untuk mengembangkan sistem dan untuk menjalankan sistem.
Objects Objek utama dalam problem domain.
Responsibility Tanggung jawab keseluruhan sistem berkaitan dengan konteksnya.
c. Konteks, yaitu deskripsi aspek yang relevan pada lingkungan sekeliling sistem, antara lain dapat berupa rich picture. Sebuah rich
picture adalah gambaran informal yang mewakili pengertian terhadap
situasi.
1. Problem Domain, berisikan presentasi informal terhadap inti fenomena dalam problem domain sistem.
2. Application Domain, berisikan presentasi informal dari aktor dan tugas kerja.
2. Problem Domain, berisikan deskripsi class, structure, dan dynamics dalam sistem objek.
a. Cluster, yaitu suatu koleksi dari class yang berhubungan.
b. Struktur, berisikan diagram class yang terdiri dari struktur
generalization, aggregation, dan association.
Struktur generalization adalah suatu hubungan antara dua atau lebih
class spesialisasi dan class yang lebih umum, di mana class yang lebih
umum ( super class ) mendeskrepsikan sifat - sifat umum dari sekelompok class spesialisasi ( subclasses ).
Struktur aggregation adalah suatu antara dua atau lebih objek, di mana satu objek adalah sebuah dasar dan mendefinisikan bagian objek lain.
Aggregation adalah sebuah objek superior ( keseluruhan ) yang terdiri
dari sejumlah objek lain yang inferior ( bagian ).
Struktur association adalah suatu hubungan antara dua atau lebih objek, tetapi berbeda dari aggregation di mana objek association tidak mendefinisikan sifat dari sebuah objek.
c. Classes, yaitu sebuah gambaran dari sekumpulan objek yang memiliki struktur pola behavior, dan atribut.
Pola behavior adalah suatu gambaran dari urutan event untuk semua objek di dalam sebuah class.
1. Definisi, yaitu karakteristik singkat dari objek dalam class.
2. Pola behavior, yang dapat digambarkan menggunakan diagram
statechart.
d. Events, yaitu suatu kejadian singkat ( instantaneous ) yang melibatkan satu atau lebih objek, dapat digambarkan dengan event table dan
sequence diagram.
3. Application Domain, berisikan deskripsi lengkap dari usage, function,
interfaces, dan persyaratan sistem lainnya.
a. Usage, yaitu deskripsi dari interaksi sistem dengan lingkungan sekitar. Analisa terhadap application domain dapat menciptakan detail informasi yang besar tetapi mempunyai nilai yang kecil dalam proses pengembangan, sehingga untuk mencapai fokus yang relevan digunakan use case. Use case adalah suatu pola interaksi antara sistem dan aktor dalam application domain. Pengertian aktor adalah abstraksi dari user atau sistem lain yang berinteraksi dengan sistem sistem target.
1. Overview, berisikan tabel aktor yang memperlihatkan aktor dan
use case yang terlibat dalam interaksi.
2. Aktor, berisikan spesifikasi aktor untuk semua aktor.
3. Use Cases, berisikan spesifikasi use case atau diagram statechart untuk semua use case.
b. Fungsi, berisikan deskripsi dari fungsionalitas sistem.
1. Complete Function List, berisikan semua fungsi, termasuk jenis fungsi dan taksiran kompleksitas untuk masing-masing fungsi. Empat jenis fungsi yaitu:
• Fungsi update yang diaktifkan oleh event problem domain dan menghasilkan perubahan dalam state model.
• Fungsi signal yang diaktifkan oleh perubahan dalam state model dan menghasilkan reaksi dalam konteks; reaksi ini dapat berupa display kepada aktor dalam application domain, atau dapat berupa intervensi langsung dalam problem domain.
• Fungsi read yang diaktifkan oleh kebutuhan informasi di dalam kerja aktor dan menghasilkan sistem mendisplay bagian yang relevan dari model.
• Fungsi compute yang diaktifkan oleh kebutuhan informasi di dalam kerja aktor dan terdiri dari perhitungan yang melibatkan informasi yang disediakan oleh aktor atau model.
2. Spesifikasi Fungsi, berisikan fungsi kompleks dalam detail yang relevan.
c. User Interface, berisikan presentasi koheren persyaratan dari user
1. Dialogue style, berisikan gambaran presentasi dan dialog dan daftar lengkap elemen dalam user interface.
2. Overview, berisikan diagram navigasi untuk seluruh user interface. d. Technical Platform, kerangka platform teknis dan keluaran untuk
sistem dan alat lain.
4. Rekomendasi, berisikan argumentasi untuk pengerjaan pengembangan selanjutnya.
a. Kegunaan dan Kelayakan Sistem, berisikan taksiran terhadap hubungan persyaratan dengan lingkungannya dan kemungkinan - kemungkinan teknis.
b. Strategi, yaitu strategi yang diusulkan untuk pengerjaan pengembangan selanjutnya.
c. Ekonomi Pengembangan, yaitu memperkirakan sumber daya dan waktu yang dikonsumsi untuk pengerjaan pengembangan selanjutnya.
Dokumentasi perancangan adalah presentasi koheren dari hasil perancangan. Menurut Mathiassen et al. ( 2000, pp304-305 ) standar dokumentasi perancangan adalah sebagai berikut:
1. Tugas, berisikan deskripsi singkat tugas dan tujuan kualitas yang diformulasi.
a. Tujuan, berisikan tujuan keseluruhan dari proyek pengembangan sistem.
b. Koreksi terhadap Analisa, berisikan koreksi kesalahan, modifikasi yang diperlukan, dan tambahan terhadap dokumen analisa.
c. Tujuan Kualitas, berisikan ringkasan prioritas kriteria rancangan dan tujuan tambahan untuk arsitektur.
2. Technical Platform, berisi gambaran ringkas dari bahasa perancangan dan peralatan, software sistem, dan sistem tempat di mana sistem akan dikembangkan dan direalisasi.
a. Peralatan, yaitu deskripsi peralatan yang relevan.
b. Software sistem, berisikan deskripsi software sistem yang relevan. c. Interface sistem, berisikan deskripsi dari rancangan keluaran terhadap
sistem yang mana akan berinteraksi dengan sistem yang dikembangkan.
d. Bahasa perancangan, berisikan deskripsi bahasa perancangan yang digunakan dengan referensi dengan bahasan dan standar yang familiar. 3. Arsitektur, berisikan deskripsi strukturisasi sistem ke dalam komponen
dan proses. Termasuk deskripsi perancangan arsitektur standar.
a. Arsitektur Komponen, berisikan class diagram yang memperlihatkan strukturisasi sistem ke dalam komponen - komponen yang terkait.
b. Arsitektur Proses, berisikan deployment diagram yang memperlihatkan prosesor yang tersedia, objek yang aktif, dan koneksinya.
c. Standar, berisikan standar perancangan yang digunakan.
4. Komponen, berisikan deskripsi model, fungsi, interface sistem, user
interface, dan komponen lainnya.
5. Rekomendasi, berisikan rencana substansi untuk pengerjaan pengembangan selanjutnya.
a. Kegunaan Sistem, berisikan evaluasi menyeluruh terhadap hubungan perancangan dengan konteks berdasarkan tujuan kualitas.
b. Rencana untuk Penggunaaan Awal, berisikan rencana yang direkomendasikan bagaimana sistem digunakan.
c. Rencana Implementasi, berisi rencana yang direkomendasikan untuk realisasi sistem meliputi aktivitas dan perkiraan waktu dan konsumsi sumber daya.
3.4.7. Keunggulan dan Kelemahan Analisis dan Perancangan Berorientasi Objek
3.4.7.1.Keunggulan Analisis dan Perancangan Berorientasi Objek
Terdapat dua kemampuan sistem berorientasi objek ( McLeod, 2001, p613-614 ) yaitu :
1. Reusability
Kemampuan untuk menggunakan kembali pengetahuan dan kode program yang ada, dapat menghasilkan keunggulan saat suatu sistem baru dikembangkan atau sistem yang ada dipelihara atau direkayasa ulang. Setelah suatu objek diciptakan, ia dapat digunakan kembali, mungkin hanya dengan modifikasi kecil di sistem lain. Ini berarti biaya pengembangan yang ditanamkan di satu proyek dapat memberikan keuntungan bagi proyek - proyek lain.
2. Interoperability
Kemampuan untuk mengintegrasikan berbagai aplikasi dari beberapa sumber, seperti program yang dikembangkan sendiri dan perangkat lunak jadi, serta menjalankan aplikasi - aplikasi ini di berbagai platform perangkat keras.
Reusability dan interoperability menghasilkan empat keunggulan
kuat ( McLeod, 2001, p614 - 615 ), yaitu:
- Peningkatan kecepatan pembangunan, karena sistem dirancang seperti dunia nyata melihatnya.
- Kode berkualitas tinggi memberikan keandalan lebih besar dan ketangguhan yang lebih dibandingkan yang biasa ditemukan dalam sistem berorientasi proses.
- Pengurangan biaya pemeliharaan dan rekayasa ulang sistem, karena kode yang berkualitas tinggi dan kemampuan pemakaian kembali.
3.4.7.2. Kelemahan Analisis dan Perancangan Berorientasi Objek
Beberapa kelemahan dari sistem berorientasi objek ( McLeod, 2001, p615 ) adalah:
- Diperlukan waktu lama untuk memperoleh pengalaman pengembangan. - Kesulitan metodologi untuk menjelaskan sistem bisnis yang rumit.
- Kurangnya pilihan peralatan pengembangan yang khusus disesuaikan untuk sistem bisnis.