Issue 7567: Port should specialize featuringClassifier (uml2-superstructure-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Resolution: Revised Text: Actions taken: July 7, 2004: received issue Discussion: End of Annotations:===== eply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 10:17:02 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Juergen, > So it looks like an issue number needs to get assigned for this > thread.... If you were to assign an issue, it would be: Port should specialize featuringClassifier. The other one on actions is already filed. Conrad To: Cc: "uml2ftf" Subject: Re: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 7 Jul 2004 18:25:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/07/2004 18:25:04, Serialize complete at 07/07/2004 18:25:04 I thought it was intentional, since a classifier does not necessarily own all of its features. Hence, a classifier may share some features with other classifiers. This may be an artifact of the old 1.x association end trick whereby an association end was in the namespace of a classifier, but not owned by it. OTOH, it could be a deeply philosophical statement on the nature of features. In any case, I would not want to change it now. If it is a problem for Ports, then it should be fixed there. Bran "Conrad Bock" 07/07/2004 05:22 PM Please respond to conrad.bock To "uml2ftf" cc Subject featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad Subject: RE: featuringClassifier Date: Wed, 7 Jul 2004 16:53:36 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: featuringClassifier Thread-Index: AcRkaKvoU7OPITShS3eEAMIzq4tZiwAFErqA From: "Karl Frank" To: , "uml2ftf" X-OriginalArrivalTime: 07 Jul 2004 23:53:47.0290 (UTC) FILETIME=[A4DDB7A0:01C4647D] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6802mlj015186 I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad From: "Thomas Weigert" To: "Karl Frank" , , "uml2ftf" Subject: RE: featuringClassifier Date: Wed, 7 Jul 2004 20:40:47 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In my personal experience, I have not seen any usage of this. I don't understand what "reuse of feature across classifiers" means. I believe, however, the reason for this is to support concepts such as the old ROOM notion of "slide-in capsules". Bran might have more insight on this. Th. > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, July 07, 2004 7:54 PM > To: conrad.bock@nist.gov; uml2ftf > Subject: RE: featuringClassifier > > > I thought about this in the context of your issue 6156, and so I have an > opinion, but it is only an opinion since as Joaquin is fond of saying, I > "... was not there at the birth". > > My opinion is that in the context of modeling reusable components one > will have to allow that a feature can be reused accross classifiers. > > It came up in the context of 6156 because the derived /attribute > relationship for Classifier is not the composition that is evident in > most of the concrete subclasses of Classifier. > > - Karl > > > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, 07 July, 2004 5:23 PM > To: uml2ftf > Subject: featuringClassifier > > > Bran, Karl, Joaquin, > > Apparently a structural feature can be on more than one classifier, > because the multiplicity of /featuringClassifier is 1..*. Not all the > subtypes of StructuralFeature narrow this to one, or change it to strong > ownership (eg, Port). > > Is it intentional that structural feature have more than one > featuringClassifier, and not be owned by that classifier? If not, Bran, > please assign this to classes. Otherwise, it is problem for Ports as > well. > > Conrad > > To: "Thomas Weigert" Cc: conrad.bock@nist.gov, "Karl Frank" , "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 7 Jul 2004 20:58:06 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/07/2004 20:58:10, Serialize complete at 07/07/2004 20:58:10 Actually, in ROOM what can be shared is the object that sits in a slot (i.e., it can be sitting simultaneously in multiple slots) but the slots are not shared. (In my view, the slot is the feature, not the value that is in the slot.) So, this is not the same thing. One way of looking at it is to consider the case of multiple views of the same thing, each view represented by a different classifier. The views are purely abstract of course, but they are modeled by different classifiers. These views might share some common features. In any case, this stuff is best left alone at this stage -- although the port issue might need to be fixed. Even that I do not view as a priority. Bran "Thomas Weigert" 07/07/2004 08:40 PM To "Karl Frank" , , "uml2ftf" cc Subject RE: featuringClassifier In my personal experience, I have not seen any usage of this. I don't understand what "reuse of feature across classifiers" means. I believe, however, the reason for this is to support concepts such as the old ROOM notion of "slide-in capsules". Bran might have more insight on this. Th. > -----Original Message----- > From: Karl Frank [mailto:Karl.Frank@borland.com] > Sent: Wednesday, July 07, 2004 7:54 PM > To: conrad.bock@nist.gov; uml2ftf > Subject: RE: featuringClassifier > > > I thought about this in the context of your issue 6156, and so I have an > opinion, but it is only an opinion since as Joaquin is fond of saying, I > "... was not there at the birth". > > My opinion is that in the context of modeling reusable components one > will have to allow that a feature can be reused accross classifiers. > > It came up in the context of 6156 because the derived /attribute > relationship for Classifier is not the composition that is evident in > most of the concrete subclasses of Classifier. > > - Karl > > > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, 07 July, 2004 5:23 PM > To: uml2ftf > Subject: featuringClassifier > > > Bran, Karl, Joaquin, > > Apparently a structural feature can be on more than one classifier, > because the multiplicity of /featuringClassifier is 1..*. Not all the > subtypes of StructuralFeature narrow this to one, or change it to strong > ownership (eg, Port). > > Is it intentional that structural feature have more than one > featuringClassifier, and not be owned by that classifier? If not, Bran, > please assign this to classes. Otherwise, it is problem for Ports as > well. > > Conrad > > From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , "Karl Frank" , "uml2ftf" Subject: RE: featuringClassifier Date: Wed, 7 Jul 2004 21:10:35 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) What is the "port issue"? Thanks, Th. P.S. My understanding of the "shared feature" was that this meant that the object in the slot was shared as a consequence, but maybe I was reading to much into the metaassociation. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 07, 2004 8:58 PM To: Thomas Weigert Cc: conrad.bock@nist.gov; Karl Frank; uml2ftf Subject: RE: featuringClassifier In any case, this stuff is best left alone at this stage -- although the port issue might need to be fixed. Even that I do not view as a priority. Date: Thu, 08 Jul 2004 08:21:15 +0200 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: Karl Frank CC: conrad.bock@nist.gov, uml2ftf Subject: Re: featuringClassifier 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=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- Birger Møller-Pedersen 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 Date: Thu, 08 Jul 2004 11:16:04 +0100 From: Guus Ramackers Organization: Oracle Corporation 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: Birger Møller-Pedersen CC: Karl Frank , conrad.bock@nist.gov, uml2ftf Subject: Re: featuringClassifier I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Date: Thu, 08 Jul 2004 13:24:24 +0200 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: Guus Ramackers CC: Karl Frank , conrad.bock@nist.gov, uml2ftf Subject: Re: featuringClassifier 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=-4.455, required 12, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54, UIO_MAIL_IS_INTERNAL -5.00) I see no problem in reusing a Classfier in different domains (and it does not even require any special metamodel features, just define it in a package and import this), but the question was about being able to have a feature without having a featuringClassifier. /birger Guus Ramackers wrote: I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- Birger Møller-Pedersen 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 To: "Thomas Weigert" Cc: conrad.bock@nist.gov, "Karl Frank" , "Thomas Weigert" , "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 8 Jul 2004 07:26:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/08/2004 07:26:12, Serialize complete at 07/08/2004 07:26:12 By "port issue" I meant what Conrad had mentioned: the possibility that a port could be a feature of more than one structured class. However, as long as it does not imply multiple ownership I see nothing wrong with this either. It might come in handy. I see no harm in it. Bran "Thomas Weigert" 07/07/2004 09:10 PM To Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , "Karl Frank" , "uml2ftf" Subject RE: featuringClassifier What is the "port issue"? Thanks, Th. P.S. My understanding of the "shared feature" was that this meant that the object in the slot was shared as a consequence, but maybe I was reading to much into the metaassociation. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 07, 2004 8:58 PM To: Thomas Weigert Cc: conrad.bock@nist.gov; Karl Frank; uml2ftf Subject: RE: featuringClassifier In any case, this stuff is best left alone at this stage -- although the port issue might need to be fixed. Even that I do not view as a priority. Date: Thu, 08 Jul 2004 12:35:38 +0100 From: Guus Ramackers Organization: Oracle Corporation 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: Birger Møller-Pedersen CC: Karl Frank , conrad.bock@nist.gov, uml2ftf Subject: Re: featuringClassifier Birger, I was commenting on 'shared features' - apologies. Reusing Features from a library might be one goal for unattached Features. But it seems strange that this would only apply to Features. Thanks, Guus Birger Møller-Pedersen wrote: I see no problem in reusing a Classfier in different domains (and it does not even require any special metamodel features, just define it in a package and import this), but the question was about being able to have a feature without having a featuringClassifier. /birger Guus Ramackers wrote: I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- Birger Møller-Pedersen 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 -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 From: "Thomas Weigert" To: Birger Møller-Pedersen , "Guus Ramackers" Cc: "Karl Frank" , , "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 07:47:33 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) After this discussion it appears that: 1. This "feature" was not in 1.4, 2. Nobody knows why this "feature" exists, 3. Nobody is able to show any credible use cases, 4. It is suggested to constrain this "feature" to 1 (or 0..1) in most (or all) concrete classifiers. In summary, this is a clear candidate for removal, if I have seen such. I suggest to remove it as it will clear up the specification. If there are future examples of a use of a feature being the feature of multiple classifiers, then we can always add it later. Th. -----Original Message----- From: Birger Møller-Pedersen [mailto:birger@ifi.uio.no] Sent: Thursday, July 08, 2004 7:24 AM To: Guus Ramackers Cc: Karl Frank; conrad.bock@nist.gov; uml2ftf Subject: Re: featuringClassifier I see no problem in reusing a Classfier in different domains (and it does not even require any special metamodel features, just define it in a package and import this), but the question was about being able to have a feature without having a featuringClassifier. /birger Guus Ramackers wrote: I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- Birger Møller-Pedersen 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 To: "Thomas Weigert" Cc: Birger Møller-Pedersen , conrad.bock@nist.gov, "Guus Ramackers" , "Karl Frank" , "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 8 Jul 2004 08:00:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/08/2004 08:00:24, Serialize complete at 07/08/2004 08:00:24 I strongly suggest against changing this at this time. It does not break anything and has at least hypothetical future uses. Let's focus on the 200 remaining issues first. For those with free time to work on this issue, I have a list of other issues that I am hoping they can work on first. Bran "Thomas Weigert" 07/08/2004 07:47 AM To Birger Møller-Pedersen , "Guus Ramackers" cc "Karl Frank" , , "uml2ftf" Subject RE: featuringClassifier After this discussion it appears that: 1. This "feature" was not in 1.4, 2. Nobody knows why this "feature" exists, 3. Nobody is able to show any credible use cases, 4. It is suggested to constrain this "feature" to 1 (or 0..1) in most (or all) concrete classifiers. In summary, this is a clear candidate for removal, if I have seen such. I suggest to remove it as it will clear up the specification. If there are future examples of a use of a feature being the feature of multiple classifiers, then we can always add it later. Th. -----Original Message----- From: Birger Møller-Pedersen [mailto:birger@ifi.uio.no] Sent: Thursday, July 08, 2004 7:24 AM To: Guus Ramackers Cc: Karl Frank; conrad.bock@nist.gov; uml2ftf Subject: Re: featuringClassifier I see no problem in reusing a Classfier in different domains (and it does not even require any special metamodel features, just define it in a package and import this), but the question was about being able to have a feature without having a featuringClassifier. /birger Guus Ramackers wrote: I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- Birger Møller-Pedersen 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 From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: Birger Møller-Pedersen , , "Guus Ramackers" , "Karl Frank" , "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 08:13:35 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Fair enough. Let's triage this as lower priority, but let's not assume that this is a "feature" until we have a use case. We can address this next round... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 08, 2004 8:00 AM To: Thomas Weigert Cc: Birger Møller-Pedersen; conrad.bock@nist.gov; Guus Ramackers; Karl Frank; uml2ftf Subject: RE: featuringClassifier I strongly suggest against changing this at this time. It does not break anything and has at least hypothetical future uses. Let's focus on the 200 remaining issues first. For those with free time to work on this issue, I have a list of other issues that I am hoping they can work on first. Bran "Thomas Weigert" 07/08/2004 07:47 AM To Birger Møller-Pedersen , "Guus Ramackers" cc "Karl Frank" , , "uml2ftf" Subject RE: featuringClassifier After this discussion it appears that: 1. This "feature" was not in 1.4, 2. Nobody knows why this "feature" exists, 3. Nobody is able to show any credible use cases, 4. It is suggested to constrain this "feature" to 1 (or 0..1) in most (or all) concrete classifiers. In summary, this is a clear candidate for removal, if I have seen such. I suggest to remove it as it will clear up the specification. If there are future examples of a use of a feature being the feature of multiple classifiers, then we can always add it later. Th. -----Original Message----- From: Birger Møller-Pedersen [mailto:birger@ifi.uio.no] Sent: Thursday, July 08, 2004 7:24 AM To: Guus Ramackers Cc: Karl Frank; conrad.bock@nist.gov; uml2ftf Subject: Re: featuringClassifier I see no problem in reusing a Classfier in different domains (and it does not even require any special metamodel features, just define it in a package and import this), but the question was about being able to have a feature without having a featuringClassifier. /birger Guus Ramackers wrote: I believe this is an intentional infrastructure approach, where a general model Classifier is constructed which might be reused in different domains, e.g. data warehousing, software process modeling etc. Whilst I don't have any concrete examples of such reuse, it is probably best to leave this construct as is at this stage. We should be able to constrain this for Classes and Interfaces (narrow the cardinality). Thanks, Guus Birger Møller-Pedersen wrote: I did not experienced its birth, even though I was there. My guess is that this has been changed by mistake. 1.4 does not have this 'feature', however, it is possible for a feature in 1.x to be owned by no classifier (multiplicity 0..1). By its very nature (and even name) it is very difficult to think of a feature that is not a feature of something. If there was any rationale behind this, and if the rationale was to be able to represent incomplete models (starting out with features and then later findng out what these should be features of), then this issue is the same as the one about lifelines without context: either incomplete models (or models for specific methods) are handled by special tools, or all mulitiplicties are changed to their most general forms. /birger Karl Frank wrote: I thought about this in the context of your issue 6156, and so I have an opinion, but it is only an opinion since as Joaquin is fond of saying, I "... was not there at the birth". My opinion is that in the context of modeling reusable components one will have to allow that a feature can be reused accross classifiers. It came up in the context of 6156 because the derived /attribute relationship for Classifier is not the composition that is evident in most of the concrete subclasses of Classifier. - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, 07 July, 2004 5:23 PM To: uml2ftf Subject: featuringClassifier Bran, Karl, Joaquin, Apparently a structural feature can be on more than one classifier, because the multiplicity of /featuringClassifier is 1..*. Not all the subtypes of StructuralFeature narrow this to one, or change it to strong ownership (eg, Port). Is it intentional that structural feature have more than one featuringClassifier, and not be owned by that classifier? If not, Bran, please assign this to classes. Otherwise, it is problem for Ports as well. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- Birger Møller-Pedersen 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 Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 09:03:14 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > I strongly suggest against changing this at this time. It does > not break anything Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier misinterpreted). The structural feature actions assume one object. I can resolve it by restricting these actions to structural features that are features on one classifier, if it is decided not to change Classes. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 09:05:11 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > I strongly suggest against changing this at this time. It does > not break anything P.S.: And it means we don't have a semantics for ports on more than one classifier, plus the bug that featuringClassifier is not made concrete on Port. Conrad To: Cc: "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 8 Jul 2004 09:06:38 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/08/2004 09:06:40, Serialize complete at 07/08/2004 09:06:40 > > I strongly suggest against changing this at this time. It does > > not break anything > > Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier > misinterpreted). The structural feature actions assume one object. I > can resolve it by restricting these actions to structural features that > are features on one classifier, if it is decided not to change Classes. I would prefer that for a number of reasons, including the fact that changing Classes requires a joint FTF resolution. Bran X-Sender: juergen@amethyst.omg.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 08 Jul 2004 09:47:44 -0400 To: Branislav Selic From: Juergen Boldt Subject: RE: featuringClassifier Cc: , "uml2ftf" So it looks like an issue number needs to get assigned for this thread.... -Juergen At 09:06 AM 7/8/2004, Branislav Selic wrote: > > I strongly suggest against changing this at this time. It does > > not break anything > > Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier > misinterpreted). The structural feature actions assume one object. I > can resolve it by restricting these actions to structural features that > are features on one classifier, if it is decided not to change Classes. I would prefer that for a number of reasons, including the fact that changing Classes requires a joint FTF resolution. 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 ================================ To: Juergen Boldt Cc: conrad.bock@nist.gov, "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 8 Jul 2004 09:55:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/08/2004 09:55:31, Serialize complete at 07/08/2004 09:55:31 Yes, but what is the issue? Two possibilities come to mind: (1) that featuringClassifier should have a multiplicity of 1 or (2) that the semantics of its 0..* multiplicity need to be clarified? I would prefer a formulation along the lines of: "The multiplicity of Feature::featuringClassifier are currently set to 0..*. However, it is unclear what it means for a feature not to be associated with any classifier and, equally, what it means for a feature to be associated with multiple classifiers. Furthermore, is it meaningful for something to be a feature of a classifier without being owned by that classifier. Unless these semantics can be clarified, the multiplicity should be set to 1." What do folks think? Bran Juergen Boldt 07/08/2004 09:47 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , "uml2ftf" Subject RE: featuringClassifier So it looks like an issue number needs to get assigned for this thread.... -Juergen At 09:06 AM 7/8/2004, Branislav Selic wrote: > > I strongly suggest against changing this at this time. It does > > not break anything > > Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier > misinterpreted). The structural feature actions assume one object. I > can resolve it by restricting these actions to structural features that > are features on one classifier, if it is decided not to change Classes. I would prefer that for a number of reasons, including the fact that changing Classes requires a joint FTF resolution. 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 ================================ Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 10:17:02 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Juergen, > So it looks like an issue number needs to get assigned for this > thread.... If you were to assign an issue, it would be: Port should specialize featuringClassifier. The other one on actions is already filed. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: featuringClassifier Date: Thu, 8 Jul 2004 10:20:10 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) FYI, the multiplicity is currently 1..*. Conrad > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, July 08, 2004 9:55 AM > To: Juergen Boldt > Cc: conrad.bock@nist.gov; uml2ftf > Subject: RE: featuringClassifier > > > > Yes, but what is the issue? > > Two possibilities come to mind: > > (1) that featuringClassifier should have a multiplicity of 1 or > (2) that the semantics of its 0..* multiplicity need to be clarified? > > I would prefer a formulation along the lines of: > > "The multiplicity of Feature::featuringClassifier are currently > set to 0..*. However, it is unclear what it means for a feature > not to be associated with any classifier and, equally, what it > means for a feature to be associated with multiple classifiers. > Furthermore, is it meaningful for something to be a feature of a > classifier without being owned by that classifier. Unless these > semantics can be clarified, the multiplicity should be set to 1." > > What do folks think? > > Bran > > > > Juergen Boldt > 07/08/2004 09:47 AM ToBranislav Selic/Ottawa/IBM@IBMCA > cc, "uml2ftf" > SubjectRE: featuringClassifier > > > > > > > > So it looks like an issue number needs to get assigned for this > thread.... > > -Juergen > > > At 09:06 AM 7/8/2004, Branislav Selic wrote: > > > > > I strongly suggest against changing this at this time. It does > > > not break anything > > > > Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier > > misinterpreted). The structural feature actions assume one object. I > > can resolve it by restricting these actions to structural features that > > are features on one classifier, if it is decided not to change > Classes. > > I would prefer that for a number of reasons, including the fact > that changing Classes requires a joint FTF resolution. > > 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 > > ================================ X-Sender: juergen@amethyst.omg.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 08 Jul 2004 10:21:32 -0400 To: From: Juergen Boldt Subject: RE: featuringClassifier Cc: "uml2ftf" hmm ok thanks Conrad -Juergen At 10:20 AM 7/8/2004, Conrad Bock wrote: FYI, the multiplicity is currently 1..*. Conrad > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, July 08, 2004 9:55 AM > To: Juergen Boldt > Cc: conrad.bock@nist.gov; uml2ftf > Subject: RE: featuringClassifier > > > > Yes, but what is the issue? > > Two possibilities come to mind: > > (1) that featuringClassifier should have a multiplicity of 1 or > (2) that the semantics of its 0..* multiplicity need to be clarified? > > I would prefer a formulation along the lines of: > > "The multiplicity of Feature::featuringClassifier are currently > set to 0..*. However, it is unclear what it means for a feature > not to be associated with any classifier and, equally, what it > means for a feature to be associated with multiple classifiers. > Furthermore, is it meaningful for something to be a feature of a > classifier without being owned by that classifier. Unless these > semantics can be clarified, the multiplicity should be set to 1." > > What do folks think? > > Bran > > > > Juergen Boldt > 07/08/2004 09:47 AM ToBranislav Selic/Ottawa/IBM@IBMCA > cc, "uml2ftf" > SubjectRE: featuringClassifier > > > > > > > > So it looks like an issue number needs to get assigned for this > thread.... > > -Juergen > > > At 09:06 AM 7/8/2004, Branislav Selic wrote: > > > > > I strongly suggest against changing this at this time. It does > > > not break anything > > > > Yes, it affects your issue 6628 (UML 2 Super/Action/featuringClassifier > > misinterpreted). The structural feature actions assume one object. I > > can resolve it by restricting these actions to structural features that > > are features on one classifier, if it is decided not to change > Classes. > > I would prefer that for a number of reasons, including the fact > that changing Classes requires a joint FTF resolution. > > 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 > > ================================ ================================= 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 ================================ To: Cc: "uml2ftf" Subject: RE: featuringClassifier X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 8 Jul 2004 10:58:53 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/08/2004 10:58:59, Serialize complete at 07/08/2004 10:58:59 > FYI, the multiplicity is currently 1..*. The reason I thought it was 0..* is because there are a couple of places in Constructs (see figure 30 of the Super spec) in which featuringClassifier is subset with a multiplicity of 0..1. Looks like we have an inconsistency. As far as I know, you cannot reduce the lower bound when subsetting. We may have to change the multiplicity on featuringClassifier to 0..* after all. Bran Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Jul 2004 08:09:20 -0700 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: ,cl, featuringClassifier The multiplicity of Feature::featuringClassifier is currently set to 0..*. Not on figure 18 and 9.3.2 (Infra) and figure 28 (Super) and 7.9.2, it's not. It's 1..* on all four. However, it is unclear what it means ... for a feature to be associated with multiple classifiers. Isn't a navigable association end a feature associated with multiple classifiers? However, it is unclear what it means for a feature not to be associated with any classifier... As an architect, i would find floating features useful. Then i can ask DBAs, designers, programmers to use that feature exactly as specified. (Of course, i can always create a classifier, the only purpose of which is to hold that feature in order to comply with a 1 or 1..* multiplicity.) ............. I'm not taking a position on this, just raising or answering questions. Cordially, Joaquin