Colin J. Theaker

Methods of Analysis and Design

During the 1970s the first significant steps were made towards applying ‘engineering’ techniques, as opposed to ‘programming’ and ‘management’ techniques, to the production of large software systems. The ‘engineering’ techniques that emerged included early versions of approaches of particular relevance to the subject of this book, namely those based on graphical models presenting various views of a proposed system under development. Typically, the views that are produced early in a development are those that support analysis, while the later views identify design structures. Before such techniques came into use, system developments tended to be either programmer led, which meant that nothing existed for external appraisal until working software emerged, or they were controlled from a management level by means of voluminous textual specifications, with poor linkage between the specification and implementation.

An Object Oriented Notation for Computer System Models

We saw in Chapter 2 that the primary means for documenting and managing the development of a computer system-based product in MOOSE is through models. At the start of the development paradigm, a Behavioural Model.i.Behavioural Model; is created, which defines the required behaviour and structure of the product. After review and approval, this initial model passes through a series of phases of refinement that incrementally accumulate implementation detail. In the first of these phases sufficient detail is added to the model to make it executable, and later phases apply implementation decisions; for example, decisions concerning the use of hardware and software. The executable property of the model is used to construct experiments that support the evaluation of subsequent design decisions. Technical management throughout the product development is based on reviews, positioned at key transition points in the development process, some of which will also exercise the Executable Model. At the end of the development process, high-level language implementations of both the hardware and software for the product are synthesised from the model.

Engineering Computer Systems

To produce a complex computer system on time and within budget is a formidable task which requires a systematic and organised approach. It is unfortunate that most current approaches used for developing these systems are far from ideal. Many have been based on the separate development of the software and hardware parts of a system, although some have adapted a Software Engineering method to the engineering of the total computer system. Very few approaches are specifically designed to provide an integrated process for developing a total system.

Partitioning and Detailing a Computer System Design

This chapter describes the third major phase of the MOOSE paradigm, the purpose of which is to produce an implementation specification from an Executable Model by a process termed Transformational Codesign. The transformations are based on implementation decisions that are concerned with choosing the ‘best’ means for realising various aspects of the functional behaviour explicit in the Executable Model, in the context of the Design Constraints that are documented in the Architecture of the product. For this reason, both the Executable Model and the Architecture are inputs to the Transformational Codesign phase.

Pragmatics of Using MOOSE

In presenting the MOOSE paradigm for computer system development, we have dealt with a notation and method for producing an architecture for a computer system product, and the commitment of this architecture to a specific implementation through a process termed Transformational Codesign. Obviously the application of the paradigm through to the stage where a tested product exists requires an intimate knowledge of the implementation technologies. Coverage of this is beyond the scope of this book. In the interest of clarifying the principles of the MOOSE approach, earlier chapters have simplified or omitted a number of pragmatic aspects of producing an implementation. This chapter reviews the main areas in which some important pragmatic considerations were passed over, and it discusses the implications for the application of MOOSE to industrial strength product developments. The issues to be discussed fall into four disparate categories. These are: The use of standard system software to support the application-specific software. The physical construction and packaging of hardware. The implementation of hardware. Aspects of simulation that relate to the evaluation of the performance-critical decisions that are taken during the codesign phase.

Designing to Meet Constraints

In earlier discussions we emphasised that the developers of computer systems products must deliver systems that meet both the Functional Requirements and the Design Constraints imposed on the system, and examples of systems that failed to do so were presented in Chapter 1. So far the discussion has centred upon the development of models that focus on the Functional Requirements of a system. We will now turn our attention to the way in which Design Constraints are addressed in the MOOSE paradigm. In particular, we are concerned with identifying how and where they affect the decisions that are taken which determine how well a system’s implementation meets the imposed Design Constraints.

Creating an Executable Model of a Computer System

Computer systems have a level of internal activity that exceeds human comprehension. Modern processors are capable of executing many millions of arithmetical and logical operations per second, and special purpose hardware performs operations even faster. Clearly a static ‘paper model’ that defines the behaviour of such a system is a very inadequate representation of the system’s capabilities, features and possible failings. Only ‘hands on’ contact with a working model can begin to offer a satisfactory means for the evaluation and validation of specified behaviour. Thus the best way to evaluate a computer system model is to simulate the operation of the system that it models, and to conduct planned experiments using the simulations.

Introduction to Computer Systems

Computer systems are everywhere. One has only to walk into any shop, office, station or airport in the industrialised world to be confronted by a host of systems handling an enormous range of applications, from those concerned with information storage, retrieval and manipulation, to those in which the computer system plays a more pro-active role in work by providing intelligent support for management, design and production tasks. In addition to these easily recognised computer systems, there is an even larger class that is concealed within other products encountered in normal daily life, such as washing machines, microwave ovens, telephones, cars, trains and aircraft. Furthermore, in recent times the potential for an even larger proliferation of computer systems has arisen in the form of computer driven ‘gadgets’ that we might carry with us wherever we go. Thus, the ubiquitous nature of computer systems requires no further comment.

Developing a Computer System Architecture

Common sense and experience lead us to conclude that an architecture should be developed for a computer system before we set out to build it. However, before discussing the process of producing such an architecture, we need to clarify what constitutes an architecture and how it is to be presented. Like so many other words commonly used by computer specialists, architecture is a borrowed word and, for most of us, it has connotations that derive from personal experience, which can easily warp its meaning in our minds.

Designing with Non-Functional Requirements

A major class of software and systems engineering projects are critically dependent upon the attributes of the final system as much upon its functionality. These attributes reflect the quality of the design and implementation of the product, yet in most circumstances, they are treated in a very loose and haphazard fashion during the system development. From very poor requirements specifications, the successful implementation of a system all too often depends upon the intuitive skills of experienced designers. There are many documented examples of systems which have failed as a result.