Even though SysML ValueType includes all the capabilities of UML DataType, plus its own optional extensions, SysML currently both of these separately in its diagram elements and abstract syntax. This adds unnecessarily to the complexity of the specification (where both DataType and ValueType must be mentioned in multiple places) and to the language that the SysML user must learn. It's inconsistent with other renaming of UML elements by SysML, in which the neutral SysML term (e.g. Block) replaces the UML term (e.g. Class). Just as SysML Block replaces the UML term Class, there's no reason the SysML term ValueType can't replace the UML term DataType. Statement of OCL constraints and metamodel and diagram syntax specifications can be simplified as a result.

Because ValueType includes all capabilities UML DataType, plus its own optional
extensions, no user need for keeping them both was identified during discussions
within the RTF. In SysML user models, there’s no reason that the SysML term
ValueType can’t replace the UML term DataType, in the same way that the
SysML term Block replaces the UML term Class. In both cases, the substitute
terms were chosen to be less software-specific than possibly appropriate for use
by system modelers. Regardless of this rationale, consolidating to just ValueType
simplifies the language including the specification of diagram elements and
constraints.

Certain activity constructs were left out of UML4SysML to reduce complexitiy of the language, butBased on usage of activity diagrams, some of these constructs are now viewed as useful. One example is structured activity nodes. Others include the parameter affect. Proposed Resolution: Update Fig 4.2 andd Table 4.1 to include additional packages in UML4SysML that support the useful constructs such as structured activity node which is included in "CompleteStructuredActivities". Also, update the diagram element tables in Table 11.1 to reflect these new constructs.

Table 4.1 (Detail of UML Reuse) says StructuredActivities is included in SysML,
but Figure 4.2 (SysML Extension of UML) should be updated to include it (the
figure includes the Composite Structures package for StructuredActivities), and
structured activities should be included in the Activities chapter diagram elements
table.

In order to begin to more fully leverage SysML, it must be integrated with various execution languages. Modelica is a highly expressive execution language to support physics based analysis and simulation, which has been standardized through the Modelica Association. Initial feasibility indicates a high degree of compatibility between SysML and Modelica. A standard mapping between SysML and Modelica is needed to enable this capability. In addition, it is expected that some refinement/extensions of SysML may be required to more fully integrate with Modelica. Recommendation: Perform an initial mapping between SysML and Modelica. Identify any refinements/extensions to SysML to support the mapping. Prepare a non-normative annex to the SysML specification that captures this mapping.

A separate specification for a "SysML-Modelica Transformation" is currently
being finalized by OMG. This specification has taken over the specification of a
mapping between the two languages and goes far further than originally
suggested by this issue. The working groups for SysML and the SysML-Modelica
Transformation are continuing to work together, and will raise specific issues
against SysML as necessary to support the transformation capability.
Disposition: Closed, no change

Port Decomposition of a Flow Specification Discussion. There has been continued need to be able to decompose ports. One approach is to decompose a flow specification. In order to more readily accomplish this, a flow specification steretoype should subclass block instead of extending interface. This would enable many of the block constructs to be used, such as nested connector ends, the dot notation, and other features. A nested connector ends would allow direct connections to the flow properties of flow specifications. Dot notation could be applied to refer to the flow properties. In addition, to enable further levels of decomposition, a flow property should be able to be typed by a Flow Specification. The notation should also be clarified to allow for flow ports typed by flow specifications to show the port with the nested flow properties, and futher levels of nesting as required. As an additional comment, a connector to the port that is typed by the flow specification can be allocated to sub connectors that connect directly to the flow properties to support the concept of connector decomposition. Recommendation. 1. Modify Figure 9.1 to show the Flow Specification stereotype subclassing block rather than extending Interface. 2. Modify Flow Property in 9.3.2.4 to allow it to also be typed by a Flow Specification. This should be reflected in the Description and Constraint 1. 3. Modify Flow Specification in 9.3.2.5 to note that Flow Specifications can be decomposed (not sure this is necessary, but it might be good to clarify). 4. Modify the text for the diagram extension to flow port in 9.3.1.1 to describe that a flow port that is typed by a flow specification can be notated with the port symbol that nests the flow properties. Also note that a connector can connect directly to these flow properties using nested connector ends, and that the dot notation can be applied to refer to the flow properties. Finally, note that flow properties can be nested more than one level.

This issue is resolved by loosening UML constraints on connectors to enable
thems to connect to ports nested on ports, recursively, and provide a notation for
nested ports. It clarifies that item flows can be typed by association blocks
containing connectors between nested ports. Issues 10059, 11628, 12914, and 14086 are also resolved, see those issues for
more information.

