Architecture-based Evolution of Software Systems Luís Andrade João Luiz José Gouveia 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… Well…How about moving "… the ability to change is now more important than the (B 2 C, B 2 B, P 2 P, …) new technology? to this 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… How iscan our ISs business and technology architecture whose components merge. How soon failure by reconfiguring themselves (self-healing)… the IS going to it? let us do can be added, modified, replaced and reconfigured". cope? n The real-time economy… to incorporate Any ideas on how P. Finger, "Component-Based Frameworks for E-Commerce", Communications of the ACM 43(10), 2000, 61 -66. Complexity is now on evolution… this new requirement? 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 business activities and through which the system can These services can be either invoked by authorized users or 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 the change? Changing the business rule: Environment can only read Input channel – observations over the environment What is the relationship between the two programs? credit is allowed on withdrawals up to a limit Component can only read Actions – guarded multiple assignments 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 Act 2 / Act 1 out num, bal, cred: int in n: int Types are preserved Guards cannot be weakened do dep: bal: =bal+n Assignments are preserved [] wit: bal+cred≥n bal: =bal–n Architecture-based Evolution of Software Systems
Externalising the business rule Superposing prog Regulator The business rule can be in r 1: int externalised as a first-class r 2: int object – a regulator. do reg: r 1≥r 2 prog Account prog Simple-account out num, bal: int in n: int do dep: bal: =bal+n [] wit: bal: =bal–n [] wit: bal≥n bal: =bal–n The superposition of the The regulator is capable of and morphisms and the and synchronise business rule can now be reading two values r 1 and r 2 that allow the requested withdrawals, achieved by interconnecting the from the environment and regulator to read amount in r 2 blocking them regulator and the base program. provides an action that blocks the balance in r 1 when the values when r 1<r 2. read do not satisfy prog Channel in a: int The interconnection itself is the guard b: int performed through a channel… do c Architecture-based Evolution of Software Systems
Categorical semantics The semantics of the configuration is the parallel composition of its prog Simple-account Parallel composition is computed through a categorical construction In the previous slide, we built a diagram in the category of components as interconnected through the morphisms. out. Comm. Unity programs and superposition morphisms. num, bal: int in n: int – a colimit of the configuration diagram. do dep: bal: =bal+n [] wit: bal≥n bal: =bal–n Intuitively, this should correspond to the original “simple-account”. For diagrams of this particular form, a 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 cred: int prog Regulator in 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); Operations that can be called within the law end law Interfaces that specify the nature of the components as part of joint actions to which the law can be applied, not their identities. The event that triggers the reaction Events that need to be observed Additional guard for the joint action coordination interface to provide triggers. The reaction: a joint action in which account-debit customer-withdrawal import types the partners and local actions of the money, account; money; services law can participate; executed as 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 provide through = old balance()-a end interface their 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; attributes Credit : Integer; constraints ? owns(x, y)=TRUE; constraints 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 by authorised users) – in this case, contract types Standard, VIP 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 removed pre exists Standard(c, a) and limit <= max. Credit when the balance goes below 100. post exists VIP(c, a) 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
Скачать презентацию Architecture-based Evolution of Software Systems Luís Andrade João
7ce856637ba2236c09e0ed515767af2f.ppt