A'NALISIS BERORIENTASI OBJEK

Rekayasa Perangkat Lunak

684

http://cuiwww.unige.ch/OSG/OOinfo/index.html Tutorial 00 yang sangat berguna bagi mereka yang lebih dulu belajar tentang subyek tersebut dapat diperoleh pada:

A'NALISIS BERORIENTASI OBJEK

http://www.soft-design.com/softinfo/objects.html Rangkuman detail mengenai banyak buku mengenai metode 00 pada:

dapat diperoJeh

http://www.amazon.com Bibliografi yang komprehensif dengan referensi ke konsep, metode dan bahasa serta peranti dapat diperoleh pada: http://zgdv.igd.thg.de/papers/se/oop/ Koleksi mengenai kertas putih yang sangat berguna, informasi umum, referensi, dan pointer dapat didapatkan dengan mengunjungi:

Daftar mutakhir mengenai referensi World Wide Web untuk teknologi objek dapat ditemukan pada: !:!!m.J!www.rspa,.COlTl -00000-

ill I

ila sebuah produk atau sistem yang baru akan dibangun, bagaimana kita , menandainya dengan cara yang sesuai dengan rekayasa perangkat lunak OO? Objek-objek apa yang relevan? Bagaimana objek-objek berhubungan satu dengan lainnya? Bagaimana objek-objek bertingkah laku di dalam konteks sistem tersebut? Bagaimana kita menentukan atau memodel suatu masalah sehingga kita dapat menciptakan suatu desain yang efektif?

B

http://www.toa.com

Masing-masing pertanyaan tersebut dijawab di dalarn konteks analisis object-oriented (OOA) - aktivitas teknik pertama yang dilakukan sebagai bagian . dari rekayasa perangkat lunak OOA. OOA didasarkan di dalam serangkaian prinsip dasar yang diperkenalkan pada Bab I I. Ada lima prinsip dasar untuk membangun model analisis, yaitu: (I) domain informasi dimodelkan; (2) fungsi modul digambarkan; (3) tingkah laku model direpresentasikan; (4) model dipartisiuntuk mengekspos detail yang lebih besar; (5) model awal merepresentasikan inti masalah sementara model selanjutnya memberikan detail implementasi. Prinsip terse but menjadi fondasi bagi pendekatan OOA yang disajikan pada bab ini.

!:i

Tujuan OOA adalah menentukan semua kelas (dan hubungan serta tingkah laku yang berkaitan dengannya) yang relevan dengan masalah yang akan dipecahkan' Untukmelakukannya, sejumlah tugas harus dilakukan: . I. 2. 3.

Persyaratan pemakai dasar harus dikomunikasikan di antara pelanggan dan perekayasa perangkat lunak. Kelas-kelas harus diidentifikasi (misalnya, atribut dan metode yang ditentukan). Hirarki kelas harus dispesifikasikan.


686

4. 5. 6.

Hubungan objek-ke-objek (koneksi objek) harus direpresentasikan. Tingkah laku objek dimodelkan. Tugas I sampai 5 diaplikasikan lagi sec~ra iteratif_sampai model s~lesai.

Selain menguji suaturnasalah dengan menggunakan model input-proses-oupuj yang klasiktaliran informasi) atau suatu model yang ditarik secara eksklusif dari struktur informasi hirarkis, OOA memperkenalkan sejumlah konsep baru. Konsepkonsep terse but kelihatan sedikit tidak biasa, tetapi sangat natural. Coad dan Yourdon [COA91] menyinggung masalah ini dengan mengatakan: OOA didasarkan pada konsep yang pertama kali kita pelajari di taman kanak-kanak: objek dan atribut, kelas dan anggota. keseluruhan dan bagian. Mengapa diperlukan waktu yang panjang untuk mengaplikasikan konsep-konsep ini ke analisis dan spesifikasi sistem informasi merupakan teka-teki bagi setiap orang - mungkin kita terlalu sibuk "rnengikuti aliran' selama masa emas analisis terstruktur untuk mernpertimbangkan alternatif-alternatif tersebut. Penting untuk dicatat bahwa tidak ada kesepakatan universal mengenai "konsep" yang berfungsi sebagai dasar bagi OOA, tetapi beberapa gagasan kunci muncul secara berulang-ulang, dan itulah yang akan kita bahas pad a bab ini.

20.1 ANALISIS BERORIENT ASI OBJEK Sasaran OOA adalah mengembangkan sederetan model ya'1g menggambarkan perangkat lunak komputer pada saat perangkat itu bekerja untuk memenuhi serangkaian persyaratan yang ditentukan oleh pelanggan. OOA, seperti metode analisis konvensionallainnya yang digambarkan pada Bab 12, membangun model analisis rnultibagian untuk memenuhi sasaran tersebut. Model analisis menggambarkan informasi, fungsi, dan perilaku dalam konteks elemen model objek yang digarnbarkan pada Bab 19.

20.1.1 Pendekatan Konvensional vs 00 Apakah OOA benar-benar berbeda dengan pendekatan analisis terstruktur yang disajikan pada Bab 12? Meskipun perd~batan terus berlanjut, Fichman dan Kemerer [FIC92] menyinggung pertanyaan berikut: Kita menyimpulkan bahwa pendekatan OOA rnerepresentasikan perubahan radikal pada metodologi berorientasi proses misal analisis terstruktur, tetapi pendekatan OOA hanyalah perubahan inkremental pada metodologi yang berorientasi pada data, rnisal rekayasa informasi. Metodologi yang berorientasi pada proses tidak mernfokuskanperhatiannya pada sifat pewarisan objek selama proses pemodelan. Metodologi tersebut membawa kepada model domain rnasalah yang ortogonal dengan tiga prinsip dasar orientasi objek: enkapsulasi. klasifikasi objek. dan pewarisan.

Allalisis Berorientasi Objek ---

687

Secara lebih sederhana, anal isis terstruktur mengadopsi pandangan input-prosesoutput yang berbeda mengenai persyaratan. Data dipertimbangkan secara terpisah dari proses-proses yang mentransformasi data. Tingkah laku sistem, meskipun penting, cen~e.rung memainkan peran sekunder di dalam an~l~sis ter~truktur. P~ndekatan analisis terstruktur banyak menggunakan dekomposisi fungsional (bagian dari diagram aliran data, Bab 12). Fichman dan Kemerer [FIC92] mengusulkan l l "dimensi pemodelan" yang dapat digunakan untuk membandingkan berbagai metode OOA dan konvensional: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

identiftkasilklasiftkasi entitas' umum ke spesifik dan keseluruhan ke hubungan entitas bagian hubungan entitas lain gambaran atribut entitas partisi model skala besar keadaan dan transisi antar keadaan spesifikasi detail untuk fungsi dekomposisi top-down urutan pemrosesan end-to-end identifikasi pelayanan eksklusif komunikasi entitas (melalui pesan atau event)

Karena banyak variasi untuk analisis terstruktur dan puluhan metode OOA (lihat Subbab 20.1.3) dapat diperoleh, maka sulituntuk mengembangkan perbandingan yang digeneralisasikan di antara dua metode. Tetapi dapat dinyatakan bahwa dimensi pemodelan 8 dan 9 selalu hadir dengan analisis terstruktur dan jarang hadir pada saat OOA digunakan. '

20.1.2 Landskap OOA Popularitas teknologi objek telah membangkitkan puluhan metode OOA2 Masing- ' masing metode memperkenalkan proses untuk analisis produk atau sistem, serangkaian model yang berkembang keluar dari proses itu, dan notasi yang memungkinkan perekayasa perangkat lunak menciptakan masing-masing model dengan cara yang konsisten. Di dalam paragraf berikut disajikan beberapa metode" OOA

Dalam konteks ini, "entitas" mengacu pada suatu objek data (daIarn artianaIisis atau objek (dalarn artian OOA).

terstruktur)

Pembahasan detail mengenai metode ini dan perbedaannya tidak ada pada lingkup buku ini. Pembaca yang tertarik harus mengacu pada Berard [BER92] dan Graharn [GRA94] untuk memperoleh perbandingan detail. Secara umum, metode OOA diidentifikasi dengan menggunakan narna pengembang metode tersebut, bahkan bila metode telah diberi narna atau akronim yang unik.

-

688


yang lebih populer dalam bentuk outline. Maksudnya adalah untuk memberikan gambaran mengenai proses OOA yang telah diusulkan oleh para penulis metode tersebut." Metode Booch. Metode B00ch [B0094] meliputi baik "proses pengembangan mikro' maupun "proses pengembangan rnakro." Tingkat mikro menentukan serangkaian tugas analisis yang diaplikasikan lagi untuk masing-masing langkah pada proses makro. Dengan demikian, pendekatan evolusioner dijaga. Metode Bocch didukung oleh berbagai peranti otomatis. Outline singkat dari proses pengembangan mikro OOA Booch adalah sebagai berikut: •

Identifikasi kelas dan objek. Usulkan objek calon. Lakukan analisis tingkah laku. Identifikasi skenario yang relevan. Tentukan atribut dan operasi untuk masing-masing

•

Indetifikasi semantik dari kelas dan objek.

kelas.

Pilih skenario dan analisis. Tentukan tanggungjawab untuk mencapai tingkah laku yang diinginkan. Bagikan tanggungjawab untuk menyeimbangkan tingkah laku. Tentukan objek dan sebutkan tugas dan tanggung jawabnya satu per satu. Tentukan operasi untuk memenuhi tanggungjawab. Carilah kolaberasi di antara objek. •

• • • •

identifikasi objek dengan menggunakan kriteria "apa y,ang dicari". Tentukan struktur generalisasi-spesifikasi. Tentukan struktur keseluruhan-bagian. Identifikasi subjek (representasi dari komponen subsistern).

• •

Tentukan atribut. Tentukan pelayanan.

Metode Jacobson. Disebut juga OOSE (rekayasa perangkat lunak berorientasi objek), metode Jacobson [JAC92] versi sederhana dari metode Objectory sebelumnya, yang juga dikembangkan oleh Jacobson. Metode ini dibedakan dari metode yang lain karena sangat menekankan use case - deskripsi atau skenario yang menggambarkan bagaimana pemakai berinteraksi dengan produk atau sistem. Outline' singkat mengenai proses OOA Jacobson adalah sebagai berikut: •

Identifikasi pernakai sistem dan seluruh tanggllngjawab

•

Bangun model persyaratan.

Lakukan sederetan penyaringan.

Implementasikan kelas dan objek (dalam konteks kasikan pelengkapan model analisis).

mereka.

Tentukan aktor dan tanggungjawab mereka. Identifikasi use case untuk setiap tingkah laku. Persiapkan pandangan awal mengenai objek dan hubungan sistem. Kaji model dengan menggunakan use case sebagai skenario untuk menentukan vasilitas.

