<<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.

No Data Available

Experience modelling a wide range of heterogeneous systems has proven that the representation of logical channels as information flows across connections between flowports nested within standard ports is a very useful idiom. It would help if this possibility is explicitly stated in both 9.3.2.3 FlowPort, 9.3.2.7 Standard Port, and illustrated in specification figures. Example: a software application acquires encoded signals representing physical positon and rotation via a high-level software API to a low-level A./D card in a computer. The software application is connected to an A/D module subject to a contract represented by an Interface provided by a standard port (subject ot a protocol). The flow of information corresponding to logical acquired channels can be well represented as flowports nested within the standard port of the A/D module. This example is illustrated in detail at: http://school.nomagic.com/node/194 It is marked as 'significant' because without this idiom of nesting flowports on standard ports it is impossible or very difficult to model a wide range or real-world systems.

No Data Available

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.

No Data Available

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s There are at least three applications of the UML2 Component which I consider very beneficial to practical UML-based systems engineering: 1st: I make extremely heavy use of the technique of stereotyped <<composition>>, <<inhertance>>, <<specialisation>> "wrapper" Components to graphically and logically organise model elements in BDDs (and in class diagrams) "parastically", i.e. without stealing ownership of the contained elements. Especially the <<composition>> wrapper Component is very powerful for diagramming and organising hierarchical assemblies of complex systems. In such cases the wrapping Component has Realizations to the wrapped elements, which can be further leveraged to trace the logical groupings. The recipe is consistent with the UML2.1.1 superstructure (although it is not supported in all UML tools). I contend the wrapper Component strategy should be made officially available to those SysML users who wish to use it (at least as a permitted option). 2nd:If one permits the UML2.1.1 Component the SysML <<requirement>> stereotype can be applied to Components so that Requirements can be graphically nested, which is far more graphically stable than just diagramming Class <<requirement>> Dependencies, and can be consistently applied in combination with the existing relationship stereotypes between SysML requirements. 3rd: Components are far better suited to creating orthogonal, parasitic <<views>> of packaged elements than the Package or Model, which both steal ownership.

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s Discussion:
SysML currently lacks capability to represent system views that define parts or
other substructure differently than other system views. As noted by the issue,
any declaration of ownership or other other model structure in one view cannot
conflict with such declarations in other views. The View stereotype of Package
defined in Chapter 7, Model Elements, only selects elements for inclusion in any
one view, and does not support additional structure which may differ across
views. The proposal to consider Component as a basis for “orthogonal, parasitic
<<views>>” is an interesting possibility, but goes beyond the scope of
incremental change that can be considered in an RTF. Addition of such a fundamental capability to SysML, and a UML profile which bases this capability
on UML Component, could be considered in response to an RFP for a major new
version of SysML.
Disposition: Closed, no change

In Figure 10.3: 'delta-t' is shown with solid-line (AggregationKind 'composite'), is should be shown with a dashed line (AggregationKind 'none') to be consistent with Figure B.26 BDD for EconomyContext.

Discussion:
Figure 10.3 will be replaced with a reference to Figure B.29 as part of the
resolution for Issue 13976, “Example figures in chapters are redundant with
Annex B sample problem.” Issue 12160 raised this same issue on Figure B.29.
Disposition: See issues 12160 and 13976 for disposition

Clarify that a binding connector can have nested connector ends like a regular connector. In particular, clarify that a binding connector can bind to parameters of a nested constraint property, without having to bind to an intermediate parameter of the outer constraint property. A binding connector can clearly bind to a nested value property using the dot notation or directly to a value property nested within parts.

Add sentences to provide the requested clarification. Also remove redundant language from 8.3.2.2 Block now that a separate BindingConnector stereotype has been defined.

10.3.2.2 ConstraintProperty: rewrite constraint [2] so does not refer to 'a SysML Block that is typed by a ConstraintBlock' SysML1.0, 10.3.2.2 ConstraintProperty: 'A constraint property is a property of any block that is typed by a constraint block. .. [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock.' These may both be misinterpreted as applying to "any block that is typed by a constraint block" and "a SysML Block that is typed by a ConstraintBlock" rather than a constraint property typed by a constraint block. Rewrite so that the type condition clearly applies to the owned constraint property, not the owning block, thus: 'A constraint property is a property that is typed by a constraint block and is owned by a block. . [2] The ConstraintProperty stereotype must be applied to any property that is typed by a ConstraintBlock.' (Note that the first constraint already makes it clear that a constraint property is owned by a SysML Block: '[1] A property to which the ConstraintProperty stereotype is applied must be owned by a SysML Block'.)

The ConstraintProperty stereotype expresses a condition that can be entirely derived
from other information in the metamodel, in this case a property of a block that is
typed by a ConstraintBlock. Property stereotypes are not defined for other categories
of property, such as part, reference, or value properties.
The constraints which currently appear under Section 10.3.2.2 ConstraintBlock, only
serve to define the ConstraintProperty category. A definition of the term “constraint
property” can be provided by language under 10.3.2.1 ConstraintBlock, similar to
how categories of part, reference, and value properties are defined under Section
8.3.2.2 Block.
OMG Issue No: 12130 Disposition: Resolved
SysML 1.4 RTF Report Page 25 of 341
Discussion in previous RTF's suggested that a consistent policy be adopted for
“calculated stereotypes” which only classify existing elements. Tools are still free to
establish internal stereotypes or other means to carry such information, but since no
other such calculated stereotypes remain in SysML, the consistent policy is to
remove the ConstraintProperty stereotype from the normative specification. Impact
on existing implementations should be minimal since they may still preserve such a
stereotype if it is useful to their implementation, but this specific stereotype would no
longer be required by the specification.
In the stereotypes for measures of effectiveness defined in Table D.5, require that
the base element for the «objectiveFunction» stereotype be a ConstraintBlock, as
stated in the immediately preceding text: "The objective function is a stereotype of a
ConstraintBlock and the measure of effectiveness is a stereotype of a block
property."

10.3.2.2 ConstraintProperty: add constraint that the AggregationKind must be 'composite' Add a constraint: [3] A property to which the ConstraintProperty stereotype is applied must have AggregationKind 'composite'

Issue 12130, “clarify constraint with OCL as well as text”, drops the
ConstraintProperty stereotype altogether, after analysis of potential OCL
indicated that the constraints added no new information but only served to define
the constraint property category of block properties. A constraint specifying the
AggregationKind of a constraint property (defined simply as any property of a
block typed by a ConstraintBlock) is still appropriate to add, but can no longer
placed under the ConstraintProperty stereotype as recommended by this issue.
Instead, this constraint is being added under the ConstraintBlock stereotype
under Section 8.3.2.1.

10 Constraint Blocks and 10.3.2.1 ConstraintBlock: parameters never clearly defined SysML1.0, 10 Constraint Blocks: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint.' The above does not make clear that parameters are properties that can be typed by a ValueType (yet are not value properties), and it does not exclude nested contraints, which are properties typed by a <<ConstraintBlock>> (although other sentences elsewhere in the specification do make that clearer). Also, it is not clear whether a constraint parameter can be typed by a block (although there are no examples of such in the figures). Rewrite to specify what constraint parameters are: 'A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block typed by a ValueType, Unit, or DataType define the parameters of the constraint.' SysML1.0, 10.3.2.1 ConstraintBlock: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.' Rewrite to explain what constraint parameters are: '.. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. Constraint parameters are properties of a Constraint Block that are typed by either a ValueType, a Unit, or a DataType.' (NB: the resolutions suggested here depends on the unit, value, dimension metamodel being changed to admit the application of Unit as a type.) This matter could be greatly simplified by including a ConstraintParameter stereotype as a point of documentation and specification

