cal: using constraints with action language for automating model ...

Software Engineering, 2013

CAL: USING CONSTRAINTS WITH ACTION LANGUAGE FOR AUTOMATING MODEL EVOLUTION1 Shahid Alam∗

evolution management in modeling languages and tools, it is highly desirable to integrate such support into these modeling languages and tools. None of the previous efforts, either commercial [2]–[8] or academic [9]–[15], support the automation of software evolution in a modeling language.

Abstract In this paper we examine two issues and propose solutions to resolve them. The first is the automation of model evolution and the second is the support of software evolution in modeling languages.

We

extend object constraint language with actions and define a new

1.1 Software Model Evolution

language constraints with action language (CAL), which gives a user the ability to use constraints with actions on software models.

Software is more than the source code. Models and metamodels play a key role in software evolution [16]. Software itself does not evolve but our understanding about it changes. Hence, the models that define the structure of the software change. Models are easier to change, and thereafter mapping such changes in implementation becomes cheaper. Model-driven architecture (MDA) [17] is an important software-design approach to model-driven software engineering (MDSE) [18], creating new opportunities for model evolution. To take full advantage of MDA, we need more research on model evolution. Executable UML [19] removes the platform specific model from MDA and directly generates code that can execute. To support executable UML evolution needs to be introduced at the model level. UML [20] does not have any modeling technique to automate software evolution. Neither object constraint language (OCL) [21] nor other languages [2]–[4] directly provide support for model evolution. We can identify changes using OCL but it cannot be used to change the state of the system [21]. Therefore, OCL alone cannot be used for making changes to a UML model. There are various efforts at detecting, tracing and managing evolution, but very few [10], [14], [22] deal with automating this process and none cover all the aspects mentioned above. Very few computer-aided software engineering (CASE) tools provide this facility either by themselves through a set of procedural application programming interfaces (APIs) [5], [7], [8] or by third party plug-ins such as Gateway [6] in Rhapsody. Even if it is provided, it is highly dependent on the CASE tool and requires a great amount of effort from the user, so this indirect support is not portable, flexible and automatic. There are two issues that our work examines and takes a step toward resolving them. One of them is the support

We have added a data type, directed acyclic graph (DAG) to CAL to optimize impact analysis and automate model evolution, and to make CAL more accessible to nonprogrammers. The DAG has been annotated (ADAG) with dependency weights, and a labeling scheme has been improved in size and used to optimize basic ADAG operations. CAL contains a small set of constructs, but is powerful enough to be used efficiently for typical software evolution management operations. A prototype tool visual CAL, for dependency analysis of unified modeling language (UML) class diagrams is presented.

Key Words Action languages, object constraint languages, model evolution, ADAG, impact analysis

1. Introduction and Motivation Of all the software development processes, evolution is the most expensive (man hours spent changing the software). It is shown that even experienced software professionals predict incomplete sets of software changes [1]. More time is spent on changing the software system than on its development. A software system starts changing before it is delivered. We believe that there is a need to evolve the system from the beginning. To achieve this, software evolution must be integrated into the design (model) of the software system. Due to the lack of support of software ∗

Department of Computer Science, University of Victoria, BC, Canada V8P5C2; e-mail: [email protected] 1 The work presented in this paper is an expansion of the author’s MASc thesis [24] and previously published work in the two conference papers [25] and [26]. Recommended by Prof. S. Xu (DOI: 10.2316/Journal.213.2013.1.213-1049)

1

Figure 2 shows the high level architecture of our CAL model evolution system. The ADAG and the tool VCAL has been explained in detail in the author’s MASc thesis [24] and the two conference papers: [25], [26]. In this paper, we just present a brief overview of the ADAG and the tool VCAL. The rest of the paper is organized as follows: Before describing CAL we present an overview of the data structure (ADAG) in Section 2. CAL is discussed in Section 3. We compare CAL with other such action languages in Section 4 and briefly describe the prototype tool VCAL (visual CAL) in Section 5. Section 6 discusses, and compares with CAL, the related work on automating model evolution. Finally we conclude and present some future directions in Section 7.

