Dimension and Unit Base Class. In Blocks, Dimension 8.3.2.4 and Unit 8.3.2.4, there are constraints that eliminate the use of the dimension and unit properties. This indicates that Dimension and Unit should not be specializations of ValueType. They should be based on Datatype without specializing from ValueType. They do not fit the definition of ValueType in 8.3.2.7.

No Data Available

Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

Proposed resolution:
For clarity use the term 'Profile Diagram in section 18.4
Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

No Data Available

Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

The submitter is correct; see revised text.

No default value specified for Generalization::isSubstitutable.
This is the only Boolean attribute in the whole specification without a default value

For consistency and correctness, add a default value as the summary mentions.

My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

This issue is an identical duplicate, submitted by the same author, as issue 10777

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.

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.

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

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

Parameters of constraint properties. In Constraint Blocks, ConstraintProperty 10.3.2.2, second sentence, "Parameters of the constraint property" should be "Parameters of the type of a constraint property".

No Data Available

Binding connectors in constraint blocks. In Constraint Blocks, ConstraintBlock 10.3.2.1, first paragraph, should say something about binding connectors.

No Data Available

The following 6 references to UML 2.0 should probably be converted to UML 2.1 (please review though). Also remember when the references are changed to UML 2.1, the OMG document numbers need to be updated also

Note I’m using the PDF page number (physical) not the page number on the bottom of the page

Page 4 – Use of specification – Terms, Conditions & Notices

The specification customizes the Unified Modeling Language (UML) specification of the Object Management Group (OMG) to address the requirements of Systems Engineering as specified in the UML for Systems Engineering RFP, OMG document number ad/2003-03-41. This document includes references to and excerpts from the UML 2.0 Superstructure Specification (OMG document number Formal/05-07-04) and UML 2.0 Infrastructure Specification (OMG document number ptc/04-10-14) with copyright holders and conditions as noted in those documents.

Page 69 8.3.2.1 Block à Constraints

