• Tidak ada hasil yang ditemukan

2.8 Analisis dan Perancangan S istem dengan Pendekatan Object Oriented Analysis and Design (OOAD)

2.8.2 Tahapan Analisis

2.8.2.2 Application Domain Analysis

M enurut M athiassen et al. ( 2000, p6, p115 ), application domain merupakan bagian yang mengatur, memonitor, atau mengendalikan problem domain. Tujuan dari application domain analysis adalah untuk menentukan kebutuhan dari system function

dan interfaces. Aktivitas dari application domain analysis terdiri dari usage, function, dan interfaces, yang akan dijabarkan dalam gambar berikut.

Gambar 2.17 : Application domain analysis (M athiassen et al, 2000, p117)

Berikut adalah bagan aktivitas dalam application domain analysis.

Activity Content Concepts

Usage Bagaimana system berinteraksi Use case dan actor dengan orang dan system lain ?

Functions Apa saja kemampuan dari system Function Untuk memproses informasi ?

Interfaces Apa saja kebutuhan interface system ? Interface, user interface,

dan system interface

Tabel 2.4 : Aktivitas dalam application domain analysis (M athiassen et al, 2000, p117)

2.8.2.2.1 Usage

M enurut M athiassen et al (2000, p119), use case menyediakan gambaran keseluruhan kebutuhan system dari sudut pandang user dan menyediakan dasar untuk menentukan dan mengevaluasi function dasar dan interface system. Use case fokus kepada interaksi antara user dengan system.

Use case adalah sebuah abstraksi dari interaksi dengan target system. Use case dapat dimunculkan oleh actor atau target system. Actor adalah abstraksi dari user atau system lain yang berinteraksi dengan target system. Use case didasarkan pada kebutuhan dan kondisi dalam application domain, tapi use case juga merupakan ekspresi dari sebuah solusi.

Berikut adalah subaktivitas dalam usage, dimana hasil dari aktivitas usage adalah use case dan actor.

Gambar 2.18 : Subaktivitas dari usage (M athiassen et al, 2000, p120)

Dalam penyajian hasil dari aktivitas usage bisa digunakan actor table atau use case diagram, bentuk dan contohnya sebagai berikut.

Tabel 2.5 : Contoh Actor table (M athiassen et al, 2000, 121)

Gambar 2.19 : Use case diagram (M athiassen et al, p122)

Find Actors and U se Cases Identifikasi actors

Untuk mengidentifikasi actor berdasarkan divisi pekerjaan dan peran yang berkaitan dengan tugas tertentu dalam target system. Jika beberapa peran mempunyai tugas yang sama pada system, maka mereka dapat dijadikan sebagai satu actor. Sebuah actor diperjelas dengan menggunakan actor specification yang berisi penjelasan dari actor.

Tabel 2.6 : Contoh Actor specification (M athiassen et al, 2000, p126)

Goal menjelaskan peran actor dalam target system. Characteristics menjelaskan aspek penting dari actor yang menggunakan system. Jika actor berupa system lain, maka characteristic harus meliputi interface teknis. Kemudian, examples diisi dengan karakteristik umum actor dan ditambahkan dengan contoh konkrit.

Identifikasi use case

Use case adalah sebuah abstraksi dari interaksi actor atau system lain dengan target system. Oleh karena itu sangat penting untuk menentukan abstraksi yang tepat. Use case didasarkan pada sudut pandang actor dan tugas dari application domain. Tujuannya adalah untuk mengumpulkan berbagai cara yang mungkin dalam menggunakan target system.

Daftar dari use case yang mungkin didapat dari menganalisa tugas dari application domain, harus digambarkan secara detail. Karena use case adalah fenomena dinamis, maka dapat digambarkan dengan menggunakan statechart diagram atau spesifikasi tertulis.

Gambar 2.20 : Statechart diagram use case “cash withdrawal” (M athiassen et al, 2000, p127)

Tabel 2.7 : Spesifikasi tertulis use case “cash withdrawal” (M athiassen et al, 2000, p128)

Explore pattern

Pola adalah sumber inspirasi yang dapat membantu untuk mengindentifikasi dan menggambarkan use case. Berikut adalah pola yang dapat dijadikan panduan.

The procedural pattern

Pola procedural merupakan solusi umum yang sering digunakan, terutama untuk use case yang mengandung aktivitas yang berupa sequence dan iteration.

