Evolution Meta-Process Model - CiteSeerX

ArchWare Architecting Evolvable Software www.architecture-ware.org

European RTD Project IST-2001-32360

Evolution Meta-Process Model (Project Deliverable D5.3b)

Authors:

Mark Greenwood - VUM, Ian Robertson - VUM, Wykeen Seet - VUM, Ben Senior – VUM, Bob Snowdon -VUM, Brian Warboys – VUM

Editor:

Ian Robertson - VUM

Document ID:

D5.3b

Date:

September 2004

Version:

v1.0

Status:

Issue

Reviewed by: Distribution: Abstract:

This is the report of the design and implementation of the ArchWare Evolution Meta-Process Model. This model forms one part of the behavioural tuple E, P that is the ArchWare component, and forms the basis for both the ArchWare system development environment and the Repository.

Copyright © 2002 by the ArchWare Consortium CPR – Consorzio Pisa Ricerche – Italy InterUnec – Université de Savoie – France Victoria University of Manchester – UK ENGINEERING – Ingegneria Informatica S.p.A. – Italy INRIA – Institut National de Recherche en Informatique et Automatique – France THESAME – Mecatronique et Management – France University Court of the University of St. Andrews – UK

All Rights Reserved



Acknowledgments This contents of this document reflect discussion held between the authors and with the following partners in the ArchWare consortium. − University of St. Andrews: Prof Ron Morrison, Dr. Dharini Balasubramaniam − Université de Savoie: Prof Flavio Oquendo

Caveat This document is subject to evolutions based on feedbacks from its usage within the project. Only the most recent version of this document should be used. New releases of this document will be advertised to Project Participants and be made available on the project cooperative work support web site.

Disclaim The authors have utilized their professional expertise in preparing this report. However, neither the ArchWare Consortium nor the authors make any representation or warranties with respect to the contents of this report. Rather, this report is provided on an AS IS basis, without warranty, express or implied, INCLUDING A FULL DISCLAIMER OF THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

ARCHWARE EVOLUTION META-PROCESS

V1.0



TABLE OF CONTENTS 1

Introduction......................................................................................................... 3 1.1 Document Purpose................................................................................................ 3 1.2 Overview ................................................................................................................. 3 1.3 Document Structure .............................................................................................. 3

2

The Structure of Change Behaviour ................................................................ 4 2.1 Evolution................................................................................................................. 4 2.2 The ArchWare Component ................................................................................... 5 2.3 Structures for E...................................................................................................... 7 2.3.1 Meta-process ............................................................................................... 7 2.3.2 Process for Process Evolution (P2E) .......................................................... 7 2.4 Structures for P.................................................................................................... 11 2.4.1 Dynamic evolution ..................................................................................... 11 2.4.2 Targeted evolution ..................................................................................... 11

3

Implementation of E ......................................................................................... 12 3.1 M ............................................................................................................................ 13 3.2 R............................................................................................................................. 14 3.2.1 Transforming goals.................................................................................... 14 3.2.2 Instantiating Producer behaviours ............................................................. 14 Programmatic Evolution......................................................................................... 15 HyperCode Evolution............................................................................................. 15 3.3 T ............................................................................................................................. 16 3.4 Interface ................................................................................................................ 16 3.4.1 User ........................................................................................................... 16 3.4.2 COTS......................................................................................................... 16 3.4.3 Producer .................................................................................................... 17 3.4.4 Repository.................................................................................................. 17

4

Dynamic Evolution........................................................................................... 18 4.1 Dynamic evolution using ADL............................................................................ 18 4.1.1 Evolving component networks using Compose and Decompose............. 19 4.1.2 Evolving process components................................................................... 20 4.1.3 Engineering benefits .................................................................................. 25 4.1.4 LIMITATIONS ............................................................................................ 25

Annexe A Programmatic Evolution ...................................................................... 30 Annexe B Prototype for dynamic Evolution ........................................................ 31 ProcessBase implementation of the dynamic evolution prototype ........................ 32

Annexe C Meta-Process ADL ................................................................................ 37

ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 I



Document HISTORY AND EVOLUTIONS

Changes Log Document Ch. Request Version Origin D1.0

Changes and Reasons for Change Issue

Authors IR

Open Issues/To Do Items Issue Date Number Logged

Description of Open Issue/ To Do Item Priority Status

ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 II

Origin


1


INTRODUCTION 1.1 Document Purpose This documentation reports on the design and early implementation of the ArchWare Meta-Process Model. It is essentially made up of three aspects: the rationale for the structure, alternative interpretations for the structure, and ADL definitions for the structure and behaviour of the process model.

1.2 Overview The concept of evoluton is core to the ArchWare architecture. The notion that models, when designed, need to satisfy not only the requirements known at that point in time, but ought also be capable of adaptation over time in response to new demands from the environment is a key concept. In addition, this adaptation needs to be dynamic, in the sense that the adaptation has to operate on an enacting process model.

1.3 Document Structure Section 2 of the document describes meta-process concepts. Section 3 goes on to describe the design of the particular meta-process adopted for the environment and repository, and its implementation in ADL. Section 4 elaborates on Dynamic Evolution.

ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 3


2


THE STRUCTURE OF CHANGE BEHAVIOUR 2.1 Evolution Evolution is one of the two framework properties proposed for this project which are specifically aimed at making system development easier and more mangeable. It is recognised that the software system, and its architecture, its development process and supporting tools, may all need to evolve during the lifetime of the system. The reasons for this are well-known and include: • • •

Changes in the business and technology environment Changes in the requirements of users Correction of defects in the system.

