defined by developers. In fact, the ”Generate UserInterfaces View” model transformation operation defined by XIS2 is currently implemented in C#, and its source-code consists of a few hundreds of lines.
Finally, the UMLModeler plugin should not be evaluated only by the functionalities it provides by itself, but also by its contribution to the ProjectIT-Studio and the Projec- tIT approach. Besides the typical features previously mentioned, the UMLModeler also provides the added value of the integration with the Requirements and the MDDGener- ator plugins [Silva 06a], allowing users to quickly obtain a model from the requirements specification, refine and transform that model, and finally generate the corresponding source-code automatically. In fact, in the case of ProjectIT-Studio, it is correct to say that the whole is worth much more than the sum of the parts.
6.2
Future Work
Although UMLModeler is currently stable and can be used in the context of the ProjectIT approach, it still lacks many of the features that users may consider important or even paramount.
A very important aspect that must be implemented soon is the set of UML Superstruc- ture packages [OMG 05b] that have not yet been implemented in UMLModel. Although this UML metamodel implementation currently provides all the UML elements necessary for the XIS2 UML profile, it is necessary that the yet-undeveloped UML Superstructure packages and functionalities of the UMLModel be implemented in the near future, be- cause of the following reasons: (1) the ProjectIT approach is language-independent, and thus the UMLModeler should also support any other UML profile; and (2) it is expected that the XIS2 UML profile definition grows in the near future, as user feedback is received and new avenues of research are pursued. Additionally, since the UML modeling plugin should support the entire UML Superstructure, the functionalities of UMLModeler must also be extended to provide this support.
The serialization functionalities of the UML model should also be improved. Although there is nothing wrong with the current strategy (save a model to an XML file, and use the correct deserializer to load a model from an XML file), it forces UMLModeler to work only with XML files. Since ProjectIT-Studio is supposed to communicate with other sources, such as ProjectIT-CommonDB and ProjectIT-LocalDB, the Strategy design pattern should also be used by the Serialization package to enable the choice of where to serialize the model (e.g., to an XMI file, to ProjectIT-CommonDB, to ProjectIT-LocalDB, or to any other locations that may be supported by ProjectIT-Studio in the future).
Another aspect to implement in the near future is the support for constraint specifica- tion (preferably using a standard language such as OCL [OMG 06a]), and the validation of models based on those constraints. UMLModeler should allow users to specify the following types of constraints: (1) model-based constraints, which are used to validate only the model in which they are specified; and (2) profile-based constraints, which are specified in the context of a profile, and are used to validate any models to which the profile is applied. The strategy currently planned for the implementation of this feature requires that each instance of the UMLModeler editor have a background thread that continuously validates the current model according to the constraints that are applied to the model. Obviously, this thread should have the lowest priority possible, so that the continuous validation of the model by the thread does not affect the performance of the ProjectIT-Studio’s user-interface. Work on this feature has already begun, but it is still in its early stages and thus not yet available for user testing.
The ”model manipulation by external plugins” mechanism should also be improved. One of the potential problems of this mechanism is that it allows each extension to specify only one validation method (which is used by UMLModeler when displaying the context menu of the Content Outline); if this validation method involves complex verifications, the performance of UMLModeler could be affected whenever the user tried to access the context menu. To solve this problem, the ”UMLModelProvider” extension point will allow extensions to specify: (1) a manipulation method, which corresponds to the current transformation method of the extension point; (2) a method, called quick validation method, which should perform only a quick validation of the model, and will be used by UMLModeler to swiftly determine whether the action should be displayed in the context menu; and (3) any number of additional methods, called regular validation methods, that would be invoked only after the user selected the action, and which should perform model validations (with any level of complexity) before the manipulation method is invoked.
Another aspect that must be addressed is the specification of ”model-to-model” trans- formations. Although these transformations can be applied through the use of the ”UMLModelProvider” extension point, the only way to currently specify them is by using source-code. It would be desirable to define a mechanism that provides a set of ”model- to-model” transformation primitives, which could then be used in the specification of ”model-to-model” transformations at a high-level, with any level of complexity. The im- plementation of the support for these transformation primitives (and the transformations derived from those primitives) would likely be trivial, but the real challenge would be to define a set of primitives that successfully accomplishes the following requirements: (1) extensible enough to allow the definition of most (if not all) types of UML model trans-