Issue 3127: Data Types Misplaced in the "Physical" Metamodel (uml-rtf) (uml2-superstructure-ftf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: All data types used in the UML metamodels are clumped together in a Data_Types package in the Foundation metamodel. When a new type is needed by some other metamodel, such as for Activity Graphs, the type is added into Foundation. This breaks the whole concept of extensibility. Data types, like other model elements, should be defined in the specific packages where they are needed. A new package that requires new types should include those types itself and not impose a change on UML Foundation. Recommendation: In the "physical" metamodel, put data types into the packages where they are first used. For example, PseudostateKind should be defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types. Resolution: Revised Text: Actions taken: December 15, 1999: received issue March 9, 2005: closed issue Discussion: This has already been done at UML 2.0 (e.g. AggregationKind is contained in Kernel::Classes). End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: Data Types Misplaced in the "Physical" Metamodel (uml-rtf) Date: Wed, 15 Dec 1999 12:04:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Yg2!!9[\!!pc5e9=A2e9 All data types used in the UML metamodels are clumped together in a Data_Types package in the Foundation metamodel. When a new type is needed by some other metamodel, such as for Activity Graphs, the type is added into Foundation. This breaks the whole concept of extensibility. Data types, like other model elements, should be defined in the specific packages where they are needed. A new package that requires new types should include those types itself and not impose a change on UML Foundation. Recommendation: In the "physical" metamodel, put data types into the packages where they are first used. For example, PseudostateKind should be defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types. Don Baisley Unisys From: "Baisley, Donald E" To: uml-rtf@omg.org Subject: UML Issue 3127 -- Data Types Misplaced Date: Thu, 17 Feb 2000 15:22:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `SW!!e9+!!F;Xd9Jihd9 Hello UML RTF, The purpose of this message is to bring issue 3127 before you all for your consideration. We discussed this issue at the UML RTF teleconference on 2/16 and decided to ask for more input. Please offer your advice, opinions, and any relevant information about use within the specification of the data types in question. The issue is shown below followed by a list of the data types not used in Foundation and where each is used. Best regards, Don Baisley Unisys ================================ Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel All data types used in the UML metamodels are clumped together in a Data_Types package in the Foundation metamodel. When a new type is needed by some other metamodel, such as for Activity Graphs, the type is added into Foundation. This breaks the whole concept of extensibility. Data types, like other model elements, should be defined in the specific packages where they are needed. A new package that requires new types should include those types itself and not impose a change on UML Foundation. Recommendation: In the "physical" metamodel, put data types into the packages where they are first used. For example, PseudostateKind should be defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types. ================================ Data Types defined in Foundation but not used in Foundation Used in Common_Behavior ObjectSetExpression, ActionExpression, IterationExpression Used in Use_Cases LocationReference Used in State_Machines TimeExpression, PseudostateKind Used in Activity_Graphs ArgListsExpression Used in Extension_Mechanisms Geometry Not used anywhere MessageDirectionKind, Time, Mapping, TypeExpression Date: Tue, 22 Feb 2000 14:04:50 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Baisley, Donald E" CC: uml-rtf@omg.org Subject: Re: UML Issue 3127 -- Data Types Misplaced References: Content-Type: multipart/mixed; boundary="------------ABFE2DC32E3B0F104D7203AB" X-UIDL: OZ>!!/g&!!Y Hello UML RTF, > > The purpose of this message is to bring issue 3127 before you all for your > consideration. We discussed this issue at the UML RTF teleconference on > 2/16 and decided to ask for more input. Please offer your advice, opinions, > and any relevant information about use within the specification of the data > types in question. > > The issue is shown below followed by a list of the data types not used in > Foundation and where each is used. > > Best regards, > Don Baisley > Unisys > > ================================ > Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel > > All data types used in the UML metamodels are clumped together in a > Data_Types package in the Foundation metamodel. When a new type is needed > by some other metamodel, such as for Activity Graphs, the type is added into > Foundation. This breaks the whole concept of extensibility. Data types, > like other model elements, should be defined in the specific packages where > they are needed. A new package that requires new types should include those > types itself and not impose a change on UML Foundation. > > Recommendation: In the "physical" metamodel, put data types into the > packages where they are first used. For example, PseudostateKind should be > defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types. > > ================================ > Data Types defined in Foundation but not used in Foundation > > Used in Common_Behavior > ObjectSetExpression, ActionExpression, IterationExpression > > Used in Use_Cases > LocationReference > > Used in State_Machines > TimeExpression, PseudostateKind > > Used in Activity_Graphs > ArgListsExpression > > Used in Extension_Mechanisms > Geometry > > Not used anywhere > MessageDirectionKind, Time, Mapping, TypeExpression [] gramacke.vcf From: "Baisley, Donald E" To: Guus Ramackers Cc: uml-rtf@omg.org Subject: RE: UML Issue 3127 -- Data Types Misplaced Date: Tue, 22 Feb 2000 17:05:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: jkEe91-*!!Q&Ke9 Hello UML RTF, > > The purpose of this message is to bring issue 3127 before you all for your > consideration. We discussed this issue at the UML RTF teleconference on > 2/16 and decided to ask for more input. Please offer your advice, opinions, > and any relevant information about use within the specification of the data > types in question. > > The issue is shown below followed by a list of the data types not used in > Foundation and where each is used. > > Best regards, > Don Baisley > Unisys > > ================================ > Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel > > All data types used in the UML metamodels are clumped together in a > Data_Types package in the Foundation metamodel. When a new type is needed > by some other metamodel, such as for Activity Graphs, the type is added into > Foundation. This breaks the whole concept of extensibility. Data types, > like other model elements, should be defined in the specific packages where > they are needed. A new package that requires new types should include those > types itself and not impose a change on UML Foundation. > > Recommendation: In the "physical" metamodel, put data types into the > packages where they are first used. For example, PseudostateKind should be > defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types. > > ================================ > Data Types defined in Foundation but not used in Foundation > > Used in Common_Behavior > ObjectSetExpression, ActionExpression, IterationExpression > > Used in Use_Cases > LocationReference > > Used in State_Machines > TimeExpression, PseudostateKind > > Used in Activity_Graphs > ArgListsExpression > > Used in Extension_Mechanisms > Geometry > > Not used anywhere > MessageDirectionKind, Time, Mapping, TypeExpression Date: Wed, 23 Feb 2000 14:29:19 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Baisley, Donald E" CC: uml-rtf@omg.org Subject: Re: UML Issue 3127 -- Data Types Misplaced References: Content-Type: multipart/mixed; boundary="------------E09FA2F5C6CD2C6BB563985C" X-UIDL: 5G9!!W+8e9/)Ge9QCR!! Don, Thanks for clarifying - just to confirm my understanding: any shared datatypes stay in Foundation, but 'local' datatypes that are only used in a single package are defined in the context of that package? Thanks, Guus "Baisley, Donald E" wrote: > Issue 3127 is not suggesting that generally useful data types like Integer > and Boolean be put in specific packages like State_Machines. Rather, it is > suggesting that specific data types that are logically part of specific > packages be put in those specific packages. > > For example, PseudostateKind is a data type that is specific to > State_Machines. It logically belongs in the same package as Pseudostate. > If the State_Machines experts invent a new PseudostateKind value, they > should be able to make the change locally within State_Machines. But as it > is now, they would need to modify the UML Foundation Data_Types package > where the change will affect the XML DTDs and CORBA IDL of all UML > metamodels and the many other metamodels that build on UML (as in CWM). > > I hope this clarifies the issue. > > Best regards, > Don Baisley > Unisys > > -----Original Message----- > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > Sent: Tuesday, February 22, 2000 6:05 AM > To: Baisley, Donald E > Cc: uml-rtf@omg.org > Subject: Re: UML Issue 3127 -- Data Types Misplaced > > Don, > > There seem to be advantages to defining datatypes in the packages where they > are > used. > Reducing dependencies is one you mentioned. Although your proposal appears > to simplify issues here, I have some questions about teh detailed > dependencies: > > Currently all packages are dependent on the Foundation::Datatypes package. > > As potential advantages this has that it lLimits the number of datatype > dependencies to 1 package only. > I.e. if I want to implement package X, I have to implement > Foundation::Datatypes > > (although practically only the datatypes that my tool accepts through > xmi/idl > would have > to be physically implemented) > If Datatypes are defined in the package where "first" used, it seems > possible > that I become dependent on more than 1 package. In fact I may get a > dependency > on > two or more packages, just because I reuse a datatype a few times. > This seems to increase dependency complexity, rather than reduce it? > > Also: what would it mean if I am dependent on a datatype in package X: > surely I will only implement that datatype, not the whole package? > (If so, then maybe being dependent on Foundation::Datatypes isn't that bad > either). > > Thanks, > > Guus > > "Baisley, Donald E" wrote: > > > Hello UML RTF, > > > > The purpose of this message is to bring issue 3127 before you all for your > > consideration. We discussed this issue at the UML RTF teleconference on > > 2/16 and decided to ask for more input. Please offer your advice, > opinions, > > and any relevant information about use within the specification of the > data > > types in question. > > > > The issue is shown below followed by a list of the data types not used in > > Foundation and where each is used. > > > > Best regards, > > Don Baisley > > Unisys > > > > ================================ > > Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel > > > > All data types used in the UML metamodels are clumped together in a > > Data_Types package in the Foundation metamodel. When a new type is needed > > by some other metamodel, such as for Activity Graphs, the type is added > into > > Foundation. This breaks the whole concept of extensibility. Data types, > > like other model elements, should be defined in the specific packages > where > > they are needed. A new package that requires new types should include > those > > types itself and not impose a change on UML Foundation. > > > > Recommendation: In the "physical" metamodel, put data types into the > > packages where they are first used. For example, PseudostateKind should > be > > defined in Behavioral_Elements.State_Machines, not in > Foundation.Data_Types. > > > > ================================ > > Data Types defined in Foundation but not used in Foundation > > > > Used in Common_Behavior > > ObjectSetExpression, ActionExpression, IterationExpression > > > > Used in Use_Cases > > LocationReference > > > > Used in State_Machines > > TimeExpression, PseudostateKind > > > > Used in Activity_Graphs > > ArgListsExpression > > > > Used in Extension_Mechanisms > > Geometry > > > > Not used anywhere > > MessageDirectionKind, Time, Mapping, TypeExpression [] gramacke2.vcf Date: Wed, 23 Feb 2000 14:29:19 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Baisley, Donald E" CC: uml-rtf@omg.org Subject: Re: UML Issue 3127 -- Data Types Misplaced References: Content-Type: multipart/mixed; boundary="------------E09FA2F5C6CD2C6BB563985C" X-UIDL: 5G9!!W+8e9/)Ge9QCR!! Don, Thanks for clarifying - just to confirm my understanding: any shared datatypes stay in Foundation, but 'local' datatypes that are only used in a single package are defined in the context of that package? Thanks, Guus "Baisley, Donald E" wrote: > Issue 3127 is not suggesting that generally useful data types like Integer > and Boolean be put in specific packages like State_Machines. Rather, it is > suggesting that specific data types that are logically part of specific > packages be put in those specific packages. > > For example, PseudostateKind is a data type that is specific to > State_Machines. It logically belongs in the same package as Pseudostate. > If the State_Machines experts invent a new PseudostateKind value, they > should be able to make the change locally within State_Machines. But as it > is now, they would need to modify the UML Foundation Data_Types package > where the change will affect the XML DTDs and CORBA IDL of all UML > metamodels and the many other metamodels that build on UML (as in CWM). > > I hope this clarifies the issue. > > Best regards, > Don Baisley > Unisys > > -----Original Message----- > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > Sent: Tuesday, February 22, 2000 6:05 AM > To: Baisley, Donald E > Cc: uml-rtf@omg.org > Subject: Re: UML Issue 3127 -- Data Types Misplaced > > Don, > > There seem to be advantages to defining datatypes in the packages where they > are > used. > Reducing dependencies is one you mentioned. Although your proposal appears > to simplify issues here, I have some questions about teh detailed > dependencies: > > Currently all packages are dependent on the Foundation::Datatypes package. > > As potential advantages this has that it lLimits the number of datatype > dependencies to 1 package only. > I.e. if I want to implement package X, I have to implement > Foundation::Datatypes > > (although practically only the datatypes that my tool accepts through > xmi/idl > would have > to be physically implemented) > If Datatypes are defined in the package where "first" used, it seems > possible > that I become dependent on more than 1 package. In fact I may get a > dependency > on > two or more packages, just because I reuse a datatype a few times. > This seems to increase dependency complexity, rather than reduce it? > > Also: what would it mean if I am dependent on a datatype in package X: > surely I will only implement that datatype, not the whole package? > (If so, then maybe being dependent on Foundation::Datatypes isn't that bad > either). > > Thanks, > > Guus > > "Baisley, Donald E" wrote: > > > Hello UML RTF, > > > > The purpose of this message is to bring issue 3127 before you all for your > > consideration. We discussed this issue at the UML RTF teleconference on > > 2/16 and decided to ask for more input. Please offer your advice, > opinions, > > and any relevant information about use within the specification of the > data > > types in question. > > > > The issue is shown below followed by a list of the data types not used in > > Foundation and where each is used. > > > > Best regards, > > Don Baisley > > Unisys > > > > ================================ > > Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel > > > > All data types used in the UML metamodels are clumped together in a > > Data_Types package in the Foundation metamodel. When a new type is needed > > by some other metamodel, such as for Activity Graphs, the type is added > into > > Foundation. This breaks the whole concept of extensibility. Data types, > > like other model elements, should be defined in the specific packages > where > > they are needed. A new package that requires new types should include > those > > types itself and not impose a change on UML Foundation. > > > > Recommendation: In the "physical" metamodel, put data types into the > > packages where they are first used. For example, PseudostateKind should > be > > defined in Behavioral_Elements.State_Machines, not in > Foundation.Data_Types. > > > > ================================ > > Data Types defined in Foundation but not used in Foundation > > > > Used in Common_Behavior > > ObjectSetExpression, ActionExpression, IterationExpression > > > > Used in Use_Cases > > LocationReference > > > > Used in State_Machines > > TimeExpression, PseudostateKind > > > > Used in Activity_Graphs > > ArgListsExpression > > > > Used in Extension_Mechanisms > > Geometry > > > > Not used anywhere > > MessageDirectionKind, Time, Mapping, TypeExpression [] gramacke2.vcf From: "Baisley, Donald E" To: Guus Ramackers Cc: uml-rtf@omg.org Subject: RE: UML Issue 3127 -- Data Types Misplaced Date: Wed, 23 Feb 2000 11:58:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: kcad9P*l!!Bd5!!EgW!! Right. -----Original Message----- From: Guus Ramackers [mailto:gramacke@uk.oracle.com] Sent: Wednesday, February 23, 2000 6:29 AM To: Baisley, Donald E Cc: uml-rtf@omg.org Subject: Re: UML Issue 3127 -- Data Types Misplaced Don, Thanks for clarifying - just to confirm my understanding: any shared datatypes stay in Foundation, but 'local' datatypes that are only used in a single package are defined in the context of that package? Thanks, Guus "Baisley, Donald E" wrote: > Issue 3127 is not suggesting that generally useful data types like Integer > and Boolean be put in specific packages like State_Machines. Rather, it is > suggesting that specific data types that are logically part of specific > packages be put in those specific packages. > > For example, PseudostateKind is a data type that is specific to > State_Machines. It logically belongs in the same package as Pseudostate. > If the State_Machines experts invent a new PseudostateKind value, they > should be able to make the change locally within State_Machines. But as it > is now, they would need to modify the UML Foundation Data_Types package > where the change will affect the XML DTDs and CORBA IDL of all UML > metamodels and the many other metamodels that build on UML (as in CWM). > > I hope this clarifies the issue. > > Best regards, > Don Baisley > Unisys > > -----Original Message----- > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > Sent: Tuesday, February 22, 2000 6:05 AM > To: Baisley, Donald E > Cc: uml-rtf@omg.org > Subject: Re: UML Issue 3127 -- Data Types Misplaced > > Don, > > There seem to be advantages to defining datatypes in the packages where they > are > used. > Reducing dependencies is one you mentioned. Although your proposal appears > to simplify issues here, I have some questions about teh detailed > dependencies: > > Currently all packages are dependent on the Foundation::Datatypes package. > > As potential advantages this has that it lLimits the number of datatype > dependencies to 1 package only. > I.e. if I want to implement package X, I have to implement > Foundation::Datatypes > > (although practically only the datatypes that my tool accepts through > xmi/idl > would have > to be physically implemented) > If Datatypes are defined in the package where "first" used, it seems > possible > that I become dependent on more than 1 package. In fact I may get a > dependency > on > two or more packages, just because I reuse a datatype a few times. > This seems to increase dependency complexity, rather than reduce it? > > Also: what would it mean if I am dependent on a datatype in package X: > surely I will only implement that datatype, not the whole package? > (If so, then maybe being dependent on Foundation::Datatypes isn't that bad > either). > > Thanks, > > Guus > > "Baisley, Donald E" wrote: > > > Hello UML RTF, > > > > The purpose of this message is to bring issue 3127 before you all for your > > consideration. We discussed this issue at the UML RTF teleconference on > > 2/16 and decided to ask for more input. Please offer your advice, > opinions, > > and any relevant information about use within the specification of the > data > > types in question. > > > > The issue is shown below followed by a list of the data types not used in > > Foundation and where each is used. > > > > Best regards, > > Don Baisley > > Unisys > > > > ================================ > > Issue 3127 -- Data Types Misplaced in the "Physical" Metamodel > > > > All data types used in the UML metamodels are clumped together in a > > Data_Types package in the Foundation metamodel. When a new type is needed > > by some other metamodel, such as for Activity Graphs, the type is added > into > > Foundation. This breaks the whole concept of extensibility. Data types, > > like other model elements, should be defined in the specific packages > where > > they are needed. A new package that requires new types should include > those > > types itself and not impose a change on UML Foundation. > > > > Recommendation: In the "physical" metamodel, put data types into the > > packages where they are first used. For example, PseudostateKind should > be > > defined in Behavioral_Elements.State_Machines, not in > Foundation.Data_Types. > > > > ================================ > > Data Types defined in Foundation but not used in Foundation > > > > Used in Common_Behavior > > ObjectSetExpression, ActionExpression, IterationExpression > > > > Used in Use_Cases > > LocationReference > > > > Used in State_Machines > > TimeExpression, PseudostateKind > > > > Used in Activity_Graphs > > ArgListsExpression > > > > Used in Extension_Mechanisms > > Geometry > > > > Not used anywhere > > MessageDirectionKind, Time, Mapping, TypeExpression