Issue 9778: constraints section 9.3.2.4 (sysml-rtf) Source: International Business Machines (Mr. John D. Low, jlow(at)us.ibm.com) Nature: Revision Severity: Significant Summary: Specify matching rules that enable flow ports and client server ports to be connected. Resolution: Following is the discussion from a previous deferred resolution by the SysML FTF: It was felt that there is a need for experience in SysML prior to making such a change or extension. Deferred for future consideration. This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred Revised Text: Actions taken: May 25, 2006: received issue 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 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 End of Annotations:===== s is issue # 9778 constraints section 9.3.2.4 Date: Sat, 18 Nov 2006 10:47:21 -0500 From: "Friedenthal, Sanford" Subject: RE: 061123 Proposed Ballot, comments To: conrad.bock@nist.gov, Jack Low , sysml-ftf@omg.org Thread-Topic: 061123 Proposed Ballot, comments Thread-Index: AccJnni15xzZf6N7QiSm3405c46+kwBf1d+wAAJ9zgA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Nov 2006 15:47:22.0305 (UTC) FILETIME=[D62A6B10:01C70B28] Conrad, Jack Regarding your comments below. 10038 - The confused wording is what I was referring to. Do you have some suggested revised wording to eliminate the confusion? 9778- You referred to comments on this issue, but I don't see them. 10029 - Seems like a mismatch between something that is stereotyped by a block property or a value type in the revised wording. One is a property and the other is a type. I would think they would both be properties or both be types. "The value of itemProperty must be stereotyped by BlockProperty or ValueType". -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Saturday, November 18, 2006 9:30 AM To: 'Jack Low'; sysml-ftf@omg.org Subject: RE: 061123 Proposed Ballot, comments Hi Jack, Here are my comments on the draft ballot. There are some critical aspects of flow ports that need to be addressed. Chapter leads, Let me know if you have any questions/comments about these. Sandy, See comments on yours in 10038, 9778. Conrad - Issue 10035 (Port Semantic Variation) The resolution seems to agree that semantic variation points need an enumeration, but then none is defined in the changed text. An enumeration is a datatype giving names for the semantic options. Users can select from these to specify the particular semantic option they are using, and interchange this choice with model like any other metaattribute value. This ensures the receiver uses the same semantic option to interpret the model. - Issue 9876 (Figure 9.2) (also applies to Issue 10031, ItemFlow constraints [1] and [3]) In the revised text, the new constraint in 9.3.2.8 should read "The value of itemProperty must be stereotyped by BlockProperty". (But see 10029 below to include ValueType). - Issue No: 10033 This refers to issue 10037, which is unrelated, and to issue 10034, which doesn't resolve the issue. - Issue 10038 (Flow property values wording) Sandy, interfaces in software don't have values, but are "supported by" objects that do. The wording is confusing, because it sounds like the interface property has a value. - Issue 10029 (ItemFlow constraint) (also applies to Issue 10031, ItemFlow constraints [1] and [3]. The resolution says the filer's assumption is correct (as does constraint 2 of ItemFlow 9.3.2.8), but the resolution doesn't change the spec to reflect it. In Figure 9.2, itemProperty currently prevents data type values from flowing, because it is typed by a BlockProperty. Suggest this resolution: in issue 9876, have the new constraint be "The value of itemProperty must be stereotyped by BlockProperty or ValueType". - Issue 10036 (Flow ports direction for non-atomic ports) The resolution didn't address the issue: why can't a non-atomic port have direction (ie, why can't multiple items flow in a direction)? I claim they can, with the following constraint added to Flow Port: [] If the FlowPort is Non-Atomic, and the FlowSpecification typing the port has flow properties that are all in direction, the FlowPort direction is in (or out if isConjugated=true). If the flow properties are all out, the FlowPort direction is out (or in if isConjugated=true). If flow properties are both in and out, the direction is inout. With constraints [3] modified to allow direction. - Issue 10031 (ItemFlow constraints [1] and [3]) In revised text, can remove "stand for," it is undefined. The item property is a property of the block. - Issue 10034 (Relaying to properties) The revised text says: ` The new values relayed from the behavioral port to its owner ` override the existing values of the owner's properties This contradicts other text in the spec (9.3.2.5 FlowPort, 4th assifier behavior. See issue 10033. And the resolution doesn't say which properties are overriden. - Issues 10030 (ItemFlow constraint [4]) Congrats to whoever caught me making a usage error. :) Sandy, Information Flows in UML can be realized by multiple connectors, etc (see Figure 17.2 of ptc/06/04-02), so for a particular connector it is a usage, and the type of thing flowing may be narrower than the conveyed cvlassifier. - Issue 10072 (restriction on no more than 1 item property per item flow is unclear) Can item flows be used between nonatomic ports? If so, there would be multiple item properties. - Issues 10025 (Single multiple confusion) The revised text has a type/instance miswording. It should be: "This can include typing an atomic flow port with a single type for the items that flows in our out, or typing a non-atomic flow port with a flow specification which lists multiple types for items that flow." - 10032 (Relaying Instances) The revised text wording doesn't parse, remove "single". It should be: "Atomic Flow Ports relay instances of a Block, Value-Type, Data-Type or Signal classifiers." You could have a separate sentence saying that ports can have only one type. aragraph): The relay of items of a behavioral FlowPort is bound only to Specify matching rules that enable flow ports and client server ports to be connected.