Chapter 9

Process Modeling
(by Rini Astuti)

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Objectives
• Define systems modeling and differentiate logical and physical
models.
• Define process modeling and explain its benefits.
• Mengenali dan memahami konsep dasar dan membangun
sebuah model proses.
• Read and interpret a data flow diagram.
• Explain when to construct process models and where to store
them.
• Construct a context diagram to illustrate a system’s interfaces with
its environment.
• Identify use cases, external and temporal business events.
• Perform event partitioning and organize events in a functional
decomposition diagram.
• Draw event diagrams and merge them into a system diagram.
• Draw primitive data flow diagrams and describe the elementary
data flows in terms of data structures and procedural logic.
• Document the distribution of processes to locations.
• Synchronize data and process models using a CRUD matrix.
9-3
 Models: Logical and Physical

Model – representasi bergambar dari realitas.

Seperti halnya sebuah gambar yang dapat
melukiskan banyak kata, umumnya suatu model
sistem adalah representasi gambar dari kenyataan.
Logical model –
representasi gambar Physical model –
nonteknis yang representasi gambar teknis
menyatakan apa sistem yang menyatakan apa sistem
tsb. atau apa yang tsb. atau apa yang dilakukan
dilakukan sistem. sistem dan bagaimana
Sinonimnya adalah model diimplementasikan.
esensial, model Sinonimnya adalah model
konseptual dan model implementasi dan model
9-4 bisnis teknis.
 Why Logical System Models
• Model logika menghilangkan bias yang
diakibatkan oleh cara pengimplementasian
sistem yang ada atau cara yang dipikirkan
orang tentang kemungkinan sistem
tsb.diimplementasikan.

• Model logika mengurangi resiko kehilangan

kebutuhan bisnis karena kita terlalu berkutat
dengan detil teknis.
• Model logika memungkinkan kita berkomunikasi
dengan pengguna akhir dalam bahasa teknis
maupun non teknis.
9-5
 Process Modeling and DFDs
Process modeling – teknik yang digunakan untuk
mengelola dan mendokumentasikan proses sistem.
• Aliran data melalui proses
• Logika
• Kebijakan
• Prosedur

Data flow diagram (DFD) – model proses yang

digunakan untuk menggambarkan aliran data melalui
sebuah sistem atau pengolahan data yang dilakukan
sistem tsb.
• DFD juga alat yang telah populer untuk rancang ulang proses
bisnis.

9-6
 Simple Data Flow Diagram

9-7
 Differences Between DFDs
and Flowcharts
• Proses dalam DFD dapat dilakukan secara
paralel (at-the-same-time)
• Proses pada Flowcharts mengeksekusi satu per satu

• DFDs menunjukkan aliran data melalui sistem

• Flowcharts menunjukkan aliran kontrol (sequence
and transfer of control)

• Proses dalam DFD dapat menunjukkan proses

dengan waktu yang berbeda (daily, weekly, on
demand)
• Proses pada diagram alir merupakan bagian dari
9-8
satu program dengan waktu yang konsisten
 External Agents
External agent – orang luar, unit, sistem, atau
organisasi yang berinteraksi dengan sistem.
Juga disebut sebagai entitas eksternal.
• External agents define the “boundary” or
scope of a system being modeled.
• Sebagai perubahan ruang lingkup, agen eksternal
dapat menjadi proses, dan sebaliknya.
• Almost always one of the following:
• Office, department, division. Gane and Sarson shape
• An external organization or agency.
• Another business or another
information system.
• One of system’s end-users or managers
• Named with descriptive, singular noun DeMarco/Yourdon shape
9-9
 Data Stores
Data store – data yang tersimpan
dimaksudkan untuk digunakan nanti. Sinonim
adalah file dan database.
• Sering diimplementasikan sebagai file atau
database.
• Sebuah menyimpan data adalah "data non aktif"
dibandingkan dengan aliran data yang "data aktif”
• "Almost always one of the following:
• Persons (or groups of persons)
• Places Gane and Sarson shape
• Objects
• Events (about which data is captured)
• Concepts (about which data is important)
• Data stores depicted on a DFD store
all instances of data entities
9-10
(depicted on an ERD) DeMarco/Yourdon shape
• Named with plural noun
 Process Concepts
