This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
4. Definitions and concepts
Some contents of this part of lecture extracted from Henry Muccini’s lecture on
software architecture at the University of L’Aquila (Italy)
10. Refresh
Example: software architecture
The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components and
the relationships among them
System
subsystem Subsystem
component component component
L. Bass, P. Clements, R. Kazman, Software Architecture In Practise, Addison Wesley, 1998
11. Software Architecture definitions
Perry and Wolf, ’92 (aspects):
– “Architecture is concerned with the selection of architectural elements,
their interactions, and the constraints on those elements and their
interactions necessary to provide a framework in which to satisfy the
requirements and serve as a basis for the design.”
– Elements are divided into processing elements, data elements and
connection elements
Garlan and Shaw, ’93 (elements):
– Architecture for a specific system may be captured as “a collection of
computational components - or simply components - together with a
description of the interactions between these components - the
connectors -”
Sommerville, 7th edition, ’04 (process):
– The design process for identifying the sub-systems making up a system and
the framework for sub-system control and communication is architectural
design. The output of this design process is a description of the SA.
12. Develop systems “architecturally”
If you think good architecture is expensive,
try bad architecture.
... Brian Foote and Joseph Yoder
– Design at an architectural level of abstraction
– Build systems compositionally from parts
– Assure that the system will satisfy critical requirements before it is
constructed
– Recognize and reuse standard architectures patterns & styles
– Reuse codified architectural design expertise à reduce costs
through product-lines
13. In general terms…
SA describes (in a more or less “formal” notation) how a system
is structured into components and connectors…
– Components
– Connectors
– Channels and Ports
… and how these components interact
– Scenarios
– State Diagrams
– …
SA Structure (topology)
SA Dynamics (behavior)
14. Process (2)
Architectural constraints
and requirements
Ideas
Constraints
Req1:..
Req2:..
Req3:..
………
Architectural
requirements
C2
C1 C3
C4
Software
Architecture
Software
Architecture
synthesis
C2
C1 C3
Software C4
Architecture
Evaluation and prototype
Decisions making
16. Components
A component is a building block that is
– A unit of computation or a data store, with an
interface specifying the services it provides and
requires
– A unit of deployment
– A unit of reuse
• e.g., client, server, database, filters, ...
C1
S1 S2 S3
S’x
S’Y
provided
services
required
services
18. Components vs Objects
The level of abstraction is usually different
• Size
– Objects tend to be small
– Components can be small (one object) or large (a library of
objects or a complete application)
• An architectural component may be implemented by
several objects
• Lifecycle
– Objects are created and destroyed constantly
– Components are created and destroyed infrequently
19. Connectors
A connector is a building block that enables interaction
among components
– Events
– Client/server middleware
– Messages and message buses
– Shared variables
– Procedure calls (local or remote)
– Pipes
Connectors may be implicit or explicit
– Connectors sometimes are just channels
– Connectors sometimes have their own logic and
complexity
20. Components and Connectors
A component is (or should be) independent of the
context in which it is used to provide services
A connector is (or should be) dependent on the
context in which it is used to connect components
Connectors sometimes are modeled as special kinds
of components
21. Interfaces
An interface is the external connection of a component
(or connector) that describes how to interact with it
Provided and required interfaces are important
Spectrum of interface specification
– Loosely specified (events go in, events go out)
– API style (list of functions)
– Very highly specified (event protocols across the interface in
CSP)
22. Architecting: example
GUI
FeedService
Common FeedService
Action
NewsFeeder
Action
Admin
Action
Factory
FeedDelegate
POJOs
NewsFeeder
DAO
FeedDAO
NewsFeederDAO
FeedDAO
FeedDelegate
Transfer
Object
ValidatorService
NewsFeederDelegate
NewsFeeder
DelegatePOJOs
Browser
(html
javascript)
Web
Services
DATABASE
Trasformation
Validation
BusinessFactory
Validation
Service
23. Architecting: example
GUI
FeedService
FeedService
Common
Action
NewsFeeder
Action
Admin
Action
Factory
FeedDelegate
PresentationExtensionOut
PresentationExtensionIn
BusinessExtensionOut
FeedDelegate
POJOs
NewsFeederDelegate
NewsFeederDAO FeedDAO
NewsFeeder
DAO FeedDAO
Transfer
Object
ValidatorService
NewsFeeder
DelegatePOJOs
Browser
(html
javascript)
Web
Services
DATABASE
Trasformation
Validation
BusinessFactory
Validation
Service
BusinessExtensionIn
24. Architectural Elements vs Design Elements
“Architecture is concerned with the selection of architectural
elements, their interactions, and the constraints on those elements
and their interactions necessary to provide a framework in which to
satisfy the requirements and serve as a basis for the design.”
“Design is concerned with the modularization and detailed interfaces
of the design elements, their algorithms and procedures, and the
data types needed to support the architecture and to satisfy the
requirements.”
(Perry & Wolf 92)
26. SA dynamics
The SA dynamics is expressed in terms of component
interactions via connectors
- Labeled Transition Systems
- Automata
- UML StateCharts, Sequence Diagrams, Activity Diagrams
- State Diagrams
- Message Sequence Charts
- …
27. An example : e-commerce system
Customer Interface
Customer Process
Web Server
Delivery Order Catalog Server
Customer Server
Cart Server
Process
Order Server
SA Static Description
28. An example : e-commerce system
CustomerInterface
CustomerProcess CatalogServer
BrowseCatalog
BrowseCatalog
ReadStatus
Catalog Page
Output Page
Catalog Info
SA Dynamic Description :
Registered Customer
Catalog DB
Involved
Browse Catalogue Sequence Diagram
29. An example : e-commerce system
CustomerInterface
Registered Customer
CustomerProcess CartServer
PlaceOrderReq
PlaceOrder
ReadStatus
Cart DB
Involved
pageOrder
OutputPage
OrderServer
Order DB
Involved
EmptyCart
Cart DB
Involved
CustomerServer
ReadInfo
Customer
DB Involved
DeliveryOrderProcess
createNewOrder
OrderInfo
newOrder
CartInfo
CustomerInfo
OrderInfo
SA Dynamic Description :
Place Order Sequence Diagram (success)
30. An example : e-commerce system
CustomerInterface
CustomerProcess CartServer
PlaceOrder
ReadStatus
errorPage
emptyCart
SA Dynamic Description :
Registered Customer
PlaceOrderReq
Cart DB
Involved
OutputPage
Place Order Sequence Diagram (empty cart)
32. Advantages of explicit architecture
System analysis
– Analysis of the system before it has been built
– Costs saving and risks mitigation
Large-scale reuse
– The architecture (or part of it) may be reusable across a range
of systems
– Design decisions reuse à saves design costs + less risks
Stakeholders communication
– Architecture may be used as a focus of discussion by system
stakeholders
– Early design decisions reasoning, when it is still relatively easy
to adapt
33. Architecture and software qualities
Performance
– Localise critical operations and minimise communications
Security
– Use a layered architecture with critical assets in the inner layers
Safety
– Localise safety-critical features in a small number of sub-systems
Availability
– Include redundant components and mechanisms for fault tolerance
Maintainability
– Use fine-grain, replaceable components
These are all examples of TACTICS
34. Tactics
A tactic is a design decision that refines a high level style
and is influential in the control of a quality attribute response
Tactics complement and refine styles that make up the
architecture
promotes tactic
Design decision Quality attribute
36. Tactics may originate conflicts
For example:
• Using large-grain components improves performance
but reduces maintainability
• Introducing redundant data improves availability but
makes security more difficult
• Localising safety-related features may mean more
communication so degraded performance
38. Outline
What is an architectural style?
Styles catalogue
Relation between tactics and patterns
Tactics interaction
Summary
39. What is an architectural style?
An architectural style establishes a relationship between:
• Context
– A recurring situation in the world that gives rise to a problem
• Problem
– The problem, appropriately generalized, that arises in the context
• Solution:
– a set of element types
• e.g., data repositories, processes, and objects
– a set of interaction mechanisms or connectors
• e.g., method calls, events, or message bus
– a topological layout of the components
– a set of semantic constraints
40. Common styles catalogue
• Publish-subscribe
• Layered
• Shared-data
• Client-server
• Peer to peer
• MVC
• Pipes and filters
41. Publish-Subscribe Pattern
Context
– There are a number of independent producers and consumers
of data that must interact. The precise number and nature of the
data producers and consumers are not predetermined or fixed,
nor is the data that they share.
Problem
– How can we create integration mechanisms that support the
ability to transmit messages among the producers and
consumers so they are unaware of each other’s identity, or
potentially even their existence?
Solution
– Components can interact via announced messages, or events.
Components may subscribe to a set of events.
– Publisher components place events on the bus by announcing
them; the connector then delivers those events to the
subscriber components that have registered an interest in those
events.
42. Publish-Subscribe Solution – 1
Elements:
– Any component with at least one publish or subscribe port
– The publish-subscribe connector, which will have announce and
listen roles for components that wish to publish and subscribe to
events
Relations:
– The attachment relation associates components with the publish-subscribe
connector by prescribing which components announce
events and which components are registered to receive events
Weaknesses:
– Typically increases latency and has a negative effect on scalability
and predictability of message delivery time
– Less control over ordering of messages
– Delivery of messages is not guaranteed
46. The Layered System Style
A layered system is organized hierarchically, each layer providing
service to the layer above and below
• Components
– Programs or subprograms deployed in a layer
• Connectors
– Protocols
• Procedure calls or system calls
• Stylistic invariants
– Each layer provides a service only to the immediate layer
“above” (at the next higher level of abstraction) and uses the
service only of the immediate layer “below” (at the next lower level
of abstraction)
47. Layered System Example: OSI Protocol Stack
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical
Network
Data Link
Physical
Network
Data Link
Physical
48. Layered System Advantages and Disadvantages
Advantages
– Decomposability: Effective separation of concerns and different
level of abstractions
– Maintainability: Changes that do not affect layer interfaces are easy
to make
– Adaptability/Portability: Can replace inner layers as long as
interfaces remain the same
– Understandability: Strict set of dependencies allow you to ignore
outer layers
Disadvantages
– Not all systems are easily structured in a layered fashion
– Performance degrades with too many layers
– Can be difficult to cleanly assign functionality to the “right” layer
49. Shared-Data style
Context
Various computational components need to share and manipulate
large amounts of data. This data does not belong solely to any one
of those components.
Problem
How can systems store and manipulate persistent data that is
accessed by multiple independent components?
Solution
In the shared-data pattern, interaction is dominated by the
exchange of persistent data between multiple data accessors and
at least one shared-data store. Exchange may be initiated by the
accessors or the data store. The connector type is data reading
and writing.
50. Shared Data Solution
Elements:
– Shared-data store
• Concerns include types of data stored, data
performance-oriented properties, data distribution, and
number of accessors permitted
– Data accessor component
– Data reading and writing connector
52. Advantages and disadvantages
Advantages
– Simplicity: Only one connector (the blackboard) that everyone
uses
– Evolvability: New types of components can be added easily
Disadvantages
– Blackboard becomes a bottleneck with too many clients
53. Client-server
• One component is a server offering a service
• The other components are clients using the service
• Server implementation is transparent but can be centralized or
distributed, single-threaded or multi-threaded
– Single interface point with physically distributed implementation
– Dynamic, transparent selection from among multiple interface
points
55. 3-tier client-server systems
3-tier client-server systems are a common class of distributed
business systems
• First tier: Client (user interface) tier
– Presentation logic
• Second (middle, “business logic”) tier: Servers acting as “business
objects”, encapsulating abstract, integrated models of multiple,
disparate data sources
– Computation
• Third (back-end, database) tier: Legacy business applications
providing data services
– Database
Weaknesses:
Substantial up-front cost and complexity
56. 3-Tier Client-server systems (example)
Web
browser
Key
SignOnFilter
*.do
Main
Servlet
*.screen
Template
Servlet
mappings.xml
Screen
JSP
index.jsp
Sign On
Notifier
screen
definitions.xml
sign-on-config.
xml
Order
Facade
OpcOrder
TrackingService
OpcPurchase
OrderService
Catalog
Facade OPC
Adventure
Catalog
DB
User
Mgmt
Facade
Client tier Web tier EJB tier Back end
Client-side
application
Java
EE
filter
Stateless
session
bean
Java EE
application
Context
listener
Data
store
File
Servlet
Web services Container
endpoint
SOAP
call
File
I/O
Java
call
HTTP/
HTTPS
JDBC
57. Peer-to-peer style
Context: need to cooperate and collaborate to provide a service to a
distributed community of users
Problem: How can a set of “equal” distributed computational entities be
connected to each other via a common protocol so that they can
organize and share their services with high availability and scalability?
Solution: components directly interact as peers. All peers are “equal” and
no peer or group of peers can be critical for the health of the system.
Peer-to-peer communication is typically a request/reply interaction
without the asymmetry found in the client-server pattern
61. Advantages and Disadvantages
Advantages
– Interoperability A natural high-level architectural style for
heterogeneous distributed systems
– Scalability: Powerful enough server tiers can accommodate many
clients
– Distributability: Components communicate over a network
Disadvantages
– Visibility, Maintainability: Difficult to analyze and debug
• Distributed state
• Potential for deadlock, starvation, race conditions, service outages
– Require sophisticated interoperability mechanisms
• Data marshalling and unmarshalling
• Proxies and stubs for RPC
• Legacy wrappers
62. Model-View-Controller Pattern
Context: User interface software is typically the most frequently modified
portion of an interactive application. Users often wish to look at data from
different perspectives, such as a bar graph or a pie chart. These
representations should both reflect the current state of the data.
Problem: How can user interface functionality be kept separate from
application functionality and yet still be responsive to user input, or to
changes in the underlying application’s data? And how can multiple views
of the user interface be created, maintained, and coordinated when the
underlying application data changes?
Solution: The model-view-controller (MVC) style separates application
functionality into three kinds of components:
– A model, which contains the application’s data
– A view, which displays some portion of the underlying data and
interacts with the user
– A controller, which mediates between the model and the view and
manages the notifications of state changes
64. MVC Solution - 1
The MVC pattern breaks system functionality into three
components: a model, a view, and a controller that mediates
between the model and the view
• Elements:
– The model is a representation of the application data or state, and
it contains (or provides an interface to) application logic
– The view is a user interface component that either produces a
representation of the model for the user or allows for some form of
user input, or both
– The controller manages the interaction between the model and
the view, translating user actions into changes to the model or
changes to the view
65. MVC Solution - 2
Relations: The notifies relation connects instances of model,
view, and controller, notifying elements of relevant state
changes
Constraints:
– There must be at least one instance of each of model, view, and
controller
– The model component should not interact directly with the
controller
Weaknesses:
– The complexity may not be worth it for simple user interfaces
– The model, view, and controller abstractions may not be good fits
for some user interface toolkits
66. Pipe and Filter Pattern
Context: Many systems are required to transform streams of
discrete data items, from input to output. Many types of
transformations occur repeatedly in practice, and so it is desirable
to create these as independent, reusable parts
Problem: Such systems need to be divided into reusable, loosely
coupled components with simple, generic interaction
mechanisms. The components, being generic and loosely
coupled, are easily reused. The components, being independent,
can execute in parallel
Solution: The pattern of interaction in the pipe-and-filter pattern is
characterized by successive transformations of streams of data.
Data arrives at a filter’s input port(s), is transformed, and then is
passed via its output port(s) through a pipe to the next filter. A
single filter can consume data from, or produce data to, one or
more ports
67. Pipe and Filter Solution
Data is transformed from a system’s external inputs to its external outputs
through a series of transformations performed by its filters connected by
pipes
Elements:
– Filter, which is a component that transforms data read on its input port(s) to data
written on its output port(s)
– Pipe, which is a connector that conveys data from a filter’s output port(s) to another
filter’s input port(s). A pipe preserves the sequence of data items, and it does not
alter the data passing through
Relations: The attachment relation associates the output of filters with the
input of pipes and vice versa
Constraints:
– Pipes connect filter output ports to filter input ports
– Connected filters must agree on the type of data being passed along the
connecting pipe
69. Architectural styles vs design patterns
Many similarities between patterns and styles
– Goal: packaged engineering experience
– Formulation: organization and interaction among “key”
components
But they have come from different communities
– Many architectural styles have been well known for a long time in
the software engineering community
– Patterns are a relatively recent development in OO design
Differences:
Architectural styles Design patterns
few many
large-scale system
organization
localized, small-scale
design solutions
70. Relationships between tactics and
styles
Styles are built from tactics
à if a style is a molecule, a tactic is an atom
MVC, for example utilizes the tactics:
– Increase semantic coherence
– Encapsulation
– Use an intermediary
– Use run-time binding
71. Tactics augment styles
Styles solve a specific problem but are neutral or have
weaknesses with respect to other qualities
Consider the shared-data pattern
– May have a single point of failure
We may use tactics such as:
– Increase resources will help performance
– Maintain multiple copies will help availability
72. Tactics and interactions
• Each tactic has pluses (its reason for being) and minuses –
side effects.
• Use of tactics can help alleviate the minuses
• But nothing is free…
à tactics should interact with each other
73. Tactics and interactions - 2
A common tactic for detecting faults is Ping/Echo
Common side-effects of Ping/Echo are:
• security
– how to prevent a ping flood attack?
• performance
– how to ensure that the performance overhead of ping/echo is
small?
• modifiability
– how to add ping/echo to the existing architecture?
75. Tactics and interactions - 4
A tactic to address the performance side-effect is “Increase
Available Resources”
Common side effects of Increase Available Resources are:
• cost
– increased resources cost more
• performance
– how to utilize the increase resources efficiently?
76. Tactics and interactions - 5
System
Ping/Echo
Add to
system
Ping
flood
Performance
overhead
Increase Available
Resources
Cost Resource
Utilization
77. Tactics and interactions - 6
A tactic to address the efficient use of resources side-effect
is “Scheduling Policy”
Common side effects of Scheduling Policy are:
• modifiability
– how to add the scheduling policy to the existing architecture
• modifiability
– how to change the scheduling policy in the future?
78. Tactics and interactions - 7
System
Ping/Echo
Add to
system
Ping
flood
Performance
overhead
Increase Available
Resources
Cost Resource
Utilization
Scheduling
Policy
Add to
system
Modify
policy
79. Tactics and interactions - 8
A tactic to address the addition of the scheduler to the
system is “Use an Intermediary”
Common side effects of Use an Intermediary are:
• modifiability
– how to ensure that all communication passes through the
intermediary?
80. Tactics and interactions - 9
System
Ping/Echo
Add to
system
Ping
flood
Performance
overhead
Increase Available
Resources
Cost Resource
Utilization
Scheduling
Policy
Add to
system
Modify
policy
Use an
Intermediary
Ensure
usage
81. Tactics and interactions – 10
A tactic to address the concern that all communication
passes through the intermediary is “Restrict
Communication Paths”
Common side effects of Restrict Communication Paths are:
• performance:
– how to ensure that the performance overhead of the intermediary
are not excessive?
Note: this design problem has now become recursive!
82. How does this process end?
• Each use of tactic introduces new concerns
• Each new concern causes new tactics to be added
• Are we in an infinite progression?
No. Eventually the side-effects of each tactic become small
enough to ignore
83. What this lecture means to you?
Software architecture is the main instrument for reasoning
about
– high level of system design
– system-level properties and qualities
• e.g., modularity, evolvability, etc.
– large-scale reuse
Architectural style: reusable pattern
– for solving recurrent problems
– for obtaining qualities “out-of-the-box”
It establishes a relationship between:
– context
– problem
– solution
• components, their relationships, constraints
84. Suggested readings
1. David Garlan. “Software architecture: a travelogue.” ICSE '14
Proceedings of the Conference on The Future of Software
Engineering, ACM Press, 2014.
2. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software
architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40.doi:
10.1145/141874.141884.
3. Garlan & Shaw (1994). "An Introduction to Software Architecture".
Retrieved 2012-09-13.