Design of rules for transforming UML sequence diagrams into java code

Design of Rules for Transforming UML Sequence Diagrams into Java code Mathupayas Thongmak Department of Computer Engineering Chulalongkorn University [email protected]

Pornsiri Muenchaisri Department of Computer Engineering Chulalongkorn University [email protected]

Abstract

Interaction Schemata1 and then changing Interaction Schemata into program was introduced by Neeraj Sangal, Edward Ferrel, Karl Lieberherr and David Lorenz [5]. Gregor Engels, Reiko Heckel, Jochen Malte Kuster discussed about consistency of behavioral models in UML by transform elements of UML model into semantic domain using UML meta model, and then verify semantic domain by semantic domain tool [4]. None of these studies presented rules to transform UML sequence diagrams into corresponding code. This paper proposes rules for transforming UML Sequence diagrams into Java code. Section 2 introduces a transformation approach for UML sequence diagrams. Application of rules with sales system is presented in section 3. The paper ends with some conclusion and future work.

UML is a modeling language that most developers employed during design phase. UML provides various types of diagrams used for specifying both the structure and the behavior of systems. During the development process, models specified by these diagrams are eventually transformed into corresponding code. Although there are many researches studied about transforming UML models into code, they discussed mainly about class, state and collaboration diagrams. None proposed about rules for transforming UML sequence diagrams into a corresponding code. This paper proposes a transformation approach for transforming UML sequence and class diagrams into Java code. The transformation approach consists of a meta model for sequence diagram and transformation rules. The proposed approach is evaluated by applying to at least 3 applications. Keywords: UML, Sequence diagrams, Class diagrams, Transformation rules

2. Transformation approach Sequence Diagram

Map UML Sequence & Class diagrams into UML meta model

1. Introduction The Unified Modeling Language (UML) is a generalpurpose visual modeling language that is designed to specify, visualize, construct and document the artifacts of a software system in both structural and behavioral aspects. Sequence diagram represents program design in behavioral aspects by displaying message passing. Because the need of automated tools, which are used to generate source code from visual model has been increasing overtime, many studies research about an automatic transformation of UML models to programs. A framework for generating source code from class diagrams using XML ruled based approach was proposed by Dong Hyuk Park and Soo Dong Kim [6]. Gregor Engels, Roland Hucking, Stefan Sauer and Annika Wagner presented rules for transforming UML collaboration diagrams into Java code [3]. An automated tool for generating programs from UML sequence diagrams by transforming UML sequence diagram into

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Class Diagram

A meta model for sequence diagram

Input

This paper finds mapping strategies

Intermediate Input

Apply transformation rules

This paper finds meta rules

“Pattern-based transformation algorithm ” Patterns + Rule schema

Java code

Output

Figure 1. The transformation approach for transforming UML Sequence diagrams.

1

Interaction Schemata is statements that describe an interaction between objects. It consists of a set of actions that users must define via user interface. The main actions are addition, deletion, iteration and searching that are used to transform sequence diagrams to programs

The transformation approach for transforming UML sequence diagrams into Java code is shown in Figure 1. It consists of mapping strategies to convert sequence and class diagrams into a meta model for sequence diagram and transformation rules. Sequence and class diagrams used are assumed to be syntactically and static-semantically correct. The transformation algorithm for sequence diagrams, Pattern-based transformation algorithm, is adapted from the transformation algorithm for translating collaboration diagrams into Java code [3]. The basic idea of the transformation algorithm for sequence and class diagrams is specifying patterns first, then transforming patterns into rule schema. The pattern is an instance diagram of the meta model for sequence diagram that is used to portray part of sequence diagrams. The rule schema presented in the form of a context-free rule expression is adapted from the two-level grammar approach [7]. The rule schema is composed of 2 nonterminal symbols. The first one is usual non- terminal symbols replaced by a sequence of non-terminals and terminals by the application of rules. The second kind is parameters of the rule schema that are instantiated by information from the pattern.

Figure 2. Sequence diagram for processOrder(). 2.1. Meta model for sequence diagram UML meta model defines the complete semantics for representing object models using UML [1]. A meta model for sequence diagram is a meta model which is changed to suitable with class and sequence diagrams’ collection. A sequence diagram in Figure 2 is mapped into meta model for sequence diagram in Figure 3 according to the mappings and additional mappings Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

