The difference between analysis and design is that analysis is implementation independent and design is implementation dependent. During design you look at the the software architecture (principles and guidelines) and non-functional requirements.
Here you work out HOW you present data and HOW you store and retrieve data. Try to keep the analysis model intact, then the model can be re-used for different implementations.
An example of a design class:
This class is used for the fulfillment of requirement U001 (Undo/Redo possibility).
The next example shows the presentation layer of the Sudoku app. Together with the MVC-pattern it can help to clarify how the app has been constructed.
During the design phase UML sequence diagrams are further refined with platfom dependent implementation details, like GUI details and data storage details. Now you also look at the non-functional requirements. Some examples:
Requirement: U003 Hint/Autosave possibility
Autosave is a saving function which automatically saves the current progress of the puzzle, helping to reduce the risk of data loss.
For each user request (set digit, set color, apply logic and so on) the state of the board is "stringified" by a JSON object and the resulting character string is stored in the local storage of the browser.
The sudoku object represents the GUI, the model represents the domain model with the analysis classes.
Requirment: U001 Undo/Redo possibility
The user must have the possibility to rollback and rollforward user actions (keyboard-, mouse- and touchscreen events). Not that such a requirement has functional aspects as well. The diagram below can help to clarify these aspects.
Functional aspects:
When the user (= actor) fires an action request (e.g. ..), the undostack from the current position is cleared. This means that when the user steps back to a previous state of the board and continues with other actions, the ... are lost
UI guideline Selection before action !!!!
The diagram above depicts a state diagram for a board during the auto solve process. During this iterative process each time the operations SetDigit(), UpdateSiblings() and AcceptSingles() cause a new state of the board, valid or invalid (color red). When an invalid state occurs, the solve process returns to the previous state and continues with the next cell candidate. When there are no more candidates (see R2C1) the solve process returns to a a previous state as well. Technically this process is called backtracking.
Examine the following screen shots of the app to get a clear picture how it works. The yellow candidates are accepted singles.
The diagram above shows the refinement of the useability requirement "Autosolve". In step 1 the actor asks the sudoku object, which represents the UI (User Interface), to solve the sudoku puzzle. In step 1.1 the sudoku object activates the board object to manage the work to be done. The first time AutoSolve is called without parameters, therefore 1.1.1 GetCell, 1.1.2 SetDigit and 1.1.3 UpdateSibling are skipped. In the first loop the board evaluates the 6 basic rules and accepts resulting singles until there are no more singles to accept. In step 1.1.6 the board checks whether the puzzle has already been solved or not. If solved, the board returns in 1.1.11 "solved". In step 1.1.7 the board looks up the cell with the fewest candidates. For each candidate the board creates in 1.1.8 a new board and sends the message AutoSolve to this new board object. Now AutoSolve is sent with 2 parameters, the location of the cell with the fewest candidates and the candidate value. The new board gets in 1.1.1 the cell with the given location, sets in 1.1.2 the candidate value and removes in 1.1.3 the candidate form all siblings in the row, the column and the box. Then the other steps are repeated over and over again until the puzzle has been solved or an invalid state occured.
Note that during the phase analysis a UML sequence diagram diagram doesn't contain implementation details. Implementation details are added during the phase design.
Page 2 of 5