Issue 14035: Currently is it possible for a Classifier to specialize the same classifier directly more than once (uml2-rtf)
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Clarification
Severity: Minor
Summary: Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.

Resolution: 
Revised Text: 
Actions taken:
June 29, 2009: received issue
Discussion: 

End of Annotations:=====

m: webmaster@omg.org
Date: 29 Jun 2009 10:09:50 -0400
To: <issues@omg.org>
Subject: Issue/Bug Report



--------------------------------------------------------------------------------

Name: Dave Hawkins
Company: Oracle
mailFrom: dave.hawkins@oracle.com
Notification: No
Specification: UML Superstructure
Section: 7.3.8
FormalNumber: formal/2009-02-03
Version: 2.2
RevisionDate: 02/03/2009
Page: 52
Nature: Clarification
Severity: Minor
HTTP User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Description
Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.
<Down>
<Down>
From: "BERNARD, Yves" <Yves.Bernard@airbus.com>
To: "uml25-ftf@omg.org" <uml25-ftf@omg.org>
Date: Wed, 20 Feb 2013 09:24:50 +0100
Subject: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Index: Ac4PQ8AWlsP7kygrTDC3Ofh/mrtw2w==
Accept-Language: fr-FR, en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
X-Virus-Scanned: amavisd-new at omg.org


I agree we shall not enforce generalization.general to be .unique. but I think it.s worth adding explanations about the way to deal with members inherited from duplicate general classifiers.
 
Assume .G. a classifier defining an attribute .a.. If .X. is a classifier with two generalization relationships to G, does an instance of X has one or two slots for this attribute .a.?
 
To me the answer is: .only one slot. but, since it is not the easiest to implement for the tools, I believe we should state it explicitly.
 
What do you think?
 
Yves
 
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

<Down>
<Down>
<Down>
From: Steve Cook <Steve.Cook@microsoft.com>
To: "BERNARD, Yves" <Yves.Bernard@airbus.com>,
        "uml25-ftf@omg.org"
        <uml25-ftf@omg.org>
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Index: Ac4PQ8AWlsP7kygrTDC3Ofh/mrtw2wAEEZJQ
Date: Wed, 20 Feb 2013 10:23:07 +0000
Accept-Language: en-GB, en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.18.102]
X-Forefront-Antispam-Report: 
 CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(5383001)(365934001)(54316002)(56776001)(79102001)(5343655001)(44976002)(63696002)(31966008)(74662001)(5343635001)(54356001)(47446002)(59766001)(77982001)(74502001)(33656001)(20776003)(53806001)(16406001)(65816001)(51856001)(80022001)(15202345001)(76482001)(512954001)(47736001)(49866001)(56816002)(46102001)(4396001)(55846006)(16236675001)(47976001)(50986001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB030;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
X-Virus-Scanned: amavisd-new at omg.org


Yves

 

There is a constraint InstanceSpecification::structural_feature that enforces no more than one slot.

 

structural_feature

One StructuralFeature (including the same feature inherited from multiple classifiers) is the defining feature of at most one slot in an InstanceSpecification. 

 

inv: classifier->forAll(c | (c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)))

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 08:25
To: uml25-ftf@omg.org
Subject: [UML 2.52 FTF] Ballot2 review: issue #14035

 

I agree we shall not enforce generalization.general to be .unique. but I think it.s worth adding explanations about the way to deal with members inherited from duplicate general classifiers.

 

Assume .G. a classifier defining an attribute .a.. If .X. is a classifier with two generalization relationships to G, does an instance of X has one or two slots for this attribute .a.?

 

To me the answer is: .only one slot. but, since it is not the easiest to implement for the tools, I believe we should state it explicitly.

 

What do you think?

 

Yves

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
<Down>
<Down>
<Down>
From: "BERNARD, Yves" <Yves.Bernard@airbus.com>
To: "uml25-ftf@omg.org" <uml25-ftf@omg.org>
Date: Wed, 20 Feb 2013 16:42:01 +0100
Subject: FW: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Index: Ac4PQ8AWlsP7kygrTDC3Ofh/mrtw2wAEEZJQAArrvDAAAEWnoA==
Accept-Language: fr-FR, en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
X-Virus-Scanned: amavisd-new at omg.org
X-Brightmail-Tracker: AAAAAgr+n5EdGLWY
X-Brightmail-Tracker: AAAAAA==


 

 

