James Cadle Business Analysis Techniques: 72 Essential Tools for Success
Подождите немного. Документ загружается.
212
Entities are represented by boxes (‘soft’ boxes in this notation) with nouns as
names, as shown in Figure 6.10.
We need to distinguish between the entity that is shown on an ERM and
individual occurrences of that entity. For example, a garage will probably have
many technicians and will look after many cars. The ERM is a generalised
model that represents all occurrences of the entity.
Relationships between entities
Entities are related to (have connections or associations with) other entities, as
shown for example in Figure 6.11.
Figure 6.11 shows that one instance of Car can have a relationship with many
instances of Service. The ‘crow’s foot’ indicates the ‘cardinality’, or degree, of the
relationship.
As well as cardinality, we can also indicate on our model whether the relationship
is an optional one, as in Figure 6.12.
Figure 6.12 tells us that a Service must be associated with a Car but a Car does
not have to have a Service associated with it; the relationship is said to be
optional. If we think about this, it is obviously true, since a new car might not
yet have been serviced.
BUSINESS ANALYSIS TECHNIQUES
Car Service Technician
Figure 6.10 Examples of entities
Car
Service
Figure 6.11 One-to-many relationship between entities
213
If we think about the relationship between Car and Service a bit more, though,
we will realise that their relationship is actually more like a many-to-many one,
as shown in Figure 6.13.
Figure 6.13 tells us that a particular Service (say the 20,000-mile major service)
will be carried out on many Cars, whereas a particular Car will have many
instances of Service over its life. Many-to-many relationships are not permitted
on ERMs because they make it logically impossible to link a specific instance
of one entity with a specific instance of the other one. So many-to-many
relationships have to be ‘resolved’ into two one-to-many relationships through
the insertion of what is called a ‘link entity’, as shown in Figure 6.14.
DEFINE REQUIREMENTS
Car
Service
Figure 6.12 Optional relationship
Car
Service
Figure 6.13 Many-to-many relationship
Car
Car Service
Service
Figure 6.14 Resolved many-to-many relationship
214
Figure 6.14 now shows a new entity, our ‘link entity’ called Car Service. If we
read this small data model, we learn that it is possible for a Car to have many
Car Services associated with it (as the relationship at the Car end is optional),
and a Service may have been carried out on a specific car as a Car Service. The
optional relationship here is caused by the fact that a particular Service may not
yet have been performed on any car. Notice, though, that at the Car Service end
of these relationships they are mandatory; after all, a Car Service cannot be
carried out without a Car!
Figure 6.15 extends our model by considering how the entity Technician fits in.
The relationship between Technician and Service and that between Technician
and Car are also of the many-to-many type, and can be resolved through the link
entity, Car Service, that already exists.
Sometimes a situation arises where an entity can have a relationship with itself.
For example, in an HR system most employees (except the very top boss) will
have a manager and many employees (except those at the bottom of the
hierarchy) may have subordinates. Thus occurrences of the entity Employee will
have a relationship with other occurrences. This is called a recursive relationship,
and is shown in Figure 6.16.
The recursive relationship (also known, for obvious reasons, as a ‘pig’s ear’!) in
Figure 6.16 is shown as fully optional because, as we have seen, the person at the
top has no superior and the person at the bottom has no subordinates; and the
ERM must cater for all possible occurrences of the entity.
BUSINESS ANALYSIS TECHNIQUES
Car
Car Service
Service Technician
Figure 6.15 Extended data model
Employee
Figure 6.16 Recursive relationship
215
The recursive relationship shown in Figure 6.16 is of the order one-to-many, but
can many-to-many relationships also exist in this situation? The answer is ‘yes’.
Consider the situation where a component is made up of other components and is
itself part of yet another component. This can be represented by what is known as
a ‘bill of materials’ structure, shown in Figure 6.17.
Finally, some relationships are ‘exclusive’: that is, an entity can participate in one
or another but not both. Consider the situation modelled in Figure 6.18.
Figure 6.18 shows part of a library system, where a Loan can be for a Book,
a DVD or a CD but not more than one of these. The arc across these three
relationships with Loan indicates that they are mutually exclusive.
In Figure 6.18 the relationships that are mutually exclusive are handily next to
one other, which makes drawing the arc easy. Figure 6.19 shows how we would
handle the situation where an entity – in this case Borrower – is between the two
exclusive relationships but is not itself part of the exclusivity. We show partial
arcs and link them by the identifying letter ‘a’.
DEFINE REQUIREMENTS
Component
Component
Figure 6.17 Many-to-many recursive relationship
Book DVD
Loan
Borrower
CD
Figure 6.18 Exclusive relationship
216
Finally, it is customary to name the relationships on the ERM in order to explain
what they are about. An example of this is shown in Figure 6.20.
In the SSADM notation we have been using, relationships have a standard
syntax, as follows:
So, reading the relationships in Figure 6.20, we get:
Each Car may be given one or many Service(s).
Each Service must be performed on one and only one Car.
Notice that we name the relationship from both ends, to make the nature of the
association as clear as possible. Some data modellers, however, omit relationship
names where the nature of the association is obvious without them, so as to avoid
cluttering the model too much.
BUSINESS ANALYSIS TECHNIQUES
Book
aa
Borrower
CD
Loan
Figure 6.19 Separated exclusive relationship
Car
Service
given
performed on
Figure 6.20 Named relationships
Each [Entity 1] may be [link phrase] one and only one [Entity 2]
must be
one or many
217
Further notation – subtypes and super-types
One last piece of useful notation is that for subtypes and super-types, as shown in
Figure 6.21.
In Figure 6.21, Officer, Warrant Officer and Other Rank are subtypes of the
more general entity Soldier – a super-type. Most of the data items held about
all soldiers are the same – army number, name, address, date of birth and so
forth – but Officers, for example, will have additional data items such as the date
they were commissioned. As Figure 6.21 also shows, some relationships are true
of all Soldiers – that they belong to a Regiment, for example – whereas only an
Officer can belong to an Officers’ Mess (dining club), and only a Warrant Officer
can belong to a Sergeants’ Mess.
Example entity relationship model
Figure 6.22 shows a small data model that has most of the features
described here.
Readers may wish to compare this model with another model of the same business
in the description of Technique 64, ‘Class modelling’, below, to see how these two
techniques deal with what is essentially the same situation.
Supporting information
Strictly speaking, what we have been describing so far is an entity relationship
diagram. The entity relationship model consists of this diagram plus supporting
information. The supporting information gives more detail about the entities and
relationships in the model, and can include:
Entity These contain fuller details about the entities, including lists of
descriptions: the attributes – the data items – that they contain. Of particular
importance is the key – the single attribute or group of
attributes that will enable one occurrence of an entity to be
distinguished from another. Car, for instance, would probably
be identified by its registration number.
DEFINE REQUIREMENTS
Regiment
Officer
Officers’
Mess
Warrant
Officer
Other Rank
Soldier
Sergeants’
Mess
Figure 6.21 Subtypes and super-types
219
On the face of it, the situation in Figure 6.23 is straightforward. A book may have
been the subject of a loan (or it might not, since it could be newly acquired), and a
borrower might, or might not, have taken out a book on loan. If a loan exists,
though, it must ipso facto be a loan of a book to a borrower. This much could
probably be deduced from just thinking about the three entities, but, some years
ago, one of the authors attempted to join his local public library. It emerged that,
to do so, he was obliged to borrow at least one book – which, on our data model,
would mean that the relationship between Borrower and Loan would have to be
shown as fully mandatory.
However, we also have to consider the issue of time in constructing data models.
If, in our library system, we learned that the librarians want to keep Loans on file
for five years and then erase them, a fully mandatory relationship with Borrower
would mean that if someone has not borrowed a book for five years then their
entity would have to be erased also (since we have just said that we cannot have a
Borrower with no Loans attached). This might be what the librarians want: if
Borrowers have not borrowed a book for five years, they must rejoin the library.
But if it is not what they want, then we will have to restore the optional quality of
the relationship, so that we can remove a Loan without removing its associated
Borrower.
This little scenario helps to explain why data modelling is the province of a
business analyst, since what we have just explored are the business rules that
cover the capture, storage and disposal of data. Such rules cannot be deduced by
a developer sitting many kilometres away – or perhaps on the other side of the
globe, in an offshore situation – but require careful discussion and analysis with
business users.
Technique 64: Class modelling
(Before reading this section, readers are recommended to study the previous
technique, ‘entity relationship modelling’, since many of the concepts explained
there are also relevant to the understanding of class models.)
Variants/Aliases
This is also known as object class modelling.
Description of the technique
An object class model – often referred to as simply a class model – is the
UML/object-oriented version of a data model. That is, it shows the data to be
held within a system and the way the various data items are connected with each
other. The concepts involved are similar to those in entity relationship models,
but the UML notation has some additional features that enrich our understanding
of the data.
As with an entity relationship model, a class model provides a better
understanding of the data that is used within an organisation and that may
need to be stored and manipulated within a computer system, together with a
stronger grasp of the business rules that govern the creation, use and deletion
of data by the organisation.
DEFINE REQUIREMENTS
220
Objects and object classes
At the heart of an object class model are objects, and so we first need to define
these. Objects are central to the object-oriented approach to software
development, which sees systems as collections of interacting objects: in effect,
very small subsystems. Each object has data within it and is capable of
performing operations, that is to say doing something. Objects communicate by
passing messages, so that, in a drawing system for instance, a Drawing Layout
object might ask a Shape object to create a circle 5 cm in diameter. Within the
Shape object there will be an operation capable of doing just that.
In UML, therefore, we are interested in knowing what these objects are and how
they are related to each other.
In the previous technique, entity relationship modelling, we saw that the entities
have to be sufficiently generalised to cover all occurrences of the things they
represent. So a Car entity, for instance, has to be able to cater for the data for all
cars. In the same way, objects can be grouped into classes and a class stands for
all instances of the object. Thus, in UML, the data model is built at the level of
classes and is called the object class model.
Classes can be:
physical – a car, a room or a building, for example;
conceptual – a car body type, a room’s total capacity or a building’s style;
active – a car service, usage of a room or a council tax year.
Classes are represented by a three-box artefact, as illustrated in Figure 6.24.
As Figure 6.24 shows, there are three compartments to our object class icon:
Name This is the name of the class, and usually relates to some
compartment: real-world thing about which we wish to hold information.
BUSINESS ANALYSIS TECHNIQUES
Car
Name compartment
registrationNumber
dateRegistered
bodyType
numberOfSeats
engineSize
length
width
height
gearboxType
+create
+amend
+delete
Operation compartment
Attribute compartment
Figure 6.24 An object class
221
In the example in Figure 6.24 we have a one-word name; where
there are additional words, the convention is to concatenate
them together, for example ‘VehicleType’. This – we think –
rather off-putting notation is known as ‘UpperCamelCase’.
Attribute Here the principal data items or attributes to be stored about
compartment: the class are recorded, using, this time, ‘lowerCamelCase’.
More details than just the name can be recorded here. To learn
more about these, we recommend looking into one of the books
listed in the ‘Further reading’ section at the end of this
chapter, particularly that by Arlow and Neustadt.
Operation Operations are functions that are specific to a particular class.
compartment: We have just shown the name of the operation in Figure 6.24,
with the prefix ‘+’, which shows that the operation is visible to
other classes.
Having explained the three compartments of a class, in the rest of this section we
shall mainly concentrate on the class as a whole, and ignore the attribute and
operation compartments.
Associations between classes
In an entity relationship model, entities have relationships with each other; in a
class model these are called ‘associations’, and a simple one is shown in Figure 6.25.
The association line shows both the cardinality of the relationship
(its ‘many-ness’), referred to in class models as multiplicity. We also show the
extent to which the association is optional, through the numbers next to the line;
these document the maximum and minimum numbers, separated by the two
dots. We read these associations as follows:
DEFINE REQUIREMENTS
Service
Car
0..*
0..*
Figure 6.25 Association between classes