CTIS 359 Principles of
Software Engineering
System Models
Cüneyt Sevgi CTIS 359 Fall 07-08
Today’s objectives
 To
explain DFDs for
requirements capturing and
modeling.
 To explain Use-Cases for
requirements capturing and
modeling.
Cüneyt Sevgi CTIS 359 Fall 07-08
Data Flow Diagrams (DFDs)

Notation for writing semi-formal operational
specifications
◦ Graphical notation
◦ Well-suited for analyzing/specifying traditional
◦ information-systems problems

System modeled as collection of data, which are
manipulated by “functions”
◦ Data can be persistent (stored in data repositories)
◦ Data can flow between/among functions
◦ Each function can be systematically decomposed into
a more refined DFD
Cüneyt Sevgi CTIS 359 Fall 07-08
DFDs Created by Top-Down Analysis

Create a narrative: description of
system

Create a Context Diagram that
contains a single process (“the
system”) and all entities which
share data with the system

Explode the “parent” context
diagram to produce a Diagram 0
(“child”) DFD

Create Diagram 1, 2, …, n DFDs
that represent “explosions” of
Diagram 0, 1, …, n-1 DFDs until a
diagram has only “primitive”
processes

Create process descriptions to be
implemented by application
programs: queries, macros, reports,
programming languages
Narrative
Context Diagram
Diagram 0 DFD
Diagram 1 DFDs
Diagram n DFDs
E-R Diagram
Process Descriptions
Cüneyt Sevgi CTIS 359 Fall 07-08
DFDs Created by Top-Down Analysis
(Cont.)
CONTEXT DIAGRAM
Level 1.2 DFD
2.2
2.1
2.3
Process
Specification
for Data Flow
Diagram 2.3
Process Spec for Level 2.3
kahgdkljhckldsajcaljscaljljakdclnh
kljclkjcl;kjcl;asjca;sjcjc;kkdj;jsa;k
ckjal;kjcalkjcal;jcaljcal;kjckljcakj
Level 0
DFD
1
2
3
4
if kjc = mjclakj
then
do
ldclscknlskld
else
jhalkscjl
lnhclsncdslnc
end - specification
Cüneyt Sevgi CTIS 359 Fall 07-08
External Agents (Entity)
External agent – an outside person,
organization unit, system, or organization that
interacts with a system. Also called an external
entity.
◦ External agents define the “boundary” or scope of
a system being modeled.
◦ As scope changes, external agents can become
processes, and vice versa.
◦ Almost always one of the following:




Office, department, division.
An external organization or agency.
Another business or another information system.
One of your system’s end-users or managers
◦ Named with descriptive, singular noun
Cüneyt Sevgi CTIS 359 Fall 07-08
Data Stores (Sink)
Data store – stored data intended for later
use. Synonyms are file and database.
◦ Frequently implemented as a file or database.
◦ A data store is “data at rest” compared to a data
flow that is “data in motion.”
◦ Almost always one of the following:





Persons (or groups of persons)
Places
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
(depicted on an ERD)
◦ Named with plural noun
Cüneyt Sevgi CTIS 359 Fall 07-08
Data Flows
◦ Data flow – A data flow is data in motion.
◦ A data flow may also be used to represent the
creation, reading, deletion, or updating of data
in a file or database.
• Represent the transfer of data over time
from one “place” (entity, process, data
store) to another
• Examples: New Student Information
New Student
Information
Cüneyt Sevgi CTIS 359 Fall 07-08
Process Concepts
Process –
work
performed by a
system in
response to
incoming data
flows or
conditions. A
synonym is
transform.
Cüneyt Sevgi CTIS 359 Fall 07-08
Common Process Errors on DFDs
Cüneyt Sevgi CTIS 359 Fall 07-08
Data Flow Packet Concept
Cüneyt Sevgi CTIS 359 Fall 07-08
Composite and Elementary Data
Flows
Cüneyt Sevgi CTIS 359 Fall 07-08
Data Flows to and from Data Stores
Cüneyt Sevgi CTIS 359 Fall 07-08
Illegal Data Flows
Cüneyt Sevgi CTIS 359 Fall 07-08
Diverging and Converging Data
Flows
Diverging data flow – a data flow that
splits into multiple data flows.
◦ Indicates data that starts out naturally as one
flow, but is routed to different destinations.
◦ Also useful to indicate multiple copies of the
same output going to different destinations.
Converging data flow – the merger of
multiple data flows into a single packet.
◦ Indicates data from multiple sources that can
(must) come together as a single packet for
subsequent processing.
Cüneyt Sevgi CTIS 359 Fall 07-08
Diverging and Converging Data
Flows
Cüneyt Sevgi CTIS 359 Fall 07-08
CASE for DFDs (Sample Screen)
from System Architect 2001
Cüneyt Sevgi CTIS 359 Fall 07-08
Sample Data to Process CRUD
Matrix
Cüneyt Sevgi CTIS 359 Fall 07-08
Sample Process to Location
Association Matrix
Cüneyt Sevgi CTIS 359 Fall 07-08