The consequence of this is that software developers and systems integrators often find that they are constrained in their work by development environments that compel them to find ways of working around an out-of-date architecture or an inappropriate development process. The ArchWare approach seeks to address this issue. There are two basic ways of bringing about evolution. One is to allow networks of components to be able to pass connections which dynamically extend the network of components in the system, and the other is to change the definition of the networks and of the behaviours embedded in the components of the networks. This report deals with the latter. The behaviour for dealing with such issues is referred to as evolution E. "E" is the set of technical and managerial activities that ensures that software continues to meet business objectives over time. Of course business objectives themselves are not static, they themselves evolve so the concept of co-evolution is important in extending the productive life of systems. Of all the properties that can come into play when considering the phenomenon of evolution – natural selection, competition, optimising, etc.– this work focuses on supporting the cybernetic control loop. This can be simply expressed as the function of detecting, then eradicating, difference. Thus evolution in this context refers to the identification of the need for change, choosing a suitable adaptation, and implementing that adaptation and so on. Evolution is characterised by the following properties: •

Evolution occurs in response to an identified difference between what a system is doing, and what it ought to be doing, thus the concept of 'feedback' is important. However it does not automatically follow that, if there is a need for evolution, then evolution will definitely take place. There can be many reasons (such as resource availabilty, or political




considerations) for not invoking a cycle of evolution and of simply tolerating the adverse feedback. • The state of the system that is the subject of evolution is preserved insofar as it is relevant for the post-evolution context. • There is no 'final' configuration for the system - it may undergo numerous cycles of evolvution at unpredictable points in time during its lifetime. Of course it would be expected that, as a consequence of this, its productive life would be greatly extended. • The change phase of the evolution process may take some time ( days, weeks, months), and may be targeted on a sub-system only, however the monitoring behaviour can continue 'in perpetuity'. • The change phase of the evolution process is initiated when the owner of the subject system decides that change is warranted (such as when the system is failing to achieve its purpose), and concludes when the change is implemented and feedback is being received from the new behaviour. The evolution described in this report can also be characterised as being dynamic evolution. This means that the artefact that is subject to evolution is continuously changing state, and aspects of this state need to be retained during the change, thus a knowledge of this state is necessary for evolution to be successful. For example the design process is commonly viewed as being evolutionary, and the design artefact can be said to evolve from requirements to implementation. However this artefact is always a representation of a system – that system does not come into existence until its implementation is executing on a platform and is interacting with people and other machines. The design can be seen as being stateless, it is simply a description that can take a number of forms, and its evolution can be called static. On the other hand, the executing system is changing state, and some states are significant when considering evolution and some states are unimportant. This is dynamic evolution. The link between the behaviour that brings about the evolution and the behaviour that is subject to evolution is crucial. They can be thought of as being quasi-independent. Under normal conditions, the relationship is one of detection and monitoring, essentially a passive relationship however if a change is warranted the evolution process can compel the installation of new behaviours on to the subject process.

2.2 The ArchWare Component Architectures make use of structural patterns which possess/display distinctive properties. The basic pattern of an ArchWare environment is the ArchWare Component. An ArchWare Component is a process (a behaviour in ADL) formed from a pair of interacting behaviours (we will now use this term rather than process) E and P as shown in Figure 1.


ArchWare


Architecting Evolvable Software www.architecture-ware.org

The behaviour P represents the behaviour which fulfils the purpose of the ArchWare Component. That is, if a particular ArchWare Component is supposed to transform input R to output W then this transformation will be fulfilled by the behaviour P (P for ‘‘production’’).

Y

W D E

P C

X

R

Figure 1 The ArchWare Component The behaviour E (E for ‘‘evolution’’) represents the behaviour which ensures the effectiveness of the P behaviour in circumstances which may require change. Thus E affects P. The interaction labelled D in figure 1 represents both feedback from P to E and the affect of E on P. Firstly E may affect the behaviour P because P’s performance is deficient in some way (a standard feedback control loop). Secondly, E may affect the behaviour P because E receives an external stimulus (represented by X in figure 1) to change P. This external stimulus could of course be part of another control loop not represented in this figure but a part of the complex network of interactions and feedbacks that are typical of contemporary complex organisations. It is this network that leads to the concept of "Co-evolution", whereby the evolution of one system initiates the evolution of another. Figure 1 shows an output Y from E representing E’s external response to the X stimulus. This behaviour is essential for run-time, or dynamic evolution. For such evolution to take place, it is essential that the evolver is aware of the state of P at all times. This is particularly important for long-lived processes where data needs to be preserved. (For static evolution, no knowledge of state is necessary, and no knowledge of intermediate date is necessary). An ArchWare environment is thus a system of interconnected ArchWare Components, linked by their inputs and outputs, to fulfil an overall purpose, namely the proactive support of the subject ‘‘business system’’. Such a system of interconnected ArchWare Components will thus form an active model with specific sets of components comprising the major structures described in section 2.4.



2.3


Structures for E

2.3.1 Meta-process The meta-process is a process that is concerned with, or deals with, another process. It is distinct from a meta-model which is of course a model for describing models. The tasks that together make up a meta-process are on the whole the same kind of tasks that make up human-centred activity such as document preparation, search, choice and decision. However there is one important activity that is unique, and that is change. The concern of a meta-process is generally that the subject process is doing what is desired and expected of it. In order to do this there needs to be sensors in the subject process that can detect qualities of interest, and an interaction between subject process and meta-process that convey the values of these qualities at run time to the meta-process. The meta-process must posses behaviour that allows these qualities (generically known as feedback) to be interpreted. On the basis of this interpretation, the meta-process supports human users in determining a suitable change and implementing it in the real-world enacting process. Note that in a conventional control process responsible for a production-type of process, the feedback measures outputs and these are used to manipulate resources so that subsequent outputs are more conformant to what is desired. In the ArchWare case we are concerned with manipulating behaviour in order to better achieve the aims of the process. A particular example of a meta-process has been developed, known as the Process for Process Evolution (P2E), that is particularly suited for supporting dynamic evolution of architectures.

