Pengantar Berorientasi Objek

Slides:



Advertisements
Presentasi serupa
KEBUTUHAN & SPESIFIKASI SOFTWARE
Advertisements

ANALISIS DAN PEMODELAN BERORIENTASI OBJEK DENGAN UML
UNIFIED MODELLING LANGUAGE
PENGENALAN ANALISA SISTEM BERORIENTASI OBYEK
KONSEP DAN TEKNOLOGI BERORIENTASI OBYEK
Yang akan dipelajari Pengenalan UML Sejarah Singkat UML
Pertemuan 2 Konsep Aplikasi Berbasis Objek, UML dan Rational Rose
Rekayasa Perangkat Lunak Proses Rekayasa Perangkat Lunak
Perancangan Berorientasi Objek (Object Oriented Analysis & Design)
ANALISIS DAN PEMODELAN BERORIENTASI OBJEK DENGAN UML
Rekayasa Perangkat Lunak
1 Pertemuan 3 Unified Modeling language (UML) Matakuliah: T0456 ~ Algoritma dan Metode Object Oriented Programming Tahun: 2005 Versi: 5.
Analisis Kebutuhan Software
1 Pertemuan 01 Pengenalan OOAD Matakuliah: M0086/Analisis dan Perancangan Sistem Informasi Tahun: 2005 Versi: 5.
PERANCANGAN SISTEM BERORIENTASI OBJEK
PERANCANGAN SISTIM BERORIENTASI OBJEK
Pengantar UML.
Rekayasa Perangkat Lunak UML (Unified Modelling Language)
Analisa dan Perancangan Berbasis Objek
Analisis dan Perancangan Berorientasi Objek (OOAD)
Pengantar Berorientasi Objek
Object-Oriented Design (OOD)
Object Oriented Design
ANALISIS & DESAIN BERORIENTASI OBJEK
System Development Life Cycle (SDLC)
Object oriented analyst and design
Perancangan Sistem Informasi
Analisa dan Desain Berorientasi Obyek
Pengantar Object Oriented Analysis and Design
Object-Oriented Analysis (OOA)
Rekayasa Perangkat Lunak Class Diagram
PENGEMBANGAN PERANCANGAN SISTEM
Intro to OOP Yesi Novia, S.Kom.
SE3414 RPL: Teknik Berorientasi Objek
Pemodelan objek.
PERANCANGAN SISTEM BERORIENTASI OBJEK DENGAN UML
Model Berorinetasi Data
OOAD & Pemodelan Fungsional
Intro to OOP Yesi Novia, S.Kom.
Testing dan Implementasi
KEBUTUHAN & SPESIFIKASI SOFTWARE
PEMODELAN SYSTEM BERORIENTASI OBYEK (UML)
Pengembangan Sistem Pertemuan 3.
CLASS DIAGRAM.
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
REKAYASA PERANGKAT LUNAK
Pertemuan 3 OOAD Coad Yourdon Pendahuluan + Notasi
REKAYASA PERANGKAT LUNAK
KEBUTUHAN & SPESIFIKASI SOFTWARE
REKAYASA PERANGKAT LUNAK
Pertemuan 1 Definisi dan Karakteristik Objek
Pertemuan 2 Model Proses + Metodologi
ANALISA & DESAIN BERORIENTASI OBJEK
Unified Modelling Languange (UML)
UML- UNIFIED MODELING LANGUAGE
Pertemuan 4 CLASS DIAGRAM.
Pengantar Objek.
Model Berorinetasi Data
Pertemuan 4 OOAD Coad Yourdon 5 Lapisan Kegiatan
PERANCANGAN SISTIM BERORIENTASI OBJEK
PERANCANGAN SISTEM BERORIENTASI OBJEK
PEMODELAN ANALISIS RPL – PERTEMUAN 5&6.
Pertemuan 8 RPL Oleh : Syukriya al-Asyik S.Kom
Pertemuan 9 UML Diagram Class & Diagram Objek
Pertemuan 6 Unified Modeling Language (UML)
ANALISA BERORIENTASI OBJEK
KEBUTUHAN & SPESIFIKASI SOFTWARE
ANALISA BERORIENTASI OBJEK
OBJECT ORIENTED ANALISYS AND DESIGN
Konsep Aplikasi Berbasis Objek
Transcript presentasi:

Pengantar Berorientasi Objek Citra N, S.Si, MT SI - UNIKOM

Karakteristik Objek