SysML does not restrict the type of parameters to which constraint blocks may be
applied. Even though the typical examples apply parametric constraints to value
parameters, such as mathematical expressions that constrain numeric property
values, constraint blocks may also be applied to structural properties such as parts or
reference properties.
Reword the explanatory sentence referenced by the issue from the final introduction
paragraph to avoid suggesting that constraint parameters are the only kind of
property a constraint block may contain. Also, avoid language that excludes recursive
definition of constraint blocks, in which a nested constraint property references the
same constraint block being defined.

B.4.1.2 Package Diagram: <<access>> should be <<import>> SysML1.0: 'B.4.1.2 Package Diagram - Showing Package Structure of the Model .. The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «access» relationship.' In fact Figure B.3 shows <<import>> relationships.

No Data Available

15.3.2.3 AllocateActivityPartition(from Allocations): /supplier (from) /client (to) wrong way round >From SysML1.0 15.3.2.3 AllocateActivityPartition(from Allocations): 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (from) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (to) end of the same «allocate» dependency.' Should read: 'An Action appearing in an «AllocateActivityPartition» will be the /supplier (to) end of an «allocate» dependency. The element that represents the «AllocateActivityPartition» will be the /client (from) end of the same «allocate» dependency.' Note that a similar mixup was reported for 15.3.2.2 Allocated(from Allocations): 'Issue 11501: Wrong ends of Allocate relationship used in Allocated definition (sysml-rtf) 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")'

Above suggestion is incorrect; the action should be the client (from) end. Revise
text consistent with resolution to issue #11501.

Figure 11.10 Suggest use output Pin from <<controlOperator>> 'Enable On Brake Pressure > 0' typed by ControlValue The <<controlOperator>> action ':Enable on Brake Pressure > 0' does not show an output Pin corresponding to an output Parameter of type ControlValue that must exist for the Behavior Enable on Brake Pressure > 0. From SysML1.0: '11.3.2.2 ControlOperator ,, Constraints [1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue. If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.' It would make sense (and be clearer) if the «controlOperator» had an output Pin typed by ControlValue. Below we see the diagram adapted to use an output Pin typed by ControlValue: http://school.nomagicasia.com/node/109 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png

Revise as suggested.

Figure11.10 suggest use anonymous, typed Pins for clear indication of flowing information type and to support

indication of the Action ':Driving' without an output Pin corresponding to an underlying output Parameter of Behavior 'Driving' satisfying the 'isStream=true' condition. Indeed Table 11.1 - Graphical nodes included in activity diagrams shows only Actions with Pins and the

indicator for UML4SysML::Parameter.isStream The following image shows Figure 11.10 adapted to use Pins throughout (except for ControlValue input to the controller Action 'Monitor Traction'): http://school.nomagicasia.com/node/108 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png NB: this issue submissions is marked as 'significant' because the I consider it extremely important that the SysML effort advertises the clear advantages of Pins whereever possible to the benefit of tool vendors and end users.

No Data Available

The «rate» stereotype has a property 'rate' of type ValueSpecification 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8 SysML1.0, 11.3.2.8 Rate: 'The «rate» stereotype has a rate property of type ValueSpecification.' However Figure 11.8 shows 'rate' with type InstanceSpecification. (Also, the 'rate' property should be clearly defined as an Attribute of <<rate>> in 11.3.2.8 Rate.)

The has a rate property of type ValueSpecification. The values of properties stereotyped by "rate" must be instances, see next to last sentence of Section 11.3.2.8 (Rate). The metamodel is enough to show "rate" is an attribute of "rate".

Table 11.1 and Table 11.2: appear to contradict constraint that <<discrete>> and <<continuous>> should not be both applied SysML 1.0, 11.3.2.3 Discrete: '[1] The «discrete» and «continuous» stereotypes cannot be applied to the same element at the same time.' However Table11.1 and Table 11.2 Rate examples appear to show both «discrete» and «continuous» applied to the same element at the same time, and Table 11.1 appears to show overloaded tagged values

and

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

No Data Available

I suggest general policy for SysML: prefer Pins over ObjectNodes in all possible cases Use of ObjectNodes is problematic for many reasons, including: - In UML2.1.1 ObjectNode is abstract ! Tool vendors are thus forced to choose an arbitrary concrete placeholder (like <<CentralBufferNode>>, which is invalid). Use of Pins avoid this problem. - ObjectNodes are graphically less stable than Pins, as on has to manage the placement of ObjectNodes between Actions and two paths. - It is easier to trace type compatibility of connections between between Pins representing typed Parameters than across two paths via an ObjectNode with no binding to Parameters. - The placement of ObjectNodes on swimlanes boundaries (like in Figure B.35) is contrived and graphically unstable. Experience has shown that Pins are far easier to read, verify, and manage, and they correspond well to the idioms of signal processing known to engineers. I recommend that they be used in ALL SysML diagrams wherever possible, and that this be adopted as SysML policy, to the advantage of systems engineers, educators, and tool vendors alike.

No Data Available

SysML1.0, p.188: 'B.4.4.3 Requirement Diagram - Acceleration Requirement Relationships Figure B.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. The “refineReqt” relation, introduced in Figure B.12, ..' Should read '"refine" relation'.

No Data Available

Figure 11.10: Suggest Actions better shown as clearly typed anonymous ClassBehaviorActions (rather than capital names and no type shown). See improved example at: http://school.nomagicasia.com/node/107 http://school.nomagicasia.com/files/images/Figure%2011.10%20-%20Continuous%20system%20example%201_%20Operate%20Car%20(adapted%20to%20use%20Pins,%20no%20annotations)_0.png

No Data Available

The XMI is missing the tags for declaring the namespace and prefix for serializing instances of the stereotypes

This issue is resolved by using the same procedures for preparing the published
artifacts for SysML1.3 as the procedures used for preparing the published
artifacts for UML2.4.1, including StandardProfileL2/L3.
Disposition: See issue 15876 for disposition

The href should reference the URI for the UML elements. This may need the namespace for UML4SysML to match that of UML

SysML1.3 follows the same process used for publishing the artifacts in the 2.4.1
series of UML, MOF and XMI where references to elements defined in external
artifacts use the full document URL of the external artifact. Moreover, there is no
longer a separate UML4SysML artifact – all references to UML metaclasses are
in terms of the full document URL to the UML2.4.1 metamodel.
Disposition: See issue 15876 for disposition

1. The XMI for the SysML has references to the metamodel as follows:

<packagedElement xmi:type="uml:Stereotype" xmi:id="Rate" name="Rate">
<ownedAttribute xmi:type="uml:Property" xmi:id="Rate-base_Parameter" name="base_Parameter" association="Parameter_Rate">
<type xmi:type="uml:Class" href="UML4SysML-metamodel.xmi#Parameter"/>

The type should be cmof:Class not uml:Class

This issue is no longer relevant for SysML1.3 since SysML1.3 extends UML2.4.1
which, altough still a CMOF metamodel, is nonetheless represented as a
UML2.4.1 model. Therefore, in the SysML1.3 XMI, all references to UML
metaclasses are in terms of their UML representation, not CMOF.
Disposition: See issue 15876 for disposition

SysML imports the UML StandardProfileL2. It contains useful stereotypes like modelLibrary. But it also includes stereotypes that extend UML elements that are not supported by SysML like artifact or component. Some stereotypes extend Class. From the viewpoint of SysML they should be an extension of stereotype Block. That's a conflict in the SysML language architecture. Proposal: Remove import of StandardProfileL2 and define a SysML specific standard profile.

