Issue 7777: Associations between interfaces (uml2-superstructure-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows an association between example interfaces IAlarm, ISensor, and has this caption: IAlarm is the required interface for any classifier implementing Isensor; conversely, Isensor is the required interface for any classifier implementing IAlarm. The text description says: A set of interfaces constituting a protocol may be depicted as interfaces with associations between them Is this just notation, or are associations really in the model? - If it is just notation, what is the model? - If it is the model, isn't it overly restrictive? The modeler's intention might be that these are both required interfaces, declaring that the two support classes will include an association between them. I thought interface were extended in UML 2 to include associations generally. Resolution: Revised Text: Actions taken: August 27, 2004: received issue Discussion: End of Annotations:===== te: Fri, 27 Aug 2004 10:29:03 -0400 From: Conrad Bock To: uml2-superstructure-ftf@omg.org Subject: Associations between interfaces User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 206.47.204.99 X-NIST-MailScanner: Found to be clean X-MailScanner-From: conrad.bock@nist.gov Interfacers, The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows an association between example interfaces IAlarm, ISensor, and has this caption: IAlarm is the required interface for any classifier implementing Isensor; conversely, Isensor is the required interface for any classifier implementing IAlarm. The text description says: A set of interfaces constituting a protocol may be depicted as interfaces with associations between them Is this just notation, or are associations really in the model? - If it is just notation, what is the model? - If it is the model, isn't it overly restrictive? The modeler's intention might be that these are both required interfaces, declaring that the two support classes will include an association between them. I thought interface were extended in UML 2 to include associations generally. Thanks, Conrad Date: Fri, 27 Aug 2004 10:31:58 -0400 From: Conrad Bock To: uml2-superstructure-ftf@omg.org Subject: Associations between interfaces User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 206.47.204.99 X-NIST-MailScanner: Found to be clean X-MailScanner-From: conrad.bock@nist.gov Correction Interfacers, The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows an association between example interfaces IAlarm, ISensor, and has this caption: IAlarm is the required interface for any classifier implementing Isensor; conversely, Isensor is the required interface for any classifier implementing IAlarm. The text description says: A set of interfaces constituting a protocol may be depicted as interfaces with associations between them Is this just notation, or are associations really in the model? - If it is just notation, what is the model? - If it is the model, isn't it overly restrictive? The modeler's intention might be that these are both provided interfaces, declaring that the two supporting classes will include an association between them. I thought interface were extended in UML 2 to include associations generally. Thanks, Conrad To: Conrad Bock Cc: uml2-superstructure-ftf@omg.org Subject: Re: Associations between interfaces X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 27 Aug 2004 10:54:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/27/2004 11:09:44, Serialize complete at 08/27/2004 11:09:44 Conrad, In reply: > A set of interfaces constituting a protocol may be depicted as > interfaces with associations between them > > Is this just notation, or are associations really in the model? > > - If it is just notation, what is the model? > > - If it is the model, isn't it overly restrictive? The modeler's > intention might be that these are both required interfaces, > declaring that the two support classes will include an association > between them. I thought interface were extended in UML 2 to include > associations generally. The associations are really in the model. The intent of that figure was not to express a restriction on how associations are used with interfaces, but to illustrate a specific case. In that particular case, the "1" multiplicities impose a constraint. Bran Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 27 Aug 2004 08:23:42 -0700 To: uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: Re: Associations between interfaces ... The modeler's intention might be that these are both provided interfaces, declaring that the two supporting classes will include an association between them. If we go this route, won't we need to have some way to distinguish an association between interfaces from a requirement placed on classes presenting those interfaces. I thought interface was extended in UML 2 to include associations generally. So did I. ....... I wonder if we are here stumbling over a consequence of the combination in UML of the general meaning of association as a declaration of some relationship between instances of the associated classifiers and the UML specific meaning of association as a declaration of, forgive me, references (properties holding references). There is no way we are going to deal with that now, but: Let's not lose the ability to use association to declare relationships between interfaces such as the one in the example. Cordially, Joaquin To: Conrad Bock Cc: uml2-superstructure-ftf@omg.org Subject: Re: Associations between interfaces X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 27 Aug 2004 13:12:15 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/27/2004 11:12:16, Serialize complete at 08/27/2004 11:12:16 Conrad, I'm not sure I understand this area fully either, but my interpretation of the spec is below... Conrad Bock wrote on 08/27/2004 10:29:03 AM: > > Interfacers, > > The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows > an association between example interfaces IAlarm, ISensor, and has this > caption: > > IAlarm is the required interface for any classifier implementing > Isensor; conversely, Isensor is the required interface for any > classifier implementing IAlarm. > > The text description says: > > A set of interfaces constituting a protocol may be depicted as > interfaces with associations between them > > Is this just notation, or are associations really in the model? > An Interface can have ownedAttributes (a Property) which can be the memberEnd or ownedEnd of an Association, so associations are supported between interfaces. However, we should be careful here about using associations to "depict" something between interfaces. There are rules that any implementingClassifier must provide the attributes and behaviors for the attributes and operations specified in interfaces it realizes. In the case of the connection between provided and required interfaces, using an association may imply constraints beyond what the modeler intended because implementingClassifiers would be required to provide the associations as the communication mechanism rather than some other means. Contrast with realizations for provided interfaces, <> dependences for required interfaces, and connectors between them indicating some communication path, but not explicitly how that path is provided. > - If it is just notation, what is the model? > Associations between interfaces is in the model, but it should simply mean that implementing classifiers have to provide the specified associations. This probably shouldn't be coupled with connections between provided and required interfaces as it provides two notations for the same thing, and some confusion about what it means for an interface to specify something its implementing classifiers must realize. > - If it is the model, isn't it overly restrictive? The modeler's > intention might be that these are both required interfaces, > declaring that the two support classes will include an association > between them. I thought interface were extended in UML 2 to include > associations generally. > You could use a connector for more flexibility. > Thanks, > > Conrad > From: Eran Gery To: Conrad Bock Cc: uml2-superstructure-ftf@omg.org Subject: RE: Associations between interfaces Date: Mon, 30 Aug 2004 13:14:35 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Conrad, The importance of declaring associations between interfaces IS to impose a "constraint" on the implemention classes to implement them. So if I have a class realizing Isensor I can make sure than in an internal structure it can be linked (via a connector) to a class realizing IAlarm. That was the oroginal rationale behind that example when I put it there... In the original script I also had the internal structure example, which is no longer there for some reason. Eran -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, August 27, 2004 8:12 PM To: Conrad Bock Cc: uml2-superstructure-ftf@omg.org Subject: Re: Associations between interfaces Conrad, I'm not sure I understand this area fully either, but my interpretation of the spec is below... Conrad Bock wrote on 08/27/2004 10:29:03 AM: > > Interfacers, > > The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows > an association between example interfaces IAlarm, ISensor, and has this > caption: > > IAlarm is the required interface for any classifier implementing > Isensor; conversely, Isensor is the required interface for any > classifier implementing IAlarm. > > The text description says: > > A set of interfaces constituting a protocol may be depicted as > interfaces with associations between them > > Is this just notation, or are associations really in the model? > An Interface can have ownedAttributes (a Property) which can be the memberEnd or ownedEnd of an Association, so associations are supported between interfaces. However, we should be careful here about using associations to "depict" something between interfaces. There are rules that any implementingClassifier must provide the attributes and behaviors for the attributes and operations specified in interfaces it realizes. In the case of the connection between provided and required interfaces, using an association may imply constraints beyond what the modeler intended because implementingClassifiers would be required to provide the associations as the communication mechanism rather than some other means. Contrast with realizations for provided interfaces, <> dependences for required interfaces, and connectors between them indicating some communication path, but not explicitly how that path is provided. > - If it is just notation, what is the model? > Associations between interfaces is in the model, but it should simply mean that implementing classifiers have to provide the specified associations. This probably shouldn't be coupled with connections between provided and required interfaces as it provides two notations for the same thing, and some confusion about what it means for an interface to specify something its implementing classifiers must realize. > - If it is the model, isn't it overly restrictive? The modeler's > intention might be that these are both required interfaces, > declaring that the two support classes will include an association > between them. I thought interface were extended in UML 2 to include > associations generally. > You could use a connector for more flexibility. > Thanks, > > Conrad > Reply-To: From: "Conrad Bock" To: Subject: RE: Associations between interfaces Date: Tue, 31 Aug 2004 09:26:11 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Interfacers, > [Bran] The intent of that figure was not to express a restriction on > how associations are used with interfaces, but to illustrate a > specific case. In that particular case, the "1" multiplicities impose > a constraint. > [Jim] Associations between interfaces is in the model, but it should > simply mean that implementing classifiers have to provide the > specified associations. This probably shouldn't be coupled with > connections between provided and required interfaces > [Eran] The importance of declaring associations between interfaces IS > to impose a "constraint" on the implemention classes to implement > them. So if I have a class realizing Isensor I can make sure than in > an internal structure it can be linked (via a connector) to a class > realizing IAlarm. That was the oroginal rationale behind that example > when I put it there... > > [Conrad] I thought interface was extended in UML 2 to include > > associations generally. > [Joaquin] So did I. OK, so the caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) isn't stating a general mapping of the notation to provided/required interfaces. This should be clarified, because there is nothing but the association in the example, so the reader can easily think it necessarily implies provided/required. Conrad To: Juergen Boldt Subject: Re: Associations between interfaces X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 8 Sep 2004 17:47:18 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2004 17:47:24, Serialize complete at 09/08/2004 17:47:24 Not a serious issue -- needs some clarification -- but I see no harm in logging it. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Juergen Boldt 09/08/2004 01:37 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject Re: Associations between interfaces Bran, discussion or issue-worthy? -Juergen At 10:54 AM 8/27/2004, you wrote: Conrad, In reply: > A set of interfaces constituting a protocol may be depicted as > interfaces with associations between them > > Is this just notation, or are associations really in the model? > > - If it is just notation, what is the model? > > - If it is the model, isn't it overly restrictive? The modeler's > intention might be that these are both required interfaces, > declaring that the two support classes will include an association > between them. I thought interface were extended in UML 2 to include > associations generally. The associations are really in the model. The intent of that figure was not to express a restriction on how associations are used with interfaces, but to illustrate a specific case. In that particular case, the "1" multiplicities impose a constraint. Bran ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================