Decomposition of Activity HigherActivity (Pins owned as objects)

Note correspondence to in/out Pin pair, two properties are NOT owned by HigherActivity as an "ObjectNode".

Decomposition of Activity HasObjectNode_AVOID_THIS

Corresponds with SysML1.0 examples, a single object appears to be owned by the usage context.

In fact a UML2 ObjectNode is abstract. Although the apparent ownership of an object by the higher activity context is consistent, it can't be represented using "elided Pin notation" in the activity diagram by MagicDraw UML.

Decomposition of Activity DecomposeMe (default result from Activity Decomposition Wizard)

Project settings (please note carefully):

• The option show navigabilityis false for every Association end (all 6 of them)
  (inspection shows all 6 generated properties are non-navigable).
• Global project option enable dot notation for Associations is true.

Only some Comments have been added to this diagram as generated by the wizard. Because project option enable dot notation for Associations is on we can tell that the generated part properties are NOT owned by the Classifier DecomposeMe (because there are no dots showing at the association ends).

Decomposition of Activity DecomposeMe: TUNED: ownership of the generated properties altered using navigability

Project settings (please note carefully): 

• The global project option Change ownership of non-navigable association ends when changing navigability is set true.

• The global project option Enable dot notations for associations is set true.

• The option show navigability is set true for every Association end (all 6 of them).

By contrast, the navigability of the Association end for Property b2 was left unchanged, it is still owned by the generated Association.

HOWTO define a custom ValueType to indicate a chosen Unit

You may use a ValueType to indicate and assign a specific Unit (with a Dimension) to a ValueProperty, which represents a named quantity. The value of the quantity is then stated (or measured) relative to that Unit (see the example default value statements). The ValueType is usually named after the symbol of it's fixed Unit.

• The Dependencies in this diagram are for illustration only; they are not needed to define the Unit and Dimension of a ValueType. Just use the specification dialog.
• The examples here have been denoted «unit-like» for illustration only.

HOWTO define a custom ValueType as a system-wide "kind of quantity" (or after its Dimension)

You may use a ValueType to define a "kind of quantity" that is not bound to a specific block. In the example below, the ClockFrequency ValueType is defined for an entire system. It may then be used to type a specific ValueProperty representing a specific quantity in a block, such as the frequency of a Processor. In this case, the ValueType is named to indicate the kind of quantity (rather than the symbol of the chosen Unit ). The same principle can be used to name a ValueType after its Dimension.

WARNING: Changes to the chosen Unit will propagate throughout the system, so special care must be taken with statement of values and defaults !

• The Dependencies in this diagram are for illustration only; they are not needed
  to define the Unit and Dimension of a ValueType. Just use the specification dialog.
• The examples here have been denoted «quantity kind» for illustration only.

• Value types defined for the SysML Hybrid SUV sample problem

Wider reading: detailed proposal for a major revision of the SysML Quantity metamodel

After completing this trail you may also like to examine:

• OMG SysML RTF: proposal by Dr Darren Kelly for Quantity profile/metamodel [WORK IN PROGRESS]
• UML Parsing Analysis of: International Vocabulary of Metrology (VIM)

Organise systems engineering <<BlockModel>>s to support forward-engineering to software simulation <<BlockPackage>>s

The <<BlockModel>> and <<BlockPackage>> strategies can be combined to support software simulation of syseng blocks.

FuelTank BDD: static (Class-level) default values of a ValueProperty

The static (or "Class-level") default values correspond to the values one would get using a noargs constructor. They are managed by the Block that owns the ValueProperty. If not overridden on instantiation of the Block as a part Property when used in a higher context these become the initial
values for the part.

Consider the capacity value in the BDD for the FuelTank block below. The designer of the FuelTank does not know what kind of vehicle (or even another type of Fueled Machine) it might be used in, and assigns a rather generic default value to the capacity of 40.0 L. This may or may not suit designers of specific vehicles.

Vehicle BDD: Property-specific initial values of a part Property

Property-specific initial values (a.k.a. Property-specific default values^(*)) are specific to the usage of a Block as a part Property in a higher context (by a structured block or "assembly"), and if there are many part Properties of the same type, they may have different property-specific default values (i.e. they will be initialised differently). They are managed by the higher context structured block that owns the part Properties, which initialises or configures their (possibly different) values on instantiation. In our example an abstract Vehicle block will configure its tank:FuelTank part Property by initialising it with a new capacity value.

The property-specific initial values of a part Property are carried by the Slots of an InstanceSpecification of the same type. In the example below have stereotyped the InstanceSpecification tank:FuelTank with «initial values», however this is only for illustration. If you have many parts to configure you may also like to group them in a dedicated Model (I have used a Model named parts below, with a custom stereotype «initialisation»).

Next we will see how to assign these property-specific initial values carries by the Slots of the tank:FuelTank InstanceSpecification to override the static (class-level) default for the capacity ValueProperty in the part tank:FuelTank in the Internal Block Diagram (IBD) for Vehicle.