2.3.2 Process for Process Evolution (P2E) The P2E is an architecture for E behaviour based on the human response to problem situations. The mechanism of this response comprises detection, identifying that there is a difference between what is occurring and what we would like to happen, formulating suitable objectives, solution-finding for these objectives, solution implementation, and again detecting. To support such behaviour in the organisational context, separation of concerns has led to the meta-process being formed from three interacting sub-behaviours. 1. Managing (M). Dealing with the overall aims of the system and monitoring of actual performance. 2. Realising (R). Dealing with implementation issues. 3. Technology (T). Dealing with solutions. The basic relationships amongst these sub-behavious and with the ‘‘P’’ element are shown in figure 2. Thus E is a meta-process and is referred to as the Process for Process Evolution (P2E).




E (P2E) T MT

QN

W

I (Install)

R FM

QR

P F M

X Y

R

Figure 2 Process for Process Evolution (P2E) 1. P is the production component transforming R to W. The interaction D within the basic ArchWare Component (see figure 1) becomes a pair of interactions, F and I. F provides feedback concerning the performance of P to the M (anaging) component of the P2E. P and the R (ealising) component of the P2E interact via I to install changes in the behaviour of P. (In ADL terms this should be interpreted as ‘‘changing the behaviour identified as P’’). The behaviour of P is largely independent of E for routine activities once P is installed. For example it will take resources as inputs and transform them into outputs and this will continue as long as resources are made available. 2. M represents a ‘‘managing’’ element of the behaviour E. M has knowledge of the purpose of P, understands how to deal with feedback, and supports a user in deciding whether or not the values of feedback being received warrants the instigation of a cycle of evolution. M interacts with P via the Feedback interaction to receive data concerning the functioning of P (for example: is P working OK? are there any problems etc.?). M also interacts with external elements through X and Y concerning any external need to alter behaviours of the system (E+P) that M is managing. Typically, external elements are modulated and interpreted by the user. 3. Depending upon interactions M has either with P or externally, M may determine that some change is needed to P. The interaction QR with R indicates the nature of the change required. R is responsible for making the appropriate change to P (see below). The interaction FM between M and R allows R to provide feedback to M about the changes, including the possibility that required changes could not be made. 4. R is responsible for changing the behaviour of P according to the instructions from M. (It is also responsible for changing M if necessary. This will be discussed later). In simple terms there are two possibilities. ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 8

ArchWare Architecting Evolvable Software •

www.architecture-ware.org


For the given instructions from M, R is directly able to generate the necessary changes for P and does so via the interaction I. • For the given instructions from M, R does not possess the capabilities to generate the appropriate changes. In this case R interacts with T (via QT) asking T to supply R with methods (MT) which R can then used in changing P. These changes are either an adaptation of P, or as a new definition of P. In ADL terms, T will supply abstractions to R which R will use to create new behaviours for P. The interaction labelled I will itself contain the behaviour labelled CH in earlier versions of WP5.T1.01 5. T is responsible for providing R with ‘‘methods’’ (ADL abstractions) (MT) to meet the requirements to change P. This can be done by searching for a suitable method, or by developing a new method. As in the Tower architecture for P, P2E does not define each of the behaviours M, R and T (see Deliverable D2.3b). The use of P2E in a specific context will define these components. Again, as noted for Towers, such provision will be the responsibility of an appropriate E behaviour.

2.3.2.1 Recursive nature of P2E When considering the behaviour of a meta-process it is important to bear in mind that it may be necessary to evolve the meta-process itself. The reasons could be similar to those put forward for evolving P processes. For example, the meta-process itself may be failing in its purpose of setting up, monitoring and evolving systems that satisfy their purpose as determined in M. It may be failing to analyse the feedback from P adequately. It may be necessary to include certain stakeholders in the evolution process. It may be necessary to clearly separate the two aspects of R behaviour, thus have an E of four interacting behaviours rather than three interacting behaviours. In order to support this, each of the component behaviours of the P2E architecture (M, R, T) is an ArchWare component, with a production element and an evolution element as shown in figure 6.


ArchWare



ET

PT QT

MT I

PR

ER QR EM

FM

F

PM Y X

Figure 3 Evolvable M,R and T M has a production element PM receiving inputs F, FM and X and producing outputs QR and Y. R has a production element PR receiving inputs QR and MT and producing outputs I and FM. T has a production element PT receiving input QT and producing output FM. Each of these has an E component (EM, ER, ET respectively) which are themselves potentially described as a P2E. Thus a P2E architecture recurses with P2E structures within P2E structures.

2.3.2.2 Grounding M, R and T In the general P2E model there are nested P2E components for each M, R and T components. Clearly this nesting needs to be grounded or else components will forever be asking another component to ask another component and so on. 'Grounding' a behaviour simply means that its production components (i.e. PM, PR and PT) do not have an associated E element. That is, such a component cannot be evolved. It is not necessary that grounding occurs ‘‘simultaneously’’ for each of M, R and T of course. As noted in section 3.3 the fact that a component does not contain an E element can mean that the architecture does not recognise the means of change as a separate component. It does not mean that it cannot be changed, however it does mean that the P cannot be changed at run time in isolation.



2.4


Structures for P P will contain certain operational behaviours that allow the system to undertake whatever tasks, or produce whatever products as have been defined in the requirements for P. However in all but the most trivial cases consideration will have to be given to the issues of dynamic and targeted evolution

2.4.1

Dynamic evolution If evolution simply consists of abandoning the executing example P and replacing it with a modified P then the operational behaviours already referred to may be adequate. However if dynamic evolution is needed, then as the two prototypes (see Section 4) indicate, in addition to the operational behaviours there will also have to be certain evolution-related behaviours. Typical would be a connection to announce to to P the imminent evolution, a behaviour to harvest the state of the state and data of P, behaviour to inject this data into the new instance of P, and behaviour to re-establish the original P were the implementation of the evolution to fail. This is expanded further in Section 4.