Gambar 2.21 : The procedural pattern (M athiassen et al, p130)

The material pattern

Pola material cocok digunakan untuk situasi dimana banyak kemungkinan banyak aktivitas yang dapat dilakukan.

Gambar 2.22 : The material pattern (M athiassen et al, 2000, p131)

Evaluate systematically

Use case dan actor yang telah ditentukan harus dievaluasi apakah relevan dengan keadaan yang sebenarnya. Ada tiga cara untuk mengevaluasi use case :

• Evaluasi harus dilakukan dengan teliti untuk menemukan kesalahan dan hal-hal yang tidak konsisten.

• Uji use case apakah dapat bekerja dengan baik di keadaan yang sebenarnya. • Evaluasi perubahan sosial dalam application domain.

2.8.2.2.2 Functions

M enurut M athiassen et al (2000, p137), function fokus pada apa yang dapat dilakukan oleh system untuk membantu actor dalam pekerjaannya. Dahulu kala secara tradisional, function dikonotasikan sebagai perhitungan, dimana input data diubah menjadi output data. Namun sekarang ini, function didefinisikan sebagai sebuah fasilitas untuk membuat model berguna bagi actor.

Sebuah function diaktifkan, dieksekusi, dan menyajikan hasil. Eksekusi dari function dapat merubah reaksi dalam application atau problem domain. Function adalah sebuah kebutuhan, dapat juga diartikan sebagai property abstrak dari system. Function direalisasikan melalui operasi dari program.

Function dibagi menjadi beberapa tipe. Berikut adalah empat tipe function : • Update

Function ini disebabkan oleh event problem-domain dan menghasilkan perubahan dalam state atau keadaan dari model tersebut.

• Signal

Function ini disebabkan oleh perubahan keadaan atau state dari model yang dapat menghasilkan reaksi pada konteks.

• Read

Function ini disebabkan oleh kebutuhan informasi dalam pekerjaan actor dan mengakibatkan system menampilkan bagian yang berhubungan dengan informasi dalam model.

• Compute

berisi perhitungan yang melibatkan informasi yang disediakan oleh actor atau model, hasil dari function ini adalah tampilan dari hasil komputasi.

Tujuan dari aktivitas function adalah menentukan kemampuan dari system untuk memproses informasi, dengan cara membangun daftar function yang lengkap, dan juga detail lengkap spesifikasi dari function yang complex.

Berikut adalah subaktivitas yang ada dalam analisis function.

Gambar 2.23 : Subaktivitas dalam analisis function (M athiassen et al, 2000, p139)

Find function

Untuk menemukan function ada dua aspek penting, yaitu : • Sumber untuk identifikasi function.

Sumber untuk identifikasi function berasal dari problem domain yaitu classes dan events, dari application domain yaitu dari use case. Classes biasanya akan menciptakan read function dan update function. Events biasanya akan menciptakan update function. use case akan menciptakan seluruh tipe function.

• Tingkat detail.

Seberapa detail yang harus digambarkan dari sebuah function tergantung pada kebutuhan users dan developers.

Update function dihubungkan dengan events. Setiap events memicu update dari state setiap model object yang terlibat event tersebut. Read function berhubungan dengan informasi yang dibutuhkan, yang diekspresikan melalui use case. Compute function berhubungan dengan kebutuhan informasi yang complex, yang tidak dapat dipenuhi hanya dengan membaca model. Compute function diidentifikasikan melalui use case. Signal function berhubungan dengan critical states dari model. Critical states dari model adalah states yang membutuhkan reaksi dari konteks.

Hasil dari aktivitas analisis function adalah daftar kebutuhan functional system. Function list berisi function secara lengkap dan mengekspresikan kebutuhan system.

Tabel 2.8 : Function list (M athiassen et al, 2000, p145)

Complexity adalah ukuran terhadap seberapa sulit dalam mengembangkan function. Dalam hal ini terbagi atas empat ukuran yaitu simple, medium, complex, dan very complex (M athiassen et al, 2000, p144).

Specify complex functions

Dibutuhkan penjelasan detail mengenai function yang tergolong complex. Cara yang dapat digunakan untuk menjelaskan complex function, sebagai berikut :

• Menggunakan perhitungan matematika

menjelaskan function dengan perhitungan matematika. • Menggunakan algoritma