Process – pekerjaan yang dilakukan oleh suatu
sistem dalam menanggapi arus data atau kondisi
yang masuk. A synonym is transform.
• Semua Sistem informasi termasuk
proses-proses – biasanya banyak
Gane and Sarson shape
• Proses merespon peristiwa-peristiwa bisnis dan
kondisi dan mengubah data menjadi informasi yang
berguna
• Pemodelan proses membantu kita untuk memahami
interaksi dengan lingkungan sistem, sistem lain, dan
proses lainnya.
• Diberi label dengan kata kerja diikuti dengan objek
yang menggambarkan pada / untuk apa pekerjaan
9-11 yang dilakukan.
 The System is Itself a Process

9-12
 Process Decomposition
Decomposition – tindakan membagi sistem ke
dalam sub-komponen. Setiap tingkat abstraksi
mengungkapkan lebih atau kurang tingkat detail.

9-13
 Decomposition Diagrams
Diagram
Dekomposisi –
alat yang
digunakan untuk
menggambarkan
dekomposisi suatu
sistem. Juga
disebut bagan
hirarki

9-14
 Types of Logical Processes
Function – serangkaian kegiatan yang berkaitan dan
berkelanjutan dalam bisnis.
• Sebuah fungsi tidak memiliki awal atau akhir

Event – unit logis dari pekerjaan yang harus

diselesaikan secara keseluruhan. Sometimes called a
transaction.
• Dipicu oleh input diskrit dan selesai ketika proses telah
merespons dengan output yang sesuai.
• Fungsi terdiri dari proses yang merespons peristiwa-peristiwa
Elementary process – kegiatan, atau tugas diskrit rinci
yang diperlukan untuk menyelesaikan respon terhadap
event. Juga disebut sebagai proses primitif.
• Tingkat terendah detail yang digambarkan dalam proses
model.
9-15
 Common Process Errors on
DFDs

9-16
 Data Flows & Control Flows
Data flow – data that is input to or
output from a process.
• Data yang mengalir Data flow name
• Sebuah aliran data juga dapat digunakan
untuk mewakili pembuatan, membaca,
penghapusan, atau memperbarui data
dalam file atau basisdata (disebut
penyimpan data).
Composite data flow – aliran data
yang terdiri dari arus data lain.
Control flow – kondisi atau peristiwa Control flow name
nondata yang memicu suatu proses.
• Used sparingly on DFDs.
9-17
 Data Flow Packet Concept
• Data that should travel together should be
shown as a single data flow, no matter how
many physical documents might be included.

9-18
 Composite and Elementary
Data Flows

Composite
flow

Elementary
flows

Junction indicates that

any given order is an
instance of only one of
9-19
the order types.
 Data Flows to and from Data
Stores

9-20
 Rules for Data Flows
• A data flow
should never go
unnamed.
• In logical
modeling, data
flow names
should describe
the data flow
without
describing the
implementation
• All data flows
must begin
and/or end at a
process.
9-21
 Data Structures
Data attribute – bagian terkecil sebuah data
yang masih memiliki arti bagi pemakai dan
bisnis.
Data structure – pengaturan khusus atribut data
yang mendefinisikan contoh tunggal dari suatu
aliran data.
• Data atribut yang terdiri dari suatu aliran data diatur ke
dalam struktur data.
• Arus data dapat dijelaskan dalam beberapa jenis
struktur data berikut :
• Urutan atau kelompok atribut data yang terjadi satu demi
satu.
• Pemilihan satu atau lebih atribut dari himpunan atribut.
• Pengulangan dari satu atau lebih atribut.
9-22
 Data Structure for a Data Flow