Since SysML1.3 extends UML2.4.1 whose StandardProfileL2 library is published
as a normative artifact, it is no longer necessary for SysML to define its own
Trace stereotype; SysML can use StandardProfileL2::Trace instead. However,
except for StandardProfileL2::Metaclass which is used to denote classes that are
part of a metamodel, the SysML specification does not specifically identify any
other stereotype from StandardProfileL2 in its scope.
Within the strict definition of SysML where only the metaclasses in the
UML4SysML subset are allowed, several stereotypes from StandardProfileL2
cannot be used with SysML because they extend classes outside the
UML4SysML subset. Thus, File, Document, Executable, Library, Script and
Source are excluded because they extend Artifact, and Entity, Implement,
Process, Service and Subsystem are excluded because they extend Component.
See resolution to issue 15876 for further details.
Disposition: See issue 15876 for disposition

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 a tag: system:<<system>>[1] <<domain>> could then extend <<system context>>. Visit also: http://school.nomagic.com/node/415

As noted by the issue,Section B.4.2.1, Internal Block Diagram - Setting Context,
includes the following sentence:
The «system» and «external» stereotypes are user defined, not specified
in SysML, but help the modeler to identify the systemof interest relative to
its environment.
Many forms of non-normative stereotypes could be developed to distinguish
particular user modeling distinctions and practices. The issue itself notes possibly
different stereotypes (such as «domain») than those used in the example. The
availability of user-defined stereotypes to make such distinctions is clearly
indicated by the example.Rather than incorporating a particular set of
stereotypes directly in the SysML specification, the original submission
deliberately left these open-ended to support possibly different modeling needs.
Multiple sets of these stereotypes could be developed as part of separately
distributed model libraries. Since the SysML specification is primarily concerned
with the definition of the core SysML language, the omission of further detailed
specification of user-model stereotypes is in keeping with the scoping decisions
of the material to be maintained as a direct part of the SysML specification.
Disposition: Closed, no change

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 by a value property directly by a Unit).

This issue points out that Quantity is a distinct concept from either Unit or
Dimension, even though SysML currently defines stereotypes only for Unit,
Dimension, and a ValueType to type values that may have a unit and/or
dimension.
To resolve these issues, and to clarify terminology to be used in a consistent way
not only for SysML, but for its alignment and close partnership with MARTE, an
extensive effort has been made to model the underlying concepts as defined by
the most recent and authoritative sources. A new Annex C.5 provides a
comprehensive model, expressed in terms of SysML blocks, for the interrelated
concepts pertaining to quantities, units of measure, conversions among units,
and dimensional analysis within systems of quantities.
The new Annex C.5 is non-normative and is intended to fill two basic roles. One
is a detailed conceptual model of the quantities domain, that, with the aid of
examples built as instances of the blocks in this model, thoroughly expresses
and defines the concepts which the SysML quantities-related stereotypes were support for capturing and documenting systems of units and quantities
comprehensively in a form suitable for dimensional analysis.
SysML 1.0 deliberately provided only minimal stereotypes to identify and name
units and/or dimensions associated with value types. It did not provide further
support for defining and documenting them including their relationships to each
other. Practical use of this modest capability has shown that comprehensive
documentation of units and related concepts is an important requirement for
quantity values to be defined unambiguously and used in consistent ways.
Although Annex C.5 provides much more comprehensive support for defining
and organizing unit and quantity-related concepts in reusable domain-specific
libraries than SysML 1.0 did, minimal changes are made to the normative parts of
SysML 1.x for incorporating the new concepts. The principal change is to
rename the current SysML stereotype “Dimension” to “QuantityKind.” The
current definition of Dimension in SysML 1.1 as ”a kind of quantity that may be
stated by means of defined units,” closely matches the QuantityKind concept in
Annex C.5, while Dimension is reserved for a more specialized relationship
between quantity kinds in the context of a system of quantities. To align with this
terminology and avoid any misleading implications of the current name, this
resolution makes a single name change from the SysML 1.1 Dimension
stereotype to QuantityKind and relaxes the restrictive constraints on Dimension
that no longer apply to the QuantityKind concept.
In addition to issue 12219, this resolution addresses two issues previously
deferred in SysML 1.1:
Issue 11600, “SysML dimensions,” pointed out inconsistencies in Unit,
Dimension, and ValueType constraints and statements. The relaxation of
constraints on Dimension (now renamed QuantityKind), Unit, and ValueType,
and related changes to the text included in the resolution for this issue should
resolve those inconsistencies. The resolution for Issue 11600 is therefore being
merged into the resolution for this issue.
Issue 12128, “8.3.2.9 Unit, 8.3.2.10 ValueType,” proposed a new metamodel
based on a class hierarchy for Unit and ValueType to express “the underlying
physical and mathematical principles of a dimensioned quantity represented by a
value subject to chosen units.” Since the resolution for this issue includes an
overall roadmap for the same goals and includes changes to Unit, ValueType,
and QuantityKind with optional support for defining systems of units and
quantities, the resolution of this issue encompasses a resolution for Issue 12128
as well. Although the present resolution does not adopt the solution proposed in Issue 12128, the scope of issue 12219 subsumes that of 12128 and provides
multiple ways to support the key concepts requested in 12128, as part of
incremental and compatible changes for SysML 1.x.

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. Visit also: http://school.nomagic.com/node/331

No Data Available

As discussed at the OMG TM SysML RTF on Th 13Mar2008. The 'defaultValue' compartment should be renamed 'initialValue' (or perhaps 'initialValues'). 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 its Block as a part Property within a higher context, by assignment of a property-specific initial value. The label 'initial values' is also consistent with the UML2.1.1 specification description of the role of the defaultValue attribute of 7.2.44 Property: "If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property." Further, the concept of "initial values" emphasises the evolving value state of a system. The "initial value" is then merely a single value slice within a series of values states. Configuration is a special case of "initial value". Example: when a Car leaves a factory it is "initialised" to a luxury, sports, or family configuration. The concept of "initial value" compartment is complemented by the suggestion of a "current values" or simply "values" compartment for recording the value state of an evolving system. (See related issues submitted by Darren Kelly.) This suggestion promotes support of animation of SysML systems, and also encompasses aspects of static configuration consistently.

No Data Available

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 "initial" configuration/state. This suggestion represents a useful unification of concepts already present in the SysML specification.

This issue was raised prior to the SysML 1.1 adoption of the "initialValues"
compartment on properties on an ibd to specify context-specific initial property
values, and the SysML 1.2 adoption of UML instance specifications to specify
current or sample property values of specific block instances. Full support of
UML instance specifications was chosen by SysML 1.2 to support more complete
specification of instances, including links between instances, than a
"currentValues" compartment could directly support. The suggested capability
would be redundant with the capability already adopted by SysML 1.1 and
SysML 1.2.
Disposition: Closed, no change

SysML needs instance specs capabilities for several reasons

1) compatibility with UML and many users' expectations
2) ability to do animation
3) ability to show particular values at a time
4) educational value / illustration value

No need for a new diagram type, instances can appear on block and sequence diagrams.

No practical substitute has been found for the use of instance specifications to
specify examples, test cases, and other occurrences of blocks defined in SysML
user models. Because SysML tool implementations are based on UML
implementations, diagram support for instance specifications can be simply a
matter of relaxing any constraints that would disable access to these elements
from within a strict SysML subset. Instance specifications are already included in
the SysML metamodel to support other elements of SysML such as the Unit
stereotype and the initial values compartment.
Because SysML already defines a taxonomy of its standard diagram types
(summarized in Annex A and defined in the specification chapters), use of
instance specifications in SysML must be identify a diagram context where they
could appear. While they might appear in more than one diagram context, the
simplest approach for uniformity in user models is to rely on a single context
where they could be shown. Instead of defining an entirely new diagram context,
the block definition diagram is a natural place to show either the definitions of
blocks or instances specifications of these blocks, or any mixture of both. Since all the required metamodel elements for instance specifications are already
present in SysML, the inclusion of their existing UML-based notation can be
specified merely by including their diagram elements in the table of graphical
elements which can be shown on block definition diagrams

