4. Analisis Berorientasi Objek
Analisis Berorientasi Objek (Object Oriented Analysis – OOA)
Merupakan tahapan untuk menganalisis spesifikasi atau kebutuhan
akan sistem yang akan dibangun dengan konsep berorientasi
objek, apakah benar kebutuhan yang ada dapat diimplementasikan
menjadi sebuah sistem berorientasi objek.
OOA biasanya menggunakan kartu CRC (Component,
Responsibility, Collaborator) untuk membangun kelas-kelas yang
akan digunakan menggunakan UML (Unified Modelling Language).
5. Analisis Berorientasi Objek
Perkembangan pemodelan berorientasi objek, sebelum
menggunakan UML :
Pemodelan OO
CRC – Component,
Responsibility,
Collaborator
Metode Booch
OMT – Object
Modelling Technique
Metode Coad
Yourdon
OOSE – Object
Oriented Software
Engineering
6. Analisis Berorientasi Objek
CRC
Component, Responsibility, Collaborator diperkenalkan oleh Kent
Beck dan Ward Cunningham pada tahun 1989 sebagai bagian dari
dari Object-Oriented Programming, Systems, Languages and
Application (OOPSLA) .
CRC Kelas yang akan dianalisis
7. Analisis Berorientasi Objek
Contoh Kartu CRC :
Nama Kelas (Class Name) : Manusia
Kelas Orang Tua (Superclasses) :
Kelas Anak (Subclasses) :
Tanggung Jawab
(Responsibilities)
Kelas Terkait (Collaborators)
Jenis Kelamin
Usia
Menghitung usia pada tahun
yang diberikan
Kemampuan memasak
Masakan, Resep
8. Analisis Berorientasi Objek
Keterangan Kartu CRC :
1. Nama Kelas (Class Name) : nama yang diberikan pada sebuah
kelas
2. Kelas Orang Tua (Superclasses) : kelas orang tua (dalam
hubungan pewarisan) atau kelas super dari kelas yang akan
dibuat CRC-nya
3. Kelas Anak (Subclasses) : kelas anak (dalam hubungan
pewarisan) atau subkelas dari kelas yang akan dibuat CRC-nya
4. Tanggung Jawab (Responsibilities) : merupakan isi atribut dan
operasi yang harus ada dalam kelas yang dibuat CRC-nya
5. Kelas terkait (Collaborators) : kelas yang akan bekerja sama
dengan kelas yang sedang dibuat CRC-nya, tetapi bukan
merupakan kelas orang tua atau kelas anak
CRC dibuat per kelas sesuai yang dibutuhkan pada sistem/aplikasi
yang akan dibangun beserta dengan kelas orang tua dan kelas
anak.
9. Analisis Berorientasi Objek
Metode Booch
Metode ini dikembangkan oleh Grady Booch pada tahun 1991.
Metode Booch terdiri dari 6 (enam) diagram antara lain :
1. Diagram kelas
2. Objek
3. Transisi status
4. Interaksi
5. Modul
6. Proses
10. Analisis Berorientasi Objek
Berikut Contoh Diagram dari Metode Booch :
Nama Kelas
--------------
Atribut
Operasi
Nama Kelas
--------------
Atribut
Operasi
Nama Kelas
--------------
Atribut
Operasi
Nama Kelas
--------------
Atribut
Operasi
digunakan
diinisiasi
memiliki
11. Analisis Berorientasi Objek
OMT
Object Modelling Technique dikembangkan oleh James Rambaugh,
Blaha, Premerlani, Eddy dan Lorensen sebagai metode untuk
mengembangkan sistem berorientasi objek, dan untuk mendukung
pemrograman berorientasi objek pada tahun 1991.
13. Analisis Berorientasi Objek
Metode Coad Yourdon
Metode ini dperkenalkan pada tahun 1991. Metode Coad Yourdon
menyediakan sebuah diagram kelas. Diagram kelas pada metode
ini dibuat dengan langkah sebagai berikut :
1. Mengidentifikasi kelas dan objek
2. Mengidentifikasi struktur kelas dan objek
3. Mendefinisikan subjek nama kelas
4. Mendefinisikan atribut
5. Mendefinisikan operasi/layanan (services)
15. Analisis Berorientasi Objek
OOSE (Object Oriented Software Engineering)
Metode ini dikembangkan oleh Ivar Jacobson pada tahun 1992.
OOSE adalah metodologi desain berorientasi objek yang mulai
melibatkan Use Case (penggunaan kasus). Berikut adalah contoh
diagram Use Case pada metodologi OOSE :
17. Desain Berorientasi Objek
Desain berorientasi objek (Object Oriented Design – OOD)
Merupakan tahapan perantara untuk memetakan spesifikasi atau
kebutuhan sistem yang akan dibangun dengan konsep berorientasi
objek ke desain pemodelan agar lebih mudah diimplementasikan
dengan pemrograman berorientasi objek.
Pemrograman berorientasi objek dimodelkan dengan UML (Unified
Modelling Language)
OOA dan OOD dalam proses yang berulang-ulang seringnya
memiliki batasan yang samar, sehingga kedua tahapan ini sering
juga disebut OOAD (Object Oriented Analysis and Design).
18. CASE Tools
CASE (Computer Aided Software Engineering) tools atau perangkat
pembantu berbasis komputer untuk rekayasa perangkat lunak
Merupakan aplikasi atau perangkat lunak yang membantu
pembuatan sebuah sistem perangkat lunak.
CASE Tools mulai digunakan oleh pelaku rekayasa perangkat lunak
sejak awak tahun 1980-an dimana fokus pada :
1. Tahap pengumpulan data
2. Desain dan analisis
19. Materi Ada Di: http://elearning.upbatam.ac.id/n/course/index.php
Upper CASE.
CASE tools yang didesain untuk mendukung perencanaan, identifikasi, dan
seleksi proyek (permulaan dari perencanaan proyek), tepatnya pada fase
analisis dan desain dari suatu system development life cycle (SDLC).
Tools yang termasuk kelas ini adalah jenis Diagramming tools, Form and report
generators, dan Analysis tools.
Contoh CASE tools: Cradle, PRO-IV Workbench, ProKit*WORKBENCH. 2.
Lower CASE.
CASE tools yang didesain untuk mendukung tahap implementasi dan
maintenance dari SDLC.
Tools yang termasuk kelas ini adalah jenis Code Pertemuan 7 CASE TOOLS
TIK : Menjelaskan konsep CASE, Tahapan dan Strategi cara menggunakan
CASE untuk membangun perangkat lunak. 2 generators. Contoh CASE tools:
Level/l-User Sensitive CASE, PRO-IV application Development
.
20. Materi Ada Di: http://elearning.upbatam.ac.id/n/course/index.php
Cross life-cycle CASE/Integrated CASE (I-CASE).
CASE tools yang dirancang untuk mendukung aktifikas-aktifitas yang terjadi
pada beberapa fase dari SDLC. Mengkombinasikan Upper dan Lower CASE
menjadi satu.
Tools yang termasuk kelas ini adalah jenis Project management tools.
Contoh CASE tools: Rational Rose, Poseidon, ArgoUML, Catalyze, in-Step,
Juggler, PRINCE.
21. CASE Tools
Namun saat ini CASE tools tidak hanya berfokus pada tahap awal
pengembangan perangkat lunak tapi ke semua bagian
pengembangan dan perbaikan perangkat lunak.
CASE tools termasuk :
1. Editor desain perangkat lunak
2. Editor kode program
3. Kompiler
4. Debugger
5. Perangkat pembangunan sistem perangkat lunak
22. CASE Tools
CASE tools dapat dikelompokkan menjadi dimensi yang berbeda
sebagai berikut :
1. Pendukung alur hidup perangkat lunak (life cycle support)
dibagi menjadi dua kelompok yaitu : Upper case tools, lower
Case tools.
2. Dimensi integrasi (integration dimension)
3. Dimensi konstruksi (Contruction dimension)
4. Dimensi CASE berbasis keilmuan (Knowledge-based Case)
Case Tools adalah alat bantu untuk
pengembangan perangkat lunak agar
hasilnya lebih baik dan waktu
pengerjaannya lebih singkat
23. RUP
RUP (Rational Unified Process)
Pendekatan pengembangan perangkat lunak yang dilakukan
berulang-ulang (iterative), fokus pada arsitektur (architecture-
centric), lebih diarahkan berdasarkan penggunaan kasus (use case
driven).
Setiap iterasi akan menghasilkan produk yang langsung bisa
digunakan, dan pada saat itu juga produk tersebut di-analisis
kembali untuk menciptakan produk baru dengan versi berbeda.
Misalnya : Produk X versi 1.0 (iterasi 1), Produk X versi 1.2 (iterasi
2), demikian seterusnya.
25. RUP
Berikut hal-hal yang dapat diatasi RUP dibanding model waterfall :
1. RUP mengakomodasi perubahan kebutuhan perangkat lunak
2. Integrasi bukanlah sebuah proses dan cepat (big bang) di akhir
proyek
3. Resiko biasanya ditemukan atau dialamatkan selama pada proses
integrasi awal
4. Manajemen berarti membuat perubahan pada taktik pada produk
5. Mendukung fasilitas penggunaan kembali
6. Kecacatan dapat ditentukan dan diperbaiki pada beberapa iterasi
7. Lebih baik menggunakan “anggota proyek” dibandingkan susunan
seri pada tim proyek
8. Anggota tim belajar selama proyek berjalan
9. Pengembangan perangkat lunak dapat diperbaiki seiring proses
pengembangan perangkat lunak
26. RUP
Fase RUP
RUP memiliki 4 (empat) buah fase yang dapat dilakukan secara
interatif :
Inception Elaboration Construction Transition
Iterasi
27. RUP
Keterangan :
1. Inception (permulaan)
Tahap ini lebih pada memodelkan proses bisnis yang dibutuhkan
(business modelling) dan mendefinisikan kebutuhan akan sistem
yang akan dibuat (requirements)
2. Elaboration (perluasan/perencanaan)
Tahap ini difokuskan pada perencanaan arsitektur sistem. Tahap ini
juga dapat mendeteksi apakah arsitektur sistem yang diinginkan
dapat dibuat atau tidak.
3. Construction (konstruksi)
Tahap ini fokus pada pengembangan komponen dan fitur-fitur sistem
4. Transition (transisi)
Tahap ini lebih pada deployment atau instalasi sistem agar dapat
dimengerti oleh user
28. RUP
Akhir dari keempat fase ini adalah produk perangkat lunak yang
sudah lengkap. Keempat fase pada RUP dijalankan secara
berurutan dan iteratif dimana setiap iterasi dapat digunakan untuk
memperbaiki iterasi berikutnya
