.: OSM - Brief user guide :.


OpenSoul Metamodeler project

What is the OpenSoul Metamodeler (OSM)?
It is an open source MOF based metaCASE tool. It's currently under development and you can download PreAlpha version. MetaCASE tool can be characterized as a CASE that is not bound with one modeling method or language. You can create your own modeling method and adapt the metaCASE tool to understand that method. Process of your own method creation involves these steps: create theoretical background, model method metamodel, representation metamodel (graphical, hierarchical, attributes grouping, etc.) and define constraints. Finally the metaCASE tool will look like standard CASE tool, but driven by your own ideas.

Who and what is in the background?
OSM project is developed by a small team of students and lecturer from Prague University of Economy - IT department. OSM is developed in Java and it is based on MOF, OMG standards, JMI, Netbeans Meta Data Repository, JGraph components and W3C standards. We are inspired with some existing CASE and metaCASE tools like MetaEdit+, DOMEArgoUML and Poseidon for UML, Corporate Modeler, etc.

Where can I find more information?
Project is hosted on SourceForge and there is all interesting information. Right now most information is in the CVS repository. In future you can find some info also in the file release part and other categories. For closer constituency look at the MeTaTéMa pages and private OSM Project pages.

What are the future targets?
In future OSM will be the main part of OpenSoul project that aims to be a platform for sharing metamodels and models for free between the metamodeling community members. OSM itself will be fully developed metaCASE application contains metamodeling, modeling, documentation, code generation, inter-model and other tools :)

You can download executable binaries from SourceForge or source codes from CVS. Binaries are distributed in two variants.
  1. binaries zip package - contains OSM files, example models, all used third party tools, etc.
  2. complete zip package - contains all files from binaries zip package plus sources and javadoc

Installation is easy process now. Unpack the downloaded zip file anywhere you can. If you download incremental package, unpack it and replace previous OSM files.

We assume that you have some Java Runtime Environment (JRE version 1.4 or upper) installed on you machine.

Execute application
It is as easy as the installation. If you have properly installed JRE, simple execution of the OSMetamodeler.jar works fine in most of cases. If not, you can use this or similar command:

<java_bin_directory>java -jar <OSM_directory>OSMetamodeler.jar


java -jar OSMetamodeler.jar (if you have java in system path and you are in OSM directory)

Manage repositories
What storage place for models do we use? OSM uses MDR (Meta Data Repository) as storage for all models and metamodels. MDR is the key component of the OSM. MDR is a center point for all other OSM components. It uses JMI standard for accessing the objects stored in the repository.

Why MDR? It is only one open source repository based on MOF, JMI and XMI standards. Secondly, thanks to our lecturer we are in touch with MDR developers. MDR has this main features:

  • based on Java, MOF, JMI and XMI standards
  • fully described architecture
  • MOF metamodel instantiation support
  • pure meta repository (you can theoretically add your own instantiation routine)
  • event handlers
  • XMI export, import
  • JMI interface generation
  • additional indexing support
  • detail information on MDR web site

Repository types - you can create three types of repositories. Each type of storage is described bellow:

  • BTree - native MDR persistent storage format. It is a special solution that stores the data into the two files *.btd (data file) *.btx (index file). For transaction it uses *.btb temporary file. Big disadvantage is that this solution doesn't work for collaborative work. Only one user can open repository at a time.
  • JDBC - extras storage format added into the MDR project by J.V.Sichi. It isn't contained in standalone distribution of the MDR. It can store data in the relational database which has JDBC driver (PostgreSQL and MySQL has been already tested). You can manipulate with objects in the repository in the same way as using BTree storage. But the most important is that you can share one repository in team and access the remote repository.
  • Transient - it's only for testing purposes. It creates a temporary repository in the memory. It doesn't work without troubles.

