1. OOD Case Study (For parallel treatment, see Chapter 2 of the text)

2. Elements of Class Design  Static class diagram  UML: Unified Modeling Language  Pseudocode for operations  Can be vague when it comes to details  Should be precise about control and function

3. Criteria for Good Class Design  Correctness: solves the problem  Simplicity  Cohesion: everything in a class directed at a single purpose  Coupling/Information Hiding: classes should never depend upon knowing the internal implementations of other classes  Error Handling: design should be robust.

4. Problem Statement: The 8-Puzzle The 8-puzzle is a device consisting of eight numbered and sliding tiles arranged in a 3x3 grid. An 8-puzzle problem is an initial state and a final state along with a list of legal actions that can be performed on states. 283 164 75 123 84 765 283 14 765 283 164 75 283 164 75 283 164 75 up downleft right initial final

5. 8-Puzzle Problem Statement (cont'd)  You are to write a program that simulates the solving of an 8- puzzle problem.  Your program must display an initial state of the 8-puzzle and then prompt the player for an action. After displaying the initial state, the program repeatedly prompts for actions, displaying the results of each action until the final state is achieved.  If an action is not possible, that is, it attempts to move a tile into an occupied space or off the edge of the board, the program must issue a diagnostic message and reprompt the player. When the final state is reached, the number of actions made is displayed. Illegal attempted moves are not counted.

6. Important Aspects of the Problem Statement  It describes the problem and defines precisely what constitutes a solution  It makes clear the "rules of the game"  It uses diagrams and examples  It does not attempt to describe how the problem is to be solved, only what the problem is  It specifies the program behavior in sufficient detail

7. Identifying Potential Classes: Collect Problem Statement Nouns State 8-puzzle Device Board Grid Tile Space Action Action List Solver Problem Message Player

8. Analyzing Potential Classes State: holds all information about an 8-puzzle state including how to move tiles 8-puzzle, Device, Board, Grid: redundant Tile: unnecessary Space: part of a State Action: contains a function for moving a tile Action List: collection of Actions, one for each legal move Problem: creates the Action List. Contains initial State, final State, and Action List Solver: contains the Problem, knows how to prompt and check for solution Message: unnecessary Player: unnecessary

9. A Primitive Class Diagram Problem State Action ActionList Solver

10. Characterizing Classes  Q: How do you determine which class to start with?  A: Identify classes that do not depend on others for their definition:  The Solver object requires a Problem to solve  The Problem object requires an Initial State, Final State, and ActionList  The ActionList object requires Actions  The Action object requires a State on which to perform itself  This leaves the State class as a good one with which to begin.

11. Class Diagram with Dependencies Solver Problem ActionList State Action depends on

12. Elements of a Complete Class Diagram  All data specified with types  All operations specified with return types, parameters, and parameter types  All operations specified as public or private (data should never be public)  Class dependencies indicated via annotated connectors and arrows

13. Example: Solver Class Solver -problem: Problem +Solver(p: Problem) +solve(): void -promptActionName(): String

14. Notes on the Solver Class  A ``-'' prefix indicates the data or operation is private, a ``+'' prefix indicates public.  The constructor for a class has the same name as the class.  The Solver constructor requires a Problem object from which to get the initial and final States, and the Action List.  The solve operation is public since it will be called from outside the class.  The promptActionName operation is private because it is used only by solve.

15. Another Example: The Problem Class Problem -startState: State -finalState: State -actionList: ActionList +Problem(startTileNums: StringArray) +getStartState(): State +getFinalState(): State +getActionList(): ActionList -createActionList(): void

16. Notes on the Problem Class  The Problem constructor receives an array of strings from which to build the start State.  getStartState, getFinalState, and getActionList are data accessors used by the Solve class.  createActionList is a private operation that builds the ActionList by using the tile motion operations from the State class

17. Relationship of the Solver and Problem Classes Solver Problem -startState: State -finalState: State -actionList: ActionList problem 1 1

18. Class Associations  The Solver and Problem classes are related by association, a relationship between instances of classes.  The label ``problem'' is the role name; the role that the Problem class plays for the Solver class.  When there is a role name, it can be left out of the box in the interests of simplicity.  The numbers at either end of the line are multiplicities; in this case there is always one solver and one problem

19. Pseudocode for the solve() Operation void solve() current = get start state from problem final = get final state from problem alist = get action list from problem count = 0 while current is not final do display current action = get action from user if action is valid then new = apply action to current current = new increment count else issue message display current and count congratulate

20. Notes on the Pseudocode  Nonexecutable  Control structures used ( while, if...then)  Loop details not explicit  Code blocks indicated through indentation (personal preference)

21. State Class  Data: Representation of the 8-puzzle board Representation of the blank position  Operations: Create a new state Display the current configuration of the puzzle Check if state is equal to another Move blank up, down, left or right...

22. New Class Diagram Solver Problem -actionList: ActionList Problem 1 1 State 1 startState finalState 2

23. Action Class  Data: Name (up, down, left, right) Operation to perform the action--What, an operation as data??  Operations: Create a new action Execute the action operation...

24. Action Class Notes  Operations for moving the tile are already in the State class--why a separate Action class?  Because we want to abstract out as much of the generic design as possible for use with other problems  Abstraction is facilitated by having an ActionList composed of Actions.  To put an action on a list, it has to be regarded as data.  In C++, we will do this using pointers to static methods.

25. ActionList Class  Data: The actions The total number of actions  Operations: Create a new action list Add an action to the action list Find an action by name...

26. New Class Diagram Solver ActionList Action Problem State problem startState finalState actionList 11 1 2 1 * 1 1

27. Comments on New Diagram  The relationship between ActionList and Action is one of aggregation, indicated by a diamond at the end of the line.  The multiplicity ``*'' means ``any number''.

28. The Art of OOD There is no one correct design for a given problem. You may wish to emphasize classes other than those chosen here. You should design your solutions in a way which is natural to you. However you should strive for SIMPLICITY. Also, you should design for REUSE (difficult).

29. Advantages of Design Simplicity  Easier to understand  Easier to implement  Easier to debug  Easier to maintain

30. Designing For Reuse  The general State class was chosen rather than the more specific 8-puzzle  The Action, ActionList, and Solver classes do not know anything about the 8-puzzle problem domain, so they can be applied to other domains  Advantage: Code can become part of a class library and used for other purposes

31. Example Class Definition in C++ class SolverInfo { private: Problem problem; public: SolverInfo(Problem p); void solve(); private: static String promptActionName(); };

32. Notes On the "SolverInfo" Class 1 Q: Why ``SolverInfo'' and not just ``Solver''?  Because Solver will be defined to be a pointer to a class object SolverInfo 2 No methods are defined in-line (defined in a separate file) 3 No data members are public 4 All public methods are part of the class interface

33. Example Main Program #include "ProblemInfo.H" #include "SolverInfo.H" int main(Integer argc, StringArray problemArgs) { Problem p = new ProblemInfo(problemArgs); Solver s = new SolverInfo(p); s->solve(); } Note that this program makes no mention of the 8-puzzle, and thus could be used on other problems suitably defined.