CSEB233: Fundamentals of
Software Engineering
Software Design
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
Software Design
Design Principles, Concepts, and Practices
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.
Analysis Models Design Model
Analysis Model
use-cases - text use-case diagrams activity diagrams swim lane diagrams
data flow diagrams control-flow diagrams processing narratives
f low-oriented elements
behavioralelements
class-basedelements
scenario-basedelements
class diagrams analysis packages CRC models collaboration diagrams
state diagrams sequence diagrams
Data/ Class Design
Architec tural Design
Interface Design
Component- Level Design
Design Model
The four design models
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.
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)
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 )
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
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
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
Named collection of data that describes a data object
Abstraction
door
manufacturer model number type swing direction weight
door
manufacturer model number type swing direction weight
Implemented as a data structure
door
details of enter algorithm
door
details of enter algorithm
Implemented with a "knowledge" of the object that is associated with “enter”
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
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
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.
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
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
Modularity : Example
Without Module
With Module
vs.
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
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
Information Hiding: Example
Suppose we have a Time class that counts the time of day:
The Display() member function prints the current time onscreen. This member function is accessible to all It is therefore declared public
In contrast, the data member ticks is declared private. 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.
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 inter-dependence 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.
Functional Independence
This class lacks cohesion
Functional Independence
The CashRegister involves two concepts: cash register and coin
Solution: Make two classes:
Functional Independence
Coupling:
High and Low Coupling between Classes
Refinement
open
walk to door;reach for knob;
open door;walk through;
close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then
take key out;find correct key;insert in lock;
endif
pull/push doormove out of way;end repeat
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.
Software Design
Design Models
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
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
Data/Class Design Elements
Example: High-level DFD Source: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9
Data/Class Design Elements
Example: ERD Source: http://www.svgopen.org/2003/papers/SvgInterfaceElectricalSwitching/index.html
Data/Class Design Elements
Example: Class Diagram Source: http://www.agiledata.org/essays/objectOrientation101.html
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
Architectural Design Elements
Example: Architecture diagram Source: http://blog.tmcnet.com/blog/tom-keating/2004/10/index.asp?page=7
Architectural Design Elements
Example: Architectural styles
Interface Design Elements
External interfaces to other systems, devices, networks or other producers or consumers of information
ControlPanel
LCDdisplay LEDindicators keyPadCharacteristics speaker wirelessInterface
readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg()
Figure 9.6 UML interface representation for ControlPanel
KeyPad
readKeystroke() decodeKey()
<<interface>>
WirelessPDA
KeyPad
MobilePhone
Interface Design Elements
The user interface (UI)
Component Design Elements
UML Component Diagram Source: http://edn.embarcadero.com/article/31863#component-and-deployment-diagrans
Software Design
Design Support Tools
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/software-enginering/tools.ht
ml
CASE Tool: Example
IBM Rational Software Architect Source:
http://www.ibm.com/developerworks/rational/library/10/whats-new-in-rational-software-architect-8/index.html
CASE Tool: Example
Database Modeling: Enterprise Architect by Sparx Systems Pty Ltd.
Source: http://www.sparxsystems.com/images/screenshots/platforms/databasemodeling_tn.jpg
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)
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
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)
Software Design
Design Specification
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
SDD: Examples
Refer to http://www.cs.uofs.edu/~dmartin/exsesrm.ht
m#_Toc514249734
Refer to SDDSample.doc
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)
THE END
Copyright © 2014
College of Information Technology