Upload
lamhuong
View
226
Download
0
Embed Size (px)
Citation preview
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