Issue 3341: Statemachine/state as Namespace (uml2-superstructure-ftf) Source: University of Oslo (Prof. Birger Møller-Pedersen, birger(at)ifi.uio.no) Nature: Uncategorized Issue Severity: Summary: I am not sure if this qualify as an Issue, but I what just wondering why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element? Resolution: Revised Text: Actions taken: February 28, 2000: received issue March 9, 2005: closed issue Discussion: In UML 2.0, state machines are kinds of namespace, and states can be made into namespaces via the submachine state mechanism. End of Annotations:===== From: Birger Mxller-Pedersen (ETO) To: "'uml-rtf@omg.org'" Subject: Statemachine/state as Namespace Date: Mon, 28 Feb 2000 17:44:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-OriginalArrivalTime: 28 Feb 2000 16:44:52.0437 (UTC) FILETIME=[227A8850:01BF820B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id LAA07581 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X+L!!T&h!!b?9!![`@e9 I am not sure if this qualify as an Issue, but I what just wondering why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element? Regards /birger Birger Mxller-Pedersen Ericsson NorARC P.O. Box 34, N-1375 Billingstad, Norway Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 Mob: +47 918 27 279 E-mail: birger.moller-pedersen@eto.ericsson.se Date: Tue, 29 Feb 2000 09:29:00 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Birger Mxller-Pedersen (ETO) CC: "'uml-rtf@omg.org'" Subject: Re: Statemachine/state as Namespace References: <89BF44E217C8D21192EB0008C7A4E25201FD3E11@enoasnt100.eto.ericsson.se> Content-Type: multipart/mixed; boundary="------------06A8F16DB265DE360CDAF951" X-UIDL: d7$e9DF&!!Z0~e92hdd9 Birger, I believe that in UML 1.3 it is currently not the case that all sets of unique names are automatically a NameSpace. Effectively, a NameSpace dictates that the 'primary' contained elements have unique names, unless that constraint is overridden. For an example see Package (with Association as the exception: duplicate names for those are allowed in a Package). There are, in addition, elements that have specific "name uniqueness" constraints in OCL. Here's a quote from the NameSpace definition: "In the metamodel, a Namespace is a ModelElement that can own other ModelElements, like Associations and Classifiers. The name of each owned ModelElement must be unique within the Namespace. Moreover, each contained ModelElement is owned by at most one Namespace. The concrete subclasses of Namespace have additional constraints on which kind of elements may be contained. Namespace is an abstract metaclass. Note that explicit parts of a model element, such as the features of a Classifier, are not modeled as owned elements in a namespace. A namespace is used for unstructured contents such as the contents of a package or a class declared inside the scope of another class." Given this current approach, it seems reasonable that a State and a StateMachine are not NameSpaces. Are there any specific (OCL) naming constraints that with regard to State or StateMachine that you feel are currently missing? Thanks, Guus Birger Mxller-Pedersen (ETO) wrote: > I am not sure if this qualify as an Issue, but I what just wondering > why Statemachine and State are not Namespaces. Is it so that names > are not supposed to be defined within these, or do names end up in > the Namespace of the context model element? > > Regards > > /birger > > Birger Mxller-Pedersen > Ericsson NorARC > P.O. Box 34, N-1375 Billingstad, Norway > Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 > Mob: +47 918 27 279 > E-mail: birger.moller-pedersen@eto.ericsson.se birger.moller-pedersen@eto.ericsson.se> [] gramacke1.vcf From: Birger Mxller-Pedersen (ETO) To: "'Guus Ramackers'" , Birger Mx ller-Pedersen (ETO) Cc: "'uml-rtf@omg.org'" Subject: RE: Statemachine/state as Namespace Date: Wed, 1 Mar 2000 09:43:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-OriginalArrivalTime: 01 Mar 2000 08:55:43.0343 (UTC) FILETIME=[ED2327F0:01BF835B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id KAA01156 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ()7!!,Yld9nF8!!2fZ!! Guus, I was just wondering if it is so that all state names of a state machine, including the substates of composite states to any depth have to be different, and as far as I can see this is the case according to the definition. The tool we are using allows, however, that e.g. a substate of a composite state has the same name as a state at the same level as the composite state. The other issue that triggered the question is the following: What in UML tells that e.g. attributes and operations are visible in the class itself (e.g. in the specifiaction of other operations and methods)? For packages it is defined that local packages see outwards, but that is linked to the fact that packages are more or less just namespaces. For state machines I would guess that within transitions the features of the context model element are visible, but how? It seems obvious that associating a statemachine with a class brings the state machine into a context where the features of the class are visible, but this is apparently not done by means of namespaces. Your answer reminded me of another question: When there is a distiction between explicit parts of a model element and elements owned by the namespace of the same element, it is apparently possible for one model element to have two elements (one explicit and one owned) with the same name - or is that ruled out by other means. /birger > -----Original Message----- > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > Sent: 29. februar 2000 10:29 > To: Birger Mxller-Pedersen > Cc: 'uml-rtf@omg.org' > Subject: Re: Statemachine/state as Namespace > > > Birger, > > I believe that in UML 1.3 it is currently not the case that > all sets of unique names are automatically a NameSpace. > > Effectively, a NameSpace dictates that the 'primary' > contained elements have unique names, unless that constraint > is overridden. > For an example see Package (with Association as the > exception: duplicate names for those are allowed in a Package). > There are, in addition, elements that have specific "name > uniqueness" constraints in OCL. > > Here's a quote from the NameSpace definition: > > "In the metamodel, a Namespace is a ModelElement that can own > other ModelElements, like > Associations and Classifiers. The name of each owned > ModelElement must be unique within > the Namespace. Moreover, each contained ModelElement is owned > by at most one Namespace. > The concrete subclasses of Namespace have additional > constraints on which kind of elements > may be contained. Namespace is an abstract metaclass. > > Note that explicit parts of a model element, such as the > features of a Classifier, are not modeled > as owned elements in a namespace. A namespace is used for > unstructured contents such as the > contents of a package or a class declared inside the scope of > another class." > > > Given this current approach, it seems reasonable that a State > and a StateMachine are not NameSpaces. > > Are there any specific (OCL) naming constraints that with > regard to State or StateMachine that you feel are currently missing? > > Thanks, > > Guus > > > Birger Mxller-Pedersen (ETO) wrote: > > > I am not sure if this qualify as an Issue, but I what just > wondering > > why Statemachine and State are not Namespaces. Is it so > that names are not supposed to be defined within these, or do > names end up in the Namespace of the context model element? > > > > Regards > > > > /birger > > > > Birger Mxller-Pedersen > > Ericsson NorARC > > P.O. Box 34, N-1375 Billingstad, Norway > > Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 > > Mob: +47 918 27 279 > > E-mail: birger.moller-pedersen@eto.ericsson.se Date: Wed, 01 Mar 2000 10:22:02 +0000 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Birger Mxller-Pedersen (ETO) CC: "'uml-rtf@omg.org'" Subject: Re: Statemachine/state as Namespace References: <89BF44E217C8D21192EB0008C7A4E25201FD3E14@enoasnt100.eto.ericsson.se> Content-Type: multipart/mixed; boundary="------------EDDA08D007C0516C24463EB7" X-UIDL: 7%*e9`!`d9<]C!!7]N!! Birger, > I was just wondering if it is so that all state names of a state machine, including the substates of composite states to any depth have to be different, and as far as I can see this is the case according to the definition. The tool we are using allows, however, that e.g. a substate of a composite state has the same name as a state at the same level as the composite state. OK probably more a vendor issue than a UML issue. > For state machines I would guess that within transitions the features of the context model element are visible, but how? The details of this are expected to come from the Action Semantics work. > It seems obvious that associating a statemachine with a class brings the state machine into a context where the features of the class are visible, but this is apparently not done by means of namespaces. NameSpaces are indeed not used in that way in UML. As far as I'm aware, in UML 1.3 there is no formal restriction on how the Transitions of a StateMachine (single object context) or ActivityGraph (multi-object context) are labelled, and which attributes or methods (etc) they reference - see the action semantics work. > Your answer reminded me of another question: When there is a distiction between explicit parts of a model element and elements owned by the namespace of the same element, it is apparently possible for one model element to have two elements (one explicit and one owned) with the same name - or is that ruled out by other means. Perhaps you could bring this question up for some concrete model elements in Denver - probably easier than via e-mail. Thanks, Guus > > > /birger > > > -----Original Message----- > > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > > Sent: 29. februar 2000 10:29 > > To: Birger Mxller-Pedersen > > Cc: 'uml-rtf@omg.org' > > Subject: Re: Statemachine/state as Namespace > > > > > > Birger, > > > > I believe that in UML 1.3 it is currently not the case that > > all sets of unique names are automatically a NameSpace. > > > > Effectively, a NameSpace dictates that the 'primary' > > contained elements have unique names, unless that constraint > > is overridden. > > For an example see Package (with Association as the > > exception: duplicate names for those are allowed in a Package). > > There are, in addition, elements that have specific "name > > uniqueness" constraints in OCL. > > > > Here's a quote from the NameSpace definition: > > > > "In the metamodel, a Namespace is a ModelElement that can own > > other ModelElements, like > > Associations and Classifiers. The name of each owned > > ModelElement must be unique within > > the Namespace. Moreover, each contained ModelElement is owned > > by at most one Namespace. > > The concrete subclasses of Namespace have additional > > constraints on which kind of elements > > may be contained. Namespace is an abstract metaclass. > > > > Note that explicit parts of a model element, such as the > > features of a Classifier, are not modeled > > as owned elements in a namespace. A namespace is used for > > unstructured contents such as the > > contents of a package or a class declared inside the scope of > > another class." > > > > > > Given this current approach, it seems reasonable that a State > > and a StateMachine are not NameSpaces. > > > > Are there any specific (OCL) naming constraints that with > > regard to State or StateMachine that you feel are currently missing? > > > > Thanks, > > > > Guus > > > > > > Birger Mxller-Pedersen (ETO) wrote: > > > > > I am not sure if this qualify as an Issue, but I what just wondering > > > why Statemachine and State are not Namespaces. Is it so > > that names are not supposed to be defined within these, or do > > names end up in the Namespace of the context model element? > > > > > > Regards > > > > > > /birger > > > > > > Birger Mxller-Pedersen > > > Ericsson NorARC > > > P.O. Box 34, N-1375 Billingstad, Norway > > > Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 > > > Mob: +47 918 27 279 > > > E-mail: birger.moller-pedersen@eto.ericsson.se birger.moller-pedersen@eto.ericsson.se> [] gramacke.vcf From: "Eran Gery" To: "'Birger M ller-Pedersen (ETO)'" , "'Guus Ramackers'" Cc: "'uml-rtf@omg.org'" Subject: RE: Statemachine/state as Namespace Date: Wed, 1 Mar 2000 19:41:24 +0200 Message-ID: <004e01bf83a5$5e447350$471c5ac2@potato.ilogix.co.il> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <89BF44E217C8D21192EB0008C7A4E25201FD3E14@enoasnt100.eto.ericsson.se> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: H-V!!M;p!!c`?e9DUA!! > -----Original Message----- > From: Birger M ller-Pedersen (ETO) > [mailto:Birger.Moller-Pedersen@eto.ericsson.se] > Sent: Wednesday, March 01, 2000 10:44 AM > To: 'Guus Ramackers'; Birger Mxller-Pedersen (ETO) > Cc: 'uml-rtf@omg.org' > Subject: RE: Statemachine/state as Namespace > > > Guus, > > I was just wondering if it is so that all state names of a > state machine, including the substates of composite states to > any depth have to be different, and as far as I can see this > is the case according to the definition. The tool we are > using allows, however, that e.g. a substate of a composite > state has the same name as a state at the same level as the > composite state. This is how it should be, and I agree with Guus there is nothing in the UML that I am aware of that prevents this. States are not owned by namespaces, by explicitly by composition. We may have to add an OCL that forbid sibling states to have the same name. > > The other issue that triggered the question is the following: > What in UML tells that e.g. attributes and operations are > visible in the class itself (e.g. in the specifiaction of > other operations and methods)? For packages it is defined > that local packages see outwards, but that is linked to the > fact that packages are more or less just namespaces. For > state machines I would guess that within transitions the > features of the context model element are visible, but how? > It seems obvious that associating a statemachine with a class > brings the state machine into a context where the features of > the class are visible, but this is apparently not done by > means of namespaces. This is not explicitly specified in the UML, since it primary touches the boundary of a surface action language that need to resolve expressions based on the "context". Once someone uses an action syntax, I'd definitely expect that what you say will happen, but it is more of a tool issue. > > Your answer reminded me of another question: When there is a > distiction between explicit parts of a model element and > elements owned by the namespace of the same element, it is > apparently possible for one model element to have two > elements (one explicit and one owned) with the same name - or > is that ruled out by other means. > It is currently not ruled out, and I am not sure it should in all > cases. General speaking though, it is currently impossible to write an OCL that says "all explicitly and owned elements should have unique > names". I believe that there is a proposal in UML 2.0 to handle the explicit > ownership (composition) in a more generic way, that simplifies writing such constrains. Currently it requires to write an OCL that explicitly > enumerates for every model elements all the explicitly owned elements via > composition relationships and verifies no name clashes. For example, in case of a classifier, there is a set of OCL rules that prohibit features to have similar names. In case of an operation for example, there is no OCL that verifies unique names for the parameters, and as said earlier, also in a case of composite state. - Eran Gery > /birger > > > > -----Original Message----- > > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > > Sent: 29. februar 2000 10:29 > > To: Birger Mxller-Pedersen > > Cc: 'uml-rtf@omg.org' > > Subject: Re: Statemachine/state as Namespace > > > > > > Birger, > > > > I believe that in UML 1.3 it is currently not the case that > > all sets of unique names are automatically a NameSpace. > > > > Effectively, a NameSpace dictates that the 'primary' > > contained elements have unique names, unless that constraint > > is overridden. > > For an example see Package (with Association as the > > exception: duplicate names for those are allowed in a Package). > > There are, in addition, elements that have specific "name > > uniqueness" constraints in OCL. > > > > Here's a quote from the NameSpace definition: > > > > "In the metamodel, a Namespace is a ModelElement that can own > > other ModelElements, like > > Associations and Classifiers. The name of each owned > > ModelElement must be unique within > > the Namespace. Moreover, each contained ModelElement is owned > > by at most one Namespace. > > The concrete subclasses of Namespace have additional > > constraints on which kind of elements > > may be contained. Namespace is an abstract metaclass. > > > > Note that explicit parts of a model element, such as the > > features of a Classifier, are not modeled > > as owned elements in a namespace. A namespace is used for > > unstructured contents such as the > > contents of a package or a class declared inside the scope of > > another class." > > > > > > Given this current approach, it seems reasonable that a State > > and a StateMachine are not NameSpaces. > > > > Are there any specific (OCL) naming constraints that with > > regard to State or StateMachine that you feel are currently missing? > > > > Thanks, > > > > Guus > > > > > > Birger Mxller-Pedersen (ETO) wrote: > > > > > I am not sure if this qualify as an Issue, but I what > just wondering > > > why Statemachine and State are not Namespaces. Is it so > > that names are not supposed to be defined within these, or do > > names end up in the Namespace of the context model element? > > > > > > Regards > > > > > > /birger > > > > > > Birger Mxller-Pedersen > > > Ericsson NorARC > > > P.O. Box 34, N-1375 Billingstad, Norway > > > Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 > > > Mob: +47 918 27 279 > > > E-mail: birger.moller-pedersen@eto.ericsson.se birger.moller-pedersen@eto.ericsson.se> > From: Birger Mxller-Pedersen (ETO) To: "'Eran Gery'" , Birger Mxller-Pe dersen (ETO) , "'Guus Ramackers'" Cc: "'uml-rtf@omg.org'" Subject: RE: Statemachine/state as Namespace Date: Thu, 2 Mar 2000 14:22:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-OriginalArrivalTime: 02 Mar 2000 13:24:24.0843 (UTC) FILETIME=[A0B695B0:01BF844A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id IAA16307 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4aWd9D:Ee9(7"e9/,b!! > -----Original Message----- > From: Eran Gery [mailto:erang@ilogix.co.il] > Sent: 1. mars 2000 18:41 > To: 'Birger M ller-Pedersen (ETO)'; 'Guus Ramackers' > Cc: 'uml-rtf@omg.org' > Subject: RE: Statemachine/state as Namespace > > > > > > -----Original Message----- > > From: Birger M ller-Pedersen (ETO) > > [mailto:Birger.Moller-Pedersen@eto.ericsson.se] > > Sent: Wednesday, March 01, 2000 10:44 AM > > To: 'Guus Ramackers'; Birger Mxller-Pedersen (ETO) > > Cc: 'uml-rtf@omg.org' > > Subject: RE: Statemachine/state as Namespace > > > > > > Guus, > > > > I was just wondering if it is so that all state names of a > > state machine, including the substates of composite states to > > any depth have to be different, and as far as I can see this > > is the case according to the definition. The tool we are > > using allows, however, that e.g. a substate of a composite > > state has the same name as a state at the same level as the > > composite state. > > This is how it should be, and I agree with Guus there is > nothing in the UML > that I am aware of that > prevents this. States are not owned by namespaces, by explicitly by > composition. We may have to > add an OCL that forbid sibling states to have the same name. > For large statemachines I am not so sure that this is the way it should be, but that is a separate (and longer) discussion. There are most certainly reasons for having namespace as a metaclass, but it appears to be simpler simply to say that all model elements that define names form namespaces, and then have one rule saying that names within a namespace are different. > > > > The other issue that triggered the question is the following: > > What in UML tells that e.g. attributes and operations are > > visible in the class itself (e.g. in the specifiaction of > > other operations and methods)? For packages it is defined > > that local packages see outwards, but that is linked to the > > fact that packages are more or less just namespaces. For > > state machines I would guess that within transitions the > > features of the context model element are visible, but how? > > It seems obvious that associating a statemachine with a class > > brings the state machine into a context where the features of > > the class are visible, but this is apparently not done by > > means of namespaces. > > This is not explicitly specified in the UML, since it primary > touches the > boundary > of a surface action language that need to resolve expressions > based on the > "context". > Once someone uses an action syntax, I'd definitely expect > that what you say > will happen, > but it is more of a tool issue. > If visibility of things defined as explicit properties or in namespaces only has to do with resolving expressions in the surface of an action language, why does UML has the notion of visibility of features of classifiers? > > > > Your answer reminded me of another question: When there is a > > distiction between explicit parts of a model element and > > elements owned by the namespace of the same element, it is > > apparently possible for one model element to have two > > elements (one explicit and one owned) with the same name - or > > is that ruled out by other means. > > > It is currently not ruled out, and I am not sure it should in > all cases. > General speaking though, it is currently impossible to write an OCL > that says "all explicitly and owned elements should have > unique names". I > believe that there is a proposal in UML 2.0 to handle the > explicit ownership > (composition) in a more generic way, that simplifies writing such > constrains. Currently it requires to write an OCL that > explicitly enumerates > for every model elements all the explicitly owned elements > via composition > relationships and verifies no name clashes. > > For example, in case of a classifier, there is a set of OCL rules > that > prohibit features to have similar names. In case of an operation for > example, there is no OCL that verifies unique names for the > parameters, and > as said earlier, also in a case of composite state. > > - Eran Gery > > > /birger > > > > > > > -----Original Message----- > > > From: Guus Ramackers [mailto:gramacke@uk.oracle.com] > > > Sent: 29. februar 2000 10:29 > > > To: Birger Mxller-Pedersen > > > Cc: 'uml-rtf@omg.org' > > > Subject: Re: Statemachine/state as Namespace > > > > > > > > > Birger, > > > > > > I believe that in UML 1.3 it is currently not the case that > > > all sets of unique names are automatically a NameSpace. > > > > > > Effectively, a NameSpace dictates that the 'primary' > > > contained elements have unique names, unless that constraint > > > is overridden. > > > For an example see Package (with Association as the > > > exception: duplicate names for those are allowed in a Package). > > > There are, in addition, elements that have specific "name > > > uniqueness" constraints in OCL. > > > > > > Here's a quote from the NameSpace definition: > > > > > > "In the metamodel, a Namespace is a ModelElement that can own > > > other ModelElements, like > > > Associations and Classifiers. The name of each owned > > > ModelElement must be unique within > > > the Namespace. Moreover, each contained ModelElement is owned > > > by at most one Namespace. > > > The concrete subclasses of Namespace have additional > > > constraints on which kind of elements > > > may be contained. Namespace is an abstract metaclass. > > > > > > Note that explicit parts of a model element, such as the > > > features of a Classifier, are not modeled > > > as owned elements in a namespace. A namespace is used for > > > unstructured contents such as the > > > contents of a package or a class declared inside the scope of > > > another class." > > > > > > > > > Given this current approach, it seems reasonable that a State > > > and a StateMachine are not NameSpaces. > > > > > > Are there any specific (OCL) naming constraints that with > > > regard to State or StateMachine that you feel are > currently missing? > > > > > > Thanks, > > > > > > Guus > > > > > > > > > Birger Mxller-Pedersen (ETO) wrote: > > > > > > > I am not sure if this qualify as an Issue, but I what > > just wondering > > > > why Statemachine and State are not Namespaces. Is it so > > > that names are not supposed to be defined within these, or do > > > names end up in the Namespace of the context model element? > > > > > > > > Regards > > > > > > > > /birger > > > > > > > > Birger Mxller-Pedersen > > > > Ericsson NorARC > > > > P.O. Box 34, N-1375 Billingstad, Norway > > > > Tel: +47 66 84 06 23 Fax: +47 66 84 12 25 > > > > Mob: +47 918 27 279 > > > > E-mail: birger.moller-pedersen@eto.ericsson.se > birger.moller-pedersen@eto.ericsson.se> > > > > From: "Eran Gery" To: "'Birger M ller-Pedersen (ETO)'" , "'Guus Ramackers'" Cc: "'uml-rtf@omg.org'" Subject: RE: Statemachine/state as Namespace Date: Thu, 2 Mar 2000 17:16:01 +0200 Message-ID: <008001bf845a$39ac9d00$471c5ac2@potato.ilogix.co.il> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <89BF44E217C8D21192EB0008C7A4E25201FD3E29@enoasnt100.eto.ericsson.se> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: <1Ge9hBj!!6@Je97JCe9 > > > > > This is how it should be, and I agree with Guus there is > > nothing in the UML > > that I am aware of that > > prevents this. States are not owned by namespaces, by explicitly > by > > composition. We may have to > > add an OCL that forbid sibling states to have the same name. > > > > For large statemachines I am not so sure that this is the way > it should be, but that is a separate (and longer) discussion. > > There are most certainly reasons for having namespace as a > metaclass, but it appears to be simpler simply to say that > all model elements that define names form namespaces, and > then have one rule saying that names within a namespace are > different. I belive this will be cleaned up in 2.0. IMO, there is a need to unify the composition and namespace concepts for this to be completely clean. > > This is not explicitly specified in the UML, since it primary > > touches the > > boundary > > of a surface action language that need to resolve expressions > > based on the > > "context". > > Once someone uses an action syntax, I'd definitely expect > > that what you say > > will happen, > > but it is more of a tool issue. > > > > If visibility of things defined as explicit properties or in > namespaces only has to do with resolving expressions in the > surface of an action language, why does UML has the notion of > visibility of features of classifiers? > Feature visibility is part of the specification of the feature, although it does not impact the well formedness of the model itself. In case of "importing" the classifier context to the state machine, it is not a part of the specification of the features or the states, it has to do with the mechanics on how the state-machine accesses the features. Clearly, the actions have the right to access the features, and maybe this should be explicitly stated, although it's strongly implied by the semantics. However, it is not a visible model issue, but rather an implementation issue as long as the action syntax is not part of the modeling language. - Eran Gery