CBOP3103- Object Oriented Approach in Software Development

Soalan 1 A

Penggunaan kes-kes gunaan di dalam pendekatan berorientasikan objek di dalam pembangunan perisian mampu mengundang masalah sekiranya tidak digunakan dengan betul. Antara punca yang mengundang masalah di dalam penggunaan kes gunaan adalah:

1. Sempadan sistem tidak didefinasikan dengan jelas dan tidak tetap

- Di dalam membangunkan sesuatu perisian, sempadan sesebuah sistem hendaklah dijelaskan dengan tepat semasa pembangunan aturcara. Ini supaya aturcara yang ditulis terutama dengan penggunaan kes gunaan dan berfungsi dengan sepenuhnya. Sebagai contoh bagi sistem maklumat pesakit, pengaturcara hendaklah mengenalpasto sempadan sistem tersebut. Sempadan bagi sistem ini adalah sistem maklumat pesakit itu sendiri manakalah pengguna sistem seperti jururawat, doctor dan sistem pembayaran seperti kredit adalah objek yang berada di luar sempadan sistem . Pengasingan objek dan sistem maklumat pesakit ini melalui sempadan dapat mengoptimumkan penggunaan sistem tersebut. Bagi mengelakkan masalah sempadan sistem ini, Susan Lily (1999) mencadangkan agar sempadan sistem hendaklah didefinasikan terlebih dahulu semasa membangunkan perisian sistem. Ini supaya ia dapat menjelaskan objek yang mana patut berada di dalam sistem dan objek yang mana patut berada di luar sistem itu sendiri.

2. Nama ‘actor’ yang digunakan tidak konsisten.

- Penggunaan nama ‘actor’ secara tidak konsisten dapat mendatangkan masalah kepada pendekatan berorientasikan objek ini. Ini disebabkan penggunaan nama ‘actor’ yang mempunyai tujuan yang sama dinamakan dengan dua atau tiga nama yang berbeza. Sebagai contoh di dalam sistem pinjaman VCD, jurujual dan kerani mempunyai peranan yang sama di dalam sistem ini di mana kedua-duanya mempunyai peranan atau tugas untuk menerima pendaftaran ahli baru. Tetapi disebabkan nama ‘actor’ dinamakan dengan menggunakan nama jawatan individu terbabit maka di dalam diagram kes guna akan ada dua nama ‘actor’ yang lain walaupun peranan mereka adalah sama. Bagi mengelakkan masalah ini berlaku, kita hendaklah memberi focus kepada peranan atau tujuan ‘actor’ terbabit dan bukannya memberi focus kepada jawatan ‘actor’ tersebut. Susan Lily (1999) juga mencadangkan supaya semasa menulis kes guna, tumpuan diberkan kepada tujuan atau peranan ‘actor’ terbabit. Ini kerena ia akan membantu kita untuk menilai kes guna tersebut dari perspektif pengguna akhir sistem.

3. Spesifikasi kes guna mengelirukan

- Penggunaan spesifikasi kes guna yang mengelirukan juga akan mendatangkan masalah kepada pembangunan perisian yang menggunakan kaedah orietasi objek. Ini kerana spesikasi kes guna yang mengelirukan dan kompleks hanya difahami oleh individu yang terlibat di dalam membangun perisian sahaja. Walaupun sebagai pengguna akhir sesuatu perisian seharusnya tidak perlu memahami kod aturcara perisian terbabit tetapi sekiranya spesifikasi yang kompleks dan mengelirukan digunakan di dalam kes guna sesuatu perisian ia boleh mendatangkan masalah kepada individu baru yang bakal menyenggara perisian terbabit. Ini kerana kes guna terbabit hanya difahami oleh individu yang membangunkan kes guna tersebut. Masalah akan menjadi lebih rumit apabila individu terdahulu tidak lagi bekerja dengan organisasi yang membangunkan perisian terbabit dan beliau digantikan dengan pekerja yang baru. Bagi menangani masalah penggunaan spesifikasi yang mengelirukan ini, Susan Lily (1999) mencadangkan agar spesifikasi kes guna menggunakan ‘template’ yang standard di dalam mendokumenkan spesifikasi kes guna. Ia dapat membantu pekerja baru untuk berkomunikasi dengan lebih baik di dalam membangunkan sesuatu perisian tersebut.

