Free xmi software for linux

ArchGenXML project is a code generator for Plone CMS.
It builds on architecture-centric, model-based and test-driven developement. Generates Python code from UML-Models (XMI-Format). Its optimized for the generation of code based on the Archetypes framework.
With ArchGenXML you can create working python code without writing one single line of python. It is is a commandline utility that generates fully functional Zope Products based on the Archetypes framework from UML models using XMI (.xmi, .zargo, .zuml) files. The most common use case is to generate a set of custom content types, possibly with a few tools, a CMFMember type and some workflows thrown in.
In practice, you draw your UML diagrams in a tool like Poseidon or ObjectDomain which has the ability to generate XMI files. Once you are ready to test your product, you run ArchGenXML on the XMI file, which will generate the product directory. After generation, you will be able to install your product in Plone and have your new content types, tools and workflows available.
At present, round-trip support is not implemented: Custom code cant be converted back into XMI (and thus diagams). However, you can re-generate your product over existing code. Method bodies and certain "protected" code sections will be preserved. This means that you can evolve your products public interfaces, its methods and its attributes in the UML model, without fear of losing your hand-written code.
WHY use "ArchGenXML":
- You want to save time
- You are a lazy programmer
- You dont like to reinvent the wheel
- You dont like copying and pasting code and bugs
- You make heavy use of references and interfaces
- You have big projects with many different custom types
- You want or need a well-documented interface to your product
- You like structured model- and pattern-driven software development
- You want to maintain your project in future without getting a headache
- and many more good and odd other reasons.
Enhancements:
- Stable ArchGenXML for Plone 2.1 and 2.5. No more new features in v1.5 in future, just bugfixing. Features are for v1.6 targetting at Plone 2.5 and 3.0. They are developed on svn-trunk. v1.5 is branched away.

Alma is a software with the following functionalities :
- Reads several sources (languages, models, ...),
- Helps to design for object-oriented modeling (definition of classes, relations, patterns, ...)
- Modifies the structure and the code
- Outputs new sources, documentation, diagrams, ...
It is designed for object-oriented modelisation (definition of classes and relations) and for migrating (help to convert) code written in old languages to newer ones. It meets two needs : having a simplified software modeling workshop for small projects and make easier rewritings, ports and encapsulation of non-OO code.
This tool will be usefull for developers who get a code and wish to integrate it in a new project, to rewrite a program in a new language, and for the conceptor/architect who will have the possibilities to declare and manipulate classes.
Alma is able t oread these sources:
- C/C++ (simplified, no preprocessor)
- Class (compiled with jikes)
- Fortran 77 (partial implementation)
- IDL (quite complete implementation, no preprocessor)
- Java (quite complete implementation)
- JavaP (result of javap)
- JSP (Java Server Page)
- MDL (files from Irrational Rose)
- Pascal (partial implementation)
- TLD (Taglib for JSP)
- XMI (XML Metadata Interchange, see the site, partial)
- XSD (XML Schema, see the site, partial)
Alma is able to generate source-code for these languages:
- Autotest (Source code for automatic testing)
- BDL
- C (headers and bodies)
- C++ (headers and bodies)
- Delphi (Object Pascal)
- Eiffel
- Gui (Editing JPanels)
- HTML documentation (similar to the javadoc tool)
- IDL (OMG, see the site)
- Java
- Lisp
- Natural (french)
- ODL (ODMG, see the site)
- Python
- Rebol (see the site)
- Resume
- Ruby (see the site)
- Sql (releases 2 and 3)
- SrcHtml
- Tom (see the site)
- Uml (only inheriting and relations diagrams)
- UXF (UML in a XML format, see the site)
- XMI
- XmlProto (Description of a GUI in XML, should be used with Prototype)
- XSD