Issue: Inability to name interruptible activity regions. Discussion. Interruptible regions are useful constructs in SysML to enable termination of activity nodes. This is useful in a variety of cases, such as when one wants to terminate actions with streaming and continuous flows. In more complex behaviors with multiple interruptible regions, it is desired to be able to identify these regions by name. This may be useful when defining the owned behavior of a block with an activity that has multiple interruptible regions that represnt behavior in a similar way to state machines, where an accept event action may cause the behavior of the block to transition to another interruptible region of its behavior. Proposed resolution: An interruptible region in UML and SysML is currently an activity group which subclasses element. Create a stereotype of interruptible region called name interruptible region that subclasses Named Element (a similar approach is applied to activity partitions in UML

This is addressed in UML 2.3. Assume this revision of SysML will be based on
UML 2.3, and update the Activities diagram table in SysML.

Issue: SysML support for Foundational UML to support execution of activities Discussion. Need to include the foundational subset of UML in the UML4SysML to support activity execution. This includes constructs suchas structured activity nodes in complete structured activities, which is a capability that is a useful addittion to SysML. Proposed Resolution. Update Figure 4.2 and Table 4.1 to included structured activities, extra structured activities and complete structured activities along with any other packages in UML4SysML needed to support the Foundational UML Subset. In addtion, update the diagram elements in Tables 11.1-11.3 to reflect the additional activity constructs including the structured activity node.

Resolution:
If the modeler stays within fUML, the model will execute. Some of SysML is not
in fUML (eg, streaming), and some of fUML is not in SysML (expansion regions),
but if the modeler stays with the intersection of fUML and SysML, the model will
be executable and SysML-compliant.
Disposition: Closed, no change

Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly.

Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property?

No Data Available

Issue: SysML synchronization with UML/XMI version updates Discussion: Since SysML was originally published, both UML and XMI specifications have been updated. It is important to maintain synchronization between SysML and these specifications since SysML leverages both of them. Proposed Resolution: Update Section 2 to reflect the current version of UML and XMI. An assessment of the changes to UML and XMI should be made, and a determination of the impact on the SysML specification. The SysML specification should be updated accordingly.

Specific issues continue to be raised to address specific points of dependence of
SysML on UML. The SysML specification itself has replaced specific version
references to UML to simply "UML 2" so that references do not have to be
changed to reflect the dependencies on which any given version of SysML
depends, with the exception of material in Chapter 4, Language Architecture.
This generic issue should be replaced by more specific ones that raise known
issues in which future versions of SysML may need further revision to address
dependencies on UML.
Disposition: Closed, no change

There is a non-normative diagram indicating a hierarchy of SysML diagram types. In this diagram we follow the UML convention of treating Use Cases as behavioral diagrams. The exact reason for this is unclear, and appears to be tied up with collaborations.

However, in SysML system engineers (and many s/w eng in UML) treat use cases as a way of capturing goals, capabilities, purposes, and as a technique to organize (and find) requirements. In this way, it is more understandable to the typical SysML user to treat both Use case Diagrams and Requirements Diagrams as belonging to the same category. I have verified this by teaching SysML to students both ways – and the common UCD/REQ approach is thought to be more understandable.

One approach would be to consider the new category Requirement Diagrams, and Use Case and Text-base Requirements as the individual requirements. Another would be to make a new category of Specification Diagrams and use Use Case and Requirements as the individual types.

The above approach represents a reasonable approach to restructuring this
Diagram Taxonomy. However, this taxonomy is intended to be more of a
conceptual organization of the SysML diagrams, and is not a precise
representation. There may in fact be many ways to categorize the diagrams in a
conceptual and informal diagram taxonomy. As a result, this resolution will add a
clarification to the non-normative Diagram Annex that other diagram taxonomies
can be included, and include the categorizing of the use case diagram and
requirements diagram as an example.

Constraint [2] says: [2]An “in” FlowProperty value cannot be modified by its owning block. What is the owning block of the flow property? The flow property is owned by the flow specification which is a type of a flow port which is owned by a block. Is this block the "owning block"? Why is the owning block not allowed to change a in flow property? Shouldn't that be defined by the readOnly property instead of the direction?

This is addressed in the resolution of issue 13178 with clarified wording in the
description of flow properties

I'm just experimenting with the parametric diagram and detected a problem. I'm not sure
if it is a SysML problem or if I am the problem.

A block A has a composition relationship to a constraint block with multiplicity * and property name cstr.
I like to use the constraint property cstr in a parametric diagram of block A multiple times.
That doesn't work, because the constraint property occurs only once in the diagram.

I don't like to define a constraint property for every usage of the constraint in the parametric
diagram, because it's not two or three times, but really many many times I want to use the constraint.
I think of something like the selector in sequence diagrams, i.e. the name of the constraint
property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on.

What do you think? Am I completely wrong?

No Data Available

Issue: Ability to capture performance properties of activities and bind to parameters in parametrics. Discussion. Need to clarify that performance properties of activities and other behaviors, such as the time, reliability, and accuracy associated with performing an activity, can be captured as part of the definition and use of an activity or the types of its object nodes in a way similar to value properties of blocks. Further clarification should be provided that these properties can be bound to parameters in parametric diagrams to support performance analysis. Activities (and other behaviors) can be captured on a bdd as shown in Figures 11.1, 11.5, 11-13 and 11-14. In section 11.3.1.1 and 11.3.1.4, the interpretation of activities and object nodes on bdd's is defined, and in section 11.3.1.4. Proposed resolution: Additional clarification should be provided in the above sections, that properties of activities and other behaviors can also be represented on their definitions on a bdd, and that the value properties are like any other value property, enabling them to be bound to parameters in parametric diagrams.

Add clarifications for Activities, as indicated above. The clarification for Object
Nodes is already in the Object Node section of Diagram Extensions.

Issue: Ambigous line crossings Discussion: When two lines cross, there can be ambiguity associated with the line path. This applies to any line including flows, associations, and connectors and other relationships represented by edges. A solution to remove ambiguity that is used in various schematic diagrams to address the same issue is to add include a curve in the lline path at the intersection. Proposed Resolution: In the Diagram Appendix on pgs 175-176, and a diagram guideline to include the curve to a crossing line path to avoid ambiguity. Consider making this a normative requirement. This will require an additional clarification statement for the Non Normative annexes.

Update the Guidelines in the Diagram Annex in Section A.2 to include an
alternative. ”jumping over “ notation for line crossings to avoid ambiguity, similar
to what has been used in electrical schematics. This is indicated by a small
semicircle at the line crossing. This can be applied to any edge in any SysML
diagram including flows, associations, connectors, and other relationships. It
should be noted that this is currently a presentation option for UML associations
as specified in the UML Superstructure specification (formal/09-02-02 pg 43).

"trigger[guard]\activity" should be "trigger[guard]/activity"

No Data Available

The behavior port notation to support the isBehavior=true condition on a port is needed to more explicitly model parts that execute the behavior directly. Refer to Figure 9.17 of the UML Superstructure Specification (v2.3).

Agree with the need

System variants are often required to modify a system in order to satisfy evolving needs, and to support product lines with varying applications and environments. System variants have some components in common and some components that may be unique for each variant. SysML currently includes some capability to address variants, such as a property-specific type for specifying a variant usage of a component (i.e., block) in a local context, redefinition for redefining the type of the component, and generalization sets for specifying alternative components. However, what it lacks is a convenient mechanism and notation for describing variations that occur in deeply nested contexts within blocks.

Issue
System Variants
Classical product configuration management evaluates whether the change to an assembly affects the next higher assembly in terms of its form, fit, or function. If there is no change to its form, fit, or function, the modification does not propagate up the hierarchy (Note: This should be confirmed). In order to ensure there is no adverse impact to the next higher assembly, one must establish criteria to evaluate the impact of the change on the next higher assembly, and then evaluate the impact of the change against the criteria.

Figure 1 describes the baseline block hierarchy for a Vehicle; in the following paragraphs we will discuss how to address variants of this baseline system.

Figure 1 - Definition of the baseline configuration for a vehicle
In considering variance, one first checks to see if the change to a component affects the interface of the next higher level assembly. For example, in Figure 1, if the number of lugbolts is changed from 6 to 8, this could impact the interface to the braking disc. In addition, one must evaluate other potential impacts due to form, fit, and function. For example, if the weight of the bolt changes, the impact may propagate up the hierarchy to affect the overall vehicle weight. Or if the modified bolt has a lower stress rating, it may impact the safety of the vehicle. These impacts need to be understood to make a determination of whether the modification to the lugbolt impacts the next higher assemblies and the vehicle as a whole. If the change propagates up the system level, then each higher level of the assembly that is impacted must be subclassed (e.g., this may correspond to a new model number) to represent the variant assembly.
Representing Variants using Block Definition Diagrams

When a system variant results from changes in its components, the variant system model must include representations of the variations at each level of the system hierarchy from the system level down to the component level where the changes occur. The example in Figures 2 illustrates the SysML solution when a modification to a lugbolt results in a variant to the automobile at each level of the system hierarchy. In Figure 2, a change to the lug bolt (i.e. LugBolt A) propagates up the system hierarchy resulting in a variant to the wheel, to the chassis (or equivalent next assembly), and to the vehicle. The variant system hierarchy includes Vehicle A, Chassis A, Wheel A, and LugBolt A as subclasses of the baseline system elements.

Figure 2 ­ Varying all levels of the system hierarchy

The following reference provides further information on a general approach to capturing variants: “Extended Generic Product Structure: An Information Model for Representing Product Families by Sean Callahan.” This short paper can be found at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_published.pdf and a longer version at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_extended.pdf.

System Variants Using Property-Specific Types

In Figure 2, 4 new types were introduced. If there is no impact to the form, fit, or function of the higher elements in the assembly, then modeling these intermediate assemblies using new types can be very cumbersome. There is a need for a more streamlined approach to capturing variations in deeply nested parts that do not affect intermediate level assemblies.

At first glance, the property-specific type concept in SysML seems to fit the bill. As shown in Figure 3, using property-specific types, the replacement part is shown using dot notation on the IBD for Vehicle A, without the need for the user to explicitly represent Chassis A, etc. on the corresponding BDD.

Figure 3 - Use of property-specific types to capture variants

However, as can be seen, the redefinition clause in the part symbol does not give a clear indication of the location of the part being redefined, nor is there a notation on a BDD for showing this replacement part.

Note: Figures were not able to be included with this posting but are available on the SysML v1.2 RTF Wiki

This RTF declines to add specialized notation for variants.
Disposition: Closed, no change

There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies.

The figures above have only one (unambiguous) underlying model, but directed
relationships, such as dependencies, linked to c1 (or c2) would be ambiguous. It
would not be possible from the underlying model alone (without the notation) to tell
whether the directed relationship was referring to values of c1 properties on
instances of B that are values of the b1 property on instances of A, or values of the b2 property on instances of A, because directed relationships do not currently
support property paths, as connector ends do when NestedConnectorEnd is applied.
Introduce an abstract stereotype of DirectedRelationship with property paths for their
sources and targets, that generalizes SysML Stereotypes based on
DirectedRelationship or its specializations

Non-atomic flow ports use the type of
the port for an interface with
properties specifying the type of things
that flow. If the various types of
things flowing are intended to flow at
the same time, then flow specifications
aren't needed. This can be done with an
atomic port flowing objects supporting
the interface. If the the various types
of things flowing are meant to flow at
different times, this is isn't UML
semantics, or at least is very
unintuitive from an engineering point.
This can be done either with 1) an
atomic port flowing a supertype of the
various types of things that flow 2) the
association mentioned in in the first
paragraph having multiple types, which
the semantics defined to be union of the
types.

