Free uml isis software for linux

UMLet project is an open-source Java tool for rapidly drawing UML diagrams with a pop-up-free, light-weight user interface.
UMLet lets you draw diagram sketches fast; export diagrams to eps, pdf, jpg, svg, and sys.
Add elements to a diagram with a double click. Edit elements using the lower-right text panel. Select multiple elements using Ctrl or lasso. Press C to copy diagram to the system clipboard
Main features:
- fast
- text-based sequence diagram
- call from command line.

The P-UMLaut tool allows the user to transform UML 2.0 Sequence Diagrams to semantically equivalent Petri Nets.
These Petri Nets may then be simulated using the supplied PN simulator (of PEP descent) or operated on with any tool that can work with high level Petri Nets.
By plugging different Realms into the simulation by way of an event filter, the modeled world may then be displayed and interacted with in various fashions. A 3D animation module is supplied as well as two examples utilizing the complete toolchain.
Enhancements:
- A new Petrinet Simulator was implemented in Java which features Highlevel-PN to Lowlevel-PN unfolding and Timed-PN simulation.
- Filtering was enhanced. Irrlicht 0.12 is used.

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.

UMLGraph facilitates the declarative specification and drawing of UML class and sequence diagrams.
One can specify a class design using the Java syntax complemented by Javadoc tags.
Running the UmlGraph doclet on the specification generates a Graphviz diagram specification that can be automatically processed to create Postscript, GIF, SVG, JPEG, fig, or Framemaker drawings.
Similarly, sequence diagrams are specified using declarative pic macros and compiled with the GNU plotutils pic2plot program into a PNG, PNM, (pseudo) GIF, SVG, AI, Postscript, CGM, FIG, PCL, HPGL, Regis, or TEK drawing.
Enhancements:
- This version improves its invocation interface so that it can be run directly as a jar file.
- It has support for sending results to the standard output for direct piping into dot.
- The distribution includes an example shell script and batch file for invoking UMLGraph.

ADIOSKIDS is a Fedora-based live and installation CD with support for User Mode Linux (UML) virtual machines, further enhanced by Linux Intrusion Detection System (LIDS) and SELinux (Security Enhanced Linux). The live CD, which includes the KDE desktop environment, uses a compressed loopback filesystem.

The objective of the ADIOS project is to quickly and easily download a consistent operating system environment onto laboratory PCs. The ADIOS environment provides students with administrative privileges required to perform advanced exercises in Network and Systems Administration.

We needed a way to download a pre-installed version of the operating system onto the PC in the laboratory. There are many tools available to do this, but the ADIOS project uses a web server to deliver the Operating System images.

The ADIOS setup image is used to install operating systems onto disk partitions. It also copies the OS images from disk to disk to reduce network traffic. The ADIOS image was ported onto CDROM for students to use at home.

ADIOS-SELinux is a separate boot CD for running NSA Security Enhanced Linux. Additional software is available on the DVD version of ADIOS.

ummf Perl module contains a driver for UMMF.

SYNOPSIS

ummf [-I dir] [-M MetaModel] [-m Main::Module] [-o {dir|-}] [-e exporter] input ...

This is a driver for the UMMF toolkit. It translates UML input documents into the export targets specified by the -e option. If -o - is specified the output is generated to STDOUT, otherwise the output is multiplexed into files underneath the directory specified by the -o option, using files2dirs.

If input is UML-1.5, then the internal UML 1.5 meta-model (from UMMF::UML::MetaModel) is used as input.

Input files can be .zargo (ArgoUML and Poseidon for UML 1.x), .zuml (Poseidon for UML 2.x) or XMI 1.0 or 1.2 documents.

USAGE

ummf -e java -e perl -o gen test/test1.xmi

Generates Java and Perl code in directory gen from test/test1.xmi.

ummf -e perl::hibernate -o gen test/test2.zargo