From: BERNARD, Yves 
Sent: mercredi 20 féier 2013 16:41
To: Steve Cook
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Steve,

 

The point is that an InstanceSpecification is .only. a specification of a set of instances (which in some cases may contain only one or even no element) but not the instances themselves. Therefore constraining the way such instances can be specified does not formally constrain the instance themselves, even if the difference is subtle.

 

Yves

 

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: mercredi 20 féier 2013 11:23
To: BERNARD, Yves; uml25-ftf@omg.org
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Yves

 

There is a constraint InstanceSpecification::structural_feature that enforces no more than one slot.

 

structural_feature

One StructuralFeature (including the same feature inherited from multiple classifiers) is the defining feature of at most one slot in an InstanceSpecification. 

 

inv: classifier->forAll(c | (c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)))

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 08:25
To: uml25-ftf@omg.org
Subject: [UML 2.52 FTF] Ballot2 review: issue #14035

 

I agree we shall not enforce generalization.general to be .unique. but I think it.s worth adding explanations about the way to deal with members inherited from duplicate general classifiers.

 

Assume .G. a classifier defining an attribute .a.. If .X. is a classifier with two generalization relationships to G, does an instance of X has one or two slots for this attribute .a.?

 

To me the answer is: .only one slot. but, since it is not the easiest to implement for the tools, I believe we should state it explicitly.

 

What do you think?

 

Yves

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

From: Steve Cook <Steve.Cook@microsoft.com>
To: "BERNARD, Yves" <Yves.Bernard@airbus.com>,
        "uml25-ftf@omg.org"
        <uml25-ftf@omg.org>
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Index: Ac4PQ8AWlsP7kygrTDC3Ofh/mrtw2wAEEZJQAArrvDAAAEWnoAAAWvHw
Date: Wed, 20 Feb 2013 16:01:43 +0000
Accept-Language: en-GB, en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.166.18.102]
X-Forefront-Antispam-Report: 
 CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(31014001)(189002)(199002)(5383001)(365934001)(16406001)(50986001)(59766001)(77982001)(5343635001)(49866001)(79102001)(65816001)(56776001)(47976001)(80022001)(47736001)(20776003)(16236675001)(4396001)(54356001)(74662001)(44976002)(51856001)(5343655001)(31966008)(63696002)(56816002)(76482001)(512934001)(33656001)(54316002)(46102001)(15202345001)(74502001)(53806001)(55846006)(47446002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB039;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
X-Virus-Scanned: amavisd-new at omg.org
X-Brightmail-Tracker: AAAAAR0YtZg=
X-Brightmail-Tracker: AAAAAA==


Yves

 

I understand the distinction, although defining UML so that instances could have multiple .slots. for the same feature while InstanceSpecifications could not would be perverse.

 

The current semantics under Structural Features says what it means for instances to have values for attributes, direct and inherited: it does not use the word .slot..  There are various operations on Classifier that define what it means to inherit a feature. These make it clear (especially inheritedMember()) that an inherited feature is inherited once.  I believe that the current spec makes it clear that each member is inherited once and what that means in terms of instances.  If you don.t agree, please raise a new issue citing an ambiguity in the text.

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 15:42
To: uml25-ftf@omg.org
Subject: FW: [UML 2.52 FTF] Ballot2 review: issue #14035

 

 

 

From: BERNARD, Yves 
Sent: mercredi 20 féier 2013 16:41
To: Steve Cook
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Steve,

 

The point is that an InstanceSpecification is .only. a specification of a set of instances (which in some cases may contain only one or even no element) but not the instances themselves. Therefore constraining the way such instances can be specified does not formally constrain the instance themselves, even if the difference is subtle.

 

Yves

 

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: mercredi 20 féier 2013 11:23
To: BERNARD, Yves; uml25-ftf@omg.org
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Yves

 

There is a constraint InstanceSpecification::structural_feature that enforces no more than one slot.

 

structural_feature

One StructuralFeature (including the same feature inherited from multiple classifiers) is the defining feature of at most one slot in an InstanceSpecification. 

 

inv: classifier->forAll(c | (c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)))

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 08:25
To: uml25-ftf@omg.org
Subject: [UML 2.52 FTF] Ballot2 review: issue #14035

 