2.4.2 Targeted evolution Another issue that impacts on the structure of P is the scope of evolutionary change. Only in the most trivial circumstances will the behaviour of P be encapsulated in a single component. In practice, P will of course be a network of components and the definition of P will in include the composition of these components. The definition and assembly of these components will be undertaken in the ArchWare environment, as will the evolution of P at its highest level. However if P is a multi-level complex network of individual components the question that arises is: ‘Is it appropriate for the complete system that is P to be decomposed in order to effect a change which may only relate to one component out of many?’. Out of such a consideration it may be appropriate to structure P as a network of ArchWare components –the EP pairs introduced earlier in Section 2. Thus the design of P would explicitly include all the behaviours for its own evolution, and only the evolution of the outermost or highest-level being undertaken by the evolver of the node of the ArchWare Environment. Thus an imposed evolution would be accomplished by passing a message to the appropriate evolver both instructing a change and also passing a reference to the new definition. The Evolver’s feedback connection is the appropriate channel for this. If, on the other hand, the evolution was in response to local feedback, then it would proceed without reference to other components




3 IMPLEMENTATION OF E This section describes the design of the P2E meta-process that has been implemented (see Annexe C). As has been noted, the P2E architecture does not define the behaviours of its constituent parts identified as M, R and T. These are being developed during the project and the first implementation is described in this section. The conventional approach, shown in fig 4 shows MRT behaviours encapsulated as a P2E. This is the default implementation for ArchWare that rigorously implements the E-P concepts. The boxes indicate behaviours and levels of composition of behaviours. For example, R is a composition of two behaviours, R_handleManager and R_handleChange, which is itself composed together with T and R to form the composition known as P2E. P2E is in turn composed with P as the ArchWare component. The M, R and T will all be ArchWare components capable of individual evolution. These can then be the basis of ongoing development of the meta-process.

T

P2E

ArchWare Component

T_R

R_T R R_handleMgr

R_handleChange

M_R

M

feedbackPtoM

Producer

Figure 4 ArchWare component for evolving P However as has been noted earlier (2.3.2) it is more than likely that it would not be possible to anticipate in the behaviour of M all the possible potential feedback from all possible behaviours in P. Thus it has to be anticipated that an evolution to P will be accompanied by an evolution to M as well. Now the ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 12



recursive architecture can of course support this, because M is itself an ArchWare component that possesses its own E and P, and this E would be invoked to evolve the P of M to suit the outputs of Producer P. However there is a special relationship between M and P in that they are composed together because of the common feedback connection and thus an alternative default implementation of E will allow the synchronised coevolution of P and M to take place. This is shown in figure 5. R_handleChange can evolve both M and P in the one change action, and re-compose both with the P2E on completion.

T

RT

ArchWare Component

T_R

R_T R

R_handleChange

R_handleMgr

M_R

M

Producer feedbackPtoM

Figure 5 ArchWare component for the co-evolution of M and P

3.1 M This behaviour supports the user in determining a purpose or goal of a system, and in monitoring the quality and performance of the operational system (i.e. the producer behaviour P). This behaviour has a number of aspects: • Receiving feedback from P. The nature of the feedback can be varied. It can include specific data detected at various points in P. Some feedback will be dealt with by the user, and other feedback will be dealt with automatically by P2E behaviours. Just how this is dealt with depends on the nature of the feedback, and is discussed further under the Compliance issue (Deliverable 5.4a). • Presenting feedback to the user. ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 13

ArchWare Architecting Evolvable Software •

www.architecture-ware.org


Identifying new or changed goals for P. A part of such a requirement would be an indication of the feedback that would be generated from P. • Supporting the user in the decision to proceed or not with a cycle of evolution. This can be a diagnostic process, identifying the true cause of adverse feedback data in order that a revised goal would enable the shortcoming to be addressed. • Receiving feedback from R. this would occur in the event that the user had specified a goal for P that could not be achieved. • Support for the evolution of M (i.e. the associated E sub-behaviour mentioned above). The treatment of feedback gives rise to a particular Compliance issue, in that the precise behaviour that should be invoked in M depends on the nature of the feedback. It is proposed to make use of a meta-process in this context to choose the appropriate behaviour (see deliverable D5.4a Compliance Support).

3.2 R There are two aspects to the behaviour of R: as follows: •

that of transforming the goals for P (identified in M) into pragmatic requirements that are useful for characterising methods that might be retrieved from a search (the actual searching being done in T of course) (by R_handleManager) , and • implementing a method (an abstraction for a Producer) so retrieved (by R_handleChange). These two behaviours are in fact independent and do not communicate. It will be possible to evolve them when R is implemented as an ArchWare component, and it will thus support the evolution of its own Producer.

3.2.1 Transforming goals The statements of purpose, aims or goals that are determined are necessarily broad and ill-defined from a technical point of view. They are intended to be easily understood by members of staff over a number of disciplines. They are not particularly useful for specifying a method, or selecting between alternative methods. Thus they have to be refined from the broad aims identified in M into a form more specific and detailed and suitable for a precise identification of a suitable producer behaviour. This takes place in R.

3.2.2 Instantiating Producer behaviours This is the key activity in the whole evolution process. It is the second aspect of R behaviour and is invoked when the T behaviour has identified a suitable new Producer and passed it to R_handleChange. There are two ways of instantiating a Producer, depending on the way that the evolution is carried out. In Programmatic Evolution a previously-defined abstraction is substituted for the applied abstraction (the abstractions being definitions of Producers). With Hypercode Evolution the definition of the enacting Producer is modified on-line at run time. ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 14



Programmatic Evolution

