Issues for OMG SysML Revision Task Force

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

"This section is very difficult to understand, in particular for non-OMG
people. Please add a clarifying paragraph here.
"

Unable to resolve. Left for RTF to decide.
Disposition:	Deferred

Redraw visio to improve look. FTF Issue - General issue of style of uniform diagrams

. 

Discussion:
Diagrams are fairly uniform in the chapter. Issue is deferred for the next major release of the spec.
Disposition:	Deferred

Specify matching rules that enable flow ports and client server ports to be connected. 

FTF Issue - Consider the need to do this without adversely impacting current port semantics. Discussion:
It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration.
Disposition:	Deferred

Add more precision to table spec in terms of what rows, columns mean (refer to SP spec). Also, enlarge table elements so they are readable.

BOM properties. In Blocks, BlockProperty, 8.3.2.2, Description, third paragraph, seems to be trying to address the request for bill of material properties. If so, these are properties whose values are all the objects in the composite of a given type. They are derived from all the other block properties of that type. Eg, all the resistors needed to assemble an circuit board. 

Discussion:
It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration.
.
Disposition:	Deferred

Behavioral flow ports. In Ports and Flows, FlowPort 9.3.2.5, Description, the fourth and sixth paragraph seem to give contradictory defintions of behavioral flow ports. The second refers to the UML isBehavior semantics. The fourth refers to "relaying" to properties or parameters, but doesn't explain what that means. If the two paragraphs are referring to the same thing, then presumably a block behavior is a classifier behavior, and since that behavior executes while the block instance exists, relaying to the parameters requires those parameter to be streaming, in the sense of CompleteActivities. The semantics of relaying properties is unrelated to UML behavior ports. 

In Requirements, Figure 16.1, Requirement has properties with Requirement as type. But instances of stereotypes are not property values. Perhaps this is supported in UML as part of stereotypes with associations to stereotypes. If not, the type should be UML4SysML::Class, with the constraint that the values of the properties are stereotyped by Requirement. 

Discussion:
Unable to be addressed in time
Disposition:	Deferred

The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13

 

However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them.

 

It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML

 

If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.  

 

Discussion:
Discussed on conference call during Anaheim Meeting (Sept 26, 2006). It was deemed that this would introduce new content into SysML 1.0 . It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration.

Disposition:	Deferred

SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.

 

I contest this on two grounds – 

            1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD. 

               b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type. 

               c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner] 

            2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts

Discussion:
Qualified associations were excluded in SysML V1.0 as part of the general goal to subset the amount of UML that a system engineer must understand for system modeling. If usage of SysML V1.0 indicates significant modeling gaps from the exclusion of qualified associations, their inclusion can be reconsidered in future versions of SysML. Experience is still needed to determine if there are alternative ways to model cases such as those cited without the complexity of the added notations and rules for qualified associations.
Disposition:	Deferred

The text in 14.1 should briefly discuss that for System Engineers, run-time optionality is not the typical distinction for indentifying extensions. If we wanted to draw a flow chart, we would use an activity diagram.

 

It is usually more relevant to identify as extensions those use cases that not are needed to reach the goal of the base use case. This allows the System Engineers to use the dependency graph among the use cases to help determine production/test/delivery order. 


This also makes it clear to the reviewer which features are considered optional and which are not. At the SE level, this is more important that than flagging those features that sometimes invoked and sometimes not invoked. 

 

Please clarify with this use at the SE level

Discussion:
Unable to be addressed in time
Disposition:	Deferred

Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.

Resolution:
Generalization / specialization of activities is not mentioned in the rest of the document, has not come up in discussion of SysML application, requires more explanation.  Defer until the need becomes clearer.

Disposition:	Deferred

Interfaces on Flow Ports

It’s not clear how to model complex ports that partake of both service and physical flow characteristics. 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. 

 

Or I can use in-band signaling over a communication line (as it used to be on a telephone lines). 

 

In such cases, I’d like to be able to attach interfaces (with the set of operations) to a flow port.

On figure 16.8 there should be up-arrow pointing to the Accelerate state from the decision node

For an SE to specify an Architecture, it is often necessary to specify reusable architectural patterns.  SysML as currently formed does not appear to support the reusable definition of architecture tied to particular systems. It may be necessary to include some of UML 2.1 Template and Collaboration packages to support this capability.

 

