Information Analysis:Information system modeling

8.1 Introduction

In this chapter we introduce the traditional methods for the analysis of information system requirements. There are many methods for expressing requirements. We will use the Unified Modeling Language (UML), which is an established and widely used method for system development. Using the UML notation we can express IS requirements in a formal way, providing a platform for software system designs and software construction.

8.1.1 The theatre booking system

Imagine that the Barchester Playhouse decides to start up an Internet ticketing facility in conjunction with a software house, Nimbus Information Systems. The plan is to make the theatre booking system an Internet application available to the two other theatres in Barchester, both of which rely currently on in-person and telephone ticket bookings. Once the system is operational it would be a relatively small step to make the service available to theatres in any part of the country. And why stop there? With appropriate user interfaces and a ticketless system, as introduced by budget airlines in Europe, the theatre booking system could provide a booking service for theatres in any country.

This would be a radical departure for the Barchester Playhouse, raising issues concerning the identity of the theatre and its core competencies – if the online ticketing service is a success it is possible that its revenues and profitability will exceed those from staging theatrical productions. In this imagining the Barchester Playhouse is transformed – the core business of the Playhouse would be better seen as ticketing operations with the staging of theatrical productions as a separate, but possibly complementary activity. In such a scenario, the Playhouse could discontinue the staging of productions and still be viable – i.e., capable of a separate existence – as an online ticket sales operation.

This scenario is the 'American Airlines story', whose CEO was reported as saying that he would sell the airline before selling the flight reservation system, SABRE. The SABRE flight reservation system, which takes bookings for many different carriers, was indeed spun off at a later date as a separate business. This is perhaps the most likely scenario for a successful online ticketing service, since there are likely to be low synergies between staging theatrical productions and operating an online ticketing service.

The competencies of the Playhouse are in selecting, promoting, and staging theatrical productions, not in the development of online ticketing systems, although these may be competencies of the software house, Nimbus. The strategy for the Playhouse ticketing system would have been decided as part of the organizational analysis (chapters 4, 5, 6). For the purposes of information analysis we will tackle the establishment of a ticket booking system from the perspective of the software house, Nimbus, who are interested in co-developing the theatre booking system with Barchester Playhouse with the intention of making it sufficiently general so that it can be offered as a service to other theatres. The booking system will be a multi-theatre Internet ticketing system that takes payment for ticket sales by credit card. Assuming that an Internet connection is available operators in the box office could also use it for processing in-person ticket sales. If the application were extended to cater for cash and cheque payments it could indeed become the single source of all ticket reservations and ticket sales.

8.2 Information system modeling

In response to the question 'why do we model?' Booch et al. (1999) propose a fundamental reason: so that we can better understand the system we are developing. Booch et al. argue that:

• Models help us visualize a system as it is or as we want it to be

• Models allow us to specify the structure or behaviour of a system

• Models provide a template to guide us when constructing a system

• Models document the decisions we have made.

The choice of what to model and how to represent the situation using a modeling notation are not neutral decisions. A model is indeed a simplification of a complex reality, but models do not merely reflect reality (as is) – they are also implicated in the construction of new realities (to be). If we choose to model work practices using only box and line diagrams then our model is unlikely to be able to show, for example, personal, political, and cultural aspects of the work situation. The analyst should be ever aware that a complex reality is best approached using a range of modeling approaches that capture and help shape different aspects of the problem situation. Over-reliance on any one modeling approach is likely to lead to blind spots in the developer's view of the domain.

When producing information models that will guide us in the development of software artefacts it is common to focus on structure and behaviour. A structural model describes the types of thing that will be represented in software and for which data must be held. For example, in the case of a motor vehicle some of these types might be wheels, engine, and gearbox. The structural model will also describe relationships between the types of thing; a motor vehicle typically has four wheels and an engine. Behaviour describes what the system does, often in response to some external stimuli. A motor vehicle can, for example, turn, accelerate, and go forwards and backwards. Depressing the accelerator pedal will cause the engine to turn more quickly – a behaviour. Structural and behavioural models provide a template to guide the developer in specifying, designing, and constructing software artefacts. The models also act as documentation, helping to record both decisions and the rationale for the decisions at each stage of a development project.

8.2.1 Analysis and design

Analysis is often presented as 'what the application will do' and design as 'how it will be achieved'. In analysis we are trying to understand and represent the problem situation, or domain – we are not concerned at this stage with the technologies that will be used to achieve a software implementation.

Structured systems analysis and design

Structured systems analysis and design came out of the structured programming methods of the 1970s and reached its zenith in the United Kingdom with SSADM (structured systems analysis and design method) in the early 1990s. In the US popular structured methods included the Yourdon method and James Martin's Information Engineering. A common theme in structured methods is to view the system from three perspectives: data, process, and dynamics. The principal models used in systems analysis are the entity relationship diagram (data), the data flow diagram (process) and the entity life history (dynamics). However, the separation of data and behaviour meant that a lot of effort had to be expended in keeping the models synchronized; it also made reuse of software objects difficult. In the 1980s object-oriented programming using languages such as Eifel and Smalltalk gained in popularity, largely because of claims of faster development times, reuse, and extensibility. In the 1990s the principles of object-oriented programming were migrated up-stream and adopted in systems analysis.

Object-oriented analysis and design

Many benefits have been claimed for an object-oriented approach to systems development, including reusability, reliability, scalability, faster development, easier maintenance, greater extensibility, a closer correspondence with the real world, and a more effective way of handling complexity. One of the attractive features of an object-oriented approach is that the same paradigm can be used throughout analysis, design, and construction. This means that the same diagramming notations can be used at each level and refined as the models become more physical, finally evolving into an executable specification from which software can be generated.