CAN YOU REMEMBER
WHAT YOU DID IN SE:
ANALYSIS AND DESIGN
University of Technology, Jamaica 1
SCIT 2023/2024
Revision
• REQUIREMENTS ELICITATION
• PROJECT PLANNING
• FEASIBILITY STUDY
• REQUIREMENTS ANALYSIS
• REQUIREMENTS SPECIFICATION
2
LETS MOVE ON!!
3
Software Design Engineering
Unit 2
Software Design Process
4
DESIGN FOCUSES ON FOUR
MAJOR AREAS
Use Cases Data Flow Diagrams
Activity Diagrams Control Flow Diagrams
Processing Narratives
Component
level Design
Interface Design
State Chart Diagram
Sequence Diagram
Architectural Design
Class Diagram
Analysis Package
Data/Class Design
CRC Model
5
Software Design
– General definition of design
• “… the process of applying various techniques and
principles for the purpose of defining a device, a
process, or a system in sufficient detail to permit its
physical realization.”
– Goal:
• To produce a model or representation that will later
be built
– Engineering or Art?
6
Software Design Model
Functional Information
model model
Data design
Behavioral
model Architectural
Design design
Interface
Design Code
Other Integrated
requirements Procedural Program & validated
design modules Test
software
7
Software Design Fundamentals
– Good design is not accomplished by chance
“The beginning of wisdom for a computer
programmer is to recognize the difference
between getting a program to work, and
getting it right.” [Jackson]
– Fundamental concepts provide the framework
for “getting it right”
8
What is System Design
• The transformation of the analysis model into a
system model.
• During the system design, developers define the
design goals of the project and decompose the
system into smaller subsystems that can be
realized by individual teams.
9
THE END RESULT OF SYSTEM DESIGN
• The end result is
– A model that includes:
– A list of design goals
• The decomposition of the system into subsystems
• The selection of off-the-shelf software (if required)
• The selection of persistent data management
infrastructure
• The handling of boundary conditions
10
Systems Design Overview
As a result of the analysis a requirements
model results which describes:
• A set of nonfunctional requirements and constraints
• A use case model, describing the functionality of the
system from the actors’ point of view
• An object model, describing the entities manipulated
by the system
• A sequence diagram for each use case, showing the
sequence of interaction among the objects
participating in the case
11
Systems Design Overview
The system design includes :
❖ A list of design goals
o Describing the qualities of the system that developers should optimize
❖ The decomposition of the system into subsystems (software architecture)
o Describing the subsystem decomposition in terms of subsystem
responsibilities,
o Dependencies among subsystems,
o Subsystem mapping to hardware,
o Major policy decisions such as control flow, access control, and data storage
❖ The selection of off-the-shelf and legacy components
❖ The selection of a persistent data management infrastructure
The handling of boundary conditions
12
Systems Design Concepts
The customers understand what the system is
to do and the developers must understand
how the system is to work.
• Conceptual Design :
Written in the customer’s language
Contains no technical jargon
Describes the functions of the system
Independent of implementation
Linked to the requirements documents
13
Systems Design Concepts
• Technical Design :
• A description of the major hardware
components and their functions
• The hierarchy and function of the
software
• The data structures and the data flow
14
Subsystems and classes
To reduce complexity of the solution domain we
decompose the system into simpler parts, called
subsystems, which are made of a number of solution
domain classes.
Every design methods involves some kind of
decomposition, starting with a high-level depiction of the
system’s key elements and creating lower-level looks at
how the system’s features and functions will fit together.
15
Systems Design
Wasserman (1995) suggests that designs are created in
one of five ways:
1. Modular decomposition: The designer begins with a
high-level description of the functions that are to be
implemented and builds lower-level explanations of how
each component will be organized and related to other
components
2. Data-oriented decomposition: Based on external
data structures. The high-level description depicts
general data structures and lower-level descriptions
provide details on what data elements will be involved
and how they are related.
16
Systems Design
3 Event-oriented decomposition: Based on events that
the system must handle and uses information about how
events change the system’s state.
4 Outside-in design: This black-box approach is based
on user inputs to the system. That is the high-level
description list all possible inputs a user can make and
then lower-level descriptions address what the system
does with each input (including what outputs are
produced).
17
Systems Design
5. Object-Oriented design: This design identifies classes
of objects and their interrelationships. At the highest
level, each object type is described. At lower levels, the
object attributes and actions are discussed and the
design explains how objects are related to one another.
18
Software Design
This is an iterative process through which requirements are
translated into a “blueprint” for constructing the software.
19
Design Principles
• How is software design both a process and a
model?
By process we mean the sequence of steps that enable the designer to describe all aspects
of the software to be built. The design model begins representing the totality of things to
be built and slowly refines the thing to provide guidance for constructing each detail.
The model provides a variety of different views of the computer software.
20
System Modeling
• System Modeling uses a representation of:
– USER INTERFACE
– INPUT PROCESSES
– OUTPUT PROCESSES
– PROCESSES AND CONTROL FUNCTIONS
– ERROR DETECTION AND VALIDATION
21
USER INTERFACE PROCESSING
PROCESS AND OUTPUT
INPUT CONTROL PROCESSING
PROCESSING FUNCTIONS
MAINTENANCE
AND SELF TEST
22
BROWSER BUILDER
AUTHENTICATION, ASSIGNMENT
ASSIGNMENT, INFORMATION
REPORT
AUTHENTICATION
EMAIL
SHIMMER INFORMATION
MAILER
AUTHENTICATOR LOGIN/PASSWORD
SYSTEM
CONFIGURATION
CONTROL
CONFIGURATION
Mapping Requirements to Software Architecture
• Establish type of information flow
– transform flow - overall data flow is sequential
and flows along a small number of straight line
paths
– transaction flow - a single data item triggers
information flow along one of many paths
Transaction
T Action Path
Transaction
center
Transaction Flow
Action Path
Transform Flow
• Flow boundaries indicated
• DFD is mapped into program structure
• Control hierarchy defined
• Resultant structure refined using design measures
and heuristics
• Architectural description refined and elaborated
Program
Architecture
•Partitioning the Architecture
• “horizontal” and “vertical”
partitioning are required
•Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication between functions
function 1 function 3
function 2
•Vertical Partitioning: Factoring
• design so that decision making and
work are stratified
• decision making modules should
reside at the top of the architecture
decision-makers
workers
Why Partitioned Architecture?
• results in software that is easier to test
• leads to software that is easier to
maintain
• results in propagation of fewer side
effects
• results in software that is easier to
extend
Transform Mapping
• Review fundamental system model
• Review and refine data flow diagrams/Use
Cases for the software
• Determine whether the DFD/Use Case has
transform or transaction characteristics
• Isolate the transform center by specifying
incoming and outgoing flow boundaries
• Perform first level factoring
• Perform second level factoring
• Refine the first iteration architecture using
design heuristics for improved software
quality
Transform Mapping
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
Factoring
direction of increasing
decision making typical "decision
making" modules
typical "worker" modules
First Level Factoring
main
program
controller
input processing output
controller controller controller
Second Level Mapping
main
D
C
control
B A
A
B
C
mapping from the D
flow boundary outward
Transaction Mapping
• Review fundamental system model
• Review and refine data flow diagrams for the
software
• Determine whether the DFD has transform or
transaction characteristics
• Identify the transaction center and flow
characteristics along each action path
• Map the DFD/Use Case to a program
structure amenable to transaction processing
• Factor and refine the transaction structure and
the structure of each action path
• Refine the first iteration architecture using
design heuristics for improved software
quality
Transaction Flow
incoming flow
action path
T
•Transaction Mapping Principles
isolate the incoming flow path
define each of the action paths by looking for
the "spokes of the wheel"
assess the flow on each action path
define the dispatch and control structure
map each action path flow individually
Transaction Mapping
Data flow model f
x1 program structure
a e
d
b t b t
g i mapping
a x2 x3 x4
l h
k
m j d e f g h x3.1 l m n
n i j
k
Isolate Flow Paths
error msg
command
produce fixture setting
read error msg
status format
command
determine setting
invalid command read
validate setting
command command fixture raw setting
status combined
determine
valid command status
type
read
robot control record record
calculate
output
send
values values
control
format
value
assembly report report
start/stop record
Map the Flow Model
process
operator
commands
command determine
input type
controller
read validate produce fixture report send
command command error status generation control
message controller controller value
each of the action paths must be expanded further
Refining Architectural Design
• Processing narrative developed for each module
• Interface description provided for each module
• Local and global data structures are defined
• Design restrictions/limitations noted
• Design reviews conducted
• Refinement considered if required and justified
Refining the Structure Chart
process
operator
commands
command determine
input type
controller
read validate produce fixture report send
command command error status generation control
message controller controller value
read determine format read calculate format
fixture setting setting record output report
status values
University of Technology, Jamaica 47
SCIT 2017
References
1. McGlaughlin, R., “Some Notes On Program Design,”
Software Engineering Notes, Vol.16, no 4, October
1991, pp. 53-54.
2. Pressman, R. (2005) Software Engineering: A
Practitioner’s Approach. McGraw Hill
3. Davis, A., 201 Principles of Software Development,
McGraw-Hill, 1995.
4. Wirth, N., “Program Development by Stepwise
Refinement, “CACM vol. 14, no 4 1971, pp. 221-227
5. Myers, G., Composite Structured Design, Van
Nostrand, 1978
University of Technology, Jamaica 48
SCIT 2007
Software Engineering
THE END
University of Technology, Jamaica 49
SCIT 2007
