Architecture-based Evolution of Software Systems

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

2. 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?

3. CODE CODE Architectures? Requirements

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

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

6. The CCC approach • The Strategy • Recognize that change in the application domain occurs at different levels;

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

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

9. 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;

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

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

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

13. (*) (*) (*) 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)

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

15. “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

16. 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?

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

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

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

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

21. prog VIP-account out num, bal, cred:int in 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

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

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

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

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

26. 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)

27. Updating to VIP contract VIP partnersx : Account; y : Customer; attributesCredit : Integer; constraints ?owns(x,y)=TRUE; coordination tp: when  y.callsx.withdrawal(z) with x.Balance() + Credit() ≥ z do x.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

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

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

30. A coordination design pattern

31. A coordination design pattern

32. Account coordination

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

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

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

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

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

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

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

40. M A D fD fM Architectures for Requirements M/A/D, fD, G  R

41. Programming interactions • Policy-drive, 2-tiered architectural reconfiguration

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

43. Software Design in Java 2K.Lano, J.Fiadeiro and L.AndradePalgrave Macmillan Learn more… • download the CDE www.atxsoftware.com/CDE • Buy the book

44. Learn more… • about • Buy the book

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

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