(11066) Namespace compartment for blocks

MD SysML example supporting suggested resolution "closed no change".

In most tools users are free to compose systems using the SysML IBD (UML2 composite structure) first or a SysML BDD (UML2 class diagram). In the better tools one can move freely between the two, and the composition aspects are mapped bijectively (except owned Connectors and ItemFlows with itemProperty only appear in an IBD).

It is true that in the sample problem the BDDs seem to come first, however that is not in my experience the best way to handle structural composition !

I recommend:

• create a "focus" BDD for each and every block in the system, independent of its usage context
  • In MD one can also use the structure compartment for a "hybrid" view of the parts, see below
• build progressively complex assemblies using IBDs and connections
• AFTERWARDS generate the corresponding associations in the focus BDDs (if you wish)
• if you really want to, create a BDD with the "associative composition" structure:
  • that BDD is not used to build the system, it is merely a view of what was already built

In MD SysML you can show the structure compartment to create a "hybrid" diagram, which is very useful, if admittedly not standard SysML (yet). One can't show the connectors in a BDD anyway, so "associative composition" really is a very limited view of the composition anyway. UML2 composite structure was a blessing !

Note in the example below:

• each property has been shown 3 different ways: as an attribute, as the end of an Association, and as a symbol in the structure compartment.
• the composed structure has been shown in the "hybrid diagram" structure compartment (non-standard)
• you can't show the Connector between property s:Source and t:Target, and you also can't show the ItemFlow v:Stuff
• in the structure compartment you can show the "initial values" vectors (a.k.a defaultValue compartment, hopefully to be renamed 'initial values')
  • in the BDD one would have to show the initSource: Source and initTarget:Target instance "vectors" that initialise the corresponding parts as instance to see the values, the values of the Slots can't be seen in Property.defaultValue area of the Property in the attributes box alone
• The Source block is - just for discussion here - an /ownedElement of (and an /ownedMember) of the Namespace StructuredBlock
  • it is also used as a part of StructuredBlock, however - since public - it could just as well be reused as a part elsewhere
    • the ownership of Source within the Namespace has nothing per se to do with its usage as part Property
  • if Source were not publically owned within the Namespace it would be be used to define a local class referenced only in a local context.

The Target block - by contrast - is not an /ownedElement of StructuredBlock, although it is used as a part

• Target could just as well come from a read-only library of reusable blocks.

---

Blocks are never "owned by composition", they are only used as properties by composition:

• StructuredBlock above "owns" Source just because I organised the model that way; it then participates In a local usage s:Source

• Target above is not owned by StructuredBlock, however the usage as Property t:Target is.

---

I really do advise against using composition associations extensively:

• they can't show all the information anyway
• they are graphically very fragile compared with composite structure using connected property symbols.
• you can't show the 'initial values' "vectors" for the property-specific initial values (only the name of an assigned InstanceValue)

I therefore recommend against the suggestion of a BDD-like compartment in a Block.

(11275): 8.3.2: Unit/Dimension Notation "to underline or not to underline"

Relates to:

Issue 12128: Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute
Issue 12219: Section: 08 Blocks: suggest need Quantity stereotype and definition

---

Proposed resolution:

'Unit and Dimension elements are defined using a rectangular box notation similar to a class, in which only the «unit» or «dimension» stereotype keyword, the name of the Unit or
Dimension, and optionally the “dimension” property value of a Unit may appear.'

MD SysML achieves this by NOT extending InstanceSpecification (see image below) !

The MD SysML <<Unit>> and <<Dimension>> both extend DataType

The resolution states:

the notation that SysML defines for Dimension and Unit differs the standard UML notation for InstanceSpecification

Which is just one reason not to choose Unit [InstanceSpecification] and Dimension [InstanceSpecification]..

Unit and Dimension elements are defined using a rectangular box notation similar to a class

Which is one reason for indeed choosing the "Class-like" DataType as base for Unit and Dimension
(even though one then has to restrict Dimension to not be used as a type).

I would already reject the proposal resolution on the basis of this text:

Even though the base metaclass of Unit and Dimension is InstanceSpecification

because I reject that metamodel.

In fact a Unit can only be sensibly modelled as "a special kind of Quantity", on in which values of quantities with a chosen unit may be stated. Unit must extend Quantity ! Please visit (and please view the metamodel images carefully):

