Transcript CSEB233 Fundamentals of Software Engineering Module 4: Software Design Badariah Solemon 2011 Objectives • To explain set of design principles, concepts, and practices. • To describe.

CSEB233 Fundamentals of
Software Engineering
Module 4: Software Design
Badariah Solemon 2011
Objectives
• To explain set of design principles, concepts,
and practices.
• To describe four design models required for a
complete design specification: data design,
architectural design, user interface design,
and component-level design.
• To introduce design support tools and
evaluation.
• To introduce design specification document.
Badariah Solemon 2011
What is Design?
• Design creates a representation or model
of the software
• but unlike the analysis model, the design
model provides detail about:
»
»
»
»
software architecture,
data structures,
interfaces, and
components that are necessary to implement the
system.
• Why is it important?
 Because the model can be assessed for quality and
improved before code is generated, tests are
conducted, and more users are involved.
Badariah Solemon 2011
Analysis Models  Design Model
The four design models:
sc e na r i o- ba se d
e l e m e 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 nt 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- ba se d
e l e m e nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e m e 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.
Badariah Solemon 2011
Characteristics of Good
Design
According to McGlaughlin(1991):
 Must implement all of the explicit requirements
contained in the analysis model, and it must
accommodate all of 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.
Badariah Solemon 2011
Design Principles
According Davis(1995 ):
 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.
 The design should “minimize the intellectual
distance” [DAV95] between the software and
the problem as it exists in the real world.
 The design should exhibit uniformity and
integration.
Badariah Solemon 2011
Design Principle:
• The design process should not suffer from
‘tunnel vision.’
• The design should not reinvent the wheel.
– Reinventing the wheel is a phrase that means to
duplicate a basic method that has already
previously been created or optimized by others.
Badariah Solemon 2011
Design Principles (cnt’d)





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.
Design is not coding, coding is not design.
The design should be assessed for quality as it is
being created, not after the fact.
The design should be reviewed to minimize
conceptual (semantic) errors.
Badariah Solemon 2011
Generic Task Set for Design

Refer to the “Task Set” in page 222.
Badariah Solemon 2011
Design Concepts

Fundamental design concepts that span both
traditional and OO software development
include:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
Abstraction
Architecture
Patterns
Separation of concerns
Modularity
Information hiding
Functional Independence
Refinement
Aspects
Refactoring
OO Design concepts
Design classes
Badariah Solemon 2011
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
Badariah Solemon 2011
Abstraction (cnt’d)
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
Badariah Solemon 2011
Abstraction (cnt’d)
Data abstraction refers to, providing only essential features by
hiding its background details.
class result
{
int marks;
float percentage;
char name[20];
void input();
void output();
}
b1 is an object calling input and output
member functions, but that code is invisible
to the object b1.
main()
{
bank b1;
b1.input();
b1.output();
}
Badariah Solemon 2011
Architecture
• Is concerned on:
– 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.
• Also, describe 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.
Badariah Solemon 2011
Patterns
• Online pattern searching:
– http://inventors.about.com/gi/dynamic/offsite.ht
m?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.
Badariah Solemon 2011
Separation of Concerns
• Actually, 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.
• Suggests that 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.
• Is manifested in other design concepts: modularity,
aspects, functional independence and refinement.
Badariah Solemon 2011
Modularity
• When software is divided into components
(modules).
• Modularize a design:
– 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
Badariah Solemon 2011
Modularity : Example
With Module
• x
vs.
Without Module
#include <stdio.h>
main()
{ …
printf(“This program
draws a rectangle”);
…
}
#include <stdio.h>
void print_menu(void);
main()
{ …
print_menu();
…
} /* end main */
void print_menu(void)
{
printf(“This program
draws a rectangle”);
} /* end function */
Badariah Solemon 2011
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.
Badariah Solemon 2011
Information Hiding (cnt’d)
• 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.
Badariah Solemon 2011
Information Hiding: Example
• Suppose we have a Time class that counts the time of day:
class Time
{
public:
void Display();
private:
int ticks;
};
• The Display() member function prints the current time
onscreen. This member function is accessible to all. It's
therefore declared public.
• By contrast, the data member ticks is declared private.
Therefore, external users can't access it.
Badariah Solemon 2011
Information Hiding: Example
(cnt’d)
• 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.
Badariah Solemon 2011
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,
Badariah Solemon 2011
and what data pass across the interface.
Functional Independence (cnt’d)
• This class lacks cohesion:
public class CashRegister
{
public void enterPayment(int dollars, int
quarters, int dimes, int nickels, int pennies)
. . .
public static final double NICKEL_VALUE = 0.05;
public static final double DIME_VALUE = 0.1;
public static final double QUARTER_VALUE = 0.25;
. . .
}
Badariah Solemon 2011
Functional Independence (cnt’d)
• The CashRegister, as described above, involves two
concepts: cash register and coin
• Solution: Make two classes:
public class Coin
{
public Coin(double aValue, String aName){ . . . }
public double getValue(){ . . . }
. . .
}
public class CashRegister
{
public void enterPayment(int coinCount, Coin coinType) { . . .
}
. . .
}
Badariah Solemon 2011
Functional Independence (cnt’d)
• Coupling:
Badariah Solemon 2011
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
Badariah Solemon 2011
Refactoring
• According to Fowler (1999):
– "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.”
• 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.
Badariah Solemon 2011
Design Model Elements
1. Data/Class Design

