"Automatic model transformations using extended UML object diagrams in modeling environments".

University Degree Mathematical and Computer Sciences

SC207 Software Engineering - Term Paper 2003

Automatic Model Transformations Using Extended UML Object Diagrams in Modeling Environments

Chathapuram V Satish

Year 2 Computer Engineering

Nanyang Technological University

[email protected]

TOPIC DETAILS

“Automatic model transformations using extended UML object diagrams in modeling environments”.

Author: Dragan Milicev

Source: Software Engineering, IEEE Transactions, Volume: 28, Issue: 4, Apr 2002, Page(s): 413-431

ABOUT THE AUTHOR

Dragan Milicev received the diploma degree in 1993, Msc degree in 1995, and PhD degree in 2001 all in computer science at the School of Electrical Engineering at the University of Belgrade, Yugoslavia. His research interests include object oriented software engineering, metamodeling and information systems. His personal webpage can be found at http://www.rcub.bg.ac.yu/~dmilicev.

INTRODUCTION

Modeling is a critical part of all the activities that are involved in the deployment of an engineering system. Modeling tools that provide an interface to implement, apply, check and visualize the modeling process are available and make the entire process less cumbersome and tedious. One of the most important features of the modeling tools is the automatic generation of an output and this is the main focus of discussion in the above stated paper. The output can be documentation, source code, net list or any other model created by the user. The problem relies on the automatic translation of problem domain1 to the target domain. Few solutions to this problem do exist and the evaluation of these methods is the other focus of the paper. The author also introduces his solution and introduces the concept called ‘domain mapping’.

RELEVANCE TO LECTURE TOPICS

This paper discusses the issue of output generation from object diagrams. Our software engineering course structure does not have any explicit module in output generation. Since creating object diagrams is a substantial part in the process of the out put generation, the following are related topics.

Object oriented Analysis: This module helps to identify objects from the client specification or problem statement.
Object Orientation – The Complete Picture: This module covers the basic object oriented topics like abstractions, polymorphism which are important considerations in generating an object oriented source code.

ELABORATION ON THE PROPOSED APPROACH

Background Information

A modeling domain is a conceptual space of modeling various systems from similar problem domains using a certain modeling language (e.g.:- UML). To describe this modeling domain we have a conceptual model called Metamodel. A metamodel is thus a model that describes a model. These metamodel can be described using basic object oriented concepts like classes, attributes, associations and generalization. In the past a grammar based specification technique was used but his paper focuses on the former method.

One of the earlier approaches is as follows. The user defines the problem domain say by using state machine diagrams. The user then specifies the metamodel for the output domain say a C++ source code. A modeling tool would then use the above information to generate a pseudo code which needs modifications. This method has drawbacks. Firstly the process of specification is tedious and the user needs to deal with the C++ syntax and semantics. The code generator is not reusable and modifications are difficult to apply.

Few revised techniques were developed to overcome the draw back of the earlier approaches but their success was only limited.

Proposed Approach

Since directing conversion between two distant domains has the same drawbacks as mentioned previously, this approach tackles the situation by creating intermediate models from domains of higher level of abstraction.

This intermediate model may be designed using the object-oriented concepts from UML, like attributes, class and method. These can then be converted into target C++ domain using the standard built-in C++ generators.

Though some modeling tools follow a similar procedure the proposed ...

This is a preview of the whole essay

Few revised techniques were developed to overcome the draw back of the earlier approaches but their success was only limited.

Proposed Approach

Though some modeling tools follow a similar procedure the proposed approach stands distinct. The usage of object oriented paradigm, higher abstraction levels and uses visual notations and hierarchical organization.

What is Domain Mapping?

The idea of domain mapping is the transformation from the source in to the target by using intermediate steps with mapping configurations between the steps. This helps to cope with the complexity of the mapping specifications

Fig 1: Illustration of Domain Mapping

Domain Mapping Specifications

The mapping between domains is specified in a hierarchy of packages, rooted with <<Domain Mapping Packages>>.

The packages contains instances and links.

The following are some concepts used in this technique:

Instances , Attributes and Links – links refer to the association between instances
Repetition - <<For Each>> package is used for repetitive element creation
Condition – addresses the issue of conditional element creation using the Cond keyword which specifies the conditional expression.
Sequences - <<sequence>> specifies the order in which elements need to be created.
Parameterized Substructures and Recursion - <<Substruct>> supports recursion of elements.
Polymorphic Substructures – analogous to polymorphism in OOP.

These concepts enable the development of mapping configuration.

RELATED WORK PUBLISHED

RELATION OF TECHNIQUE TO LAB PROJECT

This thesis focuses on the output generation from object diagram. In the lab project Rational Rose was used to model the program Domain. Detail class diagrams, sequence diagrams and collaboration diagrams were developed but for the generation of the code we had to depend on manual implementation. The rational rose does provide some output generation but our project required web form generation and database accessing. The approach proposed in this paper does work well any form of output even web forms and database manipulation. So, if such mapping components exist in the tool then they could have been reused and applied to our project scenario.

The generation of code from use-case and state diagrams is also possible with the necessary mapping components. The lab project could then have been development of the use cases, reusing and changing the mapping components (if already developed) to generate intermediate domain and then finally to the target domain.

But these are possible only if some of the mapping components and a detailed documentation of the proposed tool are available.

EXTENSION AND IMPROVISATION OF THE ARTICLE

