Modeling the Reality which
the System's Information is about

Advantage: Domain model = user's stable vocabulary for user's varying functional requirements => Realization of domain model = stable system foundation for varying functions «[T]he model implicitly defines a coherent set of possible system functions. In the railroad control system, we are able to specify functions which can be expressed in terms of trains, tracks, and segments; but we are not able to specify functions in terms of passengers, track gradients, or freight trains. By creating the model we have, as it were, constructed a dictionary of words to be used in functional specifications: we can then specify any function which can be specified in words appearing in that dictionary. Defining a coherent set of related functions is always hard if development starts by considering function directly. One of the difficulties is that the specification is always liable to change. [At the very least] we must always allow for changes to be made after development is completed: the large, and increasing portion of system engineering effort devoted to system maintenance is well known. Often an apparently small change to the functional specification proves to be surprisingly expensive and difficult. Part, at least, of the high cost of maintenance is due to this vulnerability of the specification.» [SysD 8] «The JSD insistence on starting development by explicitly modelling the real world ensures that the system user's view of reality is properly embodied in the specification and, eventually, in the structure of the system itself. The developed system can then be expected to allow easy enhancement for functions consisten with this view of reality.» [SysD 11f] «In building a JSD model of reality, we are concerned to establish the base on which a set of functions can be subsequently specified and built. Explicitly, we reach agreement with the system user on a view of the real world; implicitly, we are agreeing on the definition of a set of possible functions.» [SysD 12]

|
\|/

The most convincing little counter-example for resuability/maintainability I've ever encountered From [SysD 9-11]: For example, a company operates boats for hire on a pleasure lake. At an online terminal, the boatman enters the boat-nr, as a S[tart-session] event, when a boat leaves, and again, as an E[nd-session] event, when a boat returns. Functional requirement: report the number of sessions and the everage session time. For this function, it suffices in a loop to increment a session counter on each S event, and sum up the current times of all S events minus the current times of all E events. -> «This system is difficult---or even impossible---to maintain because its development was based on purely functional considerations. ... [E]ach new functional requirement will be arbitrarily difficult or easy, arbitrarily expensive or cheap.» [SysD 11] Some extensions which for the boat manager seem minor things to ask for: report length of the longest session report number/avgerage-length separately for sessions starting before and after noon warn if a session-end is missing at end-of-day (indicating that a boat was not returned) warn if the boatman enters E event without a corresponding S event before -> «Careful examination of the existing system convinces the developer that the requested enhancement cannot be made except by throwing away what has already been done and building a completely new system.» [SysD 10] «The developer ... would claim that he was very unlucky. [ there are other extensions which are much easier to add ] However, he was not unlucky: he simply produced a bad solution. The defect ... is that it fails to model the real world with which it is concerned. The real world for this system was certainly about sessions of boating: the customer buys a session of boating; [the system is to report the number and avg. length of session of boating] ... Clearly, the idea of a session is an important ingredient in the manager's view of reality: that is why he asked for functional changes which were all concerned with sessions.» [SysD 11, my red] «[T]he developer has failed to understand how the user sees the real world ... [T]he system, even when its function specification appears to satisfy the user's needs, is somehow not quite right: it embodies distortions of the reality seen by the user, and these distortions give rise to operational and maintenance difficulties. In the trivial illustration of the boating lake system, the user sees the world as one in which there are a number of sessions, each with a beginning and ending; but the developer sees it as one in which there are a number of events, each of which is either an S[tart-session] event or an E[nd-session] event. The difference is in some ways subtle; but it is enought to make the system absurdly inflexible.» [SysD 13f] «Many experienced system developers would claim, with justice, that they would not have developed the bad solution we are castigating. They would have recognized that the rearrangement of the computation of totaltime [from length-#1 + length-#2 ... to end-#1 + end-#2 + ... - start-#1 - start-#2 ...] was a dangerous optimization, and would have developed the system differently. Quite so. A good `function designer' is, in fact, applying criteria to system development which lie outside the realm of functional decomposition itself. JSD analyzes those criteria, places them in the appropriate early stage of the development procedure, and makes them fully explicit ...» [SysD 12, my red]