• http://school.nomagic.com/*Quantity
  • http://school.nomagic.com/files/images/Quantity_0.jpg
• http://school.nomagic.com/*Unit

Unit is (like ValueType) well modelled as a DimensionedType [DataType] (and can be used to type directly for the unitary case):

• http://school.nomagic.com/*DimensionedType

This leaves however Dimension open to have a different base metaclass from Unit, however then (given that the notation is supposed to be the same) this is hard for UML-based tool vendors.

The observation that the notation needs to be clarified is correct, however binding it to the specific metamodel is not necessary.

(11493) Lack of notation for units and dimensions on values

There is a fundamental flaw with the practice of using the ValueType to indicate a Unit's symbol:

(11622) Mapping of PropertySpecificType to the UML metamodel

The following trail analyses a proposed resolution snippet (supported by snippets from SysML1.0):

'The PropertySpecificType stereotype is automatically applied to the classifier which types a property with a property-specific type. This classifier can contain definitions of new or redefined features which extend the original classifier referenced by the property-specific type.

Classifiers with the PropertySpecificType stereotype are owned by the block which owns the property which has the property-specific type. A classifier with this stereotype must specialize at most a single classifier which was referenced as the starting classifier of the property-specific type. If there is no starting classifier (which occurs if no existing name is specified as the starting type of a property-specific type), then a classifier with the stereotype applied has no specialization relationship from any other classifier.'

Firstly, the system for which an additional "redefinition context" is to be provided is given as a simple IBD, with regular types and properties:

To evoke the impression of property-specific types in MD SysML15.1 (in place of implied property-specific types) we introduce explicit [PropertySpecificType] classifiers for illustration:

Then (see below) an IBD with redefinition of types and their properties (all in a given redefinition context for the system) can be shown:

(12126) 8 Blocks, There are at least 4 kinds of properties of blocks: parts, references, values, constraints

Constraint properties do not take part in the assembly hierarchy of blocks. Although they are of type <<Block>> via <<ConstraintBlock>> and have AggregationKind 'composite' they should not be considered "parts".

SysML1.0, 8 Blocks:

A block can include properties to specify its values, parts, and references to other blocks.

Rewrite to include constraint properties:

A block can include properties to specify its values, parts, references to other blocks, and constraint properties.

SysML1.0, 8.3.1.2 Internal Block Diagram, Property types:

Three general categories of properties are recognized in SysML: parts, references, and value properties

Rewrite to include constraint properties:

Four general categories of properties are recognized in SysML: parts, references, value properties, and constraint properties.

SysML1.0, 8.3.2.2 Block, Description:

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 ValueTyp is classified as a value property. Part, reference, and value properties may be shown in block definition compartments with the labels “parts,” “references,” and “values” respectively. Properties of any type may be shown in a “properties” compartment.

Rewrite to include constraint properties:

SysML establishes four standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classified as a part property (excluding constraint properties, which are typed by a Constraint Block). 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. Part, reference, value properties, and constraint properties, may be shown in block definition compartments with the labels “parts,” “references,” “values”, and "constraints" respectively. Properties of any type may be shown in a “properties” compartment.

Note also minor spelling correction: classifed -> classified.

(12127) 8.3.1.2 Internal Block Diagram: p.40: assert that value properties must be owned with AggregationKind 'composite'

This would be consistent with the following from 8.3.1.2 Internal Block Diagram, Property types:

".. A part or value property is always shown on an internal block diagram with a solid-outline box. A reference property is shown by a dashed-outline box, consistent with UML .."

Rewrite to include assertion that value properties must always be owned with AggregationKind 'composite':

".. A part or value property has AggregationKind 'composite' and is always shown on an internal block diagram with a solid-outline box. A reference property has AggregationKind 'none' or 'shared' and is shown by a dashed-outline box, consistent with UML .."

(Please note also that this case also illustrates why it would be useful to have a clear stereotypes like ValueProperty throughout the SysML specification, as it affords a canonical point of documentation for such assertions and constraints.)

(12128) Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute

This strategy provides a compact and elegant metamodel for the units and values, and expresses well the underlying physical and mathematical principles of a dimensioned quantity represented by a value subject to chosen units.

Value properties can then be sensibly typed by either a Unit or a ValueType.

In the case where a ValueType has a Unit, the constraint still applies that the dimension of the ValueType must be the same as the dimension of the Unit.

(12219) A stereotype for a Quantity is required.

