Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)

Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) Object-Oriented Analysis Object-oriented analysis adalah suatu metoda analisis yang memeriksa syarat-syarat dari sudut pandang kelas-kelas dan objek-objek yang ditemui pada ruang lingkup permasalahan dengan tujuanuntuk memahami domain masalah dan meningkatkan ketelitian, konsistensi, kelengkapan analisis. Mendefinisikan kebutuhan-kebutuhan sistem melalui skenario atau penggunaan kasus-kasus. Kemudian, membuat suatu model obyek (class) dengan kemampuan memenuhi kebutuhan-kebutuhan (attributes). Outputnya berupa model kebutuhan-kebutuhan, biasanya menggunakan CRC Card (classresponsibility-collaborator). Memberikan gambaran rinci dari suatu sistem dan mengidentifikasi “WHAT” → kebutuhan fungsional (Use Cases) dengan identifikasi: objects, classes, operations, object relationships, object interations. Kemudian membangun model-model di dunia nyata dengan menggunakan tampilan Object Oriented Object-Oriented Design Object-oriented design adalah metoda untuk meng-arahkan arsitektur perangkat lunak yang didasarkan pada manipulasi objek-objek sistem atau subsistem. Model kebutuhan-kebutuhan yang dibuat pada fase analisis diperkaya dalam fase perancangan. Kadang-kadang ditambahkan lebih banyak lagi atribut dan pelayanan dan ditambahkan antarmuka obyek-obyek. Object Oriented Design bertujuan untuk mengoptimalkan maintainability, reusability, enhancebility dan reliability. Memberikan blueprint untuk implementasi dan menspesifikasi “HOW” dengan menspesifikasi class definitions, class categories, subsystems, system architectures. Object Oriented Design merupakan Object-Oriented Analysis dengan tambahan rincian implementasi. Hubungan antara OOA dengan OOD

A t tr ib u t e s , o p e ra t io n s , c o lla b o ra to r s CRC In d e x C a r d s

re s p o n s ib ilitie s d e s ig n

O b je c t re la t io n s h ip m o d el

U se cases

O b je c t -B e h a v io r M odel

m essage d e s ig n C la s s a n d o b je c t d e s ig n s u b s y s te m d e s ig n

T H E A N A L Y S IS M O D E L

T H E D E S IG N M O D E L

Gambar 1. Hubungan Model Analisis dengan Model Desain

Ayuliana/ Testing dan Implementasi/April2011

1

A n a l y s i s M o d e l A n a l y s i s M o d e l c l a s s e s c l a s s e s a t t r i b u t e s a t t r i b u t e s m e t h o d s m e t h o d s r e l a t i o n s h i p s r e l a t i o n s h i p s b e h a v i o r b e h a v i o r

D e s i g n M o d e l D e s i g n M o d e l o b j e c t s o b j e c t s d a t a s t r u c t u r e s d a t a s t r u c t u r e s a l g o r i t h m s a l g o r i t h m s m e s s a g i n g m e s s a g i n g c o n t r o l c o n t r o l

Gambar 2. Kaitan OOA dengan OOD

