URDAD Specified Processes onto Java EE

Mapping URDAD-Specified Processes onto Java-EE Student: Jacques Coetzee, Student Number: 11183153 Supervisor: Dr Fritz Solms November 6, 2014

Student’s Declaration Herewith I confirm that I have written this report by myself, and that I have not used any auxiliary means other than those which are clearly indicated as such in this report. Those text parts that have their origin - literally or conceptually - in other words, are clearly indicated as citations with complete references to their original sources. The typesetting system LATEX was used for the layout of this report. I am fully aware of the anti-plagiarism rules of the University of Pretoria, and I am also fully aware of the consequences in cases where those rules are violated.

1

Abstract The Use-Case, Responsibility Driven Analysis and Design (URDAD) methodology is used by requirements engineers for the design of system functional requirements. The design is specified as a Platform Independent Model (PIM), according to the Object Management Group’s Model Driven Architecture (MDA). It is then capable of transforming the resulting PIM into Platform Specific Models (PSMs) by using some given transformation language. This project extends work done by C. Edwards which focused on the semi-automatic transformation of an URDAD PIM into a Java EJB PSM. His work excludes the mapping of URDAD service specifications onto Java stateless session bean method bodies. Thus creating a new iteration on Edwards’ work, this project has successfully mapped a sub-set of URDAD service specifications onto Java stateless session bean method bodies. This makes URDAD more attractive for model specification and use in MDA.

2

Contents 1 Introduction 1.1 Model-Driven Architecture 1.2 URDAD Methodology . . . 1.3 Previous Work . . . . . . . 1.4 Problem . . . . . . . . . . . 1.5 Research Project Relevance 1.6 Project Scope . . . . . . . . 1.7 Solution . . . . . . . . . . . 1.8 Report Outline . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

2 Related work 2.1 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Transformation of BPMN Models to XML Models . . . . 2.3 Transformation of Java PSMs to UML Use Case Diagrams 2.4 Transformation of COSA Models to EJB Models . . . . . 2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . .

5 5 5 5 5 6 6 6 7

. . . . .

8 8 8 9 9 10

3 Method 3.1 Technology Relevance . . . . . . . 3.2 Tool Relevance . . . . . . . . . . . 3.3 Mapping Specification . . . . . . . 3.3.1 ActivitySequence Mapping 3.3.2 ContainerActivity Mapping 3.3.3 Choice Mapping . . . . . . 3.3.4 While Mapping . . . . . . . 3.3.5 ExceptionHandler Mapping 3.3.6 Create Mapping . . . . . . 3.3.7 RequestService Mapping . . 3.3.8 Assign Mapping . . . . . . 3.3.9 RaiseException Mapping . 3.3.10 ReturnResult Mapping . . . 3.4 Mapping Validation . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

11 11 11 12 12 13 13 14 15 15 16 17 17 18 19

4 Implementation 4.1 Core Design . . . . . . . . . . . 4.2 Transformation Details . . . . . 4.2.1 Point of Inception . . . 4.2.2 Activity Transformation 4.2.3 Choice Transformation . 4.3 Problems and Limitations . . . 4.4 Code Availability . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

20 20 21 21 22 23 26 26

3

. . . . . . .

. . . . . . .

5 Critical Analysis 5.1 Complex Transformations using QVT-R . . . . . . . . 5.2 Architecture Hard-Coding . . . . . . . . . . . . . . . . 5.3 Automated Validation . . . . . . . . . . . . . . . . . . 5.4 Suitability of URDAD for Model-Driven Development 6 Conclusion

. . . .

. . . .

. . . .

. . . .

27 27 27 27 27 29

4

1 1.1

Introduction Model-Driven Architecture

Model-Driven Architecture sets out to seperate the specification of system functionality and the implementation of that functionality on a given technology specific platform [15]. The MDA approach allows the same functionality to be realized on multiple platforms. This is achieved by mapping a Platform Independent Model (PIM) as the core artefact to one or more target Platform Specific Models (PSM) and eventually into concrete artefacts such as executable code [17][23]. A system’s functional requirements are specified in a PIM and is independent of any specific technology[22].

1.2

URDAD Methodology

The Use-Case, Responsibility Driven Analysis and Design (URDAD) methodology [26] provides (i) a method for generating PIMs, as well as (ii) a Domain Specific Language (DSL) providing semantics for capturing a given PIM. URDAD is a semi-formal, service orientated analysis and design methodology [26] which is used for the specification of a system’s functional processes’ design, as well as the form the specification should take [13].

