2. Architecture-based Evolution of Software Systems José Luiz Fiadeiro Architecture-based Evolution of Software Systems Luís Andrade João Gouveia Georgios Koutsoukos Antónia Lopes Michel Wermelinger

3. Architecture-based Evolution of Software Systems Coping with change In Business Systems today, change is the rule of the game… Critical infrastructures depend on the ability to react to failure by reconfiguring themselves (self-healing)… The real-time economy… Complexity is now on evolution… The Web is only fuelling the rate of change… (B2C, B2B, P2P,…)

4. Architecture-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 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? n 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? n The Web is only fuelling the rate of change… (B2C, B2B, P2P,…) n Critical infrastructures depend on the ability to react to failure by reconfiguring themselves (self-healing)… n The real-time economy… Complexity is now on evolution…

5. Architecture-based Evolution of Software Systems Architectures? Requirements CODE

6. Architecture-based Evolution of Software Systems 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.

7. Architecture-based Evolution of Software Systems The CCC approach A confluence of contributions from Coordination Languages and Models Separation between computation and coordination Software Architectures Connectors as first-class citizens Parallel Program Design Superposition

8. Architecture-based Evolution of Software Systems The CCC approach n The Strategy Recognize that change in the application domain occurs at different levels;

9. Architecture-based Evolution of Software Systems 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

10. Architecture-based Evolution of Software Systems 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

11. Architecture-based Evolution of Software Systems The CCC approach n The Strategy Recognize that change in the application domain occurs at different levels; Reflect these levels in the architecture of the system;

12. Architecture-based Evolution of Software Systems A A B B Computation Layer Component Layer containing the stable independent components The CCC approach Coordination Layer ? Coordination Contract Layer containing coordination units controlling the interactions and behavior of basic components Contract Participant relationship Change-oriented layered architecture Strict-layering: Components are not aware of the contracts in place.

13. Architecture-based Evolution of Software Systems The CCC approach n 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.

14. Architecture-based Evolution of Software Systems 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. Computation Resources Coordination Resources The running system Configuration Layer These services can be either invoked by authorized users or triggered by events (self-adaptation).

15. Architecture-based Evolution of Software Systems The CCC approach n Semantic primitives for Coordination n Semantic primitives for Configuration n Full mathematical semantics n A micro-architecture for deployment over platforms for component-based development n An instantiation of this micro-architecture for Java components – the Coordination Development Environment (CDE) (*) (*) UML-compatible

16. Architecture-based Evolution of Software Systems OO is generating legacy n 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. n We propose a way for interactions to be externalised and handled as first-class citizens.

17. Architecture-based Evolution of Software Systems 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

18. Architecture-based Evolution of Software Systems 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 Changing the business rule: credit is allowed on withdrawals up to a limit prog VIP-account out num, bal, cred: int in n: int do dep: bal:=bal+n []wit: bal+credn bal:=bal–n prog Simple-account out num, bal: int in n: int do dep: bal:=bal+n [] wit: baln bal:=bal–n CommUnity A program in CommUnity What is the relationship between the two programs? How can we characterise the change?

19. Architecture-based Evolution of Software Systems Superposition 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: baln bal:=bal–n prog VIP-account out num, bal, cred: int in n: int do dep: bal:=bal+n []wit: bal+credn bal:=bal–n The change is intrusive The same applies to the VIP-account for a different business rule Superposition morphism Out 1 Out 2 In 1 In 2 + Out 2 Act 2 / Act 1 Types are preserved Guards cannot be weakened Assignments are preserved This program is a superposition of a business rule over a more basic service

20. Architecture-based Evolution of Software Systems Superposing the business rule prog Regulator in r1: int r2: int do reg: r1r2 prog Channel in a: int b: int do 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 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… 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 The business rule can be externalised as a first-class object – a regulator. prog Simple-account out num, bal: int in n: int do dep: bal:=bal+n [] wit: baln bal:=bal–n prog Account out num, bal: int in n: int do dep: bal:=bal+n [] wit: bal:=bal–n Externalising the business rule

21. Architecture-based Evolution of Software Systems Categorical semantics prog Simple-account out num, bal: int in n: int do dep: bal:=bal+n [] wit:baln bal:=bal–n prog Regulator in r1: int r2: int r2: int do reg: r1r2 do reg: r1r2 prog Account out num, bal: int in n: int do dep: bal:=bal+n [] wit: bal:=bal–n prog Channel in a,b: int do c 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. 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.

