Analysis Modeling

y Data modeling
y Functional modeling and information flow
y Behavioral modeling
y Structured analysis
Ir. I Gede Made Karma, MT

Overview Structured Analysis (DeMarco)
y The analysis model is the first technical representation of a system.  y Analysis products must be highly maintainable, especially the 
y Analysis modeling uses a combination of text and diagrams to represent software  software requirements specification. 
requirements (data, function, and behavior) in an understandable way. 
y Building analysis models helps make it easier to uncover requirement inconsistencies  y Problems of size must be dealt with using an effective method of 
and omissions.  partitioning. 
y Two types of analysis modeling are commonly used: 
yp y g y
y structured analysis (discussed in this chapter) and 
y Graphics should be used whenever possible. 
Graphics should be used whenever possible  
y object‐oriented analysis (discussed in Chapter 21).  y Differentiate between the logical (essential) and physical 
y Data modeling uses entity‐relationship diagrams to define data objects, attributes,  (implementation) considerations. 
and relationships. 
y Functional modeling uses data flow diagrams to show how data are transformed 
y Find something to help with requirements partitioning and 
inside the system.  document the partitioning before specification. 
y Behavioral modeling uses state transition diagrams to show the impact of events.  y Devise a way to track and evaluate user interfaces. 
y Analysis work products must be reviewed for completeness, correctness, and 
consistency.  y Devise tools that describe logic and policy better than narrative 
y The SEPA web site contains descriptions of several classical analysis techniques  text.
(DSSD, JSD, SADT). 

Analysis Model Objectives Analysis Model Elements
y Describe what the customer requires.  y Data dictionary ‐ contains the descriptions of all data objects 
consumed or produced by the software 
y Establish a basis for the creation of a software design.  y Entity relationship diagram (ERD) ‐ depicts relationships 
y Devise a set of requirements that can be validated once the  between data objects 
software is built.
f  i  b il y Data flow diagram (DFD) ‐
Data flow diagram (DFD)  provides an indication of how data 
are transformed as they move through the system; also depicts 
functions that transform the data flow (a function is represented 
in a DFD using a process specification or PSPEC) 
y State transition diagram (STD) ‐ indicates how the system 
behaves as a consequence of external events, states are used to 
represent behavior modes. Arcs are labeled with the events 
triggering the transitions from one state to another (control 
information is contained in control specification or CSPEC)

RPL - Analysis Modeling : Ir. I Gede Made Karma, MT

1
Data Modeling Elements (ERD) Cardinality and Modality (ERD)
y Data object ‐ any person, organization, device, or software  y Cardinality ‐ in data modeling, cardinality specifies how the 
product that produces or consumes information  number of occurrences of one object are related to the 
y Attributes ‐ name a data object instance, describe its  number of occurrences of another object (1:1, 1:N, M:N) 
characteristics, or make reference to another data object 
characteristics  or make reference to another data object  y Modality ‐
Modality  zero (0) for an optional object relationship and 
y Relationships ‐ indicate the manner in which data objects  one (1) for a mandatory relationship
are connected to one another

Functional Modeling and Information Flow 
(DFD) Behavioral Modeling (STD)
y Shows the relationships of external entities, process or  y State transition diagrams represent the system states and 
transforms, data items, and data stores  events that trigger state transitions 
y DFD's cannot show procedural detail (e.g. conditionals  y STD's indicate actions (e.g. process activation) taken as a 
or loops) only the flow of data through the software 
p y g consequence of a particular event 
q p
y Refinement from one DFD level to the next should  y A state is any observable mode of behavior 
follow approximately a 1:5 ratio (this ratio will reduce as  y Hatley and Pirbhai control flow diagrams (CFD) can also be 
the refinement proceeds)  used for behavioral modeling
y To model real‐time systems, structured analysis 
notation must be available for time continuous data 
and event processing (e.g. Ward and Mellor or Hately 
and Pirbhai)

Creating Entity Relationship Diagrams E‐R Diagram (1)
y Customer asked to list "things" that application  y Contoh:
addresses, these things evolve into input objects,  n m
output objects, and external entities  Buku meminja
Peminjam

y Analyst and customer define connections between the 
y y Entitas: m

objects  y Buku
y One or more object‐relationship pairs is created for  y Atribut: ISBN, Judul, Pengarang, Penerbit, ...
each connection  y Peminjam
y The cardinality and modality are determined for an  y Atribut: NIM, Nama, Alamat, ...
object‐relationship pair 
y Attributes of each entity are defined 
y The entity diagram is reviewed and refined

RPL - Analysis Modeling : Ir. I Gede Made Karma, MT

2
ER Diagram (2) Creating Data Flow Diagram
y Relasi: y Level 0 data flow diagram should depict the system as a single 
bubble 
y Meminjam
y Atribut: ISBN, NIM, …
y Primary input and output should be carefully noted 
y Refinement should begin by consolidating candidate processes, 
g y g p
y Kardinalitas:
data objects, and data stores to be represented at the next level 
y N‐M
y Label all arrows with meaningful names 
y 1 buku dapat dipinjam oleh banyak peminjam dan
y 1 peminjam dapat meminjam banyak buku
y Information flow must be maintained from one level to level 
y Refine one bubble at a time 
y Catatan: 
y bedakan ERD dalam level abstraksi permasalahan sistem 
y Write a PSPEC (a "mini‐spec" written using English or another 
dengan ERD dalam level abstraksi kebutuhan PL natural language or a program design language) for each bubble 
in the final DFD

