Coordination:

1
Architecture-based Evolutionof Software Systems
Architecture-based Evolutionof Software Systems
José Luiz Fiadeiro
2
Coping with change

• In Business Systems today, change is the rule of
  the game

• The Web is only fuelling the rate of change
  (B2C, B2B, P2P,)

• Critical infrastructures depend on the ability to
  react to failure by reconfiguring themselves
  (self-healing)

• The real-time economy
• Complexity is now on evolution

3
Coping with change

• In Business Systems today, change is the rule of
  the game

• The Web is only fuelling the rate of change
  (B2C, B2B, P2P,)

" the ability to change is now more important
than the ability to create e-commerce systems
in the first place. Change becomes a first-class
design goal and requires business and technology
architecture whose components can be added,
modified, replaced and reconfigured". P.Finger,
"Component-Based Frameworks for E-Commerce",
Communications of the ACM 43(10), 2000, 61-66.

• Critical infrastructures depend on the ability to
  react to failure by reconfiguring themselves
  (self-healing)

• The real-time economy
• Complexity is now on evolution

Any ideas on how to incorporate this new
requirement?
4
Architectures?
Requirements
5
The challenge

• Reflect on the (run-time) architecture of the
  system the different levels of change that can
  take place in the application domain.
• Support evolution through dynamic
  reconfiguration, without interruption of service,
  minimising impact on the global system.

6
The CCC approach

• A confluence of contributions from
• Coordination Languages and ModelsSeparation
  between computation and coordination
• Software ArchitecturesConnectors as first-class
  citizens
• Parallel Program DesignSuperposition

7
The CCC approach

• The Strategy

• Recognize that change in the application domain
  occurs at different levels

8
The CCC approach

• Distinguish Computation Resources

• Units that model core business/domain entities
  and provide services through computations
  performed locally

• These tend to be stable components, for which
  modifications imply major re-engineering

9
The CCC approach

• from Coordination Resources

Units that model volatile business rules and
processes and can be superposed, at run time, on
the core units to

• coordinate their interactions

• regulate their behaviour

• adapt their behaviour

• monitor their behaviour

10
The CCC approach

• The Strategy

• Recognize that change in the application domain
  occurs at different levels

• Reflect these levels in the architecture of the
  system

11
The CCC approach

• Change-oriented layered architecture

12
The CCC approach

• The Strategy

• Recognize that change in the application domain
  occurs at different levels

• Reflect these levels in the architecture of the
  system

• Manage evolution according to the architecture.

13
The CCC approach

• The Configuration Layer

Services that model business activities and
through which the system can be configured, at
run-time, to provide the response that is
required.
These services can be either invoked by
authorized users or triggered by events
(self-adaptation).

• Computation
• Resources

• Coordination
• Resources

The running system
14
The CCC approach

• Semantic primitives for Coordination

• Semantic primitives for Configuration

• Full mathematical semantics

• A micro-architecture for deployment over
  platforms for component-based development

• An instantiation of this micro-architecture for
  Java components the Coordination Development
  Environment (CDE)

15
OO is generating legacy

• What is intrinsically wrong with OO

• Feature calling, the basic mechanism through
  which objects interact, is identity-based
  objects call specific features of specific
  objects (clientship)

• As a result, any change on the interactions is
  intrusive on the code of the object.

• We propose a way for interactions to be
  externalised and handled as first-class citizens.

16
externalisation ?

• Superposition captured through morphisms and
  universal constructions (colimits)
• Configurations modelled as diagrams, and
  reconfiguration through graph-rewriting
• Separation between computation and coordination
  captured through functors that map systems to
  coordination interfaces

17
Changing the business rule credit is allowed on
withdrawals up to a limit
CommUnity
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
A program in CommUnity
How can we characterise the change?
What is the relationship between the two programs?

• prog VIP-account
• out num, bal, cred int
• in n int
• do dep ? balbaln
• wit balcredn ? balbaln