Ports typed by flow specifications do not mean that items supporting the interface
are flowing. This is clarified in the resolution to issue 13178.
Disposition: Closed, no change

The type in the allocation matrix must be action instead of activity.

Discussion:
Fig. 15.11 was deleted in SysML 1.2, removing redundancy with Annex B.
Fig. B.37 (Fig. C.37 in SysML 1.3) is the same figure, but the issue noted here was
fixed in the resolution to Issue 11497 in SysML 1.2.
Disposition: Closed, no change

Ports use property type incorrectly. Atomic flow ports use the type of the port for the type of thing flowing. This doesn't fit common usage in engineering design, for example, a port that is a faucet through which water flows. The type of thing flowing isn't the type of the port, it should be associated to the ports by the stereotype. Non-atomic flow ports use the type of the port for an interface with properties specifying the type of things that flow. If the various types of things flowing are intended to flow at the same time, then flow specifications aren't needed. This can be done with an atomic port flowing objects supporting the interface. If the the various types of things flowing are meant to flow at different times, this is isn't UML semantics. This can be done either with 1) an atomic port flowing a supertype of the various types of things that flow 2) the association mentioned in in the first paragraph having multiple types, which the semantics defined to be union of the types.

The atomic port portion of this issue is addressed in the resolution of issue 13178
by deprecating atomic flow ports. See resolution of issue 14424 regarding nonatomic
flow ports.