Prinsip dasar dari pendekatan berorientasi Objek Object Orientation Encapsulation Abstraction Hierarchy Modularity

Abstraksi Prinsip mengabaikan sejumlah aspek dari suatu subjek yang tidak relevan dengan tujuan tertentu untuk lebih memfokuskan pada objek yang dibahas secara utuh. Tujuan dari melakukan abstraksi adalah mendapatkan model dengan melalui cara : Pemusatan perhatian (attention focusing), yaitu hanya berfokus terhadap permasalahan inti, setelah model utama telah didapat, barulah kita memperhatikan model penunjang lainnya. Pemilihan cara pandang (viewpoint selection), yaitu membuat model dengan cara pandang tertentu berdasarkan permasalahan, Pengingat (recording by information chuncking), yaitu memperhatikan data yang harus diingat dan informasi apa saja yang harus dihasilkan oleh sistem informasi.

What is Abstraction? Salesperson Customer Product

Encapsulation Enkapulasi merupakan pembungkusan terhadap data dan prosedur atau fungsi yang akan digunakan oleh objek secara bersama- sama.

What is Encapsulation? Hide implementation from clients Clients depend on interface

Order Processing System What is Modularity? Modularity supports separation of concerns. Another example of modularity is a car, which is made up of a body, chassis, engine, wheels, etc. The breaking up of something complex into manageable pieces Order Entry Order Processing System Order Fulfillment Billing

What is Hierarchy? Levels of abstraction Hierarchy is not an organizational chart. Hierarchy is not a functional decomposition. Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize similarities and differences. For example, in botany, plants are organized into families, chemistry uses a periodic table to organize the elements. Decreasing abstraction Increasing Levels of abstraction Asset RealEstate Savings BankAccount Checking Stock Security Bond Classes at the same level of the hierarchy should be at the same level of abstraction

Metodologi Analisis dan Perancangan

OOAD - Coad Yourdon Object Oriented Analysis Dalam OOA, terdapat lima lapisan kegiatan, yang tidak bersifat sekuensial, tapi dapat dilakukan secara acak, yaitu : Menentukan lapisan Subjek Menentukan lapisan Kelas-&-Objek Menentukan lapisan struktur Menentukan lapisan attribute Menentukan lapisan service.

Object Oriented Analysis Lapisan Subyek Memilih subjek-subjek yang mungkin, dengan : Menjadikan kelas teratas pada tiap struktur yang telah teridentifikasi sebagai Subjek Menjadikan kelas&objek yang tidak menjadi anggota struktur sebagai subjek Menghaluskan subjek Mengkonstruksi Subjek Pada lapisan subjek menggambarkan kotak subjek, nama subjek, dan nomor subjek, dan bila diperlukan daftar kelas&objek yang ada pada subjek Pada lapisan lain gambarkan subjek dan kotak-kotak subjek berlabel

Object Oriented Analysis Lapisan Kelas-&-Objek Mempelajari domain permasalahan dengan mengumpulkan informasi Mencari kandidat kelas&objek potensial, dengan melihat : Struktur, perangkat dan sistem yang lain. Benda-benda/Kejadian-kejadian yang harus diingat Peran yang dibawakan ; Prosedur operasional Unit Organisasi; Lokasi Fisik Memberi penamaan untuk kandidat kelas&objek tersebut. Kelas&objek potensial diuji dengan menggunakan criteria : Harus diingat Mempunyai prilaku yang diperlukan Mempunyai atribut dan layanan yang selalu digunakan Kebutuhan dasar dari domain persoalan Dapat menghasilkan lebih dari satu objek (untuk kelas) Bukan merupakan hasil turunan

Object Oriented Analysis Lapisan Struktur Mencari struktur Gen-Spec Apakah akan ada turunan/pewarisan? Apakah spesialisasi/generalisasi masih memenuhi criteria sebagai kelas&objek Dan semua kelas&objek tersebut dijadikan spesialisasi. Mencari struktur whole-part Apakah kelas&objek menangkap lebih dari sekedar nilai status Jika tidak jadikan sebagai whole Apakah kelas&objek memberikan abstraksi yang berguna Mengidentifikasikan struktur berganda (multiple structures)