DATA STRUCTURE
ORDER=
ORDER NUMBER +
ORDER DATE+
[ PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER]
+ and SHIPPING ADDRESS (which is
SHIPPING ADDRESS=ADDRESS+
(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+
QUANTITY ORDERED+
PRODUCT PRICE+
PRODUCT PRICE SOURCE+
EXTENDED PRICE } N+
SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD
NUMBER+EXPIRATION DATE)
(QUOTE NUMBER)
ADDRESS=
(POST OFFICE BOX NUMBER)+
STREET ADDRESS+
CITY+
[STATE, MUNICIPALITY]+
(COUNTRY)+
9-23 POSTAL CODE
ENGLISH ENTERPRETATION
An instance of ORDER consists of:
ORDER NUMBER and
ORDER DATE and
Either PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT
NUMBER
equivalent to ADDRESS)
and optionally: BILLING ADDRESS
(which is equivalent to ADDRESS)
and one or more instances of:
PRODUCT NUMBER and
PRODUCT DESCRIPTION and
QUANTITY ORDERED and
PRODUCT PRICE and
PRODUCT PRICE SOURCE and
EXTENDED PRICE
and SUM OF EXTENDED PRICES and
PREPAID AMOUNT and
optionally: both CREDIT CARD NUMBER
and EXPIRATION DATE
An instance of ADDRESS consists of:
optionally: POST OFFICE BOX NUMBER
and
STREET ADDRESS and
CITY and
Either STATE or MUNICIPALITY
and optionally: COUNTRY
and POSTAL CODE
 Data Structure Constructs