of software evolution in modeling languages. The other issue is the automation of model evolution. This paper makes the following contributions toward model evolution: • A solution is provided in the form of a modeling language constraints with action language (CAL). An overview of the CAL model is shown in Fig. 2. CAL gives a user the ability to use constraints with actions on models, and provides the user with tools to automate model evolution. • A new set of Collection directed acyclic graph (DAG) has been added to the CAL library. The DAG has been annotated (ADAG) with weights for dependency analysis and labeled to optimize basic ADAG operations. We have also formally defined rules to translate a UML class model to the CAL data structure (ADAG). • The CAL model, including all the CAL operations, libraries and actions have been formally specified using temporal logic of actions+ (TLA+) [23], and is verified using TLC, a TLA+ model checker (see Fig. 1). • A prototype tool, visual CAL (VCAL), has been developed to show how CAL can be used to automatically generate dependency relationships among model elements of UML class diagrams to perform typical software evolution management operations.

2. ADAG for Dependency Analysis and Model Transformation Dependency analysis is one of the methods used in impact analysis [27]. Each vertex in the ADAG is an entity and an edge represents the dependency relationship between two entities (vertices). An improved labeling scheme and dependency relationship weight are used to effectively visualize this dependency analysis as described in [24]–[26]. 2.1 Translating a UML Model to ADAG In this section we define rules for translating a UML model to ADAG and an example of UML class diagram translation rules is given below:

Figure 1. High level overview of the CAL model verification.

Figure 2. CAL model evolution architecture. 2

We extract, using pattern matching techniques, sets of all the following dependency relationships between UML class model elements, as defined in UML 2.0 [20]: Dependency; Composition; Generalization; Realization. Let V is the set of vertices and E the set of edges in ADAG; m, x, y and z are model elements, then R 1.1:

Vm (m ∈ V ) ∧ ¬ (¬ m ∈ V )

If x, y and z are model elements, and RD ∈ (Dependency ∨ Composition ∨ Generalization ∨ Realization), then R 1.2:

Vx,y (xy ∈ E) → ((x RD y) ∧ (y RD x))

R 1.3:

Vx,y (x RD y) → ¬ (y RD x)

R 1.4:

Vx,y,z ((x RD y) ∈ (y RD z)) → (x RD z)

R 1.5: Vx,y (x RD y) ∧ ((RD ∈ (Dependency ∨ Realization)) → (w(x) = 1) ∨ (RD ∈ (Generalization ∨ Composition)) → (w(x) = 2)) According to rule R 1.1 only the model elements become vertices of the graph. Rule R 1.2 states that if there is a relationship between two model elements x and y, then they become an edge in the graph. Rules R 1.3 and R 1.4 describe the relationship RD as nonreflexive and transitive respectively, so by definition this directed graph is a DAG. Rule R 1.5 assigns a self-weight of 2 if the relationship RD between two model elements, a supplier x and a client y, is a Generalization or Composition relationship, and a self-weight of 1 if the relationship RD between two model elements, a supplier x and a client y, is a Dependency or Realization relationship. This assignment of self-weight to the model elements is due to the couplings of different relationships between the UML class model elements as described in UML 2.0. These relationships are transitive and nonreflexive. This further augments Rules R 1.3 and R1.4.