Object Oriented Analysis Lapisan Atribut Many to many instance connections  kemungkinan terdapat atribut pada koneksi sehingga membentuk kelas&objek baru Instance connections antar objek-objek yang berasal dari satu kelas  kemungkinan ada atribut pada koneksi sehingga membentuk kelas&objek baru. Instance connections berganda antar objek  kemungkinan ada atribut pada koneksi sehingga membentuk kelas&objek baru. Kebutuhan akan instance Connections tambahan akibat pembentukan kelas&objek baru hasil pengujian di atas (bila antara kedua kelas&objek semula tetap ada koneksi yang tidak perlu melibatkan kelas&objek baru yang terbentuk) Objek satu yang terkoneksi mempunyai arti khusus  bila perlu menambahkan atribut pada objek banyak (Hubungan satu ke banyak)

Karakteristik Objek Inheritance Polymorphisma Pewarisan merupakan mekanisme untuk mengekspresikan kesamaan diantara kelas Polymorphisma (kebanyakrupaan) merupakan suatu konsep yang menyatakan bahwa suatu hal yang sama dapat mempunyai bentuk dan perilaku berbeda. Note : perhatikan prinsip modularitas dan hirarki.

Object Oriented Analysis Lapisan Service Mengidentifikasikan state yang mungkin dari objek Mengidentifikasikan layanan untuk tiap kelas&objek Layanan dapat ditentukan dengan membedakan kerumitan algoritma, yaitu ; Simpel algoritma : Create, Connect, Access, Release Kompleks algoritma : Calculate Monitor Mengidentifikasi message connections : Dari objek manakah (kelas&objek) memerlukan layanan Objek lain manakah yang memerlukan layanan dari suatu kelas&objek

Object Oriented Analysis Lapisan Struktur Mencari struktur Gen-Spec Apakah akan ada turunan/pewarisan? Apakah spesialisasi/generalisasi masih memenuhi criteria sebagai kelas&objek Dan semua kelas&objek tersebut dijadikan spesialisasi. Mencari struktur whole-part Apakah kelas&objek menangkap lebih dari sekedar nilai status Jika tidak jadikan sebagai whole Apakah kelas&objek memberikan abstraksi yang berguna Mengidentifikasikan struktur berganda (multiple structures)

OOAD – Coad Yourdon Object Oriented Design Selain memiliki lapisan kegiatan, OOD memiliki 4 komponen kegiatan, yaitu : Problem Domain Component Human Interaction Component Task Management Component Data Management Component

OOD PDC (Problem Domain Component) Komponen Problem Domain merupakan tahapan yang menentukan 5 lapisan kegiatan, seta pengelolaan terhadap kombinasi atau pun penggabungan dan pembagian dari kelas dan objek yang sudah ditentukan. Dapat juga berisi penghalusan dari semua lapisan pada saat analisis.

OOD PDC (Problem Domain Component) Mencari dan menentukan hasil rancangan dari kelas-&-objek yang sudah ada untuk diguna-ulang Melakukan Pengelompokkan kelas-kelas domain permasalahan yang spesifik Memantapkan protocol antar objek dengan menambahkan kelas Generalisasi (penamaan layanan yang sama pada sejumlah kelas) Mengakomodasikan pewarisan sesuai bahasa pemrograman yang dipilih. Meningkatkan kinerja, dalam hal ini kecepatan, dengan menggunakan konsep coupling untuk menyeimpan data atau hasil perhitungan sementara. Mendukung DMC, dengan cara : Menambah kemampuan tiap objek untuk menyimpan dirinya sendiri Kemampuan ini ditentukan dalam DMC Menambahkan komponen-komponen local untuk membantu implementasi program

OOD HIC(Human Interaction Component) Komponen Human Interaction merupakan tahapan dimana kegiatan yang dilakkukan adalah untuk menentukan tampilan antar muka dan inputan ke dalam sistem yang diperlukan untuk membuat interaksi antara manusia dan computer secara efektif, berupa tampilan yang ‘user friendly’

OOD HIC(Human Interaction Component) Mengklasifikasikan orang yang akan menjadi user, dengan criteria : Tingkat keterampilan; Tingkat organisasional; Keanggotaan pada kelompok Setiap kategori orang diberi penjelasan berupa task scenario, berisi : Siapakan kategori orang tersebut Tujuan kategori orang Karakteristik (seperti : umur, pendidikan, dll) Critical Success Faktor Merancang hirarkhi perintah Merancang interaksi detail, dapat berupa : konsistensi pada interaksi manusia menyediakan umpan balik bagi user menggunakan langkah sederhana untuk menyelesaikan satu tugas menyediakan fungsi undo tidak mengandalkan ingatan manusia untuk mengingat sesuatu memberikan kepuasan dan daya tarik sistem bagi user Membuat polymorphisma Mendefinisikan/merancang kelas-kelas HIC

