Issue 6351: InformationFlow realization (uml2-superstructure-ftf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Revision Severity: Significant Summary: InformationFlow realization should be to more than relationships. It could be to any set of elements Resolution: see above Revised Text: Actions taken: October 20, 2003: received issue March 8, 2005: closed issue Discussion: Philippe Desfray: The realization association can be attached to any kind of "link" that relates "entities" such as classes or parts, and that can convey the information flow . This is typically the case for Dependencies, associations and ... connector. Relationship is supposed to abstract all that kind of "links". However, despite I beleive remembering of a decision to have a regular generalization of all kind of "links" to relationship, it is not the case for "connector" which is a feature. There are two solutions for this : 1 add a new "realization" association from InformationFlow to "connector", or 2 let connector also be a subclass of "relationship". Conrad Bock If Philippe still feels my the earlier revision (realizing “Element”) is too broad, then it would be fine just to include ActivityEdge and Message as possible realizations of InformationFlow, since these are the behavioral elements across which information can flow. Proposed resolution : Add uni-directional associations between InformationFlow and Connector, between InformationFlow and Message, between InformationFlow and ActivityEdge The following changes are required: ?? Replace the diagram in figure 412 with the following one that shows three new explicit import dependencies between InformationFlows and InsternalStructures, InformationFlows and BasicInteractions, InformationFlows and BasicActivities packages: Kernel InternalStructures PrimitiveTypes Models InformationFlows Templates BasicActivities BasicInteractions «merge» «merge» «merge» «import» «import» «import» ?? Replace the diagram in figure 413 by the following diagram: Connector ActivityEdge Message realizingConnector Relationship DirectedRelationship InformationFlow source {subsets source} * InformationItem Classifier represented * * conveyed * 1..* realization * realizingActivityEdge * NamedElement 1..* target {subsets target} * 1..* * * * * realizingMessage * * Adds associations from InformationFLow to Connector, to ActivityEdge, to Message, and redefine the target and source associations from InformationFLow to NamedElement, o Removes the redundant Classifier::representation and Relationship::abstraction roles (since these are directed relationships, the convention is not to name roles that cannot be referenced) ?? Add the following items to the list of Associations on page 532: o realizingConnector : Connector[*] Determines which Connectors will realize the specified flow o realizingActivityEdge : ActivityEdge[*] Determines which ActivityEdges will realize the specified flow o realizingMessage : Message[*] Determines which Messages will realize the specified flow o target : NamedElement[1..*] Defines to which target the conveyed InformationsItems are directed o source : NamedElement[1..*] Defines from which origin the conveyed InformationsItems are initiated End of Annotations:===== me: SysML Company: SysML Partners mailFrom: sanford.friedenthal@lmco.com Nature: Revision Severity: Significant Subject: InformationFlow realization InformationFlow realization should be to more than relationships. It OMG Issue No: 6351 Title: InformationFlow realization Source: INCOSE (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Summary: InformationFlow realization should be to more than relationships. It could be to any set of elements Discussion: Philippe Desfray: The realization association can be attached to any kind of "link" that relates "entities" such as classes or parts, and that can convey the information flow . This is typically the case for Dependencies, associations and ... connector. Relationship is supposed to abstract all that kind of "links". However, despite I beleive remembering of a decision to have a regular generalization of all kind of "links" to relationship, it is not the case for "connector" which is a feature. There are two solutions for this : 1 add a new "realization" association from InformationFlow to "connector", or 2 let connector also be a subclass of "relationship". Proposed resolution (Bran): Add a uni-directional association between InformationFlow and Connector. This should be an alternative to the association to Relationship as specified by an additional constraint. The following changes are required: · Replace the diagram in figure 412 with the following one that shows a new explicit import dependency between InformationFlows and InsternalStructures packages: · Replace the diagram in figure 413 by the following diagram: o Adds an association Connector::connector o Removes the redundant Classifier::representation and Relationship::abstraction roles (since these are directed relationships, the convention is not to name roles that cannot be referenced) · Add the following item to the list of Associations on page 532: o connector : Connector[*] Determines which Connectors will realize the specified flow Disposition: Resolved could be to any set of elements OMG Issue No: 6351 Title: InformationFlow realization Source: INCOSE (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Summary: InformationFlow realization should be to more than relationships. It could be to any set of elements Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved Reply-To: From: "Conrad Bock" To: "Branislav Selic" , , "Guus Ramackers" Subject: RE: Draft of Ballot 11 -- please review Date: Wed, 31 Mar 2004 16:19:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Bran, > OMG Issue No: 6351 > Title: InformationFlow realization Sorry I hadn't followed up on this, but the problem is that connector is not directed, whereas flows are. We shouldn't use navigation to indicate flow direction. Also, the issue is that info flow needs much more flexible implementations that can include objects. The resolution to 6484 refers to info flow on connectors, but should be written to be independent of 6351. Issue 6981 (incorrect grammar for ) removes signficant and useful functionality. I searched the email and didn't see any presentation of this before or dicussion, maybe I missed it. Recommending that 6351 and 6981 be excluded from ballot 11, and 6484 be written to not refer to connectors. Conrad To: Cc: "Guus Ramackers" , uml2-superstructure-ftf@omg.org Subject: RE: Draft of Ballot 11 -- please review X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 2 Apr 2004 00:50:11 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/02/2004 00:50:16, Serialize complete at 04/02/2004 00:50:16 Conrad, In reply to your e-mail: > > OMG Issue No: 6351 > > Title: InformationFlow realization > > Sorry I hadn't followed up on this, but the problem is that connector is > not directed, whereas flows are. We shouldn't use navigation to > indicate flow direction. Also, the issue is that info flow needs much > more flexible implementations that can include objects. This resolution was actually from Philippe Desfray, who originated the concept of information flows in UML. Also, the solution has nothing to do with using navigation -- I am not sure where you got that idea. Finally, I am also unsure where you got the idea that connectors are not directed (they most definitely can be), but, even when they are not why that should be a problem in this case. Information flows are at a very high level of abstraction and the fact that data may follow in both directions is immaterial. For instance, a different information flow could be shown to flow along the same connector in the opposite direction. I will pull this resolution from the draft however. But, I really do not understand your reasons -- it seems that there is some misunderstanding here. > The resolution to 6484 refers to info flow on connectors, but should be > written to be independent of 6351. The same problem here -- I think you have misunderstood the resolution to 6351. Connectors are DEFINITELY one possible channel for communication flows. > Issue 6981 (incorrect grammar for ) removes signficant and > useful functionality. I searched the email and didn't see any > presentation of this before or dicussion, maybe I missed it. There was definitely discussion of this. The problem here is the view that the states in the lifeline MUST refer to internal states of a state machine. This may be the case, but not necessarily, since the states in question could in fact be some externally visible states that have nothing to do with the internal implementation-specific state of the object represented by a lifeline. (In practice, it is usually the case that the state shown on a lifeline is an external state not an internal one.) The resolution does not remove any functionality, but simply removes the restriction that the states shown on a lifeline have to be internal states. Again, I think you are misunderstanding the resolution. > Recommending that 6351 and 6981 be excluded from ballot 11, and 6484 be > written to not refer to connectors. I will remove both of these from the ballot, but, as I said, I feel that all of your objections are misplaced. Cheers, Bran Reply-To: From: "Conrad Bock" To: "Branislav Selic" Cc: "Guus Ramackers" , Subject: RE: Draft of Ballot 11 -- please review Date: Fri, 2 Apr 2004 11:49:08 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > 6351 (InformationFlow realization) > I will pull this resolution from the draft however. But, I > really do not understand your reasons -- it seems that there is > some misunderstanding here. Thanks, but my main concern is that the resolution asks that information flows be able to be realized by any group of elements. Just extending to connectors is not enough. If this is too much, then defer it, and file another issue for connectors as info flow realization. > 6484 > > The resolution to 6484 refers to info flow on connectors, but should be > > written to be independent of 6351. > > The same problem here -- I think you have misunderstood the > resolution to 6351. The proposed resolution to 6484 says that an "information channel", which I assume means an information flow, may be "represented by" connectors, which I assume means realization in Figure 413. In the FAS that isn't possible, because connectors aren't relationships. It assumes 6351 is adopted. Just remove the reference to connectors in 6484 so that 6351 can be addressed independently. > Issue 6981 (incorrect grammar for ) removes signficant and > > useful functionality. I searched the email and didn't see any > > presentation of this before or dicussion, maybe I missed it. > > There was definitely discussion of this. The problem here is the > view that the states in the lifeline MUST refer to internal > states of a state machine. This may be the case, but not > necessarily, since the states in question could in fact be some > externally visible states that have nothing to do with the > internal implementation-specific state of the object represented > by a lifeline. (In practice, it is usually the case that the > state shown on a lifeline is an external state not an internal > one.) The resolution does not remove any functionality, but > simply removes the restriction that the states shown on a > lifeline have to be internal states. Again, I think you are > misunderstanding the resolution. Will look at the messages Mikolai referring to. Not sure how dependence on state machines could be removed without removing functionality. Thanks, Conrad To: , "DESFRAY Philippe" Cc: "Guus Ramackers" , uml2-superstructure-ftf@omg.org Subject: Problems with Information flow resolutions and interactions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 2 Apr 2004 14:14:22 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/02/2004 14:14:24, Serialize complete at 04/02/2004 14:14:24 Conrad, > > 6351 (InformationFlow realization) > > > I will pull this resolution from the draft however. But, I > > really do not understand your reasons -- it seems that there is > > some misunderstanding here. > > Thanks, but my main concern is that the resolution asks that information > flows be able to be realized by any group of elements. Just extending > to connectors is not enough. If this is too much, then defer it, and > file another issue for connectors as info flow realization. Philippe felt that it was sufficient to just add connectors. I took him for his word, since he defined the feature. What other kinds of elements do you think need to be added? If this gets too sophisticated, it sounds like we are extending the original definition, which kind of sounds like it is out of scope. Maybe the best thing to do then is to defer it. > > 6484 > > > > The resolution to 6484 refers to info flow on connectors, but should be > > > written to be independent of 6351. > > > > The same problem here -- I think you have misunderstood the > > resolution to 6351. > > The proposed resolution to 6484 says that an "information channel", which > I assume means an information flow, may be "represented by" connectors, > which I assume means realization in Figure 413. In the FAS that isn't > possible, because connectors aren't relationships. It assumes 6351 is > adopted. Just remove the reference to connectors in 6484 so that 6351 > can be addressed independently. I think your assumptions are wrong. The complaint was about the fact that the term was undefined. I added an informal definition since there is no formal concept. It was not necessarily meant to be complete. I have no idea why you are talking about relationships here. It is perfectly clear that connectors can represent channels through which information flows. I think your desire to be precise here is somewhat misplaced. Information flows were supposed to be very abstract things and trying to pin them down the way you are doing is the wrong thing to do. I will let Philippe defend this stuff (I personally objected to the introduction of this feature in the U2P precisely because I knew this kind of crap would start...) > > Issue 6981 (incorrect grammar for ) removes signficant and > > > useful functionality. I searched the email and didn't see any > > > presentation of this before or dicussion, maybe I missed it. > > > > There was definitely discussion of this. The problem here is the > > view that the states in the lifeline MUST refer to internal > > states of a state machine. This may be the case, but not > > necessarily, since the states in question could in fact be some > > externally visible states that have nothing to do with the > > internal implementation-specific state of the object represented > > by a lifeline. (In practice, it is usually the case that the > > state shown on a lifeline is an external state not an internal > > one.) The resolution does not remove any functionality, but > > simply removes the restriction that the states shown on a > > lifeline have to be internal states. Again, I think you are > > misunderstanding the resolution. > > Will look at the messages Mikolai referring to. Not sure how dependence > on state machines could be removed without removing functionality. By removing this needlessly restrictive constraint, we are actually ADDING functionality. The constraint limited state invariant labels to ONLY the names of states of a behavior state machine -- this is clearly overly constraining in addition to violating encapsulation. Bran Bran Reply-To: From: "DESFRAY Philippe" To: "'Branislav Selic'" , Cc: "'Guus Ramackers'" , Subject: RE: Problems with Information flow resolutions and interactions Date: Mon, 5 Apr 2004 10:09:49 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Conrad, I believe that there is some misunderstanding on this issue. >>>> Thanks, but my main concern is that the resolution asks that information flows be able to be realized by any group of elements. Well, not exactly, the requirement is that any kind of "link/relationship" be able to convey information items supported by the information flow. The problem is that at the time of the construction of this metamodel (everything moving in parallel anywhare), it was intended (fair intention should I say) that a relationship be an abstraction of almost (forget generalization) every kind of "link" that can exist between elements. This works fine for dependencies and associations, but fails for connectors. Usage of connectors for information flows is one very important use case. Given that, Yes it would be preferable that a proper abstraction be defined for all kinds of "links", but this is quite a havy change to the metamodel. My opinion is that if we add that association between Information FLow and connectors, then we do support all the most important information flow modelling use cases. -- Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoye : vendredi 2 avril 2004 21:14 A : conrad.bock@nist.gov; DESFRAY Philippe Cc : Guus Ramackers; uml2-superstructure-ftf@omg.org Objet : Problems with Information flow resolutions and interactions Conrad, > > 6351 (InformationFlow realization) > > > I will pull this resolution from the draft however. But, I > > really do not understand your reasons -- it seems that there is > > some misunderstanding here. > > Thanks, but my main concern is that the resolution asks that information > flows be able to be realized by any group of elements. Just extending > to connectors is not enough. If this is too much, then defer it, and > file another issue for connectors as info flow realization. Philippe felt that it was sufficient to just add connectors. I took him for his word, since he defined the feature. What other kinds of elements do you think need to be added? If this gets too sophisticated, it sounds like we are extending the original definition, which kind of sounds like it is out of scope. Maybe the best thing to do then is to defer it. > > 6484 > > > > The resolution to 6484 refers to info flow on connectors, but should be > > > written to be independent of 6351. > > > > The same problem here -- I think you have misunderstood the > > resolution to 6351. > > The proposed resolution to 6484 says that an "information channel", which > I assume means an information flow, may be "represented by" connectors, > which I assume means realization in Figure 413. In the FAS that isn't > possible, because connectors aren't relationships. It assumes 6351 is > adopted. Just remove the reference to connectors in 6484 so that 6351 > can be addressed independently. I think your assumptions are wrong. The complaint was about the fact that the term was undefined. I added an informal definition since there is no formal concept. It was not necessarily meant to be complete. I have no idea why you are talking about relationships here. It is perfectly clear that connectors can represent channels through which information flows. I think your desire to be precise here is somewhat misplaced. Information flows were supposed to be very abstract things and trying to pin them down the way you are doing is the wrong thing to do. I will let Philippe defend this stuff (I personally objected to the introduction of this feature in the U2P precisely because I knew this kind of crap would start...) > > Issue 6981 (incorrect grammar for ) removes signficant and > > > useful functionality. I searched the email and didn't see any > > > presentation of this before or dicussion, maybe I missed it. > > > > There was definitely discussion of this. The problem here is the > > view that the states in the lifeline MUST refer to internal > > states of a state machine. This may be the case, but not > > necessarily, since the states in question could in fact be some > > externally visible states that have nothing to do with the > > internal implementation-specific state of the object represented > > by a lifeline. (In practice, it is usually the case that the > > state shown on a lifeline is an external state not an internal > > one.) The resolution does not remove any functionality, but > > simply removes the restriction that the states shown on a > > lifeline have to be internal states. Again, I think you are > > misunderstanding the resolution. > > Will look at the messages Mikolai referring to. Not sure how dependence > on state machines could be removed without removing functionality. By removing this needlessly restrictive constraint, we are actually ADDING functionality. The constraint limited state invariant labels to ONLY the names of states of a behavior state machine -- this is clearly overly constraining in addition to violating encapsulation. Bran Bran ATT00152.htm Reply-To: From: "Conrad Bock" To: Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Sun, 25 Apr 2004 11:23:16 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Philippe, > Generalizing InformationFlow realization to Element would certainly > enhance the power and generality of this feature. But there are > problems if you consider the constraints set on IF: > > [1] The sources and targets of the information flow can only be of the > following kind : Actor, Node, Use Case, Artifact, Class, Component, Port, > Property, Interface, Package, and InstanceSpecification except when its > classifier is a relationship (i.e. it represents a link). > > [2] The sources and targets of the information flow must conform with > the sources and targets or conversely the target and sources of the > realization relationships, if any. What does "conform" mean? There isn't any OCL. BTW, the source or target of an information flow could be a Part. > >>> How about object flow in activities, or messages in interactions? > > This makes sense, but given the realization element, we need in an > abstract way to express the notions of target and source. Hard to say > for activity. And must be specifically expressed for messages (as > for connectors, you might object). The example from systems engineering is an information flow on a connector that is realized by an object flow on an activity, or in more detailed cases, realized by objects flows, invocation actions, and pins. Could post these, if you like. > If we go to generalize IF realization to element, then we are very > loose in the semantic description, and even in the notation. The semantics is very loose as it is. The restrictions on source/target don't make the constructs any better defined. > If we want to add important specific cases, a pragmatic path is to > add one by one these cases: We'd probably leave something out users wanted (like Part above). As an analogy, we tightened the semantics of partitions in UML 2 activities, and now they don't work for some of the systems engineering applications. Constructs like information flow and partitions are intentionally high-level. Let's resist trying to make them tighter just because they don't look like other parts of UML. UML should support early design stages as well as late, and the early ones are necessarily underconstrainted. > I mentioned conectors, you added messages. and object flow edges (another one missed!). There aren't abstract classes over all these things. Are you suggesting to introduce one? Reply-To: From: "DESFRAY Philippe" To: , Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Mon, 26 Apr 2004 19:45:28 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Conrad, >>> UML should support early design stages as well as late, and the early ones are necessarily underconstrainted. I heartfully agree. >>> > I mentioned conectors, you added messages. and object flow edges (another one missed!). There aren't abstract classes over all these things. Are you suggesting to introduce one? <<<< I deeply regret that the most abstract metamodel core is not a "node/link" metamodel, from which derive the related notions. Relationship is a kind of missed attempt to this. But I think it is out of scope to target that. May be an abstraction that represents all elements being able to convey an information Item can be helpful. Still it is an important change. Please post the examples of system engineering that you mention. That will certainly help. -- Philippe -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : dimanche 25 avril 2004 17:23 À : uml2-superstructure-ftf@omg.org Objet : RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Philippe, > Generalizing InformationFlow realization to Element would certainly > enhance the power and generality of this feature. But there are > problems if you consider the constraints set on IF: > > [1] The sources and targets of the information flow can only be of the > following kind : Actor, Node, Use Case, Artifact, Class, Component, Port, > Property, Interface, Package, and InstanceSpecification except when its > classifier is a relationship (i.e. it represents a link). > > [2] The sources and targets of the information flow must conform with > the sources and targets or conversely the target and sources of the > realization relationships, if any. What does "conform" mean? There isn't any OCL. BTW, the source or target of an information flow could be a Part. > >>> How about object flow in activities, or messages in interactions? > > This makes sense, but given the realization element, we need in an > abstract way to express the notions of target and source. Hard to say > for activity. And must be specifically expressed for messages (as > for connectors, you might object). The example from systems engineering is an information flow on a connector that is realized by an object flow on an activity, or in more detailed cases, realized by objects flows, invocation actions, and pins. Could post these, if you like. > If we go to generalize IF realization to element, then we are very > loose in the semantic description, and even in the notation. The semantics is very loose as it is. The restrictions on source/target don't make the constructs any better defined. > If we want to add important specific cases, a pragmatic path is to > add one by one these cases: We'd probably leave something out users wanted (like Part above). As an analogy, we tightened the semantics of partitions in UML 2 activities, and now they don't work for some of the systems engineering applications. Constructs like information flow and partitions are intentionally high-level. Let's resist trying to make them tighter just because they don't look like other parts of UML. UML should support early design stages as well as late, and the early ones are necessarily underconstrainted. > I mentioned conectors, you added messages. and object flow edges (another one missed!). There aren't abstract classes over all these things. Are you suggesting to introduce one? Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Thu, 29 Apr 2004 14:10:38 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Philippe, > As the submitter of that resolution I am officially withdrawing it -- > that is, the resolution to issue 6351 is no longer part of ballot 12. Thanks. If Philippe still feels my the earlier revision is too broad (haven't heard), then it would be fine just to include ActivityEdge and Message as possible realizations of InformationFlow, since these are the behavioral elements across which information can flow. Conrad Conrad Reply-To: From: "DESFRAY Philippe" To: , "'uml2ftf'" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Fri, 30 Apr 2004 15:18:11 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Yes Conrad, I do not feel confortable in broadening that much the realization capabilities. I would be glad if we just add connectors (6351), activityEdge and Message as other possibles realizations in the metamodel. -- Philippe -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoye : jeudi 29 avril 2004 20:11 A : uml2ftf Objet : RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Bran, Philippe, > As the submitter of that resolution I am officially withdrawing it -- > that is, the resolution to issue 6351 is no longer part of ballot 12. Thanks. If Philippe still feels my the earlier revision is too broad (haven't heard), then it would be fine just to include ActivityEdge and Message as possible realizations of InformationFlow, since these are the behavioral elements across which information can flow. Conrad Conrad Reply-To: From: "Conrad Bock" To: "'uml2ftf'" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Fri, 30 Apr 2004 10:53:04 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Philippe, > I do not feel confortable in broadening that much the realization > capabilities. I would be glad if we just add connectors (6351), > activityEdge > and Message as other possibles realizations in the metamodel. Why? Conrad Reply-To: From: "DESFRAY Philippe" To: , "'uml2ftf'" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Mon, 3 May 2004 09:54:14 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Conrad, The reason why is that I am missing Use Cases. What the metamodel addresses corresponds to use cases that I have encountered. Connectors was intended to be adressed, but the IF metamodel did not follow the connector's metamodel evolutions. Activity edges and messages are two other important cases that you mention. So specicially adressing these cases is a good option. Whidely opening the Information flow realization ability shall make sense both notationnaly and semantically for each case. For any case of edges, links, dependencies, etc. this does make sense. FOr the other, I do not have seen examples, and I would prefer a careful approach before allowing IF realization for any "Element". I do beleive that here we adress the vast majority of important users needs. I can obviously be wrong, but need usage feedbacks to be more confortable on opening that door. -- Philippe -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoye : vendredi 30 avril 2004 16:53 A : 'uml2ftf' Objet : RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Philippe, > I do not feel confortable in broadening that much the realization > capabilities. I would be glad if we just add connectors (6351), > activityEdge > and Message as other possibles realizations in the metamodel. Why? Reply-To: From: "Conrad Bock" To: , "'uml2ftf'" Subject: RE: Problems with Information flow resolutions, 6351 (InformationFlow realization) Date: Sun, 9 May 2004 21:03:08 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Philippe, > The reason why is that I am missing Use Cases. What the metamodel > addresses corresponds to use cases that I have encountered. I'll provide some. > Connectors was intended to be adressed, but the IF metamodel did not > follow the connector's metamodel evolutions. Activity edges and > messages are two other important cases that you mention. So > specicially adressing these cases is a good option. What is the use case for connectors? > Whidely opening the Information flow realization ability shall make > sense both notationnaly and semantically for each case. Where are the cases laid out for the current functionality? OMG Issue No: 6351 Title: InformationFlow realization Source: INCOSE (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Summary: InformationFlow realization should be to more than relationships. It could be to any set of elements Discussion: Philippe Desfray: The realization association can be attached to any kind of "link" that relates "entities" such as classes or parts, and that can convey the information flow . This is typically the case for Dependencies, associations and ... connector. Relationship is supposed to abstract all that kind of "links". However, despite I beleive remembering of a decision to have a regular generalization of all kind of "links" to relationship, it is not the case for "connector" which is a feature. There are two solutions for this : 1 add a new "realization" association from InformationFlow to "connector", or 2 let connector also be a subclass of "relationship". Conrad Bock If Philippe still feels my the earlier revision (realizing .Element.) is too broad, then it would be fine just to include ActivityEdge and Message as possible realizations of InformationFlow, since these are the behavioral elements across which information can flow. Proposed resolution : Add uni-directional associations between InformationFlow and Connector, between InformationFlow and Message, between InformationFlow and ActivityEdge The following changes are required: · Replace the diagram in figure 412 with the following one that shows three new explicit import dependencies between InformationFlows and InsternalStructures, InformationFlows and BasicInteractions, InformationFlows and BasicActivities packages: · Replace the diagram in figure 413 by the following diagram: Adds associations from InformationFLow to Connector, to ActivityEdge, to Message, and redefine the target and source associations from InformationFLow to NamedElement, o Removes the redundant Classifier::representation and Relationship::abstraction roles (since these are directed relationships, the convention is not to name roles that cannot be referenced) · Add the following items to the list of Associations on page 532: o realizingConnector : Connector[*] Determines which Connectors will realize the specified flow o realizingActivityEdge : ActivityEdge[*] Determines which ActivityEdges will realize the specified flow o realizingMessage : Message[*] Determines which Messages will realize the specified flow o target : NamedElement[1..*] Defines to which target the conveyed InformationsItems are directed o source : NamedElement[1..*] Defines from which origin the conveyed InformationsItems are initiated Disposition: Resolved ActivityEdge and messages vi issue7234 Conrad Subject: RE: Revised ballot 15: Please vote Date: Fri, 11 Jun 2004 17:05:56 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised ballot 15: Please vote Thread-Index: AcRI+4zDEWWOXOPUTC2n2Bp3ivY8gwG8Rnzg From: "Pete Rivett" To: "Branislav Selic" , Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i5BL1Wun004651 Adaptive votes YES to all the issues in Ballot 15 except Issue 6351 and 6429. The 'realizations' in Issue 6351 seem quite at variance with the concept of Realization defined in 7.14.6 - even to the extent of the 'direction' being the wrong way round. The discussion of 6429 only trivially addresses the question and even then adds nothing to the specification to clarify. Minor points: - it seems to me that 6210 should really be Closed No Change (which is what was done for 6148 likewise addressed by an existing resolution) or Duplicate. - 6251 should be clearer about where the change is being made. - 6280 is a shared issue and should now be voted on by Infra - 6280 adds the constraint " [3] Stereotype names should not clash with keyword names for the extended model element." However what we do not yet have is a clear statement of the latter (keywords). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, June 03, 2004 12:35 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Revised ballot 15: Please vote With due apologies to all, here is a revised version of ballot 15. (Since no one has voted on it yet, I assume that this rather late revision is acceptable. Still, such late changes will not be the rule in future ballots.) The following changes were made: (1) the resolution to issue 6149 has been removed from the ballot by Thomas since it is coupled to the resolution of issue 7335. (2) the resolution to issue 6280 was added since it was accidentally omitted from the ballot. Regards, Bran