Hasilkan diagramyang sesuai untuk kerja yang dilakukan di atas. Tentukan hirarki kelas yang sesuai. Lakukan pengklusteran berdasarkan kelaziman kelas. •

Objek

N rasi pemodelan relatif sederhana dan pedoman untuk mengembangkan model :liSis tersebut adalah jelas. Outline singkat mengenai proses OOA Coad dan an . b ik yourdon adalah sebagal en ut:

Identifikasi hubungan di antara keIas dan objek. Tentukan ketergantungan yang ada di antara objek. Deskripsikan peran masing-masing objek yang berpartisipasi. Validasi dengan berjalan melewati skenario.

•

689 ~rientasi

OOA, hal ini mengimpli-

Metode Coad dan Yourdon. Metode Coad dan Yourdon [COA9I] sering dianggap sebagai salah satu dari metode OOA yang paling mudah untuk dipelajari.

•

Bangun model analisis. Identifikasi objek interface dengan menggunakan informasi interaksi aktor. Ciptakan pandangan struktural mengenai objek interface. Representasikan tingkah laku objek. Isolasi subsistem dan model untuk masing-masing. Kaji model dengan menggunakan use case seperti skenario untuk menentukan validitas.

Metode Rambough. Rambaugh [RAM91] dan rekan-rekannya mengembangkan Object Modelling Technique [OMT] menggunakan. desain sistem, dan desain tingkat objek. Aktivitas analisis menciptakan tiga model: model objek (representasi objek, kelas, hirarki, dan hubungan), model dinamis (representasi dari objek dan tingkah laku sistern), dan model fungsional (representasi aliran informasi seperti DFD tingkat tinggi melalui sistem tersebut). Outline singkat mengenai proses OOA Rambaugh adalah sebagai berikut:

Arti dari banyak langkah yang dioutline pada gambaran proses yang berikut akan dibahas pad a Subbab 20.3 dan 20.4. Perlu dicatat bahwa masing-masing dari metode ini juga merniliki kornponen desain yang akan dibahas secara singkat pada Bab 21.

691 690


AnaliSiS Berorientasi Objek

~ • •

Kembangkan pernyataan Bangun model objek.

pereka

ruang lingkup masalah.

yasa

berikut: • Cari persyaratan

Identifikasi kelas yang relevan untuk masalah tersebut. Tentukan atribut dan asosiasi. Tentukan link objek. Organisasikan kelas objek dengan menggunakan pewarisan. •

Kembangkan

untuk sistem tersebut.

Identifikasi input dan output. Gunakan diagram aliran data untuk merepresentasikan transformasi Kembangkan PSPEC (Bab 12) untuk masing-masing fungsi. Tentukan batasan dan kriteria optimasi.

aliran.

Metode Wirfs-Brock. Metode Wirfs-Brock [WIR90] tidak membuat perbedaan yang jelas antara analisis dan tugas desain, malahan mengusulkan proses kontinu mulai dengan penilaian terhadap spesifikasi pelanggan dan berakhir dengan desain. Outline singkat mengenai tugas yang berhubungan dengan analisis Wirfs-Brock adalah sebagai berikut:

• •

• • • •

Evaluasi spesifikasi pelanggan. Gunakan uraian gramatikal untuk mengeksrak kelas calon dari spesifikasi terse but. . Kelompokkan kelas dengan tujuan untuk mengidentifikasi superkelas. Tentukan tanggungjawab untuk masing-rnasing kelas. Identifikasi hubungan antar kelas. Tentukan kolaborasi di antara kelas berdasarkan tanggungjawab. Bangun representasi hirarki kelas untuk memperlihatkan hubungan pewarisan. Bangunlah grafik kolaborasi untuk sistem.

Meskipun tenninologi berbeda, keseluruhan

generik

sebagai

dasar

sebagai

pelanggan untuk sistem OOA.

Pilih kelas

dan

objek

dengan

menggunakan

persyaratan

• • • • •

panduan. Identifikasi atribut dan operasi untuk masing-masing objek sistem. Tentukan struktur dan hirarki yang mengorganisasi kelas. Bangun suatu model hubungan objek. Bangun suatu model tingkah laku objek. Kaji model analisis 00 terhadap use case skenario.

20.2 ANALISIS DOMAIN

Perlu dicatat bahwa kerja mulai menggabungkan metode Booch dan Rambaugh. Himpunan resultan dari notasi dan heuristik, yang disebut juga Unified Methode ([B0096], [LOC96]) menggabungkan penekanan data Rambaugh yang kuat dengan tingkah laku dan tekanan operasional dari Booch.

• •

langkah-Iangkah

•

model dinamis.

Buatlah model fungsional

lunak harus melakukan

Identifikasi skenario atau use case. Bangun suatu model persyaratan.

Siapkan skenario. Tentukan event dan kembangkan penelusuran event untuk masing-masing skenario. Buatlah diagram aliran event. Kembangkan diagram keadaan. Kajilah tingkah laku untuk konsistensi dan kelengkapannya. •

perangkat

dan langkah proses untuk masing-masing metode OOA ini proses OOA benar-benar mirip. Untuk melakukan OOA,

Analisis untuk sistem berorientasi objek dapat terjadi pada berbagai tingkat abstraksi yang berbeda. Pad a tingkat bisnis atau hiburan, teknik yang sesuai dengan OOA dapat dirangkai dengan pendekatan rekayasa informasi (Bab 10) di dalam usaha untuk menentukan kelas, objek, hubungan, dan tingkah laku yang rnernodel keseluruhan bisnis. Tingkat OOA ini analog dengan perencanaan strategi informasi. Pada tingkat area bisnis, model objek yang menggambarkan pekerjaan dari area bisnis tertentu (atau kategori produk atau sistem) dapat ditentukan. Pada tingkat aplikasi, model objek berfokus pada persyaratan pelanggan yang spesifik karena persyaratan mempengaruhi aplikasi yang akan dibangun. OOA pada tingkat abstraksi tertinggi (tingkat enterprise) di luar lingkup buku ini. Pembaca yang tertarik harus melihat [DEU921, {MAT94], SUL94] dan [TA Y95] untuk memperoleh pembahasan yang lebih lengkap. OOA pada tingkat abstraksi terendah ada pada bidang umum rekayasa perangkat lunak berorientasi objek dan merupakan fokus dari semua bagian lain bab ini. Pada bagian ini kita menekankan OOA yang dilakukan pad a tingkat abstraksi tengah. Aktivitas ini, yang disebut analisis domain, dilakukan bila suatu organisasi ingin menciptakan suatu pustaka (komponen) kelas reusabel yang akan dapat diaplikasikan secara luas ke keseluruhan

kategori aplikasi.

20.2.1 Reuse dan Analisis Domain Teknologi objek dibangkitkan dari reuse. Perhatikan satu contoh sederhana. Analisis persyaratan untuk suatu aplikasi yang baru menunjukkan bahwa dibutuhkan 100 kelas. Dua tim diberi tugas untuk membangun aplikasi terse but. Masing-


692

masing akan mendesain dan membangun suatu produk akhir. Masing-masing dihuni oleh manusia dengan tingkat keahlian dan pengalaman yang sama. Tim A tidak memiliki akses ke suatu pustaka kelas, sehingga dia harus mengembangkan 100 kelas tersebut semuanya dari goresan kecil. Tim B menggunakan suatu pustaka kelas yang kuat dan menemukan bahwa 55 kelas telah ada. Sangat mungkin bahwa: I. 2. 3.

Tim B akan menyelesaikan proyek tersebutjauh lebih cepat daripada tim A. Biaya produk tim B akan jauh lebih rendah daripada biaya produk tim A. Produk yang diproduksi oleh tim B akan memiliki cacat lebih sedikit daripada produk tim A.

Meskipun marjin yang melaluinya kerja tim B akan melampaui pencapaian tim A dapat menjadi perdebatan, beberapa akan berpendapat bahwa reuse yang diberikan tim B akan sangat menguntungkan.

perangkat lunak. Dengan suatu cara, peran analisis domain sama dengan peran too/smith master pada lingkungan pemanufakturan berat. Pekerjaan toolsmith adalah mendesain dan membangun peranti yang dapat digunakan oleh banyak orang yang melakukan pekerjaan yang sama tetapi tidak sama benar. Peran analisis domain adalah mendesain dan membangun komponen reusabel yang dapat digunakan oleh banyak orang yang bekerja pada aplikasi yang sama tetapi tidak benar-benar sama. Gambar 20.1 [ARA89] menggambarkan input dan output kunci untuk proses analisis domain. Sumber pengetahuan domain diselidiki untuk mengidentifikasi objek yang dapat digunakan lagi pada domain tersebut. Secara mendasar, analisis domain sangat mirip dengan rekayasa pengetahuan. Perekayasa pengetahuan meneliti suatu area spesifik suatu interes untuk mengekstrak fakta kunci yang dapat digunakan di dalam menciptakan suatu sistem pakar atau jaringan saraf tiruan. Selama anal isis domain, terjadi ekstraksi objek (dan kelas).

Tetapi dari mana "pustaka kelas yang kuat" berasal? Oar. bagaimana entri di dalam pustaka tersebut ditentukan untuk digunakan sesuai dengan aplikasi yang baru? Untuk menjawab pertanyaan tersebut, organisasi yang menciptakan dan memelihara pustaka tersebut harus mengaplikasikan analisis domain.

literatur teknis aplikasi Sumber Pengetahuan

20.2.2 Proses Analisis Domain Firesmith [FIR93] mengambarkan sebagai berikut:

Domain

analisis domain perangkat lunak dengan cara

Analisis domain perangkat lunak adalah identifikasi. analisis. dan spesifikasi dari persyaratan umum suatu domain aplikasi spesifik. yang secara khas digunakan pada proyek bertingkat pada domain aplikasi itu ... Analisis domain berorientasi objek adalah identifikasi, analisis. dan spesifikasi kernampuan reusable yang urnurn di dalam suatu domain aplikasi khusus. dalam bentuk objek umurn, kelas. subassembly. dan kerangka kerja ....

"Domain aplikasi spesifik" dapat terentang dari avionik ke perbankan, dari multimedia video game ke aplikasi pada scanner CAT. Tujuan analisis utama adalah: menemukan atau membuat kelas-kelas yang: dapat diaplikasikan secara luas, sehingga mereka dapat digunakan lagi." Dengan menggunakan jargon yang diperkenalkan di bagian sebelumnya dari buku ini, analisis domain dapat dipandang sebagai aktivitas pelindung bagi proses perangkat lunak. Ini berarti analisis domain adalah aktivitas rekayasa perangkat lunak yang sedang beriangsung yang dihubungkan dengan setiap proyek