R retrieves an abstraction from T. The sequence then as follows: • R first has to stop producer P. It can do this because it retains a reference to the behaviour that is the composite of P and P2E from the first time P was composed with P2E. • From this decomposition the constituent behaviours can be identified. There will be at least two: P2E and P, (or, M and P depending on whether the default P2E is used or the co-evolving P2E) because they must be composed together in order to bind the feedback interaction. The decompose operation stops the behaviours. However although P is stopped, the operation of R is not stopped. This is because R has been composed at a lower level and continues to function. In fact what is stopped is the P2E composite, which in essence is the binding of interactions between P2E components. Thus the effect of the decomposition is to un-bind the feedback interaction between M and P, and to un-bind the interactions between the M, R and T. This of course disables any communication between the components of M, R and T for a period between the moment the decomposition is applied, and the subsequent composition. Otherwise, the behaviours of M, R and T are not affected by the decomposition. A fuller explanation is provided in Annexe A. In this way the P behaviour is selected for evolution. • If Dynamic Evolution (see below and the following Section 4) is to be supported, then at this point the data that represents the state of P need to be retrieved. This has to be incorporated in data values of the new behaviour when it is composed as the new Producer. This is to ensure the evolved P retains all relevant state from the earlier P. • The new Producer is then compiled and the resulting behaviour composed with the other unchanged behaviours. P will commence sending feedback to be monitored by M and so the cycle of evolution is complete.

HyperCode Evolution This kind of evolution may be more suitable for more minor changes where it is considered expedient to directly manipulate the code and values of the currently executing instance of Producer. For HyperCode Evolution, the result of the ArchWare Component decomposition is sent to a newly-invoked HyperCode Editor. There, the behaviour is reified and displayed on the screen as the Producer abstraction definition, its values and links to values. The user can then modify the ADL or values directly, evaluate it and return the link to the compiled code to the model where it is a new value for P,.In the model, the P2E and P are composed again to form the executing ArchWare component. Note that the reification is a snapshot of the behaviour tasken at a moment in time, and the subject behaviour may well continue to execute in the model while its representation is being modified in the HyperCode Editor.




3.3 T The T behaviour is responsible for finding or determining a suitable producer to be implemented. This behaviour, when implemented as P and is executing, is intended to satisfy the goal set by M. A producer as received by T is a string definition of an ADL Abstraction (if the manipulating tool is the HCE), AXL if the tool is the Graphical Modeller, and ASL if it is the Customisor, ARL if it is the Refinement tool or AAL if it is one of the Analysis tools. All available producers are developed and retrieved as artefacts from nodes in the Repository, which is visible from T. This is a tower of nodes that constitute local development environments for producer artefacts (and in the present context are ADL abstractions and compiled abstractions). Thus a user interacting with the T behaviour has the ability to navigate the environment tower, locate a suitable method, and to copy its abstraction, or utilise its compiled behaviour by reference as a method to use in the evolution of P. The Hypercode environment allows the choice of implementing the copy of a method (i.e. an abstraction) or implementing an actual behaviour itself. The advantage of the latter is that the behaviour can be maintained in a development environment and thus the reference can always be to the latest version of the artefact. Normally, suitable abstractions will be developed in the towers environment by refining existing abstractions (the user can traverse the tower to interact with the appropriate node to do this), however it is also possible to develop an abstraction local to T by invoking the Hypercode Assistant from T. This allows simple abstractions of producers to be defined and evaluated.

3.4 Interface The meta-process is a complex entity with a number of interfaces to people, alien applications, and other ArchWare core process models.

3.4.1 User The users interact with the meta-proces via one or more COTS tools. The basic navigation tool is the tower browser, from which a user can invoke one of the other ArchWare tools to develop architectures.

3.4.2 COTS The five ArchWare COTS tools will interface with the ADL Virtual Macjhine through the Transformer/Connector protocol. In essence this means there is a private protocol between the COTS and the T/C, and the Archware protocol between the T/C and the ADL VM. In its final version, this will mean that interactions with the ADL VM will be done by evaluations of ADL code, and from the ADL VM will be by primitive AXL. Communications with all ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 16



COTS will of course be moderated by the access control provided by Process Spheres (see Deliverable 2.3b).

3.4.3 Producer There are two interactions with Producer. One is install, which means that the E possesses a reference to the Producer behaviour that can subsequently be used by E to execute change to that Producer. The other is feedback from Producer to E. The nature of this feedback depends on the nature of Producer, the properties and qualities about which the metaprocess needs information in order to be able to assess performance. This is to an extent an open issue and the proposed approach to this problem is outlined in Deliverable D5.4 Compliance Support.

3.4.4 Repository This structure is accessible via the T of the P2E meta-process. It is a key property in the customisation of an environment, both from the point of view of which resources ought to be provided, but also the access rules for these resources. Access control again will be provided by Process Spheres.




4 DYNAMIC EVOLUTION Dynamic evolution is change where certain properties of the behaviour that exist at the point of evolution must be preserved in the new behaviour. This preservation can possibly be undertaken in the Virtual Machine of the ArchWare environment, or can be achieved by adopting a particular style for ArchWare models (see below). This need for state preservation gives rise to local behaviour in the producer that is associated with the evolution process: behaviour that is triggered by the imminence of an evolutionary change. There is however another reason for providing local behaviour associated with evolution. Evolution in the early release of the ADL VM is entirely the prerogative of the meta-process. At the instant decided by a user interacting with the meta-process, or if the behaviour is automated, at the point at which the change is triggered (by means of decompose ) the target behaviour is available for evolving. It can then be replaced by a new one. This is not satisfactory for three reasons: • Users might be interacting with the model at that moment, and they may not be ready for the change. • There might be unsaved data in the behaviour • There might be an exchange of data taking place which will be interrupted with unpredictable consequences. Thus a more sensitive approach is needed that takes cognisance of the state of the target producer and the data from its environment that must be preserved. The situation or state of the executing producer P is important. One possible approach is for evolution to be permitted only at specific points in the target behaviour, and if the target enaction is not at one of these points when the change is attempted, then the implementation of the change must be delayed until such time as the target behaviour does arrive at one of these points. This sensitive data needed for persistence of properties can be exported when the target behaviour is prepared to accept a change, This data can then be imported by the new target such that there is a smooth transition to the new behaviour. A prototype of this approach has been modelled in ProcessBase to assist in exploring the issues, and is described in Annexe B. The ‘global store’ used is the system’s Persistent Root that is available to users.

