Generating Dependency Relationships among UML Model Elements for Impact Analysis of UML Documents

Masayuki KOTANI and Koichiro OCHIMIZU Department of Information Science Japan Advanced Institute of Science and Technology 1-8 Asahidai, Tatsunokuchi, Nomi, Ishikawa 921-1211, JAPAN {m-kotani, ochimizu}@jaist.ac.jp

ABSTRACT In this paper, we propose a method to generate dependency relationships among UML model elements for impact anal- ysis of UML diagrams. We take Model Based Translation approach to generate them. In drawing UML diagrams, a modeler or a designer should define various kinds of depen- dency relationships, such as refine and trace, manually based on the traceability policy. This work is very error-prone and time consuming. We propose the meta model of UML to generate dependency relationships among model elements of UML diagrams automatically. We also discuss our meta model is useful for generating workflows for change support. We show the effectiveness of our approach by examining the several examples. Figure 1: An abstract of generation method for de- pendency relationships Keywords dependency relationship, impact analysis, UML, meta model

1. INTRODUCTION lationships among model elements of UML diagrams. When In a software development, a developer creates an the translator gets a model element of a UML diagram from referring other artifacts. There are various kinds of depen- the XML database of some CASE tool, it decides the corre- dencies among them, such as refine and trace. In creating sponding meta element of the meta model. Then the trans- or changing an artifact, the developer should define those lator generates the dependency relationships between the two dependency relationships manually based on the traceability model elements based on a meta relation between correspond- policy. This work is error-prone and time consuming. In this ing meta elements. paper, we propose a method for generating dependency rela- tionships automatically among model elements of UML dia- 2.1. Defining meta relations grams, using Meta model of UML for Change (abbreviated We examine the dependency relationships in UML1.5 to make to MUC). A group of artifacts connected by dependency rela- the semantics of them clear. We show the list of dependency tionships can be considered as an order of changing artifacts. relationships and define the meaning of them from the view- We also discuss the semantics of dependency relationships point of change support as shown in Table 1. In Table 1, the from the viewpoints of change activities as a basis of gener- leftmost column shows the notation in UML meta model, and ating a workflow for change support. There are three kinds the middle column shows the stereotypes used in UML dia- of change such as “Add”, “Delete” and “Modify”. Semantics grams, and the rightmost column shows the characteristics of tracing is different from each change type. We discuss the we defined. characteristic of dependency relationships for each change type. The difference of stereotypes in Table 1 mainly comes from the types of connected ones but the operations related 2. GENERATING DEPENDENCY RELATIONSHIPS to change are classified into three categories: Lifetime, At- AMONG MODEL ELEMENTS OF UML DIAGRAMS tributes and Elements as explained in the following. We take model based translation approach [1] to generate dependency relationships between UML model elements as • “Lifetime” means that a lifetime of the child is equal to the shown in Figure 1. An input of a translator is a set of UML lifetime of the parent. diagrams and an output of the translator are dependency re- • “Attributes” means that several attributes of elements of Table 1: Analyzing semantics of dependency relation- modified when the child is modified, and the reverse is also ships in UML1.5 true; the child is deleted when the parent is deleted, and the reverse is not true. The meta element at the tail of the arrow is the child, and the other at arrowhead is the parent. In Table notation in stereotypes in 2, meta element X is the parent, meta element Y is the child. UML meta model UML diagram characteristics Bind bind Lifetime, Attributes CopyOf. A meta relation “CopyOf”, characterized by “At- Abstraction derive Lifetime, Attributes tributes” and “Elements”, indicates that elements of both ends realize Lifetime, Attributes are the same one. This means that the element of the one end refine Lifetime, Attributes is modified when the other is modified. This is drawn as a trace Lifetime, Attributes line with two arrows. In Table 2, meta element X and Y are Usage use Lifetime the same. call Lifetime create Lifetime, Attributes 2.2. Defining meta elements instantiate Lifetime We define the meta elements of MUC in Table 3. Permission send Lifetime access Lifetime, Attributes Table 3: meta elements of meta model MUC friend Lifetime, Attributes meta elements model elements of UML diagram import Lifetime , , class, Flow become Lifetime, Attributes Classifier , node, copy Attributes, Elements Meta object object (in ) Extend extend Lifetime association, aggregation Include include Lifetime Relation dependency, generalization InstanceOf instanceOf Lifetime MetaLink link (in object diagram) MetaState state, action state MetaTransition transition, , action both ends are the same. MetaInstance object • “Elements” means that elements of both ends are the same MetaMessage message one. In conclusion, we categorize stereotypes into three groups and each group has the same set of characteristics. We define In Table 3, Classifier is an abstraction of structural entities the meta relations of MUC as shown in Table 2. such as an actor, a usecase, a class, a package, a component and a node. The definition of Classifier of our meta model Table 2: meta relations is different from the definition of Classifier in UML meta model. We do not include “an object” in Classifier to distin- notation meta relation guish type and instance. The corresponding meta element of an object is Meta object. Relation is an abstraction of rela- X Y ExistTogether tions between structural entities as shown in Table 3. Meta X Y Follow link is an abstraction of link. Remaining four meta elements are abstraction of computation caused by structural entities. X Y CopyOf Meta state and Meta transition represent a behavior of some entity and Meta instance and Meta message represent an in- teraction among structural entities. In Table 2, each meta relation has the following meaning. We need to recognize a UML diagram as a meta element ExistTogether. A meta relation “ExistTogether”, character- because a statechart represent a computation of some object ized by “Lifetime”, indicates that the child lifetime depends and we need to delete the statechart when we delete the cor- on the parent lifetime. This means that the child is deleted responding class definition. There are nine UML diagrams when the parent is deleted. The meta element at the diamond such as a usecase diagram, a , an object dia- side is the parent, and the other is the child. In Table 2, meta gram, a , a , a state- element X is the parent, and meta element Y is the child. chart diagram, an diagram, a and a collaboration diagram. We classified these nine UML dia- Follow. A meta relation “Follow”, characterized by “Life- grams into three categories as shown in Table 4. time” and “Attributes”, indicates that several attributes of the elements of both ends are the same, and the child lifetime de- We classified them into three based on the Classifier as pends on the parent lifetime. This means that: the parent is shown in Table 5 where the “RelationshipDiagram” shows Table 4: meta elements for UML diagrams