22. Architecture-based Evolution of Software Systems 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.

23. Architecture-based Evolution of Software Systems Evolving the business rule prog Account out num, bal: int in n: int do dep: bal:=bal+n [] wit: bal:=bal–n prog Channel in a,b: int do c prog VIP-account out num, bal, cred: intin n: int do dep: bal:=bal+n [] wit:bal+credn bal:=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 prog Regulator in r1: int r2: int do reg: r1r2 prog VIP-Regulator out cred: int in r1: int r2: int do reg: r1+credr2

24. Architecture-based Evolution of Software Systems The CCC approach A confluence of contributions from n Coordination Languages and Models Separation between computation and coordination n Software Architectures Connectors as first-class citizens n Parallel Program Design Superposition n Reconfigurable Distributed Systems Dynamic (run-time) reconfiguration

25. Architecture-based Evolution of Software Systems 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.

26. Architecture-based Evolution of Software Systems 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 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 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

27. Architecture-based Evolution of Software Systems 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…

28. Architecture-based Evolution of Software Systems A A B B Component Layer Component Coordination rule Rule: when with do Coordination rule Rule: when with do Coordination Layer ? Coordination Contract Contract Partner binding (class-instance relationship) Contracts may have operations and attributes like a normal class, but these are not public Services as coordination contracts Coordination contract = instantiation of a coordination law

29. Architecture-based Evolution of Software Systems Using Coordination Contracts for Evolution CustomerAccount For a normal customer contract Traditional partners x : Account; y : Customer; constraints ?owns(x,y)=TRUE; coordination tp:when y.callsx.withdrawal(z) with x.Balance() z do x.withdrawal(z) end contract contract Traditional partners x : Account; y : Customer; constraints ?owns(x,y)=TRUE; coordination tp:when y.callsx.withdrawal(z) with x.Balance() z do x.withdrawal(z) end contract Updating to VIP contract VIP partners x : Account; y : Customer; attributes Credit : Integer; constraints ?owns(x,y)=TRUE; coordination tp:when y.callsx.withdrawal(z) withx.Balance() + Credit() z dox.withdrawal(z) end contract contract VIP partners x : Account; y : Customer; attributes Credit : Integer; constraints ?owns(x,y)=TRUE; coordination tp:when y.callsx.withdrawal(z) withx.Balance() + Credit() z dox.withdrawal(z) end contract Semantic primitives for coordination

30. Architecture-based Evolution of Software Systems coordination context AccountManagement (c : customer) component types Account, 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) coordination context AccountManagement (c : customer) component types Account, 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) 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 removed when the balance goes below 100. Semantic primitives for configuration

31. Architecture-based Evolution of Software Systems 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.

32. Architecture-based Evolution of Software Systems A coordination design pattern

33. Architecture-based Evolution of Software Systems A coordination design pattern

34. Architecture-based Evolution of Software Systems Account coordination

35. Architecture-based Evolution of Software Systems 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.

36. Architecture-based Evolution of Software Systems 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.

37. Architecture-based Evolution of Software Systems CDE - Coordination Development Environment Context Setup Contract Development Deployment Component Development Testing Run-Time Configuration 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

38. Architecture-based Evolution of Software Systems 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.

39. Architecture-based Evolution of Software Systems 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.

40. Architecture-based Evolution of Software Systems CDE - User interaction Regist Components Contract Type Creation / Edition … Deploy System CDE Testing Developer System Assembler Tester Contract Type Registration Contract Creation Run-time Configuration Definition Animation Interface User Application Interface Trigger Operation Observe Object … CDE-Rt Deployed System Development Run time

41. Architecture-based Evolution of Software Systems 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 Mobility

42. Architecture-based Evolution of Software Systems Architectures for Requirements M A fM fD D M/A/D, fD, G R

43. Architecture-based Evolution of Software Systems Programming interactions Policy-drive, 2-tiered architectural reconfiguration

44. Architecture-based Evolution of Software Systems Learn more… n about how these principles are being used in industry! n Visit www.atxsoftware.com

45. Architecture-based Evolution of Software Systems Learn more… n download the CDE www.atxsoftware.com/CDE n Buy the book Software Design in Java 2 K.Lano, J.Fiadeiro and L.Andrade Palgrave Macmillan

46. Architecture-based Evolution of Software Systems Learn more… n about n Buy the book

47. Architecture-based Evolution of Software Systems 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

48. Architecture-based Evolution of Software Systems 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