Pemodelan Kebutuhan

Pendekatan Berorientasi Objek

Fajar Pradana S.ST., M.Eng
Tujuan perkuliahan
• Memahami konsep pendekatan berorientasi objek dalam
pemodelan kebutuhan
Agenda
• Konsep pemodelan berorientasi objek
• Elemen-elemen pemodelan berorientasi objek
• Dokumentasi dan alat bantu
Object Oriented Approach
• Mulai populer akhir ’80an – ’90an (Booch, Rumbaugh-OMT,
Jacobson-OOSE, Coad+Yourdon, Wirfs-Brock) :
▪ Elisitasi kebutuhan customer
▪ Identifikasi skenario / use-case (use-case diagram)
▪ Identifikasi klas berdasarkan kebutuhan customer
▪ Identifikasi atribut dan operasi setiap klas
▪ Definisi struktur klas (class diagram)
▪ Definisi model relasi antar klas (collaboration/sequence diagram)
▪ Definisi perpindahan status sistem (statechart diagram)
• 1996 : UML (Unified Modeling Language) – Grady Booch+James
Rumbaugh+Ivar Jacobson
Keuntungan
• Sangat natural, sesuai dengan cara berpikir manusia  improve
analyst and problem domain expert interaction
• Meningkatkan konsistensi hasil analisis  abstraksi atribut-operasi
dalam sebuah objek
• Konsep penurunan klas memberikan kemudahan dalam
generalisasi objek
• Kemudahan dalam perubahan
• Terjaganya konsistensi model antara analisis dan perancangan
• Konsep reusability
Object, Class – Apa Itu ?
• Objek (Object) :
▪ A concept, abstraction, or thing with crisp boundaries and meaning
for the problem at hand [Rumbaugh]
▪ Benda (tangible & intangible thing)
▪ Contoh : Andi, Eko, Susi (sistem akademik)
▪ Sebuah objek memiliki karakteristik : identity (identitas-pembeda),
state (sekumpulan atribut) & behaviour (sekumpulan operasi, aksi,
servis)
• Notasi :
Nama Objek

Atribut2

Operasi2
Object, Class – Apa Itu ?

• Klas (Class) :
▪ A description of one or more objects with a uniform set of attributes
and services, including a description of how to create new objects in
the class [Yourdon]
▪ Gambaran umum (template, blue-print) yang menjelaskan
sekumpulan objek yang memiliki kesamaan karakteristik (atribut dan
operasi)
▪ Merupakan cetakan dari objek
▪ Digunakan untuk menginstansiasi objek yang memiliki identitas yang
berbeda
▪ Contoh : Klas Mahasiswa  objek Andi, Eko, Susi
▪ Abstract & concrete class
Object, Class – Apa Itu ?
Mahasiswa
- NIM

Instansiasi : - Nama
penciptaan objek
- Buat skripsi
- Ujian

Mahasiswa : Andi Mahasiswa : Eko Mahasiswa : Susi

Mahasiswa Mahasiswa Mahasiswa
- NIM : 001 - NIM : 002 - NIM : 003
- Nama : Andi - Nama : Eko - Nama : Susi

- Buat skripsi - Buat skripsi - Buat skripsi

