Syntactic Modeling of UML Diagrams and Their Automatic ... - CiteSeerX

Syntactic Modeling of UML Diagrams and Their Automatic Transformation into RDBMS based Models A. Musto, G. Polese, G. Costagliola (IEEE Member), and G. Tortora(IEEE Senior Member) Dipartimento di Matematica e Informatica, Universita di Salerno, Via S. Allende, 84081 Baronissi (SA), Italy, email: musto,giupol,jencos,jentor @dia.unisa.it f

g

January 26, 2001

Abstract

We present a syntactic model of UML diagrams that can be used in conjunction with automated visual language compiler generation tools to generate a visual compiler and a syntax driven editor for them. This also allows us to de ne new software development processes based on UML notations and to rapidly generate prototype C.A.S.E tools supporting them. Indeed, we have de ned a software development process that uses object oriented analysis and design based on UML models and that re nes object models into RDBMS based models and applications. In particular, we have de ned inference mechanisms exploiting the data structuring information and the dynamic models produced during the object oriented modeling phases to infer an appropriate relational data schema and the associated manipulation mechanisms. Moreover, we have used a visual language compiler generation tool supporting our syntactic model to rapidly generate CASE tools supporting the new process.

1 Introduction Nowadays there is still an high demand of compatibility between new object oriented development methodologies and traditional DBMS platforms. In fact, in spite of reduced modeling capabilities, traditional RDBMSs oer the advantages of a widely used technology. On the other hand, the object oriented paradigm has the potential to improve many aspects of the software development process, including a more eective maintenance and reuse of existing applications. An attempt to exploit the strength points of both the object and the relational paradigm has been made in the OMAR methodology [5]. This methodology uses object oriented speci cation and design, but it prescribes the re nement of the object models into relational applications. In this paper we describe a syntactic model of UML diagrams, namely the Extended Positional Grammars [2]. The model can be used in conjunction with the visual language compiler of compiler VLCC [3] to rapidly generate a compiler and a syntax driven editor for the UML diagrams. This also allows us to rapidly implement new transformations of the diagrams by specifying semantic routines in VLCC. In this way we can easily implement new software development processes based on the UML diagrams, including the associated CASE tools. In this paper we show how we have used Extended Positional Grammars and VLCC to implement the UML based process of the OMAR methodology and the corresponding CASE tools. The paper is organized as follows. In Section 2 we brie y recall the concepts of the OMAR methodology. In Section 3 we describe Extended Positional Grammars, whereas in Section 4 we describe their use to generate OMAR front end CASE tools through VLCC. Finally, a brief discussion is given in Section 5.

2 The Development Process with OMAR The OMAR methodology supports the development of RDBMS based applications starting from object oriented speci cations. It allows a designer to build large systems by using object oriented design methodologies and to generate a prototype of the whole relational application. The OMAR development life cycle is depicted in Figure 1. The mapping from object to relational models is realized through special inference mechanisms that capture and process the information contained within static and dynamic diagrams of UML to derive an appropriate structuring of a relational data schemas,and the associated manipulation code [5]. In particular, the information stored within class diagrams is used to derive the tables. The remaining 1

OO Analysis & Design

PC++ code OO schemes

PC++ Programming Static OO Architecture & Design Schema

PC++ constructs C++/SQL C++/SQL code

code

RDBMS

ODBC

OOP

Figure 1: The OMAR development life cycle diagrams are exploited to analyze the dynamic behavior of the system, which provides heuristics on how to re ne the relational data schema to meet the data navigation requirements of the system functions, and it is also used to derive the manipulation code.