1.3

Previous Work

This project extends a semi-automatic transformation of an URDAD PIM into a Java-EE EJB PSM done by C. Edwards [7]. Edwards has created a tool to perform and validate the model transformations, which was tested using a PIM based on non-trivial example. Edwards’ work excludes the transformation of URDAD service specifications representing the system’s dynamic behaviour into their corresponding EJB representations [7].

1.4

Problem

C. Edwards’ work [7] has to be extended to include the mapping of URDAD service specifications. Thus, the URDAD model needed to be assessed in order to determine whether the model has the required information and semantics to facilitate the mapping of service specifications onto automated processes which will reside in populated method bodies in the relevant Java stateless session beans.

5

1.5

Research Project Relevance

Model-Driven Engineering (MDE) refers to the creation and use of models which form part of the core of the software development process [14]. MDE aims to increase productivity by improving communication, allowing for possible automation and reducing the software development complexity by raising the level of abstraction [14]. Mapping the URDAD service specifications onto populated stateless session bean method bodies will automate the realization of those services. Automating such a process will eliminate the need for manual implementation leading to reduced project cost, implementation time, project resources and project risk.

1.6

Project Scope

Assess whether a given URDAD model has the necessary information and semantics to facilitate the mapping of service specifications onto automated processes residing in stateless session bean method bodies. This needs to be demonstrated through an implementation of such a mapping. Due to time constraints, the mapping of the following could not be done: the mapping of Object Constraint Language (OCL) [16] expressions, having an impact on all other objects relying on constraints. All objects relating to concurrency, as well as the service requirements associated with a given service. Concluding the project, an investigation needs to be done to find out what the benefits and disadvantages are of an URDAD-based process mapping when compared to alternative technology-neutral process specification approaches, as well as a comparison with other approaches.

1.7

Solution

Conceptual mappings have been done in order to determine whether a given URDAD model would have the required information and semantics to facilitate a mapping onto automated processes. A tool with a partial mapping implementation has been developed which is capable of successfully transforming URDAD process specifications onto Java-EE stateless session bean method bodies. This tool is also capable of generating Java code from the produced Java PSM. The populated session bean method bodies include the dynamic behaviour of processes like variable creations, conditions, service requests, exception handling, variable assignments, etc. 6

The PSM that was generated was compared with the source PIM to ensure that the mapping was correct, furthermore the generated Java code was validated by manual inspection. The inspection of the generated artefacts have shown that the tool works as expected and all the transformations have been performed as expected.

1.8

Report Outline

The remainder of the report is structured as follows: Section 2 presents previous work done, as well as related work and how they compare with this project. Section 3 discusses the methodology used in the project, including the technology and tools used. In section 4, the solution implementation is discussed in detail. Section 5 will provide a critical analysis on the work which has been done. The final section concludes the report by summarizing the work, as well as the relevance of the project and discusses future work.

7

2

Related work

This section discusses the previous work done to which this project extends and also other related work which used similar techniques and technologies. A comparison will be made between our work and what has been done. in addition, the relevance of this project will be highlighted, showing the importance of this project.

2.1

Previous Work

C. Edwards had raised the importance of an automatic transformation of URDAD PIMs into Java EE EJB PSMs in his work [7]. Having a tool which provides this functionality would eliminate the necessity of manually translating PIMs into PSMs and also having to implement the source code. Such a tool would thus eliminate inherit complexities, save time and produce less error prone artefacts. In addition, having access to such a tool might nudge organizations to follow an MDA approach and reap the benifits associated with MDA. After Edwards had concluded his work on the transformation of URDAD PIMs [7] , his work had formed the first major iteration of the transformation producing EJB structures that include full Java hierarchies representing all the data structures defined in a PIM. This excluded the transformation of automated processes and thus the transformation of URDAD service specifications still had to be done in order to further the progress of the transformation tool.

2.2

Transformation of BPMN Models to XML Models