There is a need for a robust mechanism to constrain a system decomposition hierarchy to reflect only selected groupings of parts as motivated by the following example. In particular, assume a rack assembly is composed of a chassis and a set of circuit cards. The rack assembly is constrained by which cards can be inserted in which slots. This includes an optical card in an optical slot, an ethernet card in an ethernet slot and a general slot that can accommodate either an ethernet card or an optical card (source is Nathan Sowatskey example). In addition, a particular rack configuration may include a specific number of each type of slot and card. The need is to constrain the hierarchy to only allow these combinations parts. Generalization sets, redefinition, and other mechanisms can help, but require considerable modeling that is cumbersome. The desired capability is to be able to include a constraint in the rack assembly that constrains the allowable instances of the rack assembly. It is also desirable to specify constraints on nested parts using the dot notation. (Refer to related issue 14998 binding to multiplicity in parameterics).

No Data Available

Although explicitly stated that other designations may be used the list should contain at least <<action>>, <<operation>> and <<property>>. Allocation with actions and properties as related elements are shown in the examples in the specification.

The proposed change is not required, but adds clarity.

There is a need to model a broader range of interfaces which extend beyond the current capability of standard ports and flow ports in SysML. One example is the physics based interfaces that are found in Modelica referred to as across and through variables. An example is in an electrical circuit where the interface can be defined in terms of the current and voltage parameters at each input and output node of a circuit. In Modelica, the interface between two components enables Kirchoffs Laws to be imposed on these interfaces such that the voltage on the on the connecting ports are equal, and the sum of the currents on the connecting ports sum to zero. SysML needs to be able to accommodate this type of interface more directly. One possible approach is to extend the concept of a Flow Specification to accommodate other types of properties, such as across and through variables, and not be limited to flow properties.