OOD TMC (Task Management Component) Komponen Task Manajemen merupakan tahapan untuk menentukan semua definisi task program berupa fungsionalitas subprogram, serta gambaran umum operasional program, komunikasi dan koordinasi antara subprogram, berdasarkan pertimbangan penggunaan perangkat keras dan protocol perangkat yang digunakan, serta lingkungan eksternal atau interaksi dengan sistem yang lain.

OOD TMC (Task Management Component) Menentukan apakan pendefinisian task (multitasking) diperlukan sistem Mengidentifikasikan jenis task, jika terdapat lebih dari satu task, maka diperlukan task coordinator. Menguji kebutuhan task Mendefinisikan tiap task dengan menentukan : Apa maksud task Bagaimana task dikoordinasikan atau mengkoordinasikan dirinya Bagaimana task berkomunikasi

OOD DMC (Data Management Component) Komponen Data Manajemen merupakan tahapan untuk menentukan struktur database, menentukan skenario pengiriman data antar PC atau antar bagian, serta bagaimana mengelola data se adalah kegiatan mengelola data secara persistent

OOD DMC (Data Management Component) Memilih ancangan untuk DMC Ancangan yang dapat dipilih berupa flat files, RDBMS atau OODBMS, sehingga perlu dipertimbangkan aspek identifikasi dan normalisasi Memilih perangkat manajemen data Pemilihan perangkat berdasarkan criteria : Concurrency, manajemen transaksi. Merancang komponen manajemen data Hal ini menyangkut tata letak data dan layanan yang diperlukan, sesuai pendekatan yang dipilih.

OOAD OMT (Object Modeling Technique) OMT terdiri dari beberapa fase : Analysis : memahami dan memodelkan aplikasi dan ranah tempatnya beroprasi Sistem design : arsitektur sistem keseluruhan. Object design : penerjemah konsep-konsep aplikasi kepada konsep komputer (fisik)

3 sudut pandang model (OMT) Objek model : objek pada sistem dan keterhubungan Dinamic model : reaksi objek pada sistem terhadap even dan interaksi antara objek. Funtion model : transformasi nilai (status) objek dan batasan transformasi.

System Design System design adalah strategi aras tinggi untuk menyelesaikan persoalan dan membangun solusi Menentukan gaya arsitektur dan arsitektur system keseluruhan. Perancangan harus menentukan keputusan atas: Organisasi system dalam sub-sistem Identifikasi konkurensi alami persoalan Alokasi sub-sistem pada prosesor dan task Memilih rancanganmanajemen penyimpanan data Penanganan akses sumber daya global Pemilihan implementasi control pada perangkat lunak Penanganan kondisi batas Penentuan prioritas pengorbanan (trade-off)

Objek Design Menentukan : Optimasi perancangan untuk kemudian: Definisi lengkap kelas dan asosasi yang digunakan pada implementasi Antarmuka Algoritma object methods sebagai oprasi. Optimasi perancangan untuk kemudian: Implementasi Perawatan Pengembangan

Objek Design Perancangan harus: Mengkobinasikan 3 model Merancang algoritma (implementasi operasi) Mengoptimalkan jalur akses data Implementasi control interaksi eksternal Mengatur ulang struktur kelas Merancang asosiasi Menentukan representasi objek Memaketkan kelas dan sosiasi dalam modul

OOAD – Object Oriented Software Engineering OOSE adalah sebuah bahasa dan metodologi pemodelan objek. OOSE merupakan teknik desain software yang digunakan dalam perancangan perangkat lunak dalam pemrograman berorientasi objek. OOSE dikembangkan oleh Ivar Jacobson pada tahun 1992. Ini adalah pertama kali metodologi desain berorientasi objek yang memakai use case digunakan untuk perancangan perangkat lunak. Ia juga menggunakan produk-produk desain lain yang serupa dengan yang digunakan oleh OMT. OOSE juga mengunakan desain-desain lain yang serupa yang digunakan oleh OMT.

Analysis Requirement Analysis Yang dilakukan untuk memproduksi Requirement Model adalah Mengidentifikasi keperluan sistem. Analysis Tujuannya untuk menghasilkan sebuah ‘logical model’ dari sistem dalam hal kelas dan hubungan.

