RSS Feed for the unit Models and modelling

Introduction

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

Models are mechanisms for communication. This unit looks at what a model is and what the process of modelling is about. The techniques discussed here are applicable to a wide range of systems and have one thing in common: they are all commonly used diagramming techniques. The five techniques are: data flow diagrams, use case modelling, activity diagrams, entity–relationship diagrams and state machines.

This unit is an adapted extract from the Open University course Software requirements for business systems (M883).

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

Learning outcomes

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

Having studied this unit you should be able to:

explain why modelling plays a key role in eliciting requirements;
identify the different kinds of model used in eliciting requirements;
explain the need for modelling languages;
interpret a data flow diagram describing a simple process;
interpret a use case diagram describing a system's response to a business event;
interpret an activity diagram describing the activities that make up a business system;
interpret an entity–relationship diagram that describes the data involved in a business process;
interpret a state machine diagram that describes how a system responds to a sequence of events.

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

1.1 Types of model

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

When the word model is used, you are most likely to bring to mind physical models such as those that are constructed to depict new buildings, cars or other artefacts. Such models are a precursor to actually building the artefact ‘for real’. However, our use of the word goes beyond physical models. For example, when a new house is built there will be a variety of plans produced to show different aspects of the house: its floor plan, a diagram of its location, a drawing of the front elevation and so on. These are also models because they show different aspects of the house (just as a physical model would do). Some of these plans are useful to prospective purchasers, some are useful to the builders, while others are required by local authorities. The point is, each model is useful to different people and helps to communicate the ideas of the developers to prospective builders, buyers and authorities, all of whom have different needs in relation to the house. Models are mechanisms for communication. But each model shows only a small amount of the totality of information about the artefact; too much information in a model makes it difficult to comprehend.

In this unit, we shall describe a number of different modelling techniques. But they all have one thing in common: they are all diagramming techniques that are commonly used in describing ‘systems’ such as business processes, manufacturing processes and software development. In such a system, particularly when it is large, a major activity is the determination of the requirements for the system (what it should do), a role undertaken by a requirements analyst who uses diagramming modelling techniques to specify the system.

The reason that you need to look at a variety of diagramming techniques is that each one provides a different view of a system and a complete understanding of a system cannot be obtained without a number of different views. This does not mean that every diagramming technique that we shall describe is required to describe every system. Rather, the techniques that are appropriate to a given system will depend upon the type of system and what you want the description for.

There are many diagramming techniques in existence and we cannot cover them all in this unit. Therefore, we shall concentrate on five of the most commonly used techniques. Our selection is sufficiently varied to provide you with a good overview of the different kinds of views that one needs for different kinds of system.

We shall begin our discussion by looking more deeply at what a model is and what the process of modelling is about. We shall take a brief diversion to discuss modelling languages to see why it is necessary to rigorously define a modelling technique. We then move on to the five diagramming techniques:

Data flow diagrams
Use case modelling
Activity diagrams
Entity–relationship diagrams
State machines

The material in this unit has been extracted from the Open University Masters-level course M883, Software Requirements for Business Systems. While that course is primarily about software development, the modelling techniques discussed in this unit are applicable to a wide range of systems. Indeed, the main purpose of a model is to act as a mechanism for describing the requirements of an artefact (of any kind, including software).

Further reading

Occasionally, you will see reference to ‘MRP’. This is a shorthand for the book, Mastering the Requirements Process by Suzanne Robertson and James Robertson published by Addison Wesley, 1999, which is the set book for the course M883. It is not required in order to understand the materials in this unit, but can be referred to if you want to learn more about an individual topic.

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

2.1 What is modelling?

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

Modelling is about building representations of things in the ‘real world’ and allowing ideas to be investigated; it is central to all activities in the process for building or creating an artefact of some form or other. In effect, a model is a way of expressing a particular view of an identifiable system of some kind. Models are:

a means of understanding the problems involved in building something;
an aid to communication between those involved in the project, especially between the requirements analyst (a development role) and the user, as part of some deliverable;
a component of the methods used in development activities such as the analysis of the requirements for an artefact and the design of the artefact.

A model is an abstraction, which allows people to concentrate on the essentials of a (complex) problem by keeping out non-essential details. Since there is a limit to how much a person can understand at any one time, we build models to help in activities such as the development of large software systems. For example, developers build different models throughout the development process in order to verify that the eventual software system will meet the requirements.

Models are, in one respect, idealisations in the sense that they are less complicated than reality; they are simplifications of reality. The benefit arises from the fact that only the properties of the world relevant to the job in hand are represented. For example, a road map is a model of a particular part of the earth's surface. We do not show things like vegetation or birds' nests as they are not relevant to the map's purpose. We use a road map to plan our journeys from one place to another and so the map should only contain those aspects of the real world that serve the purpose of planning journeys.