Disposition: See issue 11628 for resolution

Overly restrictive statement regarding ports in blocks chapter. The following statement in section 8.3.2.2 in the Blocks Chapter is overly restrictive. "A port that is typed by a Block is a special case of a part property, as further defined in Chapter 9, Ports and Flows.". A port is a special class of property that can be typed by classifiers other than blocks. The recommendation is to generalize the wording as follows: A port is another category of property, as further defined in Chapter 9, Ports and Flows.

No Data Available

The property notation from UML to support redefinition and subsetting should be included in SysML explicitly. This notation is not currently included in the diagram element tables in the Blocks Chapter. Refer to property notation in Section 7.3.44 of the Superstructure Specification (v2.3).

Include property subsetting and redefinition in the Block Definition diagram element
tables.

There is an inability to type a flow property or item property by an enumeration. This issue surfaced when Nathan Sowatskey was attempting to model a VLAN network.

Flow properties can be typed by enumerations. They can be typed by
ValueTypes, which is a stereotype based on UML Datatype, a generalization of
UML Enumerations.
Disposition: Closed, no change

16.3.2.3:

(2) /derived: Requirement [0..1]
Derived from all requirements that are the client of a «deriveReqt»
relationship for which this requirement is a supplier.

I don't think we can write OCL to derive this value, at least not
without knowledge of the population of Requirements in which this
instance is situated. How would we navigate from this object, a
Requirement, to that population? I note that the version of the
profile XMI I am using doesn't declare this property as derived. It
appears that at least one SysML tool provider didn't derive it, but
maintains it in their tool and XMI.

I think something like the above criticism can be leveled against all
of the
attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master
that are declared derived in the spec 08-05-16. Perhaps we ought to
remove the '/' and use a word other than "derived" in describing
these attributes.

Likewise 16.3.2.4 RequirementRelated attributes should not be declared
derived.

It may be the case that the OMG needs to be clearer regarding what it
means by "derived." There are attributes whose definition can be
expressed in OCL and there are attributes whose value can only be
found by some (perhaps vaguely specified) analysis of the Model (if
Model is the correct context!). The latter notion is, I think, what
you intend throughout Clause 16. That's fine, except I don't think
the attributes for which this notion applies should be annotated with
the slash. Further, it may be useful to identify what population is
being considered when using terms like "all requirements."

RelatedRequirement properties are actually derived since their values are calculated
from existing relationships linking requirements with other kinds of model elements.
The intent of such derived properties is to specify how some characteristics of
interest can be queried from their owner. For instance a requirement can be property is to model that, given a specific requirement, it is possible to know the
element linked to it through a <<satisfy>> relationship.
Nevertheless, the way to retrieve the actual value of those derived property is
currently specified in an informal manner only. This part of the specification can be
improved by adding the corresponding OCL queries.
Since many of those derived values require getting data across non navigable
association end in the metamodel, the practical way to compute them is to browse all
possible candidate instances and select those of interest. When OCL is used for that
purpose we rely on the allInstances() operation that is predefined for each class. The
Annexe A: “Semantics” of the OCL v2.3.1 specifies the scope to be considered:
• “Object models provide information used as context for OCL expressions and
constraints” (§A.1, p193)
• Object models are defined as structures gathering a set of classes and for
each of those classes sets of: attributes, operations, associations and
generalizations (cf. §A.2.1, p193 and following pages)
• A system state is defined as the snapshot of a system at a particular moment
in time. Given an object model M (as defined above), a system state for that
object model has a finite set of objects sCLASS with sCLASS(c) representing the
subset of all objects of a given class c. Such a system provide the complete
context for evaluating an OCL expression (except post and pre conditions, see
§A.3.1.3, p201)
• In such a context, the interpretation of the allInstances() called on a class c is
specified to be equal to sCLASS(c) (cf. §A.4.4.2, p208)
From a practical point of view, the object model on which a tool shall scope the
evaluation of an OCL expression is the one resulting from loading the topmost
UML::Model element that ultimately contains the context defined for that OCL
expression.