4.1 Dynamic evolution using ADL


ArchWare



The use of the ADL functions of compose and decompose have been introduced in 3.2.2. These operate over process connectivity (see 4.1.1) not upon the program code and the state of its variables, which determines their internal behaviour. Support for the evolution of a component’s internal behaviour is required in real-world, long-lived, systems. A style of programming is now considered which provides dynamic evolution in ADL. Conformance with the style will require little developer effort.

4.1.1 Evolving component networks using Compose and Decompose Native to the ADL is the notion of composition as described earlier. To recap, a metaprocess (in this context, the ‘E’ of an Archware Component) can compose a set of other processes and their connections to form a new process, as shown in Figure 6. x1 x1 E

x2

Composes

Forms process Y

x2 Y

x3 x3

Figure 6, Composing a set of processes Correspondingly, there is also the notion of decomposition, as indicated in Figure 7. x1 x1 E

Decomposes Y Y

x2

x2

returns x1..x3

x3 x3

Figure 7, Decomposing a process It follows that to evolve the internal connectivity of process Y, the natural procedure is for M to decompose Y, and then to recompose it with a new connection configuration. It is an equally straightforward process to replace (or introduce, or remove) processes of Y by decomposition and recomposition. In Figure 8, x2 is replaced by x4.




x1 x1

x4 E

Forms process Y

Composes

Y

x4

x3 x3

Figure 8, Replacing x2 with x4

4.1.2 Evolving process components The evolution of a process component (behaviour), rather than evolution of its relationship with other process components, implies change to the program code which defines it or to the state of the variables upon which that program code operates. The goal is thus to safely replace a component x with a new component x’ where x’ may have both different program code to x but whose internal state corresponds, as far as possible, to that of x at the moment of initiation of the evolution. The positioning of this process within the context of an Archware Component has been described in Section 2.2. At present the extraction of x from its embedded process network (via decomposition) relies on the reduction limits of the associated components to provide safety, i.e. it is not possible to send or receive on connections that were formerly unified and are no longer unified (see Error! Reference source not found. for limitations of this approach and possible solutions). The state of x’ ought generally to be related to the state of x during component evolution. We therefore treat the evolution as a period of transition under the control of a meta-process. This meta-process may then itself be evolved depending on the nature of the transition. Consider an evolution of x2 to a new state x2’ occurring some time after x2 has been composed into the executing process Y. The aim is to harvest the state of x2 when evolution is triggered and to make it available to x2’. The programming style employed here requires all components wishing to be compatible with the evolution scheme to satisfy two pre-requisites. They must contain (two) connections reserved for the purpose of evolution, and they must possess and execute an internal behaviour (asynchronous and concurrent) to support the evolution. This internal evolution behaviour listens for metaprocess messages on the evolution connections, and responds either by packaging up and sending the name/value pairs of its internal variables, or accepting a package of name/value pairs with which it will over-ride the default values of those named variables which would be created on the instantiation of x2’. The ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 20



internal evolution behaviour is structured in such a way that it may be dynamically generated at run-time using features of HC reflectivity. A skeletal overview is given in the table below. value evolvableProcess = abstraction(…) { value evolverConnExtract = connection(any) value evolverConnInsert = connection(any) value EvolverAbs = abstraction(complete : connection[string]) { The EvolverAbs listens on evolverConnExtract for requests to package and export the name value pairs of this process, and on evolverConnInsert for packages whose name / value pairs ought to be inserted into this process. This code can be manually crafted, or replaced with code capable of dynamically generated the appropriate behaviours at run-time } value evoCompleted = connection(string) value runningEvolver=EvolverAbs1(complete=complete) via evoCompleted receive anything

Normal component code goes here. It is executed only after a message is received on the evoCompleted connection, thus ensuring that the state of the process has been correctly re-inserted before the process responds on any of its other waiting connections.

done }

The process begins with the decomposition of the portion of model containing the component to be evolved. Referring to the previous model by way of example, Y is decomposed, exposing x1,x2 and x3. The aim is to dynamically evolve x2 to x4. These components will hit their reduction limits if they attempt to communicate on the connections which have now been uncoupled by the decomposition operation. They are thus ‘safely’ isolated during the evolution period. During the next phase we transfer the state from the old component to its replacement. During this transfer we may manipulate the state before its insertion. It is thus possible to evolve combinations of component definition and variable state. The procedure is to attach both components to an evolution harness (implemented within the Archware Component’s Evolution component, specifically within the P2E’s R_handleChange). Using ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 21

ArchWare



successive compositions and decompositions the components x2 and x4 are connected to another component whose specific purpose is to request the extraction of each respective component’s state package and to handle its reinsertion. These components are labeled ‘Ex’ in Figure 9.

S Ex

Ex

x4

x2 Figure 9 : Evolution harness 1

We may then choose an evolution ‘style’ by connecting the two Ex components to a further component which mediates between the two states (which, for example, might itself be a process including user interaction). The most immediately useful component is one which simply transfers state between identically named variables in the old and new components. This component is labelled ‘S’ in Figure 9. Once the evolution harness has transferred the state of x2 to x4, we simply recompose the model with x4 replacing x2, as shown in Figure 8. The aspect of the metaprocess E implementing such a process is shown the below. It relates to the replacement of a message counter component that bisects a message generator and message consumer. The message counter is to be evolved from description mCA2 to description mCA3, whilst its state is to be preserved. value dynEvoExample = !The initial model compose {t1 as messageGenerator3(testTrigger=testTrigger) and t2 as messageCounterAbs2(counterConn=userConn) and t3 as messageConsumer() where {t1::messageOut unifies t2::messageIn, t2::messageOut unifies t3::messageIn}} !After a given number of messages have been generated to simulate the model having been run for an arbitrary time before evolution, the generator sends a trigger that we use to begin the evolution process. via testTrigger receive something value decompSeq = decompose runningTestHarness3 value x_gen = (decompSeq::1).bhvr ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 22









