Requirements
Modeling – OO
TIF-151551
Goals
Memahami konsep pemodelan OO pada rekayasa
kebutuhan.
Terampil dalam pembuatan diagram-diagram yang diperlukan
dalam pemodelan OO pada rekayasa kebutuhan.
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
)
Diagram UML
Use-case diagram
(statis)
scenario-based models
Class diagram
(statis)
class models
Collaboration/sequence diagram
(dinamis)
behavioral models
Statechart diagram
(dinamis)
behavioral models
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) & behavior (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 - Nama
- Buat skripsi - Ujian
Mahasiswa
- NIM : 001 - Nama : Andi - Buat skripsi - Ujian
Mahasiswa : Andi
Mahasiswa
- NIM : 002 - Nama : Eko - Buat skripsi - Ujian
Mahasiswa : Eko
Mahasiswa
- NIM : 003 - Nama : Susi - Buat skripsi - Ujian
Mahasiswa : Susi
Instansiasi :
penciptaan objek
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
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
Select product
Get return coins Customer
Ent er object
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”.
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
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
Class stereotypes
Model interaction between the system and its
environment
Actor 1 <<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
Actor 2
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
: Customer : SelectionScreen : SelectionController : Products :
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
30
Waiting for a coin
Waiting for selection accept new coin
payment returned accept new coin coin detected
accept customer request product dispensed
accept new coin
sufficient payment dispense product
product available=FALSE
return payment coin return request