M enjelaskan function dengan bahasa terstruktur, menggunakan pendekatan logika pemrograman.

Tabel 2.9 : Contoh penjelasan complex function menggunakan algoritma (M athiassen et al, 2000, p146)

• Menggunakan rincian

Tabel 2.10 : Contoh penjelasan complex function menggunakan rincian (M athiassen et al, 2000, p146)

Evaluate systematically

Function list menggambarkan fungsionalitas dari target system. Function list harus dibandingkan dengan model, untuk memastikan informasi tentang object yang dibutuhkan oleh function, tidak berlebih juga tidak kekurangan. Oleh karena itu, jika model memiliki object, structure, atau event yang tidak digunakan oleh function, maka bisa jadi model memiliki terlalu banyak informasi, atau ada function yang hilang (M athiassen et al, 2000, p146-147).

2.8.2.2.3 Interfaces

Interface digunakan oleh actor untuk berinteraksi dengan system. Interfaces menghubungkan system dengan seluruh actor yang relevan dalam konteks, oleh sebab itu interface dapat diartikan sebagai fasilitas yang membuat model system dan function tersedia bagi actor (M athiassen et al, 2000, p151). Ada dua jenis interface, yaitu : user interfaces : interface untuk user, dan system interfaces : interface untuk system lain.

Seperti yang ditampilkan dalam gambar, sumber aktivitas analisis interface berasal dari Class Diagram, Use cases, dan Function List.

Gambar 2.24 : Subaktivitas analisis interface (M athiassen et al, 2000, p153)

Explore pattern User interface pattern

M enurut M athiassen et al (2000, p154-156), user interface harus menyajikan model dan function kepada user secara jelas dan dengan cara yang dapat dimengerti user. Kegiatan analisa interfaces berusaha untuk menampilkan use case dalam bentuk aktivitas yang berurutan atau sequencial, dengan ditambahkan interface yang terlibat dalam kegiatan tersebut. Penggambaran dalam bentuk activity sequencial tersebut akan menghasilkan sequence diagram.

Gambar 2.25 : Sequence diagram (M athiassen et al, 2000, p157)

Setelah sequence diagram dibuat, kemudian dibuat navigation diagram, yang berisi urutan-urutan user interface yang digunakan dalam system.

Gambar 2.26 : Navigation diagram (M athiassen et al, 2000, p160)

Ketika menentukan user interface, maka fokus akan beralih kepada dialog style yang akan digunakan agar system dapat berkomunikasi dengan actor. Ada empat pola dialog pattern, yaitu :

• Pola menu selection

User interface disajikan dalam bentuk daftar pilihan yang mungkin. User memilih dari antara daftar tersebut sesuai dengan kebutuhannya. Pola ini cocok untuk user pada umumnya, hanya cocok untuk user yang dapat mentoleransi interaksi yang relatif lambat.

• Pola form fill-in

M erupakan pola klasik untuk input data berupa karakter. Pola ini cocok untuk user yang sering menggunakan system untuk meng-input data.

• Pola command language

User tidak disuguhi tampilan apa pun, mereka harus memasukkan command sesuai keinginan mereka. Pola ini hanya cocok untuk user yang sudah sangat ahli dalam command language, juga untuk user yang ingin kendali penuh atas dialog.

• Pola direct manipulation

M erupakan pola yang menyajikan object bagi user. Dengan pola ini user bisa memilih object dan langsung dapat melihat hasilnya. Pola ini cocok pada user pada umumnya. Dalam pola ini object ditampilkan dalam bentuk icon.

System interface pattern

System biasanya berhubungan dengan system lain. Contohnya, system dalam pelayanan umum berhubungan dengan database keamanan sosial, system perusahaan berhubungan dengan database pelanggan. Sama halnya dengan user interface, pola juga dapat membantu menganalisa system interface. Berikut adalah pola system interface :

• Read external device

Dalam hubungan antar system diperlukan kebutuhan untuk membaca dari external device. Kebutuhan tersebut bahkan dapat terjadi berulang-ulang. • Interaction protocol

Komunikasi dengan system lain dapat menjadi lebih rumit dibandingkan hanya pertukaran data melalui external device, karena dapat saling mempengaruhi satu sama lain. Biasanya pola ini tidak dipakai untuk system administratif tetapi lebih sering dalam mengawasi dan kontrol system.

2.8.3 Tahapan Desain

Dokumen terkait