RJLRef: $CASE/06f522/SetGame06f/DomainModelReview_rl_kb_rlRev1.txt Message 17/1496 From Keith Bagley Nov 28, 06 10:45:26 AM -0500 To: Bob Lechner Cc: all Subject: Re: $PH/06f522/06f522inCASE/kbagley/models/assignment4_domainModel.gif Hi Prof Lechner. Some of these items you've raised will have to be discussed with the team in class tonight. See my responses below for the items I can address right now... ------------------------------------------------------------------ Bob Lechner 11/28/2006 01:45 AM To Keith Bagley/Bedford/IBM@IBMUS cc: all Subject: $PH/06f522/06f522inCASE/kbagley/models/assignment4_domainModel.gif RJLRef: $PH/06f522/SetGame06f/DomainModelReview_rl061128.txt Hello Keith. I looked at your .gifs in $PH/06f522/06f522inCASE/kbagley/models/ (---> $CASE/06f522/...) I have a few questions to discuss with the team re: your domain model on Tues evening. Most of them do not affect SetGame06f stand-alone project code, but they would if code or table-driven control flow was auto-generated by GEN and LCP. Bob Lechner 2. The size of the .gifs is to small (particularly fontsize) for projection so they are mot much good as is. Is that a problem inherited from VISIO? KB>> Yes, this is a VISIO problem. I mentioned how bad visio was, but didn't go into detail. This is one of the details. I'll see if I can manually expand the elements and text without breaking the shape constraints they've imposed on their UML diagramming elements. I'll also rename the diagrams appropriately to SetGame04f. 3. It seems to mix active and passive classes. Only ActiveInstances (AIs) communicate by events; KB>> I disagree, unless you're using a definition of ActiveInstance/PassiveInstance that is different from the standard UML definition of ActiveObjects/PassiveObjects. From the UML Reference Manual, 2nd Ed (Rumbaugh, Jacobson, Booch) pg 148 (active object semantics, last paragraph): "The active-passive distinction is primarily a design decision and does not constrain the semantics of the objects. BOTH active and passive objects may have state machines and may exchange events" ------------------ >>[RJL: I concur. (My 1999 1Ed. has the above quote on p. 132.). >>When they have state models, their control can optionally >>be captured in a StateModel database and interpreted by LCP. >>Should they be? I'll bet (but the jury is still out) that if >>flag variables are set to remember past conditions that may no longer >>exist (or the same condition still exists and is repeatedly >>re-evaluated to avoid such flags) then State Models may help >>to understand control flow within a synchronous or passive method.] >> [RJL: My interest is in 2-way migration between state modeling >>of control flow, and procedural code: How (when & why) to expand >>a 1-state procedure into a multi-state control-flow model >>that connects its components (defined as state actions); >>How (when & why) to contract such a hierarchical or composite >>state model into a single 1-state procedures again. >>Asynchronous event vs. synchronous call semantics is already >>merged into State Models already, in the form of Guard Conditions >>coupled with Event-driven concurrency.] ------------------- AIs can create and maintain passive instances; passive ones merely obey CRUD operations (Create,Read,Update,Delete)Get and Set. KB>> Again, from the UML Reference Manual, pg 514 indicates PassiveObjects may send messages and process requests (not limited to CRUD). The basic difference is that PassiveObjects do not have their own thread of control. >>[RJL: (Off the cuff - subject to refutation:-)] >>This may be our difference wrt. the AI/PI separation boundary: >>AI with asynchronous events (and guard conditions) >>AI or PI: No asynch events, but state memory influences later control flow; >> they may generate events e.g. notifications to active receivers, >> and they do not receive (but may poll for) such events. >>PI: Neither asynch events nor internal state memory influence control flow. >> (E.g. a FFT or an image transformation.) >> Events may be generated from within such a PI if called from an AI. >>I classify the middle level as AI; UML2 classifies them as PI.?] KB>> *Note: these are UML2 definitions; I don't know if there was a change from UML1.x -> 2.x wrt Active/Passive Objects ----------------------- >>[RJL: Rumbaugh: OMT Insights (SIGS/CUPress1996): p 353-259 >>(OMT Functional Model: Operation Specs, Object Interaction Diagrams, >>Concurrent OIDs); (from JOOP 3/94:) >>"An active object is an object that maintains its own state >>and exchanges asynchronous events with other objects. >>[node with thick-line border.] >>An active object is a composite object that can contain other objects >>(including other active objects). Any passive objects in it >>are under the control of the active object; >>they are accessed with procedure calls, not true >>asynchronous events between independent objects." >>(E.g. Fig. 3 p. 358) ] ---------------------- I would prefer a cleaner separation of concerns: EERD structural diagrams as analysis data models, class diagrams (retaining all associative entities) as design data models, with separately evolving communication diagrams at objectType (ActiveClass) level. KB>> I agree to a certain extent, although I would add that Sequence Diagrams and Use Case Realizations with Activity Diagrams are useful elements at the analysis level as well for what most of industry is doing now. Since you're adept at executable UML (and I am not), I'm guessing your comments are based on that background. However, 98% of my clients are not anywhere near doing xUML (some of them can't even spell UML! :-), so the iterative approach of refining Sequence interactions and UC Realizations helps "bridge the gap" between the work on domain-specific analysis assets, and what they will have to (manually) develop during design and implementation. 7. Without associating players and boards, there is ambiguity in the data model, unless only one board is in use at a time. (Can a Dealer over time have multiple boards?) If multiple SetGames are played sequentially by the same players on the same board, then should Game be inserted betwen Board and Game or between Dealer and Board? (I prefer the latter.) KB>> I think we're still hashing that out?