Teknologi

yang berhubungan

dengan perangkat

lunak reuse dibahas pada Bah 26.

693

Analisis Berorientasi Objek

yang ada

~

survai pelanggan nasehat

teksonomi

Analisis Domain

ahli

persyaratan

saat inl yang akan datang '-

-

r ~

keras

~

standar reuse

.

model lungsional

•

bahasa

~

domain

Model Analisis Domain

~

Gambar 20.1 Input dan output untuk analisis domain. Proses analisis domain dapat ditandai dengan sederetan aktivitas yang dimulai dengan identifikasi domain yang akan diselidiki dan berakhir dengan spesifikasi objek dan kelas yang menandai domain tersebut. Bera,;,d [BER93] mengusulkan aktivitas-aktivitas berikut ini: Tentukan domain yang akan diselidiki. Untuk melakukannya, analis harus lebih dulu mengisolasi area bisnis, atau kategori produk dari kepentingan. Kemudian, baik "item" 00 dan non-OO harus diekstrak. Item 00 meliputi spesifikasi, desain, dan kode untuk kelas apalikasi 00 yang ada; kelas dukungan (misalnya, GUI atau kelas akses database); pustaka komponen produk komersial tertentu yangsiap digunakan tanpa modifikasi (COST) yang relevan dengan domain terse but; dan test case. Item non-OO meliputi aturan, prosedur, rencana, standar, dan pedoman; bagian dari aplikasi non-OO yang ada (tennasuk spesifikasi, desain, dan infonnasi pengujian); metrik; dan perangkat lunak COST non-Oo.

694

Rekayasa PerangkatLunak --~------------Kategorikan item yang diekstrak dari domain tersebut. Item dikumpulkan ke dalam kategori, dan pendefinisian umum dari karakteristik kategori itu ditentukan. Skema klasifikasi untuk kategori tersebut diusulkan, dan konvensi penamaan untuk masing-masing item ditentukan. Bila sesuai, maka hirarki kelas kemudian dibangun.

Kumpulkan sampel representatif dari aplikasi di dalam domain tersebut. Untuk melakukannya, analis harus memastikan bahwa aplikasi memiliki item yang cocok dengan kategori yang telah ditentukan. Berard [BER93] mencatat bahwa se lama tahap awal penggunaan teknologi objek, organisasi perangkat lunak akan memiliki sedikit saja aplikasi 00. Dengan demikian, analisis domain harus "mengidentifikasi objek konseptual (kebalikan dari fisik) pada masing-masing aplikasi [non-OO]." Analisis masing-masing aplikasi pada sampel tersebut. berikut ini ditemui selama analisis domain [BER93]:

Langkah-langkah

• • • •

identifikasi objek reusable calon: tunjukkan alasan mengapa objek diidentifikasi untuk reuse; tentukan adaptasi bagi objek yang juga dapat reusable; perkirakan persentase aplikasi pada domain yang dapat membuat dari objek tersebut; dan

•

identifikasi konfigurasi

objek menurut namanya, dan gunakan (Bab 9) untuk mengontrol mereka.

teknik

reuse

manajemen

Sebagai tambahan, begitu objek diidentifikasi, maka analisis harus memperkirakan berapa persentase aplikasi tipikal yang dapat dibangun dengan menggunakan objek reusable. Kembangkan model analisis untuk objek tersebut. Model analisis akan berfungsi sebagai dasar bagi desain dan konstruksi objek domain. Sebagai tambahan terhadap langkah-langkah tersebut, analis domain harus juga menciptakan serangkaian pedoman reuse dan mengembangkan suatu contoh yang menggambarkan bagaimana objek domain dapat digunakan untuk menciptakan aplikasi baru. Analisis domain adalah aktivitas teknis pertama di dalam disiplin yang lebih luas yang beberapa disebut rekayasa domain (Bab 26). Pada saat suatu domain bisnis, sistern, atau produksi ditentukan untuk menjadi strategi bisnis dalam jangka panjang, maka dapat dilakukan usaha yang kontinu untuk menciptakan pustaka kelas yang kokoh. Tujuannya adalah untuk dapat menciptakan perangkat lunak dalam domain dengan presentasi komponen reusable yang sangat tinggi. Biaya

--

AnalisisBerorientasi

695

Objek

ana lebih rendah. kualitas yang lebih tinggi, dan waktu yang makin pendek untuk ~am~ai di pasar. adalah hal-hal yang diusahakan dalam rekayasa domain.

20.3 KOMPONEN GENERIK DARI MODEL ANALISIS 00 Proses analisis berorientasi objek sesuai dengan konsep dan prinsip analisis dasar yang dibahas pad a Bab 11. Meskipun terminologi, notasi, dan aktivitasnya berbeda dengan metode konvensional, OOA (inti pertamanya) menyinggung sasaran penting yang sama. Rambaugh et.a!. [RAM91] membicarakannya dengan menya-

takan: Analisis berkaitan dengan pemikiran yang teliti. ringkas. dapat dipahami. dan model yang benar dari dunia nyata . Tujuan OOA adalah untuk rnernodelkan dunia nyata sehingga dapat dipaharni. Untuk rnelakukannya. Anda harus rnenguji persyaratan. menganalisis irnplikasinya. dan rnenyatakan kembali. Anda harus lebih dulu mengabstraksikan dunia nyata. dan mengacu detail yang kecil.

Untuk mengembangkan model yang "teliti, ringkas, dan dapat dipaharni, serta benar mengenai dunia nyata." perekayasa perangkat lunak harus memilih salah satu dari sejumlah notasi dan proses OOA. Seperti dibahas pada Subbab 20.1.2, masingmasing metode OOA (dan masih ada puluhan lainnya) memiliki proses yang unik dan notasi yang jelas. Semuanya sesuai dengan serangkaian langkah proses generik (Subbab 20.1.2) dan semuanya memberikan notasi yang mengimplementasi serangkaian komponen generik dari model analisis OOA. Monarchi dan Puhr {MON92] menentukan serangkaian komponen representasional generik yang tampak pada semua model analisis 00A.6 Komponen statis bersifat struktural dan menunjukkan karakteristik yang menjaga keseluruhan kehidupan operasional dari suatu aplikasi. Karakteristik tersebut membedakan satu objek dengan objek lainnya. Komponen dinamis berfokus pada kontrol dan sensitif lerhadap timing dan pemrosesan event. Komponen dinamis menentukan bagaimana satu objek berinteraksi dengan objek-objek lainnya. Komponen berikut ini diidentifikasikan [MON92]: Pandangan statis mengenai kelas-kelas semantik. Taksonomi mengenai kelas khusus diidentifikasi pada Bab 19. Persyaratan dinilai dan kelas-kelas diekstraksi (dan direpresentasikan) sebagai bagian dari model analisis. Kelaskelas itu berlangsung lama pada seluruh kehidupan aplikasi yang ditarik berdasarkan semantik persyaratan pelanggan.