We thus safely isolate the component processes to be evolved through decomposition. While decomposed we compose the process to be evolved (x2) with a process for evolution and possibly other processes which will contribute to or benefit from the evolution process. These then are composed temporarily with x4, and finally x4.participates in the recomposition with x1 and x3.

4.1.3 Engineering benefits In following this method we avoid operating directly on the source code of x2 (such as by using the Hyper Code Editor). The rationale for this is motivated by the pragmatic, hypothesis based Software Engineering. philosophy of evolution that underpins the Archware approach. By retaining x2 in its original state we have the possibility to reinsert it should the transfer (actually, copying) of state from x2 to x4 not succeed. We will also have the capacity to then perform tests on x4 with its new state to ascertain that it will perform correctly when inserted, possibly while x2 is reinserted into Y in the meantime. Furthermore, an accurate provenance of the system’s evolution through time may be maintained. Perhaps most importantly, it becomes possible to simultaneously insert both x2 and x4 into Y after having apriori composed both within a ‘temporary behaviour’ testing harness. In this way we can ‘stress test’ x4 in situ for a period of time by copying the inputs of x2 to x4 and then analyzing the output of x4 relative to that of x2. When we are satisfied that x4 behaves satisfactorily Y may once again be decomposed, the test harness removed, and x2 replaced with x4. While this cannot not guarantee the correctness of x4 it is a useful complementary approach where mathematical techniques may not be available, competent or entirely trusted.

4.1.4 LIMITATIONS 4.1.4.1 Defined evolution sections A key safety requirement when conducting component evolution is that during the transfer from process x to x’ the state of x must be decoupled from its original network. Specifically, from process components perspective the state of the network should not appear to have altered during its evolution (unless connection evolution is the purpose of the change). From a network perspective, the evolution of the component is ideally invisible. At this point we rely on reduction limits to provide safety during the evolution of state. Processes will block on connections which are no longer active. One common scenario in which this safety principle can be easily violated, however, is during a protocol based message transfer. Decomposition occurs at the moment it is requested. If this coincides with the execution of a ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 25



communication protocol the result is likely to be a message time-out. The evolution will have produced an unanticipated and undesirable side-effect. Likewise it must be borne in mind that internal component connections might not be unified and so for them no protection is provided by the decomposition. For such reasons, from an engineering standpoint, it will be necessary to be able to specify ‘windows of opportunity’ within which evolution is permitted during the execution of the process, and conversely, ‘exclusion zones’ where evolution is deemed to be risky and is thus not permitted. Of course these zones could themselves be modified by evoluition. The selection of these windows may be programmer determined, automatically generated, or both. The underlying issue is the disconnection of the evolution capacity of a component during unsafe periods. Ideally, this should require no changes to the evolution mechanism itself. The disconnection mechanism should be seen in the light of a mechanical switch. For example, this switch may support special evolution requests which over-ride the specification of the code areas. Such a requirement could, in fact, be easily met. What is required is an additional connection through which evolution sections are toggled, and a corresponding behaviour to handle the disconnection. Referring to the foregoing example, this behaviour can be rolled into (and composed with) the EvolverAbs where connection which would other wise be unified with the EvolverAbs are now unified into the Switch, and the Switch outputs are unified with the EvolverAbs. Although ADL is a powerful language, it is only as powerful as its underlying mathematical model. While the switch may appear to be a simple concept it is difficult to implement using pi-calculus. A suggestion is that ADL be extended to include the ability to inspect connections, to test (a) whether a message is waiting to be received, or (b) the connection is disabled. A limited workaround satisfactory when the switch may only have two states (safe/unsafe) is presented below. recursive value ReceiveUntilSafe = function(toggleConn : connection[string])-> integer { via toggleConn receive toggleMessage if (toggleMessage = "safe") then { 1 } else { ReceiveUntilSafe(toggleConn) } } recursive value switchFunc = function (inConn : connection[string], outConn : connection[string], toggleConn : connection[string], ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 26









To use this switch the developer must toggle it by : ‘via toggleConn send “safe”’ or ‘via toggleConn send “unsafe”’.


ArchWare



ANNEXE A PROGRAMMATIC EVOLUTION This is an extended explanation of the part that compose/decompose play in the application of evolutionary change, with particular regard to the availability of behaviours for enaction during evolution. T

A P2E is a composition of three behaviours, M, R and T together with the bindings of interactions between them.

R M

An ArchWare component is a composition of a P2E and a Producer and a binding of one interaction

T R M

Decomposing the ArchWare component unbinds the interaction and results in a stopped P2E and a stopped P.

P

T R

P2E is composed of sub-behaviours that are in themselves unaffected by the decomposition. The effect of stopping the P2E is only to unbind the interactions.

M

P

Producer has not been composed of any sub-behaviours, so it stops in its entirety.




ANNEXE B PROTOTYPE FOR DYNAMIC EVOLUTION The essential properties of dynamic evolution are described elsewhere. As a way of developing an understanding of how it could be implemented, a prototype model was written to explore the issues. This prototype was written in ProcessBase and executed on the ProcessBase Virtual Machine. As this is the underlying VM for the ArchWare ADL VM, it is an appropriate technology to use for the study of technical approaches. There were two programs: Testbed and SimpleOp. The former is a metaprocess in which to compile and enact the latter, and to carry out dynamic evolution of that target. Testbed. This allows the user to load a file, compile it and to execute it. During execution, the user has the choice of interacting with either of the programs. The usage scenario is to compile and execute SimpleOp, let the user step through SimpleOp, then at some point allow theTestbed meta-process to invoke an evolvution. This loads a new definition of SimpleOp, compiles it and, after a programmatic interaction between Testbed and SimpleOp, to terminate the original instance and to start executing the subsequent instance. The second instance starts in the same state as that of the first instance when it terminated. SimpleOp. This model simply steps through five phases, and in each the user activity is represented by a prompt for an acknowledgement. This represents a crude development process of Requirements, Specification, Design, Implementation and Test. The rule governing the application of evolution constrained the implementation of evolution to point of transition from one phase to the next. Thus, during a phase, the user can work without fear of interruption by the system. To achieve this it is necessary to make use of the ProcessBase global store referred to as ‘Persistent Root’. This can be accessed by all applications. The evolution scenario is as follows:

1. Load, compile and run Testbed. 2. From Testbed, load and compile SimpleOp. 3. Launching a new instance, Testbed writes the instance name and id to Persistent Root. 4. On initialistion, the new SimpleOp instance (the application) reads its name and id from Persistent Root and checks for the existence of a block of data known as Model Resources. If one doesn’t exist for this name and id, it means that the application has never been run before, and so it creates one in Persistent Root. 5. If the meta-process wishes to evolve the application, it simply sets the Evolve flag in the Persistent Root for that application. 6. The application reads the Evolve flag in its Model Resources each time it enters a state in which evolution can be accepted without interfering with users. As mentioned above, this is defined as the ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 31



period after a phase has been completed and before the next one has commenced. 7. If in (6) above the Evolve flag is found to be set, the application writes to the ModelResources the data that must persist (in this case simply name of the next phase to be enacted), unsets the Evolve flag, and terminates itself. (Clearly in practice this termination would not be permitted until the evolved instance had started and initialised correctly). 8. The meta-process observes the Evolve flag is now unset so launches the new instance of the application. 9. This new instance of SimpleOp ( new version) reads the ModelResources as in 3 above, reads the persistent data which is the name of the next phase, and commences execution at this phase. Thus when the user starts work in the next phase it is the new instance with which he or she is interacting. Any data in the application needed would have been preserved in ModelResources, so achieving dynamic evolution.

ProcessBase implementation of the dynamic evolution prototype Simple Op !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! start working code here

! obtain instanceName, instanceID from testbed resources writeString(sof,"Inputfile: Here is list for nodename of "++'nodename++"'n",-1) modelResources:= GetPSRootResource('root) thisModelResources:=getModelResources('nodename,'modelResource s) if '('('thisModelResources.data).content) ~= nil(Store_item_list_element) then { itemList:= '('('thisModelResources.data).content) listItems( 'itemList ) writeString(sof,"Inputfile: End of list for "++'nodename++"'n",-1) NewUpdateModelResources(1, true, 'nodename, itemList, modelResources,root) } else writeString(sof,"Inputfile: List for "++'nodename++" is nil 'n",-1) let thisItem Enter a goal'n" via userConn receive msg1 via M_R send msg1; } value behav2=abstraction() {replicate{ via fbConn receive feedback }} compose { l1 as behav1() and l2 as behav2() free behav2::fbConn }

} ! end M