Figure 3. Part of the main block of the CAL specifications, and the CAL data structure (ADAG) before and after annotations. • Well-defined grammar in a standard extended backus– naur form (EBNF) [28] form. • Formal specifications in TLA [23] for better comprehension, implementation and verification. • CAL parser implemented [24] in C++, which can easily be integrated into other modeling tools. An overview of the CAL model evolution architecture is shown in Fig. 2. In CAL we have extended OCL and added 5 actions, 10 operations and 1 data type (the data structure ADAG). As CAL is a complete extension of OCL, we do not describe OCL types, operations, library or usage. Interested readers are referred to OMG document [21] for readings on OCL. TLA is used to specify CAL. It is a tool for specifying the mathematical model of system’s behavioral properties. Using TLA to specify CAL is necessary because OCL do not have side effect on system behavior and thus, to verify ADAG, a behavioral specification tool is needed. We give below an example of a part of the main block of CAL specifications (Fig. 3). A TLC model checker, developed as part of the CAL verification process, translates CAL source into TLA for verification. One of the verification processes is visualized using the ADAG as shown in Fig. 3. For more details on this process and the use of TLA, the reader is referred to [24].

3. Constraints with Action Language Constraints with action language (CAL) is a text-based, scripting language defined for the purpose of model evolution, and can be extended and used as an action language or in model compilers for incremental recompilation and retransformation of models, in MDA [17]. CAL contains a small set of constructs, but is powerful enough to be used efficiently for typical software evolution management operations like impact analysis, correction, improvement and enhancement of models. CAL is an extension of OCL and is not specifically defined for UML. It supports generating the ADAG, as explained and defined in Section 2, of the model for dependency analysis. Before describing CAL in detail, we first list its basic characteristics: • Complete extension of OCL, so constraints can be used with actions. Hence, CAL combines both declarative and imperative programming paradigms. • A step toward automation for dependency analysis and model transformation.

3.1 CAL Grammar There are commercial and open source tools that support OCL that are listed in Table 2. None of the open source parsers is in C++, and the OCL commercial tools are 3

CHANGE_RATE (defined in the CAL library). CHANGE_RATE is the number of objects changed and can be used to calculate the percentage of objects that change from one version to the next, which is called change rate [30]. Similarly create and delete increment or decrement the global variables OBJECTS_ADDED and OBJECTS_REMOVED respectively to calculate the growth rate [30], which is the difference between added and removed objects. For a detailed explanation and usage of all these actions readers are referred to [24].

highly dependent on the tool vendor integrated development environment (IDE). There is no open source OCL grammar for LL(1) parsing, so we decided to start from scratch and write our own grammar for OCL and extend it for CAL. We have used formal grammar to define the language for its obvious advantages of making parsing and translation of CAL simpler. The grammar for OCL 2.0 has been extracted from the OMG document [21]. The extracted grammar has been extended and production rules have been added for different actions. The complete listing of the CAL grammar in EBNF[28] is given in [24]. The CAL grammar has been optimized for LL(1) parsing [29] by removing left recursion and using left factoring in the parser. In the process, a new set of production rules, such as LogicalStmt, RelationalStmt, AdditiveStmt, UnaryStmt and MultiplicativeStmt, which are not defined in the concrete syntax of OCL [21], has been added in the grammar for different operations. There are three basic statements in the grammar, OclStmt, ActionStmt and DefStmt. A CAL file starts with package and ends with endpackage. In between comes the statements, which are of three types, attrOrAssocContext, classifierContext and operationContext. They all end with either DefStmt, OclStmt or ActionStmt.

4. CAL and Other Action Languages This section discusses and compares action languages and their support for impact analysis. It is outside the scope of this paper to cover all such action languages. Only those that are related to software models at a higher level of abstraction and specifically used for MDSE [18] are discussed. We have not included the action languages discussed in [31], as they have more or less the same characteristics as the action languages discussed in this paper, and as they are also not currently used in any industrial or academic settings. 4.1 Comparison