These are some of the points that should have been included.

An report on the previous work done by the e author with regards to this topic should The background information is necessary to maintain the flow of argument and grasping of the concepts

Definitions of some of the terms rather than making a hint to the reference to refer. Some of the references might not be easily available to the reader.

More thorough evaluation of the drawbacks and how the present approach can overcome them should have been concluded
A detail theory of the proposed approach and having a separate section to explain the actual syntax and semantics of the proposed tool.

EXTENSION OF THE IDEAS

Illustration of the application of the model to the procedural language implementation.

Examples of multi level abstractions and domain mapping to different abstractions

Address concurrency related scenarios

COMMENTS ON THE NOTATIONS\DIAGRAMS

The diagrams used in the thesis are relevant and reinforce the concept explained.

Fig 1: The figure clearly illustrates how earlier tools generate output from the state machine.

Fig 2: The diagram illustrates the domain mapping strategy but is a bit misleading and confusing. A detailed text to explain it or a simpler illustration will do the needful

Fig 3: Illustrates the mapping specification generation aptly and clarifies numerous queries about the procedure

Fig 6, 7, 8, 9, 10: Provide a diagrammatic explanation of the Domain mapping specification explained rather abstract in the text.

Fig 14: The diagram is too abstract and detailed. It conveys too much data to be assimilated. A simplification or splitting in to two figures with more additional items will make it more comprehensible.

Fig 15a, b: Sample generated c++ code is displayed. The figure enables the reader to view the actual code generated, verify it and emphasis the potential strength of proposed approach

VALIDATION OF THE PROPOSED IDEA

The author has 3 examples through which he explains the application of his approach. The examples are

Object Oriented to Relational Transformation - the source domain is the case in the UML and the target is SQL declarations.
Web Application Development – The UML object diagram is transformed to web forms (HTML and queries).
Automatic Implementation of Structural Use-cases – Transformation of the structural use-cases to Webforms.

In all of the above three examples the author gives a detail explanation of the application of the approach. The diagrams illustrate the initial models, intermediate and final models and are concurrent with the explanation.

In addition, the author has included a case study. Three cases are discussed wherein the author has three undergraduate students to implement their final year projects using the proposed approach. The first project dealt with OOPL domain, the second ROOM and the final one with hardware logic design. The students completed the implementation in much fewer days than with the traditional technique; one project that took 10 days to complete using traditional methods was finished in three days. In addition the students had little problem mastering the procedure and had no prior knowledge in the meta modeling and domain –specific modeling.

This undoubtedly signifies that the proposed approach is indeed a practical, correct and highly effective approach to solve complex problems in software engineering.

NEW CONTRIBUTION TO SOFTWARE ENGINEERING

Thus, this paper discuss a solution that is based on the idea of specifying the problem domain in the form of Object diagrams using UML and uses the technique of domain mapping to convert it into intermediate models and finally into a C++, web forms or any other model specified by the user. The proposed approach can be used to provide output specifications (type of output required by the user) in modeling tools (e.g.:- Rational Rose, CASE tools) that allow customizability. For those tools that do not allow this, this approach can be used by the developers in designing the tool. This approach allows different level of abstractions (class is an example of abstraction) and provides the developer more flexibility by allowing more abstractions to be built over the existing ones. These abstractions can be stored and reused by other developers and users.

The user also need not deal with object oriented programming as the specifications to convert can be reused from the repository provided in the tool. The object diagrams can be extended with concepts of conditional, repetitive, sequential, parameterized and polymorphic element creation. These are some of the necessities for an object oriented program.

Some of the drawbacks are a higher level complexity required even to address a simple problem, concurrency related issues are not resolved, reusability cannot be taken for granted as some operations are language dependent etc:-. These issues are been addressed in the future work. This approach surely has proven that two conceptually different models can be bridged together effectively.

References

[1] D. Milicev , “Automatic Model Transformations Using Extended UML Object Diagrams in Modeling Environments”, Technical Report - T1-ETF-RT1-00-0042,Univ. Belgrade, School of Electrical Eng., Oct 2000,also available at http://www.rcub.bg.ac.yu/ ~dmilicev.

[2] JM Neighbors,” The Draco Approach to constructing software from Reusable Components “,IEEE Transaction Software Eng.,Vol. 10, no.5 , pp. 564-574, Sept 1984

[3] MetaModel.com, Metamodeling Glossary, http://www.metamodel.com,1999

[4] “Response to OMG RFPad/98-11-01: Action Semantics for the UML” version 16, http://www.omg.org, Sept. 2000.

[5] B.selic, G.Gullekson, and P.Ward, Real-time Object Oriented Modeling. John Wiley and Sons, 1994

[6] Ian Sommervile, Software Engineering, Pearson Education, 2001

[7] Rational Software Corporation, Rational Rose,http://www.rational.com,1998

Glossary

UML – Unified Modeling Language

OOP – Object oriented programming

OOPL - Object Oriented Programming Language

ROOM – Real Time Object Oriented Modeling

Appendix

problem domain1 – refers to the conceptual space of the particular problem being solved by a concrete application or system

modeling domain – refers to the conceptual space of modeling various systems from similar problem domains using a certain modeling language, with defined syntax and semantics for that language.

"Automatic model transformations using extended UML object diagrams in modeling environments".

This is a preview of the whole essay

Document Details

Related Essays