Export and import - without connection on other CASE tools OSM will be nothing. We always try to apply common known standards to meet this request. OSM uses XMI standard (and UML2MOF tool) for collaboration with other tools. You can export any package contents from repository into the XMI file and import any XMI file into the existing package by analogy.

Manage repositories - Repository can be created/opend by using the buttons on main OSM toolbar or from popup menu after right click on "OS MDR Manager" node in tree view. For mounting the BTree storage you have to type full path to repository file *.btd. If you use JDBC storage you have to specify complete connection string (OSM helps you a little). When repository doesn't exist, OSM tries to create the new one in both cases. You can start, commit and rollback transactions on each repository manually from right click popup menu. MDR Manager allows you to open more than one repository at a time. To close repository use right click popup menu or "Unmount all" button on main toolbar. No support for deleting repository is available now.

From MOF metamodel to your own CASE tool
Whole metamodeling and modeling process (in OSM way) is described on picture bellow.

What is the metamodeling?
Metamodeling is creation of the metamodels which can be used as base for improvements in existing or creating new modeling methods. In our scope we distinguish four layers. This classification is really important in further text.

  • M3 - meta-metamodel - this is the MOF metamodel (definition of the MOF - it's the ancestor of the all metamodels and models stored in the repository, only one fixed point in OSM)
  • M2 - metamodels - this is the metamodel designed in MOF (metamodel definition e.g. UML metamodel, ERD metamodel, CommonKADS metamodel, etc. - it's the ancestor of all user models in the repository)
  • M1 - models - this is the model driven by your own method (e.g. UML model, ERD model, XML model, etc.)
  • M0 - information - this is the instance of the model (step after using CASE - e.g. program sources, data files with modeled structure, etc.).

What is the structure of the OSM repository?
As we have already said, the top of pyramid is the MOF metamodel (M3 - "MOF" only in "admin" node). The Representation (M2) and Visual metamodel (M1 - from OSM user view) are based on it (these models are visible only in "admin" node). Your own structural metamodel (M2), has the same name as repository, is based on MOF too. Representation models (M1 - but from OSM user view it looks like M2) are based on Representation metamodel. And finally the models (M1) are based on structural metamodel and affect by appropriate representation model. Diagram models (M0 - because they are data for OSM user) serve as repository for diagrams layouts. You can see complete picture of this structure bellow. Arrow shows instantiation (creating model from metamodel) used in OSM. From another view you can see that the blank entities are system repository models, the green ones are metamodel definition and the yellow ones are models based on "green" definition.

Create new repository
First step is the creation of new repository. You can choose storage type as described upper. The easiest way is to create BTree repository. Click on button with white cube in OSM main tool bar, select repository path and file name and click on "Mount BTree repository" button. It takes a while depends on your machine. OSM create clean repository which contains base MOF metamodel (M3), admin metamodels (representation and visual - admin M2) and clean metadata model (user M2). Now you can see that new node appears in tree view. It's the repository node. After you expand it, you can see three nodes. Metamodel node is for storing repository metamodel (it will be your own modeling method metamodel - user M2) and several representation models (it will be your own representation definition for metamodel - user M1). Models node is for storing models based on your own metamodel definition (user M1 models). You can see MOF, RM (representation metamodel), VIS (visual metamodel) inside the "Admin" node in tree view. But be careful, changes made by user in these admin metamodels may corrupt repository. You should work only with the metamodel and with the models based on it.

Prepare metamodel
Second step is the preparation your own modeling method definition. It is described by metamodel (or metadata model). It draws the structural view of your modeling method. This metamodel has to be created in MOF notation. If you are not familiar with MOF, you will be in troubles :) Fortunately you can use prepared metamodels in directory "./models". Right click on "metamodel name" node and select "Import XMI model definition".
Although we are going to use OSM as a Metamodeler too, but right now is a lot easier to prepare metamodel in some UML CASE tool and then use UML2MOF tool for metamodel transformation. You can use only Reflective diagram, Tree and Property view for these purposes in this OSM version.

Prepare representation
The most important part in OSM is the Representation definition. Representation model is based on our own Representation metamodel which is described in MOF and it is stored in repository in "RM" extent (watch "admin" node).
For create new Representation model right click on "Representation models" node (navigation - MDRManager/Metamodel/Representation models). Select appropriate action. In dialog set the new representation model name and click "Ok". New model will be created.
Here will be long chapter describes how to model representation, but it hasn't got any effect in this OSM version. So you can only browse representation model in Tree view if you are interested in it.

Instantiate metamodel / create new model
This is the final step. Right click on "Metamodel" node or Instance of MOF package node and select "Instantiate metamodel" action. In dialog specify new model name, main MOF package instance in structural metamodel and select one from existing representation models. Click "Ok" and new model will be created in "Models" node in Tree view. If not, use "Reload node" action please. If still not check the Log view for errors. Now you can use this newly created model for modeling purposes. You have your own CASE tool now :)