from sequence diagram described down the page. Mappings from sequence diagram into meta model for sequence diagram follow the mappings in UML Notation Guide [2]. Additional mappings are alteration in UML meta model of which standard mappings in UML Notation Guide were not provided. The gray highlight shows parts of a meta model for sequence diagram that do not follow UML meta model standards. 2.1.1. Mappings from sequence diagram into meta model for sequence diagram. At the top part of meta model for sequence diagram, A sequence diagram maps into an Interaction and an underlying Collaboration. A Message between the ClassifierRoles is mapped from a message arrow. A constraint maps into a Constraint placed on the entire Interaction. Subsequent arrows on the same lifeline map into Message obeying the predecessor association. An arrow to the head of a focus of control region maps into a Message (synchronous,activation) with associated CallAction between the ClassifierRoles corresponding to the lifelines. Messages with an activation association to the Message corresponding to the arrow at the head of the activation are mapped from all arrows departing the nested activation. A return arrow departing the end of the activation maps into a Message (synchronous, reply) with an activation association to the Message corresponding to the arrow at the head of the activation and a predecessor association to the previous message within the same activation. Any guard conditions come to be recurrence values of the Message. In the middle part, each object box maps into a ClassifierRole. The ClassifierRole name is mapped from the name field and the type association from the role to the Classifier with the given name is mapped from the type field. At the bottom part, a CreateAction is mapped from an object symbol placed within the frame of the sequence diagram. A DestroyAction is mapped from an object termination symbol (“X”). In other ways, it maps into a TerminateAction. 2.1.2. Additional mappings from sequence diagram into meta model for sequence diagram. At the top part, an operation call maps into Request. The method the sequence diagram described maps into an Operation. The Operation visibility is mapped from the visibility field. The represented association from Operation to Collaboration is mapped from the method described by collaboration of objects. In the middle part, sent and received parameters map into Parameter. The name field called maps into Parameter alias and the Parameter kind is mapped from the type field. ClassifierRole type maps into Classifier. At the bottom part, attributes of Classifier map into Attribute. ReturnVar that have result association to CreateAction and CallAction is mapped

Constraint (From Core)

Request (From Common Behavior)

body:BooleanExpression

name:String

constraint *

Operation (From Core)

represented operation 1

name:String visibility:VisibilityKind

1

0..1

1 context

Collaboration

1

Interaction

*

*

1

1..* message * * Message predecessor * 0..* 0..1 recurrence:BooleanExpression * * activator

0..1

1 sender 1..* /ownedElement

parameter {ordered}

0..*

1

Action (From Common Behavior)

1 receiver

ClassifierRole name:String *

*

Parameter (From Core)

kind:ParameterDirectionKind name:String alias:String

request

1 type

Classifier

type 1

*

name:String 1 * feature

Attribute (From Core) name:String visibility:VisibilityKind

CreateAction * 0..1

CallAction

TerminateAction

DestroyAction

* result 0..1

result

ReturnVar name:String

Figure 3. A meta model for sequence diagram for transforming sequence diagrams.

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

from variables, which are received return values from calling operations.

2.2. Transformation rules Rules for transforming sequence diagrams into Java code are composed of rule 1: meta rules for class diagram of a method that the sequence diagram depicts, rule 2: meta rules for splitting of SEQUENCE, rule3: meta rules for conditional method invocation and branching, rule 4: meta rules for assigning a value to a variable, rule 5: meta rules for assigning object to pointer, rule 6: meta rules for creating new object, rule 7: meta rules for invoking a method of existing object, and rule 8: meta rules for invoking a method of object itself. Because sequence diagrams lack type of variable information, class diagrams are needed in transformation processes. In column 1 of all rules show parts of sequence and class diagrams. We capture the detail of sequence and class diagrams into patterns in column 2. Rule schema is presented in column 3. Rule 1: Meta rules for class diagram of a method that the sequence diagram depicts is presented in Figure 4. Part 1, the starting point of transformation processes, is the declaration of class of method which sequence diagram describes. In part 1 of column 2, c refers to an instance of the classifier. The name of the class is replaced c.name in part 1 column3. Underlined words are terminals. If there is not enough space to define rules in one line, the next line must start with dashed symbol (-). Attribute declarations are replaced the non-terminal ATTRIBUTEScin part 2 column 3. The second ATTRIBUTESc of part 2.1 in column 3 is required for

recursive production of attribute declarations. In part 3, non-terminal symbol SEQUENCEc will be replaced by the code generator for the sequence diagram. PARAMSo of part 3.4 in column 3 terminates the recursive production. Using part 1 and 2 of rule 1 with class Company of the sale system described in section 3 is shown in Figure 5. Rule 2: Meta rules for splitting of SEQUENCE is proposed in Figure 6. The non-terminal SEQUENCEc is replaced by a sequence of other non-terminals in order to specify the structure of body of the method in part 1.1. Part 1.2 to 1.3 is used to replace non-terminal LOCALVAR_DECLo and MESSAGE_INVOCo with an empty string. Rule3: Meta rules for conditional method invocation and branching is presented in Figure 7. If message arrows have conditions or branching, this rule is applied. In case the sequence diagram has no branching, an empty string will replace ELSEIFSo of part 1.1 in column 3. MESSAGE_INVOCo of part 1.1, 1.2 in column 3 will be replaced by message invocations on the conditional arrows. Part 1.4 is used to replace nonterminal MESSAGE_INVOCo with an empty string. Rule 4: Meta rules for assigning a value to a variable is shown in Figure 8. This rule is used for assign a value returned from an operation call to a variable. The variable declaration for x is presented in part 1.1 of column 3. Variable x is assigned value in part 1.2 of column 3. We use part 1.3 of the meta rules if there is no variables to assign values. Part 1.4 is used to replace non-terminal MESSAGE_INVOCo with an empty string.

Figure 4. Meta rules for class diagram of a method that the sequence diagram depicts.

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Figure 5. An adaptation of some parts of meta rules 1 with an example application.

Figure 6. Meta rules for splitting of SEQUENCE.

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Figure 7. Meta rules for conditional method invocation and branching.

Figure 8. Meta rules for assigning a value to a variable.

Figure 9. Meta rules for assigning object to pointer.

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Figure 10. Meta rules for creating new object.

Figure 11: Meta rules for invoking a method of existing object. Rule 5: Meta rules for assigning object to pointer is presented in Figure 9. This rule is used for assign an object returned from method constructor call to a pointer. Pointer declaration is presented in part 1.1 of column 3. Pointer x is assigned object in part 1.2 of column 3. We use part 1.3 of the meta rules if there is no pointers to assign objects. Part 1.9 to 1.10 is used to Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

replace non-terminal LOCALVAR_DECLo and MESSAGE_INVOCo with an empty string. Rule 6: Meta rules for creating new object is presented in Figure 10. Part 1.1 is a splitting local variable declaration’s rule. Receiving parameters of constructor’s declarations are described in part 1.2 to 1.4. Part 1.3 is used in case receiving parameters are not

Figure 12. Meta rules for invoking a method of object itself.

local variable. Part 1.5 shows new object’s creation. Part1.6 to 1.8 is parameter listings. Part 1.9 to 1.10 is used to replace non-terminal LOCALVAR_DECLo and MESSAGE_INVOCo with an empty string. Rule 7: Meta rules for invoking a method of existing object is shown in Figure 11. In this rule, the object of called operation is already created. We can call an operation without constructing new object. Part 1.9 to 1.10 is used to replace non-terminal LOCALVAR_DECLo and MESSAGE_INVOCo with an empty string. Rule 8: Meta rules for method invoking a method of object itself is presented in Figure 12. An operation is called directly in part 1.4. Part 1.9 to 1.10 is used to replace non-terminal LOCALVAR_DECLo and MESSAGE_INVOCo with an empty string.

instances of Order and can relate with several instances of Delivery. Figure 2 is a sequence diagram that depicts the method processOrder. Firstly, the company receives the product number pNr and the ordered amount a from an order object. Secondly, it searches its store whether it has products that the customer wants. If there are enough products, a delivery is created and added to a container holding all deliveries of the company. If there are not, the company will order products from the supplier.

3. Application of rules with sale system We depict an application of rules with the sale system in this section. A customer sends an order to the company when he or she wants to place an order. The company will forward the order to one of its store. The store will deliver the ordered products to the customer in case there are enough products. If there is not enough products in the store, the products will be ordered from the supplier by the company. Figure 13 shows the class diagram of an example application where one Company has one Supplier in contact. A Company is related to zero or more Store, Order and Delivery objects. An Order can have one or none Delivery object. A Customer can placed several Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Figure 13. Class diagram for sale system.

An adaptation of meta rules with sequence diagram are - Apply rule 1 with class Company. - Apply rule 2 with method invocation processOrder(o). - Apply rule 4 with method invocation pNr:=getpNr() and class Order. - Apply rule 7 with method invocation getpNr() and class Order. - Apply rule 4 with method invocation a:=getAmount() and class Order. - Apply rule 7 with method invocation getAmount () and class Order. - Apply rule 4 with method invocation s:=search_store(pNr,a) and class Company. - Apply rule 8 with method invocation search_store(pNr,a) and class Company. - Apply rule 3 with branching. - Apply rule 5 with method invocation d:=delivery (o,s) and class Delivery. - Apply rule 6 with method constructor invocation delivery(o,s) and class Delivery. - Apply rule 7 with method invocation orderProduct(pNr,a) and class Supplier. - Apply rule 8 with method invocation orderProduct() and class Supplier. - Apply rule 3 with condition s!=NULL. - Apply rule 8 with method invocation deliver(d) and class Store. - Apply rule 3 with condition s!=NULL. - Apply rule 8 with method invocation add_delivery(d) and class Company. A tool that is adapted transformation rules is shown in Figure 15. After apply the set of meta rules with the class diagrams depicted in Figure 13 and sequence diagrams shown in Figure 2 by instantiating the meta rules, replacing the non-terminal symbols and cutting off repeated variable declarations, the following Java code is generated. public class Company{ private Vector deliveries; private Vector stores; public void processOrder(Order o){ int pNr; int a; Store s; Delivery d; pNr = o.getpNr(); a = o.getAmount(); s = search_store(pNr, a); if (s!=NULL){ d = new delivery(o, s); }else if(s==NULL)

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

sup.orderProduct(pNr, a); } if (s!=NULL){ s.delivery(d); } if (s!=NULL){ add_delivery(d); } } }

Figure 14. Java code fragments of sale system.

4. Conclusion and Future Work Rules for transforming UML sequence diagrams into Java code is proposed in this paper. The transformation approach maps sequence and class diagrams into a meta model for sequence diagram firstly, then applies transformation rules with that meta model for sequence diagram to generate Java code. Because UML sequence diagrams concentrate on portraying of object interactions, the programming logic details are neglected. Additional codes are needed to complete the program by programmers. This paper focuses on transformation of general sequence diagrams, which include basic type of arrow flows, but excludes synchronous or asynchronous communications and concurrent behavior. The next step will be to perform a formal proof in order to check soundness and completeness of the transformation.

5. References [1] OMG. UML Semantics. Version 1.1. The Object Management Group, Document ad/97-08-04, Framingham MA, 1997. [2] OMG. UML Notation Guide. Version 1.1. The Object Management Group, Document ad/97-08-05, Framingham MA, 1997. [3] Gregor Engels, Roland Hucking, Stefan Sauer and Annika Wagner. “UML Collaboration Diagrams and Their Transformation to Java”, Second International Conference on the Unified Modeling Language (UML’ 99), pp. 437-488, 1999. [4] Gregor Engels, Reiko Heckel and Jochen Malte Kuster. “Rule-Based Specification of Behavioral Consistency Based on the UML Meta-model”, Fourth International Conference on the Unified Modeling Language (UML2001), pp. 272-286, 2001. [5] Neeraj Sangal, Edward Ferrel, Karl Lieberherr and David Lorenz. “Interaction Schemata: Compiling Interactions to Code”, the proceedings of Technology of Object-Oriented Language and Systems (TOOLS USA’ 99), pp. 268-277, 1999.

[6] Dong Hyuk Park, Soo Dong Kim. “XML Rule Based Source Code Generator for UML Case Tool”, Asia-Pacific Software Engineering Conference (APSEC2001), pp. 53-60, 2001.

[7] Ken Slonneger, “Two-level http://www.cs.uiowa.edu/~slonnegr/plf/Book.

Figure 15. An automated tool that implements meta rules.

Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE

Grammars”,