RPL Bab3 Rekayasa Kebutuhan Pemodelan

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
35/55
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
64/55
Statechart diagram – example
Waiting for a coin
Waiting for selection
Dispensing product
Returning payment

initial

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

return payment
63/55
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

62/54

61/54
60/55
Sequence diagram – example
59/55
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
58/55
Class stereotypes
Model interaction between the system and its environment

Actor 1

<>

<>

<>

<>

<>
Actor 2

boundary

entity
control

57/55
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
65/55
Penutup
Pemodelan kebutuhan diperlukan untuk meningkatkan pemahaman terhadap kebutuhan yang sedang dianalisis
Pemodelan terstruktur meliputi pemodelan data models, process models dan behavioral models dari sistem yang sedang dikembangkan
Pemodelan berorientasi objek mencakup scenario-based models, class models dan behavioral models dari sistem yang sedang dikembangkan
Alat bantu yang digunakan dalam pemodelan terstruktur dan berorientasi objek terdapat perbedaan
2 – Pemodelan Berorientasi Objek
Tugas kelompok
Berikan contoh studi kasus aplikasi yang menggunakan permodelan terstruktur sesuai dengan topik praktikum
Buat ERD, DFD, STD dari contoh kasus tersebut
Kumpulkan hari Selasa sebelum jam 12 siang via email.
32/54
25/55
Behavior model
State Transition Diagram (STD)
Waiting for a coin
Waiting for selection
Dispensing product
Returning payment

initial

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

return payment

27/54
26/55
Behavior model (1)
CSPEC – Dispense change : Process Activation Table
coin return request
product available
get change coin
get payment coin
TRUE
TRUE
1
0
D/C
FALSE
0
1
DFD -0
28/54

29/54

30/54

31/54
56/55
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
55/55
Class relationships – examples

54/54
43/55
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
42/55
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.
41/55
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
40/55
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
38/55
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
39/55

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
37/55
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
36/55
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
44/55
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
45/55
Use-case diagram
53/55
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
Aggregation
Denpendency
Composition
46/55
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
The customer selects a button product.
The system displays an entry prompt of number of product to order.
Alternative flows
If the selected product is not available, the system will display a message "Your selected product is not available".
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
52/55
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?
51/55
Class diagram
Menggambarkan struktur statis dari sistem
Terdiri dari node (klas) dan relasi
Jenis relasi
Generalization ('is a' – inheritance)
Association
Aggregation ('part-of')
Composition
50/55
Actor-generalization
49/55
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
48/55
<> and <>

ViewMap

OpenIncident

AllocateResources

<>
<>
Base Use
Case
Supplier
Use Case

ReportEmergency

Help

<>
A
B
Base Use
Case
47/55
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
34/55
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
24/55
Process model – Process specification
PSPEC – Validate payment (Process 3)
Inputs : payment (data in)
price (data in)
Outputs : change due (data out)
sufficient payment (control out)
Body :
IF payment >= price THEN
change due = payment – price
sufficient payment = TRUE
ELSE
change due = 0
sufficient payment = FALSE
END IF
22/55
Data/Control Flow Diagram (DFD/CFD level 1)
1*
Get customer payment
2p
Get product price
3p
Validate payment
4p
Get valid selection
5*
Dispense change
6p
Dispense product

price table

coins

products
returned coins
product
object
customer selection
slug
coin return request

payment

price

valid selection

change due

valid selection

coin detected

sufficient payment

product dispensed

product available

product available
9/55
Elemen-elemen pemodelan

Data Dictionary
Data Flow Diagram (DFD)
ER Diagram
State Transition Diagram (STD)
Process Specification (PSPEC)
Data Object Description
Control Specification (CSPEC)
8/55
Konsep
Pertama kali dipopulerkan oleh T. DeMarco (1979) Structured Analysis and System Specification
Perluasan notasi untuk kebutuhan real-time systems oleh Hatley dan Pirbhai (1987) – SA/RT Strategies for Real-Time System Specification
Processes
Data
Behavior

