Luís Andrade
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Architecture-based Evolution of Software Systems PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

Luís Andrade João Gouveia Georgios Koutsoukos Antónia Lopes Michel Wermelinger. Architecture-based Evolution of Software Systems. Architecture-based Evolution of Software Systems. José Luiz Fiadeiro. We must go on-line… How is the IS going to cope?. At last, our routes can

Download Presentation

Architecture-based Evolution of Software Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architecture based evolution of software systems

Luís Andrade

João Gouveia

Georgios Koutsoukos

Antónia Lopes

Michel Wermelinger

Architecture-based Evolutionof Software Systems

Architecture-based Evolutionof Software Systems

José Luiz Fiadeiro


Coping 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?

Well…How about moving to this new technology?

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?


Architectures

CODE

CODE

Architectures?

Requirements


The challenge

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.


The ccc approach

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


The ccc approach1

The CCC approach

  • The Strategy

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


The ccc approach2

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


The ccc approach3

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


The ccc approach4

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;


The ccc approach5

Coordination Contract

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

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

Coordination

Layer

?

Contract Participant relationship

Computation Layer

A

B

Layer containing the stable independent components

Component

The CCC approach

  • Change-oriented layered architecture


The ccc approach6

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.


The ccc approach7

ConfigurationLayer

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


The ccc approach8

(*)

(*)

(*) UML-compatible

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)


Oo is generating legacy

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.


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


Changing the business rule credit is allowed on withdrawals up to a limit

Actions – guarded multiple assignments

Input channel – observations over the environment

Component can only read

Output channel – observations over the local state

Environment can only read

CommUnity

Changing the business rule: credit is allowed on withdrawals up to a limit

prog Simple-account

out num, bal:int

in n:int

do dep: bal:=bal+n

[] wit: bal≥n  bal:=bal–n

prog VIP-account

out num, bal, cred:int

in n:int

do dep: bal:=bal+n

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

A program in CommUnity

How can we characterise the change?

What is the relationship between the two programs?


Superposition

Superposition

prog Simple-account

out num, bal:int

in n:int

do dep: bal:=bal+n

[] wit: bal≥n  bal:=bal–n

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: bal:=bal+n

[] wit: bal:=bal–n

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: bal:=bal+n

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

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


Superposing the business rule

Superposing the business rule

Externalising the business rule

prog Account

out num, bal:int

in n:int

do dep: bal:=bal+n

[] wit: bal:=bal–n

prog Simple-account

out num, bal:int

in n:int

do dep: bal:=bal+n

[] wit: bal≥n  bal:=bal–n

prog Regulator

inr1:int

  r2:int

doreg: r1≥r2 

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 r1<r2.

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…


Categorical semantics

prog Simple-account

out num, bal:int inn:int

do dep:bal:=bal+n [] wit:bal≥nbal:=bal–n

prog Regulator

inr1:int

r2:int

doreg:r1≥r2

prog Account

out num, bal:int

inn:int

do dep: bal:=bal+n

[]wit: bal:=bal–n

prog Channel

ina,b:int

doc

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.


Execution semantics

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.


Evolving the business rule

prog VIP-account

out num, bal, cred:intin n:int

do dep:bal:=bal+n [] wit:bal+cred≥nbal:=bal–n

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

outcred:int

in  r1:int

  r2:int

do reg:r1+cred≥r2 

prog Account

out num, bal:int

in n:int

do dep: bal:=bal+n

[] wit: bal:=bal–n

prog Regulator

in  r1: int

  r2: int

do reg: r1≥r2

prog Channel

in  a,b:int

do  c


The ccc approach9

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


Semantic primitives for coordination

Semantic primitives for coordination

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

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

  • Coordinationcontractsthat 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

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

What features components need to provide through their public interfaces to be partners of the law

The event that triggers the reaction

Additional guard for the joint action

coordination interface

account-debit

import types

money;

services

balance():money;

debit(a:money): post balance()

= old balance()-a

end interface

coordination interface

customer-withdrawal

import types

money, account;

services

owns(a:account):Boolean

events

withdrawal(n:money;a:account)

end interface

Services (types) as coordination laws

coordination law standard-withdrawal

partners

a:account-debit;

c:customer-withdrawal

rules

whenc.withdrawal(n,a)

witha.balance()≥n

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


Just in time integration

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…


Services as coordination contracts

Coordination rule

Rule: when <trigger>

with <condition>

do <transaction>

Coordination Contract

Coordination

Layer

?

Component Layer

A

B

Component

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)


Semantic primitives for coordination1

Updating to VIP

contract VIP

partnersx : Account; y : Customer;

attributesCredit : Integer;

constraints

?owns(x,y)=TRUE;

coordination

tp:when y.callsx.withdrawal(z)

withx.Balance() + Credit() ≥ z

dox.withdrawal(z)

endcontract

Semantic primitives for coordination

  • Using Coordination Contracts for Evolution

Customer

Account

For a normal customer

contractTraditional

partnersx : Account; y : Customer;

constraints?owns(x,y)=TRUE;

coordination

tp:when y.callsx.withdrawal(z)

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

endcontract


Semantic primitives for configuration

Semantic primitives for configuration

Ad-hoc operations (performed on demand

by authorised users) – in this case,

subscription of a VIP-package

coordination contextAccountManagement (c : customer)

component typesAccount, Customer

contract types Standard, VIP

constants maxCredit: money=10000

services

subscribe 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)

rules

automaticVIP:

when exists VIP(c,a) and avg.balance() < 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.


A micro architecture for coordination

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 pattern

A coordination design pattern


A coordination design pattern1

A coordination design pattern


Account coordination

Account coordination


Operational view

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 view1

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

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 - Coordination Development Environment

Software System

Context Setup

Contract

Development

Deployment

Run-Time

Configuration

Coordination Layer

Testing

Component Layer

Component

Development


Cde development activities

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

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

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


Architectures for mobility

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…


Architectures for requirements

M

A

D

fD

fM

Architectures for Requirements

M/A/D, fD, G  R


Programming interactions

Programming interactions

  • Policy-drive, 2-tiered architectural reconfiguration


Learn more

Learn more…

  • about how these principles are being used in industry!

  • Visit www.atxsoftware.com


Learn more1

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

Learn more…

  • download the CDE www.atxsoftware.com/CDE

  • Buy the book


Learn more2

Learn more…

  • about

  • Buy the book


Software specification and design @ leicester

Software Specification and Design @ Leicester

Who we are:

Nasreddine Aoumeur

Yifeng Chen

Mohammad El-Ramly

José Luiz Fiadeiro

Piotr Kosiuczenko

Zhiming Liu

Stephan Reiff-Marganiec

Irek Ulidowski


Www cs le ac uk softsd

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


  • Login