Contents

1. Iteration zero and beyond
2. Top-level design and source code
3. Next open issues

1. Iteration zero and beyond

• The TicTacToe project has been started in mid 2005 as a case study for software engineering. Deliveries from iteration zero can be found here: TicTacToe 0.2.A / Docs. They include a functional prototype and a product draft (by marucca):
  
• As it may be apparent by comparing those prototypes to current version (TicTacToe 1.2.B), user features have been only slightly improved and overall "completed".
• Those few improvements on 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 handle the overall complexity.

2. Top-level 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 also 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 next section on open issues. Along the right side of the diagram, you can find an essential legenda (to download: right-click / save as...):
  «ENLARGE»

  

  «ENLARGE»
  »SHRINK«

  [S/flow diagram]

  »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, GX_View.Board. These additional 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

«Our primary goal here is to investigate software development concepts and practices, and infer engineering-level indications to formal methods and patterns of construction.»

• 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