uml2svg is an XSLT-based tool for converting XMI-compliant UML Diagrams into SVG.
We started the developing uml2svg with six main goals in mind:
- Standard conformance
- Good Documentation
- Modularity
- Extensibility
- Comprehensible SVG
- Multiple diagrams per XMI-file
SVG is a standard language for describing two-dimensional vector graphics in XML. As the open SVG standard gains in popularity and gradually replaces proprietary formats for vectorial graphics, the support provided by the Web browsers is getting better.
Plugins to display SVG exist for most browsers and it is most likely that the next generation of Web browser will provide built-in support for SVG. When that happens there will be no better way to distribute vector graphics on the web. Furthermore, not only web browsers can process SVG in a meaningful way; in fact that is just the tip of the iceberg. SVG can be easily read in, processed, and then transformed into many other formats, being well suited for both text and graphic tools as well as for web agents and screen readers.
UML diagrams are composed of lines, polygons, ellipses and text labels, so they are inherently vectorial. However, the SVG is not very well suited for direct use by UML tools. While some of them can in fact export UML diagrams directly to SVG, they do that by discarding all the information about structure, and converting everything into a shape. Moreover, some tools use the screen-capture function provided by their environment (such as java2d) and then they apply a filter to generate SVG out of the "screenshot".
What comes out of that is a pile of meaningless information, which by accident happens to draw a gorgeous diagram. How will a screen reader interpret such a file? How will a web crawler be able to index it? How will a web agent process it in a meaningful way? A program needs the semantic information that the humans can extract just by looking at a picture. For a machine, an obfuscated SVG file is not easier to process than a PNG file or any other image.
Although for humans it is better to be able to scale the image, for a program this is irrelevant. Programs need a way to "understand" the semantics of the UML models to be able to process and interchange them in a meaningfull way. This was the main idea behind the XML Metadata Interchange (XMI), an OMG specification for model interchange. And probably the best use that XMI has found so far is the exchange of UML models between different modeling tools. And while the XMI provides a standard way for tools to represent models as XML documents, it is still limited to the model elements only.
With the introduction of the UML 2.0 Diagram Interchange Specification as part of the upcoming UML 2.0 standard, it will become possible for tools to exchange the models together with the layout of the diagrams. We think that, once this specification appears, XMI will be used averywhere. Not only will the tools be able to exchange diagrams, but could even represent them internaly as DOM trees. Have you ever considered drawing your UML diagrams online, using only a web browser? This could be done even now by using a custom SVG syntax for the DOM tree, but a solution based on XMI could do even better and be a standard at the same time.
Therefore, we believe that with the advent of UML 2.0 and the increase in the use of SVG, the need for transformations between XMI and SVG will be great. Nevertheless when the uml2svg project was started, there was hardly any good open-source solution to convert XMI diagams into SVG.
The UML 2.0 Diagram Interchange Adopted Specification in its current incipient form references a set of XSL transformations. Although the standard draft covers them to a large extent, the link is actually broken (you can try for yourself). It has been broken for more than a year and most likely it will stay like that forever.
The personal webpage of Professor Mario Jeckle provides an online transformation service capable of dynamically generating SVG from XMI-compliant XML files. The XSL files accomplishing the transformations are also available on that website. These transformations are monolithic and not well documented (the only documentation is in the code, and it is generally written in German). With the tragic accident that took the life of Professor Jeckle, the transformations have no longer been maintained.
Finally, the STZ-IDA research center in Karlsruhe had to convert UML diagrams to SVG, as part of one of their projects. The XSLT stylesheet they created for this purpose was named xmi2svg and is available under the terms of the MIT license. At the time we started work on uml2svg the only type of diagrams supported was class diagrams.
Recently the package reached version 0.2 and it supports more diagram types, without major changes in the code (the opposite of what we were expecting). Andreas Junghans, the author of xmi2svg, provided us with a lot of insightful hints which helped us eliminate many glitches in uml2svg. It looks that the development of uml2svg and xmi2svg will continue in parallel, at least for a while. The good thing about this is that the two (quite different) implementations prove each others validity and the features tend to propagate freely from one side to the other. However, this comes with the prize of having to maintain two different code-trees and possibly confusing some users.
We did not like the two existing solutions because they were:
incomplete - just prototypes, not well suited for production environment
monolithic - hard to maintain and extend
not documented - hard to understand
At first sight, we thought we could find a way to improve one of the existing solutions and just add the features we needed. However, we slowly came to the conclusion that it would be better if we started anew. There are things one can fix in a project, but that does not include what we thought is was bad design. The fact that the two implementations presented above are open source helped us get quickly on the way with our own project.
Enhancements:
- Two annoying bugs were fixed.
- The site and documentation were updated.

AutoDia is a modular application that parses source code, XML or data and produces an XML document in Dia format (or images via graphviz and vcg). AutoDias goal is to be a UML / DB Schema diagram autocreation package.
The diagrams its creates are standard UML diagrams showing dependancies, superclasses, packages, classes and inheritances, as well as the methods, etc of each class.
AutoDia supports any language that a Handler has been written for - see below for an up to date list..
Autodia now outputs the following formats :
- Graphviz (using dot to generate jpg, png, etc)
- dot
- vcg
- xvcg (using xvcg to output postscript, etc)
- dia (using a new custom directed graph algorithm to layout diagrams)
- HTML/XML/Anything (if you write your own template)
- Experimental SpringGraph (native perl directed graphs similar to graphviz) now included
- Experimental Umbrello XML/XMI (requires fixing)
Autodia now parses the following forms of input
- Perl
- Python
- PHP
- Java (some issues with version 1.4) no longer fully supported (it used to work, Java broke its APIs now it doesnt, fixes welcome)
- C++
- Torque (XML DB schema)
- DBI (perl database interface handles)
- SQL
- Umbrello (experimental)

