Issue 19209: Generalization should be limited to relate similar UML-elements (uml2-rtf) Source: oose Innovative Informatik eG (Mr. Axel Scheithauer, axel.scheithauer(at)oose.de) Nature: Revision Severity: Significant Summary: The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances? The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293). Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view. Suggestion: Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses. Resolution: Revised Text: Actions taken: February 10, 2014: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 10 Feb 2014 10:46:35 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Axel Scheithauer Employer: oose Innovative Informatik GmbH mailFrom: axel.scheithauer@oose.de Terms_Agreement: I agree Specification: UML Section: 9.2.3 FormalNumber: ptc/2013-09-05 Version: 2.5 Doc_Year: 2013 Doc_Month: September Doc_Day: 01 Page: 98, 141 Title: Generalization should be limited to relate similar UML-elements Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: 87.128.223.58 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:46 AM Description: The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances? The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293). Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view. Suggestion: Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses. From: "Bock, Conrad" To: Axel Scheithauer CC: "issues@omg.org" , "uml2-rtf@omg.org" Subject: RE: issue 19209 -- UML 2.6 RTF issue Thread-Topic: issue 19209 -- UML 2.6 RTF issue Thread-Index: AQHPJo8Pnsq36cKmjEGFlT50H6TdrZqvfU+ggABsvwCAACWncA== Date: Tue, 11 Feb 2014 13:38:08 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.32.106] x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(6009001)(5403001)(189002)(199002)(74316001)(4396001)(80022001)(76482001)(53806001)(65816001)(47736001)(49866001)(81342001)(74706001)(50986001)(47976001)(87266001)(85306002)(51856001)(81816001)(33646001)(77096001)(46102001)(92566001)(66066001)(81686001)(74366001)(69226001)(63696002)(54356001)(81542001)(76576001)(76796001)(59766001)(85852003)(83072002)(77982001)(90146001)(56816005)(47446002)(31966008)(76786001)(56776001)(2656002)(74662001)(74876001)(93516002)(87936001)(74502001)(79102001)(93136001)(83322001)(94946001)(54316002)(80976001)(95416001)(86362001)(95666001)(94316002)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR09MB061;H:BY2PR09MB062.namprd09.prod.outlook.com;CLIP:129.6.32.106;FPR:BE7AF285.9EFC6E96.6DD0BF4C.44EFB031.2015E;InfoNoRecordsMX:1;A:1;LANG:en; X-OriginatorOrg: nist.gov X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id s1BDcKRk024234 Content-Transfer-Encoding: 8bit Axel, > Thus it is allowed to have a generalization between an Activity and a > signal. This definitely makes no sense. Does it make sense to have a > generalization between an Activity and a Class? What does that mean > for the instances? Although UML has a constraint against this, as Ed pointed out, it isn't clear that it should. For example, an application might want to send objects representing executions of an activity (instances of an activity) as signals. Or perhaps a modeler has a class already defined with properties that turn out to only apply to activities. I can't think of a logical contradiction caused by violating the constraint UML imposes, can you?. Conrad X-Virus-Scanned: OK From: Ed Seidewitz To: "Axel Scheithauer (Axel.Scheithauer@oose.de)" CC: "issues@omg.org" , "uml2-rtf@omg.org" Subject: RE: issue 19209 -- UML 2.6 RTF issue Thread-Topic: issue 19209 -- UML 2.6 RTF issue Thread-Index: AQHPJo8Pnsq36cKmjEGFlT50H6TdrZqvfU+g Date: Tue, 11 Feb 2014 04:59:51 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.30.59.206] X-Virus-Scanned: amavisd-new at omg.org Axel . The constraint you are looking for is .specialize_type. on Classifier: · specialize_type A Classifier may only specialize Classifiers of a valid type. inv: parents()->forAll(c | self.maySpecializeType(c)) The operation .maySpecializeType. is also on Classifier, with the definition: · maySpecializeType(c : Classifier) : Boolean The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. body: self.oclIsKindOf(c.oclType()) -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, February 10, 2014 1:36 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19209 -- UML 2.6 RTF issue From: webmaster@omg.org Date: 10 Feb 2014 10:46:35 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Axel Scheithauer Employer: oose Innovative Informatik GmbH mailFrom: axel.scheithauer@oose.de Terms_Agreement: I agree Specification: UML Section: 9.2.3 FormalNumber: ptc/2013-09-05 Version: 2.5 Doc_Year: 2013 Doc_Month: September Doc_Day: 01 Page: 98, 141 Title: Generalization should be limited to relate similar UML-elements Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: 87.128.223.58 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:46 AM Description: The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances? The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293). Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view. Suggestion: Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] From: Axel Scheithauer To: Ed Seidewitz CC: "issues@omg.org" , "uml2-rtf@omg.org" Subject: AW: issue 19209 -- UML 2.6 RTF issue Thread-Topic: issue 19209 -- UML 2.6 RTF issue Thread-Index: AQHPJo8oR5rFtiI8m0yduq9DP8LXB5qvbk6AgABxpBA= Date: Tue, 11 Feb 2014 11:22:46 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.128.223.58] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org Hi Ed, oh, that.s what I was looking for, obviously in the wrong place under Generalization. Is it possible to undo an issue report? As it is new to me, that I can model an activity specializing a class, do you have a good example, where using this possiblility would be the best way to model it? -- Axel Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Dienstag, 11. Februar 2014 06:00 An: Axel Scheithauer Cc: issues@omg.org; uml2-rtf@omg.org Betreff: RE: issue 19209 -- UML 2.6 RTF issue Axel . The constraint you are looking for is .specialize_type. on Classifier: · specialize_type A Classifier may only specialize Classifiers of a valid type. inv: parents()->forAll(c | self.maySpecializeType(c)) The operation .maySpecializeType. is also on Classifier, with the definition: · maySpecializeType(c : Classifier) : Boolean The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. body: self.oclIsKindOf(c.oclType()) -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, February 10, 2014 1:36 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19209 -- UML 2.6 RTF issue From: webmaster@omg.org Date: 10 Feb 2014 10:46:35 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Axel Scheithauer Employer: oose Innovative Informatik GmbH mailFrom: axel.scheithauer@oose.de Terms_Agreement: I agree Specification: UML Section: 9.2.3 FormalNumber: ptc/2013-09-05 Version: 2.5 Doc_Year: 2013 Doc_Month: September Doc_Day: 01 Page: 98, 141 Title: Generalization should be limited to relate similar UML-elements Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: 87.128.223.58 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:46 AM Description: The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances? The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293). Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view. Suggestion: Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392150267; bh=iY6kfOBLEdl/Du8VJNbx5JKqaEQVoTjsv9JDTtAZBUU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=Ifp6GEejMGiMG1QWLDiZOhNYPgTNozFtCPvIeIwjE4B2AZ/leF27VUei8lpyvPACtZuAh/chuP000nWQ1XbVZ9Um1NcJMyjqW6WuD5o6blQ5lvJ/LbW/q8P/w3OGW8m86L3E9PITal5/MRrKb5ddVoDTMHOymoUUj4SNEfFQF2Y= X-Yahoo-Newman-Id: 430817.7688.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: V0BssvwVM1l5bak.zcJx7FAZL.1JxumDXir2nFMcuyqFwcJ 4d1PXtwQ6Z.C6L1tola4Yf_TcFC.RgySYKARPFPUt7tOtrh0Y88sp34ujaTJ 3n5s.2Z1Za6Hc2Mc5JqzedLSD0djg_Vv1SHZfR08bVe3v7SB02GZF2.w2E9E nbAKlEzgePz6YsC9cps8T450Ao12nG0926F5fpRYlSpclEemRU1LUX1l5sv_ aCowdebd_w3UWwM0nuehx2fZDlofBRYIve7iCa_Wawm.af7Vx9MmzGRHu6f8 mT.cdJNRgfsZC2S._zrfogKs9C.ixBVTO2tGcazrECJ70JhZYfpTAkJTM4iN y0COWMYk31XOQc39fY59cS5ManCxIGY6XkycKI1E46yl.RkVVVrEszEzU30N 0XOQyO5nDMsHxu1T4D5ZzAoe6SXgECXIXhtXGiBV0rMszwpIV69D1zxq7an. _9f_lpbW6ernqIXZuW4WQtbpmuA89ykYNMagSZ2xZVRp06J_qdQkkoJJcFfr hCcTeZUQCZLMlJ0b1z9ef2teAsfHqPmOrk1yTYCoDkvfAU7ZW8GJj X-Yahoo-SMTP: BHehp.2swBCs4PqecFo6LCqjUcnFjw4- X-Rocket-Received: from mjchonolesHP (mjchonoles@71.225.93.40 with plain [98.139.211.125]) by smtp112.mail.ne1.yahoo.com with SMTP; 11 Feb 2014 12:24:27 -0800 PST From: "Michael Chonoles" To: "'Bock, Conrad'" , "'Axel Scheithauer'" Cc: , Subject: RE: issue 19209 -- UML 2.6 RTF issue Date: Tue, 11 Feb 2014 15:24:22 -0500 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHhFPzWcy8Nksl9xfqrbwZTHLbkVAGnLpywAewZ2PABh4rEK5pjzVYw X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id s1BKOWRI009200 Content-Transfer-Encoding: 8bit I can certainly think of a class of activities. We do allow activities on class diagrams (and in SysML in block diagrams) and these are very useful. Each instance of these class/activities are instances of the activity running. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, February 11, 2014 8:38 AM To: Axel Scheithauer Cc: issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 19209 -- UML 2.6 RTF issue Axel, > Thus it is allowed to have a generalization between an Activity and a > signal. This definitely makes no sense. Does it make sense to have a > generalization between an Activity and a Class? What does that mean > for the instances? Although UML has a constraint against this, as Ed pointed out, it isn't clear that it should. For example, an application might want to send objects representing executions of an activity (instances of an activity) as signals. Or perhaps a modeler has a class already defined with properties that turn out to only apply to activities. I can't think of a logical contradiction caused by violating the constraint UML imposes, can you?. Conrad X-Virus-Scanned: OK From: Ed Seidewitz To: Axel Scheithauer CC: "issues@omg.org" , "uml2-rtf@omg.org" Subject: RE: issue 19209 -- UML 2.6 RTF issue Thread-Topic: issue 19209 -- UML 2.6 RTF issue Thread-Index: AQHPJo8Pnsq36cKmjEGFlT50H6TdrZqvfU+ggADRVQCAAI8LcA== Date: Wed, 12 Feb 2014 01:58:42 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.30.59.206] X-Virus-Scanned: amavisd-new at omg.org X-PE-GPVersion: 1.74 X-PE-Data: NA X-PE-BayesianScore: 40.000000% X-PE-CorpusSize: 0 Good, 0 Bad X-PE-BayesianWarning: Insufficient statistics for accurate Bayesian calculation. X-PE-BayesianWarning: No filtering took place based on this Bayesian score. Bayesian X-PE-BayesianWarning: statistics will be used to filter your email once the system X-PE-BayesianWarning: has collected sufficient statistics (normally a few days). X-PE-UniqueID: 1392181452-9565 X-PE-Report: Report this as spam: http://www.bopspam.co.uk/rs.php?ID=50&adt=126&c=2208 Axel . I don.t know that I have a good example of an activity specializing a class, but I do think it makes sense, at least formally. Since an activity is a class (as is any behavior), it can have attributes and operations, like any class. So, an activity specializing a class would simply inherit attributes and behaviors from the class, as well as defining a behavior, and could be used in any typed element that is typed by the parent class. -- Ed From: Axel Scheithauer [mailto:Axel.Scheithauer@oose.de] Sent: Tuesday, February 11, 2014 6:23 AM To: Ed Seidewitz Cc: issues@omg.org; uml2-rtf@omg.org Subject: AW: issue 19209 -- UML 2.6 RTF issue Hi Ed, oh, that.s what I was looking for, obviously in the wrong place under Generalization. Is it possible to undo an issue report? As it is new to me, that I can model an activity specializing a class, do you have a good example, where using this possiblility would be the best way to model it? -- Axel Von: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Gesendet: Dienstag, 11. Februar 2014 06:00 An: Axel Scheithauer Cc: issues@omg.org; uml2-rtf@omg.org Betreff: RE: issue 19209 -- UML 2.6 RTF issue Axel . The constraint you are looking for is .specialize_type. on Classifier: · specialize_type A Classifier may only specialize Classifiers of a valid type. inv: parents()->forAll(c | self.maySpecializeType(c)) The operation .maySpecializeType. is also on Classifier, with the definition: · maySpecializeType(c : Classifier) : Boolean The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. body: self.oclIsKindOf(c.oclType()) -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, February 10, 2014 1:36 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 19209 -- UML 2.6 RTF issue From: webmaster@omg.org Date: 10 Feb 2014 10:46:35 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Axel Scheithauer Employer: oose Innovative Informatik GmbH mailFrom: axel.scheithauer@oose.de Terms_Agreement: I agree Specification: UML Section: 9.2.3 FormalNumber: ptc/2013-09-05 Version: 2.5 Doc_Year: 2013 Doc_Month: September Doc_Day: 01 Page: 98, 141 Title: Generalization should be limited to relate similar UML-elements Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: 87.128.223.58 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Time: 10:46 AM Description: The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances? The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293). Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view. Suggestion: Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org []