Architecturebased Evolution of Software Systems Lus Andrade Joo

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

Coping with change n In Business Systems today, change is the rule of the game… n The Web is only fuelling the rate of change… about "… the ability to. Well…How change is nowmoving more important than the (B 2 C, B 2 B, P 2 P, …) to this new technology? ability to create [e-commerce] systems in the first place. n Critical infrastructures depend on the ability to react to Change becomes a first-class design goal and requires We must At last, our routes can go on-line… business and technologythemselves architecture whose components merge. How sooniscan our ISs failure by reconfiguring (self-healing)… the IS going let usto do it? can be added, modified, replaced and reconfigured". cope? n The real-time economy… Any ideas on how to incorporate this new requirement? P. Finger, "Component-Based Frameworks for E-Commerce", Communications of the ACM 43(10), 2000, 61 -66. Complexity is now on evolution… Architecture-based Evolution of Software Systems

Architectures? Requirements CODE 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. 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 Architecture-based Evolution of Software Systems

The CCC approach n The Strategy • Recognize that change in the application domain occurs at different levels; 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 reengineering 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 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; Architecture-based Evolution of Software Systems

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

The CCC approach The Configuration Layer Services that model activities andbythrough which users the system These services canbusiness be either invoked authorized or can be configured, at run-time, to provide the response that is required. triggered by events (self-adaptation). Computation Resources Configuration Layer The running system Architecture-based Evolution of Software Systems Coordination Resources

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

Comm. Unity prog Simple-account out num, bal: int in n: int do dep: bal: =bal+n [] wit: bal≥n bal: =bal–n A program in Comm. Unity Output channel – observations over the local state How can we characterise theover change? Changing Environment can onlyrule: read Input – observations thetwo environment Whatchannel is thebusiness relationship between the programs? credit is allowed ononly withdrawals up to assignments a limit Component read Actions – can guarded multiple prog VIP-account out num, bal, cred: int in n: int do dep: bal: =bal+n [] wit: bal+cred≥n bal: =bal–n Architecture-based Evolution of Software Systems

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

Externalising Superposing the business rule prog. The Regulator business rule can be in r 1: externalised int as a first-class r 2: int object – a regulator. do reg: r 1≥r 2 Account prog Simple-account out num, bal: int in n: int do dep: bal: =bal+n do dep: bal: =bal+n wit: [] wit: []bal≥n bal: =bal–n The superposition of The regulator is capable of and morphisms andsynchronise thethe and business rule with can now reading two values r 1 and r 2 that allowbe the requested withdrawals, achieved by interconnecting the from the environment and regulator amount them intor 2 read blocking regulator and when the provides an action that blocks the base balance in r 1 the program. values when r 1<r 2. read do not satisfy prog Channel in a: int The interconnection itself is the guard b: int a channel… performed through do c Architecture-based Evolution of Software Systems

Categorical semantics The semantics of slide, theisconfiguration is the parallel composition prog Parallel computed aincategorical construction In Simple-account thecomposition previous we built a through diagram the category of of its as interconnected through morphisms. out num, int in n: intthe morphisms. –components a. Comm. Unity colimitbal of: the configuration diagram. programs and superposition do dep: bal: =bal+n [] wit: bal≥n bal: =bal–n Intuitively, thisofshould correspond toathe original “simple-account”. For diagrams this particular form, colimit is called a pushout. This diagram depicts a system configuration. prog Regulator in r 1: int r 2: int do reg: r 1≥r 2 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 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. Architecture-based Evolution of Software Systems

Evolving the business rule prog VIP-account Changing the business rule now is as simple as reconfiguring the system out num, bal, cred: int in n: int by replacing the regulator. It does not require any changes to be do dep: bal: =bal+n [] wit: bal+cred≥n bal: =bal–n performed on Account and does not interfere with the rest of the system prog VIP-Regulator out prog cred: Regulator int in r 1: in int r 1: int r 2: int do reg: r 1+cred≥r 2 do reg: r 1≥r 2 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 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 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. Architecture-based Evolution of Software Systems

Services (types) as 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); that can be called within the law end law Interfaces that specify the nature of the components Operations as part of joint actions to which the law can be applied, not their identities. The event that triggers the reaction Events Additional that need to be observed guard for the joint action coordination interface to provide triggers. The reaction: a joint action in which account-debit customer-withdrawal import types import the partners andtypes local actions of the money, account; money; services executed as law can participate; services owns(a: account): Boolean balance(): money; a synchronisation set events debit(a: money): post balance() withdrawal(n: money; a: account) What features components need to end provide through = old balance()-a interface endtheir interface public interfaces to be partners of the law 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… Architecture-based Evolution of Software Systems

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

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

Semantic primitives for configuration coordination context Account. Management (c : customer) Ad-hoc operations (performed on demand component types Account, Customer authorised contract types by Standard, VIP users) – in this case, subscription of a VIP-package constants max. Credit: money=10000 Programmed operations (performed in services reaction to triggers) – in this case, a VIPsubscribe VIP(a: account, limit: money): Package is automatically pre exists Standard(c, a) and limit <= max. Credit removed the balance=goes below 100. post exists VIP(c, a) when and VIP(c, a). credit limit and not exists Standard(c, a) rules automatic. VIP: when exists VIP(c, a) and avg. balance() < 100 post exists Standard(c, a) and not exists VIP(c, a) Architecture-based Evolution of Software Systems

A micro-architecture for coordination None of the standards for component-based software development – CORBA, Java. Beans, COM – can support superposition as a first-class mechanism. Because of this, we propose our solution as a microarchitecture that exploits polymorphism and subtyping, and is based on well known design patterns, such as the Chain of Responsibility, and the Proxy or Surrogate. Architecture-based Evolution of Software Systems

A coordination design pattern Architecture-based Evolution of Software Systems

A coordination design pattern Architecture-based Evolution of Software Systems

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

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 Run-Time Configuration Coordination Layer Testing Component Layer Deployment Component Development 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. 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. Architecture-based Evolution of Software Systems

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 Deploy System Testing Tester Deployed System Trigger Operation Observe Object … CDE User Application Interface Architecture-based Evolution of Software Systems Animation Interface

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

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

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

Learn more… n about how these principles are being used in industry! n Visit www. atxsoftware. com 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 Architecture-based Evolution of Software Systems

Learn more… n about n Buy the book 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 Architecture-based Evolution of Software Systems

www. cs. le. ac. uk/Soft. SD 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 Architecture-based Evolution of Software Systems