1 – Pemodelan Terstruktur
6/55
Tipe-tipe model kebutuhan
Scenario-based models
Berdasarkan sudut pandang aktor
Data models
Menjelaskan domain informasi dari masalah
Class-oriented models
Merepresentasikan klas-klas yang relevan dengan kebutuhan PL
Flow-oriented models
Merepresentasikan proses dan data dari sistem
Behavioral models
Merepresentasikan perilaku sistem berdasar event
5/55
Prinsip pemodelan kebutuhan
Model yang dibuat harus fokus pada kebutuhan yang relevan dengan domain permasalahan WHAT
Setiap model kebutuhan harus bisa dilacak ke model perancangan traceability
Setiap elemen dalam model kebutuhan harus mampu memperjelas pemahaman secara utuh terhadap kebutuhan PL domain masalah, fungsionalitas dan perilaku sistem
Minimalisasi kopling antar klas
Memastikan bahwa model kebutuhan memiliki nilai manfaat untuk seluruh stakeholders
Model dibuat sesederhana mungkin notasi yang sederhana, non duplikasi informasi
4/55
Konsep pemodelan kebutuhan
Model kebutuhan menjembatani antara deskripsi sistem secara umum dengan model perancangan
Tujuan utama model kebutuhan:
Menjelaskan apa yang dibutuhkan oleh customer
Menjadi dasar bagi perancangan PL
Menjadi referensi dalam melakukan validasi kebutuhan
Metode: terstruktur (structured analysis – SA) & berorientasi objek (object oriented analysis – OOA)
3/55
Agenda
Konsep pemodelan kebutuhan
Pemodelan terstruktur
Pemodelan berorientasi objek
23/55
Data/Control Flow Diagram (DFD/CFD level 2)
DFD/CFD level 2 : Dispense change
5.1p
Get change coin
coin return request

5.2p
Get payment coin

product available

change due

coins

payment

payment coins

