1. Software Architecture & Design
6CCS3SAD / 7CCSMDAS
Dr Kevin Lano

2. Session 3: Compound Components, Basic Styles
January 28th, 2019

3. Learning Outcomes At the end of this session you should be able to:
Explain the need for complex architectures and compound components;
Represent complex architectures in UML2;
Explain the concept of architectural styles;
Apply the pipes-and-filters style to architecture design.
04/02/2016

4. So far... Components and connectors as design abstractions
Software packages (modular, cohesive, encapsulated, sometimes reusable)
Expose provided and required functionality
Connections:
Usage relations between components
Simple architectures
One way to implement in Java
A simple architecture design process
04/02/2016

5. Abstractions & Implementations
This we discussed in first week
Abstract view
(platform independent,
written in UML2)
Abstract system
architecture
Domain-Specific Models
(platform specific,
written in UML2 with
extra notation)
Enterprise
middleware
architecture
Safety critical
architecture
Embedded
system
architecture
Implementations
OO:
simple
Java:
EJB,
JMS, JSP
.NET:
COM+,
ASP
CORBA C
04/02/2016

6. Today We stay at the abstract level Next week:
Conclude tour of UML2 superstructure
Compound components and complex architectures
Make a start on simple architectural styles
Next week:
Continue to catalogue architectural styles
04/02/2016

7. Part I Advanced architectural constructs: Compound components
Delegation connectors
Part I
04/02/2016

8. Encapsulation Components are encapsulated
How functions are implemented is hidden from component clients
Clients do not need to know the code to use the component
Can think about components as black boxes
Functionality only to be understood via exposed interfaces
Sometimes insides are important!
04/02/2016

9. When are Insides Important?
Structure complex architectures into subsystems
Each subsystem is a compound component
Architecture details expressed by its internal structure
Restrict potential component interaction
Greater encapsulation
Reuse entire sections of an architecture
Not just its basic components
Modularize the architecture
Aid to project management, maintenance of code, ...
Zoom-in – Zoom-out
For example, if part of an architecture requires a set of 100% black-box OTS components – but other parts of the architecture do not use them – then it is architecturally important to isolate and encapsulate these components within a compound component
04/02/2016

10. Example – Compound Components
3 internal components are encapsulated by compound component BigHotelRes – are not accessible to rest of the system
BigHotelRes
BigHotelRes exposes HotelRes’s provided interface
04/02/2016

11. When are Insides Important? (2)
Unless components are bought off-the-shelf, they still need to be implemented
Architecture should detail semantics of components to be implemented
By defining finer-grain parts of a system
04/02/2016

12. Compound Components in UML2
In all ADLs, there are two kinds of component:
Basic
“Black box”, no internal composition specified
Composite or compound
“White box”, with an internal view
UML2 has several notations for compound components
Setting a reference to set of realizations – any UML diagram
Composite structure diagrams
Specify a mini architecture
04/02/2016

13. Realizations: Diagram 1
Simplest kind of internal view
List elements used to program component
Realizations
Can be any UML classifier
We will just consider classes
Notation
Class box with <<component>> stereotype
<<component>>
Order
<<provided interfaces>>
OrderEntry
AccountPayable
<<required interfaces>>
Person
<<realizations>>
OrderHeader
LineItem
<<artifacts>>
Order.jar
04/02/2016

14. Realizations: Diagram 2
Alternatively, use dependency relations
<<component>>
Customer
CustomerImpl
CustomerColl
CustomerDef
04/02/2016

15. Realizations: Diagram 3
Nested display
Note, internal elements are not components
<<component>>
Customer
OrderHeader
LineItem
Person
OrderEntry
04/02/2016

16. Compound Components in UML2
In all ADLs, there are two kinds of component:
Basic
“Black box”, no internal composition specified
Composite or compound
“White box”, with an internal view
UML2 has several notations for compound components
Setting a reference to set of realizations – any UML diagram
Composite structure diagrams
Specify a mini architecture
04/02/2016

17. Composite Component: What we Want
UML2 does something like this – encapsulating smaller components in a bigger component and exposing a subset of inner interfaces
BigHotelRes
04/02/2016

18. UML2 Composite Components
Provided interface
Compound component name
Required interface
<<component>>
BigHotelRes
ILoyalty
:LoyaltyProgram
IHotelRes
IMilesAndMore
IHotelRes
<<delegate>>
:HotelRes
<<delegate>>
IMilesAndMore
:CreditCardBilling
Provided
port
Required
port
IBilling
Composite structure:
internal workings of
compound component
External provided interface
implemented using
subcomponent interface
External required interface
implemented using
subcomponent interface
04/02/2016

19. Composite Structure Diagrams
Noticed the small ‘:’?
We have used Composite Structure Diagrams
Just like simple component architectures, but with components replaced by component instances
:LoyaltyProgram
An instance of component LoyaltyProgram
04/02/2016

20. Delegation Connectors
Map between external and internal interfaces
Link provided to provided
Call to external interface A is delegated to internal interface B
Link required to required
Request of internal interface B is delegated to a request on external interface A
In contrast to assembly connectors
Link required to provided
Delegation connectors represented by arrow with stereotype <<delegate>>
04/02/2016

