9.3.13 StructuredClassifier

*Generalizations

   •

    Classifier (from Kernel , Dependencies , PowerTypes ) on page 51

*Description

   A structured classifier is an abstract metaclass that represents any classifier whose behavior can be fully or partly described by the collaboration of owned or referenced instances.

*Attributes

   No additional attributes

*Associations

Issue 8128 - add derivation symbol on ‘role’, ‘part’ and various multiplicities

• /part: Property [0..*] References the properties specifying instances that the classifier owns by composition. This association is derived, selecting those owned properties where isComposite is true.

• /role: ConnectableElement [0..*] References the roles that instances may play in this classifier. (Abstract union; subsets Classifier::feature)

• ownedAttribute: Property [0..*] References the properties owned by the classifier. (Subsets StructuredClassifier ::role, Classifier.attribute, and Namespace ::ownedMember)

   • ownedConnector: Connector [0..*] References the connectors owned by the classifier. (Subsets Classifier::feature and Namespace ::ownedMember)

*Constraints

   [1] The multiplicities on connected elements must be consistent.

*Semantics

Issue 8032 -Clarify semantics of link maintenance.

   The multiplicities on the structural features and connector ends indicate the number of instances (objects and links) that may be created within an instance of the containing classifier, either when the instance of the containing classifier is created, or in the case of links, when an object is added as the value of a role, or at a later time. The lower bound of the multiplicity range indicates the number of instances that are created (unless indicated differently by an associated instance specification or an invoked constructor function); the upper bound of the multiplicity range indicates the maximum number of instances that may be created. The slots corresponding to the structural features are initialized with these instances.

   The manner of creation of the containing classifier may override the default instantiation. When an instance specification is used to specify the initial instance to be created for a classifier (see Class on page 173), the multiplicities of its parts determine the number of initial instances that will be created within that classifier. Initially, there will be as many instances held in slots as indicated by the corresponding multiplicity. Multiplicity ranges on such instance specifications may not contain upper bounds.

   All instances corresponding to parts of a structured classifier are destroyed recursively, when an instance of that structured classifier is deleted. The instance is removed from the extent of its classifier, and is itself destroyed.

Issue 8032 -Clarify semantics of link maintenance.

   When an instance is removed from a role of a composite object, links that exist due to connectors between that role and others are destroyed.

*Semantic Variation Points

   The rules for matching the multiplicities of connector ends and those of parts and ports they interconnect are a semantic variation point. Also, the specific topology that results from such multi-connectors will differ from system to system. One possible approach to this is illustrated in Figure 9.22and Figure 9.23.

   For each instance playing a role in an internal structure, there will initially be as many links as indicated by the multiplicity of the opposite ends of connectors attached to that role (see ConnectorEnd on page 183 for the semantics where no multiplicities are given for an end). If the multiplicities of the ends match the multiplicities of the roles they are attached to (see Figure 9.22 i), the initial configuration that will be created when an instance of the containing classifier is created consists of the set of instances corresponding to the roles (as specified by the multiplicities on the roles) fully connected by links (see the resultant instance, Figure 9.22 ii).

   (i)

*Notation

   The namestring of a role in an instance specification obeys the following syntax:

   {<name> [‘/’ <rolename>] | ‘/’ <rolename>} [‘:’ <classifiername> [‘,’ <classifiername>]*]

Issue 8129 -clarify

   The name of the instance specification may be followed by the name of the role which the instance plays. The role name may only be present if the instance plays a role.

*Examples

   The following example shows two classes, Car and Wheel. The Car class has four parts, all of type Wheel, representing the four wheels of the car. The front wheels and the rear wheels are linked via a connector representing the front and rear axle, respectively. An implicit association is defined as the type of each axle with each end typed by the Wheel class. Figure 9.24 specifies that whenever an instance of the Car class is created, four instances of the Wheel class are created and held by composition within the car instance. In addition, one link each is created between the front wheel instances and the rear wheel instances.

Issue 8033 -Clarify what lack of multiplicity indicates.

    Figure 9.25 specifies an equivalent system, but relies on multiplicities to show the replication of the wheel and axle arrangement. This diagram specifies that there will be two instances of the left wheel and two instances of the right wheel (as no multiplicity is specified for the connector at the right wheel, the multiplicity is taken from the attached role), with each matching instance connected by a link deriving from the connector representing the axle. As specified by the multiplicities, no additional instances of the Wheel class can be added as left or right parts for a Car instance.

    Figure 9.26 shows an instance of the Car class (as specified in Figure 9.24). It describes the internal structure of the Car that it creates and how the four contained instances of Wheel will be initialized. In this case, every instance of Wheel will have the predefined size and use the brand of tire as specified. The left wheel instances are given names, and all wheel instances are shown as playing the respective roles. The types of the wheel instances have been suppressed.

    Finally, Figure 9.27 shows a constructor for the Car class (see Class on page 173). This constructor takes a parameter brand of type String. It describes the internal structure of the Car that it creates and how the four contained instances of Wheel will be initialized. In this case, every instance of Wheel will have the predefined size and use the brand of tire passed as parameter. The left wheel instances are given names, and all wheel instances are shown as playing the parts. The types of the wheel instances have been suppressed.

Issue 8130 - change ‘make’ to ‘createCar’

   Car

   «create» createCar(brand:String)

Issue 8028 -Modify figure: invert arrow, move <<create>>.