Discussion:
Not within the scope of the FTF to expand the specification at this time.
Disposition:	Deferred

In Table 14.1 Use Case Diagram, the abstract syntax reference for the Subject notation is given as “Role name on Qualifier”.  This does not appear correct

In the constraints on viewpoint, 7.3.2.5, the plural form of the prosperities is used. I believe they should be in the singular. 

Constraints

…

[2]The property ownedOperations must be empty.



[3]The property ownedAttributes must be empty.

…

in paragraph 8.3.2.3, the semantic of a default value for a DistributedProperty is not specified. My suggestion is that the default values should be a realization of the random variable following the distribution. It would be nice to have an example in the paragraph too, for instance: <<uniform>>{min=0,max=2} p:Real=2 <<uniform>>{min=0,max=2} p:Real=1.2 but not: <<uniform>>{min=0,max=2} p:Real=2.3 

FlowPorts can be typed by (p64): · Block · DataType · FlowSpecification · Signal · ValueType FlowProperties (which are owned by FlowSpecifications) can be typed by (p65): · Block · DataType · Signal · ValueType Yet ItemFlows can only be typed by (p66): · Block · ValueType Since FlowPorts and associated Flow Specifications define “what can flow” between the block and its environment. Whereas ItemFlows specify “what does flow” in a specific usage context. It therefore proposed that the ItemFlows constraint section is updated to include DataType and Signal, as well Block and ValueType (i.e. same as FlowProperties). Note: It is assumed that having an ItemFlow typed by a flow specification would make no sense, since the item properties have direction on them that would have to be interpreted in relation to the direction of the item flow arrow. Is this assertion correct?

The names of tracedTo and tracedFrom appear counter-intuitive. On a <<requirement>> (p144)... /tracedTo: NamedElement[*] Derived from all elements that are the client of a <<trace>> relationship for which this requirement is a supplier. On a <<requirementRelated>> (p145)... \tracedFrom: Requirement[*] Derived from all requirements that are the supplier of a <<trace>> relationship for which this element is a client. If a trace dependency ends at a requirement therefore, it would be listed on the <<requirement>> with the property name 'tracedTo'. It is thought that most users wouldexpect this property to be called 'tracedFrom' instead. Should we swap the names of these properties around to avoid this confusion? 

I would like to model an atomic flow port at a block "Battery".
The base type is Volt (value type). 
Now I would like to show that the value is 12,5V in this context.


If I use a property specific type, I can't show the constant value
in my diagram. The name of my atomic flow port is:


out:[Volt]


Where can I show the value 12,5? 

The CAN_Bus shown in the ibd B.22 is missing in figure B.18.

Update Annex G to accurately specify the graphical and textual notations supported by the current SysML specification. Currently, an editorial note at the top of Annex G notes that the Annex contents are to be updated for specific diagram types during the finalization phase of the specification. Resolve the diagram types for which BNF syntax productions will be provided, and make sure that these match the notations documented in the corresponding SysML chapters.

Discussion:
Completion and detailed verification of Annex G exceeds the scope of work that is feasible during the SysML FTF.  Because the scope of SysML is defined by its concrete syntax, a more formal version of concrete syntax definition should be considered for future versions of the SysML specification.
Disposition:	Deferred

The relationship between a behavioral flow port and parameters is marked as a semantic variation point. Isn't it possible to specify a concrete relationship here? The specification proposes a binding relationship. What is a binding relationship? It is not known in SysML or UML. 

Viewpoint.Purpose[1] should probably be Purpose[*] to be consistent with the other attributes of Viewpoint. Perhaps [1..*] if needs to be mandatory. 

In SysML 9.3.2.4, the possible flow directions include 

 

nout

 

 

based on later usage, this is incorrect for

 

            inout.

Inconsistent use of "sub-type" and "subtype". UML2 and SysML spec in general use subtype, there are a few instances of "sub-type" in the SysML spec (chapters 9, 16, and C), should be replaced with subtype.

Add a brief statement to Section 6.1, Levels of Formalism, to clarify that SysML reuses UML instance semantics, adapted as necessary for description of systems. A brief statement of UML instance semantics can be found in the UML Superstructure specification (ptc/06-04-02) under 6.4.2, Semantic Levels and Naming, under the paragraph labeled "Instance level."

