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