Software Architect

Introduction to
Software Architecture
and Design
Cesare Pautasso
http://www.pautasso.info
Spring Semester 2009
17.2.2009 Software Architecture and Design 9
©2009 Cesare Pautasso
Contents
• Architecture 101
• When do you need an Architect?
• Why do we need Software Architecture?
• Architecture within the Software Development
Process
• Course Overview


De Architectura
firmitatis utilitatis venustatis
• Durability:
the building should last for a long time without falling down on
the people inside it
• Utility:
the building should be useful for the people living in it
• Beauty:
the building should look good and raise the spirits of its
inhabitants
Vitruvio, De Architectura, 23BC

Architecture
The Art and Science of Building
• Architects are not concerned with the creation of
building technologies and materials—making glass
with better thermal qualities or stronger concrete.
• Architects are concerned with how building materials
can be put together in desirable ways to achieve a
building suited to its purpose.
• The design process that assembles the parts into a
useful, pleasing (hopefully) and cost-effective
(sometime) whole that is called “architecture”.

Architecting, the
planning and
building of
structures, is as old
as human societies
– and as modern as
the exploration of
the solar system
Eberhardt Rechtin
1991
When do you need
an architect?
It depends what you are trying to build…

Small
One person can do it alone with:

Minimal modeling
Simple process
Simple tools

Medium
Better to build a house as a team using some:

Modeling plans
Well-defined process
Power tools
Large
You definitely
need an
architect for
planning a
skyscraper!

How large?
• Always choose the tools and design strategy
appropriate for the size of the project you're
working on

How large?
• How much time to build it?
• How many people in the project?
• How much did it cost?
• Hard to measure software size:

– Estimate the “lines of code” (LOC)
– Measure the deployment size (GB)