[5]The following constraint under Section 9.3.6, “Connector” in the UML 2.0 Superstructure Specification (OMG document formal/05-07-04) is removed by SysML: “[3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be ports of such roles.”

P 99 Part III Behavioral Constructs

This Part specifies the dynamic, behavioral constructs used in SysML behavioral diagrams, including the activity diagram, sequence diagram, state machine diagram, and use case diagram. The behavioral constructs are defined in Chapter 11, “Activities,” Chapter 12, “Interactions,” Chapter 13, “State Machines,” and Chapter 14, “Use Cases.” The activities chapter defines the extensions to UML 2.0 activities, which represent the basic unit of behavior that is used in activity, sequence, and state machine diagrams.

Page 122. Table 12.1

1. Table is compliant with UML 2.0 Superstructure source document dated 050704.

P 237. D.3 XMI Serialization of SysML

UML 2.0 is formally defined using the OMG Meta Object Facility (MOF). MOF can be considered a language for specifying modeling languages. The

No Data Available

Backslash typos. In Requirements, RequirementRelated 16.3.2.4, Attributes, backslahses should be forward

No Data Available

Flow port isAtomic derivation.In Ports and Flows, FlowPort 9.3.2.5, Attributes, /isAtomic, should explain this in terms of the flow specification, rather than circularly with "atomic".

No Data Available

Flow ports direction for non-atomic ports. In Ports and Flows, FlowPort 9.3.2.5, should explain why non-atomic ports cannot have direction. Multiple types of things can flow in a direction just as much as a single type of thing. If multiple types of things can flow in a direction, then the spec should be updated for that.

No Data Available

Relaying to properties. In Ports and Flows, FlowPort 9.3.2.5, Description, sixth paragraph, the semantics relaying properties is very unclear. Are the values propogated from one end of the connector to the other and stored in properties? Do new values overwrite old ones?

No Data Available

Relaying instances. In Ports and Flow, FlowPort 9.3.2.5, Description, implies that type are relayed, but it is the instances of the types that are relayed: "Atomic Flow Ports relay a single usage of a Block, Value-Type, Data-Type or Signal." The term "usage" at least informally is a type-level notion, see fourth paragraph of 8.1.

No Data Available

ItemFlow constraint [4]. In Ports and Flows, ItemFlow 9.3.2.8, constraint [4] says The "type of itemProperty should be the same or a sub-type of the conveyedClassifier." Presumably this should be generalization: "The type of the itemProperty must be same or a generalization of the conveyedClassifier". If it were a subtype, then there could be instances of the conveyed classifier that could not be values of the item property. Or maybe the types should be required to be identical.

No Data Available

ItemFlow constraint [2]. In Ports and Flows, Figure 9.2 shows the itemProperty on ItemFlows restricted to block properties in (has BlockProperty as type), but ItemFlow 9.3.2.8, constraint [2] says "An ItemFlow itemProperty is typed by a Block or by a ValueType.", I assume values flow as well as blocks. For example, the ports by be typed by Number and the item flow in a particular usage could be integer

No Data Available

Flow property constraint [3]. In Ports and Flows, FlowProperty 9.3.2.6 constraint [3] says a block can't read its own properties if they have out direction. Why can't it? Every object can read its own properties, regardless of which object provides the values.

No Data Available

Flow property values wording. In Ports and Flows, FlowProperty 9.3.2.6 refers to flow properties having values ("A Flow Property’s values are either received from or transmitted to an external Block."), but if a flow property is on an interface, it can't have values. A property of a block supporting the interface property will have the value. The wording could be "flow property" instead of "FlowProperty" which clarification of the relation of properties on a FlowProperty to those on a Block.

No Data Available

Flow ports semantic variation. In Ports and Flows, FlowPort 9.3.2.5, Description, the sixth paragraph introduced a semantic variation point, which means the models are not interchangeable. The sender will use one technique to bind flow properties and the receiver might another. At least enumerate and normalizes the techniques and put the enumeration in the model so the receiver knows which is being used

No Data Available

ItemFlow constraints [1] and [3]. In Ports and Flows, Item Flow, constraints [1] and [3] are worded without using the metamodel association ends names, so are difficult to interpret. For example, what do "assign" and "context" mean for the metamodel?

No Data Available

ItemFlow constraint [5]. In Ports and Flows, ItemFlow 9.3.2.8, the attribute itemProperty and constraint [5] constrain multiplicities, but should constrain the number of values of instances of the ItemFlow metaclass (also see the text under Attributes just above). Multiplicities are in the metamodel and don't change in the instances.

No Data Available

Add clarification of how to represent non-depletable stores in an ibd as a part. Consider including as a usage example.

No Data Available

"In the table row for Actor, add some space between the two alternative
representation to make it obvious these are alternatives.
"

No Data Available

"Remove UML 2.0 Superstructure
Change UML Infrastructure to UML 2.1 Infrastructure Convenience Document
(ptc/06-04-03)
"

No Data Available

"Change ""ISO AP233"" to ISO 10303-233 STEP AP233. This should be changed
in the whole document. Abbrevations to ""AP233"" are fine within a
section provided it has been fully introduced at the beginning of
that section. In section headings and captions, it should never be
abbreviated
"

No Data Available

How do you represent static properties of a block on a parametric diagram without imposting a usage, such as specific heat in the distiller example. The intent is to represent a value property for the specific heat of water that applies to all usages of water. One approach is to specify an anonymous type from a model library of ItemTypes with a value property as :ItemTypes::Water.specificHeat, where Water is specified as a block.

No Data Available

Consider removing constraint. Delete Constraint [1]
Exclusion of all state or behavior within a constraint block may be too extreme for some potential uses.

No Data Available

Update diagram element tables to include requirements, allocations, packages, comments,ratinale, etc or include a statement where they are defined.
Diagram element tables should include cross cutting constructs such as allocations, requirements, and packages

No Data Available

Apply paste special - metafile to all visio figures
Figures are all metafiles, Tables are embedded Visio still. General issue for upgrade to Visio 2003 and update the SysML template

No Data Available

Separate definition from description

No Data Available

"Consider changing ""... of a whole system ..."" to ""... of a whole system
or subsystem ...""
"

No Data Available

Change UML 2.0 reference to UML 2.1 throughout the document

No Data Available

Please add a footnode explaining what <<moe>> is (just for readability)

No Data Available

Constraint [1] is not very clear. Please clarify

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

Part-specific type metamodel. Was reviewing the thread below and there seemed to be agreement that part-specific types needed a metamodel representation. Otherwise, there would be nothing in the repository linking the property to the part-specific type, and it will be lost in XMI interchange. ----Original Message---- From: Eran Gery [mailto:erang@ilogix.co.il Sent: Friday, March 24, 2006 7:06 AM To: 'Moore, Alan'; 'Branislav Selic'; Burkhart Roger M Cc: anders.ek@telelogic.com; 'Laurent L Balmelli'; 'Carolyn B Boettcher'; conrad.bock@nist.gov; 'Cory Bialowas'; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; 'Eldad Palachi'; 'Fredrick A Steiner'; 'Baker, James D (US SSA)'; jlow@ilogix.com; 'Chonoles, Michael J'; 'Friedenthal, Sanford'; 'Tim Weilkiens' Subject: RE: Anonymous types I agree. Not sure if a meta-association is needed or a Boolean tag would suffice. ----Original Message---- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com Sent: Monday, March 27, 2006 1:54 PM To: Eran Gery; Moore, Alan; Branislav Selic Cc: anders.ek@telelogic.com; Laurent L Balmelli; Carolyn B Boettcher; conrad.bock@nist.gov; Cory Bialowas; Diego.Tamburini@gatech.edu; Dwayne.Hardy@2asc.com; Eldad Palachi; (Fredrick A Steiner; Baker, James D US SSA); jlow@ilogix.com; Chonoles, Michael J; Friedenthal, Sanford; Tim Weilkiens Subject: RE: Anonymous types In the V1.0 spec, we've kept the notations for the two forms of property-specific "types" for an internal property on an internal block diagram: a type enclosed in square brackets to specialize an existing type, or a name without a colon to indicate a property that has its entire type constructed for the local usage (which Eran correctly pointed out had been included in the SST and post-merge specs.) While we've included these user-visible notations, I agree with Alan that we need more explicit ways in the metamodel to identify the types that are automatically created as a result of these mechanisms, or the properties that hold them. UML refers to these as "anonymous classes" but I agree with Bran that they're not likely to remain implicit as design proceeds, and I wonder if we should consider assigning a default name to them along with any metamodel identification. I had proposed previously that they could be given the same name as the property for which they supply the type, and a stereotype such as <propertySpecific> applied to them (which I think is the same as a boolean tag such as Eran said might be all that's needed). A related issue I think we'll need to raise in the FTF, since it's not in the current spec, is how these property-specific types can be shown in a properties compartment on a block definition diagram. Following the UML spec, which allows for the "name without a colon" case as a presentation option only on a composite structure diagram, we hadn't included the notation in our diagram extensions for a block definition diagram. That's probably an oversight; we should probably allow the same square-bracket qualification for the type of a property on a bdd just like we allow on an ibd. For the case of the entire type constructed from scratch, however, the simple name without a colon case seems to me entirely inappropriate to carry over to a bdd, so perhaps we could still allow the [ ] without a type name inside like we originally had on the ibd as well. Of course, the motivation that Eran (and Michael) have expressed to start building your design on an internal structure diagram prior to a block definition diagram means you may not care at that stage about a bdd at all, but we should adopt some way to show the same properties consistently across the diagrams regardless of likely interest or usage. For now, I just wanted to highlight the status of this issue as reflected in the draft V1.0 spec, so we can switch over to the FTF for any further resolution that may be needed. --Roger

No Data Available

Include examples of additional feature notations in the diagram elements table for Blocks. Examples of UML notations that have not been excluded by SysML include a "/" for derived features, underline for static features, and optional visibility characters "+" "-" "#" "~".

No Data Available

Am studying the adopted sysml spec ptc/06-05-04, noted the following possible bug.

IMO, Annex A needs to plug a gap wrt how to recognize diagrams that come with a default namespace. I can see no way to know whether a diagram is designating a default namespace. The <modelElementName> in the header seems to have been intended to do this, but it is not up to the job.

One way to plug this gap would be to make modelElementName optional in heading, and specify that, if present, the model element instance it names must be an instance of a namespace metaclass, which is the default namespace.

Another way is to add a mandatory <namespace> field in the header, and specify some concretely recognizable value, such as the string "None" or an equivalent in the local language, as a valid value.

details:

Annex A, A.1 Overview, page 167 of the pdf pagination, states: The frame is a rectangle...The frame can designate a model element that is the default namespace for the model elements enclosed in the frame. This means the rectangle is a concrete graphic notation which may, optionally, represent a namespace, with the implication that in that case, whatever is shown inside the contents area of the frame, is (unless explicitly represented otherwise) contained within the represented namespace.

But how does a user of the diagram know whether this option is being taken? In any particular case, the frame may not designate a model element that is the default namespace, and yet there must be some value present for modelElementName.

This name could even designate an element of namespace type. How is that case to be recognized?The modelElementType field is optional. Is the intent that, if a value is present for modelElementType, and is a specialization of namespace, that this is the default namespace?

Was the intent that in that case, the Header would not include a modelElementName? If so, we need a concrete way to show that the modelElementName in the Header is null.

But what if the modelElementName field in the Header is not null, but the model element it names is not a namespace? A case where one might want to do this is when the focus or point of the diagram revolves around some particular element owned by a namespace. I am not advocating that, but trying to debug the spec.

I suspect we need one of the following:

1. either a constraint that requires the value in the <modelElementName> field to refer to a namespace element,
2. or a way to show that the <modelElementName> is intended to name a namespace which applies by default to any element shown within the contents area.

It also states: The top level "Model" name is the highest level namespace for the model elements.

Intuitively the point of this seems to be that what we call "the model" is generally the root of the namespace hierarchy for model elements. . However, the specification of the frame, contents area, heading, and diagram description, nowhere uses the terminology "Model" name . So it seems that this sentence is irrelevant in the present context?

The text describing the frame says The frame can designate a model element that is the default namespace for the model elements enclosed in the frame. This implies that a model element named in the header may not be the default namespace for the model elements, indeed it may not be a namespace at all. But in that case, what does it signify? It is not mandatory that the frame designate a model element.

I conclude that the spec needs to allow that the modelElementName is optional, and that, if present, the model element instance it names shall be an instance of a namespace metaclass, and if absent, some concretely recognizable value, such as the string "None" shall be put in that field.

No Data Available

The boolean isEncapsulated property of the block element must be shown as

(instead of

) if true and not shown if false. That's conform to the UML notation of boolean properties

No Data Available

The SysML spec says that a BDD can be used for functional decomposition because an Activity is a Class in UML. (see the end of 11.1; 11.3.1.1)

However, the spec says elsewhere that a BDD can only be for Blocks, Packages, or constraint blocks.

For example, Annex A.1 (p 167)

The following are the designated model elements

associated with the different diagram kinds.

• activity diagram - activity

• block definition diagram - block, package, or constraint block

• internal block diagram - block or constraint block

From 8.3.2, it is clear that while a block is a class, a class is not a block.

From this, it is unclear how a block diagram can really (formally) be for an activity.

Possible solutions

1) Let a bdd for any classifier

