Issue 8071: ClassifierInState not supported in UML2.0 ? (uml2-rtf) Source: GOO Tech (Mr. Birol Berkem, birol.berkem(at)goobiz.com) Nature: Uncategorized Issue Severity: Summary: In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states. Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes ! Resolution: This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance. Revised Text: In Subclause 12.3.38, under "Changes from Previous UML" add the following sentence at the end of the paragraph: Use of the inState association replaces ClassifierInState in UML 1.5 for activity modeling. Actions taken: January 4, 2005: received issue February 20, 2015: closed issue Discussion: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change End of Annotations:===== m: "Birol Berkem" To: Subject: ClassifierInState not supported in UML2.0 ? Date: Tue, 4 Jan 2005 18:01:44 +0100 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Hello, In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states. Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes ! Thanks in advance Regards, Birol Berkem www.goobiz.com Goal-Driven Development with UML and MDA Reply-To: From: "Conrad Bock" To: , , Subject: RE: issue 8071 -- UML 2 RTF (Superstructure?) issue Date: Tue, 4 Jan 2005 15:44:40 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Birol, > In the UML 1.x, we have the notion of ClassifierInState. We used > them for representing associations and methods of classes that > are valid when instances of these classes are in the > corresponding states. > > Could you let me know how to do that using UML 2 ? If > class-in-states are not supported in UML 2.0, I am afraid, we > cannot represent these valuable information particularly for > reifying business processes. For example Order[Delivery] , > Order[Billing], etc.. with their operations and session attributes ! In UML 2 these would be subclasses of Order, with an OCL constraint referring to that state (using oclInState). For example, Order [Delivery] would be a subclass of Order with the OCL: context Order[Delivery] inv self.ocInState = Delivery where Delivery is an OclState. To ensure all the orders are instances of the corresponding subtype, you can either have subtypes for all the states, and make Order abstract, or use the following expression instead: context Order if self.ocInState = Delivery then self.isKindOf(Order[Delivery]) Not as neat as a dedicated modeling element, but there are lots of reasons to define specialized subclasses, and OCL can capture them all. Subject: Proposed issue resolutions, set 1: Activities -- No change and duplicates Date: Fri, 30 Jan 2009 18:00:16 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, set 1: Activities -- No change and duplicates thread-index: AcmDLoPo5ZLYjIHbRwaX3F8d2ZwvGA== From: "Ed Seidewitz" To: Attached is a Word document with draft resolutions for Activities issues that I propose to close with no change or that I have identified as duplicates of other issues. -- Ed UML 2.3 Resolutions 090130 Seidewitz 1.doc OMG Issue No: 8071 Title: ClassifierInState not supported in UML2.0 ? Source: GOO Tech (Mr. Birol Berkem, birol.berkem@goobiz.com birol@goobiz.com) Summary: In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states. Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes ! Resolution: This is really a question of clarification of a misunderstanding of the submitter, not an issue. The equivalent of ClassifierInState is supported in UML 2 by the ObjectNode inState association. Revised Text: None Disposition: Closed, no Change DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fo31odo+STQz4nvaayejeFrxuqgDuIxh8MOJx3Zy40g=; b=IqTQzko/O8kkXkGBIZSk1/A9JafYj0zgzz2NlnKsezWXtfFlYkh5JkDrM+Z3eZdGHk slOLsbWjURS50Abhnsa3DiIvXAiecdHwZ8lOqMWYIZ3DirjH6N8HdAinD/5jwgPek3gJ po39GAKooFpoxJJJwZEhSvkARZHRwpj6chSew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KT2M6rrCMK2w0GKNToM6vQJmh6nHyIeXFTWsW7jvN3DqhuJU+wVmh+X4Mt3bhvpEqg JOmW9rDQhBwGH+WS3LixCmQgLejjQdTuz2wASWhkD5hTB8EZg6jU6tc8roptQPdSR/3N 2yuw2iO2BrsYmDAWbfH5mmHG2njlzKmT0KEfk= Date: Fri, 30 Jan 2009 18:52:34 -0500 Subject: Re: Proposed issue resolutions, set 1: Activities -- No change and duplicates From: Bran Selic To: Ed Seidewitz Cc: uml2-rtf@omg.org Ed, a few minor comments on the proposed resolutions: -7375: While I agree that the spec should not have to explain FFT (Fast Fourier Transform), the spec should at least provide a reference pointer to some text, for those readers who want to understand the example but don't know about FFT. However, a better solution would be to give a short (one-paragraph?) explanation and a reference. -8071: perhaps the information that you provided in your resolution should be included in the "Changes from UML 1.x" section of the ObjectNode metaclass description? -8673: I suggest reformulating the resolution text, since it reads as if the resolver is not quite sure if the problem has been solved or not (because of the way the word "seems" is used in the text). I think that the intent here was to say that the problem no longer exists, but what is still unclear is when in the past it was resolved. - 9395: same problem as 8673; i.e., because of the word "seems", it sounds as if the resolver is not quite sure if the problem has been solved or not. Cheers...Bran On Fri, Jan 30, 2009 at 6:00 PM, Ed Seidewitz wrote: Attached is a Word document with draft resolutions for Activities issues that I propose to close with no change or that I have identified as duplicates of other issues. -- Ed Subject: RE: Proposed issue resolutions, set 1: Activities -- No change and duplicates Date: Sat, 31 Jan 2009 10:29:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, set 1: Activities -- No change and duplicates thread-index: AcmDNeigOGg55xX7RRGfwZtWKnlL7wAgiVkg From: "Ed Seidewitz" To: "Bran Selic" Cc: Bran . Thanks for the comments. See below. -7375: While I agree that the spec should not have to explain FFT (Fast Fourier Transform), the spec should at least provide a reference pointer to some text, for those readers who want to understand the example but don't know about FFT. However, a better solution would be to give a short (one-paragraph?) explanation and a reference. [EVS] I don.t know. The point of the example isn.t really to show how to do FFT in UML, it is to give a realistic-looking example of the use of expansion regions. I don.t think the reader really needs to know anything about FFT in order to get something useful from the example on how expansion regions can be used. In any case, I am probably not the right person to write up an explanation of FFT for the example. Would you (or someone else) like to do it? If someone does, I wouldn.t object to including it. But if no one wants to come up with such a revised resolution, I think the example is still useful, and I don.t think there is any point in just leaving the issue open. -8071: perhaps the information that you provided in your resolution should be included in the "Changes from UML 1.x" section of the ObjectNode metaclass description? [EVS] Good idea. I will revise the resolution. -8673: I suggest reformulating the resolution text, since it reads as if the resolver is not quite sure if the problem has been solved or not (because of the way the word "seems" is used in the text). I think that the intent here was to say that the problem no longer exists, but what is still unclear is when in the past it was resolved. - 9395: same problem as 8673; i.e., because of the word "seems", it sounds as if the resolver is not quite sure if the problem has been solved or not. [EVS] Good points on the above. I will revise the text. -- Ed Subject: Proposed issue resolutions, Set 2: Activities -- Low and trivial effort changes Date: Sun, 1 Feb 2009 23:25:51 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, Set 2: Activities -- Low and trivial effort changes thread-index: AcmE7lQ9kq9LsV5zRgKwNovhcAlo8A== From: "Ed Seidewitz" To: Attached are proposed resolutions to 21 additional Activity issues that only required low or trivial effort changes (though there are a few that, on further analysis, I decided to propose to close or identified as duplicate). -- Ed OMG Issue No: 8071 Title: ClassifierInState not supported in UML2.0 ? Source: GOO Tech (Mr. Birol Berkem, birol.berkem@goobiz.com birol@goobiz.com) Summary: In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states. Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes ! Resolution: This is really a question of clarification of a misunderstanding of the submitter.. The equivalent of ClassifierInState is supported in UML 2 by the ObjectNode inState association. Revised Text: In Subclause 12.3.38, under .Changes from Previous UML. add the following sentence at the end of the paragraph: Use of the inState association replaces ClassifierInState in UML 1.5. Disposition: Resolved Reply-To: From: "Conrad Bock" To: "'Ed Seidewitz'" , Subject: RE: Proposed issue resolutions, set 1, Activities, revised Date: Mon, 9 Feb 2009 12:53:46 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmE7asVdGlXYjIDSN6pynRH5qVWDwF8Vycg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n19HrkOp012676 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1234806828.38654@iXeq9PRY9WN20j2XYxcxUA X-Spam-Status: No Ed, Comments on the revised ACtivity 1 resolutions. Conrad Issue 8071 (ClassifierInState not supported in UML2.0 ?) ClassifierInState is not supported in UML 2. In UML 1 it was a way for classifiers to be restricted in their state. The ObjectNode only does this for a particular point in an activity. Issue 8973 Would be good to correct this to prevent confusion, since the UML Subject: RE: Proposed issue resolutions, set 1, Activities, revised Date: Mon, 9 Feb 2009 13:09:29 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed issue resolutions, set 1, Activities, revised thread-index: AcmE7asVdGlXYjIDSN6pynRH5qVWDwF8VycgAABqOuA= From: "Ed Seidewitz" To: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n19I9P6S027867 Conrad -- > Ed, > > Comments on the revised ACtivity 1 resolutions. > > Conrad > > > Issue 8071 (ClassifierInState not supported in UML2.0 ?) > > ClassifierInState is not supported in UML 2. In UML 1 it was a way > for classifiers to be restricted in their state. The ObjectNode > only does this for a particular point in an activity. Well, ClassifierInState is introduced in the abstract syntax for Activity Graphs in UML 1.x, so that was where it was usually used. You are right, though, that there is a comment that it "may be used in static structural models and collaborations", too. Is there any UML 2 equivalent for that? > Issue 8973 > > Would be good to correct this to prevent confusion, since the UML > 1.x symbol has much more rounded sides. I really don't think it is worth the effort to correct the relevant diagrams. Unless there is a consensus of the RTF that the diagrams should really be changed, I would suggest that we leave the resolution as closed no change. (Of course, if the RTF consensus is to change the diagrams, then this moves out of the category of an "easy effort" low-priority change -- in which case it will probably not be fixed anyway...) Synchronize your IT with your changing environment..