Soalan 1 B

Jenis-jenis ‘Actor’

Nama ‘Actor’	Jenis	Kepentingan
Graduan	Primer	Sederhana
Pegawai_Pengajian	Primer	Tinggi
Acara	Sekunder	Sederhana
Penganjur	Sekunder	Sederhana

Kes Guna

1. Daftar Graduan
2. Daftar Acara
3. Rekod Komen
4. Rekod Kehadiran
5. Jana Laporan

Diagram Kes Guna

Daftar Acara

Daftar Graduan

Rekod Komen

Rekod Kehadiran

Jana Laporan

Pegawai Pengajian

Acara

Penganjur

Graduan

Sistem Perekodan Aktiviti Alumni HI

Graduan

- ID_graduan : integer - Nama : string - Alamat : string - Warganegara : string - Kursus : string

+daftarKursus (ID_graduan:integer, KodKursus : integer, NamaKursus : string

Acara

- ID_acara : integer - Nama : string - Tarikh : integer - Tempat : string - Penganjur : string

+daftarGraduan (ID_graduan:integer, RekodHadir : integer, Komen : string

Pegawai Bank

Juruteknik

Hubungan ‘include’

Senggara ATM

Penyengaraan Tak Berjadual

Pengisian ATM

Penyenggaraan Berjadual

Hubungan ‘extend’, sekiranya ralat berlaku

Sebagai contoh di atas pegawai bank akan mengisi semula(Pengisian ATM) sejumlah wang di dalam mesin ATM pada masa tertentu bagi mengelakkan masalah kehabisan wang di mesin tersebut. Setelah pengisian semula wang dilakukan, pegawai berkenaan akan terus mengemaskini data Penyenggaraan Berjadual mesin ATM berkenaan. Ini menunjukkan hubungan ‘include’ di dalam kes guna Pengisian ATM di mana selepas mengisi semula wang ke dalam mesin, ia juga akan mengemaskini kes guna Penyenggaraan Berjadual.

Bagi hubungan ‘extend’ pula ia berlaku semasa juruteknik ATM melakukan kerja penyenggaraan ATM. Kes guna Senggara ATM merujuk kepada proses menyenggara mesin. Setelah selesai menyenggara mesin ATM, juruteknik berkenaan akan mengemaskini data di kes guna Penyenggaraan Berjadual mesin ATM. Hubungan ‘extend’ berlaku semasa proses kes guna Senggara ATM di mana semasa proses penyenggaraan dilakukan mesin ATM berkenaan mengesan ralat mesin. Juruteknik akan melakukan membaiki ralat tersebut. Setelah membaiki ralat tersebut juruteknik tersebut akan mengemaskini kes guna Penyenggaraan Tak Berjadual. Kes guna Senggara ATM secara tidak langsung akan melakukan hubungan ‘extend’ dengan kes Penyenggaraan Tak Berjadual kerana ralat mesin hanya dikesan ketika proses di dalam kes Senggara ATM dijalankan. Sekiranya tiada ralat dikesan, hubungan ‘include’ atas kes guna Senggara ATM dan kes guna Penyengaraan Berjadual akan berlaku.
Soalan 2 C

Perwarisan berganda ialah pewarisan di mana kelas mewarisi gelagat ataupun atribut daripada beberapa superkelas. Perwarisan jenis ini berlainan dengan perwarisan tunggal di mana sesuatu kelas itu hanya boleh mewarisi atribut dari satu superkelas sahaja. Kebanyakan perisian bahasa pengaturcaraan seperti C++, Eiffel dan Perl menyokong penggunaan perwarisan jenis ini.

Kelemahan perwarisan berganda ini ialah penggunaanya tidak semudah perwarisan tunggal. Perwarisan berganda ini sering dikritik penggunaannya kerana ia meningkatkan kerumitan terhadap aturcara terbabit. Ia juga menimbulkan masalah bagi menyelenggara sesuatu sistem yang menggunakan perwarisan berganda ini. Pewarisan berganda ini juga dikritik kerana berlaku masalah semasa pelaksanaannya di mana kegagalan kelas untuk mewarisi atribut dari beberapa superkelasnya. Kegagalan ini juga menyebabkan perubahan kelas terbabit secara semantik.

Terdapat beberapa cara yang telah dikenalpasti oleh perisian pengaturcaraan bagi mengatasi masalah di atas. Antara cara-cara yang telah dikenalpasti ialah:

Bagi C++: Ia menghendaki pengaturcara untuk menentukan superkelas yang mana atributnya diwarisi oleh subkelas . Sebagai contoh XXXXXXXX. C++ tidak menyokong pewarisan berulang kerana pewarisan berulang ini tidak dapat menentukan superkelas yang mana untuk digunakan.

Bagi PERL pula kelas akan mewarisi atribut daripada senarai atur superkelas. Ia akan mencari atribut untuk diwarisi daripada senarai superkelas.

Eiffel pula membenarkan pengaturcara untuk menggabungkan atau memisahkan atribut yang diwarisi dari superkelas. Eiffel atau mengabungkan semula atribut ini secara automatik sekiranya kelas tersebut mempunyai atribut yang sama dengan beberapa superkelas. Ia juga membenarkan pengaturcara untuk menamakan atribut yang diwarisi dengan nama lain bagi tujuan pengasingan atribut berkenaan. Berbeza dengan C++, Eiffel membenarkan perwarisan berulang.

Contoh rajah UML perwarisan berganda adalah seperti di bawah:

Individu

Pensyarah

Pelajar Sambilan

Pelajar

Terdapat 4 jenis mesej yang dihantar melalui penghantaran mesej ini iaitu:

1. mesej ‘synchronous’ – penerimaan mesej hanya dimulakan apabila penerima sudah bersedia untuk menerima mesej. Keadaan ini berlaku apabila kedua-dua penerima dan penghantar mesej bersedia untuk melakukan aktiviti ini
2. mesej ‘asynchronous’ – penghantaran mesej boleh dilakukan pada bila-bila masa walaupun penerima mesej tidak bersedia atau tidak berada di dalam talian. Mesej yang tidak dituntut oleh penerima akan menunggu sehingga penerima menerima mesej tersebut
3. mesej ‘balking’ – objek yang menghantar mesej membatalkan penghantaran mesej akibat objek penerima tidak bersedia untuk menerima mesej.
4. mesej masa terhad atau ‘timeout message’ – objek penghantar mesej hanya menunggu untuk tempoh masa tertentu bagi objek penerima mesej untuk menerima mesej sahaja.

Contoh sintaks bahasa pengaturcaraan bagi penghantaran mesej seperti di bawah:

Bahasa C++ sintaks penghantaran mesej adalah seperti di bawah.

<rujukan_objek>.<nama_mesej>(senarai_parameter)

Oleh itu, sintaks bagi c++ ialah:

aCard.setFaceUp true ;

Bagi java sintaks penghantaran mesej dihantar kepada objek menerusi operator titik. Sintaksnya ialah:

<rujukan_objek>.<nama_mesej>(senarai_parameter)

Sebagai contoh bagi java ialah

“jadualMarkah.pengawalan (80,4)

Rujukan

1. B. Chandra (2005). Object Oriented Programming Using C++. London: Alpha Science International Limited
2. A source with not known author – Introduction to Distance Learning: What is it? Why I should be interested? Where may I find courses? How much does it cost? Defining Distance Learning and Its Role from http://distancelearn.about.com

3. Grant Emery (1999). Not known title from http://web.mit.edu/6.033/1999/www/reports/r02-gemery.html

1. P. Sellappan(2002). C++ Through Examples. Includes Object Oriented Programming. Selangor: Federal Publications Sdn Bhd
2. Dr. Raymond J. Curts, CDR, USN (Ret.). Avoiding Information Overload Through the Understanding of OODA Loops, A Cognitive Hierarchy and Object-Oriented Analysis and Design. Strategic Consulting Inc. http://www.belisarius.com/modern_business_strategy/campbell/ooda_and_objects.doc

6. Nantha Kumar Subramanian et. al. (2007). Open University Malaysia: CBOP3103: Object Oriented Approach in Software Development.. Kuala Lumpur. MeteorDoc Sdn. Bhd.