TIF-151551 REKAYASA DAN MANAJEMEN KEBUTUHAN
Requirements
Modeling – OO
TIF-151551REKAYASA DAN MANAJEMEN KEBUTUHAN
2 Goals
Memahami konsep pemodelan OO pada rekayasa kebutuhan.
Terampil dalam pembuatan diagram-diagram yang diperlukan dalam pemodelan OO pada rekayasa kebutuhan.
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
3 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 Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Booch+James Rumbaugh+Ivar Jacobson
4 Diagram UML Use-case diagram (statis) scenario-based models Class diagram (statis) class models
Collaboration/sequence diagram (dinamis) behavioral models
Statechart diagram (dinamis) behavioral modelsRekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
5 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
6 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 Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Operasi2
7 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 Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
8 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
- Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
Ujian Ujian Ujian
9 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
10 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 sistemSites Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Informasi lokasi/posisi yang harus diingat oleh sistem
11 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.
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
12 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
13 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Use-case diagram
Select product Get return coins Customer Ent er object
14
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 15/54
16 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO <<include>> and <<extend>>
ViewMap OpenIncident AllocateResources <<include>>
<<include>> Base Use Case
Supplier Use Case ReportEmergency Help
<<extend>> A
B Base Use Case
17
18 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Actor-generalization
19
20 Class diagram
Menggambarkan struktur statis dari sistem Terdiri dari node (klas) dan relasi Jenis relasi
Generalization (‘is a’ – inheritance) Association Aggregation (‘part-of’) Composition
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
21 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?
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
22 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Class relationships – examples
23
24 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
25 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 Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO roughly one per use case
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Class stereotypes
Model interaction between the system and its
environment
Actor 1<<boundary>>
<<control>>
<<boundary>> <<entity>> <<entity>> Actor 2 boundary entity control
26
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO 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
27
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO Sequence diagram – example
: Customer : SelectionScreen : SelectionController : Products : DispenserProduct selectProduct( ) getValidSelection(String) isProductAvailable(String) dispenseProduct(String, int)
28
29 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
Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO
30 Statechart diagram – example initial accept new coin Waiting for a coin payment returned coin detected accept new coin coin return request accept customer request return payment product dispensed Waiting for Returning accept new coin selection payment product sufficient payment available=FALSE
dispense product return payment
Dispensing Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - OO product