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 List of topics: --------------------------------- 1. The administration of the game 2. The size of the .gifs is to small 3. Active vs. passive classes 4. Card to BoardSlot association 5. 12-card Layout subset of the Deck 6. Four facet or property value attributes 7. Associating players with board[s] 8. Database Replication for Clients. 9. Logging for object-level communication visibility 10.Multiple Decks vs. Game histories ---------------------------------------- 1. Administration of the game is undefined so far: E.g. how does the game start, how do players join, how do they know their scores, etc.. what code keeps score, and how are host sites of players set up for networking? Does anyone in particular have this task assignd? 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? (I didn't use that to see assignment4.vsd.) BTWay, this is project SetGame04f, not assignment 4. 3. It seems to mix active and passive classes. Only ActiveInstances (AIs) communicate by events; AIs can create and maintain passive ones; passive ones merely obey CRUD operations (Create,Read,Update,Delete)Get and Set. [My preference is to show all classes in the Data Model on the class diagram. I recognize a weakness in this approach is that classes consisting only of methods may be ignored or get lost in this forest of entity types (e.g., methods for control, factories, bridges). Passive classes disappear on the ACCD but the class data model diagram/schema restores their visibility, in a form that is more accurate for code generation. Here is where I disagree with UML/Larman. Their kind of domain model emphasizes the multiple class-level relationships and communications, but is imprecise (and confusing) about other class model associations. 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. The Class Comm'n Diagram only needs ActiveClasses (ACCommD). They interact asynchronously through event messages (EI's). External inputs generate some of these events. State Model State Actions generate the rest. LCP's database provides access to control flow among these State Actions and their generated EventInstances. Communication Diagrams at objectInstance (AI) level are a possible extension of the LCP schema. See comments below. 4. The Card to BoardSlot association is 0..1 to 0..1, since each direction is a partial function (Board has < 12 cards when Deck is exhausted). 5. The 12 Cards on the board are really contained in an (ordered) 12-card Layout subset of the Deck. I recommend inserting a Layout class to represent this 12-card subset between Deck and Card. a. Layout needs replication at each Player/DSG_Client. b. Deck is arguably needed only at the c. Dealer/Controller/DSG_Server(ralmonte). d. Deck changes like a queuee, while Layout changes randomly, 3 slots at a time. 6. Thare are four facet or property value attributes on each card (a candidate key! :-) . A child_set of four Facet or Property values for each Card would give this repeating group more visibility (compared to four data fields). This is optional because SetGame cards have such simple properties. I used it to demo the interaction among multiple StateMachine types and ActiveInstances in SetGame04x as another example besides the Hominid. BoardSlot is a 1 to 1 associative entity relating Card to Board. It works better with Layout instead of Deck as one of its 'containers'. If Card has complex behavior (e.g. constructive graphics calls depend variously on its facets) then Card might optionally become an ActiveClass, but otherwise it is passive. E.g. chess pieces have more complex properties like move constraints, so they become ActiveClasses. 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.) How are players associated with the card layout they see? Are all players playing one Game on one board, at any time? That would be the case if boards were displaying the 'auto-shuffled' deck, one deck and game at a time. But then there would be multiple sequential game objects each having one board. 8. Database Replication for Clients: It is unclear how and what objects get replicated at separate Client-player sites. The domain model doesn't exlain this. Should it? (required for at least this sub-view: Layout--->Card--->BoardSLot<---Board) For SetGame, replicating the Deck is optional since a Card's properties are easily decoded from its radix 3 encoding as card index. The Board/Layout with 12 slots MUST be replicated (or regenerated) as the state of each Client from which to draw its local View of the board. 9. Logging for object-level (ActiveInstance Communication Diagram) visibility? An ACCD is represented in the LCP schema by an inter-AC link. from some class node ACid1 to class node ACid2. (AIid1 == AIid2 is possible.) An AICD (or OCD for short) is a snapshot of behavior over time. It represents possible histories of EI interaction. Each EI has an ETid fkey and two AI fkeys AIid1 and AIid2. (I prefer OCD over AICD. OCD is Shlaer-Mellor's term.) Both inter-class ACCD and inter-object (OCD) links can be inferred from logs. Specifically, an event of type ETid is sent from node AIid1 to node AIid2 iff this EI has the three fkeys ETid, ACid1, ACid2. This EI must be generated within some action of some state of some SM of some AI of Active Class ACid1. Simulations must associate other ACs and AIs with the external environment or external actors to capture their I/O events. A byproduct of this log can be sequence diagrams. These show message flow among a subset of objects with concurrent time histories in parallel 'swim-lanes'. An AICD (ActiveInstance Communication Diagram) or OCD constrains possible histories of object interactions. Sequences of EventInstances with AIId1 and AIid2 fkeys can be logged and their traced history used to derive and display a Sequence Diagram. A set of Sequence Diagrams can be reverse-engineered into a (partial) AICD and a (partial) ACCD can be inferred from the AICDs. 10. Multiple Decks vs Game histories? I am quite willing to forego the multi-board aspect, since a new process or a restart of the same one can begin each new game, maintaining the same player context. Then Deck---Game---Board is 1 to 1 to 1 (except for Board replication at Clients?) I would prefer to retain the history or trace log of which card triples are selected as sets, and by whom. Logging all EI messages would automatically provide such statistics. (Perhaps this would be of interest to psychologists who look for correlations between pattern recognition traits of players and their backgrounds - or brain activity:-) Bob Lechner > From kbagley@us.ibm.com Mon Nov 27 19:57:11 2006 > Cc: all > Ok. Done. In my "models" subdirectory > Keith > > ----- original msg ------ > Pls. upload .gif and (editable) source to $CASE/06f522/kbagley.Thanks. > > Bob Lechner > 11/27/2006 06:42 PM