Browse Prior Art Database

Transformation of UML diagrams to text in natural language.

IP.com Disclosure Number: IPCOM000130330D
Original Publication Date: 2005-Oct-20
Included in the Prior Art Database: 2005-Oct-20
Document File: 4 page(s) / 116K

Publishing Venue

IBM

Abstract

Actually, Unified Modeling Language (UML) is the formal language generally adopted to visualize, specify, construct, and document the artifacts of a software system. Several tools are available on the market to support software engineers in building UML diagrams. In some cases, those tools reduce the engineer?s work and give the possibility to view the system from different perspective. In fact, they provide facilities of converting of class diagrams to skeleton code (round-trip facility), mapping of logical data models to database specific physical model, automatic switching from a type of diagram to another (i.e. sequence diagram to collaboration diagram), and so forth. Although research in this area is going on, no tool is currently known to transform a software description expressed in UML to text in natural language. Such a system may be convenient for example to automatically produce user?s manuals or software documentation (high level or low level) for those individuals who are not able to understand UML. Actually, the classical procedural programming approach is not suitable to be applied to this specific application domain. The methodology described into the next session addresses the transformation of some UML artifacts to text in natural language by leveraging on the concept of ontology familiar in disciplines like data mining and artificial intelligence.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 4

Transformation of UML diagrams to text in natural language.

The main idea is to use an ontology describing the meaning of the UML artifacts to infer the textual description of the diagrams. For simplicity, only sequence diagrams will be considered in this paper. However, the technique can be also applied to all the other UML diagrams by constructing the appropriate ontology.

Let's consider the sequence diagram in Figure 1 showing an execution flow of a software deployment system.

: Release Manager

: Software Deployer

: Dependency Checker

1 : deploy software ( software instance )

2 : check dependencies ( software instance )

3 : perform deployment ( )

Figure 1

A possible ontology summarizing the description of a generic sequence diagram can be expressed by means of the following ISA hierarchy (taxonomy) and relationships (inferences are omitted for simplicity).

ISA Hierarchy

Actor Boundary Control Entity

UML element

Swim lane element

Message

Message paramenter

Re lati on

Arg. #1
(X)

Arg. #2
(Y)

Arg. #3
(Z)

Arg. #4
(P)

Constraint s

Text

1

Page 2 of 4

The (X) asks the
(Y) to execute the operatio n (Z)

invokeOperatio n

Swim lane element

Message

Swim lane element

none

X <> Y

Message none X = Y The (X) execute s the operatio n (Z)

PassData For simplicity, only operations, which take as input at most one parameter, are considered. The method can be easily generalized to include operations with more than one input parameter.

invokeOperation Swim lane element

Swim lane element

Message

none

Swim lane element

Swim lane element

Message paramete r

The (X) provides
(Y) with the (P).

A text builder can basically navigate the sequence diagram from the first message to the last one trying to instantiate the relations (using the ISA hierarchy) in the order they are specified into the relationship table. In applying the technique to other diagrams, which does not foresee any navigation order, it is possible to leverage on concepts, specific to the diagram, for having a sort of navigational guide. Specifically to class diagrams, a main class may be firstly identified (i.e. looking at a sequence diagram that involves the class in the first steps); hence, relations to other classes may be browsed iterating navigation on each of the related classes.

The navigation produces a sequence of relation instances, as follows:

1. invokeOperation(Release Manager, Software Deployer, deploy software);
2. passData(Release Manager, Software Deployer, deploy software, software instance);
3. invokeOperation(Software Deployer, Dependency Checker, check dependencies);
4. passData(Software Deployer, Dependency Checker, check dependencies, software instance);
5. invokeOperation(Software Deployer, Software Deployer, perform deploy);

2

Page 3 of 4

Substituting the sequence of relation instances with the text associated to each relation into the table the following description of the diagram is obtained:

"The Release Manager asks the Software Deployer to execute the operation depl...