Output pin of a control operator is not a control pin as shown in fig. 11.10. It should be a regular pin typed by ControlValue.

Agreed, and the control flow in Monitor Traction should be a control pin.

The semantics of composition between activities refers to synchronous calls. What happens if the activity is called asynchronously? Is it possible to show that activity in the bdd, too? What is the relationship to the calling activity?

Resolution:
Asynchronous calls start a new execution of the called behavior, but there is
usually no link between the new execution and the calling execution (the caller
invokes, but after that doesn't communicate with the called behavior execution).
If this is needed for some applications, the caller execution can instantiate the
called activity as a class/block, and link the new instance (the new called
execution) to the caller execution via an association. This association would be
composite if the called execution is started synchronously, and non-composite if
it is started asynchronously (using StartObjectBehaviorAction in both cases).
This seems like too much detail of UML to cover in the SysML spec for an
uncommon usage scenario. The filer agrees to close with no change.
Disposition: Closed, no change

Notation for multiple item flows. The UML specification provides a compact notation for multiple information items flowing in the same direction. A similar notation should be provided in SysML, but this is not explicitly called out. Recommendattion. Add a sentence at the end of section 9.3.1.4 which describes diagram extensions for item flows consistent with the UML approach that reads "When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented." Also, include the multiple item flow notation in the Item Flow entry in Table 9.1.

Accept proposed resolution with text that describes diagram extensions for
multiple item flows consistent with the UML approach, and with some additional
constraints on ItemFlow. Note that an item flow can have only one conveyed
classifier. A future revision should consider a constraint that “An ItemFlow must
have a single item property” since the item flow and item property should be
viewed as a single concept in SysML

Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example.

It is convenient to be able to group model elements based on modeler-defined
criteria. Simple examples are groups of elements that may be associated with a
particular release, or with a legacy design. Unfortunately, there is no metaclass in
UML that supports such a concept of collection. The word “group” is preferred to
“partition” in the resolution since the concept of partition would suggest that
participations in those groups are mutually exclusive while this limitation is not
desirable.
UML packages are a means to organize model elements. They have the convenient
semantics except that they imply ownership, whereas it is requested to have no
limitation on the number of groups an element can belong to. Instead, this proposal
extends the UML::Comment metaclass for that purpose. The provided mechanism is
intended to specify groups of model artifacts and should not be extrapolated for
representing groups of runtime elements.
A Comment may be owned by any kind of element and has no semantic side-effect.
It can designate grouped elements using its annotatedElement association, and the
criterion applicable to any element of the group can be defined via its body property. Annotated elements are not owned by the Comment. Thus, built on a
UML::Comment, an ElementGroup does not own its members. There is no limitation
on the number of Comments that can annotate a given element. Thus, any element
can participate in an unlimited number of groups.
Adding an element to a group does not modify it. Then, an element cannot hold any
information about the groups it is member of. Instead a static query
allGroups(e:Element) is provided for that purpose. It returns the set of
ElementGroups a given element is member of.
Note that a group may have some groups among its elements (annotated elements
may be any kind of element, including UML::Comment).
The members of an ElementGroup may optionally be ordered.
The resolution to issue #18653 provides through the concepts of “View and
Viewpoint” the means to compute collections of element as the result of an arbitrary
query applied to a model or to a part of a model. An element group is distinct from
view and viewpoint in that a) element groups provide a means to create persistent
collections of elements, and b) membership of an ElementGroup is asserted rather
than computed. The ElementGroup::member property is derived from the collection
of annotated element. The way this property is derived cannot be modified by the
modeler. Thus, View/Viewpoints and ElementGroup are disjoint concepts. However,
View/Viewpoints can leverage ElementGroup for constructing views.
Since an element group is expected to have a name, and the proposed base class
(i.e., comment) is not a named element, an ElementGroup::name property is added
to the ElementGroup stereotype.

Example figures in chapters are redundant with Annex B sample problem. This creates document maintenance issues. Figures 7.3, 8.11, 9.5, 9.6, 10.2, 10.3, 12.1, 12.2, 12.3, 13.1, 14.1, 14.2, 15.9, and 15.10 are all duplicated in Annex B. It is recommended that these diagrams are removed from chapters in part II and IV of the spec, and instead specifically reference the appropriate diagrams out of Annex B, thus making the specification easier to maintain.

Delete redundant figures, but leave captions to act as notes referencing figures in
Appendix B. This conveniently avoids extensive changes to the body text.

The SysML specification does not define the correct namespace URI for the standard profile(s) - it should.

No Data Available

