1. Applying Architectural Styles and Patterns

2. Outline Defining Architectural Patterns and Style
The activation model
Styles and Quality Attributes
Common Architectural Styles
Dataflow systems
Call-and-return systems
Independent components
Virtual machines
Repositories

3. Introduction
Relying solely on design operators to design an architecture can be a slow process.
By utilizing existing design experience from the software engineering community design productivity can be improved.
There are two types of reusable architectural products:
Product families
Architectural styles and patterns

4. Architectural Style
It is a type of metamodel that prescribes a set of elements and their relationships that characterize a system based on the style.
These elements are expressed as components and connectors.
Their relationships are the constraints on how components and connectors may be combined.

5. Architectural Patterns
A pattern is a solution that strikes some balance between competing forces.
However, what makes it a pattern is the fact that it is recurring.
If a design solution in its essential distilled form is found in multiple systems and is a successful design, then this solution is a pattern.

6. Architectural Patterns (Cont’d)
A pattern language is a set of patterns, together with the rules for describing how patterns are created and how they must be arranged with respect to other patterns.
The patterns are the vocabulary of the language, and the rules for their implementation and combination are the grammar.
Patterns in a pattern language can be constructed from other patterns.

7. Architectural Styles
An architectural style is a framework for a solution and not really a solution itself.
The selection of a style limits the scope of the solution space.
According to Ivar Jacobson, the architectural style of a system is “the denotation of the modeling languages used when modeling the system.”
It includes the guiding principles and prescriptions that the other development model elements must satisfy.

8. Architectural Styles (Cont’d)
It is the foundation of a philosophy of building.
An architectural style defines a vocabulary of components and connector types and a set of constraints on how they can be combined.
Most applications, however, are a combination of styles, i.e., they have a heterogeneous architectural style.
There are many parameters that we can use to characterize software architecture:
The way in which control is passed between components (activation model)
The quality attribute emphasis (e.g., maintainability and performance)

9. Activation Model
This model describes how components are activated and how information is passed between them (the control principle of the architecture).
In classic procedural languages and their object-oriented derivatives, method invocation and method execution are bound, i.e., method execution follows immediately from method invocation.
In languages like Smalltalk method invocation and method execution are decoupled.

10. Activation Model (Cont’d)
At the design level you can simulate these activation models in the language level.
Synchronous communication means that the client component activates a server component and then waits for a response.
A variation of this is the balking model in which a component may reject a request for any reason.

11. Activation Model (Cont’d)
Another variation is the timeout in which a client component assumes that the server has failed to complete a request after a certain amount of time.
Asynchronous communication means that the client doesn’t wait on a response from the server before continuing.
In the delegating pattern, a client component invokes a server component and provides an address to which the response is to be sent.

12. Activation Model – Patterns of Information Passing
Data elements can be passed directly between processing elements (pipes and filters).
Data elements may also be shared in a central store and accessed by different processing elements (repository).

13. Uses of the Activation Model
To compare different architectural styles.
To identify the appropriate architectural style for the entire system or the best combination of architectural styles.

14. Styles and Quality Attributes
Each style emphasizes a set of quality attributes while de-emphasizing another set.
Pipes and filters emphasizes reusability and adaptability but sacrifices maintainability with respect to changes in data representation.
Object-oriented systems emphasize maintainability but are not easily reused

15. Styles and Quality Attributes (Cont’d)
Repository-based systems emphasize adaptability and performance but are not highly reusable or maintainable in terms of changes to algorithms or data representations
Styles can be combined in order to exhibit different quality attributes.

16. Common Architectural Styles (Adapted from Shaw and Garlan)
Dataflow systems
Batch sequential
Process control
Pipes and filters
Call-and-return systems
Main program and subroutine
Object-oriented systems
Hierarchical layers

17. Common Architectural Styles (Cont’d)
Independent components
Communicating processes
Event systems
Virtual machines
Interpreters
Rule-based systems
Repositories
Databases
Hypertext systems
Blackboards

18. How can we study Architectural Styles
How can we study Architectural Styles? (Perry James – Concordia University)
By examining the following for each:
Connectors, components
Key characteristics
Strengths & weaknesses
Variants & specializations
Examples

19. Dataflow Systems

20. Style – Process Control
Stolen from Dan