Class diagrams transformed into the design class
realization and the data structures required to
implement the software.
2. 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.
Badariah Solemon 2011
Design Models (cnt’d)
3. Interface Design

Describes how the software communicates
with systems that interoperate with it, and
with human who use it.
4. Component-Level Design

Defines the data structures, algorithms,
interface characteristics, and communication
mechanisms allocated to each software
component or module.
Badariah Solemon 2011
Data/Class Design Elements
example: High-level DFD
Source: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9
Badariah Solemon 2011
Data/Class Design Elements (cnt’d)
example: ERD
Source: http://www.svgopen.org/2003/papers/SvgInterfaceElectricalSwitching/index.html
Badariah Solemon 2011
Data/Class Design Elements (cnt’d)
example: Class Diagram
Source: http://www.agiledata.org/essays/objectOrientation101.html
Badariah Solemon 2011
Architectural Design Elements
The architectural model [Sha96] 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 (Chapter 12) and
styles (Chapter 9).
Badariah Solemon 2011
Architectural Design Elements
(cnt’d)
Example: architecture diagram
Source: http://blog.tmcnet.com/blog/tom-keating/2004/10/index.asp?page=7
Badariah Solemon 2011
Architectural Design Elements
(cnt’d)
Example: Architectural styles
Source: x
Badariah Solemon 2011
Interface Design Elements
MobilePhone
• External interfaces to
other systems, devices,
networks or other
producers or consumers
of information
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
Badariah Solemon 2011
Interface Design Elements (cnt’d)
• The user
interface
(UI)
Badariah Solemon 2011
Component Design Elements
• UML
Component
Diagram
Source: http://edn.embarcadero.com/article/31863#component-and-deployment-diagrans
Badariah Solemon 2011
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
Badariah Solemon 2011
CASE Tool: Example
• IBM
Rational
Software
Architect
Source: http://www.ibm.com/developerworks/rational/library/10/whats-new-in-rationalsoftware-architect-8/index.html
Badariah Solemon 2011
CASE Tool: Example (cnt’d)
• Database
Modeling:
Enterprise
Architect by
Sparx
Systems Pty
Ltd.
Source: http://www.sparxsystems.com/images/screenshots/platforms/databasemodeling_tn.jpg
Badariah Solemon 2011
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)
According to Elssamadisy (2007):
1)
Design quality is people-sensitive.

2)
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:
1.
2.
generalizing from the tools like design patterns, and
using tests and refactoring as change-enablers.
Badariah Solemon 2011
Design Evaluation (cnt’d)
3)
Modification and maintenance time are more
important than creation time.

Because:
1.
2.
4)
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 it standing
the test of time and modifications.
Badariah Solemon 2011
Design Evaluation (cnt’d)
• 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).
Badariah Solemon 2011
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.
Badariah Solemon 2011
SDD: Examples
• Refer to
http://www.cs.uofs.edu/~dmartin/exsesrm.htm#_To
c514249734
• Refer to SDDSample.doc
Badariah Solemon 2011
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).
Badariah Solemon 2011
References
• Pressman, R. (2003). Software Engineering: A Practitioner's Approach. 6th
& 5th edition. New York: McGraw-Hill.
• Somerville I. (2001). Software Engineering. 6th edition. Addison Wesley
• http://www.allinterview.com/showanswers/66313.html
• http://www.augustana.ab.ca/~mohrj/courses/2006.winter/csc120/slides/c
h09/ch09.html
• http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=78
• Shore, J. and Chromatic, (2007). The Art of Agile Development. O'Reilly
Media.
• Elssamadisy, A. (2007). Defining Design Quality.
http://www.infoq.com/news/2007/04/defining-design-quality
Badariah Solemon 2011