CHAPTER 3

DEVELOPMENT OF SOFTWARE
ARCHITECTURE

5GL - 2017 / 2018

LEARNING OBJECTIVES
 Select and adhere to approaches and heuristics for
architecture development.
 Design architecture.
 Identify and rank influencing factors upon software
architecture.
 Describe, explain and appropriately use important
architectural patterns.
 Explain and use design principles.
 Design building blocks / structural elements of software
architecture.
 Design and define interfaces.
 Understand and use architecture-relevant design
patterns. 2
OUTLINE
 Development process of architectures
 Design principles and heuristics

 Design techniques

 Design patterns

 Architectural patterns

3
 DEVELOPMENT PROCESS OF
ARCHITECTURES
4
ITERATIVE DEVELOPMENT OF
ARCHITECTURE

5
ITERATIVE DEVELOPMENT OF
ARCHITECTURE

 Architectures, organizations and systems

influence each other.
 Customers and Stakeholders can change the
requirements and influencing factors.
 Architecture design and decisions should
be modified iteratively.
 Prevent problems early in the design.
 Consider requirements earlier.

6
PROCESS OVERVIEW

7
FIRST STEP – COLLECT INFORMATION

8
FIRST STEP – COLLECT INFORMATION
 Acquire required domain knowledge and
technical background for the project.
 Identify existing systems in the organization
and verify the reusability.
 Identify systems offered by third parties, which
perform the similar task or at least a part of
it, such as the system to be developed.
 Study appropriate technical literature needed
for solution approaches and process models.

9
SYSTEM CONCEPTS
 What is the core task of the system?
 The main task and responsibility of a system are
described in a few words with reference to the most
important concepts and aspects of the business
domain.

 What is the type of the system?

 Exp.: Interactive online system, Embedded system,
etc.

 What is the type of the system’s control?

10
 Exp.: Event driven, Rule based, etc.
STEP 2 – CLARIFY REQUIREMENTS AND
INFLUENCING FACTORS

11
INFLUENCING FACTORS AND CONSTRAINTS
 Organizational / political
 Technical

 Functional properties (required features)

 Non-functional properties (required constraints)

12
ORGANIZATIONAL FACTORS

13
TECHNICAL FACTORS

 Programming guidelines.  Availability of runtime

 System operation. environment.
 Data structures.  Programming interfaces.
 Reference architectures.  Graphical user interface.
 Libraries, frameworks and  Technical communication.
components.  Programming language.
 Analysis and design  Hardware infrastructure.
model.  Software infrastructure.

14
STEP 3 – INDENTIFY RISKS

15
TYPICAL RISKS

 Limited availability of  Inadequate requirements.

resources.  High rate of change of
 Limited suitability of requirements.
resources.  Lack of documentation.
 Limited availability of  Ambiguity.
expertise.
 Contradictions.
 New, untested products.
 Lack of prioritization.
 Critical external
 Tight schedule.
interfaces.
 Availibility of technical
infrastructure. 16
STRATEGIES FOR ORGANIZATIONAL RISKS
 Cooperation with project management in
organizational problems (time, budget, know-how)
 Provide information to risk management in-time and
openly:
 Prepare alternative work planning in order to meet
deadlines
 Clarify effects of critical requirements and negotiate or
redefine them if necessary
 Prioritization
 Cost
 Quality

 Reconsider decision 17
 DESIGN PRINCIPLES &
HEURISTICS
18
STEP 4 – DESIGN STRUCTURE AND
TECHNICAL CONCEPTS

19
PRINCIPLES OF DECOMPOSITION
 Design in iterations.
 Consider alternatives to the obvious approaches.

 Consider all point of views.

 Identify and assess strengts and weaknesses.

 Independent elements.

 Encapsulate and seperate responsibilities.

 Reuse of established and proven structures.

20
DECOMPOSITION APPROACHES

 Both process models are complementary to each

other.
21
TOP-DOWN
Advantages Disadvantages

Good understanding of the Critical integrations at the end

problems
Machine and language Overlooking existing (partial)
independent solutions
Not “get lost” in details Late detection of problems may
cause serious design changes
Clean Interfaces

Design still visible in Product

22
BOTTOM-UP
Advantages Disadvantages

High rate of reusability Begins with suspected sub

problems
High reliability through Focus on technical aspects
incremental test rather than on user
requirements
Gradual integration Risk of premature optimization

"Wild grown" system structure

23
DIVIDE AND IMPERA
 The task on hand will be decomposed into