This has the extra advantage of allowing bdd’s for actors, ports, etc.

2) Change the annex to allow a bdd to be for activities (and perhaps actors, ports…)

3) Change the definition of a SysML activity to be both a UML4SysML Activity and a SysML Block (probably too complicated)

Also the example diagrams (such as figure 11.1 and the figure in Table 11.3 row 1) should have a complete diagram header. This should at least include the model element type for the diagram (to be consistent with the solution above).

They should also have a «diagramUsage» if one is required (as implied by Table 11.3)

No Data Available

In SysML we decided that Blocks do not have instances if I remember correctly. Therefore, could you confirm or infirm the following statement: "The composition relationship connects a block to other blocks having a role as part in the context of this block. In contrast, the association relationship connects a block to other blocks having a role as part reference in the context of this block (dashed notation)."

There is therefore no runtime semantic anymore (i.e. instance deletion)

correct or not?

No Data Available

The description and constraints of the Rate stereotype refer to distributionDefinition which does not exist. can this use the distributionProperty stereotype instead?

No Data Available

Issue 10031 Constraint [1] 1] A Connector or an Association must exist´between the source and the target of the InformationFlow TimWeilkiens: I think there is another option that should be allowed: An association between the supertypes of the source and the target of the InformationFlow. ConradBock: You're right, this should include inherited associations. It would be good to file an issue that identifies the places where inherited associations are ruled out unnecessarily.