The exclusion of UML concrete syntax for Instance Specifications has resulted in the inability to assign default values to properties of blocks using anything other than simple text strings for value properties. Consider reintroducing UML concrete syntax for UML InstanceSpecification into one or more SysML diagram types so that more complex default values can be assigned.

Discussion:
The defaultValue compartment on an internal block diagram does provide at least one available option for assigning default values to structured values, as discussed in the subsection "Default value compartment" under 8.3.1.3 Internal Block Diagram. Creating a graphical compartment on an internal block diagram to assign values to properties defined on a block definition diagram may be more cumbersome than a textual syntax, but tools may be able to streamline the  linkage to the default value  for usability. In particular, the use of a "structure" compartment on a block definition would allow the default value to be shown next to a properties compartment where a property is defined.
Other work in OMG is currently underway that may define a standardized form of textual syntax for value specifications.  SysML could consider such a textual syntax for property values in future versions.
Disposition:	Deferred

The figure and added text describing the use of <<extend>> is still unclear and inconsistent. As agreed, converting Start the vehicle to an <<include>> and Park to <<extend>> will correct the confusion and make the added text unnecessary. 

Brake is spelled Break twice on this page, once in the paragraph between the figures and once in figure 11.141

Several places in the spec, it is indicated that behaviors can be shown on block and class diagrams. As SysML does not support class diagrams, it should be changed to block diagrams only. See text on 11.1.1.1; 11.3.1.1(3x);11.3.1.4

In the explanation for Fig 17.4.2, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an "isEncapsulated" property, described elsewhere in the specification (p. 46) This is very confusing. The text should be corrected to indicate that the property isEncapsulated of the Block Stereotype is inherited by the stereotype system and concept

In Annex A, the bdd is indicated that it can only be for blocks, pkgs, and constraint blocks. [A previous issue was raised that this list should include activities]. This list is incomplete; it should probably include all SysML-allowed stereotypes (and extensions) of class (perhaps classifier), including signal, actor, interface, etc. Even if such elements are not allowed to be model elements _for_ the diagram, they should be explicitly allowed as elements on a bdd. Similarly the allowed elements for and on an ibd should be clarified.

It is unclear in this diagram what the element that this bdd is for (a package?) However, the elements on this diagram are metaclass and stereotype elements, which I believe are the wrong metalevel for bdd diagrams. This is really a notional metaclass diagram indicating how SysML might be extended, but it is not a SysML diagram itself

In Figure 17.4.2’s explanation, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an “isEncapsulated” property (defined elsewhere in the spec). 

 

This is very confusing. The text should be corrected to indicate that all properties of the Block stereotype (e.g., “isEncapsultated), even if not indicated on the diagram, would be inherited by the stereotypes «system» and «context»  An alternative fix that also corrected the diagram would perhaps be better but more effort.

Can anybody clarify the definition of a constraint parameter for me?


To quote the SysML spec:
[1]The type of a constraint property must be a constraint block.


So a constraint parameter is not a constraint property typed by a value type or something like that...


To quote again:


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


So does this mean that a parameter is a block property (or an ordinary property)?  


Would it make sense to add a <<constraint parameter>> stereotype to constraint blocks? Has this been suggested or does it make sense?

As previously mentioned in our 2004 review; a rationale must be considered as a class, that has its own lifecycle and its own access rights.
It is not only a simple UML comment extension.

Allocation arrows direction seems to be  opposite to UML dependency rules. We do ne think it is a good idea ?

We do not agree with a systematic propagation rule of sub-requirements when copying requirements. That introduces useless constraints in contractual contexts that have their own rules.

