On 08/22/2006 10:56 PM, Martin Grosse-Rhode wrote:
> Dear all,
> I am trying to derive from the UML2 meta model that: A subcomponent can
> have a port. But I don't succeed in finding the association in the meta
> model that justifies this statement.
I have already been looking at this part of UML 2.0, and I can share my
I was originally also looking for a "port instance" model element - and
UML 2.0 does not have any. Neither the specification anywhere says that
there would be an implicit representation of the port on the _part_ (or
InstanceSpecification) representing the subcomponent.
Your analysis is correct, also in saying that the type of the Property may
be an EncapsulatedClassifier - but it is not guaranteed.
UML 2.0 uses a quite different mechanism to connect Ports of subcomponents
via a Connector. The Connector's ConnectorEnd is linked to the Port
owned by the part's *type* - which is not related to the particular
instance corresponding to the _part_. Then, the association partWithPort
of the ConnectorEnd is used to relate the ConnectorEnd to the _part_ of
the StructuredClassifier we are modeling.
A rather weird and complicated way of linking subcomponents.
In addition, this allows only to link ConnectableElements - which include
a Property, and a Port, but not an Interface. (This has been raised in
issues 7247, 7248, 7249 and 7251 to the UML 2.0 Finalization Task Force,
but it was deferred to the next Revision Task Force).
I have at the same time also looked at how tools implementing UML 2.0 work
around this issue. At least for Enterprise Architect, a proprietary
solution ("a hack of the metamodel") was used - when a subcomponent
instance is created (as a _part_ of a StructuredClassifier), the tool just
creates copies of all its ports. Then, connectors are linked to the
copies of the ports. While the solution does not follow the technical
aspects of the UML 2.0 metamodel, it gives its users the assumably
intended "feel" of the UML 2.0 Components specification.
I hope UML 2.0 will still evolve to a reasonably consistent specification
where such workarounds will not be necessary.
If you are interested in further details, I recommend to look at the paper
where I documented this analysis of UML 2.0 Components:
Mencl, V., Polak, M.: UML 2.0 Components and Fractal: An Analysis,
accepted to the 5th Fractal Workshop (part of ECOOP'06), July 3rd, 2006,
Nantes, France, Jul 2006, http://nenya.ms.mff.cuni.cz/publications.phtml
> Here's a more precise statement of the problem:
> A component is a StructuredClassifier. To give it a subcomponent I have
> to introduce a Property as ownedAttribute. Now I would like to attach a
> Port to this Property, but I don't find the association that would
> justify it.
> The Property is a TypedElement, so it has a Type which might(*) be an
> EncapsulatedClassifier which can have a Port. But this does not mean
> that the Property can have a Port. However, in order to connect the
> subcomponent (ownedAttribute:Property) within the component
> (StructuredClassifier), it is necessary to distinguish the "port
> instance" of the subcomponent from the Port of its Type.
> The type-association of TypedElement and Type also does not specify that
> the subcomponent would have port instances, just because the type has
> (* By the way, is there any constraint that prevents an
> ownedAttribute:Property of a StructuredClassifier to have another
> Classifier as Type, like a Signal, a UseCase, or something like this?)
> Does anyone have an explanation?
> Kind regards,
Received on Wed 23 Aug 2006 - 05:15:50 BST