News

Keep current on your OMF updates!

09.15.2004

Apparently, I forgot to post the fixed version of the OMF from the 10th of this month. Oh well...

Big news, however. I'm calling today the official release of the OMF version 1.0. The library is pretty solid - and all of the Python bindings seem to work properly. Also included in the release is the much-vaunted GNU autotools integration. No longer do you have to tweak the Makefiles to get the build right. Just configure, make and install. Of course, this is the first time I've used autotools (from scratch) so somethings are still a little flaky - like finding and libxml2 includes. Please download the new OMF and let me know what you think.

09.10.2004

Redevelopment of the web page continues...

A new version of the OMF has been released. This includes a small fixes that actually makes the UML Python bindings useful, and it includes a new facility for lightweight property extensions (really lightweight). See the download page to download the new version.

09.08.2004

The obvious big news is a redevelopment of the OMF website. Explore, have fun.

I've also finished a pretty ugly code generator (mmgen is back) that I used to generate a stub of UML for the OMF. I haven't tested the new code, but it's already in the build. This version of mmgen is written in Python.

Aside from that there have been some pretty significant modifications to the OMF.

The most visible change is the addition of a new module for the OMF: UML is back! In theory, the OMF is now ready for the development of real UML tools.
OMF can read XMI 1.2 and XMI 2.0, but it only writes 2.0. Also, I haven't implemented any of the cross-document reference support for the 1.2 module. I added this support so I didn't have to re-create the UML metamodel in XMI 2.0.
The Python bindings have an interesting new feature: classes in the metamodel libraries. No longer are all the elements "OMF.Element", but actually appear as their instantiated types (e.g., Model.Class, UML.Pacakge). Caveat: you'll need to import all the OMF modules if you want this to work right. For example, it's probably pretty bad to request the meta- object of a UML object if you haven't imported the MOF package.
Numerous and various bugfixes

Get your new version of the OMF here and the Doxygen documentation can be found here.

08.23.2004

After a month of semi-intensive development and frustration with coding, I'm releasing a new version of the OMF2 library and Python bindings. This fixes most of the bugs that were around in the last release - particularly with respect to the Python bindings. However, the build environment is still probably a little flaky (I need to learn automake/autoconf). But, here it is: Get the OMF2 library. This will untar to the directory "omf2". Build directions are the same. If you want to build the tests or the Python bindings, You'll have to cd into those directories specifically. Check the ChangeLog for details.

07.19.2004

Well, after looking at my lists of improvements and then at the code in its existing state, I've decided that the most direct path to getting this done would be to... well.. start from scratch. I'm sort of working on a new philosophy with this version that goes something like this: make the MOF (Meta-Object Facility) as complete as possible and build on that. The MOF should have been the starting point from the beginning but I've always seen it as just another model. However, after seeing how successful the EMF (Eclipse Modeling Framework) has become, I've had to rethink my approach to the problem. As such, I've been pounding out code for the last four or five days and actually have a nice hand-built implementation of the MOF that includes some of easier "improvements". Here's what I've got so far:

No more Qt
New and improved type system
New property system using templte get/set functors
Dynamically loadable metamodels (coming soon)
No XMI reading or writing (coming soon)
No reflective interfaces (coming soon - sort of)

Basically, what I've got is an API for building metamodels, but you can't do anything with them just yet. However, based on the rate of progress, that shouldn't be too far off. If anybody wants to sample the new code base, here's a link to it. You'll need a version of Boost that includes boost::lexical_cast. Also, it's not using the automake/autoconf tools, just a simple set of Makefiles. Here's some build instructions:

        $ tar xvjf omf2-.tar.bz2
        $ cd omf2
        $ export OMF_ROOT=`pwd`
        $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:`pwd`/lib
        $ make

The test dir will not build by default and you'll need the LD_LIBRARY_PATH stuff to get the examples to run. Feedback is always appreciated :)

07.14.2004

It's been a while since I've done any work on the OMF. Well, that's not entirely true, but it's certainly been a while since I've made a release. I'm still not going to - I've got some plans in mind. I did some work to beef up the implementation for a reverse engineering tool I had built, but in the end, decided that it wasn't worth compiling the release for everybody. There are just too many problems with the current incarnation. Instead, what I'm posting today is my wishlist for fixes, optimizations and extensions to the current OMF. Here's the [pdf] file describing my proposed changes. Unfortunately, the list of changes is so long, that it's going to take forever and a day. I'm considering moving the CVS repository for this set of modifications to a subversion server with anonymous access on my personal machine. If there's any interest in public src code access (above and beyond the current level) send me an and I'll see what I can do. Alternatively, if I get significant interest, I'll move the project to SourceForge or something similar.

03.08.2004

Big news for the OMF today. Well, not really the OMF, but people wanting to play with UML at the data level. This release inludes a set of Python bindings for the OMF. They're built using the excellent (although sometimes cryptic) Boost.Python library. You'll need the latest version of that (1.3.1 works fine) to build it. It also isn't part of the regular build so you should build and install the OMF first, and you'll probably need to tweak the setup.py script to link against the right version of Boost.Python... I got lazy and forgot to change that before tarring the distro.

I've also been lazy and haven't updated anything else on this page... Just the OMF. Oh. and there are some nasty bugs (like the fact that deleting a model will crash the program). For a better list of bugs, see the TODO file.

Just to show a quick example of how nice Python is, here's a snippet of code to list all the types and names of objects in the UML metamodel.

# the most important step
import omf

# create an empty model
model = omf.Model()

# read the uml metamodel
model.read("/usr/share/apps/libomf/uml-1.4.xmi")

# get the MOF extent for the metamodel
ext = model.extent(omf.model())

# get the extent of the base-most class in UML (Element)
proxy = ext.proxy("Element")

# get all derived types of Element
types = proxy.types()

# print everything
for i in types:
        print i.meta().get("name"), i.get("name")

Yes, that's really all it takes. This will, of course, be under some pretty heavy development over the course of the semester, so expect improvements and interface changes.

Older news

I got tired of backporting my news... most of it isn't relevant anyways, so i'm not going to write it all down.

Last modified: Wed Sep 15 09:42:06 EDT 2004