Issue 9778: constraints section 9.3.2.4
Issue 10047: SysML: Protocol State Machines needed
Issue 10048: SysML: UML Qualifieed Associations
Issue 10058: SysML: Generalizing Activites
Issue 10059: SysML: Interfaces on Flow Ports
Issue 10061: SysML: << and >> vs < and >
Issue 10143: Semantic of default value in the scope of a DistributedProperty
Issue 10342: Section: 9.3.2.8 ItemFlow
Issue 10371: How to use property specific types for atomic flow ports?
Issue 10410: Section: 9.3.2.5 FlowPort
Issue 10472: Section: 6.1 Levels of Formalism
Issue 10500: Section: Figure 14.2
Issue 10642: Timing diagrams
Issue 11011: Block namespace compartment: Are external relationships allowed
Issue 11117: Section: 12. Interactions
Issue 11276: Issue: Nested connector ends
Issue 11333: BindingConnector
Issue 11493: Lack of notation for units and dimensions on values.
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 11498: <<continuous>>
Issue 11499: Parts are added directly into package
Issue 11623: Address potential points of convergence between MARTE and SysML
Issue 11627: SysML: Interaction diagram and Data-based comm of SysML
Issue 11628: SysML:Ports can't be blocks
Issue 11648: SysML Interactions
Issue 11653: Section: 5.3
Issue 12123: Inferred Allocation on Allocate Activity Partitions
Issue 12125: Item Flows on Activity Diagrams
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 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 12152: Annex B / Figure B.35
Issue 12154: Annex B / Figure B.38
Issue 12156: Section: 9.3.2
Issue 12160: Annex B, Figure B.29
Issue 12222: 09.Ports and Flows: 9.3.2.3 FlowPort, 9.3.2.7 Standard Port
Issue 12255: Section: Generalization of stereotyped elements
Issue 12268: Section: 8.3.2.1
Issue 12269: Section: More constraints for flow ports
Issue 12353: 08.Blocks, 8.2.2 Internal Block Diagram:
Issue 12365: p.46 under 8.3.2.4 DistributedProperty
Issue 12366: Figure B.34 and Figure B.35
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 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 13177: Requirements interchange issue
Issue 13178: Port Decomposition of a Flow Specification Discussion
Issue 13179: SysML/Modelica Integration Discussion
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 13263: Support BDD's for State Machines
Issue 13342: AllocateActivityPartition and UML 2 semantics
Issue 13348: Inability to represent dependent, independent parameters on constraint properties
Issue 13840: Allocations should not generate dependencies
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 14055: Proposal to have a stereotype for reference nested property
Issue 14058: Flow port compatibility with behavior
Issue 14079: SysML RTF: 11.4 Activity Usage Sample: ControlOperator has regular pins (2)
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 9778: constraints section 9.3.2.4 (sysml-rtf)
Click here for this issue's archive.
Source: International Business Machines (Mr. John D. Low, jlow@us.ibm.com)
Nature: Revision
Severity: Significant
Summary:
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
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
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
Whenever possible, the spec should use the correct symbols « and » which are easily available in Visio
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
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 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
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 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
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
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
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
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?
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
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)
<<continuous>> is stereotype of Parameter and ActivityEdge, but is used on ObjectNodes (figure 11.10). It must extend ObjectNode too.
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
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
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
In the notation table for sequence diagrams there is no reference to interaction parameters, or to arguments of interaction uses.
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
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
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
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
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
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.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.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
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
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
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.
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 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.
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 Summary: 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
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
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
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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
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 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
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."
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 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?
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 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
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: Activity Properties should be accessible in Activity diagrams for decision making
Resolution: 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)
Resolution: 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
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 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.
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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.
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.
Discussion: 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. 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?
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)
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.
Discussion: This issue is deferred because no other proposed resolution was voted on during the schedule of the SysML 1.2 RTF. Disposition: Deferred
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.
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.
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.
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.
Discussion: Multiple proposals and extensive discussion on metamodel extensions and/or diagram extensions to support a partition or grouping capability of elements 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 most recently proposed resolution, which is being included here for future reference: Resolution: It is convenient to be able to group model elements based on a defined criterion. Especially for complex systems it is mandatory to distinguish different aspects in the model. The point is that participating in a group shall not imply any kind of ownership. Then, the word “group” will be preferred to “partition” in the resolution because the concept of partition suggests that participations in those groups are mutually exclusive. Unfortunately, there is no meta-class in UML that supports the concept of “collecion”. Nevertheless the Constraint meta-class could be extended for that purpose. It's a NamedElement, it's packageable, it can designate group elements using their constrainedElement association, and the criterion for specifying a valid element of the group can be defined via the constraint expression. In addition, a group can include subgroups as its elements1. A view is proposed to be a specialization of a group that conforms to a viewpoint. Currently a view uses the import relationship to assign elements to the view. This proposal for view will not include the feature of the import relationship of not requiring the use of qualified names, but will allow non-packageable elements to be included in the view. The ability to use unqualified names can be provided by including the view in a package that will have the required import relationships. Fig. B.27 and 7.3 in the SysML 1.1 specification document are currently invalid. They show a view with elements inside the package symbol that indicates membership. Views do not own elements and accept constraints and comments. Elements are bound to the view with the constrainedElement association. The proposed diagram extension of this resolution allows that kind of a view notation and makes fig. B.27 and 7.3. valid.
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.
Discussion: Extensive discussion on proposed extensions to support a “Markup String” capability, to at least partially address this issue, 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 most recently proposed resolution, which is being included here for future reference:
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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
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.
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).
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).
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).
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.)
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.)”
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
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.