The current Unit, Value, Dimension system in SysML is incomplete without the crucial concept of quantity. A physical or industrial Quantity is independent of a choice of unit and value as measured or stated. A Quantity has a Dimension, which can be fundamental (as in the SI system), or derived (according to industrial needs).

A Quantity DOES NOT have a Unit, and it DOES NOT have a relationship to a given unit systems, although it may be allocated a default unit within a given system.

The statement/measurement of a Quantity is given as a value relative to a chosen Unit.

A Quantity is represented in SysML by a value property (typed currently by a ValueType, although a strong case can be made for typing a value property directly by a Unit).

(12353) 8.2.2 Internal Block Diagram: "initialValues" compartment should be complemented by "values" compartment in same IBD

As discussed at the OMG TM SysML RTF on Th 13Mar2008.

Assumes the property-specific 'defaultValue' compartment has been renamed to 'initialValue' (or perhaps 'initialValues'), as suggested in a previous issue submission.

The case of a property-specific 'initialValues" compartment (as in Table 8.3 - Graphical nodes defined in Internal Block diagram) and also deeply nested "initial values" is well complemented by a "values" or "currentValues" compartment, as illustrated for the test results in Figure 8.11 - SUV EPA Fuel Economy Test.

Together, the "initialValues" and "values" compartments illustrate usefully the evolution of the value state of a system used within an additional top-level "value slice" context. Tool vendors would be free to show one, both, or none of these two complementary compartment in part Properties of an IBD.

This strategy promotes progress towards animation of systems, and also enables comparison of special configurations with an "intial" configuration.

This suggestion represents a useful unification of concepts already present in the SysML specification.

 

(12361) 08 Blocks, 8.2.2 Internal Block Diagram, the 'defaultValue' compartment should be renamed 'initial values',

As discussed at the OMG TM SysML RTF on Th 13Mar2008.

The 'defaultValue' compartment should be renamed 'initial values' (two words, with plural for values).

The static (class level) default values of a given Block's Properties may be overridden on instantiation and initialization of a part Property usage of that Block by the using context.

The concept of "initial values" is more consistent with the programmatic practice, and it serves to highlight the difference between the UML2 defaultValue (of a Property within a class) and the (re)initialisation of a SysML value Property on usage of that value's Block as a part Property within a higher context, by assignment of a property-specific initial value.

The label 'initial values' is also consistent with the UML2.1.1 specification description of the role of the defaultValue attribute of 7.2.44 Property:

"If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property."

Further, the concept of "initial values" emphasises the evolving value state of a system. The "initial value" is then merely a single value slice within a series of values states.

Configuration is a special case of "initial value". Example: when a Car leaves a factory it is "initialised" to a luxury, sports, or family configuration.

The concept of "initial value" compartment is complemented by the suggestion of a "current values" or simply "values" compartment for recording the value state of an evolving system. (See related issues submitted by Darren Kelly.)

This suggestion promotes support of animation of SysML systems, and also encompasses aspects of static configuration consistently.

(12363) The 'values' compartment for a part Property in an IBD should be decoupled from PropertySpecificValue

There should be a definition of the role of the 'values' compartment for display of "current values" (for representing the entire value state of a system within a unique value context) and/or "deep configuration" values indepedendent of the PropertySpecificType concept, which may be seen as only one possible way of carrying values for assignment to the 'values' compartment in and IBD.

Another strategy employing values in Slots of InstanceSpecifications that are related to targeted part Properties by a Property[*] path and then mapped to the targeted part Properties would achieve the same 'values' idiom in and IBD without indication of the implied subtype using [brackets].