Designating a Diagram Frame with a the name of a Stereotyped Model Element Type: Annex A (Diagrams) is not explicit on how to designate a diagram frame with a model element type that has a stereotype applied. If, for example, a diagram is intended to represent a package which has been stereotyped as a model library, one would expect the diagram header to reflect the model library as the designated model element type. The naming of diagram header is defined beginning on pg 173 in Annex A.1, and does not clarify this. The proposed resolution is to allow the name of the stereotype or the name of the base class to be used as the name of the model element type in the diagram header. For the previous example, the name of the model element type could either be [package] or [model library].

Update text per below to allow a stereotype name to appear in the diagram header as the name of the model element type. Also, ensure consistency with this notation throughout the spec. The control operator in the activities chapter needs to be modified in table 11.1 and in the usage example in Figure 11.2.

The viewpoint should use a Behavior element to describe the construction of the view instead of methods and languages. Concrete behaviors could be SysML elements like Activity or Interaction. Or construction rules specified in any language using a OpaqueBehavior element

No Data Available

NAME - JUNCTION PORT Limited ability to model certain typs of physical interfaces in SysML such as mechanical, electrical, optical, and thermal, where the interface does not explicitly represent a flow or a service. An example is the mechanical interface between two parts at their mating surface. An approach was included in a recent paper called "Modeling Continuous System Dynamics in SysML" by Thomas Johnson, Jonathan Jobe, Christiaan Paredis, Roger Burkhart, Proceedings of the IMECE 2007, Nov ' 2007, which is available on the omg sysml website. A stereotype for a junction is introducted to model a mechanical interface (Flange in Fig 4). This concept can be applied more generally to model a mechanical interface. The proposal is to stereotype a port as a <<junction port>> that is typed by a Junction, which would also be a stereotype. The junction would have properties such as a position, and force, and include constraints on its properties such as conservation of mass flow, energy flow, etc. Several subclasses of junction can be defined for mechanical, electrical, thermal, optical, other electromagnetic interfaces, each of which may have different constraints applied. The concstraints can be used in parametrics.

Disposition: See issue 11628 for resolution

The composing owner of FrontWheel is never made clear It is clear from Figure B.18 - Defining Structure of Power Subsystem (Block Definition Diagram) and Figure B.19 - Internal Structure of the Power Subsystem (Internal Block Diagram) that ChassisSubsystem.FrontWheel is shared by PowerSubsystem, and that FrontWheel is a specialisation of WheelHubAssembly.. However nowhere is it made clear which block is the composing owner of FrontWheel (although we may guess that it is ChassisSubsystem). The polymorphic substitution of FrontWheel for WheelHubAssembly is never explained.

Discussion:
Polymorphic substitution is not implied, and elaboration of composing ownership
of frontWheel would add unnecessary complexity to the example without specific
benefit.
Disposition: Closed, no change

B.4.8.3 Activity Diagram (EFFBD): refers incorrectly to objectFlows in BDD Figure B.34 SysML1.0: 'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail) Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34' In fact Figure B.34 is a BDD, so it can't show 'objectFlows'. It shows the Blocks that type the ObjectFlows.

No Data Available

B.4.5.4 Block Definition Diagram: Should say 'white diamond (shared AggregationKind)' not 'white diamond (composition)' SysML1.0: 'B.4.5.4 Block Definition Diagram - Power Subsystem .. Note how the of white diamond (composition) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.' The choice of the word 'composition' in combination with the white diamond is unfortunate, as it implies 'composite' AggregationKind. Rewrite to say 'white diamond (shared AggregationKind)' rather than 'white diamond (composition)': 'Note how the of white diamond (shared AggregationKind) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.'

No Data Available

Figure B.37: the elements allocated from are of type Action, not Activity In table Figure B.37 allocations are made from the following Actions (activity usages): a1:ProportionPower a2:ProvideGasPower a3:ControlElectricPower a4:ProvideElectricPower The 1st column shows them incorrectly as of type Activity. NB: this issue relates to and/or duplicates: Issue 11497: Mixed action and activity concepts (sysml-rtf)

Disposition: See issue 11497 for disposition

Figure B36: ice:InternalCombustionEngine should be allocated from ProvideGasPower, not ConvertGasToPower Figure B36 shows 'ice:InternalCombustionEngine' allocated from '<<activity>> ConvertGasToPower'. Figure B35 shows Action 'a2:ProvideGasPower' allocated to '<<block>> InternalCombustionEngine'. The table in Figure B37 shows Action 'a2:ProvideGasPower' (incorrectly typed as an Activity) allocated to '<<block>> InternalCombustionEngine'. For consistency Figure B36 should show 'ice:InternalCombustionEngine' allocated from Action 'a2:ProvideGasPower'.

Disposition: See issue 11497 for disposition

Figure B36: ecu:PowerControlUnit should be allocated from ProportionPower, not ProportionPowerLoad Figure B36 shows 'ecu:PowerControlUnit' allocated from '<<activity>> ProportionPowerLoad'. Figure B.35 shows Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'. Figure B.37 table shows 'a1:ProportionPower ' allocated to part Property 'ecu:PowerControlUnit'. For consistency Figure B.36 should show Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'.

Disposition: See issue 11497 for disposition

Figure B.36: shows allocations to part Properties, not to Blocks as in Figure B.35 Figure B.35 shows allocations of actions to swimlanes representing blocks. Figure B.36 shows allocations of activities to part properties. Figure B.35 should probably shows allocations of actions to part properties. Figure B.36 should probably show the same allocations of actions to part properties.

Disposition: See issue 11497 for disposition

Figure B.36 emg:ElectricalMotorGenerator should be allocated from a4:ProvideElectricPower not ConvertElectricToPower Figure B.36 shows 'emg:ElectricalMotorGenerator' allocated from <<activity>> ConvertElectricToPower Figure B.35 shows Action 'a4:ProvideElectricPower' allocated to '<<block>> ElectricalMotorGenerator'. The table in Figure B.37 shows 'a4:ProvideElectricPower' (incorrectly typed as an Activity) allocated to '<<block>> ElectricalMotorGenerator'. For consistency Figure B.36 should show 'emg:ElectricalMotorGenerator' allocated from Action 'a4:ProvideElectricPower'.

Disposition: See issue 11497 for disposition

There appears to be a typographical error in Fig 8.5 re: the multiplicity of a NestedConnectorEnd propertyPath. This figure says [2..*], whereas Section 8.3.2.6 says [1..*]. === Specifics: In the SysML 1.0 document (formal/2007-09-01), Fig 8.5 entitled "Abstract syntax extensions for SysML connector ends" shows this for NestedConnectorEnd: - propertyPath: Property [2..*] (ordered) However, Section 8.3.2.6 NestedConnectorEnd has a different multiplicity: - propertyPath: Property [1..*] (ordered) Section 8.3.2.6 seems to be the correct version, as it provides further explanation including stating "The connector end property is not included in the propertyPath list, but instead is held by the role property of the UML ConnectorEnd metaclass.", which is consistent with a multiplicity of [1..*]. The severity of this issue is deemed "Significant" because tool implementations that follow the figure versus ones that follow the section text (which has already occurred) will be incompatible. === Proposed Resolution: Change the multiplicity in Fig 8.5 from [2..*] to [1..*].

Correct the multiplicity in Fig 8.5.

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 value property that is not within a block. A candidate examp[le 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 value properties, and thus admitting application of DistributedProperty stereotype, or substereotype).

Following is the discussion from a previous deferred resolution by the SysML 1.1
RTF:
There are many specialized cases of SysML diagram and model elements
which are not currently covered either by usage examples in the
specification chapters or in Annex B, Sample Problem. A candidate
example as suggested, either by itself or included in other examples,
could be considered in future revisions of the specification.
This is one of many specialized usage cases not covered by examples in the
SysML specification. Examples of DistributedProperty stereotypes applied to
elements of a structured ValueType raise no inherent difficulties of notation or
usage, and so do not cross a threshold of priority to be included in the
specification itself. Such examples would be entirely appropriate to include in
tutorial materials about the SysML language.
Disposition: Closed, no change

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] 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 must have AggregationKind 'composite', a DistributedProperty will also have AggregationKind 'composite'.

