Software Design: An
Overview
Guy Tremblay and Anne Pons
EEL 6883
Software Engineering Vol. 1 Chapter 4
pp.191-208
Presenter: Sorosh Olamaei
1 Introduction




Design as a life cycle activity bonds the
requirements to construction
Process of breaking down the system into
components, defining interfaces and
defining components to a level of detail that
enables their construction
Blueprint of the solution to be implemented
Usually not unique
Scope of the paper
DeMarco’s terminology:
 Decomposition design ( D-design ): mapping of a
system into its component pieces
 Family Pattern design (FP-Design): goal is to
establish exploitable commonalities over a family of
systems
 Not covered: User Interface design, Invention
design (I-design): a conceptualization of a system
to satisfy discovered needs and constraints
2 Software Design
Concepts

Design key concepts: (car example)
– Goals
– Constraints
– Alternatives
– Representations
– Solutions ( to wicked problems: lack of test to
determine when the problem is indeed solved)
2.2 Software Design
Context
Software design is bounded to:
 Requirement analysis
 Construction (coding and unit testing)
 Integration and qualification testing
 Linear or Incremental life cycle models
2.3 Software Design
Process


Software architectural design
Software detailed design
3 Software Structure and
Architecture
Definition of software architecture:
The fundamental organization of a system embodied in its
components, their relationships to each other, and to the
environment, and principles guiding its design and evolution.
Reuse of generic design knowledge:
 Architectural Styles
 Design Patterns
 Product Lines
3.1 Architectural
Structures and Views


Key purpose of software architecture is communication among
stakeholders
Design View:
– A collection of models that represent an aspect of an entire
system.
– Represent a partial aspect of software architecture that shows
specific properties of a software system
– Overall organization of an SDD is composed of a number of
design views each of which contains a subset of the various
attributes describing design entities

View model by IEEE:
– Decomposition, Dependency, Interface , detailed description

4+1 view model by RUP:
– Logical, Implementation, Process ,Deployment ,Use-case
Architectural Structures
and Views

Views can be classified into 3 categories
called Viewtypes:
– Module viewtype
– Component-and-connector viewtype
– Allocation viewtype

Software architecture is a multifaceted
artifact produced by the design process and
composed of a set of relatively independent
and orthogonal views
3.2 Macro/Micro architectural Patterns:
Architectural Styles Versus Design Patterns



A pattern is a common solution to a common problem in a
given context
Goal is to codify and document recurring solutions to typical
problems
Attributes to ensure transferability:
–
–
–
–
–
–
–
–
Pattern name
The context in which the pattern may apply
Example illustrating need
Essence of the general problem
Underlying solution
Implementation guidelines
Related patterns
Advantages and disadvantages
Macro/Micro architectural Patterns:
Architectural Styles Versus Design Patterns

Pattern Classification based on scope and
level of abstraction:
– Architectural Styles
– Design Patterns
– Coding Idioms ( part of software construction not explained in this
paper)
Macro/Micro architectural Patterns: Architectural Styles
Versus Design Patterns


An architectural style expresses a fundamental
structural organization schema for software
systems. It provides a rich set of predefined
subsystems, specifies their responsibilities, and
includes rules and guideline for organizing the
relationship between them
Major Architectural Styles:
–
–
–
–
–

General structure
Distributed systems
Interactive systems
Adaptable systems
Other Styles
Choice depends on quality attributes that must be satisfied.
Heterogeneous styles are possible.
Macro/Micro architectural Patterns: Architectural Styles
Versus Design Patterns
Gamma et al. :
– Creational patterns
– Structural patterns
– Behavioral patterns
Buschmann et al. :
–
–
–
–
–
Structural decomposition patterns
Organization of work patterns
Access control patterns
Management patterns
Communication patterns
3.3 Design of Families of
Systems and Frameworks




Based on software product lines and software components
Software production line : A collection of systems sharing a
managed set of features constructed from a common set of
core software asset
Building a common set of software assets involves identifying
the key commonalities encountered among the various
members of the possible family of product- done through
domain analysis as well as accounting for their possible
variability - done by identifying and defining reusable and
customizable components
In an object-oriented context, a related notion is that of
framework, a partially complete software subsystem that can
be extended by instantiating specific plug-ins or hot spots
4 Software design quality
analysis and evaluation


