Software Design
Mihaela Dinsoreanu, PhD
Contact: room D01, Baritiu 26-28
E-mail: mihaela.dinsoreanu@cs.utcluj.ro
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
HOUSEKEEPING DETAILS
Time & Location:
See Schedule on www.ac.utcluj.ro
Prerequisites:
Software Engineering Course
Programming Techniques Course
Grading:
Project 25% Lab 25%
Final Exam 50%
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
HOUSEKEEPING CONTINUED..
TA’s
prep. ing. Ionut Anghel - 30231, 30232 prep.ing. Pop Cristina - 30234, 30235 ing. Sorin Suciu - 30431
ing. Grigore Vlad - 30236
ing. Iulia Vartic- 30433, 30434, 30234 ing. Tudor Vlad - 30432
Communication
ONLY via your utcluj account!
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
HOUSEKEEPING CONTINUED..
Lab sessions are compulsory
no more than 3 absences allowed!
2 types of projects
Common
Research-oriented (can be continued as DS
projects and Diploma projects)
Adaptive systems (contextual advertising) Semantic Business Intelligence
Data mining
Course files
http://users.utcluj.ro/~dinso/PS2011 …to be set up
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
REFERENCES
OOD Design Principles www.objectmentor.com
OO Development Methodologies
G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998.
R.S. Pressman, Software Engineering – A Practitioner’s Approach, McGraw-Hill, 5th edition, 2001, ISBN 0073655783.
RUP: Best Practices for Software Development Teams, Rational whitepaper, http://www-128.ibm.com/developerworks/rational/library/253.html
Design Patterns
E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. AddisonWesley, 1995.
Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition), Prentice Hall, 2004, ISBN: 0131489062
Software Architectures
Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sornmerlad, and Michael Stal. 2001. Pattern-oriented system architecture, volume 1: A system of patterns. Hoboken, NJ: John Wiley & Sons.
Fowler Martin, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002
Courses
B. Meyer (ETH Zurich)
G. Kaiser (Columbia Univ. NY) I. Crnkovic (Sweden)
R. Marinescu (Univ. Timisoara)
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
PRETEST (10 MIN)
1.
What software development
methodologies do you know?
2.
What types of diagrams would you use to
represent dynamic behavior?
3.
What types of diagrams would you use to
represent a domain model?
4.
How do we model requirements ?
5.
What is the outcome of software design?
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
OBJECTIVES
After completing this course, the student
should be able to:
Describe Object Oriented Analysis and Design
Concepts
Analyze system requirements and identify use cases Expand use cases into analysis and design models
Produce detailed static object models and dynamic
behavioral models
Apply design patterns to refine analysis and design
models
Apply class design principles to develop object
models
Construct testable and adaptable designs
Adapt and implement a design model in an OO
language (i.e. Java, C#, C++)
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
CONTENT
Software Quality Assurance
Software Quality attributes.
Introduction to software architecture
concepts like:
Architectural Patterns and Styles Design Patterns
Most important OOD principles
Class Design Principles,
Principles of Package Coupling and Cohesion GRASP
OO Design metrics
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
TODAY’S OUTLINE
Software quality dimensions Product
Process
Software design techniques Concepts
Principles
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
SOFTWARE ENGINEERING
The collection of processes, methods, techniques, tools and languages for
developing quality operational software. [B. Meyer]
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
SOFTWARE QUALITY
External factors: visible to customers (not
just end users but e.g. purchasers)
Examples: ease of use, extendibility, timeliness
Internal factors: perceptible only to
developers
Examples: good programming style, information
hiding
Only external factors count in the end, but the
internal factors make it possible to obtain them.
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
SOFTWARE QUALITY:
PROCESS/PRODUCT
Product: properties of the resulting
software
For example: correctness, efficiency
Process: properties of the procedures
used to produce and maintain the
software
Glossary follows
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
EXTERNAL QUALITY FACTORS
Product immediate:
Correctness
Robustness
Security
Ease of use
Ease of learning
Efficiency
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
EXTERNAL QUALITY FACTORS
(CONT’D)
Product long-term:
Extendibility
Reusability
Portability
Process
Timeliness
Cost Effectiveness
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
RELIABILITY
Correctness
The systems’ ability to perform according
to the specifications, in cases covered by the specification
Robustness
The systems’ ability to perform reasonably
in cases not covered by the specification Security
The systems’ ability to protect itself
against malicious use
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
MODULARITY
Reusability + Extendibility
Architectural techniques must ensure
decentralization of modules
Some Principles
Composability Decomposability Continuity
Information hiding
Open-closed principle Single choice principle
…
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
SOFTWARE DESIGN TECHNIQUES
What are Software Design Techniques?
SD Techniques provide a set of practices for
analysing, decomposing, and modularising software system architectures
In general, SD Techniques are characterized by
structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs.
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
LEARNING SD TECHNIQUES
Junior Developer ->Rules
algorithms, data structures and software
languages
write programs, although not always good ones
Senior Developer ->Principles
software design & programming paradigms with
pros and cons
importance of cohesion, coupling, information
hiding, dependency management
Master ->Patterns
study the "design of masters" Understand! Memorize! Apply!
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
WHERE DO YOU STAND?
You know the Rules
1-2 OO programming languages (Java, C++, C#) some experience in writing programs (< 10
KLOC)
You heard about Principles
"Open-Closed"; "Liskov Substitution Principle"
etc.
Maybe (in)voluntary applied some of them
You aim to become "design masters" but...
you believe that writing good software is somehow "magic"
exclusively tailored for geniuses, gurus
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
ROADMAP
Define good Design Goals of Design
Concepts and Principles of Design Metrics for Design
Apply good Design Patterns
Analysis
Architectural Design
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
GOALS OF DESIGN
Decompose system into components
i.e. identify the software architecture
Describe component functionality
informally or formally
Determine relationships between components
identify component dependencies
determine inter-component communication
mechanisms
Specify component interfaces
Interfaces should be well defined
facilitates component testing and team communication
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
CONCEPTS AND PRINCIPLES
Concepts Modularity
Composition/Decomposition
Principles
Software quality Systematic reuse
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
MODULARITY
A modular system is one that's structured
into identifiable abstractions called components
Components should possess well-specified
abstract interfaces
Components should have high cohesion and low
coupling
A software construction method is modular
if it helps designers produce software systems
made of autonomous elements connected by
a coherent, simple structure.
[B. Meyer]
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
BENEFITS
Modularity facilitates
software quality
factors
, e.g.:
Extensibility
well-defined, abstract interfaces
Reusability
low-coupling, high-cohesion
Portability
hide machine dependencies
Modularity is important for
good design
since it
Enhances for separation of concerns
Enables developers to reduce overall system complexity via decentralized software
architectures
Increases scalability by supporting independent and concurrent development by multiple
personnel
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
METRICS FOR GOOD MODULAR
DESIGN
Meyer’s Criteria
Decomposability Are larger components decomposed into smaller
components?
Composability
Are larger components composed from smaller
components?
Understandability
Are components separately understandable?
Continuity
Do small changes to the specification affect a
localized and limited number of components?
Protection
Are the effects of run-time abnormalities limited
to a small number of related components?
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
DECOMPOSABILITY
Decompose problem into smaller
sub-problems that can be solved
separately
Goal
: Division of Labor
keep dependencies
explicit
and
minimal
Example
: Top-Down Design
Counter-example
: Initialisation
Module
initialize everything for everybody
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
COMPOSABILITY
Freely combine modules to
produce new systems
Reusability
in different
environments
components
Example
: Math libraries; UNIX
command & pipes
Counter-example
: use of
pre-processors
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
UNDERSTANDABILITY
Individual modules
understandable by human
reader
Counter-example
: Sequential
Dependencies (
A |
B
| C
)
contextual significance of modules
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
CONTINUITY
Small change in specifications results in:
Small changes in the architecture (affects only a few
modules, not the overall architecture)
Example: Principle of Uniform Access Counter-Example: data-driven design
PROTECTION
Effects of an abnormal
run-time condition is limited to a
few modules
Example
: Validating input at
source
Counter-example
:
Undisciplined exceptions
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
MEYER'S PRINCIPLES OF
MODULARITY
Decomposition Composition Direct Mapping Few Interfaces Small Interfaces Explicit Interfaces Uniform Access
Information Hiding
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
DECOMPOSITION – DIVIDE AND
CONQUER
1. Select a piece of the problem
initially, the whole problem
2. Determine the components in this
piece using a design paradigm
e.g. functional, structured, object-oriented,
generic, etc.
3. Describe the components interactions
4. Repeat steps 1 through 3 until some
termination criteria is met
e.g., customer is satisfied, run out of
money, etc.
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
COMPONENT
... a SW entity encapsulating the
representation of an abstraction
... a vehicle for hiding at least one
design decision
... a "work" assignment
for a programmer or group of
programmers
... a unit of code that
has one (or more) name(s) has identifiable boundaries
can be (re-)used by other components encapsulates data
hides unnecessary details can be separately compiled
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
COMPONENT INTERFACE
A component interface consists of
several sections:
Exports
services provided to other
components
Imports
services required from other
components
Access Control
e.g. protected/private/public
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
DECOMPOSITION PRINCIPLES
P1. Don't design components to correspond to execution steps
Since design decisions usually transcend execution
time
[Parnas72]
P2. Decompose so as to limit the effects of design decisions
Anything that spreads within the system will be
expensive to change
P3. Components should be specified by all information needed to use the component
and nothing more!
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
DIRECT MAPPING
Keep the structure of the solution
compatible with the structure of the
modeled problem domain
clear mapping (correspondence) between the
two
Impact on:
Continuity
easier to assess and limit the impact of
change
Decomposability
decomposition in the problem domain model
as a good starting point for the decomposition of the software
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
FEW INTERFACES
Don’t talk to many!
Every module should communicate with as few others as possible
rather n-1 than n(n-1)/ 2
affects ... Continuity, Protection,
Understandability, Composability
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
SMALL INTERFACES
Don’t talk a lot!
If two modules communicate, they should exchange as little information as possible
limited "bandwidth" of communication Affects Continuity and Protection
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
EXPLICIT INTERFACES
Talk loud and clear!
Whenever two modules A and B
communicate, this must be obvious from the specification of A or B or both.
Affects: Decomposability and Composability,
Continuity, Understandability
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
UNIFORM ACCESS
Functionalities managed by a module should be accessible to its clients independent on their implementation method.
Affects: Decomposability, Continuity.
Example
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
INFORMATION HIDING
Motivation: design decisions that are subject to change should be hidden behind abstract
interfaces, i.e. components
Components should communicate only through
well-defined interfaces
Each component is specified by as little
information as possible
Continuity: If internal details change, client components should be minimally affected
not even recompiling or linking Decomposability
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
QUESTIONS?
Thank you!
S
p
rin
g
2
0
1
1
C
o
m
p
u
te
r S
cie
n
ce
D
e
p
a
rtm
e
n
t, T
U
C