A project had been done transforming a given Business Process Model and Notation (BPMN) model [20] into an XML model [11]. BPMN is an OMG standard, providing a graphical notation. Requirements engineers can use BPMN to define business process models. Both BPMN and URDAD can be used to specify business processes in a technology independent manner, but BPMN does not prescribe a design and analysis methodology. The BPMN models in this work has been described as Computational Independent Models (CIMs). CIMs are used to specify system requirements at a higher level of abstraction than done in our work. Thus a given CIM would be a level higher of abstraction than its PIM counterpart, where a CIM excludes the system’s processing and structural characteristics. The goal of this project had been to transform a given BPMN CIM into an XML based PIM. Both the source and target models conform to their own MOF meta-models. They used ATLAS Transformation Language (ATL) [12] as the transformation technology.

8

In comparison, BPMN does not include the specification of data structures, unlike URDAD. This poses a serious restriction on the automation of mapping BPMN models into Java EJB PSMs. In the work C. Edwards [7] has done, he has used the given URDAD data structures to map to JavaBean classes used for persistence, which would not be possible when using BPMN models. In addition, BPMN models do not make provision for the specification of service contracts with pre- and post-conditions. Thus, there exists no standardized method for determining whether service dependencies have been realized, no eligent way of enforcing business rules onto service contracts, nor an automated method for generating unit tests for a given service, which would all be possible with URDAD based models. This poses some serious restriction on the use of BPMN models and further encourages the use of URDAD for model specification.

2.3

Transformation of Java PSMs to UML Use Case Diagrams

This project introduces a method to map Java code to UML use case diagrams [6]. This simplifies the maintenance of Java based legacy systems, as use case diagrams are less complex than Java code. A Java PSM is built from the Java code which is then transformed into a PIM, representing the use case diagrams. The Java PSM is based on the authors own meta-model. The UML PIM is based on the OMG UML meta-model. The UML meta-model has been slimmed down to only include the model elements required to represent a use case diagram. An abstract syntax, conforming to the Java meta-model, had been built using compiler techniques. The transformation rules used to dictate the mapping from PSM to PIM elements had been defined using OCL constraints at meta-model level. The transformation direction in this project is the opposite of that being done in our work. Transforming from a PSM to a PIM raises the level of abstraction, thus removing platform specific characteristics from the source PSM during transformation. The transformations are similar that they both do vertical exogenous transformations.

2.4

Transformation of COSA Models to EJB Models

Raising the level of abstraction while developing or maintaining a system using the Component Object based Software Architecture (COSA) had been proposed in [5]. COSA is an architecture description approach which abstracts system architectures by representing them as components as well as the dependencies between these components as connectors. All COSA concepts have been mapped and automatically converted to EJB 2.0 implementations using MDA transformation techniques. 9

The COSA and EJB 2.0 meta-models have been defined using UML profiles. A given UML profile is created by applying a UML stereotype and OCL constraints to a UML model, representing the meta-model. Since the UML models upon which the profiles are based have to conform to the MOF UML meta-model, the UML profiles inherit this property. One of the disadvantages of using UML profiles, instead of URDAD models, is that it is difficult to ensure that a given UML profile is used as intended. In other words, it is difficult to ensure that only model elements are used which have been defined in the UML profile. In order to mitigate this issue, a set of OCL constraints would have to be included by specifying them at meta-model level in the profile specification. This exercise is not an impossibility, but a complex one as one has to restrict the valid models to a small subset of UML, together with the correct usage of the extensions provided by the UML profiles. The URDAD DSL had been created in order to mitigate this problem with UML profiles. The ATL transformation language had been used to define the transformations. COSA models focus on archetectural descriptions opposed to URDAD, which is an architecture independent approach for the specification and design of application level functional requirements. Thus, COSA models do not make provision for the specification of application level functional requirements, such as service contracts with pre- and post-conditions along with services which set out to realize their respective service contracts. It might be possible to use URDAD in conjunction with COSA models to attain more control over the architecture into which the URDAD application logic will be injected during the transformation of URDAD models into PSM models. This avoids hard-coding architectures into the respective transformations.

2.5

Summary

None of the related projects discussed in this section related to the transformation of URDAD PIMs into Java PSMs, but it had been identified that the related projects, including the relevant technologies and tools, aren’t equally sufficient for specifying application level functional requirements. URDAD has the edge when assisting with requirements engineering and the repeatable exercise of specification and design of functional requirements.

10

3

Method

In the previous work done by C. Edwards [7], preference has been given to OMG standards such as MOF, XMI, OCL and QVT ([18], [19], [16] and [21]). This is due to the close association URDAD has with MDA, where OMG maintains several standards which serve as methodological basis for MDA [7]. It is important to investigate the relevance of the original decisions made during C. Edwards’ work [7] for this project.