3.2 Production Rules Added for CAL Table 1 gives a comparison of CAL with three other action languages. The rationale for the comparison of these languages with CAL is that they are based on actions and they are capable of manipulating (changing) a UML model. We would like to see if they provide any support for impact analysis or for using constraints. We would also like to explore the potential and advantages of CAL for use as an action language. The main purpose of these action languages is to make UML models executable. Unlike OCL they can be used to make changes, but these changes do not affect the model, because, except for action specification language (ASL), they can only instantiate an object but cannot create a new object in the model. They can also be used to navigate the model, just like OCL. These action languages are designed with the design part of the software life cycle in mind, and hence they lack software maintenance capabilities (impact analysis, propagation of changes, refactoring, etc.). Code can be generated in different languages like Java or C++ from UML models, or the models can be directly executed on a specific platform. They all are similar to OCL, but their syntax is quite different from OCL. CAL completely supports OCL concrete syntax. All of these action languages support action semantics (AS) [32] and AS does not have any concrete syntax, so each language has its own syntax. These action languages are more powerful than CAL in manipulating the models; however, CAL is an academic effort and its purpose is to prove a concept, which is very new to the models and which none of them supports. Moreover, CAL can be extended to accommodate all that is offered by these languages. The main question that comes to mind here is why we need another language with a different syntax than OCL to manipulate models. Why not extend OCL, add actions like CAL and you

There are five kinds of action statements that have been added for CAL: createStmt, deleteStmt, addAttrStmt, createLinkStmt and deleteLinkStmt. As each name suggests, they can be used to create or delete methods or attributes, and create or delete links or associations between elements. These production rules have been added to perform model evolution (change) tasks. For a complete list of CAL production rules readers are referred to [24]. 3.3 CAL Library Like OCL, CAL is a typed language, so we have defined another collection type, DagType, for the CAL data structure (ADAG). In addition to the OCL library defined in [21], CAL contains an additional library function, Dag. This library function can be used to create the ADAG of a UML model. The methods depend and descendants check for dependency between two elements and all the descendants of an element respectively. The production rules deleteStmt and deleteLinkStmt added for CAL check the dependency using the library function depend, and accordingly the dependent objects are deleted or unlinked. The collection type DagType in CAL is used to define the ADAG. The complete process of using the ADAG can also be displayed visually using one of the CAL library operations, view, to let the software design or maintenance engineer decide where and what changes are to be made to the model. For a detailed listing and explanation of the CAL library readers are referred to [24]. 3.4 CAL Actions CAL actions, create, delete, link, unlink and addattr, are responsible for incrementing the global variable 4

Table 1 Comparison of CAL with Other Action Languages Feature

CAL

OAL

ASL

PAL

Standard supported

OCL 2.0 and based on action semantics of UML

Based on action semantics of UML

Based on action semantics of UML

Based on action semantics of UML

Executable UML Partially supported1

Supported

Supported

Supported

Impact analysis

Supported

Not supported

Not supported

Not supported

Extendable

Yes

Yes

Yes

Yes

Control statements

If-then-else-endif (same as OCL)

if-elif-else-end if

If-then-else-endif and switch-case-endswitch

if-else if-else

Loops

iterate

for-each-end for and while-end while

for-do-end for and loop-endloop

for-each-where and while

Data structure supported

All OCL2 collections and the ADAG3 (for impact analysis)

Not supported

Set6 with hierarchical data support

Group (ordered set of items) and GroupIter (iterator over group)

Navigation

Yes

Yes

Yes

Yes

Communication Messages (OCL)

Events

Signals

Events

Operators

Same as OCL

Almost same as OCL

Almost same as OCL

Almost same as OCL

Actions

Objects can be and added but cannot be instantiated

Objects cannot be created or added but can be instantiated

Objects can be created, Objects cannot be added and can also created or added but be instantiated can be instantiated

Timers

Not supported

External4 timer and internal5 supported

Relative and absolute timer

Tool support

An interoperable prototype BridgePoint UML Suite CASE tool iUML Æby PathMate Transformation c by Mentor Graphics Kennedy Carter Limited Engine by c tool has been implemented  PathFinder as part of the research Solutions

1

Not supported

