Architecture-based Evolution of Software Systems José Luiz Fiadeiro Architecture-based Evolution of...

Architecture-based Evolutionof Software Systems

José Luiz Fiadeiro

Architecture-based Evolutionof Software Systems

Luís Andrade

João Gouveia

Georgios Koutsoukos

Antónia Lopes

Michel Wermelinger

Architecture-based Evolution of Software SystemsArchitecture-based Evolution of Software Systems

"… 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.

Coping with changeCoping with change

We must

go on-line… How is the IS going to

cope?

At last, our routes can merge. How soon can our ISs

let us do it?

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

Well…How about moving to this new

technology?

Any ideas on how to incorporate this new

requirement?

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…


Architectures?Architectures?

Requirements

CODECODE


The challengeThe 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.


The CCC approachThe CCC approach

A confluence of contributions from

Coordination Languages and ModelsSeparation between “computation” and “coordination”

Software ArchitecturesConnectors as first-class citizens

Parallel Program DesignSuperposition



The Strategy

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



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



…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



The Strategy


• Reflect these levels in the architecture of the system;


AA BB

Co

mp

uta

tio

n L

ay

er

ComponentComponent

Layer containing the stable independent components

Layer containing the stable independent components


Co

ord

ina

tio

nL

aye

r

?

Coordination Contract

Coordination ContractLayer containing

coordination units controlling the interactions and behavior of basic components

Layer containing coordination units controlling the interactions and behavior of basic components

Contract Participant relationship

Contract Participant relationship

Change-oriented layered architecture

Strict-layering: Components are not aware of the contracts in place.

Strict-layering: Components are not aware of the contracts in place.



The Strategy


• Reflect these levels in the architecture of the system;

• Manage evolution according to the architecture.



The Configuration LayerServices that model business activities and through which the system can be configured, at run-time, to provide the response that is required.

Computation Resources

Coordination Resources

The running system

Configuration Layer

These services can be either invoked by authorized users or triggered by events (self-adaptation).



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)

(*)

(*)

(*) UML-compatible


OO is generating OO is generating legacylegacy

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.


““externalisation” ?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


Actions – guarded multiple assignmentsInput channel – observations over the environmentComponent can only read

Output channel – observations over the local stateEnvironment can only readChanging the business rule: Changing the business rule: credit is allowed on withdrawals up to a limitcredit is allowed on withdrawals up to a limit

prog VIP-accountout num, bal, cred: intin n: intdo dep: bal:=bal+n

[] wit: bal+cred≥n bal:=bal–n

prog Simple-accountout num, bal: intin n: intdo dep: bal:=bal+n[] wit: bal≥n bal:=bal–n

CommUnityCommUnity

A program in CommUnity

What is the relationship between the two programs?What is the relationship between the two programs?What is the relationship between the two programs?What is the relationship between the two programs?How can we characterise the change?How can we characterise the change?How can we characterise the change?How can we characterise the change?


SuperpositionSuperposition

prog Accountout num, bal: intin n: intdo dep: bal:=bal+n[] wit: bal:=bal–n


prog VIP-accountout num, bal, cred: intin n: intdo dep: bal:=bal+n

[] wit: bal+cred≥n bal:=bal–n

The change is intrusiveThe change is intrusiveThe change is intrusiveThe change is intrusive

The same applies to the VIP-account for a different business rule

The same applies to the VIP-account for a different business rule

Superposition morphism

Out1 Out2

In1 In2 + Out2

Act2 /Act1

Types are preservedGuards cannot be weakenedAssignments are preserved

Superposition morphism

Out1 Out2

In1 In2 + Out2

Act2 /Act1

Types are preservedGuards cannot be weakenedAssignments are preserved

This program is a superposition of a business rule over a more basic service

This program is a superposition of a business rule over a more basic service


Superposing the business rule

prog Regulatorin r1: int

r2: intdo reg: r1≥r2

prog Channelin a: int

b: intdo c

The regulator is capable of reading two values r1 and r2 from the environment and provides an action that blocks when r1<r2.

The regulator is capable of reading two values r1 and r2 from the environment and provides an action that blocks when r1<r2.

The superposition of the business rule can now be achieved by interconnecting the regulator and the base program.

The superposition of the business rule can now be achieved by interconnecting the regulator and the base program.

The interconnection itself is performed through a channel…The interconnection itself is performed through a channel…

