1. B. Computer Sci. (SE) (Hons.)
CSEB233:
Fundamentals of
Software Engineering
Software Design

2. Objectives


Explain set of design principles, concepts,
and practices
Describe four design models required for a
complete design specification:
 data
design
 architectural design
 user interface design
 component-level design


Use design support tools and evaluation
Explain the use of design specification
document

3. What is Design?


Design creates a representation or model of the
software
But unlike the analysis model, the design model
provides details about:





software architecture
data structures
interfaces, and
components that are necessary to implement the system.
Why is it important?


The model can be assessed for quality and improved
before code is generated
Tests are conducted, and more users are involved.

4. Analysis Models  Design Model
The four design models
sc e n a r i o - b a se d
e l e me nt s
Co m p o n e n t L e v e l D e sig n
f l ow- or i e n t e d
e l e m e nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e r f a c e D e sig n
Analysis Model
c l a ss- b a se d
e l e me nt s
class diagrams
analysis packages
CR models
C
collaboration diagrams
b e ha v i or a l
e l e me nt s
A r c h it e c t u r a l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
Each of the elements of the analysis/requirements model provides
information that is necessary to create the design models required
for a complete design specification.

5. Characteristics of Good Design




Must implement all of the explicit requirements
contained in the analysis model
Must accommodate all the implicit requirements
desired by the customer
Must be a readable, understandable guide for
those who generate code and for those who test
and subsequently support the software
Should provide a complete picture of the
software, addressing the data, functional, and
behavioral domains from an implementation
perspective
(McGlaughlin, 1991)

6. Design Principles



The design process should not suffer from „tunnel
vision‟
The design should be traceable to the analysis model
The design should not reinvent the wheel



Reinventing the wheel means to duplicate a basic method
that has previously been created or optimized by others
The design should „minimize the intellectual distance‟
between the software and the problem as it exists in
the real world
The design should exhibit uniformity and integration
(Davis,1995 )

7. Design Principles




The design should be structured to
accommodate change
The design should be structured to degrade
gently, even when irregular data, events, or
operating conditions are encountered
The design should be assessed for quality as
it is being created, not after
The design should be reviewed to minimize
conceptual (semantic) errors

8. Design Concepts

Fundamental design concepts that span both
traditional and OO software development
include:






Abstraction
Architecture
Patterns
Separation of concerns
Modularity
Information hiding






Functional Independence
Refinement
Aspects
Refactoring
OO Design concepts
Design classes

9. Abstraction
Designers should work to derive both
procedural and data abstractions that
serve the problem
 Procedural abstraction – sequence of
instructions that have a specific and
limited function
 Data abstractions – a named collection of
data that describes a data object


10. Abstraction
door
details of enter
algorithm
Implemented with a
"knowledge" of the
object that is
associated with
“enter”
door
manufacturer
model number
type
swing direction
weight
Implemented as a
data structure

11. Abstraction

Data abstraction refers to, providing only essential
features by hiding its background details
b1 is an object
calling input and
output member
functions.
But that code is
invisible to the
object b1

12. Architecture

Is concerned with:
 describing
the fundamental organization of the
system,
 identifying its various components and their
relationships to each other, and
 the environment in order to meet the system's
quality goals

It also describes the overall structure of the
software:
 organization
of program modules,
 the manner in which these modules interact, and
 the structure of data used by the components

13. Patterns

Online pattern searching:
 http://inventors.about.com/gi/dynamic/offsite.
htm?site=http%3A%2F%Fpatents.uspto.gov
%2Fpatft%2Findex.html
Under Quick Search, try to search pattern
no. 7669112.
 You will get „automated spell analysis‟
pattern.


14. Separation of Concerns

It is a rule of thumb to define how modules should
be separated to each other:




different or unrelated concerns should be restricted
to different modules
Any complex problem can be easily handled if it is
sub-divided into pieces that can be solved
independently
Why? So that a problem takes less time and effort
to solve
Manifested in other design concepts: modularity,
aspects, functional independence and refinement

15. Modularity
When software is divided into components
(modules)
 A design is modularized:

 To
ease the planning for implementation
(coding)
 To define and deliver software increments
 To easily accommodate changes
 To efficiently test and debug program, and
 To conduct long-term maintenance without
serious side effects

16. Modularity : Example
With Module
vs.
Without Module

17. Information Hiding
Suggests that modules should be
specified and designed so that information
(data structures and algorithm) contain
within a module is inaccessible to other
modules that have no need for such
information
 Implies that effective modularity can be
achieved by defining a set of independent
modules that communicate with one
another only necessary information


18. Information Hiding


Serves as an effective criterion for dividing any
piece of equipment, software or hardware, into
modules of functionality
Provides flexibility
This flexibility allows a programmer to modify
functionality of a computer program during normal
evolution as the computer program is changed to
better fit the needs of users
 When a computer program is well designed
decomposing the source code solution into modules
using the principle of information hiding, evolutionary
changes are much easier because the changes
typically are local rather than global changes


19. Information Hiding: Example


Suppose we have a Time class that counts the time of
day:
The Display() member function prints the current time
onscreen.



In contrast, the data member ticks is declared private.


This member function is accessible to all
It is therefore declared public
External users could not access it
Regardless of how Display() extracts the current
timestamp from ticks, users can be sure that it will “do
the right thing” and display the correct time onscreen.

20. Functional Independence



Achieved by developing independent modules –
each module address a specific subset of
requirements
Is assessed using cohesion and coupling.
Cohesion is an indication of the relative functional
strength of a module


a cohesive module should (ideally) do just one thing
Coupling is an indication of the relative interdependence among modules