I agree we shall not enforce generalization.general to be .unique. but I think it.s worth adding explanations about the way to deal with members inherited from duplicate general classifiers.

 

Assume .G. a classifier defining an attribute .a.. If .X. is a classifier with two generalization relationships to G, does an instance of X has one or two slots for this attribute .a.?

 

To me the answer is: .only one slot. but, since it is not the easiest to implement for the tools, I believe we should state it explicitly.

 

What do you think?

 

Yves

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

From: "BERNARD, Yves" <Yves.Bernard@airbus.com>
To: Steve Cook <Steve.Cook@microsoft.com>,
        "uml25-ftf@omg.org"
        <uml25-ftf@omg.org>
Date: Thu, 21 Feb 2013 13:57:10 +0100
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Topic: [UML 2.52 FTF] Ballot2 review: issue #14035
Thread-Index: Ac4PQ8AWlsP7kygrTDC3Ofh/mrtw2wAEEZJQAArrvDAAAEWnoAAAWvHwACwoRDA=
Accept-Language: fr-FR, en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
X-Virus-Scanned: amavisd-new at omg.org
X-Brightmail-Tracker: AAAAAgr+n5EdGLWY
X-Brightmail-Tracker: AAAAAA==


Ok, you convinced me.

 

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: mercredi 20 féier 2013 17:02
To: BERNARD, Yves; uml25-ftf@omg.org
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Yves

 

I understand the distinction, although defining UML so that instances could have multiple .slots. for the same feature while InstanceSpecifications could not would be perverse.

 

The current semantics under Structural Features says what it means for instances to have values for attributes, direct and inherited: it does not use the word .slot..  There are various operations on Classifier that define what it means to inherit a feature. These make it clear (especially inheritedMember()) that an inherited feature is inherited once.  I believe that the current spec makes it clear that each member is inherited once and what that means in terms of instances.  If you don.t agree, please raise a new issue citing an ambiguity in the text.

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 15:42
To: uml25-ftf@omg.org
Subject: FW: [UML 2.52 FTF] Ballot2 review: issue #14035

 

 

 

From: BERNARD, Yves 
Sent: mercredi 20 féier 2013 16:41
To: Steve Cook
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Steve,

 

The point is that an InstanceSpecification is .only. a specification of a set of instances (which in some cases may contain only one or even no element) but not the instances themselves. Therefore constraining the way such instances can be specified does not formally constrain the instance themselves, even if the difference is subtle.

 

Yves

 

From: Steve Cook [mailto:Steve.Cook@microsoft.com] 
Sent: mercredi 20 féier 2013 11:23
To: BERNARD, Yves; uml25-ftf@omg.org
Subject: RE: [UML 2.52 FTF] Ballot2 review: issue #14035

 

Yves

 

There is a constraint InstanceSpecification::structural_feature that enforces no more than one slot.

 

structural_feature

One StructuralFeature (including the same feature inherited from multiple classifiers) is the defining feature of at most one slot in an InstanceSpecification. 

 

inv: classifier->forAll(c | (c.allFeatures()->forAll(f | slot->select(s | s.definingFeature = f)->size() <= 1)))

 

-- Steve

 

From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] 
Sent: 20 February 2013 08:25
To: uml25-ftf@omg.org
Subject: [UML 2.52 FTF] Ballot2 review: issue #14035

 

I agree we shall not enforce generalization.general to be .unique. but I think it.s worth adding explanations about the way to deal with members inherited from duplicate general classifiers.

 

Assume .G. a classifier defining an attribute .a.. If .X. is a classifier with two generalization relationships to G, does an instance of X has one or two slots for this attribute .a.?

 

To me the answer is: .only one slot. but, since it is not the easiest to implement for the tools, I believe we should state it explicitly.

 

What do you think?

 

Yves

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

<Down>
<Down>