change coins
returned coins
REKAYASA PERANGKAT LUNAK (RPL)
Rekayasa Kebutuhan – Pemodelan
10/55
Data dictionary
Representasi Simbol :
= : composed of + : and
{ } : iterations of […."…] : selection / or
( ) : optional " " : literal
* * : comment/description
Vend product (partly) :
Name Element Type
object [coin " slug](product) data
product [ice cream " coffee " candy] data
coins 0{[quarter " nickel " dime]}8 data
product available [TRUE " FALSE] control
["YES" " "NO"]
quarter *25 cents US currency*
coin return request [TRUE " FALSE] control
2/55
Tujuan perkuliahan
Memahami konsep pemodelan dalam rekayasa kebutuhan
Memahami konsep pendekatan terstruktur dan berorientasi objek dalam pemodelan kebutuhan

12/54
21/55
Data/Control Context Diagram (DCD/CCD)
Vend
product
Customer
returned coins
0*
Customer

product

object

customer selection

slug

coin return request

product available
20/55
Process model – DFD/CFD leveling
Must be consistent
19/55
Data – control identification
Identify data first rather than control to know what you are controlling first
Continuous signals, and processes that act on them, are always categorized as data
Discrete signals, and processes that act on them, are usually categorized as control
Terms like activate, turn on, engage and execute are usually associated with control requirements
18/55
Process model – Panduan DFD
Jumlah proses dalam satu diagram DFD : 4 + 2
Maks. 4 level dekomposisi (DFD/CFD)
Dekomposisi fungsional (DFD) :
fungsi-fungsi yang saling berhubungan dikelompokkan
fungsi-fungsi yang tidak berhubungan dipisahkan
setiap fungsi dispesifikasi hanya sekali
Data flow membawa informasi yg diperlukan oleh sebuah proses untuk transformasi, control flow membawa informasi yang harus diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses
Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi
Penjenjangan CFD harus sesuai dengan DFD
11/55
Data model – ER diagram
Entitas (atribut dan nilai atribut)
Modalitas : tingkat mandatory (minimal)
Kardinalitas : tingkat relasi (maksimal)
Bentuk relasi
Manufacturer
Car
Builds

16/55
Process model – Elemen2 DFD
Terminator
Representasi entitas eksternal
Notasi: persegi panjang
Tidak memproses data
Data flow
Representasi aliran data
Notasi: anak panah penuh
Umumnya satu arah
Hubungkan terminator, process dan storage
Control flow
Representasi aliran kontrol proses
Notasi: anak panah putus2
Hubungkan terminator, process dan control bar
Customer

data

control

13/54
17/55
Process model – Elemen2 DFD (1)
Process
Representasi aktifitas sistem
Notasi: lingkaran
Memproses data
Storage
Representasi tempat penyimpanan data
Notasi: dua garis paralel
Data flow in = diubah, data flow out = dibaca
Control bar
Representasi spesifikasi kontrol
Notasi: garis tegak
1
Proses A

data X

15/55
Process model – DFD
Useful for analyzing existing as well as proposed systems process decomposition
Focus on the movement of data between external entities and processes, and between processes and data stores
A relatively simple technique to learn and use
Model elements: terminator, process, data flow, control flow, storage, control bar
The highest level (0) Context diagram
Single process
Terminators
Data flows, control flows
14/55
Data model – data object description
Data object
represents a composite information
consists of a number of different attributes or properties
encapsulates data only no operation applied to its data
can be external entity, thing, occurrence/event, role, organizational unit, structure, etc.
e.g. dimensions (height, weight, depth), cars (make, model, ID, body type, color, owner)
can be represented in a tabular representation

Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level

# /54

- Generalisasi berarti target dari hubungannya ke kelas yang lebih general (umum). Sebagai contoh jika kita memiliki kelas bernama Cat dan kelas bernama Dog, kita dapat membuat generalisasi dari keduanya dengan nama Animal. Generalisasi biasanya dibaca "… adalah …" dimulai dari kelas yeng lebih spesifik menuju kelas yang lebih umum (general class). Jadi dapat dikatakan "suatu Cat adalah suatu Animal".
- Association Terkadang hubungan antara dua elemen tidak sederhana. Misalnya, suatu tim pemain bola (football player) berasosiasi dengan liga (league) lewat suatu regu. Jika hubungannya terlalu rumit, bisa dibuatkan hubungan asosiasi antar kelas. Yang perlu diperhatikan dari gambar diatas adalah FootballPlayer tidak memiliki referensi langsung kepada FootballLeague tapi memiliki referensi terhadap FootballTeam. footballTeam akan memiliki referensi terhadap FootballLeague.
Composit : Misalnya, jika Window yang kita buat harus memeliki Titlebar maka kita dapat merepresentasikan suatu kelas bernama Titlebar yang merupakan "bagian dari" kelas Window.
Agregasi adalah versi kuat dari asosiasi. Tidak seperti asosiasi, agregasi mengimplikasikan kepemilikansuatu kelas. Agregasi bisa dibaca " … memilik … ".
51

# /54
Second level
Third level
Fourth level
Fifth level

# /54


# /54
Second level
Third level
Fourth level
Fifth level

# /54
Second level
Third level
Fourth level
Fifth level

# /54
Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.
53
Second level
Third level
Fourth level
Fifth level
Second level
Third level
Fourth level
Fifth level

# /54
Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many).
52
Boundary class menangani komunikasi antara lingkungan sistem dan kedalam sistem. Mereka dapat menjamin interface ke pengguna atau sistem lain ( misalnya, interface ke actor ). Boundary class digunakan untuk memodelkan sistem interface.
56
Actor merepresentasikan entitas yang berada di luar system. Mereka bisa berupa manusia, perangkat keras atau system lain.
General life line Merepresentasikan entitas tunggal dalam sequence diagram, digambarkan dengan kotak. Entitas ini memiliki nama, stereotype atau berupa instance (menggunakan instance:class)
59
Second level
Third level
Fourth level
Fifth level

# /54

Click to edit Master subtitle style

# /43

- Entity class memodelkan informasi dan operasi yang biasanya berumur panjang/lama. Tipe class ini menggambarkan entitas dunia nyata atau entitas yang dibutuhkan untuk melakukan tugas internal sistem.
- Control class memodelkan urutan kelakukan ( behavior ) khusus untuk satu atau lebih use case. Pada awal phasa Elaboration, sebuah control class ditambahkan untuk setiap pasangan actor atau use case. Control class bertanggung jawab untuk aliran kejadian-kejadian dalam use case.
57

# /54
Second level
Third level
Fourth level
Fifth level
Second level
Third level
Fourth level
Fifth level

# /54

# /54
Second level
Third level
Fourth level
Fifth level
Second level
Third level
Fourth level
Fifth level

# /54

Second level
Third level
Fourth level
Fifth level

#

RPL Bab3 Rekayasa Kebutuhan Pemodelan

Recommend Documents