3.1

Technology Relevance

Preference being given to OMG standards is still relevant today, since URDAD continues to live in close association with MDA. In addition, conforming to OMG standards results in the compatibility of business functions across virtually all popular middleware platforms such as web services, XML / SOAP, Enterprise JavaBeans, etc. [4]. Thus, QVT as the chosen transformation technology is still sufficient for the purposes of this project. Choosing the same technology for this project also means that this project would be an extention of C. Edwards work, opposed to redo his work in a different technology.

3.2

Tool Relevance

The tool is the software used to create, execute, debug and validate the transformations created in QVT. The two main tools used for QVT development in eclipse are QVTd for Eclipse [2] and Medini QVT [1]. QVTd for Eclipse is a younger project than Medini QVT, and is still heavily under development. The tool does not have full support for QVT, where the release providing full functionality and execution of QVT is only planned to be released in the middle of 2015 [3]. Medini QVT on the other hand is a mature tool providing the necessary functionality needed for this project [1]. Given that Medini QVT is the only tool to fully support QVT transformations, Medini QVT had been chosen as the tool for this project.

11

3.3

Mapping Specification

Conceptual mappings have been done in order to determine whether a given URDAD model has the necessary information and semantics to facilitate the mapping of process specifications onto stateless session bean method bodies. 3.3.1

ActivitySequence Mapping

The ActivitySequence object contains zero or more Activity objects. The ActivitySequence object is mapped to a Java Block object which houses a list of zero or more Statement objects. Every given Activity object within the ActivitySequence object is represented as a Statement within the Java Block.

Figure 1: ActivitySequence to a Block

12

3.3.2

ContainerActivity Mapping

The ContainerActivity object in Figure 2 is similar to the ActivitySequence object, but it only contains a single Activity. The ContainerActivity is also mapped to a Java Block, where the Activity object is mapped to its Statement counterpart.

Figure 2: ContainerActivity to a Block 3.3.3

Choice Mapping

The Choice object contains a list of one or more ConditionalActivity objects. This represents the if - elseif condition chain. In addition, the Choice object also houses an Activity object which represents an else link to close off the condition chain. On the Java side, the Condition object contains a single Conditional object which represents the constraint. The Condition object also hosts a single Statement object, representing the next link in the if - elseif - else chain. This Statement object would be defined as either another Condition or a Java Block, depending on what the source object represents an if or else in the condition chain. A given ConditionalActivity would thus be mapped to a Java Condition. Each following ConditionalActivity would then be nested in the previous Java Condition. Finally, the single Activity object representing the else link in the chain would be nested in the very last Java Condition object, and thus concluding the conditional chain.

13

Figure 3: Choice to a Condition 3.3.4

While Mapping

A While object is mapped to a Java WhileLoop. The Constraint contained within the While will be mapped to its corresponding Java Expression constraint. Regarding the body of the while loop, the While object houses a single ContainerActivity object which will be mapped to a Java StatementContainer.

Figure 4: While to a WhileLoop

14

3.3.5

ExceptionHandler Mapping

The URDAD ExceptionHandler object will be mapped to a Java CatchBlock contained within a parent TryBlock. The ExceptionHandler has an Exception object, which will be mapped to a Java OrdinaryParameter housed in the mapped CatchBlock. Lastly, the contained ContainerActivity will be mapped to a Java Statement, representing the CatchBlock ’s body.

Figure 5: ExceptionHandler to a Try/Catch Block 3.3.6

Create Mapping

Variable creation consists of two parts in the Java world, and this reflects in the mapping. The first part is variable declaration. The variable declaration is done by mapping the Variable contained in the Create object to a Java LocalVariableStatement. This LocalVariableStatement contains the declared variable. The second part is instantiation. The declared variable needs to be set with an object instance. This is achieved by mapping the variable DataType to a Java NewConstructorCall and assigning it to the newly created variable.

15

Figure 6: Create to an Assignment Expression 3.3.7

RequestService Mapping

An URDAD RequestService contains zero or more ExceptionHandler objects. Thus, to make provision for these exception handlers, the requested service mapping will reside in a Java TryBlock. The RequestService object will then be mapped to an AssignmentExpression, where a MethodCall will be created and the returning variable assigned to a local variable. This local variable is mapped from the URDAD VariableProduction object’s contained Variable.