Our consulting firm has just been hired by Knights Pies to
develop a system to record orders for pizza and buffalo
wings. When regular customers call Knights Pies on the
phone, they are asked their phone number. When the
number is typed into a computer, the name, address, and last
order date is automatically brought up on the screen. If the
customer is new, then they are added to the system. Once
the order is taken, the total, including tax and delivery, is
calculated. Then the order is given to the cook. A receipt is
printed. Occasionally, special offers (coupons) are printed so
the customer can get a discount. Drivers who make
deliveries give customers a copy of the receipt and a coupon
(if any). Weekly totals are kept for comparison with last
year’s performance. You have the following tasks:
1. Draw the logical context level (Level 0) DFD for Knights
Pies.
2. Explode the logical context level DFD for Knights Pies,
creating the Level 1 DFD.
Cüneyt Sevgi CTIS 359 Fall 07-08
Context Diagram
Cüneyt Sevgi CTIS 359 Fall 07-08
Level-1 DFD
Cüneyt Sevgi CTIS 359 Fall 07-08
OBJECT-ORIENTED (OO)
SYSTEM
Object-Oriented
System is composed of
objects.
An Object is any person, thing, or event
about which we wish to store data or whose
behavior we wish to capture.
An Object has certain attributes and
behaviours.
Cüneyt Sevgi CTIS 359 Fall 07-08
OBJECT-ORIENTED (OO)
SYSTEM
•Object-Oriented Analysis
(OOA) –
Consider the problem domain from the
perspective of objects.
•Object-Oriented Design (OOD) – Define
the solution as a collection of software
objects.
•Object-Oriented Programming (OOP) –
Implement the objects using OO
languages.
Cüneyt Sevgi CTIS 359 Fall 07-08
What is UML?
The Unified Modeling Language (UML) is a
general-purpose visual modeling language
that is used to specify, visualize, and document
the artifacts of a software system.
 It captures decisions and understanding about
systems that must be constructed.


Source: UML Reference Manual, By James Rumbaugh, Ivar Jacobson, Grady
Booch.
Cüneyt Sevgi CTIS 359 Fall 07-08
UML Diagrams









