• A group of interrelated and interdependent objects or units
  
• A group of devices or an organisation that serves a common purpose
  
• An organised or established procedure
  
• A manner of classifying, symbolising or formalising

In the context of "systems development", we are interested only in the first two: whenever we talk about a system from now on, you may assume that we are talking about a group of interrelated objects or units, organised in some way so that they (appear to) serve a common purpose.

We all appear to have some intuitive understanding of what constitutes a system, since we are happy to assume we share a meaning for phrases like the following ...

digestive system hi-fi system central heating system ecosystem

On the other hand, we would not, generally, refer to a screwdriver, or a pin, as a system.

We often make a decision (conscious or unconscious) about whether to view something as a system, depending on why we are viewing it at all ...

• Mr Jones, a patient on the operating table, is viewed as a complex biological system by the surgeon, Mr Smythe-Pratt.
  
• When, a year later, Mr Jones breaks into a house and steals the silver, the house owner, Mrs Ogmore-Pritchard, does not see him as a "complex biological system".

So, the choice of whether to view some chunk of reality as a system depends not only on whether it has systemic properties, but also on whether we are interested in those properties. But what are these "systemic properties"? What makes a system "a system"? What is a system?

If we refer to something as "a system" it’s because we perceive it to have certain properties. Here are some of these properties:

• A system is composed of parts that interact.

These interacting parts may themselves have systemic properties, in which case they may be viewed as subsystems of the wider system, which can themselves be decomposed into parts. Where our interest stops depends on our purpose. (In considering a hi-fi system we would not normally be interested in the quantum-mechanical systemic properties of each transistor.)

• A system manifests some externally observable behaviour.

This behaviour often involves interaction with the system's environment. If it is an artificial system, produced by humans, (such as a central heating or data processing system) this behaviour will be purposeful - directed towards a particular set of results. Natural systems often fulfil some particular function or purpose in a larger system

• A system has a boundary.

This must be the case, as otherwise we wouldn’t be able to identify the system as a separate object. It’s the boundary which defines the extent of a system: there are many choices we can make about where to place a system boundary with each different boundary defining a different system.

Inside the boundary are all the things and activities we perceive as part of the system; outside is the system environment (the system’s surroundings). The system will affect / influence / be affected by / be influenced by the objects in its environment.

A helpful way of determining a sensible conceptual boundary for a system is to include within the boundary all activities, objects, resources, etc., over which the system has complete control, and include in the environment of the system all activities, objects, resources, etc., which influence the system, or which the system influences, but which are not entirely under its control. Of course, the whole of the rest of the universe is the environment of any system, but we only want to consider objects in the environment that are of significance to the system we’re interested in.

We can all think of systems in our everyday lives which can be conceived of in terms of the properties above: the national telephone network, the postal system, a motor car, the students’ union, an air-conditioning system, or even a humble gas cooker. All of these are examples of systems.

What is a model?

A "model" is the representation of some abstraction from some "part of reality". A model can exist in a person’s head only, invisible to everyone else, or it can also exist external to the modeller, for example as a diagram on paper, or a piece of text or mathematics.

• The standard map of the London Underground is a model.
  
• It represents a certain abstraction from the real underground system.

Things included in the abstraction:

Lines (Piccadilly, Victoria, etc.),

Connections (Where you can change from the Northern Line to the Central Line, etc.),

The order of stations on each line.

Things left out of the abstraction:

The distances between stations,

The orientation of stations at ground level,

The depth of the underground tunnels.

The kind of model which a person requires of a system depends upon the relationship between the person and the system. For instance, the user of a gas cooker is interested in how to cook food: turn the gas rings and oven on and off, set the oven timer, and so on; the service engineer is interested in how to fix the cooker when it goes wrong; the manufacturer is interested in how to put it together; whilst the delivery van driver is only interested in how best to get it on and off the van! Each of these people will require a different model of the system, even though several of these models may have aspects in common.

When we think about systems we tend to sweep much of the detail of their operation under the carpet and concentrate on those general properties which we need to know about in order to use or to understand them. This is a technique which most of us employ automatically, and yet this process of abstraction underlies all modelling techniques.

In the case of our gas cooker, a simple schematic diagram and a set of instructions including statements like

" When you turn one of the gas taps (marked A,B,C,D on the diagram) anti-clockwise, the relevant burner will be lit automatically "

is usually thought to suffice as a model for the user. The service engineer, on the other hand, needs detailed information (possibly in the form of an engineering drawing) about the various components of a gas cooker, how they fit together, and how they interact with each other. Thus, the user requires a much more abstract model of how the system works than does the service engineer. The men getting the cooker on and off their lorry need only a model of its approximate dimensions and weight, and perhaps an instruction "This way up!" They are, in fact, not interested in the systemic properties of the cooker at all.

Comment This is about the invariant or permanent properties of the data which the system must store in order to support the other views. It is really about the structure of this data: how a typical item is composed from simpler data, and how it is related to other data.

It is often thought of as modelling the ‘things’ inherent in the problem. Modern (e.g. object-oriented) methods emphasise this view as the fundamental one.

