The G-UML project is just starting. That's why this site is so poor and uncomplete at this moment.
However it will be regulary updated with the project's progress.
What is G-UML ?
GUML aims at providing a new development methodology, from the customer requirements until the
implementation of a solution.
This methodology is mainly based on model transformations and refinements.
The objective of this method is to fulfill the following requirements:
reusability and maintainability: be able to reuse elements/components already
defined (by the user itself as well as by a framework, a library...), and be able to make a component
evolve easily at all the steps of the methodology (a change at a step must be easily propagated to the
other steps (other models))
minimum effort: be able to generate a lot of elements, documentation... at each step of
safety: be able to proove that the built application satisfies to properties in all
possible situations (such there is no deadlock, the result of an algorithm will always follow a rule...),
and help the user (designer, developer...) to build a safe application (verify that all possible situations
are handled in an algorithm...)
Currently, the methodology is elaborating and not totally defined.
At the end of the methodology is the implementation layer. This section gives you some details about
the current state of this layer.
This layer provides a new programming language. Here, I know you're saying 'Why a new language again ?'.
But let us introducing this language:
Our language is object-oriented: (for reusability, maintainability and safety)
As shown in , it is widely reconized that object-oriented languages are very useful for
reusability and maintainability, by defining boundaries for a part of the system, and refusing
internal data access to unauthorized modules. That provides also the basis for implementation of fault
tolerance: decomposition protects other modules from failures which can occur in a module and control
his propagation, either by correcting it locally, or indicating the context within the failure occured
to other modules, giving more sense to a failure and so increasing the capacity to recovery it.
From our language, we are able to generate source code in a lot of languages (such as Java, C#, C++...):
For that, the compiler of the language use one plug-in per language.
First, the compiler asks questions to the plug-in about the language features (Does Java support multiple
inheritance ? Does Java support to specify a behaviour for accessing a property ? and so one...).
According to the answers (the features supported by the target language), the compiler transforms the code
making the generation to source code easier.
For instance, if the language does not support a behaviour for accessing a property, it generates two
methods per property (one for read access and one for write access) corresponding to the two behaviours,
and each time a property is accessed, it generates a method call.)
Thus, after transformations of the code, the compiler asks the plug-in to generate parts of source code.
For instance, for an expression i = a.b(), it will ask the plug-in to generate a method call with
instance "a", method name "b", and no parameter, then ask to generate an affectation of "i" to "a.b()".
Thus, a plug-in can be very easy to develop, and a language similar to Java or C# can be added in about
one to two hours !
Now we are able to generate source code in different language, but what is also very important is to be
able to use the framework provided with the language (for instance, we don't want to implement an XML
parser because it is already well implemented in the Java framework, in the .NET framework...). So the
language allows to specify a mapping of classes, methods, and properties to elements of the target
A simple example can be the type string: in Java it is java.lang.String, in C# it is System.String;
the method which return a sub-string is substring in Java, and Substring in C#...
The language may contain formal specification for methods, and constraints on properties, method parameters
and return value, in order to make verifications of code and proofs of properties.
 G. Le Cousin, Modeling Distributed Fault-Tolerant Systems, Technical Report, Software Engineering Competence Center. University of Luxembourg, Luxembourg, LUX, 2004