OOAD - Panduan Cepat Paradigma Berorientasi Objek Sejarah Singkat Paradigma berorientasi obyek mengambil bentuknya dari konsep awal pendekatan pemrograman baru, sementara minat terhadap metode perancangan dan analisis datang jauh kemudian. Bahasa berorientasi objek pertama adalah Simula (Simulasi sistem nyata) yang dikembangkan pada tahun 1960 oleh para periset di Norwegian Computing Center. Pada tahun 1970, Alan Kay dan kelompok risetnya di Xerox PARK menciptakan komputer pribadi bernama Dynabook dan bahasa pemrograman berorientasi objek murni pertama (OOPL) - Smalltalk, untuk memprogram Dynabook. Pada tahun 1980an, Grady Booch menerbitkan sebuah makalah berjudul Object Oriented Design yang sebagian besar menyajikan desain untuk bahasa pemrograman, Ada. Dalam edisi berikutnya, dia memperluas gagasannya ke metode perancangan objectoriented yang lengkap. Pada 1990-an, Coad memasukkan gagasan perilaku ke metode berorientasi objek. Inovasi signifikan lainnya adalah Object Modeling Techniques (OMT) oleh James Rumbaugh dan Object-Oriented Software Engineering (OOSE) oleh Ivar Jacobson. Analisis Berorientasi Objek Analisis ObjectOriented (OOA) adalah prosedur untuk mengidentifikasi persyaratan rekayasa perangkat lunak dan mengembangkan spesifikasi perangkat lunak dalam hal model objek sistem perangkat lunak, yang terdiri dari objek yang berinteraksi. Perbedaan utama antara analisis berorientasi obyek dan bentuk analisis lainnya adalah bahwa dalam pendekatan berorientasi objek, persyaratan disusun di sekitar objek, yang mengintegrasikan data dan fungsi. Mereka dimodelkan setelah objek dunia nyata yang berinteraksi dengan sistem. Dalam metodologi analisis tradisional, dua aspek - fungsi dan data - dianggap terpisah. Grady Booch telah mendefinisikan OOA sebagai, analisis berorientasi objek adalah metode analisis yang menguji persyaratan dari perspektif kelas dan objek yang ditemukan dalam kosakata domain masalah. Tugas utama dalam analisis berorientasi objek (OOA) adalah: Mengidentifikasi objek Mengorganisir objek dengan membuat diagram model objek Mendefinisikan bagian dalam objek, atau atribut objek Mendefinisikan perilaku objek, yaitu tindakan objek Menggambarkan bagaimana objek berinteraksi. Model yang digunakan dalam OOA adalah use case dan object models. Object-Oriented Design ObjectOriented Design (OOD) melibatkan implementasi model konseptual yang dihasilkan selama analisis berorientasi objek. Dalam OOD, konsep dalam model analisis, yang bersifat teknologindependent, dipetakan ke kelas implementasi, batasan diidentifikasi dan antarmuka dirancang, menghasilkan sebuah model untuk domain solusi, yaitu deskripsi rinci bagaimana sistem akan dibangun di atas beton Teknologi. Rincian implementasi umumnya meliputi: Restrukturisasi data kelas (jika perlu), Implementasi metode, yaitu struktur data internal dan algoritma, Implementasi pengendalian, dan implementasi asosiasi. Grady Booch telah mendefinisikan desain berorientasi obyek sebagai metode perancangan yang mencakup proses penguraian berorientasi objek dan notasi untuk menggambarkan model logis dan fisik serta statis dan dinamis dari sistem yang sedang disain. Pemrograman Berorientasi Objek Pemrograman berorientasi objek (OOP) adalah paradigma pemrograman berdasarkan objek (memiliki kedua data dan metode) yang bertujuan untuk menggabungkan keuntungan modularitas dan usabilitas. Objek, yang biasanya merupakan contoh kelas, digunakan untuk berinteraksi satu sama lain untuk merancang aplikasi dan program komputer. Fitur penting dari pemrograman objectoriented adalah: Pendekatan dasar dalam perancangan program Program yang diselenggarakan di sekitar objek, dikelompokkan dalam kelas Fokus pada data dengan metode untuk beroperasi pada objek data Interaksi antara objek melalui fungsi Reusability of design melalui penciptaan kelas baru dengan menambahkan fitur ke kelas yang ada. Beberapa contoh bahasa pemrograman berorientasi objek adalah C, Java, Smalltalk, Delphi, C, Perl, Python, Ruby, dan PHP. Grady Booch telah mendefinisikan pemrograman berorientasi objek sebagai metode implementasi di mana program disusun sebagai kumpulan objek yang kooperatif, yang masing-masing mewakili sebuah instance dari beberapa kelas, dan kelas-kelasnya adalah anggota dari hirarki kelas yang disatukan melalui hubungan warisan. OOAD - Object Model Model objek memvisualisasikan elemen dalam aplikasi perangkat lunak dalam hal objek. Dalam bab ini, kita akan melihat konsep dasar dan terminologi sistem objectoriented. Objek dan Kelas Konsep objek dan kelas secara intrinsik saling terkait satu sama lain dan merupakan dasar dari paradigma objectoriented. Objek adalah elemen dunia nyata dalam lingkungan objectoriented yang mungkin memiliki eksistensi fisik atau konseptual. Setiap objek memiliki: Identitas yang membedakannya dari objek lain di sistem. Negara yang menentukan sifat karakteristik suatu objek serta nilai sifat yang dimiliki objek. Perilaku yang mewakili kegiatan yang terlihat secara eksternal dilakukan oleh suatu objek dalam hal perubahan keadaannya. Objek bisa dimodelkan sesuai kebutuhan aplikasi. Objek mungkin memiliki eksistensi fisik, seperti pelanggan, mobil, dll, atau eksistensi konseptual yang tidak berwujud, seperti sebuah proyek, sebuah proses, dll. Kelas mewakili kumpulan objek yang memiliki karakteristik karakteristik yang sama yang menunjukkan perilaku umum. Ini memberi cetak biru atau deskripsi objek yang bisa diciptakan darinya. Penciptaan objek sebagai anggota kelas disebut instantiasi. Dengan demikian, objek adalah turunan dari kelas. Konstituen dari kelas adalah: Satu set atribut untuk objek yang akan di instantiasikan dari kelas. Umumnya, objek yang berbeda dari sebuah kelas memiliki beberapa perbedaan dalam nilai atribut. Atribut sering disebut data kelas. Satu set operasi yang menggambarkan perilaku objek kelas. Operasi juga disebut fungsi atau metode. Mari kita perhatikan sebuah kelas sederhana, Circle, yang mewakili lingkaran sosok geometris dalam ruang dua dimensi. Atribut dari kelas ini dapat diidentifikasi sebagai berikut: xcoord, untuk menunjukkan xcoordinate dari center ycoord, untuk menunjukkan ycoordinate dari pusat a, untuk menunjukkan jari-jari lingkaran Beberapa operasinya dapat didefinisikan sebagai berikut: findArea (), Metode untuk menghitung daerah findCircumference (), metode untuk menghitung skala lingkar (), metode untuk meningkatkan atau menurunkan radius Selama instantiasi, nilai diberikan setidaknya untuk beberapa atribut. Jika kita membuat objek mycircle, kita bisa menetapkan nilai seperti x-coord. 2, y-coord. 3, dan a. 4 untuk menggambarkan negaranya. Sekarang, jika skala operasi () dilakukan pada skala mycircle dengan faktor penskalaan 2, nilai variabel a akan menjadi 8. Operasi ini membawa perubahan pada keadaan mikroskop, yaitu objek telah menunjukkan perilaku tertentu. Enkapsulasi dan Penyembunyian Data Enkapsulasi Enkapsulasi adalah proses pengikatan kedua atribut dan metode bersama-sama di dalam kelas. Melalui enkapsulasi, rincian internal sebuah kelas dapat disembunyikan dari luar. Ini memungkinkan elemen kelas untuk diakses dari luar hanya melalui antarmuka yang disediakan oleh kelas. Penyembunyian Data Biasanya, kelas dirancang sedemikian rupa sehingga datanya (atribut) dapat diakses hanya dengan metode kelasnya dan terisolasi dari akses luar langsung. Proses isolasi data benda ini disebut data bersembunyi atau menyembunyikan informasi. Di kelas Circle, persembunyian data dapat digabungkan dengan membuat atribut yang tidak terlihat dari luar kelas dan menambahkan dua metode lagi ke kelas untuk mengakses data kelas, yaitu: setValues (), metode untuk menetapkan nilai ke koordinat, coord, Dan metode getValues (), untuk mengambil nilai koordinat x, coord, dan a Disini data pribadi objek mycircle tidak dapat diakses secara langsung dengan metode apapun yang tidak dienkapsulasi dalam kelas Circle. Ini malah harus diakses melalui metode setValues () dan getValues (). Message Passing Setiap aplikasi membutuhkan sejumlah objek yang berinteraksi secara harmonis. Objek dalam suatu sistem dapat berkomunikasi satu sama lain dengan menggunakan pesan yang lewat. Misalkan sebuah sistem memiliki dua objek: obj1 dan obj2. Objek obj1 mengirimkan sebuah pesan ke objek obj2, jika obj1 ingin obj2 melakukan salah satu metodenya. Fitur dari message passing adalah: Message passing antara dua objek umumnya searah. Pengiriman pesan memungkinkan semua interaksi antar objek. Pesan yang lewat pada intinya melibatkan metode kelas yang memohon. Objek dalam proses yang berbeda dapat dilibatkan dalam pengiriman pesan. Warisan Warisan adalah mekanisme yang memungkinkan kelas baru dibuat dari kelas yang ada dengan memperluas dan menyempurnakan kemampuannya. Kelas yang ada disebut kelas dasar kelas classessuper yang ketat, dan kelas-kelas baru disebut kelas classclasses kelas yang diturunkan. Subkelas dapat mewarisi atau menurunkan atribut dan metode kelas super yang disediakan agar kelas super mengizinkannya. Selain itu, subclass dapat menambahkan atribut dan metode sendiri dan dapat memodifikasi metode kelas super. Warisan mendefinisikan sebuah hubungan. Dari kelas Mamalia, sejumlah kelas bisa diturunkan seperti Manusia, Kucing, Anjing, Sapi, dll. Manusia, kucing, anjing, dan sapi semuanya memiliki karakteristik mamalia yang berbeda. Selain itu, masing-masing memiliki karakteristik tersendiri. Bisa dikatakan seekor sapi adalah mamalia. Jenis Warisan: Warisan Tunggal. Sebuah subclass berasal dari kelas super tunggal. Beberapa Warisan. Subclass berasal dari lebih dari satu kelas super. Warisan bertingkat. Subclass berasal dari kelas super yang pada gilirannya berasal dari kelas lain dan seterusnya. Hierarkis Warisan. Kelas memiliki sejumlah subclass yang masing-masing memiliki subclass berikutnya, berlanjut ke sejumlah level, sehingga membentuk struktur pohon. Warisan hibrida. Kombinasi multiple dan multilevel inheritance sehingga membentuk struktur kisi. Gambar berikut menggambarkan contoh berbagai jenis warisan. Polimorfisme Polimorfisme pada awalnya adalah kata Yunani yang berarti kemampuan untuk mengambil banyak bentuk. Dalam paradigma berorientasi obyek, polimorfisme menyiratkan penggunaan operasi dengan cara yang berbeda, bergantung pada contoh yang mereka jalankan. Polimorfisme memungkinkan objek dengan struktur internal berbeda memiliki antarmuka eksternal yang umum. Polimorfisme sangat efektif saat menerapkan warisan. Mari kita simak dua kelas, Circle and Square, masing-masing dengan metode findArea (). Meskipun nama dan tujuan metode di kelas sama, pelaksanaan internal, yaitu prosedur penghitungan daerah berbeda untuk setiap kelas. Ketika sebuah objek di kelas Circle memanggil metode findArea () nya, operasi menemukan area lingkaran tanpa konflik dengan metode findArea () kelas Square. Generalisasi dan Spesialisasi Generalisasi dan spesialisasi mewakili hirarki hubungan antar kelas, di mana subclass mewarisi dari kelas super. Generalisasi Dalam proses generalisasi, karakteristik umum kelas dikombinasikan untuk membentuk kelas di tingkat hirarki yang lebih tinggi, yaitu subclass digabungkan untuk membentuk kelas super umum. Ini merupakan semacam hubungan. Misalnya, mobil adalah semacam kendaraan darat, atau kapal sejenis kendaraan air. Spesialisasi Spesialisasi adalah proses pembalikan generalisasi. Di sini, fitur pembeda kelompok objek digunakan untuk membentuk kelas khusus dari kelas yang ada. Dapat dikatakan bahwa subclass adalah versi khusus dari kelas super. Gambar berikut menunjukkan contoh generalisasi dan spesialisasi. Link dan Asosiasi Sebuah link mewakili sebuah koneksi dimana sebuah objek bekerja sama dengan objek lain. Rumbaugh telah mendefinisikannya sebagai koneksi fisik atau konseptual antar objek. Melalui sebuah link, satu objek dapat memanggil metode atau menavigasi melalui objek lain. Sebuah link menggambarkan hubungan antara dua atau lebih objek. Asosiasi Asosiasi adalah sekelompok hubungan yang memiliki struktur umum dan perilaku umum. Asosiasi menggambarkan hubungan antara objek dari satu atau lebih kelas. Tautan dapat didefinisikan sebagai instance dari asosiasi. Gelar Asosiasi Tingkat asosiasi menunjukkan jumlah kelas yang terlibat dalam suatu koneksi. Derajat mungkin tidak seragam, biner, atau terner. Hubungan yang tidak jelas menghubungkan objek kelas yang sama. Hubungan biner menghubungkan objek dari dua kelas. Hubungan terner menghubungkan objek dari tiga kelas atau lebih. Rasio Kardinalitas Asosiasi Kardinalitas asosiasi biner menunjukkan jumlah kasus yang berpartisipasi dalam sebuah asosiasi. Ada tiga jenis rasio kardinalitas, yaitu: OnetoOne. Objek tunggal kelas A dikaitkan dengan satu objek kelas B. OnetoMany. Objek tunggal kelas A dikaitkan dengan banyak objek kelas B. ManytoMany. Objek kelas A dapat dikaitkan dengan banyak objek kelas B dan sebaliknya objek kelas B dapat dikaitkan dengan banyak objek kelas A. Agregasi atau Komposisi Agregasi atau komposisi adalah hubungan antara kelas dimana kelas dapat dibuat. Dari kombinasi objek dari kelas lainnya. Hal ini memungkinkan objek ditempatkan secara langsung di dalam tubuh kelas lainnya. Agregasi disebut sebagai partof atau hasa relationship, dengan kemampuan untuk menavigasi dari keseluruhan ke bagian-bagiannya. Objek agregat adalah objek yang terdiri dari satu atau lebih objek lainnya. Dalam hubungan, motor hasa mobil, mobil adalah keseluruhan objek atau agregat, dan motor merupakan bagian dari mobil. Agregasi dapat menunjukkan: Penahanan fisik. Contohnya, komputer terdiri dari monitor, CPU, mouse, keyboard, dan sebagainya. Penahanan konseptual Contoh, pemegang saham hasa share. Manfaat Model Objek Sekarang kita telah melewati konsep inti yang berkaitan dengan orientasi objek, akan bermanfaat untuk mencatat kelebihan yang ditawarkan model ini. Manfaat menggunakan model objek adalah: Ini membantu dalam pengembangan perangkat lunak yang lebih cepat. Mudah dipelihara. Misalkan sebuah modul mengalami kesalahan, maka seorang programmer dapat memperbaiki modul tertentu, sementara bagian lain dari perangkat lunak tersebut masih menyala dan berjalan. Ini mendukung upgrade yang relatif tanpa kerumitan. Ini memungkinkan penggunaan kembali benda, desain, dan fungsi. Ini mengurangi risiko pembangunan, terutama dalam integrasi sistem yang kompleks. Object Oriented System Kita tahu bahwa teknik Object-Oriented Modeling (OOM) memvisualisasikan berbagai hal dalam sebuah aplikasi dengan menggunakan model yang diorganisasikan di sekitar objek. Pendekatan pengembangan perangkat lunak berjalan melalui tahapan berikut: Dalam rekayasa perangkat lunak berorientasi objek, pengembang perangkat lunak mengidentifikasi dan mengatur aplikasi dalam hal konsep berorientasi objek, sebelum representasi terakhir mereka dalam bahasa pemrograman atau perangkat lunak tertentu. Fase dalam Pengembangan Perangkat Lunak Berorientasi Obyek Tahap utama pengembangan perangkat lunak dengan menggunakan metodologi berorientasi objek adalah analisis berorientasi objek, perancangan berorientasi objek, dan implementasi berorientasi objek. Analisis ObjectOriented Pada tahap ini, masalah diformulasikan, persyaratan pengguna diidentifikasi, dan kemudian model dibangun berdasarkan objek realworld. Analisis ini menghasilkan model bagaimana sistem yang diinginkan harus berfungsi dan bagaimana hal itu harus dikembangkan. Model tidak mencakup rincian pelaksanaan sehingga dapat dipahami dan diperiksa oleh ahli aplikasi nonteknis manapun. Desain ObjectOriented Desain berorientasi obyek meliputi dua tahap utama, yaitu perancangan sistem dan desain objek. Perancangan Sistem Pada tahap ini, arsitektur lengkap sistem yang diinginkan didesain. Sistem ini dipahami sebagai seperangkat subsistem interaksi yang pada gilirannya terdiri dari hierarki objek yang berinteraksi, dikelompokkan ke dalam kelas. Perancangan sistem dilakukan sesuai dengan model analisis sistem dan arsitektur sistem yang diusulkan. Di sini, penekanannya adalah pada objek yang terdiri dari sistem daripada proses dalam sistem. Desain Objek Pada tahap ini, model perancangan dikembangkan berdasarkan kedua model yang dikembangkan pada tahap analisis sistem dan arsitektur yang dirancang pada tahap perancangan sistem. Semua kelas yang dibutuhkan diidentifikasi. Perancang memutuskan apakah: kelas baru harus dibuat dari awal, kelas yang ada dapat digunakan dalam bentuk aslinya, atau kelas baru harus diwarisi dari kelas yang ada. Asosiasi antara kelas yang teridentifikasi didirikan dan hierarki kelas diidentifikasi. Selain itu, pengembang merancang rincian internal kelas dan asosiasi mereka, yaitu struktur data untuk setiap atribut dan algoritme untuk operasi. Implementasi dan Pengujian Berorientasi Pada tahap ini, model perancangan yang dikembangkan pada desain objek diterjemahkan ke dalam kode dalam bahasa pemrograman atau perangkat lunak yang sesuai. Database dibuat dan persyaratan perangkat keras tertentu dipastikan. Setelah kode ini dalam bentuk, itu diuji menggunakan teknik khusus untuk mengidentifikasi dan menghapus kesalahan dalam kode. Prinsip Berorientasi Objek Prinsip Sistem Berorientasi Objek Kerangka konseptual dari sistem objectoriented didasarkan pada model objek. Ada dua kategori elemen dalam sistem berorientasi objek: Elemen Utama. Secara mayor, ini berarti bahwa jika sebuah model tidak memiliki salah satu dari elemen-elemen ini, ia berhenti menjadi berorientasi objek. Keempat elemen utama tersebut adalah: Minor Elements. Dengan minor, ini berarti elemen-elemen ini berguna, namun bukan bagian tak terpisahkan dari model objek. Tiga elemen minor adalah: Abstraksi Abstraksi berarti berfokus pada fitur penting dari elemen atau objek di OOP, mengabaikan sifat-sifat yang tidak relevan atau tidak disengaja. Fitur penting relatif terhadap konteks di mana objek sedang digunakan. Grady Booch telah mendefinisikan abstraksi sebagai berikut: Abstraksi menunjukkan karakteristik penting dari objek yang membedakannya dari semua jenis objek lainnya dan dengan demikian memberikan batas konseptual yang didefinisikan dengan singkat, relatif terhadap perspektif pemirsa. Contoh. Ketika seorang siswa kelas dirancang, atribut enrolmentnumber, name, course, dan address disertakan sementara karakteristik seperti pulserate dan sizeofshoe dieliminasi, karena tidak relevan dalam perspektif institusi pendidikan. Enkapsulasi Enkapsulasi adalah proses mengikat kedua atribut dan metode bersama-sama di dalam kelas. Melalui enkapsulasi, rincian internal sebuah kelas dapat disembunyikan dari luar. Kelas memiliki metode yang menyediakan antarmuka pengguna dimana layanan yang diberikan oleh kelas dapat digunakan. Modularitas Modularitas adalah proses penguraian suatu masalah (program) ke dalam satu set modul sehingga dapat mengurangi kompleksitas keseluruhan dari masalah. Booch mendefinisikan modularitas sebagai: Modularitas adalah milik sistem yang telah didekomposisi menjadi seperangkat modul yang digabungkan secara kohesif dan longgar. Modularitas secara intrinsik terkait dengan enkapsulasi. Modularitas dapat divisualisasikan sebagai cara pemetaan abstraksi yang dienkapsulasi menjadi modul fisik yang nyata yang memiliki kohesi tinggi di dalam modul dan interaksi intermodula atau koplingnya rendah. Dalam kata-kata Grady Boochs, Hirarki adalah rangking atau pemesanan abstraksi. Melalui hirarki, sebuah sistem dapat terdiri dari subsistem yang saling terkait, yang dapat memiliki subsistem mereka sendiri dan seterusnya sampai komponen tingkat terkecil tercapai. Ini menggunakan prinsip membagi dan menaklukkan. Hirarki memungkinkan penggunaan kembali kode. Dua jenis hierarki dalam OOA adalah: hirarki ISA. Ini mendefinisikan hubungan hierarkis dalam warisan, di mana dari kelas super, sejumlah subkelas dapat diturunkan yang mungkin lagi memiliki subkelas dan sebagainya. Misalnya, jika kita menurunkan kelas Rose dari kelas Flower, kita dapat mengatakan bahwa bunga mawar adalah bunga. Hirarki PARTOF Ini mendefinisikan hubungan hierarkis dalam agregasi dimana kelas dapat terdiri dari kelas-kelas lain. Misalnya, bunga terdiri dari sepal, kelopak, benang sari, dan carpel. Bisa dikatakan kelopak bunga adalah bagian dari bunga. Menurut teori tipe data abstrak, tipe adalah karakterisasi satu set elemen. Di OOP, kelas divisualisasikan sebagai tipe yang memiliki sifat yang berbeda dari jenis lainnya. Mengetik adalah penegasan gagasan bahwa objek adalah turunan dari satu kelas atau jenis. Ini juga memberlakukan bahwa objek dari berbagai jenis mungkin tidak dapat dipertukarkan secara umum dan dapat dipertukarkan hanya dengan cara yang sangat terbatas jika benar-benar diwajibkan untuk melakukannya. Dua jenis pengetikannya adalah: Strong Typing. Di sini, operasi pada sebuah objek diperiksa pada saat kompilasi, seperti dalam bahasa pemrograman Eiffel. Lemah mengetik Di sini, pesan bisa dikirim ke kelas manapun. Operasi hanya diperiksa pada saat eksekusi, seperti pada bahasa pemrograman Smalltalk. Concurrency Concurrency dalam sistem operasi memungkinkan melakukan banyak tugas atau proses secara simultan. Ketika satu proses ada dalam sebuah sistem, dikatakan bahwa ada satu benang kontrol. Namun, sebagian besar sistem memiliki banyak benang, beberapa aktif, beberapa menunggu CPU, beberapa ditangguhkan, dan beberapa dihentikan. Sistem dengan beberapa CPU secara inheren mengizinkan benang kontrol bersamaan namun sistem yang berjalan pada satu CPU menggunakan algoritma yang tepat untuk memberi waktu CPU yang setara ke benang sehingga memungkinkan konkurensi. Dalam lingkungan berorientasi objek, ada objek aktif dan tidak aktif. Objek aktif memiliki benang kontrol independen yang dapat mengeksekusi bersamaan dengan benang benda lainnya. Objek aktif disinkronkan satu sama lain serta dengan objek berurutan murni. Kegigihan Benda menempati ruang memori dan ada untuk jangka waktu tertentu. Dalam pemrograman tradisional, umur sebuah objek biasanya merupakan masa eksekusi program yang menciptakannya. Dalam file atau database, umur objek lebih panjang dari durasi proses pembuatan objek. Properti dimana objek terus ada bahkan setelah penciptanya tidak lagi dikenal sebagai ketekunan. Analisis Berorientasi Objek Dalam analisis sistem atau tahap analisis berorientasi objek pengembangan perangkat lunak, persyaratan sistem ditentukan, kelas diidentifikasi dan hubungan antar kelas diidentifikasi. Ketiga teknik analisis yang digunakan bersamaan satu sama lain untuk analisis berorientasi obyek adalah pemodelan objek, pemodelan dinamis, dan pemodelan fungsional. Pemodelan Objek Pemodelan objek mengembangkan struktur statis dari sistem perangkat lunak dalam hal objek. Ini mengidentifikasi objek, kelas dimana objek dapat dikelompokkan menjadi dan hubungan antara objek. Ini juga mengidentifikasi atribut dan operasi utama yang menjadi ciri setiap kelas. Proses pemodelan objek dapat divisualisasikan pada langkah-langkah berikut: Mengidentifikasi objek dan kelompok ke dalam kelas Mengidentifikasi hubungan antar kelas Membuat diagram objek objek pengguna Menentukan atribut objek pengguna Tentukan operasi yang harus dilakukan di kelas Review glosarium Dynamic Modeling Setelah statis Perilaku sistem dianalisis, perilakunya berkaitan dengan waktu dan perubahan eksternal perlu diperiksa. Inilah tujuan pemodelan dinamis. Pemodelan Dinamis dapat didefinisikan sebagai cara untuk menggambarkan bagaimana suatu objek individual menanggapi kejadian, baik peristiwa internal yang dipicu oleh benda lain, atau peristiwa eksternal yang dipicu oleh dunia luar. Proses pemodelan dinamis dapat divisualisasikan dalam langkah-langkah berikut: Mengidentifikasi keadaan dari setiap objek Mengidentifikasi kejadian dan menganalisis penerapan tindakan Membangun diagram model dinamis, terdiri dari diagram transisi negara Mengekspresikan setiap keadaan dalam hal atribut objek Memvalidasi diagram statetransisi yang diambil Fungsional Pemodelan Pemodelan Fungsional merupakan komponen akhir dari analisis berorientasi objek. Model fungsional menunjukkan proses yang dilakukan dalam suatu objek dan bagaimana data berubah saat berpindah antar metode. Ini menentukan arti operasi pemodelan objek dan tindakan pemodelan dinamis. Model fungsional sesuai dengan diagram alir data dari analisis terstruktur tradisional. Proses pemodelan fungsional dapat divisualisasikan pada langkah-langkah berikut: Mengidentifikasi semua input dan output Membangun diagram alir data yang menunjukkan ketergantungan fungsional Menentukan tujuan masing-masing fungsi Mengidentifikasi kendala Menentukan kriteria optimasi Analisis Terstruktur vs. Analisis Berorientasi Objek Analisis Terstruktur Desain Terencana (SASD ) Pendekatan tradisional adalah pengembangan perangkat lunak berdasarkan model air terjun. Tahapan pengembangan sistem dengan menggunakan SASD adalah: Studi Kelayakan Persyaratan dan Spesifikasi Desain Sistem Implementasi Review Pasca Implementasi Sekarang, kita akan melihat keuntungan dan kerugian relatif dari pendekatan analisis terstruktur dan pendekatan analisis berorientasi objek. Keuntungan Kelebihan Analisis Berorientasi Objek Berfokus pada data dan bukan pada prosedur seperti dalam Structured Analysis. Fungsionalitas dibatasi di dalam objek. Hal ini dapat menimbulkan masalah bagi sistem yang secara intrinsik bersifat prosedural atau komputasi. Prinsip enkapsulasi dan penyembunyian data membantu pengembang mengembangkan sistem yang tidak dapat dirusak oleh bagian lain dari sistem. Tidak dapat mengidentifikasi objek mana yang akan menghasilkan perancangan sistem yang optimal. Prinsip enkapsulasi dan penyembunyian data membantu pengembang mengembangkan sistem yang tidak dapat dirusak oleh bagian lain dari sistem. Model berorientasi objek tidak mudah menunjukkan komunikasi antar objek dalam sistem. Hal ini memungkinkan pengelolaan kompleksitas perangkat lunak dengan efektif karena modularitas. Semua antarmuka antara objek tidak dapat diwakili dalam satu diagram. Hal ini dapat ditingkatkan dari sistem kecil ke besar lebih mudah daripada sistem yang mengikuti analisis terstruktur. Keuntungan Kelebihan Analisis Terstruktur Karena mengikuti pendekatan top-down yang berlawanan dengan pendekatan bottom-up analisis berorientasi objek, hal itu dapat lebih mudah dipahami daripada OOA. Dalam model analisis terstruktur tradisional, satu tahap harus diselesaikan sebelum fase berikutnya. Hal ini menimbulkan masalah dalam desain, terutama jika kesalahan muncul atau persyaratan berubah. Hal ini didasarkan pada fungsionalitas. Tujuan keseluruhan diidentifikasi dan kemudian dekomposisi fungsional dilakukan untuk mengembangkan perangkat lunak. Penekanan tidak hanya memberikan pemahaman yang lebih baik tentang sistem tetapi juga menghasilkan sistem yang lebih lengkap. Biaya awal untuk membangun sistem tinggi, karena keseluruhan sistem perlu dirancang sekaligus meninggalkan sedikit pilihan untuk menambahkan fungsionalitas di kemudian hari. Spesifikasi di dalamnya ditulis dalam bahasa Inggris sederhana, dan karenanya dapat lebih mudah dianalisis oleh tenaga non-teknis. Ini tidak mendukung penggunaan kembali kode. Jadi, waktu dan biaya pembangunan sangat tinggi. Pemodelan Dinamis Model dinamik mewakili aspek waktu dari satu sistem. Hal ini berkaitan dengan perubahan temporal di negara bagian benda dalam suatu sistem. Konsep utamanya adalah: State, yang merupakan situasi pada kondisi tertentu selama masa sebuah objek. Transisi, sebuah perubahan dalam acara negara, sebuah kejadian yang memicu transisi Aksi, perhitungan atom yang tidak terputus dan terputus yang terjadi karena beberapa kejadian, dan Concurrency of transition. Sebuah mesin negara memodelkan perilaku objek saat melewati sejumlah negara bagian dalam masa hidupnya karena beberapa peristiwa dan juga tindakan yang terjadi karena kejadian tersebut. Mesin negara digambarkan secara grafis melalui diagram transisi keadaan. Negara Bagian dan Transisi Negara Negara adalah abstraksi yang diberikan oleh nilai atribut yang dimiliki objek pada periode waktu tertentu. Ini adalah situasi yang terjadi selama periode waktu yang terbatas dalam masa suatu objek, di mana ia memenuhi kondisi tertentu, melakukan aktivitas tertentu, atau menunggu kejadian tertentu terjadi. Dalam diagram transisi negara, sebuah negara diwakili oleh persegi panjang bulat. Bagian dari nama negara String membedakan satu keadaan dari yang lain. Sebuah negara mungkin tidak memiliki nama apapun. Tindakan EntryExit. Ini menunjukkan aktivitas yang dilakukan saat memasuki dan saat keluar dari negara. Transisi Internal Perubahan dalam keadaan yang tidak menyebabkan perubahan keadaan. Substat. Negara-negara di dalam negara bagian. Initial dan Final States Status awal default dari sebuah objek disebut keadaan semula. Status terakhir menunjukkan selesainya eksekusi mesin negara. Negara awal dan terakhir adalah negara semu, dan mungkin tidak memiliki bagian-bagian dari keadaan biasa kecuali nama. Dalam diagram transisi negara, keadaan awal diwakili oleh lingkaran hitam yang penuh. Status terakhir diwakili oleh lingkaran hitam penuh yang dikelilingi lingkaran hitam yang tidak terisi. Transisi Transisi menunjukkan perubahan dalam keadaan suatu objek. Jika sebuah benda berada dalam keadaan tertentu ketika sebuah peristiwa terjadi, objek dapat melakukan aktivitas tertentu yang tunduk pada kondisi tertentu dan mengubah negara. Dalam kasus ini, statetransisi dikatakan telah terjadi. Transisi memberikan hubungan antara negara pertama dan negara baru. Transisi digambarkan secara grafis oleh busur terarah padat dari keadaan sumber ke negara tujuan. Lima bagian transisi adalah: Source State. Negara terkena transisi. Pemicu Peristiwa Kejadian yang disebabkan oleh suatu objek di negara sumber mengalami transisi jika kondisi penjaga terpenuhi. Kondisi penjaga Ekspresi Boolean yang jika Benar, menyebabkan transisi menerima pemicu acara. Aksi. Perhitungan un-interruptible dan atomic yang terjadi pada objek sumber karena beberapa kejadian. Negara target Negara tujuan setelah selesainya transisi. Misalkan seseorang naik taksi dari tempat X ke tempat Y. Negara bagiannya mungkin: Menunggu (menunggu taksi), Naik (dia sudah naik taksi dan sedang bepergian di dalamnya), dan Mencapai (dia telah mencapai tujuan). Gambar berikut menggambarkan transisi negara. Peristiwa adalah beberapa kejadian yang dapat memicu transisi suatu objek atau sekelompok objek. Acara memiliki lokasi dalam ruang dan waktu namun tidak memiliki jangka waktu yang terkait dengannya. Acara umumnya terkait dengan beberapa tindakan. Contoh kejadian adalah klik mouse, penekanan tombol, interupsi, stack overflow, dll. Peristiwa yang memicu transisi ditulis bersamaan dengan busur transisi dalam diagram keadaan. Mengingat contoh yang ditunjukkan pada gambar di atas, transisi dari status Waiting ke Riding state berlangsung saat orang tersebut mendapat taksi. Begitu juga, keadaan akhir tercapai, saat ia sampai di tempat tujuan. These two occurrences can be termed as events GetTaxi and ReachDestination. The following figure shows the events in a state machine. External and Internal Events External events are those events that pass from a user of the system to the objects within the system. For example, mouse click or keypress by the user are external events. Internal events are those that pass from one object to another object within a system. For example, stack overflow, a divide error, etc. Deferred Events Deferred events are those which are not immediately handled by the object in the current state but are lined up in a queue so that they can be handled by the object in some other state at a later time. Event Classes Event class indicates a group of events with common structure and behavior. As with classes of objects, event classes may also be organized in a hierarchical structure. Event classes may have attributes associated with them, time being an implicit attribute. For example, we can consider the events of departure of a flight of an airline, which we can group into the following class: FlightDeparts (FlightNo, FromCity, ToCity, Route) Activity is an operation upon the states of an object that requires some time period. They are the ongoing executions within a system that can be interrupted. Activities are shown in activity diagrams that portray the flow from one activity to another. An action is an atomic operation that executes as a result of certain events. By atomic, it is meant that actions are un-interruptible, i. e. if an action starts executing, it runs into completion without being interrupted by any event. An action may operate upon an object on which an event has been triggered or on other objects that are visible to this object. A set of actions comprise an activity. Entry and Exit Actions Entry action is the action that is executed on entering a state, irrespective of the transition that led into it. Likewise, the action that is executed while leaving a state, irrespective of the transition that led out of it, is called an exit action. Scenario is a description of a specified sequence of actions. It depicts the behavior of objects undergoing a specific action series. The primary scenarios depict the essential sequences and the secondary scenarios depict the alternative sequences. Diagrams for Dynamic Modelling There are two primary diagrams that are used for dynamic modelling: Interaction Diagrams Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of objects, their relationships, and the message that the objects send and receive. Thus, an interaction models the behavior of a group of interrelated objects. The two types of interaction diagrams are: Sequence Diagram . It represents the temporal ordering of messages in a tabular manner. Collaboration Diagram . It represents the structural organization of objects that send and receive messages through vertices and arcs. State Transition Diagram State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates the sequences of states that an object goes through in its lifetime, the transitions of the states, the events and conditions causing the transition and the responses due to the events. Concurrency of Events In a system, two types of concurrency may exist. They are: System Concurrency Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of state machines, where each state machine executes concurrently with others. Concurrency within an Object Here, an object can issue concurrent events. An object may have states that are composed of sub-states, and concurrent events may occur in each of the sub-states. Concepts related to concurrency within an object are as follows: (a) Simple and Composite States A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity of a state machine. Sub-states can be nested to any number of levels. Composite states may have either sequential sub-states or concurrent sub-states. (b) Sequential Sub-states In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after another in a sequential manner. There is at most one initial state and one final state in these state machines. The following figure illustrates the concept of sequential sub-states. (c) Concurrent Sub-states In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently executing state machines within it. Each of the state machines has its own initial and final states. If one concurrent sub-state reaches its final state before the other, control waits at its final state. When all the nested state machines reach their final states, the sub-states join back to a single flow. The following figure shows the concept of concurrent sub-states. Functional Modelling Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of what the system is supposed to do. It defines the function of the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the functional derivation of the data values without indicating how they are derived when they are computed, or why they need to be computed. Data Flow Diagrams Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation. Rumbaugh et al. have defined DFD as, A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects. The four main parts of a DFD are: The other parts of a DFD are: Features of a DFD Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function. Representation in DFD . A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values. Contoh. The following figure shows a process ComputeHCFLCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple). Data Flows Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow. Representation in DFD . A data flow is represented by a directed arc or an arrow, labelled with the name of the data item that it carries. In the above figure, Integera and Integerb represent the input data flows to the process, while L. C.M. and H. C.F. are the output data flows. A data flow may be forked in the following cases: The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value. The data flow contains an aggregate value, and each of the components is sent to different places as shown in the following figure. Here, each of the forked components is labelled. Actors are the active objects that interact with the system by either producing data and inputting them to the system, or consuming data produced by the system. In other words, actors serve as the sources and the sinks of data. Representation in DFD: An actor is represented by a rectangle. Actors are connected to the inputs and outputs and lie on the boundary of the DFD. Contoh. The following figure shows the actors, namely, Customer and SalesClerk in a counter sales system. Data Stores Data stores are the passive objects that act as a repository of data. Unlike actors, they cannot perform any operations. They are used to store data and retrieve the stored data. They represent a data structure, a disk file, or a table in a database. Representation in DFD . A data store is represented by two parallel lines containing the name of the data store. Each data store is connected to at least one process. Input arrows contain information to modify the contents of the data store, while output arrows contain information retrieved from the data store. When a part of the information is to be retrieved, the output arrow is labelled. An unlabelled arrow denotes full data retrieval. A two-way arrow implies both retrieval and update. Contoh. The following figure shows a data store, SalesRecord, that stores the details of all sales. Input to the data store comprises of details of sales such as item, billing amount, date, etc. To find the average sales, the process retrieves the sales records and computes the average. Constraints Constraints specify the conditions or restrictions that need to be satisfied over time. They allow adding new rules or modifying existing ones. Constraints can appear in all the three models of object-oriented analysis. In Object Modelling, the constraints define the relationship between objects. They may also define the relationship between the different values that an object may take at different times. In Dynamic Modelling, the constraints define the relationship between the states and events of different objects. In Functional Modelling, the constraints define the restrictions on the transformations and computations. Representation . A constraint is rendered as a string within braces. Contoh. The following figure shows a portion of DFD for computing the salary of employees of a company that has decided to give incentives to all employees of the sales department and increment the salary of all employees of the HR department. It can be seen that the constraint causes incentive to be calculated only if the department is sales and the constraint causes increment to be computed only if the department is HR. Control Flows A process may be associated with a certain Boolean value and is evaluated only if the value is true, though it is not a direct input to the process. These Boolean values are called the control flows. Representation in DFD . Control flows are represented by a dotted arc from the process producing the Boolean value to the process controlled by them. Contoh. The following figure represents a DFD for arithmetic division. The Divisor is tested for non-zero. If it is not zero, the control flow OK has a value True and subsequently the Divide process computes the Quotient and the Remainder. Developing the DFD Model of a System In order to develop the DFD model of a system, a hierarchy of DFDs are constructed. The top-level DFD comprises of a single process and the actors interacting with it. At each successive lower level, further details are gradually included. A process is decomposed into sub-processes, the data flows among the sub-processes are identified, the control flows are determined, and the data stores are defined. While decomposing a process, the data flow into or out of the process should match the data flow at the next level of DFD. Contoh. Let us consider a software system, Wholesaler Software, that automates the transactions of a wholesale shop. The shop sells in bulks and has a clientele comprising of merchants and retail shop owners. Each customer is asked to register with hisher particulars and is given a unique customer code, CCode. Once a sale is done, the shop registers its details and sends the goods for dispatch. Each year, the shop distributes Christmas gifts to its customers, which comprise of a silver coin or a gold coin depending upon the total sales and the decision of the proprietor. The functional model for the Wholesale Software is given below. The figure below shows the top-level DFD. It shows the software as a single process and the actors that interact with it. The actors in the system are: In the next level DFD, as shown in the following figure, the major processes of the system are identified, the data stores are defined and the interaction of the processes with the actors, and the data stores are established. In the system, three processes can be identified, which are: Register Customers Process Sales Ascertain Gifts The data stores that will be required are: The following figure shows the details of the process Register Customer. There are three processes in it, Verify Details, Generate CCode, and Update Customer Details. When the details of the customer are entered, they are verified. If the data is correct, CCode is generated and the data store Customer Details is updated. The following figure shows the expansion of the process Ascertain Gifts. It has two processes in it, Find Total Sales and Decide Type of Gift Coin. The Find Total Sales process computes the yearly total sales corresponding to each customer and records the data. Taking this record and the decision of the proprietor as inputs, the gift coins are allotted through Decide Type of Gift Coin process. Advantages and Disadvantages of DFD DFDs depict the boundaries of a system and hence are helpful in portraying the relationship between the external objects and the processes within the system. DFDs take a long time to create, which may not be feasible for practical purposes. They help the users to have a knowledge about the system. DFDs do not provide any information about the time-dependent behavior, i. e. they do not specify when the transformations are done. The graphical representation serves as a blueprint for the programmers to develop a system. They do not throw any light on the frequency of computations or the reasons for computations. DFDs provide detailed information about the system processes. The preparation of DFDs is a complex process that needs considerable expertise. Also, it is difficult for a non-technical person to understand. They are used as a part of the system documentation. The method of preparation is subjective and leaves ample scope to be imprecise. Relationship between Object, Dynamic, and Functional Models The Object Model, the Dynamic Model, and the Functional Model are complementary to each other for a complete Object-Oriented Analysis. Object modelling develops the static structure of the software system in terms of objects. Thus it shows the doers of a system. Dynamic Modelling develops the temporal behavior of the objects in response to external events. It shows the sequences of operations performed on the objects. Functional model gives an overview of what the system should do. Functional Model and Object Model The four main parts of a Functional Model in terms of object model are: Process . Processes imply the methods of the objects that need to be implemented. Actors . Actors are the objects in the object model. Data Stores . These are either objects in the object model or attributes of objects. Data Flows . Data flows to or from actors represent operations on or by objects. Data flows to or from data stores represent queries or updates. Functional Model and Dynamic Model The dynamic model states when the operations are performed, while the functional model states how they are performed and which arguments are needed. As actors are active objects, the dynamic model has to specify when it acts. The data stores are passive objects and they only respond to updates and queries therefore the dynamic model need not specify when they act. Object Model and Dynamic Model The dynamic model shows the status of the objects and the operations performed on the occurrences of events and the subsequent changes in states. The state of the object as a result of the changes is shown in the object model. UML Analysis Model The Unified Modeling Language (UML) is a graphical language for OOAD that gives a standard way to write a software systems blueprint. It helps to visualize, specify, construct, and document the artifacts of an object-oriented system. It is used to depict the structures and the relationships in a complex system. Brief History It was developed in 1990s as an amalgamation of several techniques, prominently OOAD technique by Grady Booch, OMT (Object Modeling Technique) by James Rumbaugh, and OOSE (Object Oriented Software Engineering) by Ivar Jacobson. UML attempted to standardize semantic models, syntactic notations, and diagrams of OOAD. Systems and Models in UML System . A set of elements organized to achieve certain objectives form a system. Systems are often divided into subsystems and described by a set of models. Model . Model is a simplified, complete, and consistent abstraction of a system, created for better understanding of the system. View . A view is a projection of a systems model from a specific perspective. Conceptual Model of UML The Conceptual Model of UML encompasses three major elements: Basic building blocks Rules Common mechanisms Basic Building Blocks The three building blocks of UML are: There are four kinds of things in UML, namely: Structural Things . These are the nouns of the UML models representing the static elements that may be either physical or conceptual. The structural things are class, interface, collaboration, use case, active class, components, and nodes. Behavioral Things . These are the verbs of the UML models representing the dynamic behavior over time and space. The two types of behavioral things are interaction and state machine. Grouping Things . They comprise the organizational parts of the UML models. There is only one kind of grouping thing, i. e. package. Annotational Things . These are the explanations in the UML models representing the comments applied to describe elements. Relationships are the connection between things. The four types of relationships that can be represented in UML are: Dependency . This is a semantic relationship between two things such that a change in one thing brings a change in the other. The former is the independent thing, while the latter is the dependent thing. Association . This is a structural relationship that represents a group of links having common structure and common behavior. Generalization . This represents a generalizationspecialization relationship in which subclasses inherit structure and behavior from super-classes. Realisasi. This is a semantic relationship between two or more classifiers such that one classifier lays down a contract that the other classifiers ensure to abide by. (c) Diagrams . A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML includes nine diagrams in all, namely: Class Diagram Object Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram UML has a number of rules so that the models are semantically self-consistent and related to other models in the system harmoniously. UML has semantic rules for the following: Common Mechanisms UML has four common mechanisms: Specifications Adornments Common Divisions Extensibility Mechanisms Specifications In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. These are the specifications. The specifications provide a semantic backplane that contains all the parts of a system and the relationship among the different paths. Adornments Each element in UML has a unique graphical notation. Besides, there are notations to represent the important aspects of an element like name, scope, visibility, etc. Common Divisions Object-oriented systems can be divided in many ways. The two common ways of division are: Division of classes and objects . A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system. Division of Interface and Implementation . An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in the interface. Extensibility Mechanisms UML is an open-ended language. It is possible to extend the capabilities of UML in a controlled manner to suit the requirements of a system. The extensibility mechanisms are: Stereotypes . It extends the vocabulary of the UML, through which new building blocks can be created out of existing ones. Tagged Values . It extends the properties of UML building blocks. Constraints . It extends the semantics of UML building blocks. UML Basic Notations UML defines specific notations for each of the building blocks. A class is represented by a rectangle having three sections: the top section containing the name of the class the middle section containing class attributes the bottom section representing operations of the class The visibility of the attributes and operations can be represented in the following ways: Public . A public member is visible from anywhere in the system. In class diagram, it is prefixed by the symbol . Private . A private member is visible only from within the class. It cannot be accessed from outside the class. A private member is prefixed by the symbol . Protected . A protected member is visible from within the class and from the subclasses inherited from this class, but not from outside. It is prefixed by the symbol . An abstract class has the class name written in italics. Contoh. Let us consider the Circle class introduced earlier. The attributes of Circle are x-coord, y-coord, and radius. The operations are findArea(), findCircumference(), and scale(). Let us assume that x-coord and y-coord are private data members, radius is a protected data member, and the member functions are public. The following figure gives the diagrammatic representation of the class. An object is represented as a rectangle with two sections: The top section contains the name of the object with the name of the class or package of which it is an instance of. The name takes the following forms: object-name . class-name. package-name class-name . in case of anonymous objects The bottom section represents the values of the attributes. It takes the form attribute-name value. Sometimes objects are represented using rounded rectangles. Contoh. Let us consider an object of the class Circle named c1. We assume that the center of c1 is at (2, 3) and the radius of c1 is 5. The following figure depicts the object. A component is a physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces. It represents the physical packaging of elements like classes and interfaces. Notation . In UML diagrams, a component is represented by a rectangle with tabs as shown in the figure below. Interface is a collection of methods of a class or component. It specifies the set of services that may be provided by the class or component. Notation . Generally, an interface is drawn as a circle together with its name. An interface is almost always attached to the class or component that realizes it. The following figure gives the notation of an interface. A package is an organized group of elements. A package may contain structural things like classes, components, and other packages in it. Notation . Graphically, a package is represented by a tabbed folder. A package is generally drawn with only its name. However it may have additional details about the contents of the package. See the following figures. Relationship The notations for the different types of relationships are as follows: Usually, elements in a relationship play specific roles in the relationship. A role name signifies the behavior of an element participating in a certain context. Contoh. The following figures show examples of different relationships between classes. The first figure shows an association between two classes, Department and Employee, wherein a department may have a number of employees working in it. Worker is the role name. The 1 alongside Department and alongside Employee depict that the cardinality ratio is onetomany. The second figure portrays the aggregation relationship, a University is the wholeof many Departments. UML Structured Diagrams UML structural diagrams are categorized as follows: class diagram, object diagram, component diagram, and deployment diagram. Class Diagram A class diagram models the static view of a system. It comprises of the classes, interfaces, and collaborations of a system and the relationships between them. Class Diagram of a System Let us consider a simplified Banking System. A bank has many branches. In each zone, one branch is designated as the zonal head office that supervises the other branches in that zone. Each branch can have multiple accounts and loans. An account may be either a savings account or a current account. A customer may open both a savings account and a current account. However, a customer must not have more than one savings account or current account. A customer may also procure loans from the bank. The following figure shows the corresponding class diagram. Classes in the system: Bank, Branch, Account, Savings Account, Current Account, Loan, and Customer. Relationships: A Bank hasa number of Branches . composition, onetomany A Branch with role Zonal Head Office supervises other Branches . unary association, oneto-many A Branch hasa number of accounts . aggregation, onetomany From the class Account, two classes have inherited, namely, Savings Account and Current Account. A Customer can have one Current Account . association, onetoone A Customer can have one Savings Account . association, onetoone A Branch hasa number of Loans . aggregation, onetomany A Customer can take many loans . association, onetomany Object Diagram An object diagram models a group of objects and their links at a point of time. It shows the instances of the things in a class diagram. Object diagram is the static part of an interaction diagram. Contoh. The following figure shows an object diagram of a portion of the class diagram of the Banking System. Component Diagram Component diagrams show the organization and dependencies among a group of components. Component diagrams comprise of: Components Interfaces Relationships Packages and Subsystems (optional) Component diagrams are used for: constructing systems through forward and reverse engineering. modeling configuration management of source code files while developing a system using an object-oriented programming language. representing schemas in modeling databases. modeling behaviors of dynamic systems. The following figure shows a component diagram to model a systems source code that is developed using C. It shows four source code files, namely, myheader. h, otherheader. h, priority. cpp, and other. cpp. Two versions of myheader. h are shown, tracing from the recent version to its ancestor. The file priority. cpp has compilation dependency on other. cpp. The file other. cpp has compilation dependency on otherheader. h. Deployment Diagram A deployment diagram puts emphasis on the configuration of runtime processing nodes and their components that live on them. They are commonly comprised of nodes and dependencies, or associations between the nodes. Deployment diagrams are used to: model devices in embedded systems that typically comprise of software-intensive collection of hardware. represent the topologies of clientserver systems. model fully distributed systems. The following figure shows the topology of a computer system that follows clientserver architecture. The figure illustrates a node stereotyped as server that comprises of processors. The figure indicates that four or more servers are deployed at the system. Connected to the server are the client nodes, where each node represents a terminal device such as workstation, laptop, scanner, or printer. The nodes are represented using icons that clearly depict the real-world equivalent. UML Behavioural Diagrams UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system. The behavioral diagrams are categorized as follows: use case diagrams, interaction diagrams, statechart diagrams, and activity diagrams. Use Case Model (a) Use case A use case describes the sequence of actions a system performs yielding visible results. It shows the interaction of things outside the system with the system itself. Use cases may be applied to the whole system as well as a part of the system. An actor represents the roles that the users of the use cases play. An actor may be a person (e. g. student, customer), a device (e. g. workstation), or another system (e. g. bank, institution). The following figure shows the notations of an actor named Student and a use case called Generate Performance Report. (c) Use case diagrams Use case diagrams present an outside view of the manner the elements in a system behave and how they can be used in the context. Use case diagrams comprise of: Use cases Actors Relationships like dependency, generalization, and association Use case diagrams are used: To model the context of a system by enclosing all the activities of a system within a rectangle and focusing on the actors outside the system by interacting with it. To model the requirements of a system from the outside point of view. Let us consider an Automated Trading House System. We assume the following features of the system: The trading house has transactions with two types of customers, individual customers and corporate customers. Once the customer places an order, it is processed by the sales department and the customer is given the bill. The system allows the manager to manage customer accounts and answer any queries posted by the customer. Interaction Diagrams Interaction diagrams depict interactions of objects and their relationships. They also include the messages passed between them. There are two types of interaction diagrams: Sequence Diagrams Collaboration Diagrams Interaction diagrams are used for modeling: the control flow by time ordering using sequence diagrams. the control flow of organization using collaboration diagrams. Sequence Diagrams Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to time. Notations . These diagrams are in the form of two-dimensional charts. The objects that initiate the interaction are placed on the xaxis. The messages that these objects send and receive are placed along the yaxis, in the order of increasing time from top to bottom. Contoh. A sequence diagram for the Automated Trading House System is shown in the following figure. Collaboration Diagrams Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send and receive messages. Notations . In these diagrams, the objects that participate in the interaction are shown using vertices. The links that connect the objects are used to send and receive messages. The message is shown as a labeled arrow. Contoh. Collaboration diagram for the Automated Trading House System is illustrated in the figure below. StateChart Diagrams A statechart diagram shows a state machine that depicts the control flow of an object from one state to another. A state machine portrays the sequences of states which an object undergoes due to events and their responses to events. StateChart Diagrams comprise of: States: Simple or Composite Transitions between states Events causing transitions Actions due to the events State-chart diagrams are used for modeling objects which are reactive in nature. In the Automated Trading House System, let us model Order as an object and trace its sequence. The following figure shows the corresponding statechart diagram. Activity Diagrams An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state machine. Activities result in actions which are atomic operations. Activity diagrams comprise of: Activity states and action states Transitions Objects Activity diagrams are used for modeling: workflows as viewed by actors, interacting with the system. details of operations or computations using flowcharts. The following figure shows an activity diagram of a portion of the Automated Trading House System. Object Oriented Design After the analysis phase, the conceptual model is developed further into an object-oriented model using object-oriented design (OOD). In OOD, the technology-independent concepts in the analysis model are mapped onto implementing classes, constraints are identified, and interfaces are designed, resulting in a model for the solution domain. In a nutshell, a detailed description is constructed specifying how the system is to be built on concrete technologies The stages for objectoriented design can be identified as: Definition of the context of the system Designing system architecture Identification of the objects in the system Construction of design models Specification of object interfaces Object-Oriented System Design System Design Object-oriented system design involves defining the context of a system followed by designing the architecture of the system. Context . The context of a system has a static and a dynamic part. The static context of the system is designed using a simple block diagram of the whole system which is expanded into a hierarchy of subsystems. The subsystem model is represented by UML packages. The dynamic context describes how the system interacts with its environment. It is modelled using use case diagrams . System Architecture . The system architecture is designed on the basis of the context of the system in accordance with the principles of architectural design as well as domain knowledge. Typically, a system is partitioned into layers and each layer is decomposed to form the subsystems. Object-Oriented Decomposition Decomposition means dividing a large complex system into a hierarchy of smaller components with lesser complexities, on the principles of divideandconquer. Each major component of the system is called a subsystem. Object-oriented decomposition identifies individual autonomous objects in a system and the communication among these objects. The advantages of decomposition are: The individual components are of lesser complexity, and so more understandable and manageable. It enables division of workforce having specialized skills. It allows subsystems to be replaced or modified without affecting other subsystems. Identifying Concurrency Concurrency allows more than one objects to receive events at the same time and more than one activity to be executed simultaneously. Concurrency is identified and represented in the dynamic model. To enable concurrency, each concurrent element is assigned a separate thread of control. If the concurrency is at object level, then two concurrent objects are assigned two different threads of control. If two operations of a single object are concurrent in nature, then that object is split among different threads. Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a clear strategy needs to be made whenever concurrency is required. Besides, concurrency requires to be identified at the design stage itself, and cannot be left for implementation stage. Identifying Patterns While designing applications, some commonly accepted solutions are adopted for some categories of problems. These are the patterns of design. A pattern can be defined as a documented set of building blocks that can be used in certain types of application development problems. Some commonly used design patterns are: Faade pattern Model view separation pattern Observer pattern Model view controller pattern Publish subscribe pattern Proxy pattern Controlling Events During system design, the events that may occur in the objects of the system need to be identified and appropriately dealt with. An event is a specification of a significant occurrence that has a location in time and space. There are four types of events that can be modelled, namely: Signal Event . A named object thrown by one object and caught by another object. Call Event . A synchronous event representing dispatch of an operation. Time Event . An event representing passage of time. Change Event . An event representing change in state. Handling Boundary Conditions The system design phase needs to address the initialization and the termination of the system as a whole as well as each subsystem. The different aspects that are documented are as follows: The startup of the system, i. e. the transition of the system from non-initialized state to steady state. The termination of the system, i. e. the closing of all running threads, cleaning up of resources, and the messages to be sent. The initial configuration of the system and the reconfiguration of the system when needed. Foreseeing failures or undesired termination of the system. Boundary conditions are modelled using boundary use cases. Object Design After the hierarchy of subsystems has been developed, the objects in the system are identified and their details are designed. Here, the designer details out the strategy chosen during the system design. The emphasis shifts from application domain concepts toward computer concepts. The objects identified during analysis are etched out for implementation with an aim to minimize execution time, memory consumption, and overall cost. Object design includes the following phases: Object identification Object representation, i. e. construction of design models Classification of operations Algorithm design Design of relationships Implementation of control for external interactions Package classes and associations into modules Object Identification The first step of object design is object identification. The objects identified in the objectoriented analysis phases are grouped into classes and refined so that they are suitable for actual implementation. The functions of this stage are: Identifying and refining the classes in each subsystem or package Defining the links and associations between the classes Designing the hierarchical associations among the classes, i. e. the generalizationspecialization and inheritances Object Representation Once the classes are identified, they need to be represented using object modelling techniques. This stage essentially involves constructing UML diagrams. There are two types of design models that need to be produced: Static Models . To describe the static structure of a system using class diagrams and object diagrams. Dynamic Models . To describe the dynamic structure of a system and show the interaction between classes using interaction diagrams and statechart diagrams. Classification of Operations In this step, the operation to be performed on objects are defined by combining the three models developed in the OOA phase, namely, object model, dynamic model, and functional model. An operation specifies what is to be done and not how it should be done. The following tasks are performed regarding operations: The state transition diagram of each object in the system is developed. Operations are defined for the events received by the objects. Cases in which one event triggers other events in same or different objects are identified. The suboperations within the actions are identified. The main actions are expanded to data flow diagrams. Algorithm Design The operations in the objects are defined using algorithms. An algorithm is a stepwise procedure that solves the problem laid down in an operation. Algorithms focus on how it is to be done. There may be more than one algorithm corresponding to a given operation. Once the alternative algorithms are identified, the optimal algorithm is selected for the given problem domain. The metrics for choosing the optimal algorithm are: Computational Complexity . Complexity determines the efficiency of an algorithm in terms of computation time and memory requirements. Fleksibilitas. Flexibility determines whether the chosen algorithm can be implemented suitably, without loss of appropriateness in various environments. Understandability . This determines whether the chosen algorithm is easy to understand and implement. Design of Relationships The strategy to implement the relationships needs to be chalked out during the object design phase. The main relationships that are addressed comprise of associations, aggregations, and inheritances. The designer should do the following regarding associations: Identify whether an association is unidirectional or bidirectional. Analyze the path of associations and update them if necessary. Implement the associations as a distinct object, in case of manyto-many relationships or as a link to other object in case of oneto-one or oneto-many relationships. Regarding inheritances, the designer should do the following: Adjust the classes and their associations. Identify abstract classes. Make provisions so that behaviors are shared when needed. Implementation of Control The object designer may incorporate refinements in the strategy of the statechart model. In system design, a basic strategy for realizing the dynamic model is made. During object design, this strategy is aptly embellished for appropriate implementation. The approaches for implementation of the dynamic model are: Represent State as a Location within a Program . This is the traditional procedure-driven approach whereby the location of control defines the program state. A finite state machine can be implemented as a program. A transition forms an input statement, the main control path forms the sequence of instructions, the branches form the conditions, and the backward paths form the loops or iterations. State Machine Engine . This approach directly represents a state machine through a state machine engine class. This class executes the state machine through a set of transitions and actions provided by the application. Control as Concurrent Tasks . In this approach, an object is implemented as a task in the programming language or the operating system. Here, an event is implemented as an inter-task call. It preserves inherent concurrency of real objects. Packaging Classes In any large project, meticulous partitioning of an implementation into modules or packages is important. During object design, classes and objects are grouped into packages to enable multiple groups to work cooperatively on a project. The different aspects of packaging are: Hiding Internal Information from Outside View . It allows a class to be viewed as a black box and permits class implementation to be changed without requiring any clients of the class to modify code. Coherence of Elements . An element, such as a class, an operation, or a module, is coherent if it is organized on a consistent plan and all its parts are intrinsically related so that they serve a common goal. Construction of Physical Modules . The following guidelines help while constructing physical modules: Classes in a module should represent similar things or components in the same composite object. Closely connected classes should be in the same module. Unconnected or weakly connected classes should be placed in separate modules. Modules should have good cohesion, i. e. high cooperation among its components. A module should have low coupling with other modules, i. e. interaction or interdependence between modules should be minimum. Design Optimization The analysis model captures the logical information about the system, while the design model adds details to support efficient information access. Before a design is implemented, it should be optimized so as to make the implementation more efficient. The aim of optimization is to minimize the cost in terms of time, space, and other metrics. However, design optimization should not be excess, as ease of implementation, maintainability, and extensibility are also important concerns. It is often seen that a perfectly optimized design is more efficient but less readable and reusable. So the designer must strike a balance between the two. The various things that may be done for design optimization are: Add redundant associations Omit non-usable associations Optimization of algorithms Save derived attributes to avoid re-computation of complex expressions Addition of Redundant Associations During design optimization, it is checked if deriving new associations can reduce access costs. Though these redundant associations may not add any information, they may increase the efficiency of the overall model. Omission of Non-Usable Associations Presence of too many associations may render a system indecipherable and hence reduce the overall efficiency of the system. So, during optimization, all non-usable associations are removed. Optimization of Algorithms In object-oriented systems, optimization of data structure and algorithms are done in a collaborative manner. Once the class design is in place, the operations and the algorithms need to be optimized. Optimization of algorithms is obtained by: Rearrangement of the order of computational tasks Reversal of execution order of loops from that laid down in the functional model Removal of dead paths within the algorithm Saving and Storing of Derived Attributes Derived attributes are those attributes whose values are computed as a function of other attributes (base attributes). Re-computation of the values of derived attributes every time they are needed is a timeconsuming procedure. To avoid this, the values can be computed and stored in their computed forms. However, this may pose update anomalies, i. e. a change in the values of base attributes with no corresponding change in the values of the derived attributes. To avoid this, the following steps are taken: With each update of the base attribute value, the derived attribute is also re-computed. All the derived attributes are re-computed and updated periodically in a group rather than after each update. Design Documentation Documentation is an essential part of any software development process that records the procedure of making the software. The design decisions need to be documented for any nontrivial software system for transmitting the design to others. Usage Areas Though a secondary product, a good documentation is indispensable, particularly in the following areas: In designing software that is being developed by a number of developers In iterative software development strategies In developing subsequent versions of a software project For evaluating a software For finding conditions and areas of testing For maintenance of the software. A beneficial documentation should essentially include the following contents: Highlevel system architecture . Process diagrams and module diagrams Key abstractions and mechanisms . Class diagrams and object diagrams. Scenarios that illustrate the behavior of the main aspects . Behavioural diagrams The features of a good documentation are: Concise and at the same time, unambiguous, consistent, and complete Traceable to the systems requirement specifications Well-structured Diagrammatic instead of descriptive OOAD Implementation Strategies Implementing an object-oriented design generally involves using a standard object oriented programming language (OOPL) or mapping object designs to databases. In most cases, it involves both. Implementation using Programming Languages Usually, the task of transforming an object design into code is a straightforward process. Any object-oriented programming language like C, Java, Smalltalk, C and Python, includes provision for representing classes. In this chapter, we exemplify the concept using C. The following figure shows the representation of the class Circle using C. Implementing Associations Most programming languages do not provide constructs to implement associations directly. So the task of implementing associations needs considerable thought. Associations may be either unidirectional or bidirectional. Besides, each association may be either onetoone, onetomany, or manytomany. Unidirectional Associations For implementing unidirectional associations, care should be taken so that unidirectionality is maintained. The implementations for different multiplicity are as follows: Optional Associations . Here, a link may or may not exist between the participating objects. For example, in the association between Customer and Current Account in the figure below, a customer may or may not have a current account. For implementation, an object of Current Account is included as an attribute in Customer that may be NULL. Implementation using C: Onetoone Associations . Here, one instance of a class is related to exactly one instance of the associated class. For example, Department and Manager have onetoone association as shown in the figure below. This is implemented by including in Department, an object of Manager that should not be NULL. Implementation using C: Onetomany Associations . Here, one instance of a class is related to more than one instances of the associated class. For example, consider the association between Employee and Dependent in the following figure. This is implemented by including a list of Dependents in class Employee. Implementation using C STL list container: Bi-directional Associations To implement bi-directional association, links in both directions require to be maintained. Optional or onetoone Associations . Consider the relationship between Project and Project Manager having onetoone bidirectional association as shown in the figure below. Implementation using C: Onetomany Associations . Consider the relationship between Department and Employee having onetomany association as shown in the figure below. Implementation using C STL list container: Implementing Associations as Classes If an association has some attributes associated, it should be implemented using a separate class. For example, consider the onetoone association between Employee and Project as shown in the figure below. Implementation of WorksOn using C: Implementing Constraints Constraints in classes restrict the range and type of values that the attributes may take. In order to implement constraints, a valid default value is assigned to the attribute when an object is instantiated from the class. Whenever the value is changed at runtime, it is checked whether the value is valid or not. An invalid value may be handled by an exception handling routine or other methods. Consider an Employee class where age is an attribute that may have values in the range of 18 to 60. The following C code incorporates it: Implementing State Charts There are two alternative implementation strategies to implement states in state chart diagrams. Enumerations within Class In this approach, the states are represented by different values of a data member (or set of data members). The values are explicitly defined by an enumeration within the class. The transitions are represented by member functions that change the value of the concerned data member. Arrangement of Classes in a Generalization Hierarchy In this approach, the states are arranged in a generalization hierarchy in a manner that they can be referred by a common pointer variable. The following figure shows a transformation from state chart diagram to a generalization hierarchy. Object Mapping to Database System Persistency of Objects An important aspect of developing object-oriented systems is persistency of data. Through persistency, objects have longer lifespan than the program that created it. Persistent data is saved on secondary storage medium from where it can be reloaded when required. Overview of RDBMS A database is an ordered collection of related data. A database management system (DBMS) is a collection of software that facilitates the processes of defining, creating, storing, manipulating, retrieving, sharing, and removing data in databases. In relational database management systems (RDBMS), data is stored as relations or tables, where each column or field represents an attribute and each row or tuple represents a record of an instance. Each row is uniquely identified by a chosen set of minimal attributes called primary key . A foreign key is an attribute that is the primary key of a related table. Representing Classes as Tables in RDBMS To map a class to a database table, each attribute is represented as a field in the table. Either an existing attribute(s) is assigned as a primary key or a separate ID field is added as a primary key. The class may be partitioned horizontally or vertically as per requirement. For example, the Circle class can be converted to table as shown in the figure below. Mapping Associations to Database Tables OnetoOne Associations To implement 1:1 associations, the primary key of any one table is assigned as the foreign key of the other table. For example, consider the association between Department and Manager: SQL commands to create the tables: OnetoMany Associations To implement 1:N associations, the primary key of the table in the 1-side of the association is assigned as the foreign key of the table at the N-side of the association. For example, consider the association between Department and Employee: SQL commands to create the tables: ManytoMany Associations To implement M:N associations, a new relation is created that represents the association. For example, consider the following association between Employee and Project: Schema for WorksOn Table . WORKSON (EMPID, PID, HOURS, STARTDATE) SQL command to create WorksOn association :CREATE TABLE WORKSON Mapping Inheritance to Tables To map inheritance, the primary key of the base table(s) is assigned as the primary key as well as the foreign key in the derived table(s). OOAD Testing and Quality Assurance Once a program code is written, it must be tested to detect and subsequently handle all errors in it. A number of schemes are used for testing purposes. Another important aspect is the fitness of purpose of a program that ascertains whether the program serves the purpose which it aims for. The fitness defines the software quality. Testing Object-Oriented Systems Testing is a continuous activity during software development. In object-oriented systems, testing encompasses three levels, namely, unit testing, subsystem testing, and system testing. Unit Testing In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented as per design and whether the methods and the interfaces are error-free. Unit testing is the responsibility of the application engineer who implements the structure. Subsystem Testing This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead. It involves testing the associations within the subsystem as well as the interaction of the subsystem with the outside. Subsystem tests can be used as regression tests for each newly released version of the subsystem. System Testing System testing involves testing the system as a whole and is the responsibility of the quality-assurance team. The team often uses system tests as regression tests when assembling new releases. Object-Oriented Testing Techniques Grey Box Testing The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. Some of the important types of grey box testing are: State model based testing . This encompasses state coverage, state transition coverage, and state transition path coverage. Use case based testing . Each scenario in each use case is tested. Class diagram based testing . Each class, derived class, associations, and aggregations are tested. Sequence diagram based testing . The methods in the messages in the sequence diagrams are tested. Techniques for Subsystem Testing The two main approaches of subsystem testing are: Thread based testing . All classes that are needed to realize a single use case in a subsystem are integrated and tested. Use based testing . The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems. Categories of System Testing Alpha testing . This is carried out by the testing team within the organization that develops software. Beta testing . This is carried out by select group of co-operating customers. Acceptance testing . This is carried out by the customer before accepting the deliverables. Software Quality Assurance Software Quality Schulmeyer and McManus have defined software quality as the fitness for use of the total software product. A good quality software does exactly what it is supposed to do and is interpreted in terms of satisfaction of the requirement specification laid down by the user. Quality Assurance Software quality assurance is a methodology that determines the extent to which a software product is fit for use. The activities that are included for determining software quality are: Auditing Development of standards and guidelines Production of reports Review of quality system Quality Factors Correctness . Correctness determines whether the software requirements are appropriately met. Usability . Usability determines whether the software can be used by different categories of users (beginners, non-technical, and experts). Portability . Portability determines whether the software can operate in different platforms with different hardware devices. Maintainability . Maintainability determines the ease at which errors can be corrected and modules can be updated. Reusability . Reusability determines whether the modules and classes can be reused for developing other software products. Object-Oriented Metrics Metrics can be broadly classified into three categories: project metrics, product metrics, and process metrics. Project Metrics Project Metrics enable a software project manager to assess the status and performance of an ongoing project. The following metrics are appropriate for object-oriented software projects: Number of scenario scripts Number of key classes Number of support classes Number of subsystems Product Metrics Product metrics measure the characteristics of the software product that has been developed. The product metrics suitable for object-oriented systems are: Methods per Class . It determines the complexity of a class. If all the methods of a class are assumed to be equally complex, then a class with more methods is more complex and thus more susceptible to errors. Inheritance Structure . Systems with several small inheritance lattices are more wellstructured than systems with a single large inheritance lattice. As a thumb rule, an inheritance tree should not have more than 7 ( 2) number of levels and the tree should be balanced. Coupling and Cohesion . Modules having low coupling and high cohesion are considered to be better designed, as they permit greater reusability and maintainability. Response for a Class . It measures the efficiency of the methods that are called by the instances of the class. Process Metrics Process metrics help in measuring how a process is performing. They are collected over all projects over long periods of time. They are used as indicators for long-term software process improvements. Some process metrics are: Number of KLOC (Kilo Lines of Code) Defect removal efficiency Average number of failures detected during testing Number of latent defects per KLOC
No comments:
Post a Comment