A model and the real world are alike in some ways, but different in others. For example, road maps are helpful because they represent the distance between, and relative positions of, a set of places and the routes between them. They use the relevant properties of the real thing with just a change in scale; one centimetre on the road map, for instance, may be equivalent to one kilometre on the ground. A map may be unhelpful if it shows only major roads.

Quite often, a property of the real world may be represented by a different kind of property in a model. In the case of the road map, different colours are normally used to represent different classes or types of road. Such a road map should have a key or legend so that those who read the map can understand what the different coloured lines are intended to represent. In effect, an analogy is being used to exploit the similarity between two different properties: one in the real world and one in the model.

Models of a problem situation are only an approximate representation of that situation. The real world situation will have a complexity that tends to reduce your chances of achieving an exact representation. So, you need to find some way of achieving an acceptable balance between accuracy and manageability. As a project unfolds, there will be a number of practical considerations that result in some compromise. It is for this reason that several different models are built, each one representing different aspects (views) of the real world.

If a model is so complex that its author (or other team members) cannot use it, then that model is of little or no value. However, simplification is only of value if all simplifying assumptions, and their consequences, are made explicit. At some point in a project, any of these assumptions may need to be justified.

Models are subject to change. At the very least they require some form of testing so that a model can maintain its correspondence with reality. As towns and cities expand and contract, a road map must be changed to reflect the new situation. In the worst case, a change in scope necessitates a whole new model. For example, if there was a need to reflect the current status of roads and the traffic on them, a simple road map is inadequate since we would want to show, amongst other things, the changes in traffic density over time.

Unfortunately, not all models of a particular type share the same notation, often because they originate from different sources. For example, different publishers will have different ways of constructing and presenting road maps.

When developing a product, a variety of models are likely to be constructed. It is unrealistic to expect to put everything into just one model. Too much detail in a model can only be a distraction. It would be hard to use such a model as an aid to communication.

Each model is used to illustrate a different point of view. For example, there are two different kinds of views that modellers often distinguish:

static models, which describe a set of elements and any relationships that exist between them;
dynamic models, which describe the behaviour of one or more elements over time.

There is a useful discussion in Michael Jackson's Software Requirements and Specifications (1995, p. 120) where he defines what he means by a model by distinguishing between a model and reality in relation to developing software. To Jackson, a model refers to the machine (what the software does when it executes on a computer), which embodies a simulation of the real thing; it is a description of a domain (that part of reality that you are interested in). A model and the domain are different so he draws attention to the difference between a description that is true in both the machine and the domain, a description that is true only of the domain, and another description that is true only of the machine. It is important to be clear whether you are talking about reality, the machine, or both.

Further reading: Michael Jackson, Software Requirements and Specification, Addison-Wesley, 1995, ISBN 0-201-87712-0

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

3.1 Making consistent models

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

It would be preferable to have a consistent way of representing the different models that one might want to construct. The notion of a modelling language allows the developer to make useful connections between different models. For the most part, models are represented diagrammatically. There are two aspects of a diagram-based modelling language that you should be aware of:

a set of rules that defines what symbols can be used on a particular type of diagram and what can be constructed with these symbols – its syntax;
one that determines what the diagrams and symbols mean – its semantics.

It is important to recognise that you construct models to express your understanding of a particular situation in the expectation that the model will help you pass on that understanding to others. On any given project there are decisions to be made about every model. You should favour a modelling language that is:

sufficiently expressive, so that you can be confident that your particular ‘take’ on a situation can be represented;
easy enough to use, but in such a way that its notation allows you to express what you want to say (there will necessarily be some limitations on this because models are a simplification of reality);
unambiguous, so that the number of possible interpretations of your model are minimised (ideally, that number should be one);
supported by suitable tools, so that you can apply your modelling skills and not be constrained by your drawing skills;
widely used, so that you can move to other problem situations without having to learn a new modelling language every time. If you leave one project team and join another that uses the same modelling language, you need only learn about the new problem situation. This advantage is amplified if you have also moved to a different company at the same time! Naturally, the team that you join will expect you to be more productive than if you had to learn a whole new modelling language.

Using an accepted language increases the chance that a component developed for one product, such as a software application or some electrical device, can become a component in another product. For example, suppose you were trying to decide which electric motor to include in a new vacuum cleaner. Clearly, you would begin by reading all the descriptions. The chances of choosing an appropriate electric motor are increased if you can understand the descriptions of its specification to be confident that it will meet your requirements.