Use-Case diagram
Class diagram
Object diagram
State diagram
Sequence diagram
Collaboration diagram
Activity diagram
Component diagram
Deployment diagram
Cüneyt Sevgi CTIS 359 Fall 07-08
UNIFIED MODELING
LANGUAGE (UML)
•UML
is the industry standard language for
specifiying, visualizing, constructing, and
documenting the artifacts of OO systems.
•UML embodies a set of 9 unique object
modeling and diagramming tools to define and
model an OO System.
•UML is NOT a development methodolgy.
•UML replaces older techniques such as
DFDs and ERDs.
Cüneyt Sevgi CTIS 359 Fall 07-08
UML DYNAMIC DIAGRAMS
•Use-Case
Diagram – Shows what a system does
from an external observer
•Sequence Diagram – Shows interactions that details
how operations are carried out
•Collaboration Diagram – Shows interactions also,
but focuses on object roles instead of times that
messages are sent
•Activity Diagram – Shows flow of activities in a
single process
•Statechart Diagram – Shows the possible states of
the object and the transition that causes a change in
state
Cüneyt Sevgi CTIS 359 Fall 07-08
UML STATIC DIAGRAMS
•Class
Diagram – Shows system’s classes and
relationships
•Object Diagram – Shows instances of
classes
•Component Diagram – Shows code
module
•Deployment Diagram – Shows the physical
deployments.
Cüneyt Sevgi CTIS 359 Fall 07-08
USE CASE DIAGRAM
•Although
each of the nine diagramming techniques in
the UML is important, the central building block of
the UML is the Use-Case diagram.
•It provides a high-level description of what the
system must do.
•A Use-Case diagram is created for each major
function of the system during the requirements
gathering process.
•A Use-Case diagram is concerned with interactions
between a user (human or another system) and the
system.
Cüneyt Sevgi CTIS 359 Fall 07-08
USE CASE DIAGRAM BENEFITS
•They
are regarded as an excellent technique for
capturing the functional requirements.
•They serve as a basis for identifiying the relevant
objects.
•They do not use special language.
•They allow to tell stories.
•Test cases can be directly drived from them.
•They can be used for estimating and scheduling
effort.
Cüneyt Sevgi CTIS 359 Fall 07-08
USE CASE DIAGRAM
LIMITATIONS
•They
cannot capture non-functional
requirements.
•They are not well-suited for safetycritical and real-time systems where
greater degree of precision is required.
•Some customers find it hard to
understand.
Cüneyt Sevgi CTIS 359 Fall 07-08
USE CASE DIAGRAM
COMPONENTS
•Use-Case
diagrams consists of 3 components.
•Actors - Any person, organization, or computer
system that is external but interacting with it.
•An actor does not represent a specific end
user, but rather represents a role that an end
user can play while interacting with the system.
•Illustrated as stick figures.
•Use-Cases – They are “scenarios” and
•A use-case represents a sequence of steps
that define the completion of a single business
task.
•Illustrated as ovals.
•Relationships – Associations between an actor
and use-case.
Cüneyt Sevgi CTIS 359 Fall 07-08
BUILDING A USE CASE
DIAGRAM PROCESS
•Identify
system boundry with actors.
•Identify each actor’s goals when
interacting with the system.
•Express these goals with use-cases.
Cüneyt Sevgi CTIS 359 Fall 07-08
IDENTIFY ACTORS
•Human Actors
•Who uses system?
•Who provides events and data to the system?
•Who gets information from the system?
•Non-Human
Interface Points
•What other systems use this system?
•What other devices use this system?
•What other external event trigger system
response?
Cüneyt Sevgi CTIS 359 Fall 07-08
Example Application - ATM

Software will be developed for a bank’s
ATM. ATM will allow withdrawing money
from accounts, depositing money to
accounts, and transfering money between
accounts of customers who have a bank
card. ATM will get information about the
customer or customer accounts from the
central bank system when required. The
central bank system will get a summary of
the operations performed in a day from the
ATM at the end of that day.
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM Application - Actors

Question:
◦ Who/what are the users of ATM application?
Bank
Customer
Central Bank
System
Cüneyt Sevgi CTIS 359 Fall 07-08
Example - Small Changes

If the application to be developed is a branch
application with the following requirement:
◦ “The bank customer tells the bank clerk the operation
that s/he wants to perform.”
◦ Who are the actors of that system?
Actor, because Bank Clerk directly intracts with the system
Bank
Customer
Bank Clerk
Branch
Application
Cüneyt Sevgi CTIS 359 Fall 07-08
Example - Small Changes

If the application to be developed is an
Internet banking application:
◦ Who is the actor of that system?
Bank
Customer
Internet Application
Actor, because Bank Customer
directly intracts with the system
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM Application – Use Cases

Question: What do the actors identified
want to accomplish by using the ATM?
◦ Actor: Bank customer
 Withdraw money
 Deposit money
 Transfer between accounts
◦ Actor: Central bank system
 Taking daily summary
 In addition, it will take roles in all of the use cases
above
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM Application –
Short Descriptions

Actor: Bank customer
◦ Is the person who has a bank card and who is
allowed to perform operations on ATM with
his/her card

Use Case:Withdraw money
◦ Defines how a bank customer withdraws
money from his/her account. The bank
customer should select the amount to
withdraw and the customer’s funds should
meet the stated amount.
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM Application –
Use Case Model
Withdraw money
Central Bank System
Deposit money
Bank Customer
Taking daily summary
Transfer between accounts
Cüneyt Sevgi CTIS 359 Fall 07-08
Use Case Model