- Ujian - Ujian - Ujian
Where to look ?
• Investigasi domain masalah
• Langkah-langkah:
▪ Observe first-hand  observasi langsung ke lap.
▪ Actively listen to problem domain experts  what, who, why, when
and how
▪ Check previous OOA results
▪ Check other systems  comparison
▪ Read, read, read  getting some more information
What to look for ? Nouns
• Structures
▪ Relasi antar objek -> generalisasi, agregasi
• Other systems
▪ Sistem lain yang berinteraksi dg proposed system
• Things or events remembered
▪ Data, status, kejadian yang harus disimpan
• Roles played
▪ Identifikasi peran manusia dalam sistem -> berinteraksi langsung,
tidak berinteraksi tetapi informasinya disimpan sistem
• Sites
▪ Informasi lokasi/posisi yang harus diingat oleh sistem
Identifikasi atribut
• Some data (state information) for which each object in a class has
its own value [Yourdon]
• Langkah-langkah:
▪ Identifikasi atribut umum (adjectives, possessives)
▪ Identifikasi atribut yang relevan dg domain masalah
▪ Identifikasi atribut yang relevan dg peran atau tanggung jawab dalam
sistem
▪ Restrukturisasi atribut sehingga atomic  kemudahan
▪ Reposisi atribut yang sesuai dengan hirarki klas nya  pewarisan klas
▪ Spesifikasi atribut presisi, nilai default, batasan, dll.
Identifikasi operasi/servis
• A specific behavior that an object is responsible for exhibiting
[Yourdon]
• Langkah-langkah:
▪ Identifikasi tanggung jawab umum sebuah klas (verbs)
▪ Identifikasi operasi yang spesifik untuk domain masalah
▪ Identifikasi operasi yang relevan dg peran atau tanggung jawab
dalam sistem
▪ Spesifikasi operasi  argumen, batasan/aturan, logika/algoritma
Diagram UML
• Use-case diagram (statis)
• Class diagram (statis)
• Collaboration/sequence diagram (dinamis)
• Statechart diagram (dinamis)
Use Case Diagram
• Menjelaskan perilaku sistem dari tampak luar
• Menyediakan fungsi-fungsi yg harus dipenuhi sistem sesuai
dengan aktornya
• Elemen: actor (orang, sistem lain) dan use-case
• Setiap use-case dilengkapi dengan skenario (deskripsi)
• Langkah-langkah:
▪ Identifikasi aktor
▪ Identifikasi use-case per aktor
Use Case Diagram

Enter object

Select product
Customer

Get return coins

Use-case scenario
Flow of events for the Select product use-case

Objective Allow customer to select a certain product to dispense

Actors Customer

Pre-condition Coin detected and valid

Main flow 1. The customer selects a button product.

2. The system displays an entry prompt of number of product to
order.

Alternative flows 1. If the selected product is not available, the system will display
a message “Your selected product is not available”.
2. If the selected product is available but there isn’t enough
number to order, the system will display a message “The
number isn’t enough, max. x”. X is the existing number of the
product.

Post-condition The selected product dispensed as the number needed

Use-case association
• Include
▪ A use case uses another use case (functional decomposition)  reuse
▪ A function in the original problem statement is too complex to be
solvable immediately  describe the function as the aggregation of
a set of simpler functions (mandatory)
• Extend
▪ A use case extends another use case
▪ The functionality in the original problem statement needs to be
extended
▪ The extended use-case plays an optional use-case
<<include>> and <<extend>>

<<include>>

OpenIncident
ViewMap
Base Use
Case <<include>>
Supplier
AllocateResources
Use Case

