Issue 9763: Page 16
Issue 9771: Section 16.4.2
Issue 9778: constraints section 9.3.2.4
Issue 9779: Section 16.3.1.1
Issue 10020: Section: Blocks - BOM properties
Issue 10033: Section: Ports and Flows - Behavioral flow ports
Issue 10042: Section: Requirements - Figure 16.1
Issue 10047: SysML: Protocol State Machines needed
Issue 10048: SysML: UML Qualifieed Associations
Issue 10057: SysML: Use Cases
Issue 10058: SysML: Generalizing Activites
Issue 10059: SysML: Interfaces on Flow Ports
Issue 10060: SysML: Missing arrow on figure 16.8
Issue 10061: SysML: << and >> vs < and >
Issue 10073: SysML:Architecture
Issue 10097: Table 14.1 Use Case Diagram
Issue 10098: constraints on viewpoint, 7.3.2.5
Issue 10143: Semantic of default value in the scope of a DistributedProperty
Issue 10342: Section: 9.3.2.8 ItemFlow
Issue 10343: Section: 16.3.2.4 RequirementRelated (from Requirements)
Issue 10371: How to use property specific types for atomic flow ports?
Issue 10374: Section: Appendix B.4.5
Issue 10380: Section: Annex G
Issue 10410: Section: 9.3.2.5 FlowPort
Issue 10427: Section: 7.3.2.5 Viewpoint
Issue 10446: SysML: nout-->inout
Issue 10471: Section: 9, 16, C
Issue 10472: Section: 6.1 Levels of Formalism
Issue 10473: Chapter 8, Blocks, instance specifications for default values
Issue 10500: Section: Figure 14.2
Issue 10501: Section: 11 Actibities
Issue 10502: Section: 11 Activities
Issue 10509: Section: 17.4.2
Issue 10510: Section: Annex A
Issue 10511: Section: figure 17.6
Issue 10517: Figure 17.4.2
Issue 10524: Constraint parameter stereotype
Issue 10538: 7.1 Overview
Issue 10539: 15.2.1Representing Allocation on Diagrams
Issue 10540: Section 16.3.2.3
Issue 10587: SysML doesn't explicitly support the modeling of alternative models
Issue 10602: Section: Appendix B
Issue 10641: Section: 11.3.2.2
Issue 10642: Timing diagrams
Issue 11011: Block namespace compartment: Are external relationships allowed
Issue 11066: Namespace compartment for blocks
Issue 11091: Section: Chapter 7-17
Issue 11117: Section: 12. Interactions
Issue 11118: Section: 11.3.1.1
Issue 11267: Section: 11.3.2.2 ControlOperator
Issue 11269: Section: 16 Requirements
Issue 11270: Section: 8.3.2.8 ValueType
Issue 11271: Section: 16 Requirements
Issue 11274: Section: Annex A: Diagrams
Issue 11275: Section: 8.3.2 Unit/Dimension Notation
Issue 11276: Issue: Nested connector ends
Issue 11308: Question on PropertySpecificType
Issue 11333: BindingConnector
Issue 11490: Requirements are abstract
Issue 11491: <<satisfy>> is displayed as dependency (in examples)
Issue 11492: Uppercase/lowercase problems
Issue 11493: Lack of notation for units and dimensions on values.
Issue 11494: Association branching is not defined in UML
Issue 11495: Constraint parameter notation conflicts with UML private ports notation
Issue 11496: It is not allowed in UML to display stereotypes of related elements
Issue 11497: Mixed action and activity concepts
Issue 11498: <<continuous>>
Issue 11499: Parts are added directly into package
Issue 11500: View as Package extension is very bad idea
Issue 11501: Wrong ends of Allocate relationship used in Allocated definition
Issue 11502: PropertySpecificType concept is highly ineffective and suboptimal
Issue 11523: optional parameter section
Issue 11591: 8.3.1.3 UML Diagram Elements not Included in SysML Block Definition Diagram
Issue 11599: SysML -- Fix for Fig 9.4 p70.
Issue 11600: SysML dimensions
Issue 11612: SysML specification for containment relationship
Issue 11622: Section: 8/3
Issue 11623: Address potential points of convergence between MARTE and SysML
Issue 11626: Section: Appendix E
Issue 11627: SysML: Interaction diagram and Data-based comm of SysML
Issue 11628: SysML:Ports can't be blocks
Issue 11629: Section: 5.1
Issue 11648: SysML Interactions
Issue 11650: Section: 9.4
Issue 11651: Section: 9.3.2.
Issue 11652: Section: 16.3.2.7
Issue 11653: Section: 5.3
Issue 11654: Section: 11.4
Issue 11655: Section: 8.3.2.2
Issue 11656: Section: 16.2.1
Issue 11691: Rate stereotype attribute
Issue 11814: Section 7.1
Issue 11819: Section: 8.3.1.2 Internal Block Diagram Extensions
Issue 11823: Stakeholder and Concern
Issue 11895: Chapter Blocks/Section 8.3.2.6
Issue 11961: Section: 9.3.2
Issue 12123: Inferred Allocation on Allocate Activity Partitions
Issue 12124: Allocation Callout to Item Flow is Ambiguous
Issue 12125: Item Flows on Activity Diagrams
Issue 12126: 8 Blocks, 8.3.1.2 Internal Block Diagram, 8.3.2.2 Block
Issue 12127: 8.3.1.2 Internal Block Diagram
Issue 12128: 08 Blocks, 8.3.2.9 Unit, 8.3.2.10 ValueType
Issue 12129: 10.3.2.2 ConstraintProperty
Issue 12130: 10.3.2.2 ConstraintProperty
Issue 12131: 10.3.1.2 Parametric Diagram
Issue 12132: 10 Constraint Blocks, 10.3.2.1 ConstraintBlock
Issue 12133: 11 Activities, 11.2.1 Activity Diagram
Issue 12134: 11.Activities/11.3.2.8 Rate/Figure 11.8
Issue 12135: 11 Activities, Figure 11.10
Issue 12136: 11.Activities, Figure11.10
Issue 12137: 11 Activities, Figure 11.10
Issue 12138: 11. Activities
Issue 12139: 15.3.2.3 AllocateActivityPartition
Issue 12140: Annex B/B.4.1.2 Package Diagram
Issue 12141: Annex B, B.4.4.3 Requirement Diagram
Issue 12142: Annex B / B.4.5.4 Block Definition Diagram
Issue 12143: Annex B / B.4.8.3 Activity Diagram
Issue 12144: Annex B / B.4.8.3 Activity Diagram
Issue 12145: Annex B / Figure B.10
Issue 12146: Annex B / Figure B.9
Issue 12147: Annex B / Figure B27
Issue 12148: Annex B / Figure B.36
Issue 12149: Annex B / Figure B36
Issue 12150: Annex B / Figure B.36
Issue 12151: Annex B / Figure B36
Issue 12152: Annex B / Figure B.35
Issue 12153: Annex / Figure B.37
Issue 12154: Annex B / Figure B.38
Issue 12155: Annex B, Figure B.18, Figure B.19
Issue 12156: Section: 9.3.2
Issue 12157: Section: 8.3.2.1
Issue 12159: 10.Constraint, Figure 10.3
Issue 12160: Annex B, Figure B.29
Issue 12163: Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp
Issue 12219: Section: 08 Blocks: suggest need Quantity stereotype and definition
Issue 12222: 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port
Issue 12239: Section: Chapter 7: Viewpoint
Issue 12253: Section: annex A.1, Activities
Issue 12254: Section: Chapter 2: UML version
Issue 12255: Section: Generalization of stereotyped elements
Issue 12256: Icons for FlowPort
Issue 12257: remove homemade stereotypes
Issue 12258: moe should be removed from section 7.4 or added to the standard
Issue 12268: Section: 8.3.2.1
Issue 12269: Section: More constraints for flow ports
Issue 12270: SysML unnecessarily restricts aggregation of datatypes
Issue 12277: SysML needs instance specs
Issue 12353: 08.Blocks, 8.2.2 Internal Block Diagram:
Issue 12361: 08.Blocks: compartment for property-specific defaultValue should be renamed
Issue 12363: 08. Blocks: The 'values' compartment for a part Property in an IBD
Issue 12364: DistributedProperty
Issue 12365: p.46 under 8.3.2.4 DistributedProperty
Issue 12366: Figure B.34 and Figure B.35
Issue 12377: NestedConnectorEnd multiplicity typo in Fig 8.5
Issue 12435: Section: 08 Blocks, Annex B, Annex C
Issue 12510: 4.2: StandardProfileL2 uses elements not supported by SysML
Issue 12546: type should be cmof:Class not uml:Class
Issue 12547: The href should reference the URI for the UML elements
Issue 12548: Missing tags in XMI
Issue 12560: Section: 11.3.1.1 Activity in bdd
Issue 12576: 11.4 Activity Usage Sample: ControlOperator has regular pins
Issue 12751: use of derived in Requirements
Issue 12853: More than one constraint block of the same type in a parametric diagram
Issue 12914: Section: 9.3.2.4 Constraint about "in" flow properties
Issue 13152: SysML: Align SysML Activities with Foundational UML
Issue 13153: SysML: Activity Properties should be accessible in Activity diagrams for decision making
Issue 13154: SysM:L: Operations on Activities need to be callable (e.g., start, restart, cancel)
Issue 13155: Section: 11.3.1.1, 11.3.1.4, 11.4
Issue 13156: Section: 4.2, 11.2.1
Issue 13157: Section: 11.3.2 Inability to name interruptible activity regions
Issue 13177: Requirements interchange issue
Issue 13178: Port Decomposition of a Flow Specification Discussion
Issue 13179: SysML/Modelica Integration Discussion
Issue 13190: Ambigous line crossings
Issue 13196: SysML synchronization with UML/XMI version updates Discussion
Issue 13197: Representation of nested object nodes in activity diagrams
Issue 13219: Section: 8/8.3.2 Inability to efficiently capture datasets
Issue 13259: Requirement constants should be integrated into Model-centric vision of SysmL
Issue 13260: Parametrics and Depletable Stores
Issue 13261: Binding Relationships require unit conversions
Issue 13262: Use cases in SysML are more similar to Requiremetns than Behavioral diagrams
Issue 13263: Support BDD's for State Machines
Issue 13328: Lack of Structured Activity Node and other Activity features Discussion
Issue 13342: AllocateActivityPartition and UML 2 semantics
Issue 13345: Merge UML DataType into SysML ValueType
Issue 13348: Inability to represent dependent, independent parameters on constraint properties
Issue 13465: "trigger[guard]\activity" should be "trigger[guard]/activity"
Issue 13503: Fig. 11.10: Pin of ControlOperator
Issue 13666: Participant Property constraint #6 not correct.
Issue 13667: Connector Property value text.
Issue 13840: Allocations should not generate dependencies
Issue 13854: Chapter 7.3.1.1 Update comment stereotype diagram extension
Issue 13924: Using composite association between activities
Issue 13928: Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct
Issue 13939: Parsing Text in Requirements
Issue 13942: Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect
Issue 13945: Notation for multiple item flows
Issue 13976: Example figures in chapters are redundant with Annex B sample problem
Issue 14032: The information in Annex D regarding AP233 needs to be updated
Issue 14033: Representing multiple item flows on the same connector
Issue 14041: SysML Issue based on UML Issue 10044: Profile Structure Diagrams are missing from Annex A
Issue 14042: SysML issue based on UML Issue 11160: Namespace URI for Standard Profile(s)
Issue 14043: SysML Issues based on UML 13080 New proposal for conjugate types for port
Issue 14055: Proposal to have a stereotype for reference nested property
Issue 14056: UML4SysML: Architecture & Compliance with UML subset
Issue 14058: Flow port compatibility with behavior
Issue 14079: SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2)
Issue 14085: Overly restrictive statement regarding ports in blocks chapter
Issue 14086: Ports use property type incorrectly
Issue 14238: Wrong type in fig. 15.11
Issue 14239: 15.3.2.2 Allocated(from Allocations)
Issue 14424: Non-atomic flow ports use property type incorrectly
Issue 14447: Ambiguous Block Hierarchy
Issue 14575: callout notation issues
Issue 14827: Streamlined notation for representing system variance
Issue 14998: Binding to multiplicity in parametrics
Issue 15003: Do parametric bindings observe derived and read-only properties
Issue 15018: SysML 7.3.2.5 Viewpoint
Issue 15074: Including Behavior Port Notation
Issue 15075: Including Property Notation for Redefinition and Subsetting
Issue 15076: Extending Ports to Support Non-flow Properties
Issue 15077: Constraining a decomposition hierarchy
Issue 15078: properties allocatedFrom and allocatedTo should be capitalized
Issue 15079: Ability for a binding connector to be typed
Issue 15112: Inheriting Allocations
Issue 15117: Typing Flow Properties and Item Properties as Enumerations
Issue 15131: SysML 1.2 Section 16.4.4
Issue 15132: Allocate of Actions or of Activities
Issue 15176: Flow properties and activity paramters
Issue 15293: SysML 1.2 Issue Viewpoint referencing other viewpoints properties
Issue 15294: SysML 1.2 Issues: Structure compartment wrong in spec
Issue 15295: SysML 1.2 Issues: Default <block> stereotype on unlabeled box is not always optimal
Issue 15296: SysML 1.2 Issues: DistributedProperties on Activates
Issue 15297: SysML 1.2 Issues: Activity's sub-activities should be able to have mandatory multiplicity
Issue 15298: Continuous flows in non-streaming situations with >1 multiplicities
Issue 15299: SysML 1.2 Issues: Optional with streaming
Issue 15300: SysML 1.2 Issues: Definition of Overwrite
Issue 15301: SysML 1.2 Issues: Missing constraint on Rationals
Issue 15302: SysML 1.2, ch 12
Issue 15355: Structure Compartment shows blocks instead of parts
Issue 15600: SysML 1.2 - Blocks
Issue 15683: Figure B.35 object nodes
Issue 15728: SysML Issue based on UML 15369
Issue 15729: SysML Issue based on UML 14062 -- Stereotypes/keywords and upper/lowercase
Issue 15730: SysML Issue representation of properties as associations
Issue 15731: SysML Issue based on UML 15370 -- Package has optional URI
Issue 15875: SysML Issue on Multiplicity of Use Case Communication Associations
Issue 15876: Define the SysML profile as referencing UML and replace the UML4SysML subset with OCL constraints
Issue 15882: SysML primitive value types
Issue 15884: Another issue with allocate
Issue 15905: Appendix F out of date
Issue 15918: NestedConnectorEnd constraints refer to metaclass
Issue 15982: Blocks cannot own items flows
Issue 15983: IBD notation doesn't distinguish item properties from connector labels
Issue 15984: NestedConnectorEnd constraints
Issue 15985: Description of Item Flows
Issue 16008: partWithPort change from UML needs to be clearly stated
Issue 16016: SysML Issue on Refine limitations
Issue 16041: NestedConnectorEnd propertyPath should be non-unique
Issue 16042: Item flows can have multiple types but item properties cannot
Issue 16045: Claify partWithPort vs. NestedConnectorEnd
Issue 16046: Clarification when Allocated Stereotype is applied
Issue 16057: Compartment labelling rules
Issue 16058: Definition of part
Issue 16061: Test Context appears in XMI but not in Profile Spec
Issue 16093: Incorrect statement about UML n-aries
Issue 16112: Where have stereotypes been defined?
Issue 16113: parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete
Issue 16114: typo in diagram C. 15
Issue 16170: Multiassociation
Issue 16211: Deprecated elements package
Issue 16212: Missing cross references in Deprecated Elements Annex
Issue 16213: Water association decomposition example should be in ports
Issue 16214: Clarify that item flow decomposition examples are not methodology
Issue 16215: Flow property compatibility rules should not be dependent on item flow
Issue 16216: Remove colons from item flow classifiers in decomposition examples
Issue 16217: Connectors should not link ports in block definition diagram elements
Issue 16218: Clarifications to flow port resolution
Issue 16219: Ownership of item flow properties
Issue 16220: Sample problem using deprecated conjugated port notation
Issue 16221: Provided / required operations & receptions
Issue 16225: onNestedPort should enable sending directly to target
Issue 16226: Internal and external connectors undefined
Issue 16227: Owning block undefined
Issue 16230: Block shown as metaclass
Issue 16231: Flow property semantics only defined for external connectors
Issue 16234: Ports that have behavior ports should be behavioral
Issue 16254: InvocationOnNestedPortAction and TriggerOnNestedPort notation not extended
Issue 16255: TriggerOnNestedPort refers to onPort instead of port
Issue 16263: Association owning ends
Issue 16264: Invocations of required behavior features without going through ports
Issue 16265: Non-behavioral ports on behavioral ports
Issue 16280: Flow properties on blocks typing internal parts
Issue 16284: Proxy ports should not have connectors
Issue 16285: Internal fanout from proxy ports should be clarified
Issue 16286: TestCase should use PackageMerge
Issue 16293: Full ports should not be conjugated
Issue 16304: Can Enumerations be used on parametric diagrams for typing constraint parameters
Issue 16332: Binding connectors may not have constraint parameters on any end
Issue 16333: Clarify open and closed meaning of port types vs other property types
Issue 16334: Item flow property values
Issue 16335: Association decomposition in diagram element tables
Issue 16336: Proxy port owning block definition should refer to internal structure
Issue 16337: Contextualized item flows
Issue 16344: Events for property value changes
Issue 16345: Broadcasting along connectors
Issue 16351: Owning block terminology
Issue 16352: Provided and required feature abbreviations
Issue 16373: Content of Requirement::/tracedTo
Issue 16391: InvocationOnNestedPortAction and TriggerOnNestedPort
Issue 16396: Improvements to QUDV for SysML v1.3
Issue 16406: Rate does not support the examples
Issue 16407: Wrong multiplicity for Requirement in stereotype description
Issue 16594: Constraint Blocks cannot have parameters
Issue 16608: sentence introduced in §9.1 by the resolution to issue #16280 is confusing
Issue 16636: Problems with property-specific types
Issue 16652: InstanceSpecifications for exactly one instance
Issue 16653: InstanceSpecification equality
Issue 16657: Lightweight representations of faults, failures, hazards and off-nominal conditions and behavior
Issue 16726: Issue on Block constraint#4
Issue 16876: SysML's PrimitiveValueTypes library is missing "value" properties everywhere
Issue 16891: SysML diagrams show only SysML-stereotyped elements
Issue 16945: Question about the Activity decomposition in Bloc Definition Diagrams
Issue 16947: Error in pending 1.3 diagram 15.6 and elsewhere
Issue 17016: Property Based Requirements
Issue 17120: Addition of derived property notation
Issue 17161: Issues with XMI for SysML 1.3
Issue 17210: SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML
Issue 17246: Part 1 of the specification
Issue 17247: Section 9.3.1.6
Issue 17248: Section 9.3.1.7
Issue 17249: Table 9.1
Issue 17250: 9.1 InterfaceBlock - unnamed compartment
Issue 17251: Port labels inside Port symbol
Issue 17252: ports with flow properties are displayed the same as flow ports in SysML 1.1?
Issue 17253: 9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???
Issue 17254: 9.3.2.8 FullPort
Issue 17255: 9.3.2.9 What is InterfaceBlock?
Issue 17256: 9.3.2.10 InvocationOnNestedPortAction
Issue 17257: Figure 9.7
Issue 17258: Figure 9.8 - can roles be ports??
Issue 17307: clarification, what "part property" is
Issue 17371: Full ports compartment
Issue 17372: Wrong compartment names
Issue 17373: Is <<equal>> keyword (or stereotype) on binding connectors is part of SysML notation?
Issue 17406: Callout notation for port-specific types and initial values
Issue 17423: remove figure numbers from diagram frames
Issue 17443: SysML Issue Lower bounds on multiplicity not consistent with diagram
Issue 17444: SysML Issue: SysML Issue: Activitiy Switched on diagrams
Issue 17445: SysML Issue: State Machine Notation
Issue 17467: SysML: References to CreateEvent incorrect
Issue 17501: Problems with 1.3 Enumeration Literals
Issue 17529: Requirements should be disallowed from typing other elements
Issue 17546: Contradiction regarding allowed use of the derived indicator for constraint parameters
Issue 17549: ControlOperator stereotype should also extend the CallBehaviorAction metaclass
Issue 17562: N-ary Allocation needs better definition, or deletion
Issue 18168: How to refer to properties of an extension?
Issue 18169: Interface blocks and protocols
Issue 18181: Missing ownership constraints
Issue 18182: Missing type constraints for FullPort
Issue 18183: Incorrect constraint [2] on InterfaceBlock
Issue 18193: Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane
Issue 18268: SysML stereotype notation creates ambiguity about to which element is the stereotype applied
Issue 18269: SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit
Issue 18278: Conjugation of full ports question
Issue 18312: VerdictKind
Issue 18391: View and Viewpoint Limitations in support of auto-view generation
Issue 18407: propertyPath property should be defined once and reused
Issue 18409: Figure 15.8 diagram type
Issue 18410: Constraint [5] should include specializations of Requirement
Issue 18434: Inability to specify partial allocation and requriements satisfaction
Issue 18435: QUDV Unit/QuantityKind name redundancy
Issue 18438: Use of "inherited method" in section 9.3.2.4
Issue 18439: 9.3.2.4 direction of ports
Issue 18440: 9.3.2.4 direction of ports and their notation
Issue 18441: 9.3.2.4 direction of ports and their notation (second issue)
Issue 18456: Activity model library package
Issue 18458: Ports and Flows
Issue 18459: Figures 15.5 and 15.6 diagram types
Issue 18460: Allocation tabular notation normative?
Issue 18461: Allocated notation on object nodes missing from diagram elements table
Issue 18462: Libraries package should be named "SysML Model Libraries"
Issue 18502: Don't use the optional notation for Pins with Allocation
Issue 18503: Diagram show inconsistent data
Issue 18525: Clarification required for Copy relationship
Issue 18561: Refine relationship contextualization
Issue 18623: Semantics of multiple Dependencies
Issue 18653: View and Viewpoint Property Limitations (from Issue 18391 a) and f))
Issue 18659: primitive types in SysML Activities
Issue 18676: ProxyPort with FlowProperties
Issue 18678: Unclear is StructuredActivityNode owned Actions should be Allocated
Issue 18681: QUDV's support for measurement scales is impractical
Issue 18685: Forked association notation ill-formed
Issue 18692: SysML: Unts and QualityKind
Issue 18704: Navigation through non-properties
Issue 18705: SysML 1.3 is incorrect that full ports cannot be behavioral and is inconsistent about what behavioral ports are
Issue 18707: SysML ISO-80000-1 libraries need update per 18269, 18435 and 18681
Issue 18709: The SysML classification of properties is incomplete
Issue 18719: View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g))
Issue 18724: QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit
Issue 18735: About Rate, Continuous and Discrete
Issue 18737: What kind of elements can diagrams be for?.
Issue 18758: Allow the equal symbol, =, without guillemets as an alternative diagram notation for SysML binding connectors
Issue 18783: SysML says nothing about how to deal with multiplicity for flow properties matching
Issue 18805: SysML Issues on Itemp Property values in an IBD
Issue 18846: Missing/wrong elements in diagram table (InformationFlows)
Issue 9763: Page 16 (sysml-rtf)
Click here for this issue's archive.
Source: 88solutions (Mr. Manfred R. Koethe, koethe(at)88solutions.com)
Nature: Uncategorized Issue
Severity:
Summary:
"This section is very difficult to understand, in particular for non-OMG people. Please add a clarifying paragraph here. "
Unable to resolve. Left for RTF to decide. Disposition: Deferred
Redraw visio to improve look. FTF Issue - General issue of style of uniform diagrams .
Discussion: Diagrams are fairly uniform in the chapter. Issue is deferred for the next major release of the spec. Disposition: Deferred
Specify matching rules that enable flow ports and client server ports to be connected.
This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: This issue was previously deferred by the FTF with the following discussion comment: It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration. No additional resolution was reached by the current RTF. Disposition: Deferred
Add more precision to table spec in terms of what rows, columns mean (refer to SP spec). Also, enlarge table elements so they are readable.
Unable to be addressed in time. Disposition: Deferred
BOM properties. In Blocks, BlockProperty, 8.3.2.2, Description, third paragraph, seems to be trying to address the request for bill of material properties. If so, these are properties whose values are all the objects in the composite of a given type. They are derived from all the other block properties of that type. Eg, all the resistors needed to assemble an circuit board.
Discussion: It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration. . Disposition: Deferred
Behavioral flow ports. In Ports and Flows, FlowPort 9.3.2.5, Description, the fourth and sixth paragraph seem to give contradictory defintions of behavioral flow ports. The second refers to the UML isBehavior semantics. The fourth refers to "relaying" to properties or parameters, but doesn't explain what that means. If the two paragraphs are referring to the same thing, then presumably a block behavior is a classifier behavior, and since that behavior executes while the block instance exists, relaying to the parameters requires those parameter to be streaming, in the sense of CompleteActivities. The semantics of relaying properties is unrelated to UML behavior ports.
Clarify the meaning of isBehavioral to indicate if the item is relayed to the owning block or to on of its parts over an internal connector. Add a constraint that states that isBehavioral must be set to True if the port is not connected to an internal connector
In Requirements, Figure 16.1, Requirement has properties with Requirement as type. But instances of stereotypes are not property values. Perhaps this is supported in UML as part of stereotypes with associations to stereotypes. If not, the type should be UML4SysML::Class, with the constraint that the values of the properties are stereotyped by Requirement.
Discussion: Unable to be addressed in time Disposition: Deferred
The current document eliminates Protocol State Machines on the grounds of simplification. See Section 13 However, this leaves a hole in the capabilities of SysML. Currently, SysML supports UML interfaces (provided and required), which can’t have state machines to define them. It is an important part of designing systems interfaces (SE terminology) to define the details of the (UML/SysML) Interfaces. These details include the allowed ordering of messages. As we are not allowed to use behavior state machines and the standard solution, that of, protocol state machines are not included, we can’t properly do interface engineering within SysML If some other solution/work-around is proposed (which I don’t recommend) the explanation of how to accomplish this should be in the spec.
Discussion: Discussed on conference call during Anaheim Meeting (Sept 26, 2006). It was deemed that this would introduce new content into SysML 1.0 . It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration. Disposition: Deferred
SysML currently discards UML 2.1 qualified associations (see 8.3.1.4) as not being of interest to the SE community.
I contest this on two grounds –
1) a. Qualifiers are used expressively and meaningfully to explain domain situations that have nothing to do with data modeling. For example, when I say a baseball roster had 9 members and that there are 9 positions to fill, I am not explicitly saying that there is one person per position. Qualifiers allow me to clarify this piece of the real world and would be very useful on a BDD.
b. Qualifiers are also used idiomatically with generalization discriminators to tie parallel generalization structures together. They are capable of modeling situations, such as when there are many types of missiles, each with their own launcher type.
c. Qualifiers are also used to indicate addressing schemes and mechanisms. For example, by placing an operation/activity etc that returns a type in a qualifier, one can specify the mapping or prioritization /ordering algorithm. Specifying such algorithms may be the SE’s job, when it part of an equation report, algorithm development. This could fit into SysML and support allocation to functional (target prioritization scheme, best antenna-signal function) and structural components (packet routers). This is fully in the spirit of what practicing SEs do and would round out the capability of SysML.[Note that this capability could be delayed for a later SysML, the other parts should be addressed sooner]
2) Qualifiers appear to be part of small part of UML that is incompatible with use with a SysML strict profile mechanism. Imagine a model done in strict SysML, then brought into UML, where a qualifier is added to the relationship, changing the multiplicity at one end. If the model is then brought back into (strict) SysML and the qualifier is then dropped, the multiplicity cannot be automatically restored (or determined from the model). Because of this, qualifiers must be forbidden in UML in such contexts
Discussion: Qualified associations were excluded in SysML V1.0 as part of the general goal to subset the amount of UML that a system engineer must understand for system modeling. If usage of SysML V1.0 indicates significant modeling gaps from the exclusion of qualified associations, their inclusion can be reconsidered in future versions of SysML. Experience is still needed to determine if there are alternative ways to model cases such as those cited without the complexity of the added notations and rules for qualified associations. Disposition: Deferred
The text in 14.1 should briefly discuss that for System Engineers, run-time optionality is not the typical distinction for indentifying extensions. If we wanted to draw a flow chart, we would use an activity diagram. It is usually more relevant to identify as extensions those use cases that not are needed to reach the goal of the base use case. This allows the System Engineers to use the dependency graph among the use cases to help determine production/test/delivery order. This also makes it clear to the reviewer which features are considered optional and which are not. At the SE level, this is more important that than flagging those features that sometimes invoked and sometimes not invoked. Please clarify with this use at the SE level
Discussion: Unable to be addressed in time Disposition: Deferred This issue was previously deferred by the FTF with the following discussion comment: Unable to be addressed in time. No additional resolution was reached by the current RTF. Disposition: Deferred
Section 11 should show an example of generalization/specialization of Activiites when then are being shown in a bdd.
Resolution: Generalization / specialization of activities is not mentioned in the rest of the document, has not come up in discussion of SysML application, requires more explanation. Defer until the need becomes clearer. Disposition: Deferred
Interfaces on Flow Ports It’s not clear how to model complex ports that partake of both service and physical flow characteristics. For example, I could use communicate in morse code over a hydraulic line. This would be modeled normally as a standard (service) port, except for the medium. Or I can use in-band signaling over a communication line (as it used to be on a telephone lines). In such cases, I’d like to be able to attach interfaces (with the set of operations) to a flow port.
This is too complicated for the RTF. We defer it to the next version of SysML. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: This is too complicated for the RTF. We defer it to the next version of SysML. Disposition: Deferred
On figure 16.8 there should be up-arrow pointing to the Accelerate state from the decision node
Unable to be addressed in time. Disposition: Deferred
Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio
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.
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. Disposition: Deferred
In Table 14.1 Use Case Diagram, the abstract syntax reference for the Subject notation is given as “Role name on Qualifier”. This does not appear correct
In the constraints on viewpoint, 7.3.2.5, the plural form of the prosperities is used. I believe they should be in the singular. Constraints … [2]The property ownedOperations must be empty. [3]The property ownedAttributes must be empty. …
in paragraph 8.3.2.3, the semantic of a default value for a DistributedProperty is not specified. My suggestion is that the default values should be a realization of the random variable following the distribution. It would be nice to have an example in the paragraph too, for instance: <<uniform>>{min=0,max=2} p:Real=2 <<uniform>>{min=0,max=2} p:Real=1.2 but not: <<uniform>>{min=0,max=2} p:Real=2.3
Various views on the possible semantics of a default value for a distributed property were discussed within the RTF with no final resolution reached. The issue is being deferred so more discussion can occur. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Various views on the possible semantics of a default value for a distributed property were discussed within the RTF with no final resolution reached. The issue is being deferred so more discussion can occur. Disposition: Deferred
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?
Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred
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?
Unable to be addressed in time. Disposition: Deferred
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?
Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred
The CAN_Bus shown in the ibd B.22 is missing in figure B.18.
Unable to be addressed in time. Disposition: Deferred
Update Annex G to accurately specify the graphical and textual notations supported by the current SysML specification. Currently, an editorial note at the top of Annex G notes that the Annex contents are to be updated for specific diagram types during the finalization phase of the specification. Resolve the diagram types for which BNF syntax productions will be provided, and make sure that these match the notations documented in the corresponding SysML chapters.
Discussion: Completion and detailed verification of Annex G exceeds the scope of work that is feasible during the SysML FTF. Because the scope of SysML is defined by its concrete syntax, a more formal version of concrete syntax definition should be considered for future versions of the SysML specification. Disposition: Deferred
The relationship between a behavioral flow port and parameters is marked as a semantic variation point. Isn't it possible to specify a concrete relationship here? The specification proposes a binding relationship. What is a binding relationship? It is not known in SysML or UML.
We did not reach an agreement on this during our discussions for the initial submission - it is too complicated for the RTF. We recommend to bring this issue to the next version of SysML. Disposition: Deferred This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: We did not reach an agreement on this during our discussions for the initial submission – it is too complicated for the RTF. We recommend to bring this issue to the next version of SysML. Disposition: Deferred
Viewpoint.Purpose[1] should probably be Purpose[*] to be consistent with the other attributes of Viewpoint. Perhaps [1..*] if needs to be mandatory.
The viewpoint element can specify more than one stakeholder (multiplicity *). Each of the stakeholder has it's own concerns (multiplicity *). However the view has only one purpose that covers all concerns of all stakeholders. Disposition: Closed, no change
In SysML 9.3.2.4, the possible flow directions include
nout
based on later usage, this is incorrect for
inout.
This misspelling was already fixed in the 1.0 Available Specification. 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.
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."
Unable to be addressed in time. Disposition: Deferred Discussed: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Unable to be addressed in time. Disposition: Deferred
The exclusion of UML concrete syntax for Instance Specifications has resulted in the inability to assign default values to properties of blocks using anything other than simple text strings for value properties. Consider reintroducing UML concrete syntax for UML InstanceSpecification into one or more SysML diagram types so that more complex default values can be assigned.
Discussion: The defaultValue compartment on an internal block diagram does provide at least one available option for assigning default values to structured values, as discussed in the subsection "Default value compartment" under 8.3.1.3 Internal Block Diagram. Creating a graphical compartment on an internal block diagram to assign values to properties defined on a block definition diagram may be more cumbersome than a textual syntax, but tools may be able to streamline the linkage to the default value for usability. In particular, the use of a "structure" compartment on a block definition would allow the default value to be shown next to a properties compartment where a property is defined. Other work in OMG is currently underway that may define a standardized form of textual syntax for value specifications. SysML could consider such a textual syntax for property values in future versions. Disposition: Deferred
The figure and added text describing the use of <<extend>> is still unclear and inconsistent. As agreed, converting Start the vehicle to an <<include>> and Park to <<extend>> will correct the confusion and make the added text unnecessary.
Unable to be addressed in time. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Unable to be addressed in time. Disposition: Deferred
Brake is spelled Break twice on this page, once in the paragraph between the figures and once in figure 11.141
This is fixed in the current version of the specification. Disposition: Closed No Change
Several places in the spec, it is indicated that behaviors can be shown on block and class diagrams. As SysML does not support class diagrams, it should be changed to block diagrams only. See text on 11.1.1.1; 11.3.1.1(3x);11.3.1.4
In the explanation for Fig 17.4.2, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an "isEncapsulated" property, described elsewhere in the specification (p. 46) This is very confusing. The text should be corrected to indicate that the property isEncapsulated of the Block Stereotype is inherited by the stereotype system and concept
In Annex A, the bdd is indicated that it can only be for blocks, pkgs, and constraint blocks. [A previous issue was raised that this list should include activities]. This list is incomplete; it should probably include all SysML-allowed stereotypes (and extensions) of class (perhaps classifier), including signal, actor, interface, etc. Even if such elements are not allowed to be model elements _for_ the diagram, they should be explicitly allowed as elements on a bdd. Similarly the allowed elements for and on an ibd should be clarified.
Unable to be addressed in time. Disposition: Deferred
It is unclear in this diagram what the element that this bdd is for (a package?) However, the elements on this diagram are metaclass and stereotype elements, which I believe are the wrong metalevel for bdd diagrams. This is really a notional metaclass diagram indicating how SysML might be extended, but it is not a SysML diagram itself
In Figure 17.4.2’s explanation, the Block stereotype is described as having no properties. While the diagram does not show any properties, the block stereotype has an “isEncapsulated” property (defined elsewhere in the spec). This is very confusing. The text should be corrected to indicate that all properties of the Block stereotype (e.g., “isEncapsultated), even if not indicated on the diagram, would be inherited by the stereotypes «system» and «context» An alternative fix that also corrected the diagram would perhaps be better but more effort.
Can anybody clarify the definition of a constraint parameter for me? To quote the SysML spec: [1]The type of a constraint property must be a constraint block. So a constraint parameter is not a constraint property typed by a value type or something like that... To quote again: "A constraint block is defined by a keyword of «constraint» applied to a block definition. The properties of this block define the parameters of the constraint." So does this mean that a parameter is a block property (or an ordinary property)? Would it make sense to add a <<constraint parameter>> stereotype to constraint blocks? Has this been suggested or does it make sense?
The constraint referenced was quoted from the SysML Final Adopted Specification (ptc/06-05-04). The FTF replaced this constraint by two new constraints by two new ones that clarify that the stereotype must be applied to properties of a SysML Block that are typed by a ConstraintBlock. Because the ConstraintProperty must be applied to any property typed by a ConstraintBlock, it could be removed with no loss of information, or additional stereotypes could be defined for other cases, such as a constraint parameter. No additions or changes to the property stereotypes are being proposed in this version of SysML. 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.
Additional requirements would need to be established to before defining Rationale as more than just the stereotype of Comment currently defined in SysML. Such requirements and proposals to satisfy them could be considered in future revisions of SysML. Disposition: Deferred
Allocation arrows direction seems to be opposite to UML dependency rules. We do ne think it is a good idea ?
Unable to be addressed in time. Disposition: Deferred
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.
Unable to be addressed in time. Disposition: Deferred
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.
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. Disposition: Deferred
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
Unable to be addressed in time. Disposition: Deferred
What happens if a control value disables an action within an activitz and no other actions are active and no more tokens are present?
The execution of the activity is complete. Disposition: Closed, no change
Timing diagrams are missing in SysML. They are an important diagram for several engineering disciplines. For example I know a project from the automotive/robotic domain that won't use SysML, because of the missing timing diagrams. Timing diagrams will improve the acceptance of SysML in engineering disciplines.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Much useful discussion about the usefulness of timing diagrams occurred within the RTF. Their addition could be considered in future versions of SysML. Disposition: Deferred
The block namespace compartment shows a bdd of the elements that are part of the namespace of the block. Is it allowed to show relationships from a block inside that compartment to a external block? The relationship could be in the model, but can I show it in the diagram? I think it should be allowed. I don't see any problems.
There is nothing stated in the specification that disallows associations being shown that would cross a namespace compartment boundary, and as the issue notes allowing this doesn't seem to raise any problems. How to specify that such cases are permitted, however, along with many other variations of concrete syntax, is being left for consideration in future updates of the specification. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: There is nothing stated in the specification that disallows associations being shown that would cross a namespace compartment boundary, and as the issue notes allowing this doesn’t seem to raise any problems. How to specify that such cases are permitted, however, along with many other variations of concrete syntax, is being left for consideration in future updates of the specification. Disposition: Deferred
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
The namespace compartment is reserved for nested classifiers owned by a SysML Block, which is represented in the UML metamodel by elements contained in the "nestedClassifier" attribute of UML Class. It can be used to define local classes which are referenced only in a local context. Moreover, UML defines such nested classifiers as redefinable within an inheritance context, though specifics of how this would be done or shown on a diagram do not seem to be fully specified. The issue is correct that the SysML specification does not currently contain any examples of such local namespace classifiers. Adding such examples could be considered in future revisions of SysML, but the main request of this issue is to define a compartment to contain blocks owned by composition. UML itself is relatively loose in its specification of classifier compartments and many details of concrete syntax, but some of its developers have shown such namespace compartments in their examples. The closest prescription UML makes is in "Presentation Options" under 7.3.7 Class, "Additional compartments may be supplied to show other details, such as constraints, or to divide features." SysML makes the definition of this compartment explicit, to remove any ambiguity for the depiction of nested classifiers such as local blocks. It would be good to establish usage examples for namespace compartments on a Block, either within the SysML spec itself or within tutorial materials developed outside the spec. Specific proposals for such examples could be raised as future issues. This issue, however, requests a new block compartment to replace the namespace compartment currently in SysML. SysML already provides the UML black diamond notation to show composition associations between blocks on a block definition diagram, which can include details such as multiplicities and ordering of the end roles carried by the composition. Internal block diagrams provide another means by which to show blocks owned by composition roles, which SysML defines as "parts." While the issue is correct that more motivation could be provided for the namespace compartment already included in SysML, the specific request for a new kind of compartment for blocks on a bdd is beyond the scope of appropriate for an RTF. It could be considered for an RFP for SysML 2.0, after more experience is gained with existing compartments to determine which ones might be added or dropped. Disposition: Closed, no change
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.
Considerable work has been completed to draft initial OCL versions of constraints currently stated in the SysML spec by means of natural language statements. The RTF has agreed that both natural language and OCL forms of constraints should be included in future versions of the specification. Additional review will be needed before the current draft OCL constraints will be ready to be included in the specification. Disposition: Deferred
I was unable to find a standard way to describe a flow of data in sequence diagrams. Currently sequence diagrams only deal with flow of control by exchanging messages. We believe that it would be very useful to also have a way for describing data flow as part of the interaction scenario
Multiple suggestions to address this issue were discussed by the RTF, but a final resolution was not reached. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Multiple suggestions to address this issue were discussed by the RTF, but a final resolution was not reached. Disposition: Deferred
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.
The semantics of black diamond applies to CallBehaviorActions. The semantics of black diamond is deletion of an instance of the class on the diamond end deletes instances of the class on the other end, when they are linked by the composite association (the life span semantics was removed in an early version of UML). The instances of UML behaviors are executions of the behaviors. When an activity execution starts another behavior execution through CallBehaviorAction, deleting the calling execution (terminating it) deletes the called executions (terminating them). This is described in Section 11.1.4. Disposition: Closed, no change
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.
Yes, the execution of the activity is complete. There is no control value defined in SysML for suspending and resuming actions. Disposition: Closed, no change
It is not explicitly mentioned that SysML changes the notation for the satisfy relationship. It is a stereotyped realization relationship and should be notated as a dashed line with a triangular arrowhead. But SysML uses a simple arrowhead.
The types of the attributes dimension and unit must be Dimension and Unit instead of ValueType according to Fig 8.4.
The nesting of requirements has the semantics that the upper requirement is fulfilled if all it's sub-requirements are fulfilled. In addition we need a mechanism to express a xor between sub-requirements sets to support variant modeling. If a requirement can be satisfied by different system components, these system components have different technically requirements. These requirements are sub-requirements, but a subset of them that relates to one of the system components is sufficient to fulfill the upper requirement. It is not necessary to fulfill all sub-requirements
Unable to be addressed in time. Disposition: Deferred
The list of diagram kinds and abbreviations should contain the non-normative table and matrix diagram kinds
I miss a explicit statement that SysML changes the standard notation for instance specifications. According to that the name of dimensions and units must be underlined
Nested connector ends: "Connectors may be drawn that cross the boundaries of nested properties to connect to properties within them." That's an important feature of SysML. "The ability to connect to nested properties within a containing block requires that multiple levels of decomposition be shown on the same diagram." I think that's a problem in practice. Often I don't want to see the nested properties in the diagram. I propose to add a notational feature to show that a connector end is connected with a nested property without showing that property. For example we could draw the connector to the border of the surrounding property and attach the stereotype <<nested>> as a short form of <<nestedConnectorEnd>> and optionally the propertyPath. What do you think?
Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred
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?
Disposition: See Issue 11622 for resolution
The semantics of the Binding Connector is described as follow : “8.3.2.10 Binding Connector Description A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values. If the properties at the ends of a binding connector are typed by a DataType or ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties. If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.” So, I understand that definition if the multiplicity of the properties linked by the binding connector is 0..1 or 1. But what happen is the upper bound of the multiplicity is greater than 1? If for example, it is 0..* ? And moreover, what happen when the multiplicity of both property is different, as for example on one end 0..1 and on the other end 1 ? In this case, as according to the previous definition, the value of both properties has to be equal, what happen to the value of the proiperty which multiplicity is 1 when the other property is not yet defined?
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation
<<satisfy>> is displayed as dependency (in examples), however it is extension of Realization (closed arrow notation shall be used)
Uppercase/lowercase problems. Stereotype names are defined in upper case, but in diagrams are displayed in lower case (e.g. Block and <<block>>). Attributes(tags) are displayed in uppercase in diagrams, but are defined in lower case in the specification.
Lack of notation for units and dimensions on values. There are no samples at all
Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. Disposition: Deferred Discussion: Issue 12219, “suggest need Quantity stereotype and definition,” is proposing changes to the current SysML support of value types with units and dimensions (and is renaming the current Dimension stereotyp to QuantityKind). These changes provide an important foundation for supporing notations on values, including a distinction between symbols for units vs. unit names. A new normative Annex C.5 also defines a Quantity value type which could be used to carry values that include the identification of a dynamically selected unit within the value itself. Issue 12219, however, does not change the underlying structure of value types or provide new forms of value specfications. As part of alignment efforts between SysML and MARTE, the MARTE Value Specification Language (VSL) continues to offer a possible long-term direction for expressions and other, more complete forms of value specifications that might be considered in future revisions of SysML. Until MARTE VSL can be considered in more detail, and more experience is gained with the new capabilities included in Issue 12219, this issue is being deferred. Disposition: Deferred
Association branching is not defined in UML. Mapping is not clear. Composition tree is not defined in UML, mapping is not clear.
The UML Superstructure specification, in the last paragraph under 7.3.3 Association, subsection "Presentation Options," states: If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends into a single segment. Any adornments on that single segment apply to all of the aggregation ends. SysML merely adopts this existing notation variant from UML. Each separate branch is represented in the metamodel by a separate association, as in UML. Branching is only supported for associations with composite or shared aggregation, which is consistent with the notations shown in the SysML Diagram Elements tables. Disposition: Closed, no change
Constraint parameter notation conflicts with UML private ports notation. How to distinguish between part and ports if notation is the same?
Unable to be addressed in time. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Unable to be addressed in time. Disposition: Deferred
Stereotypes, tags and constraints are displayed on elements that can’t have such stereotypes applied. It is not allowed in UML to display stereotypes of related elements (secondary references): a) Stereotypes i. Block stereotypes are displayed on parts ii. Block stereotypes are displayed on object nodes iii. Parameter stereotypes are displayed on ActivityParameterNode iv. Behavior or operation stereotypes are displayed on CallActions b) Tags i. Block allocations are displayed on parts ii. Units and dimensions shall be possible to show on properties and slots, but these tags are owned in Valuetype c) Constraints i. Constraints of ConstraintBlock are displayed on constraintProperty (B.30)
Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Some of the cases raised by this issue may be covered by the resolution for Issue 11819, Internal Block Diagram Extensions, including the discussion within that resolution. Other cases raised by this issue, may not be fully covered by that issue or may require additional mechanisms for the requested display capability. The issue is being deferred so that all these cases can continue to be explored. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
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)
Unable to be addressed in time. Disposition: Deferred
<<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Parts are added directly into package. B27 - <<moe>> element that is a part is displayed inside of a package <<view>>
Unable to be addressed in time. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Unable to be addressed in time. Disposition: Deferred
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)
The view is not the owner of the elements that are shown in the context of the view. As stated in constraint [1] the view is only allowed to own element import, package import, comments, and constraints. Disposition: Closed, no change
Wrong ends of Allocate relationship used in Allocated definition. /allocatedTo is set of clients, but client is source of dependency (so "from"), /allocatedFrom is set of suppliers, but supplier is target of dependency (so "to")
PropertySpecificType concept is highly ineffective and suboptimal. It requires to redefine all structure from very root context if some deep nested part should use different configuration. So one should redefine all car internal structures if one bolt should be changed or color should be different
See the resolution for Issue 10473, Instance Specifications for Default Values, for a definition of an initialValues compartment on an internal block diagram and a corresponding metamodel to represent values within these compartments. This compartment and metamodel now provide an alternative to property-specific types when all that is required is to specify context-specific values. For example, if just the size of a bolt or the value of a color is changed, it is no longer necessary to redefine all the internal structures of a car. With the definition of new capabilities for context-specific values, use of the property-specfic type mechanism can be reserved for cases in which new or redefined features are defined on a classifier which types a local property. Preserving this additional capability for cases in which additional or redefined features are of interest in a local context was agreed in meetings and discussions of the RTF to be worth preserving in SysML. Issues 11308, "Question on PropertySpecificType" and 11622, "Mapping of PropertySpecificType to the UML metamodel," request further clarification of the metamodel used to represent a property-specific type. Their resolution is consolidated under issue 11622. The resolution for Issue 11895, "Section 8.3.2.6: questions about PropertySpecificType" includes answers to the specific questions raised by that issue. Disposition: Closed, no change
Is it allowed to attach the optional stereotype to outgoing parameters? The definition mentions only ingoing parameters: "This means the parameter is not required to have a value for the activity or any behavior to begin execution."
"An “X” on a single end of an association to indicate that an end is “not navigable” has similarly been dropped, as has the use of a small filled dot at the end of an association to indicate an owned end of an association." In this text I see two mistakes: 1. "filled dot" notation is used for ends owned by associated classifier, not owned by association (an opposite situation). 2. "owned end of an association" does not mean it is not navigable. Association has "navigableOwnedEnds" property for navigable owned ends.
On Fig 9.4 p 70. the I_ICEData I/F has the following services defined on the cntrl (the engine) getRPM():Integer getTemperature():Real isKnockSensor():Boolean These names make sense if the interface was a provided interface on the engine. However, the I_ICEData interface on the engine is a REQUIRED interface. The interface should be defined something more along the lines of… hereIsRPM(:Integer) hereIsTemperature(:Real) hereIsKnockSensor(:Boolean) as the engine is using this interface to tell the PowerControlUnit the current values of those properties. This problem is duplicated later in Figure B.20 on p 194
This is a naming convention argument and there is no absolute right and wrong on this. The get* may make more sense than hereIs* since it means that the owner of the block requiring the services can call get* to get the values, while hereIs* is not a common naming convention. Since this is just an example anybody can choose any naming convention they like. No specific naming convention is dictated by SysML. Disposition: Closed, no change
Inconsistency among valuetype/unit/dimension In Figure 8.4 p 43, the following multiplicities are given A valutype may (0..1) have a unit and may have a (0..1) dimension A unit may (0..1) have a dimension. On page 49. there is a constraint Constraints [1]If a value is present for the unit attribute, the dimension attribute must be equal to the dimension property of the referenced unit. This would mean that if the unit’s dimension is null, then the valutype’s dimension must also be null. This seems overly constraining. In 8.4.2, it says Because a unit already identifies the type of quantity, or dimension, that the unit measures, a value type only needs to identify the unit to identify the dimension as well. This statement seems to say the unit must have a dimension, and the valuetype’s dimension can be null even though the unit’s is not. This statement therefore disagrees with the Figure 8.4 and the constraint on page 49
This 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: Deferred
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.
This issue points out that containment works precisely as designed with respect to requirements. Containment for requirements should be no different than containment for packages. The subsystem package can contain a copy of the original requirement. This is the primary reason the copy relationship was added to SysML. Disposition: Closed, no change
Mapping of PropertySpecificType to the UML metamodel requires further explanation Chapter 8 introduces the notion of property-specific type to assign values to parts inside an ibd. Section 8.3.1.1 defines a notation for property-specific types. Section 8.3.2.8 provides a definition of the <<propertySpecificType>> stereotype and gives elements on how this concept maps to the UML metamodel. However, this section does not explicitly define: 1) where are stored the actual values? One may understand that a default value of a property owned by a class, which is stereotyped as <<propertySpecificType>>, is considered as a property-specific value. This property-specific value may be considered as an instance of a property owned by the refrenced block. It is not clearly stated though. 2) how does a property-specific type relate to the referenced block ? In other words, if a class is stereotyped as <<propertySpecificType>>, which feature of this class points to the referenced block? We may need to add a paragraph in section 8.3.2.8 that provides answers to questions.
Address potential points of convergence between MARTE and SysML The MARTE profile supports modeling and analysis of real-time and embedded systems. Some of the concepts defined in this specification are applicable to Systems Engineering practices and can be of interest to SysML users. Early interactions between the SysML and MARTE partners have allowed to identify convergence points: - support for value expressions and constraint expressions using a dedicated language - formalisation of a time model, including the notion of clock to measure time - definition of metamodel elements for units and dimensions As discussion goes on, other convergence points may be identified and added to this list. Working on an alignment between MARTE and SysML has been identified as an important opportunity for both groups.
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. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. 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. Disposition: Deferred
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
Here is a question on the usage of sequence diagrams with SysML, more specially with blocks that communicate via flow ports. Within UML, Message is associated with signature of either a Signal or an Operation (see constraint 2 on Message meta class, p. 492 of the UML2 superstructure spec.). In SysML, blocks introduce an alternative for communication between blocks w.r.t. to usual UML2 composite structures: flow ports are basically dedicated to support data-based communication between blocks in contrast of UML2 that does not support such kind of communication between composite structures. In this case, a Message within an interaction should be able to refer either a DataType, a Block, a ValueType if the communication happen between two atomic flow ports, or to a FlowSpecification if the communication happen between two non-atomic port. I did not see anything related this issue within the SysML spec. Do I miss something or is it something missing in the SysML doc?
Unable to be addressed in time. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Unable to be addressed in time. Disposition: Deferred
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.
Discussion by the RTF recognized that additional typing of a flowports may be needed, but no resolution was reached. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion by the RTF recognized that additional typing of a flowports may be needed, but no resolution was reached. Disposition: Deferred
Replace horrific long UML URL with short form: http://doc.omg.org/formal/2007-02-03
In the notation table for sequence diagrams there is no reference to interaction parameters, or to arguments of interaction uses.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
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.
In 9.3.2.7, the Standard Port is listed as a stereotype, yet it is not shown as an extension in Figure 9.1. The Standard Port should either be included in Figure 9.1 as a stereotype or removed from the list of stereotypes in 9.3.2.7. Since the only change is a change of name, I propose leaving it in as a stereotype, but clarifying that the only extension is a name change.
The verify relationship currently constraints one of its ends to be a test case. There have been several cases where this is too restrictive. In particular, sometimes it is useful to verify a requirement via analysis and leverage parametrics. In this case, it one may want to verify the reuqirement using a constraint block, block, or constraint property. The proposal is to delete the constraint that a requirement can only be verified with a test case which reads as follows: [2]The client must be an element stereotyped by «testCase» or one of the «testCase» subtypes. In addition, the description should be changed as follows: From: A Verify relationship is a dependency between a requirement and a test case that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) test case to the (supplier) requirement. To: A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) to the (supplier) requirement. There were two changes to the above description text. add 'or other model element', delete 'test case'
SysML needs the capability to interchange diagrams in addition to model data. The concrete syntax complliance should include a requirement to comply with diagram interchange in a similar way that the infrastructure specifciation does. The following is included in section 2.3 of the Infrastructure Spec under Concrete Syntax Compliance: - the ability to output diagrams and to read in diagrams based on the XMI schema defined by the Diagram Interchange specification for notation at that level. This option requires abstract syntax and concrete syntax compliance. The proposal is to add the same requirement as above to section 5.3 as a second bullet under the concrete syntax compliance.
Diagram interchange is strongly desirable but is not yet supported among current tools. A new "Diagram Definition RFP" issued by OMG could offer additional support for concrete syntax compliance including interchange. Diagram compliance issues can be considered in future updates of the specification. Disposition: Deferred Discussion: This issue was previously deferred by the SysML 1.1 RTF, which noted: Diagram interchange is strongly desirable but is not yet supported among current tools. A new “Diagram Definition RFP” issued by OMG could offer additional support for concrete syntax compliance including interchange. Diagram compliance issues can be considered in future updates of the specification. Submission and adoption are still in progress for the Diagram Definition RFP. New forms of support for diagram definition and interchange may be adopted by OMG as a result of this process. The addition of diagram interchange compliance to SysML should be reassessed once these future directions become clear. Additional compliance points for diagram syntax and interchange could be added by either a future RTF or RFP submission process. Disposition: Deferred
There is reference to timelines in 11.1.5. This is widely considered a critical capability for SysML, but there is not example in the spec. Add a usage example of an activity diagram with timing constraints and the corresponding timing diagram as referred to in 11.1.5.
A block stereotype should be applied to any subclass of a block. Add a constraint to the block stereotype in 8.3.2.2 to reflect this.
The callout notation used in the Diagram Elements tables in 16.2.1 of the Requirements Chapter (pg 144-146)is inconsistent with the callout noation in the Diagram Elements tables in 15.2.1 of the Allocation chapter (pg 130). The text in the callout in Requirements starts with a capital letter and the text in the callout in Allocations starts with lower case. Make them consistent.
Disposition: See issue 11492 for disposition
Figure 11.8, page 98, defines a "rate" stereotype attribute typed as InstanceSpecification. In section 11.3.2.8, page 101, one can read "The rate stereotype has a rate property of type ValueSpecification". There seems to be an inconsistency here. I assume the relevant type for the "rate" stereotype attribute is ValueSpecification. Please can you confirm?
Disposition: See issue 12134 for disposition
The current paragraph describes comments as follows: "Comments can be associated with any model element and are quite useful as an informal means of documenting the model. The comment is not included in the model repository." If comments and their extensions (e.g., rationale, problem, etc) are not stored in the model repository, then they would not be retrievable when the model is next opened. This would make filling them out a waste of time. Please determine what is meant here and correct it.
Please provide a notation variant that allows to show block stereotypes at property elements typed by those blocks in an ibd. Similar to the notation variant that CallBehaviorActions can show the stereotypes of the called Behavior element. For example a common approach is to define stereotypes for discipline specific elements like <<hardware>>, <<software>>, <<mechanic>>, and so on. It is important to see the information in a bdd and ibd. It is circumstantial and superfluous to define two stereotypes for blocks and properties.
Stakeholder and Concern should be first class elements. This is needed for UPDM modelers, that will likely will be reusing SysML View/Viewpoint structure.
Alignment with UPDM is premature, since UPDM has not completed finalization. This issue should be considered in the context of broader requirements for reuse of SysML Viewpoint. The initial version of SysML relies on informal documentation strings to define a viewpoint. Any greater formalization of viewpoint should consider whether other supporting elements beyond just Stakeholder should also be promoted to first-class status. Disposition: Deferred
I am trying to support PropertySpecificType in our SysML Toolkit and I hit some road block while trying to implement the same. I have had some discussion with Sandy last week regarding the same but I quiet don’t get how this can be supported without some additional constructs to the PropertySpecificType stereotype. Below are the lists of questions I have: When a default value is provided for the property type, then a type derived from the original type should be created and its default value should be set as the new deafult value of the property. The property type should be displayed in square brackets which would indicated that the type is a specialized type. There can be more than one specialization of the same class, in such case there is no construct to store which specialization is associated with which property? This additional construct is very much needed because there is no way to know whether the specialization is created by SysML for PropertySpecificType or whether it is created by user? What happens in case of multi-level hierarchy? (If Class2 inherits Class1, and property1 is typed by Class2 & the default value at property1 is changed the resultant propertyspecifictype is Class3. Should the tool show property1:[Class2] or property1:[Class1]). Why is the PropertySpecificType extends UML2::Classifier and not UML2:Type? PropertySpecificType was introduced to provide specific default values to properties in Internal Block Diagram. Why not use the InstanceSpecification from UML2? Below Diagram shows how this is supported in UML2.
In response to Question 1, a property-specific type results in a new classifier which specializes whatever classifier was referenced as the starting classifier of the property-specific type. At most one classifier can be specified as the starting classifier of a property-specific type. While this classifier may itself specialize multiple other classifiers, the property-specific type specializes only the single classifier referenced by the property-specific type. In the example, if Class2 was referenced as the starting type (the name specified within square brackets) than that is the only classifier which the property-specific type specializes directly, regardless of any other classes such Class1 that Class2 may inherit from. In response to Question 2, property-specific types are allowed only on properties of a SysML Block. A block property may be typed only by a SysML Block, SysML ValueType, or UML DataType. All of these are UML classifiers. In the UML metamodel, Type is an abstract metaclass, and Classifier is its primary concrete metaclass. In response to Question 3, one of the original purposes of PropertySpecificType was not to provide specific default values of properties, but also to permit local specialized types with customized features in a local usage context. See the resolution for Issue 10473 for the definition of an initialValues compartment, including a metamodel representation based on UML InstanceValue and ValueSpecification, for a solution which can provide context-specific values for properties without property-specific types, as suggested. Disposition: Closed, no change
in Figure 9.1 Port Stereotypes,the Flow Specification that extends UML4SysML::Property should be a Flow Property and not a Flow Specification.
When an allocation relationship is depicted on an activity diagram using Allocate Activity Partitions, it is unclear if the allocation relationship is from the Action Node to the Part represented by the partition (direct allocation), or from the Activity typing the Action Node to the Block typing the Part (Inferred allocation). Since in practice it has become necessary to represent both conditions, this portion of the SysML specification should be modified to incorporate some graphical indication to distinguish them.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
An allocation callout, when anchored to an Item Flow on an Internal Block Diagram, is unclear. If the Item Flow has an Item Property, then the allocation could be to the Item Flow itself, the Item Property, or the Item Property type (Conveyed Classifier). Recommendation: develop a compact graphical notation to distinguish the target of the allocation when a callout is used with any graphical depiction of an Item Flow.
Since ItemFlow is a stereotype of InformationFlow, it can be related to an ActivityEdge and depicted on an Activity Diagram. At least one tool has provided this capability. Clarify the use of ItemFlows on Activity Diagrams in the specification: If this is not desirable, then an additional constraint must be added to ItemFlows to prevent it. Personally, I like the idea of representing ItemFlows on ObjectFlows, but the semantic meaning of this representation is unclear. If this is retained, then it should be discussed in both chapter 9 and chapter 11.
The UML metamodel shows information flows can be realized by activity edges, and that realization of information flow is intended to link more abstract models to more concrete (realizing) ones in ways determined by the modeler. Agreeing on the specific ways this is done with realizing activity edges and whether to standardize those in SysML will take more time. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: The UML metamodel shows information flows can be realized by activity edges, and that realization of information flow is intended to link more abstract models to more concrete (realizing) ones in ways determined by the modeler. Agreeing on the specific ways this is done with realizing activity edges and whether to standardize those in SysML will take more time. Disposition: Deferred
There are at least 4 kinds of properties of blocks: parts, references, values, constraints Constraint properties do not take part in the assembly hierarchy of blocks. Although they are of type Block via ConstraintBlock and have AggregationKind 'composite' they should not be considered "parts". SysML1.0, 8 Blocks: 'A block can include properties to specify its values, parts, and references to other blocks.' Rewrite to include constraint properties: 'A block can include properties to specify its values, parts, references to other blocks, and constraint properties.' SysML1.0, 8.3.1.2 Internal Block Diagram, Property types: 'Three general categories of properties are recognized in SysML: parts, references, and value properties' Rewrite to include constraint properties: 'Four general categories of properties are recognized in SysML: parts, references, value properties, and constraint properties.' SysML1.0, 8.3.2.2 Block, Description: 'SysML establishes three standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classifed as a part property. A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, and value properties may be shown in block definition compartments with the labels “parts,” “references,” and “values” respectively. Properties of any type may be shown in a “properties” compartment.' Rewrite to include constraint properties: 'SysML establishes four standard classifications of properties belonging to a SysML Block. A property typed by a SysML Block that has composite aggregation is classified as a part property (excluding constraint properties, which are typed by a Constraint Block). A property typed by a Block that does not have composite aggregation is classified as a reference property. A property typed by a UML DataType or SysML ValueType is classified as a value property. Part, reference, value properties, and constraint properties, may be shown in block definition compartments with the labels “parts,” “references,” “values”, and "constraints" respectively. Properties of any type may be shown in a “properties” compartment.' Note also minor spelling correction: classifed -> classified.
.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.)
Disposition: See issue 12126 for disposition
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
they can be fully typed with units of measure and related concepts has occurred within the RTF. A variety of authoritative sources and comparison with practice by other communities including the related OMG MARTE profile have also contributed much to the discussion. The scope of any potential new model, however, has ended up beyond the workload that could be completed during this RTF. While much of the discussion has indicated a need for refinement or elaboration beyond the current Unit and DImension model of SysML, these initial elements of SysML 1.0 do provide an initial capability for SysML models. Issues 12128 and 12219 are both being deferred so that they can continue to be considered for future revisions of SysML. Disposition: Deferred
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'
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'.)
A more complete resolution would be to add a constraint that a ConstraintBlock may be used only to type a property owned by a SysML Block. Then the additional constraints on ConstraintProperty could be further simplified. It is recommended that all these constraints and stereotype definitions be reevaluated along with OCL statements of these constraints, as raised by Issue 11091 (also deferred). Disposition: Deferred Discussion: The issue is being deferred to allow further consideration in future revisions of SysML. The email archive of the RTF discussion list contains discussion and concerns raised about this issue after a resolution was initially included as part of a draft ballot. Following is the complete text of the original proposed resolution, which was withdrawn from further consideration in the current revision of SysML: Resolution: 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. Analysis of the constraints which currently appear under Section 10.3.2.2 ConstraintBlock, including their potential formulation in OCL, confirmed that they added no new constraints but only served to define of the ConstraintProperty category. The definition of the term “constraint property” can be accomplished entirely by language under 10.3.2.1 ConstraintBlock, in the same way used to define the categories of part, reference, and value properties under Section 8.3.2.2 Block. Discussion within the RTF recommended that a consistent policy be adopted for such “calculated stereotypes” which only classify existing elements. Since tools are free to create internal stereotypes or other means to carry such information (e.g., to control placement of properties in compartments of a block), and no other such calculated stereotypes remain in SysML, the policy that is consistent with the other categories of property is to remove the ConstraintProperty stereotype altogether. Existing implementations are free to preserve such a stereotype if it is useful to their implementation, but this special stereotype would no longer be required by the specification. Revised Text: In Table 10.2, replace the Metamodel Reference column for the row ConstraintProperty with “UML4SysML::Property typed by SysML::ConstraintBlocks::ConstraintBlock”. In Section 10.3.1.2 Parametric Diagram, in the paragraph under the subsection “«constraint» keyword notation for constraint property”, delete the last sentence of the paragraph.Move the paragraph which currently appears under the Description section of 10.3.2.2 ConstraintProperty to the end of the Description section of 10.3.2.1 ConstraintBlock. Delete the entire contents of Section 10.3.2.2 ConstraintProperty. Disposition: Deferred
10.3.1.2 Parametric Diagram: clarify applicability of square box notation to constraint parameters (or otherwise) SysML1.0, 10.3.1.2 Parametric Diagram: 'Small square box notation for an internal property A value property may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a value property may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of property boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where an internal property box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the innermost property.' It is not clear whether 'value property' here is meant to refer to a constraint parameter. Also, the term 'internal property' does not exclude, for example, nested constraints, leaving open the possibility of drawing nested constraint properties using square box notation, which is surely not intended. The following suggests that only constraint parameters - not value properties - are intended: SysML1.0, , 10.3.2.1 ConstraintBlock: '[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, binding connectors between its internally nested constraint parameters, constraint expressions that define an interpretation for the constraint block, and general-purpose model management and crosscutting elements.' Rewrite SysML1.0, 10.3.1.2 Parametric Diagram, replacing all references to 'value property' and 'internal property' with 'constraint parameter': 'Small square box notation for a constraint parameter A constraint parameter may optionally be shown by a small square box, with the name and other specifications appearing in a text string close to the square box. The text string for such a constraint parameter may include all the elements that could ordinarily be used to declare the property in a compartment of a block, including an optional default value. The box may optionally be shown with one edge flush with the boundary of a containing property. Placement of constraint parameter boxes is purely for notational convenience, for example to enable simpler connection from the outside, and has no semantic significance. If a connector is drawn to a region where a constraint parameter box is shown flush with the boundary of a containing property, the connector is always assumed to connect to the constraint parameter.'
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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 {rate=constant} and {rate=distribution}. Resolution: change Table11.1 and Table 11.2 to show dedicated examples of «discrete» and «continuous» stereotype usage.
The tables show all the notations at once on the element they apply to, for example, one shows "rate = constant" and "rate = distribution" on the same object node. The tables would get very large if all the cases were shown separately. Disposition: Closed, no change
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.)
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
It is typical to show just the name of the behavior being called, because the distinction between action name and called behavior is more the advanced user. Disposition: Closed, no change
Figure11.10 suggest use anonymous, typed Pins for clear indication of flowing information type and to support {stream} Parameter t is difficult and/or inconsistent to show the {stream} 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 {stream} 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.
Eliding pins is a UML presentation option, see UML specification, Object Flow, Presentation Option. Showing this option would make the graphical tables unnecessarily large. Disposition: Closed, no change
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
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.
The object node notation is captured at M1 as instances of InputPin and OutputPin, rather than sObject Node. The disadvantages of the object node notation should be compared to its advantages, for example, being more compact. SysML should not demote the object node notation. Disposition: Closed, no change
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")'
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.
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'.
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.'
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.
B.4.8.3 Activity Diagram (EFFBD): refers to allocations to parts instead of blocks 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. It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.' In fact the AllocateActivityPartitions in Figure B.35 represent blocks, not part Properties typed by blocks.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
Figure B.10: justify/clarify 'StartVehicle' from outside in terms of UML Please clarify how UML4SysML supports the drawing of a 'StartVehicle' message from the boundary of a ref Interaction.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
Figure B.9: clarify turnIgnitionToStart message on driver:Driver Is it supposed to be a message to self ? If so please include message to self path, otherwise explain,
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
Figure B.27: <<view>> Package "steals ownership" of MOEs, Actor, UseCase and Requirement Severity Critical since there is currently no sensible way to implement <<view>> in tools ! In Figure B.27 - Establishing a Performance View of the User Model It is not at all clear how the MOEs, Actor, UseCase and requirement should be shown as directly within the view without the view package "stealing ownership". Appears to break constraint: '7.3.2.4 View [1] A view can only own element import, package import, comment, and constraint elements.' See also example images in Magicdraw UML SysML Plugin at: http://school.nomagicasia.com/node/127 http://school.nomagicasia.com/files/images/Figure%20B.27%20-%20Establishing%20a%20Performance%20View%20of%20the%20User%20Model.png Note that this relates to:: Issue 11500: <<view>> as Package extension is very bad idea (sysml-rtf), No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com) '<<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)'
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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'.
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.
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'.
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'.
Figure B.35: prefer <<continuous>> pins over contrived placement of ObjectNodes on border of swimlanes Placement of ObjectNodes on boundaries of swimlanes is contrived and graphically unstable. Prefer typed output/input Pin pairs on CallBehaviorActions corresponding to Parameters. TODO: alternative diagram with pins for resolution. See also: http://school.nomagicasia.com/node/138 http://school.nomagicasia.com/files/images/Figure%20B.35%20-%20Detailed%20Behavior%20Model%20for%20Provide%20Power%20(with%20Swimlane%20Allocation).png
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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)
Figure B.38: property names of p:[PowerSubsystem] inconsistent w.r.t. other figures Figure B.38 gives p:[PowerSubsystem] with parts: em: [ElectricMotor] t: [Transmission] ice: [InternalCombustionEngine] Figure 9.3 shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 9.6 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine (ecu:PowerControlUnit) (epc: ElectricalPowerController) Figure 15.10 IBD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine emg:ElectricalMotorGenerator (ecu:PowerControlUnit) (epc: ElectricalPowerController) (can:CAN_Bus) Figure B.18 BDD shows PowerSubsystem with parts: trsm: Transmission ice: InternalCombustionEngine em: ElectricalMotorGenerator pcu:PowerControlUnit (epc: ElectricalPowerController) .. For consistency Figure B.38 should show p:[PowerSubsystem] with parts: emg: [ElectricMotor] (not 'em') trsm: [Transmission] (not 't') ice: [InternalCombustionEngine] Also, Figure B.18 should show PowerSubsystem with part: ecu:PowerControlUnit Visit also analysis at: http://school.nomagicasia.com/node/149
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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.
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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.
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.
In Figure B.29 'delta-t' is shown with solid-line (AggregationKind 'composite'), it should be shown with a dashed line (AggregationKind 'none') to be consistent with Figure B.26 BDD for EconomyContext.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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.
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).
Much useful discussion about underlying concepts of system quantities and how they can be fully typed with units of measure and related concepts has occurred within the RTF. A variety of authoritative sources and comparison with practice by other communities including the related OMG MARTE profile have also contributed much to the discussion. The scope of any potential new model, however, has ended up beyond the workload that could be completed during this RTF. While much of the discussion has indicated a need for refinement or elaboration beyond the current Unit and DImension model of SysML, these initial elements of SysML 1.0 do provide an initial capability for SysML models. Issues 12128 and 12219 are both being deferred so that they can continue to be considered for future revisions of SysML. Disposition: Deferred
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.
Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Discussion of this issue was still in progress at the end of the current RTF. The issue is being deferred so the discussion can continue under any future revision process. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
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
A Behavior element to formalize the elements in a view would apply the behavior in a metamodeling role unrelated to its use to express behavior in a user model. It would also require establishing a whole new set of metaclass behaviors not currently defined in UML. This level of formalization on methods and languages should be considered within the wider set of UML modeling specifications, not uniquely by SysML. Disposition: Closed, no change
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].
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.
The generalization of model elements, e.g. blocks, does only affect the instances (from Generalization definition: Each instance of the specific classifier is also an indirect instance of the general classifier.). Doesn't that mean that stereotypes of a block and it's properties are not inherited by sub-blocks? If yes all informations about flow ports, units and so on get lost. They are not inherited by the sub-blocks.
There is still a need to cover additional cases in which stereotype applications on SysML blocks, properties, and other model elements should be inherited, but no proposed resolution on this issue was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
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).
Having the arrows point out or in is definitely solvable by tools and there is no technical difficulty. The notation was accepted during SysML submission and was implemented by the tools. There is no reason to change it as the tools definitely can handle maintaining the correct direction when moving the port. Disposition: Closed, no change
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.
User-defined stereotypes are fully supported in SysML. Chapter 17 includes the UML-based mechanisms for users to define their own profiles. These profiles can define further stereotypes of the metaclasses and stereotypes already defined by SysML. Profiles allow the general-purpose elements of SysML to be further customized to support specific classes of modeling needs. Examples of such user stereotypes are included in SysML usage examples to illustrate various ways such user extensions can be applied. Reusable stereotypes can also be established for sharing across or within organizations. Annex C of the SysML specification gives examples of stereotypes which are not defined as part of the SysML language itself, but which can help meet such shared modeling needs. Disposition: Closed, no change
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.
Disposition: See issue 12257 for disposition
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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?
These clarifications require modification in the text on a one by one basis.
Specifically about the questions asked:
1. A Block should not realize a Flow Specification. As mentioned in section 9.3.2.5, flow specification is used by flow ports to specify what items can flow via the port. It is unclear if it is legal to add a constraint about Block (not being able to realize a FlowSpecification) in the section that deals with FlowSpecification. We can consider making it more explicit in the text ("Flow Specification are intended to be used as types for flow ports and not in any other relationships")
2. Typing a FlowPort by a Block means it relays an instance of the Block - it is an atomic flow port. This is explained in an explicit way in the Flow Port section.
3. It is not allowed to use Flow Specification for anything other than to type Flow Ports.
4. It is not possible to type a Flow Port by more than a single Flow Specification. We can add that as a constraint if necessary but it is unclear that this is necessary since we don't mention that an atomic flow port cannot be typed by more than one block or data type.
As mentioned above, we can consider revising the text to clarify but for now such changes are more than can be considered.
Disposition: Deferred Discussion:
This issue is deferred because no other proposed resolution was voted on during
the schedule of the SysML 1.2 RTF.
Following is the discussion from a previous deferred resolution by the SysML 1.1
RTF:
These clarifications require modification in the text on a one by one basis.
Specifically about the questions asked:
1. A Block should not realize a Flow Specification. As mentioned in
section 9.3.2.5, flow specification is used by flow ports to specify
what items can flow via the port. It is unclear if it is legal to add a
constraint about Block (not being able to realize a
FlowSpecification) in the section that deals with FlowSpecification.
We can consider making it more explicit in the text (“Flow
Specification are intended to be used as types for flow ports and
not in any other relationships”)
2. Typing a FlowPort by a Block means it relays an instance of the
Block – it is an atomic flow port. This is explained in an explicit way
in the Flow Port section.
3. It is not allowed to use Flow Specification for anything other than to
type Flow Ports.
4. It is not possible to type a Flow Port by more than a single Flow
Specification. We can add that as a constraint if necessary but it is
unclear that this is necessary since we don’t mention that an atomic
flow port cannot be typed by more than one block or data type. As mentioned above, we can consider revising the text to clarify but for
now such changes are more than can be considered.
Disposition: Deferred
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.
See proposed resolution for Issue 12126 for a replacement of this constraint as a result of cleanup of SysML property classifications. The original intent of the constraint was to disallow value properties from having composite or shared aggregation. The new constraint states this intent much more directly, but also changes the constraint on a value property to require composite aggregation, so that the solid-square-box notation of a value property on an internal block diagram is consistent with its aggregation. Because SysML is in some respects a significantly different language than UML, preservation of software hints for models that move from to SysML to UML and back is not likely to be fully successful without further model mapping support. Definition of mappings from SysML to UML, beyond the subset of UML which SysML reuses directly, is not currently addressed by SysML. 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.
Much discussion occurred within the RTF on the possible roles of instance specifications and/or additional value compartments to show property values within blocks as they evolve during the lifetime of a system. As noted, such display could be useful for animation of a system, or to show particular valid states of blocks and all their properties. Another issue, 12353, suggests additional forms of property compartments as another mechanism to display such values. Both issues are being deferred and could be considered separately or together for future updates of SysML. For the current RTF, the scope of support for property-specific values considered useful as a feasible scope and important initial step is better support for the "defaultValue" compartment as addressed in the resolution for Issue 10473. This resolution renames the compartment to "initialValues" and specifies a metamodel that does not require use of property-specific types. Disposition: Deferred
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.
Much discussion occurred within the RTF on the possible roles of instance specifications and/or additional value compartments to show property values within blocks as they evolve during the lifetime of a system. As noted, such display could be useful for animation of a system, or to show particular valid states of blocks and all their properties. Another issue, 12277, suggests UML instance specifications as another mechanism to display such values. Both issues are being deferred and could be considered separately or together for future updates of SysML. For the current RTF, the scope of support for property-specific values considered useful as a feasible scope and important initial step is better support for the "defaultValue" compartment as addressed in the resolution for Issue 10473. This resolution renames the compartment to "initialValues" and specifies a metamodel that does not require use of property-specific types. Disposition: Deferred Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Following is the discussion from a previous deferred resolution by the SysML 1.1 RTF: Much discussion occurred within the RTF on the possible roles of instance specifications and/or additional value compartments to show property values within blocks as they evolve during the lifetime of a system. As noted, such display could be useful for animation of a system, or to show particular valid states of blocks and all their properties. Another issue, 12277, suggests UML instance specifications as another mechanism to display such values. Both issues are being deferred and could be considered separately or together for future updates of SysML. For the current RTF, the scope of support for property-specific values considered useful as a feasible scope and important initial step is better support for the “defaultValue” compartment as addressed in the resolution for Issue 10473. This resolution renames the compartment to “initialValues” and specifies a metamodel that does not require use of property-specific types. Disposition: Deferred
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.
Disposition: See issue 10473 for disposition
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
Disposition: See issue 10473 for disposition
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'.
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).
Previous submission had incorrect reference to ValueProperty of a structured ValueType, should only say Property. Corrected below. --- On p.46, under 8.3.2.4 DistributedProperty it is stated that: '[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.' There are however, as far as I can tell, no examples of a DistributedProperty or specialisation thereof applied to a property that is not within a block. A candidate example might include a variation on a Complex <<ValueType>> (cf. Figure 8.7 - Model Library for Blocks) with distributions applied to the real and imaginary parts (being represented by properties, and thus admitting application of the DistributedProperty stereotype, or substereotype). ------------------------------------------------------------- <<ValueType>> StrangeDistributedComplex ------------------------------------------------------------- <<Uniform>> {min=-10, max=10} realPart : Real <<Uniform>> {min=-12, max=12} imagPart : ImagFigureB34 shows an Activity decomposition with: * an <<activity>> ControlElectricPower owning part Property 'elecDrivePower:ElecPower'. * an <<activity>> ProvideElectricPower without any owned part Properties. FigureB35 shows: * an Action 'a3:ControlElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> driveCurrent' * an Action 'a4:ProvideElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> elecDrivPower' The translation of ObjectFlows in FigureB35 to part Properties in the Activity decomposition FigureB34 is thus inconsistent.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
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..*].
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
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
The href should reference the URI for the UML elements. This may need the namespace for UML4SysML to match that of UML
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
The XMI is missing the tags for declaring the namespace and prefix for serializing instances of the stereotypes
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
The semantics of composition between activities refers to synchronous calls. What happens if the activity is called asynchronously? Is it possible to show that activity in the bdd, too? What is the relationship to the calling activity?
Output pin of a control operator is not a control pin as shown in fig. 11.10. It should be a regular pin typed by ControlValue.
16.3.2.3: (2) /derived: Requirement [0..1] Derived from all requirements that are the client of a «deriveReqt» relationship for which this requirement is a supplier. I don't think we can write OCL to derive this value, at least not without knowledge of the population of Requirements in which this instance is situated. How would we navigate from this object, a Requirement, to that population? I note that the version of the profile XMI I am using doesn't declare this property as derived. It appears that at least one SysML tool provider didn't derive it, but maintains it in their tool and XMI. I think something like the above criticism can be leveled against all of the attributes /satisfiedBy, /verifiedBy, /tracedTo, /derived, /derivedFrom, /refinedBy, /master that are declared derived in the spec 08-05-16. Perhaps we ought to remove the '/' and use a word other than "derived" in describing these attributes. Likewise 16.3.2.4 RequirementRelated attributes should not be declared derived. It may be the case that the OMG needs to be clearer regarding what it means by "derived." There are attributes whose *definition* can be expressed in OCL and there are attributes whose value can only be found by some (perhaps vaguely specified) analysis of the Model (if Model is the correct context!). The latter notion is, I think, what you intend throughout Clause 16. That's fine, except I don't think the attributes for which this notion applies should be annotated with the slash. Further, it may be useful to identify what population is being considered when using terms like "all requirements."
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
I'm just experimenting with the parametric diagram and detected a problem. I'm not sure if it is a SysML problem or if I am the problem. A block A has a composition relationship to a constraint block with multiplicity * and property name cstr. I like to use the constraint property cstr in a parametric diagram of block A multiple times. That doesn't work, because the constraint property occurs only once in the diagram. I don't like to define a constraint property for every usage of the constraint in the parametric diagram, because it's not two or three times, but really many many times I want to use the constraint. I think of something like the selector in sequence diagrams, i.e. the name of the constraint property in the parametric diagram is cstr[1] : MyConstraintBlock, cstr[2] : MyConstraintBlock, and so on. What do you think? Am I completely wrong?
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Constraint [2] says: [2]An “in” FlowProperty value cannot be modified by its owning block. What is the owning block of the flow property? The flow property is owned by the flow specification which is a type of a flow port which is owned by a block. Is this block the "owning block"? Why is the owning block not allowed to change a in flow property? Shouldn't that be defined by the readOnly property instead of the direction?
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
SysML: Align SysML Activities with Foundational UML
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
SysML: Activity Properties should be accessible in Activity diagrams for decision making
This will be addressed by examples for ReadSelfAction in a future UML. ReadSelf action has no inputs and one output. When used in an activity that is not owned by a class, it returns an object representing the execution of the activity that started the action. This object can be given as input to the actions that access property values. Disposition: Deferred
SysM:L: Operations on Activities need to be callable (e.g., start, restart, cancel)
This will be addressed by examples for ReadSelfAction in a future UML. ReadSelf action has no inputs and one output. When used in an activity that is not owned by a class, it returns an object representing the execution of the activity that started the action. This object can be given as the target input to CallOperationAction. Disposition: Deferred
Issue: Ability to capture performance properties of activities and bind to parameters in parametrics. Discussion. Need to clarify that performance properties of activities and other behaviors, such as the time, reliability, and accuracy associated with performing an activity, can be captured as part of the definition and use of an activity or the types of its object nodes in a way similar to value properties of blocks. Further clarification should be provided that these properties can be bound to parameters in parametric diagrams to support performance analysis. Activities (and other behaviors) can be captured on a bdd as shown in Figures 11.1, 11.5, 11-13 and 11-14. In section 11.3.1.1 and 11.3.1.4, the interpretation of activities and object nodes on bdd's is defined, and in section 11.3.1.4. Proposed resolution: Additional clarification should be provided in the above sections, that properties of activities and other behaviors can also be represented on their definitions on a bdd, and that the value properties are like any other value property, enabling them to be bound to parameters in parametric diagrams.
Issue: SysML support for Foundational UML to support execution of activities Discussion. Need to include the foundational subset of UML in the UML4SysML to support activity execution. This includes constructs suchas structured activity nodes in complete structured activities, which is a capability that is a useful addittion to SysML. Proposed Resolution. Update Figure 4.2 and Table 4.1 to included structured activities, extra structured activities and complete structured activities along with any other packages in UML4SysML needed to support the Foundational UML Subset. In addtion, update the diagram elements in Tables 11.1-11.3 to reflect the additional activity constructs including the structured activity node.
Issue: Inability to name interruptible activity regions. Discussion. Interruptible regions are useful constructs in SysML to enable termination of activity nodes. This is useful in a variety of cases, such as when one wants to terminate actions with streaming and continuous flows. In more complex behaviors with multiple interruptible regions, it is desired to be able to identify these regions by name. This may be useful when defining the owned behavior of a block with an activity that has multiple interruptible regions that represnt behavior in a similar way to state machines, where an accept event action may cause the behavior of the block to transition to another interruptible region of its behavior. Proposed resolution: An interruptible region in UML and SysML is currently an activity group which subclasses element. Create a stereotype of interruptible region called name interruptible region that subclasses Named Element (a similar approach is applied to activity partitions in UML
Information for facilitating the partner integration within the specification and requirements definition process (requirements interchange) are missing (e.g. meta information like version, access rights). Remark: There is a specification already addressing this topic, the Requirements Interchange Format (RIF). It is available for download as ProSTEP iViP Recommendation PSI 6 at www.prostep.org. This specification was introduced to the SE DSIG by Rupert Wiebel from HOOD (a paper is available) and presented by Dr. Steven Vettermann from ProSTEP iViP and discussed at the ManTIS meeting on December 11th.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Port Decomposition of a Flow Specification Discussion. There has been continued need to be able to decompose ports. One approach is to decompose a flow specification. In order to more readily accomplish this, a flow specification steretoype should subclass block instead of extending interface. This would enable many of the block constructs to be used, such as nested connector ends, the dot notation, and other features. A nested connector ends would allow direct connections to the flow properties of flow specifications. Dot notation could be applied to refer to the flow properties. In addition, to enable further levels of decomposition, a flow property should be able to be typed by a Flow Specification. The notation should also be clarified to allow for flow ports typed by flow specifications to show the port with the nested flow properties, and futher levels of nesting as required. As an additional comment, a connector to the port that is typed by the flow specification can be allocated to sub connectors that connect directly to the flow properties to support the concept of connector decomposition. Recommendation. 1. Modify Figure 9.1 to show the Flow Specification stereotype subclassing block rather than extending Interface. 2. Modify Flow Property in 9.3.2.4 to allow it to also be typed by a Flow Specification. This should be reflected in the Description and Constraint 1. 3. Modify Flow Specification in 9.3.2.5 to note that Flow Specifications can be decomposed (not sure this is necessary, but it might be good to clarify). 4. Modify the text for the diagram extension to flow port in 9.3.1.1 to describe that a flow port that is typed by a flow specification can be notated with the port symbol that nests the flow properties. Also note that a connector can connect directly to these flow properties using nested connector ends, and that the dot notation can be applied to refer to the flow properties. Finally, note that flow properties can be nested more than one level.
Discussion: Extensive discussion on proposed extensions to support decomposition of flow ports occurred within the RTF, and was still occurring at the time of the final ballot. The issue is being deferred to allow further consideration in future revisions of SysML. The email archive of the RTF discussion list contains an extensive record of issues, concerns, and alternative proposals for possible ways in which the requested capability could be provided. Following is the complete text of the two most recently proposed resolutions, which are being included here for future reference: First proposed resolution: Resolution: This proposal is intended to enable SysML to support decomposition of Flow Ports. A simple example can be derived from the water delivery example in Figure 8.12 by adding Flow Ports to the example. In this case, the hot and cold water are sent from a water supply to a faucet and associated water client. A single Flow Port on both the water supply side and the client side can support the flow of water between the supplier and client. However, it is desired to decompose these Flow Ports into a hot port and a cold port. The current specification does not support this type of Flow Port decomposition explicitly. As part of this proposal, it became evident that there is a need to clarify the distinction between a port as an interaction point (or a connection point); from the flow properties which specify what can be relayed through the interaction point. The flow property can represent a complex data structure such as the physical encoding of logical information, as well as other physical flows. For non-atomic Flow Ports, the distinction between the port as an interaction point and the item that can be relayed is clear. The Flow Port is the interaction point, which is typed by a Flow Specification that contains flow properties that can be relayed through this interaction point. In the case of atomic Flow Ports, this distinction is not as clear. In particular, an atomic Flow Port is a mechanism which does not require definition of a Flow Specification that contains a single flow property. In this case, the port is typed by the item that is relayed. In other words, the port represents both the interaction point and the flow property. This proposal provides some wording to clarify the distinction between the interaction point and the item that can be relayed. With this clarification, decomposing a Flow Port requires the Flow Specification to contain other Flow Ports. Nested Flow Ports that are non atomic can support further nesting of the ports. In order to support the decomposition of Flow Ports, it is also assumed that the connectors that bind these Flow Ports can be decomposed in a consistent manner. The approach used is to leverage the association blocks referred to in 8.3.2.7 and illustrated in the example in Section 8.4.4. A connector that connects Flow Ports typed by Flow Specifications that contain nested Flow Ports can be further decomposed using this approach. The connector is typed by an association block that references the Flow Specifications on either end of the connector, using its participant properties. Item flows that can convey items across the connector must also be consistent with the Flow Port and connector decomposition. To accomplish this, an item property can be displayed on the un-decomposed connector, but refers to the item property on the decomposed connector using the dot notation. The dot notation enables a navigation mechanism from the top level connector down through the association blocks to the item property on the leaf level connector. Compatibility rules must be established to ensure consistency between the item properties, flow properties, and the parameters corresponding to the inputs and outputs of the behavior of the block that contains the Flow Ports. Default compatibility rules are specified, but additional constraints can be imposed as needed. The following is a summary of the proposed changes: 1. Flow Ports decomposition is supported by allowing Flow Specification to own Flow Ports and flow properties. A Flow Port owned by a Flow Specification is a sub-port of the Flow Port typed by the Flow Specification. This sub-port can be either atomic or non-atomic. 2. We clarify the difference between flow property and a Flow Port: a flow property represents an item relayed via a Flow Port while a Flow Port (atomic and non-atomic) is a connection point of its owning block through which items can be relayed either to its properties or to its behavior. An atomic Flow Port is a convenience so users won't need to define a Flow Specification for Flow Ports that relay only one item – it implicitly represents both the interaction point and the item that can be relayed. Flow properties cannot be connected by connectors. 3. We define how to decompose connectors between non-atomic Flow Ports using an IBD that has an association block with participant properties typed by the Flow Specifications that type the ports at either end of the connector. The connectors within the association block show how the sub-ports owned by the Flow Specifications are connected. 4. We define how to resolve ambiguities when connecting Flow Ports typed by different Flow Specifications with flow properties on each side that cannot be matched by the default rules (name and type). One way to resolve such an ambiguity is by specifying a constraint on the connector connecting the two Flow Ports which specifies the mapping. 5. To complete the support of Flow Port and connector decomposition we define a dot notation for item flows that are defined on subconnectors so they can also be viewed at the composite (i.e. undecomposed) connector level
In order to begin to more fully leverage SysML, it must be integrated with various execution languages. Modelica is a highly expressive execution language to support physics based analysis and simulation, which has been standardized through the Modelica Association. Initial feasibility indicates a high degree of compatibility between SysML and Modelica. A standard mapping between SysML and Modelica is needed to enable this capability. In addition, it is expected that some refinement/extensions of SysML may be required to more fully integrate with Modelica. Recommendation: Perform an initial mapping between SysML and Modelica. Identify any refinements/extensions to SysML to support the mapping. Prepare a non-normative annex to the SysML specification that captures this mapping.
Issue: Ambigous line crossings Discussion: When two lines cross, there can be ambiguity associated with the line path. This applies to any line including flows, associations, and connectors and other relationships represented by edges. A solution to remove ambiguity that is used in various schematic diagrams to address the same issue is to add include a curve in the lline path at the intersection. Proposed Resolution: In the Diagram Appendix on pgs 175-176, and a diagram guideline to include the curve to a crossing line path to avoid ambiguity. Consider making this a normative requirement. This will require an additional clarification statement for the Non Normative annexes.
Issue: SysML synchronization with UML/XMI version updates Discussion: Since SysML was originally published, both UML and XMI specifications have been updated. It is important to maintain synchronization between SysML and these specifications since SysML leverages both of them. Proposed Resolution: Update Section 2 to reflect the current version of UML and XMI. An assessment of the changes to UML and XMI should be made, and a determination of the impact on the SysML specification. The SysML specification should be updated accordingly.
Issue: Representation of nested object nodes in activity diagrams. Discussion: It is desirable to be able to represnt nesting of object nodes on activity diagrams to reflect one or more levels of nested properties of the classifier that types the object node. For example, if water is shown as an object node, and it is desired to refer to the temperature of water, then it should be possible to reflect this property on the activity diagram using the notations that are used on ibd's. In particular, one may want to use either a nested rectangle to represent the property, or the dot notation. Proposed update. In the diagram extensions for activity diagrams in Section 11.3.1.4, add a clarifying statement that nested properties of the classifier that types an object node can be represented on activity diagrams either using the nested rectangle notation or the dot notation similar to the use of nesting on ibd's and parametric diagrams.
Following is the discussion from a previous deferred resolution by the SysML 1.2 RTF: Filer’s elaboration: Intent is to be able to represent object nodes on activity diagrams with nested properties using either the nested notation or dot notation. An example where this would be useful is to model the manufacturing process as a series of assembly steps for an assembly such as an engine. Assume any given action represents a step in the process where a partially assembled engine is input along with another input part such as a cylinder. The output is a partially assembled engine with the cylinder included. I would like to highlight the output object node as the engine with the cylinder part nested in the engine. The intent would be to use the "create" parameter effect (refer to ParameterEffectKind in UML superstructure 12.3.4.1, .2 which shows the ParameterEffectKind as create, read, update, delete or the SysML equivalent of create, not modify, modify, destroy). In the engine assembly process, the effect kind would be create indicating the creation of the new engine assembly with the cylinder included. SysML 1.3 RTF Disposition: Deferred OMG Issue No: 13197 Document ptc/2011-08-08 Page 180 The addition of class notation to an activity would not specify that the output engine has the cylinder, this could only be done by postconditions on the assembly action/subactivity. It would also be a significant change to introduce class notations onto the activity diagrams, requiring changes in vendor implementations. The proposed modification doesn't address the use case and would require significant changes in implementation. The issue is deferred for further discussion of other solutions. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
There is currently limited ability to capture datasets for selected property values. A simple example is the difficulty in capturing the time histories for the position, velocity, and acceleration properties for two different instances of a vehicle, where the vehicle is a block, and the position, velocity, and acceleration are value properties of vehicle. Another example is the need to capture data such as environmental loads data (e.g. temperature, vibration as a function of freq) which is referenced as part of a requirement.
Proposed resolution: Consider creating a stereotype called a Dataset that enables a user to specify a set of properties and their values as a function of time or other property. The data values can be derived from parametrics or a behavior execution, or pre-specified. The dataset should support data arrays, matrices, etc.
SysML requirements are now pure text and not completely integrated in to the model-centric approach Currenltly requirements are written as The top speed of this car shall be greater than 100 mph. Instead, it should be written as The top speed of this car shall be greater than <x>. And there be a compartment of the requirement where the current value of <x> is given <x> = 200mph. This <x> should be integrated as a design value throughout SysmL and should be connectable to parmetrics. It should also support dependencies so that other requirements value's (and block's features) can be dependent on the value of <x>. Then I can determine all the places in my system where there is a dependency on <x> and my equations and constraints are automatically updated. Which in many cases would allow me to automatically rerun my simulations. This is an improvement in integrating the model. Currently, with pure text requirements constants in the requirements are often repeated in equations, parametrics, constraints, algorithms. This repeating defeats some of the advantages of model-approach, as they are identical or related elements that need to be synchronized by hand.
Following is the discussion from a previous deferred resolution by the SysML 1.2 RTF: SysML 1.3 RTF Disposition: Deferred OMG Issue No: 13259 Document ptc/2011-08-08 Page 183 Methods to capture values of requirements properties within a model, and to allow other parts of a model to depend on these values, are still being explored. The issue is being deferred to continue consideration of various options. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Though we recently changed SysML to allow depletable stores, there appears to be some open issues about what they are and how to handle them with Parametrics properly. Is the name of the depleteable store that property of the owning block whose values change? (and can be used in Parametrics) Or does the depleteable store have a property (perhaps with a standard name) that is the changing value. Is the depleteable store a variable property or a part with a variable property?
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Binding relationships are used between model element properties and parameter in the constraint blocks, similarly they are used between constraint blocks.
These constraint blocks are intended to be reusable.
However connecting constraint blocks from different sources does not usually work unless the units are the same. Model element values may also not be using tehehe same units.
A reasonable solution is to indicate the scaling factor on the binding relationship. This could be done in several ways. One way would be to indicate a simple assignment equations between the two parameter names.
Currently
x----------------------------------Y
Proposed
Y=100*x
x-----------------------------------------Y
Instead of using a constant 100, we could used a named constant such as cmPm
If both ends of the binding relationship were identically named, we need to add an arrow to indicate the souce and target sidel
ŕ
X=cmPM*X
X-----------------------------------------X
This would indicate that the left side X must be multipled by the cmPm to give the left side x
This approach allows us to handle more complex conversions by including the ability to add/sub constants
C=5/9*(F-32)
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
There is a non-normative diagram indicating a hierarchy of SysML diagram types. In this diagram we follow the UML convention of treating Use Cases as behavioral diagrams. The exact reason for this is unclear, and appears to be tied up with collaborations. However, in SysML system engineers (and many s/w eng in UML) treat use cases as a way of capturing goals, capabilities, purposes, and as a technique to organize (and find) requirements. In this way, it is more understandable to the typical SysML user to treat both Use case Diagrams and Requirements Diagrams as belonging to the same category. I have verified this by teaching SysML to students both ways – and the common UCD/REQ approach is thought to be more understandable. One approach would be to consider the new category Requirement Diagrams, and Use Case and Text-base Requirements as the individual requirements. Another would be to make a new category of Specification Diagrams and use Use Case and Requirements as the individual types.
One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams BDD (for Blocks) ŕ IBDs BDD (for Activities) ŕ ACTs BDD (for Constraint Blocks) ŕ PARs The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form. It would be convenient and symmetric to support a similar diagram ppar for State Machnies BDD(for States) ŕSTMs In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Certain activity constructs were left out of UML4SysML to reduce complexitiy of the language, butBased on usage of activity diagrams, some of these constructs are now viewed as useful. One example is structured activity nodes. Others include the parameter affect. Proposed Resolution: Update Fig 4.2 andd Table 4.1 to include additional packages in UML4SysML that support the useful constructs such as structured activity node which is included in "CompleteStructuredActivities". Also, update the diagram element tables in Table 11.1 to reflect these new constructs.
In Allocations, AllocateActivityPartition, Constraints, the second paragraph says the AllocateActivityPartition stereotype does nopt preserve the semantics of of UML 2 ActivityPartition, and that partitions with AllocateActivityPartition do not have responsibility for invoking the actions in them. I think there is no conflict with UML 2 semantics, because UML 2 ActivityPartition only requires performing the actions to be the responsibility of the element represented by the partiion, not the invoking of the action. This seems compatible with allocation.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Even though SysML ValueType includes all the capabilities of UML DataType, plus its own optional extensions, SysML currently both of these separately in its diagram elements and abstract syntax. This adds unnecessarily to the complexity of the specification (where both DataType and ValueType must be mentioned in multiple places) and to the language that the SysML user must learn. It's inconsistent with other renaming of UML elements by SysML, in which the neutral SysML term (e.g. Block) replaces the UML term (e.g. Class). Just as SysML Block replaces the UML term Class, there's no reason the SysML term ValueType can't replace the UML term DataType. Statement of OCL constraints and metamodel and diagram syntax specifications can be simplified as a result.
Parametrics provide a powerful capability for representing constraints on properties. However, they currently do not allow a modeler to specify or notate dependent and independent parameters on a usage of a constraint property. This will enable the modeler to better express the nature of the constraint in many usage situations. The recommendation is to stereotype constraint parameters so that they can be designated as in, out, or in-out if desired. They can also be left unspecified as they are in the current parametric diagram. Proposed Solution. Add a stereotype called constraint parameter that extends property, with a stereotype property that can be in, out, in-out, or unspecified. Consider including the desctiption in the diagram extension for the parametric diagram in 10.3.1.2, adding the stereotype in 10.3.2, the diagram elements in Table 10.2, and updating the usage example in Fig 10.3.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
"trigger[guard]\activity" should be "trigger[guard]/activity"
The outpin of the control operator in fig. 11.10 is a control pin. But pins of control operators must be normal pins. The action Monitor Traction has no input pin.
Participant Property constraint #6 not correct. In Blocks, UML Extensions, Stereotypes, Participant Property, remove constraint 6 (the one resrtricting the upper multiplicity of the end property). End properties of associations can have any multiplicity. See example in Figures 8.13 and 8.14, where the deliveredTo end of a participant property has multiplicity 1..*.
Connector Property value text. In Blocks, UML Extensions, Stereotypes, Connector Property, Description, first paragraph, last sentence, the current text implies all instances of association blocks will be values of the connector property. The value is actually the subset of those due to the connector. Suggestion: - remove "exactly those" - replace "that are instances" with "(instances)".
Allocations should not generate dependencies The Allocate stereotype extends the Abstraction UML meta-class, which is a Dependency. It is in contradiction with the following description (cf. p133: "This concept requires independent models if “function” (behavior) and “form” (structure)") If we refere to EIA-632 the logical solution that will be allocated to the physical solution only depends from upstream requirements. In some cases, one may have some (upstream) requirements to use a given implementation platform, but this cannot be considered generic and anyway the dependendcy is still on the requirement not directly on the platform. A logical solution makes abstraction of the implementation to focus on issues strictly related to the missions of the system. Then, by definition a logical solution is semantically dependent from the need and not from the implementation. In most times, several logical solutions are possible. Their are more or less effective against each of their requirements, that's why the design work includes tradeoff activities. Saying that a given logical solution is not convenient to be implemented on a given platform doesn't mean that it's not a logical solution to the need. More, the current stereotype implementation biases the impact analysis. The objective of this analysis is to parse the model and to report what model elements should be reviewed (i.e. are potentially impacted) in case of modification of a given model element to preserve the model integrity and consistency. If the platform is modified, what has first to be checked is whether or not the modified elements of the platform can still play the role they have been assigned by the allocation (with the required QoS, etc...). If the answer is "yes", then nothing to do. If the answer is "no", then they are several potential choices: a) if possible modify the allocations only, b) select another logical solution (i.e. modify it) and define the new allocations, b) select another platform and define the new allocations. This is matter of tradeoff. The only point that has always to be checked is the allocations. Then the only "thing" that actually depends on the "from" and "to" sides of an allocation is the allocation itself.
Extensive discussion on alternative elements for allocations that do not carry the impacts of dependencies has occurred within both the SysML 1.2 and 1.3 RTF's, SysML 1.3 RTF Disposition: Deferred OMG Issue No: 13840 Document ptc/2011-08-08 Page 191 often as part of alignment discussions with MARTE. Alternative elements for allocations is a potential priority for SysML 1.4. Disposition: Deferred
UML 2.2 defines a presentation option for stereotypes for comments. There is no need to repeat that option in SysML. There is no need for a tool vendor to support a UML presentation option to be compliant with the specification. Since SysML depends on the presentation option the chapter 7.3.1.1 should be updated to state that the presentation option is required.
Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity.
Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example.
Multiple proposals and extensive discussion on metamodel and/or diagram extensions to support a partition or grouping capability of elements occurred within both the SysML 1.2 and 1.3 RTF's. The issue is being deferred to allow further consideration in future revisions of SysML. The email archive of the RTF discussion list contains an extensive record of issues, concerns, and alternative proposals for possible ways in which the requested capability could be provided. The Deferred resolution of this issue in the SysML 1.2 RTF report also contains a proposal under consideration at that time. Disposition: Deferred
Parsing Text in Requirements: There is a need to parse the text string in a SysML requirement and create a reference from the parsed text to other model elements or perhaps to a URI. This will enable one to associated additional meaning to selected portions of the text string, such as a particular value, property name, function, or some other feature. A parsed text string which can refer to other elements could be generalized to support other uses within SysML where text is used. In this sense, the proposal could treat this in another chapter such as model elements to make it more generally applicable. One possible approach is to consider a net type called "ParsedText" that has some structure to it, so that the text can be parsed and a reference can be made from the parsed text. The Requirements text property would then be typed by ParsedText instead of String as it currently is.
Extensive discussion on this issue occurred during the 1.2 RTF, but not during the 1.3 RTF. The complete text of a proposed resolution from the 1.2 RTF discussions was included for future reference in a deferred resolution of this issue in the 1.2 RTF report. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Table 16.2 (top of pg. 146): Trace Dependency concrete syntax diagram incorrect. Replace <<requirement>> Client with Named Element (no stereotype). Figure 16.1 (top of pg. 148): Recommend adding Refine stereotype (as specialization of Trace stereotype); otherwise note that it comes directly from UML metaclass rather than as a UML extension. Recommend reordering specializations of trace in alphabetical order on UML class diagram (e.g., Copy, DeriveReq, [Refine], Satisfy, Verify). Section 16.3.2: Should reintroduce Refine relationship description and contraints, even though a UML metaclass and not an extension. It is an important relationship with respect to requirements. Perhaps introduce prior to Sect 16.3. Section 16.3.2.3 (middle of pg. 150): Change cardinality of /derived: Requirement attribute from [0..1] to [*]. Also, add right bracket to cardinality of /master: Requirement attribute. Currently shows as [0..1 with not closing right bracket.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Notation for multiple item flows. The UML specification provides a compact notation for multiple information items flowing in the same direction. A similar notation should be provided in SysML, but this is not explicitly called out. Recommendattion. Add a sentence at the end of section 9.3.1.4 which describes diagram extensions for item flows consistent with the UML approach that reads "When several item flows having the same direction are represented, only one triangle is shown, and the list of item flows, separated by a comma is presented." Also, include the multiple item flow notation in the Item Flow entry in Table 9.1.
Example figures in chapters are redundant with Annex B sample problem. This creates document maintenance issues. Figures 7.3, 8.11, 9.5, 9.6, 10.2, 10.3, 12.1, 12.2, 12.3, 13.1, 14.1, 14.2, 15.9, and 15.10 are all duplicated in Annex B. It is recommended that these diagrams are removed from chapters in part II and IV of the spec, and instead specifically reference the appropriate diagrams out of Annex B, thus making the specification easier to maintain.
Out of Date Annex D.4: The information in Annex D regarding AP233 needs to be updated. AP233 to be released as DIS and this section needs to be revised to reflect changes to AP233.
Representing multiple item flows on the same connector. The specification should clarify the notation for representing multiple item flows with the same direction on a connector. In particular, UML allows for multiple information items to be represented with a single triangle, along with the list of the information item names spearated by a comma (refer to Figure 17.6 of the Superstructure Spec). A similar notation should be provided to represent multiple items flows in SysML. Proposal resolution: Recommend adding the following sentence at the end of section 9.3.1.4. " When several item flows having the same direction are represented, one triangle can be shown, along with the list of item flows separated by a comma." Also, add a constraint to 9.3.1.4 as follows" 1. If the ItemFlow has an itemProperty, there must be one conveyed classifier which matches the type of the item property.
UML 2.1 added a new structural diagram type, Profile Diagram for the purposes of containing the profile-defining elements. SysML either should be made consistent or should explicitly indicate that the diagram is not part of SysML
The SysML specification does not define the correct namespace URI for the standard profile(s) - it should.
The UML rtf’s response to this issue was to add an “isConjugated:Boolean” to the Port definition. This renders superfluous the SysML addition of the conjugated flag on flow ports. The SysML flag needs to be removed. In addition, the notation has changed to use a ~
When one needs to reference a value of a specific property of part in a composition hierarchy in order to bind it to a constraint parameter, one uses the dot notation shown in section 8.3.1.2. (Example: a box labeled myCar.myEngine.currentTemp in a parametric diagram). When such a box is binded to a constraint parameter a nested connector end may be used to reference this property in the context of the composition hierarchy. However this poses a serious implementation issue for tools since until the box is binded it has no real model element behind it, also if one copies this box or the diagram to another hierarchy in the model then the tool has to complicated analysis. We propose to have a stereotype for reference nested property similar to nested connector end in which the path in the composition hirerchy is specified (i.e. propertyPath: Property [1..*] (ordered) - like in section 8.3.2.6). This will make it easier for tools to implement backed by the standard meta-model.
Extensive discussion occurred during the SysML 1.3 RTF on the opportunity to create a common, generalized form of contextualized reference path to address not only the applications raised by this issue, but to support nested properties as allocation ends, as constrained elements, to support context-specific initial values, for contextualized flow definitions, and to replace the current NestedConnectorEnd. Adopting a common form of reference path is a potential priority for the SysML 1.4 RTF. Disposition: Deferred
The compliance levels defined for UML 2.1.1 and UML 2.2 merge UML::CommonBehaviors::Communications at L1 instead of at L2 in SysML 1.1 as specified in table 5.2 (Metamodel packages added in Level 2). With UML::CommonBehaviors::Communications at L2, it is not possible to properly define UML::Actions::BasicActions at L1 because UML::Actions::BasicActions::SendSignalAction::signal : UML::CommonBehaviors::Communications::Signal [1] becomes ill-formed at L1. The UML::CommonBehaviors::Communications package is also absent from table 4.1 (Detail of UML Reuse) in SysML 1.1, clause 4.2 (Architecture).
Update clauses 4.2 (Architecture) and 5.1 (Compliance with UML subset) to reflect merging UML::CommonBehaviors::Communications at SysML's L1. It is not clear what is the purpose of Figure 4.2 as it shows a combination of L2 and L3 content from Table 5.2 and 5.3.
Flow port compatibility with behavior. Semantics of flow ports need to be clarified as they relate to behavior. In particular, need to clarify how flow properties are passed to behavior (classifier behavior, owned behavior) including to the parameters of operations and activities.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Summary: This issue is a complement to issue #12576 that deal only with the output pin. A control operator should have a regular input pin typed by ControlValue in fig. 11.10.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Overly restrictive statement regarding ports in blocks chapter. The following statement in section 8.3.2.2 in the Blocks Chapter is overly restrictive. "A port that is typed by a Block is a special case of a part property, as further defined in Chapter 9, Ports and Flows.". A port is a special class of property that can be typed by classifiers other than blocks. The recommendation is to generalize the wording as follows: A port is another category of property, as further defined in Chapter 9, Ports and Flows.
Ports use property type incorrectly. Atomic flow ports use the type of the port for the type of thing flowing. This doesn't fit common usage in engineering design, for example, a port that is a faucet through which water flows. The type of thing flowing isn't the type of the port, it should be associated to the ports by the stereotype. Non-atomic flow ports use the type of the port for an interface with properties specifying the type of things that flow. If the various types of things flowing are intended to flow at the same time, then flow specifications aren't needed. This can be done with an atomic port flowing objects supporting the interface. If the the various types of things flowing are meant to flow at different times, this is isn't UML semantics. This can be done either with 1) an atomic port flowing a supertype of the various types of things that flow 2) the association mentioned in in the first paragraph having multiple types, which the semantics defined to be union of the types.
The type in the allocation matrix must be action instead of activity.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Although explicitly stated that other designations may be used the list should contain at least <<action>>, <<operation>> and <<property>>. Allocation with actions and properties as related elements are shown in the examples in the specification.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Non-atomic flow ports use the type of the port for an interface with properties specifying the type of things that flow. If the various types of things flowing are intended to flow at the same time, then flow specifications aren't needed. This can be done with an atomic port flowing objects supporting the interface. If the the various types of things flowing are meant to flow at different times, this is isn't UML semantics, or at least is very unintuitive from an engineering point. This can be done either with 1) an atomic port flowing a supertype of the various types of things that flow 2) the association mentioned in in the first paragraph having multiple types, which the semantics defined to be union of the types.
There is ambiguity in the block hierarchy shown on a bdd for parts that are nested more than one level. By illustration, assume Block A is composed of Block B which is composed of Block C. If Block A has two compositions to Block B, called b1 and b2, and Block B has two compositions to Block C, called c1 and c2, one cannot determine from the bdd whether c1 is nested within b1 or b2. The ambiguity can be removed by displaying the nesting on an ibd or by specifying the path with the dot notation. The former resovles the ambiguity in the concrete syntax only. Neither of these approaches does resolves the ambiguity on the bdd, which needs to be resolved for complex system hierarchies.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
I'm trying to prepare requirements for "callout" notation changes in MagicDraw SysML diagrams and trying to remove tool-specific notation. The SysML spec says that each allocatedTo or allocatedFrom property will be expressed as «elementType» ElementName. It looks simple at a first glance, but later SysML spec is a total mess: "For uniformity, the «elementType» displayed for the /allocatedTo or /allocatedFrom properties should be from the following list, as applicable. Other «elementType» designations may be used, if none of the below apply. «activity», «objectFlow», «controlFlow», «objectNode» «block», «itemFlow», «connector», «port», «flowPort», «atomicFlowPort», «interface», «value» Note that the supplier or client may be an Element (e.g., Activity, Block), Property (e.g., Action, Part), Connector, or BehavioralFeature (e.g., Operation). For this reason, it is important to use fully qualified names when displaying / allocatedFrom and /allocatedTo properties. An example of a fully qualified name is the form (PackageName::ElementName.PropertyName). " So, looking at the predefined list it is clear that: For the Activity or other "clean" UML element it is an metaclass name in lowercase. for let's say ItemFlow or FlowPort is is an stereotype name in lowercase. That's ok. But what is <<atomicFlowPort>> ? Port with <<flowPort>> stereotype applied which has isAtomic=true. What is <<value>> ? Property which has Type with <<ValueType>> stereotype applied. In the example below (Figure 15.4) it has allocation of actions to parts and it uses another one <<elementType>> which is not described - <<part>>. What is <<part>> ? The Property with AggregationKind = composite? Also, full qualified names and <<elementTypes>> are used incorrectly in this Figure or I don't understand how it should be used. For example: <<block>> Block4.Part5 - why it is <<block>>, but not <<part>> ??? <<part>> Part2:Block1 - why part name is before block name? It should be displayed as (PackageName::ElementName.PropertyName) as described above. I believe, all these rules and exceptions should be described somewhere
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
System variants are often required to modify a system in order to satisfy evolving needs, and to support product lines with varying applications and environments. System variants have some components in common and some components that may be unique for each variant. SysML currently includes some capability to address variants, such as a property-specific type for specifying a variant usage of a component (i.e., block) in a local context, redefinition for redefining the type of the component, and generalization sets for specifying alternative components. However, what it lacks is a convenient mechanism and notation for describing variations that occur in deeply nested contexts within blocks. Issue System Variants Classical product configuration management evaluates whether the change to an assembly affects the next higher assembly in terms of its form, fit, or function. If there is no change to its form, fit, or function, the modification does not propagate up the hierarchy (Note: This should be confirmed). In order to ensure there is no adverse impact to the next higher assembly, one must establish criteria to evaluate the impact of the change on the next higher assembly, and then evaluate the impact of the change against the criteria. Figure 1 describes the baseline block hierarchy for a Vehicle; in the following paragraphs we will discuss how to address variants of this baseline system. Figure 1 - Definition of the baseline configuration for a vehicle In considering variance, one first checks to see if the change to a component affects the interface of the next higher level assembly. For example, in Figure 1, if the number of lugbolts is changed from 6 to 8, this could impact the interface to the braking disc. In addition, one must evaluate other potential impacts due to form, fit, and function. For example, if the weight of the bolt changes, the impact may propagate up the hierarchy to affect the overall vehicle weight. Or if the modified bolt has a lower stress rating, it may impact the safety of the vehicle. These impacts need to be understood to make a determination of whether the modification to the lugbolt impacts the next higher assemblies and the vehicle as a whole. If the change propagates up the system level, then each higher level of the assembly that is impacted must be subclassed (e.g., this may correspond to a new model number) to represent the variant assembly. Representing Variants using Block Definition Diagrams When a system variant results from changes in its components, the variant system model must include representations of the variations at each level of the system hierarchy from the system level down to the component level where the changes occur. The example in Figures 2 illustrates the SysML solution when a modification to a lugbolt results in a variant to the automobile at each level of the system hierarchy. In Figure 2, a change to the lug bolt (i.e. LugBolt A) propagates up the system hierarchy resulting in a variant to the wheel, to the chassis (or equivalent next assembly), and to the vehicle. The variant system hierarchy includes Vehicle A, Chassis A, Wheel A, and LugBolt A as subclasses of the baseline system elements. Figure 2 Varying all levels of the system hierarchy The following reference provides further information on a general approach to capturing variants: “Extended Generic Product Structure: An Information Model for Representing Product Families by Sean Callahan.” This short paper can be found at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_published.pdf and a longer version at http://129.187.108.94/dsm-conference/fileadmin/user_upload/downloads/2009/pdf/Callahan_GPS_extended.pdf. System Variants Using Property-Specific Types In Figure 2, 4 new types were introduced. If there is no impact to the form, fit, or function of the higher elements in the assembly, then modeling these intermediate assemblies using new types can be very cumbersome. There is a need for a more streamlined approach to capturing variations in deeply nested parts that do not affect intermediate level assemblies. At first glance, the property-specific type concept in SysML seems to fit the bill. As shown in Figure 3, using property-specific types, the replacement part is shown using dot notation on the IBD for Vehicle A, without the need for the user to explicitly represent Chassis A, etc. on the corresponding BDD. Figure 3 - Use of property-specific types to capture variants However, as can be seen, the redefinition clause in the part symbol does not give a clear indication of the location of the part being redefined, nor is there a notation on a BDD for showing this replacement part. Note: Figures were not able to be included with this posting but are available on the SysML v1.2 RTF Wiki
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
In parametrics, one cannot currently bind a constraint parameter in a constraint expression to a multiplity. For example, one may need to include the number of tires in the constraint expression that constraints braking force. However, if the model includes a Vehicle, composed of Tire with multiplicity 4, one must be able to access the number of tires (i.e. the multiplity) in the expression.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
Do parametric bindings observe derived and read-only constraints on properties? . In SysML if I bind a read-only property value to a parameter, I would expect that any evaluation of the parametric model would not be able to update the property value. If I wanted to have such a value calculated, I would expect to take off the read-only constraint Similarly, if I bind a derived property value to a parameter, I would expect that any evaluation of the parametric model would not use that value as an input, but only as an output. However, this is answered (and I hope it is answered positively), the SysML specification should clarify this behavior
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
SysML 2.2 B 7.3.2.5 Viewpoint A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint. Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads. A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. A viewpoint may reference another viewpoint to help in the specification. SysML 2.2 B 7.3.2.5 Viewpoint A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. How is this done? There are no examples. I see examples of a Viewpoint with a dependency on another Viewpoint, but no languages referencing languages in another viewpoint. Suggest either developing an example or deleting the sentence and adding another one after the next sentence, so it reads. A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. A viewpoint may reference another viewpoint to help in the specification.
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
The behavior port notation to support the isBehavior=true condition on a port is needed to more explicitly model parts that execute the behavior directly. Refer to Figure 9.17 of the UML Superstructure Specification (v2.3).
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
The property notation from UML to support redefinition and subsetting should be included in SysML explicitly. This notation is not currently included in the diagram element tables in the Blocks Chapter. Refer to property notation in Section 7.3.44 of the Superstructure Specification (v2.3).
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
There is a need to model a broader range of interfaces which extend beyond the current capability of standard ports and flow ports in SysML. One example is the physics based interfaces that are found in Modelica referred to as across and through variables. An example is in an electrical circuit where the interface can be defined in terms of the current and voltage parameters at each input and output node of a circuit. In Modelica, the interface between two components enables Kirchoffs Laws to be imposed on these interfaces such that the voltage on the on the connecting ports are equal, and the sum of the currents on the connecting ports sum to zero. SysML needs to be able to accommodate this type of interface more directly. One possible approach is to extend the concept of a Flow Specification to accommodate other types of properties, such as across and through variables, and not be limited to flow properties.
There is a need for a robust mechanism to constrain a system decomposition hierarchy to reflect only selected groupings of parts as motivated by the following example. In particular, assume a rack assembly is composed of a chassis and a set of circuit cards. The rack assembly is constrained by which cards can be inserted in which slots. This includes an optical card in an optical slot, an ethernet card in an ethernet slot and a general slot that can accommodate either an ethernet card or an optical card (source is Nathan Sowatskey example). In addition, a particular rack configuration may include a specific number of each type of slot and card. The need is to constrain the hierarchy to only allow these combinations parts. Generalization sets, redefinition, and other mechanisms can help, but require considerable modeling that is cumbersome. The desired capability is to be able to include a constraint in the rack assembly that constrains the allowable instances of the rack assembly. It is also desirable to specify constraints on nested parts using the dot notation. (Refer to related issue 14998 binding to multiplicity in parameterics).
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
The properties allocatedFrom and allocatedTo should be capitalized as shown here, and are so in SysML 1.1 pp 133 and following, but they are incorrect in the text on pp 131 and 132. (They are always capitalized correctly in figures; the errors occur in the text.)
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
A binding connector used in parametrics should allow for decomposition via association blocks in a similar way that other connectors support decomposition. The specification currently includes a constraint on Block that precludes this as follows: “The number of ends of a connector owned by a block must be exactly two. (In SysML, a binding connector is not typed by an association, so this constraint is not implied entirely by the preceding constraint.)”
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties
This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred
There is an inability to type a flow property or item property by an enumeration. This issue surfaced when Nathan Sowatskey was attempting to model a VLAN network.
Several errors in this section that need to be fixed. 1) Figure 16.8. Type of diagram should be "stm" not "sm" 2) Figure 16.7 and Figure 16.8. The relation between the testCase and the Requirement should be «verify» not «refine» 3) The paragraph mentions Figure 16.7, but actually describes Figure 16.8. 4) No description of Figure 16.7 appears.
When a swimlane in an activity diagram has the «allocate» stereotype, it means that the actions within the swimlane are allocated to the structural element in question. How come the examples seem to have the structural compartment of allocate from --- «activity» xxx intead of «action» xxx
The SysML flow properties specify elementary flows (nature and direction) that can cross the boundary of a block through a port. According to the functional approaches of systems engineering, an entering flow when getting over the boundary of a block is handled as an input by at least one function of the block. An outgoing flow getting out the boundary of the same block is produced as an output by at least one function. Activity diagrams are used for carrying out functional graphs with SysML. Inputs and outputs of SysML activities are specified by parameters. Nevertheless SysML does not seem to provide any mean to relate activity input / output parameters to the flow properties. This entails that the unfortunate SysML developers, after having made careful and strenuous efforts for specifying the block interfaces with flow properties and ports, have no other solution than to redo exactly the same work for specifying the inputs / outputs of the functional architecture as activity parameters (or vice-versa). Moreover, there is no mean to ensure consistency in the SysML model between the flow properties and the activity parameters and neither between the ports and the activity pins. A solution would be to enable to use flow properties like parameters as activity inputs / outputs.
Page 26
Original Text
7.3.2.5 Viewpoint
Description
A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases
Comment
How is the highlighted sentence done? There are no examples. I see examples of Viewpoint with a dependency on another Viewpoint, but no references for the individual fields (e.g., language and methods). Are the fields populated in an inheritance manner. Can they be overridden? Does it only work if the fields are blank on the dependant Viewpoint?
Type: Clarification
Add example and clarify rules
Page 31 There is an example of the Structure Compartment. As this compartment follows the ibd format, it should contain parts not blocks Type: Formatting/Clarification Change Block2 and Block3 to :Block2 and :Block3
Page 36, 8.3.1.1 Default «block» stereotype on unlabeled box is not always optimal
Original Text
Default «block» stereotype on unlabeled box
If no stereotype keyword appears within a definition box on a block definition diagram (including any stereotype property compartments), then the definition is assumed to be a SysML block, exactly as if the «block» keyword had appeared before the name in the top compartment of the definition.
Comment
I question whether this is always desirable, e.g.,
1) if the diagram had the «functional hierarchy» diagram usage stereotype applied, wouldn’t the default be «activity»,
2) if the containing block is an activity block, wouldn’t «activity» be the right default
Type: Clarification/Fix
Add sentences that say: If the bdd diagram has a «diagram usage» specified (such as «functional hierarchy»), a different default (such as «activity») can be used.
If the bdd diagram is for an activity block, the default stereotype elements is «activity»
Page 45 Distributed Properties on Activities
Original Text
8.3.2.4 DistributedProperty
Constraints
[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block or ValueType.
Comment
As I read this, on a BDD, if we have activities, the properties of the activities cannot be distributed properties, because activities are not stereotyped as block
Type: Fix
Rewrite this constraint,
[1] The DistributedProperty stereotype may be applied only to properties of classifiers stereotyped by Block, Activity, or ValueType.
Activity's sub activities should be able to have mandatory multiplicity
Page 86, 3rd paragraph and page 86 constraint 3
Original Text
Combining the two aspects above, when an activity invokes other activities, they can be associated by a composition association, with the invoking activity on the whole end, and the invoked activity on the part end. If an execution of an activity on the whole end is terminated, then the executions of the activities on the part end are also terminated. The upper multiplicity on the part end restricts the number of concurrent synchronous executions of the behavior that can be invoked by the containing activity. The lower multiplicity on the part end is always zero, because there will be some time during the execution of the containing activity that the lower level activity is not executing.
p87 [3] The lower multiplicity at the part end must be zero.
Comment
While this is technically true, it is not in the spirit of UML. We can have classes/blocks with mandatory components, because the, even though there is always a delay between the creation of the owner and the part, because we assume the time is
1) small, and
2) the situation can be made undetectable by normal UML means.
The same situation can occur here, that we should allow the lower multiplicity to exclude zero, if the component activity is the first sub behavior to run (or tied for first) and that it is the last sub-behavior to end (or tied for last)
Type: Fix
Rewrite constraint
[3]) The lower multiplicity of the part end must be zero, if
a) An instance of the part is not always the first thing started (or concurrently initialized with the first thing stared) or
b) An instance of the part is not always the last thing terminated (or terminated concurrently terminated with the last thing terminated), or
c) It is possible at some point, for no instances of the part to exist.
SysML 1.2 Issues: Continuous flows in non-streaming situations with >1 multiplicities 11.3.2.1 Continuous It’s a bit unclear how continuous flows work in non streaming situation, especially with high multiplicities. If a continuous flow arrives at a pin with a multiplicity of 2, it would appear that the 1st and 2nd value arriving at the pin would be captured. If the flow is also continuously valued, the two values would be same. The difference between two adjacent samples goes to zero if the delta time between samples goes to zero (assuming differentiability). Type: Fix To make this capability useful, we’ll need to add a sampling rate to be able to use continuous with >1 multiplicity. If we don’t the specification should have a caveat for >1 multiplicity and differentiable input values.
Sysm 1.2 Optional with «streaming»
Page 92
11.3.2.6 Optional
Does optional on an input mean optional to start the activity or optional for the activity to finish? Consider an «optional» streaming input.
Does optional on an output mean optional to appear at the end of the activity or optional for it ever to appear? Consider an «optional» streaming output..
We need to have all the possibilities for streaming; it probably should have two multiplicities for each streaming parameter
Starting Multiplicity: number of tokens that must appear for the activity to start
Total Multiplicity: number of tokens that must appear over the lifetime of the activity
Ending Multiplicity: number of tokens that must appear at the end of the activity
Total Multiplicity: number of tokens that must appear over the lifetime of the activity
Page 92 Overwrite
The description of how overwrite works is wrong. The rule given in the spec is to replace the token that would be last to be selected according to the node rules.
For example, let us imagine a node with 1..3 FIFO tokens when overwrite is applied.
New Token Position 3 Position 2 Head (1st to be taken off)
A A
B B A
C C B A
D D B A
E E B A
Probably desired behavior
New Token Position 3 Position 2 Head (1st to be taken off)
A A
B B A
C C B A
D D C B
E E D C
The recommended behavior is the standard behavior for real-time systems (usually implemented as a circular buffer, with the most recently arrived element the oldest element
For LIFO queues
For example, let us imagine a node with 1..3 LIFO tokens when overwrite is applied.
New Token Position 3 Position 2 Head (1st to be taken off)
A A
B A B
C A B C
D D B C
E E B C
Probably desired behavior
New Token Position 3 Position 2 Head (1st to be taken off)
A A
B A B
C A B C
D B C D
E C D E
The recommended approach makes both LIFO/FIFO queues always having the freshest elements to work from.
Recommended
“For upper bounds greater than one, when the queue is full, an arriving token replaces the oldest token in the queue, leaving a FIFO queue with the remaining earliest arriving token at the head of the queue and leaving a LIFO queue with the latest arriving token at the head of the queue.
Also, consider giving an example as above.
Page 214, C.5.2.14 Rational
Current description of the Rational value type is missing a constraint that prohibits the denominator from being 0.
Type: Fix
Add constraint [1]) The denominator must not be 0
Table on page 110 – Creation Event should be shown as a dashed arrow to be consistent with UML.
The structure compartment shows two blocks connected with a connector. It should be two parts.
It’s not clear whether the notation for static is part of SysML or not.
Annex B, Figure B.35, the object nodes after the decision and before the merge should be removed and the names/types moved to the ProportionPower pins / output parameter node.
A new keyword was added for attributes in UML, {id}. This concatenation of all such attributes within a class (block) for an instance must be unique.
While this will mostly be used by database developers, it’s also a domain model analysis property, e.g, Social Security Number for a US citizen, Mac Address, etc. As such, it may be useful to some SysML modelers.
UML issue 14062 now attempts (though is not completely successful) in begin Stereotypes with uppercase and keywords with lowercase, though the old stuff will still work. Effectively, this is a style recommendation for the specification and for later methodologist. SysML should probably for sake of consistency adopt this as a guideline for our spec and developers
In the UML 2.4 Superstructure specification, under the subsection "Notation" in Section 18.3.9, Stereotype (from Profiles), the following statement appears: Normally a stereotype's name and the name of its applications start with upper-case letters, to follow the convention for naming classes. Domainspecific profiles may use different conventions. Matching between the names of stereotype definitions and applications is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete. SysML consistently follows the lower-case keyword convention for stereotype applications, which the UML specifications now indicates is a valid convention for domain-specific profiles. The less-obtrusive lowercase keywords are valid according to the case-insenstive matching of stereotype names, and is preferred by many users based on long-standing practice in SysML and because the many uses of such keywords in SysML are less obtrusive than uppercase names would be. Language could be added to the SysML specification to explain this capitalization convention, however. The issue is being deferred so that a more explicit statement of these conventions can be considered in a future revision of SysML. Disposition: Deferred
In UML, there appears to be consistent representing of attributes as regular associations from the owning class. SysML, in similar circumstances, represents value properties as composite associations. We should try to understand what UML is saying (and perhaps push back on them) and consider the value of consistency.
UML issue 15370 added an optional URI field to packages. This has several potential usages, including unique identification, federated models, etc. There appears to be no reason not to include this change into SysML
SysMl does not give any example of using multiplicity on the relationships between actors and use cases. This is part of UML as shown in Figure 16.11. Apparently, the "official" interpretation of SysML is that if there is no example, it is not part of SysML. This incompatibility means that standardize training, books, etc, on Use Cases can not be applied to SysML. And the notation is of value.
Today, during the SysML1.3 RTF, we discussed simplifying the definition of the SysML profile by referencing the UML metamodel directly instead of the UML4SysML construction and replace the UML4SysML construction with OCL constraints about the scope of UML that defines strict conformance to SysML in the context of the UML4SysML subset. The practical advantages include: - any UML tool can be used as the basis for implementing the SysML profile - the SysML profile can be easily combined with other profiles that extend UML; e.g., SoaML, etc... (i.e., this could simplify the construction of UPDM) - if users need to use more than the UML4SysML subset, they could simply disable the OCL constraints for strict UML4SysML conformance
We have issues with SysML primitive value types - Real, Integer, Boolean, String etc. The problem is that these types are not inherited from corresponding UML primitive types - Real, Integer, Boolean, String. That means, UML tool can't understand, what kind of ValueSpecification should be created for values of properties typed by these value types. Should it be LiteralString or LiteralInteger or OpaqueExpression? Constraints can't check if slot values are compatible with property types, as it is not clear what kind of value specification it should be also. There are issues in parametrics solving also, as values must be compatible with property types. I think, SysML primitives must be directly inherited from UML primitives - Real subtype of UML Real, String subtype of UML String etc.
The allocate relationship is defined from client A::part1:P1 to supplier B::part2:P2. I think that’s ok according to the current SysML specification. However what I need is a allocate relationship defined from myA.part1:P1 to myB.part2:P2, i.e. the allocate relationship should consider the context and not be valid in another context. I’ve tried to assign the ownership of the allocate relationship to the TopLevel block which doesn’t work. MagicDraw doesn’t allow blocks to be owner of a allocate. I’m not sure whether it is a tool issue or if I’ve overseen a constraint. According to the UML metamodel it should be possible. Nevertheless I’m not sure if that’ll solve my problem. Any ideas?
Appendix F refers to a glossary and other documents that are out of sync with the SysML spec. Suggest removing the appendix.
In Blocks, NestedConnectorEnd, Constraints 3 and 4, replace all occurrences of "ConnectorEnd metaclass" with "connector end".
Blocks cannot own items flows, because UML NameSpace abstractly owns NamedElement. Consider specializing on blocks to own item flows.
Item properties and connector labels both appear in colon notation near the center of an assocation. How do you tell the difference?
In Blocks, NestedConnectorEnd, Constraints 3 and 4, replace all occurrences of "ConnectorEnd metaclass" with "connector end".
Description of item flow and its attributes should explain that "assign" means "realization", change "usage" to "instance", and convey items rather than classifiers.
From discussion within the MIWG (raised at Sandy's request). In UML 2.3 partWithPort is clearly only valid for a connector connected to a Port. SysML appears to expect this to be used when a connector is connected to any nested Property. This breaks the UML constraint and needs to be stated clearly in the SysML specification.
The text description of how the refine relationship can be used disagrees with formal restrictions.
On page 126, 2nd paragraph, the text says.
“The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.”
This allows a refine relationship to be
[Requirement] ß1..*[Model element]
Or
[Requirement] ŕ [Model element]
However, Figure 16.1 only has
/refinedBy:Named Element[*] as property for a Requirement
Thus it is not possible to have a requirement refine a model element.
This is confirmed by Figure 16.2, which in showing the tags for a NamedElement
Has /refines Requirement [*]
This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around).
So problem 1.
The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence:
The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.
Problem 2
The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word “diagram” from the text
Final wording
The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement.
Additional comment.
It’s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement.
The same property might appear more than once in the path.
Item flows can have multiple types but item properties cannot
Add a constraint to Section 8.3.2.5 NestedConnectorEnd that the stereotype is applied only to connector ends that violate Constraint [3] of Section 9.3.6 Connector in the UML Superstructure specification. Replace the existing Constraint [4] of 8.3.2.5 NestedConnectorEnd (that the partWithPort property must be must be equal to the property at the last position of the propertyPath list) with a constraint that partWithPort must be empty for any ConnectorEnd to which the stereotype is applied. Also, add clarifications to the SysML specification to make it explicit that SysML goes beyond extending UML entirely by UML stereotypes by also removing an existing constraint of the UML metamodel.
The allocated stereotype is applied to an element at either end of an allocate relationship. This enables the use of the compartment and callout notations to identify what element is on the other end of the allocate relationship. The specification does not explictly state that the allocated stereotype is applied to the elements when the allocate relationship is established. This should be specified as a constraint for the allocated stereotype. This should not imply that the stereotype name must be displayed, but only that the stereotype is applied.
Suggest these compartment rules: - Italics - Plural - All lower case - Words separated by spaces
Progress has been made in standardizing on these compartment label rules, but exceptions still exist in the SysML specification, such as allocatedFrom and allocatedTo in Chapter 15. This issue is being deferred so further standardization of conventions on compartment labels can be considered in a future revision of SysML. Disposition: Deferred
The current definition of "part" includes ports. Is that intended?
The stereotype TestContext appears in the SysML profile XMI file http://www.omg.org/spec/SysML/20100301/SysML-profile.uml , but is not in the SysML v1.2 profile specification. It should be removed from the xmi file and anywhere else it may have inadvertently been introduced.
Section 8.3.1.3 (UML Diagram Elements not Included in SysML Block Definition Diagrams) says "N-ary associations, shown in UML by a large open diamond with multiple branches, can be modeled by an intermediate block with no loss in expressive power." An intermediate block cannot capture multiplicities that would be on an the ends of an n-ary association. These multiplicities are for the links from end to end, rather than from intermediate object to end, as they would be with an intermediate object. However, intermediate blocks can specify the number of links each end might participate in for any of the other n-1 ends, which is not possible with n-ary associations. The expressiveness of n-aries and intermediate blocks is overlapping, rather than equivalent.
in some figures of the examples provided in Annex, some stereotypes are displayed: <<domain>>, <<external>>, <<diagramDescription>>, … and so on. Can someone tell me where these stereotypes have been defined?
the parameter of the constraint block StraightLineVehicleDynamics shown in figure B.31 seems to be incomplete w.r.t. to figure B.30. Is it ok?
I think there is a typo error in the diagram C.15. The stereotype <<normal>> should be shown on the property force of the class Canon.
In the spec, it is said that : « Notational and metamodel support for n-ary associations and qualified associations has been excluded from SysML.”. However, as shownin the extract of the table of the SyML symbol, multibranch association are possible:
Elements deprecated in issue 13178 should have a package in the language architecture and be noted in the compliance chapter.
The annex added for deprecated elements by issue 13178 has cross referencing errors. It should also be marked as informative.
Issue 13178 updated the Water association decomposition example in the blocks chapter to use ports. It should be in the ports chapter.
Clarify that item flow decompositions examples introduced by issue 13178 are not rules for item flow decomposition.
The flowFlow property compatibility rules introduced by issue 13178 assume item flow is present. They should be applicable when item flow is not present.
Remove colons from item flow classifiers in item flow decompositions examples introduced by issue 13178. Colons are for item properties, not item flow classifiers.
The subfigure added to the block definition diagram elements table by issue 13178 in the item flow row has a connector between ports. So does Figure B.23 (Elaborating Definition of Fuel Flow. (Block Definition Diagram)).
Chapter 9 (Flow Ports), as revised by issue 13178, should clarify what "expressively" means in the overview, how textual notation flow direction in compartments is determined, and what the term "behavioral port" means in UML.
The description of item flow properties refers to owner of source and target, which might not be the same. Fourth constraint should refer to realization.
Figure B.36 (Flow Allocation to Power Subsystem (Internal Block Diagram)) uses black-filled rectangles for ports.
It would simplify the use of required / provided interfaces if operations and receptions could be required and provided instead. It would enable provided and required ops/recs to be defined on the same block, including InterfaceBlock introduced by resolution of 13178.
UML's onPort property on invocation actions enables invocations to be sent to ports of the target objects directly. The nested port extension to onPort in 13178 does not have this capability, but it should, since it is meant as an extension of onPort
The terms internal and external connector are used in v1.2 and the resolution of 13178, but are not defined.
The term owning block is used in v1.2 and the resolution of 13178, but is not defined.
Figure 9.1, as modified by issue 13178 shows block as a metaclass instead of a stereotype.
The flow property semantics in the second paragraph of Section 9.3.2.3 (FlowProperty) only gives semantics for out to in flow properties, which does not work for internal connectors to proxy ports as introduced in issue 13178.
The resolution of issue 13178 only requires ports of behavioral ports to be behavioral, but should also require ports owning behavioral ports to be behavioral.
Issue 13178 extends UML's onPort abstract syntax for InvocationAction and Trigger, but not the notation.
TriggerOnNestedPort introduced by issue 13178 refers to UML's onPort property, but it's actually called port. It should constrain that property to have exactly one value.
Associations in SysML should be able to own their ends. Otherwise modelers can't add an association between blocks in model libraries they do not have permission to modify. They also cannot create association that are non-navigable in both directions, which might be useful for directing flows across them into flows contained by the association as a block.
Invocations of required behavioral features on self should be forwarded along links from the executing object to external objects that provide those features. Currently this can only be done through ports.
Issue 13178 added a constraint requiring ports of behavioral ports to be behavioral. This prevents nested proxy ports from being bound to internal parts.
Issue 13178 prevents flow properties from being defined on blocks that type internal parts. Flow properties specify the kind of things that flow into and out of a block, regardless of how the block is used. In v1.2 they are related to receptions, which also do not restrict how the block owning the flow property is used. The constraint also causes an unnecessary difference between full ports and internal parts.
Proxy ports in the resolution of 13178 should have a constraint preventing them from owning connectors.
he semantics of multiple internal connectors from proxy ports should be clarified. For example, what is the value of the port? Issue 13178 refers to a "virtual aggregate" that is not explained.
The stereotype «TestCase» is primarily specified in the UML Testing Profile (UTP) and should not be defined by SysML redundantly (or even inconsistently). Rather it should be separated in a dedicated package in SysML and a PackageMerge be specified. This would properly add the properties of a «TestCase» specified in SysML to the "base" «TestCase» specified in UTP.
he types of full ports have behaviors defined independently of the ports they type. They cannot switch the direction of flows and invocations based on the port they type.
when participating in the discussions on the draft ballot 3 on the SysML 1.3 spec, we observed that there is a need for clarification. The question was about whether Enumerations can be used on parametric diagrams for typing constraint parameters. The spec defines: From 8.3.2.10 SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. … A SysML ValueType may define its own properties and/or operations, just as for a UML DataType. See Section 8.3.2.2, “Block” for property classifications that SysML defines for either a Block or ValueType. ValueTypes can be used to type constraint parameters. Since ValueTypes extend UML DataTypes, and Enumerations are a subtype of DataType, Enumerations might be used. Since Blocks could be used as types of constraint parameters as well, the implication that any subtype of a UML datatype might lead to the implication that any subtype of UML classifier could be used here as well (e.g. activity or StateMachine), which is of course not meant. We need to constrain this definition better
On pg 74 (section 10.4.2) of the SysML 1.2 spec, it is stated that: "A parametric diagram is similar to an internal block diagram with the exception that the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end." One may have binding connectors, whether or not they are shown in par diagrams, that have neither of their ends as constraint parameters. A binding connector may have both ends as value properties of the owning block or any of the nested part/ref/shared properties (at any depth).
Clarify that connectors use port types in a closed way, rather than open, as described in Block, unless specialized
In Section 9.3.2.7 (ItemFlow), Issue 13178 modified the last sentence of second paragraph ungrammatically. It should say the values of the item property are the flowing instances of water.
In Section 9.2.1 (Extensions to Block Definition Diagram), as modified by Issue 16217, the row for item flows has an internal structure for the association class that does not match its end classes. Similar examples should also be in Section 9.2.1 (Extensions to Internal Block Diagram), and in Section 8.2.2 (Internal Block Diagram).
Section 9.3.2.8 (ProxyPort), first paragraph, as modified by Issue 16227, should refer to internal structure instead of diagrams, because multiple diagrams can describe the internal structure of the same class.
Item flows are based on dependencies, which cannot be contextualized in an internal structure, but many of the use cases are for item flows realizing connectors.
Extend ChangeEvent and AcceptEventAction to detect and changes in property values.
It is not possible to send out invocations along untyped connectors to parts. Flow properties can be changed on self and broadcast along connectors to neighbors that support them, but invocations cannot. Extend invocation action semantics to send invocations out connectors to neighbors that support them.
The resolutions of issues 16227 and 16221 sometimes use the term "owning block" for proxy ports differently than UML ownership. For flow direction it is the block items are flowing in or out of, and for behavioral ports and directed features, it is the block the proxy port is standing in for. These uses should have different terms than "owning block".
The provreq abbrevation for providedrequired should be provreqd, to be consistent with the reqd abbrevation for required. The block diagram elements table in the ports and flows chapter should use the abbreviations.
In the specification the content of the derived property “Requirement::tracedTo” is defined as follows: • /tracedTo: NamedElement [*] Derived from all elements that are the supplier of a «trace» relationship for which this requirement is a client. As «copy» «deriveReqt» «verify» and «satisfy» inherit from “Trace”, does this means that /tracedTo also list all elements that are the supplier of a «copy» «verify» «satisfy» «deriveReqt» relationship for which this requirement is a client ?
In InvocationOnNestedPortAction and TriggerOnNestedPort, in the path attribute description, replace "until a port is reached" with "ending in a port", to support nonuniqueness
There are mistakes and inconveniences in the model and model library of quantities, units, dimensions and values (QUDV) in SysML v1.2 as defined in Annex C. Furthermore the ordering of the sections in Annex C can be made more logical to improve the readability.
There is an inconsistency w.r.t. the definition of SysML Rate with the notation & examples. According to figure 11.8, SysML Rate extends only 2 metaclasses: Parameter and ActivityEdge. By generalization, SysML Continuous and Discrete also extend these two metaclasses. According to the notation in Table 11.1, <<rate>>, <<continuous>> and <<discrete>> also apply to ObjectNodes. The examples in figure B.33 and B.35 show applications of <<continuous>> to CentralBufferNodes and ActivityParameterNodes, both are direct specializations of ObjectNode. Some examples in the Practical Guide to SysML do the same -- see figure 8.17 on p. 196; figure 15.14 on p. 373 Both SysML 1.2 Figure 11.8 and the published profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml are incomplete. The resolution is fairly simple: Add an extension from Rate to ObjectNode in figure 11.8 and update the SysML profile accordingly. I propose to include this resolution in ballot 5 for sysml 1.3.
Both Figure 16.1 and the SysML 1.2 profile http://www.omg.org/spec/SysML/20100301/SysML-profile.uml define Requirement::/derived : Requirement[*] but in 16.3.2.3, the attribute is described incorrectly as: /derived : Requirement[0..1] It's obvious that the specification in 16.3.2.3 is incorrect; the property description should be changed from: /derived : Requirement[0..1] to: /derived : Requirement[*] I propose to include this resolution in ballot 5 for sysml 1.3.
It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented?
Specifically (in the beta2, inherited from 1.2):
- Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock."
- Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties.
- Section 10.3.2.1 (ConstraintBlock):
Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks"
Constraints, "[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, ..."The following sentence introduced in §9.1 by the resolution to issue #16280 is confusing: "Default compatibility rules are defined for connecting blocks used in composite structure, including parts and ports [...]" since it is not "blocks" (SysML sense), which are not connectable elements, that are connected in composite structure but parts and ports. In addition the rules we are speaking about deal with "matching/mapping" (i.e. routing) rather than with "compatibility" since one can have several possible solutions (mapping) to connect two compatible ports. I suggest replacing this sentence by the following one: "Default matching rules are defined for connecting parts or ports in composite structure but specific mappings can be specified thanks to association blocks".
Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name. No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end. No examples of property specific types are given. The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type. The description of the property-specific types refers to: "local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and "starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType) The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text. The following sentence is a tautology (ie, adds nothing to the spec): "The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)" because a property with a property specific type is one where the property type has the PropertySpecificType applied. Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous. The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.
InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.
Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.
There is a critical need to model off nominal conditions and behavior associated with faults, failures, and hazards. However, there currently is no standard way to represent this in the SysML model. This issue is intended to provide some lightweight and standardized and light-weight capability for this type of modeling, such as a trigger on a state machine with the stereotype failure or a fault stereotype to represent a fault condition. There is a separate profile (not standardized) that was developed by Bruce Powell Douglass that provides a broader more comprehensive capability that could be leveraged as source material.
In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states: “[4]In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)” No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45): “A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute” The SysML Block constraint #4 has no clear justification and should be removed.
For SysML 1.3, has anyone tried to specify the value of a SysML::ValueType ? If you haven't done so, please try to do this carefully -- i.e., don't just assume that Real x = "42.0" is enough! You'll realize then that the SysML 1.3 spec doesn't provide the capability to specify the actual value for any of the SysML::Libraries::PrimitiveValueTypes SysML::Libraries::PrimitiveValueTypes::Boolean SysML::Libraries::PrimitiveValueTypes::Integer SysML::Libraries::PrimitiveValueTypes::Real SysML::Libraries::PrimitiveValueTypes::String Since we can't specify the actual real value of a SysML Real, we can't specify the realPart or the imaginaryPart of a SysML Complex number either! SysML::Libraries::PrimitiveValueTypes::Complex::realPart : SysML::Libraries::PrimitiveValueTypes::Complex::imaginaryPart What is missing is an actual "value" attribute whose type then must be from the UML PrimitiveTypes library since it's the only capability in UML/SysML we have to specify an actual "value" via the Literal[X] metaclasses in UML. SysML::Libraries::PrimitiveValueTypes::Boolean::value : PrimitiveTypes::Boolean -- an actual value can be specified as a UML::LiteralBoolean SysML::Libraries::PrimitiveValueTypes::Integer::value : PrimitiveTypes::Integer -- an actual value can be specified as a UML::LiteralInteger SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real -- an actual value can be specified as a UML::LiteralReal SysML::Libraries::PrimitiveValueTypes::String::value : PrimitiveTypes::String -- an actual value can be specified as a UML::LiteralString SysML::Libraries::PrimitiveValueTypes::Complex can remain as-is since it inherits the capability to specify an actual value for its realPart & imaginaryPart attributes thanks to SysML::Libraries::PrimitiveValueTypes::Real::value : PrimitiveTypes::Real I also realized that the QUDV library inconsistently uses in a few places SysML::Libraries::PrimitiveValueTypes when in fact it should use UML's PrimitiveTypes. I believe that this is a new issue for SysML 1.3.
As discussed in the SysML 1.4 RTF meeting today, it is currently unclear whether all of the elements shown in SysML diagrams have a SysML stereotype applied or not. In some cases, there is an explicit mention about the meaning of SysML diagrams, e.g., 11.3.1.1 Activity: Activities in block definition diagrams appear as regular blocks, except the «activity» keyword may be used to indicate the Block stereotype is applied to an activity, as shown in Figure 11.1. We need a clarification whether the meaning of SysML diagrams is that they show only SysML-stereotyped elements or not and if not which UML elements can be shown on a SysML diagram without any SysML stereotype applied.
I like the feature of SysML to decompose activities in a block definition diagram based on the callbehavior semantics (Fig. 11.1. SysML spec.). For example I use that extensively in the FAS methodology (Functional Architectures for Systems). I have a question about the composite relationship between activities. The SysML specification seems to be unclear about that. When modeling an activity with a CallbehaviorAction of another activity, does that automatically creates the association between the activities in the model? I think it must do that. Unfortunately tools seems to have a different behavior.
In Figure 15.6 in pending SysML 1.3, on the left side of the diagram, the object-flow, labeled objectflow3 is a dashed line. From table 11.2, object flows always use solid lines (though control flow can use either solid or dashed). This was also wrong in SysML 1.2, though the diagram number was then 15.5. Thanks to Geoffrey Shuebrook who pointed this out to me,.
In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts. This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements. A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard
The derived property notation was originally included in SysML and removed. This notation is very helpful and should be restored. An example of how this is used can be found in Figure 7.2.1 of the 2nd edition of "A Practical Guide to SysML".
I am working through some examples for MEF as you suggested. When I look at the XMI for SysML 1.3, I find the following anomalies: 1. The model library PrimitiveValueTypes is a Package owned by the SysML Profile. This is what the XMI says but it is not shown as such in figure 4.3 in the SysML specification. 2. The PrimitiveValueTypes Package does have the SysML profile applied to it, but it does not have any stereotypes applied to the various DataTypes. Surely there should be elements of the following form in there: <sysml:ValueType xmi:id="Stereotype1" base_DataType="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-Real" /> In order for such elements to be legal, the sysml xmlns needs to be declared. Also it’s somewhat unclear to me whether those elements should be children of the outer XMI element, or of the contained SysML package element.
SysML XMI seems to define its own versions of UML Primitive Types rather than reusing those from UML. Furthermore they are not even defined as instances of PrimitiveType despite their XMI id.
For example we have:
<packagedElement xmi:type="uml:DataType"
xmi:id="_OMG_SysML_20110919_SysML_Libraries-PrimitiveValueTypes-String"
name="String"/>
In Part 1, there is a paragraph that says, in the context of describing the origins of SysML Currently it is common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers. This is not currently correct. It should be changed to. It was then common practice for systems engineers to use a wide range of modeling languages, tools, and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML has started to unify the diverse modeling languages currently used by systems engineers.
9.3.1.6 The fill color of port rectangles is white and the line and text colors are black. - Notation CAN'T be related to colors
9.3.1.7. The keyword “full” before a property name indicates the property is stereotyped by ProxyPort . Copy/paste bug? <<full>> is for FullPorts. What is the type of FullPort? Spec says nothing. What are possible owned properties of the InterfaceBlock? Values, FlowProperties? other? In 9.1 InterfaceBlock it is not flow nor value.
- why Integer property is under "properties" compartment? why not "value properties"?
9.1 InterfaceBlock - unnamed compartment?? why not "operations"? What is "void" ??? no such primate type in sysml. Better example needed.
Port labels inside Port symbol. Is it new notation, not supported in UML? One more nightmare for tools?Where it is described? What information can be inside port? Name, type? How about stereotype label, tags, etc? E.g. <<full>> - should it be inside or not?
ports with flow properties are displayed the same as flow ports in SysML 1.1? Can we say this clearly? is <> notation based on flow properties only? How about directed features? Can we use the same notation to show direction? <> notation is used on WHAT port types? proxy ? or full or even simple ports? What notation (reversed?) is on conjugated port? How about nested port, when parent is conjugated?
9.3.2.4 DirectedFeature , constraint 4 - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all? constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties??? what does it mean "the meaning of direction"?? how direction is visible on port? what happens on nested ports when owning port is conjugated? example is needed.
9.3.2.8 FullPort - in description it says it cannot be conjugated. 1. Why? 2. Why there is no constraint for that? what constraint 2 means? when binding connector is connector to proxy port?
9.3.2.9 What is InterfaceBlock? Where is description? Description is the same as constraint [1] text now. InterfaceBlock is kind of Block, so, can it be used everywhere Block is used? e.g. part of the FullPort. Constraint [2]. Does it mean Interface block can't have value properties and e.g. constraint properties? Constaint [3] - does it mean "proxy ports" ? if so, it could be more clear text to say "InterfaceBlock can own proxy ports only" constraint [4] - it must be constraint[4] for FullPort???
Constraint [2] is incorrect. What does it mean "owned by the target object" ?what is object? Also, target is always the context of activity. Port can be not only owned, but inherited too. [3] incorrect too - it can be inherited, not owned only.
reference properties "sp" in all subtypes must redefine "sp" from block P.
also, p1, p2, p3 in Plug Design 1 - are they redefining or not? if yes, must be {redefines} used, if not, how <<proxy>> appears there?
Figure 9.8 - can roles be ports?? or ports be association ends???? Is it new SysML notation? Where it is described??? Did we voted? Tools does not support that.
The NEW issue - clarification, what "part property" is, as new port types typed by Blocks changed everything, they fit into "part properties" definition. SysML 1.3, Page 43 : "A property typed by a SysML Block that has composite aggregation is classified as a part property, except for the special case of a constraint property. "
Spec says: "Full ports can appear in block compartments labeled “full ports.” The keyword «full» before a property name indicates the property is stereotyped by FullPort. " a) "full ports." should be changed to "full ports". (without dot inside) b) does it say that even in full ports compartment keyword <<full>> is used? Or it is used near port symbol, when NOT in compartment? It should be clarified. c) there is no single example of this notation - nor in Table 9.1 - Graphical nodes defined in Block Definition diagrams nor in any other diagram example in spec. d) the same issues with "proxy ports" compartment.
Compartments "part" and "reference" must be renamed to "parts" and "references" in Figure 9.7 Usage example of proxy and full ports
Is <<equal>> keyword (or stereotype) on binding connectors is part of SysML notation? Figure 9.7 Usage example of proxy and full ports
The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property. Suggested addition to the spec - property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point] - A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties. - Table 8.3: Example for call-out notation Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.
Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself. Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.
In SysML 1.3 11.3.1.1 Activity constraints “The lower multiplicity at the part end must be zero.” The diagram above Figure 11.1 on the previous page does not indicate 0 as the lower end. The default for a composition relationship at the part end is 1..1 and does not include 0. However, as you fix the diagram consider eliminating the constraint 3. I believe this constraint has been eliminated from UML 2.5 (in the works). The proper constraint is something like. (Conrad will know what’s in the UML spec). If the part end action starts running when the parent activity is started, and continues until the parent activity is ended, then the minimum multiplicity is non-zero. Otherwise, the lower multiplicity at the part end must be zero. Whether the constraint is fixed or not, the diagram must include a lower end of zero. Recommended fix, eliminate the constraint and fix the diagram 11.3.1.4.1 Constraint 3 Similar to above. The BDD in Figure 11.5 would need to explicitly be marked to allow for 0. This constraint was not changed in UML. Recommend the diagram be fixed
In SysML 1.3 C.4.8.2 Diagram C.34 The «activity» ProvideElectricPower is switched with «activity»ControlElectricPower. If you switch them now, you’ll be consistent with Figure C.35
13.1 Table 13.1
The state machine decomposition symbol (which looks like eyeglass – not a rake) is not given
13.2 Table 13.2
The notation that comes from transition-focused state machines is included in the table. However, the notion that looks like:
|
(via entry point name)
|
is not indicated.
In UML 2.4.1, the equivalent to createEvent and desturctionEvent are now called messages. This should be followed in SysML. This changes the text in the 1st row of Table 12.1 on page 116, but it may impact other places also.
In section 6.3 ,the convention is given that indicates that enumeration literals within SysML are named with the suffix of Kind. Enumeration types: always end with “Kind” (e.g., “DependencyKind”). Several of the SysML enumeration literals are correctly named, but the following do not follow the convention: Section 9.3.2 Figure 9.1 FlowDirection ŕFlowDirectionKind Section 9.3.2 Figure 9.4 FeatureDirection ŕFeatureDirectionKind Section 11.3.3 Figure 11.9 ControlValue ŕControlValueKind
The concept of Requirement, as intended in the original SysML specification, included the notion that textual requirements only have meaning in their original context. Requirements thus should not provide a source of inheritance. This precludes their use as classifiers for typing other Requirements or any other model elements. The 5 constraints listed at the end of section 16.3.2.3 are currently insufficient to enforce this concept. Recommend adding a 6th constraint, precluding a class stereotyped by <<requirement>> from typing any other model element.
There is a contradiction in the SysML spec. regarding whether constraint parameters--as properties of constraint blocks--may use the derived indicator, "/". Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine." On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks." There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this. As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression. This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84. Proposed Resolutions: 1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property. 2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.
Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied to a call behavior action (when that call behavior action calls an activity that also has the «controlOperator» stereotype applied). However, the metamodel fragment on pg. 104 and the stereotype description on pg. 105 do not support that. Currently the spec. states that SysML::ControlOperator only extends UML4SysML::Behavior and UML4SysML::Operation, not UML4SysML::CallBehaviorAction. This would be appropriate, though, and seems to be in keeping with the original intent of the SysML Development Team given that it appears in Table 11.1 Proposed Resolution: Add another extension relationship from SysML::ControlOperator to UML4SysML::CallBehaviorAction.
An unnumbered constraint on the Allocate relationship states: "A single «allocate» dependency shall have only one client (from), but may have one or many suppliers (to)." The use or meaning of this n-ary relationship is not described. An informal survey of RTF members indicated that this n-ary allocation capability has not been implemented in any tool, nor has it been used by practitioners. Note that Satisfy relationship (see 16.3.2.6) serves a similar purpose to Allocate, but does not require an n-ary implementation. Removal of the n-ary requirement on Allocate would simplify efforts to unify SysML relationship dependencies. This requirement should either be 1) rationalized, elaborated and applied consistently across similar SysML relationships, or 2) deleted to facilitate ongoing SysML improvements.
For a practical usage it is required to be able to refer to a property of a stereotype application, for instance as target or source of an allocation relationship. This need is somewhat similar to that of referencing a nested property but we shall make sure the solution selected for the Common Reference Path will be able to address this case too.
The practical usage of port implies the ability to specify a protocol, especially when operations or receptions are provided but not only (this can be true with flow properties too). The UML::Interface metaclass (at L3) has a specific property to define a protocol. Note that this protocol is not an owned behavior but only a specification of conformance characteristics. I believe we should add something similar to our InterfaceBlock stereotype, even if we do not include UML protocol state machines.
The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added
Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.
Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties. The constraint at the moment is too strict and needs to be changed to allow certain composite properties.
Fix the notation (hopefully in the same way as UML) to allow allocation of a decision to a swimlane
The SysML notation allows a stereotype <<S>> applied to an element E1 to be shown as the notation for a different element E2 related to E1 in some way. Example: 11.3.1.2 CallBehaviorAction and Figure 11.2: Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as shown in Figure 11.2. What this means is that if a CallBehaviorAction shows a stereotype <<S>>, then it is unclear whether <<S>> is applied to the CallBehaviorAction itself or to the behavior that the CallBehaviorAction calls. This ambiguity is problematic for users reading SysML diagrams as indicated by SysML issue 17549: Table 11.1 on pg. 93 shows that the «controlOperator» stereotype can be applied to a call behavior action (when that call behavior action calls an activity that also has the «controlOperator» stereotype applied). More generally, the SysML spec needs to be reviewed where this stereotype notation can result in this kind of ambiguity.
In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind. There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK. Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself. This notation could suggest that one could change the tag/values shown on the value property itself. It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself. This tool-specific practice in fact suggests that there is a missing capability; that is: QUDV unit and quantityKind could be specified on the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them) The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind) A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property) However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit. Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property. This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType) Suggest the following: Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind Add a new stereotype: ValueProperty extending UML::Property with: ValueProperty::unit : QUDV::Unit[0..1] ValueProperty::/effectiveUnit : QUDV::Unit[0..1] -- it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] -- it is derived from the ValueType::quantityKind of the type of the ValueProperty. Add a new stereotype: QuantityValue extending UML::ValueSpecification with: QuantityValue::unit : QUDV::Unit[0..1] QuantityValue::/unitConstraint : QUDV::Unit[0..1] -- if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue
Clause 9.3.2.8, FullPort - in description it says it cannot be conjugated. 1. Why? This issue is a portion of issue 17254 (9.3.2.8 FullPort) and is filed to allow it to be addressed separately from the rest of 17254, and for the resolution of 17254 to ignore this portion of issue
I just realized that Requirements::VerdictKind enumeration in SysML profile is NOT a ValueType, so I can't use it in SysML model to type my values. Does everyone agree that it shall have ValueType stereotype applied? We should make sure all datatypes we provide are ValueTypes.
An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications. At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions. The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows: Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint. Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification. Some of the limitations that have been identified include the following: a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.) The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint. b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application. c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders. d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information. A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below. In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ). In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents. e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others. f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking. g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).
NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction have exactly the same property (propertyPath). It should be defined once in a generalization of NestedConnectorEnd, TriggerOnNestedPort, and InvocationOnNestedPortAction
Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?
Constraint [5] states: "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»." This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to: "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"
The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships. Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element. The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.
SysML 1.3 QUDV provides redundant ways of naming a Unit/QuantityKind: <!--[if !supportLists]-->a) <!--[endif]-->by naming the definition of the Unit or QuantityKind (e.g., InstanceSpecification) <!--[if !supportLists]-->b) <!--[endif]-->by the property Unit::name and QuantityKind::name This redundancy is unnecessary; it invites confusion and could also lead to problems of interchange since different users could use different ways of naming what should be equivalent definitions of the same Unit or QuantityKind
9.3.2.4 DirectedFeature, constraint [2] - what is inherited method??? how operation CAN inherit a method? Why it is mentioned at all? This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.
9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port? This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.
9.3.2.4 What does it mean "the meaning of direction"?? how direction is visible on port? This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.
Constraint [1] - properties that have no FlowProperty applied. does it include ports, association ends, value properties??? More specifically – can port be stereotyped as directed feature/flow property, what types of properties can be stereotypes with these stereotypes? This issue is a portion of issue 17253 (9.3.2.4 DirectedFeature , constraint 4 - what is inherited method???) and is filed to allow it to be addressed separately from the rest of 17253.
The model library for Activities should be in a new package inside the SysML::Activities package. Figure 11.9 (Control values) does not have a frame, but Figure 8.7 (Model library for primitive value types) does. They should be consistent.
The title of section 9.4.2 includes the term "Flow Ports", which is deprecated. I think it should be "Flow properties". Maybe an editing instruction for a 1.3 issue exists for this, not sure.
Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).
The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?
In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).
The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.
Figure C.35 uses the optional notation for Pins (i.e. ->[]-> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following: + the origin and destination pins + the object flow + the common type of the pins Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).
Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships. In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1". In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown). In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1". There are a number of issues: 1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed. 2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1". 3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.
There's a few issues with the Copy relationship as described in the specification. 1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)? 2. How do you match subrequirements in the slave to subrequirements in the master? 3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters? 4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?
We need a specialization of the UML standard <<refine>> stereotype within SysML in order to be able to contextualize the corresponding relationships instances just like the resolution to issue #14447 specifies for the <<trace>> stereotype.
SysML defines or uses some relationship based on the UML Dependency metaclass. It is possible to specify multiple dependencies having with the same client or supplier. The user can rely on this capability for various purposes. The point is that there is no standard semantics for such constructs. This must be clarified.
Source: Jet Propulsion Lab (Chris Delp – Christopher.L.Delp@jpl.nasa.gov) INCOSE (Sanford A. Friedenthal – safriedenthal@gmail.com) Summary: This issue represents issues a) and f) from Issue 18391 – View and Viewpoint Limitations in Support of Auto-View Generation. An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications. At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions. The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows: Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint. Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification. Some of the limitations that have been identified include the following: a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.) b) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
In SysML, value property types are restricted to be a ValueType. I see the problem with incompatible and inconsistent types in customer models, as Activities have no restrictions and still use UML primitive types as pin and parameter types. Did I miss something in the spec, or types used in Activity are not restricted to be ValueTypes? Also, did we fix VerdictKind to be a ValueType? I don't remember.
I struggle to use proxy port with flow properties. One idea is to use a behavioral port and to bind the flow properties with the behavior parameters. In chapter 9.3.2.7 about FlowProperties the spec states: The binding of flow properties on ports to behavior parameters can be achieved in ways not dictated by SysML. One approach is to perform name and type matching. Another approach is to explicitly use binding relationships between the ports properties and behavior parameters or block properties. What are port properties? A port has no properties, but the type of the port, e.g. a InterfaceBlock. And these properties are the same for any usage of the InterfaceBlock and I can’t use context-specific binding relationships.
In the Constraints section the specification states the following: 'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.' For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be: a) One allocate from the StructuredActivityNode only? b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode? To make things clearer, instead of the constraints section saying: 'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”' It should say something along the lines of: 'An Action referenced in the "node" role of an “AllocateActivityPartition”' This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.
The QUDV conceptual model in SysML 1.3 provides 2 concepts intended to support the modeling of measurement scales: D.5.2.13 Scale (for defining a measurement scale in the sense of the Vocabulary of International Metrology (VIM)) D.5.2.14 ScaleValueDefinition (for representing a specific value for a measurement scale) D.5.2.13 mentions a simple example of a "priority" measurement scale whose scale value definitions would be 0 for "low", 1 for "medium" and 3 for "high". In practice, a user can reasonably expect to use a suitably-defined "priority" measurement scale as the type of a SysML value property. Unfortunately, this requires defining the "priority" measurement scale twice: Per QUDV, a definition of "priority" as an InstanceSpecification classified by QUDV::Scale so that it can specify its "low", "medium" and "high" values defined as InstanceSpecifications classified by QUDV::ScaleValueDefinition For typing a value property, a definition of "priority" as a SysML ValueType Enumeration whose EnumerationLiterals correspond to “low”, “medium” and “high” From a metrology standpoint, both definitions of “priority” can be related to a definition of a Unit and a definition of a QuantityKind: - The QUDV-based definition of “priority” can refer to a definition of a Unit; a given QuantityKind definition can refer to the QUDV “priority” scale (See SysML 1.3, Figure D.8 in section D.5.2) - The ValueType-based definition of “priority” can refer to a definition of a Unit and to a definition of a QuantityKind via the SysML ValueType stereotype properties (See SysML 1.3, Figure 8.4 in section 8.3.2) From a pragmatic standpoint, the QUDV-based definition has no utility beyond QUDV purposes whereas the ValueType-based definition of “priority” is clearly useful for typing value properties and specifying their values. Suggest merging the two approaches, explaining that QUDV::Scale and QUDV::ScaleValueDefinition can be deleted from the spec since: - A SysML::ValueType Enumeration really defines a “scale”, thereby alleviating the need for a separate QUDV::Scale concept. - The EnumerationLiterals of a SysML::ValueType Enumeration constitute the ordered set of values for a “scale”, thereby alleviating the need for a separate QUDV::ScaleValueDefinition concept. Nicolas.
In Table 8.2 (Graphical paths defined by in Block Definition diagrams), rows MultibranchPart Association and MultibranchShared Association shows two association lines sharing one end (property3), implying the end is owned by two blocks (assuming the other ends are different), which isn't possible. Even if the two blocks on the opposite ends redefine property3 using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of property3 should be added to the figure, and some diagram extension text should explain that the "shared" graphical elements refer to three underlying model elements. The notation isn't in 2.4.1 that I can find.
Currently, QuanttiyKind can only be part of 1 SystemOfQuantities. This seems wrong. For example, wouldn’t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities. This exclusive association would prevent reusing existing definitions of Units & QuantityKinds for custom systems.
Many UML elements are semantically equivalent to properties, but are not properties in the abstract syntax, such as behavior parameters, activity variables and call behavior actions. This means they cannot be used with deep nested connectors and other elements requiring property navigation. Add stereotypes based on properties that have "runtime" instance values for these elements.
SysML 1.3 section 9.1.3 Proxy Ports and Full Ports states: Full ports cannot be behavioral in the UML sense of standing in for the owning object, because they handle features themselves, rather than exposing features of their owners, or internal parts of their owners. This is incorrect; see UML 2.5, section 11.3.3 Structured Classifier Semantics: A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any. Such a Port is called a behavior Port. If there is no Behavior defined for this EncapsulatedClassifier, any communication arriving at a behavior Port is lost. Based on the UML 2.5 semantics of behavioral ports, there is no legitimate reason to exclude a SysML 1.3 FullPort to be behavioral in the UML sense. This is inconsistent with SysML 1.3, section 9.3.2.7 FlowProperty: Items going to or from behavioral ports (UML isBehavior = true) are actually going to or from the owning block. (See “Block” on page 66 for definition of owning block of proxy ports in this case.) The above is consistent with the UML 2.5 semantics but it is inconsistent with the SysML 1.3 semantics of FullPort above. Finally, SysML 1.3 section 9.3.2.8 FullPort states: They cannot be behavioral ports, or linked to internal parts by binding connectors, because these constructs imply identity with the owning block or internal parts. The notion that a behavioral port implies identity with the owning block or internal parts is incorrect and does not make sense. It would require that a behavioral port to be typed by its owning block or internal part. It would be impossible for a block A to have a behavioral port typed by B for example.
The ISO-80000-1 libraries need to be updated according to the resolutions of issues 18269, 18435 and 18681 in SysML 1.4 ballots 4 and 5.
SysML 1.3 section 8.3.2.2 Block says: SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType. … A property typed by a SysML ValueType is classified as a value property, and always has composite aggregation. In SysML, we also have Signals. In UML, Signals can have properties. How does SysML then classify properties defined in a Signal? A very strict reading of the SysML spec would suggest that a Signal cannot have any kind of SysML property because a Signal is neither a SysML Block nor a SysML ValueType. However, this is clearly too restrictive in practice. I propose expanding SysML's classification of properties to include SysML Blocks, ValueTypes and Signals. This leads to another question: What are the legal types of a property belonging to a Signal? I propose restricting such properties to be typed by SysML ValueTypes only. This corresponds to the practical situation where a Signal carries a data payload – I.e., it is a message with some data content. Allowing a property belonging to a Signal to be typed by a SysML Block or Signal leads to semantic problems — what would it mean to send / receive such signals?
An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications. At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions. The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows: Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint. Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification. Some of the limitations that have been identified include the following: a) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application. b) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders. c) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information. A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is included below. In the above example, different subviews correspond to the different sections of the document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata). In the example above, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents. d) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others. e) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).
SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively. For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela. These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5). The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind. For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI. Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI. From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre. This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit. To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit. Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length. This is redundant with the fact that metre already specifies length as its Unit::quantityKinds. This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit. The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived. For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection. For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections.
In the figure shown below, Continous and Discrete stereotypes seems to be applied an ActivityParameterNode of an Activity. However, those aforementioned stereotype do not extend ActivityParameterNode but only Parameter and ActivityEdge. Is it an error? In the same order, <<continuous>>, <<discrete>> and <<rate>> are also applied on something called “Object Node”? However, <<Rate>> seems not to extend any node.
In Appendix A there is a list that says: The following are some of 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 ? package diagram - package or model ? parametric diagram - block or constraint block ? requirement diagram - package or requirement ? sequence diagram - interaction ? state machine diagram - state machine ? use case diagram - package Based on my readings, which seems to indicate that the type of element whose namespace contains the elements in the diagram, I would say it should be ? activity diagram - activity ? block definition diagram - block, package, or constraint block, activity, profile ? internal block diagram - block or constraint block ? package diagram - package or model, view, modelLibrary, profile ? parametric diagram - block or constraint block ? requirement diagram - package or requirement, model, view, modelLibrary, ? sequence diagram - interaction ? state machine diagram - state machine, block, operation, use case ? use case diagram ? package, block, view, model, modelLibrary ( I left out some cases of profile, when I couldn?t think of what it would show, but profile could be added to any list that covers package)
Table 8.4 in SysML 1.3 defines the notation for a SysML BindingConnector in terms of an "<<equal>>" keyword. This notation is very expensive in terms of diagram footprint. Without displaying the "<<equal>>" keyword, SysML BindingConnectors become visually indistinguishable from bidirectional SysML assembly connectors. Suggest providing an alternate notation for SysML BindingConnectors in Table 8.4 based on an elegant solution that some SysML tools and SysML RTF members already use, that is, a single "=" symbol without the keyword guillemets, that is, "=", not "<<=>>".
SysML says nothing about how to deal with multiplicity for flow properties matching
The SysML spec does not give any notation for (or example of) specifying the values of an item property participating in an item flow. For example, if water flows in multiple places in the distiller, each should be able to have a specified temperature and dissolved matter % (perhaps as distributions). Perhaps a variant of a property specific type would work, perhaps a callout approach would work. It possible, it would be desirable to allow for multiple item properties:item flows to have the same name within an ibd, as this would be a natural modeling approach (e.g., all the pipes covey the same thing, but with different values).
Table 9.1, ItemFlow: The concrete syntax shows elements from an ibd. But table 9.1. is about bdd. SysML also includes the concept of InformationFlows from UML (compliance level 3). The concrete syntax for an InformationItem or InformationFlow is missing.