Free modeling tool software for linux

QML (Quantity Modeling Language) is a "thing"-based language for scientific and mathematical data modeling.
Each "thing" is a quantity which may be associated with either a structure or physical phenomena.
Quantities, in turn, may hold other Quantities or values (numbers or strings). Higher-level data models, which associate or define meanings to various quantities (such as velocity or position), can be built from QML quantities.
The higher-level data model (XML) schema that inherits from QML may be understood, and its instance documents may be parsed into QML documents and objects by the QMLReader.
Enhancements:
- This release adds partial Xerces2 DOM support, and works with Java 1.4 and Java 1.5 (no JAXP DocumentBuilder/Factory support currently).
- The test procedure is a little less chatty.
- Support has been added for testing either/both Crimson/Xerces DOM support.
- (Note: Crimson support only works with Java 1.4, as Java 1.5 interfaces have DOM lvl 2 and 3, which crimson doesnt support).
- This release adds compilerargs, and better build support for different configurations to build.xml.

medini QVT implements OMGs QVT Relations specification in a powerful QVT engine.
The standard is designed for model-to-model transformations to allow fast development, maintenance and customization of process specific transformation rules.
Main features:
- Execution of QVT transformations expressed in the textual concrete syntax of the Relations language
- Trace management enabling incremental update during retransformation
- Key concept enabling incremental update as well as the transition from manual modeling to automation through transformations in the abscence of traces
- Bidirectional transformations

DREAM Tool is a generic framework that aims at providing a common semantic domain which can express several (real-time, power consumption, resource) constraints.
The semantic domain has an executable C++ model which has been semantically anchored to the hybrid automata formalism. Although the model of computation corresponds to hybrid automata, so far we have been successful in analyzing the models by conservative approximation using timed automata on moderate size systems.
To deal with large-scale examples the user has the ability to use the simulation/testing interface on the executable C++ model before implementing the system. We plan to extend the genetic algorithms to solve a large number of problems.
DREAM is a simulation and verification framework which provides a formal model and analysis of your system in less than a day. Systems in DREAM are specified using XML in a straightforward way. I hope you find it useful.
Real-time middleware provides dependable and efficient platforms supporting key functional and quality of service (QoS) needs of distributed real-time embedded (DRE) systems.
Key challenges in DRE system developments include safe composition of system components and mapping the functional specifications onto the target platform. Model-based technologies help address these issues by enabling design-time analysis and providing the means for the rapid evaluation of design alternatives with respect to end-to-end QoS properties, predictability and performance measures before committing to a specific platform.
The Distributed Real-time Embedded Analysis Method DREAM is an open-source tool and method for optimizing multiple quality of service (QoS) properties of distributed real-time embedded (DRE) systems. The project focuses on the practical application of formal analysis methods to real-time middleware to automate the verification, development, configuration, and integration of middleware-based DRE systems.
Enhancements:
- This version implemented several optimizations for improved model checking performance, resulting in impressive performance gains of at least 2-3 times.
- There are no known memory leaks present in the current release.
- Balanced AVL trees are now used, resulting in exponential speedups in several steps of the model checking method.
- XML Schema validation was implemented.
- Verification time reporting was upgraded to include data on the simulation speeds.
- Random simulation-based testing now provides an execution trace when a deadline is missed.

Session Directory Tool provides a multicast session directory manager.
SDR is a session directory tool designed to allow the advertisement and joining of multicast conferences on the Mbone. It was originally modelled on sd written by Van Jacobson at LBNL, but implements a later version of the session description protocol than sd does.
SDR was originally written under the MICE and MERCI projects at UCL by Mark Handley who now works for ISI. SDR will continue to be maintained on a limited basis as part of the infrastructure for conferencing on the CAIRN testbed network and the EC MECCANO project.
Many many fixes and improvements to SDR have been contributed by Bill Fenner and Van Jacobson. Security features were implemented by Edmund Whelan and Goli Montasser-Kohsari at UCL.
Enhancements:
- new application media type for session directories
- fixed byte ordering of headers on intel machines
- fixed IP6 address allocation for unix IP6 stacks
- Authentication and encryption code fixed to allow for extra space for IPv6 addresses
- Added IPv6 flags to configure scripts "--enable-ipv6"