As the issue states, examples of DistributedProperty are shown only for ValueType. Since all details of a probability distribution are left to a user-defined subtype of the DistributedProperty stereotype, however, such a stereotype could be applied to a stereotype typed by a block, such as a part or reference property. Such a stereotype could be defined, for example, to express probabilities of different cases of the block instances referenced by the property. For example, a distribution on the expected number of occurrences could be specified for a property with multiplicity greather than one.
By not restricting the kind of property to which the DistributedProperty may be applied, the current text does not limit its application. A statement limiting it to a value property would contradict the lack of restriction intended by the current stereotype. The constraint does not refer to the type of the property itself but to the Block or ValueType which must own the property.
The issue further states the implications that properties with a DistributedProperty stereotype could appear in different compartments or could have different values of AggregationKind. All these implications flow naturally from the lack of any restriction on the kind of property to which the stereotype can be applied.
The Blocks chapter currently lacks any reference to Annex C.5, Distribution Extensions. Section 8.3.2.4 is the natural place in the Blocks chapter where such a reference could be added. This reference can also indicate that the annex defines distributions only on value properties, without suggesting that DistributedProperty stereotypes are necessarily limited to value properties. Such usage is currently the main expected use of DistributedProperty, but there is no need to restrict it from other possible uses. Moreover, it relies only on standard stereotype extension mechanisms, with no custom notation, so all its implications are those which flow naturally from an independent stereotype.

The 6th constraint on blocks is written as follows:

[6] If the aggregation attribute of a property owned by a SysML block is equal to “composite” or “shared,” then the type of the property must be a block

This constraint, as written, limits the use of solid or hollow diamond aggregation relationships from a block to "own" only other blocks.

1) This is not what the original intent was. Apparently it was to prevent the use of aggregation relationships from a block to own dataTypes or valueTypes.
As written, it is overly restrictive for its intent

2) Even the intent is overly restrictive. UML modelers have (for years) modeled the relationship between a class and its attributes as an aggregation relationship.True, software developers have occasionally used the distinction between composite/shared as implementation clues which are unimportant to SysML concerns. However, even though the SysML distinction between an association, aggregation, or composition relationship to a property is irrelevant, the variation of notation allows modelers to use the style they are most familiar with. In addition, for models that move from SysML to UML and back, it allows the preservation of the software hints. It also leverages existing training and educational material on models.

I recommend dropping this constraint completely. At the most, add a sentence in the description section explaining that using the composite/shared relationship to properties has no implementation meaning.

No Data Available

The flow port and the flow specification need more constraints and clarification statements. What does it mean to type a flow port with a block that realizes many flow specifications? What does it mean to type a port with block that realizes many interfaces including some flow specifications? Is it allowed that a flow specification is part of a realization relationship? How to define a complex flow port that uses more than one flow specification?

Any property (including flow ports) that are typed by a classifier that realizes
multiple interfaces (including flow specifications) means the value will support the
features of all the interfaces. This is UML semantics that is not necessary to
restate in SysML. Flow specifications are based on interfaces, and participate in
realization relationships like any other interface. A classifier can realize multiple
interfaces, including flow specifications. This is UML syntax that is not necessary
to restate in SysML.
Disposition: Closed, no change

1) The definition of Constraint [5] for Block in section 8.3.2.2 is defined as "The following constraint under section [...] in the UML Superstructure Specification is removed by SysML: [...]". 2) The UML 2.1.2 Superstructure Specification states in section 18.1.2 under 'Extensibility': "It is not possible to take away any of the constraints that apply to a metamodel such as UML using a profile, [...]". 3) In Section 6 of the SysML-Specification, it is stated that "The SysML specification is defined by using UML 2 specification techniques. These techniques are used to achieve the following goals in the specification. Correctness [...] The specification technique used in this specification describes SysML as a UML extension that is defined using stereotypes and model libraries." The points 1), 2) and 3) together are a contradiction.

The referenced text from the introductory section of Chapter 6 is incorrect.
SysML is defined using not only stereotypes and model libraries, but additional
techniques including diagram extensions as well as the removal of a specific
existing UML constraint, as noted by the issue. The initial statement that "The
SysML specification is defined by using UML 2 specification techniques" is
incorrect since some of these extension techniques are not provided by UML 2.
The second statement that "These techniques are used to achieve the following
goals in the specification" is incorrect since the specification techniques used are
not sufficient to achieve the listed goals. Remove this introductory section entirely
to avoid misleading statements and to eliminate the contradition noted by the
issue.

I would suggest changing the icons you have chosen for FlowPort. Hence, in the following picture extracted from the spec., ac and dc are understood respectively as input and output flow port.

But, if I move dc on left hand side of the rectangle denoted Transformer, ac on the right, dc becomes an input and ac becomes an output. I suggest you to adopt the ones defined within MARTE (see following picture).

No Data Available

OMG SysML 1.0 is an extension of UML 2.1.1. The next version OMG SysML 1.1 should be an extension of UML 2.2 to avoid a gap between these two closely related standards. According to UML 2.2 SysML should support OMG XMI 2.2 instead of XMI 2.1.

Since the RTF of the UML 2.2 has not finished its work, it is too early to define OMG SysML as an extension of UML 2.2. It is not possible to analyse the impact.
However, there is a minor mistake in the UML4SysML definition. UML4SysML imports the UML StandardProfileL1 which doesn't exist in UML. It should be the StandardProfileL2.

Section 7.4, part of the standard, utilizes the <<moe>> stereotype. <<moe>> is not part of the standard. Annex C, where <<moe>> is defined, states "This annex describes useful non-normative extensions to SysML that may be considered for standardization in future versions of the language." The standard should not be infected with non-standardized stereotypes. <<moe>> should be removed from section 7.4 or added to the standard.

No Data Available

Don't the authors find it embarrassing that their solution to a sample problem isn't even compliant with their own specification? In section B.4.2.1, its states "The «system» and «external» stereotypes are user defined, not specified in SysML,...". I don't care what excuse the authors come up with, "user defined" stereotypes should not be used. The concept of "user defined" or just "making up" stereotypes is inconsistent with the concept of profiles. By standard, «system» and «external» must be in a profile since they are not standard UML keywords nor stereotypes. The authors need to remove homemade stereotypes from their example or add them to the profile. The removal of the homemade stereotypes will likely prove the current specification inadequate.

No Data Available

Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute This strategy provides a compact and elegant metamodel for 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. See also analysis image and commentary at: http://school.nomagicasia.com/node/126

Disposition: See issue 12219 for disposition

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

No Data Available

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