smaller subtasks until the complexity of these
tasks is manageable.

 Horizontal decomposition in layers

 Offer clearly defined interfaces.
 Use services of underlying layers.

 Vertical decomposition in functional module

 Decomposition criteria can be functional or technical
24
INFORMATION HIDING
 Developed by David L. Parnas in 1972
 Encapsulate the complexity in components
 Increases the flexibility
 Improved testability, stability and flexibility

 Components are considered as “Black box”

 Prevention of direct access to the internal data
structure
 Access only via defined interfaces

 Neglection of encapsulation leads to

 Unwanted and difficult dependencies
 Higher complexity
25
AS-SIMPLE-AS-POSSIBLE PRINCIPLE
Make things as simple as possible - but not
simpler.
Albert Einstein

 Simplicity effects:

 Facilitate the understandability.

 Prevent the problem hiding with excessive
complexity.

26
USAGE OF INTERFACES
The most important aspects of the architecture
are interfaces and relationships between the
components

 Interfaces are the basis for the overall system:

 Relationships are the added value of the system
 Link between the specialized components
 Allow to control complex network of subsystem
 Link to the outside world

27
 DESIGN TECHNIQUES
(HANDLING DEPENDENCIES)
28
HANDLING DEPENDENCIES :
PROBLEMATIC
 Too much dependencies = degenerated
design

 Changes in one place cause unexpected errors in

other locations  Fragility

 Modifications are difficult (number of dependent

components)  Rigidity

 Components can not be reused separately (too much

dependencies)  Poor reuse
29
HANDLING DEPENDENCIES:
RECOMMENDATIONS
 Apply OO technics:

 GRASP (General Responsibilty Assignement

Patterns)

 SOLID (Single Responsibility, Open-Closed Principle,

Liskov Substitution, Interface Segregation,
Dependency Inversion)

 Others OO technics.

30
LOOSE COUPLING
We should construct dependencies in design in such a way
that the future changes produce no new dependencies.

Gernot Starke

 Two loosely coupled building blocks:

 Can interact, but they may know very little about each other.
 The degree of dependence for the involved classes is as low as
possible.
 Coupling refers to the degree to which one object requires
other objects for its construction or operations.
 Loose coupling promotes flexibility and reusability. 31
LOOSE COUPLING – EXAMPLE (DEGREES
OF COUPLING)

Tight coupling
(Subclassing) Abstract ("Looser") coupling

extends

composition

Loose coupling

aggregation 32
HIGH COHESION
 The higher the cohesion, the more interrelated is the
responsibility of a class in the application.

 Cohesive packages accommodate classes of a

interrelated complex function.

 A cohesive class:
 Solves one problem.
 Has a specific amount of strongly related functionalities.

33
HIGH COHESION

High cohesion

Low cohesion

34
SINGLE-RESPONSIBILITY PRINCIPLE

A class should have one and only one reason to

change, meaning that a class should have only
one job.

 Too many responsibilities on a single class can

cause problems Responsibilities
assignement .
 Overload : A class is doing things which it is not
supposed to do.
35
OPEN-CLOSED PRINCIPLE
Software components should be open for
extension but closed for modification.
Bertrand Meyer

 Reduces the impact of changes

Open for extensions Closed for modification

Extension occurs in derived Implementations once

components completed are unchangeable

Derived blocks contain only the Requires definition of

extensions extension points 36
 DEPENDENCY ONLY FROM ABSTRACTIONS

Allow dependencies only from abstractions,

not from concrete implementations.
Gernot Starke

 Prohibiting direct dependencies allows interchangeability

of building blocks
Implementation of the Open-Closed Principle
Key to flexible and extensible architectures

37
 LISKOV SUBSTITUTION PRINCIPLE

Subtypes must be used instead of their super types.

Barbara Liskov

 One derived class should:

 Be used wherever its superclass is used.
 Behave exactly as the upper class, if it is used as such.

38
INTERFACES SEGREGATION
Several specific interfaces are better than a
large universal interface.
Gernot Starke

 Decomposition into individual interfaces reduces number

of dependent users and thus follow-up changes.

 Many client-specific interfaces are better than one general-

purpose interface.

 Small and focused interfaces are easier to implement.

39

 Resolve dependencies through interfaces

DEPENDENCY INVERSION
Modules in higher levels should not depend
on modules of lower levels. Both should
depend on abstractions.
Abstractions should not depend on details.
Details should depend on abstractions.

 Decoupling software modules.

 Inversion of Control.
 Hollywood Principle: “Don’t call us, we’ll call you”
 Dependency Injection.
 Application of the Inversion of Control principle
