improving naming and grouping in uml

Improving Naming and Grouping in UML

Antonio VallecilloUniversidad de Málaga, Spain

http://www.lcc.uma.es/~av

http://www.lcc.uma.es/~av

Context

Specification of non-trivial systems using UML and ODPUML as base languageUML4ODP Profiles to represent ODP concepts

Viewpoint Modeling to structure the systems specsFive viewpoints Correspondences between them

Retail, eHealth, Aerospace

Heterogeneous Federated modeling

ECMFA 2011A. Vallecillo: "Improving Naming and Grouping in UML" 2

UML package

The package is the UML mechanism for grouping modeling elements

Provides a namespace for its members (P::x)Owns its members (if a package is removed from a model, so are its members)

PackageImport Allows using unqualified names to refer to elements in other packages

PackageMergeAllows extending the contents of one package with the contents from anotherThe receiving package is modified, being replaced by the duplicate-free union of the two packagesNames are used to identify corresponding elements

[Import deals with naming issues, Merge deals with contents]


Issues


Issues about the UML package itself

Imposes a hierarchical tree structure, in which one model element cannot belong to more than one package

No flexible organization schema Sometimes we want to group elements according to several criteria (there is no single organizational criteria that fits all purposes)

Elements may have at most one nameThis assumes a single global naming schemeIt hinders heterogeneous federated modeling


Issues about PackageImport

It does not work well with name clashesName resolution is complex or even impossible sometimesHas side-effectsThe situation gets worse under the presence of OCL


[In this diagram, the OCL constraint in package P refers with no problems to class A in the outer package]




[Now, the OCL constraint refers to class A in package Q, which can cause problems if there is no age attribute in A]




[Now the OCL constraint refers back to class A in Outer package! Class C cannot be directly referenced any more]

Issues about PackageMerge

Complex semantics

Complex side-effects

No warning of problems

No tool support

Complex behaviour when used under the presence of PackageImport

UML specification explicitly mentions it is only intended for expert modelers ("Don't do this at home")


Our proposal


A more flexible grouping schema

A group is “a set of objects with a particular relationship that characterizes either the structural relationship among objects, or an expected common behaviour”

[RM-ODP Part 2, clause 10.1]


A more flexible grouping schema

A group is “a set of objects with a particular relationship that characterizes either the structural relationship among objects, or an expected common behaviour”

[RM-ODP Part 2, clause 10.1]

Have you used Gmail grouping scheme using labels?


A more flexible Naming schema

A namespace is a set of terms usable as names (strings, icons, …)A naming context establishes the relations between names and entitiesA name is a term that refers to an entity, in a naming contextA naming action associates a name to an entityNaming contexts are named elements


[ISO 14771: ODP Naming Framework, 1999]

Some examples


“perro” = “Inglés::dog”

Name resolution

Given an identifier and a naming context, name resolution consists of finding a naming action for the identifier

context Identifier::resolve(C : NamingContext) : NamedElement body: self.namingAction->any(namingContext = C).entity

context Identifier::canResolve(C : NamingContext) : Boolean body: self.namingAction->exists(namingContext = C)

The opposite operation is not that simple

context NamedElement::name(C : NamingContext) : Identifier body: self.namingAction->any(namingContext = C).name

…the problem is that this element may not be in that naming context but in others (indirect naming).


Putting it all together


The new elements


Back to the future…

Integrating all this in UML


Packages and groups can be used together in specifications

context PackageableElement::name : Identifier

derive: self.name(self.group.namingContext))context Package inv NamesItsElements:

self.member->forAll(name = name(self.namingContext))

Groups and Packages


PackageImport

Why is there any need for PackageImport?

The need for PackageImport in UML is due to the dual nature of Packages as groups and as naming contexts, and that packages are the exclusive owners their members

PackageImport is needed be able to use an unqualified name to refer to an entity owned by another package

In our proposal it is enough to add its name to the naming context associated to the group


New import operations

context NamingContext::import (n : Identifier, e : NamedElement) : Boolean post: if (self.namingAction.name->excludes(n) and self.namingAction.entity->excludes(e)) then result = true and

self.namingAction-> includes (na | na.name = n and na.entity = e) else result = ( n.resolve(self) = e ) endif

context Group::import (n : Identifier, e : NamedElement): Boolean body: self.namingContext.import(n,e)

context Group::include ( n : Identifier ) pre: n.canResolve(self.namingContext) post: self.member->includes(n.resolve(self.namingContext))


Merging


A new semantics for Merge

It now creates a new group with the result of the mergeSide-effect freeUser-defined merging operation between elements


Conclusions

New UML grouping and naming mechanismsElements can belong to more than one groupElements can have different names in different contexts

ProsBackwards compatible with UML (almost)

Package is a kind of GroupElement names are now derived attributes

Import and Merge operations ironed outSide-effects freeClear conflict detection

Aligned with existing and mature international standards

ConsUML may ignore it…

Future workSynonyms, refinement of operation specifications, fine-tuning of constraints (e.g., name+types), tool support for operationsUML “redefines”


improving naming and grouping in uml

Documents