Pemodelan Proses
dan Data
Copyright to Modern Systems Analysis and Design,
Global Edition, 9th Edition
Pemodelan Proses
DEFINISI
1. Merupakan suatu cara untuk merepresentasikan bagaimana suatu
sistem beroperasi;
2. Mengilustrasikan beberapa aktifitas yang dilaukan dan bagaimana
proses aliran data.
Data Flow Diagram
Source : Modern Systems Analysis and Design, Global Edition, 9th Edition
Data Flow Diagram
Source : Modern Systems Analysis and Design, Global Edition, 9th Edition
Why DFD?
First,
a context diagram shows the scope of the system, indicating which elements are
inside and which are outside the system.
Second,
DFDs of the system specify which processes move and transform data, accepting
inputs and producing outputs
DFDs provide notation as well as illustrate important concepts about the
movement of data between manual and automated steps, and they offer a way to
depict work flow in an organization
DFD Symbols
Data store
Data at rest, which may take the form of
many different physical representations.
Process
The work or actions performed on data so
that they are transformed, stored, or
distributed.
Source/sink
The origin and/or destination of data;
sometimes referred to as external entities
DFD’s Rules
DFD’s Rules
DFD’s Diagram
Level-0 diagram
A DFD that represents a system’s major processes, data flows, and data stores at
a high level of detail.
This diagram is called a level-0 diagram because it represents the primary individual
processes in the system at the highest possible level. Each process has a number that
ends in .0 (corresponding to the level number of the DFD).
Level-n diagram
A DFD that is the result of n nested decompositions from a process on a level-0
diagram.
In general, a level-n diagram is a DFD that is generated from n nested decompositions
from a level-0 diagram
Guidelines for Drawing DFDs
Completeness,
The concept of DFD completeness refers to whether you have included in your DFDs all of the
components necessary for the system you are modeling. If your DFD contains data flows that do
not lead anywhere or data stores, processes, or external entities that are not connected to
anything else, your DFD is not
complete.
Consistency,
The concept of DFD consistency refers to whether or not the depiction of the system shown at
one level of a nested set of DFDs is compatible with the depictions of the system shown at other
levels. A gross violation of consistency would be a level-1 diagram with no level-0 diagram.
Another example of inconsistency would be a data flow that appears on a higher-level DFD but
not on lower levels (also a violation of balancing). Yet another example of inconsistency is a data
flow attached to one object on a lower-level diagram but also attached to another object at a
higher level.
Guidelines for Drawing DFDs (Cont.)
Timing,
You may have noticed in some of the DFD examples we have presented that
DFDs do not do a very good job of representing time. On a given DFD, there is no
indication of whether a data flow occurs constantly in real time, once per week, or once per year.
There is also no indication of when a system would run. For example, many large, transaction-
based systems may run several large, computing-intensive jobs in batch mode at night, when
demands on the computer system are lighter. A DFD has no way of indicating such overnight
batch processing. When you draw DFDs, then, draw them as if the system you are modeling has
never started and will never stop.
Iterative Development,
The first DFD you draw will rarely capture perfectly the system you are modeling. You should
count on drawing the same diagram over and over again, in an iterative fashion. With each
attempt, you will come closer to a good approximation of the system or aspect of the system you
are modeling. Iterative DFD development recognizes that requirements determination and
requirements structuring are interacting, not sequential, subphases of the analysis phase of the
SDLC.
Guidelines for Drawing DFDs (Cont.)
Primitive DFDs,
One of the more difficult decisions you need to make when drawing DFDs is when to stop
decomposing processes. One rule is to stop drawing when
you have reached the lowest logical level; however, it is not always easy to know what the lowest
logical level is
Object-oriented Analysis and Design
Use Case Diagrams,
A use case diagram is depicted
diagrammatically. It is a picture that shows
system behavior, along with the key actors that
interact with the system.
Use Case Diagram
Definitions and Symbols
Actor. An actor is a role, not an individual. Individuals are
instances of actors. One particular individual may play many
roles simultaneously. An actor is involved with the functioning of a
system at some basic level. Actors are represented by stick
figures.
Use case. Each use case is represented as an ellipse. Each use
case represents a single system function. The name of the use
case can be listed inside the ellipse or just below it.
Definitions and Symbols (Cont.)
System boundary
The system boundary is represented as a box that includes all of
the relevant use cases. Note that actors are outside the system
boundary.
Connections
A solid line connecting an actor to a use case shows that the actor is
involved in that particular system function. The solid line does not mean
that the actor is sending data to or receiving data from the use case.
Note that all of the actors in a use case diagram are not involved in all
the use cases in the system.
IT’S TIME TO TRY
CHEERS