Executable UML as a model is supported for manipulation, but the generation of code or executable model/platform is not supported. 2 Example of defining one (the set) of the collections in OCL: set 2, 4, 1, 5, 7, 13, 11, 17. 3 Read Chapter 4 for more details. 4 Time external to the application. For example October 14, 2006. 5 The internal system clock that measures the time in ¨ ticks¨for supporting real-time systems. 6 Syntax for defining the set in ASL def ine structure < structure type name > < member name > < member type > < member name > < member type > enddef ine

programmers. For example, the syntax for defining a structure in these languages is like a high-level language (PAL’s syntax is more like C++). In CAL it is more like OCL, and even simpler than OCL for a complex task of impact analysis, therefore using CAL, both programmers and nonprogrammers can understand and discuss the model with each other, which greatly reduces the time and cost of completing any software system or software project.

obtain the same powerful language at a higher level of abstraction to manipulate models? They use AS but are not based on any industrial standard, so they are not interoperable between different tools. It is better and more advantageous to learn a language that is an extension of OCL, which is an industrial standard, that can support the same functionalities as these action languages. From Table 1 it is clear that these languages are quite different from OCL. One of the purposes of defining a high-level modeling language (UML, OCL) is that it can be used by programmers and nonprogrammers because it provides the same understanding of the design. The three action languages mentioned above are meant for skilled

5. VCAL A visual CAL parser tool, VCAL, has been implemented in Java with a graphical user interface (GUI). The complete 5

VCAL implementation consists of 15 C++ classes (the CAL parser) and 26 Java classes. We have used BigInteger API of Java 1.5 to implement the ADAG labeling, so java runtime environment (JRE) 1.5 is required to run VCAL. VCAL loads a UML model and uses the CAL parser to parse CAL files. Rules have been defined to translate a UML model to the CAL data structure (ADAG) as mentioned and listed above. After translating these rules and generating the ADAG, VCAL interprets the CAL actions and operations in a CAL file and then executes these actions and operations on the ADAG. VCAL also provides an interactive GUI, which can be accessed using one of the CAL operations, view. The VCAL GUI displays the ADAG and provides tools for the user to apply basic filters (viewAncestors, viewDescendants, viewBoth and viewAll ) to the ADAG. This graphical abstraction (also called ADAG filters ) helps the user focus on the relationships among the elements of the model that are being maintained. The complete VCAL API documentation and user manual can be found in [24], [33]. A complete example is available as an online demonstration [33]. A case study is carried out in [24] to assess the usefulness and effectiveness of CAL. In future we will carry out more case studies using industrial applications.

6.2 Recent Languages for Model Transformation Naoyasu Ubayashi and others developed the aspectoriented modeling language AspectM (aspect for modeling) [22]. AspectM is used [12] to demonstrate the effectiveness of aspect-orientation in terms of model evolution. AspectM only supports adding aspects that are not dependent on others and performs no impact analysis. It does not support pre- and postconditions or invariants, and hence there is no support for defining contracts or constraints. The authors are working on extending AspectM to add support for defining contracts. They proposed a language, contract writing language (COW) [36], that can be used for defining contracts. C-SAW [13] from the Institute for Software Integrated Systems (ISIS), Vanderbilt University, is a transformation engine for manipulating models that shows how tools can be used to automate model evolution. A tool (an engine) is developed [10] to specify the transformation rules to act as a front end to C-SAW. The aspects and strategies for model weaving are based on the language embedded constraint language (ECL) [37]. It is used for describing the location and behavior of the change to be performed on the source models. Like CAL, it provides operators to change the model, addModel, addConnection, removeModel and removeConnection. Transformation rules (behavior of the change) can be specified in the form of a strategy, but it is not clear if any impact analysis is performed before transforming or making changes to the model, which is very important for maintaining software. ECL is implemented using generic modeling environment (GME), a configurable toolset that supports domain-specific modeling environments, so unlike CAL, it is a domain-specific language. ECL borrows some concepts from OCL but is not a complete extension of OCL. There are no OCL-like syntaxes for pre- and postconditions for defining contracts in ECL. Only preconditions can be applied inside strategies using a different syntax than OCL.

