Issue 6945: UML 2 Super / Classes / Dependency should not be abstract (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some): Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown Table 4, P.130, defines a visual symbol for it Fig. 101, P.155, shown as abstract Fig. 126, P.183, shown as abstract Fig 130, P.188, shows a pure dependency in an example Table 9, P.199, defines a visual symbol for it Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters. Resolution: see above Revised Text: Actions taken: January 29, 2004: received issue March 8, 2005: closed issue Discussion: Dependency should clearly not be an abstract class since there are many cases where the general concept of Dependency is used. Therefore, the diagrams in figures 101 and 126 should be replaced with the following diagrams (respectively) in which Dependency is shown as concrete. (NB: the diagram above includes the results of applying resolution 6352) Also, in the metamodel, the class Dependency should be made concrete rather than abstract End of Annotations:===== ubject: UML 2 Super / Classes / Dependency should not be abstract X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 29 Jan 2004 11:54:22 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/29/2004 11:54:24, Serialize complete at 01/29/2004 11:54:24 A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some): Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown Table 4, P.130, defines a visual symbol for it Fig. 101, P.155, shown as abstract Fig. 126, P.183, shown as abstract Fig 130, P.188, shows a pure dependency in an example Table 9, P.199, defines a visual symbol for it Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters. Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 From: "Eran Gery" To: "'Branislav Selic'" Cc: Subject: RE: Ballot 9 issue 6465 Date: Sun, 7 Mar 2004 14:16:59 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal Bran - Is the notation used in figured 406 (and 405) defined somewhere ? I refer to the package "frames" and notes for defining local attributes - ? what is it based on ? I know these frames are used in sequence diagrams, but did we introduce them as a generic notational technique for namespacing ? Where ? In case of package nesting, I would use a package symbol instead the proposed frame notation. For class internal structure, we use a class symbol as the "frame" - so we need to be consistent with that. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thu, March 04, 2004 1:45 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 9 -- vote starts today at 6 pm EST You have two weeks to vote (and re-vote, if you want) on these proposed resolutions. Bran To: "Eran Gery" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 9 issue 6465 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 7 Mar 2004 21:18:12 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/07/2004 21:18:14, Serialize complete at 03/07/2004 21:18:14 Hi Eran, My answers are embedded below: > Bran - Is the notation used in figured 406 (and 405) defined > somewhere ? I refer to the package "frames" and > notes for defining local attributes - ? what is it based on ? I know > these frames are used in sequence diagrams, > but did we introduce them as a generic notational technique for > namespacing ? Where ? Please look at Appendix B: Diagrams. Using frames is an optional way of denoting a number of different things in UML 2.0. > In case of package nesting, I would use a package symbol instead the > proposed frame notation. For class internal structure, we use a > class symbol as the "frame" - so we need to be consistent with that. You can use either one. Cheers, Bran From: Eran Gery To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 9 issue 6465 Date: Mon, 8 Mar 2004 13:05:52 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Bran First thanks for pointing me there... Apologize for being a pain, but these notational issues are what end users really care about... From what I saw, the frame is only for a diagram. So figure 405 and 406 can't really be rendered in a UML tool as they suggest a diagram having multiple frames. Another important issue is that the appendix says Each diagram has a frame, a contents area, and a heading, see Figure 460. This is clearly an optional notation and should be presented as such I will log an issue on that. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Mon, March 08, 2004 4:18 AM To: Eran Gery Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 9 issue 6465 Hi Eran, My answers are embedded below: > Bran - Is the notation used in figured 406 (and 405) defined > somewhere ? I refer to the package "frames" and > notes for defining local attributes - ? what is it based on ? I know > these frames are used in sequence diagrams, > but did we introduce them as a generic notational technique for > namespacing ? Where ? Please look at Appendix B: Diagrams. Using frames is an optional way of denoting a number of different things in UML 2.0. > In case of package nesting, I would use a package symbol instead the > proposed frame notation. For class internal structure, we use a > class symbol as the "frame" - so we need to be consistent with that. You can use either one. Cheers, Bran To: Eran Gery Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 9 issue 6465 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Mar 2004 08:19:29 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/08/2004 08:19:35, Serialize complete at 03/08/2004 08:19:35 Eran, I am not sure which issue you want to log, but you seem to be making some assumptions about diagrams that may not be shared. Namely, for some reason, you are assuming that you cannot have nested diagrams. This is a possibility that Birger and I discussed and, as far as I am concerned, it is still an option. In fact, I think that it is absolutely necessary when one needs to show things such as relationships between two or more models. Our problem is that there is no formal syntax defined for the notation of UML, merely a set of examples. This is still an outstanding item. If you raise an issue against figures 406, I can tell you that I will propose either a defer or a close, no change resolution for it (since I own that part of the text). I don't mean to be contrarian but I really believe that diagrams such as that are necessary in some cases. Regards, Bran Eran Gery wrote on 03/08/2004 06:05:52 AM: > Bran > > First thanks for pointing me there... > Apologize for being a pain, but these notational issues are what end > users really care about... > > From what I saw, the frame is only for a diagram. So figure 405 and > 406 can't really be rendered in > a UML tool as they suggest a diagram having multiple frames. > > Another important issue is that the appendix says > Each diagram has a frame, a contents area, and a heading, see Figure 460. > This is clearly an optional notation and should be presented as such > I will log an issue on that. > > Eran > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Mon, March 08, 2004 4:18 AM > To: Eran Gery > Cc: uml2-superstructure-ftf@omg.org > Subject: RE: Ballot 9 issue 6465 > > Hi Eran, > > My answers are embedded below: > > > > Bran - Is the notation used in figured 406 (and 405) defined > > somewhere ? I refer to the package "frames" and > > notes for defining local attributes - ? what is it based on ? I know > > these frames are used in sequence diagrams, > > but did we introduce them as a generic notational technique for > > namespacing ? Where ? > > Please look at Appendix B: Diagrams. Using frames is an optional way > of denoting a number of different things in UML 2.0. > > > In case of package nesting, I would use a package symbol instead the > > proposed frame notation. For class internal structure, we use a > > class symbol as the "frame" - so we need to be consistent with that. > > You can use either one. > > Cheers, > > Bran Date: Mon, 08 Mar 2004 15:03:38 +0100 From: Birger Møller-Pedersen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Branislav Selic CC: Eran Gery , uml2-superstructure-ftf@omg.org Subject: Re: Ballot 9 issue 6465 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=1.019, required 12, HTML_20_30 0.47, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) X-UiO-Spam-score: s Figure 405 is certainly an examle of nested diagrams. Figure 406 is not obviously. One may of course put a diagram around them all (or claim that there is an implicit frame - which is by the way also allowed according to the spec), but the the question is then if it is possible to have relations between diagrams. /birger Branislav Selic wrote: Eran, I am not sure which issue you want to log, but you seem to be making some assumptions about diagrams that may not be shared. Namely, for some reason, you are assuming that you cannot have nested diagrams. This is a possibility that Birger and I discussed and, as far as I am concerned, it is still an option. In fact, I think that it is absolutely necessary when one needs to show things such as relationships between two or more models. Our problem is that there is no formal syntax defined for the notation of UML, merely a set of examples. This is still an outstanding item. If you raise an issue against figures 406, I can tell you that I will propose either a defer or a close, no change resolution for it (since I own that part of the text). I don't mean to be contrarian but I really believe that diagrams such as that are necessary in some cases. Regards, Bran Eran Gery wrote on 03/08/2004 06:05:52 AM: > Bran > > First thanks for pointing me there... > Apologize for being a pain, but these notational issues are what end > users really care about... > > From what I saw, the frame is only for a diagram. So figure 405 and > 406 can't really be rendered in > a UML tool as they suggest a diagram having multiple frames. > > Another important issue is that the appendix says > Each diagram has a frame, a contents area, and a heading, see Figure 460. > This is clearly an optional notation and should be presented as such > I will log an issue on that. > > Eran > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Mon, March 08, 2004 4:18 AM > To: Eran Gery > Cc: uml2-superstructure-ftf@omg.org > Subject: RE: Ballot 9 issue 6465 > > Hi Eran, > > My answers are embedded below: > > > > Bran - Is the notation used in figured 406 (and 405) defined > > somewhere ? I refer to the package "frames" and > > notes for defining local attributes - ? what is it based on ? I know > > these frames are used in sequence diagrams, > > but did we introduce them as a generic notational technique for > > namespacing ? Where ? > > Please look at Appendix B: Diagrams. Using frames is an optional way > of denoting a number of different things in UML 2.0. > > > In case of package nesting, I would use a package symbol instead the > > proposed frame notation. For class internal structure, we use a > > class symbol as the "frame" - so we need to be consistent with that. > > You can use either one. > > Cheers, > > Bran -- Birger Møller-Pedersen Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 24 37 (office) Tel: +47 918 27 27 9 (mobile) http://folk.uio.no/birger e-mail: bselic@ca.ibm.com