For example, the development of software applications according to object-oriented principles is commonplace. The Unified Modelling Language (UML) has emerged to become an industry standard. Its success is partially due to its separation from any particular method for developing software. UML is available for anyone to include in his or her own method. Although a detailed history and description of UML is beyond the scope of this unit, it is useful to know that it was derived from three of the most popular methods that were used in early projects that adopted object-oriented principles in software development. UML is intended to be a general purpose language for software development – it is not meant to be a complete language for modelling all aspects of all systems.

The UML is only one of many modelling languages that have been developed and which are in common use. They provide different viewpoints on the decomposition of problems. As a requirements analyst, you would need to explore other modelling notations, languages and techniques. For example, different types of model you might find useful are:

a model to identify the key stakeholders and their relationships to one another;
a model that shows how the intended product fits into its working environment (known as a context model);
a model which shows the parts of the product that come about because of a particular requirement (that is, one that shows the relationships between an agreed set of requirements and the eventual product, and enables you to trace the links between the requirements and the product – such a model is an essential component of working on projects).

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

4.1 What is a data flow diagram?

The Open University — Fri, 15 Jul 2011 10:12:07 GMT

A data flow diagram (DFD) is a graphical description of the ebb and flow of data in a given context. A DFD allows you to identify the transformations that take place on data as it moves from input to output in the system. (DFDs pre-date UML diagrams, but still have a complementary role to play in describing systems.)

The Case Study below provides an example of a DFD used to describe the Open University's eTMA system (electronic Tutor Marked Assignment system). It uses the notation described in Table 1 below.

Case study: An electronic tutor-marked assignment (eTMA) system

As you may already know, the Open University (OU) operates what we call the eTMA system – a system that, among other things, enables students to submit their assignments electronically. The eTMA system came about through pressure, in the mid-1990s, from both students and the University. Students had begun to use word processors to prepare their assignments and they wanted to submit them electronically rather than print out the assignments and submit them using the postal system. At the same time, the University wanted to extend its reach to non-UK residents in countries where the postal system was less reliable and less efficient than that in the UK. Both sets of goals could be satisfied by an electronic system. At much the same time, demand for an electronic system was also coming from a small number of course teams in different academic units (the Faculty of Mathematics and Computing, the Faculty of Technology and the Business School). Although there was only a small number of courses involved, these were among the largest courses in the University (one of the Technology courses had 12,000 students on its first presentation!).

Prior to the development of the eTMA system, the University's assignment handling system was entirely paper-based with assignments written (often by hand) on paper and posted to tutors. Paper-based TMAs were accompanied by a multipart control form (known as a PT3 form), the naming of which was lost in the sands of time, but we do know that PT stood for ‘part time’ and 3 indicated the third in a sequence of forms dealing with different aspects of assignment handling. The tutors mark the paper-based assignments, fill in the PT3 forms and send the amended documents to the University by post.

The University operates a large Assignment Handling Office headed by the Head of Assignment Handling who is responsible for ensuring that all University policies and functions relating to assignments are carried out appropriately. Among other things, assignment handling clerks (a) enter the marks into the student records database, (b) copy some assignments for monitoring (quality assurance) purposes, and (c) send the marked paper-based assignments back to the student using the postal service.

The paper-based system runs in parallel with the eTMA system as there are still courses for which the eTMA system is not suitable for the types of assessment materials involved, and it acts as a back-up system should the eTMA system be unavailable. However, the University wants more courses to use the eTMA system because it provides a better service to students, gives more management information and is potentially less expensive.

The eTMA system

The eTMA system allows students to submit their answers to tutor-marked assignments (TMAs) electronically, as computer files, to the University via a website. Whenever a TMA file is submitted, it is stored in a central database and a ‘receipt’ (a simple message containing a unique number) is sent to the student to acknowledge that the TMA has been received. Tutors (Associate Lecturers) are informed, by email, that a TMA is waiting for them to be marked.

The system enables tutors to download their students' submissions, mark and comment on the assignments ‘on-screen’ and submit the marked TMAs back to the University. A marked TMA is stored in a database and the student is informed, by email, that their TMA has been marked and is available to be retrieved electronically.

When the tutor downloads an unmarked TMA, she also receives an electronic version of the PT3 form on which the marks awarded for each question and the overall comments on the TMA must be entered. The completed PT3 form accompanies the TMA when it is sent to the OU database, and eventually both of them are sent electronically to the student.

The data flow diagram given in Figure 1 summarises the basic system.

View larger image

Figure 1 The basic electronic tutor-marked assignment system

Item	Representation	Meaning
External entity	A rectangle	A producer or consumer of information that is outside the process being modelled.
Process or activity	A circle	A transformer of information that is within the scope of the system being modelled.
Data (flow)	A line with an arrowhead that indicates the direction of data flow	The input to, or output from, a given process, which is associated with each arrow in a DFD.
Data store	Two parallel lines with the name of the data store between them	A repository of data for use by one or more processes.