SysML doesn't explicitly support the modeling of alternative models for example for trade studies as requested by the UML for Systems Engineering RFP. Models and Packages are not useful, because they don't allow to exclude elements. For example to specify a xor between requirements (if reqA is used, then don't use req B). Same for blocks and other model elements. 

Figure B.16, B.18, and B.26 do not use white diamond notation for referenced properties. Please update these figures to use white diamond

What happens if a control value disables an action within an activitz and no other actions are active and no more tokens are present?

Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines. 

The block namespace compartment shows a bdd of the elements that are part 
of the namespace of the block.


Is it allowed to show relationships from a block inside that compartment to
a external block? The relationship could be in the model, but can I show it
in the diagram?


I think it should be allowed. I don't see any problems.

We build the structure of a system on the block definition level by composition
and not by namespace containment. We also use this approach in the sample problem.
Therefore I would like to use a block compartment to show a bdd of all owned elements
by composition and not by namespace containment. I don't know any good example where to 
use the namespace compartment or the namespace containment relationship. 


Should we change the namespace compartment to a owned element compartment?
Do you know good examples when to namespace containment vs. composition?


By the way the concrete syntax of the namespace containment in the sysml spec isn't 
defined in the uml specification

Add clarification and precision to the specification by replacing the natural language constraints with OCL constraints. This is a general issue that applies to constraints on stereotypes within Chapters 7-17 of the specification. It is appropriate to address this on a priority basis to selected constraints that are ambigous due to their natural language representation, and where OCL can reduce their ambiguity.

I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario

Using black-diamond composition for functional decomposion is confusing and misleading since the owner Activity does not contain other activity in the sense that they have the same life span and obvuisly since different CallVehavior are used to invoke the activities, these activites may actually be carries out one after the other. We propose that either another relationship is used to signify functional decomposition or a hierarchy of Activity Diagrams should be used.

What happens if a control value from a control operator stops the following action and there are no more tokens left and no actions are active? Does this terminates the execution of the activity? What if the control value suspends the action? Who can resume the action? There are no more tokens and running actions.

It is not explicitly mentioned that SysML changes the notation for the satisfy relationship. It is a stereotyped realization relationship and should be notated as a dashed line with a triangular arrowhead. But SysML uses a simple arrowhead.

The types of the attributes dimension and unit must be Dimension and Unit instead of ValueType according to Fig 8.4.

The nesting of requirements has the semantics that the upper requirement is fulfilled if all it's sub-requirements are fulfilled. In addition we need a mechanism to express a xor between sub-requirements sets to support variant modeling. If a requirement can be satisfied by different system components, these system components have different technically requirements. These requirements are sub-requirements, but a subset of them that relates to one of the system components is sufficient to fulfill the upper requirement. It is not necessary to fulfill all sub-requirements

The list of diagram kinds and abbreviations should contain the non-normative table and matrix diagram kinds

I miss a explicit statement that SysML changes the standard notation for instance specifications. According to that the name of dimensions and units must be underlined

Nested connector ends:


"Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them."


That's an important feature of SysML. 


"The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be
shown on the same diagram."


I think that's a problem in practice. Often I don't want to see the nested properties in the diagram.
I propose to add a notational feature to show that a connector end is connected with a nested property without
showing that property.


For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>>
as a short form of <<nestedConnectorEnd>> and optionally the propertyPath. 


What do you think?

Can anybody elaborate on the following definition of PropertySpecificType : “The PropertySpecificType stereotype is automatically applied to a classifier created by the notation for a property-specific type for a property belonging to a SysML Block or ValueType. It identifies these classifiers so that they may be managed along with the property that they type.”

 

It is quite obscure to me to understand its meaning?

The semantics of the Binding Connector is described as follow :

“8.3.2.10 Binding Connector

Description 

A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.”

 

So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?

Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation

Uppercase/lowercase problems. Stereotype names are defined in upper case, but in diagrams are displayed in lower case (e.g. Block and <<block>>). Attributes(tags) are displayed in uppercase in diagrams, but are defined in lower case in the specification. 

Lack of notation for units and dimensions on values. There are no samples at all

Association branching is not defined in UML. Mapping is not clear. Composition tree is not defined in UML, mapping is not clear. 

Constraint parameter notation conflicts with UML private ports notation. How to distinguish between part and ports if notation is the same?

Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references):
a) Stereotypes
  i. Block stereotypes are displayed on parts 
  ii. Block stereotypes are displayed on object nodes 
  iii. Parameter stereotypes are displayed on ActivityParameterNode 
  iv. Behavior or operation stereotypes are displayed on CallActions
b) Tags
  i. Block allocations are displayed on parts 
  ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype
c) Constraints
  i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30) 

Mixed action and activity concepts. B.35, B.36, B.37 - concepts of activity and action are mixed (action is allocated, but activity is in tabular notation)

Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>> 

View as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view) 

Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")

PropertySpecificType concept is highly ineffective and suboptimal. It requires to redefine all structure from very root context if some deep nested part should use different configuration. So one should redefine all car internal structures if one bolt should be changed or color should be different