No Data Available

Fig. 7.3; requirement performance: requirement keyword isn't enclosed in guillemets, but in lesser/greater than angles.

No Data Available

In figure C2, subactivity Add requires two inputs, u(t) and -2x(t). While the logic makes sense, I don’t believe the activity diagram should ever start running, because the 2nd pin is never supplied with data until the Add runs.

It’s difficult to see how this could be fixed, for example, making the 2nd pin optional will allow the Adder to work when the Multiplier hasn’t finished, which is not correct.

So we only want this to be optional the first time.

In any case, a fix is needed.

No Data Available

The reason for the restriction on no more than 1 item property per item flow is unclear to me.

Please consider that transferring a block, e.g., water, could be transferring heat, pressure, liquid (volume)

No Data Available

The SysML specification inadvertently omitted the join spec notation from the Diagram Elements Table in the Activities Chapter). The join spec is useful for specifying more complex control flow logic than is available with Join Nodes and Fork Nodes alone.

The recommendation is to include join spec notation in the concrete syntax column in JoinNode and ForkNode row of Table 11.1 of the Activities Chapter. The notation is described in Figure 12.102 in the UML Superstructure Spec under the Join Node section 12.3.34. The notation is a constraint notation in curly shown near a Join Node or the Fork Node. A specific example is provided in Figure 12.104.

