Basic Rules to Build Correct UML Diagrams Mohammad N.

Alanazi Department of Computer Science Imam Muhammad Ibn Saud University P.O. Box 5701 Riyadh 11432, Saudi Arabia alanazi@gmail.com Abstract The Unified Modeling Language (UML) has been designed to be a full standard notation for Object Oriented Modeling. UML has nine types of diagrams [3, 6]: class, object, sequence, collaboration, use case, statechart, activity, deployment and, component diagram. All these diagrams together are used to describe one model. There are some basic rules should be followed when drawing a diagram. Also, one diagram could be correct but inconsistence with another. This paper proposed fifteen basic rules that help developers to build correct and consistent UML diagrams. Keywords- Software Modeling; UML; Modeling Langauges. I. INTRODUCTION Software development is usually a long and complex process including several phases. The development process of a software system is usually divided into steps. In each step different UML diagrams are involved. Some basic rules should be considered when drawing one diagram. Furthermore, UML consists of many diagrams. Each one dedicated to a different design aspect. This variety of diagrams can leave the overall system design specification in an inconsistent state. To enforce consistency between different UML diagrams, some consistency rules must be checked. Current UML CASE tools do not take full advantage of the relationships that exist between the different UML model elements to provide support for maintaining consistency between UML models. This paper introduces some basic rules that can be used to build correct and consistent UML diagrams. Each rule is explained with an example. II. RELATED WORK The author of [1] presented a new approach, ViewIntegra, to discover the errors and consistency on some UML diagrams. He introduced a transformation framework for five UML diagram types (class, object, and sequence, collaboration, and statechart diagrams). This approach uses transformation to bring models closer to one another in order to compare them and detect the errors. In [2], the authors presented techniques for the quantitative assessment of inconsistency and incompleteness in UML designs. Using these techniques they performed a number experiments based on industrial case studies. [4] described an approach for identifying and correcting inconsistency and incompleteness across UML views, in particular use case diagrams, class diagrams, sequence diagrams, and statecharts. The rules for describing the mapping between these different views are derived from the COMET method and are expressed as Object Constraint Language (OCL) constraints. Since UML is not a formal language, authors in [5] suggested translating the UML models into formal language first. Then, make the comparison between the specifications to detect any errors. The authors in [7] presented a flexible and incremental consistency management realized in a UML CASE tool, Fujaba. For the specification of syntactical

consistency rules they provide a built-in formalism based on graph grammars. III. BASIC UML RULES To build correct UML models, there are some basic rules that should be followed. In this section, we describe fifteen basic rules with examples. Those rules help the developers to build correct UML models. Rule 1: Name of the use case must be a verb The use case name in the use case diagrams must be a verb. Figure 1 shows a use case named System Startup. This name is illegal to make it correct the name can be changed to Startup System. Figure 1. Class System Startup violates rule 1. The class use case name must be a verb. Rule 2: Use case must match interaction A use case must correspond to at least one scenario described by an interaction diagram (sequence or collaboration diagram). In figure 2, the use cases: Startup System and Shutdown System are not described in any interaction diagram. 2009 International Conference on New Trends in Information and Service Science 978-0-7695-3687-3/09 $25.00 2009 IEEE DOI 10.1109/NISS.2009.252 72