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 the methodology
• 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.

Implementation layer

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 [1], 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 language.
  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.

References

[1] G. Le Cousin, Modeling Distributed Fault-Tolerant Systems, Technical Report, Software Engineering Competence Center. University of Luxembourg, Luxembourg, LUX, 2004