We are halfway through the book, and we now begin to analyse the system behav tour. In terms of project time scales this is not unusual IT projects are business projects, and the construction of a system is only part of the overall project. It is vital that the groundwork is done well in advance of defining the system The effect of premature analysis and design can be a great deal of rework later on, or worse the production of a system that is inappropriate.
Of course, if the development is a relatively minor extension to an existing system in an established business, much of what we have gone through is overkill However, that does not remove from the development team the responsibility of understanding the environment into which their system or subsystem is to be deployed
Now we move on to the detailed elaboration of the requirements into computer specific specifications of behaviour. This is the first point at which any notion of an object is essential. This stage focuses on the domain, and the necessary logical elements to support the domain. This will be a long and very detailed chapter. extending the notion of an object and introducing object interaction.
The inputs and outputs of systems analysis are shown in Figure 12.1. Use case descriptions and prototypes are the primary input, though the systems analyst may well refer to any of the previously provided documentation.Sequence diagrams use scenarios derived from the primary/alternative/exception paths in the use case descriptions to determine sensible networks of objects to implement Metalwho the behaviour. These objects are recorded in class diagrams. Complicated classes have state models to further define their behaviour.
We will look a little at different types of object, and define a process for working through the use case descriptions to produce the key systems analysis outputs.