Figure 7: RequestService to an Assignment Expression

16

3.3.8

Assign Mapping

A given URDAD Assign object will be mapped to a Java AssignmentExpression. The contained Assignable and Query objects will then each be mapped to the AssignmentExpression’s source and target references.

Figure 8: Assign to an Assignment Expression 3.3.9

RaiseException Mapping

The URDAD RaiseException is mapped to a Java Throw object. The Exception object’s data type contained within the RaiseException is used to create a NewConstructorCall which will be situated in the mapped Throw object.

17

Figure 9: RaiseException to a Throw 3.3.10

ReturnResult Mapping

A given URDAD ReturnResult will be mapped to a Java Return object. The Variable contained within the ReturnResult object will be mapped to its corresponding LocalVariable object in the mapped Java Return.

Figure 10: ReturnResult to a Return

18

3.4

Mapping Validation

It would not be a trivial exercise to validate a conceptual mapping to ensure that it is both correct and complete. Instead the conceptual mapping phase is seen as an explorative exercise which would present a given given mapping ready for implementation. The implementation of these mappings is done in order to demonstrate that the conceptual mappings are possible. Instead, validations of the mappings are made after the execution of the transformations. One is then presented with the resultant Java PSM. This model will undergo visual inspection and compared with the source URDAD PIM to determine the validity of the mappings. Furthermore, the generated Java code will also undergo visual inspection. This is done to verify the observations made during the inspection of the Java PSM.

19

4 4.1

Implementation Core Design

Any given URDAD source PIM is presented as an object tree. This tree is in turn governed by the URDAD meta-model object tree, which defines the object types and relationships between these types. Every leaf object type in the URDAD meta-model has been assigned to a single concrete mapping. All other non-leaf object types do not have such a concrete mapping. Although the non-leaf object types in the meta-model are not associated to concrete mappings, the importance of routing objects with a meta-model object tree root type had been identified. An example of such a root type can be seen in Figure 11, where Activity is the root type of the given object tree in the meta-model. Routing objects with a root type allows us to simply pass such objects on to the routing transformations instead of having to determine the leaf type manually. This drastically reduces the unnecessary overhead to determine the leaf object types.

Figure 11: Partial Meta-Model Object Tree Making use of the meta-model object inheritance tree dramatically reduces duplicate code to determine leaf object types and increases the maintainability of the code. These advantages are gained from processing all objects with a given super type in one place. These objects’ leaf types are then determined and sent to the concrete mapping for transformation. Concrete mappings would “consume” a given source object and transform it to its Java counterparts.

20

4.2

Transformation Details

This section will highlight and discuss some of the implementation details of the project. We will focus only on the important and complex parts of the implementation. 4.2.1

Point of Inception

The point of inception in terms of the transformation of the service specifications, is the point in the entire transformation when the transformation of the dynamic processeses will initiate. This point of inception is presented in the code snippet below. A top relation was chosen for its unique properties which separate it from the normal relations defined in QVT. Top relations are invoked by the main execution thread in sequence, where normal relations would be called from other relations and top relations. This gives us the freedom to delay the transformation of service specifications, such that it only occurs after the transformation of the static structures. top relation InceptionPointToPopulateClassMethodBodies { name : String; checkonly domain source responsibilityDomain : urdad::core::ResponsibilityDomain { name = name }; where { ResponsibilityDomainToService(responsibilityDomain); } }

Delaying the transformation of the service specifications is necessary to ensure that all dependencies are in place. This ensures that all data types, service contracts, and classes exist when they are accessed during the service transformation.

21

4.2.2

Activity Transformation

The transformation of Activity objects serves as a realization of the core design. As discussed in section 4.1, this transformation is responsible for routing a given Activity object to the correct concrete transformation associated with the object’s type. Due to the declarative nature of QVT, it is not possible to pre-emptively determine the object type by iterating through all the possible object types before sending the object off for transformation. The solution to this problem was to attempt to cast a given object per transformation. If the cast was successful, then the object would be sent off for transformation. Failing the cast on the other hand would result in the transformation being skipped. This behaviour ensures that an object is only transformed once, and all concrete transformations are relieved from their responsibility of determining object types. See a portion of the ActivityToClassMethodBody relation in the code snippet below. relation ActivityToClassMethodBody { checkonly domain source activity : urdad::process::Activity{}; enforce domain target block : java::statements::Block{}; when { isTypeActivity(activity); } where { ActivitySequenceToClassMethodBody( activity.oclAsType(urdad::process::ActivitySequence), block ); ContainerActivityToClassMethodBody( activity.oclAsType(urdad::process::ContainerActivity), block ); WhileActivityToClassMethodBody( activity.oclAsType(urdad::process::While), block ); ... } }

