![](bg6.png)
GenericFactory:Class:Classifier :
TemplateableElement
:TemplateSignature :
RedefinableTemplateSignature
P : TemplateParameter
ProductIF:Class : Classifier
Figure 7: Generic definition.
Figure 8 shows the generic instantiation of a
concrete product factory of
ConcreteProduct1.
Those objects that are useful as nexus between both
diagrams have been highlighted.
GenericFactory<C oncreteProduct1>:Classifier
:Class : TemplateableElement
: TemplateBinding
: TemplateParameterSubstitution
P : TemplateParameter
ConcreteProduct1:Classifier:Class
: ParameterableElement
Figure 8: Generic instantiation.
5 CONCLUSIONS
UML can be used to store source code, even though
there is a high complexity in the metamodel
structure. Table 1 shows a comparison of the two
metamodels, MOON and UML, divided in
subsystems/sections and number of classes. The
number of related classes in the UML metamodel is
three times higher than in the MOON metamodel.
Table1: Comparative MOON vs. UML metamodel.
MOON UML
Subsystem
Number of
classes
Sections
Number of
classes
Module 24
Inheritance 7
classes 55
Genericity 5 templates 20
Instructions 20 actions 54
activities 52
Total 56 Total 181
The paper focuses on UML abstractions which
are needed to represent code information, classes
and activity diagrams. Although the displayed
example in Section 4 achieves a mapping to UML
abstractions (generic classes, exceptions, etc.), the
experiment is limited because it does not include all
abstractions in object oriented languages. In this
sense, we have identified some abstractions that are
not represented in the UML metamodel, as typecast
and multiple bounds of parametric types. Both
features are supported on the MOON metamodel,
but MOON does not support concepts such as
exceptions, conditionals, loops, etc. Besides, MOON
supports three type variants in genericity giving a
suitable support to this feature in statically typed
object oriented languages.
Due to the previous advantages and the minimal
core size in the MOON metamodel, we think that an
UML approach is only appropriate from the point of
view of a standardization effort, and reuse in other
abstraction levels, such as the design level.
Therefore, we propose a new design solution with
the UML metamodel extension as a future direction,
extending the current MOON metamodel in the
same way as we have done with programming
languages. This should provide full support to a
refactoring process reusing the previously designed
framework.
REFERENCES
Booch, G., Rumbaugh, J. y Jacobson, I. (1999). The
Unified Modeling Language User Guide. Addison
Wesley.
Crespo, Y. (2000). Incremento del potencial de
reutilización del software mediante refactorizaciones.
PhD thesis, Universidad de Valladolid. Available at
http://giro.infor.uva.es/Publications/2000/Cre00/.
Demeyer, S., Tichelaar, S., and Steyaert, P. (1999).
FAMIX 2.0 - the FAMOOS in-formation exchange
model. Technical report, Institute of Computer Science
and Applied Mathematic. University of Bern.
Ducasse, S., Lanza, M., and Tichelaar, S. (2000).
MOOSE: an extensible language-independent
environment for reengineering object-oriented systems.
In Proceedings on constructing Software Engineering
Tools (CoSET 2000).
Fowler, M. (2000). Refactoring. Improving the Design of
Existing Code. Addison Wesley.
Gamma, E., Helm, R., Johnson, R., and Vlissides,
J.(1995). Design Patterns. Elements of Reusable
Object Oriented Software. Addison Wesley.
Mens, T. and Tourwé, T. (2004). A survey of software
refactoring. IEEE Trans. Softw. Eng., 30(2):126–139.
OMG 2004. Unified Modeling Language: Superstructure
version 2.0. http://www.uml.org.
Tichelaar, S., Ducasse, S., Demeyer, S., and Nierstrasz, O.
(2000). A meta-model for language-independent
refactoring. In Proceedings ISPSE 2000, pages 157–
167. IEEE.
Van Gorp, P., Stenten H., Mens, T., and Demeyer, S.
(2003) Towards automating source-consistent UML
Refactorings. In Proceedings of UML 2003 - The
Unified Modeling Language. Springer-Verlag, 2003
ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES
170