1. T-76.5150 Software Architectures
Helsinki University of Technology, SoberIT
T Software Architectures
T Software Architectures
Component interaction
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

2. Helsinki University of Technology, SoberIT
T Software Architectures
Outline
From decomposition to interaction
Interfaces
Patterns of interaction
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

3. Helsinki University of Technology, SoberIT
T Software Architectures
After decomposition
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

4. Starting point: decomposition
Helsinki University of Technology, SoberIT
T Software Architectures
Starting point: decomposition
Typically the first steps of designing your architecture involves coming up with an initial decomposition
Main structural view / functional view
Possible criteria for partitioning system into parts
Functionality
Quality concerns
Organisational and development concerns
Used technologies and frameworks
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

5. From decomposition to interaction
Decomposition is a vehicle for managing the complexity of the system and dividing system into parts that hide some overall aspects of the system
Therefore, interactions and interfaces between parts is as important than the parts themselves
Aim from “boxes-and-lines” to well-defined interfaces
Interfaces should represent the responsibilities of the components
Defining interfaces between system parts is often one of the major responsibilities for an architect (Rozanski & Woods, 2005)
© Varvana Myllärniemi, 2008

6. Motivation Well-designed interfaces improve
Maintainability: flexibility, testability, interoperability, etc.
Evaluation of architectural concerns from the design
Work allocation
Crucial when e.g. outsourcing or distributing development
Reusability
Especially important for software product families or when developing reusable components
© Varvana Myllärniemi, 2008

7. Helsinki University of Technology, SoberIT
T Software Architectures
Interfaces
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

8. A does not need to know anything about B
Interface
An interface separates what from how
The implementation of a service is not anymore tied to the abstraction of the service
Therefore, the consumer of the service is not anymore tied to a particular implementation
An interface can be an abstract empty class, an interface (e.g., Java, C++), or a collection of them A B A
Services B
A does not need to know anything about B
© Varvana Myllärniemi, 2008

9. Provided and required interfaces
A component can either provide services to other components, or it can require the usage of such services
Therefore, need to distinguish between
Interface signature
Provided interface of a component
Required interface of a component
Why should required interfaces be also defined?
Explicate out-bound dependencies of a component
© Varvana Myllärniemi, 2008

10. (Koskimies & Mikkonen, 2005)
Example in UML 2.0
Car
PowerSource
PowerSource
Engine
Required interface
Provided interface
Car
PowerSource
Engine
(Koskimies & Mikkonen, 2005)
© Varvana Myllärniemi, 2008