22

4.2.3

Choice Transformation

The implementation details for the URDAD Choice object is included in the implementation overview due to the difficulties experienced during the realization of the conceptual mapping. The root cause of the difficulties experienced is a fundamental structural mismatch between URDAD’s Choice and Java’s Condition objects. This mismatch can be seen in the conceptual mapping in figure 12. The ConditionalActivity objects found in the Choice object is structured as a list representing the if - elseif links in a given condition chain. Concluding the condition chain with the else link, is a seperate Activity object representing the body of the else statement.

Figure 12: Choice to a Condition Java’s Condition object on the other hand, has a recursively defined structure. The Condition houses a Statement which can be defined as either another Condition representing an elseif link in a given condition chain, or as a Java Block populating the else link’s body. The problem manifests when discovering that QVT relational cannot handle this structural mismatch with the available tools in an elegant manner. Thus, a work-around is needed to make provision for the problem at hand.

23

When a Choice object is encountered and sent for transformation, the choice is sent off to two different transformations. The first, namely ConditionalActivityToClassMethodBody, will handle the list of ConditionalActivity objects. The second, called CheckElseConditionalActivity, processes the Activity representing the else statement. If the Activity object is not split off from the ConditionalActivity list, then the transformation would attempt to transform the else statement for every given ConditionalActivity instance. relation ChoiceToClassMethodBody { checkonly domain source choice : urdad::process::Choice{}; enforce domain target block : java::statements::Block{}; when { isChoice(choice); } where { ConditionalActivityToClassMethodBody(choice, block); CheckElseConditionalActivity(choice, block); } }

The ConditionalActivityToClassMethodBody relation is responsible for looping through the ConditionalActivity list and sending each instance in the list to two more transformations. These two relations will map a given ConditionalActivity object to either an if or an elseif statement, depending on the index of the current ConditionalActivity in the list. A distinction has to be made between the mapping of if and elseif statements, due to elseif statements represented by the Java Condition object being defined in its Condition parent. The mapping of the first ConditionalActivity would thus become the parent Condition object of all the consecutive instances to follow. relation ConditionalActivityToClassMethodBody { checkonly domain source choice : urdad::process::Choice { conditionalActivities = conditionalActivity : urdad::process::ConditionalActivity{} }; enforce domain target block : java::statements::Block{}; when {

24

isTypeConditionalActivity(conditionalActivity); } where { CheckImbedConditionalActivityToConditionalBody( choice, conditionalActivity, block ); CreateConditionalActivityToClassMethodBody( choice, conditionalActivity, block ); } }

The CreateConditionalActivityToClassMethodBody relation simply creates a Condition object in the given Java Block, but this transformation only occurs if the incoming Condition object it the first instance in the list. The CheckImbedConditionalActivityToConditionalBody relation first checks the index of the current ConditionalActivity to ensure it is not the first instance in the list. Secondly, it calls a sub-query which recursively traverses the parent Condition object to fetch the deepest Condition instance in the parent structure. This child instance is then passed to the ImbedConditionalActivityToConditionalBody relation to host the new Java Condition object representing the new elseif statement. Going back to the mapping of the else statement, the Activity object had been sent to the CheckElseConditionalActivity. It is important to note that if the elseActivity does not exist, then the transformation does not execute. Thus, the check had to be moved out of the ChoiceToClassMethodBody relation, otherwise the entire Choice transformation would not execute without the existance of an else statement. relation CheckElseConditionalActivity { checkonly domain source choice : urdad::process::Choice { elseActivity = activity : urdad::process::Activity{} }; enforce domain target block : java::statements::Block{}; where { ImbedElseActivityToConditionalBody( activity,

25

getLastConditionFromBlock(block) ); } }

The ImbedElseActivityToConditionalBody relation works in a similar fashion to ImbedConditionalActivityToConditionalBody. The difference being that ConditionalActivity indices do not have to be checked and the end product is not a Condition instance, but instead a Java Block to house the logic for the else statement body.

