Lecture1_Introduction.ppt 809KB Jun 23 2011 12:06:48 PM

Contact: room D01, Baritiu 26-28
E-mail: mihaela.dinsoreanu@cs.utcluj.ro

Computer Science Department, TUC-N

Mihaela Dinsoreanu, PhD

Spring 2011

Software Design

HOUSEKEEPING DETAILS
 See

& Location:
Schedule on www.ac.utcluj.ro

 Software

Engineering Course
 Programming Techniques Course

 Grading:
 Project

25%
 Lab 25%
 Final Exam 50%

Computer Science Department, TUC-N

 Prerequisites:

Spring 2011

 Time

HOUSEKEEPING CONTINUED..



Communication

 ONLY

via your utcluj account!

Computer Science Department, TUC-N

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

Spring 2011



HOUSEKEEPING CONTINUED..

Course files
http://users.utcluj.ro/~dinso/PS2011
…to be set up


Computer Science Department, TUC-N

Adaptive systems (contextual advertising)
 Semantic Business Intelligence
 Data mining


Spring 2011

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)



REFERENCES


OOD Design Principles



OO Development Methodologies



Design Patterns





E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns.

AddisonWesley, 1995.
Craig Larman, Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and Iterative Development (3rd Edition),
Prentice Hall, 2004, ISBN: 0131489062

Software Architectures





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, McGrawHill, 5th edition, 2001, ISBN 0073655783.
RUP: Best Practices for Software Development Teams, Rational whitepaper,
http://www-128.ibm.com/developerworks/rational/library/253.html

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, AddisonWesley Professional, 2002

Courses





B. Meyer (ETH Zurich)
G. Kaiser (Columbia Univ. NY)
I. Crnkovic (Sweden)
R. Marinescu (Univ. Timisoara)

Computer Science Department, TUC-N




www.objectmentor.com

Spring 2011



1.

3.

4.
5.

What software development
methodologies do you know?
What types of diagrams would you use to
represent dynamic behavior?
What types of diagrams would you use to
represent a domain model?
How do we model requirements ?
What is the outcome of software design?

Computer Science Department, TUC-N

2.

Spring 2011

PRETEST (10 MIN)



After completing this course, the student
should be able to:

Computer Science Department, TUC-N

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++)


Spring 2011

OBJECTIVES

 Software

Quality Assurance
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

Computer Science Department, TUC-N

 Software

Spring 2011

CONTENT



Software quality dimensions
 Process



Software design techniques
 Concepts
 Principles

Computer Science Department, TUC-N

 Product

Spring 2011

TODAY’S OUTLINE

Computer Science Department, TUC-N

The collection of processes, methods,
techniques, tools and languages for
developing quality operational software.
[B. Meyer]

Spring 2011

SOFTWARE ENGINEERING

 External

 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.

Computer Science Department, TUC-N

factors: visible to customers (not
just end users but e.g. purchasers)

Spring 2011

SOFTWARE QUALITY

 Product:

properties of the resulting

 Glossary

follows

Computer Science Department, TUC-N

software
For example: correctness, efficiency
 Process: properties of the procedures
used to produce and maintain the
software

Spring 2011

SOFTWARE QUALITY:
PROCESS/PRODUCT

 Product

Computer Science Department, TUC-N

immediate:
Correctness
Robustness
Security
Ease of use
Ease of learning
Efficiency

Spring 2011

EXTERNAL QUALITY FACTORS

 Product

Computer Science Department, TUC-N

long-term:
Extendibility
Reusability
Portability
 Process
Timeliness
Cost Effectiveness

Spring 2011

EXTERNAL QUALITY FACTORS
(CONT’D)

Computer Science Department, TUC-N

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


Spring 2011

RELIABILITY

 Reusability

 Composability
 Decomposability
 Continuity
 Information

hiding
 Open-closed principle
 Single choice principle
…

Computer Science Department, TUC-N

+ Extendibility
 Architectural techniques must ensure
decentralization of modules
 Some Principles

Spring 2011

MODULARITY



What are Software Design Techniques?
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.

Computer Science Department, TUC-N

 SD

Spring 2011

SOFTWARE DESIGN TECHNIQUES

LEARNING SD TECHNIQUES
Developer ->Rules

 algorithms,

data structures and software

 Senior

Developer ->Principles

 software

design & programming paradigms with
pros and cons
 importance of cohesion, coupling, information
hiding, dependency management
 Master
 study

->Patterns

the "design of masters"
 Understand! Memorize! Apply!

Computer Science Department, TUC-N

languages
 write programs, although not always good ones

Spring 2011

 Junior



You know the Rules
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