Penulis [MON921 bagaimana mctode

juga memberikan itu mcnyinggung

analisis mengenai komponen-komponen

23 metode ini.

OOA

dan menunjukkan

696


Pandangan statis mengenai atribut. Setiap kelas harus secara eksplisit digambarkan. Atribut-atribut yang berkaitan dengan kelas memberikan deskripsi mengenai kelas serta indikasi pertama mengenai operasi yang relevan dengan kelas terse but. Pandangan statis mengenai hubungan. Objek "dihubungkan" satu dengan yang lainnya dengan berbagai cara. Model analisis harus merepresentasikan hubungan ini sehingga operasi (yang mempengaruhi koneksi ini) dapat diidentifikasi sehingga desain pendekatan pemesanan dapat dilakukan. Pandangan statis mengenai tingkah laku. Hubungan yang ditulis di atas menentukan serangkaian tingkah laku yang mengakomodasi penggunaan skenario (use case) dari sistem. Tingkah laku ini diimplementasi dengan menentukan urutan operasi yang niencapainya. Pandangan dinamis mengenai komunikasi. Objek harus berkomunikasi dengan lainnya dan melakukannya berdasarkan serangkaian event menyebabkan transisi dari satu keadaan sistem ke sistem lainnya.

satu yang

Pandangan dinamis mengenai kontrol dan waktu. Sifat dan timing event yang menyebabkan transisi di antara keadaan harus digambarkan.

dari

Seperti diperlihatkan pada Gambar 20.2. de Champaux dan rekan-rekannya [CHA93] menentukan pandangan yang sangat berbeda dari representasi OOA. Komponen statis dan dinamis diidentifikasi untuk objek internal dan untuk representasi inter-objek. Pandangan dinamis mengenai objek internal dapat dikarak-terisasi sebagai sejarah kehidupan objek, yaitu keadaan objek dari waktu ke waktu pacta saat berbagai operasi dilakukan terhadap atributnya .. internal objek

,

komponen objek

kelas atribut operasi

komponen dinamis

sejarah hidup objek

Gambar

representasi inter-objek hubungan objek keadaan transisi

komunikasi timing

20.2 Representasi OOA [CHA93}.

20.4 PROSES OOA Proses OOA tidak dimulai dengan suatu pemikiran mengenai objek. melainkan dengan memahami cara sistem akan digunakan - oleh manusia, bila sistem adalah human-interactive; oleh mesin, bila sistem dilibatkan di dalam kontrol proses; atau


oleh program yang lain, bila sistem berkoordinasi skenario kegunaan didefinisikan, maka pemodelan

697

dan mengontrol aplikasi. Sekali perangkat lunak dimulai.

Subbab berikut menentukan sederetan teknik yang dapat digunakan untuk mengumpulkan persyaratan pelanggan dasar dan kernudian menentukan model analisis untuk sistem berorientasi objek.

20.4.1 Use Case Pengumpulan persyaratan selalu merupakan langkah pertama pada setiap aktivitas analisis perangkat lunak. Seperti dibahas pada Bab 11, pengumpulan persyaratan dapat berbentuk pertemuan FAST di mana pelanggan dan pengembang bertemu untuk menentukan sistem dasar dan persyaratan perangkat lunak. Berdasarkan persyaratan tersebut. perekayasa perangkat lunak (anal is) dapat menciptakan serangkaian skenario yang masing-masing mengidentifikasi urutan pemakaian bagi sistem yang akan dibangun. Skenario tersebut, yang sering disebut use case [JAC92], memberikan deskripsi mengenai bagaimana sistem akan digunakan. Untuk membuat use case, analis lebih dulu harus mengidentifikasi tipe manusia (atau perangkat) yang berbeda yang menggunakan sistem atau produk tersebut. Aktor-aktor tersebut merepresentasikan peran yang dimainkan oleh manusia (atau perangkat pada saat sistem beroperasi). Bila didefinisikan secara lebih formal, aktor adalah sesuatu yang berkomunikasi dengan sistem atau produk dan eksternal terhadap sistem itu sendiri. Penting untuk dicatat bahwa aktor dan pemakai tidak sama. Pemakai tertentu dapat memainkan sejumlah peranan yang berbeda pada saat menggunakan suatu sistem, sedangkan aktor merepresentasikan suatu kelas dari entitas eksternal (sering, tapi tidak selalu manusia) yang hanya memainkan satu peran saja. Sebagai contoh, perhatikan operator mesin (seorang pemakai) yang berinteraksi dengan komputer kontrol untuk sel pemanufakturan yang berisi sejumlah robot dan mesin yang dikontrol secara numerik. Setelah melalui kajian persyaratan yang cermat, perangkat lunak untuk komputer kontrol tersebut mernbutuhkan 4 mode yang berbeda (peran) untuk interaksi: mode pemrograman, mode pengujian. mode monitoring, dan mode troubleshooting. Dengan demikian, keernpat aktor itu dapat didefinisikan: pemrogram, penguji (tester), monitor, dan troubleshooter. Dalam beberapa kasus, operator mesin dapat memainkan semua peran terse but. Pada-kasus lainnya, manusia yang berbeda dapat memainkan peran masing-masing aktor. Seperti aspek model analisis 00 lainnya, tidak semua aktor diidentifikasi selama iterasi pertama. Dimungkinkan untuk mengidentifikasi aktor primer (primary actor) [JAC92] se lama iterasi pertama dan aktor sekunder sehubungan dengan lebih banyaknya yang dipelajari mengenai sistem tersebut. Aktor-aktor primer berinteraksi untuk mencapai fungsi sistem yang diperlukan dan mernper-


698

oleh manfaat yang diharapkan dari sistem tersebut. Mereka bekerja secara langsung dan sering dengan perangkat lunak. Aktor-aktor sekunder ada untuk mendukung sistem sehingga aktor primer dapat melakukan tugas mereka. Begitu aktor-aktor telah diidentifikasi, use case dapat dikembangkan. Use case menggambarkan cara di mana aktor berinteraksi dengan sistem. Jacobson {JAC92] mengajukan sejumlah pertanyaan yang harus dijawab oleh use case:

3.

• •

4.

• • •

Apakah tugas atau fungsi utama yang dilakukan oleh aktor? Sistem informasi apakah yang akan didapat atau diperoleh, dihasilkan, atau diubah oleh aktor? Haruskah aktor memberi tahu sistem mengenai perubahan di dalam lingkungan ekstemal? lnformasi apa yang diinginkan oleh aktor dari sistem tersebut? Apakah aktor ingin diberi tahu mengenai perubahan-perubahan yang tidak diharapkan?

Secara umum, use case secara sederhana merupakan narasi tertulis yang menggambarkan peran aktor pada saat berinteraksi dengan sistem. Sistem keamanan Safe Home, yang dibahas pada bab-bab sebelumnya, dapat digunakan untuk menggambarkan bagaimana use case dapat dikembangkan. Dengan melihat lagi persyaratan Safe Home dasar, kita dapat menentukan 3 aktor: pemilik rumah (user), sensor (perangkat yang dilampirkan ke sistem), dan monitoring serta subsistem respon (stasiun pusat yang memonitor Safel-lome), Untuk tujuan contoh ini, kita hanya akan memperhatikan aktor pemilik rumah (homeowner). Pemilik rumah berinteraksi dengan produk dalam sejumlah cara yang berbeda: • • • • •

Menginput password untuk mengijinkan semua interaksi yang lain Pengamatan mengenai status zone keamanan Pengamatan mengenai status suatu sensor Menekan tombol panik dalam suatu keadaan darurat Aktifasi/deaktifasi sistem keamanan

Use case untuk aktifasi sistem adalah sebagai berikut: I.

2.

Pemilik rumah mengamati kontrol panel Safel-lome (Gambar 11.4) untuk menentukan apakah sistem siap menerima input. Bila sistem tidak siap (not ready), pemilik rumah harus menutup jendela/pintu secara fisik sehingga muncul indikator siap. (lndikator tidak siap mengimplikasikan bahwa sensor terbuka, misalnya pintu atau jendela terbuka.) Pemilik rumah menggunakan keyboard untuk mengunci dengan password 4 digit. Password tersebut dibandingkan dengan password yang berlaku yang

699


disimpan di dalam sistem. Bila password salah, kontrol panel akan mengeluarkan bunyi (beep) satu kali dan mereset dirinya sendiri untuk input tambahan. Bila password betul, kontrol panel menunggu aksi selanjutnya. Pemilik rumah memilih dan mengunci dalam stay atau away (lihat Gambar 11.4) untuk mengaktifasi sistem. Stay hanya mengaktifasi sensor perimeter (sensor yang mendeteksi gerakan di dalam dideaktifasi). Away mengaktifasi semua sensor. Bila aktifasi terjadi, lainpu alarm merah dapat dilihat oleh pemilik rumah.

Use case untuk interaksi pemilik rumah yang lain akan dikembangkan dengan cara yang mirip. Penting untuk dicatat bahwa masing-masing use case harus dikaji secara cermat. Bila beberapa elemen interaksi memiliki ambiguitas, mungkin kajian use case akan mengindikasikan masalah. Masing-masing use case memberikan skenario interaksi yang tidak mengandung ambiguitas antara aktor dan perangkat lunak. Use case juga dapat digunakan untuk menentukan persyaratan timing atau batasan lain. Contohnya, pada use case yang ditulis di atas, persyaratan menunjukkan bahwa aktifasi terjadi 30 detik setelah kunci stay atau away ditekan. Informasi itu dapat dilampirkan untuk use case. . Use case akan dirasakan secara berbeda oleh aktor yang berbeda. Wyder [WYD96] menghimbau agar penyebaran fungsi kualitas (QFD/ dapat digunakan untuk mengembangkan nilai prioritas yang dibebankan bagi masing-masing use case. Untuk melakukannya, use case dievaluasi dari titik pandang semua aktor yang ditentukan untuk sistem tersebut. Nilai prioritas diberikan ke masing-masing use case (misalnya nilai dari I sampai 10) oleh masing-masing aktor." Kemudian prioritas rata-rata dihitung, yang menunjukkan kepentingan yang dirasakan dari masing-masing use case. Pada saat model proses iteratif atau inkremental digunakan pada rekayasa perangkat lunak berorientasi objek, prioritas-prioritas tersebut dapat mempengaruhi fungsionalitas sistem yang disampaikan pertama kali.

20.4.2 Pemodelan Kelas- Tanggung jawab-Kolaborator Begitu skenario pemakaian dasar telah dikembangkan untuk sistern, maka saat itulah waktunya lIntukmengidentifikasi kelas-kelas calon, dan rnenunjukkan tanggung jawab serta kolaborasi mereka. Pemodelan kelas=-tanggung jawabkolaborator (eRC) [WIR90] memberikan cara sederhana untuk mengidentifikasi

QFD dibahas secara singkat pada Bab 11. Idealnya evaluasi ini dilakukan oleh seorang aktor.

oleh individu

dari organisasi

atau fungsi bisnis yang diwakilkan


700

dan mengumpulkan kelas-kelas yang relevan dengan persyaratan produk atau sistem. Ambler [AMB95] menggambarkan pemodelan eRe dengan cara berikut: Model CRC merupakan sekumpulan kartu indeks standar yang merepresentasikan kelas. Kartu tersebut dibagi menjadi 3 bagian. Sepanjang puncak kartu Anda menulis nama kelas. Pada badan kartu, Anda menulis daftar tanggung jawab kelas di sebelah kiri dan kolaborator di sebelah kanan.

Pada dasarnya, model eRe dapat menggunakan kartu indeks virtual atau aktual. Maksudnya adalah untuk mengembangkan representasi kelas yang terorganisasi. Tanggung jawab adalah atribut dan operasi yang relevan untuk kelas. Pendeknya, tanggung jawab adalah "sesuatu yang diketahui atau dilakukan oleh kelas" [AMB95]. Kolaborator adalah kelas-kelas yang diperlukan untuk memberikan informasi yang dibutuhkan yang diperlukan oleh kelas untuk menyelesaikan tanggung jawab. Secara umum, kolaborasi mengimplikasikan permintaan informasi atau permintaan beberapa aksi.

Kelas Pedoman dasar untukrnengindentifikasi kelas dan objek disajikan pada Bab 19. Ringkasnya, objek memanifestasi dirinya di dalam berbagai bentuk (Subbab 19.3.1.): entitas ekstemal, benda, peristiwa atau kejadian, peran, unit organisasi, tempat, atau struktur. Teknik untuk mengidentifikasi hal tersebut dalam konteks masalah perangkat lunak adalah dengan melakukan uraian gramatikal pada narasi pernrosesan untuk sistem tersebut. Semua kata benda menjadi objek potensial. Tetapi tidak setiap objek potensial membuat potongan. Enam karakteristik pemilihan ditentukan pada Bab 19. Informasi yang disimpan, layanan yang dibutuhkan, atribut bertingkat, atribut umum, operasi umum, dan persyaratan dasar. Objek potensial harus memenuhi keenam karakteristik pemilihan tersebut bila objek akan dipertimbangkan untuk dimasukkan dalam model eRe


701

Sehagai tambahan, objek dan kelas dapat dikategorikan oleh karakteristik: Tangibilitas. Apakah kelas merepresentasikan suatu hal yang dapat dilihat (misalnya, keyboard atau sensor), atau apakah merepresentasikan informasi yang lebih abstrak (misalnya, hasil akhir yang diprediksi)? IncIusiveness. Apakah kelas atomic (kelas tidak memasukkan kelas-kelas lainnya) atau agregate (memasukkan paling tidak satu objek tersarang)? Sekuensial. Apakah kelas konkuren (memiliki urutan kontrol sendiri) atau sekuensial (dikontrol oleh sumber dari luar)? Persistence. Apakah kelas transient (dibuat dan dihilangkan selama operasi program); temporqry (diciptakan selama operasi program dan dihilangkan begitu program terhenti); atau permanent (disimpan di dalam suatu database)? Integritas. Apakah kelas dapat disuap (tidak melindungi sumber dayanya dari pengaruh luar) atau terjaga (kelas memaksa kontrol pada akses ke sumber dayanya)? Dengan menggunakan kategori kelas terse but, "kartu indeks" yang dibuat sebagai bagian dari model eRe dapat diperluas untuk mencakup tipe kelas dan karakteristiknya (Gambar 20.3.). name kelass tipe

kelas

(mise I

perangkat, properti, peran, event, ... )

karakteristik ketas: (misa! dapat dilihat, atomik, konkuren, ... ) tanggung jawab

Firusmith {FIR93] memperluas taksonomi tipe kelas yang ditulis di atas dengan mengusulkan tambahan-tambahan berikut: Kelas-kelas perangkat. Entitas eksternal model seperti sensor, motor, dan keyboard. Gambar 20.3 Kartu indeks model

eRe.

Kelas-kelas properti. Merepresentasikan berbagai properti penting dari lingkungan masalah (misalnya, rating kredit dalam konteks aplikasi pinjaman hipotek).

Tanggungjawab

Kelas-kelas interaksi. Memodelkan interaksi yang terjadi di antara objekobjek lain (misalnya, ijin atau pembelian).

Pedoman dasar pendefmisian tanggung jawab.(atribut dan operasi) juga disajikan pada Bab 19. Untuk ringkasnya, atribut merepresentasikan bentuk kelas yang stabil, yaitu informasi tentang kelas yang harus disimpan untuk mencapai sasaran perangkat lunak yang ditentukan oleh pelanggan. Atribut dapat sering diekstrak

702


dari statemen ruang lingkup atau dilihat dari pemahaman sifat kelas. Operasi dapat diekstrak dengan melakukan uraian gramatika pad a narasi pemrosesan sistem. Kata kerja menjadi operasi calon. Masing-masing operasi yang dipilih untuk sebuah kelas memperlihatkan tingkah laku kelas tersebut. Wyrfsbrock dan rekan-rekannya [WIR90] mengusulkan untuk mengalokasikan tanggung jawab terhadap kelas: I.

untuk mendefinisikan operasi yang biasanya berlaku bagi superkelas tetapi diimplementasikan secara berbeda pada masing-masing subkelas. 3.

4.

Kecerdasan sistem harus didistribusikan secara merata. Setiap aplikasi rneli-

Dengan demikian, kecerdasan sistem harus didistribusikan secara merata pada semua kelas di dalam suatu aplikasi. Karena masing-masing objek mengetahui dan melakukan hanya beberapa hal (yang biasanya difokuskan dengan baik). maka kohesivitas sistem menjadi meningkat. Efek samping sehubungan dengan perubahan cenderung dikurangi karena kecerdasan sistem pada banyak objek telah dirangkai pada banyak objek. Untuk menentukan apakah kecerdasan sistem didistribusikan secara merata, tanggung jawab yang ditulis pada masing-masing kartu indeks model CRC harus dievaluasi untuk menentukan apakah setiap kelas memiliki daftar tanggung jawab yang sangat panjang. Hal ini menunjukkan konsentrasi kecerdasan. Tanggung jawab untuk masing-rnasing kelas jugaharus mernperlihatkan tingkat abstraksi yang sama. Contohnya, di antara operasi yang ditulis untuk kelas agregate yang disebut checking account adalah dua tanggung jawab: Balance-the- account dan check-off-cleared-checks. Operasi yang pertama (tanggung jawab mengimplikasikan prosedur logika dan matematika yang kompleks. Yang kedua merupakan aktivitas administrasi yang sederhana. Karena kedua operasi itu tidak ada pada tingkat abstraksi yang sama, maka check of cleared-checks harus ditempatkan di dalam tanggung jawab checkentry, sebuah kelas yang diliputi oleh kelas agregat checking account. 2. Masing-masing tanggung jawab harus dinyatakan selazim mungkin. Pedoman ini mengimplikasikan bahwa tanggung jawab umum (atribut maupun operas i) harus tinggi di dalam hirarki kelas (karena mereka generik). Mereka akan sesuai dengan semua subkelas. Polimorfisme (Bab 19) juga harusdigunakan

Informasi dan tingkah laku yang sesuai dengannya harus ada pada kelas yang sama. Hal ini memenuhi prinsip 00 yang disebut enkapsulasi (Bab 19). Data

dan proses yang memanipulasi data harus dikemas sebagai sebuah unit yang kohesif.

lima pedoman

puti tingkat kecerdasan tertentu, yaitu apa yang diketahui sistern dan apa yang dapat dilakukannya. Kelas-kelas "DUMB" (yang memiliki sedikit tanggung jawab) dapat dimodel untuk berperan membantu beberapa {elas "pandai' (yang memiliki banyak tanggung jawab). Pendekatan ini membuat aliran kontrol pada suatu sistem menjadijelas, tetapi memilik'i beberapa kelemahan: • mengkonsentrasikan semua kecerdasannya pada beberapa kelas sehingga perubahan menjadi lebih sulit. • cenderung membutuhkan lebih banyak kelas sehingga lebih ban yak usaha pengembangan

703


Informasi mengenai satu hal harus dilokalisir pada sebuah kelas tunggal, tidak didistribusikan pada kelas bertingkat. Kelas tunggal harus melakukan tanggung jawab untuk menyimpan dan memanipulasi tipe informasi spesifik.

Tanggung jawab ini secara umum tidak boleh dipakai bersarna-sarna pada sejumlah kelas. Bila informasi disebarkan, perangkat lunak menjadi lebih sulit dipelihara dan lebih menantang untuk diuji. 5.

Pemakaian bersama tanggung jawab di antara kelas-kelas yang berhubungan, apabila sesuai. Ada beberapa kasus di mana berbagai objek y,\ng

berhubungan semuanya harus memperlihatkan tingkah laku yang sama pada waktu yang sama, Misalnya, kita lihat sebuah video game yang menampilkan objek-objek berikut: Player, player-body, player-arms, player-head. Masingmasing objek memiliki atribut sendiri-sendiri (misalnya posisi, orientasi, warna, kecepatan), dan semuanya harus diperbarui dan ditampilkan pad a saat pemakai memanipulasi sebuah joy stik. Tanggung jawab update dan display harus dipakai bersama-sama oleh masing-masing objek. Player mengetahui kapan sesuatu telah berubah dan update diperlukan. Dia bekerja sama dengan objek-objek lain untuk mencapai suatu atau orientasi yang baru, tetapi masingmasing objek mengontrol tampilannya sendiri. Kolaborator

Kelas-kelas memenuhi tanggung jawab mereka dengan salah satu dari kedua cara. (I) Kelas dapat menggunakan operasinya sendiri untuk memanipulasi atributnya sendiri, sehingga memenuhi suatu tanggung jawab tertentu, atau (2) Kelas dapat bekerja sama dengan kelas-kelas lain. Wirfs-Brock [WIR90] dan rekan-rekannya dengan cara sebagai berikut:

mendefinisikan

kolaborasi

Kolaborasi merepresentasikan pennintaan dari suatu client ke suatu server di dalam pemenuhan tanggungjawab client. Kolaborasi adalah bentukan dari kontrak antara client dan server .... Kita katakan bahwa suatu objek berkolaborasi dengan objek lain bila untuk memenuhi tanggung jawab. dia perlu mengirim pesan ke objek lain. Kolaborasi tunggal mengalir dalam satu arah - yang merepresentasikan permintaan dari client ke server. Dari titik pandang client. masing-masing kolaborasinya dihubungkan dengan suatu tanggungjawab tertentu yang diimplementasikan oleh server.


704

An~sis Berorientasi Objek

705

Kolaborasi mengidentifikasikan hubungan antarkelas. Bila serangkaian kelas semua berkolaborasi untuk mencapai beberapa persyaratan maka mereka dapat dikumpulkan ke dalam suatu subsistem (masalah desain).

Bila model CRC lengkap telah dikembangkan, maka perwakilan dari pelanggan dan organisasi rekayasa perangkat lunak dapat berjalan melalui model tersebut dengan menggunakan pendekatan berikut [AMB95]:

Kolaborasi diidentifikasi dengan menentukan apakah suatu kelas dapat memenuhi masing-masing tanggung jawabnya sendiri. Jika tidak, maka kelas itu memerlukan interaksi dengan kelas lain. Begitulah kolaborasi.

I.

Sebagai contoh, perhatikan aplikasi Safel-lome." Sebagai bagian dari prosedur aktivasi (Iihat use case untuk aktivasi pad a Subbab 20.4.1). kontrol panel harus mengatur atribut status ke "not ready". Informasi sensor dapat diperoleh dari objek sensor. Dengan demikian, tanggung jawab determiner-sensor-status dapat dipenuhi hanya jika konrtol panel bekerja dalam kolaborasi dengan sensor. Untuk membantu identifikasi kolaborator, analis dapat menguji tiga hubungan generik yang berbeda di antara kelas [WIR90]: (1) hubungan is-part-of, (2) hubungan has-knowledge-of, dan (3) hubungan depend-upon. Dengan menciptakan diagram hubungan kelas (Subbab 20.4.4), analis mengembangkan sambungan yang perlu untuk mengidentifikasi hubungan-hubungan tersebut. Masingmasing dari tiga hubungan generik diperhatikan secara singkat di dalam paragraf berikut. Semua kelas yang merupakan bagian dari kelas gabungan dihubungkan dengan kelas gabungan melalui hubungan is-part-of Kita lihat kelas yang didefinisikan untuk video game yang ditulis sebelurnnya adalah suatu contoh dari hubungan has-knowlegde-of Hubungan depends-upon mengimplikasikan bahwa dua kelas memiliki ketergantungan yang tidak dicapai oleh has-knowledge-of atau is-part-of Contohnya, player head harus selalu dihubungkan ke player-body (jika tidak, video game itu benar-benar keliru), tetapi masing-masing objek dapat ada tanpa pengetahuan langsung dari objek lain. Atribut objek player-head yang disebut centerposition ditentukan dari center-position dari player-body. Informasi ini diperoleh melalui objek ketiga, player, yang mendapatkannya dari player-body. Demikianlah player body bergantung-pada player-body. Dalam semua kasus, nama kelas kolaborator direkam pad a kartu indeks model CRC untuk tanggung jawab yang telah membangkitkan kolaborasi tersebut. Dengan dernikian, kartu indeks berisi daftar mengenai tanggung jawab dan kolaborasi yang sesuai yang memungkinkan tanggungjawab dipenuhi.

" Lihat Subbab 19.3 untuk penggambaran

kelas SafeHornc.

Semua partisipan di dalam kajian (model CRC) diberisebuah subset dari kartu indeks model CRe. Kartu-kartu yang berkolaborasi harus dipisahkan (yaitu, pengkaji tidak boleh memiliki dua kartu yang berkolaborasi). 2. Semua skenario use case harus dikumpulkan ke dalam kategori. 3. Pemimpin kajian membaca use case dengan cermat. Pada saat pemimpin sampai pada suatu objek bernama, dia melewatkan token ke orang yang memegang kartu indeks kelas yang bersesuaian. Misalnya, use case yang ditulis pad a Subbab 20.4.1 berisi narasi sebagai berikut: I. Pemilik rumah mengamati kontrol panel (Gambar 11.4) untuk mencntukan apakah sistem siap rncnerirna input atau tidak, Bila sistern not ready maka pemilik rumah harus secara fisik rnenutup pintu/jendela sehingga indikator siap dihadirkan. Iindikator not ready mengimplikasikan bahwa suatu sensor terbuka, yaitu bahwa pintu atau jendela terbuka.]

Pada saat pemimpin kajian sampai pad a "kontrol panel," pad a narasi use case, token dilewatkan ke orang yang memegang kartu kontrol panel. Frase ini yang "mengirnplikasikan bahwa suatu sensor terbuka" mengharuskan kartu indeks berisi tanggung jawab yang akan memvalidasi implikasi tersebut (tanggung jawab determine-sensor-status melakukan hal ini), Kemudian tanggung jawab pada kartu indeks merupakan sensor kolaborator. Token ini kemudian dilewatkan ke objek sensor. 4.

5.

Pada saat token dilewatkan, pemegang kartu kelas diminta menjelaskan tanggung jawab yang ditulis di dalam kartu tersebut. Kelompok itu menentukan apakah satu tanggung jawab (atau lebih) memenuhi persyaratan use case. Bila tanggung jawab dan kolaborasi yang ada pada kartu indeks tidak dapat mengakomodasi use case, rnodifikasi dibuat untuk kartu tersebut. Modifikasi akan meliputi definisi dari kelas-kelas baru (dan kartu indeks CRC yang sesuai) atau spesifikasi dari tanggung jawab atau kolaborasi yang baru yang sudah direvisi pada kartu yang sudah ada. Modus operandi ini berlanjut sampai use case diselesaikan.

Model CRC adalah representasi pertarna dari model analisis untuk suatu sistem 00. Dia dapat "diuji" dengan melakukan kajian yang dikendalikan oleh use case yang ditarik untuk sistem tersebut.

706


20.4.3 Pendefinisian Struktur dan Hirarki Begitu kelas dan objek sudah diidentifikasi dengan menggunakan model CRC, analis mulai untuk berfokus pada struktur model· kelas dan hirarki resultan yang muncul pada saat kelas dan subkelas muncul. Coad dan Yourdon [COA91] menghirnbau agar generalization-specialization(gen-spec)-structure harus digunakan untuk kelas yang diidentifikasikan. Untuk menggarnbarkannya, perhatikan objek sensor yang ditentukan untuk SafeHome dan diperlihatkan pada Gambar 20.4. Di sini, generalisasi, yakni sensor, disaring ke dalarn serangkaian spesialisasi - entry sensor, smoke sensor, dan motion sensor. Kita sudah menciptakan hirarki kelas sederhana.

controlpanel

707


Dalam kasus lain, objek yang direpresentasikan pada model awal dapat dirangkai dari sejumlah bagian komponen yang dapat ditentukan oleh dirinya sendiri sebagai objek, Objek-objek gabungan ini dapat direpresentasikan sebagai wholepart-structure [COA 9 I] dan ditentukan dengan menggunakan notasi yang direpresentasikan pada Gambar ~0.5. Segitiga tersebut menyatakan sebagai hubungan assembly. Harus dicatat bahwa garis-garis hubungan dapat diperbesar dengan simbol tambahan (tidak diperlihatkan) untuk merepresentasikan kardinalitasnya. Mereka diadaptasi dari notasi pemodelan hubungan entitas yang dibahas pad a Bab 12. Representasi struktur memberikan kepada analis alat untuk mempartisi model CRC dan merepresentasikan partisi itu secara gratis. Perluasan dari masingmasing kelas memberikan detail yang dibutuhkan bagi kajian dan desain subsekuen.

20.4.4 Pendefinisian Subjek dan Subsistem mewakili

.

£Cl ! i __-------.- struktur gen-spec

i

:

mm]

I!

;

!

eypa~ screen

l

':~~~~~.~~.~...~

~

.._...........

~

i).ite

!

.=.:

. .

Gambar 20.4 Notasi struktur gen-spec. ensor

,

= ~

~

, .~,,=,.=

'---.

.c.:: entry sensor

.....

,

•

~/'" )...~/

mewakili struktur whole-part

;mmmmTm-,m-----::=J. smoke sensor

motion sensor

_._-

Model analisis untuk aplikasi kompleks yang kompleks memiliki ratusan kelas dan puluhan struktur. Karena itu perlu untuk menentukan representasi singkat yang merupakan intisari dari model struktur dan CRC yang digambarkan di atas. Bila suatu subset dari semua kelas berkolaborasi di antara mereka sendiri untuk melakukan serangkaian tanggung jawab yang kohesif, mereka sering diacu secara subjek [COA91] atau subsistem [WIR90]. Baik subjek maupun subsistem merupakan abstraksi yang memberikan referensi atau pointer ke model analisis yang lebih detail. Bila dikaji dari luar maka suatu subjek atau subsistem dapat diperlakukan sebagai sebuah kotak hitam (black box) yang berisi serangkaian tanggung jawab dan yang memiliki kolaboratomya sendiri (di luar). Subsistem mengimplementasi satu atau lebih kontrak dengan kolaborator luamya. Kontrak _adalahdaftar permintaan khusus yang dapat dibuat oleh kolaborator dari subsistem tersebut.'?

Subsistem dapat direpresentasikan di dalam konteks pemodelan CRC dengan membuat satu kartu indeks subsistem. Kartu indeks subsistem menunjukkan nama subsistem, kontrak yang harus diakomodasi oleh subsistem, dan kelas atau subsistem (Iainnya) yang mendukung kontrak tersebut. Subjek identik dengan subsistem di dalam tujuan dan isinya, tetapi direpresentasikan secara gratis. Misalnya, kita asumsikan bahwa kontrol panel untuk SafeHome jauh lebih kompleks daripada yang diimplikasikan pada Gambar 20.5,

,,,

Gambar 20.5 Notasi struktur whole-part.

Ingat bahwa ini subsistern

kelas berinteraksi dengan menggunakan suatu filosofi klien/server. rnenjadi server dan kolaborator 11Iar menjadi klien.

Dalam

kasus


708

yang berisi area tampilan bertingkat, pengaturan kunci yang canggih, dan bentukbentuk lainnya. Kontrol panel dapat dimodel seperti struktur whole-part yang diperlihatkan pada Gambar 20.6. Bila model persyaratan keseluruhan berisi puluhan struktur ini (SafeHome tidak akan), maka sulit untuk menyerap seluruh representasi pada satu waktu. Dengan mendefmisikan referensi subjek seperti diperlihatkan pada gambar tersebut, maka keseluruhan struktur dapat direferensi dengan suatu ikon tunggal (persegi panjang). Referensi subjek biasanya dibuat untuk setiap struktur yang memiliki lebih dari lima atau enam objek. Pada tingkat yang paling abstrak, model OOA hanya akan berisi referensi subjek seperti ditunjukkan pada bagian atas Gambar 20.7. Masing-masing referensi ini akan diperluas ke dalam suatu struktur. Struktur-struktur untuk kontrol panel, dan objek sensor (Gambar 20.6 dan 20.4) diilustrasikan; struktur untuk sistem, sensor, kejadian, dan alarm audible juga akan dibuat bila objek-objek itu memerlukan lebih dari lima atau enam klasifikasi atau objek assembly .

. 16, control

r

panel ~

709


Anak panah berkepala ganda yang diperlihatkan pada bagian atas Gambar 20.7 merepresentasikan jalur komunikasi (pesan) di antara objek-objek yang diisikan pada referensi subjek. Hal ini diperoleh sebagai akibat dari aktivitas pemodelan yang dijelaskan pada bagian berikutnya.

20.5 MODEL HUBUNGAN OBJEK Pendekatan pemodelan eRe yang digunakan pada bagian sebelumnya membangun elemen pertama dari hubungan kelas dan objek. Langkah pertama dalam pembangunan hubungan ini adalah untuk memahami tanggungjawab bagi masingmasing kelas. Kartu indeks model' eRe berisi daftar tanggung jawab. Langkah selanjutnya adalah menentukan kelas kolaborator yang membantu melakukan masing-masing tanggungjawab. Hal ini membangun "hubungan" antara kelas.

"'

CJntrol panel

I

\ *

referensi subjek

~·-I--L keys

-

display area

I

lite

--

=m~

keypad

I

I'

11 FRs

L

==

= =

--,-

I

................. 1:=-1 1.,,= Gambar

---

= =

=

20.6 Referensi subjek. Gambar 20.7 Model OOA dengan referensi subjek.

712

1. 2. 3. 4. 5.

Rekayasa Pe rang kat L~ak

Evaluasi sernua use case (Subbab 2004.1) agar dapat benar-benar memahami urutan interaksi di dalam sistem. Identifikasi kejadian yang mengendalikan urutan interaksi serta memahami bagaimana event-event tersebut berhubungan dengan objek spesifik. Lakukan penelusuran event [RAM91] untuk masing-rnasing use case. Membangun diagram state-transition untuk sistem. Mengkaji model tingkah laku objek untuk memverifikasi akurasi dan konsistensi.

Masing-masing

langkah di atas dibahas di bagian-bagian

20.6.1 Identifikasi

selanjutnya.

Event dengan Use Case

Anal

Berorientasi Objek

isis ;..;.---

713

Sebagai contoh dari suatu kejadian khusus, perhatikan frase use case beroaris bawah pemilik rumah menggunakan key pad untuk mengunci di dalam ~rd empat digit. Dalam konteks model analisis 00, aktor pemilik rumah mentransmisikan suatu event ke objek kontrol panel. Event itu dapat disebut password entered. Informasi yang ditransfer adalah empat digit yang membentuk password, tetapi ini bukan bagian penting dari model tingkah laku. Penting untuk dicatat bahwa ban yak event berpengaruh eksplisit terhadap aliran kontrol. Contohnya, event password entered secara eksplisit tidak mengubah aliran kontrol dari use case, tetapi hasil event compare password (ditarik dari interaksi password dibandingkan dengan password valid yang disimpan di dalam sistem) akan berpengaruh eksplisit terhadap informasi dan aliran kontrol dari perangkat lunak SafeHome.

Seperti dicatat pada Subbab 2004.1, use case merepresentasikan urutan aktivitas yang melibatkan aktor dan sistem. Umurnnya, event terjadi setiap kal sistem 00 dan suatu aktor (ingat bahwa aktor dapat orang, perangkat, atau bahkan sistem ekstemal) bertukar informasi. Dengan mengingat kernbali pembahasan yang disajikan pada Bab 21. penting untuk dicatat bahwa event adalah Boolean; yaitu event bukan informasi yang telah ditukar; ini fakta bahwa informasi telah ditukar.

Begitu semua event telah diidentifikasi, event dialokasikan ke objek-objek yang terlibat. Aktor (entitas ekstemal) dan objek dapat bertanggung jawab untuk memunculkan event (rnisalnya, pemilik rumah membangkitkan event password entered) atau mengenali event yang telah terjadi di tempat lain (rnisalnya, kontrol panel mengenali hasil biner dari event compare password).

Use case diuji titik pertukaran informasinya. Untuk menggambarkannya, perhatikan use case yang dijelaskan pada Subbab 2004.1:

20.6.2 Representasi

I.

kan:

2.

3.

4.

Pemilik rumah meneliti kontrol panel SafeHome (Gambar 1104) untuk menentukan apakah sistem siap untuk diinput. Bila sistem tidak siap, maka pemilik rumah harus menutup jendela/pintu secara fisik sehingga muncul indikator ~. [Indikator tidak siap mengimplikasikan bahwa sebuah sensor terbuka, yaitu bahwa sebuah jendela atau pintu terbuka]. Pemilik rumah menggunakan key pada untuk mengunci di dalam password empat digit. Password dibandingkan dengan password valid yang disimpa~ dalam sistem. Bila password salah, kontrol panel akan membunyikan alarm (beep) satu kali dan mereset dirinya sendiri untuk input tambahan. Bila password benar, maka kontrol panel menunggu aksi lebih jauh. Pemilik rumah memilih dan mengunci dalam stay atau away (Iihat Gambar 1104) untuk mengaktivasi sistem. Stay hanya mengaktivasi parameter sensor (sensor pendeteksian dalam dideaktivasi). Away mengaktivasi semua sensor. Bila terjadi aktivas, maka sebuah lampu alarm merah akan dapat dilihat oleh pemilik rumah.

Bagian yang digaris bawah dari skenario use case yang ditulis di atas menunjukkan kejadian-kejadian. Aktor harus diidentifikasi untuk setiap kejadian; informasi yang ditukar harus dicatat dan setiap kondisi atau batasan harus ditunjukkan.

Keadaan

Dalam kontaks sistem 00, dua karakterisasi • •

keadaan yang berbeda harus diperhati-

keadaan dari masing-masing objek ketika sistem melakukan fungsinya keadaan sistem pada saat diselidiki dari luar ketika sistem melakukan fungsinya

Keadaan dari suatu objek menerima baik karakteristik pasif maupun aktif [CHA93]. Keadaan pasif hanyalah keadaan saat ini dari seluruh atribut objek. Misalnya, keadaan pasif dari objek agregat player (pada aplikasi video game yang dibahas sebelumnya) akan meliputi current position dan orientation dari pemain (atribut objek) serta fitur lain dari player yang relevan dengan game tersebut (misalnya, atribut yang menunjukkan magic wishes remaining). Keadaan aktifdari suatu objek menunjukkan keadaan saat ini dari objek pada saat objek mengalami proses atau transformasi yang kontinu. Objek player dapat memiliki keadaan aktif sebagai berikut: bergerak, diam. terluka, diobati, terjebak, kalah, dan sebagainya. Event (kadang-kadang disebut pemicu) harus terjadi untuk menekan suatu objek untuk membuat transisi dari satu keadaan aktif ke keadaan aktif lainnya. Kornponen suatu model tingkah laku objek merupakan representasi sederhana dari keadaan aktif untuk masing-rnasing objek dan event (trigger) yang menyebabkan perubahan di antara keadaan-keadaan aktif ini. Gambar 20.9 menunjukkan representasi sederhana dari keadaan aktif untuk objek kontrol panel pada sistem SafeHome.


714


715

kukan perbandingan digit demi digit untuk memvalidasi password yang dimasukcontrol panel password

dibandingkan

= tidak

control panel

control panel pa

sword

dimasukkan

I

U

l

J "dimasukkan lagi~

password

dibandingkan

= tida

password

dibandingkan

= ben ar

--I "membandingkan"

Mdiam~

-,

L.._

L

k benar

control panel

I

i

kan.

benar

"pemilihan aldiv,sl berh.sil

Tipe representasi tingkah laku yang kedua untuk OOA memperhatikan representasi keadaan untuk keseluruhan produk atau sistem. Representasi ini meliputi model penelusuran event sederhana [RAM91] yang menunjukkan bagaimana event menyebabkan transisi dari objek ke objek dan diagram state-transition yang menggambarkan tingkah laku pernrosesan dari masing-masing objek. Begitu event sudah diidentifikasi untuk suatu use case, maka analis menciptakan representasi mengenai bagairnana event menyebabkan aliran dari satu objek ke objek lainnya. Disebut event trace, representasi ini menjadi versi steno dari use case. Event tersebut merepresentasikan objek kunci dan event yang menyebabkan perilaku mengalir dari objek ke objek. Pemilik rumah sistem slap

Kontrcl panel

memasukkan

password

L..o

bila (input password

=

4 digit) maka buat transisi untuk keadaan pembandingan;

Biasanya, guard untuk suatu transisi biasanya tergantung pada nilai sutu atau lebih atribut dari suatu objek. Dengan kata lain, guard tergantung pada keadaan pasif objek tersebut. Action terjadi secara konkuren dengan transisi atau sebagai akibat dari transisi dan secara umum melibatkan satu operasi atau lebih (tanggungjawab) dari objek. Misalnya, action yang berhubungan dengan event password entered (Gambar 20.9) merupakan operasi yang mengakses objek password dan mela-

menginisiasi L..o

Gambar 20.9 Representasi transisi keadaan aktif untuk objek kontrol panel. Masing-masing anak panah pada Gambar 20.9 merepresentasikan suatu transisi dari satu keadaan aktif suatu objek ke keadaan aktif lainnya. Label yang diperlihatkan untuk setiap anak panah merepresentasikan event yang memicu transisi. Meskipun model keadaan aktif memberikan wawasan yang berguna ke dalam "sejarah kehidupan" suatu objek, dimungkinkan untuk menentukan informasi tambahan untuk memberikan pemahaman yang lebih mendalam mengenai tingkah laku objek. Sebagai tambahan untuk menentukan event yang menyebabkan terjadinya transisi, analisis dapat juga menentukan guard dan action [CHA93]. Guard adalah kondisi Boolean yang harus dipenuhi agar transisi terjadi. Contohnya, guard untuk transisi dari keadaan "diam" ke "keadaan pembandingan" pada Gambar 20.9 dapat ditentukan dengan menguji use case:

..

~

siap utuk aktivasi/deaktivasi

Sistem

~

beep

beep berbunyi

..

~

memilih stay/away sensor aktivasi/deaktivasi

~

sensor teraktivasilterdeaktivasi

lampu marah sesuai permintaan

..• l..t

lampu merah menyala

siap untuk aksi berikutnya

Gambar 20.10 Penelusuran event parsial dari SafeHome. Gambar 20.10 mengilustrasikan penelusuran event parsial bagi sistem SafeHome. Masing-masing anak panah merepresentasikan suatu event (ditarik dari sebuah use case) dan menunjukkan bagaimana event menyalurkan tingkah laku di antara objek SafeHome. Event pertama, system ready, ditarik dari lingkungan eksternal dan menyalurkan tingkah laku ke pemilik rumah. Pemilik rumah memasukkan password. Event initiates beep dan beep sounded menunjukkan bagaimana tingkah laku disalurkan bila password tidak valid. Password yang valid menghasilkan aliran balik ke pemilik rumah. Event yang tertinggal serta penelusuran mengikuti tingkah laku pada saat sistem diaktifkan atau dimatikan.


716

rnernnn stay/away masukkan password sistem siap

•.

Pemilik

..

Kontrol

panel

siap untuk aksi berikutnya siap untuk aktivasi/deaktivasi j~

beeb berbunyi sensor teraktvasiceaktvas! lampu merah menyala

mengil siasi beeb sensor eraktivasi·deaktivasi lampu merah sesuai permintaan

Sistem

Gambar 20.11 Diagram aliran event parsial untuk SafeHome. Begitu penelusuran event yang lengkap telah dikembangkan, maka semua event yang menyebabkan transisi di antara objek sistem dapat disatukan ke dalam serangkaian event input dan event output (dari sebuah objek). Hal itu dapat direpresentasikan dengan menggunakan diagram aliran kontrol [RAM91]. Semua kejadian yang mengalir ke dan keluar dari suatu objek ditulis seperti diperlihatan pada Gambar 20.11. Diagram state-transition (Bab 12) kemudian dapat diembangan untuk merepresentasikan tingkah laku yang sesuai dengan tanggung jawab masing masing-masing kelas." Seperti diagram terstruktur yang disajikan pada Bab 12, representasi grafis membentuk dasar bagi model analisis 00 dan menjadi dasar yang sangat kuat bagi pembentukan spesifikasi persyaratan perangkat lunak.

20.7 RANGKUMAN Metode OOA memungkinkan perekayasa perangkat lunak memodelkan suatu masalah dengan merepresentasikan objek, atri-but, dan operasi sebagai komponen pemodelan primer. Berbagai metode OOA telah diusulkan di dalam literatur, tetapi semuanya memiliki serangkaian karakteristik umum: (1) representasi kelas dan hirarki kelas, (2) kreasi model hubungan objek, (3) derivasi dari model berorientasi objek.

13

III

Tutorial yang [RUB92].

sangat

bagus

mengenai

"analisis

tingkah

laku

objek"

717

Analisis untuk sistem berorientasi objek terjadi pada beberapa tingkat abstraksi yang berbeda-beda. Pada tingkat bisnis atau hiburan, teknik yang sesuai dengan OOA dapat dirangkai dengan pendekatan rekayasa informasi. Teknik ini sering disebut analisis domain. Pada tingkat aplikasi, model objek berfokus pada persyaratan pelanggan yang spesifik di mana persyaratan-persyaratan tersebut mempengaruhi aplikasi yang akan dibagun.

~

rumah

-


dapat

ditemukan

pada

Proses OOA dimulai dengan definisi use case - skenario yang menggambarkan bagaimana sistem 00 digunakan. Teknik pemodelan kelas-tanggungjawabkolaborator (CRC) kemudian diaplikasikan ke kelas dokumen dan atribut serta aplikasi mereka. Teknik ini juga memberikan suatu pandangan awal mengenai kolaborasi yang terjadi di antara objek. Langkah selanjutnya pada proses OOA adalah klasifikasi objek dan pembuatan hirarki kelas. Subsistem (subjek) dapat digunakan untuk mengenkapsulasi objek yang berhubungan. Model hubungan objek memberikan indikasi mengenai bagaimana kelas-kelas disambungkan satu dengan yang lainnya, dan model tingkah laku objek menunjukkan tingkah laku dari objek individual serta keseluruhan tingkah laku sistem 00.

DAFT AR PUST AKA [AMB95] Ambler, S., "Using Use Cases," Software Development, Juli 1995, h. 53-61. [ARA89] Arango, G., dan R. Prieto-Diaz, "Domain Analysis Concepts and Research Directions," dalam Domain Analysis: Acquisition of Reusable Information for Software Construction, G. Arango dan R. Prieto-Diaz (eds.), IEEE Computer Society Press, 1989. [BER92] Berard, E.V., A Comparison of Object-Oriented Development Methodologies, Berard Software Engineering, Inc., Gaithersburg, MD, 1992. [BER93] Berard, E.V., Essays on Object-Oriented Software Enginering, AddisonWesley, 1993. [B0094] Booch, G., Object-Oriented Analysis and Design, 2nd edition, Benjamin Cummings, 1994. [B0096] Booch, G., dan J. Rambaugh, Unified Method for Object-Eriented Development, Rational Software Corp., 1996. [CHA93] de Champeaux, D., D. Lea, dan P. Faure, Object-Oriented System Development, Addison-Wesley, 1993. [COA 91] Coad, P., dan E. Yourdon, Object-Oriented Analysis, 2nd edition, Prentice-Hall, 1991. [DUE92] Due, R., "Enterprise Modeling: Still in Pursuit," Database Programming and Design, November 1992, h. 62-65. [EMB92] Embley, D.W., B.D. Kurtz, dan S.N. Woodfield, Object-Oriented Systems Analysis, Yourdon Press, 1992.

718


Fichman. R.G .. dan C.F. Kemerer, "Object-Oriented and Conventional Analysis and Design Methodologies," Computer, Vol. .25. No. 10. Oktober 1992, h. 22-39. [FIR93 J Firesmith, D.G., Object-Oriented Requirements Analysis and Logical Design, Wiley, 1993. [GRA 94] Graham, I.. Object-Oriented Methods. Addison- Wesley, 1994. [JAC92] Jacobson, I.. Object-Oriented Software Engineering, Addison-Wesley, 199.2. .

[FIC92]

[LOC96 J Succeeding with the Booch and OMT Methods. Loekheed-Martin and Rational Software Corporation, Addison- Wesley, 1996. [MA T94] Mattison. R., The Object-Oriented Enterprise. McGraw-Hill, 1994. [MON92] Monarchi. D.E., dan G.!. Puhr, "A Research Typology for ObjectOriented Analysis and Design," Communications ofthe ACM, Vo\. 35, No. 9, September 1992, h. 35-47. [RAM91] Rambaugh, 1. et analisis., Object-Oriented Modeling and Design, Prentice- Hall, 1991. [RUB92] Rubin, K.S., dan A. Goldberg, "Object Behavior Analysis". Communications of the A CM, Vo\. 35, No. 9, September 1992. h. 48-62. [SUL94] Sullo. o.c. Object Engineering, Wiley, 1994. [T A Y95] Taylor. D.A., Bussiness Engineering with Object Technology, Wiley, 1995. [WIR90] Wirfs-Broek, R., B. Wilkerson, dan L. Weiner, Designing ObjectOriented Software, Prentice-Hall, 1990. [WYD96] Wyder, T.. "Capturing Requirements with Use Cases," Software Development, Februari 1996, h. 37-40.

SOAL-SOAL 20.1.

20.2.

20.3.

Pilihlah lima metode OOA dan analisis terstruktur (Bab 1.2) dan bandingkan dengan menggunakan dimensi pemodelan yang diusulkan oleh Fiehman dan Kemerer [FIC92] PADA Subbab 20.1.1 Kembangkan representasi ruang kelas mengenai satu metode OOA yang dibahas pad a Subbab 20.1.2. Sajikan metode tersebut dalam konteks contoh yang sederhana. Catatlah area di mana notasi atau pendekata unik digunakan. Lakukan analisis domain singkat untuk satu dari area berikut: a. sistem penyimpanan rekaman mahasiswa. b. pelayanan on-line. c. costumer service untuk sebuah bank. d. pengembang video game. e. area aplikasi yang diusulkan oleh instruktur Anda.

719


Pastikan untuk mengisolasi pada domain itu.

20.4. 20.5.

20.6.

20.7.

20.8. 20.9.

kelas yang dapat diaplikasikan

pada sejumlah

aplikasi

Dengan kalimat Anda sendiri gambarkan perbedaan antarapandangan statis dan dinamis mengenai sistem 00. Tulislah use ease untuk sistem Safe Home yang dibahas pad a buku ini. Use case tersebut harus menyinggung skenario yang diperlukan untuk menentukan daerah keamanan. Daerah keamanan meliputi serangkaian sensor yang dapat dituju, diaktifkan, dan dimatikan sebagai suatu rangkaian, dan bukan seeara individu. Sebanyak 10 daerah ke-amanan dapat ditentukan. Jadilah kreatif di sini, tetapi tetaplah berada di dalam batas kontrol panel seperti didefinisikan pada bagian sebelumnya buku ini. Kembangkan serangkaian use ease untuk sistem PHTRS yang diperkenalkan dalarn Soal 12.13. Anda harus membuat sejumlah asumsi mengenai eara pemakai berinteraksi dengan sistem ini. Kembangkan serangkaian use ease yang ada pad a Tabel 20.1 atau untuk sebuah sistem atau produk yang diusulkan oleh instruktur Anda. Lakukan beberapa jam pengamatan pada area aplikasi dan lakukan pertemuan FAST (Bab 11) dengan rekan-rekan kelas Anda untuk mengembangkan persyaratan dasar (instruktur Anda akan membantu Anda mengkoordinasikan hal ini). Kembangkan serangkaian kartu indeks model CRC lengkap untuk produk atau sistem yang Anda pilih sebagai bagian dari SoaI20.7. Lakukan kajian kartu indeks CRC yang dikembangkan dalam Soal 20.8 dengan rekan Anda. Berapa ban yak kelas tambahan, tanggung jawab, dan kolaborator ditambahkan sebagai konsekuensi dari kajian tersebut?

Tabel 20.1 Aplikasi yang diusulkan untuk Soal 20. 7 sampai 20.12

Aplikasi PHTRS yang diperkenalkan pada soa112.13 Perangkat lunak untuk sebuah sistem pengolah kata berdasarkan komputer personal Sistem monitoring pengujian real-time untuk mesin turbin gas Perangkat lunak untuk sistem kontrol pemanufakturan Perangkat lunak untuk video game pilihan Anda Aplikasi spreadsheet Kemasan grafik 3D berbasisi PC Sistem yang diusulkan oleh instruktur anda

20.10. Kembangkan suatu hirarki kelas untuk produk atau sistem yang Anda pilih sebagai bagian dari SoaI20.7. 20.1 I. Kembangkan serangkaian subsistem untuk produk atau sistem yang Anda pilih sebagai bagian dari Soal 20.7.

720


20.12. Kembangkan suatu model hubungan objek untuk produk atau sistem yang Anda pilih sebagai bagian dari Soal 20.7. 20.13. Kembangkan model tingkah laku objek untuk produk atau sistem yang Anda pilih sebagai bagian dari Soal 20.7. Pastikan untuk mendaftar semua event, berikan penelusuran event, kembangkan diagram aliran event, dan tentukan diagram keadaan untuk masing-masing kelas. 20.14. Dengan kalimat Anda sendiri, gambarkan bagaimana kolaborasi bagi masing-masing kelas ditentukan. 20.15. Strategi apa yang akan Anda usulkan untuk menentukan subsistem bagi sekumpulan kelas? 20.16. Peran apa yang dimainkan oleh kardinalitas dalam pengembangan model hubungan objek? 20.17. Apa perbedaan antara keadaan aktif dan keadaan pasif bagi sebuah objek?


721

http://www.cs.crnu.edu/Web/Groups/A

I/htrn I/faqs/lang/oop/faq,htrnl

Pembahasan mengenai masalah OOA kadang-kadang dapat ditemukan di dalam comp.software-eng dan comp.specification. A Comparison of Object-Oriented Development Methodologies oleh Edward Berard dapat diperoleh. Pilihlah "dokumen on-line" pada: http://www.toa.com

Informasi tambahan dapat diperoleh pada:

mengenai

OOA dan teknologi

objek secara umum

http://www.rational.com

Berbagai referensi mengenai paper dan buku mengenai OOA dapat diperoleh pada: http://www.cera2.com/object.htrn

BACAAN LEBIH LANJUT DAN SUMBER-SUMBER MASI LAIN

INFOR-

Banyak buku menyinggung mengenai OOA. Sebelum memilih salah satunya, pembaca harus memilih metode OOA yang sesuai dengan kebutuhan lokal dan kemudian pilih sebuah buku yang menggambarkan metode yang sesuai. Penelitian yang sangat menarik mengenai metode yang dapat diperoleh disajikan di dalam [MON92] dan [FIC92]. Pembahasan detail mengenai OOA dapat ditemukan di [BER93], [B0094], [CHA93], [COA91]. [FIR93], [JAC92], [RAM91], dan [WIR90]. Sebagai tambahan, buku-buku oleh Shlaer dan Melior (Object-Oriented System Analysis: Modeling the World in States, Prentice-Hall, 1992), Martin dan Odell (ObjectOriented Analysis and Design, Prentice-Hall, 1992), Goldstein dan AIger (Developing Object-Oriented Software for the Macintosh, Addison- Wesley, 1992), dan Lorenz tObject-Oeriented Software Development, Prentice-Hall, 1993) berisi diskusi yang berguna. Yourdon dan Argila (Case Studies in Object-Oreinted Analysis Design, Prentice-Hall, 1995) menyajikan dua studi kasus yang realist is yang menggambarkan proses OOA secara detail. Pernbahas-an mengenai teknik OOA untuk prototyping disajikan oleh Connell dan Shafer iObject-Oreinted Rapid Protoyyping, Prentice-Hall, 1994) dan Krief (Using Object-Oriented Languages for Rapid Prototyping, Prentice-Hall, 1996). Sumber Internet yang sama yang ditulis untuk Bab 19 dapat diaplikasikan untuk OOA. Newsgroup Internet cornp.object merupakan suatu sumber informasi yagn berguna, diskusi. dan debat mengenai metode dan peranti OOA. FAQ untuk newsgroup ini berisi rangkuman singkat mengenai metode OOA dan menunjukkan referensi tarnbahan, dan dapat ditemukan pada:

Daftar mutakhir mengenai referensi World temukan pada: ~t.tp":.._~\~~\,\t>J?i1S().t.1.1 -00000-

Wide Web untuk OOA dapat di-

A'NALISIS BERORIENTASI OBJEK

Recommend Documents