UML 2.1 added a new structural diagram type, Profile Diagram for the purposes of containing the profile-defining elements. SysML either should be made consistent or should explicitly indicate that the diagram is not part of SysML

The Profile Diagram was proposed as a new SysML diagram since it was added
to UML to support profile definitions. However, the Superstructure Specification,
Table 18.1 and Table 18.2, does not require that profiles be defined on a profile
diagram. The diagram elements needed to specify a profile can be represented
on any structure diagram. As a result, it is recommended not to add a profile
diagram in SysML to limit the number of diagram kinds, and that profile
definitions be represented on package diagrams.
The following text was originally proposed as part of the resolution for this issue,
but did not fit as part of the scope of Annex A. It could be considered as part of a
future revision of SysML, for example as part of Chapter 17, Profiles and Model
Diagrams:
... extra caution is warranted regarding the intent of a profile diagram as
explained below. ...
As far as UML is concerned, a profile can extend the UML metamodel
instead of the UML4SysML subset of UML metamodel. However, a profile
extending the UML may not be compatible with the SysML profile that
extends the UML4SysML subset of the UML. For example, a stereotype
called <<AssociationWithNavigableEnds>> extending UML::Association
with a constraint to the effect that the association ends are navigable and
also owned directly by the association would clearly be incompatible with
the <<Block>> stereotype of SysML per 8.3.2.2. For such cases where the
user intent is clearly in extending the UML4SysML subset of the UML in a
manner that is compatible with the SysML stereotypes and their
constraints, it is important that a SysML tool provides support for
distinguishing user-defined profiles extending the UML metamodels and user-defined profiles extending the UML4SysML subset of the UML in a
manner that is compatible with respect to the SysML stereotypes and their
constraints.
Revised Text:
On p. 171, Annex A.1, change the third paragraph, currently:
SysML does not use all of the UML diagram types such as the object
diagram, communication diagram, interaction overview diagram, timing
diagram, and deployment diagram. This is consistent with the approach
that SysML represents a subset of UML. In the case of deployment
diagrams, the deployment of software to hardware can be represented in
the SysML internal block diagram. In the case of interaction overview and
communication diagrams, it was felt that the SysML behavior diagrams
provided adequate coverage for representing behavior without the need to
include these diagram types. Two new diagram types have been added to
SysML including the requirement diagram and the parametric diagram.
with the following:
SysML does not use all of the UML diagram types such as the object
diagram, communication diagram, interaction overview diagram, timing
diagram, deployment diagram, and profile diagram. This is consistent with
the approach that SysML represents a subset of UML. In the case of
deployment diagrams, the deployment of software to hardware can be
represented in the SysML internal block diagram. In the case of interaction
overview and communication diagrams, it was felt that the SysML
behavior diagrams provided adequate coverage for representing behavior
without the need to include these diagram types. In the case of the profile
diagram, profile definitions can be captured on a package diagram, which
is also allowed in SysML. Two new diagram types have been added to
SysML including the requirement diagram and the parametric diagram.

Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity.

Resolution:
When an Activity property corresponds to a CallBehaviorAction of another
Activity, the value at “runtime” is an instance of the called activity (it can’t be an
instance of the CallBehaviorAction, since Actions are not Classifiers). This value
is not derived from anything else, it’s a new instance of the activity, a new
execution (associations themselves are not derived, only their instances/links).
This information is in the section on CallBehaviorAction. At the time the section
on CallBehaviorAction was written, it was decided not to require a one-to-one
correspondence between property names and CallBehaviorActions, even though
that would typically be true.
Comment from filer:
Except if i miss something, the only way to create an instance of an
activity from another activity is to execute an invocation action. That is: an
activity execution won't instanciate any other activity if it doesn't own the
corresponding invocation action, and conversely any execution of an
CallBehaviorAction will instantiate the corresponding behavior. Then, for a
given Activity, owned invocation action (e.g. CallBehaviorAction) and
activity instance owned by composition are actually not independent. If no
constraint is defined between these two properties the activity definition
can be inconsistent. That's why I suggest that composite associations
between activities should be derived. The two composition associations
you describe above are at different metalevels. The link between Activity
and CallBehaviorAction is specified by an M2 (metamodel) association
and the link itself exists at M1 (user model). The link between Activity and Activity (due to invocation) is specified at M1 and
the link itself exists at M0 (runtime). The constraints between these two
associations is semantics, in the mathmatical sense, and is described in
UML/SysML in natural language (see Executable UML for a mathematical
specification of semantics). The constraints in the UML/SysML spec in the
Constraints sections are syntactic, that is, between M2 and M1.
Disposition: ClosedNoChange