When the 'values' are carried by redefined defaultValue : ValueSpecification[0.1] of redefined properties of an implied [PropertySpecificType] the bracket notation should still be used (inviting also indication of other redefinitions that can't be achieved using mapping of InstanceSpecifications, such as operation and constraint redefinitions).

In particular, the following paragraph from p.53 (illustrated in Figure 8.11 - SUV EPA Fuel Economy Test) should be rewritten to admit other solutions:

"In SysML, one approach is to capture system configurations by creating a context for a configuration in the form of a context block. The context block may capture a unique identity for the configuration, and utilizes parts and part-specific types to express property design values within the specification of a particular system configuration. Such a context block may contain a set of parts that represent the block instances in this system configuration, each containing specific values for each property. This technique also provides for configurations that reflect hierarchical system structures, where nested parts or other properties are assigned design values using property-specific types. The following example illustrates the approach.":

While Figure 8.11 - SUV EPA Fuel Economy Test could remain with [PropertySpecificType] notation as an indication of that strategy, there should be an equivalent figure showing the same 'values' compartment and a similar top-level value context block, however without the [brackets] notation on part types, and without any reference to the PropertySpecificType solution. The title of Figure 8.11 should be clearly marked to indicated use of the PropertySpecificType solution and notation.

(12364) It should be clearly stated whether DistributedProperty may only be applied to a value property

On p.46 under 8.3.2.4 DistributedProperty it is stated that:

'[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.'

It does not however state whether a DistributedProperty [Property] within a Block may only be applied to a value property (a "block property" typed by a ValueType or DataType) or other Property variations. All examples of the application of DistributedProperty show it applied to a value property.

This has implications for sorting into block compartments in BDDs; if a DistributedProperty [Property] may only be applied to a value property then it will always be sorted into the 'values' compartment.

It also has implications for aggregation; since a value property (within a block) must have AggregationKind 'composite', a DistributedProperty will also have AggregationKind 'composite' (within a block).

(12365) If a DistributedProperty may be applied to a property within a structured ValueType, then an example should be provided

On p.46, under 8.3.2.4 DistributedProperty it is stated that:

'[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.'

There are however, as far as I can tell, no examples of a DistributedProperty or specialisation thereof applied to a property that is not within a block.

A candidate example might include a variation on a Complex <<ValueType>> (cf. Figure 8.7 - Model Library for Blocks) with distributions applied to the real and imaginary parts (being represented by properties, and thus admitting application of the DistributedProperty stereotype, or substereotype).

-------------------------------------------------------------
<<ValueType>>
StrangeDistributedComplex 
-------------------------------------------------------------
<<Uniform>> {min=-10, max=10} realPart : Real
<<Uniform>> {min=-12, max=12} imagPart : Imag 
-------------------------------------------------------------

Collate <<system>>, <<system context>>, <<external>>, <<domain>>, <<subsystem>> as non-normative ex

It is not enough to refer simply to (p.180):

'The «system» and «external» stereotypes are user defined, not specified in SysML,'

Although already raised as Issue 12257, this new Issue submission (by a different submitter) makes the constructive suggestion that the 'user defined' stereotypes by defined in non-normative extension Section in the Annex C.

It is not acceptable that a specification dedicated to systems engineering does not even have at least a well-defined non-normative definition of a <<system>> and <<system context>> ! These need to be upgraded to a non-normative Annex, and then introduced properly through the example.

I see no reason why the figures should not use non-normative stereotypes as long as they are defined in an Annex and clearly. This is not the case for:

<<system context>>, <<system>>, <<external>>, <<domain>>, <<subsystem>>,

yet these are truly crucial for even basic systems engineering, and the examples (which use them well) make little sense without them.

There is a very nice summary of C.2 Requirements Diagram Extensions. and those requirement categories have proved very useful already.

I have made a small summary and guide here:

http://school.nomagic.com/node/396

Block extensions (non-normative)

As recommended through SysML1.0 examples:

• «system» top-level block to be used in a system context
• «subsystem» grouping (usually physical) within a system
• «external» outside the top-level system (yet affecting it)
• «domain» provides a common context for a system and externals
• «system context» a particular context for a system and externals

Note my definitions for <<domain>> vs. <<system context>>.

I suggest that at least «system context» should have an attribute:

system:<<system>>[1]

<<domain>> could then extend <<system context>>.

OMG SysML RTF: proposal by Darren Kelly for unified "value slice" system for initialisation, configuration, and animation

In MD SysML the technique illustrated here must be supplemented by Dr Darren's <<BlockPackage>>/<<BlockModel>> concept, since (consistent with the UML2.1.2 spec.) MD SysML does not permit the ownership of InstanceSpecifications by a block, and so a <<ValueSlice>> block can't own the <<Values>> InstanceSpecifications it "manages". It turns out this has some benefits; it makes sense to package all engineering data, and even icons and images, together with the owned <<Block>>. This scales well to <<TimeSlicePackage>> for a <<TimeSlice>> block, and to a <<ConfigurationPackage>> for a <<Configuration>> block.

Note that in the diagram below the <<Values>> are indicated as being under shared aggregation by their <<ValueSlice>> Block, although they must actually be owned by the <<ValueSlicePackage>> that also owns the <<ValueSlice>> Block. This emphasises that the <<ValueSlice>> manages the <<Values>> and applies them to the root part (the Block usage) and that Block's deeply nested parts, although the <<Values>> are owned by a BlockModel or BlockPackage.

---

Thanks are due to Nerijus Jankevicius, Alain Isoz and the MD SysML Team for input and collaboration on this evolving proposal.

OMG SysML RTF: proposal by Dr Darren Kelly for Quantity profile/metamodel [WORK IN PROGRESS]

This trail represents a significant proposed revision and enhancement of the SysML metamodel/profile for representation of physical and industrial quantities with a stated/measured value relative to a unit, within a given quantity and dimension system.

The proposal combines:

• experience modelling real-world systems - such as scientific instruments with known physical parameters and enginering data. - with SysML1.0
• experience with the MD SysML Plugin tool, including conformance analysis and collaboration with the MD SysML Plugin team
• customer feedback on difficulties employing the Unit, Dimension, ValueType approach of SysML1.0
• formal issues submitted to the OMG SysML1.0 RTF, especially prior to the OMG Technical Meeting, 10-14 Mar 2008, Washington DC
• discussions from the SysMLRTF sessions of the OMG Technical Meeting, 10-14 Mar 2008, Washington DC
• detailed analysis of the sample problems and diagrams of the SysML1.0 specification
• consideration of the need to support efficient assignment of value states for complex assemblies
• a detailed parsing and analysis of the following authoritative metrology reference into an illustrative UML profile:
  International Vocabulary of Metrology – Basic and General Concepts and Associated Terms (VIM) 3rd edition

Visitors please note well:

• In order to understand the justifications and rationales for this proposed SysML Quantity metamodel you SHOULD examine, in turn, every page of the UML Parsing Analysis of VIM.
• Concepts introduced specifically for the SysML Quantity metamodel proposal (which find no equivalent in the VIM reference) are at the top-level of this trail, not within the UML Parsing Analysis of VIM. Examples include:
  • *DimensionedType
  • *QuantityProperty
  • *UnitProperty
  • *ValueProperty

• Pages marked with [brackets] represent either incubating pages, or concepts that have not yet been mapped to this SysML Quantity metamodel
  proposal.

---

[Suggest show both part-specific values & static values "showing through" to part within a value context with static indicator]

Follows on from last night's SysML RTF telecon 09 Apr 2008. Elaborates on an original, quite super idea from Rick Steiner for indicating two types of values (class-level and context-specific) in one IBD compartment.

At first the idea was to use the whole values compartment for EITHER context-specific OR class-level values, with an indicator to show which mode the compartment is in. Then I suggested instead using an indicator per-property, so that only those values which have been explicitly assigned in the values context are set, with the class-level values "showing through" to the part with an indicator. We discussed an appropriate notation to indicate which values are specific to a part and which are "inherited" from the underlying type.

Am using a BDD in the diagram below to mimic an IBD so can illustrate this "translucency" effect, (which Rick compared with "inheriting" some values while redefining others). The part:Type shown below would be a part Property in an IBD in a particular value context.

If no value is given for a value property v1 for part:Type typed here by the block Type then the primitive "static (class-level)" Property.defaultValue (in this case 2.1) shows through. To indicate that the value is in this sense "static" it is underlined (in the values compartment of the part in an IBD).

If a value is explicitly set for another value property v2
(only) for part:Type typed here by the block Type then that particular value (in this case v2=3.2) is shown in the values compartment for the part, and it is not underlined, since "instance-like". Note that in this case the context specific value (v2=3.2) overrides the "static" Property.defaultValue 0.5 (which v2 had in the Type).

This would solve a heap of implementation problems and would help resolve confusion about the meaning of a values comparment on a part in an IBD. As an educator I really like this underline notation and hybrid compartment idea. It blends very well with other conventions for UML and for programming.

[The sorting of DistributedProperty applied to a ValueProperty or a Block into SysML block compartments should be specified]

On  p.46 under 8.3.2.4 DistributedProperty it is stated that:  '[1] The DistributedProperty stereotype
may be applied only to properties of classifiers stereotyped by Block or ValueType.'

It is not clear what SysML compartment a DistributedProperty should be sorted into.

If it mayn only type a value property then it will be sorted into values. See related issue.

(10059) 'Interfaces on Flow Ports': Recommend use nested ports

Issue example:

'For example, I could use communicate in morse code over a hydraulic line.
This would be modeled normally as a standard (service) port, except for the medium.'

Handled here using nested ports in MD SysML.

One could optionally conjugate one of the standard ports to emphasise asymmetric connections. 

(10342) 'Section: 9.3.2.8 ItemFlow'

There are genuine issues concerning the inability to type an ItemFlow.itemProperty[0..1] by a Signal (see metamodel analysis bottom).

The diagram below shows three different usages of the ItemFlow label on a Connector:

• InformationFlow showing Signal as conveyed:Classifier, matching the flowports
• ItemFlow.itemProperty typed by a ValueType (can't match Signal)
• ItemFlow.itemProperty typed by a Signal (breaks SysML1.0 constraints)

(10371) RECOMMEND: use both default value "callout" into a note and 'initial values' compartment in an IBD

In MD SysML you can callout a default value of FlowPort into a Note.

This can be combined with the initial values (SysML1.0 defaultValue) compartment in a higher context
to display both a class-level and property-specific initial values for a flowport typed by a ValueType.

(11599) "Fix for Fig 9.4 p70"

I suggest use 'put' as shown:

Visit also:

• Figure B.20 - Interfaces Typing StandardPorts Internal to the Power Subsystem (ICE Interface Definitions)
• Figure B.19 - Internal Structure of the Power Subsystem (Alternative 1 - Combined Motor Generator)

(11628) Consider nested ports

---

(12222) 9.3.2.3 FlowPort, 9.3.2.7 Standard Port: formally permit useful idiom of flowport nested within standard port

Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures.

Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module.This example is illustrated in detail at:

(12222) flowports nested within standard ports

Visit also:

• HOWTO use nested flowports within standard ports to model logical channels

(10524) Constraint parameter stereotype

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).

(11495) Constraint parameter notation conflicts with UML private ports notation

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.

(11501) Wrong ends of Allocate relationship used in Allocated definition

(This analysis trail requires unusually large quotes snippets from the UML2.1.2 and SysML specs than usually used on this eSchool.)

(12129) 10.3.2.2 ConstraintProperty: add constraint that the AggregationKind must be 'composite'

Add a constraint:

[3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'.

(12130) ConstraintProperty: rewrite constraint [2] so does not refer to 'a SysML Block that is typed by a ConstraintBlock'

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.)

(12131) 10.3.1.2 Parametric Diagram: clarify applicability of square box notation to constraint parameters (or otherwise)

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.'

(12132) 10 Constraint Blocks and 10.3.2.1 ConstraintBlock: parameters never clearly defined

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.

(12160) Figure 10.3: 'delta-t' shown with solid-line (AggregationKind 'composite'), not dashed line (AggregationKind 'none')

Compare with Figure B.26 which shows 'delta-t::GlobalTime' with AggregationKind 'none' within EconomyContext.

(12134) «rate» stereotype has property 'rate' type ValueSpecification in 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8

SysML1.0, 11.3.2.8 Rate:

'The «rate» stereotype has a rate property of type ValueSpecification.'

However Figure 11.8 shows 'rate' with type InstanceSpecification.

(Also, the 'rate' property should be clearly defined as an Attribute of <<rate>> in 11.3.2.8 Rate.)

 

Figure 11.10 - Continuous system example 1: many issues:

From SysML1.0: Figure 11.10 - Continuous system example 1:

Table 11.1 and Table 11.2: appear to contradict constraint that <<discrete>> and <<continuous>> should not be both applied

SysML 1.0, 11.3.2.3 Discrete:

[1] The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.

However Table11.1 and Table 11.2 Rate examples appear to show both «discrete» and «continuous» applied to the same element at the same time, and Table 11.1 appears to show overloaded tagged values {rate=constant} and {rate=distribution}.

Resolution: change Table11.1 and Table 11.2 to show dedicated examples of «discrete» and «continuous» stereotype usage.

 

TODO 11.3.1.2 CallBehaviorAction: recommend strict colon for :Behavior or none for named with no Behavior

I do not recommend using the Behavior name EVER without a colon, as can be confused with action name.

Prefer:

• always use Colon in combination with anonymous Actions
• no colon implies (strictly) a named Action

TODO Permit UseCase <<subsystem>> from UML