WheelHubAssembly BDD: a pre-configured complex assembly

Let us consider first the Block Definition Diagram (BDD) of an entire WheelHubAssembly to be re-used with deep reconfiguration in a Truck (overriding many of the static (class-level) default values). We also want to be able to simply display the "value state" of all elements of a used :WheelHubAssembly as the system that uses it evolves.

As always, I recommend (in MagicDraw UML) the use of «composition» wrapper Components to logically and graphically organise the elements.

[LugBoltThreadedHole] example of a lowest-level PropertySpecificType

Let us start by redefining default values using a PropertySpecificType [LugBoltThreadedHole] for a lowest-level block. A higher level PropertySpecificType will then compose a part apparently "typed" by [LugBoltThreadedHole] instead of the base LugBoltThreadedHole (see next pages). In fact one is not supposed to show a a named PropertySpecificType in a Block Definition Diagram (BDD) in this way:

SysML1.0: 8.3.2.8 PropertySpecificType:

Constraint [2] The name of a classifier to which a PropertySpecificType is applied must be missing. (The “name” attribute of the NamedElement metaclass must be empty.)

SysML1.0: 8.3.1.2 Internal Block Diagram:

Property-specific type

Enclosing the type name of an internal property in square brackets specifies that the type is a local specialization of the referenced type, which may be overridden to specify additional values or other customizations that are unique to the property. Redefined or added features of the newly defined type may be shown in compartments for the property.

However for illustration, and for easy illustration in IBDs, we nevertheless use an explicit subtype [LugBoltThreadedHole].

The values are for illustration only (the author is no automotive engineer nor car freak).

[Hub] BDD: example of cascading use of PropertySpecificTypes

The part of a PropertySpecificType is  redefined to use a PropertySpecificType specialisation of the composed part of its own Generalization parent, the "cascading" effect.

[WheelHubAssembly] BDD

Here we see one level higher up.

Problem: the "cascading" PropertySpecificTypes quickly become unwieldy to manage both graphically (in diagrams) and in the model ! Clearly a very high degree of automation would be required to make this practical for real-world systems engineering.

Deep configuration trail conclusions

It has been shown that the SysML PropertySpecificType strategy suffers from many disadvantages. While it admittedly does offer the greatest possibility of redefinition of default values, operations, and constraints, it is fundamentally subject to inefficiency both in modelling and diagramming, primarily because of the "cascading" effect of the implied subtypes of an existing complex assembly. It also presents problems for reuse of existing typed connections between parts.

If we are just interested in deep re-configuration of a complex assembly, or in statement of its evolving "value state", an alternative offers itself. We may use a ValueSlice strategy, which manages a list of InstanceSpecifications, the Slots of which can be mapped efficiently to a values compartment of parts in an IBD for a specific "value slice" usage context of a complex system. The MD SysML team is now working towards practical deep value assignment suited to real-world systems engineering leveraging this technique.

Framed IBD in MD SysML with cross-project navigation

By default the name of a “structured block” is bound to its linked IBD !

• To create a "structured block" (in a BDD) use the "Structured Block" menu item in the BDD diagram bar.
  • You can then simply click on it to "open it up" into its IBD. 

Symbol-based hyperlink navigation for practical systems engineering:

• Just drag a the diagram icon of the IBD for the block Type of a Property from the browser onto the Property's symbol in an IBD.
  • You can then simply click on it to "open it up" into its IBD.

Simply Super !

Frameless IBD in MD SysML: pros and cons

pro: provide associated navigation points, esp. “up”

con: including associated elements can block modularisation !

IBD as “context diagram” for a system

A system needs a context in which to interact with entities external to the system boundary:

• This is often called the 0th (or zero-th) level.

• A system is used as a part property within a system context.

Package Diagram for View and ViewPoint

AssociationBlock: example of decomposed connections between ParticipantProperties

SysML1.0:

Participant properties can be the ends of connectors owned by an association block. 

SysML1.0:

The association block can be the type of multiple other connectors to reuse the same internal structure for all the connectors.

Every usage of AssociationBlock as a Connector typed by it is decomposed into finer connections between participants (and/or nested parts). 

Example: ItemFlow without 'itemProperty'

SysML1.0: 9.3.2.6 ItemFlow:

'An ItemFlow .. may constrain the item exchange between blocks, block usages, or flow ports as specified by their flow properties. For example, a pump connected to a tank: the pump has an “out” flow property of type Liquid and the tank has an “in” FlowProperty of type Liquid. To signify that only water flows between the pump and the tank, we can specify an ItemFlow of type Water on the connector.'

Example: ItemFlow with 'itemProperty'

SysML1.0: 9.3.2.6 ItemFlow:

'.. In addition, if there is an item property (corresponds to the conveyed classifier), then one can label the item flow with the item property. For example, a label of “liquid: Water” would imply that the item flow relays Water and this relay is associated with an item property “liquid” of the item flow, i.e., the “liquid” item property is set once Water is relayed.'

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

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.

• 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

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

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 No Magic 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.