KPovModeler is a modeling and composition program for creating POV-Ray scenes in KDE.
For most of the modelers, POV-Ray is nothing but a rendering engine and they bring a lot of limitations to the innate possibilities of POV-Ray scripted language. This is not the case for KPovModeler which allows you to use all the features of POV-Ray through the translation of POV-Ray language into a graphical tree.
Almost all options of POV-Rays script language can be used within KPovModeler. "Almost" because variables, loop instructions, macros and some operators cant directly be, unfortunately.
On the other hand, KPovModeler allows you to include a part of a script with the "Raw POV-Ray" tool; such a raw code will only be taken into account by POV-Ray during the rendering stage.
Main features:
- Management of the scene through a graphical tree.
- Object modification with control points in a graphical view or direct manipulation of object attributes in a dialog
- Nonblocking scene rendering with OpenGL as wire frame views
- Freely configurable view layout with dock widgets
- Copy/paste and drag/drop of (a subset of) povray(!) code into and out of the object tree
- Undo and redo
- Scene rendering and texture preview with povray inside the program
- Support for almost all povray objects
- Support for all textures
- Prototypes (declarations) and references
- All projection modes of the camera
For modeling an object, it is not required to know POV-Rays script language. On the other hand, for creating textures refering to POV-Rays documentation will be difficult to avoid.
But to ease the work, it is possible to simply cut-and-paste a script from POV-Ray into KPovModeler. KPovModeler will then, if the script only makes use of known primitives, convert the pasted text and include it into the current scene.
In other words, if you dont know how to create an object or an effect with KPovModeler, you could always copy its example from POV-Rays documentation and experiment with it within KPovModeler.

Config::Model provides a framework to help in validating the semantic content of configuration data. The project can also be used to provide a semantic check of options of a complex program like mplayer or transcode.
For most complex software, configuration upgrade is a difficult task for most people. By using Config::Model, a software can provide a smooth upgrade path for their users.
How does this work ?
Using this project, a typical configuration validation tool will be made of 3 parts :
The user interface
The validation engine which is in charge of validating all the configuration information provided by the user.
The storage facility that store the configuration information
Dont we already have some configuration validation tools ?
Youre probably thinking of tools like webmin. Yes, these tools exist and work fine, but they have their set of drawbacks.
Usually, the validation of configuration data is done with a script which performs semantic validation and often ends up being quite complex (e.g. 2500 lines for Debians xserver-xorg.config script which handles xorg.conf file).
In most cases, the configuration model is expressed in instructions (whatever programming language is used) and interspersed with a lot of processing to handle the actual configuration data.
Whats the advantage of this project ?
The Config::Model projects provide a way to get a validation engine where the configuration model is completely separated from the actual processing instruction.
The configuration model is expressed in a declarative form (i.e. a Perl data structure) which is always easier to maintain than a lot of code.
The declaration specifies:
the structure of the configuration data (which can be queried by generic user interfaces)
the properties of each element (boundaries, check, integer or string, enum like type ...)
the default values of parameters (if any)
mandatory parameters
the targeted audience (intermediate, advance, master)
on-line help (for ach parameter or value of parameter)
the level of expertise of each parameter (to hide expert parameters from newbie eyes)
So, in the end:
maintenance and evolution of the configuration content is easier
user will see a *common* interface for *all* programs using this project.
user will not see advanced parameters
upgrade of configuration data is easier and sanity check is performed
audit of configuration is possible to check what was modified by the user compated to default values
What about the user interface ?
Config::Model will also come with a Curses::UI interface that queries the users model and generate the relevant user screens.
What about data storage ?
Since the syntax of configuration files vary wildly form one program to another, most people who want to use this framework will have to provide a dedicated parser/writer.
Nevertheless, this project can also provide a writer/parser for most common format: like ini style file, or provide an interface to the Elektra or debconf projects. This point is open for discussion.
It is entirely possible for a single configuration model to use several parsers and writers so one model will ensure the consistency of several configuration files together.
Enhancements:
- The Xorg model was updated to Config::model version 0.609.
- Some bugs were fixed.

OpenEuclide is a geometry software that can produce geometrical figures by adding preformed objects one at a time.

OpenEuclide is an opensource multi-platform 2D geometry software. Figures are defined dynamically by describing formal geometrical constraints. This project is a basic tool for educational or modeling purpose that aims to be extended as far as possible in response to user needs. May it involve users talents in C++ programming.

Supported languages are : English and French.

The goal is now to make a robust, easy to use, totally multiplatform software (no runtime environment needed), featured for education until high school (excluded).

CoreLinux++ Function Load Library (libclfll++) takes advantage of the abstract Library Load framework in the CoreLinux libclfw++ library by providing management of loading Linux shared libraries.
Application developers define function objects as wrappers and can then dynamically load the functions. It is very useful for implementing a framework for plug-ins.
Main features:
- Enlist members ( for requirements, analysis, design, and development )
- Formalize conventions for Object Oriented Analysis (OOA) and Design (OOD).
- Formalize standards and conventions for C++ code style.
- Gather requirements. Perform OOA and OOD using UML as the modeling language.
- Implement designs and example drivers.
- Develop utilities and applications for Linux that are CoreLinux++ certified
- Showcase CoreLinux++ certified applications by others