Domain Model = 1. Abstract description (symbolic object) + 2. Concrete model (realization of description in computer connected physically with its environment=domain)
«Making a JSD model of the real world involves two distinct tasks: --- first, making an abstract description of the real world, and --- second, making a realization, in the computer, of that abstract description.» [SysD 5].	For example, developing a system to control traffic on the a certain part of a railroad network starts with an abstract description of that railroad:
1. «An abstract description of the real world is, as we have seen [in the railroad example on pp. 5-7], a partial description: we chose to describe certain parts of reality and to omit others. In the railroad model, the developer apparently chose to describe the arrangement of the tracks in segments, the connections between segments, and the movements of trains over the segments; the curvature of the main segments, their physical construction, the varying gradient of the track, the size of each train, and an infinity of other aspects of reality have all been omitted. This kind of selectivity is inevitable in any description: the only complete description of reality is reality itself, as the Ruritanian map-makers learnt when they set out to construct a perfect one-to-one scale map of their country.» [SysD 7]	«"The railroad consists of three tracks, each divided into segments. Trains ... can move from a segment to an adjacent segment of the same track. [Additionally:] Trains moving east can move from the second segment of track A to the second segment of track B, ..."» [SysD 5] | \|/
2. «The realization in the computer is then a model of the real world in the same sense that an architectural model is a model of the real building, or a naval model is a model of the real ship, or an economic model is a model of the real economy, or a map is a model of the real terrain. The abstract description of the real world is simply a description in which relevant aspects are described and irrelevant aspects are omitted ... The realization must satisfy the abstract description closely enough for the purpose the model is to serve» [SysD 5].	«This description can be realized in an electronic model. The apparatus might consist of a number of circuits, connected to each other and to the real tracks. Pulses sent from the real tracks to the apparatus indicate the movements of trains from segment to segment. The circuits are designed so that a movement of a real train from one segment of real track to another is modelled by some suitable change in the states of the circuits.» [SysD 5f]
3. «Given a computer model which simulates the real world, we will be able to add functions for displaying the state of the real world, either continuously or on request, for producing exceptional outputs to indicate the occurence of particular conditions, and for producing outputs that can be fed back to the real world to affect its subsequent behavior.» [SysD 7]	«This electronic model has, in itself, no function. It does nothing except fulfil its role as a model, faithfully simulating the described behavior of the real world.» [SysD 6] | \|/ Possible functions to built on this model, eg.: (1) Continuous display of the state of the real world tracks. (2) Warning light if two trains are in the same segment of track. (3) Cut off power from segments of track containing two trains.

Advantage: Give unambiguous meaning to system environment=domain description (abstract model) by connecting computer system with its environment (concrete model) -> meaning by effective coupling «To make a realized working model corresponding to the abstract description requires that we establish some connection between the real world and the model. In the railroad model, the tracks and trains must be connected to the parts of the electronic apparatus which simulate their behavior, ensuring that when a real train enters a real segment of track the states of circuits corresponding to the train and track segment are correspondingly changed. The abstract description and its realization together provide the context for functional specifications. They define a set of words---train, track, segment--- to be used in specifying system functions; the meaning of each word in the real world is given by the connections between the real world and the model. Once the model has been created, we can be in no doubt about the meaning, for example of 'train'. In the model itself, a train is that part of the circuitry which realizes the description of a train; in the real world, a train is whatever is connected to that part of the model. Functions concerned with trains can then be specified unambiguously: any ambiguity must perforce have been resolved when the abstract description and its realization were made and agreed with the user of the system. By contrast, a development procedure starting with functional specifications is inevitably dealing in undefined terms. In a banking system, a function specified as 'report when a customer's account is overdrawn' relies in an obvious way on the meanings of the words 'customer', 'account', and 'overdrawns'. If these meanings have not been defined in an earlier stage of development, the functional specification is necessarily ambigusous. Of course, as this illustration shows, we may well suppose that the meanings of the terms are so clear and so well known that no explicit definition is necessary. The consequence of this supposition is often that hidden ambiguities in functional specifications remain to plague the later stages of the development. In JSD we ensure that functions can be unambiguously specified in terms of a previously created model.» [SysD 7f]