6. Related Work in Software Model Evolution Most software evolution techniques target the source code level. There is much less support at a higher level (models) of abstraction. The major reason for this is the lack of support of tools for model evolution. In this section we discuss current efforts at automating model evolution and only cover languages and tools for model transformation and impact analysis. 6.1 Model Evolution and Impact Analysis Briand et al. [14], [34] proposed an approach to perform impact analysis of UML model elements and present promising empirical results, but it does not address making changes to the model. The changes in two versions of the model are automatically identified and reported. Impacted model elements are detected in the form of OCL collections (as Bags) by using 97 rules [34] defined in OCL. These rules are used to trace the impact of a change. A prototype tool, iACMTool, has been implemented to automate the process. In [35], impact analysis is performed using traceability analysis, which unlike dependency analysis gives a coarse evaluation of relationships between program entities. However, the authors claim that their traceability analysis technique gives detailed guidance as to what traces should be established to support impact analysis. The tool developed is good for tracing changes in requirements and documents, neither of which needs a detailed analysis of dependencies. QuaTrace is highly dependent on other tools (Rational Rhapsody [7]) and is not interoperable, and the use of APIs makes this approach difficult to implement for a nonprogrammer.

6.3 Impact Analysis Support in Commercial UML Tools Table 2 lists the tools that support OCL, including commercial, academic and open source, with a brief description of each tool. Only those tools are included that support OCL 2.0. The reason for listing them here is not to compare their technical features, but to compare the platform they support and where they are used (i.e., the license). Unlike the CAL parser, all the academic and open source tools are implemented in Java. Commercial tools are implemented using C++. This shows that the OCL tools that are being used in industry are still implemented in C++. Almost all the commercial CASE tools that support UML are implemented in C++ because of the graphical nature of the UML diagrams and notations. It takes much effort and skill from an average software engineer who is not a programmer to develop an impact analysis application or a tool using the APIs provided by the tool vendors. If not developed properly the application 6

Table 2 Current OCL Tools Tool Name

Description

Company 1

Platform

License

Java

Open Source

Octopus

An OCL plug-in for eclipse Klasse Objecten

Oclarity

Add-in for Rational Rose to support OCL

EmPowerTec2

Dresden OCL Toolkit

OCL parser

Dresden University of Technology3 Java

Open Source

OSLO (Open Source Based on the OCL Library for OCL) implementation of the University of Kent

University of Kent4

Java

Open Source

Bold for Delphi

Add-in to Borland Delphi IDE to support OCL

Borland Software Corporation5

Delphi (C++)

Commercial

The KeY Project

It is a formal software specification and verification tool. OCL is used as a basis for reasoning about the specification. It requires Borland Together for UML/OCL support.

University of Karlsruhe6

Java

Academic

OCLE (object constraint language environment)

OCL tool

University of City-Napoca7

Java

Academic

OCL Compiler Version 1.5

This is a demo version and an industrial version is under development

Cybernetic Intelligence GmbH8

Windows

Commercial

2

Rational Rose (C++) Commercial

1 octopus.sourceforge.net. www.empowertec.de/products/rational-rose-ocl.htm. 3 dresden-ocl.sourceforge.net. 4 oslo-project.berlios.de. 5 info.borland.com/techpubs/delphi/boldfordelphi. 6 www.ira.uka.de/key. 7 lci.cs.ubbcluj.ro/ocle/index.htm. 8

www.cybernetic.org.

them in the form of a modeling language, CAL. This solution provides more direct and explicit support for model evolution. CAL abstracts the details so even a nonprogrammer in a business environment can use it effectively. Formal specification of CAL allows better comprehension, implementation and verification. CAL provides tool to automate model evolution: CAL gives a user (modeler) the ability to use constraints with actions on models, provides a means to explicitly represent transformation behavior, and hence provides the user with tools to automate model evolution. The use of CAL in a tool provides automation: A prototype tool VCAL is presented to show how CAL can be used to generate dependency relationships among model elements of a UML class diagram to perform automatic impact analysis, correction, improvement and enhancement

