Transcript Lecture 3 Structured System Analysis

System Analysis Overview


Document functional requirements by
creating models
Two concepts help identify functional
requirements in the traditional approach
and object-oriented approach

Events that trigger use cases

Things in the users’ work domain
Models and Modeling





Analyst describes information system
requirements using a collection of models
Complex systems require more than one type of
model
Models represent some aspect of the system
being built
Process of creating models helps analyst clarify
and refine design
Models assist communication with system users
Why modeling?





Learning from modeling process
Reduce complexity by abstraction
Remembering the details
Communicating with other team
members, users, and stakeholders
Documenting what was done for future
maintenance/enhancement
Types of Models

Different types of models are used in
information systems development



Mathematical – formulas that describe
technical aspects of the system
Descriptive – narrative memos, reports, or lists
that describe aspects of the system
Graphical – diagrams and schematic
representations of some aspect of the system
Events



Business events trigger elementary
business processes (EBPs)
EBPs are at correct level of analysis for use
cases
Business events are memorable, can be
described, and occur at a specific time and
place
Sequence of “Transactions” for One Specific
Customer Resulting in Many Events
Types of Events

External



Temporal



Outside system
Initiated by external agent or actor
Occur as result of reaching a point in time
Based on system deadlines
State

Something inside system triggers
processing need
Events Affecting a Charge
Account Processing System
Events modeling



Identify business events to decompose system
into activities/use cases
Use cases (activities) are identified from user
goals and business events that trigger
elementary business processes
Event decomposition is, therefore, used by



Traditional approach to identify activities
OO approach to identify use cases
Event table records event, trigger, source, use
case, response, and destination
Information about Each Event
in an Event Table
Things


“Things” are what user deals with and
system remembers, such as an order
placed by a customer
Analysts identify these types of things by
considering each use case in the event table

What things does the system need to know about and
store information about?
Types of Things
Modeling things


Traditional approach uses entityrelationship diagrams (ERD) for data
entities, attributes of data entities, and
relationships between entities
Object-oriented approach uses UML
class diagrams for classes, attributes,
methods of class, and associations
among classes
Traditional and OO Approach
Components of a Traditional Analysis Model
Data Flow Diagrams (DFDs)


Graphical system model that shows all
main requirements for an IS in one
diagram

Inputs/outputs

Processes

Data storage
Easy to read and understand with
minimal training
Data Flow Diagram Symbols
DFD Integrates Event Table and ERD
DFD and Levels of Abstraction




Data flow diagrams (DFDs) are
decomposed into additional diagrams to
provide multiple levels of detail
Higher-level diagrams provide general
views of system
Lower-level diagrams provide detailed
views of system
Differing views are called levels of
abstraction
Layers of
DFD
Abstraction
for Course
Registration
Context Diagrams




DFD that summarizes all processing
activity for the system or subsystem
Highest level (most abstract) view of
system
Shows system boundaries
System scope is represented by a single
process, external agents, and all data
flows into and out of the system
Context Diagram
External
entity
Data
Flow
Data
Flow
The
System
External
entity
Data
Flow
Data
Flow
External
entity
DFD Fragments





Created for each use case in the event
table
Represent system response to one
event within a single process symbol
Self-contained models
Focus attention on single part of system
Show only data stores required in the
use case
Three Separate DFD Fragments for Course
Registration System
Event-Partitioned System
Model





DFD to model system requirements using single
process for each use case/activity in system or
subsystem
Combines all DFD fragments together to show
decomposition of the context-level diagram
Sometimes called “diagram 0”
Used primarily as a presentation tool
Decomposed into more detailed DFD fragments
Combining
DFD
Fragments to
Create EventPartitioned
System Model
Decomposing DFD Fragments



Most DFD fragments can be
further described using structured
English
Sometimes DFD fragments need to
be diagrammed in more detail
Decomposed into subprocesses in
a detailed DFD
Layers of
DFD
Abstraction
for Course
Registration
DFD Practice

Precision tools sells a line of high-quality
woodworking tools. When customers place
orders on the company’s web site, the system
checks to see if the items are in stock, issues
a status message to the customer, and
generates a shipping order to the warehouse,
which fills the order. When the order is
shipped, the customer is billed. The system
also produces various reports.
DFD Practice

Draw a context diagram


System scope is represented by a single process,
external agents, and all data flows into and out of
the system
Draw Level-0 diagram



Identify the major use cases
Draw DFD fragment for each use case
Combine DFD fragments together at the same
level of detail
Context Diagram
Five Separate DFD Fragments
Detailed DFD for Create new order
Evaluating DFD Quality





Readable
Internally consistent and balanced
Accurately represents system
requirements
Reduces information overload – rule
of 7 +/- 2
Minimizes required number of
interfaces
Data Flow Consistency
Problems




Differences in data flow content
between a process and its process
decomposition
Data outflows without corresponding
inflows
Data inflows without corresponding
outflows
Results in unbalanced DFDs
Consistency Rules

All data that flows into a process must



Flow out of the process, or
Be used to generate data that flows out of
the process
All data that flows out of a process
must


Have flowed into the process, or
Have been generated from data that
flowed into the process
Unnecessary Data Input: Black Hole
Process with Impossible Data Output: A
Miracle
Process with Unnecessary
Data Input
Process with Impossible Data
Output
Documentation of DFD
Components





Lowest-level processes need to be
described in detail
Data flow contents need to be described
Data stores need to be described in terms
of data elements
Each data element needs to be described
Various options for process definition exist
Structured English




Method of writing process specifications
Combines structured programming
techniques with narrative English
Well-suited for lengthy sequential
processes or simple control logic (single
loop or if-then-else)
Ill-suited for complex decision logic or few
(or no) sequential processing steps
Structured English Process Description
Decision Tables and Decision
Trees


Can summarize complex decision logic better
than structured English
Incorporate logic into the table or tree
structure to make descriptions more readable
Decision Tables
Decision Tree
Decision Tables for Calculating
Shipping Charges
Decision Tree for Calculating
Shipping Charges
Data Flow Definitions



Textual description of data flow’s content and internal
structure
Often coincide with attributes of data entities included in
ERD plus computed values
Algebraic notion describes data elements on data flow
plus data structure
Data Element Definitions

Data type description





String, integer, floating point, Boolean
Sometimes very specific written description
Length of element
Maximum and minimum values
Data dictionary – repository for
definitions of data flows, data stores,
and data elements
Data Element Definition
Physical and Logical DFDs

Logical model



Physical model
Describes assumptions about implementation
technology
 Developed in last stages of analysis or in
early design
Current physical -> Current logical -> New
logical -> New physical


Assumes implementation in ideal situation
Does not tell how system is implemented
Summary



Data flow diagrams (DFDs) are used in
combination with event table and entityrelationship diagram (ERD) to model
system requirements
DFDs model system as set of processes,
data flows, external agents, and data
stores
DFDs easy to read – graphically
represent key features of system using
small set of symbols
Assignment 2




Draw a context diagram of the proposed
student housing system
Draw a level-0 data flow diagram. Specify
the main functions of the system (data
flow, process, and data store).
Draw a level-1 data flow diagram for the
process of student searching for houses.
Use of drawing tools
http://www.homes4students.ca/add_a_listing.html
http://www.homes4students.ca/ontario.html