CASE tool
Sorry, we are working on it. It's the target of our effort. You can use Reflective diagram tool instead.

Reflective Diagram
Reflective diagram offers easy way how to show extent or package contents in graphical view. Right click on some Extent or Package node and select "Open reflective diagram". Then select which classes and associations (in MOF view) you want to see. You can select visualization options for each entity (color, image, style and association ends symbols). You can save configuration for further use. Then click "Ok" and OMS draws package contents diagram. You can create new instances, new association, update or delete. Layout entities automatically or by hand, zoom it, print it, etc. But unfortunately you can't save entity layout now.

Matrix view
Other view which is applicable on Extent or Package node is the Matrix View. It enables you to show class instances on axis and association type in the intersection. You can use this view to create or delete associations.

Important note for users, who are familiar with MOF. OSMetamodeler can be used as metamodel editor and model editor as well. When you want to design metamodels in MOF, create repository based on MOF metamodel, prepare MOF representation and instantiated models will be prepared for MOF metamodeling. It is possible in respect of the fact that the MOF is self-describing. If you want to model in any of your methods, create new repository, import your metamodel designed in MOF, create representation model and instantiate them.

Other OSM functions
MOF Doc It is the first implementation of the documentation generator. It is working only for MOF models (in our scope it is a metamodel). The core of the MOF Doc is based on XSLT standard. Nowadays it contains only one XSL template, which is able to transform XMI MOF model.

The "MOF Doc" command is accessible from popup menu in "tree view" in OSM. Right click on extent or package node and select item "Create HTML documentation". Type the target HTML file name and approve it. OSM exports the package content into the XMI file and then calls Saxon parser for creating HTML document. After that OSM copies CSS file into the same directory where target HTML was created. Finally OSM deletes temporary XMI file.

You can also use XSL template (it is located in "../jars/xml") manually for transformation of existing XMI file. Don't forget the XMI file must be MOF model ("model" namespace is expected).

UML2MOF This is an extra tool  for MDR. We developed only UI for this command line tool. This tool can transform the UML XMI file into the MOF XMI file. This tool is very useful for exchanging models between OSM and other UML CASE tools. Especially for exchanging the metamodels. You can simply create metamodel in some UML CASE tool, export it into UML XMI file and then transform that into the MOF XMI file. MOF XMI file can be imported into the OSM repository. This way we have created some examples in "../models" directory.

This tool is accessible from main menu "Tools -> UML2MOF". Remember that there are a few important points here:

  • for correct transformation you have to import MOF PrimitiveTypes in your UML metamodel. Templates for Poseidon and MagicDraw are in "../profiles" directory.
  • top package has to have "metamodel" stereotype
  • all elements must be named (also associations and associations end)
  • before transformation exclude "Diagram" namespace from UML XMI file (if exists)
  • detail information on MDR web site

We are sorry for that, but we haven't implemented the error log for this tool yet. Therefore when transformation fails you don't get any useful information. Wait for next versions, please.

That's all for now ...