11. (Koskimies & Mikkonen, 2005)
Example in Java
interface PowerSource {
void start();
int temperature();
void stop(); }
class Engine implements PowerSource {
void start() { ... }
int temperature() { ... }
void stop() { ... }
...
class Car {
public void setPowerSource(PowerSource e) { ... }
Since Java has no built-in mechanism for required interfaces, need to agree on the means to bind a provided interface to a required interface.
© Varvana Myllärniemi, 2008
(Koskimies & Mikkonen, 2005)

12. Defining interfaces Defining interfaces is a surprisingly tricky issue
We can have two interfaces with matching services that do not create a working solution when combined
Some useful means of defining interfaces
Verbal explanations
Method signatures, public data structures, exceptions
Message / data descriptions
Protocol descriptions
Control or synchronisation stereotypes
<<notify>> <<blocking pull>> etc.
Pre- and post-conditions
Invariants
© Varvana Myllärniemi, 2008

13. Role-based interfaces
Idea: partition services provided by a component based on the role that the component acts in that interaction
Benefit: minimise client dependencies to services that they do not need
CustomerClient
Services
Server
AdminClient
CustomerClient
CustomerServices
Server
AdminClient
AdminServices
© Varvana Myllärniemi, 2008

14. Patterns of interaction
Helsinki University of Technology, SoberIT
T Software Architectures
Patterns of interaction
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008

15. Styles and patterns governing interaction
Inherently, architectural styles and patterns describe a set of roles that components act in
A pattern therefore dictates also component interaction
Original design patterns (GoF) aim at flexibility and maintainability by ensuring low coupling
Typically, by adding indirection between component using a service and component implementing a service
In the following, a couple of very typical patterns and styles that govern component interaction are described
Some are closer to lower-level design, but may be applicable also at a larger scale, or as part of a larger style
© Varvana Myllärniemi, 2008

16. Forwarding
A very typical technique in many design patterns is forwarding
Example patterns: Adapter, Proxy, Delegate etc.
Idea: component receiving a service request does not implement the service itself, but forwards it to another component
Pros: implementing component can be changed dynamically without service requestor even noticing
See example next slide
© Varvana Myllärniemi, 2008

17. (adapted from Koskimies & Mikkonen, 2005)
Forwarding example
BasicCustomerMgmt
OrderMgmt
CustomerMgmt
KeyCustomerMgmt
Chargable
getDiscount(int):int cumulateOrder(int)
OrderMgmt
CustomerMgmt
KeyCustomerMgmt
Chargable getDiscount(int):int cumulateOrder(int)
CustomerServices getDiscount(int):int
© Varvana Myllärniemi, 2008
(adapted from Koskimies & Mikkonen, 2005)

18. Façade
Client
Façade can be used for providing one interface to a component that consists of many subcomponents
E.g., when creating a layered architecture
Façade component transfers calls to its services to appropriate subcomponents
Forwarding to many subcomponents, creating a completely new interface
Services
Façade A B C
© Varvana Myllärniemi, 2008

19. Mediator
Problem: many interacting peer components with their own control and responsibilities
As a result, many-to-many dependencies
Idea: collect interaction to one mediating component that encapsulates collaboration
Easier to maintain collaboration
Difference between God antipattern and Mediator pattern?
God assumes control and responsibilities, Mediator just takes care of interaction between peer components M
© Varvana Myllärniemi, 2008

20. (Koskimies & Mikkonen, 2005)
Mediator example
ListBox
getSelected():string
Coordinator
handleChange(widget) createWidgets()
WListBox
TextField
setText(string)
Dialog Coordinator
WTextField
Example scenario:
Button
enable()
WList Box
Dialog Coordinator
WText Field
WButton
WButton
Widget
changed()
handleChange
getSelected
setText
enable
(Koskimies & Mikkonen, 2005)
© Varvana Myllärniemi, 2008

21. Proxy Forwarding with the same interface
Client cannot distinguish between proxy and the component implementing the provided service
Virtual proxy: want to postpone creation of the provider
Remote proxy: provider is behind a network, proxy marshalls request
Protection proxy: proxy grants or refuses access to the provider
Proxy
request() {
...
actual.request(); }
Client
actual
Services
request()
Provider
© Varvana Myllärniemi, 2008

22. Proxy example: postponed downloading
getRoute(from,to) {
...
if (!loaded) {
map = loadFromFile();
loaded = true; }
map.getRoute(from,to);
MapProxy
Navigator
map
Map
getName() getRoute(from,to)
CityMap
(Koskimies & Mikkonen, 2005)
© Varvana Myllärniemi, 2008

23. Event-based interaction
Dependencies between components can also be diminished using event-based communication
Requesting a service: sending an event
Providing a service: reacting to an event
Issues that need to be decided
The representation of an event
The mechanism for identifying interested parties
The mechanism for sending an event to interested parties
Is event sending blocking (synchronous) or non-blocking (asynchronous)
© Varvana Myllärniemi, 2008

24. Event-based interaction: Observer
Observer handle(event)
SourceImpl
ObserverImpl
Source register(observer)
unregister(observer)
Typical example: graphical user interfaces
Observer = ActionListener
SourceImpl = JButton
Source = AbstractButton
Applied in Model-View-Controller architectural style
© Varvana Myllärniemi, 2008

25. Adapter (a.k.a. wrapper)
So far, patterns have increased decoupling of components via introducing interfaces
Sometimes components cannot even know each others’ interfaces
Existing reusable components have incompatible interfaces
Components are implemented in different programming languages
Client
Adapter
Provider
Services request()
WrappedServices wrappedRequest()
wrappedRequest() {
...
actual.request(); }
© Varvana Myllärniemi, 2008

26. Using an adapter in event-based systems
An adapter can be used for integrating one or more independent components in an event-based system
Combination of an observer and an adapter
Example application: JavaBeans composition
Observer handle(event)
SourceImpl
ObsAdapter
TargetImpl
Services request()
Source register(observer)
unregister(observer)
handle(event) {
...
actual.request(); }
© Varvana Myllärniemi, 2008

27. Message-based interaction
Sometimes there may be a need to eliminate service-based interfaces altogether
E.g. want to later add completely new services to the system dynamically, without the need for shutdown or recompilation
Message-based systems
Interaction only through static interfaces that provide services for passing messages
Services themselves are encapsulated in the messages
Have become highly popular
Embedded systems, distributed systems, SOA
© Varvana Myllärniemi, 2008

28. Message-bus architecture
1) Create a message 2) Translate (optional) 3) Send to bus
6) Receive
7) Translate (optional)
8) React to message
App Comp
Adapter
App Comp
Adapter
Message
Message
App Comp
Adapter
App Comp
Adapter
4) Decide receivers 5) Send to them
Message
Messaging Bus
Message
App Comp
Adapter
App Comp
Adapter
Registered components
© Varvana Myllärniemi, 2008

29. Message-based interaction: pros and cons
Allows changing the number and identities of participating components dynamically
Allows adding new services dynamically
Fault-tolerance easy to implement
Cons
Complexity
Performance considerations
Creates easily implicit dependencies
Peer components start assuming each others’ properties
Program logic gets encoded in the messages
Often dependant on messaging technology
© Varvana Myllärniemi, 2008

30. Conclusions
Besides mere decomposition, an architecture should define also component interaction
Well-defined interfaces between components in the architecture is one of the major responsibilities of an architect
Many design patterns govern the interaction between components
However, most are oriented towards maintainability and flexibility by introducing low coupling
In some cases, this does not come without a cost
© Varvana Myllärniemi, 2008

31. Helsinki University of Technology, SoberIT
T Software Architectures
References
Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
Koskimies, Kai & Mikkonen, Tommi. Ohjelmistoarkkitehtuurit. Talentum Media, 2005.
Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005.
© Varvana Myllärniemi, 2008
© Varvana Myllärniemi, 2008