Radoslav Menkyna
email: radoslav.menkyna@softec.sk

Valentino Vranić
email: vranic@fiit.stuba.sk

Aspect-Oriented Change Realization Based on Multi-Paradigm Design with Feature Modeling

Keywords: change, aspect-oriented programming, multi-paradigm design, feature modeling, change interaction

It has been shown earlier that aspect-oriented change realization based on a two-level change type framework can be employed to deal with changes so they can be realized in a modular, pluggable, and reusable way. In this paper, this idea is extended towards enabling direct change manipulation using multiparadigm design with feature modeling. For this, generally applicable change types are considered to be (small-scale) paradigms and expressed by feature models. Feature models of the Method Substitution and Performing Action After Event change types are presented as examples. In this form, generally applicable change types enter an adapted process of the transformational analysis to determine their application by their instantiation over an application domain feature model. The application of the transformational analysis in identifying the details of change interaction is presented.

Introduction

Changes of software applications exhibit crosscutting nature either intrinsically by being related to many different parts of the application they affect or by their perception as separate units that can be included or excluded from a particular application build. It is exactly aspect-oriented programming that can provide suitable means to capture this crosscutting nature of changes and to realize them in a pluggable and reapplicable way [START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF].

Particular mechanisms of aspect-oriented change introduction determine the change type. Some of these change types have already been documented [START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF][START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF], so by just identifying the type of the change being requested, we can get a pretty good idea of its realization. This is not an easy thing to do. One possibility is to have a two-level change type model with some change types being close to the application domain and other change types determining the realization, while their mapping is being maintained in a kind of a catalog [START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF].

But what if such a catalog for a particular domain does not exist? To postpone change realization and develop a whole catalog may be unacceptable with respect to time and effort needed. The problem of selecting a suitable realizing change type resembles paradigm selection in multi-paradigm design [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF]. This other way around -to treat change realization types as paradigms and employ multi-paradigm design to select the appropriate one -is the topic of this paper.

We first take a look at the two-level aspect-oriented change realization model (Sect. 2). Subsequently, the approach to modeling change realization types as paradigms using feature modeling is introduced (Sect. 3). The approach employs the application domain feature model with changes expressed as features (Sect. 4). The key part of the approach is the transformational analysis -the process of finding a suitable paradigm -tailored to change realization (Sect. 5). Afterwards, it is shown how the transformational analysis results can be used to identify change interaction (Sect. 6). The approach is discussed with respect to related work (Sect. 7). Concluding notes close the paper (Sect. 8).

Two-Level Change Realization Framework

In our earlier work [START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF][START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF], we proposed a two-level aspect-oriented change realization framework. Changes come in the form of change requests each of which may consist of several changes. We understand a change as a requirement focused on a particular issue perceived as indivisible from the application domain perspective.

Given a particular change, a developer determines the domain specific change type that corresponds to it. Domain specific change types represent abstractions and generalizations of changes expressed in the vocabulary of a particular domain. A developer gets a clue to the change realization from the cataloged mappings of domain specific change types to generally applicable change types, which represent abstractions and generalizations of change realizations in a given solution domain (aspect-oriented language or framework). Each generally applicable change type provides an example code of its realization. It can also be a kind of an aspect-oriented design pattern or a domain specific change can even be directly mapped to one or more aspect-oriented design patterns.

As an example, consider some changes in the general affiliate marketing software purchased by a merchant who runs his online music shop to advertise at third party web sites (denoted as affiliates). 1 This software tracks customer clicks on the merchant's commercials (e.g., banners) placed in affiliate sites and whether they led to buying goods from the merchant in which case the affiliate who referred the sale would get the provision.

Consider a change that subsumes the integration of the affiliate marketing software with the third party newsletter used by the merchant so that every affiliate would be a member of the newsletter. When an affiliate signs up to the affiliate marketing software, he should be signed up to the newsletter, too. Upon deleting his account, the affiliate should be removed from the newsletter. This is an instance of the change type called One Way Integration [START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF], one of the web application domain specific change types. Its essence is the one way notification: the integrating application notifies the integrated application of relevant events. In this case, such events are the affiliate sign up and affiliate account deletion.

The catalog of changes [START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF] would point us to the Performing Action After Event generally applicable change type. As follows from its name, it describes how to implement an action after an event in general. Since events are actually represented by methods, the desired action can be implemented in an after advice [START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF]:

public aspect PerformActionAfterEvent {
pointcut methodCalls(TargetClass t, int a): . . .; after(/⇤ captured arguments ⇤/): methodCalls(/⇤ captured arguments ⇤/) { performAction(/⇤ captured arguments ⇤/); } private void performAction(/⇤ arguments ⇤/) { /⇤ action logic ⇤/ } } The after advice executes after the captured method calls. The actual action is implemented as the performAction() method called by the advice.

To implement the newsletter sign up change, in the after advice we will make a post to the newsletter sign up/sign out script and pass it the e-mail address and name of the newly signed-up or deleted affiliate.

