An Architecture-Centric Approach for Information System Architecture Modeling, Enactement and Evolution

ion B. The latter can then dynamically apply it and may behave as the received abstraction C. As a consequence, the abstraction B has dynamically evolved, its current behavior might be radically different from the previous one (Verjus et al., 2006). Such evolution is (1) dynamic because the new behavior (abstraction C) is dynamically received and (2) unplanned as the abstraction definition is unknown in advance. An architect can provide the abstraction definition at runtime, and thus represent the unplanned evolution (as opposed to the planned evolution illustrated in section 5). To illustrate the evolution mechanisms let us consider a simple abstraction my_abst (cf. Figure 9). It receives a boolean (evolution) and an abstraction (evol_arch_part) on its connection evolRep. If the boolean value is true, my_abst behaves as the evol_arch_part abstraction definition received and applied. Otherwise (the boolean value is false), my_abst behaves in accordance to its initial description ( // some code in Figure 9). ion definition received and applied. Otherwise (the boolean value is false), my_abst behaves in accordance to its initial description ( // some code in Figure 9). Thus, my_abst abstraction can be dynamically modified; such modification is unplanned as the evol_arch_part abstraction definition is unknown at design time and is provided at runtime by the evolver abstraction. The latter plays an important role in the evolution: it is always connected to the abstraction that is expected to evolve (the my_abst in this example). Innovative Information Systems Modelling Techniques 34 value my_abst is abstraction(); { value evolReq is free connection(); value evolRep is free connection(Boolean, abstraction() ); . // some code via evolReq send; via evolRep receive evolution:Boolean, evol_arch_part:abstraction(.); if (evolution) then { evol_arch_part(.) } else { . //some code } }; The new current abstraction’s behaviour: the received abstraction is applied at runtime Fig. 9. Abstraction Dynamic Evolution value evolver is abstraction(); { value evolReq is free connection(); value evolRep is free connection(Boolean, abstraction); value checkReq is free connection(abstraction); value checkRep is free connection(Boolean); evol_arch_part is ARCH-EVOLUTION; iterate{ via evolReq receive; via checkReq send evol_arch_part; via checkRep receive propertyVerification : Boolean; if (propertyVerification) via evolRep send true, evol_arch_part ; } }; Fig. 10. The Evolver Abstraction The evolver abstraction is the communication means between the virtual machine and the external world i.e., the architect who decides to evolve the architecture. As unplanned changes are to be implemented dynamically in the system, an important issue is the property preservation. Property verifications are made on the evol_arch_part abstraction, which represents (all) the evolved architecture (see section 6.4 for some insights on the evolved architecture according to the evolver abstractions’ location(s)). This abstraction is sent using the mechanism we introduced to enable the on-the-fly exchange of abstractions: the use of a special abstraction type, ARCH-EVOLUTION. At design time, the evol_arch_part abstraction is declared of type ARCH-EVOLUTION (inside the evolver). This special type entails the evolution strategy, which can consist in using files, user’s interfaces, etc. An example of such a strategy consists in using a file containing the new abstraction definition, at a place known by the virtual machine. The architect can place the evol_arch_part abstraction definition in this file. When the evolver sends the evol_arch_part abstraction, its definition is dynamically loaded by the virtual machine from the file. However this is done only if property verification results are true, i.e., the properties remain satisfied if changes contained in evol_arch_part are applied to the executing architecture. This verification is even more crucial than in the case of anticipated evolution since the content of evol_arch_part is not known in advance. The earlier property violations are detected, the lower the maintenance cost is. Thus the decision to evolve or not is taken in the evolver, depending on whether the properties are still verified after the evolution. Property An Architecture-Centric Approach for Information System Architecture Modeling, Enactement and Evolution 35 verifications are made on the evol_arch_part abstraction, which represents the evolved architecture and which is sent by the evolver to the property checker, also represented by an abstraction. The checker verifies the properties attached to the abstraction to be evolved tacking into account the changes contained in the evol_arch_part abstraction. It sends then a boolean value (propertyVerification) to the evolver: true if the properties still hold, false otherwise. If the properties hold, then the evolver sends the evol_arch_part abstraction to the abstraction to be evolved. Other strategies can be implemented, such as prompting the architect with the analysis results. The architect’s choice to proceed or not is then reflected on the boolean value. Finally the changes are implemented on the running system taking into account the architecture execution state (Balasubramaniam et al., 2004). 6.3 Illustration of the dynamic unplanned evolution This evolution scenario is interesting: on the one hand it implies evolving the system architecture structure by adding a second and new supplier; on the other hand, it enforces to change dynamically the restocking process to take into account that a restocking request may not be satisfied; in this case, a new supplier is appearing and the initial restocking request has to be split (with some quantity computations) among the two suppliers. The system behavior has to be changed dynamically according to the new configuration and process (Figure 11 and Figure 12). The new architecture description is presented in Figure 12. Fig. 11. The Evolved Architecture Innovative Information Systems Modelling Techniques 36 value scm is abstraction(); { value evolReq is free connection(); value evolRep is free connection(Boolean, abstraction() ); compose { behaviour { via evolReq send; via evolRep receive evolution:Boolean, evol_arch_part:abstraction(Float,Integer); if (evolution) then { evol_arch_part(100.00, 32) } else { eai(100.00, 32) }} and client("rollings", 12) } }; value scm_arch is abstraction(); { compose { scm() and evolver() and cheker()} }; The received abstraction is dynamically applied Fig. 12. The evolved architecture (scm abstraction description) Changes between the initial architecture (before evolution – Figure 5) and the modified architecture (after evolution – Figure 11) take place in the scm abstraction. The scm abstraction definition contains -ADL code that manages the evolution: the scm abstraction behavior includes and applies both the eai and client abstractions (before evolution), and both the evol_arch_part and client abstractions (when the evolution occurs). Thus, when the evolution occurs, the evol_arch_part abstraction substitutes the eai abstraction. The evolver abstraction is unified with the abstraction that is supposed to evolve (scm). As explained in section 6.2, the evol_arch_part abstraction is dynamically received and then applied after property verification by the property checker. As in the case of planned evolution, architectural properties may hold on both the structure and behavior of the system. Note that in the present case, the properties are expressed in AAL using the core ADL concepts; this is because the virtual machine can only interpret the core language (Morisson et al., 2004). Examples of properties are: