UML-Compiler: A Framework for Syntactic and Semantic Verification of UML Diagrams

Transcription

1 UML-Compiler: A Framework for Syntactic and Semantic Verification of UML Diagrams Jayeeta Chanda, Ananya Kanjilal, and Sabnam Sengupta B.P. Poddar Institute of Management & Technology Kolkata -52, India jayeeta.chanda@gmail.com, ag_k@rediffmail.com, sabnam_sg@yahoo.com Abstract. UML being semi formal in nature, it lacks formal syntax and hence automated verification of design specifications cannot be done. To address this we propose a UML Compiler that takes context free grammars for UML diagrams and verifies the syntactic correctness of the individual diagrams and semantic correctness in terms of consistency verification with other diagrams. This UML-Compiler is a part of a framework, which consists of two modules. First module converts XMI format of UML diagrams, as generated by any standard tool into string format and second module (UML-Compiler) is for verification of the diagrams. This paper focuses on the second module and proposes a formal context free grammar for the two of the commonly used UML diagrams - Class diagram (depicting the static design) and sequence diagram (depicting behavioral design) and validated by using Lex and YACC. Keywords: UML Formalization, Context Free Grammar, Parse Tree, Formal Verification of UML. 1 Introduction UML is a widely accepted industry standard for modeling analysis and design specifications of object-oriented systems. But, UML lacks the rigor of formal modeling languages and hence verification of a design specified in UML becomes difficult. Formalization of UML diagrams is now a dominant area of research. This paper is also a work in that direction. We propose a framework for automatic transformation of the UML diagram from its graphical form into a string that conforms to the grammar we have defined in section 4 of this paper and a compiler for the string form of the diagrams. For compiling the string form of the diagrams we propose a grammar and implement it in Lex/YACC for syntax verification. The production rules, terminals, non-terminals are chosen and proposed such that it adheres to the notations of UML 2.0 standard. We have also proposed a set of verification criteria that comprises of syntactic correctness rules and consistency rules. The consistency rules have been proposed by analyzing the interrelationships among the diagrams so that they together represent a coherent design. Existing UML editors or the standard drawing tools do enforce syntactic correctness to some extent, but much needs to be done regarding semantic T. Janowski and H. Mohanty (Eds.): ICDCIT 2010, LNCS 5966, pp , Springer-Verlag Berlin Heidelberg 2010

2 UML-Compiler: A Framework for Syntactic and Semantic Verification 195 verification. Our proposed framework is a step towards that direction. The consistency rules will help in verifying semantic correctness of the design as they correlate the design models, which is not explicit in the UML standard. Verification of all the rules has been presented based on the proposed grammar. We derive the parse tree representation of the class and sequence diagrams, which is an alternate form of the same grammar and these different formal representations are deliberately used to bring completeness in our formal model. 2 Review of Related Work Formalization of UML has become a prominent domain of research for the last few years. Achievement of automated consistency checking and execution has led the software engineers and researchers to focus in this domain. Our work, too, proposes formalization of UML class and sequence diagrams based on a proposed grammar. In this section we will discuss a few works done in this domain related to formalization of UML static and dynamic models. In [1], UML class diagram is formalized in terms of a logic belonging to Description Logics, which are subsets of First-Order Logic to make it possible to provide computer aided support during the application design phase for automatic detection of relevant properties, such as inconsistencies and redundancies,. An algebraic approach is chosen in [2] because it is more abstract than state-based style languages. The transformation rules for formalizing UML statet diagrams have been proposed in [3]. The target language for the transformation is Concurrent Regular Expressions (CREs), which are extensions of regular expression. RSL (RAISE (Rigorous Approach to Industrial Software) Specification Language) has been used in [4] as a syntactic and semantic reference for UML. An automated tool that implements the translation and the abstract syntax in RSL for the RSLtranslatable class diagrams are also presented. The integration of the domain modeling method for analyzing and modeling families of software systems with the SOFL formal specification language is discussed in [5]. A UML 1.5 profile named TURTLE (Timed UML and RT-LOTOS Environment) is proposed in [9], which is endowed with a formal semantics given in terms of RT- LOTOS. An approach to formally define UML class diagrams using hierarchical predicate transition nets (HPrTNs) have been presented in [6] and preliminary results are presented. The authors show how to define the main concepts related to class diagrams using HPrTN elements. The semantics presented in [7] captures the consistency between sequence diagram with class diagram and state diagram. In [12], Hoare's CSP (communicating sequential processes) has been used to formalize the behaviors of UML Activity Diagrams. In [10], π-calculus has been applied to formalize UML activity diagrams to get rich process semantics for activity diagrams. This process model can be automatically verified with the help of π-calculus analytical tools. Hoare's CSP (communicating sequential processes) has been used in [13] to formalize the behaviors of UML activity diagrams and provides an approach to enable model checking during software analysis or design phase. UML's class diagram and OCL constraints is formalized in [14] using theorem prover Isabelle using one of its built-in logics, HOL.

