1. Separation of Concerns in the Design of Distributed Systems
Introduction to
Separation of Concerns in the Design of Distributed Systems
IPA Springdays on Middleware
3-5 April 2002
Michel Chaudron

2. Outline Challenges in Software Engineering Principal ideas behind
Aspect Orientation
Component-Based Development
Design by Transformation
Proposal for a design approach
Gamma + Coordination
Conclude

3. Challenges in Software Engineering
Complicating factors:
systems are very complex
everything changes
people make mistakes
Highly Desirable:
Easy development & maintenance of software

4. Design Methods for Software : Goals
Systems are very complex
help designer in conquering complexity
Everything changes
direct the designer towards flexible design
People make mistakes
support correctness of design
a priori – by design
a posteriori - verification
analysable

5. Aspect Oriented Programming 1
Observations of AOP:
Requirements address many types
of ‘aspects’ / ‘concerns’ of a system
Implementation languages
provide primitives at a
different level of abstraction
The design of implementation is complicated
by the interaction of different aspects
aspect = e.g. reliability, distribution, timeliness, security, …
aspects
implementation
Can we separate the design of aspects? And thereby simplify design?

6. Aspect Oriented Programming 2
Observation of AOP:
aspect can be cross-cutting
i.e. interact with/connect to many
other aspects of a system.
Symptom
implementation of aspects is scattered

7. Aspect Oriented Programming 3
Scattered implementations complicate
maintenance and evolution
program
dkjshdkfh s
sdfkj
hsdjfk
kjshdf
Sdkjfhksdhf
Jksdjd
djjjdjdjdjs
dkjshdkfh s
sdfkj
hsdjfk
kjshdf
Sdkjfhksdhf
Jksdjd
djjjdjdjdjs
Aspect 2
Aspect 1
dkjshdkfh s
sdfkj
hsdjfk
kjshdf
Sdkjfhksdhf
Jksdjd
djjjdjdjdjs
dkjshdkfh s
sdfkj
hsdjfk
kjshdf
Sdkjfhksdhf
Jksdjd
djjjdjdjdjs

8. Requirements for an Aspect- Oriented SW Development Method
 Systems can be decomposed in a
number of aspects
 Aspects can be changed independently
 SW Engineer is relieved from designing
interaction between aspects

9. Component-Based Development
Systems can be assembled from components
Components are units of independent
deployment & replacement (i.e. change)
 no coupling between components
Trend towards run-time replacements
Components encapulate change (design decision / requirement)

10. Design by Correctness Preserving Transformation
Start with a high-level specification
traditionally: focus on correctness
A transformation provably preserves
some relevant properties, but adds details
that are useful for efficient implementation
Mistakes are avoided
(as long as the designer follows ‘the rules’)

11. Proposed Approach systems are very complex  aspect-oriented
everything changes  component-based
people make mistakes  transformational

12. Implementation Domain
Proposed Approach 2
Design Domain
Implementation Domain
refine
Aspect 1
components
Aspect 2
weave
Aspect 3
change
middleware
Aspect n

13. How Can We Realize This? Develop a way of modelling systems such that
aspects can be separated
aspects can be weaved into an implementation
aspects can be changed dynamically
Develop techniques for specification &
transformation of aspects
Develop techniques for weaving aspects
Ad.2. Weaving: any subset of aspects can be turned into an implementation
=> there should be default values for aspects
Ad.3. Change dynamically: binding (weaving) of aspects should happen during run-time
Q: Which aspects can be treated separately?
A: Unknown; but let’s see how far we come …

14. Inspiration for Separation from Coordination
Separate Computation from Coordination
Computation ( What / Functionality )
what a system computes
the relation between input and output
without reference to internals of computation
Coordination ( How / Behaviour )
how a system computes
e.g. ordering, timing, multiplicity &
synchronization of actions

15. Gamma Model 1 Claim: Defines Functionality
Abstracts from other aspects
Coordination
Timeliness
Distribution

16. Gamma Model 2 Gamma specification = set of rules
sieve : x,y  x  x divides y
match with elements from multiset,
then replace with provided 6 2 8 5 3 4 7 9
Rules are executed
in arbitrary order

17. Gamma Model 3 Traffic Lights( id, lightColor, lightStatus )1 2
Traffic Lights( id, lightColor, lightStatus ) …
Initial Configuration
InitMultiset:
{ for all id : (id, red, on), (id, yellow, off), (id, green, off) }
Program
RedOn(id): (id,red,x)  (id,red,on)
RedOff(id): (id,red,x)  (id,red,off)
YellowOn(id) …
YellowOff(id) …
GreenOn(id) …
GreenOff(id) …

18. Extension with Coordination
Example of schedule language syntax
conditional r  s [ t ]
sequential s1; s2
parallel s1||s2
… and some more

19. Example Coordination Strategies
Single Traffic Light
Program:
RedOn, RedOff, YellowOn, YellowOff, GreenOn, GreenOff
Schedules:
NL = RedOn; RedOff;
GreenOn; GreenOff;
YellowOn; YellowOff; NL
IT = RedOn; RedOff;
GreenOn; YellowOn;
GreenOff || YellowOff; IT

20. Example Coordination Strategies
Single Traffic Light
Program:
RedOn, RedOff, YellowOn, YellowOff, GreenOn, GreenOff
Schedules:
NL = RedOn; RedOff;
GreenOn; GreenOff;
YellowOn; YellowOff; NL
IT = RedOn; RedOff;
GreenOn; YellowOn;
GreenOff || YellowOff; IT
Extension with Time
 See Mohammad Mousavi’s presentation

21. Implementation 1 Gamma is a design model
decoupling of actions in space and time
for distributed system, use
publish/subscribe interaction

22. Implementation 2 Cooperating Aspect Managers
Distribution  see Giovanni Russello
Scheduling / Synchronization
Replication / Consistency
Need: middleware that manages &
integrates these aspects

23. Summary systems are very complex  aspect-oriented
everything changes  component-based
people make mistakes  transformational

24. Implementation Domain
Proposed Approach
Design Domain
Implementation Domain
Gamma: R1, R2, R3 R1 R2 R3 S S S
Coordination: S T T T
weave D D D
Timing: T T D S
publ/subscr
Distribution: D

25. Please watch
Mohammad & Giovanni
for technical details
Thank You