PemodelanRekayasa Kebutuhan

REKAYASA PERANGKAT LUNAK

Semester Ganjil 2015/2016

ADAM HENDRA BRATA

Tujuan & Agenda Perkuliahan

Tujuan Memahami konsep pemodelan dalam rekayasa

kebutuhan

Memahami konsep pendekatan terstruktur dan

berorientasi objek dalam pemodelan kebutuhan

Agenda Konsep pemodelan kebutuhan

Pemodelan terstruktur

Pemodelan berorientasi objek

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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)

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Pemodelan Terstruktur

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Processes

Data Behavior

Elemen – Elemen PemodelanP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

Data Dictionary

Data Flow Diagram

(DFD)

ER Diagram

State Transition Diagram

(STD)

Process Specification

(PSPEC)

Data Object Description

Control Specification

(CSPEC)

Data DictionaryP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Data Model : ER Diagram

Entitas (atribut dan nilai atribut)

Modalitas : tingkat mandatory (minimal)

Kardinalitas : tingkat relasi (maksimal)

Bentuk relasi

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Manufacturer CarBuilds

Data Model : ER Diagram

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Process Model : Elemen – Elemen

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Customer

data

control

Process Model : Elemen – Elemen

DFD 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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

1

Proses A

data X

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Process Model : Panduan DFD

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Data – Control Identification

Must be consistent

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Process Model : DFD/CFD Leveling

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Data / Control Context Diagram

(DCD/CCD)

Vendproduct

Customer

returned

coins0*

Customer

product

object

customer

selection

slug

coin return

request product

available

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Data / Control Flow Diagram

(DCD/CCD 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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Data / Control Flow Diagram

(DCD/CCD Level 2)

5.1p

Get

change

coin

coin return

request

5.2p

Get

payment

coin

product

availablechange due

coins

payment

payment

coins

change coinsreturned

coins

DFD/CFD level 2 : Dispense change

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

State Transition Diagram (STD)

Behavior Model

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment

initial

accept new coin

payment

returned

accept new coincoin detectedaccept

customer

requestproduct

dispensed

accept new coin

sufficient

payment

dispense

product

product

available=FALSE

return payment

coin return

request

return payment

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

CSPEC – Dispense change : Process Activation

Table

Behavior Model

coin return

request

product

available

get change

coin

get

payment

coin

TRUE TRUE 1 0

D/C FALSE 0 1

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Pemodelan BerorientasiObjek

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Keuntungan UML

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Object & Class

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)

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Nama Objek

Atribut2

Operasi2

Object & Class

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Object & ClassP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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.

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Identifikasi Operasi / Servis

A specific behavior that an object is responsible

for exhibiting [Yourdon]

Langkah-langkahIdentifikasi 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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Use Case DiagramP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an Select product

Get return coins

Customer

Enter object

Use Case ScenarioP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Use Case AssociationP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Actor GeneralizationP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

Class Diagram

Menggambarkan struktur statis dari sistem

Terdiri dari node (klas) dan relasi

Jenis relasi Generalization (‘is a’ – inheritance)

Association

Aggregation (‘part-of’)

Composition

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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?

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Class RelationshipsP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Class StereotypesP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Sequence Diagram

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Statechart DiagramP

em

od

ela

n

Re

ka

ya

sa

Ke

bu

tuh

an

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment

initial

accept new coin

payment

returned

accept new coincoin detectedaccept

customer

requestproduct

dispensed

accept new coin

sufficient

payment

dispense

product

product

available=FALSE

return payment

coin return

request

return payment

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

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Pe

mo

de

lan

Re

ka

ya

sa

Ke

bu

tuh

an

Terimakasih v^^