ANALISIS DAN PERANCANGAN SISTEM (APS) Pemodelan Kebutuhan: Pendekatan Terstruktur

(1)

ANALISIS DAN PERANCANGAN

SISTEM (APS)

Pemodelan Kebutuhan:

Pendekatan Terstruktur

(2)

Tujuan perkuliahan

Memahami pemodelan yang dibutuhkan dalam

rekayasa kebutuhan

Memahami konsep pendekatan terstruktur dalam

pemodelan kebutuhan

(3)

Bahan Kuliah APS - Pemodelan Kebutuhan: Terstruktur | Tri A. Kurniawan, S.T, M.T, Ph.D 3/26

Agenda

Konsep pemodelan kebutuhan

Konsep pemodelan terstruktur

(4)

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

(5)

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

Pastikan bahwa model kebutuhan memiliki nilai

manfaat untuk seluruh stakeholders

Model dibuat sesederhana mungkin  notasi yang

sederhana, non duplikasi informasi

(6)

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

(7)

(8)

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

(9)

Elemen-elemen pemodelan

Data Dictionary Data Flow Diagram (DFD) ER Diagram State Transition Diagram (STD) Process Specification (PSPEC) Data Object Description Control Specification (CSPEC)

(10)

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

(11)

Data model – ER diagram

Entitas (atribut dan nilai atribut)

Modalitas : tingkat mandatory (minimal)

Kardinalitas : tingkat relasi (maksimal)

Bentuk relasi

(12)

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)

(13)

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

(14)

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

(15)

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

(16)

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

(17)

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)

Process model – DFD/CFD leveling

(19)

Data/Control Context Diagram (DCD/CCD)

Vend

product

Customer

returned coins 0*

Customer

product object customer selection slug coin return request product available

(20)

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

(21)

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

(22)

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

(23)

Behavior model

State Transition Diagram (STD)

Waiting for a coin Waiting for selection Dispensing product Returning payment initial accept new coin