18
Superposition
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
This program is a superposition of a business
rule over a more basic service
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
Superposition morphismOut1 ?Out2In1 ? In2
Out2Act2 /?Act1Types are preservedGuards
cannot be weakenedAssignments are preserved
The change is intrusive
prog VIP-account out num, bal, cred int in n
int do dep ? balbaln wit balcredn ?
balbaln
The same applies to the VIP-account for a
different business rule
19
Superposing the business rule
Externalising the business rule
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
prog Regulator in  r1 int   r2 int do reg
r1r2 ?
The business rule can be externalised as a
first-class object a regulator.
The superposition of the business rule can now be
achieved by interconnecting the regulator and the
base program.
The regulator is capable of reading two values r1
and r2 from the environment and provides an
action that blocks when r1ltr2.
and morphisms that allow the regulator to read
the balance in r1
and the requested amount in r2
and synchronise with withdrawals, blocking them
when the values read do not satisfy the guard
prog Channel in  a int   b int do  c
The interconnection itself is performed through a
channel
20
Categorical semantics
The semantics of the configuration is the
parallel composition of its components as
interconnected through the morphisms.Intuitively
, this should correspond to the original
simple-account.
Parallel composition is computed through a
categorical construction a colimit of the
configuration diagram.For diagrams of this
particular form, a colimit is called a pushout.
In the previous slide, we built a diagram in the
category of CommUnity programs and superposition
morphisms.This diagram depicts a system
configuration.
21
Execution semantics

• Each action of the channel defines a
  synchronisation set and provides an explicit
  representation of an interaction within the system

• Each synchronisation set is executed atomically

• and is guarded by the conjunction of the guards
  of the participating actions

• and performs the parallel composition of the
  assignments.

22
Evolving the business rule
Changing the business rule now is as simple as
reconfiguring the system by replacing the
regulator. It does not require any changes to be
performed on Account and does not interfere with
the rest of the system
prog VIP-Regulator out cred int in  r1
int   r2 int do reg r1credr2 ?
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
prog Regulator in  r1 int   r2 int do reg
r1r2 ?
prog Channel in  a,b int do  c
23
The CCC approach

• A confluence of contributions from
• Coordination Languages and ModelsSeparation
  between computation and coordination
• Software ArchitecturesConnectors as first-class
  citizens
• Parallel Program DesignSuperposition
• Reconfigurable Distributed SystemsDynamic
  (run-time) reconfiguration

24
Semantic primitives for coordination

• Coordination laws that provide abstract models of
  services in terms of reactions to be performed
  upon detection of triggers.

• Coordination interfaces that identify the types
  of components that can instantiate the service as
  a law.

• Coordination contracts that provide services as
  concrete coordination units obtained by
  instantiating laws through the binding of the
  interfaces to the public interfaces of given
  components.

25
Services (types) as coordination laws
coordination law standard-withdrawal partners
aaccount-debit ccustomer-withdrawal rul
es when c.withdrawal(n,a)
with a.balance()n do a.debit(n) end law
Operations that can be called within the law as
part of joint actions
Events that need to be observed to provide
triggers .
The reaction a joint action in which the
partners and local actions of the law can
participate executed as a synchronisation set
26
Just-in-time integration
coordination law standard-withdrawal
coordination interface account-debit
coordination interface customer-withdrawal
Bindings of the coordination interfaces (formal
parameters) to specific classes of the
application
Object class account
Object class customer .
Binding may require adaptation
27
Services as coordination contracts
Coordination contract instantiation of a
coordination law
Contracts may have operations and attributes like
a normal class, but these are not public
Contract Partner binding (class-instance
relationship)
28
Semantic primitives for coordination

• Using Coordination Contracts for Evolution