40
RESOLVE CYCLIC DEPENDENCIES
 Cyclic dependencies prevent separated reuse

 Separate the parts from A, which are used by C,

as Abstraction CA
 Dissolving done by inheritance relation from A to
41
CA
USEFUL PRACTICES
 Favor composition over inheritance.
 In particular, across a package boundary.

 Expose fields and methods when necessary.

 Dependency only from abstraction

 Refer to object instances by their interfaces.

 Be conservative when defining an interface.

 Adding an operation is plausible; removing one is not.

 Make concrete classes final.

 Unless the reasons for extending them are clear and
documented. 42
 PATTERNS
43
APPLYING PATTERNS
 It is not efficient to solve every problem afresh.

 Problems should be solved in the same way

as those that have been solved successfully.
 The general idea of reusing proven concepts is
called heuristics.
 Heuristics that are sufficiently well known and
documented become patterns.
 A pattern-based partial implementation
characterizes a typical framework.

44
ADVANTAGES OF USE OF PATTERNS

45
COMMON PATTERNS CATALOGS

 Hardware Configuration Patterns

 Software Design Patterns

 The GOF patterns
 Java EE Patterns
 Etc.

 Architectural Patterns

46
 DESIGN PATTERN
47
WHAT DESIGN PATTERNS DO
 Design patterns address two general concerns:

 Name basic forms for addressing common

software problems.

 Document these forms by criteria that may

include:
 A problem statement
 A list of forces that constrain a solution

 A solution that defines class roles and participants

 A list of strategies for well-known variations

 Any consequences or trade-offs that the solution imposes

 Mention of similar or related patterns 48

 GANG OF FOUR (GOF) CATEGORIES
Creational Structural Behavioral

Goal Solutions to classes’ instantiating Solutions to classes structuring , Solutions to objects’

problems abstraction and reuse problems communication and
algorithmic problems
Instanciation process abstraction Classes and objects composition for
more complex structures
Objects creation without creational
logic knwowing
Motivation More flexible programs Define ways to compose objects in order Responsabilities distribution
to get new functionalities
Decide wich object to create for a Define object roles and
particular use case Form complex structures or consolidate responsibilities
interfaces
Separete the creation process from
the constructor
Examples Abstract Factory Adapter Chain of Responsability
Builder Bridge Command
Factory Method Composite Interpreter
Prototype Decorator Iterator
Singleton Facade Mediator
Flyweight Memento
Proxy Observer
49
State
Strategy
Template Method
Visitor
 ABSTRACT FACTORY
50 Creational GOF’s pattern
ABSTRACT FACTORY PATTERN:
PRESENTATION
 Intent:
 Provide an interface for creating families of related or
dependent objects without specifying their concrete
classes.

 Motivation:
 A system should be independent of how its products
are created, composed, and represented.
 A system should be configured with one of multiple
families of products.
 Providing a class library of products by revealing just
their interfaces, not their implementations. 51
ABSTRACT FACTORY PATTERN:
STRUCTURE

52
 ABSTRACT FACTORY PATTERN:
EXAMPLE SOLUTION Abstract
Products
Abstract
Factory

Concrete Concrete
factories products
53
ABSTRACT FACTORY PATTERN:
SYNTHESIS
 Problems:
 Create families of related or dependent objects
without specifying their concrete classes.
 Hide the concrete product classes from the client.

 Advantage:
 Provide different kinds of objects through a single
interface.
 Clients are independent of implementation.

54
 PROTOTYPE
55 Creational GOF’s pattern
PROTOTYPE PATTERN:
PRESENTATION
 Intent:
 Specify the kinds of objects to create using a
prototypical instance, and create new objects by
copying this prototype.

 Motivation:
 A system should be independent of how its products
are created, composed, and represented.
 The classes to instantiate are specified at run-time,
for example, by dynamic loading.

56
PROTOTYPE PATTERN:
STRUCTURE

57
PROTOTYPE PATTERN:
EXAMPLE SOLUTION Prototype

Client

Concrete
prototypes
58
PROTOTYPE PATTERN:
SYNTHESIS
 Problems:
 Hide the concrete product classes from the client.
 Instances of a class can have one of only a few
different combinations of state.
 Avoid building a class hierarchy of factories that
parallels the class hierarchy of products.
 Specifying instantiated classes at runtime.

 Advantage:
 Provide new objects by copying an example rather