4.3

Problems and Limitations

Some problems and limitations regarding QVT have been identified. In the case of service requests and exception handling, new variables have to be created during model transformation in order to produce a valid target Java PSM. These new variables have not been specified in the source URDAD model, because these variables are only relevant in the Java context. The new variables require unique variable names, but it would not be feasible to look for unique variable names, as this would require a comparison of all other variables within scope to ensure the selection of unique variable names. The next problem is as a result of the given model structural characteristics. A given object does not have a link to its parent node in the object tree. Thus large sections of the tree need to be traversed in order to find the parent node in question. This leads to computationally expensive queries in order to find a given object’s parent node.

4.4

Code Availability

The entire implementation is stored in a git repository and will be made available on request.

26

5 5.1

Critical Analysis Complex Transformations using QVT-R

A potential issue had been raised by C. Edwards [7] that QVT-R might not be sufficient for specifying the transformations of URDAD service specifications. This is due to it being a complex exercise of defining complex dependencies with QVT-R relationships. Fortunately, most of the URDAD service specifications were successfully mapped using QVT-R relationships, but the solution does exclude the transformation of OCL expressions. It had been noted in [9] that one of the limitations with using QVT-R is the difficulty of defining complex queries using OCL. Thus QVT-R could be replaced with QVT-O for an imperitive approach, but there are trade offs associated with this appraoch [9]. On the other hand, the URDAD DSL could be refined to exclude OCL expressions for constraint specification.

5.2

Architecture Hard-Coding

One of the problems with current model transformations is the hard-coding of software architectures and technologies into the transformations used to map PIMs into PSMs [10, 8]. This side effect has injected architectures into PSMs which cannot be reasoned about or modified. A Systematic Method for Software Architecture Design (SyMAD) [24] could be a solution to this problem as it forces the clear seperation between the application and architectural components.

5.3

Automated Validation

The validation of generated artefacts is currently manually inspected for validation. This is a long and taxing exercise. Furthermore, the validation of complex PIMs or a large number of PIMs would be error prone and unreliable. Thus a method for automating the validation process is required. Formal mathematical methods could be used to prove that the resultant Java PSM and code is semantically equivalent to the source URDAD PIM. Having automated validation of produced artefacts would increase the confidence in the tool and consequently the adoption rate of URDAD for model specification.

5.4

Suitability of URDAD for Model-Driven Development

URDAD ideal for use in Model-Driven Development (MDD), because it compliments MDA by improving some of the issues associated with Model-Driven Architecture. The main goal of URDAD is the architecture independant specification of functional requirements in the form of an

27

MDA PIM [25, 26]. URDAD eliminates the need for a requirements modelling technique by defining a repeatable analysis and design methodology for specifying a system’s functional requirements. It provides a punctilious and consistent means of defining an MDA PIM. URDAD provides a basis for tool support and future development. It also reduces the the complexity with constructing MDA PIMs present when using traditional approaches such as UML. Finally, due to the close association URDAD has with MDA, OMG standards are still compatible and accessible when using URDAD for model specification in the context of MDD. The current tool support includes the complete mapping of URDAD static structures onto Java EJB PSMs, as well as the partial mapping of URDAD service specifications onto populated stateless session bean method bodies. This results in further automating the transformation of URDAD PIMs into Java EJB PSMs. This project has excluded the transformation of concurrent related activities, as well as the service requirements associated with services which would both have to be implemented manually or included in the mapping as possible future work. Further work done related to URDAD transformations includes document generation, Web Services Description Language (WSDL) contracts mapping and unit test generation from URDAD PIMs.

28

6

Conclusion

C. Edwards’ work [7] has successfully been extended with the ability to transform a subset of URDAD service specifications onto automated processes, populating stateless session bean method bodies. This new iteration of the prototype tool makes URDAD more attractive for model specification as well as for adoption in the context of Model-Driven Development. Potential future work involves the full mapping of URDAD service specifications onto automated processes. In addition, the shortcomings and problems with the tool, highlighted both in this report and in Edwards’ work [7], must be addressed to further mature this tool for potential enterprise use.

29

