Software Architecture and Design

CS 406 Software Engineering I

Fall 2001

Aditya P. Mathur

Purdue University

Last update: September 25, 2001

Organization

Part I: Design principles

Part II: Design Patterns-I
Part III: OO Design
Part IV: Design Patterns-II

September 20, 2001 Software Architecture and Design 2

Learning Objectives

 To understand the basic principles of and

techniques for software architecture and design.

September 20, 2001 Software Architecture and Design 3

What is Architecture?
 Organization of a software system

 Components within the system.

 Interfaces of the components and their interconnection.
 Collaborations amongst components.

 Involves the identification of those functional and non-functional

requirements that have a significant impact on the system design.
Examples:
 Performance
 Cost
 Maintainability
 Points of evolution

September 20, 2001 Software Architecture and Design 4

What is Architecture?

 Involves the identification of those functional and non-functional requirements that

have a significant impact on the system design. Examples:

 Performance
 Cost
 Maintainability
 Points of evolution

September 20, 2001 Software Architecture and Design 5

Architecture (2)

 Analogy: Explain the architecture of:

 Your favorite Concerto
 Your favorite play
 Your favorite home

September 20, 2001 Software Architecture and Design 6

Architecture (3)

 Software components-OO View:

 Application
 A subsystem
• An object
– A method
– A data item

September 20, 2001 Software Architecture and Design 7

Architecture (4)

 Software components-Functional View:

 Application
 A Subsystem
• A function
• A data item
 Do you understand the differences
between a class, an object, and a
function? Between a function and a
method?
September 20, 2001 Software Architecture and Design 8
What is Design?

 As a process:
The process by which the architecture of a
software system is established.

 As an artifact:
The architecture of a software system
describing system components and their
interactions.

September 20, 2001 Software Architecture and Design 9

Analysis and Design

 Analysis: Focus on….

 Understanding, refining, and specifying
requirements.
 “What” are domain processes, concepts,
terms, operations?
 Design: Focus on….
 “How” can the requirements be met?

September 20, 2001 Software Architecture and Design 10

Design Phase

Refine Sync Analyze Design Construct Test

Plan Artifacts

September 20, 2001 Software Architecture and Design 11

Design Principles [1]

 Design for change

Change of algorithms
Change of data representation
Change of peripheral devices
Change of underlying abstract machine
Change of social environment
September 20, 2001 Software Architecture and Design 12
Design Principles [2]

 Separation of concerns

Separation over time.

Separation of quality attributes:
e.g. performance and correctness
Separation by views: e.g. data and control flows.
Separation by parts of the system.

September 20, 2001 Software Architecture and Design 13

Coupling (1)

 Measure of interconnectedness.
 Class C1 is coupled to class C2 if C1 requires
C2 directly or indirectly.
 Coupling measures the strength of
dependence between classes and packages.

September 20, 2001 Software Architecture and Design 14

Coupling (2)

High coupling Low coupling

September 20, 2001 Software Architecture and Design 15
Coupling (3)

 Design with low coupling

 A class that depends on 2 other classes has a
lower coupling than a class that depends on 8
other classes.
 Why low coupling?...Leads to easier changes,
easier understanding, and easier re-use.

September 20, 2001 Software Architecture and Design 16

Factors effecting coupling

Coupling Interface
complexity
Low Simple
Obvious
High Complicated
Obscure

September 20, 2001 Software Architecture and Design 17

Cohesion (1)

 Cohesion measures the strength of the

relationship amongst elements of a class.
 When methods within a class use a
“similar” set of instance variables, the
class is considered highly cohesive.

September 20, 2001 Software Architecture and Design 18

Cohesion (2)

 High cohesion and low coupling is

preferred. (Example: Electric subsystem of a home.)
 All operations and data within a class
should naturally “belong” to the concept
the class models.
 Classes with high cohesion can often be
described by a simple sentence.

September 20, 2001 Software Architecture and Design 19

Types of cohesion

 Coincidental : No meaningful relationship amongst

elements of a class. May occur when a program is
“modularized” by chopping it into pieces and making
each piece a module.
 Logical cohesion : Elements of a class perform one kind
of a logical function, e.g. interfacing with the Point of
Sale terminal hardware.
 Temporal cohesion : All elements of a class are
executed “together”.
 Was NATO cohesive during its operations in the 90’s?

September 20, 2001 Software Architecture and Design 20

Design Patterns [1]

 A solution to a problem that occurs repeatedly in a

variety of contexts.

 Each pattern has a name.

 Use of each pattern has consequences.

September 20, 2001 Software Architecture and Design 21

Design Patterns [2]

 Generally at a “higher level” of abstraction.

 Not about designs such as linked lists or hash tables.

 Generally descriptions of communicating objects and classes.

September 20, 2001 Software Architecture and Design 22

Observer Pattern [1]
 Need to separate presentational aspects with the data, i.e. separate
views and data.

 Classes defining application data and presentation can be

reused.

 Change in one view automatically reflected in other

views. Also, change in the application data is reflected in
all views.

 Defines one-to-many dependency amongst objects so that when

