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