(This discussion is elaborated from RTF Telecon Minutes 2008-02-13 &
2008-02-13)
This issue asks that the name of a requirement be in italics, in keeping with the rules on UML classes when isAbstract is True. This raises the following questions:
1. Do requirements need to be abstract? In order to answer this, we need to address the following.
2. Do requirements need subclasses? SysML does not currently support any form of subclassing of requirements.
3. How robustly do requirements need to support properties? Are static properties necessary?
One philosophy considers that if requirements had any features such as properties, they could be only static features that applied to the entire requirement class and not to any instance, which was part of the rationale for the isAbstract = True constraint.
If static properties were supported on SysML requirements, along with adding specialization (subclassing) relationships between requirements, they could support a more complete form of property-based requirements in addition to their current support for text-based requirements. This would more closely parallel the requirements capability in STEP AP233, which has support for both text- and property-based requirements. It would also allow performance requirements to be stated by defined property values that could participate in parametrics or other analysis.
In the original submission, however, the SysML model of requirements has been left deliberately simple without further detail for modeling the system itself, in part so SysML would more closely match the scope and structure of typical requirements specifications which have simple containment models of text-based statements. Associating properties with requirements relied on linking requirements to highly abstract models of system structure, built using SysML blocks, and providing a skeleton model of system structure to which properties would belong. This is appropriate because the properties are typically of the system, rather than of the requirement, e.g. "the car shall weigh less than 3000lb" implies that weight is a property of the car. This approach also provides a more extensive means to capture properties and other details of an evolving system very early in its specification process. This option remains available in SysML to model greater detail about requirements that need to go to a greater level of detail or precision.
This remains a clear and consistent approach to SysML requirements, and should not be reconsidered at this time. The decision of this resolution is not to add any additional support for requirements subclassing or properties in this revision of SysML. Separate issues could be raised for future revisions of SysML to consider adding requirements subclassing or properties, but such an addition is outside the scope of this issue, which seeks only to make the font of requirement names consistent with the isAbstract attribute.
Given the lack of subclassing for SysML requirements, the constraint on isAbstract has no added semantics and could be constrained either way. The main issue at this point is simply whether the names of requirements should be in italics or not. Forcing the names into italics, to be consistent with the current constraint, would change the notation defined by the current specification and used in all the current requirements examples. Removing the current constraint will allow tools to keep the name consistent with the setting of the isAbstract attribute. The same resolution should apply to Viewpoint in Chapter 7, which has the same constraint on the isAbstract attribute.

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?

No Data Available

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

No Data Available

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.

No Data Available

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

The table and matrix diagram kinds are rarely mentioned in appendix A. To have a complete overview of all diagram kinds they should be added to the bullet lists.

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

Discussion:
Issue may be accomplished by modeling style (e.g. use package containment for
“x-or” instead of requirement containment). No need to encumber SysML with
Boolean operators for requirement satisfaction or containment.
Disposition: Closed, no change

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

As the issue notes, the notation that SysML defines for Dimension and Unit differs the standard UML notation for InstanceSpecification. Revise the subsection for Unit and Dimension under 8.3.1 Diagram Extensions to describe the specific notation that SysML defines for these two elements. Revise the text for how stereotype properties of Unit and ValueType reference these elements.

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)

Update referenced figures to represent allocation of usage (Action to Part).
Update figure B.35 to use colon notation for the part represented by the
AllocateActivityPartitions. Note that this proposal also resolves issues #12148,
12149, 12150, 12151 and 12153

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

This issue is being deferred because no proposed resolution was voted on during
the schedule of the SysML 1.3 RTF.
Disposition: Deferred The private port notation, in which a port located inside a containing rectangle had
more restricted visibility than ports placed on the boundary of the rectangle, was
included in UML 2.0 but removed in subsequent UML revisions. SysML specifies that
all ports be placed on the rectangle boundary.
SysML specifies its own specific notation for constraint properties and their constraint
parameters within a parametric diagram, in which the constraint parameter must be
shown flush inside the boundary of a constraint property.
The constraint property also has its own specific notation as a round-cornered
rectangle. No conflict with any UML notation is present within this specific diagram
context.
Disposition: Closed, no change

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

Fix the type of the unit and dimension attributes on ValueType as suggested, and to match that abstract syntax shown in Figure 8.4.

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 desired notation is that a "satisfy" dependency be displayed with an open arrowhead like all the other dependencies between SysML requirements. Rather than specialize Realization, which carries its notation of a closed arrowhead, change the the abstract syntax shown in Figure 16.1 to have Satisfy specialize UML Trace, like all the other dependencies defined in this figure.

<<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)

Discussion:
A resolution for this issue was never completed during the SysML 1.1 RTF, but
the issue raised was resolved by Issue 11269 in SysML 1.1. Issue 11269 had
the identical title, «satisfy» is displayed as dependency, and had the following
description:
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 change made by resolution of 11269 was to change «satisfy» to be a
stereotype of Trace rather than Realization (the same as the DeriveReqt, Verify,
and Copy dependencies), which resolved the discrepancy in the notation.
This issue should have been resolved by the SysML 1.1 RTF as
Duplicate/merged with Issue 11269. To correct the oversight, this resolution will
close the issue as part of the SysML 1.2 RTF.
Disposition: See issue 11269 (in the SysML 1.1 RTF Report) for
disposition

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)

No Data Available

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.

No Data Available

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.

A property-specific type defines a new specialization of a single existing classifier, which was used to type a single property in the definition of a block which owns that property. The PropertySpecificType stereotype is used in the SysML metamodel to distinguish a classifier created by this mechanism from classifiers created by all other forms of user definitions.
Within the property-specific type, new or redefined properties or other features such as operations may be defined. Within a property defined within a property-specific type, one option is to specify a default value. As the resolutions for issues 10473 and 11502 indicate, however, an initialValues compartment may be used instead of a property-specific type if all that is needed are context-specific values and not a more customized definition of the classifier that types a property.
If the property-specific type is used to define a feature that carries its own default value, that default value is specific to that property. The default value of a property owned by a classifier carries its value by means of a UML ValueSpecification. It is not considered as an instance of the property, and the classifier provides only the definitions of its properties and not any instance to be referenced.
The suggestion to add a paragraph to Section 8.3.2.8 to better explain the PropertySpecificType stereotype is valid, and Issue 11308 also requested somewhat less obscure explanation of the meaning of this stereotype. A full explanation of the representation of the metamodel representation of a property-specific type would benefit from examples of metaclass instances that could be represent specific example models, but the SysML specification does not currently include such metamodel instance examples. The revised text below is intended as an initial start toward a somewhat less opaque explanation, but falls short of full metamodel examples or other forms of explanations which could still be considered for future revisions of the spec.

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.

No Data Available

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

Discussion:
This issue is being deferred as part of the same overall discussion and
consideration noted under the resolution for Issue 12128, “8.3.2.9 Unit, 8.3.2.10
ValueType.” As noted there, the scope of any potential changes to the current
ValueType, Unit, and Dimension metamodel has ended up beyond the workload
that could be completed during this RTF. Relaxing the current constraints, as well
as extensions or changes to the current model, should continue to be evaluated
for future versions of SysML. In the meantime, a workaround could be to define
new units if necessary to carry different dimensions. The statement in Section 8.4.2 is in a usage example for the definition of value
types with SI units. It is not intended to imply that a unit must have a dimension,
just that if a unit does already identify a dimension, the dimension need not also
be specified. This language could be further clarified if needed in future updates
of the specification.
Disposition: See issue 12219 for disposition

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

No Data Available

Apparently from 9.3.2.3 while you can type a flowport by a block, that block indicates the things that flow over the port.

A more intuitive interpretation would be that the flowport is a block. Most flowports appear to be physical things that may convey blocks.

Without the ability to indicate the physical thing that is the block, you lose the ability to specify it, reuse it, define it, etc.

It’s much more intuitive to indicate that the flowport is a

US-110voltACmale

In addition, for example, in Figure B.19. There are flowpoints named

Port:FuelTankFitting

Port:ICEFuelFitting

Based on section 9.3.2.3, these flowports convey Fittings, not Fuel.

There needs to be a way, preferably graphically, that would indicate that the type of Flowport is a block, and in that block, allow for the definitiaojn of what flows.

Ports are properties, so cannot be blocks, but the resolution of issue 13178
clarifies that some ports represent a new, potentially physical, element in the
system (full ports). These can be typed by blocks that have flow properties as
well as other kinds of properties, as suggested above. Some ports do not
represent a new element in the system (proxy ports). Flow specifications and
non-atomic flow ports are deprecated.as redundant.

The following text cites two OMG documents: "The OMG SysML requirements traceability matrix traces this specification to the original source requirements in the UML for Systems Engineering RFP (ad/2003-03-41). The traceability matrix is included by reference in a separate document (ptc/2007-03-09)." Someone unfamiliar with the OMG process has no way of knowing how to obtain these two documents. They should be cited by URL; e.g., http://doc.omg.org/ptc/2007-03-09

