Software Design
CIS 375
Bruce R. Maxim
UM-Dearborn
12/3/2011 1
Design Models – 1
• Data Design
– created by transforming the data dictionary and ERD into
implementation data structures
– requires as much attention as algorithm design
• Architectural Design
– derived from the analysis model and the subsystem
interactions defined in the DFD
• Interface Design
– derived from DFD and CFD
– describes software elements communication with
• other software elements
• other systems
• human users
12/3/2011 2
Design Models – 2
• Component-level design
– created by transforming the structural
elements defined by the software
architecture into procedural descriptions of
software components
– Derived from information in the PSPEC,
CSPEC, and STD
12/3/2011 3
A Good Design Should - 1
• exhibit good architectural structure
• be modular
• contain distinct representations
– data
– architecture
– interfaces
– components (modules)
• lead to data structures that are appropriate
for the objects to be implemented
12/3/2011 4
A Good Design Should - 2
• lead to interfaces that
– reduce complexity of module connections
– reduce complexity of connections to the external
environment
• be derived using a method driven by
information during software requirements
analysis
12/3/2011 5
Design Principles - 1
• Process should not suffer from tunnel vision
• Design should be traceable to analysis model
• Do not try to reinvent the wheel
• Try to minimize intellectual distance between
the software and the real world problem
• Design should exhibit both uniformity and
integration
• Should be structured to accommodate
changes
12/3/2011 6
Design Principles - 2
• Design is not coding and coding is not design
• Should be structured to degrade gently, when
bad data, events, or operating conditions are
encountered
• Needs to be assessed for quality as it is being
created
• Needs to be reviewed to minimize conceptual
(semantic) errors
12/3/2011 7
Design Concepts -1
• Abstraction
– allows designers to focus on solving a problem
without being concerned about irrelevant lower
level details
– procedural abstraction
– data abstraction
• Software Architecture
– overall structure of the software components and
the ways in which that structure
– provides conceptual integrity for a system
12/3/2011 8
Design Concepts -2
• Design Patterns
– description of a design structure that
solves a particular design problem within a
specific context and its impact when
applied
• Modularity
– the degree to which software can be
understood by examining its components
independently of one another
12/3/2011 9
Design Concepts -3
• Information Hiding
– information (data and procedure) contained
within a module is inaccessible to modules
that have no need for such information
• Functional Independence
– achieved by developing modules with
single-minded purpose and an aversion to
excessive interaction with other models
12/3/2011 10
Design Concepts -4
• Refinement
– process of elaboration where the designer
provides successively more detail for each
design component
• Refactoring
– process of changing a software system in
such a way internal structure is improved
without altering the external behavior or
code design
12/3/2011 11
Design Concepts - 4
• Objects
– encapsulate both data and data manipulation
procedures needed to describe the content and
behavior of a real world entity
• Class
– generalized description (template or pattern) that
describes a collection of similar objects
• Inheritance
– provides a means for allowing subclasses to reuse
existing superclass data and procedures; also
provides mechanism for propagating changes
12/3/2011 12
Design Concepts - 5
• Messages
– the means by which objects exchange information
with one another
• Polymorphism
– a mechanism that allows several objects in an
class hierarchy to have different methods with the
same name
– instances of each subclass will be free to respond
to messages by calling their own version of the
method
12/3/2011 13
Design Concepts - 6
• Design Classes
– refine analysis classes by providing detail
needed to implement the classes and
implement a software infrastructure the
support the business solution (i.e. user
interface classes, business domain
classes, process classes, persistent
classes, system classes)
12/3/2011 14
Modular Design Methodology
Evaluation - 1
• Modular decomposability
– provides systematic means for breaking problem
into subproblems
• Modular composability
– supports reuse of existing modules in new
systems
• Modular understandability
– module can be understood as a stand-alone unit
12/3/2011 15
Modular Design Methodology
Evaluation - 2
• Modular continuity
– module change side-effects minimized
• Modular protection
– processing error side-effects minimized
12/3/2011 16
Control Terminology - 1
• Span of control
– number of control levels within a software product
• Depth
– distance between the top and bottom modules in
program control structure
• Fan-out or width
– number of modules directly controlled by a
particular module
12/3/2011 17
Control Terminology - 2
• Fan-in
– number of modules that control a particular
module
• Visibility
– set of program components that may be called or
used as by a given component (either indirectly or
directly)
• Connectivity
– set of components that are called directly or are
used as data by a given component
12/3/2011 18
Effective Modular Design
• Functional independence
– modules have high cohesion and low coupling
• Cohesion
– qualitative indication of the degree to which a
module focuses on just one thing
• Coupling
– qualitative indication of the degree to which a
module is connected to other modules and to the
outside world
12/3/2011 19
Types of Coupling
• No direct coupling.
• Data coupled (data structures).
• Stamp coupling (parts of data structure).
• Control coupling (flags, etc.).
• External coupling (file format, database).
• Common coupling.
• Content coupling (references cross
component boundaries).
12/3/2011 20
Coupling Factors
• Type of connection between modules.
• Complexity of the interface.
• Type of information flow.
• Binding time of the connection.
12/3/2011 21
Decoupling?
• Start early in design process.
• Convert implicit references.
• Standardize connections.
• Localize your variables.
• Use buffers to moderate I/O to modules.
• Avoid race conditions, no waiting.
12/3/2011 22
Cohesion
• Coincidental cohesion.
• Logical cohesion.
• Temporal cohesion.
• Procedural cohesion.
• Communicational cohesion.
• Sequential cohesion.
• Functional cohesion.
12/3/2011 23
Promoting High Cohesion and
Low Coupling
• Small modules.
• Control "fan out" (width of tree).
• Focus on "fan in" (fan in = reuse).
• Scope of effect should be a subset of
scope of control.
– Don’t make a major decision in the lower
modules.
• Control Depth.
12/3/2011 24
Design Heuristics
• Evaluate "first cut" to reduce coupling and increase
cohesion.
• Minimize "fan out" and focus on "fan in".
• Scope of effect should be subset of scope of control.
• Reduce complexity of interfaces and improve
consistency.
• Define modules with predictable behavior, but don’t
be overly restrictive.
• Strive for single entry, single exit modules.
• Package software based on design constraints and
portability requirements (e.g. how the modules fit
together and work with one another).
12/3/2011 25
Data Design Principles - 1
• Systematic analysis applied to functional
behavior, can be applied to data.
• Data structures and operations should be
identified.
• Establish a data dictionary and use it to guide
both data and program design.
• Defer low level data structure decisions until
late in the design.
12/3/2011 26
Data Design Principles - 2
• Information hiding.
• Libraries of useful data structures and
operators is developed.
• Environment must support creation of
ADT’s (abstract data types).
12/3/2011 27
Architectural Design
• Derived from
– Information about the application domain relevant
to software
– Relationships and collaborations among specific
analysis model elements
– Availability of architectural patterns and styles
• Usually depicted as a set of interconnected
systems that are often derived from the
analysis packages
12/3/2011 28
Interface Design
• Interface is a set of operations that describes
the externally observable behavior of a class
and provides access to its operations
• Important elements
– User interface (UI)
– External interfaces to other systems
– Internal interfaces between various design
components
• Modeled using UML collaboration diagrams
12/3/2011 29
Component Level Design
• Describes the internal detail of each software
component
• Defines
– Data structures for all local data objects
– Algorithmic detail for all component processing
functions
– Interface that allows access to all component
operations
• Modeled using UML component and activity
diagrams, and pseudocode (PDL)
12/3/2011 30
Using Patterns in Design
• Architectural patterns
– define overall structure and relationships of
software components (classes, packages,
subsystems)
• Design patterns
– address specific design elements (component
aggregations, component relationships, or
communication)
• Idioms (coding patterns)
– language specific implementations for algorithms
or communications mechanisms
12/3/2011 31
Design Pattern Template
• Name
• Intent
• Aliases
• Motivation
• Applicability
• Structure
• Participants
• Collaborators
• Consequences
• Related patterns
12/3/2011 32