Object-Oriented Testing Tujuan Pembelajaran : • Aktivitas-aktivitas dalam object-oriented testing • Menjelaskan strategi object-oriented testing (class testing, integration testing, validation testing) • Menjelaskan desain kasus uji untuk perangkat lunak berorientasi Objek (OO software) • Mendefinisikan dan menjelaskan metode ujicoba yang dapat diterapkan pada tingkatan class • Menjelaskan desain kasus uji inter-class • Menjelaskan metoide ujicoba yang dapat diterapkan pada tingkatan inter-class Pendahuluan Proses ujicoba sistem yang berorientasi objek (object-oriented system) dimulai dengan meninjau ulang analisis dan model desain berorientasi obyeknya (object-oriented analysis and design models). Ketika sebuah program telah dituliskan, object-oriented testing (OOT) dimulai dengan menguji "in the small" dengan class testing (class operations dan collaborations). Ketika class-class tersebut diintegrasikan menjadi sebuah subsistem, maka masalah kolaborasi class akan diketahui. Terakhir, use-cases dari model OOA digunakan untuk menemukan kesalahan validasi software. OOT hampir mirip dengan ujicoba software konvensional dalam hal kasus uji yang akan dibangun untuk melatih class-class yang ada dan kolaborasi antar class-nya juga prilakunya. OOT berbeda dari ujicoba software konvensional dalam hal penekanan terhadap konsistensi dan kelengkapan penaksiran dari model OOA dan OOD yang telah dibangun. OOT cenderung lebih fokus kepada masalah integrasi dari pada unit testing. Object-Oriented Testing Activities • Meninjau ulang model OOA dan OOD • Ujicoba Class setelah penulisan program sumber • Ujicoba Integrasi dalam subsistems • Ujicoba Integrasi subsistem yang telah ditambahkan kedalam sistem • Ujicoba validasi berdasarkan OOA use-cases Ujicoba Model OOA dan OOD OOA dan OOD tidak dapat diujikan tetapi dapat ditinjau ulang untuk ketepatan (correctness) dan konsistensinya (consistency).


2

•

Ketepatan (correctness) model OOA dan OOD

Syntactic

Ditetapkan dengan memastikan bahwa keperluan pemodelan dan konvensi simbolisme telah digunakan

•

Semantic

Berdasarkan pada ketepatan model dengan sumber masalah di dunia nyata

Konsistensi (Consistency) model OOA dan OOD 1. Menilai model CRC (classresponsibility-collaborator) dan diagram hubungan antar obyek. 2. Meninjau desain sistem (memeriksa model perilaku objek untuk memeriksa pemetaan perilaku sistem ke subsystems, meninjau konkuresi dan alokasi tugas, menggunakan skenario use-case untuk memeriksa desain antarmuka pengguna) 3. Model Obyek test terhadap jaringan relasi objek untuk memastikan bahwa semua desain objek berisi atribut dan operasi yang diperlukan untuk melaksanakan kolaborasi yang ditetapkan untuk setiap kartu CRC. 4. Periksa rincian spesifikasi algoritma yang digunakan untuk melaksanakan operasi konvensional menggunakan teknik inspeksi

Strategi Ujicoba Berorientasi Objek (Object-Oriented Testing Strategies) A) Unit testing dalam konteks OO 1. Unit terkecil yang diujikan adalah enkapsulasi class atau objek 2. Hampir serupa dengan ujicoba sistem pada software konvensional 3. Tidak menguji operasi dalam isolasinya dengan operasi yang lain 4. Dijalankan oleh operasi class dan perilaku tetap, bukan detail algoritmik dan aliran data yang melintasi antar interface modul 5. Ujicoba lengkap keseluruhan class meliputi : - Menguji seluruh operasi yang berhubungan dengan objek - Mengatur dan interogasi semua atribut obyek - Melatih objek dalam semua kemungkinan 6. Mendesain ujicoba untuk class dengan menggunakan metode yang benar - Ujicoba berbasis kesalahan (fault-based testing) - Ujicoba acak (random testing) - Ujicoba Partisi (partition testing) 7. Setiap metode-metode ini akan melatih operasi yang dienkapsulapsi oleh class 8. Urutan ujicoba didesain untuk memastikan bahwa operasi yang relevan telah diujicobakan 9. Posisi tetap suatu class (Nilai atributnya) di uji untuk menentukan apakah terdapat kesalahan B) Integration testing dalam konteks OO 1. difokuskan pada kelompok-kelompok kelas yang berkolaborasi atau berkomunikasi dalam beberapa cara. 2. Integrasi operasi satu per satu ke dalam kelas sering sia-sia


3