21. Process Control: Components & Connectors
The following slides offer only an introduction to the process control style.
The process control style is modeled on the process control systems that are common in other engineering disciplines (e.g. chemical engineering).
Motivating example: furnace
Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

22. Process Control: Example
Open-loop temperature control.

23. Process Control: Example
Closed-loop temperature control.

24. Process Control: Example
Applied to software

25. Process Control: Components & Connectors
Process
Input variables
Controlled variables
Changes to manipulated variables
Controller
Set point
(Feedback control)
(Feed-forward control)
Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

26. Process Control: Key Characteristics
Organization:
Computational elements (important separation)
Process definition.
Control algorithm.
Data elements:
Process variables.
Set point.
Control algorithm uses information about actual system state to tune the process, driving the actual state towards the intended state.

27. Process Control: Strengths
Well suited for the control of continuous processes particularly where the control algorithm is subject to change (possibly even at run-time).

28. Process Control: Weaknesses
Not easily applicable when multiple interacting processes (and controls) are needed.

29. Process Control: Examples
Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

30. Process Control: Examples
Cruise control system
Heating system
Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

31. Style – Pipes and Filters: Components & Connectors
Components: Filter
Completely independent entities
Consume streams of inputs and produce streams of outputs
Context independent (do not know what produced the input or will consume the output)
Output starts before input is (entirely) consumed (incremental transformation of data)
Connectors: Pipes
Carrier of data streams
Binding between component ports
Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

32. Pipes and Filters: Key Characteristics
Data Flow Architecture
Model assumes concurrent processing.
Filters are independent.
Do not share data.
Do not know identity of neighbors.
Individual filter behavior: simple I/O relation
System behavior = simple composition of individual filter behaviors.
Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

33. Pipes and Filters: Strengths
System easy to understand
System = simple composition of individual filters
No complex interaction between components
Reuse, Enhancement & Maintainability
Easy to add filters & replace existing ones (why?)
Concurrency can be easily exploited.

34. Pipes and Filters: Weaknesses
Can lead to batch sequential processing
Not well suited to interactive applications
Use of this style may
Force least common denominator in data format
Can lead to extra work for filters to assemble and organize data
Can lead to decreased performance and increased filter complexity

35. Pipes and Filters: Variations
Pipelines
Linear sequences of filters
Batch Sequential Systems
Pipeline; but each step runs to completion before the next starts
Bounded pipes
Restriction on the amount of data that can temporarily reside/buffered on/in a pipe
Typed pipes
Restricts the data passed between two filters to a well-defined type
“UI pipes”
Each filter is associated with UI to allow the user to set parameters of operation
Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

36. Pipes and Filters: Examples

37. Pipes and Filters: Examples
Unix shell: e.g. ls | grep “my” | wc –l
Traditional view of compilers
Also has applications in
Signal processing
Parallel programming
Functional programming
Distributed systems

38. Style – Object-Oriented Systems: Components & Connectors
Components: Classes & Objects
Connectors: Method calls
Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

39. Object-Oriented Systems: Key Characteristics
Call and return architecture
Interaction through method invocation
Based on data abstraction:
Encapsulation
Information hiding
Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

40. Object-Oriented Systems: Encapsulation
A packaging / scoping mechanism for names
Names can refer to data, types, …
Especially, a means of packaging data
Access points at interface

41. Object-Oriented Systems: Information Hiding
Design principle
A module
has a “secret”, usually a design decision
makes particular design choice “invisible” to clients
E.g.
Choice of algorithm
Data structure

42. Object-Oriented Systems: Strengths
Naturally supports information hiding, which shields implementation changes from clients
Encapsulation and information hiding reduce coupling
=> Enhances maintainability
Allows systems to be modeled as collections of collaborating objects
=> can be an effective means of managing system complexity

43. Object-Oriented Systems: Weaknesses
Object identity must be known for method invocation
=> Identity change of an object affects all calling objects
Contrast this to pipe-and-filter …
Concurrency problems through concurrent access

44. Object-Oriented Systems: Variations
Active classes
When instantiated, control their own execution
Can operate standalone (rather than being invoked by other classes)
Own thread
Other OO variants such as support (or not) of multiple inheritance, interfaces, static typing, etc.
although most OOPL have compromised security—information hiding—for sake of efficiency

45. Object-Oriented Systems: Examples

46. Object-Oriented Systems: Examples
Object-oriented systems can be seen as an evolution of ADTs