Generates Java Hibernate hbn.xml file in directory gen from test/test2.zargo.

ummf -e XMI -o - UML-1.5

Generates XMI for the UML 1.5 meta-model on the standard output stream.

ummf --perl5lib

Print the PERL5LIB path needed for Perl code generated by UMMF.

ummf -L Some::Package

Loads Some::Package.

ummf -m Some::Package @args ...

Loads Some::Package and executes >.

ummf -I dir/with/perl/modules

Executes use lib dir/with/perl/modules; including modules from the specified directory in the search path.

ummf -M UMMF::Boot::MetaModel

Uses UMMF::Boot::MetaModel for the meta-model, defaults to UMMF::UML_1_5.

ummf -profile MyMagicProfile -e Perl UML-1.5

Applies MyMagicProfile during export of Perl code on the UML 1.5 meta-model. This overides the default lib/ummf/profile/UML-1.5.ummfprofile file.

UML::Sequence is a Perl module to render UML sequence diagrams, often by running the code.

SYNOPSIS

use UML::Sequence;

my $tree = UML::Sequence->new(@methods, @outline, &parse_method);
print $tree->build_xml_sequence(Title);

To use this package, or see how to use it, see genericseq.pl and seq2svg.pl.
This class helps produce UML sequence diagrams. build_xml_sequence returns a string (suitable for printing to a file) which the seq2svg.pl script converts into svg.

To control the appearance of the sequence diagram, pass to the constructor:
1 a reference to an array containing the signatures you want to hear about or a reference to a hash whose keys are the signatures you want 2 a reference to an array containing the lines in the outline of calls 3 a reference to a sub which takes signatures and returns class and method names

To build the array references and supply the code reference consult UML::Sequence::SimpleSeq, UML::Sequence::JavaSeq, or UML::Sequence::PerlSeq. To see one way to call these look in the supplied genericseq script.

HTML::Toc module can generate, insert and update HTML Table of Contents.

The HTML::Toc consists out of the following packages:

HTML::Toc
HTML::TocGenerator
HTML::TocInsertor
HTML::TocUpdator

HTML::Toc is the object which will eventually hold the Table of Contents. HTML::TocGenerator does the actual generation of the ToC. HTML::TocInsertor handles the insertion of the ToC in the source. HTML::TocUpdator takes care of updating previously inserted ToCs.

HTML::Parser is the base object of HTML::TocGenerator, HTML::TocInsertor and HTML::TocUpdator. Each of these objects uses its predecessor as its ancestor, as shown in the UML diagram underneath:

+---------------------+
| HTML::Parser |
+---------------------+
+---------------------+
| +parse() |
| +parse_file() |
+----------+----------+
/_
|
+----------+----------+ +-----------+
| HTML::TocGenerator + - - - - - -+ HTML::Toc |
+---------------------+ +-----------+
+---------------------+ +-----------+
| +extend() | | +clear() |
| +extendFromFile() | | +format() |
| +generate() | +-----+-----+
| +generateFromFile() | :
+----------+----------+ :
/_ :
| :
+----------+----------+ :
| HTML::TocInsertor + - - - - - - - - -+
+---------------------+ :
+---------------------+ :
| +insert() | :
| +insertIntoFile() | :
+----------+----------+ :
/_ :
| :
+----------+----------+ :
| HTML::TocUpdator + - - - - - - - - -+
+---------------------+
+---------------------+
| +insert() |
| +insertIntoFile() |
| +update() |
| +updateFile() |
+---------------------+

When generating a ToC youll have to decide which object you want to use:

TocGenerator:

for generating a ToC without inserting the ToC into the source

TocInsertor:

for generating a ToC and inserting the ToC into the source

TocUpdator:

for generating and inserting a ToC, removing any previously inserted ToC elements

Thus in tabular view, each object is capable of:

generating inserting updating
---------------------------------
TocGenerator X
TocInsertor X X
TocUpdator X X X