3. Ujicoba berbasis thread (uji semua kelas yang dibutuhkan untuk merespon ke satu masukan atau event sistem) 4. Pengujian berbasis Kegunaan (dimulai dengan uji independen oleh kelas pertama dan kelaskelas yang tergantung yang menggunakannya) 5. Pengujian cluster (kerjasama kelompok kelas yang diuji untuk interaksi kesalahan) 6. Pengujian regresi adalah penting karena setiap thread, cluster, atau subsistem yang ditambahkan pada sistem 7. Tingkat integrasi yang lebih sedikit berbeda dalam sistem berorientasi objek C) Validation testing dalam konteks OO 1. Berfokus pada tindakan pengguna yang terlihat dan pengguna dapat mengenali output dari sistem 2. tes validasi didasarkan pada skenario use-case, model perilaku objek, dan diagram alur event dibuat dalam model OOA 3. Pengujian Black box konvensional dapat digunakan untuk mendorong tes validasi Test Case Design untuk software OO 1. Setiap kasus uji harus dapat diidentifikassikan secara unik dan secara eksplisit dihubungkan dengan class yang akan diujikan 2. Tetapkan kegunaan dari setiap ujicoba 3. Tuliskan langkah-langkah ujicoba untuk setiap ujicoba yang disertakan, diantaranya: • Tuliskan tahapan ujicoba untuk setiap objek yang disertakan dalam ujicoba • Tuliskan pesan-pesan dan operasi yang dijalankan sebagai konsekuensi dari ujicoba ini • Tuliskan eksepsi yang muncul ketika suatu objek di ujicoba • Tuliskan kondisi eksternal yang memerlukan perubahan untuk ujicoba tersebut • Informasi tambahan lainnya yang diperlukan untuk memahami atau mengimplementasikan ujicoba tersebut. 4. Ujicoba Struktur permukaan dan Struktur Dalam (Testing Surface Structure and Deep Structure) • Ujicoba struktur permukaan (Testing surface structure) yaitu melatih struktur yang tampak oleh pengguna akhir, sering kali melibatkan pengamatan dan mewawancarai pengguna karena mereka memanipulasi objek sistem. • Ujicoba struktur dalam (Testing deep structure) yaitu melatih struktur program internal, seperti ketergantungan, perilaku, dan mekanisme komunikasi yang ada sebagai bagian dari sistem dan desain objek. Metode Testing yang Dapat diaplikasikan pada Tingkatan Class (Testing Methods Applicable at The Class Level) A) Random testing – memerlukan sejumlah besar permutasi dan kombinasi data, dan dapat menjadi tidak efisien • Identifikasikan operasi yang mungkin pada class • Definisikan batasan penggunaannya • Identifikasikan urutan ujicoba minimum • Buatlah beberapa variasi urutan ujicoba random B) Partition testing – Menghilangkan sejumlah kasus uji yang dibutuhkan untuk menguji sebuah class • state-based partitioning – ujicoba didesain dalam suatu cara sehingga operasi yang menyebabkan perubahan state diujikan secara terpisah dari yang tidak. • attribute-based partitioning – untuk setiap atribut class, operasi diklasifikasikan berdasarkan pengguna atribut tersebut, yang memodifikasi atribut dan yang tidak menggunakan atau memodifikasi atribut • category-based partitioning – operasi dikategorikan berdasarkan fungsi yang dilakukannya, seperti : inisialisasi, komputassi, query, terminasi


4