How large?
Name Size Time
Indusha 4-5 People (Java) 1 semester
Luca 2 People (C++, 4k LOC) 2 months
Athos 4 People (C, Hardware) 1 year
Alan 4 People (PHP, ~100 “pages”) 3 years
Andrea 1 Person (Bachelor Prj, PHP 40- 2.5 months
50 files)
Alessio 15-20 People (Wiki, Ruby, 1 semester
Atelier Project, 50 Ruby Files)
Labinot 5 People (C#, 70-80 classes) 8 months
Alessio G. 1 Person (Tapestry, Java5, 50 6 months
classes)
Danilo A. Robots (C++/Java/C, 30 big 6 months
classes)

Large Software Project
• Lines of code: 50 Million
• Number of developers: 2000
• Time to compile: 24 hours
• Time to ship: 5 years (from previous release)
Millions of LOC
60
40
20
0
17.2.2009 1990Software
1995Architecture2000
and Design 2005 2010 28
As the size and complexity of a
software system increase, the
design decisions and the global
structure of a system become
more important than the
selection of specific algorithms
and data structures.

Context
• Software Engineering
• Programming Languages How to build
• Algorithms and Complexity components
from scratch
• Databases
• Software Architecture
How to design large systems
• Component-based out of reusable components
Software Engineering

Why SW Architecture?
1. Manage complexity of large software projects through
abstraction
2. Communicate, remember and share global design decisions
among the team
3. Visualize and represent relevant aspects (structure,
behavior, deployment, …) of a software system
4. Understand, predict and control how the design impacts
quality attributes of a system
5. Define a flexible foundation for the maintenance and future
evolution of the system

Abstraction
• The hard part is to know which details to leave

out and which should be emphasized
Representation
From Grady Booch

Quality Attributes
Functionality
Cost/Schedule Compatibility
Ease of support Reliability/Availability

Testability Security
Usability Fail safe/Fault tolerance
Performance
Adapted From Grady Booch

Integration
Scalability Customizability
Portability Resilience/Maintainability
Technology churn

Future Evolution
From Stewart Brands

Course Overview

• Defining Software Architecture: Basic Concepts
• System Decomposition vs. Software Composition
• Architectural Views: Logical, Physical, Process, Development;
• Design Principles: Simplicity, Abstraction, Separation of Concerns,
Encapsulation, Information Hiding
• Patterns and Anti-Patterns: Avoiding Common Design Mistakes
• Component Models
•
•
Composition Techniques
Architectural Styles
Lab
• Modeling Architectures: Architectural Description Languages
• Visualization of Architectures
• Evaluating Quality Attributes and Non-Functional Properties
• Architectural Decision Modeling
• API Design Techniques
Subject to change
It is all in
my head!

References
• Eberhardt Rechtin, Systems Architecting: Creating
and Building Complex Systems, Prentice Hall 1991
• Henry Petroski, Small Things Considered: Why There
Is No Perfect Design, Vintage, 2004
• Ian Gordon, Essential Software Architecture,
Springer 2004
• Christopher Alexander, The Timeless Way of Building,
Oxford University Press 1979
• Stewart Brand, How Buildings Learn, Penguin 1987
• Grady Booch, Handbook of Software Architecture,
http://booch.com/architecture/
Defining
Prof. Cesare Pautasso

Contents
• The role of the Software Architect
• Architecture and the Software Development
Cycle
• Defining Software Architecture
– Prescriptive vs. Descriptive Architecture
– Architectural Degradation: Drift and Erosion
– M-Architecture vs. T-Architecture
– Solution vs. Product
Who is a software architect?

• William (Bill) H. Gates,
Chief Software Architect, Microsoft
(until June 2006)

IT Architect Job Ad
Wir bieten: Sie bieten
• Mitarbeit in der Definition der Targets für die • Fach- oder Hochschulabschluss
NextGen Architecture Platform für IT Core Banking (Wirtschaftsinformatik/Informatik)
Solutions & Services • Mind. 5 Jahre Erfahrung in der IT Architektur (Applikation-
• Unterstützung bei der Planung und der Erstellung von und Technologie-Architektur) und der Software-
Dokumentationen, Leitfaden und Entwicklung in einem Grossunternehmen im
Konzeptbeschreibungen für die definierten IT & Finanzdienstleistungsbereich
Platform Architecture Standards • Fundierte Kenntnisse im Host-Bereich und in den
• Unterstützung in der Kommunikation der IT & entsprechenden Technologien wie z.Bsp. PL1, J2E, SOA
Platform Architecture Standards an Interessenten (CORBA, WebServices) und High-Volume
• Koordination der Projektarbeit mit Projekt Transaktionssysteme sowie in der Datenmodellierung
Mitarbeitern und im Reengineering
• Unterstützung des Head of Architecture Officer in den • Verhandlungssichere Kommunikation in Deutsch und
Koordinations- und Kontrollaufgaben betreffend der Englisch
Umsetzung der IT & Platform Architecture Standards
sowie in den ScoreCard Rapportierungen
• Schnittstellenfunktion zwischen den verschiedenen
Architekturschnittstellen und Interessenten
Posted 18.2.2008, CS Zurich

• Enge Zusammenarbeit mit den entsprechenden
Stakeholdern inklusive projektrelevanten Gremien

IT Director
Programme Manager
24.2.2009
IT Manager
Project Manager
Solutions Architect
Business Analyst
Development Manager
VB Developer
VBA / ExceI / Access Developer
VC++/C++ Developer
Java Developer
Net Specialist
C# Specialist
Database Developer
Database Administrator
Network Manager

System / Support Analyst
Software Architecture and Design

Support / Helpdesk Manager
3rd Line Technical Support
Trade Floor Support
1st / 2nd Line Support Analyst
Helpdesk Analyst (24x7)
IT Trainer
Security Manager
Senior Security Consultant / Architect

Value of the Architect
Security Consultant
7
From Michael Page Intl

Customers
Marketing Analyst
Model the
problem Define
Requirements
Measure
Performance
Architect & Design Architect
IT Operations
Product Manager
Manager Manage
Manage Change
Program Modeler
Code
Deploy
Application Test
Support
Helpdesk
Developer
Operations Deployment Tester - QA Development

Role of the Architect
1. Software Engineering Lead
– Excellent software engineering skills
– Lead technical development team by example
– Solve the hard problems
– Understand impact of decisions
– Defend architectural design decisions
– Promote good development practices
– Plan and manage software releases

Role of the architect
2. Facilitate Communication

3. Technology Expert
– Know and understand relevant technology
– Evaluate and influence the choice of 3rd party
frameworks, component and platforms
– Track technology development
– Know what you don’t know

4. Risk Management
– Estimate and evaluate risks associated with
design options and choices
– Document and manage risks, making the whole
team (incl. management) aware
– Prevent disasters from happening

Architect Soft Skills
Technical Leadership
• Creative problem solver • Charismatic and credible
• Practical/pragmatic • Committed, dedicated, passionate
• Insightful, Investigative • Know how to motivate teams
• Tolerant of ambiguity, willing to
backtrack, seek multiple solutions
• Good at working at an abstract level Organizational politics
• Able to see from and sell to
Consulting multiple viewpoints
• Committed to others’ success • Confident and articulate
Adapted from Bredemeyer.com

• Empathetic, approachable • Ambitious and driven
• An effective change agent, process • Patient and not
savvy
• Resilient
• A good mentor, teacher
• Sensitive to where the power is
• Visionary
and how it flows in an organization
• Entrepreneurial

and the Software

Development Lifecycle

Waterfall Model
1. Requirement Analysis
2. Design
Architecture
3. Implementation
4. Testing
5. Maintenance

Bridge the Gap
Problem Space Solution Space
Problem
Architecture Design
Definition
Data Models
Functional
Requirements
Code
Non-functional
Acceptance Tests
Requirements

Evolutionary Model
Software
concept
Preliminary Architecture
requirements
analysis
Design of
architecture and
system core
From John Reekie, Rohan McAdam

Develop
a version
Architectural decisions Incorporate Deliver a

version
are made early in customer
feedback
the development lifecycle Elicit
customer
feedback
System Lifecycle
Vision
Architectural decisions Inception

affect the whole lifetime
of a system Development
Deployment
Operation

Architecture Maintenance
Alteration
Legacy
operation
Death
Defining Software Architecture
Architecture is what architects do

Basic Definition
•A software system’s architecture is
the set of principal design decisions
made about the system.
Architecture = {Principal Design Decision}
•It is the blueprint for a software
From N. Taylor et al
system’s construction and evolution
Design Decisions
• Design decisions • Principal Design Decisions:
cover all aspects of – the “important ones”
the system:
depending on the goals of the
– Structure stakeholders
– Behavior
• Decisions are made over time
– Interaction
– Deployment • Decisions are changed over
– Non-functional time
properties • Decisions depend on other
– Implementation decisions

Prescriptive vs. Descriptive
Prescriptive Descriptive
Architecture Realization Architecture
Intent Recovery
System
Artifacts
Green Field Development
• At the beginning, systems designed and implemented

from scratch only have a prescriptive architecture
Architecture Architecture
System
Artifacts

Brown Field Development
• Systems developed reusing existing components

already have a descriptive architecture
(and may have an empty prescriptive architecture)
System
Artifacts

Architectural Degradation
P
D
P D
Ideal Case Realistic Case
• Ideal Case (P = D) • Not all P decisions can

• D always a perfect be implemented
realization of P • Over time, P and D
change independently
and drift apart
Causes of Architectural Drift
System
Intent Artifacts
Ad-hoc Changes
From Drift to Erosion
• Over time, decisions are added to D
P
P D P
D
D
• Drift: new D decisions do not violate P
• Erosion: D decisions violate P decisions
Solution vs. Product
• A solution architect • A product architect

solves the problems of designs one product
one customer by architecture that can
designing a solution solve the problems
architecture made of and satisfy all the
multiple products that requirements of
are integrated and multiple customers
reused as components
From O. Zimmermann
M-architecture, T-architecture
• Principal Design Decisions:
– the “important ones” depending on the goals of the stakeholders
• Marketing Architecture • Technical Architecture

• Describe how to market • Prescribe how to build
and sell (business deploy and configure the
model, licensing model) system (styles, patterns,
the system to customers components, connectors)
From L. Hohmann
The $10’000 Boolean Flag
• Marketing Architecture • Technical Architecture

• 4 Different Products: • For multiple “products”
there can be a single
technical architecture and
a single codebase.
• Simple configuration flags
can be used to switch
between the different
M-architectures perceived
by customers
Thursday Exercise
SI 006 – 8:30-10:30

References
• Richard N. Taylor, Nenad Medvidovic, Eric M.
Dashofy, Software Architecture: Foundations,
Theory and Practice, John-Wiley, January 2009
• Luke Hohmann, Beyond Software Architecture:
Creating and Sustaining Winning Solutions,
Addison-Wesley, February 2003
• Ian Gorton, Essential Software Architecture,
Springer, April 2006
• Grady Booch, Handbook of Software
Architecture, http://booch.com/architecture/
Software Components


Contents
• Components
– Defining Components
– Classifying Components
– Component Frameworks
– The Problem of Heterogeneity and Interoperability

Architecture
Interfaces
Purpose Design Plan (Decisions)
– Mediation
Customer Map:
Components
Requirements Function → Structure – Processing
Behavior – Data/State
Quality
Abstraction Connectors
Stakeholders Viewpoint – Communication
– Composition
– Collaboration

Hardware Component
• Reusable unit of composition
Made out of smaller
components
Can be composed
into larger systems

Software Component
• Locus of computation and state in a system
Processing
Provided Required
Interface Interface
State
Environment
Black Box
• Components only accessible
from the “outside”
• Encapsulation
– Separate the content from the
rest of the system
• Abstraction
– Hide implementation details
behind the interface
• Modularity
– Reusable unit of assembly
Transparent Boxes
• Black Box - Components only accessible through
its interface. Implementation is kept hidden.
• Glass box – Implementation can be inspected,
but not modified.
• Grey box – Implementation can be inspected,
but only limited modification is allowed
• White box – Implementation can be inspected
and modified completely

Recursive Components
• Components are meant
to be composed into
larger components
• Components (inside the
black box) are made of
components
• Software Architecture is
Fractal (up to a certain
point)

Distributed Components
• Components can be • Components can be
deployed on the same distributed over multiple
physical host physical hosts
OS

Kinds of Components
• User-Interface • Active (Passive)
• Realtime • Stateful (Stateless)

Invented by
Doug Mc Ilroy, MASS PRODUCED SOFTWARE COMPONENTS, NATO Conference on
Software Engineering, Garmisch, Germany, 7-11. October 1968
Software components (routines), to be widely applicable to
different machines and users, should be available in families
arranged according to precision, robustness, generality and
time-space performance. Existing sources of components -
manufacturers, software houses, users' groups and algorithm
collections - lack the breadth of interest or coherence of purpose
to assemble more than one or two members of such families, yet
software production in the large would be enormously helped by
the availability of spectra of high quality routines, quite as
mechanical design is abetted by the existence of families of
structural shapes, screws or resistors. The talk will examine the
kinds of variability necessary in software components, ways of
producing useful inventories, types of components that are ripe
for such standardization, and methods of instituting pilot
production. Spring Semester 2009
Component Quality
http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
• In 1996, the maiden flight of the • “data conversion from 64-bit
Ariane 5 rocket ended in disaster floating point to 16-bit signed
when the launcher went out of control integer value. The floating point
40s after take off. number which was converted had
• The problem was due to a reused a value greater than what could
component from a previous version of be represented by a 16-bit signed
the launcher (the Inertial Reference integer. This resulted in an
System - SRI) that failed because exception being thrown… ”
assumptions made when that • This “lack of protection of this
component was developed did not conversion which caused the SRI
hold for Ariane 5. computer to stop”
• The functionality that failed in this
component was not required in Ariane
5.
Always validate your
“trusted components”
Marketplaces

Example Components
• Application-specific • Infrastructure
– Directly involved in – Independent of a specific
implementing the application domain, address the
functionality of the needs of multiple classes of
system applications
– May be difficult to – Reusable, but may provide
reuse for other much more than what is
application domains necessary in one specific
application
Media Math GUI Web
Database
Player Library Toolkit Server
Component Frameworks
Provide common run-time infrastructure (persistence,
distribution, user interface, concurrency/transactions)
to support application-specific components
• Component deployed or
Framework
plugged into the container
Application-Specific
Application-Specific
Components
Components
• Components “hanging” from
Container the framework (e.g., by
inheritance from abstract
classes)
Classifying Frameworks
Distributed
Platform-Independent
Portability
Centralized Platform-Dependent
Specific Language Agnostic

What Component Frameworks
do you know?
Ruby on Rails, Eclipse (SWT, JFace, GEF)
AWT/Swing, OMG CORBA, Apache Struts
Microsoft MFC, COM, DCOM, ActiveX, .NET, WCF/WPF

Sun J2EE, Mozilla XPCOM,
GNOME Bonobo, KDE KParts, QT, OpenOffice UNO

Heterogeneity
Due to the lack of
interoperability
between existing
component frameworks,
it is not always possible
to build a system using
heterogeneous
components of different frameworks
Tomorrow LAB
Finish Architectural Style Reports
Come to the LAB to get
feedback/corrections
Thursday NO Exercise

Components, Services,
Interfaces and Connectors

Contents
• Components
– Abstraction Levels:
Objects, Components, Services
– Interoperability
– Interfaces
• Connectors
– Coupling Dimensions

CBSE Principles
Component Based Software Engineering
• Components are independent unit of deployment and
composition that should not interfere with each other
(but can explicitly require other components)
• Component as black boxes:
– Components communicate through well-defined
(and documented/standardized) public interfaces
– Implementation details are hidden behind the interface

Abstractions Levels
Web Services
Services XML
J2EE
Components .NET
Eclipse
Objects C++
Java
Eiffel
C#
Component vs. Objects
• Component • Object
– Encapsulate state and – Encapsulate state and
functionality functionality
– Coarse-grained – Fine-grained
– Reusable unit of composition – Identifiable unit of instantiation
– Well-defined (documented, – May not always provide a public
standardized) interface interface
contract with explicit – Hard to reuse by itself (lots of
dependencies dependencies to other objects)
– Architecture Element: – At run-time can “move” between
Implementation not components
important (Black Box) – Object-Oriented Programming
– High Quality Language Typing Construct

Components vs. Services
Example
Map Drawing Component
Map getMap(lat, long, zoom)
• (lat, long) centers the map on any

location on the planet Earth and zoom
can show details up to 1m precision
• What is the “size” of this component?

• How to deliver the component to
customers so that it can be included in
their own applications? 4 TB

Business Model
• How to sell a component? • How to sell a service?
– Component developers – Service providers can
charge on a per-deployment charge on a per-call basis:
basis: whenever a new client each time an existing client
downloads the component. interacts with a service by
– Component upgrades may be exchanging a new message.
sold separately to generate a – Service providers can
revenue stream charge a monthly/yearly
– Components can be licensed flat access fee
to be redistributed within – Services can be made
larger systems and available for free and
developers can demand providers can support them
royalties from the revenue of with advertising revenue
the final product
Technology
• To be used a component must: • To be used a service must:
– be packaged to be deployed – be published on the Web (once)
as part of some larger – advertise its description and
application system location to potential clients
across the Web so that they can
– fit with the existing access it using standard
framework used to develop protocols
the system • Like components, services can be
• There are many component reused, composed into larger
frameworks available for systems and (of course) they can be
building distributed systems found on the Web.
(e.g., J2EE, DCOM, .NET, • Unlike components, services do not
CORBA). have to be downloaded and
• The problem is: they are not deployed in order to be used by
clients. Instead, a client may
compatible (as an exercise try to discover and access their
use a .NET assembly to make an functionality by using standard
Eclipse plug-in and see what protocols (WSDL, SOAP, UDDI)
happens) based on XML standards.
Component Interoperability
• Due to lack of interoperability, it is not always possible to build
a system using heterogeneous components
Enterprise
Java DCOM
.NET
Beans Objects
Assemblies
Web Legacy
CORBA
Services COBOL
Objects
Programs
Interfaces
• Specify and document the
externally visible features
(or the public API) of the
component
• Operations
– Call functionality, modify state
• Information Hiding Principle:
• Properties always keep the
– Read visible state attributes implementation details
• Events secret (invisible from the
– “Call Backs” outside) and only access
• Dependencies them through the public
– What the component requires interface

Dependencies
• Which assumptions makes a component?
• A component can be reused if:
The required interface is satisfied
(by other components that provide it)
The platform is compatible
• Runtime Libraries/Framework
• Operating System/Device Drivers
• Hardware
The environment is setup correctly:
• Databases
• Configuration Files
• File System Directories

Interface Description
Languages (IDL) 00 s 20
1990s
1980s
WSDL
CORBA 1.0
DCOM
RPC IDL
MIDL
IDL
Java Interfaces
Interface Design Principles
• Explicit Interfaces • Few Interfaces
– Components always – Every component
communicate through communicates with as few
interfaces others as possible
• Uniform Access • Clear Interfaces
– Facilities managed by – Do not publish useless
a component are accessible to functionality (unless it is
its clients in the same way used by other components)
whether implemented by • Small Interface
computation or by storage.
– If two components
From Bertrand Meyer

communicate, they exchange
as little information as possible

Reusable Interfaces
• Usability vs. Generality • Legacy “Wrapping”
– A general interface helps to reuse – Existing system can be reused as
a component in many components by adding a standard
architectures interface that does not require to
– A general interface is more modify them (which can be very
complex and difficult to use in one expensive or impossible to do
architecture safely)
• Performance • Minimize Required Interface
– A general reusable component – Self-contained
may be less optimized and (zero dependencies) components
provide worse performance than a are most reusable
specific, non-reusable one
– For the same interface, there can
From Ian Sommerville

be multiple implementation
components optimized for
different hardware platforms

Connectors

Connector
Connectors enable
architects and
engineers to
assemble
heterogeneous
• Generic enabler of composition functionality,
developed at
Plug into different times, in
different locations,
matching by different
component organizations.
ports
Transfer signals
(data, control)
between ports

Software Connector
• A software connector is the architectural element
tasked with effecting and regulating interactions
among components
• A connector couples
two or more components
to perform transfer of data
and control
• Component interfaces
need to “match” to be
connected
Connector Examples
File Transfer Procedure Call

Remote Procedure Call
Shared Data Message Bus

24.3.2009
Events 18
Connector Examples
Linkage Stream
(Static/Dynamic)
Adapter
Arbitrator
Adapter
• Architectures may choose to • Mismatches:

reuse pre-existing – Naming
components that do not – Typing
always “fit” perfectly – Syntax/Structure
• Adapters help to connect – Granularity
mismatching interfaces – Interaction style
by doing the necessary – Semantics
conversion – Missing data/functionality
Wrapper
• Wrapping is a pattern to W A
reuse components with
incompatible interface
• The interface A is hidden
“inside” a component with
interface W implemented
with the Adapter connector

Tomorrow Lab
Thursday Exercise (SI 013)

Modeling Architectures

Contents
• Models of Architecture
• Modeling Process
• Multiple Views
– 4+1
• Quality of Models
• Modeling Techniques Overview

Capturing the Architecture
• Every system has an architecture
some architectures are made manifest and
visible, many others are not Architecture
• A system’s (descriptive) architecture
ultimately resides in its executable code
• Before a system is built, its (prescriptive)
architecture should be made explicit
• A system’s architecture may be visualized
and represented using models that are Code
somehow related to the code
(existing or to be written)
From Grady Booch

Why Modeling?
• Record decisions • Generate
– Which decisions? What level of detail? artifacts
– Document the architecture – With detailed
enough
• Communicate decisions models,
– Notations (Visualization) it is possible
– Different roles involved in the project to drive the
development
• Evaluate decisions of the code
– What is a good architectural model? from the
– Help to detect problems early model itself
• Evolve decisions
– Give constraints and a clear path to change the system

Definitions
•An architectural model is an artifact that
captures some or all of the design
decisions that comprise a system’s
architecture.
•Architectural modeling is the reification
and documentation of those design
From Richard Taylor et al.

decisions.

Abstraction and Interpretation
• The architecture models only some interesting aspects of a system
Abstraction Quality:
some information Model •Ambiguity
is intentionally •Accuracy
left out
•Precision
“Real”
Interpretation
System solve ambiguities
add missing
decisions

Modeling Process
1. What aspects of the architecture to model?
2. What is their importance for the project?
3. What is the goal of the model?
4. Select suitable notation and level of detail
5. Design good models
6. Use the models consistent with their goal

1. What to model?
• Static Architecture: • Design Process:
– Structural Decomposition – Rationale of decisions
– Interfaces – Stylistic Constraints
– Components – Dependencies on other
– Connectors projects
– Mapping to Code Artifacts – Team Organization
– Legal Constraints
• Dynamic Architecture:
– Behavior • Quality:
– Deployment – Non Functional
Properties
– Mapping to Hardware
– Testing
2. How much modeling?
• Scope of the model: • Target Audience:
– The architecture of the – Technical Developers
entire system – Marketing/Customers
– Parts of the system for – Management
different use cases
– The style of the system
(constrain the actual
architecture without
describing it)
• Add details to the
model only where they
are needed
Multiple Views
• There is too much information to model, we need
multiple views
Logical
View
Physical
“Real” View
System
Deployment
View
Multiple Views
• There is too much information to model, we need
multiple views
Logical
View
Physical
“Real” View
System
Deployment
View
Consistency Problem
• Views are not orthogonal and should not become
inconsistent
Logical
View
Physical
“Real” ! View
System
Deployment
View
What is a View?
• No single modeling • A view is a set of design
approach can capture the decisions related by
entire complexity of a common concerns
software architecture (the viewpoint)
• Various parts of the
architecture (or views) may View
have to be modeled with a
different:
– Notation
– Level of detail
Viewpoint
– Target Audience
System
4+1 View Model
Logical View Development View
Use Case Scenarios
From Philippe Kruchten

Process View Physical View

Logical View
Use Case Scenarios
• Decompose the system structure into software

components and connectors
• Map functionality/requirements/use cases
onto the components
• Concern: Functionality
• Target Audience: Developers and Users

Process View
Use Case Scenarios
• Model the dynamic aspects of the architecture:

– Which are the active components?
– Are there concurrent threads of control?
– Are there multiple distributed processes in the system?
– What is the behavior of (parts of) the system?
• Describe how processes/threads communicate
(e.g., RPC, Messaging connectors)

• Concern: Functionality, Performance
• Target Audience: Developers

Development View
Use Case Scenarios
• Static organization of the software code

artifacts (packages, modules, binaries…)
• A mapping between the logical view and the
code is also required
• Concern: Reuse, Portability, Build
• Target Audience: Developers

Physical View
Use Case Scenarios
• Define the hardware environment (nodes, hosts,

networks, storage, etc.) where the software will be
deployed
• Different hardware configurations may be used for
providing different qualities
• A Mapping between logical and physical entities is
also necessary (sometimes found in a separate
Deployment View)

• Concern: Performance, Scalability, Availability,
Reliability
• Target Audience: Operations
Scenarios
Use Case Scenarios
• The modeling elements of the 4 views are linked by

scenarios that show how they work together to fulfill
the use cases of the system
• The actual model of the architecture can be broken
down in scenarios, that are illustrated using the
notations of the 4 views
• Scenarios help to ensure that the architectural model
is complete with respect to requirements

• Scenarios can be prioritized to help driving the
development of the system
What is a good model?
We designed it with UML

therefore
it is a good architecture
• Improving the quality of a model is done by making

good design decisions and documenting those
decisions with adequate precision using the most
suitable notation (not the other way around).
Model Quality
• Ambiguity
– A model is ambiguous if it • Make sure your architecture is
leads to more than one accurate (a wrong or conflicting
interpretation architectural decision is a recipe
– Incomplete models can be for disaster)
ambiguous: different people • Sometimes you can even make it
will fill in the gaps in different complete (but it will be more
ways. expensive, so only do it for critical
aspects of the system)
• Accuracy • Precision helps, but/if you can
– A model is accurate if it is trust developers to add detail
correct, conforms to fact, or (avoid over-specifying and over-
deviates from correctness designing the architecture,
within acceptable limits. especially if the architecture is
• Precision inaccurate, adding details will not
fix it)
– A model is precise if it is
sharply exact or delimited.
Accuracy and Precision
Accurate but
Inaccurate imprecise
Imprecise

Very precise Accurate
but inaccurate and precise
Model-Driven Engineering
• MDE is a style of software development centered on modeling
• Design of systems is organized around a set of models and
model transformations to move within and between different
abstraction layers (e.g., code generation, reverse engineering)
Code only Code visualization Roundtrip engineering Model-centric Model only
Model Model Model Model
Code Code Code Code
From IBM Rational

“What is a model?” “The model “Let’s do some
“The code is “Code and
specifies design”
the model!” model coexist”
the code”

Unified Modeling Language
for Architects

Contents
• Modeling Techniques Overview
• Unified Modeling Language
– Component and Deployment Diagrams
– Interaction (Activity and Sequence) Diagrams
– Class Diagrams
– State Machine Diagrams
– Use Case Diagrams

How much modeling effort?
• All architecture is design,
but not all design is architecture Design
• Architecture focuses on significant
design decisions, decisions that
are both structurally and
behaviorally important as well as Architecture
those that have a lasting impact
on the performance, reliability,
cost, and resilience of the system
• Architecture involves the how and
the why, not just the what
From Grady Booch

Maturity of Modeling
Techniques
• Ideally, stakeholders and architects would simply be able to
select a mature notation that would cover their modeling
and analysis needs
• However, the reality is that there are not enough mature
notations currently available to make this possible.
Even if one were prepared to use several notations
simultaneously (and deal with the costs of managing
consistency among them), there will likely still be gaps
between what can be modeled and what stakeholders
need.

• This means that architects will not only have to invest in
modeling, but invest in developing the technologies they
use to model.
Modeling Techniques
• Natural Language
• PowerPoint
• Unified Modeling Language (UML)
• Architectural Description Languages (ADL)

Evaluation Criteria
What is it intended to model with the technique and what is it not intended
Scope and Purpose
to model?
Basic Elements What are the basic modeling elements and concepts?
Style Can the technique capture stylistic constraints? For what kind of styles?
Static and Dynamic Does the technique only support structural modeling or can also model
Aspects behavior?
To what extent can the model be changed to reflect changes as a system
Dynamic Modeling
executes?
Non-Functional Does the technique include explicit support for capturing or evaluating the
Aspects quality of the system
Ambiguity Are multiple interpretations of the model possible or disallowed?
Accuracy Can the correctness of the model be determined using the technique?
Precision Does the technique allow to refine the model to higher detail levels?
Viewpoints Can a model built using the technique be partitioned into multiple views?
Does the technique help to detect and deal with inconsistencies across
View Consistency
multiple views?
Natural Language,
PowerPoint
Evaluation

Text (Natural Language)
Scope and Purpose Describe all aspects of an architecture informally
Basic Elements Extensive vocabulary
Style Style can be captured through generalizations
Static and Dynamic Both
Aspects
Models can be manually rewritten but cannot be tied to the implementation
Dynamic Modeling
automatically
Non-Functional Can be described but not verified automatically
Aspects
Most ambiguous (predefined vocabularies and templates can help to reduce
Ambiguity
ambiguity)
Accuracy Checked with manual inspection
Precision Just add more text to add details
Viewpoints All viewpoints (treated in the same way)
View Consistency Checked with manual review

PowerPoint (Slideware)
Visualize all aspects of an architecture informally through arbitrary diagrams
Scope and Purpose
and text
Basic Elements Geometric shapes and lines, text, clip art, animations
Style Not supported
Static and Dynamic No semantics
Aspects
Dynamic Modeling No support
Non-Functional Informal decorations/text on diagrams
Aspects
Ambiguity Predefined shapes and templates can help to reduce ambiguity
Accuracy Checked with manual inspection
Precision How much information fits on one slide?
Viewpoints All viewpoints (no direct support)
View Consistency Checked with manual review

Unified Modeling Language
http://www.uml.org/

Evaluating UML
Originally focused on low-level object-oriented design, in version 2.0
Scope and Purpose
extended to model architectural-level decisions (13 diagram types).
Classes, Associations, States, Events, Transitions, Activities, Messages,
Basic Elements Components, Connectors, Ports, Lifelines, Frames, Actors, Use Cases,
Deployment Nodes, Constraints
Style Captured as OCL Constraints or Profiles
Static and Dynamic Static (Class, Package, Object, Component Diagram)
Aspects Dynamic (State, Activity, Sequence Diagrams)
Dynamic Modeling UML Models can be reverse engineered out of a running system
Non-Functionals Textual Annotations/Comments
UML does not have a strict semantics. Stereotypes, Profiles can be used to
Ambiguity
reduce ambiguity
Accuracy Basic Syntax (Well-formed) and OCL checking
Precision UML Diagrams can become very detailed and be used to generate code
Viewpoints Each kind of Diagram shows a different viewpoint
View Consistency Little support offered
UML Overview
• Unified • Object-oriented
Modeling • Multiple Views Support
Language • Target Programming
• Visual notation for Language Independent
specifying, constructing and • Unifies many existing
documenting structure and Object-Oriented Analysis and
behavior of software Design notations:
systems
– Booch Diagrams
• Standardized and – Rumbaugh’s OMT
maintained by the OMG – Jacobson’s OOSE
(Object Management – Jacobson’s Objectory
Group) – Harel’s Statecharts
• Current Version: 2.1.2 – …
(November 2007)
UML Goals
• Define an easy-to-learn and expressive,
“general purpose” visual modeling language
• Unify existing modeling notations
• Incorporate industry best practices
• Address contemporary software development issues
– scale, distribution, concurrency, model-driven engineering
• Provide flexibility for applying within different
software engineering processes
• Enable model interchange between tools

Logical
View
Multiple Views “Real”

Physical
View
System
Deployment
View
• UML supports 13
different kinds of
diagrams
• Each diagram groups
different types of design
decisions
Model of the System
• All diagrams together
should give a
“complete” view over
the model of the system
architecture
UML 2.0 Diagrams
Package Class
Composite
Diagram Diagram Activity
Structure
Diagram
Diagram
State Machine
Object Behavioral Diagram
Diagram Structural Diagrams
Diagrams
Use Case
Deployment Interaction Diagram
Diagram Diagrams

Component Timing
Diagram Diagram
Interaction Sequence
Communication
Overview Diagram
Diagram
SpringDiagram
Semester 2009
Structural Diagrams
• Object Diagrams – show run-time relationships between
object instances
• Class Diagrams – show the classes and their relationships
(inheritance, aggregation, association)
• Package Diagrams – modularize the model description
• Composite Structure – define the internal structure of classes
and components
• Component Diagrams – decompose the system into

components, show their interfaces, dependencies and
connections
• Deployment Diagrams – map components to the hardware
execution environments

Behavioral Diagrams
• Use Case Diagrams – interaction scenarios between system
and its environment/users
• Activity Diagrams – Flowcharts to model high level logic and
business processes
• State Machine Diagrams – Model run-time states and the
events that produce transitions between states
• Communication Diagrams – Show the interactions between a

set of elements
• Sequence Diagrams – Show the interactions between a set of
elements using swim-lanes
• Interaction Overview Diagrams – Activity+Sequence (connect
together multiple diagrams)
• Timing Diagrams – State+Sequence viewed over time
Component
and Deployment
Diagrams

Component Diagrams
Component
Provided
Interface
Required
Interface
• Substitutability = ability to transparently replace the content
(implementation) of a component, provided its provided and
required interface contracts are not modified
Deployment Diagrams
Node (Device, Execution Environment)
Component Artifact
Dependency
<<jdbc>> Network Connection

Deployment Diagrams
• Model the physical software architecture,
including: the hardware, the software installed
on it and the middleware providing the
communication between the various nodes of
the system
• Gives a static view of the run-time
configuration of processing nodes and the
components that run on them
• Trivial for monolithic, centralized systems
Activity and Sequence
Diagrams

Activity Diagrams
Customer Store Supplier
Initial
• Model complex Store Branch

Condition
Swimlane
interactions Search Role

within multiple Supplier
components Store Supplier
Order CheckAvail Out of stock
• Model high-level Branch
business Activity
processes Customer Customer

Store Confirm Cancel
• Concurrency
semantics Pay Final
Supplier
based on Order
Petri-Nets Customer
Parallel Customer Ship
Split
7.4.2009
Invoice 23
Sequence Diagrams
Participant
• Model concrete Customer Store Supplier

execution scenarios
highlighting the lifelines search Lifeline
of the participants
• Focus on interactionsFrame
order
checkAvail
represented by ordered
message exchanges. alt
• Frames are used to cancel
model optional
alternative, loop,
reference, parallel, confirm
invalid (neg), critical,
interaction fragments
pay Message
invoice order
ship
Class Diagrams

Class Diagrams
• Model the types of objects in the system and the relationships
between them
Multiplicity Basketball Player
-Name: String
-Height: Float
Class Name * -Weight: Float
Team employ
Class 1 + ballDribble()
- TeamName: String
Attributes + ballPass()
- NumberofPlayer: Integer
exercise + rebound()
Class Association + shoot()
Operations
Generalization
Guard Forward

Classes
• Most important building block of any object-oriented system
• Abstraction modeling the properties of a set of objects in the system
• Can be associated with other diagrams modeling their behavior
Team BasketballPlayer
Class Name
- TeamName: String - Name: String
- NumberofPlayer: Integer - Height: Float
- Weight: Float
+ ballDribble()
+ ballPass()
+ rebound()
+ shoot()
Attributes and Operations
• Attributes • Visibility:
– Model properties of the class – Private
Syntax: Name: Type + Public
• Operations # Protected
~ Package
– Model methods of the class
Syntax: Name(param1:type, param2:type, ...) : Result
Team BasketballPlayer
Class - Name: String
- TeamName: String Attributes
- NumberofPlayer: Integer - Height: Float
- Weight: Float
Class + ballDribble()
Operations + ballPass()
+ rebound()
Spring Semester 2009 + shoot()
Association and
Multiplicity
• Association
– Relationship between classes that specifies the existence of a
reference between their objects
• Multiplicity
– Number of instances of one class related to ONE instance of the other
class
Multiplicity Basketball Player
Association -Name: String
Team -Height: Float
1 employ * -Weight: Float
- TeamName: String
- NumberofPlayer: Integer + ballDribble()
1 * + ballPass()
exercise + rebound()
Association name + shoot()
“Team employs oneSemester

Spring or more2009basketball players”
7.4.2009 Software Architecture and Designin one team” 29
“Many Basketball players exercise
Aggregations and
Compositions
• Aggregation
– Weak “whole-part” relationship between elements
• Address may exist without Message
• Deleting Message does not delete Address
• Composition
– Strong “whole-part” relationship between elements
• Window ‘contains a’ Scrollbar
Message Window
Aggregation Composition
1 1 1 0 ..2
Address Body Panel Scrollbar

Inheritance
• Abstract commonalities of subclasses in their superclass
– All attributes and operations of the superclass are also in the subclasses
Transportation
Specialization Generalization
Road Vehicle Boat
Car Truck Bus Oil Tanker Yacht
Benz BMW Audi

State Machine Diagrams

State Machine Diagrams
• Describe the dynamic behavior of objects over time by modeling their
lifecycle showing:
– The event that cause (or trigger) a transition between states
– The conditions that guard the transition
– The actions that result from a state change
State
Event
turn PC on logout Shutting

Booting Working
Down
Guard Condition
Transition keyStroke or
Initial mouseMovement timeOut[slideshow]/ Final
State popUpScreenShot() State
Screen Action
Saving
States
• Situation during the lifecycle of an object
– Models some condition, some activity to be performed or
waits for some event
State

Booting Working Down
keyStroke or timeOut[slideshow]/
Initial mouseMovement popUpScreenShot()
State
Final
Screen State
State
Saving
Transition
Syntax: event(arguments)[condition]/action
• Change state (may be triggered by an event)
• Occur only when guard condition is true

Booting Working
Down
Transition keyStroke or timeOut[slideshow]/

mouseMovement popUpScreenShot()
Screen
Saving

Event and Action
• Event (Trigger the state change)
• Action (Call to operation of the object)
– During the transition
– Before entering a state
– After exiting a state
Event – While in the state Event

Booting Working
Down
Guard Condition
keyStroke or
mouseMovement timeOut[slideshow]/
popUpScreenShot()
Event
Screen
Action
Saving
Nested States
• To avoid the combinatorial explosion of the model, common states can be
factored out into nested states OR Decomposition (Nesting)
Plugged
Off On Mute
Unplugged
AND Decomposition
CD Radio Phone

Use Case Diagrams

What is a Use Case?
Use Case ~ An observable behavior or

coherent set of behaviors triggered by
events sent to the system from actors
found in the outside environment: human
users, other systems, timers,
or hardware components.

Use Case Diagrams
• Describe WHAT the system will do at a high-level
System Boundary
Box Office
Use Case
Survey Sales
Actor Association Supervisor
Credit Card Service Make Charges Use Case Name
Dependency <<include>>
<<include>>
Buy
Tickets
Buy Customer
Kiosk Subscription
Use Case
• Unit of functionality (or feature) expressed as the interaction
among actors and the system
Box Office
Use Case
Survey Sales
Supervisor
Make Charges
Use Case Name
Credit Card <<include>>
Service <<include>>
Buy
Tickets
Buy Customer
Kiosk Subscription

Identifying Use Cases
– Which functions does the actor require from
system?
– Does the actor need to read, create, destroy,
modify, or store some kind of information in the
system?
– Does the actor have to be notified about events
from the system?
– Could the actor’s daily work be simplified or made
more efficient through a specific feature of the
system?
Actor
• Entities that interact with the system:
– User roles, external systems, devices
Box Office
Survey Sales
Actor Supervisor
Make Charges
Service <<include>>
Buy
Tickets
Buy Customer
Kiosk Subscription
Identifying Actors
• Primary Actors:
– Who will use the main functionality of the system?
– Who will need support from the system to their daily tasks?
– Who or what has an interest in the results (the value) that the
system produces?
• Secondary Actors:
– Who will need to maintain, administrate, and keep the system
working?
– With which other systems does the system need to
interact/depend on?

System Boundary
• Group the use cases implemented by the system
(or the component) System Boundary
System Name Box Office

Survey Sales
Supervisor
Make Charges
Service <<include>>
Buy
Tickets
Buy Customer
Kiosk Subscription

Association
• Model bi-directional communication between the actor and the
system within a specific use case
Association Box Office

Survey Sales
Supervisor
Make Charges
Service <<include>>
Buy
Tickets
Buy Customer
Kiosk Subscription

Dependency – Include
• Reuse behavior common to several Use Cases
• Helps to decompose the system reusing components
Box Office
Survey Sales Inclusion
Use Cases
Supervisor
Make Charges
<<include>> Dependency
Service
Buy
Tickets
Buy Customer
Kiosk Base Use Case Subscription

Use Case Diagrams
Summary
• The diagram itself just shows an overview listing the
use cases supported by the systems and the actors
involved in them
• The use cases themselves are usually described
using text and other more precise interaction
diagrams
• Use case diagrams are often used to model
requirements, plan the development of the project,
assign priorities, and communicate with customers.

References
• A. Cockburn, Writing Effective Use Cases, Addison-Wesley, October
2000
• S. W. Ambler, The Object Primer: Agile Model Driven Development
with UML 2, 3rd Ed, Cambridge University Press, 2004
• D. Rosenberg, K.Scott Use Case Driven Object Modeling with UML :
A Practical Approach, Addison-Wesley, 1999
• I. Jacobson, Object-Oriented Software Engineering: A Use Case
Driven Approach, Addison-Wesley, 1999
• David Harel and Eran Gery, "Executable Object Modeling with
Statecharts", IEEE Computer, July 1997, pp. 31-42.
• http://www.omg.org/spec/UML/2.1.2/
– Infrastructure (224 pages)
– Superstructure (768 pages) Do not print it!
More Architectural Patterns


How to Design
Method
Theft Intuition
System
From Grady Booch

How to Design
Method Method
Theft Intuition
?
Classical System Unprecedented system
From Grady Booch

Why Patterns?
Patterns help you build on the

collective experience
of many skilled software engineers

Architectural Patterns
• Goal:
practical advice and solutions to concrete design problems
• Definition:
A pattern is a standard solution
to common and recurring design problems
• Related:
related (but different) to Object-Oriented Design Patterns
• Hint:
these patterns should be applied where they actually solve a problem
• Warning:
as with all design decisions, all consequences should be evaluated and
implications fully understood

Styles vs. Patterns
From R. Taylor
Patterns
• Layered • Composition
– State-Logic-Display – Scatter/Gather
– Model-View-Controller – Master/Slave
• Service Oriented – Synchronous
Architecture – Asynchronous
– Interoperability • Testing
– Service Directory – Faux Implementation
• Notification – Wire Tap
– Event Monitor • Optimization
– Observer – Data Transfer Object
– Publish/Subscribe – Partial Population
– Messaging Bridge

Layered
State-Logic-Display
Model-View-Controller
State-Logic-Display
• Goal:
separate elements with different rate of change
• Solution:
cluster elements that change at the same rate
together
• Pattern:
apply the layered style to separate the user
interface (display/client), from the business logic
(server), from the persistent state (database) of the
system
State-Logic-Display
Client Server Database
Display Application Data
Business Business
Presentation
Logic Objects
Client is any user or The application logic The state layer deals with
program that wants to determines what the the organization (storage,
perform an operation with system actually does indexing, and retrieval)
the system (code, rules, constraints) of the data used by the
application logic
• Goal:
support different means of interaction and display of the
same content
• Solution:
separate content (model) from presentation (output) and
interaction (input)
• Pattern:
model objects are completely ignorant of the UI. When the
model changes, the views react. The controller's job is to
take the user's input and figure out what to do with it.
Controller and view should (mostly) not communicate
directly but through the model.
Controller View
(Interaction) Model (Display)
Input
Output
The View displays the

User Input is handled by current state of the Model
the Controller which may (and may receive
change the state of the notifications about state
Model changes by observing it)

Service Oriented Architecture
Interoperability
Service Directory
Interoperability
• Goal:
enable communication between different platforms
• Solution:
map to a standardized intermediate representation and
communication style
• Pattern:
components of different architectural styles running on
different platforms are integrated by wrapping them with
adapters. These adapters enable interoperability as they
implement a mapping to common means of interaction

Interoperability Pattern
Component Adapter Adapter Component
(Platform A) (Platform A) (Platform B) (PlatformB)
Components of different platforms can interoperate through

adapters mapping the internal message format to a common
representation and interaction style
Interoperability: Hints
• Why two adapters?
– For Point to Point solutions one adapter is enough (direct mapping)
– In general, when integrating among N different platforms, the total
number of adapters is reduced by using an intermediate
representation
• Adapters do not have to be re-implemented for each component, but can
be generalized and shared among all components of a given platform
• This pattern helps to isolate the complexity of having to deal with a
different platform when building each component. The adapters make
the heterogeneity transparent.
• Warning: performance may suffer due to the overhead of applying
potentially complex transformations at each adapter

Service Directory
• Goal:
facilitate location transparency
(avoid hard-coding service addresses in clients)
• Solution:
use a directory service to find service endpoints based
on abstract descriptions
• Pattern:
clients lookup services through a directory in order to
find out how and where to invoke them

Service Directory Pattern
Client Directory Service
Service
Description 1. Publish
2. Lookup
3. Invoke
Clients use the Directory Service to lookup published service

descriptions that will enable them to perform the actual
service invocation
Service Directory Hints
• Clients cannot directly invoke services, they first need to lookup their endpoint for every
invocation.
• Directories are a service in its own right (the difference is that its endpoint should be
known in advance by all clients).
• The directory data model heavily depends on the context where the directory is applied
and to the common assumptions shared by clients and services:
– Simplest model: map <Symbolic Name> to <IP:Port>
– Directories can store complete service descriptions or only store references to service
descriptions
– Depending on the metadata stored in the directory, clients can perform sophisticated
queries over the syntax and semantics of the published services
• Directories are a critical point for the performance fault-tolerance of the system. Clients
usually cache previous results and repeat the lookup only on failure of the invocations.
• The amount of information stored in a directory may grow quite large over time and needs
to be validated and kept up to date. Published services should be approved in order for
clients to trust the information provided by the directory.
Notification
Event Monitor
Observer
Publish/Subscribe
Messaging Bridge
Event Monitor
• Goal:
inform clients about events happening at the service
• Constraint:
service does not support a publish/subscribe mechanism
• Solution:
poll and compare snapshots
• Pattern:
clients use an event monitor that periodically polls the
service, compares its state with the previous one and
notifies the clients about changes

Event Monitor Pattern
Event
Client Service
Monitor
1. poll(frequency)
Snapshot (A)
Snapshot (B)
2. compare(A,B)
3. notify
A client instructs the Event Monitor to periodically poll the state

of a remote service. The Event Monitor only notifies the client
if a change has occurred between different snapshots.
Event Monitor: Hints
• Necessary only if a service (or a component) does not provide a
publish/subscribe interface
• To minimize the amount of information to be transferred,
snapshots should be tailored to what events the client is
interested in detecting. This may be a problem if the service
interface cannot be changed.
• One event monitor should be shared among multiple clients by
using the observer pattern
• Clients should be able to control polling frequency to reduce the
load on the monitored service
• Warning: this solution does not guarantee that all changes will
be detected, but only those which occur at most as often as the
sampling rate of the event monitor
Observer
• Goal:
ensure a set of clients gets informed about all state changes of
a service as soon as they occur
• Solution:
detect changes and generate events at the service
• Pattern:
clients register themselves with the service, which will inform
them whenever a change occurs

Observer Pattern
Client (A) Service Client (B)
S.register(A) A
A.notify
B S.register(B)
A.notify B.notify
S.unregister(A) A
B.notify
Clients register a callback/notification endpoint with the service.
This is used by the service to notify all clients about state changes.
Clients should also unregister
Springthemselves
Semester 2009when no longer interested.
Observer Hints
• Assuming that a service can implement it, this pattern improves on the
Event Monitor pattern:
– State changes are not downsampled by clients
– State changes are propagated as soon as they occur
– If no change occurs, useless polling by clients is spared
• Clients could share the same endpoint with several observed services.
Notifications should identify the service from which the event originates.
• To avoid unnecessary polling by the client, notification messages should
also include information about the new state and not just that a state
change has occurred.
• Warning: the set of registered clients becomes part of the state of the
service and may have to be made persistent to survive service failures.
• A client which stops listening without unregistering should not affect the
other registered clients
Publish/Subscribe
• Goal:
decouple clients from services generating events
• Solution:
factor out event propagation and subscription management
into a separate service
• Pattern:
clients register with the event service by subscribing to certain
event types, which are published to the event service by a set
of one or more services.
Publish/Subscribe Pattern
Pub/Sub
Client (C) Service (S)
(E)
E.subscribe(C) C
X E.publish(X)
X C.notify(S,X)
As opposed to the Observer, subscriptions are centrally managed

for a set of services by the Pub/Sub Service.
As opposed to the Event Monitor, services actively push
state changes into the Pub/Sub Service.
Publish/Subscribe Hints
• The interaction between published and subscriber is similar to the
Observer pattern. It is also more decoupled, as messages are routed
based on their type.
• Warning: event types become part of the interface of a service, and
it may be difficult to determine the impact of changes in event type
definitions
• Like in the Observer pattern, subscriptions should be made
persistent, as it is difficult for clients to realize that the pub/sub
service has failed.
• Unlike with the Observer pattern, all events in the system go through
a centralized component, which can become a performance
bottleneck. This can be alleviated by partitioning the pub/sub service
by event type.
Messaging Bridge
• Goal:
connect multiple messaging systems
• Solution:
link multiple messaging systems to make messages exchanged on
one also available on the others
• Pattern:
introduce a bridge between the messaging systems, the bridge
forwards (and converts) all messages between the buses

Messaging Bridge Pattern
Bus Bridge Bus
Client (C) Service (S)
(E1) (B) (E2)
M
E1.subscribe(M) M
E2.subscribe(M)
M E2.publish(M)
M B.notify(M)
M E1.publish(M)
M C.notify(M)
The bridge (B) replays all subscriptions made by clients one bus (E1)
onto the other (E2) so that it can inform the client (C) of one bus of
messages published on the other
Messaging Bridge Hints
• Enable the integration of existing multiple messaging systems so that
applications do not have to use multiple messaging systems to
communicate
• Often it is not possible to use a single messaging system (or bus) to
integrate all applications:
– Incompatible messaging middleware (JMS vs. .NET MQ)
– External bus(es) vs. Internal bus
– One bus does not scale to handle all messages
• Although messaging systems may implement the same standard API, they
are rarely interoperable so they cannot be directly connected.
• Messaging bridges are available (or can be implemented) so that messages
can be exchanged between different buses. They act as a message
consumer and producer at the same time and may have to perform
message format translation.
Composition
Scatter/Gather
Master/Slave
Synchronous
Asynchronous
Scatter/Gather
• Goal:
send the same message to multiple recipients which will
(or may) reply to it
• Solution:
combine the notification of the request with aggregation of
replies
• Pattern:
broadcast a message to all recipients, wait for all (or some)
answers and aggregate them into a single message.
Scatter/Gather Pattern
Scatter/
Client A B C
Gather
Broadcast
Request
Aggregate
Results
Broadcasting can be implemented using subscriptions (loosely coupled)

or a distribution list provided by the client (which knows A, B, C)
Results will be collected and aggregated before they are returned to
the original client as a single message
Scatter/Gather Hints
• This is a simple composition pattern, where we are interested in aggregating
replies of the components processing the same message.
• Alternatives for controlling the components:
– The recipients can be discovered (using subscriptions) or
be known a priori (distribution list attached to request)
• Warning: the response-time of each component may vary and the response-
time of the scatter/gather is the slowest of all component responses
• Different synchronization strategies:
– Wait for all messages
– Wait for some messages (within a certain time window, or using an N-out-
of-M synchronization)
– Return fastest reply (discriminator, maybe only under certain conditions)
• Example:
– Contact N airlines simultaneously for price quotes
– Buy ticket from either airline if price<=200 CHF
– Buy the cheapest ticket if price >200 CHF
– Make the decision within 2 minutes
Master/Slave
• Goal:
speed up the execution of long running computations
• Solution:
split a large job into smaller independent partitions which can
be processed in parallel
• Pattern:
the master divides the work among a pool of slaves and
gathers the results once they arrive

Master/Slave Pattern
Client Master Partition Slave A Slave B
Assign to
Slaves
Merge
Results
Assignment to slaves can be implemented using push or pull.

The set of slaves is not known in advance and may change over time.
Results will be collected and aggregated before they are returned to
the original client
Master/Slave Hints
• This composition pattern is a specialized version of the scatter/gather pattern,
also known as divide and conquer
• Clients should not know that the master delegates its task to a set of slaves
• Master Properties:
– Different partitioning strategies may be used
– Fault Tolerance: if a slave fails, resend its partition to another one
– Computational Accuracy: send the same partition to multiple slaves and compare their results
to detect inaccuracies (this works only if slaves are deterministic)
– Master is application independent
• Slave Properties:
– Each slave runs its own thread of control
– Slaves may be distributed across the network
– Slaves may join and leave the system at any time (may even fail)
– Slaves do not usually exchange any information among themselves
– Slaves should be independent from the algorithm used to partition the work
• Example Applications:
– Matrix Multiplication (compute each row independently)
– Movie Rendering (compute each picture frame independently)
– TSP Combinatorial Optimization (local vs. global search)
Composition
• Goal:
Improve reuse of existing applications
• Solution:
Build systems out of the composition of existing ones
• Pattern:
by including compositions as an explicit part of the architecture, it becomes
possible to reuse existing services in order to aggregate basic services into
value-added ones
• Variants: Synchronous, Asynchronous

• Synonyms: Orchestration
Composition Pattern
Composite Service Service Service
Client
Service (Web) (Extranet) (Intranet)
Initiate
Progress
Notification
Completion
(Final result)
Composite services provide value-added services to clients by
aggregating a set of services and orchestrating them according
to a well-defined and explicit business process model
Composition Hints
• Composition is recursive: a composite service is a service that can be
composed.
• Services involved in a composition do not necessarily have to know that they
are being orchestrated as part of another service and may be provided by
different organizations
• Services can be reused across different compositions and compositions can
be reused by binding them to different services
• Composite services may be implemented using a variety of tools and
techniques:
– Ordinary programming languages (Java, C#, …)
– Scripting languages (Python, PERL, …)
– Workflow modeling languages (JOpera, BPEL…)
• Compositions may be long-running processes and involve asynchronous
interactions (both on the client side, and with the services)
Testing
Faux Implementation
Wire Tap
Faux Implementation
• Goal:
test a client separately from the services it depends on
• Solution:
bind the client to a local replacement
• Pattern:
the interfaces of the production services that are needed by the
client are implemented by mockup services. These are used to
test & debug the client that does not have to call the remote
service
• Synonyms: Interface Pattern, Mockup

Faux Implementation Pattern
Service
Interface
Testing Production
Client
Service Service
For testing the client calls a replacement service

which implements the same interface as the production one.
Faux Implementation: Hints
• Necessary when the production Web services are not (yet)
available for testing the client
• Warning: the faux implementation should behave like the real
one it replaces:
– Compatible functional interface
– Similar non-functional properties: e.g., response time
• Applicable when it is good enough to re-implement a subset of
the original service interface.
• As an alternative, a copy of the production service could be
redeployed for testing

Wire Tap
• Goal:
inspect messages between client and server
• Solution:
intercept messages in transit using a “wire tap”
• Design Pattern:
The wire tap replaces the intended destination of the messages,
forwards them to the original destination but also keeps a copy for
inspection
• Synonyms: Tee
Wire Tap Pattern
Wire
Client Server Log
Tap
The client may have to be modified to send messages to the wiretap

The server may be transparently replaced by the wiretap
Wire tap acts as a proxy between client and server

Wire Taps: Hints
• Useful for debugging (read the data on the wire), auditing (log all
information in transit), performance measurement (measure the
time between the request and response message)
• Warning: wire taps introduce additional latency & overhead,
especially if the messages are logged synchronously
• Three ways to set it up:
– Can Modify the Client: point the client to the wire tap proxy
instead of the original destination.
– Can Replace the Server: make the wiretap listen on the original
server endpoint and forward messages to new server address.
– Cannot Change Anything: use a packet sniffer.

Optimization
Data Transfer Object

Partial Population
Data Transfer Object
• Goal:
reduce load on service, minimize response time
(Performance Optimization)
• Solution:
reduce the number of messages that are exchanged
• Pattern:
operations should be designed with the optimal level of
granularity to perform a given function. The required input
information and the results should be exchanged with a
minimal number of messages (2 in the best case)

Data Transfer Object Pattern
Client Service Client Service
service.op1(a)
service.op2(b)
service.op(a,b,c,d)
service.op3(c)
service.op4(d)

Data Transfer Object: Hints
• Performance is improved if:
N * O(Call(1)) > O(Call(N))
Calling N-times an operation with one object takes longer than
calling once an operation passing N-objects
• Applicable when clients retrieve multiple data items from a
service
• Warning: a Data Transfer Object should not have behavior
associated with it
• Can be used to ensure client gets a consistent snapshot of
data on server (if each Call runs in its own transaction)
• Variation: Data Transfer Collection (when multiple data objects
are transferred with one message)
Partial Population
• Goal:
control and reduce message size
• Solution:
a further optimization of the Data Transfer Object pattern,
where the amount of data to be transferred can be
controlled by the client
• Pattern:
extend a Data Transfer Object with a key field – explicit
description of the actual data it contains (for sending data
to service) and pass the key as input to operation (for
choosing what the service should return)

Partial Population Pattern
Client Service Client Service
key
key
Filtering Partial Results Sending Partial Requests

Partial Population: Hints
• Advantage: Avoid defining Data Transfer Objects for every
combination of data items that a client may ever need
• The same Data Transfer Object can use “null” values to avoid
transferring unwanted fields and reduce message sizes
• Further generalizing this pattern leads to a service providing a
flexible “query” (RESTful) interface, where clients use the same
operation to submit any possible query over the data provided
by the service
ResponseDocument = Query(RequestDocument)
Response = Call(Method, Request)

Some Advice
The best architectures are full of patterns
Do not use too many unnecessary patterns

(this is an anti-pattern)

More Advice
Most software systems cannot be

structured according to a single
architectural pattern
Choosing one or more patterns does not

give a complete software architecture.
From Marek Reformat

Further refinement is needed

References
• Paul Monday, Web Service Patterns: Java Edition, APress, 2003
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,
Design Patterns: Elements of Reusable Object-Oriented Software,
Addison-Wesley, 1994
• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Patterns-Oriented Software Architecture, Vol. 1: A
System of Patterns, John Wiley, 1996
• Martin Fowler, Patterns of Enterprise Application Architecture,
Addison-Wesley, 2003
• Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns,
Addison Wesley, 2004
• William Brown, Raphael malveau, Hays McCormik III, Thomas
Mowbray, Anti-Patterns, Refactoring Software, Architectures, and
Projects in Crisis, Wiley, 1998
http://sourcemaking.com/antipatterns

Software Architect

Uploaded by

Copyright:

Available Formats

Software Architect

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architect

Uploaded by

Copyright:

Available Formats

Introduction to

Spring Semester 2009

Spring Semester 2009

Vitruvio, De Architectura, 23BC

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

One person can do it alone with:

Spring Semester 2009

Better to build a house as a team using some:

Spring Semester 2009

Spring Semester 2009

• Hard to measure software size:

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

• The hard part is to know which details to leave

From Grady Booch

Ease of support Reliability/Availability

Adapted From Grady Booch

Spring Semester 2009

From Stewart Brands

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

Spring Semester 2009

Posted 18.2.2008, CS Zurich

Spring Semester 2009

VBA / ExceI / Access Developer

Spring Semester 2009

©2009 Cesare Pautasso