Model testing OOA dan OOD

8.2.2 Model testing OOA dan OOD

Model disain analisis tidak dapat dites dalam arti konvensional, karena model tersebut tidak dapat dieksekusi. Namun demikian, kajian teknis formal dapat digunakan untuk melakukan testing kebenaran dan konsistensi model analisis maupun model disain.

Kebenaran Model OOA dan OOD

Notasi dan sintak yang digunakan untuk merepresentasikan model analisis dan disain akan dikaitkan dengan analisis khusus dan metode disain yang didipilih untuk proyek itu. Oleh sebab itu, kebenaran sintaksis dinilai pada penggunaan simbol yang teratur, dan masing- masing model dikaji untuk memastikan apakah konvensi pemodelan yang tepat telah terjaga. Selama analisis dan disain, kebenaran sematik harus dinilai berdasarkan kesesuaian model dengan domain dunia nyata. Bila model secara akurat merefleksikan dunia nyata (ke suatu tingkat detil yang sesuai dengan pengembangan di mana m odel dikaji) maka model benar secara sematis. Untuk menentukan apakah model pada dasarnya sungguh-sungguh merefleksikan dunia nyata, model haru s direpresentasikan ke pakar dari domain masalah, yang akan memeriksa definisi kelas dan hirarki untuk penghilangan dan ambigu By Hendranet itas. Koneksi kelas (koneksi instan) dievaluasi untuk menentukan apakah mereka secara akurat

merefleksikan koneksi obyek dunia nyata. Use case mungkin berharga dalam sintaksis penelusuran dan model disain terhadap skenario kegunaan dunia nyata untuk sistem OO.

Konsistensi Model OOA dan OOD

Konsistensi model OOA dan OOD dapat dinilai dengan “mempertimbangkan hubungan antar entitas di dalam model tersebut.” Model yang tidak konsisten memiliki representasi di dalam satu bagian ya ng tidak direfleksikan secara benar di bagian lain dari model [MCG94]. Untuk m enilai konsist ensi, masing-masing kelas dan koneksinya ke kelas lain harus dites. Model CRC dan diagram OO dapat digunakan untuk memfasilitasi aktivitas tersebut. Model CRC disusun pada kartu indeks CRC. Masing-masing kartu CRC mendaftar nama kelas, tanggung jawabnya (operasi), dan kolaborasinya (kelas-kelas lain ke mana ia mengirim pesan dan di mana dia bergantung untuk melakukan tanggung jawabnya). Kolaborasi mengimplikasikan sederetan hubungan (koneksi) di antara kelas-kelas sistem OO. Model hubungan obyek memberikan representasi grafik mengenai koneksi-koneksi di antara kelas- kelas. Semua informasi itu dapat diperoleh dari model OOA.

Untuk mengevaluasi model kelas, direkomendasikan langkah-langkah berikut [MCG94]:

1. Lihat lagi model CRC dan model hubungan obyek. Lalukan cek silang untuk memastikan apakah semua kolaborasi yang diimplikasikan oleh model OOA direfleksikan secara tepat pada keduanya.

2. Periksa deskripsi masing-masing kartu indeks CRC untuk menentukan apakah tanggung jawab yang dilimpahkan merupakan bagian dari definisi kolaborator. Contohnya, perhatikan kelas yang didefinisikan untuk sistem point-of-sale check-out yang disebut credit sale . Kelas ini memiliki kartu indeks CRC yang ditunjukkan pada gambar 8.1.

3. Untuk kumpulan kelas dan kolaborasi tersebut, kita bertanya apakah tanggung jawab (m isalnya, read credit card ) dilakukan bila dilimpahkan ke kolaborator yang diberi nama ( credit card ): yaitu, apakah kela s credit card memilki operasi yang memungkinkan dibaca? Di dalam kasus ini, jawaban nya adalah “ya”. Hubungan obyek dilewatkan untuk memastikan apakah semua koneksi itu valid.

4. Inversikan koneksi untuk memastikan apakah masing-masing kolaboraor yang diminta untuk melayani sedang mene rima permintaan dari sumber yang jelas. Misalnya, bila kelas credit card menerima permintaan untuk melakukan purchase amout dari kelas credit sale , akan ada suatu masalah. Credit card tidak mengetahui purchase amount .

5. Dengan menggunakan koneksi yang diinversi yang diamati dalam langkah 3, tentukan apakah kelas-kelas yang lain mungkin diperlukan atau apakah tanggung jawab dikelom pokkan di antara kelas secara tepat.

6. Tentukan apakah tanggung jawab yang diminta secara luas dapat dikombinasikan ke dalam sebuah tanggung jawab tunggal. Contohnya, read credit card dan get authorization terjadi pada setiap situasi. Keduanya dapat dikombinasikan ke dalam tanggung jawab By Hendranet validate credit request yang bersama-sama mengambil nomor kartu kerdit dan memperoleh otorisasi.

7. langkah 1 – 5 diaplikasikan secara iteratif pada masing-masing kelas melalui setiap evolusi model OOA.

Gambar 8.1 Contoh kartu indeks CRC yang digunakan untuk kajian.

Begitu model disain diciptakan, kajian disain sistem dan disain obyek sudah harus dilakukan. Disain sistem menggambarkan subsistem yang dialokasikan ke prosesor, dan alokasi kelas ke subsistem. Model obyek menyajikan detail dari masing-masing kelas dan aktivitas pemesanan yang diperlukan untuk mengimplementasikan kolaborasi antar kelas. Disain sistem dikaji dengan melakukan testing model tingkah laku obyek yang dikembangkan selama OOA serta pemetaan yang diperlukan tingkah laku sistem terhadap subsistem yang didisain untuk melakukan tingkah laku ini. Keadaan tingkah laku sistem dievaluasi untuk menentukan mana yang ada secara konkruen. Model obyek harus dit es terhadap jaringan hubungan obyek untuk memastikan apakah semua obyek disain berisi atribut dan operasi yang diperlukan untuk mengimplementasi kolaborasi yang ditentukan untuk masing-masing kartu indeks CRC, sebagai tambahan, spesifikasi detil mengenai detil operasi (algoritma yang mengimplementasi operasi) dikaji dengan menggunakan teknik inspeksi konvensional.