As another example, consider a change is needed to prevent attempts to register without providing an e-mail address. This is actually an instance of the change type called Introducing Additional Constraint on Fields [START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF], which can be realized using Performing Action After Event or Additional Parameter Checking, but if we assume no form validation mechanism is present, even the most general Method Substitution (which wasn't considered originally [START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF] for this) can be used to capture method calls:

Generally Applicable Change Types as Paradigms

Generally applicable change types are independent of the application domain and may even apply to different aspect-oriented languages and frameworks (with an adapted code scheme, of course). The expected number of generally applicable change types that would cover all significant situations is not high. In our experiments, we managed to cope with all situations using only six of them.

On the other hand, in the domain of web applications, eleven application specific changes we identified so far cover it only partially. Each such change type requires a thorough exploration in order to discover all possible realizations by generally applicable change types and design patterns with conditions for their use, and it is not likely that someone would be willing to invest effort into developing a catalog of changes apart of the momentarily needs.

The problem of selecting a suitable generally applicable change type resembles the problem of the selection of a paradigm suitable to implement a particular application domain concept, which is a subject of multi-paradigm approaches [START_REF] Vranić | Towards Multi-paradigm Software Development[END_REF]. Here, we will consider multi-paradigm design with feature modeling (MPD FM ), which is based on an adapted Czarnecki-Eisenecker [START_REF] Czarnecki | Generative Programing: Methods, Tools, and Applications[END_REF] feature modeling notation [START_REF] Vranić | Reconciling Feature Modeling: A Feature Modeling Metamodel[END_REF]. Section 3.1 explains how paradigms are modeled in MPD FM . Section 3.2 and 3.3 introduces two examples of change paradigm models.

Modeling Paradigms

In MPD FM , paradigms are understood as solution domain concepts that correspond to programming language mechanisms (like inheritance or class). Such paradigms are being denoted as small-scale to distinguish them from the common concept of the (largescale) paradigm as a particular approach to programming (like object-oriented or procedural programming) [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF].

In MPD FM , feature modeling is used to express paradigms. A feature model consists of a set of feature diagrams, information associated with concepts and features, and constraints and default dependency rules associated with feature diagrams. A feature diagram is usually understood as a directed tree whose root represents a concept being modeled and the rest of the nodes represent its features [START_REF] Vranić | Binding Time Based Concept Instantiation in Feature Modeling[END_REF].

The features may be common to all concept instances (feature configurations) or variable, in which case they appear only in some of the concept instances. Features are selected in a process of concept instantiation. Those that have been selected are denoted as bound. The time at which this binding (or choosing not to bind) happens is called binding time. In paradigm modeling, the set of binding times is given by the solution model. In AspectJ we may distinguish among source time, compile time, load time, and runtime.

Each paradigm is considered to be a separate concept and as such presented in its own feature diagram that describes what is common to all paradigm instances (its applications), and what can vary, how it can vary, and when this happens. Consider the AspectJ aspect paradigm feature model shown in Fig. 1. Each aspect is named, which is modeled by a mandatory feature Name (indicated by a filled circle ended edge). The aspect paradigm articulates related structure and behavior that crosscuts otherwise possibly unrelated types. This is modeled by optional features Inter-Type Declarations, Advices, and Pointcuts (indicated by empty circle ended edges). These features represent references to equally named auxiliary concepts that represent plural forms of respective concepts that actually represent paradigms in their own right (and their own feature models [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF]). To achieve its intent, an aspect may -similarly to a class -employ Methods (with the method being yet another paradigm) and Fields.

An aspect in AspectJ is instantiated automatically by occurrence of the join points it addresses in accordance with Instantiation Policy. The features that represent different instantiation policies are mandatory alternative features (indicated by an arc over mandatory features), which means that exactly one of them must be selected. An aspect can be Abstract, in which case it can't be instantiated, so it can't have Instantiation Policy either, which is again modeled by mandatory alternative features.

!"#$%& '(&$)*+,#$- .$%/0)0&12("! '("&0(&10&12(- 32/1%, !"#$%&"! 4&0&1% 506$ 71(0/ !891%$"! 321(&%:&"! 71$/8" ;$&<28"! 41(=/$&2( 3$)->?@$%& 3$)-A2(&)2/-7/2B 321(&%:&! 321(&%:&! C<2/$ D$/2B 4%2#$ '(&$)E0%$"! A/0""$"! '(<$)1&0(%$"! !%%$""! 3)191/$=$8 !?"&)0%&
Fig. 1. The AspectJ aspect paradigm (adopted from [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF]).

An aspect can be declared to be Static or Final. It doesn't have to be either of the two, but it can't be both, which is modeled by optional alternative features of which only one may be selected (indicated by an arc over optional features). An aspect can also be Privileged over other aspects and it has its type of Access, which is modeled as a reference to a separately expressed auxiliary concept. All the features in the aspect paradigm are bound at source time.

The constraint associated with the aspect paradigm feature diagram means that the aspect is either Final or Abstract. We use first-order predicate logic to express constraints associated with feature diagrams, but OCL could be employed, too, as a widely accepted and powerful notation for such uses (but even of wider applicability, e.g. instead of object algebras [START_REF] Navarčik | Object Model Notation[END_REF]).

Generally applicable changes may be seen as a kind of conceptually higher language mechanisms and modeled as paradigms in the sense of MPD FM .

Method Substitution

Figure 2 shows the Method Substitution change type paradigm model. All the features have source time binding. This change type enables to capture calls to methods (Original Method Calls) with or without the context (Context) and to alter the functionality they implement by the additional functionality it provides (Altering Functionality) which includes the possibility of affecting the arguments (Check/Modify Arguments) or return value (Check/Modify Return Value), or even blocking the functionality of the methods whose calls have been captured altogether (Proceed with Original Methods). Note the Context feature subfeatures. They are or-features, which means at least one them has to be selected. Method Substitution is implemented by an aspect (Aspect) with a pointcut specifying the calls to the methods to be altered by an around advice, which is expressed by the constraints associated with its feature diagram (Fig. 2).

Performing Action After Event

Figure 3 shows the Performing Action After Event change type paradigm model. All the features have source time binding. This change type is used when an additional action (Action After Event) is needed after some events (Events) of method calls or executions, initialization, field reading or writing, or advice execution (modeled as orfeatures) taking or not into account their context (Context). Performing Action After Event is implemented by an aspect (Aspect) with a pointcut specifying the events and an after advice over this pointcut used to perform the desired actions, which is expressed by the constraints associated with its feature diagram (Fig. 3).

Feature Model of Changes

For the transformational analysis, the application domain feature model that embraces the changes is needed. We will present how changes can be expressed in the application domain feature model in our running example of affiliate tracking software.

Expressing Changes in a Feature Model

In our affiliate marketing example, we may consider the following changes:

-SMTP Server Backup A/B -to introduce a backup server for sending notifications (with two different implementations, A and B) -Newsletter Sign Up -to sign up an affiliate to a newsletter when he signs up to the tracking software -Account Registration Constraint -to check whether the affiliate who wants to register submitted a valid e-mail address -Restricted Administrator Account -to create an account with a restriction of using some resources -Hide Options Unavailable to Restricted Administrator -to restrict the user interface -User Name Display Change -to adapt the order of displaying the first name and surname -Account Registration Statistics -to gain statistical information about the affiliate registrations

These changes are captured in the initial feature diagram presented in Fig. 4. The concept we model is our affiliate marketing software. 2 All the changes are modeled as optional features as they can, but don't have to be applied. We may consider the possibility of having different realizations of a change of which only one may be applied. This is expressed by alternative features. In the example, no Affiliate Marketing instance can contain both SMTP Server Backup A and SMTP Server Backup B. Some change realizations make sense only in the context of some other change realizations. In other words, such change realization require the other change realizations. In our scenario, hiding options unavailable to a restricted administrator makes sense only if we have introduced a restricted administrator account. This is modeled by having Hide Options Unavailable to Restricted Administrator to be a subfeature of Restricted Administrator Account. For a subfeature to be included in a concept instance, its parent feature must be included, too.

The feature -subfeature relationship represents a direct dependency between two features. Such dependency can be an indication of a possible interaction between change realizations. However, with alternative features, no interaction can occur because an application instance can contain only one change realization.

Partial Feature Model

Often, no feature model of the system is available. Creating the feature model of the whole system is difficult and time consuming. Fortunately, as it has been shown [START_REF] Vranić | Aspect-oriented Change Realizations and their Interaction Submitted to e-Informatica Software Engineering Journal[END_REF] -for the purpose of change interaction analysis, it is a partial feature model is sufficient. The process of constructing a partial feature model starts with the feature model in which aspect-oriented change realizations are represented by variable features that extend the existing system represented by a concept node as an abstract representation of the underlying software system, which is exactly the model we discussed in the previous section.

In partial feature model construction, only the features that potentially take part in change interaction are being identified and modeled. Starting at change features, we proceed bottom up identifying their parent features until related features become grouped in common subtrees [START_REF] Vranić | Aspect-oriented Change Realizations and their Interaction Submitted to e-Informatica Software Engineering Journal[END_REF].

A partial feature model constructed from the initial feature model of the changes being introduced into our affiliate marketing software (presented in Fig. 4) is depicted in Fig. 5. All the identified change parent features are open because the sets of their subfeatures are incomplete, since we model only the changes that affect them, and since there may be other changes in the future. At this stage, it is possible to identify potential locations of interaction. Such locations are represented as features of the system to which changes are introduced. The highest probability of interaction is among sibling features (direct subfeatures of the same parent feature) because they are potentially interdependent. This is caused by the fact that changes represented by such features usually employ the same or similar pointcuts which is generally a source of unwanted interaction. Such locations should represent primary targets of evaluation during the transformational analysis, which is the topic of the following section.

Newsletter

Interaction can occur also between indirect siblings or non-sibling features. However, with an increasing distance between features that represent changes, the probability of their interaction decreases.

Transformational Analysis

The input to the transformational analysis in multi-paradigm design with feature modeling [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF] are two feature models: the application domain one and the solution domain one. The output of the transformational analysis is a set of paradigm instances annotated with application domain feature model concepts and features that define the code skeleton.

A concept instance is defined as follows [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF]:

An instance I of the concept C at time t is a C's specialization achieved by configuring its features which includes the C's concept node and in which each feature whose parent is included in I obeys the following conditions: 1. All the mandatory features are included in I.

2. Each variable feature whose binding time is earlier than or equal to t is included or excluded in I according to the constraints of the feature diagram and those associated with it. If included, it becomes mandatory for I. 3. The rest of the features, i.e. the variable features whose binding time is later than t, may be included in I as variable features or excluded according to the constraints of the feature diagram and those associated with it.

The constraints (both feature diagram and associated ones) on the included features may be changed as long as the set of concept instances available at later instantiation times is preserved or reduced. 4. The constraints associated with C's feature diagram become associated with the I's feature diagram.

Transformational Analysis of Changes

For determining change types that correspond to the changes that have to be realized, a simplified transformational analysis can be used. Changes presented in the application domain feature model are considered to be application domain concepts, and generally applicable change types to be paradigms. A complete application domain feature model may be used if available, otherwise a partial feature model has to be constructed.

For each change C from the application domain feature model, the following steps are performed:

1. Select a generally applicable change type P that has not been considered for C yet.

2. If there are no more paradigms to select, the process for C has failed. 3. Try to instantiate P over C at source time. If this couldn't be performed or if P's root doesn't match with C's root, go to step 1. Otherwise, record the paradigm instance created.

Paradigm instantiation over application domain concepts means that the inclusion of some of the paradigm nodes is being stipulated by the mapping of the nodes of one or more application domain concepts to them in order to ensure the paradigm instances correspond to these application domain concepts.

If the transformational analysis fails for some change, this change is probably an instance of a new change type. The process should continue with AspectJ paradigms, which is the subject of the general transformational analysis [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF].

Example

We will demonstrate the transformational analysis on several changes in the affiliate marketing software (introduced in Sect. 4.1) with the AspectJ paradigm model [START_REF] Vranić | Multi-paradigm Design with Feature Modeling[END_REF] extended by feature models of the generally applicable change types (see Sect. 3) as a solution domain.

The Restricted Administrator Account change provides an additional check of access rights upon execution of specified methods. Methods should be executed only if access is granted. This scenario suites best to the Method Substitution change type which can control the execution of selected methods, and ensure displaying an error message or logging in case of an access violation event.

Figure 6 shows the transformational analysis of the Restricted Administrator Account change. The Target Class and Method Arguments features are included to capture additional context which is needed by the Proceed with Original Methods feature when the access is granted. The If Access Granted annotation indicates the condition of proceeding with the original methods. Note that the Banner Management and Campaign Management features are mapped to the Original Method Calls feature expressed by an annotation. This means that the change affects the behavior represented by them. Such annotations are crucial to change interaction evaluation (discussed in the next section).

!"#$%&'()*+#,#)#,%-./,0,-12' !"#$%&''3122 4/%5""&'6,#$' ./,0,-12'!"#$%&+ 7+8"5#! 9"+#/,5#"&' 7&:,-,+#/1#%/' 755%)-# 31:81,0-' !1-10":"-# ;<'755"++' ;+'=/1-#"& >1--"/ !1-10":"-# 3%-#"?#' !"#$%&' 7/0):"-#+ @1/0"#' 321++ 72#"/,-0' A)-5#,%-12,#B The transformational analysis of Account Registration Constraint would be similar. Again, we would employ the Method Substitution change type. The Original Method Calls feature would map to the Affiliate Sign Up feature and the original method will be executed only if a valid e-mail address is provided.

Figure 7 shows the transformational analysis of the Newsletter Sign Up change. Recall that this change adds a new affiliate to the existing list of newsletter recipients, which can be best realized as Performing Action After Event. In this case, the Events feature is mapped to the Affiliate Sign Up feature which represents the execution of the affiliate sign up method. Through Method Arguments, the data about the affiliate being added can be accessed (Affiliate Data) from which his e-mail address can be retrieved and subsequently added to the newsletter recipient list by the Action After Events feature. A similar transformation would apply to the Account Registration Statistics change.

Change Interaction

Change realizations can interact: they may be mutually dependent or some change realizations may depend on the parts of the underlying system affected by other change realizations [START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF]. The interaction is most probable if multiple changes affect the same functionality. As has been shown, such situations could be identified in part already during the creation of a partial feature model [START_REF] Vranić | Aspect-oriented Change Realizations and their Interaction Submitted to e-Informatica Software Engineering Journal[END_REF], but the transformational analysis can reveal more details needed to avoid the interaction of change realizations. Consider, for example, the Newsletter Sign Up and Account Registration Statistics changes. Despite they share the target functionality (Affiliate Sign Up), no interaction occurs. This is because both changes are realized using the Performing Action After Event change type which employs an after() advice. In such a situation, it is important to check whether the execution order of the advices is significant. In this particular case, it is not.

The Account Registration Constraint change represents a potential source of interaction with Newsletter Sign Up and Account Registration Statistics because it also targets the same functionality. This change is realized using the Method Substitution paradigm through which it can disable the execution of the method that registers a new affiliate. If the Newsletter Sign Up and Account Registration Statistics change realizations rely on method executions, not calls, i.e. they employ an execution() pointcut, no interaction occurs. On the other hand, if the realizations of these changes would rely on method calls, i.e. they would employ a call() pointcut, their advices would be executed even if the registration method haven't been executed, which is an undesirable system behavior.

In most cases, the interaction can be solved by adapting change realizations. Unsolvable change interaction should be introduced in the application domain model by constraints that will prevent affected changes from occurring together.

Related Work

The impact of changes implemented by aspects has been studied using slicing in concern slice dependency graphs [START_REF] Khan | Analysing Requirements Dependencies and Change Impact Using Concern Slicing[END_REF]. It has been shown that the application domain feature model can be derived from concern slice dependency graphs [START_REF] Menkyna | Dealing with Interaction of Aspect-oriented Change Realizations Using Feature Modeling[END_REF]. Concern slice dependency graphs provide in part also a dynamic view of change interaction that could be expressed using a dedicated notation (such as UML state machine or activity diagrams) and provided along with the feature model covering the structural view.

Applying program slicing to features implemented as aspects with interaction understood as a slice intersection has been applied so far only to a very simplified version of AspectJ. Extension to cover complicated constructs has been identified as problematic. Even at this simplified level, it appears to be too coarse for applications in which the behavior is embedded in data structures [START_REF] Monga | Investigating Feature Interactions by Exploiting Aspect Oriented Programming[END_REF].

Even if the original application haven't been a part of a product line, changes modeled as its features tend to form a kind of a product line out of it. This could be seen as a kind of evolutionary development of a new product line [START_REF] Bosch | Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach[END_REF].

As an alternative to our transformational analysis, framed aspects [START_REF] Loughran | Supporting Product Line Evolution with Framed Aspects[END_REF][START_REF] Loughran | From Requirements Documents to Feature Models for Aspect Oriented Product Line Implementation. In: MDD for Software Product-lines: Fact or Fiction?[END_REF] can be applied to the application domain feature model with each change maintained in its own frame in order to keep it separate.

Annotations that determine the feature implementation in so-called crosscutting feature models [START_REF] Kulesza | Instantiating and Customizing Aspectoriented Architectures Using Crosscutting Feature Models[END_REF] are similar to annotations used in our transformational analysis, but no formal process to determine them is provided.

An approach to introduce program changes by changing the interpreter instead based on grammar weaving has been reported [START_REF] Forgáč | Adaptive Approach for Language Modification[END_REF]. With respect to suitability of aspectoriented approach to deal with changes, it is worth mentioning that weaving -a prominent characteristic of aspect-oriented programming -has been identified as crucial for the automation of multi-paradigm software evolution [START_REF] Kollár | Multi-paradigm Approaches to Systems Evolution[END_REF].

Conclusions and Further Work

The work reported here is a part of our ongoing efforts of comprehensively covering aspect-oriented change realization whose aim is to enable change realization in a modular, pluggable, and reusable way. In this paper, we extended the original idea of having two-level change type framework to facilitate easier aspect-oriented change realization by enabling direct change manipulation using multi-paradigm design with feature modeling (MPD FM ) with generally applicable change types as (small-scale) paradigms.

We introduced the paradigm models of the Method Substitution and Performing Action After Event change types. We also developed paradigm models of other generally applicable change types not presented in this paper such as Enumeration Modification with Additional Return Value Checking/Modification, Additional Return Value Checking/Modification, Additional Parameter Checking or Performing Action After Event, and Class Exchange.

We adapted the process of the general transformational analysis in MPD FM to work with changes as application domain concepts and generally applicable change types as paradigms. We demonstrated how such transformational analysis can help in identifying the details of change interaction.

Our further work includes extending our approach to cover the changes realized by a collaboration of multiple generally applicable change types and design patterns. We also work on improving change type models by expressing them in the Theme notation of aspect-oriented analysis and design [START_REF] Clarke | Aspect-Oriented Analysis and Design: The Theme Approach[END_REF].

Fig. 2 .

 2 Fig. 2. Method Substitution.

!Fig. 3 .

 3 Fig. 3. Performing Action After Event.

Fig. 4 .

 4 Fig. 4. Changes in the affiliate marketing software.

Fig. 5 .

 5 Fig. 5. A partial feature model of the affiliate marketing software.

Fig. 6 .

 6 Fig. 6. Transformational analysis of the Restricted User Account change.

Fig. 7 .

 7 Fig. 7. Transformational analysis of the Newsletter Sign Up change.

This is an extended scenario originally published in our earlier work[START_REF] Bebjak | Evolution of Web Applications with Aspect-oriented Design Patterns[END_REF][START_REF] Vranić | Developing Applications with Aspectoriented Change Realization[END_REF].

In general, there may be several top-level concepts in one application domain.

Acknowledgements

The work was supported by the Scientific Grant Agency of Slovak Republic (VEGA) grant No. VG 1/0508/09 and SOFTEC, s. r. o., Bratislava, Slovakia.


Isabelle Côté

Maritta Heisel

Jeanine Souquières

On the Evolution of Component-based Software

In a component-based software system the different components communicate with each other through their interfaces, possibly using adapters. Whenever the requirements or the environment change, the component-based software system must be adapted accordingly. We present a method that supports a systematic evolution of component-based software at the architectural level. It is based on operators and modification schemata that help to identify different architectural alternatives to realize the evolution task.

Introduction

The component-based paradigm has received considerable attention in the software development field in academia as well as in the industry in the past years. A componentbased application consists of assembled, pre-fabricated components. Some of these components are considered to be black-boxes, i.e., their implementation cannot be changed as it is inaccessible. They possess interfaces that describe their visible behavior. In general, interfaces are not directly compatible, and an adapter is required to bridge this gap. Assembling a software system in a component-based way leads to well-structured and modular architectures with independent and re-usable components. The component-based paradigm provides a challenge for software evolution, i.e., the task of adapting the software system to new or changed requirements and/or environment. This is because the components themselves usually cannot be manipulated. It is only possible to rely on their interfaces for this matter. This, in turn, has an influence on the solution of the evolution task, as not all possible solutions are implementable. Therefore, an evolution method for component-based systems has to be tailored to address these special conditions. With this work, we propose a method that allows for a systematic evolution of component-based systems.

We focus on the architecture of the system to be evolved, relying on available documents. We propose different architectural evolution schemata that guide the engineer to determine different alternatives for the evolution to be performed. The method then provides some heuristics to help choosing from the different alternatives. Our method is intended to be carried out by human developers, even though some steps may be tool-supported.

The paper is organized as follows. In Section 2, we introduce the basic terminology used as well as the prerequisites under which our method can be applied. An overview of our evolution method is presented in Section 3, introducing the different schemata. In Section 4 we introduce the access control system, which serves as a case study and forms the starting point for our evolution. We then illustrate the application of the proposed method by evolving the access control system. Related work is discussed in Section 5. A summary and future work conclude the paper.

Basic terminology and Prerequisites

According to Jackson and Zave [START_REF] Zave | Four Dark Corners for Requirements Engineering[END_REF], the task in software engineering is to build a machine that operates in an environment and serves to improve that environment. The overall purpose the machine should serve is called the system mission. Requirements are optative statements expressing our wishes how the environment should behave, once the machine is in operation. Accordingly, requirements do not refer to the machine but only to the environment; they refine the system mission. To build the machine, a specification has to be constructed. Specifications are implementable requirements. They describe the machine and are the starting point for its construction. To transform requirements into specifications, domain knowledge is used. It consists of indicative statements, expressing facts and assumptions that are true in the environment.

For example, a requirement for an access control system is that only those persons are admitted to enter a building who have permission to be in the building. Such a requirement is not implementable because a software system does not know who has permission. To transform this requirement into a specification, we use the knowledge that each person who wants to enter the building possesses an entry card containing a user identification. Furthermore, a database is used to store which user has permission for the building. With this domain knowledge, we can derive the following specification: "Only those persons with an entry card are admitted to the building for whom the database contains an entry specifying that they have permission to be in the building." This optative statement is now implementable.

In this paper, we investigate how component-based software can be evolved in a systematic way. Thus, we consider the case where a machine, which is built from components, is already developed. A software component is a piece of software that is encapsulated and accessible only via well-defined interfaces. Components can be integrated into different environments. In general, it is not possible to access (and therefore, change) their implementation. To adapt a software component to different environments, adapters are used to connect different components whose interfaces do not coincide completely.

Our evolution method relies on several documents that need to be available. These are either available from the start or need to be reconstructed. Even in the first case it is advisable to consolidate the documents to make sure that they are up-to-date. First, prior to the evolution, the current situation should be described. Usually, this is done by writing a short text, providing an as-is status of the system and the shortcomings which have been identified. The shortcomings are the reason for the evolution task. Then, evolution requirements (eRs) are derived, based on the shortcomings stated in the descriptive text. We assume that the eRs are available, have been consolidated and are non-contradictory.

Second, the machine specification should be known, i.e., its behavior at its external interfaces. We use UML 2.0 sequence diagrams [START_REF]UML2: Unified Modeling Language: Infrastructure and Superstructure[END_REF] to express these specifications. An example can be found in Fig. 7.

Third, we need the component-based software architecture of the machine to be evolved. It can be represented, for example, by UML composite structure diagrams, see Fig. 3. Such diagrams contain named rectangles, called parts. They represent the components the software is built from. Parts may have ports, denoted by small rectangles. Ports may have interfaces associated to them. Provided interfaces are denoted using the "lollipop" notation, and required interfaces using the "socket" notation. The interfaces are described using interface classes known from UML. We distinguish different component layers in the architecture: one or more components implement those parts which are needed to fulfill the system mission (called application components). These application components are clearly separated from components handling auxiliary functionality (called adapters). An application component as well as the adapters may be modified when performing an evolution, whereas the third-party (black-box) components cannot be changed.

Finally, the communication between the different components must be specified, using again sequence diagrams. Figure 5(a) shows an example of the specification of such communication. Note that these specifications should always have a precondition expressing in which state the interaction begins, and a postcondition expressing in which state the interaction ends. The pre-and postconditions are denoted as state invariants in the sequence diagrams.

3 The Evolution Method

Expressing Evolution Tasks

We have identified two basic constituents, namely operations such as add, modify, replace, and delete on the one hand and elements such as requirement, environment, and component on the other hand. Based on these two constituents we form pairs that specify the kind of change that is required and which element is affected by the given evolution task. The basic operations have the following meaning:

add: something that is not yet present in the software system and which should be newly introduced, e.g., a light for users at an entry turnstile. modify: something that already exists, but has to undergo some modification in order to cope with a changed situation, e.g., a visual signalization is used differently than before. replace: a present part in the system should be exchanged by a new part, e.g., the light bulb of a traffic light is replaced by a LED bulb with its corresponding software driver.

In general, the behavior of the software system should not change when performing a replacement. It may, however, be necessary to adapt the application component or the adapters. delete: something which has become superfluous is removed, e.g. an exit turnstile may no longer be needed. This case will not be considered in the rest of the paper.

The basic elements have the following meaning:

requirement: statements expressing our wishes how the environment should behave, once the machine is in operation. environment: that part of the "real world" which is relevant to our problem.

component: the black-box entities we possess.

However, not all combinations make sense. The prohibited combinations are: Add, delete component: Usually, adding or deleting a component becomes necessary by some reason which lies in adding, deleting or modifying requirements and/or the environment. A component itself does not account for its addition or deletion.

Modify component: Components are considered as black-boxes and their source code is not supposed to be accessible.

Replace requirement: We treat a replacement as a special kind of modifying a requirement.

Note that additions, modifications, or deletions in the environment usually influence at least one requirement. Therefore, applying an operator involving the environment usually triggers the application of another operator involving a requirement. Hence, we consider environment and requirement as one entity. However, evolving requirements need not imply effects on the environment.

Schemata

We have developed architectural evolution schemata that specify how a component-based software architecture can evolve in different cases. Each schema specifies which parts of the software are affected by the evolution and which parts will remain unaffected. These schemata will be detailed at the appropriate places in Subsect. 3.2.

The Evolution Method

To describe our method we use a pseudo code-like notation containing procedure definitions and procedure calls (cf. Alg. 1). The procedure parameters are characterized as follows: in These parameters constitute input parameters, which means that they are read but not changed. inout The parameters here are read and may be changed, as well. out These parameters are output parameters. They are generated by the procedure. In the following, we detail the different steps of Alg. 1: investigate (line 1) The first step is to get an understanding of the software (in parameter sw) and its components. The actions to be performed are to verify whether all relevant documents (inout parameter docs) are available and up-to-date. Should this be not the case, it is necessary to reconstruct the missing documents. After this, every eR is classified according to the combinations described in Subsect. 3.1. Furthermore, it is necessary to decide if the eR is mission-critical, i.e., it is needed to fulfill the system mission. Here, the following question provides some guidance on finding a solution: "Is the system still capable of fulfilling its purpose even if the new functionality fails?"

According to the answer to this question the eRs are being tagged as either missioncritical (answer: no) or not mission-critical (answer: yes). The classified and tagged eR then form the set of classified evolution requirements cRs (out parameter classi set). deriveExtSpec (line 2) As a second step, we derive a specification for every cR (in parameter classi set). The specifications we consider here are machine specifications i.e. they describe the machine behavior that is visible at the external interfaces. The following actions have to be performed for the different classifications: add(requirement, environment), modify(requirement, environment): transform the evolution requirement into a machine specification; update the domain knowledge if necessary. Replace(environment), replace(component): update the domain knowledge. The obtained specifications form the set of machine specifications (out parameter ev set). selectEspec (line 4) As a next step, we select one of the machine specifications. How the selection is performed depends on the given circumstances. deriveAltern (line 5) For the selected specification (in parameter curr spec) we derive possible alternatives solving the problem. For that purpose, we need to ask ourselves: "How can this behavior be realized internally?" This is necessary, because at the moment we only have a machine specification describing the external behavior that is visible to the environment. In particular, we have to inspect all pre-and postconditions that are used in the available internal specifications. Then, we have to decide if we find conditions that can serve as a pre-or a postcondition for the new specification.

The actions to be performed for the different evolution cases are: add(requirement, environment) Collect all sequence diagrams related to the evolution task. Compare the resulting diagrams according to either common starting states (preconditions) or common terminating states (postconditions) with the selected evolution specification. This results in the following cases:

• Schema I for Addition (Fig. 1(a)). The left-hand side shows the current state with an application component which may or may not have interfaces to other connected components (not shown in the figure). This schema adds a new interface to the application which connects it to the new component.

If no common state can be found in the sequence diagrams, this schema should be applied. Note that it is always applicable. • Schema II for Addition (Fig. 1(b)). In contrast to the previous schema, it is not necessary to add a new interface to the application component. Instead, the new component is handled together with an already existing component. The corresponding adapter is changed to mediate the communication of the two (or more) components with the application. The already existing interfaces remain unchanged and a new interface has to be added to the adapter.

If an internal specification can be found that shares a state with the evolution specification, then this schema can be applied; depending on the following cases: ⇤ Both specifications share the same precondition: the application informs the adapter about the met precondition. The adapter then sends appropriate signals to the old as well as the new component.

⇤ Both specifications share the same postcondition: the old and the new component inform the adapter that they established the terminating condition.

The adapter then processes this information and informs the application. ⇤ The precondition of the existing internal specification is the postcondition of the evolution specification: the new component informs the adapter that it established the postcondition; the adapter then informs the old component that the precondition is met. ⇤ The postcondition of the existing internal specification coincides with the precondition of the evolution specification: analogues to the previous case. modify(requirement, environment)

We have both the original specification as well as the modified and new additional sequence diagrams, respectively. The different schemata for modifying are:

• Schema I for Modification (Fig. 3.2). The original and modified specification are sufficiently similar. The modification can be handled completely by the corresponding application component. • Schema II for Modification (Fig. 2(a)). The modifications in the specification are related to the adapter. • Schema III for Modification (Fig. 2(b)). The modified specification relies on information that was not processed in the current version, e.g., it uses services the component provides but have not been of interest previously. Then, the application as well as the adapter have to be modified. replace(environment), replace(component)

It is necessary to investigate the interfaces which are already present as well as the interfaces of the new component:

• Schema I for Replacement (Fig. 4(a)). This schema can be applied if the new component is sufficiently similar to the old one and the data that is required or provided by this new component can be converted by the adapter. The application as well as the interfaces between adapter and application remain unaffected. • Schema II for Replacement (Fig. 4(b)). The interfaces between the application and the adapter cannot be retained. This is usually the case when the data being transmitted changes and the conversion cannot be performed by the adapter alone.

Note that when deriving the different alternatives, it may become apparent that further evolution tasks are needed in order to fulfill the current evolution task. Whenever this occurs, the method has to be applied for every resulting additional evolution requirement.

assessAltern (line 6) Subsequently, it is necessary to decide which of the determined alternatives should be chosen. Here we rely on the tags introduced during the investigation step (cf. Alg. 1 line 1): If the task is tagged with "not mission-critical", schemata leaving the application component unaffected are to be preferred. The rule of thumb is: "The application should only be changed if the new functionality is mission-critical."

All the alternatives determined in deriveAltern constitute valid solutions. However, each alternative with its underlying schema has its advantages and disadvantages. These have to be weighed in order to find the schema which fits best under the given circumstances:

-Schema I for Addition provides the advantage of guaranteeing a well-structured architecture. Each component remains independent and reusable. On the other hand the application might get too complex, which would make future evolutions difficult. -Schema II for Addition does not require changes of the application component.

The possibility to arrange the components in several ways (grouping old and new components together), based on the same schema is an advantage. However, some solutions may complicate further evolution tasks. Furthermore, the adapter may take over too much functionality, mutating into an application-like component. It should be avoided that the adapter gets too complex.

-Schema I for Modification makes changes to the application, which seems to be a drawback. However, as only the application needs to be changed (all the other parts remain unaffected), this also constitutes the advantage of this schema. -In contrast to the previous schema, Schema II for Modification only requires changes to the adapter in order to implement the modified functionality. Therefore, this schema should be preferred whenever possible. -Schema III for Modification requires changes to the adapter as well as to the application. If it is possible, one of the other modification schemata should be preferred. -Schema I for Replacement constitutes the desirable case when replacing a component as it only requires changes to the adapter. Similar to Schema II for Addition, it has to be avoided that the adapter gets too complex. -Schema II for Replacement should be avoided where possible if the new functionality is not mission-critical, as many changes are necessary in order to implement the replacement.

These advantages and disadvantages should be taken into consideration when choosing between different evolution alternatives. They can serve as heuristics or rules-of-thumb. However, for the final decision human comprehension and experience are necessary.

selectcand (line 7) After assessing the alternatives (in parameter as set), we select the alternative (out parameter cand) that is best suited for the current problem based on the reasoning performed in step assessAltern.

deriveIntSpec (line 8) For this alternative (in parameter cand) we derive the internal specification (out parameter spec).

evolve (line 10) We now incorporate the chosen alternative into the software system.

Application on the Case Study 4.1 The Base System

We evolve a simple access control system already used for other investigations [START_REF] Afadl | Etude de cas : système de contrôle d'accès[END_REF], which controls the access to a building. Persons who are authorized to enter the building are equipped with a smartcard on which a user identification is stored. The access control system queries a database to obtain the information whether the person is permitted to enter the building. If access is granted, a turnstile located at the entrance is unblocked, so that the person can enter the building. At the exit of the building, another turnstile is installed. It is always unblocked and only serves to count the number of persons who have left the building. The software architecture for the controller is presented in Fig. 3. The top-most layer consists of the application component, which implements the mission-critical functionality. The bottom-most layer includes the software drivers. These drivers connect the software to the hardware components and cannot be changed. Therefore, they are shown in black. The middle layer consists of adapters. The adapters are used to connect the application component to the software drivers. In some cases it may be possible to omit such an adapter. The connection between the different interfaces is realized through required and provided interfaces (cf. Fig. 3). Thus, adapters implement the required services by the provided ones.

The required and provided interfaces in our software architecture are named according to the following convention, consisting of a compound of abbreviations. The first abbreviation, usually denoted by two to three letters of the component, indicates the first component e.g. Ap for application. The second abbreviation is either "P" for provided or "R" for required. The third abbreviation, indicates the second component to which the first component is connected via the interface, e.g. TSE for the entry turnstile adapter. Hence, the name Ap P TSE describes the provided interface of the application connected to the entry adapter.

Evolution: Visual Signalization

The original system does not possess any kind of visual signalization. Therefore, we can formulate the following evolution requirement (eR): (eR1) Add a green light that is lit for n seconds when a person is authorized to enter the building.

investigate (line 1) The first step now is to investigate the software. In our case, we assume that all prerequisites stated in Section 2 are fulfilled. Taking a look at our eR, it can clearly be classified as add(requirement, environment). Hence, we get cR1 add(r,e) . As the second step of the classification, we evaluate whether it is mission-critical. This can clearly be answered with "no". Thus, we tag cR1 add(r,e) as not mission-critical, resulting in cR1 add(r,e) , which is added to the set of classified evolution requirements. deriveExtSpec (line 2) For every member of the cRs (parameter classi set) we derive a machine specification. The corresponding machine specification for cR1 can be stated as follows, applying the rules for add(requirement, environment):

(eS1): If has permission3 , turn on green light for n seconds.

The sequence diagram of Fig. 7 illustrates this specification. We can then add it to the evolution set (parameter ev set). selectEspec (line 4) As we only have one member in our set, we select it. deriveAltern (line 5) With the current specification we derive all possible alternatives. For our example, we are able to find two sequence diagrams in the initial system, namely unblock Entry Turnstile (cf. Fig. 5(a)) and DB authorize (cf. Fig. 5(b)). They can be mapped to the following alternatives:

-Alternative I. We group properties together according to a common starting point, i.e., their common precondition (cf. has permission in Figs. 7 and5(a)). The idea behind this alternative is that it signalizes that a person is authorized at the same time the turnstile is unblocked. This corresponds to applying Schema II for Addition. In this case, we also apply Schema II for Addition. The resulting architecture shown in Fig. 6(b) looks similar to the one in Alternative I: the adapter is renamed into DBLightAdapter, and a new interface it added, as well. However, the change performed in this case is different. The adapter informs the Application that the person is authorized to enter the building via the message authorize(uid), which establishes the postcondition has permission(uid). Then, the adapter sends the message turn on to the Light, as presented in Fig. 9(a). Note that in both cases the adapters must have access to a timer component in order to deal with the timing constraints, i.e. to handle the necessary timeouts. -Alternative III. It introduces an independent component Light. In this case, we do not have to take into account any existing sequence diagrams. However, it is necessary to add a new port to the application component with corresponding interfaces (cf. Fig. 6(c)). The application knows that the precondition is met and sends the signal turn on to the light driver (cf. With this, we have our set of alternatives (parameter alt set).

assessAltern (line 6) We now have to assess all of alternatives (parameter alt set), in order to find the solution that fits best to our problem. Therefore, we also need to take into account the tag we assigned to the eR. We know, that the new functionality is not mission-critical. It rather addresses a usability concern. Keeping this in mind, we evaluate the different alternatives: Alternative I (Light grouped with Entry Turnstile). This alternative is very intuitive as entry and light serve the same purpose, namely admitting authorized persons to the building. Furthermore, it is not necessary to make any changes to the application as the adapter can handle the new behavior, as well.

Alternative II (Light grouped with Data Base). Similar to Alternative I, it is possible to group the light with the database as the light relies on a message sent by the database.

In contrast to Alternative I, however, it is not so obvious or intuitive to group the light with the database.

Alternative III (handling Light separately). Of course, this alternative provides the most modular and straight-forward solution. In contrast to the two other solutions, it is necessary to modify the application component.

With that, we have assessed all our alternatives (parameter as set).

selectcand (line 7) Based on the previous step, we select the alternative which is suited best for our current situation (parameter cand). Here, the experience of the engineers comes into play as the selection will be based on it.

deriveIntSpec (line 8) Usually, only the internal specification for the chosen alternative is derived (parameters cand, spec). In this paper, we derived specifications for each of the aforementioned alternatives. Figures 8,9(a), and 9(b), respectively, show the internal specifications for the three alternatives.

evolve (line 10) Incorporating the new functionality lies beyond the scope of this paper.

Related Work

The evolution of software has long been recognized as one of the most problematic and challenging areas in the field of software engineering. Yet, it has received relatively little attention in the past. Cheesman and Daniels [START_REF] Cheesman | UML Components -A Simple Process for Specifying Component-Based Software[END_REF] propose a process to specify component-based software, which starts with an informal requirements description and produces an architecture showing the components to be developed or reused, their interfaces and their dependencies. The approach may seem similar to ours. However, our aim is to evolve an existing system and not to specify a new system from scratch.

In an earlier paper [START_REF] Heisel | Adding Features to Component-based Systems[END_REF], we have addressed the problem of adding features to component-based systems. The method described there relies on the process proposed by Cheesman and Daniels [START_REF] Cheesman | UML Components -A Simple Process for Specifying Component-Based Software[END_REF]. It does not consider architectural patterns. Methodological aspects of evolving a given component-based system to make it more dependable have been introduced in [START_REF] Lanoix | Enhancing Dependability of Component-Based Systems[END_REF]. The approach is to increase the dependability of componentbased software by taking exceptional behavior into account. The aim is to preserve the normal cases implemented by the application by intercepting and possibly modifying its inputs and outputs to "shield" it against the exceptional behavior.

Sadou et al. [START_REF] Sadou | A Unified Approach for Software Architecture Evolution at Different Abstraction Levels[END_REF] propose a model for software architecture evolution composed of three abstraction levels: the meta level, the architectural level and the application level. It offers a set of evolution concepts, namely operations, rules, strategies and invariants, to describe and manage uniformly the evolution of architectures at the architectural level as well as at the application level. With this approach we share the usage of evolution operations such as addition, deletion, etc. In [START_REF] Tamzalit | Connectors Conveying Software Architecture Evolution[END_REF], the authors enhanced their previous work by enriching the semantic of connectors to be able to determine and propagate the impact of evolutions. The focus of their work, however, lies more with the structure of the architecture. Our approach, in contrast, is aimed at providing different realization alternatives for a given evolution task at the architectural level and then to modify the software according to the chosen alternative.

A framework for designing software architecture through step-by-step refinements is proposed in [START_REF] Barais | Safe Integration of New Concerns in a Software Architecture[END_REF]. The main idea of this project is inspired by the aspect-oriented software development concepts. It provides three main features: a mechanism to add new concerns to a software architecture specification, a description model for software architecture and specific rules, which guarantee the correct integration of a technical concern into a business model. The decision on where to put the new concern is left to the architect in this approach with no further help. Our approach is aimed at deriving different schemata as alternatives for one concern. The architect can then use these schemata to base the decision where to put the new concern.

In the approach proposed by Casanova et al. [START_REF] Casanova | Supporting Evolution in Component-Based Development Using Component Libraries[END_REF], the authors review the concepts of version and configuration management in order to apply them in the context of component-based software development. The use of multi-dimensional component libraries is proposed as well as a configuration model for component-based applications based on components and connectors. In this way, the libraries not only support component storage and retrieval, but also version and configuration management of components. The focus of this approach is to classify, document, retrieve and version components, not to evolve the software system at the architectural level.

Conclusion and Future Work

In this paper, we have described a method that applies schemata and heuristics to guide software engineers through evolution tasks. With this method, it is possible to perform component-based software evolution systematically on the architectural level whenever new requirements or changes in the application environment occur.

As a proof of concept, we evolved an access control system. The evolution was achieved by applying our method step-by-step using the schemata to determine several alternatives for the same evolution task. These alternatives have then been assessed according to heuristics provided by the method to find the solution which fits best under the given circumstances.

In summary, the advantages of our approach are the following:

-It gives guidance on how the addition, modification, or replacement of components, environment or requirements can be performed in a systematic way. -Using the combination of operator and element, it is possible to classify the evolution. -Architectural schemata describe how and where the changes have to be implemented. -It is possible to determine several solutions for the same evolution requirement.

Heuristics help to choose from the different alternatives.

We are currently working on a workflow-tool that supports the software engineer in carrying out evolution tasks based on our method.

Fig. 1 .

 1 Fig. 1. Schemata for Addition.

Fig. 2 .

 2 Fig. 2. Schemata for Modification.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Software architecture of the access control system.

Fig. 5 .

 5 Fig. 5. Internal specifications.

Fig. 6 .

 6 Fig. 6. Different solutions for Scenario I.

Figure 6 (

 6 Figure6(a) illustrates the corresponding architecture according to the application of this schema. A new component Light is connected to the adapter of the Entry Turnstile. The Entry Adapter is renamed to EntryLightAdapter. Originally, the adapter translated the signal unblock of the Application in the signal unlock provided by the Entry Turnstile. The evolved adapter still sends the message unlock to the Entry Turnstile. In addition, it sends the signal turn on to the Light via the newly introduced interface, as presented in Fig.8.-Alternative II. The sequence diagram shown in Fig.5(b) specifies the communication between the Application and the Data Base. Its postcondition has permission matches the precondition of the sequence diagram Light behavior (cf. Fig.7).In this case, we also apply Schema II for Addition. The resulting architecture shown in Fig.6(b) looks similar to the one in Alternative I: the adapter is renamed into DBLightAdapter, and a new interface it added, as well. However, the change performed in this case is different. The adapter informs the Application that the person is authorized to enter the building via the message authorize(uid), which establishes the postcondition has permission(uid). Then, the adapter sends the message turn on to the Light, as presented in Fig.9(a). Note that in both cases the adapters must have access to a timer component in order to deal with the timing constraints, i.e. to handle the necessary timeouts. -Alternative III. It introduces an independent component Light. In this case, we do not have to take into account any existing sequence diagrams. However, it is necessary to add a new port to the application component with corresponding interfaces (cf. Fig.6(c)). The application knows that the precondition is met and sends the signal turn on to the light driver (cf. Fig.9(b)).

Fig. 9 Fig. 7 .

 97 Figure6(a) illustrates the corresponding architecture according to the application of this schema. A new component Light is connected to the adapter of the Entry Turnstile. The Entry Adapter is renamed to EntryLightAdapter. Originally, the adapter translated the signal unblock of the Application in the signal unlock provided by the Entry Turnstile. The evolved adapter still sends the message unlock to the Entry Turnstile. In addition, it sends the signal turn on to the Light via the newly introduced interface, as presented in Fig.8.-Alternative II. The sequence diagram shown in Fig.5(b) specifies the communication between the Application and the Data Base. Its postcondition has permission matches the precondition of the sequence diagram Light behavior (cf. Fig.7).In this case, we also apply Schema II for Addition. The resulting architecture shown in Fig.6(b) looks similar to the one in Alternative I: the adapter is renamed into DBLightAdapter, and a new interface it added, as well. However, the change performed in this case is different. The adapter informs the Application that the person is authorized to enter the building via the message authorize(uid), which establishes the postcondition has permission(uid). Then, the adapter sends the message turn on to the Light, as presented in Fig.9(a). Note that in both cases the adapters must have access to a timer component in order to deal with the timing constraints, i.e. to handle the necessary timeouts. -Alternative III. It introduces an independent component Light. In this case, we do not have to take into account any existing sequence diagrams. However, it is necessary to add a new port to the application component with corresponding interfaces (cf. Fig.6(c)). The application knows that the precondition is met and sends the signal turn on to the light driver (cf. Fig.9(b)).

Fig. 8 .

 8 Fig. 8. Internal spec. for Alt. I of Scenario I.

Fig. 9 .

 9 Fig. 9. Internal specifications.

has permission is the state reached when the database component sends the message authorized = true