Development process in vogelvlucht:

  1. Define use cases (or user stories) and non-functional requirements
  2. Start with the most important use cases. Start with the "happy day flows" where everything goes right.
  3. Look for functional components or classes to divide the work that has to be done (divide and conquer!)
  4. Add implementation details
  5. Write and test the code

 

 

Refine requirements stepwise all the way down the development process

It is extremely important that requirements are worked out gradually from abstract high level requirements to concrete code. They have to go through the phases Requirements, Analysis and Design first before the can be implemented. Each phase ends up with milestones they have to be evaluated by stakeholders and users.

 

Break down complexity by addressing classes with responsibilities

 

Class Responsibility
Board Orchestration of user requests 
House Orchestrating of sudoku rules
Cell Managing digits and pencil marks

 

During Design the following classses are added:

Class Responsibility
Location Managing navigation
Candidates Bitwise operations

 

What's essential about architecture is that you can not set up a good architecture in an ivory tower. The pictures you make must be useful and not become wallpaper. Architecture encompasses standards, principles, guidelines, conceptual models, patterns, mechanisms and more.

The non-functional requirements are a good starting point for setting up software architecture artifacts.

Functionality

Functionality is covered by use cases, but often there are also use case transcending functional requirements like patterns and mechanisms. An example:

subclass plaatje met Region voor killer sudoku

 

Usability

From an architectural perspective the following principles are relevant:

  • Separation of presentation logic, business logic and data
  • Selection before action

By separating the business logic, the sudoku rules, this logic can be re-used by both mobile devices and desktop computers.

 

Mobile devices like smartphones and tablets must handle touchscreen events, while traditional desktop applications must handle keyboard and mouse events. So the presentation logic differs, but the sudoku logic is the same.   

Selection before action can be considered as a user interface guideline as well. For the app the principle means that the user first has to select one or more cells and then activate an action upon these selected cells, for instance by pushing a button.

 

Reliability

Reliability can be divided into Confidentiality, Integrity and Availability (CIA). For the app there are no real security issues, but for availability there is a autosave requirement (R001). Important design decisions are the usage of the browser's local storage and the JSON standard for serialization and deserialization of objects (the board objects).

 

Performance

To ensure a response time within 100 milliseconds (requirement P001) cell candidates are stored in a bitmask. Candidates can be added and removed by using bitwise operations.

Example:

Suppose a cell has 4 candidates 1, 3, 7 and 9

These candidates can be stored in 2 bytes as

These 2 bytes can be interpreted as a 16-bit integer as well

If you want to remove candidate 7, you shift in a new bitmask with value 1 that value 7 positions to the left

Then you compare the 2 bitmasks using a logical AND operator

Now the resulting bitmask has candidate 1, 3 an 9

Note that In Javascript the smallest integer is a 64-bit integer, which means that bitwise operations are not really effective.

 

Supportability

A supportability principle that has been used for the app is:

  • Separation of the know and the flow

Separation of the know (rules) and the flow (processes and presentation) is important for the maintainability and reusability of the sudoku rules. 

 A common pattern for setting up a web app is MVC, see Model-View-Controller. Since the app is a Javascript application controllers are represented by eventhandlers and views are represented by HTML-pages. The model is represented by the implementation independent analysis model (class diagram).

Other patterns that has been used are the strategy and the visitor pattern,see software design patterns.

Software can be written in many languages. For the app Javascript has been chosen. There are some drawbacks:

  • Javascript is a (slow) interpreter
  • Javascript uses weak typing
  • Javascript doesn't support class inheritance

 

R001 Autosave possibility

Each user event (keyboard-, mouse- or touchscreen event)  must trigger a saved snapshot of the board.

 

U001 Undo/Redo possibility

For this requirement you can specify a mechanism

 

U003 Hint/Autosolve possibility

For autosolve a backtracking algorithm can be used. 

 

 

 

 


 

Use cases describe the functional requirements for the app. Additional requirements can be categorized as follows.

F Functionality

F001 Import/Load facilities

F002 Usage of colors

F003 Delete functionality

U Useability

U001 Undo/Redo possibility

U002 Reset possibility

U003 Hint/Autosolve possibility

U004 Desktop/Mobile devices

R Reliablility

R001 Autosave possibility

R002 24/7 availability

P Performance

P001  Response within 100ms     

S Supportability

S001 Easy adaptable

S002 Easy extendable

Play !

 

Down under you find a list of very hard sudoku puzzles. You can copy a puzzle from the screen and paste it into the dropbox of the app. You can solve up each puzzle using the "Apply logic" button until the 6 basic sudoku rules don't give any progress anymore. At this point you must find the advanced technique to break the puzzle. It can be a simple swordfish, but it can also be a complex grouped continuous nice loop or a sue de coq. When you have applied such a technique you can use "Apply logic" again. Good luck!

Sudoku puzzles:

 

 

Source code:

 

  • You are here:  
  • Home
  • English