System design and analysis 1: period 2

About This Presentation

Title:

System design and analysis 1: period 2

Description:

Tom de Marco - Structured Analysis and System Specification ... Take care to distinguish between separate events coincidently 'packaged' together ... – PowerPoint PPT presentation

Number of Views:133

Avg rating:3.0/5.0

Slides: 103

Provided by: ssuu

Category:

more less

Transcript and Presenter's Notes

Title: System design and analysis 1: period 2

1
System design and analysis 1period 2

Oulu Polytechnic
Sinikka Suutari
Spring 2005

2
Content

Modern Structured Analysis or MSA
The tools of MSA
Data Flow Diagrams
Entity Relationship Diagram
Data Dictionary
Process Specification

3
Modern 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

6
Modeling tools

Dataflow diagram
The Data dictionary
Entity-relationship diagram
State-transition diagrams
Process specification

7
The 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
8
The 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
9
8 The Tools of MSA
10
The tools of MSA

Environmental model
Behavioral model
Implementation model

11
Essential 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
12
Environmental 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
13
Behavioural 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
14
Implementation 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
15
Analysis 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
16
1 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

17
1.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.

18
1.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.

19
1.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

20
1.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
21
1.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
22
1.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
23
1.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

24
1.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

25
1.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

26
1.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

27
1.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

28
1.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?

29
Your answer?
30
MSA by Yourdon
31
2 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

32
2.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

33
2.1 Example Context diagram of Hoosier Burgers
Food ordering system
8.33
34
2.1 Example Level-0 DFD of Hoosier Burgers food
ordering system
8.34
35
2.2 Data Flow Diagram
A
B
Stage1 Context Diagram
System
36
2.2 Data Flow Diagram
A
B
System
Stage 2 0-level Data flow diagram
A
B
Do X
Do Y
V1
Do Z
37
2.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
38
2.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
39
2.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
40
2.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

41
2.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

42
2.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
43
Some 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)

44
2.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
45
Diverging 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
46
Typical 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
47
Creating 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.

48
Guidelines 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

49
Guidelines (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

50
Control 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

51
Example
Process Satellite Data
satellite data
satellite signal
Control Surveillance System
enable satellite processing
radar signal
enable radar processing
Process Radar Data
radar data
52
Levelled DFDs

Most systems are far too complex to depict on one
DFD

53
Levelled 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

54
Guidelines 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

55
Balanced DFDs
56
An Unbalanced DFD
Can you see the problem?
57
Data Stores and Levelled DFDs

Show the data store at all relevant levels

58
Entity-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

59
Why 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.

60
Definitions

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

61
E-R models

Symbols in E-R diagrams

Entity Set
Relationship Set
62
Degrees of a Relationship
One-to-one (11)
1
1

Woman

One-to-many (1n)
1
N

Order

Customer

Many-to-many (nm)
N
M

Subject

Course

NOTE Every many to many relationship consists of
two one to many relationships
working in opposite directions
63
E-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
64
Exercise - Complete the Relationships
Employee
Company
Mother
Child
Driver
Car
65
State 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
66
E-R models

Attributes

Customer
Rental Car
1
N
rental
Registration
Customer
Number
Number
67
ER 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

68
A 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.

69
Identify 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.

70
Determine 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

71
Summary

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

72
The 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

73
Data 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
74
Data 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

75
Data 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

76
State 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.

77
State 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
78
State Transition Diagram

The components of State Transition Diagram

State
State
79
State 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

80
State 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

81
State 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
82
Implementation 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

83
Implementation 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.

84
Implementation 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.

85
Implementation 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.

86
Implementation 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.

87
Implementation 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

88
Implementation 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
89
Implementation 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

90
The 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

91
Implementation model