Automatic code generation using unified modeling language activity and sequence models
2016; Institution of Engineering and Technology; Volume: 10; Issue: 6 Linguagem: Inglês
10.1049/iet-sen.2015.0138
ISSN1751-8814
AutoresSunitha Edacheril Viswanathan, Philip Samuel,
Tópico(s)Software Testing and Debugging Techniques
ResumoIET SoftwareVolume 10, Issue 6 p. 164-172 Research ArticlesOpen Access Automatic code generation using unified modeling language activity and sequence models Sunitha Edacheril Viswanathan, Corresponding Author Sunitha Edacheril Viswanathan sunithaev@gmail.com Department of Computer Science, Cochin University of Science and Technology, Kochi, IndiaSearch for more papers by this authorPhilip Samuel, Philip Samuel Division of Information Technology, SOE, Cochin University of Science and Technology, Kochi, IndiaSearch for more papers by this author Sunitha Edacheril Viswanathan, Corresponding Author Sunitha Edacheril Viswanathan sunithaev@gmail.com Department of Computer Science, Cochin University of Science and Technology, Kochi, IndiaSearch for more papers by this authorPhilip Samuel, Philip Samuel Division of Information Technology, SOE, Cochin University of Science and Technology, Kochi, IndiaSearch for more papers by this author First published: 01 December 2016 https://doi.org/10.1049/iet-sen.2015.0138Citations: 14AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract A fully automatic translation of unified modeling language (UML) models to complete source code is not reported so far because some implementation details will not be there in the model, or a single UML model is not enough for complete code generation, or some model elements may not be directly convertible to source code. These issues are addressed in this study. The authors take workflow modelling and automation as the focus of their research. Hence, UML activity diagram is considered. Activity diagram alone cannot give the implementation details like object interactions. A formal association is found between activity and sequence diagrams to add object interaction details to the work flow. Moreover, the authors formulate an algorithm, Am_To_Prototype, which is composed of two subroutines named Method_Body & Excecution_Logic, to generate code from the combined model of activity and sequence diagrams consisting of concurrent activities. The authors compare the proposed method with other research outcomes with respect to workflow automation, support for concurrency, etc. The proposed algorithms are able to generate class definition, method definition and control flow. A case study is presented that demonstrates the algorithm, to generate Java code for the ATM operation. 1 Introduction Automatic code generation from unified modeling language (UML) models is an interesting research area. 100% complete source code generation is the ultimate aim of this field. The main challenge in this field is the perfection of the code generated. UML emerged as the de facto standard for software system modelling and design [1]. We use UML for modelling the system structure and behaviour. These designs give us the high level design details of the system. When a programmer implements these designs, he/she includes so many implementation specific details [2] such as, variable declarations, initialisations, pre-defined constant values, method definitions, class definitions, etc. Automatic code generation could be possible in its real sense, only when we are able to automatically generate all these implementation specific details. Researches in automatic code generation started with structural modelling such as class diagrams [3]. It could produce only skeletal source codes such as, skeletal class definitions. Hence, the behavioural models came into picture to improve the code that produced automatically. State diagram was the first candidate [4]. It is best suited for event driven applications since it shows the state changes of an object in its life time. Behavioural modelling is very much important in the context of automatic code generation, since it helps us to represent the control flow in the system. Activity diagram is one of the most important diagrams for behavioural modelling. It is the only UML diagram which models control flow (work flow). State models lack this information. Activity diagram gives the activity model of the system which shows the workflow from activity to activity. Unlike state chart diagrams, activity diagrams are activity centric and it shows flow of control from activity to activity. Activity diagram can show the group of activities done by different objects in the system. We can specify which object is responsible for which activity. This is a unique feature of activity diagram compared with other behaviour diagrams like state chart diagrams. This feature, which is not exploited so far, is very much useful in automatic code generation. Few research works have been reported on code generation from the UML activity diagrams, but those works primarily concentrate on control flow generation. Moreover, those works do not present any well-defined formal method for code generation. Method definitions are not generated because activity diagrams show a high level activity model. Each activity in the activity diagram can be a method (function) in the program. The actions inside each activity and the control flow between them may not be specified in activity diagrams. Fine tuning the activity models to include those details will help in improved code generation. In this paper, we define a method to fine tune the activity diagrams for improved code generation. We tried to associate activity diagram with sequence diagram to include object interactions in activity diagram. We introduced a formal method for this association. Even though activity and sequence diagrams are behavioural models, they model the system from different perspective. First one is activity centric and the latter is object interaction oriented. If we put them together we can generate more complete source code because, activity diagram contributes to control flow and class definitions, and sequence diagram contributes to method definitions and object interactions. This overcomes the shortcomings of state model based approaches where the state diagram primarily models the behaviour of a single object and lacks information on object interactions. The concepts such as activity node, work flow, decision node are easy to implement, since there are built in programming constructs like method invocation statements, if…else statements, etc. When we consider more advanced and expressive features such as fork and join nodes, the implementation is not so straight forward. We surveyed many research publications to find a method to handle concurrency (fork and join) in the activity diagrams. Unfortunately, we could not find any method/algorithm to do so. Hence, we formulated an algorithm to convert concurrent activities in the activity diagram to source code. In addition, we introduced algorithms for code generation from activity and sequence combined models. Our method gives a well-defined algorithm for code generation which is lacking in other published works in this field of research. We are using model driven architecture (MDA) [5] strategy for the code generation. The basic principle behind MDA is to make the software design independent of implementation details and it could be implemented in any platform. MDA lays down a possibility to automatically generate code from the system designs. In this paper, we use UML 2.0 activity and sequence diagrams for system design. We have evaluated our method by developing a tool called AutoKode. The main contributions of this paper are as follows: It provides formalisation for associating activity diagram with sequence diagram. It provides a method to generate control flow and class definitions from activity diagram, and method definition and object interactions from sequence diagrams. It provides a better algorithm for code generation from activity and sequence diagrams. It provides code generation algorithm which handles concurrency. The rest of the paper is organised as follows. Section 2 gives a scenario of associating activity diagram and sequence and the formal definition for the same. Section 3 gives prototype generation process, Section 4 gives prototype generation algorithm, Section 5 demonstrate the algorithm with a case study, Section 6 gives a comparison with related works, Section 7 concludes the paper. 2 Associating activity diagram with sequence diagram Associating activity diagram with sequence diagram will help us in code generation from activity models. In this section, we explain a method to associate activity and sequence diagrams for workflow modelling. The basic idea behind this is that all the control flow and data flows are depicted using the activity diagram, and the method invocations (communication between objects) are depicted using sequence diagrams. Each activity in an activity diagram can be expanded using a sequence diagram. This will help us to include more details to the activity diagram. That is we have one activity diagram and many sequence diagrams associated with it as shown in Fig. 1. Each activity node in the activity diagram generates a method declaration and the corresponding sequence diagram generates the method definition as a sequence of method calls. The execution control flow will be based on the control flow in activity diagram. Fig. 1Open in figure viewerPowerPoint Associating activity diagram with sequence diagrams Formal definition for the association of activity and sequence diagrams is presented in Sections 2.1 and 2.2 explains the mapping of the definition elements to the UML 2.0 Activity diagram meta model. 2.1 Formal definition for associating activity diagram with sequence diagram In this section, we formally define activity diagram and sequence diagram. The definition reveals the association between them. This formal definition shows the elements in activity diagram and sequence diagram that are considered for work flow modelling and collaboration modelling, respectively. This formal definition is used in the algorithm for prototype generation, which is explained in the next section. In the earlier versions (UML 1.x), activity diagram had been considered as an extension of the state machine. As per UML2.0, it is considered as a graph [1, 6]. Hence we use the term Activity Graph to represent activity diagram in our definition. Formalisation of sequence diagram: A sequence diagram, SD, is a tuple. It is a set of objects o and the interactions m between them. The interactions are through message passing. As Li [7] defines message, it has four main components – action, sender obi, receiver obj, and sequence order of the message. The action can be of five types; synchronous message, asynchronous message, return, create and destroy. [o – objects, m – messages, obi – source object of class Ci, obj – target object of class Cj, action – method call, order – the sequence number of the message in the current sequence diagram, Ci and Cj are classes]. Formalisation of activity graph: An activity graph, AG, is a hextuple which contains nodes N, edges E, events e, guard conditions G, local variables var, and set of objects o. A node can be of two types, ActionNode AN and ControlNode CN. AN includes action node, acceptEvent node, sendSignal node, and CallBehaviorAction (CBA) node. The CallBehaviorAction node is used to represent a function call in the activity diagram. It is implemented as a call to a sequence diagram which details the function. CN includes initial node, actionFinal node, flowFinal node, decision node, merge node, and fork and join node. The AG contains callBehaviorAction nodes (CBA), which are associated with sequence diagram, since CBA is implemented using SD. In both AG and SD, set of objects/actors o is common. 2.2 Mapping of the definition elements to UML meta model The abstract syntax of AG is shown in Fig. 2. The AG may contain many activities. The element activity diagram in the figure represents the AG. The mapping is shown in Table 1. AG contains many activities. Each Activity is associated with an Object which is responsible for the activities to be done. There will be associated Events and variables. Each activity is composed of Activity Edges and activity nodes. Each activity edge can be either Control flow or Object flow. Each Activity Node can be Control node, Object node or Executable node. Control nodes are initial node, final node, decision node, merge, fork or join. Executable nodes are the directly executable action nodes. The Call Behavior Action (CBA) node comes under executable node. The Value Specification associated with activity edge involves guard conditions, variable/object values, etc. Fig. 2Open in figure viewerPowerPoint Simplified Meta model of UML2.0 Activity Diagram Table 1. Mapping the formalisation elements to metamodel Element in metamodel Components in formalisation activity graph AG activityNode N activityEdge E events e valueSpecification G variable Var objects o controlNode CN executable Node AN, CBA Table 2. Comparison with related works Sl. No Related works Generating Java Skeleton from XMI Mapping UML designs to Java Automatic code generation from UML class and Statechart diagrams Consistent code gen from UML models Declarative technique for MD business process integration Adaptive multi lang code gen using YAMDAT UJECTOR AutoPA AutoKode Features [3] [6] [11] [13] [9] [14] [12] [10] 1 work flow automation nil nil nil nil yes nil nil yes yes 2 code generation from activity models with concurrent actions nil nil nil nil nil nil nil nil yes 3 formal definition for associating AM with CM nil nil nil nil nil nil nil nil Yes 4 process of prototype generation yes yes nil nil yes nil yes nil Yes 5 efficient algorithm for code/prototype generation nil nil nil yes nil nil nil nil Yes 6 degree of automatic code/prototype generation skeletal code for class definitions class definition & associations class definitions, object composition and delegation class declarations, method definitions control flow class & method declarations control flow, object manipulation, user interaction class declarations, control flow class declaration, method definition, control flow 7 implementation of the method yes yes yes nil nil yes yes yes Yes 8 MDA approach nil nil Nil nil yes yes yes nil yes 9 support for UML2.0 nil yes yes yes yes yes yes yes Yes 10 support for activity diagram nil nil nil nil yes nil yes yes yes 11 support for sequence diagram nil nil nil yes nil nil yes nil yes 12 programming language supported java Java Java rCOS BPELWS Java, C++ Java java Java 3 Prototype generation process The prototype generation process includes four major steps. In the first step, the workflow of a system is modelled using activity and sequence diagrams. The OCL statements are included for adding finer details. In the second step, the diagrams and OCL statements are checked for errors. In the third step, the diagrams and OCL statements are converted to XML files. In the final step, these XML files are converted to prototype of the system. This four step process of code generation is shown in Fig. 3. Fig. 3Open in figure viewerPowerPoint Code Generation process The modeller gives the option to design a system using UML 2.0 activity diagram and sequence diagram. The model processor does the parsing and modification of the object tree. The XML generator regenerates the XML document which contains the modified data. Transformation Engine includes Activity Diagram Transformer and Sequence Diagram Transformer. The Activity Diagram Transformer transforms the activity diagram to the prototype. It is subdivided into three parts; AD parser, AD prototype generator, and the transformation rules. The AD parser takes the input as the XML files. It will be parsed to get the details of the activity diagram. These data will be given to the prototype generator. The AD prototype generator applies transformation rules on the activity diagram data to get the prototype. Since the sequence diagrams have been attached to the activity diagram, the prototype generation will not be independent. It has to refer to the sequence diagram details and should be merged with the prototype. The AD prototype generator sends the sequence diagram reference, which has been used in the workflow modelling, to the sequence diagram transformer. The corresponding sequence diagram tree will be traced out and parsed by the SD parser. The SD parser takes the XML document of the sequence diagram as input. The SD prototype generator generates the method definitions based on the sequence diagram and its transformation rules. The prototype generators (AD prototype generator and the SD prototype generator) use the algorithms which are given in the next section for code generation. 4 Prototype generation algorithm The prototype generation algorithm, Am_To_Prototype, takes the object tree of activity graph (AG) and sequence diagram (SD) as input and the output is the prototype P of the activity model (AM). We use the term activity model (AM) to refer to the combination of activity and sequence diagram. It generates one Main class and one class for each type of object present in AG. Main class includes a main() method which initiates execution. This algorithm uses two sub procedures, Excecution_Logic and Method_Body. Excecution_Logic is used to implement the main() method in the Main class. Method_Body is used to implement the definition of all methods in AG. The classes generated after Am_To_Prototype is shown in the Fig. 4. There will be one main class, say the Context class, and other associated class corresponds to each object present in the work flow. Fig. 4Open in figure viewerPowerPoint Class diagram generated from Am_To_Prototype for Fig. 10 4.1 Algorithm Am_To_Prototype Am_To_Prototype algorithm first creates a java package with the name of the activity diagram. It applies Depth First Search on AG to visit all nodes in the activity graph. A method declaration will be added whenever a new action node is visited. It checks each node in the AG and identifies all action nodes and writes the method declaration for all those action nodes. If there is any callBehaviorAction node, then call the subroutine Method_Body. The algorithm identifies currently active object, ca_obj, and its type. The active objects will be fetched from the XML document of AG. If no class exists corresponding to the object, then a class will be created. Otherwise the existing class will be updated with the method declarations and added to the prototype P. The search stops when all nodes have been visited. A main class will be created and embed a main() method in it. Then call Excecution_Logic subroutine to implement the main() body. The generated class diagram can be edited to add attributes in the classes (see Fig. 5). Fig. 5Open in figure viewerPowerPoint Am_To_Prototype 4.2 Algorithm Excecution_Logic(AG, P, parentThread, currentThread, start) The Excecution_Logic algorithm generates the execution logic from AG. It converts each node in the AG to its corresponding programming statements. It considers activity nodes, decision nodes, fork, join, etc. for conversion. The overall AG is traversed in depth first search manner starting from the initial node. When it is an action node, corresponding method will be called using the currently active object. The ‘if statement’ will be generated for the corresponding decision nodes. Fork and join are handled in a different manner. Fork starts some sub threads at that point of execution. Each thread should run concurrently. If fork node has two child nodes one sub thread should be created and started there. Out of two child nodes, one will be the current node itself and the second one is the sub thread. See Fig. 6 for sample fork-join segment in an AG. Suppose T1 is the current thread and it calls method A(). Then it reaches a fork node. Fork node has two child nodes and one of them is T1 itself and the other one is T2 which is a sub thread of T1. All actions coming under T1 will belong to main() method if T1 is the main thread. Otherwise it will belong to the run() method of Thread class. Whenever a new thread is generated it is named after its parent thread suffixed with t1, t2, etc. If T1 is the main thread, then T2 will be named as main_t1. These thread names will be pushed to stack for future use. The segment of AG between fork and join node is treated separately. Excecution_Logic() method will be called recursively for each thread between a pair of fork and join. For Fig. 6, Excecution_Logic() will be called for T1 and T2 after the fork node. Fig. 6Open in figure viewerPowerPoint Sample fork and join nodes When a join node is encountered by the parent thread (here it is T1), it will just return the recursion. If it is a sub thread, a currentThread.join() statement needs to be added in the parent method. When T2 reaches the join node it adds main_t1.join(); statement to the main() method (assume T1 is the main thread. If T1 is not the main thread, then the main_t1.join(); statement needs to be added to the run() method where threadName = name of T1. All these updates will be added to the prototype P. when the search reaches the actionFinal node, the algorithm returns with the updated prototype P. The Excecution_Logic algorithm is given below (see Fig. 7). Fig. 7Open in figure viewerPowerPoint Excecution_Logic(A,G, P, parentThread, currentThread, start) 4.3 Algorithm Method_Body (ca_obj, N, T, SD, P) The Method_Body algorithm takes current node, currently active object, its class T, and sequence diagram tree as input and returns the modified prototype P. Sequence diagram tree is nothing but a tree which is constructed [8] using object nodes and message flow edges [7]. The SD tree gives a tree representation of the sequence diagrams. This tree representation allows the traversal through the sequence diagram and it is essential when we automate the sequence diagram implementation process. Each node in the SD tree is the objects that are parts of the collaboration model. Edges represent the messages. The root of the tree will be the object which initiates the collaboration. For instance, there are four objects in a collaboration, say :Customer, :ATM, :Network, and :Bank as shown in Fig. 8. :Customer initiates three message sequences. It is shown as three edges from the customer object. The receiver of the messages is shown at the other end of the edge. For example, the receiver of msg1() is :ATM. It is given as the end node of the first branch from :Customer. The message msg1() gets a return value from :ATM, so that sequence (path in tree) ends at :ATM. Each path in the tree ends when it reaches a node which gives a return for the instantiating message. This tree helps to show the synchronisation between messages. The Method_Body algorithm defines the function related to the current activity node N in the activity graph and it will be added to the prototype P. First of all, search the SD tree to find a node with the name of the current object. The number of child nodes will be counted, if the current object is found in the tree. Each edge to the child node is converted to a method invocation statement. It is done for all child nodes and in the order of the message. The Method_Body algorithm is given as Fig. 9. Fig. 8Open in figure viewerPowerPoint A sample sequence tree 5 ATM case study In this section we demonstrate our algorithm with a case study. Consider the work flow of an ATM machine. Fig. 10 gives a simple activity diagram for ATM transaction. It includes four activities and one decision making. The four activity nodes cause the generation of four method declarations, say, login(), withdraw(), updateBalance() and eject() in the class Atm. The activities login and withdraw are expanded using sequence diagrams. These sequence diagrams will fill up the definition of the methods login() and withdraw(). Fig. 9Open in figure viewerPowerPoint Method_Body (ca_obj, N, T, SD, P) Fig. 10Open in figure viewerPowerPoint ATM transaction The activities inside login are described in the sequence diagram. It includes PIN verification (verifyPIN()), validation and verification of the account with the bank network. The sequence of interactions is shown as method calls. The activity withdraw is shown in the second sequence diagram. It includes the selection of the service from the choice menu, verifying the feasibility of the transaction, issue of receipt, etc. In short, the case study presented here contains one activity diagram (AG), and two sequence diagrams (SD) to elaborate the login() and withdraw() functionalities. The object tree of AG and SD are the inputs to the algorithm Am_To_Prototype. The following paragraphs show how the algorithms convert the AG and SD to the prototype. 5.1 Code generated by algorithm Am_To_Prototype The algorithm, Am_To_Prototype, will create a package called ATM since AG is named as ATM. Perform DFS on AG. Visit Login node. Create a class, Atm, for the current object, and add to the package ATM. Call subroutine Method_Body() to generate the method definition of Login(). Visit next nodes and call subroutine Method_Body() to generate the method definition of withdraw(). Add a Main class to the package ATM. Call subroutine Excecution_Logic() to generate the definition of main() function (Fig. 11). Fig. 11Open in figure viewerPowerPoint Code generated by algorithm Am_To_Prototype 5.2 Code generated by algorithm Method_Body The subroutine, Method_Body(), will be called twice to generate the definitions for login() and withdraw(). For login():- Creates definition of login(). Search SD tree to find the node with name atm. Identify all messages originating from atm. There is only one message verifyPIN() and prepare a function call statement with the receiver of the message (here it is transaction). Similar processing is done for the function withdraw() (Fig. 12). Fig. 12Open in figure viewerPowerPoint Code generated by algorithm Method_Body 5.3 Code generated by algorithm Excecution_Logic The subroutine, Excecution_Logic(), generates the definition of main() function. The AG is traversed in Breadth First Search manner and find out each node and interprets accordingly. The only object active here is atm. So, all the action nodes are called with the object atm. For decision making, the guard conditions are checked and true/false paths are traversed. There can be nodes of type action node, initial and final nodes, decision node, fork/join nodes, call behaviour action nodes, etc. (Fig. 13). Fig. 13Open in figure viewerPowerPoint Code generated by algorithm Excecution_Logic To make the description simpler, we omitted the codes that are generated to declare the variables and objects. The additional codes for constructors and destructors also remain hidden in this description. 6 Comparison with related works Focus on work flow automation. Code generation from UML models is an interesting research area. However, few works [9, 10] focus on work flow automation. Most of the research works in code generation focus on class diagrams and state machines [3, 4, 11]. We focus on activity diagrams to model work flow. Our paper proposes a method to automate work flow/ process flow. We have presented a formal definition for the activity models (work flow models) and collaboration models which reveals the association between the two. The formal definition helps us to device an algorithm to generate software prototype from the UML models. Prototype generation process. Our paper presents a precise description of the prototype generation process. The prototype generation process is enriched with a detailed algorithm based on the formal definitions of AM and CM. Even though few research works [3, 6, 9, 12] give a minimal description of the code generation process, very few works [13] present an algorithm for prototype generation. To the best of our knowledge, no algorithms are reported for code generation that associates AM and CM. We have presented an efficient algorithm for prototype generation in our paper, bearing time complexity O (|E|), where E is the number of transitions in the activity diagram. The algorithm works in the depth first search fashion and hence holds the same time complexity. Degree of automatic code/prototype generation. When we develop a software using object oriented concepts, it includes class declarations, method definitions, and the instructions to show control flow. Many of the research works in the field of code generation support automatic generation of class declarations [3, 6, 11]. Some of the research works produce class declaration as well as a part of the method definitions [13, 14]. Few research papers provide methods to implement class declarations, control flow and part of the method definition [10, 12]. Still, the code generation of method (or function) definitions remains incomplete. In our paper we propose a method to implement method definitions with the help of activity diagram and sequence diagram. Table 2 gives a summary of the comparison with the related works. Considering the degree of automatic prototype generation, we could find that our method has a clear advantage over existing research works. Our method generates class declarations along with the method definitions, preserving the control flow of the system. Concurrency in activity models is not considered in other publications for code generation. 7 Conclusions We have presented a new method to generate Java code from workflow models, which is represented as a set of UML activity diagrams and sequence diagrams. We defined activity diagram and sequence diagram formally which proves the association among both the diagrams. This formal definition helped us to formulate a precise algorithm for code generation. To the best of our knowledge, no other research outcome provides both the formal definition and the precise algorithm for code generation combining object interactions and activity. The proposed algorithms deal with concurrency in the activity diagram which is a big step in research in this area. The algorithms have been implemented, AutoKode, which automatically generates Java source code from the workflow model of a system. Our method ensures more than 80% of completion of the prototype of the system. Since we associate activity models with collaboration models we are able to handle object interactions and are able to generate more complete source code automatically. Comparison with the related works shows that our approach provides a new method to associate the activity diagram with sequence diagram which improves the quantity and quality of information included in the activity model. Our method provides a new method for work flow automation with the help of a formal definition for activity diagram and sequence diagram association and an efficient algorithm which can deal with concurrent activities in the system models. The degree of automatic prototype generation is better than other related works since our method produces complete class definition, method definition and control flow considering object interactions. Our method will be suitable for current and future software development scenarios since we use MDA approach, and supports UML 2.x and machine independent language Java. 8 References 1Samuel, P., Mall, R.: ‘Slicing-based test case generation from UML activity diagrams’, ACM SIGSOFT Softw. Eng. Notes, 2009, 34, (4), pp. 1– 14 (doi: 10.1145/1640162.1666579) 2Mellor, S.J., Balcer, M.J.: ‘ Executable UML a foundation for model-driven architecture’ ( Addison-Wesley, 2002) 3Bjoraa, E., Myhre, T., Straapa, E.W.: ‘ Generating Java Skeleton from XMI’ ( Open Distributed Systems, Agder University College, 2000) 4Ali, J., Tanaka, J.: ‘An object oriented approach to generate executable code from OMT-based dynamic model’, J. Integr. Des. Process Sci., 1998, 2, (4), pp. 65– 77 5 OMG: ‘ MDA guide version 1.0.1’, June 2003. Available at http://www.omg.org 6Harrison, W., Barton, C., Raghavachari, M.: ‘Mapping UML designs to Java’. Proc. of the 15th ACM SIGPLAN Conf. on Object-oriented Programming, Systems, Languages, and Applications, 2000, pp. 178– 187 7Li, X., Liu, Z., Jifeng, H.: ‘A formal semantics of UML sequence diagrams’. Proc. of ASWEC2004, Melbourne, Australia, April 2004 8Samuel, P., Mall, R., Kanth, P.: ‘Automatic test case generation from UML communication diagrams’, J. Inf. Softw. Technol., 2007, 49, pp. 158– 171 (doi: 10.1016/j.infsof.2006.04.001) 9Koehler, J., Sendall, S.: ‘Declarative techniques for model-driven business process integration’, IBM Syst. J., 2005, 44, (1) (doi: 10.1147/sj.441.0047) 10Yin, L., Liu, J., Ding, Z., et al.: ‘Modeling and prototyping business processes in AutoPA’. Fifth Int. Symp. on Theoretical Aspects of Software Engineering (TASE), 2011 11Niaz, I.A.: ‘ Automatic code generation from UML class and statechart diagrams’. Thesis Report, University of Tsukuba, Japan, 2005 12Usman, M., Nadeem, A., Kim, T.-H.: ‘UJECTOR: a tool for executable code generation from UML models’. Conf. on Advanced Software Engineering and its Applications, 2008 13Long, Q., Liu, Z., Jifeng, H., et al.: ‘Consistent code generation from UML models’. Proc. of Australian Software Engineering Conf., 2005 14Rudhal, K.T., Goldin, S.E.: ‘Adaptive multi-language code generation using YAMDAT’. Proc. of ECTI-CON 2008, Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology, 5th Int. Conf., 2008, 14–17 May 2008, vol. 1, pp. 181– 184 Citing Literature Volume10, Issue6December 2016Pages 164-172 FiguresReferencesRelatedInformation
Referência(s)