47. Style: Hierarchically Layered Systems
3-Tiered Enterprise Applications
Presentation
Domain Logic
Technical Services

48. Hierarchically Layered Systems: Components & Connectors
Components: Layers
Connectors: Protocols that define how layers interact
Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

49. Hierarchically Layered Systems: Key Characteristics
Hierarchical organization
Only adjacent layers communicate
Each layer provides services to the level above and serves as a client to the layer below
Lower layer is unaware of higher layer
Each layer hides its lower layers from the layers above
Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

50. Hierarchically Layered Systems: Strengths
A single layer acts as a coherent whole
No need to know much about other layers
Portability:
Easy to replace a layer with another implementation of its services
Maintainability: Each layer’s role is well defined
Minimized dependencies
Supports design based on increasing levels of abstraction

51. Hierarchically Layered Systems: Weaknesses
Performance
High-level functions only indirectly access low-level functions -> must go through the various layers
Difficult to find the right abstractions (especially with many layers involved)
Risk of abstracting the wrong thing
Not all systems fit into the layered style
The scope of one component may overlap several layers

52. Hierarchically Layered Systems: Variations
Layer may accesses other lower level layers than just the layer below
Less pure
Increased performance
although most OOPL have compromised security—information hiding—for sake of efficiency

53. Hierarchically Layered Systems: Examples

54. Hierarchically Layered Systems: Examples
Protocols
TCP/IP
OSI ISO model
X Window system
Enterprise Applications
Presentation layer
Domain logic layer
Data source layer

55. Style: Event Systems: Components & Connectors
Component: (active or passive) object, capsule, module
Can be an instance of a class, an active class, or simply a module.
Interface provides methods and ports.
Publisher: individual components announce data that they wish to share with their subscribers.
Subscriber: individual components register their interest for published data.
Connector: “connector”, channel, binding, callback.
Offers one-to-one, one-to-many, many-to-one connections;
Asynchronous event broadcast.
Synchronous event broadcast & await reply (call-and-return)
Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

56. Event Systems: Key Characteristics
Components do not explicitly invoke each other.
Components generate signals, also called events.
To receive events, objects can
Receive events at ports (statically or dynamically bound).
Register for event notification (e.g. via callback).
Announcers do not know which components will be affected by thrown events
System framework implements signal propagation
Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

57. Event Systems: Strengths
Supports reuse
Only little coupling
Easy system evolution
Introduction of new component simply by registering
Well suited for asynchronous communication

58. Event Systems: Weaknesses
Components don’t have control over computation since they can only generate events; the run-time system handles event dispatching. Thus responses to events are not ordered.
Exchange of data can require use of global variables or shared repository => resource management can become a challenge.
Global system analysis is more challenging.
Asynchronous event handling
Contrast to explicit call & use of pre-, post-conditions. (E.g., how to ensure that at least one object has processed an event.

59. Event Systems: Variations
Pure implicit invocation systems are quite rare.
At some point explicit invocation is used among objects.
Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

60. Event Systems: Examples

61. Event Systems: Examples
UIs
Macintosh computers popularized the “main event loop” approach for UI applications.
Other examples include
Constraint satisfaction systems (e.g. some database systems).
Daemons.
S/W environments that make use of multiple tools: e.g. text editor registers for events from debugger.

62. Style – Repository

63. Repository: Components & Connectors
Data store,
Clients, that interact with the store
Connectors
Queries

64. Repository: Key Characteristics
The Architecture is centered on a widely accessed data store
Data store & clients. Two main variants:
Database
Passive data store,
active clients that poll the database.
Blackboard
Active data store that notifies each client of data changes of interest to the client.
(Clients also called knowledge sources.)

65. Repository: Strengths
Clients are relatively independent of each other. Data store is independent of the clients.
Scalable (i.e., new clients can be easily added)
Modifiable

66. Repository: Weaknesses
Strong dependence on data store…

67. Repository: Variants
There are several variants of DB systems including the main distinction between traditional databases vs. object-oriented databases.
Distributed DB.

68. Repository: Examples

69. Repository: Examples Programming environments (IDEs)
All applications that use global databases
Modern Compilers

70. Summary
Architectural styles allow us to reason about the high-level design of a system before we start to implement it.
They are applied early in the architectural process.
Architectural styles address many nonfunctional quality characteristics such as performance, reliability, and modifiability.
They help us to decompose our system more effectively.