SysML1.0 10.3.2.1 ConstraintBlock:
'All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks.'
SysML1.0 8.3.2.2 Block
'. SysML establishes three standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classifed as a part property. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property.'
Some examples of the MD SysML ConstraintParameter (including some provocative ones outside SysML).
Illustration of the problem statement only. In MD SysML a Port usually can't be displayed on a constraint property anyway unless stereotyped as a ConstraintParameter.
(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).
Add a constraint:
[3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'.
SysML1.0, 10.3.2.2 ConstraintProperty:
'A constraint property is a property of any block that is typed by a constraint block.
..
[2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock.'
These may both misinterpreted as applying to "any block that is typed by a constraint block" and "a SysML Block that is typed by a ConstraintBlock" rather than a constraint property typed by a constraint block. Rewrite so that the type condition clearly applies to the owned constraint property, not the owning block, thus:
'A constraint property is a property that is typed by a constraint block and is owned by a block.
.
[2] The ConstraintProperty stereotype must be applied to any property that is typed by a ConstraintBlock.'
(Note that the first constraint already makes it clear that a constraint property is owned by a SysML Block: [1] A property to which the ConstraintProperty stereotype is applied must be owned by a SysML Block.)
SysML1.0, 10.3.1.2 Parametric Diagram:
'Small square box notation for an internal property
A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a value property may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of property boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where an internal property box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the innermost property.'
It is not clear whether 'value property' here is meant to refer to a constraint parameter. Also, the term 'internal property' does not exclude, for example, nested constraints, leaving open the possibility of drawing nested constraint properties using square box notation, which is surely not intended.
The following suggests that only constraint parameters - not value properties - are intended:
SysML1.0, , 10.3.2.1 ConstraintBlock:
'[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, binding connectors between its internally nested constraint parameters, constraint expressions that define an interpretation for the constraint block, and general-purpose model management and crosscutting elements.'
Rewrite SysML1.0, 10.3.1.2 Parametric Diagram, replacing all references to 'value property' and 'internal property' with 'constraint parameter':
'Small square box notation for a constraint parameter
A constraint parameter may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a constraint parameter may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of constraint parameter boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where a constraint parameter box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the constraint parameter.'
SysML1.0, 10 Constraint Blocks:
'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint.'
The above does not make clear that parameters are properties that can be typed by a ValueType (yet are not value properties), and it does not exclude nested contraints, which are properties typed by a <<ConstraintBlock>> (although other sentences elsewhere in the specification do make that clearer). Also, it is not clear whether a constraint parameter can be typed by a block (although there are no examples of such in the figures).
Rewrite to specify what constraint parameters are:
'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block typed by a ValueType, Unit, or DataType define the parameters of the constraint.'
SysML1.0, 10.3.2.1 ConstraintBlock:
'.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.'
Rewrite to explain what constraint parameters are:
'.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. Constraint parameters are properties of a Constraint Block that are typed by either a ValueType, a Unit, or a DataType.'
(NB: the resolutions suggested here depends on the unit, value, dimension metamodel being changed to admit the application of Unit as a type.)
This matter could be greatly simplified by including a ConstraintParameter stereotype as a point of documentation and specification.
Compare with Figure B.26 which shows 'delta-t::GlobalTime' with AggregationKind 'none' within EconomyContext.