than producing uninitialized new instances of a class.
59
 FACADE
60 Structural GOF’s pattern
FACADE PATTERN:
PRESENTATION
 Intent:
 Provide a unified interface to a set of interfaces in a
subsystem. Facade defines a higher-level interface
that makes subsystem easier to use.
 Motivation:

61
FACADE PATTERN:
STRUCTURE

62
FACADE PATTERN:
EXAMPLE PROBLEM
 Client is coupled to many classes in the reservation
subsystem.

63
FACADE PATTERN:
EXAMPLE SOLUTION

64
FACADE PATTERN:
SYNTHESIS
 Problem: When a client directly links to many classes:
 It is vulnerable to changes in any of those classes.
 It must know each one’s interface.
 It must devise an order for calling operations and delegating
parameters to them.
 In a distributed environment, many fine-grained client calls can also
increase network overhead.
 Advantages:
 The client is decoupled from the subsystem components.
 The client does not have to know the underlying process.
 There are fewer network trips in a distributed environment.
 Clients can still communicate directly with the subsystems.
 Disadvantage:
 A layer of indirection obscures the underlying process. 65
 ADAPTER
66 Structural GOF’s pattern
ADAPTER PATTERN:
 Intent:
 Convert the interface of a class into another interface
clients expect. Adapter lets classes work together that
couldn't otherwise because of incompatible interfaces.

 Motivation:
Problem

Solution

67
ADAPTER PATTERN :
STRUCTURE

68
ADAPTER PATTERN:
EXAMPLE Adaptee
Target

Adapter
Client

69
ADAPTER PATTERN:
SYNTHESIS
 Problems:
 When using an existing class, and its interface does not
match the one you need.
 When creating a reusable class that cooperates with
unrelated or unforeseen classes, that is, classes that
don't necessarily have compatible interfaces.

 Advantages:
 Adapter as a bridge between two incompatible
interfaces.
 Joining functionalities of different interfaces through a
single class. 70
 STRATEGY
71 Behavioral GOF’s pattern
STRATEGY PATTERN:
PRESENTATION
 Intent:
 Define a family of algorithms, encapsulate each one,
and make them interchangeable. Strategy lets the
algorithm vary independently from clients that use it.

 Motivation:
 We need different variants of an algorithm.
 Replacing or adding algorithms requires code modification.
 A class defines many behaviors.
 Multiple conditional statements in its operations.

72
STRATEGY PATTERN:
STRUCTURE

73
STRATEGY PATTERN:
EXAMPLE PROBLEM

 A library system’s search method wants to use

multiple algorithms for sort results.
 Replacing or adding algorithms requires code
modification.

74
STRATEGY PATTERN:
EXAMPLE SOLUTION

75
STRATEGY PATTERN:
SYNTHESIS
 Problem:
 Classes often need to choose from multiple algorithms.
 The details of these algorithms should be hidden from client
classes.
 Separating choices by conditional logic is hard to maintain.

 Advantages:
 Adding new strategies doesn’t affect the existing code.
 Branch logic that can grow over time can be avoided.
 Each algorithm is expressed separately.
 Change to one algorithm is isolated from other algorithms.

 Disadvantage:
76
 Clients must know which strategies are available.
 OBSERVER
77 Behavioral GOF’s pattern
OBSERVER PATTERN:
PRESENTATION
 Intent :
 Define a one-to-many dependency between objects so
that when one object changes state, all its
dependents are notified and updated automatically.

 Motivation:

78
OBSERVER PATTERN:
STRUCTURE

79
OBSERVER PATTERN:
EXAMPLE PROBLEM
 The faulted() method delegates a message to services
that are coupled to the FaultMessageGenerator class.
 Other fault handlers may be needed.

80
OBSERVER PATTERN:
EXAMPLE SOLUTION

81
OBSERVER PATTERN:
SYNTHESIS

 Problem:
 Several classes want to monitor changes in another class:
 Synchronous polling for asynchronous state changes may waste
resources.
 Multiple observers polling an observable object may also require
synchronization controls.
 Observers must know how to get to an observable object.

 You want to add observers as needed.

 Advantages:
 Subjects and observers can be reused independently.
 Coupling is based on abstract type, not concrete type. 82

 The Observer list can be managed dynamically.

 ARCHITECTURAL PATTERNS
83
ARCHITECTURAL PATTERNS
 Describe overarching, recurring system structures.

 Describe less concrete form of individual components or