Context Diagram Data Flow Diagram (1)

• Merepresentasikan sistem sebagai sebuah • Penjabaran lebih lanjut dari Diagram Konteks
‘black box’ terhadap lingkungan sekitarnya • dapat terdiri atas beberapa level
• Contoh: gg
– level 0: level tertinggi
– level 1: penjabaran dari level 0
Id_ pemakai +
jenis permintaan

Sistem – level 2: penjabaran dari level 1, dst

Pemakai Informasi
Perpustakaa
n • semakin rendah levelnya, semakin rinci fungsinya
laporan • Catatan:
– bedakan DFD dalam level abstraksi permasalahan sistem dengan
DFD dalam level abstraksi kebutuhan PL

Data Flow Diagram (2) Data Flow Diagram (3)

• Notasi dasar: • Contoh level 0:

Id_ pemakai + Id_ pemakai +
External Entity jenis
jenis 0.2
Process Data Store permintaan permintaan
Pencari- pustaka
Data Object an data
0.1
Masuka
n data 0.4 laporan
pustaka Penceta-
kan data

• Setiap proses harus diberi nomor: peminjam Id_ pemakai +

jenis
0.3
Update pustaka
– level.nomor-urut
permintaan data

RPL - Analysis Modeling : Ir. I Gede Made Karma, MT

3
 Process Specification (1) Process Specification (2)

• Deskripsi rinci setiap proses yang • Contoh:

muncul pada DFD – P-SPEC 0.4:
• Input:
–p
proses yyang
g harus mengandung
g g P-SPEC – id_pemakai
– data buku
adalah proses yang sudah tidak • Output:
– file teks
didekomposisi lagi menjadi sub-proses • Algoritma:
dibawahnya (sudah level terendah) if found then
print header
else . . .

Creating Control Flow Diagrams Data Dictionary Contents
y Creating Control Flow Diagrams y Data Dictionary Contents
y Name ‐ primary name for each data or control item, 
y Begin by stripping all the data flow arrows form the DFD  data store, or external entity 
y Events (solid arrows) and control items (dashed arrows) are  y Alias ‐ alternate names for each data object 
added to the diagram 
dd d    h  di   y Where‐used/how‐used ‐
Wh d/h d  a listing of processes that use 
 li i   f   h    
y Add a window to the CSPEC (contains an STD that is a 
the data or control item and how it is used (e.g. input 
to process, output from process, as a store, as an 
sequential specification of the behavior) for each bubble in  external entity) 
the final CFD y Content description ‐ notation for representing content 
y Supplementary information ‐ other data type 
information, preset values, restrictions, limitations, 
etc.

Data Dictionary (1) Data Dictionary (2)

• Berisi:
• Menyimpan semua objek data yang – Name
dibutuhkan dan dihasilkan oleh PL • nama utama yang muncul pada objek data, data store,
atau external entity
– objek data yang muncul pada: – Alias
• ERD • nama lain yang digunakan
• DFD – Where-used/how-used
• daftar proses yang menggunakan data dan bagaimana
• STD menggunakannya
– harus selengkap dan serinci mungkin – Content description
• notasi untuk merepresentasikan isi data
• contoh: Nama = nama_depan +
– Supplementary information
nama_belakang

RPL - Analysis Modeling : Ir. I Gede Made Karma, MT

4
 Data Dictionary (3) Data Dictionary (4)
• Notasi:
Jenis Notasi Arti
• Contoh:
====================================== – nama mahasiswa = nama depan + nama
= Terdiri atas
urutan
t + dan
d belakang
pilihan [ | ] atau – jenis kelamin = [perempuan | laki-laki]
pengulangan { }n Pengulangan sebanyak n kali
( ) Data optional – nomor telepon = (kode negara) + kode
* * pembatas komentar wilayah + nomor

State Transition Diagram

Behavioral Modeling
y Mendeskripsikan status sistem yang dapat muncul  • Contoh STD untuk mesin otomatis penjual minuman
ketika perangkat lunak digunakan (tidak ada hubungannya dengan contoh sebelumnya):

y mendeskripsikan kelakuan sistem
inisialisasi
Pembayaran dikembalikan
Terima koin baru
Terima koin baru
y Tools: Menunggu koin

Koin sah terdeteksi

y State Transition Diagram Terima permintaan
Permintaan pengembalian koin

Kembalikan pembayaran
y Control Specification Minuman dikeluarkan
Menunggu masukan pilihan Mengembalikan
Terima koin baru pembayaran
y Umumnya digunakan pada sistem waktu‐nyata Pembayaran mencukupi
Minuman tersedia = 0

Kembalikan pembayaran
Keluarkan minuman

Mengeluarkan minuman

Control Specification Kaitan antara Data dan Control Model

• Fungsi C-SPEC sama dengan P-SPEC Data input Process Model

Data
output

namun berisi deskripsi dari setiap status DFD

yyang
g dapat
p muncul p pada sistem Process
activators
PSPEC

Control Data
Model conditions
CFD

CSPEC
Control output Control input

RPL - Analysis Modeling : Ir. I Gede Made Karma, MT

5