Issue 6446: Clarification of Information Flow semantics (uml2-rtf) Source: Pivot Point (Mr. Cris Kobryn, ) Nature: Uncategorized Issue Severity: Summary: Description: Consider the following recommendations to improve Information Flow semantics: b) Allow Information Flow to be specialized and decomposed using aggregation. c) Allow Information Flow between classifiers with ports and interfaces. Make provisions for relating the information flow to a port, such that an Information Flow can flow through a port. d) Allow Information Flows between classifiers with object flows across activity partitions. e) Change the name from Information Flow to Item Flow (or something similar) to allow for the flow of non-information, such as physical items specified in systems engineering applications. Resolution: see above Revised Text: In section 17.2.1 InformationFlow – Constraints Change: 1] The sources and targets of the information flow can only be of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link). into: 1] The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link). Actions taken: November 6, 2003: received issue August 23, 2006: closed issue Discussion: These are very good suggestions but such changes clearly qualify as new features – since they extend the current definition of Information Flows – and are, therefore, out of scope of the FTF. Resolution: b) needs an entire new specification. The combination of these new mechanisms with the relations between targets & sources, the association Information Items is not at all defined. That door is dangerous to open now. I suggest to reject this one. Regarding c): Information flow are explicitly allowed between ports and interfaces. (may be the issue is outdated) d) OK, although I have never seen a dependency drawn between partitions. It also shows an inconsistency in the spec that does not allow sources & target being ActivityNodes. Regarding e) "Information" is purposely a very broad word that encompasses anything we want to exchange between sources and targets. It does not prevent at all "physical items": their circulation is also information. End of Annotations:===== eference: UML 2 Superstructure, OMG doc# ptc/03-08-02, Section 17.2 Issue: Clarification of Information Flow semantics Description: Consider the following recommendations to improve Information Flow semantics: b) Allow Information Flow to be specialized and decomposed using aggregation. c) Allow Information Flow between classifiers with ports and interfaces. Make provisions for relating the information flow to a port, such that an Information Flow can flow through a port. d) Allow Information Flows between classifiers with object flows across activity partitions. e) Change the name from Information Flow to Item Flow (or something similar) to allow for the flow of non-information, such as physical items specified in systems engineering applications. OMG Issue No: 6446 Title: Clarification of Information Flow semantics Source: Telelogic AB (Mr. Cris Kobryn, ckobryn@acm.org) Summary: Consider the following recommendations to improve Information Flow semantics: b) Allow Information Flow to be specialized and decomposed using aggregation. c) Allow Information Flow between classifiers with ports and interfaces. Make provisions for relating the information flow to a port, such that an Information Flow can flow through a port. d) Allow Information Flows between classifiers with object flows across activity partitions. e) Change the name from Information Flow to Item Flow (or something similar) to allow for the flow of non-information, such as physical items specified in systems engineering applications. Discussion: These are very good suggestions but such changes clearly qualify as new features . since they extend the current definition of Information Flows . and are, therefore, out of scope of the FTF. Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , Cc: Subject: RE: Ballot 3 Reissue -- discard old version - resolving critical-path issues for SysML Date: Fri, 20 May 2005 21:53:29 -0700 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVaV0jNHlGPuu8LTqi4zQyS8duBhwDYS9gg > My apologies to all, but due to some belated input (and a screw up on my part), > I have removed 4 proposed resolutions from Ballot 3. They are > > * 6126, 6372, and 8161 (removed until Actions/Activities groups reach consensus on them) > * 6446 (removed because SysML raised objections to the current resolution) There were two issues, not one, on the original Ballot 3 that the SysML Partners submitted and do not want to be deferred: "Issue 6445: Clarification of use case semantics" and "Issue 6446: Clarification of Information Flow semantics". I submitted both of these issues on behalf on the SysML Partners on November 6, 2003, more than 1.5 years ago. These issues are critical path for SysML because we cannot complete the specification of SysML Requirements and ItemFlow constructs without further clarification of the semantics of UseCases and InformationFlows, respectively. Removing Issue 6446 from Ballot 3 may be a start, but raises the questions of when and how this issue will be resolved by the current RTF. Deferring Issue 6445 on the Ballot 3 reissue is also problematic for us, for the reason explained above. Given the importance of these constructs to SysML, if the RTF is unable to provide us with bona fide resolutions (contrast "Closed, No Change", "Defer" resolutions) for these issues we will need to provide recommended changes to the UML2 Superstructure specification with our final SysML submission. Thanks, Cris ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, May 16, 2005 1:33 PM To: uml2-rtf@omg.org Disposition: Defer