Dynamics of a use case may be specified
by






statechart diagrams
sequence diagrams
collaboration diagrams
informal text
Use-Cases diagrams accompanied by a
textual documents.
The combination of two is called UseCase model.
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM Application –
“Withdraw Money” Use Case
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
The bank customer inserts his card
The ATM reads the card and requests the password
The bank customer enters his password
The ATM shows the types of transactions
The bank customer selects “withdraw money”
transaction
The ATM displays cash amounts to withdraw
The bank customer selects the cash amount to withdraw
The central bank system checks for sufficient funds
The central bank system debits the account
The ATM dispenses the cash
The ATM ejects the card
Cüneyt Sevgi CTIS 359 Fall 07-08
Use Case No
1
Use Case Name
Withdraw Money
Defined By
Ali Veli
Last Updated
By
Ali Veli
Defined On
DD/MM/
YY
YY
Last Updated
On
DD/MM/YYYY
Actors:
Bank customer, Central Bank System
Descriptions
Defines how a bank customer withdraws money from his/her account
Pre-conditions
The central bank is online;
ATM holds the amount of money withdrawn
Post-conditions
The bank customer takes the cash dispensed and the card ejected by the ATM
Priority
1
Frequency of
Use
Very Frequent
ATM Application
“Withdraw Money”
Use Case Definition
Cüneyt Sevgi CTIS 359 Fall 07-08
Basic Flow
Alternative Flows
The bank customer inserts his card
1. The ATM reads the card and requests the password
2. The bank customer enters his password
3. The ATM shows the types of transactions
4. The bank customer selects “withdraw money” transaction
5. The ATM displays cash amounts to withdraw
6. The bank customer selects the cash amount to withdraw
7. The central bank system checks for sufficient funds
8. The central bank system debits the account
9. The ATM dispenses the cash
10. The ATM ejects the card
A1.1 The bank customer cannot insert his/her card right
A1.2 ATM returns the card
A1.3 Continue with Step 1 in the basic flow
A2.1 The customer enters wrong password
A2.2 ATM invokes the bank customer
A2.3 Continue with Step 3 in the basic flow
A9.1 The central bank determines the fund are not sufficient
A9.2 ATM invokes the bank customer
A9.3 Continue with Step 7 in the basic flow
Referenced Use Cases
Special Requirements
For “withdraw money” transaction type to be active, the ATM should hold
the minimum cash amount displayed by the ATM for witdrawal
Assumptions
Notes:
Cüneyt Sevgi CTIS 359 Fall 07-08
ATM
Application
“Withdraw
Money”
Use Case
Definition
Some other Features of Use Case
Models
Cüneyt Sevgi CTIS 359 Fall 07-08
<<include>>

An include relationship can be used to when
a particular use case is included in other use
cases because it encapsulates some
functionality that is used at several points
in the system. This avoids having to define
the same sequence of actions in multiple use
cases. The including use case will continue up
to the point where it includes the base use
case, the full sequence of activities in the
base use case will be carried out, and the
including use case will carry on at the point
where it left off.
Source: UML- Schaum’s Outline Series 2nd Edition P.29
Cüneyt Sevgi CTIS 359 Fall 07-08
<<include>>

Factor out subfuction use cases and use
the <<include>> relationship when
◦ They are duplicated in the other use cases
◦ A use case is very complex and long, and
separating it into subunits aids comprehension
◦ To describe the handling of an asynchronous
event such as when a user able to, at any time,
select a particular window, function, etc..
Source: Larman P. 497
Cüneyt Sevgi CTIS 359 Fall 07-08
<<extend>>

There are occasions where one use case
may OPTIONALLY be extended by the
functionality in another use case. This
relationship is called extend.
Cüneyt Sevgi CTIS 359 Fall 07-08
<<extend>>

Note that <<extend>> use case is
triggered by some condition.
Cüneyt Sevgi CTIS 359 Fall 07-08
LAB

You will create a use case model for a
given example.
Cüneyt Sevgi CTIS 359 Fall 07-08
End

Any questions/suggestions?
Cüneyt Sevgi CTIS 359 Fall 07-08