Title: System design and analysis 1: period 2
1System design and analysis 1period 2
- Oulu Polytechnic
- Sinikka Suutari
- Spring 2005
2Content
- Modern Structured Analysis or MSA
- The tools of MSA
- Data Flow Diagrams
- Entity Relationship Diagram
- Data Dictionary
- Process Specification
3Modern Structured Analysis (MSA)
4 Structured analysis
- Background
- The models and design notification
5 Background
- First texts appeared in 1977
- Tom de Marco - Structured Analysis and System
Specification - Gane and Sarson - Structured Systems Analysis
- 1984 - SA is extended
- McMenamin and Palmer - Essential Structured
Analysis - 1989 - SA reaches its peak
- Yourdon publishes Modern Structured Analysis
- Integrates Chens Entity-Relationship Models
- Terms
- SA Structured Analysis
- SD Structured Design
6Modeling tools
- Dataflow diagram
- The Data dictionary
- Entity-relationship diagram
- State-transition diagrams
- Process specification
7The models and tools of MSA
SA/SD-model
Essential model
Environmental model - statement of purpose -
context diagram - event list
Behavioral model - Data Flow Diagram (DFD)
Statement Diagrams (STD) - Entity Diagram (ERD)
Data dictionary
- Implementation model
- Defining the limits of the system
- Defining of the user interface
- Editing the diagrams for implemation
The Definitions of the Information is ready
8The models and tools of MSA
Tool
Methodology
Phases
MSA
System requirements
Environmental model
Text
Context d
List
System analysis
Behavioral model
DFD
Data model
Text
State-transition diagram
Design
Implementation model
Architecture diagram
Text
Implementation
CASE tools Office programs Prosa Rational Rose
You can use case-tools
Testing
Implementaiton of ready system
98 The Tools of MSA
10The tools of MSA
- Environmental model
- Behavioral model
- Implementation model
11Essential Model
- Model of what the system must do.
- Does not define how the system will accomplish
its purpose. - Is a combination of the environmental and
behavioural model.
Essential Model
Environmental Model
Behavioural Model
Implementation Model
12Environmental Model
- Defines the scope of the proposed system.
- Defines the boundary and interaction between the
- system and the outside world.
- Composed of Statement of
- Purpose, Context Diagram, and
- Event List.
-
Essential Model
Environmental Model
Behavioural Model
Implementation Model
13Behavioural Model
- Model of the internal behaviour and data
entities of the - system.
- Models the functional requirements.
- Composed of Data Dictionary, Data Flow Diagram,
- Entity Relationship Diagram, Process
Specification, - and State Transition Diagram.
-
Essential Model
Environmental Model
Behavioural Model
Implementation Model
14Implementation Model
- Maps the functional requirements to the hardware
and - software. Minimizes the cost of development and
- maintenance.
- Determines which functions should be manual vs.
- automated. Can be used to discuss the
costs-benefits of - functionality with the users/stakeholders.
- Defines the Human-Computer Interface.
- Defines non-functional
- requirements.
- Tool Structure Charts
-
Essential Model
Environmental Model
Behavioural Model
Implementation Model
15Analysis Design Process
Environmental Model
Behavioural Model
Statement of Purpose
Activity
Implementation Model
Context Diagram
Event List
Data Dictionary
ERD
DFD
Process Specification
State Transition Diagram
Structure Charts
Time
161 Environmental model
- Model defines
- The boundary between the system and the rest of
the world(i.e. the environment in which the
system exist) - What includes in the system and what not??
- The boundary between the system and its
environment is arbitrary. It is critical. - It may be made by management decree, or as the
result of political negotiation or simply by
accident. - It is something that the systems analyst usually
has some opportunity to influence. - gray area
- Statement of purpose
- Context diagram
- Event list
171.1 Statement of purpose
- A brief , concise textual statement of the
purpose of the system. - It is intended for top management, user
management, and others who are not directly
involved in the develoment of the system. - One or some few sentences long. Not more than a
single paragraph long. - It is not intended to give a comprehensive ,
detailed decsription of the system.
181.1 Statement of purpose
- An example of a typical statementof purpose
- The purpose of the Ajax Book Processing System is
to handle all of the details of customer orders
for books, as well as shipping, invoicing, and
back-billing of customers with overdue invoices.
Information about book orders should be available
for other systems, such as marketing, sales, and
accounting.
191.2 Context Diagram
- Indicate the people, organisations and systems
which communicate with our system so called
terminators - Show the data which our system receives from the
outside world - Show the data produced by the system and sent to
the outside world - Show the data which is shared by the system with
the outside world - Show the boundary between the system and the rest
of the world
201.2.1 Constructing a Context Diagram
- Four components
- The System
- Terminators
- also know as external entities
- Data Flows
- Data Stores
Airline Booking System
Customer
or
211.2.2 Airline Reservation System
Customer
Airline
Request for reservation
Flight confirmation
Flight details
Request for reservation
Airline Reservation System
Credit details
Reports
Transaction details
Management
Finance System
221.2.3 Guidelines for Context Diagrams
- Use appropriate names
- Dont be too specific with names
Yes
No
Customer
Fred Flintstone
Ready to send input
Order Entry System
Customer
Okay, send input
Heres the input
Great, I got the input
231.2.4 Guidelines (2)
- Can have Dialogue Flows representing two-way data
flow
Flight status response
Credit check request
Customer
Airline Reservation System
Finance System
Flight status request
Credit check response
- Duplicate terminators if necessary to simplify
the diagram
241.2.4 Student Enrolment System
- System
- Student Enrolment system
- Terminators(entity)
- Student
- University Management
- University Staff
- Data Stores
- Student Results
- Data Flows (7)
- reports to management, enrolment details from
student, confirmation of enrolment to student,
payment details from staff, student lists to
staff, student results from staff to system,
student results from Student Results database to
system
251.3 Event Lists
- List of the external events that occur in the
outside world which affect the system, i.e.
events generated by terminators - Events can be
- Flow - some data flows between the external world
and the system - Temporal - an event occurs as a result of some
timing - Control - special case of a temporal event, an
external stimulus that occurs at some
unpredictable point in time - Events are always viewed from the terminators
point of view
261.3.1 Event examples
- Customer places reservation (Flow)
- Customer cancels reservation (Flow)
- Accounting System receives transaction details
(Flow) - Management requests weekly report (Temporal)
- Airline confirms reservation (Temporal)
- There is no control event in this list since they
are unusual in business systems. They are,
however, common in real-time systems
271.3.2 Constructing the Event List
- Examine each terminator, and ask what effects the
terminators actions can have on the system - Take care to distinguish between separate events
coincidently packaged together - Event Customer places order might in fact be
both Customer places order and Salesperson
places customer order - Clue could be different data present in the two
cases - Need to allow for failure conditions on the part
of the terminator, but no need to allow for
system failures
281.3.3 Events
- Look at a system which controls the sales of
goods at a supermarket - Entities to think about
- Cash register
- Checkout Operator
- Customer
- Scanner
- Receipt printer
- What events can you identify?
29Your answer?
30MSA by Yourdon
312 Behavioral Model
- Behavioral model is the model of what the
internal behavior of the system must be in order
to deal succesfully with the environment. - Model have to be done with the end users
- System analyst interviews end users, meetings,
documents etc. - Wall technic is good in this phase. Or PC
drawing programs, modelling programs (Rational
Rose, Prosa) - Parts of the model
- Data Flow Chart
- Entity Relationship Diagram
- Data Dictionary
- State Transition Diagram
- Process Specifications Minispecifications
322.1 Types of Diagrams
- Context Diagram
- A data flow diagram (DFD) of the scope of an
organizational system that shows the system
boundaries, external entities that interact with
the system and the major information flows
between the entities and the system - Level-O Diagram
- A data flow diagram (DFD) that represents a
systems major processes, data flows and data
stores at a high level of detail
332.1 Example Context diagram of Hoosier Burgers
Food ordering system
8.33
342.1 Example Level-0 DFD of Hoosier Burgers food
ordering system
8.34
352.2 Data Flow Diagram
A
B
Stage1 Context Diagram
System
362.2 Data Flow Diagram
A
B
System
Stage 2 0-level Data flow diagram
A
B
Do X
Do Y
V1
Do Z
372.2 Data Flow Diagram
A
B
System
Stage 3 1 level data flow diagram
B
A
B
2.2 Do G
V1
1 Do X
2 Do Y
V1
2.1 Do F
3 Do Z
382.2 Data Flow Diagram
A
B
Stage 4 n-level diagrams
System
B
A
B
2.2 Do G
V1
1 Do X
2 Do Y
V1
2.1 Do F
3 Do Z
392.3 Data Flow Diagrams
- Extends the Context Diagram by defining the
processes which make up a system - 4 components
- Processes
- Number - identifies process and indicates place
in DFD level hierarchy - Name - what the process does
- Part of system which transforms inputs to
outputs - Data Flows
- Data Stores
- Terminators
as in context diagram
402.3.1Some Rules for External Entities
(terminators)
- External people, systems and data stores
- Reside outside the system, but interact with
system - Either a) receive info from system, b) trigger
system into motion, or c) provide new information
to system - e.g. Customers, managers
- Not clerks or other staff who simply move data
412.3.2 Some Rules for Data Stores
- Internal to the system
- Data at rest
- Include in system if the system processes
transform the data - Store, Add, Delete, Update
- Every data store on DFD should correspond to an
entity on an ERD(ERD comes later) - Data stores can come in many forms
- Hanging file folders
- Computer-based files
- Notebooks
422.3.3Some Rules for Data Flows
- Data in motion, moving from one place to another
in the system - From external entity (source) to system
- From system to external entity (sink)
- From internal symbol to internal symbol, but
always either start or end at a process
Data Flow
43Some Rules for Processes
- Always internal to system
- Law of conservation of data
- - Data stays at rest unless
- moved by a process.
- - Processes cannot consume or create data
- Must have at least 1 input data flow (to avoid
miracles) - Must have at least 1 output data flow (to avoid
black holes) - Should have sufficient inputs to create outputs
(to avoid gray holes)
442.3.4 Data Flows
- Indicate movement of packets of information from
one part of the system to another part - Flows are named
- Input flow
- Output flow
- Diverging flows - see next slide
Validate Phone No.
Phone No.
Generate Flight Schedule
Flight Schedule Information
45Diverging Data Flows
Order
Customer Address
Produce Valid Order
Validate postcode
Generate Shipping Docs
Invalid orders
postcode
Order details
phone no.
Validate phone no.
street address
Update Inventory
Generate Invoice
Validate street address
46Typical Figure 0 DFD
Notesome analysts do notshow terminators on
theFigure 0 DFD
Customers
Warehouse
name,orders
Order
Order
1. Receive Order
invalidorders
books
Notephysical flows
2. Ship Books
Customer
Invoice
Customer
books
Customer
Invoice
3. Collect Payment
invoices, statements
Customers
payments, inquiries
47Creating Data Flow Diagrams
- Creating DFDs is a highly iterative process of
gradual refinement. - General steps
- 1. Create a preliminary Context Diagram
- 2. Identify use cases, i.e. the ways in which
users most commonly use the system - 3. Create DFD fragments for each use case
- 4. Create a Level 0 diagram from fragments
- 5. Decompose to Level 1,2,
- 6. Go to step 1 and revise as necessary
- 7. Validate DFDs with users.
48Guidelines for constructing DFDs
- Choose meaningful names
- Number the processes
- Redraw the DFD as many times as necessary for
aesthetics - Avoid overly complex DFDs
- Fit on one A4 page
- approximately 6 processes and related data stores
and terminators
49Guidelines (2)
- Make sure the DFD is internally consistent and
consistent with any associated DFDs - Avoid infinite sinks - processes with inputs but
no outputs - Avoid spontaneous generation processes -
processes with outputs but no inputs (possible
exception is a random number generator) - Beware of unlabelled flows and processes
- Beware read-only/write-only stores
- Make sure that incoming and outgoing flows from
the DFD match those on the DFD at the level above
50Control Flows and Processes
- Real-time systems need a means to model control
(signals/interrupts) - Shown with dashed lines and circles
- A control flow can be regarded as a binary signal
- does not carry value-bearing data - Used to trigger/wake-up a dormant process
- Internal behaviour of a control process described
by a state-transition diagram - Generally one control process in a DFD
- inputs and outputs of control process consist
only of control flows
51Example
Process Satellite Data
satellite data
satellite signal
Control Surveillance System
enable satellite processing
radar signal
enable radar processing
Process Radar Data
radar data
52Levelled DFDs
- Most systems are far too complex to depict on one
DFD
53Levelled DFDs (2)
- Break each process down into sub-processes
- Numbering of processes indicates their parents
process, and thus their position in the hierarchy
of levelled DFDs
54Guidelines for Levelled DFDs
- How many levels?
- Each level should have approximately 6 processes
- Simple systems 2-3 levels
- Medium size 3-6 levels
- Large size 5-8 levels
- All parts of the system may not need the same
numbers of levels - Levels must be consistent with each other
- Data flows coming into and going out of a process
at one level must correspond to the data flows
coming into and out of the entire figure at the
next lower level - this is known as balancing
55Balanced DFDs
56An Unbalanced DFD
Can you see the problem?
57Data Stores and Levelled DFDs
- Show the data store at all relevant levels
58Entity-Relationship Diagrams
- Model the relationships between data in the
system - NB. In some contexts, also used for behavioural
modeling - Highlight the relationships between data stores
directly - When using ERD for data modeling, only
relationships that are represented in the data
stores (e.g. via a foreign key) should be shown - Very useful in relational database systems
- Often more central to your system than DFDs
- 4 Components
- Entity types
- Relationships
- Associative entity types
- Supertype/subtype indicators
59Why use ER Diagrams ?
- provides a global quick reference to an
organizations data structures. - can be used individually to design an Information
Systems (IS) data structure - can be used with Data Flow Diagrams to provide a
more comprehensive IS logical design.
60Definitions
- Entity
- an aggregation of a number of data elements
- each data element is an attribute of the entity
- Entity type
- a class of entities with the same attributes
- Relationship
- an association between two or more entities that
is of particular interest
61E-R models
Entity Set
Relationship Set
62Degrees of a Relationship
One-to-one (11)
1
1
One-to-many (1n)
1
N
Many-to-many (nm)
N
M
NOTE Every many to many relationship consists of
two one to many relationships
working in opposite directions
63E-R models
- (a) an M-N relationship, (b) a 1-1 relationship,
(c) a 1-N relationship
Student
M
N
(
a)
Course
enrolment
Customer
Rental
1
1
(
b)
rental
Car
Customer
Rental
(
c)
1
N
rental
Car
64Exercise - Complete the Relationships
Employee
Company
Mother
Child
Driver
Car
65State General
State
1
managed-
1
Manager
Company
by
1
1
1
supervised-
by
N
Depot
Manager
owned
belongs
by
to
1
managed-
- E-R diagram for a
- simplified rental
- car database for a
- single Rent-a-Car
- organization
by
N
1
N
is
N
1
Depot
Rental
garaged
Car
at
N
rental
1
Customer
66E-R models
Customer
Rental Car
1
N
rental
Registration
Customer
Number
Number
67ER Development Process
- Identify the entities
- Determine the attributes for each entity
- Select the primary key for each entity
- Establish the relationships between the entities
- Draw an entity model
- Test the relationships and the keys
68A Simple Example
- STUDENTs attend COURSEs that consist of many
SUBJECTs. - A single SUBJECT (i.e. English) can be studied in
many different COURSEs. - Each STUDENT may only attend one COURSE.
69Identify the entities
- Any entity can be classified in one of the
following categories - Regular
- any physical object, event, or abstract concept
that we can record facts about. - Weak
- any entity that depends on another entity for its
existence.
70Determine the Attributes
- Every Entity has attributes.
- Attributes are characteristics that allow us to
classify/describe an entity - e.g., entity STUDENT has the attributes
- student number
- name
- date of birth
- course number
71Summary
- In todays session we have learned to
- Identify the entities
- Determine the attributes for each entity
- Select the primary key for each entity
- Establish the relationships between the entities
- Draw an entity model
72The Data Dictionary
- Provides definitions for all elements in the
system, which include - Meaning of data flows and stores in DFDs
- Composition of the data flows e.g. customer
address breaks down to street number, street
name, city and postcode - Composition of the data in stores e.g. in
Customer store include name, date of birth,
address, credit rating etc. - Details of the relationships between entities
73Data Dictionary Notation
is composed of and ( ) optional ( may be
present or absent) iteration select one
of several alternatives comment _at_ identifier
(key field) for a datastore separates
alternative choices in the construct
74Data Dictionary examples
order _at_order-id customer-name
shipping-address 1item10 orders
order customer-name courtesy-title
first-name (middle-name) last-name courtesy-
title Mr. Miss Mrs. Ms. Dr.
Professor first-name legal-character middle-
name legal-character last-name
legal-character legal-character
A-Za-z0-9- current-height
units metres range 1.00-2.50
- current-height is an example of elementary data.
No composition need be shown (an empty comment,
, is used as a placeholder), though an
explanation of the relevant units/symbols is
needed - an order always has an order-id (which is the key
field), a customer-name and a shipping-address,
and has between 1 and 10 items. - orders is a datastore
75Data dictionary
- Customer register Customer
- Customer _at_Personal ID Customers name
contact information - Personal ID Number 6 -
Legal_character4 - Customer name First name Last name
- Contact information 1 Legal_character n
- First name 1Legal character n
- Last name 1 Legal charactern
- Legal_character Number Legal_character
- - Number 0-9
- Legal_character A-Ö a-ö 0-9
76State Transition Diagram - Purpose
- The State Transition Diagram is a graphical
technique to highlight the time-dependent
behaviour of the system. It describes what
happens when Yourdon, 1989. - The sequence of events can be complex for
real-time systems. The STD's can also be
partitioned and leveld as needed.
77State Transition Diagram - Door Control
Power off
power_on
initial
Shut down
Must Be shut
cage_moving
Closed
power_switch_off
cage_stopped
open_command
closed_status
Opening
close
open_status
close_command
Open
78State Transition Diagram
- The components of State Transition Diagram
State
State
79State Transition Diagram
- Start state
- Descripes where the event starts
- The first event starts the state transition
- End state
- Descripes where the state ends
- Last event close the state transitions
80State Transition Diagram
- State transition
- Descripes the transition from state to state
- state transition includes always function that
makes the transition to happen - The event has to name shortly and clearly
- Function means the action that the system has to
do in consequence of the event
81State Transition Diagram
- State
- Is the most important component in state
transition diagram - State descripes a continuous state in a certain
time. - You can build up the diagram
- Descripe first all the possible states of the
system and define the states and their
transitions. - Start from the initial state and go through all
the paths to next states until you overtake all
the end states.
Ordered
82Implementation Model
- Maps the functional requirements to the hardware
and software. - Minimizes the cost of development and
maintenance. - Determines which functions should be manual vs.
automated. - Can be used to discuss the costs-benefits of
functionality with the users/stakeholders. - Defines the Human-Computer Interface.
- Defines non-functional requirements.
- Tool Structure Charts
83Implementation model
- There are two stages when building the
implementation model - The user implementation model
- Structured design
- The phase includes to the system analysis phase.
- Structured design includes to the design phase.
- The purpose of the implementation model is to
move to implemention in system design.
84Implementation model
- In implementation model you collect information
(you have to have to viewpoint of the end user)
information for the implementation - Requirements
- Limits
- Definition of policy
- Take into account
- How to devide the system between people and
machine - The user interface of the system
- The content of the manual tasks
- The requirements of usage and other requirements
and limits. - The requirements of the reliability and
protection.
85Implementation model
- The distribution between people and machine
- Which function will be automatized.
- Usually we propose that as much as possible will
be automatized. - The costs and benifits take into account in this
phase. - The develoment of the system cost more as more it
will be automatized. - And if there are manual tasks the system needs
people to do the work.
86Implementation model
- The design of user interface
- Take in account
- Input and print equipments or what are the
communicate equipments between the system and
equipments. - The form of inputs
- In which form the information inputs into system
- Are there lot of information, can we use
selection lists.Onko paljon tietoja, jotka
voidaan valita erilaisista valintalistoista - Are the lot of information in text form
- The form of the outputs
- In user interface
- Paper outputs
- The timing and order of the inputs
- What we have to do first, next next.
- If we have lot of unconnected tasks
- If we have lot of sequential tasks.
87Implementation model
- The design of the user interface is really
important - The hierarchy of the screens
- The discussion structures
- The details of the screens
- The standards of the screens
- Screen models
- Functionality
- The design of the paper outputs (reports)
- Design and its phases depends on the type of the
user interface. (is it Windows or browser) - Protypes
88Implementation model
- Example of the screen hierarchy
The Input of the order
The input of the order row
New customer
Menu
Inquiry
The Retraction Of the order
The row retraction ff the order
89Implementation model
- The manual tasks
- In this phase it has to ne noticed how the system
and user interface change the tasks of the users.
- Manual tasks
- The manual tasks beside the user interface.
- Use and other requirements and limits.
- The amount of the information
- The amount of the information that has to handle.
How many order per day. - Changes (seasons, week days, time)
- The develoment of the amount
90The implementation model
- Response times
- The more some the system is doing a task tht less
response times are required - E.g. receiving the order from a customer in phone
vs. the modifacation of basic information of the
customer. - The processing of a big thing may last longer
time than the processing of a little thing - The requirements of the environment and limits
- E.g.
- Industrial hall
- Outside
- Noise , dusty and others..
- The requirements of reliability and security
91Implementation model
- Data security
- Use names, passwords
- The usage rights
- Data protection
- The information of patients
- The information of salary and taxies
- Inspection
- The requirements of accounting
- Technical requirements
- Fire walls
92Pros of SASD
- It has distinct milestones, which allows for
easier project management tracking - Very visual easier for users/programmers to
understand - Makes good use of graphical tools
- Well known in industry
- A mature technique
- Process-oriented approach is a natural way of
thinking - Flexible
- Provides a means of requirements validation
- Relatively simple and easy to read
93Pros of SASD
- Context Diagram
- Provides a black box overview of the system and
the environment - Event List
- Provides guidance for functionality
- Provides a list of system inputs and outputs
- Means of requirements summarization
- Can be used to define test cases
- DFD
- Ability to represent data flows
- Functional decomposition- divide and conquer
94Pros of SASD
- Data Dictionary
- Simplifies data requirements
- Used at high or low level analysis
- ERD
- Commonly used well understood
- Graphical tool easy to read by analysts
- Data objects and relationships are portrayed
independently from the processes - Can be used to design database architecture
- Effective tool to communicate with DBAs
95Pros of SASD
- Process Specifications
- Expresses the process specifications in a form
that can be verified. - State Transition Diagrams
- Models real time behaviour
- Structure Charts
- Modularity improves system maintainability
- Provides a means for transition from analysis to
design - Provides a synchronous hierarchy of modules
96Cons of SASD
- It ignores non-functional requirements
- Minimal management involvement
- Non-iterative waterfall approach
- Not enough user-analyst interaction
- Doesnt provide a communication process with
users - Hard to decide when to stop decomposing
97Cons of SASD
- Doesnt address stakeholders needs
- Doesnt work well with Object-Oriented
programming languages
98Cons of SASD
- Context Diagram
- Does not provide a specific means to determine
the scope of the system. - Event List
- Does not define all functionality (ex. Edits)
- Does not define specific mechanism for
interaction. - DFD
- Weak display of input/output detail
- Users find it confusing initially
- Do not represent time
- No implied sequencing
- Assign data stores early in the analysis with
little deliberation
99Cons of SASD
- Data Dictionary
- No functional details
- Formal language is confusing to users
- ERD
- May be confusing for users formal notation
- Complex in large systems
- Structure Charts
- Does not work well for asynchronous processes
such as networks - Could be too large to be effectively understood
with large programs.
100Cons of SASD
- Process Specifications
- They may be too technical for the users
- Difficult to stay away from the current How
- State Transition Diagrams
- Explains what action causes a state change but
not when or how often
101Where to use SASD?
- In well known problem domains
- With contract projects where SRS is specified
- In both real-time systems and transaction
processing systems - Not appropriate when time to market is short
102References
- Yourdon, E., Modern Structured Analysis, Prentice
Hall, 1989.