(This analysis trail requires unusually large quotes snippets from the UML2.1.2 and SysML specs than usually used on this eSchool.)
From SysML1.0: 15.3.2.1 Allocate(from Allocations):
Description
Allocate is a dependency based on UML::abstraction. It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level. Allocate is used for assessing user model consistency and directing future design activity. It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes.
Allocate is a stereotype of a UML4SysML::Abstraction which is permissible between any two NamedElements. It is depicted as a dependency with the “allocate” keyword attached to it.
Allocate is directional in that one NamedElement is the “from” end (no arrow), and at least one NamedElement is the “to” end (the end with the arrow).
..
Constraints
If subtypes of the «allocate» dependency are introduced to represent more specialized forms of allocation, then they should have constraints applied to supplier and client as appropriate.'
Although the swapping of client and supplier has been correctly identified in the proposed Revised Text, however it is implied that a single allocation relationship can have more than one supplier, which would seems to contradict indications elsewhere that there is only 1 'element at the opposite end of any «allocate» dependency'.
Suggest amendment to the proposed Revised Text:
Allocation to more than one supplier requires more than one «allocate» Dependency.
The example shows an Activity This (which types an Action this:This from a lower level of a decomposition of a ComplexActivity) allocated to a Block.
From SysML1.0: 15.3.2.2 Allocated(from Allocations):
'Description
«allocated» is a stereotype that applies to any NamedElement that has at least one allocation relationship with another NamedElement. «allocated» elements may be designated by either the /from or /to end of an «allocate» dependency.
The «allocated» stereotype provides a mechanism for a particular model element to conveniently retain and display the element at the opposite end of any «allocate» dependency. This stereotype provides for the properties “allocatedFrom”and “allocatedTo,” which are derived from the «allocate» dependency.'
Please note that:
There are no '/from' or '/to' attributes, only '/allocatedFrom' and '/allocatedTo'
There are no '/from' or '/to' attributes, only '/allocatedFrom' and '/allocatedTo' .
SysML1.0:
'The «allocated» stereotype provides a mechanism for a particular model element to conveniently retain and display the element at the opposite end of any «allocate» dependency'
Please note that this implies that there is only 1 ("the") 'element at the opposite end of any «allocate» dependency'.
Visit also:
Suggest the proposed resolution should be amended to:
The element types and names of the set of elements that are clients (from) of possibly many «allocate» relationships whose shared supplier is extended by an instance of this stereotype.
Please note that:
Suggest amendment of the proposed revised text:
This property is the union of all suppliers to which this instance is the client, i.e.,
there may be more than one /allocatedTo named element per allocated model element.
The /allocatedTo elements are not ncessarily properties (nor are there multiple stereotype-level properties). See 11501.
Element < DirectedRelationship < Dependency < Abstraction < Allocation
'Description
A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).
..Associations
client: NamedElement [1..*]
The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. Subset DirectedRelationship::source.
supplier: NamedElement [1..*]
The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific. Subsets DirectedRelationship::target.
..Semantics
A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements. A dependency implies the semantics of the client is not complete without the supplier. ..'
Please note that:
A good rule-of -thumb for Dependency is that the supplier must
precede - in the development or modelling process - the client. A
typical example is when resources are supplied to a client by an
element that is imported from a read-only module or library; clearly
the supplier, the one from the library, must exist first (or at least
be presumed to exist already).
Confusion for SysML allocations used to decompose a single element into many - or to refine an element - may arise because there is a sense in which the element that came first - the one that is to be decomposed or otherwise refined - "requires other model elements" for its engineering specification.
Let us assume that the Project already exists. One may then then «allocate» the HumanResource (the Dependency.client = DirectedRelationship.source) to the Project
(the Dependency.supplier = DirectedRelationship.target).