3 196 J. Chanda, A. Kanjilal, and S. Sengupta The operational semantics of UML sequence diagrams is specified and this specification is extended to include features for modeling multimedia applications as a case study in [8]. Dynamic Meta modeling has been proposed for specifying operational semantics of UML behavioral diagrams based on UML collaboration diagrams that are interpreted as graph transformation rules. The authors in [11] have defined a template to formalize the structured control constructs of sequence diagram, introduced in UML 2.0. Z specifications has been proposed in [13] to reduce risks associated with software development and increase safety and reliability by formalizing the syntax of (a sub-set of the popular UML diagrams (Use Case diagram, Class diagram, and State Machine diagram). Our earlier work [15] also used Z to propose a formal model for six UML diagrams. However Z is a non-executable language and hence automated verification is not possible unless translated or mapped to executable models like XML using ZML. In all these research works, UML diagrams have been formalized using other formal languages. In this paper, we define a context free grammar of the very widely used UML diagrams, Class and Sequence diagram. The CFG is executable unlike Z notation and validation of the grammar is done using LEX and YACC, which are open source software. 3 Scope of Work In this paper we propose a framework for automatic transformation of UML diagrams into a string and then compilation of that string for syntactic correctness and interdiagram consistency verification, which is a kind of semantic verification. The framework is divided into following two modules (as shown in Fig 1) 1) XMI to String Converter: This module will convert the XMI form of the UML diagrams into a string that will follow the context free grammar proposed by us in section 4 of this paper. 2) UML Compiler: This module will check the syntactic correctness of diagrams and verification of consistency among the diagrams. In this paper we have defined and implemented the second module i.e. the UML compiler. Here we have proposed the formalization technique using context free grammar for Class and Sequence diagrams the two most commonly used UML models capturing the static and dynamic aspects of an object-oriented system. Based on the grammar and UML 2.0 standard, we have defined several rules to highlight syntactic correctness of the diagrams and inter-diagram consistency based on the common elements present. We have used Lex and YACC to validate the grammar. UML Diagram UML Tools XMI format XMI to String Converter String Format UML Compiler Verified UML Fig. 1. The Framework for Graphical UML compiler