or the tool may need to be developed or changed for each project. Because of the limited capabilities of these APIs the developer may not be able to define impact analysis rules at a higher level of abstraction. The tools and the options these tools provide are not automatic or portable and are highly dependent on the specific tool. There is a need to automate these tasks and make them flexible, interoperable and independent of any CASE tool and that is one of the motivations for CAL. 7. Conclusion and Future Work In this paper, we have examined two issues: the automation of model evolution and the support of software evolution in modeling languages. A solution is proposed to resolve 7

of the model, with as little input from the user as possible. The following areas could be explored as future research: (1) How can the CAL data structure be used to propagate change automatically to the transformed model or to the generated code, for the model compiler? (2) More case studies of using CAL specifically in industrial applications. (3) CAL can be extended for use as a full action language in MDA. To extend CAL as a full action language, not only do we need to add more actions, but we also need to define rules and mapping for translating CAL actions to code for different programming languages. For example, current CAL actions, operations and its data structure can be translated automatically to Java language, as is done manually in VCAL.

[20] Object Management Group (OMG) Inc., Unified modeling language: version 2.4.1, http://www.omg.org/spec/UML/2.4.1/ (accessed May 21, 2013). [21] Object Management Group (OMG) Inc., OCL 2.0 Specification Version 2.0, http://www.omg.org/spec/OCL/2.0/ (accessed May 21, 2013). [22] N. Ubayashi, T. Tamai, S. Sano, Y. Maeno, and S. Murakami, Model compiler construction based on aspect-oriented mechanisms, Proc. 4th GPCE, Berlin, Heidelberg, 2005, 109–124. [23] L. Lamport, Specifying systems: The TLA+ language and tools for hardware and software engineers (Boston, MA: AddisonWesley Longman Publishing Co., Inc, 2002). [24] S. Alam, Automating software evolution: Towards using constraints with action for model evolution, Master’s Thesis, Carleton University, 2007. [25] S. Alam and S.A. Ajila, Using constraints with action language for model evolution, Proc. Software Engineering Research & Practice (SERP), Volume II, Nevada, USA, 2007, 553–559. [26] S.A. Ajila and S. Alam, Using a formal language constructs for software model evolution, Proc. ICSC, Washington, DC, USA, 2009, 390–395. [27] R.S. Arnold, Software change impact analysis (Los Alamitos, CA: IEEE Computer Society Press, 1996). [28] Joint Technical Committee of ISO and IEC. Information Technology – Syntactic Metalanguage – Extended Backus-Naur Form, ISO/IEC 14977 : 1996. [29] A.V. Aho, M.S. Lam, R. Sethi, and J.D. Ullman, Compilers: Principles, techniques, and tools, 2nd ed. (Boston, MA: USA, Addison-Wesley Longman Publishing Co., Inc., 2006). [30] C. Larman and V.R. Basili, Iterative and incremental development: A brief history, Computer, 36(6), 2003, 47–56. [31] S.J. Mellor and M. Balcer, Executable UML: A foundation for model-driven architectures (Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 2002). [32] Object Management Group (OMG) Inc., Precise Action Semantics for UML, http://www.omg.org/spec/UML/2.4.1/ (accessed May 21, 2013). [33] S. Alam, CAL online, http://www.cs.uvic.ca/∼salam/thesis/ cal/cal.html (accessed Mar. 6, 2013). [34] L.C. Briand, Y. Labiche, and L. O’Sullivan, Impact analysis and change management of UML models, Proc. ICSM, Washington, DC, 2003, 256–265. [35] A. von Knethen and M. Grund, QuaTrace: A tool environment for (semi-) automatic impact analysis based on traces, Proc. ICSM, ICSM ’03, Washington, DC, 2003, 246–255. [36] S. Shinotsuka, N. Ubayashi, H. Shinomi, and T. Tamai, An extensible contract verifier for AspectJ, 2nd AOAsia, Tokyo, Japan, 2006, 35–40. [37] J. Gray, T. Bapty, E. Neema, and A. Gokhale, Aspect-oriented domain-specific modeling: A generative approach using a metaweaver framework, PhD Thesis, ProQuest Co., 2002.