No Data Available

Figure 11.14 uses the value stereotype, which doesn't exist. Should be the valueType stereotype

No Data Available

The SI unit defined in Figure 8.9 should be a Newton (the unit of force) as opposed to New ton (a unit of mass ?)

No Data Available

A viewpoint has a list of stakeholders. It would be more convenient if this could include a list of actors (or associations with actors). Many of the stakeholders will be actors and it shouldn’t be necessary to define them twice. And it is more in keeping with SE thinking to allow for definitions (including generalizations, aggregation) of all the stakeholders, to allow for modeling the stakeholders directly, because of the correct focus on stakeholders’ needs.

Recommend fix, allow for Viewpoints to be modeled on Use Case diagrams or block diagrams and connected directly to actors

No Data Available

On the copyright page (PDF 4), on the line for the National Institute of Standards and Technology 1) Change "Insitute" to "Institute" 2) Remove the word "Copyright, the copyright symbol, and the date range.

No Data Available

"Description paragraph for AllocateActivityPartition states that the relationship depicted is an allocation of definition (from Activity), but Constraints paragraph states that the relationship depicted is an allocation of usage (from Action).
"

No Data Available

"If we use the pin notations for object flows does the user have to allocate both pins, bear in mind that two or more object flows may start or end at a given pin so in order to designate the precise object flow you need both ends.

• From the item flow end does the user get a choice of pins (the actual elements in the model) or object node symbols (which may or may not exist on the activity diagram depending on whether pins are shown).

• When the type name is shown in the allocatedFrom compartment, e.g. <<objectNode>>dirtywater, what should the typename be - either the tool derives it from the type of the allocated element (which is tricky because there are two elements with different type), or we explicitly list what the type name should be under which circumstances.
  "

No Data Available

Now that View extends Package instead of Model, the Model Elements sub-profile depends only on UML4SYML Level 1, not 3.

No Data Available

regarding the <<requirementRelated>> stereotype in the Requirements package of the SysML profile. I have two questions:

Why is the “verifies” tag on requirementRelated instead of <<testcase>>?
Why do you allow <<requirementRelated>> to be applied to <<testcase>> items?

It makes more sense to me to put the “verifies” tag on <<testcase>> and have a constraint on <<requirementRelated>> that states it cannot be applied to items stereotyped as <<testcase>>. As I understand it <<requirementRelated>> is basically a placeholder for the derived tags that can’t go anywhere else (e.g. “satisfies”, etc). Since <<testcase>> is already a stereotype there’s no reason why it can’t hold the “verifies” tag.

No Data Available

In table 7.2, page 26, PrivatePackageImport should list UML4SysML::PackageImport as the Abstract Syntax Reference

No Data Available

In table 7.2, page 26, PublicPackageImport should list UML4SysML::PackageImport as the Abstract Syntax Reference

No Data Available

"Suggest to add a sentence explaining that the diagram frame sets an
unambiguous context for recognizing an unlabeled box as <<block>>
"

No Data Available

"Consider other types than ""String"" for the ViewPoint attributes. This would
allow to refer to elements representing these concepts (like stakeholder).
"

No Data Available

Section A.1 mentions a "freeform" version of package diagrams. If freeform diagrams are allowed (as they are), there does not seem to be any special benefit to restricting such diagrams to only the contents of a single package. Freeform diagrams are typically used to show relationships between elements that are normally shown in different diagrams. Experience with UML has shown that this is an extremely useful capability and is in high demand. I suggest moving this diagram from out of the package diagram restriction and make it a general diagram type that is not restricted to elements belonging to the same namespace.

No Data Available

