TicTacToe 1.2.B / Docs (preview)
Tic-tac-toe online game in JavaScript

Contents

1. Iteration zero and beyond
2. Design and source code
3. Next open issues

1. Iteration zero and beyond

TicTacToe the project was started in mid 2005 as a case study for software engineering. Deliveries from iteration zero can be found in TicTacToe 0.2.A / Docs. These include a functional prototype and a product draft (by marucca).

As it may be apparent by comparing prototype 0.2.A to the current version (TicTacToe 1.2.B), user features have been just slightly improved and overall completed.

Those few improvements at the surface correspond to, and have required, the first actual engineering of the product, involving:

• a major restructuring of the code towards a model-view-controller pattern (MVC) plus widgets;
• many rounds of refactoring to improve readability, modularity, and conventions;
• a growing design-level documentation to manage the overall complexity.

2. Design and source code

Below is a top-level design diagram mainly showing: the modules composing the system, their structural relationships, and the flow of control.

(Particularly, structural notation is very informal here because the overall architecture is still emerging, and because the underlying JavaScript implementation does not fit quite naturally into an object-oriented paradigm as implied by industry standard notations, namely UML - at least, to the best of our current knowledge!)

In orange are elements marked for revision or extension: these will be illustrated in the next section on open issues. An essential legenda is along the right side of the diagram (to download: right-click / save as...):

• «ENLARGE»

  

  «ENLARGE»
  »SHRINK«

  

  »SHRINK«

(This diagram is coupled with a high-level pseudo-class diagram, and detailed state-transition diagrams for the few modules with significant complexity, namely: GX_Board, GE_Controller, and GX_View.Board. These diagrams are not provided here.)

Follows a reference list to the source files along with a summary description of the modules they package (to download: right-click / save as...):

• Engine.source.js
  GE_Controller: "universal" game controller
  GE_Model: wrapper to concrete model
  GE_APlayer: wrapper to concrete player
  
• Board.source.js
  GX_Board: (tic-tac-toe) game model
  
• APlayer.source.js
  GX_APlayer: (tic-tac-toe) automatic player
  
• View.source.js
  GX_View: (tic-tac-toe) game view context
  GX_View.Board: board widget
  GX_View.Score: score widget
  GX_View.Info: info widget
  GX_View.Ctrl: controls widget
  GX_View.CtrlExt: external controls widget
  
• Driver.source.js
  GX_Driver: (tic-tac-toe) main game driver
  GX_Driver.Engine: facade to engine system
  GX_Driver.View: facade to view system
  

3. Next open issues

The software process in place for TicTacToe follows a road-map to a radical agile approach where: [A] implementation drives design (forward engineering), and design supports back implementation (reverse engineering). This is called "implementation-driven development" (IDD).

There are some underlying open issues to this:

• our process model needs a "link-up" to: [B] the conceptual level of development (requirements analysis - quality assurance); in this field, greater insight is coming from the concepts of "behaviour-driven development" (BDD) and their emphasis on requirements-based testing;
  
• our implementation needs to isolate: [C] control patterns and state machines (instances in a procedural paradigm), from: [D] computational flow and algebraic expressions (occurrences of a functional paradigm); in this field, greater insight is coming from the concepts of "functional programming" and their emphasis on modularity.
  

All these components are crucial to a deeper formalization and instrumentation of the (software) development process as a whole.

At the moment, these high-level requirements are informally tied to elements marked in orange within the TicTacToe top-level design diagram. These marks remind us of the areas promising immediate development:

1. GX_APlayer:
   the concrete player is the only module in the system with significant computational requirements; its current implementation is little more than a stub; this module promises development in the sense of a functional (algebraic) paradigm [A, D];
   
2. GE_Controller:
   the universal game controller is the most complex state machine in the system; its current implementation lacks abstraction and normalization; this module promises development in the sense of a procedural (imperative) paradigm [A, C];
   
3. GX_View:
   this module is currently no more than a context object for the view widgets; also, there is no uniformity in synchronization logic built into the widgets (it may be apparent that interface elements are out of sync); to start from, this module should implement a common clock source for widgets synchronization [A];
   
4. GX_View.CtrlExt:
   the external controls widget is marked for revision to remind that the implementation of "default working parameters" needs further elaboration; the very status of this information is in question, since it is not yet clear whether it belongs to the procedural vs. the functional side of the implementation, and if/how to properly expose it [A, B];
   
5. GX_Driver:
   the game driver module is marked for revision to remind that the higher level design needs significant development; possibly, additional insight and a higher level of abstraction may come from working out a time-constrained, concurrent implementation [A, B].
   

Issued : 2007-01-05 00:00 GMT+1