value T = abstraction() { via sysout send "hello World from T open a user pls'n" value userConn = stdio() via userConn send "This is T'n" value prodloc = location(producer) replicate { via R_T receive msg; !unobservable ! find a model ... via userConn send "T > Choose a producer (1 or 2) for "++msg++"'n" via userConn receive msg1 if msg1 ="1" then {prodloc:= producer;done} else {prodloc:= producer2;done} via T_R send 'prodloc done } } recursive value R_handleManager = abstraction() { via M_R receive msg; via R_T send msg R_handleManager() done } recursive value R_handleChange = abstraction() { via T_R receive newp ARCHWARE EVOLUTION META-PROCESS, VERSION V1.0 39



awcloc := compose { l1 as 'awcloc and l2 as newp() } replicate { via T_R receive newp value decseq = decompose 'awcloc value p2e = (decseq::1).bhvr compose { l1 as p2e and l2 as newp() } }! end replicate }

value R = abstraction() { via sysout send "Hello World from R'n" compose { l1 as R_handleManager() and l2 as R_handleChange() } } awcloc := compose{ l1 as M() and l3 as R() and l2 as T() }

done } awc()


Evolution Meta-Process Model - CiteSeerX

Evolution Meta-Process Model - CiteSeerX

Suggest Documents

Compartmental Model for Cancer Evolution: Chemotherapy - CiteSeerX

Toward a Model of Audience Evolution - CiteSeerX

Resistive Bridge Fault Model Evolution From ... - CiteSeerX

9 Model Evolution and Management - CiteSeerX

business model design and evolution - CiteSeerX

Consistency-Preserving Model Evolution through ... - CiteSeerX

Grammar Model-based Program Evolution - CiteSeerX

Toward a Model of Audience Evolution - CiteSeerX

Grammar Model-based Program Evolution - CiteSeerX

The Model Evolution Calculus

On Multiobjective Evolution Model

A General Noise Model and Its Effects on Evolution ... - CiteSeerX

A model of melt pond evolution on sea ice - CiteSeerX

A General Model of Co-evolution for Genetic Algorithms - CiteSeerX

structure of a product database supporting model evolution - CiteSeerX

Dynamic Software Evolution and The K-Component Model - CiteSeerX

Total Software Process Model Evolution in EPOS 1 ... - CiteSeerX

The Co-Evolution of Model Parameters and Control ... - CiteSeerX

Understanding a Co-Evolution Model of Business and IT ... - CiteSeerX

Total Software Process Model Evolution in EPOS - CiteSeerX

Automating Co-evolution in Model-Driven Engineering - CiteSeerX

A Mathematical Model for the Evolution of Nitric Oxide ... - CiteSeerX

a human model of color term evolution - CiteSeerX

Sex as Gibbs Sampling: a probability model of evolution - CiteSeerX