Lecture 01 Introduction to Software Design
Lecture 01 Introduction to Software Design
Lecture 01
By Engr Muhammad Usman
Malik
Objectives
• To introduce the process of software design
• To describe the different stages in this design
process
• To show how object-oriented and functional
design strategies are complementary
• To discuss some design quality attributes
Programmer’s Approach to
Software Engineering
UML -A Genera ted De pend ency C lass :aRou teCol lectio n Ass ociatio n (0. 25)
theVehicleCollection
UM L-A Generated Association Class:aW arehouse Association (1.0)
aVehicle
theCarg oRouter
UML -A Genera ted As socia tion C lass: theWa rehou seCo llectio n De pende ncy ( 0.25)
UM L-A Generated Association Class:aRoute Association (0.5)
theAWT aLocation
UM L-A Generated Association Class:theRouter Association (0.25)
UM L-A Generated
UMAssociation
L-A Generated
Class:availableGoods
Association Class:aW
Association
arehouse(0.5)
Association (0.5)
theGoods
The Usual Tool: Design Abstraction
aLocation
aVehicle
theRouter
RegularStorage
aRouteCollection
theStorage availableVehicleCollection
aWarehous e
theWarehous eCollection
RefrigeratedStorage
availableGoods
aPortDialog
aVehiceDialog
aWarehous eDialog
aPortCollection
Architectural Abstraction
Cl o ck :
Cl o ck
8 : re q u e st
Cl o ckCo n n
9 : n oti fi ca ti o n 1 0 : no ti fi ca ti o n
Wa reh o u se De l i ve ryPo rt Ve h i cl e
7 : re q u e st
1 : re q u e st
4 : re q u e st 3 : re q u e st
Ro u te rCo n n
2 : n oti fi ca ti o n
Ca rgo Rou te r
5 : re q u e st
Gra p h i csCo n n
6 : n oti fi ca ti o n
Gra p h i csB i n d i n g :
Gra p h i csB i n d i n g
What is not Design
• Design is not programming.
• Design is not modeling. Modeling is part of the architectural
design.
• Design is not part of requirements.
• Where requirements finishes and where design starts ?.
• Requirements = What the system is supposed to do.
• Design = How the system is built.
What is Design (or Architecture?)
• A high-level model of a software system
– Describes the structure, functionality and
characteristics of the software system.
– Understandable to many stakeholders
– Allows evaluation of the system’s properties before
it is built
– Provides well understood tools and techniques for
constructing the thing from its blueprint
• A software system’s blueprint
– Its components
– Their interactions
– Their interconnections
What is Design (or Architecture?)
• How should they be represented most effectively to enable
stakeholders to understand, reason, and communicate about a
system before it is built?
• What tools and techniques are useful for implementing an
architecture in a manner that preserves its properties?
• We design the software but we must consider the hardware
(and the environment).
• Design must reflect requirements, and we must be able to
relate each requirements with parts of the design.
• How can we include non-functional requirements into the
design?
Stages of design
• Problem understanding
– Look at the problem from different angles to
discover the
design requirements
• Identify one or more solutions
– Evaluate possible solutions and choose the
most
appropriate depending on the designer's
experience and
available resources
• Describe solution abstractions
From informal to formal design
Requirements
specifica
tion
Design acti
vities
Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design
Software Data
System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification
Design pr
oducts
Design phases
• Architectural design Identify sub-systems
• Abstract specification Specify sub-systems
• Interface design Describe sub-system
interfaces
• Component design Decompose sub-systems
into components
• Data structure design Design data structures
to hold problem data
• Algorithm design Design algorithms for
problem functions