Xholon runtime framework executes applications that are event-driven or that have highly dynamic structure or behavior. Specify your models using XML and Java, or using third-party UML2 tools and MDA transformations.
To get started, read or actively work through the basic HelloWorld tutorial. Its a very simple application, but it demonstrates many of the main concepts.
For more detail on the concepts behind Xholon, you might want to read one of the papers thats been published. These describe how to model cells and other complex biological entities using tools designed for developing real-time and embedded systems.
This earlier work used Rational Rose RealTime and C++, rather than the current Java. Xholon is intended to be a runtime framework that can execute the same types of systems described in those papers, plus many more traditional non-biological event-driven systems.
The goal of the Cellontro sister project is to develop complex biological simulations using the Xholon framework. Most of the features described in the published papers have been re-implemented as Cellontro applications using Xholon.
Also have a look at the sample applications that are included with the Xholon software. These give an idea of the range of applications that can be supported by the Xholon runtime framework.
These have been employed as use cases to determine what functionality is most important in Xholon. The digital watch simulation is a good example of a Xholon application with a hierarchical state machine, developed using a UML modeling tool.
A Xholon is essentially a holon. A holon is an entity that lives within a hierarchical structure, and is both a whole and a part at the same time.
In mainstream computer science terms, a Xholon is a node in a tree. The node has a single parent, possibly one or more children, and possibly one or more siblings. A Xholon may also be an active agent able to interact in real-time with other Xholons in the tree.
In UML2 terminology, a Xholon is a structured classifier that may exist as a part within other structured classifiers, and that may in turn contain other structured classifiers as parts of itself. The result is a hierarchical containment structure, nested to an arbitrary number of levels.
As a part, a Xholon plays a specific role within another structured classifier. Xholons are UML classes that are subsequently refined using UML2 composite structure diagrams. Structured classifiers interact with each other through ports, by passing messages or by making function calls.
Using the more philosophical terminology used to describe holons, a Xholon is something that is simultaneously both a whole and a part. Since everything in the universe is a holon, then everything running within a computer application should be a Xholon. The term holon was invented by Arthur Koestler in 1967.
The Xholon Project is inspired by biological concepts. A major incentive behind the project is to build a run-time environment that is equally adapted to running simulations of biological systems, and to running more traditional real-time, embedded and other event-driven reactive systems.
Xholon applications may contain structures that are highly mutable. A Xholon is an active agent that can modify the tree structure in which it lives. It can navigate the tree to interact with any other node, it can add, delete or modify other nodes, it can exchange messages with other nodes, and it can move itself to another position within the tree.
The Xholon Project incorporates many concepts of the Real-time Object-Oriented Modeling (ROOM) methodology, much of which has been incorporated into UML2. At the same time, Xholon removes some of the limitations of ROOM to allow for greater flexibility, mutability and mobility of active objects.
The Xholon run-time can serve as a target for a Model Driven Architecture (MDA) transformation pipeline. MDA stresses the importance of models, and the ability to transform those models, through a series of steps, into an executing target system.
You can create your model using a UML tool such as Gentlewares Poseidon or NoMagics MagicDraw, save the model as an XMI file, transform it using XSLT (or by some other MDA means) into a Xholon model and application, and then execute the model.
Enhancements:
- UML state machine simulation capabilities have been extended, including animation, and fork, join, junction.
- Additional Agent-Based Modeling functionality is available.
- The NetLogo-like syntax has been enhanced.
- The architecture is more flexible and is ready to more fully support integration of multiple domains.
- Histograms and probability distributions are now available. Line charts update in real-time.
- Numerous other modeling, simulation, transformation, and execution features have been added.

OpenSwarm processes your UML 2.0 model to generate a Python server application.

It provides easily customizable business logic based on Python and PostgreSQL. As required by the MDA standard, OpenSwarm uses UML (version 2.0 stored as XMI 2.1).

Open Blue Lab is an enterprise resource planning system.
Whatever your goal is, the objective of this tool is to provide you the ready-to use stuff to create, update, search and view data you need for your application.
Moreover, this stuff is provided with the latest UI goodies like AJAX support that will ensure you the best feeling you never had in browsing.
Like OpenBlueLab.org project is portal aware, that means you have aggregation and personalization too.
That way, you can focus on your added value : the business logic and requirements your customer needs.
Main features:
- to collaborate and communicate better
- to manage your personal time
- to schedule your appointments
- to define and track personal and group project
- to manage your content (asset, document, ...)
- to manage your customer relationship
- to make coffee (not yet, next release maybe
We want to develop a product, free, that fits exactly your needs, so read this web site and take time to indicate us your requirements. They will appear on our todo list, maybe in a long time, but they will. Then, you may incitate people to contribute in your direction by sponsoring somebody to achieve it.
This product is completely free. You can even package it and sell it. If you wonder what is our business model, you can ask to the forum.
Built on java technology, you may download the GUI installer, double-click and use it (with all your entreprise) through your preferred browser, whatever your environment is.
Built on XML and REST technology, you may integrate (in synchronous or asynchronous mode) it very easily in your environment too.
OMF (OpenBlueLab Modeling Famework) created by and for OpenBlueLab permit to configure easily the portal. Actually, we must use ArgoUML or the plugin ArgoEclipse with the IDE Eclipse. The goal is to create a specialized editor to create the diagrams needed by OpenBlueLab to configure the portal.
The main steps are :
- Transformation files generated by ArgoUML (XMI format) to the ECORE format.
- Transformation files from ECORE format to XMI format (or PIVOT format) to configure the portal.
- Creation of the editor.
Enhancements:
- This version integrates the transformation to UML2, and adds a dialog on comments in the class diagram.