Base Use
Case B
Help
A <<extend>>
ReportEmergency
Actor-generalization
• Two/more sub-actors generalized into a super-actor
• Have both behavior and attributes in common – described under
the super-actor
• Super-actor should interact with use cases when ALL of its sub-
actors interact in the same way
• Sub-actors should interact with use cases when their individual
interactions differ from that of the super-actor
Actor-generalization
Class diagram
• Menggambarkan struktur statis dari sistem
• Terdiri dari node (klas) dan relasi
• Jenis relasi
▪ Generalization (‘is a’ – inheritance)
▪ Association
▪ Aggregation (‘part-of’)
▪ Composition
Association
• For “real-world objects” is there an association between classes?
• Classes A and B are associated if:
▪ An object of class A sends a message to an object of B
▪ An object of class A creates an instance of class B
▪ An object of class A has an attribute of type B or collections of
objects of type B
▪ An object of class A receives a message with an argument that is an
instance of B (maybe…)  will it “use” that argument?
• Does an object of class A need to know about some object of class
B?
Aggregation – composition
• Aggregation represents a part-whole or part-of relationship
• Aggregation can occur when a class is a collection or container of
other classes, but where the contained classes do not have a
strong life cycle dependency on the container – essentially, if the
container is destroyed, its contents are not
• Composition is more specific than aggregation
• Composition usually has a strong life cycle dependency between
instances of the container class and instances of the contained
class(es)  if the container is destroyed, normally every instance
that it contains is destroyed as well
Class relationships – examples
Class stereotypes
• Boundary classes
▪ model the interaction and manage communication between the
computer system and its actors, but don’t directly represent the
specific interface object in the implementation
▪ used to identify the main logical interfaces with users and other
systems (including e.g. other software packages, printers)
▪ main task is to translate information across system boundaries
▪ partition the system so that interface is kept separate from business
logic
Class stereotypes
• Entity classes
▪ used to model data and behavior of some real life system concept or
entity e.g. member, bank account, order, employee
▪ these will sometimes require more persistent storage of information
e.g. a student’s details are ultimately stored as a student record
• Control classes
▪ represent coordination, sequencing, transactions and control of other
objects
▪ glue between boundary elements and entity elements, describing the
logic required to manage the various elements and their interactions
▪ roughly one per use case
 Class stereotypes
<<control>>
<<boundary>> <<boundary>>
Actor 1 Actor 2

<<entity>> <<entity>>

boundary entity control

Sequence diagram
• An interaction diagram that emphasizes the time ordering
of messages
• Shows a set of objects and the messages sent and received
by those objects
• Elements
▪ Object  represented in a box
▪ Dashed line  called the object lifeline, and it represents the
existence of an object over a period of time
▪ Message  rendered as horizontal arrows being passed from object
to object as time advances down the object lifelines
Sequence diagram – example

: Products :
: Customer : SelectionScreen : SelectionController
DispenserProduct

selectProduct( )
getValidSelection(String)
isProductAvailable(String)

dispenseProduct(String, int)
Statechart diagram
• A statechart diagram shows the behavior of classes in response to
external stimuli
• This diagram models the dynamic flow of control from state to
state within a system
 Statechart diagram – example
initial
accept new coin

Waiting for a
coin payment returned
accept new coin
coin detected
accept customer coin return request
request return payment
product dispensed
Waiting for Returning
accept new coin
selection payment
product
sufficient payment available=FALSE
dispense product return payment

Dispensing
product
Alat Bantu
• Structured Analysis :
▪ Aplikasi pengolah model : Visio, dll.
▪ Aplikasi pengolah kata : MS Word, dll.
▪ CASE Tool : StP (Software through Picture), PSL/PSA (Problem
Statement Language/Problem Statement Anaylzer), ILeaf, SPMS, dll.
• OO Analysis :
▪ Aplikasi pengolah model : Visio, dll.
▪ Aplikasi pengolah kata : MS Word, dll.
▪ CASE Tool : Rational RequisitePro, Rational Soda for Word, Rational
Rose, ArgoUML, dll.
Dokumentasi
• Introduction
▪ 1.1. Purpose of the requirements document
▪ 1.2. Scope of the product
▪ 1.3. Definition, acronyms and abbreviations
▪ 1.4. References
• General Description
▪ 2.1. Product perspective
▪ 2.2. Product functions
▪ 2.3. User characteristics
▪ 2.4. General constraints
• Specific Requirements
▪ All functional and non-functional requirements, system models (eg. DFD/CFD, ERD, STD,
Use-Case, Class, Sequence, Statechart diagrams), performance, database requirements,
design constraints, security.
• Qualification/Validation Requirements
• Appendices/Bibliography
Summary
• Pemodelan berorientasi objek meliputi use-case, class, sequence
dan state dari sistem yang sedang dikembangkan
• Alat bantu yang digunakan dalam pemodelan terstruktur dan
berorientasi objek terdapat perbedaan
• Dokumentasi yang dihasilkan dari RE terdiri IRS dan SRS
Terima Kasih
Ada Pertanyaan