and morphisms that allow the regulator to read the balance in r1

and morphisms that allow the regulator to read the balance in r1

and the requested amount in r2

and the requested amount in r2

and synchronise with withdrawals, blocking them when the values read do not satisfy the guard

and synchronise with withdrawals, blocking them when the values read do not satisfy the guard

The business rule can be externalised as a first-class object – a regulator.

The business rule can be externalised as a first-class object – a regulator.



Externalising the business ruleExternalising the business rule


Categorical semantics

progprog Simple-account Simple-accountoutout num, num, balbal:: intint inin nn:: intintdodo dep: dep:bal:=bal+n bal:=bal+n [] [] witwit::bal≥nbal≥nbal:=bal–nbal:=bal–n

progprog Regulator Regulatorinin r1r1:: intint

r2r2:: intintdodo regreg:: r1≥r2r1≥r2

progprog Account Accountoutout num, num, balbal:: intintinin nn:: intintdodo dep: dep: bal:=bal+n bal:=bal+n[][] witwit:: bal:=bal–n bal:=bal–n

progprog Channel Channelinin aa,,bb:: intintdodo cc

In the previous slide, we built a diagram in the category of CommUnity programs and superposition morphisms.

This diagram depicts a system configuration.

In the previous slide, we built a diagram in the category of CommUnity programs and superposition morphisms.

This diagram depicts a system configuration.

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”.

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.

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.


Execution semanticsExecution 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.


Evolving the business ruleEvolving the business rule


prog Channelin a,b: intdo c

prog VIP-accountout num, bal, cred: int in n: intdo dep:bal:=bal+n [] wit:bal+cred≥nbal:=bal–n

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

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 Regulatorin r1: int

r2: intdo reg: r1≥r2

prog VIP-Regulatorout cred: intin r1: int

r2: intdo reg: r1+cred≥r2



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


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.


Services (types) as coordination laws

coordination law standard-withdrawalpartners a:account-debit; c:customer-withdrawalrules

when c.withdrawal(n,a) with a.balance()≥n do a.debit(n);

end law

coordination interface account-debitimport types money;services balance():money; debit(a:money): post balance() = old balance()-aend interface

coordination interface customer-withdrawalimport types money, account;services owns(a:account):Booleanevents withdrawal(n:money;a:account)end interface

Interfaces that specify the nature of the components to which the law can be applied, not their identities.

The event that triggers the reactionAdditional guard for the joint action

What features components need to provide through their public interfaces to be partners of the 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


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…Binding may require adaptation…


AA BB

Co

mp

on

en

t L

aye

r

ComponentComponent

Coordination rule

Rule: when <trigger> with <condition> do <transaction>

Coordination rule

Rule: when <trigger> with <condition> do <transaction>

Co

ord

ina

tio

nL

aye

r

?

Coordination ContractCoordination Contract

Contract Partner binding (class-instance relationship)

Contract Partner binding (class-instance relationship)

Contracts may have operations and attributes like a normal class, but these are not public

Contracts may have operations and attributes like a normal class, but these are not public

Services as coordination contracts

Coordination contract =Coordination contract =instantiation of a coordination lawinstantiation of a coordination law


Using Coordination Contracts for Evolution

Customer Account

For a normal customerFor a normal customercontract Traditionalpartners x : Account; y : Customer;constraints ?owns(x,y)=TRUE;coordinationtp: when y.callsx.withdrawal(z)

with x.Balance() ≥ zdo x.withdrawal(z)

end contract

contract Traditionalpartners x : Account; y : Customer;constraints ?owns(x,y)=TRUE;coordinationtp: when y.callsx.withdrawal(z)

with x.Balance() ≥ zdo x.withdrawal(z)

end contract

Updating to VIP Updating to VIP

contract VIP partners x : Account; y : Customer;attributes Credit : Integer;constraints

?owns(x,y)=TRUE;coordinationtp: when y.callsx.withdrawal(z)

with x.Balance() + Credit() ≥ zdo x.withdrawal(z)

end contract

contract VIP partners x : Account; y : Customer;attributes Credit : Integer;constraints

?owns(x,y)=TRUE;coordinationtp: when y.callsx.withdrawal(z)

with x.Balance() + Credit() ≥ zdo x.withdrawal(z)

end contract

Semantic primitives for coordination