References [1] Medini QVT. http://projects.ikv.de/qvt, November 2007. [Online; accessed 03-November-2014]. [2] QVTd (QVT Declarational). https://projects.eclipse.org/projects/modeling.mmt.qvtd, November 2013. [Online; accessed 03-November-2014]. [3] QVTd (QVT Declarational) 1.0.0 Mars. https://projects.eclipse.org/projects/modeling.mmt.qvtd/releases/1.0.0mars, November 2013. [Online; accessed 03-November-2014]. [4] OMG’s Standards. http://www.omg.org/marketing/omgstandards.htm, 2014. [Online; accessed 06-November-2014]. [5] A. Ati. An automatic transformation from COSA software architecture to EJB platform. In In 3rd International Conference on Information and Communication Technologies: From Theory to Applications, 2008, pages 1–6. ICTTA, April 2008. [6] P. Claudia, M. Liliana, and F. Liliana. Recovering use case diagrams from object-oriented code: An MDA-based approach. In In Eighth International Conference on Information Technology: New Generations (ITNG), pages 737–742, April 2011. [7] C. Edwards. Transformation of an URDAD Platform Independent Model into a Java EE EJB Model. Masters thesis, University of Pretoria, Nov. 2011. [8] C. Edwards and S. Gruner. A new tool for urdad to java ee ejb transformations. In Proceedings of the South African Institute for Computer Scientists and Information Technologists Conference, SAICSIT ’13, pages 144–153, New York, NY, USA, 2013. ACM. [9] P. Guduric, A. Puder, and R. Todtenhoefer. A comparison between relational and operational QVT mappings. In In Sixth International Conference on Information Technology: New Generations (ITNG), 2009, pages 266–271, Las Vegas, NV, USA, 2009. [10] J. Hou, J. Wan, and X. Yang. MDA-based Modeling and Transformation Approach for WEB Applications. In In Intelligent Systems Design and Applications, 2006. ISDA 2006. Sixth International Conference on, volume 2, pages 867–874, 2006. [11] J. Imen, M. Khemaja, and M. Abed. Towards MDA implementation based on a novel BPMN metamodel and ATL transformation rules. In In 4th International Conference on Logistics, LOGISTIQUA, pages 62–67, June 2011. 30

[12] F. Jouault and I. Kurtev. Transforming models with ATL. In In Satellite Events at the MoDELS 2005 Conference, volume 3844 of Lecture Notes in Computer Science, pages 128–138, Berlin, Heidelberg, Springer, 2006. [13] R. Klopper, S. Gruner, and D. Kourie. Assessment of a framework to compare software development methodologies. In In Proceedings of the 2007 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists on IT Research in Developing Countries, pages 56–65. Port Elizabeth, South Africa, ACM, 2007. [14] P. Mahagheghi and J. Aagedal. Evaluating quality in model-driven engineering. In In Proceedings of the International Workshop on Modeling in Software Engineering, MISE 2007. Washington DC, USA, IEE Computer Society, 2007. [15] J. Miller and J. Mukerji. Model Driven Architecture. In (MDA), Document number ormsc/2001-07-01. Architecture Board ORMSC, July 2001. [16] Object Management Group. Object constraint language v2.2. Specification, February 2010. [17] OMG. MDA guide v1.0.1. Object Management Group, June 2003. [18] OMG. Meta object facility (MOF) core v2.0. Specification. Object Management Group, January 2006. [19] OMG. MOF 2.0 XMI mapping v2.1.1. Specification. Object Management Group, December 2007. [20] OMG. BPMN v2.0 Specification. Object Management Group, January 2011. [21] OMG. Meta object facility (MOF) 2.0 Query/View/Transformation v1.1 Specification. Object Management Group, January 2011. [22] Y. Singh and M. Sood. Model driven architechture: A perspective. In In Advance Computing Conference, 2009, IACC 2009, pages 1644–1652. IEEE International, March 2009. [23] Y. Singh and M. Sood. Models and transformations in MDA. In In First International Conference on Computational Intelligence, Communication Systems and Networks, 2009, pages 253–258. CICSYN ’09, 2009.

31

[24] F. Solms and L. Cleophas. A Systematic Method for Software Architecture Design. In ACM Transactions on Software Engineering and Methodology, June 2014. [25] F. Solms and D. Loubser. Generating MDA’s platform independent model using URDAD. Knowledge-Based Systems, 22(3):174–185, April 2009. [26] F. Solms and D. Loubser. Urdad as a semi-formal approach to analysis and design. Innovations in Systems and Software Engineering, 6(12):155–162, 2010.

32