Issue 1512: Need for notation for dealing with evolution of UML models (uml2-superstructure-ftf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings: Resolution: Revised Text: This issue will be addressed by the MOF versioning specification. Hence, it is outside the scope of UML Actions taken: June 8, 1998: received issue July 22, 1999: Deferred:UML 1.4/2.0 March 9, 2005: closed issue Discussion: Deferred to UML 1.4/2.0. This issue will be addressed by the MOF versioning specification. Hence, it is outside the scope of UML. End of Annotations:===== Return-Path: Date: Mon, 8 Jun 19 submit: Submit Issue Report 98 05:12:14 -0400 From: www To: juergen@omg.org, web-incoming@omg.org Subject: WWW Form output Name: Tom Mens Company: Programming Technology Lab, Vrije Universiteit Brussel Email: tommens@vub.ac.be Notification: Yes Specification: UML Semantics Section: Formal #: ad/97-08-04 Version: 1.1 Revision_Date: 08/01/97 Page: Nature: Enhancement Severity: Significant full_desc: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings: 7 The generalisation relationship is too restrictive because of the substitutability requirements it imposes: the specialised element should be substitutable for the more general element. In practice this means that one is only able to add new items to the more general element. However, in a general evolution mechanism you also need a way to deal with kinds of incremental modification where parts of the modelling element are removed or altered. Due to the substitutability requirements, the generalisation relationship is not suitable for expressing this kind of modification. 7 As an alternative, the dependency relationship can be used for expressing evolution, but in order to do this a specialised kind of dependency relationship is needed. Indeed, current specialisations of the dependency relationship, namely "refinement", "usage", "trace" and "binding" are not directly suitable. "Binding" is a relationship between a template and its instantiation, "refinement" is a relationship between modelling elements at different levels, a "trace" is only a conceptual connection between modelling elements, and a "usage" relates different modelling elements that require each others use. In order to express that a modelling element evolves (or changes, or is reused) to another modelling element at the same modelling level, we propose a new kind of specialisation of the dependency relationship, called "reuses" (or "evolves", or "modifies") which is specifically destined to deal with evolution and incremental modification of modelling elements, and to which a special semantics to do this can be attached. Because there are many different kinds of reuse, evolution or incremental modification imaginable, we also suggest that this "reuses" relationship should have an attribute (or association) called "type" (or "kind"), that expresses which kind of reuse is currently taking place. E.g. "type=extension" indicates that new elements are added to the model, "type=cancellation" indicates that existing elements are removed from the model, "type=renamed" indicates that a new name is given to an element. Dependent on the context and on the kind of modelling element that is being "reused", different types of reuse might be needed, so we do not think it is possible to give a complete list of the possible types of reuse here. Probably it is best to define the "type" attribute as a string. (An advantage of using dependencies to express reuse or evolution is that the approach is scaleable. Since a dependencies is allowed to have a set of subdependencies, it is possible to define more complex kinds of reuse in terms of more primitive ones. E.g. a "reuses" dependency with attribute "type=factorisation" is usually expressed by means of more primitive "reuses" dependencies of the form "type=cancellation", "type=extension" and some others. We will not go into detail on this here, but refer to [Mens&al98] for more information and a more detailed discussion on the need for a notation that deals with evolution features. [Mens&al98] Tom Mens, Carine Lucas & Patrick Steyaert: "Supporting Reuse and Evolution of UML Models", pp. 341-350, Proceedings of UML