Computer Science Department, TUC-N

 1-2

Spring 2011

WHERE DO YOU STAND?



Define good Design
of Design
 Concepts and Principles of Design
 Metrics for Design



Apply good Design
 Patterns

Analysis
 Architectural
 Design


Computer Science Department, TUC-N

 Goals

Spring 2011

ROADMAP



Decompose system into components


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

Computer Science Department, TUC-N



i.e. identify the software architecture

Spring 2011

GOALS OF DESIGN



Concepts




Principles



Software quality
Systematic reuse

Computer Science Department, TUC-N



Modularity
Composition/Decomposition

Spring 2011

CONCEPTS AND PRINCIPLES

A

 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]

Computer Science Department, TUC-N

modular system is one that's structured
into identifiable abstractions called
components

Spring 2011

MODULARITY

Modularity facilitates software quality
factors, e.g.:


well-defined, abstract interfaces

 Reusability


low-coupling, high-cohesion

 Portability


hide machine dependencies

 Modularity

since it

is important for good design

 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

Computer Science Department, TUC-N

 Extensibility

Spring 2011

BENEFITS

 Meyer’s

Criteria



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?

Computer Science Department, TUC-N

 Decomposability

Spring 2011

METRICS FOR GOOD MODULAR
DESIGN



Division of Labor

keep dependencies explicit and
minimal

Example:

Top-Down Design
Counter-example: Initialisation
Module


initialize everything for everybody

Computer Science Department, TUC-N

Goal:

Spring 2011

DECOMPOSABILITY
 Decompose problem into smaller
sub-problems that can be solved
separately

Freely

Reusability

in different
environments  components
Example: Math libraries; UNIX
command & pipes
Counter-example: use of preprocessors

Computer Science Department, TUC-N

combine modules to
produce new systems

Spring 2011

COMPOSABILITY

Individual

Counter-example:

Sequential
Dependencies (A | B | C)
contextual significance of modules



Computer Science Department, TUC-N

modules
understandable by human
reader

Spring 2011

UNDERSTANDABILITY

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

Effects

Example:

Validating input at

source
Counter-example:
Undisciplined exceptions

Computer Science Department, TUC-N

of an abnormal runtime condition is limited to a
few modules

Spring 2011

PROTECTION

Computer Science Department, TUC-N

Decomposition
 Composition
 Direct Mapping
 Few Interfaces
 Small Interfaces
 Explicit Interfaces
 Uniform Access
 Information Hiding


Spring 2011

MEYER'S PRINCIPLES OF
MODULARITY

1. Select a piece of the problem
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.

Computer Science Department, TUC-N

 initially,

Spring 2011

DECOMPOSITION – DIVIDE AND
CONQUER

 ...

 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

Computer Science Department, TUC-N

a SW entity encapsulating the
representation of an abstraction
 ... a vehicle for hiding at least one
design decision
 ... a "work" assignment

Spring 2011

COMPONENT

Computer Science Department, TUC-N

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

Spring 2011

COMPONENT INTERFACE

P1. Don't design components to correspond to
execution steps

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!

Computer Science Department, TUC-N

Since design decisions usually transcend execution
time
[Parnas72]


Spring 2011

DECOMPOSITION PRINCIPLES

 clear

two

mapping (correspondence) between the

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

Computer Science Department, TUC-N

Keep the structure of the solution
compatible with the structure of the
modeled problem domain

Spring 2011

DIRECT MAPPING

 rather

n-1 than n(n-1)/ 2
 affects ... Continuity, Protection,
Understandability, Composability

Computer Science Department, TUC-N

Don’t talk to many!
 Every module should communicate with as
few others as possible


Spring 2011

FEW INTERFACES

 limited

"bandwidth" of communication
 Affects Continuity and Protection

Computer Science Department, TUC-N

Don’t talk a lot!
 If two modules communicate, they should
exchange as little information as possible


Spring 2011

SMALL INTERFACES

 Affects:

Decomposability and Composability,
Continuity, Understandability

Computer Science Department, TUC-N

Talk loud and clear!
 Whenever two modules A and B
communicate, this must be obvious from the
specification of A or B or both.


Spring 2011

EXPLICIT INTERFACES



 Affects:


Example

Decomposability, Continuity.

Computer Science Department, TUC-N

Functionalities managed by a module should
be accessible to its clients independent on
their implementation method.

Spring 2011

UNIFORM ACCESS

 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

Computer Science Department, TUC-N

Motivation: design decisions that are subject to
change should be hidden behind abstract
interfaces, i.e. components

Spring 2011

INFORMATION HIDING

Computer Science Department, TUC-N

Thank you!

Spring 2011

QUESTIONS?