UML 2.2 defines a presentation option for stereotypes for comments. There is no need to repeat that option in SysML. There is no need for a tool vendor to support a UML presentation option to be compliant with the specification. Since SysML depends on the presentation option the chapter 7.3.1.1 should be updated to state that the presentation option is required.

UML 2.2 defines the presentation option for stereotypes for comments. SysML
also defines it as a diagram extension, because it wasn’t mentioned in UML 2.1
which is the basis for SysML 1.1. Due to the update of UML there is no longer a
need to keep the diagram extension in SysML.
It is not necessary to explicitly mention that the presentation option isn’t optional
in SysML. The notation of the affected model elements rationale and problem is
clearly defined in table 7.1.

Summary:

This issue is a complement to issue #12576 that deal only with the output pin.
A control operator should have a regular input pin typed by ControlValue in fig. 11.10.

Control operators typically output control values to affect other actions, based on
inputs that are not control values. In Figure 11.10, the input is Brake Pressure, which
the control operator uses to determine whether the enable to disable Monitor
Traction.
Disposition: Closed, no change

The compliance levels defined for UML 2.1.1 and UML 2.2 merge UML::CommonBehaviors::Communications at L1 instead of at L2 in SysML 1.1 as specified in table 5.2 (Metamodel packages added in Level 2). With UML::CommonBehaviors::Communications at L2, it is not possible to properly define UML::Actions::BasicActions at L1 because UML::Actions::BasicActions::SendSignalAction::signal : UML::CommonBehaviors::Communications::Signal [1] becomes ill-formed at L1.
The UML::CommonBehaviors::Communications package is also absent from table 4.1 (Detail of UML Reuse) in SysML 1.1, clause 4.2 (Architecture).

Update clauses 4.2 (Architecture) and 5.1 (Compliance with UML subset) to
reflect merging UML::CommonBehaviors::Communications at SysML’s L1.
It is not clear what is the purpose of Figure 4.2 as it shows a combination of L2
and L3 content from Table 5.2 and 5.3.

Participant Property constraint #6 not correct. In Blocks, UML Extensions, Stereotypes, Participant Property, remove constraint 6 (the one resrtricting the upper multiplicity of the end property). End properties of associations can have any multiplicity. See example in Figures 8.13 and 8.14, where the deliveredTo end of a participant property has multiplicity 1..*.

The constraint is misstated. The ParticipantProperty is a property of the
association block, and it is this property to which the multiplicity constraint should
apply. Each link of the association block has a value of the participant property
which refers to one instance contained in the referenced end of the association.

The outpin of the control operator in fig. 11.10 is a control pin. But pins of control operators must be normal pins. The action Monitor Traction has no input pin.

Resolution:
This is a duplicate of 12576.
Disposition: See issue 12576 for disposition

Representing multiple item flows on the same connector. The specification should clarify the notation for representing multiple item flows with the same direction on a connector. In particular, UML allows for multiple information items to be represented with a single triangle, along with the list of the information item names spearated by a comma (refer to Figure 17.6 of the Superstructure Spec). A similar notation should be provided to represent multiple items flows in SysML. Proposal resolution: Recommend adding the following sentence at the end of section 9.3.1.4. " When several item flows having the same direction are represented, one triangle can be shown, along with the list of item flows separated by a comma." Also, add a constraint to 9.3.1.4 as follows" 1. If the ItemFlow has an itemProperty, there must be one conveyed classifier which matches the type of the item property.

Disposition: See issue 13945 for disposition

Out of Date Annex D.4: The information in Annex D regarding AP233 needs to be updated. AP233 to be released as DIS and this section needs to be revised to reflect changes to AP233.

see ptc/2009-08-13 for details

Connector Property value text. In Blocks, UML Extensions, Stereotypes, Connector Property, Description, first paragraph, last sentence, the current text implies all instances of association blocks will be values of the connector property. The value is actually the subset of those due to the connector. Suggestion: - remove "exactly those" - replace "that are instances" with "(instances)".

Simplify the wording of this sentence further to refer directly to instances of the
association block. Association blocks are blocks with regular instances, not
merely links. Links cannot ordinarily be referenced by properties of a class, but
because association classes in UML specialize both Association and Class, they
can be referenced like all other class instances. Also modify the wording “that
exist due to instantiation of the block” to allow creation as part of a block at any
time during its lifetime, not merely at the time of instantiation.

The UML rtf’s response to this issue was to add an “isConjugated:Boolean” to the Port definition. This renders superfluous the SysML addition of the conjugated flag on flow ports. The SysML flag needs to be removed. In addition, the notation has changed to use a ~

1. Remove isConjugated:Boolean from SysML since it is not needed anymore.
2. Deprecate (but still maintain for backward compatibility) the current notation
of conjugated flow ports and add the same notation as the new UML
suggests.