one object changes its state, all its dependents are notified.

September 20, 2001 Software Architecture and Design 23

Observer Pattern [2]

Relative Percentages
A B C D
A
X 15 35 35 15 D
Y 10 40 30 20 B
C
Z 10 40 30 20
A B C D

A=10%
B=40%
C=30% Application data
Change notification
D=20%
Requests, modifications
September 20, 2001 Software Architecture and Design 24
Observer Pattern [3]
observers
Subject Observer

attach (Observer) Update()

detach (Observer)
For all x in observers{
Notify () x  Update(); }

Concrete Observer
subject
Concrete Subject Update()

GetState() observerState
SetState()
observerState=
subjectState subject  getState();
September 20, 2001 Software Architecture and Design 25
Class collaboration in Observer

:ConcreteSubject :ConcreteObserver-1 :ConcreteObserver-2

SetState()
Notify()

Update()

GetState()

Update()

GetState()

September 20, 2001 Software Architecture and Design 26

Observer Pattern: Observer code

class Subject;

class observer { Abstract class defining

public: the Observer interface.
virtual ~observer;

virtual void Update (Subject* theChangedSubject)=0;

protected:

observer ();

};
Note the support for multiple subjects.

September 20, 2001 Software Architecture and Design 27

Observer Pattern: Subject Code [1]

class Subject {
Abstract class defining
public:
the Subject interface.
virtual ~Subject;

virtual void Attach (observer*);

virtual void Detach (observer*) ;
virtual void Notify();

protected:
Subject ();

private:
List <Observer*> *_observers;

};
September 20, 2001 Software Architecture and Design 28
Observer Pattern: Subject Code [2]

void Subject :: Attach (Observer* o){

_observers -> Append(o);
}
void Subject :: Detach (Observer* o){
_observers -> Remove(o);

}
void Subject :: Notify (){
ListIterator<Observer*> iter(_observers);
for ( iter.First(); !iter.IsDone(); iter.Next()) {
iter.CurrentItem() -> Update(this);

}
September 20, 2001 Software Architecture and Design 29
Observer Pattern: A Concrete Subject [1]

class ClockTimer : public Subject {

public:
ClockTimer();

virtual int GetHour();

virtual int GetMinutes();

virtual int GetSecond();

void Tick ();

September 20, 2001 Software Architecture and Design 30

Observer Pattern: A Concrete Subject [2]

ClockTimer :: Tick {

// Update internal time keeping state.

// gets called on regular intervals by an internal timer.

Notify();

September 20, 2001 Software Architecture and Design 31

Observer Pattern: A Concrete Observer [1]

class DigitalClock: public Widget, public Observer {

public:
DigitalClock(ClockTimer*);
virtual ~DigitalClock();
Override Observer operation.
virtual void Update(Subject*);
virtual void Draw();
Override Widget operation.
private:
ClockTimer* _subject;

September 20, 2001 Software Architecture and Design 32

Observer Pattern: A Concrete Observer [2]

DigitalClock ::DigitalClock (ClockTimer* s) {

_subject = s;

_subjectAttach(this);

DigitalClock ::~DigitalClock() {
_subject->Detach(this);

September 20, 2001 Software Architecture and Design 33

Observer Pattern: A Concrete Observer [3]

void DigitalClock ::Update (subject* theChangedSubject ) {

If (theChangedSubject == _subject) {

Draw();
}
} Check if this is the clock’s subject.

void DigitalClock ::Draw () {

int hour = _subject->GetHour();

int minute = _subject->GeMinute(); // etc.

// Code for drawing the digital clock.

}
September 20, 2001 Software Architecture and Design 34
Observer Pattern: Main (skeleton)

ClockTimer* timer = new ClockTimer;

DigitalClock* digitalClock = new DigitalClock (timer);

September 20, 2001 Software Architecture and Design 35

When to use the Observer Pattern?

 When an abstraction has two aspects: one dependent

on the other. Encapsulating these aspects in separate
objects allows one to vary and reuse them
independently.

 When a change to one object requires changing others

and the number of objects to be changed is not known.

 When an object should be able to notify others without

knowing who they are. Avoid tight coupling between
objects.

September 20, 2001 Software Architecture and Design 36

Observer Pattern: Consequences

 Abstract coupling between subject and observer.

Subject has no knowledge of concrete observer classes.
(What design principle is used?)

 Support for broadcast communication. A subject need

not specify the receivers; all interested objects receive
the notification.
 Unexpected updates: Observers need not be concerned
about when then updates are to occur. They are not
concerned about each other’s presence. In some cases
this may lead to unwanted updates.
September 20, 2001 Software Architecture and Design 37
 Summary

1. What is design?

2. What is architecture?

3. Where does design fit in a development process?

4. What are the general principles of design ?

Reference for the Observer Pattern:

Design patterns by Gamma et al., 1995, Chapter 5,
Or read pp. 372-380 from Larman’s book or section 3.2.2.1 of Braude’s book.
September 20, 2001 Software Architecture and Design 38