meta elements UML diagrams , class diagram, Figure 3: recursive meta relation of Meta Element RelationshipDiagram object diagram, component diagram, deployment diagram statechart diagram, between “Classifier” and “MetaInstance” because “MetaIn- BehaviorDiagram stance” is an instance of “Classifier”. There is a meta relation sequence diagram, “CopyOf” between “MetaInstance” and “MetaObject”. InteractionDiagram collaboration diagram We need to define several matching rules based on the model elements shown in Figure 4 to generate the depen- dency relationships automatically among model elements. a relation between Classifiers. “BehaviorDiagram” shows a behavior of the Classifier. “InteractionDiagram” shows com- In Table 6, we show “matching rules”. Filled matrix el- munication between Classifiers. ements show the allowable combinations of types of model elements. The value of a matrix element means the condi- Table 5: classification based on Classifier tion for matching. For an example, we can generate some dependency relationship between two actors if the name of diagrams components one actor equals to the name of the other actor. The other ex- Classifier, MetaObject, ample is that we can generate some dependency relationship RelationshipDiagram Relation, MetaLink between object and class if the name of an object includes BehaviorDiagram MetaState, MetaTransition the name of class. It means the name of the object should be InteractionDiagram MetaInstance, MetaMessage qualified by the name of the class.

2.4. Evaluating the effectiveness of the MUC We define “MetaElement” as a super class of all meta el- We performed an experiment to evaluate the effectiveness of ements as shown in Figure 2. The role of “MetaElement” is the MUC. We compared dependency relationships created by to define “CopyOf” meta relation among any meta elements an examinee with dependency relationships generated by a of MUC ( Figure 3 ). tool. We used 15 UML diagrams described in Cruise Con- trol & Monitoring System [2]. The result of the experiment is shown in Table 7. There are 50 dependency relationships generated by a tool. There are 42 dependency relationships that were recognized by the examinee. There are 35 depen- dency relationships common to both.