C) Fault-based testing • Terbaik untuk operasi dan tingkatan class • Menggunakan struktur pewarisan • Pengujian memeriksa model OOA dan menghipotesis sekumpulan kerusakan yang dipahami yang mungkin terjadi dalam pemanggilan operasi dan sambungan pesan, dan membangun kasus uji yang sesuai • Menemukan spesifikasi yang tidak tepat dan kesalahan dalam interaksi subsistem Inter-Class Test Case Design 1. Desain kasus uji menjadi lebih rumit seperti halnya integrasi dari dimulainya sistem OO – menguji kolaborasi antar class 2. Ujicoba class yang beragam, seperti : • Untuk setiap class client menggunakan daftar operator classs untuk men-generate urutan ujicoba random yang mengirimkan pesan ke server class yang lain • Untuk setiap pesan yang di-generate, tentukan class kolaborator dan operator server object yang ditunjuk • Untuk setiap operator server class (dimohon oleh pesan dari client object) tentukan pesan yang dikirimkan • Untuk setiap pesan, tentukan tingkatan operator berikutkan yang memohon dan menggabungkannya kedalam urutan ujicoba 3. Ujicoba yang dihasilkan dari model perilaku • gunakan state transition diagram (STD) sebagai model yang merepresentasikan perilaku dinamis dari suatu class. • Kasus uji harus mencakkup seluruh tahapan STD • breadth first traversal dari state model dapat digunakan (uji satu transisi dalam satu waktu dan hanya membuat kegunaan daari transisi yang diujikan sebelumnya ketika mengujikan transisi yang baru) • Kassus uji juga dapat dihasilkan untuk memastikan bahwa seluruh perilaku untuk class telah diujikan dengan benar Testing Methods Applicable at Inter-Class Level A) Cluster Testing 1. Menitikberatkan pada pengintegrasian dan menguji kelompok objek yang bekerja sama 2. Mengidentifikasi kelompok dengan menggunakan pengetahuan tentang pengoperasian objek dan memiliki sistem yang diterapkan oleh kelompok ini. 3. Pendekatan Cluster Testing o Use-case atau ujicoba skenario  Ujicoba berdasarkan pada interaksi user dengan sistem  Mempunyai keuntungan bahwa fitur ujicoba sistem seperti yang dialami pengguna. o Thread testing – menguji respon sistem terhadap event sebagai pemrosesan thread melalui sistem o Object interaction testing – menguji urutan interaksi objek yang berhenti ketika operasi objek tidak memanggil layanan dari objek lainnya B) Use Case/Scenario-based Testing 1. Berdasarkan pada o use cases o corresponding sequence diagrams 2. Identifikassi skenario dari use-case dan menambahkan hal ini dengan diagram interaksi yang menampilkan objek-objek yang termasuk dalam skenario 3. Konsentrasi pada kebutuhan (fungsional) : o Setiap use case o Setiap perluasan kombinasi perpanjangan penuh(<<extend>>) o Setiap perluasan kombinasi penggunaan penuh(<<uses>>) o Ujicoba normal seperti perilaku Ayuliana/ Testing dan Implementasi/April2011

5

4. Sebuah skenario adalah sebuah alur/path melalui diagram urutan 5. Banyak skenario yang berbeda dapat dihubungkan dengan sebuah diagram urutan 6. Mengggunakan tugas pengguna yang dideskripsikan dalan use-cases dan membangun kasus uji dari tugas-tugas tersebut dan variasinya 7. Menemukan kesalahan yang muncul ketika pengguna berinteraksi dengan software OO 8. Konsentrasi pada apa yang dilakukan oleh fungsinya, bukan apa yang dilakukan oleh produknya 9. Dapat memperoleh nilai kembali yang lebih besar atas usaha dan waktu lebih yang dikeluarkan dalam meninjau ulang use-cases semenjak mereka dibuat, dari pada membuang waktu untuk uji coba use-case OO Test Design Issues 1. Metode White-box testing dapat diaplikasikan pada ujicoba kegunaan program untuk mengimplementasi operasi class tetapi tidak untuk lainnya 2. Metode Black-box testing method sangat tepat untuk ujicoba sistem OO 3. Object-oriented programming menyebabkan kebutuhan tambahan untuk ujicoba, berupa : • class dapat mengandung operasi yang diturunkan dari super classes • subclass dapat mengandung operasi yang didefinisikan ulang daripada diturunkan • seluruh class dihasilkan dari ujicoba class dasar sebelumnya memerlukan ujicoba lanjutan


6

Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)

Recommend Documents