Is it allowed to attach the optional stereotype to outgoing parameters? The definition mentions only ingoing parameters: "This means the parameter is not required to have a value for the activity or any behavior to begin execution." 

"An “X” on a single end of an association to indicate that an end is “not navigable” has similarly been dropped, as has the use of a small filled dot at the end of an association to indicate an owned end of an association."

 

In this text I see two mistakes:

1. "filled dot" notation is used for ends owned by associated classifier, not owned by association (an opposite situation).

2. "owned end of an association" does not mean it is not navigable. Association has "navigableOwnedEnds" property for navigable owned ends.

On Fig 9.4 p 70. the I_ICEData I/F has the following services defined on the cntrl (the engine)

 

getRPM():Integer 

getTemperature():Real 

isKnockSensor():Boolean

 

These names make sense if the interface was a provided interface on the engine. 

However, the I_ICEData interface on the engine is a REQUIRED interface.

 

The interface should be defined something more along the lines of…

 

hereIsRPM(:Integer)

hereIsTemperature(:Real)

hereIsKnockSensor(:Boolean)

 

as the engine is using this interface to tell the PowerControlUnit the current values of those properties.

 

This problem is duplicated later in Figure B.20 on p 194

Inconsistency among valuetype/unit/dimension

 

In Figure 8.4 p 43, the following multiplicities are given

 

A valutype may (0..1) have a unit and may have a (0..1) dimension

A unit may (0..1) have a dimension.

 

On page 49. there is a constraint

 

Constraints

[1]If a value is present for the unit attribute, the dimension attribute must be equal to the dimension property of the referenced unit.

 

This would mean that if the unit’s dimension is null, then the valutype’s dimension must also be null. This seems overly constraining.

 

In 8.4.2, it says

Because a unit already identifies the type of quantity, or dimension, that the unit measures, a value type only needs to identify the unit to identify the dimension as well.

 

This statement seems to say the unit must have a dimension, and the valuetype’s dimension can be null even though the unit’s is not. This statement therefore disagrees with the Figure 8.4 and the constraint on page 49

this about the interpretation of the the containment 
relationship and its
implementation on the tool side.

We are using MagicDraw 14.0 and SysML 1.1sp2.
 
As soon as a containment relationship is created between two
requirements the
contained requirement is automatically relocated to the package
of the container. This prevents distribution of requirements 
in different
packages, in particular if a contained requirement belongs to 
a subsystem.
I would like to properly distribute them.

We have a requirement A which contains requirement B and C.
A is a requirement on very high level of the system which is decomposed into
requirements B and C on a subsystem level.
To avoid to have all requirements together (because B and C 
belong to the
subsystems) we want to put A, B and C in different packages 
but still have
the containment relationship (as foreseen by the SysML spec.)
that's why I think it is different from a package containment. They
 are not the same. 

Mapping of PropertySpecificType to the UML metamodel requires further explanation Chapter 8 introduces the notion of property-specific type to assign values to parts inside an ibd. Section 8.3.1.1 defines a notation for property-specific types. Section 8.3.2.8 provides a definition of the <<propertySpecificType>> stereotype and gives elements on how this concept maps to the UML metamodel. However, this section does not explicitly define: 1) where are stored the actual values? One may understand that a default value of a property owned by a class, which is stereotyped as <<propertySpecificType>>, is considered as a property-specific value. This property-specific value may be considered as an instance of a property owned by the refrenced block. It is not clearly stated though. 2) how does a property-specific type relate to the referenced block ? In other words, if a class is stereotyped as <<propertySpecificType>>, which feature of this class points to the referenced block? We may need to add a paragraph in section 8.3.2.8 that provides answers to questions.

Address potential points of convergence between MARTE and SysML The MARTE profile supports modeling and analysis of real-time and embedded systems. Some of the concepts defined in this specification are applicable to Systems Engineering practices and can be of interest to SysML users. Early interactions between the SysML and MARTE partners have allowed to identify convergence points: - support for value expressions and constraint expressions using a dedicated language - formalisation of a time model, including the notion of clock to measure time - definition of metamodel elements for units and dimensions As discussion goes on, other convergence points may be identified and added to this list. Working on an alignment between MARTE and SysML has been identified as an important opportunity for both groups.