3 A Syntactic Model of UML In this section we present Extended Positional Grammars as a syntactic model for UML diagrams. An Extended Positional Grammar is the pair (G, PE), where PE is a positional evaluator, and G can be seen as a particular type of context-free string attributed grammar (N, T, POS, S, P) where N is a nite non-empty set of non-terminal symbols, T is a nite non-empty set of terminal symbols, POS is a nite set of binary relation identi ers, S is the starting non-terminal symbol, P is a nite non-empty set of productions of the following format: A : x1 R1 x2 R2 :::: xm ;
; ? where A is a non-terminal symbol, x1 R1 x2 R2 :::: xm is a linear representation with respect to POS where each xi is either a terminal or non terminal symbol, and each Rj is partitioned in two subsequences of spatial relations. The rst subsequence contains Driver relations, whereas the second one contains Tester relations. Driver relations are used during syntax analysis to determine the next symbol to be scanned, whereas tester relations are used to check whether the last scanned symbol (terminal or nonterminal) is properly related to previously scanned symbols.
is a set of rules used to synthesize the values of the syntactic attributes of A from those of x1 R1 x2 R2 :::: xm ; ? is a set of triples (Tj ; Condj ;
j ), used to dynamically insert new terminal symbols in the input sentence during the parsing process. In particular, Tj is a terminal symbol to be inserted in the input sentence; Condj is a pre-condition to be veri ed in order to insert Tj ;
j is the rule used to compute the values of the syntactic attributes of Tj from those of x1 R1 x2 R2 :::: xm . Informally, a Positional Evaluator PE is a materialization function which transforms an internal representation of a visual sentence into the corresponding external representation.

4 Constructing OMAR Front-End CASE Tools through Visual Languages This section shows how the Visual Language Compiler of Compiler (VLCC) [3], [4] has been used as a meta-case for generating OMAR front-end CASE tools. VLCC is a grammar-based system that can support the implementation of graphical objects, syntax, and semantics of many types of visual languages.

4.1 A Visual Grammar for UML Diagrams

In this section we describe how the syntax of UML diagrams has been modeled through an extended positional grammar, which has led to a VLCC implementation of UML. This allows a more exible utilization of UML, since it gives the possibility to customize the visual notation and the rules for mapping the UML diagrams to lower level models. 2

Class-name

CLASSPEC

CLASS

Figure 2: Class Speci cation tokens. A class-name

class-name 1

attributes

1

CLA

2

1

attributes

package

CLAA

2

D

2

PACKAGE

2

C roleA

1

1

CLASSIFI

2

CLASSDIN

2

1

1

EREPUB

EREPRI

roleB

1

cardB 1

AGGREGAT

CLASSCOM

2

roleA

2 cardA

roleB

cardB 1

COMPOSIT

1 HAS

2

1 EREPRO

2 cardA

1 DEPEND

Figure 3: Class Diagram tokens. The VLCC system architecture includes two main modules:  the Parameterized Grammar Editor (PGE), and  the Visual-Programming-Environment Generator(VPEG). PGE is a parametric system that can be con gured to create and manipulate graphical components in a given visual-language class, G. PGE provides the language designer with editors to de ne speci c visual grammars in the G class. Moreover, PGE derives the corresponding extended positional grammars in YACC-like format. VPEG inputs the grammar speci cations produced by PGE and generates an integrated visual programming environment containing a compiler and a visual editor for the de ned visual language. We have used VLCC for the automatic generation of the visual programming environment of the UML visual notations [1]. As an example, it is presented a sample of productions from the extended positional grammar for the Class Speci cation language of UML [1]. The Class Speci cation language describes the objects, the classes, the types and the relationships that are in a class diagram. Conceptual aspects and software interfaces are considered, whereas implementation aspects are considered in another part of the UML language, the Implementation Class Diagram Language. Class Speci cation is composed of "Class Identi cation" and "Class Diagram Speci cation". Class Identi cation speci es any system class and any system type. Class Diagram Speci cation conceptually speci es the existing relationships between classes and the class classi cations. Therefore, we have implemented the grammar for Class Speci cation that includes three grammars: one for Class Identi cation, one for Class Diagram Speci cation and one comprehending the preceding grammars.

4.1.1 Token Identi cation

The process of tokens identi cation and their syntactic attributes leads to 



