Post on 04-Jan-2016
Software Design
Mihaela Dinsoreanu, PhD
Contact: room D01, Baritiu 26-28E-mail: mihaela.dinsoreanu@cs.utcluj.ro
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
HOUSEKEEPING DETAILS
Time & Location: See Schedule on www.ac.utcluj.ro
Prerequisites: Software Engineering CourseProgramming Techniques Course
Grading:Project 25%Lab 25%Final Exam 50%
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
HOUSEKEEPING CONTINUED..
TA’sprep. ing. Ionut Anghel - 30231, 30232 prep.ing. Pop Cristina - 30234, 30235 ing. Sorin Suciu - 30431 ing. Grigore Vlad - 30236 ing. Iulia Vartic- 30433, 30434, 30234ing. Tudor Vlad - 30432
Communication ONLY via your utcluj account!
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
HOUSEKEEPING CONTINUED..
Lab sessions are compulsory no more than 3 absences allowed!
2 types of projectsCommonResearch-oriented (can be continued as DS
projects and Diploma projects) Adaptive systems (contextual advertising) Semantic Business Intelligence Data mining
Course fileshttp://users.utcluj.ro/~dinso/PS2011
…to be set up
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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)
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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?
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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++)
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
CONTENT Software Quality Assurance
Software Quality attributes. Introduction to software architecture
concepts like: Architectural Patterns and StylesDesign Patterns
Most important OOD principlesClass Design Principles,Principles of Package Coupling and
CohesionGRASPOO Design metrics
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
TODAY’S OUTLINE
Software quality dimensions Product Process
Software design techniques Concepts Principles
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
SOFTWARE ENGINEERING
The collection of processes, methods, techniques, tools and languages for developing quality operational software.
[B. Meyer]
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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.
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
SOFTWARE QUALITY: PROCESS/PRODUCT Product: properties of the resulting
softwareFor example: correctness, efficiency
Process: properties of the procedures used to produce and maintain the software
Glossary follows
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
EXTERNAL QUALITY FACTORS
Product immediate:CorrectnessRobustnessSecurityEase of useEase of learningEfficiency
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
EXTERNAL QUALITY FACTORS (CONT’D)
Product long-term:ExtendibilityReusabilityPortability
ProcessTimelinessCost Effectiveness
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
RELIABILITY
CorrectnessThe systems’ ability to perform according
to the specifications, in cases covered by the specification
RobustnessThe systems’ ability to perform reasonably
in cases not covered by the specification Security
The systems’ ability to protect itself against malicious use
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
MODULARITY
Reusability + Extendibility Architectural techniques must ensure
decentralization of modules Some Principles
ComposabilityDecomposabilityContinuity Information hidingOpen-closed principleSingle choice principle…
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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.
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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 ->Patternsstudy the "design of masters"Understand! Memorize! Apply!
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
ROADMAP Define good Design
Goals of Design Concepts and Principles of Design Metrics for Design
Apply good Design Patterns
Analysis Architectural Design
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
CONCEPTS AND PRINCIPLES Concepts
Modularity Composition/Decomposition
Principles Software quality Systematic reuse
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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 systemsmade of autonomous elements connected by a
coherent, simple structure. [B. Meyer]
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
BENEFITSModularity 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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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?
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
DECOMPOSABILITY
Decompose problem into smaller sub-problems that can be solved separatelyGoal: Division of Labor
keep dependencies explicit and minimal
Example: Top-Down DesignCounter-example: Initialisation
Module initialize everything for everybody
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
COMPOSABILITY
Freely combine modules to produce new systemsReusability in different
environments components Example: Math libraries; UNIX
command & pipes Counter-example: use of pre-
processors
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
UNDERSTANDABILITY
Individual modules understandable by human readerCounter-example: Sequential
Dependencies (A | B | C)contextual significance of modules
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Spring 2011 Computer Science Department, TUC-N
PROTECTION
Effects of an abnormal run-time condition is limited to a few modulesExample: Validating input at
sourceCounter-example:
Undisciplined exceptions
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
MEYER'S PRINCIPLES OF MODULARITY Decomposition Composition Direct Mapping Few Interfaces Small Interfaces Explicit Interfaces Uniform Access Information Hiding
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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 paradigme.g. functional, structured, object-oriented,
generic, etc.
3. Describe the components interactions4. Repeat steps 1 through 3 until some
termination criteria is met e.g., customer is satisfied, run out of
money, etc.
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
COMPONENT INTERFACE
A component interface consists of several sections:
Exportsservices provided to other
components Imports
services required from other components
Access Controle.g. protected/private/public
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
DECOMPOSITION PRINCIPLESP1. 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!
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
DIRECT MAPPING
Keep the structure of the solution compatible with the structure of the modeled problem domainclear mapping (correspondence) between
the two
Impact on: Continuity
easier to assess and limit the impact of change
Decomposabilitydecomposition in the problem domain
model as a good starting point for the decomposition of the software
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
UNIFORM ACCESS Functionalities managed by a module should
be accessible to its clients independent on their implementation method. Affects: Decomposability, Continuity.
Example
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
INFORMATION HIDINGMotivation: 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
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N
QUESTIONS?
Thank you!
Sp
ring
20
11
Co
mp
ute
r Scie
nce
De
pa
rtme
nt, T
UC
-N