The dependency relationships generated by a tool, but not created by the examinee. The examinee failed to define a lot of dependency relationships between the same model el- ements. Some class in a class diagram is copied to another Figure 2: meta elements of MUC class diagram. All of them should have dependency relation- ships to the same collaboration diagram. The tool can cre- 2.3 Definition of the MUC ate all of the necessary dependency relationships completely. We show the MUC in Figure 4 and Table 6 summarizing the This shows one of advantages of our approach. consideration so far. Dependencies that cannot be generated automatically but Our MUC consists of meta elements, meta relations and recognized by the examinee. There are 7 dependency rela- matching rules. In Figure 4, there exist meta relations “Ex- tionships that cannot be generated by the tool. But all of them istTogether”: between “RelationshipDiagram” and “Classi- have the same type. They are the dependency relationships fier”, “MetaObject”, “Relation”, “MetaLink” ; between “Be- between a usecase diagram and a collaboration diagram. The haviorDiagram” and “MetaState”, “MetaTransition”; between examinee created them as the dependency relationships be- “InteractionDiagram” and “MetaInstance”, “MetaMessage”. tween a usecase and a collaboration diagram. We need to There is a meta relation “Follow” between “Classifier” and add the meta relation between “Classifier” and “Interaction- “BehaviorDiagram” because “BehaviorDiagram” shows the Diagram” in our MUC to generate those dependency rela- behavior of “Classifier”. There is a meta relation “Follow” tionships automatically. However, we should not take such Figure 4: meta model of UML for change

Table 7: the result of the examination Intuitively dependency relationship represents the order of works when we change model elements. But whether we Automatically Manually can generate sequencing information from dependency re- A number of 50 42 lationship or not depends on types of change activities. We dependencies consider two kinds of change activities here. When we delete A number of some model element, we may delete the other model element matched 35 connected by meta relations “ExistTogether” and “Follow”. dependencies When we modify some model element, we may modify the other model element connected by “Follow” and “CopyOf” meta relations. We summarize the result in Table 8. Defini- tion of change type for “Add” is under consideration. an ad hoc approach. This result suggests us that the “Clas- sifier” should be defined for each UML view to assure the traceability between UML views. We are now investigating Table 8: related meta relations for each change type the proper definition of the subclasses of meta element “Clas- change type related meta relations sifier”. Delete ExistTogether, Follow 3. PRELIMINARY DISCUSSION FOR AUTOMATIC Modify Follow, CopyOf WORKFLOW GENERATION Final goal of our research is to generate multi-threaded work- flows to make designer’s change activities efficient and re- 4. CONCLUSION AND FUTURE WORKS ducing error-prone. In this section, we discuss the prelimi- In this paper, we proposed the meta model that enable us to nary consideration about workflow generation. We show an generate dependency relationships among model elements of outline of generation of the workflow in Figure 5. Inputs of UML diagrams. a generator are: dependency relationships; the original UML diagrams and their model elements of the UML diagram. The Our meta model is mainly defined for the logical view of output of the generator is a workflow. UML. We must refine our meta model to be able to deal with the other view, such as, usecase view, concurrency view, de- ployment view and component view. We think we can define them by refining our meta model especially for Classifier.

We also had the basic consideration on a workflow gener- ation. To generate a useful workflow, we must consider syn- Figure 5: generating workflows using dependency re- chronization among multi-threaded workflows execution and lationships access control of based on the role assignment in the team. Table 6: matching rules ------equal include action state name/name file/element ------state equal include name/name file/element ------equal object include include include include include name/name name/name name/name file/element file/element file/element ------equal include component name/name file/element ------node equal include name/name file/element ------equal include package name/name file/element ------class equal include include include include name/name name/name name/name name/name file/element ------equal include include include include include use case name/name name/name name/name name/name name/name file/element ------actor equal include include name/name name/name file/element state class node class actor object object activity diagram diagram diagram diagram diagram diagram diagram diagram use case use case sequence statechart component component action state deployment collaboration This research is supported by the Ministry of Education, Science, Sports and Culture, Grant-in-Aid for Scientific Re- search on Priority area #16016239. REFERENCES 1. Dragon Milic`ev, “Automatic Model Transformations Using Extended UML Object Diagrams in Modeling Environments”, IEEE Trans. Software Eng., vol. 28, no. 4, pp.413-431, April. 2002. 2. Hassan Gomma, “Designing concurrent, distributed, and real-time applications with UML”, Addison Wes- ley, Inc. 2000. 3. , “Unified Modeling Lan- guage (UML), version 1.5”, http://www.omg.org/cgi- bin/doc?formal/03-03-01