groups of classes.

 Offers pattern for:

 Approach for the decomposition of a system.
 Distribution of responsibilities within a system.

 Examples:
 MVC pattern.
 Layers pattern.
 Blackboard architecture pattern. 84
 Pipe and filter pattern.
 THE MVC PATTERN:
PRESENTATION

 Motivation:

 User interfaces and business logic change at different

rates:
 The model data must reflect the changes initiated from a view
immediately.
 The user interface must be loosely coupled to the data and logic.

 Some clients will support multiple interfaces:

 Display the same information in different views.
 Some views must be updated to reflect the changes in the model data.

85
 THE MVC PATTERN:
PRESENTATION
 Intent:
 Separates the concerns.

 Divides the system into three areas:

 Controller: Accepts user requests, invokes processing on the Model

components, and determines which View component should be
displayed.

 View: Displays a GUI with the Model component data. It may also
pass GUI-driven events to the Controller components.

 Model: Contains business data, processing and rules. It is unaware

86
of any user interface type.
THE MVC PATTERN:
PRESENTATION

 MVC is a widely known development metaphor.

 It is useful as a general example for separating

concerns.
 Delegates command requests.
 Uses event notification for flexible communication.

 It is a compound pattern consisting of the

Observer, Strategy and Composite patterns.

87
THE MVC PATTERN:
STRUCTURE
Model
• Encapsulates application state
• Responds to state queries
• Exposes application functionality
• Notifies views of changes
State State
Query Change

Change
Notification

View View Selection Controller

• Renders the models • Defines application behavior
• Requests updates from models • Maps user actions to model
• Sends user gestures to controller updates
• Allows controller to select view • Selects view for response
User Gestures
• One for each functionality

Method Invocations 88
Events
THE MVC MODEL:
KNOWN USES
 Interactive systems.

 It is a well-known approach for UI-centric

frameworks:
 Swing.
 Struts.
 Etc.

89
THE MVC PATTERN:
HOW DOES IT WORK?

90
THE MVC PATTERN:
HOW DOES IT WORK?

91
THE MVC PATTERN:
HOW DOES IT WORK?

92
APPLYING THE MVC PATTERN:
EXAMPLE PROBLEM

 Hotel clerks need to access reservation information and

check guests in without a browser-based system.

 You need to divide the system into parts so that:

 The user interface can progress independently from the
business logic.
 The web-based reservation system and other user interfaces can

access the same business logic.

93
APPLYING THE MVC PATTERN: EXAMPLE
SOLUTION

94
APPLYING THE MVC PATTERN:
BENEFITS & LIABILITIES
 Benefits:
 Multiple views offer simple or detailed perspectives.
 It is easier to modify the Model, View, and Controller
components separately.
 Some developers specialize on the UI, whereas others
specialize on the model.

 Liabilities:
 A very simple implementation of subsystems may
greatly increase the communication overhead (large
number of listeners).
95
THE LAYERS PATTERN:
PRESENTATION
 Motivation:
 When system has different levels of abstraction.
 When requests go down and notification goes back
up.
 When needing to change or add layers over time.

 Intent :
 Helps establish logical tiers and technology layers.
 Defines and enforces abstraction boundaries.

96
THE LAYERS PATTERN:
PRESENTATION
 Structures the system on the base of services offered
by underlying layers.
 Abstraction increases with the number of underlying
layers.
 Service usage only takes place directly between
successive layers.
 Service usage is directed from upper to lower layer
(communication is in both ways).
 A layer « j » can use service of j-1, j-2, etc.
 The reverse direction or access through an
intermediate layer should be allowed only in
97
exceptional cases.
THE LAYERS PATTERN:
STRUCTURE

98
THE LAYERS PATTERN:
KNOWN USES
 Virtual Machines.
 APIs.

 Information systems.

 Some operating systems – Windows NT.

99
LAYERS AND COMPONENTS

100
THE LAYERS PATTERN:
EXAMPLE

101
THE LAYERS PATTERN:
BENEFITS

 Layers are independent:

 In the development (distribution of tasks).
 In operation (installation, maintenance).

 Reuse of layers.

 Reduces the amount of possible dependencies between

components.

 Exchangeabilities:
 Replacement of old implementation with Adapter Pattern.
 Dynamic exchange with Bridge Pattern. 102
THE LAYERS PATTERN:
LIABILITIES
 Cascades of changing behavior.

 Lower efficiency.

 Unnecessary work: functions of a layer called many

times for one service.

 Difficulty of establishing correct granularity of

layers:
 Too few layers: less benefits.
 Too many layers: complexity and overhead. 103