From omg-list-errors@emerald.omg.org Mon Dec 9 10:32:19 2002 Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by saturn.cs.uml.edu (8.11.6/8.11.6) with ESMTP id gB9FVA8101367 for ; Mon, 9 Dec 2002 10:31:10 -0500 (EST) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by emerald.omg.org (8.11.0/8.9.2) with ESMTP id gB9F7f302615 for ; Mon, 9 Dec 2002 10:07:41 -0500 (EST) Received: from eurmta01.london.eur.slb.com [134.32.26.55] by hobbit.omg.org asmtp(1.4f) id 2091; Mon, 09 Dec 2002 10:13:14 -0500 (EST) Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.02 (built Sep 16 2002)) id <0H6U00201X6CIW@eurmta01.london.eur.slb.com> for adtf@omg.org; Mon, 09 Dec 2002 15:06:27 +0000 (GMT) Received: from mailrelay2.sema.co.uk (unused-041-014.London.eur.slb.com [157.203.41.14]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.02 (built Sep 16 2002)) with ESMTP id <0H6U00LN7XW25Q@eurmta01.london.eur.slb.com> for adtf@omg.org; Mon, 09 Dec 2002 15:04:50 +0000 (GMT) Received: from lonns01.sema.co.uk (lonns01.London.eur.slb.com [157.203.40.61]) by mailrelay2.sema.co.uk (8.11.6+Sun/8.11.6) with ESMTP id gB9F4Km04164 for ; Mon, 09 Dec 2002 15:04:20 +0000 (GMT) Received: from lones3.sema.co.uk (unverified) by lonns01.sema.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Mon, 09 Dec 2002 14:52:10 +0000 Received: by lones3.sema.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 09 Dec 2002 15:01:15 +0000 Content-return: allowed Date: Mon, 09 Dec 2002 15:01:00 +0000 From: "BERRISFORD, Graham" Subject: RE: UML-2 MDA Issue List - (why subtype states?) To: "'Bob Lechner'" , "'steve@projtech.com'" Cc: "'lechner@saturn.cs.uml.edu'" , "'adtf@omg.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Status: X-Keywords: X-UID: 838 Status: RO Steve I overlooked the issue we started with. Of course, one Robot has many Robot States, and each Robot State is either X, Y or Z. This preserves the rule that subclasses must be mutually exclusive and an instance cannot swap from one class to another. And it is surely closer to a "right model" than the model that omits "Robot State", even if that model works when coded. Below - do you mean we should take optionality or mutually exclusivity of data groups/attributes as a key factor in driving decomposition of entities into classes? Now you are turning into a data modeller! Decomposing something into smaller units just to understand/manage each bit more readily, is different from decomposing something into smaller units because the overall solution is more economical, measured by some criterion to be defined. If (wearing my FSM modeller hat) I take economy of state variable values to be the measure, I come up with different answers from if (wearing my data modeller hat) I take economy of data storage to be the measure. I accept the impossibility and futility of striving for one "right" model, or even one modelling paradigm, without having defined the measure(s) up front. Graham > From steve@projtech.com Sat Dec 7 20:52:26 2002 > From: "Stephen J. Mellor" > To: "Bob Lechner" > Cc: "Bob Lechner" , , > , > Subject: RE: UML-2 MDA Issue List - Generalization & Dynamic Subtypes (why subtype states?) > > There's nothing wrong with this view, if that's the view you want > to take :) However, your paragraph starting "However," below > concerns me greatly. You say: > > | However, it also hides the real semantics suggested by meaningful action > | names associated with state roles, which would help us visualize behavior > | and maintain the diagram's connection to its implementation source code. > > As far as I'm concerned, this is a killer argument for wanting > to allow the model I describe. > > Separately, my example did not draw out another critical feature, > that the subtypes may themselves have different data as well as > different behavior, which includes different associations. For > example, the normally operating robot may have an attribute > 'destination', and the lost robot, and only a lost robot, may > have an association to a Request, the one that is deferred. > I agreed with you, that this is important, in my Caveat: parag: > | Caveat: Nested sub-machines may justify subclasses, but only > | to the extent they extend the Active Class with more data. > | But just because submachines extend the state of a superclass > | or parent machine, they do not need to become nested subtypes. > | I tend to think of submodels as compositions, and their > | instantiations as dynamic transient aggregations. > Stuffing all that data into a single class suffers from the same > problems as you correctly aver for behavior above (and below :). > Understanding that the 'destination' attribute has no meaning for > the robot when it is initializing, and 'deferredRequest' attribute > has meaning only when the robot is lost for half a dozen attributes > quickly becomes impossible. > I quite agree that the model must be split. I objected to having to call the virtual action routine function in the superclass instead of specifically-named functions of subclasses, and to lack of mnemonic labels for action routine names on submodel diagrams (if code maintainers now have to infer an implicit correspondence). In fact, my alternative proposal (composition of submodels) also provides a hierarchy of classes, with one 'Active Class' per state, and one 'Active Instance' object of a child class, which is not a 'State' but a 'State Machine'. However, this new instance of a State Model is a component of the aggregate that is the Active Class of the parent container (not parent superclass). 'Building the 4-component aggregate model also makes it easy'. (analogous to your words below :-) I can't draw the data model for such an implementation here, but you can view it (and source code for its entities, via hotspots:-) at www.cs.uml.edu/~lechner/97f522/DEMO/JPArchitecture_HG000003.html (BTWay,I got lots of mileage out of your JuicePlant case study :-) Active Instance inter-communication via Event Instances supports RPC or parallel invocation across, up and down the compositonal hierarchy. This approach can be implemented in either C or C++. Our current life-cycle interpreter is written in C. In C++, the Active Class holds static data members for its Active Instance objects (i.e., access to the State Model meta-database). > These examples could be handled by OCL, but the very freedom > of OCL makes it hard to discern patterns. What the modeler > wants to know is What data and behavior does a Lost Robot have? > Building the four class model I have described makes that easy. > > -- steve > > > | -----Original Message----- > | From: Bob Lechner [mailto:lechner@cs.uml.edu] > | Sent: Friday, 2002-12-06 22:34 > | To: Stephen J. Mellor > | Cc: Bob Lechner; adtf@omg.org; uml2-eval@omg.org; uml2review@omg.org > | Subject: Re: UML-2 MDA Issue List - Generalization & Dynamic Subtypes > | (why subtype states?) > | > | > | I append some concerns about Steve's 'state as subtype' model below. > | I'd appreciate some hints on what is wrong with my view. > | > | > From omg-list-errors@emerald.omg.org Fri Dec 6 17:29:34 2002 > | > From: "Stephen J. Mellor" > | ... > | > Subject: RE: UML-2 MDA Issue List - Generalization & Dynamic Subtypes > | > Date: Fri, 6 Dec 2002 15:14:07 -0700 > | > > | > Re: UML-2 MDA Issue List - Generalization & Dynamic SubtypesThanks: Nice > | > description of time-scoped analysis as it applies in this case. > | > > | > But the conclusion that's drawn is more than little arbitrary, isn't it? > | > > | > I ask you: How would you model this situation? You have a > | Robot that runs > | > along a track. When the system is initialized, the robot runs > | off to a known > | > place that we call (0, 0, 0, 0). It then goes about its > | business delivering stuff. > | > Trouble is, for a host of reasons that don't matter for this > | discussion, the > | > robot can become lost. Under these circumstances, the robot > | goes to a known > | > place (0, 0, 0), but it does not drop its cargo (the fourth zero) > | > > | > Now I model this by a supertype Robot and subtypes > | Initializing, Operating > | > and Lost, migrating between the three as required. It's > | simple, easy and neat. > | > There is one state chart diagram for each of the subtypes, created and > | > deleted by sending signals. Common data belongs with the supertype > | > > | > Making UML(*) 'simple' is not about throwing away constructs you happen > | > not to use or to like. If it were, I could make UML very > | simple indeed :) > | > > | > -- steve > | > (*) Or its schema as it evolves. > | > > | > | I have always been troubled about identifying states of an Active Class > | with subtypes of this class, when it seemed to me that a life-cycle state > | code (enumerated) attribute would be sufficient. Instead, > | I made do with a C-style switch(state) and case blocks for each one. > | My justification was that nothing changed among these subtypes except > | this state code and the function(s) that are executed on entry > | (and during, > | and on exit) to the state. > | > | Calling this action as an anonymous 'do-your-thing'function > | simplifies the source code: this action call can now be in the supertype, > | since each subclass == state can over-ride the supertype default. > | > | However, it also hides the real semantics suggested by meaningful action > | names associated with state roles, which would help us visualize behavior > | and maintain the diagram's connection to its implementation source code. > | > | I agree that if data member types change when the life-cycle state value > | of an Active Class instance changes, then subclasses may well be > | justified. > | But unless more things are different among two states than their names > | and action routines, I don't see any value in subtypes. > | I would like to see more counter-examples to this simplification. > | > | State actions depend on both state and event instance data. > | and guard condition values depend (usually) on data from both. > | The outcomes depend equally on the Active Object's > | complete data state and the Event Instance's complete argument list. > | I don't see why the data type of either one should change during the > | object's life cycle. > | > | Caveat: Nested sub-machines may justify subclasses, but only > | to the extent they extend the Active Class with more data. > | But just because submachines extend the state of a superclass > | or parent machine, they do not need to become nested subtypes. > | I tend to think of submodels as compositions, and their > | instantiations as dynamic transient aggregations. > | > | I'd appreciate some hints on what is wrong with this view. > | > | Thanks. > | > | Bob Lechner > | CS Dept UMass Lowell > | lechner@cs.uml.edu > | rJLRef: ~/02f522/WhySubtypeStates.021106 > _________________________________________________________ This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of SchlumbergerSema. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify the SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600. _________________________________________________________