Typical Questions

What 'things' is the problem about?

What are the entities (types or classes) in the problem?

What attributes or properties do these have (what are they "made up of")?

What (structural) relationships are there between these (client-supplier, association, aggregation, sub/supertype)?

What data do we need to store in order to meet the requirements?

Notations & Techniques
Data Dictionary, ER Model, Z data schema, Object (class) Model, Object-Z, etc.

Examples of static properties (taken from the Door Security System)

this system is about rooms, doors, cards and employees, etc.…

information about an employee consists of name, personnel number, address, etc.…..

cards are issued to employees

doors connect rooms

an employee can have at most one card issued at any time

the length of an employee's name must not exceed 32 characters

Comment This is about the way that the system responds to events (stimuli) in its environment. An event is atomic or instantaneous (at this level of abstraction) - it either happens or doesn’t happen. An event may cause the system to change state, so that it will now recognise and respond to a different set of stimuli. Events may be asynchronous (occur at any time) or synchronous (temporal - at fixed times, see (d) below).

The interaction between human users and the system (the user interface) is an important special case of dynamic behaviour.

We may divide models of dynamic behaviour into two further sub-categories:

• models of external or apparent behaviour. (interface or boundary models)

Here we are modelling the interface between the system and the people, devices and so on with which it interacts (its environment). In such models we are concerned only with what happens at the boundary. For example, what does a user of a word processor have to do to save a file and what externally observable behaviour does the system show in response to her doing it?

• models of internal behaviour.

Here we look inside: when some event occurs to which the system must respond, how is the response generated? For example, what steps does a word-processor go through when you select "Save" from the "File menu"? It checks whether there is space on the disk, checks whether you have changed the document since you last selected "Save" ... and so on.

Typical Questions

What happens outside the system which the system must know about, and to which it must respond?

What states can the system be in, and what causes it to change state?

How does a system respond to an event, and how is this response generated?

Notations and Techniques
Finite State Machines (STDs), Statecharts, Process Algebras (CCS, CSP), Object Interaction Diagrams, Context Diagrams (level 0 DFD), Regular Expressions, Entity Life Histories, etc.

Examples of events (taken from the Door Security System)

Comment . This is about the processing or data transformation which the system performs, what outputs it produces and how these are generated from its inputs and the stored data. This view is usually closest to the customers’ view of the requirements, and used to dominate most development methods, with a top-down decomposition by function driving the whole process.

What does the system do?

What calculations does it have to perform?

How does it transform its input data into its output data?

Notations and Techniques
Use Cases, Data Flow Diagrams, Process Descriptions, Z Operation Schemas.

Examples of functions (taken from the Door Security System)

Comment This is about the effect of time on the system, and is the least well catered for in most methods. It is not well integrated with the other views, although it is closely related to (b), but adding time constraints to responses. These could be relative (e.g. ‘within 5 milliseconds’) or absolute (e.g. ‘at the end of the month’).

What is an acceptable response time for event E?

Are there any significant dates, times, deadlines?

Are any of the system's operation cyclical or synchronised?

Notations and Techniques
Timing Diagrams, Timed Process Algebras (Timed CSP), Interval Logics.

Examples of temporal behaviour (taken from the Door Security System)

As noted above, development methods used to be 'function-oriented' or 'process-oriented'; the basic questions asked during development were along the lines of "what do you want the system to do?", as in view (c) above. This was then used as the top of a hierarchical decomposition, in which this main function was decomposed into a sequence of sub-functions, etc., typically using Data Flow Diagrams.

The functionality provided by a system is obviously very important, but there are (at least) two reasons why it is not a good basis for the design of a system:

• most systems these days don't have a single, top-level function, or even an easily identified group of functions. Instead they provide a group of closely-related services, each of which might involve numerous functions. Again, consider a word processor; this provides a whole range of document-processing services, most of which can be invoked at any time
  .
• users are never satisfied with functionality, and always want more (or those responsible for marketing want to add more to justify a new release!), so any design based on functionality is going to need a lot of rework.

In addition, changes at a high-level in the hierarchy will cause major rework lower down - a problem with any ‘top-down’ method: you have to commit to major decisions early on.

The standard view these days is that view (a) is the best basis for the design of a system. The static properties represent those aspects of the problem which are least likely to change over time, and are therefore a more stable basis for design:

Door security systems will always be about cards, employees, rooms, doors, card issues, access permissions, and so on.

Word processors will always be about documents, fonts, headers, margins, printer characteristics, etc.

Whatever changes to functionality are requested, we should be able to provide these on the basis of a sound model of the structure and relationship of the data in the problem. In a way it is obvious that we cannot model behaviour (from any of the views (b) to (d)) without first considering what this behaviour works on… the system data.

So in the description of modelling techniques which follows, we will spend a lot of time on three techniques for modelling view (a):

Data Dictionary

Entity Relation Diagrams

Object (Class) Models (in UML - the Unified Modeling Language)

before we look at models of behaviour.