Modelling Theory and Practice/Models in Software Engineering and Business Analysis
The Chess Example edit
This is a large example of a chess program, how it is modelled as an analytic information system, i.e. without any technological design. We start with a tiny example and expand it in small steps.
The long-term goal of the program is to manage chess games (i.e. display, store, replay, etc. them) as well as to calculate own moves. The former corresponds to a typical database centric business application, the latter is a complex algorithmic problem, i.e. 'just' a single function of very high complexity (typically approached by methods of Artificial Intelligence).
Version 0.1: Board with Pieces edit
Context edit
Our initial version should simply do the basic job of receiving moves and displaying a board with the current position. Since we focus on the modelling of the functionality and not on user interaction, it is assumed that our application has an interface to some user interface unit for receiving the moves and displaying the board, as in the diagram Context. The moves are given as a pair of squares, as described in the next section.
Functionality edit
From the information system perspective the core value of the application is to keep persistent information of the status of the board, and change it according to moves entered. However, there are more changes to the board than chess moves. For example, positions can be set up or special moves like queening, where a pawn mutates to a queen, can occur. So, in order to be able to represent this, we chose a very flexible approach: we implement a the function put, that simply puts a given piece to a given square. This includes putting null to a square and makes the application quite flexible. The downside is of course that every move requires two function calls, one to clear the from-square and one to set the to-square. A typical software trade-off.
- DISCOURSE (Software Enigineering)
- An alternative approach is to implement a move function, that moves a piece from a square a to a square b. This excludes rare special moves like queening, casteling and en-passent. We also have to think of a way to setup the starting position. For testing purposes, we could do this by a test script that initially populates the database. Of course, then our version is not a runnable application. This contradicts the paradigm of ??? EXAMPLE: ??? minimal runnable product: necessary functions vs performance/ scalable functions - necess. is important to run scalable is important to sell.
put( s:Square, p:PieceType )
update Square
display :Square
select * from Board join Square
Information edit
From the above considerations we gain the Entities Board with Squares, Pieces, and a mapping of Squares and Pieces. The mapping is modelled as attaching piece types, like black knight, to squares.
- DISCOURSE (Modelling)
- An alternative modelling option is to attach squares to pieces instead, such that the entity type piece would refer to exactly one square. So, which option is better?
- Attaching pieces to squares, ??? squares have an identity, defined by their key (column, row), like a1 or f3. Whereas the identity of a Piece itself is of no interest, it's just its type that is relevant.
Data types: Board Square x:[a-h] y:[1-8] Piece [bw] [KQRBNP_] Constraints: Board is unique, completeness of the board is assured by cardinality 64 and value ranges a-h and 1-8.
Notice, that the status of our system are the possible placements of pieces on the board. Since we have among these no emphasized position (like e.g. a start position), the state machine of our system looks like in the diagram.
Behaviour edit
So far, we hav described the data flow, but no control flow. For thies version we simply assume that we completely controlled from the outside, i.e. each put and display is triggered by the UI unit. This leaves us with two use cases:
- place piece: put, display
- move piece: put, put, display
TOPIC Who shall control the flow?
