Adam Hendra Brata

Teknik Informatika FILKOM UB

Semester Genap 2015/2016

TUJUAN PERKULIAHAN

• Memahami pemodelan yang dibutuhkan dalam rekayasa

kebutuhan

• Memahami konsep pendekatan terstruktur dalam

pemodelan kebutuhan

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

AGENDA PERKULIAHAN

• Konsep pemodelan kebutuhan

• Konsep pemodelan terstruktur

• Elemen-elemen pemodelan terstruktur

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

MOTIVASI REKAYASA KEBUTUHAN

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Model kebutuhan menjembatani antara deskripsi sistem

secara umum dengan model perancangan

• Metode : terstruktur & berorientasi objek

• Tujuan utama model kebutuhan:

• Menjadi referensi dalam melakukan validasi kebutuhan

• Menjadi dasar bagi perancangan PL

• Menjelaskan apa yang dibutuhkan oleh customer

PRINSIP PEMODELAN KEBUTUHAN

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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/modul

• Pastikan bahwa model kebutuhan memiliki nilai manfaat untuk

seluruh stakeholders

• Model dibuat sesederhana mungkin notasi yang sederhana,

non duplikasi informasi

TIPE-TIPE MODEL KEBUTUHAN

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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

KONSEP

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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

ELEMEN-ELEMEN PEMODELAN

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

Data Dictionary

Data Flow Diagram

(DFD)

ER Diagram

State Transition Diagram

(STD)

Process Specification

(PSPEC)

Data Object Description

Control Specification

(CSPEC)

DATA DICTIONARY

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

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

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Entitas (atribut dan nilai atribut)

• Modalitas : tingkat mandatory (minimal)

• Kardinalitas : tingkat relasi (maksimal)

• Bentuk relasi

Manufacturer CarBuilds

DATA MODEL – DATA OBJECT DESCRIPTION

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Data Object

• merupakan informasi komposit

• terdiri dari sejumlah atribut atau properti yang berbeda

• Mengenkapsulasi data saja tidak ada operasi yang

diterapkan pada data tersebut

• bisa entitas eksternal, hal, kejadian / peristiwa, peran, unit

organisasi, struktur, dll

• misalnya dimensi (tinggi, berat, kedalaman), mobil (membuat,

model, ID, tipe bodi, warna, pemilik)

• dapat direpresentasikan dalam representasi berbentuk tabel

PROCESS MODEL – DFD

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Berguna untuk menganalisis sistem yang sudah ada maupun

sistem yang akan diusulkan dekomposisi proses

• Fokus pada “pergerakan” data antara entitas eksternal dan

proses, dan antara proses dan penyimpanan data

• Sebuah teknik yang relatif sederhana untuk dipelajari dan

digunakan

• Elemen model : terminator, proses, aliran data / data flow, aliran

kontrol / control flow, penyimpanan, bar kontrol / control bar

• Tingkat tertinggi (0) Diagram konteks

• proses tunggal

• terminator

• Arus data, arus kontrol

PROCESS MODEL – ELEMEN DFD

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Terminator

• Representasi entitas eksternal

• Notasi: persegi panjang

• Tidak memproses data

• Data Flow / Aliran Data

• Representasi aliran data

• Notasi: anak panah penuh

• Umumnya satu arah

• Hubungkan terminator, process dan storage

• Control Flow / Aliran Kontrol

• Representasi aliran kontrol proses

• Notasi: anak panah putus2

• Hubungkan terminator, process dan control bar

Customer

data

control

PROCESS MODEL – ELEMEN DFD

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Process / Proses

• Representasi aktifitas sistem

• Notasi: lingkaran

• Memproses data

• Storage / Penyimpanan

• Representasi tempat penyimpanan data

• Notasi: dua garis paralel

• Data flow in = diubah, data flow out = dibaca

• Control Bar / Bar Kontrol

• Representasi spesifikasi kontrol

• Notasi: garis tegak

1

Proses A

data X

PROCESS MODEL – DFD

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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 harusdiinterpretasikan untuk merubah perilaku sistem dan/ aktifasiproses

• Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekalijadi

• Penjenjangan CFD harus sesuai dengan DFD

DATA – CONTROL IDENTIFICATION

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Urutan identifikasi dimulai dari data kemudian baru kontrol

untuk mengetahui apa yang kita kendalikan pertama

kali

• Adanya sinyal yang kontinyu dan ada proses yang bekerja,

selalu dikategorikan sebagai data

• Adanya sinyal diskrit dan ada proses yang bekerja, biasanya

dikategorikan sebagai kontrol

• Istilah seperti mengaktifkan, menyalakan, terlibat dan

mengeksekusi biasanya berhubungan dengan persyaratan

kontrol

PROCESS MODEL – DFD/CFD LEVELING

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Harus konsisten

DATA/CONTROL CONTEXT DIAGRAM (DCD/CCD)

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

Vend

productCustomer

returned coins

0*

Customer

product

object

customer

selection

slug

coin return

request product

available

DATA/CONTROL FLOW DIAGRAM (DFD/CFD LEVEL 1)

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

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 detectedsufficient

payment

product

dispensed

product

available

product

available

DATA/CONTROL FLOW DIAGRAM (DFD/CFD LEVEL 2)

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• DFD/CFD level 2 : Dispense change

5.1p

Get change

coin

coin return

request

5.2p

Get

payment

coin

product

availablechange due

coins

payment

payment coins

change coins returned coins

PROCESS MODEL – PROCESS SPECIFICATION

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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

BEHAVIOR MODEL

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• State Transition Diagram (STD)

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment

initial

accept new coin

payment returned

accept new coincoin detected

accept customer

requestproduct dispensed

accept new coin

sufficient payment

dispense product

product

available=FALSE

return payment

coin return request

return payment

BEHAVIOR MODEL

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• 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

KESIMPULAN

T E K N I K I N FO R M AT I K A F I L KO M U B

S E M E S T E R G E N A P 2 0 1 5 / 2 01 6

APS

• Pemodelan kebutuhan diperlukan untuk meningkatkan

pemahaman terhadap kebutuhan yang sedang dianalisis

• Pemodelan terstruktur meliputi pemodelan data, proses

dan perilaku dari sistem yang sedang dikembangkan

TERIMAKASIH V^^

To Infinity

and Beyond !

APS