coordination context AccountManagement (c : customer)component types Account, Customercontract types Standard, VIPconstants maxCredit: money=10000servicessubscribe VIP(a: account,limit: money): pre exists Standard(c,a) and limit <= maxCredit post exists VIP(c,a) and VIP(c,a).credit = limit and not exists Standard(c,a)rulesautomaticVIP: when exists VIP(c,a) and avg.balance() < 100 post exists Standard(c,a) and not exists VIP(c,a)

coordination context AccountManagement (c : customer)component types Account, Customercontract types Standard, VIPconstants maxCredit: money=10000servicessubscribe VIP(a: account,limit: money): pre exists Standard(c,a) and limit <= maxCredit post exists VIP(c,a) and VIP(c,a).credit = limit and not exists Standard(c,a)rulesautomaticVIP: when exists VIP(c,a) and avg.balance() < 100 post exists Standard(c,a) and not exists VIP(c,a)

Ad-hoc operations (performed on demand by authorised users) – in this case,subscription of a VIP-package

Programmed operations (performed in reaction to triggers) – in this case, a VIP-Package is automatically removedwhen the balance goes below 100.

Semantic primitives for configuration


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.


A coordination design patternA coordination design pattern

Component

ISubjectProxy

<<abstract>>

SubjectToProxyAdapter

SubjectInterface

<<abstract>>

Client Component Request

Component Pattern

Request operation()

ISubjectrPartner

Contract- n Contract- 1

Coordination Pattern

chain of responsibility

0..*

<<abstract>>

operation() _operation()

Subject

_operation()

Ct_1_Subject Connector

Ct_n_Subject Connector


A coordination design pattern

operation()

ISubjectProxy

<< abstract>>

SubjectToProxyAdapter

SubjectInterface

<<abstract>>

Subject

Component

Client Component

Request

Component Pattern

Request

operation() _operation()

_operation()


Account coordination

Account Client Component Request

Account Pattern

Coordination Pattern

Account

IAccountProxy

<<abstract>>

AccountInterface

<<abstract>>

AccountToProxyAdapter

Flexible Package

VIP

chain of delegation

0..* IAccountPartner

<<abstract>>

Flexible Package Contract

AccountConnector

VIP Contract AccountConnector

Request

withdrawal() _withdrawal()

_withdrawal()

Request for withdrawal()


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.


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.


CDE - Coordination Development Environment

Context Setup

ContractDevelopment

Deployment

ComponentDevelopment

Testing

Run-TimeConfiguration

Software System

Component Layer

Coordination Layer

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


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.


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.


CDE - User interaction

Regist ComponentsContract Type Creation / Edition…

Deploy System CDETesting

Developer

System Assembler

Tester

Contract Type RegistrationContract CreationRun-time Configuration Definition

AnimationInterface

UserApplication

Interface

Trigger OperationObserve Object…

CDE-Rt

Deployed System

Development Run time


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…

Architectures for MobilityArchitectures for Mobility


Architectures for RequirementsArchitectures for Requirements

M A

fM fD

D

M/A/D, fD, G R


Programming interactionsProgramming interactions

Policy-drive, 2-tiered architectural reconfiguration

Configurationcontexts

CurrentMiddleware

CurrentConfiguration

Platformrules

Policyspecifications

Platformconstraints

Configurationresources

Platformresources Platform

consistency

Domainconsistency

Architecturalconsistency

Contextconsistency


Learn more…

about how these principles are being used in industry!

Visit www.atxsoftware.com


Learn more…

download the CDE www.atxsoftware.com/CDE

Buy the book

Software Design in Java 2Software Design in Java 2K.Lano, J.Fiadeiro and L.AndradeK.Lano, J.Fiadeiro and L.AndradePalgrave MacmillanPalgrave Macmillan


Learn more…

about

Buy the book


Software Specification and Design @ Leicester

Who we are: Nasreddine

AoumeurYifeng Chen Mohammad El-

RamlyJosé Luiz FiadeiroPiotr KosiuczenkoZhiming Liu Stephan Reiff-

Marganiec Irek Ulidowski

QuickTime™ and aGraphics decompressorare needed to see this picture.


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

Date post:	30-Mar-2015
Category:	Documents
Upload:	isabell-kirk
View:	214 times
Download:	1 times

Architecture-based Evolution of Software Systems José Luiz Fiadeiro Architecture-based Evolution of...

Documents