4 UML-Compiler: A Framework for Syntactic and Semantic Verification Formal Model Use cases are realized through Sequence diagrams, which are a set of messages each having a number ordered with respect to time. Each message is sent between either two Actors or two Objects or an actor and an object. The messages may be text strings or methods of classes. Each sequence diagram corresponds to one use case. A Class diagram is defined as a set of both zero or more relationships and one or more classes. We will be considering only two of the commonly used UML diagrams for formalization Class diagram that depicts the static acteristics and Sequence diagram that depicts the behavioral acteristics. The formal grammar has been defined for each of the diagrams followed by the parse tree representation. We have used regular expression features (eg. +, *) in the production rules for simplicity and easy understanding. However, for Lex/YACC implementation, we have used a recursive definition of the grammar. 4.1 Grammar for Class Diagram Let the grammar (S, N, T, P) where S, N, T, P represent start symbol, non terminals, terminals and production rules T= {, void, integer, long, short, date, String, class,double,digit, +, -, #, association, generalization, aggregation, (, ),.., :} All other symbols used in the production rule P are non-terminals (N). P: S class_diagram class_diagram classes + relation* classes cname attribute* method_class* cname attribute access_specifier data_type attribute_name data_type attribute_name access_specifier + _ # data_type void integer long short date String class double attribute_name method_class access_specifier data_type method_name ( parameter_list) parameter_list parameter* parameter data_type parameter_name parameter_name relation cname multiplicity* cname relationship relationship identifier description type identifier type type aggregation association generalization identifier description multiplicity digit.. digit [a-z A-Z][a-z A-Z 0-9]+ digit [0-9 *]

5 198 J. Chanda, A. Kanjilal, and S. Sengupta 4.2 Grammar for Sequence Diagram P: S sequence_diagram sequence_diagram lifeline+ lifeline object_name focus_of_control + object_name message+ focus_of_control focus_id message+ message time_order message_description source destination time_order digit + focus_id message_description method_sequence source actor_from object_from destination actor_to object_to (actor_from and object_from is destination actor & destination object) actor_to actor_from object_to object_name object_from object_name object_name : classname classname (classname is name of the class and object_name is name of the object) method_sequence ( ) [a-z A-Z 0-9]+ digit [0 9] 4.3 Notations Used in the above Grammar and Their Meanings The notations used in this paper and their meanings are given in Table 1. Table 1. Notations and their Meanings Sl. No. Notation Meaning Sl. No. Notation Meaning 1. class_diagram Class diagram 12. access_specifier Access Specifier for attributes 2. classes Classes defined in class diagram 13. data_type Data type 3. relation Relation between classes 14. attribute_name Name of attribute 4. cname Name of class in Class diagram 15. method_name Name of Method 5. attribute Attribute of a class 16. parameter_list List of parameters for a method 6. method_class Method defined in class diagram 17. parameter_name Name of parameter 7 life_line Object Life line in Method defined in 18. method_sequence sequence diagram sequence diagram 8 object_name Name of object 19. actor_to Source actor 9. focus_of_control Focus of control of a message 20. object_to Source object 10. message Message of sequence diagram 21. time_order Time order 11. message_description Description of the classname and Name of class and 22. message objectname object

6 UML-Compiler: A Framework for Syntactic and Semantic Verification 199 The parse tree representation of the above grammar for class diagram is shown in Fig 2. The same is generated in figure 3 for the grammar (in section 4.2) defined for sequence diagram class_ diagram classes.. relation.. name attribute.. method_class.. access_ specifier Name - or + or # terminal : data_ type access_ specifier method_ name + void or integer. parameter_ list ( parameter.. parameter_ name : memid ) cname multiplicity cname relationship data_ type n..n void or integer. 1 identifier description type association or... Fig. 2. Parse Tree for the proposed grammar of class diagram sequence_diagram lifeline.. object_ name focus_ of_control : focus_ ID message digit+ tim e_ order message_ descrip.. source actor_ from destination object_ to object_ name : Fig. 3. Parse tree for the proposed grammar of sequence diagram

7 200 J. Chanda, A. Kanjilal, and S. Sengupta 5 Defining Verification Criteria 5.1 Correctness Rules The syntactical rules for a Class Diagram to be a correct one are: 1. A class diagram must have at least one class. 2. A class diagram may or may not have a relationship (association, generalization, aggregation etc.) between two classes. 3. A class must have one and only one name. 4. A class may or may not have one or many attributes and methods. 5. A relation may or may not have multiplicity but it should have relationship. 6. A relationship should have unique id and type and it may or may not have description. The syntactical rules for a Sequence Diagram to be a correct one are: 1. A sequence diagram must have at least one lifeline and henceforth at least one message. 2. A message must have one and only one time order. 3. A message must be composed of either one of the following combinations: Two objects One object and one actor Two actors i.e. Objects in Sequence diagram belong to specific Classes 4. Objects in the sequence diagram have one and only one lifeline. 5. Objects have one or many focus of control. 6. Multiple messages may belong to same focus of control. 7. A message may or may not have one and only one method (0 or 1 method) Additional syntactic rules for correct Sequence Diagram 1. A message may have one object (when method of that object itself is invoked) but this message cannot be the only message of the sequence diagram. In other words, if there is more than one message, a particular message may have one object. if msg i ={ tm_o, m, ob_fr, ob_to} then (ob_fr = ob_to) iff ( i>1) where msg message, m method_sequence,ob_to object_to, ob_fr object_from and tm_o time_order 2. The object name of the life line in which a message belongs should either be the source or the destination of the message

8 UML-Compiler: A Framework for Syntactic and Semantic Verification 201 message, if ob_nm object_name then either ob_nm=ob_to or ob_nm=ob_fr where ob_fr object_from ob_to object_to then either ob_nm=ob_to or ob_nm=ob_fr 5.2 Consistency Rules The class and sequence diagrams though represent different views of the system they are related. The sequence diagram uses the operations defined in classes. This is cross- checked for ensuring consistency between the two diagrams Necessary conditions - The following two rules have been proposed which are necessary conditions for ensuring consistency within class and sequence diagram. Rule 1: Each unique method of messages in Sequence diagram should be present as a method of a class in class diagram Rule 2: The classes having objects appearing in Sequence diagram must be present in Class diagram 6 Verification of Rules 6.1 Verifying Syntactic Correctness Using Grammar Refer to the regular expression of the UML models defined in section 4.3. For a Class Diagram the correctness rules can be verified using the grammar in the following way: 1. A class diagram must have at least one class. 2. A class diagram may or may not have a relationship (association, generalization, aggregation etc.) between classes. Rule (1) &(2) can be verified from the following production rules of the grammer class_diagram class + relation* class name attribute* method_ class* From the above production rule we can derive the regular expression class_diagram class1 class_diagram class1 class2 relation 3. A class must have one and only one name. class name attribute* method_class* From the above production rule we have the class name regular expression

9 202 J. Chanda, A. Kanjilal, and S. Sengupta 4. A class may or may not have one or many attributes and methods. class name attribute* method_class* class name class name attribute class name attribute1.attributen class name attribute1.attributen method_class class name attribute1.attributen method_class1 method_classn 5. A relation may or may not have multiplicity but it should have relationship. relation multiplicity* relationship multiplicity* relation relationship relation multiplicity relationship relation multiplicity relationship multiplicity 6. A relationship should have unique id and type and it may or may not have description. relationship identifier description type identifier type type aggregation association generalization identifier description relationship identifier type id1 aggregation relationship identifier description type id1 generalization Therefore, all the correctness rules for the class diagram can be verified using the proposed UML grammar. Notations used in this section represent the same meaning as defined in section 4.1 For a Sequence Diagram the correctness rules can be verified using the grammar in the following way: 1. A sequence diagram must have at least one message. sequence_diagram lifeline+ lifeline object_name focus_of_control + object_name message+ focus_of_control focus_id message+ 2. A message must have one and only one time order. message time_order message_description source destination 3. A message is between one & only source and one &only destination and must have a description. The message description can be a string or a method. message time_order message_description source destination message_description method_sequence

10 UML-Compiler: A Framework for Syntactic and Semantic Verification A message must be composed of either one of the following combinations: Two objects source object_to destination object_from One object and one actor Two actors source actor_to object_to destination actor_from object_from source actor_to destination actor_from 5. Sequence diagram have one and only one lifeline and lifeline is uniquely identified by object name. sequence_diagram lifeline lifeline object_name focus_of_control + object_name message+ 6. Lifeline have one or many focus of control or atleast one message. lifeline object_name focus_of_control + object_name message+ Therefore, all the correctness rules for the class diagram can be verified using the proposed UML grammar. Notations used in this section represent the same meaning as defined in section Verifying Consistency Using Grammar Rule 1: Every method in Sequence diagram should be present in the Class diagram In the Sequence diagram, object_to object_from represent objects of classes which should belong to class diagram i.e. object_to class object_to name attribute* method_class* The method in Sequence diagram belongs to object_to (object of the Class to which message is sent) i.e. method_sequence object_to method_sequence name attribute* method_class* method_sequence method_class

11 204 J. Chanda, A. Kanjilal, and S. Sengupta This implies that method method_sequence in sequence diagram within the message should be represented as method_class to which messages is sent. It satisfies consistency rule 1. Rule 2: Every object in Sequence should belong to a Class in Class diagram Again,object_to class Again object_to name attribute* method_class* method_sequence object_to method_sequence name attribute*method_class* This implies that method_sequence within the message in sequence belongs to the object of the class (object_to ), the name of which should be the name of the class in class diagram that contains the method as method_class. It satisfies rule 2. 7 Conclusion UML being a visual modeling language is widely used for capturing and designing specifications of object oriented systems. However it is not a formal model and hence ambiguities may arise in design specifications between models that represent compiler overlapping but different aspects of the same system. In this paper we propose a UML compiler in which define a formal model for UML class and sequence diagrams, the two widely used models, which represent static and behavioral aspects. A context free grammar is proposed for both for the UML 2.0 standard. A set of verification criteria composed of correctness rules and consistency rules are defined. Using the proposed grammar each of these rules has been verified and parse tree for the grammar is generated. Our future work will focus on developing the first module of the tool, which will convert XMI format of the UML diagram into a string, which conforms to the grammar defined in this paper. The formal models can be defined for all other UML diagrams so that consistency among all the models can be verified, which is a kind of semantic verification. References 1. Calì, A., Calvanese, D., De Giacomo, G., Lenzerini, M.: A Formal Framework for Reasoning on UML Class Diagrams. In: Hacid, M.-S., Raś, Z.W., Zighed, D.A., Kodratoff, Y. (eds.) ISMIS LNCS (LNAI), vol. 2366, pp Springer, Heidelberg (2002) 2. Pascal Andre, Annya Romanczuk, Jean-Claude Royer. Checking the Consistency of UML Class Diagrams Using Larch Prover, Rigorous Object Oriented Method, ROOM (2000) 3. Jansamak, S., Surarerks, A.: Formalization of UML Statet Models Using Concurrent Regular Expressions. In: 27th Australasian Computer Science Conference, the University of Otago, Dunedin, NZ (January 2004) 4. Meng, S., Naixiao, Z., Aichernig, B.K.: The Formal Foundations in RSL for UML Statet Diagram, Technical Report 299. UNU/IIST (July 2004) 5. Gomaa, H., Liu, S., Shin, M.E.: Integration of the Domain Modeling Method for Families of Systems with the SOFL Formal Specification Language. In: 6th IEEE International Conference on Complex Computer Systems (ICECCS 2000), Tokyo, Japan, September 11-15, p. 61 (2000)

12 UML-Compiler: A Framework for Syntactic and Semantic Verification He, X.: Formalizing UML Class Diagrams: A Hierarchical Predicate Transition Net Approach. In: The Twenty-Fourth Annual International Computer Software and Applications Conference, Taipei, Taiwan, October 25-28, p. 217 (2000) 7. Li, X., Liu, Z., Jifeng, H.: A Formal Semantics of UML Sequence Diagram. In: Australian Software Engineering Conference (ASWEC 2004), Melbourne, Australia, April 13-16, p. 168 (2004) 8. Hausmann, J.H., Heckel, R., Sauer, S.: Towards Dynamic Meta Modeling of UML Extensions: An Extensible Semantics for UML Sequence Diagrams. In: IEEE 2001 Symposia on Human Centric Computing Languages and Environments (HCC 2001), Stresa, Italy, September 5-7 (2001) 9. Apvrille, L., Courtiat, J.-P., Lohr, C., de Saqui-Sannes, P.: TURTLE: A Real-Time UML Profile Supported by a Formal Validation Toolkit 30(7) (July 2004) 10. Dong, Y., Sheng, Z.S.: Using p - calculus to Formalize UML Activity Diagram. In: 10th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS 2003), Huntsville, Alabama, April 7-10 (2003) 11. Virani, H.S., Niu, A.J.: Formalize UML 2 Sequence Diagrams. In: 11th IEEE High Assurance Systems Engineering Symposium, HASE 2008, December 3-5, pp (2008) 12. Xu, D., Philbert, N., Liu, Z., Liu, W.: Towards Formalizing UML Activity Diagrams in CSP. In: International Symposium on Computer Science and Computational Technology, ISCSCT 2008, December 20-22, vol. 2, pp (2008) 13. Mostafa, A.M., Ismail, M.A., El-Bolok, H., Saad, E.M.: Toward a Formalization of UML2.0 Metamodel using Z Specifications. In: Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, SNPD 2007, July 30-August , vol. 1, pp (2007) 14. Ali, T., Nauman, M., Alam, M.: An Accessible Formal Specification of the UML and OCL Meta-Model in Isabelle/HOL. In: IEEE International Multitopic Conference, INMIC 2007, December 28-30, pp. 1 6 (2007) 15. Sengupta, S., Bhattaya, S.: Formalization of Functional Requirements of Software Development Process. Journal of Foundations of Computing and Decision Sciences (FCDS) 33(1), (2008)