1390
IEICE TRANS.INF.&SYST.,VOL.E89–D,NO.4APRIL2006
PAPER Special Section on Knowledge-Bad Software Engineering
Meta-Modeling Bad Version Control System for Software Diagrams
Takafumi ODA†∗,Nonmember and Motoshi SAEKI†a),Member
SUMMARY In iterative software development methodology,a version control system is ud in order to record and manage modification histories of products such as source codes and models described in diagrams.How-ever,conventional version control systems cannot manage the models as a logical unit becau the systems mainly handle source codes.In this paper, we propo a version control technique for handling diagrammatical mod-els as logical units.Then we illustrate the feasibility of our approach with the implementation of version control functions of a meta-CASE tool that is able to generate a modeling tool in order to deal with various diagrams. key words:UML diagram,version control system,meta-CASE,repository 1.Introduction
In software development process,various kinds of doc-uments and source codes produced in the pro
cess are frequently changed for various reasons, e.g.customers’requirements changes,during development.Developers should have various versions of a product and manage them in their project.In this situation,the techniques for version control are significant to support their tasks by using com-puterized tools.In addition,in modern software develop-ment,we frequently adopt iterative and incremental devel-opment styles such as Unified Process[2]and XP[3],and version control is mandatory for incremental and iterative development styles.We have excellent version control tech-niques and computerized supporting tools for source codes such as RCS[4],CVS[5]and Subversion[6].The tools store the current version of a product and the differences be-tween the adjacent versions in a repository,so that all the older versions can be recovered by applying the stored dif-ferences to the current version(backward difference).How-ever,they are for text documents and adopt line bad he granularity of version control is a“line”and the difference is generated line by line.Since we u di-agram documents such as class diagrams in modeling stages of development projects,we should manage the changes on the diagrams,not in the granularity of a line,but of a logical unit “Class”,“Association”,“Attribute”etc. in the ca of Class Diagram.The targets of version control should be logical components and they depend on develop-ment methods.For example,the targets are“Class”,“At-tribute”,“Association”,etc.in the ca of Class Diagram, Manuscript received June30,2005.
Manuscript revid October11,2005.
†The authors are with the Dept.of Computer Science,Tokyo Institute of Technology,Tokyo,152–8552Japan.
∗Prently,with Yokogawa Electric Corporation.
a)E-mail:saeki@.cs.titech.ac.jp
DOI:10.1093/ietisy/e89–d.4.1390while they are“State”,“Transition”etc.in State Diagram. That is to say,we should manage version records on the level of manipulating components of a class creation of a class and deletion of an attribute in a class,etc.
To model a complicated software system,we repre-nt its model with various diagrams from parated mul-tiple viewpoints,for example a class diagram for structural views and state diagrams for behavioral views.It means that our version control system should handle various logi-cal components that are different according to the ud dia-grams.Becau of this,a bespoke version control system is required for each diagram type,which will prove an unrea-sonable waste of development resources.
Some of CASE tools for diagrams such as Argo UML[7]can transform a diagram into an XML document using the XMI technology[9],and after the transformation, we can apply an existing version control tool such as RCS and CVS to the transformed XML document.In fact,some of them such as Eclip UML[11],Jude[10]and Poi-don[12]have interfaces to CVS.However,this solution cannot achieve an integrated and amless support for de-veloping a diagram and for its version control,and the de-velopers should u two parated tools;a CASE tool and a version control one.And as far as RCS or CVS is ud, the management of versions is bad on the granularity of a line,not a logical component of a diagram.Some tools such as Rational Ro[13]and Konesa[14]include the“differ-encer”function[15],[16],which shows the differences be-tween the older version of the diagram and the current one, e.g.by highlighting different graphical components or by depicting in tree form the changed class appearing in a class diagram.The“differencer”holds a copy for each ver-sion of the product and not the differences between them. Thus it has a shortcoming that large amount of space in the repository is wasted.Furthermore,we have to construct a differencer for each type of Differencer for Class Diagram,Differencer for Sequence Diagram,etc.,and much effort in building a development environment is nec-essary.In[18],a technique of version control for diagrams was discusd.However,it regarded a diagram as a graph consisting of nodes and edges and it did not consider logical properties specific t
o the diagrams.The techniques to cal-culate differences on XML[20]and on complex objects[17] were studied.However,they did not discuss theflexible variation of the logical components that should be targets of version control.In addition,calculating directly differences between two diagrams or graphs has a rious problem of
Copyright c 2006The Institute of Electronics,Information and Communication Engineers
ODA and SAEKI:META-MODELING BASED VERSION CONTROL SYSTEM FOR SOFTWARE DIAGRAMS
1391
computation cost as will be mentioned in Sect.2.1.
We can summarize the current issues on version control of software diagrams mentioned above as follows:
1.The logical components in a software diagram such as
“Class”and“Association”in class diagrams should be units of version control.However,the current tech-niques are bad on lines of text documents.
2.Since logical components vary in software diagrams,
we should develop a version control system for each type of software a version control system for class diagrams,a system for state diagrams,a sys-tem for u ca diagrams,etc.In particular,in modern methods where multiple diagrams are in the method where a class diagram and state diagrams are ud,we should have a combination of version control systems for the multiple diagrams.
To solve the problems,we adopt an approach to gen-erate a version control system from a definition of a soft-ware diagram.The esntial point of our work is generating a CASE tool together with the functions of version control from a meta model reprenting a diagram.That is to say, we have developed a kind of meta-CASE tool generating the tools having version control mechanisms.Although we can consider other description techniques to define a software diagram,we u a meta modeling technique.The reasons are as follows:
1.We can extract logical components directly and easily
from a meta model.
2.We apply Meta CASE technology where we can gener-
ate a CASE tool from a meta model,in order to develop
a generator of version control systems together with a
CASE tool.More concretely,we simply embed a ver-sion control mechanism in a Meta CASE to implement the generator.
3.Like UML meta model,we have already had many
meta-model descriptions of various diagrams and can u them as inputs to the generator.
The rest of the paper is organized as follows.Sec-tion2prents the outline of the propod system and in-troduces our meta-CASE tool,a kind of CAME(Computer-Aide Method Engineering tool)[1].A meta modeling tech-nique to reprent diagrams is also shown in the ction. Section3describes the operations of modifying a diagram in order to reprent differences between versions.In Sects.4 and5,we prent the functions of version control and the illustration of the generated diagram editors with a version control mechanism,respectively.Section6is the conclud-ing remark with discussion of future work.
2.Generating Version Control Systems
2.1The Overview of Our Approach
In our version control system,we adopt a technique to store differences between two versions in a repository like RCS and CVS,etc.so that we can recover the older versions that were previously produced.In this approach,the state of the artifact at a certain time is considered as a baline, and the version control system stores the difference between this baline and each version to the repository.It has an advantage point where products are efficiently manageable.
When adopting an approach of storing differences,the techniques to define the differences between versions and to acquire them are necessary.To extract a difference effi-ciently,we focus on the developer’s activities of editing a diagram by using a diagram editor.In other words,we gen-erate the element of the difference from an execution of an editor operation such as“create”and“delete”a component. Suppo that a developer creates a new class in a class dia-gram by using Class Diagram editor.The execution of the editor operation“create a class”results in its addition to the difference data.The meta model of the diagram provides the information on what editor operations we should focus on, and we can specify operations such as“create”,“delete”and “update”a logical component appearing in the meta model. The quence of the editing operations that a developer is performing is acquired in real-time during his editing activ-ity using the editor.The acquired operation
quence can be considered as the difference between versions,and is stored in the repository.Our meta-CASE tool,which generates a diagram editor from the meta model description,should automatically embed the functions of acquiring performed editing operations in real-time and of transforming them to difference data,when it generates the editor.
We can take a different approach by calculating directly differences between two products using veral algorithms. However,in this approach,we calculate directly the dif-ferences between graphs,and its time complexity is O(n4) where n is the total number of the graph nodes[21].In this n,this approach is not so efficient to extract the differ-ences between software diagrams.One of the merits of our approach is that we can extract differences as quences of editing operations in real-time as the ur edits the diagram. On the other hand,the quences of editing operations can include uless operations to recover the version.This short-coming will be discusd in Sect.6.
Figure1depicts the overview of our approach.Arrows in thefigure stand for theflows of artifacts including a meta-model description,a generated modeling tool,and versions of a diagram to be controlled.As shown in thefigure,we have two types of engineers;a method engineer who is the expert of specifying meta models and a software engineer who constructs models of the software systems to be devel-oped.The method engineer us a method editor to ma-nipulate the meta mode
l and the method editor is a kind of diagram editor.The method editor adopts Class Diagram in order to describe a meta model.The details of the meta model will be explained in the next sub ction.Our meta-CASE tool automatically generates from the meta model, 1)an editor(a modeling tool)for supporting inputting and editing products,such as the editor of Class Diagram,and 2)the schema of a repository.That is to say,the meta model
1392
IEICE TRANS.INF.&SYST.,VOL.E89–D,NO.4APRIL
2006
Fig.1Overview of our generative approach.
rves as the schema definition for the repository to which the developed products are stored.Software engineers may develop a model of a software system by using the tools generated from the meta model.The functions of version control,who access interfaces are similar to CVS,are em-bedded into the generated diagram editors.
A software ,a ur of the generated edi-tor develops thefirst version of a model as a baline,and imports it to the repository.The engineer can check-out any version of the model that is stored in the repository,and edit them by using the editor.The editor gets the operation -quences on the model in real-time by monitoring the editor commands that were ud.The engineer can then check-in the current version of the product by storing operation quences as the difference to the repository whenever de-sired.
2.2Meta Models and Meta-CASE
An example of a meta model of a simplified version of u ca diagrams is shown in the left side wi
ndow of Fig.2. As shown in thefigure,the meta model“U Ca Dia-gram”has concepts“Actor”,“Association”,“UCa”and “System”and all of them are defined as class of the meta model.The concept“ModelElement”is their super class containing an attribute“name”,thus the instances of U-Ca,Actor,Association and System can have a name as-signed to them.The concepts(called method concepts) have associations(called method association)reprenting logical relationships among them.For instance,the concept “UCa”is associated with“Association”,so u cas can be connected with each other through instances of“As-sociation”class.This is for reprenting the relationships such as“us”and“extends”between u cas.We simply call both method concepts and method association method elements.The method elements can be the logical unit of version control.
In addition,we should consider constraints on the prod-ucts.For example,we cannot have different u cas hav-ing the same name in a u ca diagram.We can specify this constraint to keep consistency of the products,by using OCL(Object Constraint Language).For more details on the meta modeling technique plea refer to[1].
Our meta-CASE is only for generating diagram editors which deal with a product conceptually as a graph consist-ing of nodes and edges.Thus we should provide the infor-mation using which the meth
od concepts in a meta model can be reprented with nodes or edges of the graph.The method engineer provides two types of information:one is the correspondence of method concepts to the elements of des,edges,texts within the nodes and texts on the edges,and another is notational information of the nodes and edges.As an example,let’s consider that the en-gineer will generate a u ca diagram editor from a meta model of U Ca Diagram.The concepts UCa,Actor and System in the U Ca Diagram conceptually corre-spond to nodes in a graph,while Association corresponds to edges.The information is provided as stereotypes on the method concepts.Figure2includes the information for the meta-CASE as well as the meta model of u ca dia-grams.The readers canfind the stereotypes“<<entity>>”and“<<relationship>>”attached to the class in the meta model.The former stereotype stands for the correspondence to a node and the latter to an edge.For example,an occur-rence of a u ca in a u ca diagram corresponds to a node in the graph,while an association between u cas to an edge.Note that a generated editor automatically includes commands for creating and deleting the method concepts
ODA and SAEKI:META-MODELING BASED VERSION CONTROL SYSTEM FOR SOFTWARE DIAGRAMS
1393
Fig.2An example of a meta model and a
meta-CASE.
Fig.3An instance of u ca diagram.
corresponding to the nodes or the edges.
In addition,method engineer should specify whichfig-
ures,say a rectangle,a circle,an oval and a dashed ar-
row,are ud for expressing method elements on the editor
screen.We call this information notation model,while the
model consisting of method concepts and associations for
expressing its logical structure is called logical model.Basic
graphicalfigures such asfigures ud in UML diagrams are
built-in and their drawing programs are embedded as Java
class into our meta-CASE.A method engineer lects
thefigures out of the pre-defined built-infigures for the
<<entity>>and<<relationship>>components,by click-
ing a menu item,as shown in the right window Meta-CASE
of Fig.2.In the example of thisfigure,the method engi-
neer specifies a graphicalfigure for Actor as“ActorShape”
which is pre-defined and built-in shape in the system.The
meta-CASE produces a diagram editor by embedding the
above information and the Java class into a modeling tool
framework.The technique to generate a diagram editor is
out of scope of this paper and its detail is mentioned in[1].
Figure3illustrates an instance of a u ca diagram
含有羊的成语and shows how to store it following its meta model.As
mentioned above we have a logical model and a notation
model.The logical model has method concepts“U Ca”
and“Actor”,both of which have the information on their
“CreateElement”and“Developer”.They are
connected to the elements of the notation model having the
information on their locations and the graphical shapes on
the screen,as depicted with dotted arrows in thefigure.
All model elements included in logical models and notation
models that can be the targets of version control hold unique
identifiers called UUID[19],in order to keep their identities
in the repository.
3.Operations on Model Elements
In this ction,we discuss operations on the models to rep-
rent the differences between versions.The operations can
记叙文题目be classified into the following three categories:
•Operations on a logical model
They are for inputting and editing method elements on
the logical part of the meta ating and
deleting method concepts such as Class,State and As-
sociation etc.
•Operations on layout data of graphical elements
They are for changing the layout of graphical elements
on the display screen,such as moving and resizing a
rectangle denoting the class.The operations do not
琼美卡随想录
have any mantic influence on the model.
•Operations on a notation model
They are for manipulating the elements of the notation
model such as creating a node and deleting an edge etc.
The operations include the UUIDs as parameters so that
their target instances can be uniquely identified in the repos-
itory.In addition,the instances of the operations are la-
beled with unique UUIDs so that the version control system
1394
IEICE TRANS.INF.&SYST.,VOL.E89–D,NO.4APRIL2006
can identify them.
Tables1and2show the operations on the layout data
of the graphical elements and on the notation model respec-
tively.Thefirst parameter UUID of each operation is the
identifier of its instance.The control point in Table1is a
point where a ur can change the size of a graphical ele-
ment by dragging it with a mou.
Note that the delete operations such as Dele-
teEdgePickPoint and DeleteNode have the information on
the deleted elements as their parameters.For exam-
ple,DeleteNode operation includes location data x and y
which denote X-Y coordinates of the element on the dis-
play screen.This information is necessary to implement
Redo/Undo functions in the generated modeling tools.If
a ur deletes an element and the corresponding delete op-
eration does not have the X-Y coordinates of the deleted el-
ement,the tool cannot recover or put the deleted element on
the screen when Undo is invoked.Redo/Undo functions are
implemented using the operations,shown in the tables,in
辄止
the modeling tools.
Operations on layout data and on the notation model
Table1Operations on layout data.
私信面膜
Operations Definitions
Moving a control point MovePickPoint(UUID,sUUID,pID,dx,dy) Moving a control point labeled with pID in a notation model sUUID(dx,dy).
Moving a graphi-cal element MoveShape(UUID,sUUID,dx,dy) Moving a notation model labeled with sU-UID(dx,dy).
Inrting a ver-tex in a polygonal line CreateEdgePickPoint(UUID,eUUID,pID, x,y)
Creating a control point pID at(x,y)in the edge eUUID.
仔细反义词是什么
Deleting a ver-tex in a polygonal line DeleteEdgePickPoint(UUID,eUUID,pID, x,y)
Deleting a control point pID in the edge eU-UID.
Table2Operations on a notation model. Operations Definitions
Creating a node CreateNode(UUID,nUUID,Type,x,y) Creating a node of type“Type”at the posi-tion(x,y)on the screen,and labeling it with nUUID.
Deleting a node DeleteNode(UUID,nUUID,Type,x,y) Deleting a node labeled with nUUID.The deleted node had the type Type and was put at(x,y)on the screen.
Creating an edge CreateEdge(UUID,eUUID,Type,sUUID, dUUID)
Creating an edge of type“Type”and label-ing it with eUUID.The created edge is con-nected to the node sUUID as its source and to dUUID as a destination.
Deleting an edge DeleteEdge(UUID,eUUID,type,sUUID,
dUUID)
Deleting an edge labeled with eUUID.The
parameters sUUID and dUUID were the
明月升起
source and the destination of the deleted
edge.
are common to all diagrams,while operations on the logical
model are dependent on diagrams becau we have opera-
tions specific to method ating a Class for
Class Diagram and creating a State for State Diagram.We
extract the operations from a meta model focusing on its
method concepts.Furthermore,we have veral additional
operations to manipulate the relationships between a logical
and notation models,and to edit the texts of attributes of the
method concepts.For example,the following two opera-
tions are to create and delete a connection between a logical
model and a notation model.
ConnectShapeModel(UUID,nmUUID,lmUUID)
DisconnectShapeModel(UUID,nmUUID,lmUUID)
In the operations,nmUUID and lmUUID denote the el-
ements of the notation model and of the logical model re-
spectively.The connection between nmUUID and lmUUID
is established after executing ConnectShapeModel.
The following operation is for updating the texts of
the attributes attached to an element of a model.Up-
dateAttribute operation changes the attribute attrName from
preValue to newValue on the element lmUUID of the logical
model and/or the element nmUUID of the notation model.
UpdateAttribute(UUID,lmUUID,nmUUID,attrName,
newValue,preValue)
Any editing activity on a diagram through a modeling
tool can be defined as a combination of the operations.
In this n,the operations listed above are primitive and
atomic.Suppo that a software engineer creates a new class
and adds it to a class diagram.This activity compris1)
creating a class in a logical model of Class Diagram,2)cre-
ating a node(a rectangle)on a display screen,and3)con-
necting the class in the logical model to the node in the nota-
tion model.Thus we can have a quence of the operations
as follows.
1.CreateClass(UUID1,ClassUUID,anonymous)
2.CreateNode(UUID2,RectangleUUID,
ClassShape,30,20)
3.ConnectShapeModel(UUID3,
RectangleUUID,ClassUUID)
运筹帷幄之中
In the above description,UUID1,UUID2and UUID3are
unique identifiers denoting the three operations.Thefirst
operation creates a class on the logical model level and la-
bels it with ClassUUID,while a rectangle labeled with Rect-
angleUUID is created and put at the location(30,20)of the
screen in the cond operation.ClassShape is the type of
graphical ,a rectangle in this ca,which is pre-
defined in the meta-CASE.The last operation is for con-
necting the two components that have been created by the
previous operations.Note that thefirst operation Create-
Class has a third actual parameter“anonymous”.The oper-
ation CreateClass shall have the name of the created class
as its third parameter.In this example,the software engi-
neer does not input the class name of the created class yet,
ODA and SAEKI:META-MODELING BASED VERSION CONTROL SYSTEM FOR SOFTWARE DIAGRAMS
1395
but just put a rectangle for the created class on the screen. Thus“anonymous”is tentatively ud as the third parame-ter of the CreateClass.The parameter“anonymous”is ud as a tentative label of the created component who name is not input yet.When the engineer inputs a class name, e.g.ClassA,the operation UpdateAttribute(UUID4,ClassU-UID,RectangleUUID,name,ClassA,anonymous)is added to the above operation quence.
For each execution of an editing command of a mod-eling tool,a combination of the corresponding operations is automatically generated as an element of the difference.In addition,to detect the conflicts on merging branched ver-sions,the operations have pre conditions that should be true when they are applied,as mentioned later in Sect.4.4.
4.Version Control Functions
4.1Overview
By using our generated version control system,a software engineer has working spaces at his local site,and per-forms import,check-out and check-in operations between his working space and a repository.First,the engineer im-ports a product into the repository,thus registering the initial version of the product(a.k.a.baline).When the engineer checks out from the repository version n of a product,the working space for modifying it is allocated at his local site and the product is loaded into the working space.The en-gineer us the modeling tool to modify version n,and after completing the modification,it is stored as version n+1into the repository(check-in).
A method engineer starts a method editor and devel-ops a meta model of a diagram that software engineers will u.Then the engineer generates a modeling tool for the di-agrams specified with the meta model.The generated tool has menu commands for version control.The basic com-mands for version control are as follows:
import:for generating an empty working space and then loading a product as a baline.
check-out:for loading a product from a repository to the current working space.
check-in:for saving the product in the current working space as a new version back to the repository.
How to u the commands is illustrated in the subquent ctions.
4.2Acquiring Differences and Checking-In
Figure4illustrates how to acquire the differences between two u ca diagrams.Thefigure includes three layers;the upper one depicts instances of u ca diagrams,the middle and the bottom ones show their notation and logical models respectively.Note that for clarity we have simplified the identifier numbers of the elements to“id”instead of UUID.
A software engineer,a ur of the modeling tool for u ca diagrams,develops a u ca diagram as shown in the left side of the upper layer of thefigure and ts it as
a
Fig.4Acquiring diff
erences.
Fig.5An acquired operation quence. baline.The u ca diagram is then stored as version1 into the repository.Subquently,the following modifica-tions are performed and a new u ca diagram is obtained as shown in the right side of the upper layer of Fig.4.
1.Creating a new u ca.The default value is assigned
to the attribute value“name”,i.e.the name of the u ca,by the editor.
2.Changing the name of the new u ca to CreateEle-
ment.
3.Creating an association between the actor Developer
and the new u ca CreateElement.
The above quence of the modifications caus change of the attributed graph internally reprenting the u ca diagram and the version control system gets the operation quences sho
wn in Fig.5.For example,the modification activity of creating a new u ca in Compound(op1)of thefigure compris three operations:CreateNode in a no-tation model level,CreateUCa in a logical model level and ConnectShapeModel for relating the notation model to the logical model.The word“anonymous”appearing as the fourth parameter to CreateUCa is the default name of the created u ca.The cond operation UpdateAt-tribute is for replacing this default name with“CreateEle-ment”.Compound(id6)is for establishing an association between the actor and the u ca.
The ur can check-in the acquired operation quence
