[Modeling] Class & roles

James Odell email@jamesodell.com
Sat, 21 Jun 2003 17:52:57 -0400

Hi Hong,

> I would like to distinguish class from role as follows. Class is a language
> facility that has well-defined structure and senamtics, while role is an
> abstract concept that different people may have different understanding.
> However, the concept of roles helps the analysis and design of systems. It
> can be implemented by classes. Therefore, in my opinion, there is no need to
> include a concept of role in the meta-model.

UML  2.0 defines a the classifier Class as follows:
A class describes a set of objects that share the same specifications of
features, constraints, and semantics.

Class is a kind of classifier whose features are attributes and operations.
Attributes of a class are represented by instances of Property that are
owned by the class. Some of these attributes may represent the navigable
ends of binary associations.

The purpose of a class is to specify a classification of objects and to
specify the features that characterize the structure and behavior of those
Objects of a class must contain values for each attribute that is a member
of that class, in accordance with the characteristics of the attribute, for
example its type and multiplicity.
When an object is instantiated in a class, for every attribute of the class
that has a specified default, if an initial value of the attribute is not
specified explicitly for the instantiation, then the default value
specification is evaluated to set the initial value of the attribute for the
Operations of a class can be invoked on an object, given a particular set of
substitutions for the parameters of the operation. An operation invocation
may cause changes to the values of the attributes of that object. It may
also return a value as a result, where a result type for the operation has
been defined. Operation invocations may also cause changes in value to the
attributes of other objects that can be navigated to, directly or
indirectly, from the object on which the operation is invoked, to its output
parameters, to objects navigable from its parameters, or to other objects in
the scope of the operation¹s execution. Operation invocations may also cause
the creation and deletion of objects.


No where in this does it mention "implementation" or indicate that it is a
"language facility."

Moreover, UML has a stereotype called «implementationClass» whose definition
"The implementation of a class in some programming language (e.g., C++,
Smalltalk, Java) in which an instance may not have more than one class. This
is in contrast to Class, for which an instance may have multiple classes at
one time and may gain or lose classes over time, and an object (a child of
instance) may dynamically
have multiple classes.
An Implementation class is said to realize a Classifier if it provides all
of the operations defined for the Classifier with the same behavior as
specified for the Classifier's operations. An Implementation Class may
realize a number of different Types. Note that the physical attributes and
associations of the Implementation class do not have to be the same as those
of any Classifier it realizes and that the Implementation Class may provide
methods for its operations in terms of its physical attributes and

I hope this helps.  It is important not to confuse OO with the
implementation of OO.