Use URL references as suggested.

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

Writer of this issue correctly points out an inconsistency between the text in section 15.3.1.1, 15.3.2.1, and 15.3.2.2, with respect to the client and supplier ends of the allocation relationship. Text will be modified to resolve this inconsistency.

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.

Following is the discussion from a previous deferred resolution by the SysML 1.1
RTF:
Much useful interaction and review of material from both MARTE and
SysML has occurred within the RTF, especially on topics such as
definition of quantity types, models of time, the need for value
specifications, and the need to align allocations. Some opportunities for
alignment can continue to be addressed in resolutions to other, more
specific issues. This more general issue, however, will also be deferred,
so that many remaining opportunities for alignment can continue to be
pursued. Some specific areas of possible alignment, such as support for
expressions in the MARTE Value Specification Language (VSL), are
premature until the MARTE specification has completed its finalization.
Ongoing discussion and development of potential common elements is
continuing to occur between the SysML and MARTE RTF's. This generic
placeholder issue should now replaced by specific issues that address specific
points of alignment between the two specifications.
Disposition: Closed, no change

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

Correct the descriptions of the UML notations which SysML excludes.
The statement about an "X" on the end of an association does seem consistent with this statement from the UML Superstructure spec, under 7.3.3 Association, "Notation" subsection:
A small x on the end of an association indicates the end is not navigable.

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

Amend the cited sentence to indicate optional out parameters do not need to have values to end execution.

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

No Data Available

Replace horrific long UML URL with short form: http://doc.omg.org/formal/2007-02-03

Implement the requested form of URL reference.
For consistency with references elsewhere in the spec, include the URL form of reference only in Chapter 2 Normative References, and refer to specifications only by name elsewhere in the spec

The outline indenture for the Atomic Flow Ports (9.4.1.1) and non Atomic Flow Ports (9.4.1.2)usage examples is incorrect. They should be 9.4.2 and 9.4.3 respectively.

Update indentures per above

In the notation table for sequence diagrams there is no reference to interaction parameters, or to arguments of interaction uses.

Supply identified missing notation in table 12.1.

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.

This is addressed in the resolution of issue 13178 by enabling blocks typing ports
to have flow properties, where the blocks can support operations and receptions
or realize interfaces that do the same.

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

Instead of a long discussion on the differences between SW and SE perspectives
on use cases, we add some words to clarify the SE goal/requirement-oriented
perspective, trying to avoided use of UCDs as flow charts. This approach leaves
open the possibility of compatibility with SW approaches.
In addition, a minor grammatical error is fixed.
Revised Text:

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:
Stereotypes as property types are permitted as part of associations to stereotypes. Section 18.3.6 Profile of the UML 2.1.2 Superstructure spec contains the following paragraph:
Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
Disposition: Closed, no change

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.

Change the following paragraph in section 9.3.2.3:
"Flow ports relay items to/from the associated connector to/from properties of the owning block or parameters of the block behavior if the port is not connected to an internal link that may relay the items to an internal part of its owner. This means that every flow property contained within a flow port is bound to a property owned by the block or a parameter of the block behavior."
To:
"Flow ports relay items to their owning block or to a connector that connects them with their owner's internal parts (internal connector).
The isBehavior attribute inherited from UML port is interpreted in the following way: if isBehavior is set to true, then the items are relayed to\from the owning block. More specifically, every flow property within the flow port is bound to a property owned by the port's owning block or to a parameter of its behavior. If isBehavior is set to false, then the flow port must be connected to an internal connector which in turn related the items via the port. The need for isBehavior is mainly to allow specification of internal parts relaying items to their containing part via flow ports"
Add the following constraint:
[5] If a flow port is not connected to an internal part then isBehavior should be set to true.

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.

The referenced section no longer exists in SysML 1.0. The BlockProperty stereotype was removed and its descriptive material incorporated in 8.3.2.2 Block. The previous text referenced by issue is no longer included in the resulting text. The referenced paragraph in the Final Adopted Specification, ptc/06-05-04, previously read:
Parts may be used to show all the components from which a larger system is built. Consistent with UML, however, SysML currently does not provide any means to indicate whether all the parts which make up a larger system are either shown on a particular diagram or contained within a model. Various forms of diagram or model annotation, such as a Diagram Description note as shown in Annex A, may be used to communicate completeness of a diagram or model to a user.
Since this text no longer exists in the 1.0 specification, this issue no longer applies. If there is a need to define a concept of Bill of Material properties within SysML, either by description or by additional metamodel elements, a new issue requesting changes to the current text could be raised and considered within future revisions of SysML.
Disposition: Closed, no change

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.

Discussion:
SysML should not specify the layout and format of tables. There has never been
any intent to standardize them in SysML 1.x. Legibility of example tables will be
improved as each is modified in response to other changes.
Disposition: Closed, no change

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

Following is the discussion from a previous deferred resolution by the SysML
FTF:
It was felt that there is a need for experience in SysML prior to making
such a change or extension. Deferred for future consideration.
This issue is being deferred because no proposed resolution was voted on during
the schedule of the SysML 1.3 RTF.
Disposition: Deferred The new proxy ports and full ports defined in SysML 1.3 allow a mixture of
inputs/outputs (using flow properties) and services (using directed features and
provided/required interfaces). Flow ports have been deprecated. As a result there is
no need for matching rules between flow ports and ports anymore.
Disposition: Closed, no change

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:
This issue was previously deferred by the SysML 1.1 RTF with the following
discussion at that time:
A full resolution of this issue is beyond the scope of an RTF. The issue is
being deferred, however, so that additional explanatory material could be
considered in a future RTF to clarify the scope of modeling supported by
SysML or to suggest possible workarounds. A full resolution of this issue
could be considered in an RFP for SysML 2.0.
Addition of support for specifying reusable architectural patterns was considered
to be beyond the scope of an RTF, so this issue is being closed. Requirements
or proposals to add such support can be considered under a future RFP.
Disposition: Closed, no change

Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio

All remaining occurrences of << and >> have already been replaced by « and ».
Disposition: Closed, no change

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

The primary readers intended by this chapter are tool vendors responsible for implementations that comply with the SysML specification and user specialists responsible for evaluating compliance of tools. This audience is expected to have extensive familiarity with the other OMG specifications which SysML extends.
Additional explanatory material could be added either to this chapter or elsewhere, but edits would best be driven by specific suggestions after greater experience with the compliance levels and their UML dependencies has been gained.
Disposition: Closed, no change

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

.

Considerable improvement was made to the diagrams included in the OMG Available Specification for 1.0, produced after the FTF Convenience Document was completed. Issues of uniformity and consistent quality to diagrams are expected to continue as part of ongoing editorial cleanup of the spec. Since the issue refers to the now-completed FTF, it should be closed. Further fixes can be completed either by ongoing editorial work or by issues raised against specific diagrams.
Disposition: Closed, no change

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

Replace figure 16.8 with attached figure. Caption is unchanged

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.

In keeping with the request to “address this on a priority basis to selected
constraints,” SysML 1.2 is beginning to include its first limited set of OCL
constraints to supplement the current natural language statements of constraints.
In addition to an OCL constraint included in the resoluton of Issue 12129 in
Chapter 10 Constraint Blocks, this resoluton includes an OCL constraint for one
more existing constraint.
Since continuing to supply OCL versions of constraints will be an ongoing effort
over multiple revisions of SysML, new versions of this issue should continue to
be raised for consideration by future RTF’s. This issue number, however, is
being resolved so that it can provide a place to provide the statement of a
specific OCL constraint not included in any other issue resolution.

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

No Data Available

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

1.1 spec (“shared AggregationKind” – text update per issue 12142). Updating
Figure B.16 should be done for consistency. Figure B.26 does not immediately
lend itself to “shared AggregationKind”, so will remain unchanged.

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.