Class Identi cation tokens: { CLASS with the "cointained in" syntactic attribute shown in Fig. 2; { CLASSPEC with the "Annoted" and "Contained" syntactic attributes shown in Fig. 2. Class Diagram Speci cation tokens are shown in Fig. 3. Their syntactic attributes specify points and regions sensitive to the link attachment. In the Fig. 3 they are shown boldface and numbered.

In particular, it is possible to associate a visual sentence of a Class Diagram Speci cation to the CLASSPEC token. CLA from Figure 3 and CLASS from Figure 2 may contain class names or types of data. CLAA from Figure 3 only contains abstract class names. 3

4.1.2 Production Generation

In most cases, if a visual language has tokens and relationships recognizable with VLCC then it is possible to construct a YACC-type grammar for the language. A sample of the productions for the Class Diagram Speci cation language is the following: (1) nal : CLASSPEC ANNOTED classdia | CLASSPEC ; (2) classg : CLAA
= classgR1 = CLAAR1 ; | CLA
= classgR1 = CLAR1 ; ; (3) claiter: classg
= claiterR1 = classgR1; claiter' R1 1 ; R1 2 ere R2 1 ; R1 1 Classg'
= claiterR1 = classgR1; ? = (Classg; ClassgR1 != 1; ClassgR1 = Classg'R1 - ereR2) | claiter R1 2 ; R1 1 ere R1 1 ; R2 1 Classg'
: classiterR1 = classiter'R1 - ereR2); ? = (Classg; ClassgR1 != 1; ClassgR1 = Classg'R1 - ereR1) ; (4) claiterc: claiter
= claitercR1 = claiterR1; ; (5) claiter2 : claiterc
: classiter2R1 = classitercR1; | claiterc R1 1 ; R1 2 rhas R2 1 ; R1 1 Classg'
: classiter2R1 = classitercR1 - rhasR1); ? = (Classg; ClassgR1 != 1; ClassgR1 = Classg'R1 - rhasR2 ) | claiterc R1 2 ; R1 1 rhas R1 1 ; R2 1 Classg'
: classiter2R1 = classitercR1 - rhasR2); ? = (Classg; ClassgR1 != 1; ClassgR1 = Classg'R1 - rhasR1 ) ; (6) claiter3 : claiter2
: classiter3R1 = classiter2R1; ; (7) claiter4 : claiter3
: claiter4R1 = claiter3R1; ; (8) claiter : claiter4 ANY classg
: claiterR1 = classgR1; ; (9) classdia : claiter4
: claiterR1 = classgR1; ; (10) classdia : claiter4 | category ; (11) ere: EREPUB | EREPRI | EREPRO
: ereR1 = ERE R1 ; ereR2 = ERE R2 ; ; (12) rhas: AGGREGAT | COMPOSIT | HAS
: RHASR1 = R1 ; rhasR2 = R2 ; ; h

i

f

g

f

g

f

g

i h

hh

ii

hh

f

i h

ii

g

f

j

hh

j

i h

g

ii

hh

i h

f

ii

g

f

j

j

g

f

g

f

g

hh

i h

ii

hh

i h

f

f

j

hh

j

i h

g

ii

hh

i h

f

j

j

g

f

g

f

g

h

i

f

g

f

g






f

ii

g

f

f

ii

g
















g

g

Fig. 4 shows how to recognize a class diagram through the extended positional grammar above. In particular, Figure 4 (a) shows the initial class diagram, two dashed ovals indicating the handles to be reduced, and the productions to be used in the reductions. By applying production 2, the CLA token 4

production 2

production2, 3, 4

production 12

class 1

class 2

claiterc

classg

class 3

class 3

(a)

(b)

production 5

claiterc

rhas

classg

claiter4

classg

claiter production 3 ere

production 8 class 3

class 3

(c)

(d)

classg

(e)

final

(f)

Figure 4: The reduction process for a Class Diagram. is reduced to the non-terminal classg. Due to the
rule of production 2, classg inherits all the connections of CLA token. Similarly, the application of production 3 substitutes the non-terminal classg with the non-terminal claiter and the application of production 4 substitutes the non-terminal claiter with the non-terminal claiterc. Moreover, by applying production 2, the second CLA token in Fig. 4 (a) is reduced to the non-terminal classg and by applying production 12, the HAS token in Fig. 4 (b) is reduced to the non-terminal rhas. Figure 4 (c) shows the resulting generalized sentential form and the handle for the application of production 5. The symbols claiterc, rhas and classg' are then reduced to the new non-terminal claiter2. Due to the
rule of production 5, claiter2 is not connected to any node. Moreover, due to the ? rule, since |classg|=2 ! =1, a new node classg is inserted in the input and connected to all the remaining edges attached to the old classg (classg'). Figure 4 (d) shows the resulting generalized sentential form. After the application of productions 6 and 7 the non-terminal claiter2 is substituted with the non-terminal claiter4. From here, production 8 reduces the non-terminal claiter4 and classg to a new non-terminal claiter. By applying the
rule of production 8, the new claiter inherits all the connections to classg (see Figure 4 (e)). The subsequent application of productions 11, 3, 4, 5, 6, 7, 10, reduces the original class diagram to the non-terminal classdia. Because the non-terminal classdia is in CLASSPEC token, by applying production 1 it is reduced to the starting symbol in 4(e).

4.2 Semantic Routines for Generating PC++ Code

The OMAR methodology relies upon and intermediate object relational representation of programs, namely the PC++ representation. PC++ extends the C++ language with abstract mechanisms to cope with persistent classes and objects to be stored and manipulated through relational DBMSs [5]. Therefore, UML diagrams in OMAR are transformed in PC++ representation. The semantic routines to generate PC++ code from UML diagrams are inserted within YACC like les generated by VLCC. An example of semantic routines included within the Class Speci cation language is the following: classg :

| f






CLA *syntactic attributes valutation* if ( ag lista==0) list==MakeList(); node=MakeNode("",","); Persistent(node, $1 GetTxtDirect(1)); Mlist=ParseMemberString($1 GetTxtDirect(2), out); node=MemberListInsert(node, Mlist); f

!

!

5

list=TailInsert(list, node);

ag list=1; g

else f

node=SearchClass(ClassName($1 if (node==NULL)

!

GetTxtDirect(1)), list);

f

node=MakeNode("",","); Persistent(node, $1 GetTxtDirect(1)); Mlist=ParseMemberString($1 GetTxtDirect(2), out); node=MemberListInsert(node, Mlist); list=TailInsert(list,node); !

!

g g

........... ;

g

With this semantic routine, the C++ SearchClass(ClassName($1!GetTxtDirect(1)),list) function checks if it already exists a node for class-name class. If it doesn't exist then it is created by the C++ MakeNode() function. This list node contains information about class name, the persistency and class members. This check is necessary to avoid that same information is stored more times because of tokens reinstate technique in visual grammars. VLCC creates istances of the LToken class to store and manipulate all graphic symbol information (included textual information). The C++ ParseMemberString(string) function analyzes this information to distinguish the information necessary to generate appropriate PC++ code.

References

[1] G. Booch, I. Jacobson, J. Rumbaugh, "The Uni ed Modeling Language Reference Manual", Addison Wesley, 1999. [2] G. Costagliola, G. Polese, "Extended Positional Grammars", Proceedings of 2000 IEEE International Symposium of Visual Languages , Seattle, WA, USA, 10-13 September 2000, pp. 103-110. [3] G. Costagliola, G. Tortora, S. Ore ce, A. De Lucia, "Automatic Generation of Visual Programming Environments", IEEE Software, vol. 98, no. 3, March 1995. [4] G. Costagliola, P. D'Ambrosio, G. Polese and G. Tortora, "A Visual Language Based System for the Ecient Management of the Software Development Process", in Proceeding of IEEE Symposium on Visual Languages - VL97, Capri Island, Italy, 1997. [5] A. Musto, A. Pannella, G. Polese, G. Tortora, "Automatic Generation of RDBMS based Applications from Object Oriented Design Schemes", Proceedings of ACM SAC2000, Como, Italy, 2000.

6