Customer
Account
For a normal customer
contract Traditional partners x Account y
Customer constraints ?owns(x,y)TRUE coordinatio
n tp when  y.callsx.withdrawal(z) with  x.Balan
ce() z do  x.withdrawal(z) end contract
29
Semantic primitives for configuration
Ad-hoc operations (performed on demand by
authorised users) in this case, subscription of
a VIP-package
coordination context AccountManagement (c
customer) component types Account,
Customer contract types Standard, VIP constants
maxCredit money10000 services subscribe VIP(a
account,limit money) pre exists
Standard(c,a) and limit lt maxCredit post
exists VIP(c,a) and VIP(c,a).credit limit
and not exists Standard(c,a) rules automa
ticVIP when exists VIP(c,a) and
avg.balance() lt 100 post exists Standard(c,a)
and not exists VIP(c,a)
Programmed operations (performed in reaction to
triggers) in this case, a VIP- Package is
automatically removed when the balance goes below
100.
30
A micro-architecture for coordination

• None of the standards for component-based
  software development CORBA, JavaBeans, COM
  can support superposition as a first-class
  mechanism.
• Because of this, we propose our solution as a
  micro-architecture that exploits polymorphism and
  subtyping, and is based on well known design
  patterns, such as the Chain of Responsibility,
  and the Proxy or Surrogate.

31
A coordination design pattern
32
A coordination design pattern
33
Account coordination
34
Operational view

• Before the subject gives rights to the real
  object to execute the request, it intercepts the
  request and gives right to the contract to decide
  if the request is valid and perform other
  actions.
• This allows us to impose other contractual
  obligations on the interaction between the caller
  and the callee.

35
Operational view

• On the other hand, it allows the contract to
  perform other actions before or after the real
  object executes the request.
• Only if the contract authorises can the connector
  ask the involved objects to execute and commit,
  or undo execution because of violation of
  post-conditions established by the contract.

36
CDE - Coordination Development Environment

• A development and run-time environment for
  layered coordination systems
• The coordination layer, defining the more
  volatile part of a system, is built over the
  component layer, the stable parts of the business

Software System
Context Setup
Contract Development
Deployment
Run-Time Configuration
Coordination Layer
Testing
Component Layer
Component Development
37
CDE Development Activities

• Registration components are registered as
  candidates for coordination.
• Edition Contract types are defined connecting
  registered components. Coordination rules are
  defined on those contracts.
• Deployment the code necessary to implement the
  coordinated components and the contract semantics
  in the final system is produced according to the
  contract design pattern.

38
CDE Run time Activities

• Animation facilities are provided allowing
  testing/prototyping of contract semantics
• Registration contract types are registered in
  the system.
• Configuration contracts are configured in the
  system (enabling/disabling rules, priorities,
  etc)
• Evolution concrete contracts are created between
  specific system elements, regulating its
  behaviour.

39
CDE - User interaction
Run time
Development
Developer
Contract Type Registration Contract
Creation Run-time Configuration Definition
Regist Components Contract Type Creation /
Edition
CDE-Rt
System Assembler
Deployed System
Deploy System
Trigger Operation Observe Object
CDE
Testing
User Application Interface
Animation Interface
Tester
40
Architectures for Mobility

• This architectural approach relies on the fact
  that
• individual components can perform the
  computations that are required at the locations
  in which they are placed,
• the coordination mechanisms put in place through
  connectors can be made effective across the
  "wires" that link components in the underlying
  communication network.
• In the context of mobile systems

41
Architectures for Requirements
M/A/D, fD, G ? R
42
Programming interactions

• Policy-drive, 2-tiered architectural
  reconfiguration

43
Learn more

• about how these principles are being used in
  industry!
• Visit www.atxsoftware.com

44
Learn more

• download the CDE www.atxsoftware.com/CDE
• Buy the book

45
Learn more

• about
• Buy the book

46
Software Specification and Design _at_ Leicester
Who we are Nasreddine Aoumeur Yifeng Chen
Mohammad El-Ramly José Luiz Fiadeiro Piotr
Kosiuczenko Zhiming Liu Stephan Reiff-Marganiec
Irek Ulidowski
47
www.cs.le.ac.uk/SoftSD

• What we do
• component-based and object-oriented methods
• service-oriented system development
• architectural aspects of system construction and
  evolution
• generative and re-engineering techniques
• verification, testing and analysis techniques
• real-time, embedded, and reactive system
  specification and design