Construction Design Implementation Memproduksi Design Model : Mengidentifikasi lingkungan implementasi. Implementation Pada tahap ini setiap objek diimplementasikan dalam bahasa pemrograman. Selama Proses Konstruksi, ada subproses yang disebut proses pembangunan komponen, yang mengembangkan dan memelihara komponen yang akan digunakan.

Testing Pengujian dimulai dengan perencanaan tes di mana seseorang sedang meneliti apakah ada program tes dan data yang dapat digunakan, apakah software tersebut dapat diubah

OOSE Analysis Model                                    Interface object Interface objects interact directly with the environment. Entity object Information about an entity object is stored even after a use case is completed.                                       Control object A control object illustrates functionality that is not contained in any other object in the system.                                        

Konsep Dasar Objek

Basic Concepts of Object Orientation Class Attribute Operation Component Generalization Polymorphism

Definisi “Objek” Objek (N) : semua benda baik secara fisik maupun konseptual Objek = entitas (data) yang didalamnya mempunyai identitas tertentu yang menjadi karakteristik dengan objek yang lain Objek adalah entitas yang memiliki identitas, state dan behaviour, serta dapat bereaksi terhadap pesan (message) yang diberikan oleh objek lain.

What is an Object? Behavior State Unique identity English 101 Other examples of objects (or classes, for that matter): an invoice in a business system, or an employee in a payroll system. Behavior State Unique identity English 101 Intro to OO 180 Geology 110 World History 200 Geology 110 Algebra 110 Music History 200

Class Kelas : deskripsi dari satu atau lebih objek dengan sejumlah atribut dan layanan yang sama termasuk deskripsi tentang cara membuat objek dari kelas tersebut.

What is a Class? An object is defined by a class CourseOffering English 101 Intro to OO 180 Geology 110 CourseOffering World History 200 Geology 110 Algebra 110 Music History 200

What is an Attribute? :CourseOffering CourseOffering Object Class number = 101 startTime = 900 endTime = 1100 Name = 104 startTime = 1300 endTime = 1500 CourseOffering number startTime endTime Class Attribute Object Attribute Value

What is an Operation? CourseOffering Class Operation addStudent deleteStudent getStartTime getEndTime Class Operation

Part of Class Atribut merupakan variabel data, yang dapat memberikan informasi keadaan dimana tiap objek dari suatu kelas mempunyai nilai tersendiri. Operation atau sering disebut layanan (service) atau operasi adalah prosedur atau fungsi yang menjadi perilaku kelas-&-objek dan menjadi tanggung jawab objek tersebut. Dalam bentuk pemrogrman merupakan bentuk subprogram yang digunakan terhadap atribut kelas-&-objek.