21. External Interfaces – Ports
Representation of external interface
As normal (lollipop or socket)
But with a box at the end, called a port
Delegate connector actually joins ports to internal interfaces
Ports can be quite complicated
We consider them simply to be part of the interface
More can be done with ports, but we don’t touch on that
04/02/2016

22. Loose Ends We’ve covered the main concepts and diagrams
Many subtle points we have not had time for
Whenever you are in doubt on how to use the standard:
Consult the standard itself
Failing this, do what everyone does
Guess how best to specify what you want using the notation
If necessary, annotate your use of the notation with an explanation
04/02/2016

23. Loose Ends Multiple Clients
UML2 permits multiple clients of the same provided interface
04/02/2016

24. Loose Ends Multiplicities of Usage
Just as in UML class diagrams
1..n means from 1 to n
* means unlimited
1..* means 1 to unlimited
Example
1 Google web service used by
unlimited number of webpage clients and
unlimited number of .NET application clients * 1 *
04/02/2016

25. Break
04/02/2016

26. Part II Architectural styles: What are styles?
Style #1: Pipes-and-filters
Part II
04/02/2016

27. Architectural Styles Design Patterns for Architectures
“[..] are recurring organizational patterns and idioms.” Shaw & Garlan
“Established, shared understanding of common design forms is a mark of a mature engineering field.” Shaw & Garlan
“[..] is an abstraction of recurring composition and interaction characteristics of a set of architectures.” Taylor
“[..] are key design idioms that enable exploitation of suitable structural and evolution patterns and facilitate component, connector, and process reuse.” Medvidovic
04/02/2016

28. Architectural Styles (2)
Deal with global organizational structures
Generic: applicable across a wide range of architectures
Domain/platform-independent (now)
Domain/platform-specific (later)
Warning!
Some architectural styles are actually O-O design-patterns (e.g., model-view-controller)
But not all O-O design-patterns are architectural styles
04/02/2016

29. Core Elements of Styles
Vocabulary of design elements
Component and connector types
e.g., pipes, filters, objects, servers
Set of configuration rules
Topological constraints
Determine allowed compositions of elements
e.g., “a component may be connected to at most two other components”
Semantic interpretation
Compositions of design elements have well-defined meanings
Explanation of what components are supposed to do in general
Explanation of how connections are meant to work
04/02/2016

30. Benefits of Styles Design reuse Code reuse
Well-understood solutions applied to new problems
Code reuse
Shared implementations of invariant aspects of a style
Understandability of system organization
“Client-server” conveys a lot of information
04/02/2016

31. Benefits of Styles (2) Interoperability Style-specific analyses
Supported by style standardization
Components can be independently developed with a particular style in mind
Style-specific analyses
Aided by the constrained design space (e.g., reliability, efficiency)
Visualizations
Style-specific depictions matching engineers’ mental models
04/02/2016

32. Simple Architectural Styles
We cover the following domain/platform-independent styles
Pipes and filters
2-tiered
N-tiered
Layered
Blackboard
Fault-tolerance
04/02/2016

33. Style 1: Pipes and Filters
All components use the same interface
Input through provided interface
Output through required interface
Components are filters
Transform input messages into output messages
Usually – one provided (input) interface and one required (output) interface
Connectors are pipes
Conduits for messages
Simple connections between filters’ provided and required interfaces
Style invariants
Filters are independent
A filter has no knowledge of up- and down-stream filters
Semantics
Each filter receives messages on inbound pipe, processes messages, publishes results to the outbound pipe.
Pipe connects one filter to next, sending output messages from one filter to next.

34. Style 1: Pipes and Filters
Advantages
Simple: system behavior = sum of component
Filter addition, replacement, and reuse
Disadvantages
Lowest common denominator on data formats
Compare: Chain of Responsibility OO pattern; Intercepting Filter EIS pattern
04/02/2016

35. Style 1: Pipes and Filters
Commonly seen in:
UNIX shells (piping data between processes)
Telecommunications
Signal processing
Parallel programming
But also useful style for enterprise systems
Often, single event triggers sequence of processing steps
04/02/2016

36. Style 1: Pipes and Filters Example
Order processing system
New orders arrive from client in form of a message
Requirements
Messages are encrypted to prevent eavesdroppers from spying on a customer's order
Messages contain authentication information (digital certificate) to ensure orders are placed only by trusted customers
Duplicate messages could be sent from external parties – these must be eliminated
Remember all the warnings on popular shopping sites to click the 'Order Now' button only once?
Solution
Transform stream of possibly duplicated, encrypted messages containing extra authentication data into stream of unique, simple plain-text order messages
04/02/2016

37. Style 1: Pipes and Filters Example
IMessage
External client component  Produces order message
<<interface>>
IMessage
+transmit(msg:Object)
Messages are input/output using the same simple interface
transmit(msg:Object) transmits the message
IMessage
Order processing system
04/02/2016

38. Style 1: Pipes and Filters Example
Simplification
Build complex processing of messages from simple steps
Flexibility
All components use the same external interface
Can be composed into different solutions by connecting components to different pipes
Add new filters
Omit existing ones
Rearrange into a new sequence
No need to change the filters
Remove order encryption
Add a log of each order received
04/02/2016
Authenticate orders before deduplicating

39. Coming Up
More styles
More basic styles
Domain-specific styles
Implementation of components and component architectures
Beyond basic Java classes
Complex forms of communication
Domain-specific modelling issues
04/02/2016