In Figure 9-1, "Port Stereotypes" ownedFlowProperty redefines ownedAttribute in FlowSpecification.
You cannot redefine something that is not inherited - and extension is not inheritance.

Fortunately this seems to be a one-off: I could not find any other similar subsets or redefines in the spec.

No Data Available

"Remark: Be aware that the way it is defined, an optional attribute
has a physical slot in the instance, even though it has no value.
"

No Data Available

Clarify the line style for ControlFlow (last table row)

No Data Available

"Two comment examples show still the old (wrong) notation with the
circle at the attach point.
"

No Data Available

Please add example(s) for NestedConnectorEnd

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?

This is issue is closed without change because atomic flow ports are deprecated
in the resolution of issue 13178.
Disposition: Closed, no change

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

Discussion:
Recommend no change. Fig B.18 & B.19 are consistent. The CAN bus is a
design refinement introduced after figure B.19,and does not need to be included
in earlier figures.
Disposition: Closed, No Change

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

No Data Available

Definition of part properties. In Blocks, BlockProperty, 8.3.2.2, Description, second paragraph, it says: "A property of a block may refer to another element of a system that is required to exist for the system to exist. Such properties are called part properties." This means the minimum multiplicity of the property is always greater than zero. I assume part properties can be optional, ie, not required to have a value. Was this sentence meant to say that part properties are strong compositional? That would be consistent with UML's definition of the term "part property". If so, the spec should read: "A property of a block may refer to another element of a system, and when instances of the block are destroyed, instances of the other element will be destroyed. Such properties are called part properties." Same comment on another sentence in the same paragraph: "While referenced by the part property, however, these instances cannot cease to exist unless the owning system also ceases to exist." This isn't UML destruction semantics (see above) or consistent with a multiplicity of 0..1, as indicated in the paragraph. Is this intended?

No Data Available

Block constraint [2]. In Blocks, Block, 8.3.2.1, constraint [2], presumably should be restricted to connectors owned by blocks.

No Data Available

Definition of binding connector. In Blocks 8.3.2.1, the definition of binding connector includes this sentence: "If the two ends of a binding connector have the same type, the connector specifies that the properties at the end of the connector must have the same values, recursively through any nested properties within the connected properties." Clarify that the part after "same value" only applies to data/valuetypes. For objects/blocks, if it is the same instance, then it's the same all the way down.

No Data Available

Stereotype for binding connector. The Blocks chapter should define a stereotype for binding connectors to distinguish them from those with UML semantics (SysML and UML semantics for associationless connectors is not the same). A stereotype can also specify the constraint that the types of the connected properties must be the same for binding connectors, which currently applies too generally to all associationless connectors with the same type at both ends (binding connectors are defined as any connector with no association). A stereotype would also enable them to be distinguished visually. Currently binding connectors appear in the concrete syntax table with no way to distinguish them from other connectors, and from connectors with UML semantics in particular.

No Data Available

propertyPath definition. In Blocks, NestedConnectorEnd 8.3.2.5, Attributes, propertyPath, at the end of the entry description, it says "not including the property which is directly connected.". I gather the property directly connected is identified by the UML ConnectorEnd.role metaproperty? If so, Constraint [1] isn't true, and the multiplicity of propertyPath should be 1.., rather than 2... The entry should clarify if the intention to only use NestedConnector below ports (ie, use the UML ConnectorEnd.partWithPort metaproperty). I think the simplest solution is to just remove the quoted phrase above. The path will be from the Block owning the connector all the way down the connected property. These would need to be consistent with values of UML's ConnectorEnd.role and ConnectorEnd.partWithPort properties, if any (ie, the first two elements in the path would need to be the same as these, if they exist)

No Data Available

DistributedProperty stereotype of stereotype. In Blocks, DistributedProperty, 8.3.2.3, first sentence, DistributedProperty is a subtype of BlockProperty, rather than a stereotype of BlockProperty

No Data Available

Aggregation. In Blocks, BlockProperty, 8.3.2.2, Description, furth paragraph, perhaps SysML should give more specific semantics than UML for aggregation. In particular, require acyclic graphs.

No Data Available

FlowPort constraints [2] and [3]. In Ports and Flows, FlowPort 9.3.2.5, constraints [2] and [3], constrains multiplicities of Direction and iConjugated, but it should be constraining the number of values of these properties in instances of the FlowPort metaclass. Multiplicities are in the metamodel and don't change in the instances.

No Data Available