Re: [SrcML] UML2.0 representition

[Frank R. <fra...@in...>]

On Fri, May 20, 2005 at 10:06:58AM +0200, Claudia Lang wrote:
> as I mentioned in the latest meeting I'm going to implement a project representing XML-Code in UML2.0 The chosen language for this project is Java and the name of the project XUML. 

After a quick google for XUML I think you might want to use another name, as
XUML is already heavily used for eXecutable UML (there also seems to be a book
available on this subject).

> The XML-Code which shall be represented in UML2.0 is handed over to the software project by executing it. The user can start the project by the BASH typing the name of the project followed by the XML-Files. I know so far SrcML is running just under Linux. Linux users don't like GUIs so much. Nevertheless I will also implement a  simple one. Maybe some day there will be a Windows version of SrcML. In this GUI the files can be chosen by clicking on them. 

SrcML is written in Java and runs on all platforms which support Java. This includes
Windows, but of course it's a little bit harder to setup a development environment.

> UML2.0 includes 13 different kind of diagrams. For it's to much for a single person to implement a project supporting all of these I concentrate on one diagram: the ClassDiagram. It is seen as the foundation on which all the other diagrams - behavior diagrams and the rest of the structured diagrams - build.
> 
> It is not possible to realize all of the notations which can be uses in ClassDiagrams in Java and thus in SML. So the followed notations will not be represented by XUML:
> 
> - template class: exists in Java since version 1.5 but SrcML parses Java version 1.4.2

Actually only 1.3, but I'm currently working on a parser for version 1.5 which
should become useable within a few weeks. (Only annotations and enums are currently
missing).

> - association and association class

What are you reasons for not including associations? Simon and me thought that it
should be possible to add aggregation relations, but we haven't yet thought about
all eventualities of course.

> - stereotype

Could you please explain what this means in the context of class diagrams?

> Before I can go on and finish the requirement phase I need some answers on the following questions:
> 
> - which kind of classes doews SrcML realize? Embedded abstract classes and also interfaces? How does SrcML handles the import of packages? Does SrcML realize user specified types?

If you mean 'embedded' as in inner classes, then yes. Abstract classes are supported
too, and also interfaces. Package import is showing up in SrcML as something like this:
<import package="java.util.Vector"/>

SrcML does not (yet :) have a type inference engine. But we do have type information
at those points where the original program's source code has explicit types. This means
you can get the types for variables and parameters and the like, but you can not find
out the result type of an expression. But I think for the purpose of generating a class
diagram the existing type information should be sufficient.

> - maybe somebody can send me a SrcML document as an example?

You should have created one for yourself as part of the 'zeroth' practice and
if you didn't do so yet I suggest you set up a proper environment where
you are able to parse java files into SrcML files. You will definitely need
to parse several files during the course of this practical in order to test
your application.
If you have any problems with the installation just show up in the linux pool
and ask us.

> - so far it is also not clears whether the ClassDiagram shall be saved as a Visio or an XMI file. I've googled for some interresting document telling more about XMI but without any success. Also the book shops have no books dealing with XMI. Maybe you can recommend a link or a book?

Here's a rather informal introduction:
http://www.jeckle.de/xmi.htm

And here's the formal specification of XMI 2.0:
http://www.omg.org/cgi-bin/doc?formal/05-05-01

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

In the world of systems design, programs and data are the scissor blades
working together to form the broader class -- software. Lacking either blade,
computers couldn't cut through problems -- yet for many people, software is 
synonymous with programs. (Tom Gilb)