What Is A Component? A subsystem is the design representation of a component. They both encapsulate a set of replaceable behaviors behind one or more interfaces. Subsystems will be discussed in detail in the Architectural Design, Use Case Design, and Subsystem Design modules. In Rose, the Implementation Model is modeled in the Component View (e.g., components “live” in the Component View Rose doesn’t support the inclusion of component instances on interaction diagrams (though UML would permit it). Workaround: Use design elements as proxies for components as opposed to representing components on a Component Diagram. The design elements could be a <<subsystem>> stereotyped package and/or class. This is demonstrated in later modules of the course. A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture Design Model Implementation Model <<subsystem>> Component Name Component Name Component Interface Component Interface

Component Whole - Part Satu objek (yang mewakili whole) dapat didekomposisi menjadi objek-objek lain (Parts). Hubungan whole-part dapat memiliki rentang spesifik, seperti konsep kardinalitas pada pemodelan E-R. 3 Struktur whole-part : Assembly-Part, yaitu Satu Kelas yang terdiri dari berbagai elemen pembentuknya, PC sebagai Whole dengan Part yang terdiri dari Hardisk, Memory, dan lain-lain Container-Contents, yaitu Satu Kelas terdiri dari berbagai objek yang beragam, seperti kotak pos sebagai Whole dengan Part dapat terdiri dari surat, majalah dan kartu pos. Collection-Members, yaitu Satu Kelas sebagai satu perkumpulan dengan para anggotanya sebagai Part.

What is Generalization? Generalization is NOT used much in analysis; what is found is usually what comes up and hits you in the head with a 2x4. In analysis, generalization is included if it is inherent to the basic concept definitions in the problem domain. Design is the real activity of inventing generalization. Generalization will be discussed in more detail later in the course. Generalization and polymorphism (discussed later) are the shiny new toys in OO; so they are often overused and misused. USE APPROPRIATELY! Ask the class the following to test their understanding: How many operations does Car have? How may relationships? Answer: 1; 1 How many operations does Truck have? How may relationships? 2; 2 One class inherits from another Truck tonnage GroundVehicle weight licenseNumber Car owner register( ) getTax( ) Person 0..* Trailer 1 ancestor decendent generalization size

Generalization (Gen-Spec) Struktur Generalization-Specialization/Gen- Spec (Pewarisan) memperlihatkan definisi hirarki pewarisan untuk kelas-kelas yang merupakan spesialisasi dari kelas lain yang lebih umum (General). Sebuah kelas dapat mewarisi sifat dari sebuah superclass (kelas general) yang disebut dengan pewarisan tunggal (single inheritance) atau dari sejumlah superclass yang disebut dengan pewarisan ganda (mulitiple inheritance).

What is Polymorphism? Inheritance provides a way to implement polymorphism in cases where polymorphism is implemented the same way for a set of classes. The use of generalization to support polymorphism is discussed in more detail in the Class Design module Polymorphism will be addressed in more detail in the Class Design module. Another example of polymorphism: There is a toddler sitting in front of some blocks and a teenager siting in front of a piano. An adult walks into the room and says “play”. The toddler plays with the blocks and the teenage plays the piano. The ability to hide many different implementations behind a single interface Manufactor A Manufactor C

Strengths of Object Orientation A single paradigm Single language used by users, analysts, designers, implementers Facilitates architectural and code reuse Models more closely reflect the real world More accurately describe corporate data and processes Decomposed based on natural partitioning Easier to understand and maintain Stability A small change in requirements does not mean massive changes in the system under development

A Simple Sales Order Example Product Ship via

Class Diagram for the Sales Example Salesperson Customer Product Vehicle Corporate Individual Truck Train

Effect of Requirements Change Suppose the requirements for shipping by a truck change ... Salesperson Product Sale Corporate Customer Individual Truck Vehicle Train Only the Truck class changes

Metodologi vs Model Proses

METODOLOGI Metodolog adalah cara sistematis untuk mengerjakan analisis dan desain. Penggunaan metodologi memudahkan tim pengembang untuk merencanakan dan mengembangkan sistem, menghilangkan perbedaan notasi untuk hal yang sama. Metodologi : Coad Yourdon -OOAD- (Peter Coad dan Edward Yourdon) Object Modeling Technique -OMT- (James Rumbaugh) Object Oriented Software Engineering –OOSE- (Ivar Jacobson)

MODEL PROSES Model proses merupakan suatu paradigma yang digunakan untuk menggambarkan model dari urutan suatu kejadian di dalam sistem pada saat membangun ataupun mengembangkan suatu perangkat lunak. Model proses yang sering digunakan adalah Model Prescriptive, yaitu menggambarkan suatu set dari elemen sistem, dapat berupa kegiatan, aksi, tugas, proses produksi maupun proses untuk jaminan kualitas dalam setiap proyek perangkat lunak. Pada tiap proses digambarkan aliran kerja yang akan digunakan dalam pekerjaan rekayasa perangkat lunak, dan digunakan oleh tim pengembang sebagai acuan membuat perangkat lunak.

Tipe Model Proses Linear Prototype Gabungan Linier dan Protoype Component Based

Keuntungan Menggunakan Objek

OOAD 7 keuntungan menggunakan objek Menangani domain persoalan yang makin kompleks Meningkatkan interaksi antara analis dan ahli pada domain permasalahan Meningkatkan konsistensi internal antara analisis, perancangan dan pemrograman Secara eksplisit menyatakan antara kelas dan objek Membuat spesifikasi yang lebih tangguh terhadap perubahan Mengguna-ulang hasil OOA, OOD, dan OOP Menyediakan representasi yang konsisten antara analisis, perancangan dan pemrograman.

OOAD Catatan Tidak ada perbedaan besar antara notasi analisis dan perancangan Tidak ada transisi dari tahapan analisis ke tahapan perancangan Tidak ada model waterfall yang harus diikuti, dalam hal ini dapat menggunakan model spiral dan incremental, walaupun penggunaan tersering adalah model prototyping. Terdapat sejumlah keahlian dan strategi khusus yang diperlukan oleh analis dan perancang Terdapat keseragaman representasi dari OOA, OOD ke OOP.