Diagramming Technique	Section
Use case modelling	Use Cases and Activity Diagrams
Activity diagrams	Use Cases and Activity Diagrams
Entity–relationship diagrams	Entity–relationship data modelling
State machines	An Introduction to State Machines

Identifier and name	UC_1 Make reservation.
Initiator	Receptionist or Guest.
Goal	Reserve a room at a hotel for a guest.
Pre-condition	None (that is, there are no conditions to be satisfied prior to carrying out this use case).
Post-condition	A room of the desired type will have been reserved for the guest for the requested period and the room will be occupied for that period.
Assumptions	A guest can make a reservation via the Internet. The guest is not already known to the hotel's software system (see main success scenario, step 5).

Main success scenario
1	The guest requests a reservation.
2	The guest selects the desired hotel, dates and type of room.
3	The hotel receptionist provides the availability and price for the request (an offer is made).
4	The guest agrees to proceed with the offer.
5	The guest provides identification and contact details for the hotel's records.
6	The guest provides payment details.
7	The hotel receptionist creates a reservation and gives it an identifier.
8	The hotel receptionist reveals the identifier to the guest.
9	The hotel receptionist creates a confirmation of the reservation and sends it to the guest.

Main success scenario
1	The reserver requests a reservation on behalf of a potential guest.
2	The reserver selects the desired hotel, dates and type of room.
3	The receptionist provides the availability and price for the request. (An offer is made.)
4	The reserver agrees to proceed with the offer.
5	The reserver provides identification and contact details for the hotel's records.
6	The reserver provides payment details.
7	The receptionist creates a reservation and gives it an identifier.
8	The receptionist reveals the identifier to the reserver.
9	The receptionist creates a confirmation of the reservation and sends it to the guest identified by the reserver.

Extensions
3	A room matching the request is not available.
3.1	The receptionist offers alternative dates and types of room.
3.2	The guest selects from the alternatives.
5	The guest is already on record.
5.1	Resume at step 6.

Identifier and name	UC_2 Check in guest.
Initiator	Receptionist.
Goal	A guest takes up a reservation and occupies a room at the desired hotel.
Pre-condition	There is a reservation for the guest and there is, at least, one room available (of the desired type) and the guest can pay for the room.
Post-condition	The guest will have been allocated to a room for the period identified in the reservation and a bill will have been opened for the duration of the stay.
Assumptions	The guest is already known to the hotel's software system. The hotel is confident that the guest can pay. For example, the guest has a valid credit card.

Main success scenario
1	The guest provides a reservation reference number to the receptionist.
2	The receptionist uses the reference number to find the reservation.
3	The receptionist states the details of the room type and the duration of the stay recorded in the reservation.
4	The guest confirms the details of the room type and the duration of the stay.
5	The receptionist allocates a room to the guest.
6	The receptionist opens a bill for the guest. (It could be that there is a separate billing application, which must be notified upon check in.)
7	The receptionist issues a key to the guest.

Studentid	Name	Registered	Region
S01	Akeroyd	Yes	England
S02	Thompson	No	Scotland
S05	Ellis	No	Nl
S07	Gillies	Yes	Scotland
S09	Reeves	Yes	England
S10	Urbach	Yes	Wales

RSS Feed for the unit Models and modelling

Introduction

Learning outcomes

1.1 Types of model

2.1 What is modelling?

3.1 Making consistent models

4.1 What is a data flow diagram?

Table 1 DFD notation

5.1 More information about modelling techniques

6.1 Use case modelling

6.2 Actors

6.3 Describing use cases

6.4 Scenarios

Table 2 Textual description of a use case in the hotel domain

6.5 More about actors

6.6 Modelling the relationships between use cases

6.7 Stereotypes

6.8 Sharing behaviour between use cases

6.9 Alternatives to the main success scenario

Table 3 Extending the description of a use case in the hotel domain

6.10 To extend or include?

6.11 Issues with use cases

6.12 Self-assessment questions

SAQ 1 Actors

Answer

SAQ 2 describing use cases

Answer

SAQ 3 Scenarios

Answer

SAQ 4 To extend or include?

Answer

6.13 Exercises

Exercise 1

Table 2 Textual description of a use case in the hotel domain

Answer

Table 4 Textual description of a use case in the hotel domain

Exercise 2

Answer

Exercise 3

Answer

Exercise 4

Answer

7.1 Activity diagrams

7.2 Exercises

Exercise 5

Answer

Exercise 6

Answer

8.1 Introduction

8.2 Example of a university registration data model

8.3 Entities

Table 5 Some entities of the entity type Student

8.3 Relationships

Exercise 7

Answer

9.1 What is a state machine?

Next steps

References

Acknowledgements

Unit Image

Don't miss out