Issue 4736: UML 1.4: ClassifierRole contents problem (uml2-superstructure-ftf)
Source:  (, )
Nature: Uncategorized Issue
Severity: 
Summary: The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
"...specifies a restricted view of a [base] classifier.." and defines "...a
set of Features, which is a subset of those available in the base
classifier, as well as a subset of ModelElements contained in the base
classifier...".

The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
"feature" association inherited from Classifier must be empty - instead the
ClassifierRole must select features from the base classifier using the
"availableFeature" association [UML 1.4, pp. 2-121].

The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
2-121] indicating "the subset of ModelElements contained in the base
Classifier, which is used in the Collaboration". There is however *no*
restriction in the wellformedness rules restricting the ownedElements
contents of the ClassifierRole itself, meaning that a ClassifierRole can
contain the following meta-elements:

  Method   
  Attribute   
  Operation   
  Reception   
  State   
  ActionState   
  ObjectFlowState   
  Transition   
  CallState   
  Pseudostate   
  SimpleState   
  SubactivityState   
  SynchState   
  CompositeState   
  SubmachineState   
  SubState   
  FinalState   
  CallAction   
  TerminateAction   
  CreateAction   
  DestroyAction   
  SendAction   
  ActionSequence   
  UninterpretedAction   
  ReturnAction   
  ExtensionPoint   
  Stimulus   
  Parameter   
  Permission   
  UseCase   
  ProgrammingLanguageDataType   
  StateMachine   
  Comment   
  LinkObject   
  Enumeration   
  Association   
  Dependency   
  ClassifierInState   
  SignalEvent     
  Constraint   
  NodeInstance   
  Usage   
  Signal   
  Actor   
  Interface   
  Component   
  Link   
  Primitive   
  Collaboration   
  SubsystemInstance   
  ChangeEvent   
  Generalization   
  Stereotype   
  Subsystem   
  TagDefinition   
  Abstraction   
  Extend   
  ActivityGraph   
  Flow   
  UseCaseInstance   
  DataType   
  Object   
  Class   
  TimeEvent   
  ComponentInstance   
  Exception   
  Include   
  CollaborationInstanceSet   
  AssociationClass   
  CallEvent   
  Binding   
  Package   
  Node   
  Artifact   
  Model   
  DataValue   
  TaggedValue

So the question is: is this lack of restriction intentional? And if so, why
are ownedElements handled differently from features? And what is the
semantic difference between entities selected using the "availableContents"
association and those contained directly?

Resolution: 
Revised Text: 
Actions taken:
December 5, 2001: received issue
March 9, 2005: closed issue
Discussion: 
The modeling of collaborations has changed substantially in UML 2.0. In particular,
classifier roles are now represented as parts of the internal structure of a collaboration.
Their “contents” is specified by their type, which is an ordinary classifier, and all
restrictions are inherited from classifier. The instance playing the role must possess the
properties specified by the classifier typing the role. Disposition: Closed, no change
End of Annotations:=====
From: Thomas Schaumburg <thomas.schaumburg@hiq.dk>
To: "'issues@omg.org'" <issues@omg.org>
Subject: UML 1.4: ClassifierRole contents problem
Date: Wed, 5 Dec 2001 15:46:19 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: <e=!!h4l!!T0I!!4djd9

The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
"...specifies a restricted view of a [base] classifier.." and defines
"...a
set of Features, which is a subset of those available in the base
classifier, as well as a subset of ModelElements contained in the base
classifier...".

The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states
that the
"feature" association inherited from Classifier must be empty -
instead the
ClassifierRole must select features from the base classifier using the
"availableFeature" association [UML 1.4, pp. 2-121].

The ClassifierRole also has an "availableContents" association [UML
1.4, pp.
2-121] indicating "the subset of ModelElements contained in the base
Classifier, which is used in the Collaboration". There is however *no*
restriction in the wellformedness rules restricting the ownedElements
contents of the ClassifierRole itself, meaning that a ClassifierRole
can
contain the following meta-elements:

  Method   
  Attribute   
  Operation   
  Reception   
  State   
  ActionState   
  ObjectFlowState   
  Transition   
  CallState   
  Pseudostate   
  SimpleState   
  SubactivityState   
  SynchState   
  CompositeState   
  SubmachineState   
  SubState   
  FinalState   
  CallAction   
  TerminateAction   
  CreateAction   
  DestroyAction   
  SendAction   
  ActionSequence   
  UninterpretedAction   
  ReturnAction   
  ExtensionPoint   
  Stimulus   
  Parameter   
  Permission   
  UseCase   
  ProgrammingLanguageDataType   
  StateMachine   
  Comment   
  LinkObject   
  Enumeration   
  Association   
  Dependency   
  ClassifierInState   
  SignalEvent     
  Constraint   
  NodeInstance   
  Usage   
  Signal   
  Actor   
  Interface   
  Component   
  Link   
  Primitive   
  Collaboration   
  SubsystemInstance   
  ChangeEvent   
  Generalization   
  Stereotype   
  Subsystem   
  TagDefinition   
  Abstraction   
  Extend   
  ActivityGraph   
  Flow   
  UseCaseInstance   
  DataType   
  Object   
  Class   
  TimeEvent   
  ComponentInstance   
  Exception   
  Include   
  CollaborationInstanceSet   
  AssociationClass   
  CallEvent   
  Binding   
  Package   
  Node   
  Artifact   
  Model   
  DataValue   
  TaggedValue

So the question is: is this lack of restriction intentional? And if
so, why
are ownedElements handled differently from features? And what is the
semantic difference between entities selected using the
"availableContents"
association and those contained directly?



Discussion:
The modeling of collaborations has changed substantially in UML 2.0. In particular, classifier roles are now represented as parts of the internal structure of a collaboration. Their "contents" is specified by their type, which is an ordinary classifier, and all restrictions are inherited from classifier. The instance playing the role must possess the properties specified by the classifier typing the role.
Disposition:	Closed, no change