References [1] M. Lindvall and K. Sandahl, How well do experienced software developers predict software change?, Journal of Systems and Softwares, 43(1), 1998, 19–27. [2] Accelerated Technology Embedded Systems Division of Mentor Graphics Corporation (MGC), Object action language c 2004, MGC. reference manual,  [3] I. Wilkie, A. King, M. Clarke, C. Weaver, and C. Rastrick, c 2001, ASL language reference level 2.5, manual revision C,  Kennedy Carter Limited. [4] Pathfinder Solutions. Platform independent action language c 2004, LLC Solutions. version 2.2 reference manual,  [5] IBM Corporation, Rational Rose, A UML visual modeling and application development solution, http://www-03.ibm. com/software/products/us/en/ratirosefami/ (accessed May 21, 2013). [6] IBM Corporation, Rational XDE (eXtended development environment) http://www.ibm.com/developerworks/rational/ products/xde/ (accessed May 21, 2013). [7] IBM Corporation, Rational Rhapsody , Collaborative design and development environment, http://www-03.ibm./ com/software/products/us/en/ratirhapfami/ (accessed May 21, 2013). [8] IBM Corporation, Rational TAU, A UML and SysML modeling tool, http://www-03.ibm.com/software/products/us/en/ ratitau/ (accessed May 21, 2013). [9] G. Suny´ e, A. Le Guennec, and J.-M. J´ ez´ equel, Using UML action semantics for model execution and transformation, Information Systems, 27(6), 2002, 445–457. [10] J. Zhang, Y. Lin, and J. Gray, Generic and domain-specific model refactoring using a model transformation engine (Springer-Verlag Heidelberg, Germany, 2005), 199–218. [11] L. Dobrza´ nski and L. Ku´ zniarz, An approach to refactoring of executable UML models, Proc. SAC, New York, NY, 2006, 1273–1279. [12] N. Ubayashi, S. Sano, Y. Maeno, S. Murakami, and T. Tamai, Model evolution with aspect-oriented mechanisms, Proc. IWPSE, Washington, DC, 2005, 187–194. [13] J. Gray, Y. Lin, and J. Zhang, Automating change evolution in model-driven engineering, Computer, 39(2), 2006, 51–58. [14] L.C. Briand, Y. Labiche, L. O’Sullivan, and M.M. S´ owka, Automated impact analysis of UML models, Journal of Systems and Software, 79(3), March 2006, 339–352. [15] T. Mens and T. D’Hondt, Automating support for software evolution in UML, Automated Software Engineering, 7(1), 2000, 39–59. [16] M. Jazayeri, Species evolve, individuals age, Proc. Eighth IWPSE, Washington, DC, 2005, 3–12. [17] Object Management Group (OMG) Architecture Board MDA Drafting Team, Model driven architecture guide version 1.0.1, June 2003. [18] D.C. Schmidt, Guest editor’s introduction: Model-driven engineering, Computer, 39(2), 2006, 25–31. [19] Object Management Group (OMG) Inc., Semantics of a foundational subset for executable UML models, http://www.omg. org/spec/FUML/1.1/ (accessed May 21, 2013).

Biography Shahid Alam is currently a PhD student in the Computer Science Department at University of Victoria, BC, working under professor R. Nigel Horspool and professor Issa Traore. He received his MASc degree from Carleton University, Ottawa, ON, in 2007. He has more than 5 years of experience working in the software industry. His research interests include programming languages, compilers, software engineering and binary analysis for software security. Currently he is looking into applying compiler optimizations, binary analysis and artificial intelligence techniques to automate and optimize malware analysis and detection. He is a member of IEEE. 8