Software Quality: The totality of features
and characteristics of a software product or
service that bear on its ability to satisfy
stated or implied needs
Properties of Software Quality
–
–
–
–
–
Functionality
Usability
Efficiency
Maintainability
portability
Software design quality
analysis and evaluation

4.1 Design Quality Attributes


Run-time qualities
Development-time qualities
– Impact of architectural choices
– Conceptual integrity which concerns the architecture’s intrinsic
quality : architecture reflects one single set of design ideas
leading to simplicity, consistency and elegance

4.2 Measures (quantitative estimates)
– Depends on selected design approach



Function-oriented (structured) measures
Objected-oriented measures
4.3 Quality Analysis and Evaluation Tools
– Quality attributes are hard to quantify


Software design reviews
Simulation and prototyping
5 Software design notations
and documentation
– Budgen categorization:


Black-box notation : external properties of the
elements of a design model
White-box notation : describing some aspect of the
detailed realization of a design element
– Alternative categorization:


Structural/Static properties
Behavioral/dynamic properties
– 5.1 A selection of Design Notations (UML)





Class and object diagrams
Component diagrams
Deployment diagrams
Structure charts
Structure (Jackson) diagrams
Software design notations
and documentation
– 5.2 Behavioral Descriptions (Dynamic
view)
Activity diagrams
 Interaction diagrams : sequence and
collaboration diagrams

Data flow diagrams
 State transition diagrams and statechart

diagrams

Pseudo code and program design languages
(PDLs)
5.2 Design
Documentation


Coherency of the design documentation
depends on many aspects: stakeholders,
software development methods …
Key practice is selection of an appropriate
set of views which satisfies different
stakeholders needs
– Project manager: detailed allocation views
– Developer: detailed module and component-andconnector views
Design Documentation



View documentation also involves describing
interfaces of the element from that view
A key characteristic of any interface specification :
must be two-way which means what the element
provides and what it requires
Another key idea: design should be presented and
documented in a rational way: the rationale behind
the key decisions should also recorded ex. The
design alternatives that were considered and
rejected should be described
6 Software Design
strategies and methods

6.1 General Strategies and Enabling
Techniques
– Software design strategies can be described in
terms of enabling techniques : independent of
specific software development method





Abstraction
Coupling and cohesion
Divide and conquer
Information hiding and encapsulation
Sufficiency
Software Design
strategies and methods

6.2 Function-oriented (Structured) Design
Divide and conquer approach toward identifying major system
function in a top-down approach.
Structured analysis produces DFDs of the various system functions
together with associated process descriptions, that is,
descriptions of the processing performed by each subtask,
usually using informal Pseudocode.
Entity-relationship diagrams describing the data stores can also be
used.
– Key strategies to help derive a software architecture from a DFD


Transaction analysis: triggers
Transformation analysis : identifying the central transform, structure
chart
– Key concept of structured design are those of coupling and
cohesion: restrict coupling to normal types: data, stamp, control
coupling. Avoid common and contest coupling
Software Design
strategies and methods
– Additional Heuristics to improve the
quality of resulting design
Fan-in/Fan-out: high / low or moderate ( 5-7
max)
 Decision splitting (avoid separating them into
files)
 Balanced systems: top-level modules deal
with logical and abstract data independent of
the implementation format

Software Design
strategies and methods

6.3 Object-oriented Design
– Object based (no inheritance or polymorphism) Vs object
oriented design
– OO design (solution domain) Vs requirement analysis ( problem
domain)
– Class diagrams Vs Integration diagrams (sequence or elaboration
diagrams)
6.4 Data-structured-oriented Design (Jackson Structured
Programming)
– Emphasis is on the data that a program manipulates rather than
the functions it performs
– Motivated by stability in data rather then functions that need to
be performed
– Restricted to the design of data-processing programs using
sequential ( batch-style) files and processes
– Jackson System Development (JSD) : approach similar to OOD to
address more complex interacting processes
My views about the paper



Comprehensive overview which does
not get the reader lost
Gets the reader motivated to read the
following design papers
Lack of references to sources that
expand on topics
Questions !?