Data Structure
Sequence of Attributes - The
sequence data structure
indicates one or more attributes NUMBER+
that may (or must) be included in TAXPAYER NAME+
a data flow.
Selection of Attributes - The
selection data structure allows
you to show situations where
different sets of attributes
describe different instances of
the data flow.
9-24
Format by Example
(relevant portion is boldfaced
WAGE AND TAX STATEMENT=
TAXPAYER IDENTIFICATION
TAXPAYER ADDRESS+
WAGES, TIPS, AND
COMPENSATION+
FEDERAL TAX WITHHELD+
… FEDERAL TAX WITHHELD
ORDER=
(PERSONAL CUSTOMER
NUMBER,
CORPORATE ACCOUNT
NUMBER)+
ORDER DATE+…
English Interpretation
(relevant portion is boldfaced)
An instance of WAGE AND TAX
STATEMENTS consists of:
TAXPAYER IDENTIFICATION
NUMBER and
TAXPAYER NAME and
TAXPAYER ADDRESS and
WAGES, TIPS AND
COMPENSATION and
and…
An instance or ORDER consists
of:
Either PERSONAL
CUSTOMER NUMBER or
CORPORATE
ACCOUNT NUMBER; and
ORDER DATE and…
 Data Structure Constructs
(continued)
Data Structure Format by Example English Interpretation
(relevant portion is boldfaced (relevant portion is boldfaced)

Repetition of Attributes - The POLICY NUMBER+ An instance of CLAIM consists

repetition data structure is used POLICYHOLDER NAME+ of:
to set off a data attribute or POLICY HOLDER POLICY NUMBER and
group of data attributes that may ADDRESS+ POLICYHOLDER NAME and
(or must) repeat themselves a 0 {DEPENDENT NAME+ POLICYHOLDER ADDRESS
specific number of time for a DEPENDENT’S and
single instance of the data flow. RELATIONSHIP} N+ zero or more instance of:
The minimum number of 1 {EXPENSE DESCRIPTION+ DEPENDENT NAME and
repetitions is usually zero or one. SERVICE PROVIDER+ DEPENDENT’S
The maximum number of EXPENSE AMOUNT} N RELATIONSHIP and
repetitions may be specified as one or more instances of:
“n” meaning “many” where the EXPENSE DESCRIPTION
actual number of instances and
varies for each instance of the SERVICE PROVIDER and
data flow. EXPENSE ACCOUNT

9-25
 Data Structure Constructs
(concluded)
Data Structure Format by Example English Interpretation
(relevant portion is boldfaced (relevant portion is boldfaced)
Optional Attributes - The optional CLAIM= An instance of CLAIM consists
notation indicates that an POLICY NUMBER+ of:
attribute, or group of attributes in POLICYHOLDER NAME+ POLICY NUMBER and
a sequence or selection date POLICYHOLDER ADDRESS+ POLICYHOLDER NAME and
structure may not be included in ( SPOUSE NAME+ POLICYHOLDER ADDRESS
all instances of a data flow. DATE OF BIRTH)+… and
Note: For the repetition data optionally, SPOUSE NAME
structure, a minimum of “zero” is and
the same as making the entire DATE OF BIRTH and…
repeating group “optional.”

Reusable Attributes - For groups DATE= Then, the reusable structures

of attributes that are contained in MONTH+ can be included in other data
many data flows, it is desirable DAY+ flow structures as follows:
to create a separate data YEAR+ ORDER=ORDER NUMBER…
structure that can be reused in +DATE
other data structures. INVOICE=INVOICE
NUMBER…+DATE
PAYMENT=CUSTOMER
NUMBER…+DATE
9-26
 Data Types and Domains

Data atribut harus ditentukan oleh jenis

data dan domain.

Data type - kelas data yang dapat

disimpan dalam atribut .
• Character, integers, real numbers, dates,
pictures, etc.

Domain – nilai valid dari atribut .

9-27
 Diverging and Converging
Data Flows
Diverging data flow – aliran data yang
memisah jadi banyak aliran data
• Menunjukkan data yang dimulai secara alami
sebagai salah satu aliran, tetapi diteruskan ke tujuan
yang berbeda.
• Juga berguna untuk menunjukkan beberapa salinan
dari output yang sama akan ke tujuan yang berbeda.
• Converging data flow – gabungan
banyak aliran data menjadai aliran data
tunggal
• Menunjukkan data dari berbagai sumber yang dapat
(harus) datang bersama-sama sebagai satu paket
9-28
untuk diproses selanjutnya
 Diverging and Converging
Data Flows

9-29
 Classical Structured Analysis
Rarely practiced anymore because cumbersome & time-consuming

1. Draw top-down physical DFDs that represent current

physical implementation of the system.
2. Convert physical DFDs to logical equivalents.
3. Draw top-down logical DFDs that represent improved
system.
4. Describe all data flows, data stores, policies, and
procedures in data dictionary or encyclopedia.
5. Optionally, mark up copies of the logical DFDs to
represent alternative physical solutions.
6. Draw top-down physical DFDs representing target
solution.

9-30
 Modern Structured Analysis
(More Commonly Practiced)

1. Draw context DFD to establish initial project scope.

2. Draw functional decomposition diagram to partition the
system into subsystems.
3. Create event-response or use-case list for the system
to define events for which the system must have a
response.
4. Draw an event DFD (or event handler) for each event.
5. Merge event DFDs into a system diagram (or, for larger
systems, subsystem diagrams).
6. Draw detailed, primitive DFDs for the more complex
event handlers.
7. Document data flows and processes in data dictionary.
9-31
 Structured Analysis Diagram
Progression (1 of 3)

9-32
 Structured Analysis Diagram
Progression (2 of 3)

9-33
 Structured Analysis Diagram
Progression (3 of 3)

9-34
 CASE for Process Modeling

9-35
 Context Data Flow Diagram
• Context data flow diagram - a process model
used to document the scope for a system. Also
called the environmental model.

1. Think of the system as a "black box."

2. Ask users what business transactions the system
must respond to. These are inputs, and the sources
are external agents.
3. Ask users what responses must be produced by the
system. These are outputs, and the destinations are
external agents.
4. Identify any external data stores, if any.
5. Draw a context diagram.
9-36
 SoundStage Context DFD

9-37
 SoundStage Functional
Decomposition Diagram
• Break system into
sub-components
to reveal more
detail.
• Every process to
be factored
should be
factored into at
least two child
processes.
• Larger systems
might be factored
into subsystems
and functions.
9-38
 Events and Use Cases
• External events are initiated by external agents. They
result in an input transaction or data flow.

• Temporal events are triggered on the basis of time, or

something that merely happens. They are indicated
by a control flow.
• State events trigger processes based on a system’s
change from one state or condition to another. They
are indicated by a control flow.

• Use case – an analysis tool for finding and identifying

business events and responses.

• Actor – anything that interacts with a system.

9-39
 SoundStage Partial Use Case
List
Actor/ Event Trigger Response
External Agent (or Use Case)
Marketing Establishes a new New Member Generate Subscription Plan
membership Subscription Confirmation.
subscription plan to Program Create Agreement in the
entice new members. database.
Marketing Establishes a new Past Member Generate Subscription Plan
membership Resubscription Confirmation.
resubscription plan to Program Create Agreement in the
lure back former database.
members.
(time) A subscription plan (current date) Generate Agreement Change
expires. Confirmation.
Logically delete Agreement in
database.
Member Joins club by New Generate Member Directory
subscribing. Subscription Update Confirmation.
Create Member in database.
Create first Member Order and
Member Ordered Products in
database.
9-40
 SoundStage Partial
Event Decomposition Diagram

9-41
 Event Diagrams
Event diagram – data flow diagram that
depicts the context for a single event.
• One diagram for each event process
• Depicts
• Inputs from external agents
• Outputs to external agents
• Data stores from which records must be "read."
Data flows should be added and named to
reflect the data that is read.
• Data stores in which records must be created,
deleted, or updated. Data flows should be
named to reflect the update.
9-42
 Simple Event Diagram

9-43
 Event Diagram (more complex)

9-44
 Temporal Event Diagram

9-45
 System DFD

9-46
 System DFD (concluded)

9-47
 Balancing

Balancing - a concept that requires that

data flow diagrams at different levels of
detail reflect consistency and completeness

• Quality assurance technique

• Requires that if you explode a process to
another DFD to reveal more detail, you must
include the same dta flows and data stores

9-48
 Primitive Diagrams

• Beberapa (tidak perlu semua) proses

dapat dipecah ke dalam diagram primitif
untuk mengungkap lebih detil.
• proses transaksi bisnis kompleks
• Proses didekomposisi menjadi beberapa
proses dasar
• Setiap proses dasar yang kohesif - hal itu
hanya satu hal
• Arus mirip dengan struktur program komputer
9-49
 Primitive DFD
(see book for more readable copy)

9-50
 Specifying a Data Flow
Using a CASE Tool

9-51
 Process Logic
• Data Flow Diagram baik untuk mengidentifikasi
dan menjelaskan proses
• Tidak baik di dalam logika yang menunjukkan
proses
• Harus menetapkan petunjuk rinci untuk proses
dasar
• Bagaimana melakukannya?
• Flowcharts & Pseudocode – umumnya pemakai akhir
tidak memahaminya
• Natural English - tepat dan tunduk pada interpretasi
9-52
 Problems with Natural English
• Banyak yang tidak menulis dengan baik dan tidak
mempertanyakan kemampuan menulis.
• Banyak juga dididik untuk berkomunikasi dengan
khalayak umum
• Beberapa menulis semuanya seperti itu program.
Dapat memungkinkan jargon komputasi, akronim bahasa
mendominasi.
• Laporan sering memiliki ruang lingkup yang berlebihan
atau membingungkan.
• Terlalu sering menggunakan kalimat majemuk.
• Terlalu banyak kata memiliki beberapa definisi.
• Terlalu banyak laporan tidak tepat menggunakan kata
Source: Adapted from Matthies, Leslie, The New Playscript Procedure,
9-53 sifat. (Stamford, CT: Office Publications, Inc. 1977)

instruksi dapat Bersyarat tidak tepat.

 Structured English

Structured English – a language syntax

for specifying the logic of a process.
• Based on the relative strengths of structured
programming and natural English.

9-54
 Structured English Constructs
(Part 1)

9-55
 Structured English Constructs
(Part 2)

9-56
 Structured English Restrictions
on Process Logic
• Only strong, imperative verbs may be used.
• Only names that have been defined in project
dictionary may be used.
• Formulas should be stated clearly using
appropriate mathematical notations.
• Undefined adjectives and adverbs are not
permitted.
• Blocking and indentation are used to set off the
beginning and ending of constructs.
• User readability should always take priority.
9-57
 Policies and Decision Tables

Policy – a set of rules that govern show a

process is to be completed.

Decision table – a tabular form of

presentation that specifies a set of
conditions and their corresponding actions.
• As required to implement a policy.

9-58
 A Simple Decision Table

9-59
 Describing an Elementary
Process Using a CASE Tool

9-60