depends on the interface complexity between
modules, the point at which entry or reference is
made to a module, and what data pass across the
interface.

21. Functional Independence

This class lacks cohesion

22. Functional Independence


The CashRegister involves two concepts: cash
register and coin
Solution: Make two classes:

23. Functional Independence

Coupling:
High and Low Coupling between Classes

24. Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

25. Refactoring

“Refactoring is the process of changing a software
system in such a way that it does not alter the
external behavior of the code [design] yet improves its
internal structure”
(Fowler, 1999)

When software is refactored, the existing design is
examined for





redundancy
unused design elements
inefficient or unnecessary algorithms
poorly constructed or inappropriate data structures
or any other design failure that can be corrected to yield a
better design.

26. Design Model Elements

Data/Class Design


Class diagrams transformed into the design class
realization and the data structures required to
implement the software
Architectural Design
Provides high-level overview of the system with
detailed descriptions to be given by other design
elements
 Defines the relationship between major structural
elements of the software, the architectural styles and
design patterns that can be used to achieve the
requirements of the system and the constraints that
affect the way in which the architecture can be
implemented


27. Design Models

Interface Design
 Describes
how the software communicates
with systems that interoperate with it, and
with human who use it

Component-Level Design
 Defines
the data structures, algorithms,
interface characteristics, and communication
mechanisms allocated to each software
component or module

28. Data/Class Design Elements

Example: High-level DFD

Source: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9

29. Data/Class Design Elements

Example: ERD

Source: http://www.svgopen.org/2003/papers/SvgInterfaceElectricalSwitching/index.html

30. Data/Class Design Elements

Example: Class Diagram

Source: http://www.agiledata.org/essays/objectOrientation101.html

31. Architectural Design Elements

The architectural model is derived from
three sources:
 information
about the application domain for
the software to be built
 specific requirements model elements such
as data flow diagrams or analysis classes,
their relationships and collaborations for the
problem at hand, and
 the availability of architectural patterns and
styles

32. Architectural Design Elements

Example: Architecture diagram

Source: http://blog.tmcnet.com/blog/tom-keating/2004/10/index.asp?page=7

33. Architectural Design Elements

Example: Architectural styles

34. Interface Design Elements

External interfaces
to other systems,
devices, networks
or other producers
or consumers of
information
MobilePhone
WirelessPDA
Cont rolPanel
LCDdisplay
LEDindicat ors
keyPadCharact erist ics
speaker
wirelessInt erf ace
Key Pad
readKeySt roke()
decodeKey ()
displaySt at us()
light LEDs()
sendCont rolMsg()
< < int erfac e> >
Key Pad
readKeyst roke()
decodeKey()
Figure 9 .6 UML int erfac e represent at ion for Co n t ro lPa n e l

35. Interface Design Elements

The user interface (UI)

36. Component Design Elements

UML Component Diagram

Source: http://edn.embarcadero.com/article/31863#component-and-deployment-diagrans

37. Design Support Tools

All aspects of the software engineering can be
supported by software tools:



from project management software through tools for
business and functional analysis, system design,
code storage, compilers, translation tools, test
software, and so on.
However, tools that are concerned with analysis
and design, and with using design information to
create parts (or all) of the software product, are
most frequently thought of as CASE tools.
List of CASE tools:

http://www.unl.csi.cuny.edu/faqs/softwareenginering/tools.html

38. CASE Tool: Example

IBM Rational Software Architect

Source: http://www.ibm.com/developerworks/rational/library/10/whats-newin-rational-software-architect-8/index.html

39. CASE Tool: Example

Database Modeling: Enterprise Architect by Sparx
Systems Pty Ltd.

Source: http://www.sparxsystems.com/images/screenshots/platforms/databasemodeling_tn.jpg

40. Design Evaluation

“A good software design minimizes the time
required to create, modify, and maintain the
software while achieving run-time performance”
(Shore and Chromatic, 2007)

Design quality is people-sensitive.


For instance, design quality is dependent upon the
programmers writing and maintaining the code.
Design quality is change-specific.

There are two general ways to make designs of
higher quality with respect to this aspect:


generalizing from the tools like design patterns, and
using tests and refactoring as change-enablers.
(Elssamadisy, 2007)

41. Design Evaluation
 Modification
and maintenance time are more
important than creation time because
time spent in maintenance is much more than
creation time of a software, and
 in iterative development, modification happens
during the initial creation of the software

 Design
quality is unpredictable
Because quality is really dependant on the team
developing the software. As the team changes,
or evolves, then the design quality also evolves
 You really only know how good a design is by its
standing the test of time and modifications


42. Design Evaluation

Points to ponder:
 To
maintain the quality of the design, we
must maintain the theory of the design as the
programming team evolves,

That design quality is tied to the people who are
building and maintaining the software
(Shore and Chromatic, 2007)

43. Design Specification


IEEE Standard for Information Technology Systems Design - Software Design
Descriptions (IEEE 1016-2009) an improved
version of the 1998 version
This standard specifies an organizational
structure for a software design description
(SDD)
 An
SDD is a document used to specify system
architecture and application design in a software
related project
 Provides a generic template for an SDD

44. SDD: Examples

Refer to
 http://www.cs.uofs.edu/~dmartin/exsesrm.ht
m#_Toc514249734

Refer to SDDSample.doc

45. Summary

This module has:
 Introduced
set of design principles, concepts,
and practices
 Described four design models required for a
complete design specification: data design,
architectural design, user interface design, and
component-level design
 Introduced design support tools and evaluation
 Introduced design specification document (SDD)

46. THE END
Copyright © 2013
Mohd. Sharifuddin Ahmad, PhD
College of Information
Technology