Discussion:
This issue was previously deferred by the SysML 1.1 RTF with the following
discussion at that time:
A full resolution of this issue is beyond the scope of an RTF. The issue is
being deferred, however, so that additional explanatory material could be
considered in a future RTF to clarify the scope of modeling supported by
SysML or to suggest possible workarounds. A full resolution of this issue
could be considered in an RFP for SysML 2.0.
Addition of support for modeling of alternative models was considered to be
beyond the scope of an RTF, so this issue is being closed. Requirements or
proposals to add such support can be considered under a future RFP.
Disposition: Closed, no change

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

Discussion:
Related to issue 11501 (resolved in RTF 1.1), and 12139, making the spec
consistent. The arrowhead must always represent the “AllocatedTo” end of
the dependency, since any other direction would be counterintuitive, and the
derived property of the model element at the arrowhead end must be
“AllocatedFrom XXX”, where XXX is the model element at the other end of the
allocation dependency. Similar concept to “Trace” relationship - see issue 10343.
Which end of the dependency is client and which is supplier is unimportant in
practice, and invisible to the user. Allocation is based on Abstraction (UML 2.1.2
Superstructure Section 7.3.1), which accommodates various directionality and
mappings. Linguistic merits of directionality may be debated, but at this point
Table 15.1 and Section 15.2.2 are consistent and no further changes are
required.
Disposition: Closed, no change

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.

Discussion:
Lifecycle and access right management is out of scope of SysML. The resolution
has been discussed with the author of the issue who agrees to close the issue
without any change.
Disposition: Closed, no change

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.

In Figure 17.6, replace Block symbol with the Block stereotype definition shown in Figure 8.2.
In the paragraph after Figure 17.6, remove "(in this case none)" from the 4th sentence.

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

The best solution is to use package diagrams to describe profiles.

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

Disposition: See issue 10517 for disposition

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

Use ""block" instead of "class" unless specifically referring to UML.

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.

Discussion:
The above reference to Annex A (Section A.1 pg 173) is not referring to model
elements that can appear on a block definition diagram, internal block diagram or
any other diagram. It is referring to the type of model element that is represented
by the frame of the diagram. As a result, this is a misinterpretation of the content.
It is felt that the description is adequately clear, so no change is required.
The type of model elements that can appear on a diagram are specified in the
applicable chapter as described in the last paragraph on pg 172 in Annex A.
Disposition: Closed, no change

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?

No Data Available

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.

Agreed. Propagation rule is unnecessary and should be deleted

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

No Data Available

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.

Change the specification of the defaultValue compartment to base its internal metamodel representation on UML InstanceValue, and to decouple the representation of context-specific property values entirely from property-specific types. Also rename the compartment to "initialValues" to more accurately indicate the ability of these compartments to provide values which are assigned in a local property-specific context to override of any existing default or initial values defined on underlying blocks that may type a property.
As background, this issue was previously deferred by the FTF with the following discussion comments:
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.
The scope of this resolution is to clarify the graphical syntax and internal metamodel for the "initialValues" compartment that may be shown on properties on an internal block diagram. Other issues, such as 12277 and 12353, request additional support for display of context-specific values using forms of concrete syntax for UML InstanceSpecification or else additional forms of compartments on properties on an ibd. These issues are being deferred, but can be reconsidered in the future following this initial step to clarify the initialValues compartment, as included in the scope of this resolution. Other forms of textual syntax for complex values, such as the MARTE Value Specification Language (VSL), could also be considered by future issue resolutions following the current RTF.
Issue 11502, "PropertySpecificType concept is highly ineffective and suboptimal," has its own resolution of Closed, no change, but this resolution is based partly on the ability of the initialValues compartment to remove one of the major reasons why property-specific types might need to be used. Instead, use of the more complicated property-specific type mechanism can be reserved for cases in which new or redefined features are really needed in a new specialized property-specific type, rather than merely an assignment of local values. See the resolution for Issue 11502 for more information.
Issues 12361, "defaultValue should be renamed initialValue(s)," and 12363, "Decouple 'values' compartment for a part Property in an IBD from PropertySpecificType" record some of the history of working discussions by the RTF on the defaultValue compartment issue, as well as additional perspective. All specific changes to the specification are being consolidated under this issue, so these two other issues are being closed as having their resolutions merged under this one.

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

Following is the paragraph labed "Instance level," which now appears in the
section numbered 6.3.2 in the UML 2.4 Superstructure Specification:
Instance level – These are the things that models represent at runtime.
They don’t appear in models directly (except very occasionally as detailed
examples), but they are necessary to explain the semantics of what
models mean. These classes do not appear at all in the UML2 metamodel
or in UML models, but they underlie the meaning of models. We provide a
brief runtime metamodel in the Common Behavior chapter, but we do not
formally define the semantics of UML using the runtime metamodel. Such
a formal definition would be a major amount of work.
Since SysML already includes the semantics of existing UML elements, except
as specifically changed or extended by SysML, this existing language (which has
not changed since UML 2.1) applies to SysML.
SysML already includes the following statement in Section 6.1, which leaves
open the option to consider further semantics in the future, but in the meantime
leaves them open just as does UML:
SysML is specified using a combination of UML modeling techniques and
precise natural language to balance rigor andunderstandability. Use of
more formal constraints and semantics may be applied in future versions
to further increase the precision of the language.
Given the generality of both the UML and SysML statements about formal
semantics, no change is required to the current version of the SysML
specification. A new issue could be raised if future versions of UML adopt a
formal specification of semantics that would also need to be adapted or reflected
by SysML, but such an issue should be raised against specific future changes to
UML.
Disposition: Closed, no change

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?

Table 16.2 is correct, spec is inconsistent. 16.3.2.3 and 16.3.2.4 should be
updated to correct attributes associated with the trace relationship.

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?

Change the constraint on the conveyed classifier of items flows to be the same
as the constraint on item properties. In answer to the question, item flows can
convey items that have flow properties, but these flow properties apply to the
item itself, not the source and target of the flow.

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

p:Real=1.2 but not: <<uniform>>

p:Real=2.3

Any value assigned to a property must lie within the values having non-zero
probabilities as defined by an applied DistributedProperty stereotype. These
constraint semantics are inherent in the concept of a probability distribution, and
apply to the default or initial value along with all other values.
How any further patterns of probabilities can expected to be observed, however,
is currently unspecified by SysML. For example, the probabilities might be seen
across the property values of different instances, or within a succession of values
carried by a single instance. A specific user model must specify any such further
interpretation of its applied property value distributions.
Until or unless the SysML specification addresses more specific cases of how a
user model must interpret its property value distributions, it is premature to
preclude any interpretation that a model might apply. Different interpretations
may be appropriate for different models, each of which may document any
specific timing or scope for the values which may occur under the probability
distribution.
As referenced by section 8.3.2.3, some initial examples of distributed property
stereotype definitions and their application in a user model are already provided
in Annex C.6.
Disposition: Closed, no change

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

No Data Available

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.

Annex G no longer exists in the SysML 1.0 specification. Formerly, it held BNF Diagram Syntax Definitions, but this annex was dropped by the FTF. A new Diagram Definition RFP may provide a more complete framework in which to define concrete syntax for SysML and other UML-based languages, but a separate issue should be raised to add such concrete syntax definitions when appropriate
Disposition: Closed, no change

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.

Change remaining occurrences of "sub-type" to "subtype". The OMG Available Specification for SysML 1.0 no longer contains any occurrences of "sub-type" in Chapter 16, but occurrences do still remain in Chapter 9 and Annex C.

In SysML 9.3.2.4, the possible flow directions include

nout

based on later usage, this is incorrect for

inout.

No Data Available

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.

The submitter is correct

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

While the UML 2.x spec may not yet be consistent, it appears that the term "role name" has been replaced by "association end name".

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?