Paul J.

Adam
Cohort 3

Assignment for Teaching Block D

Table of Contents
YOURDON ESSENTIAL MODEL 2
Environmental Model 2
Statement of Purpose 2
Notes on the Statement of Purpose 2
Context Diagram 2
Notes on the Context Diagram 2
Critique 3
Event List 3
Direct Events 3
Indirect Events 3
Temporal 3
Notes on the Event List 4
Behavioural Model 5
Data Flow Diagram 5
Notes on the Data Flow Diagram 5
Critique 6
State Transition Diagrams 7
Critique 7
Entity Relationship Diagrams 8
Critique 10
Error Handling 11
Insufficient Payment 11
Change Unavailable 11
Beverage Unavailable 11
Drinkable Water Unavailable 11
Hot Water Unavailable 12
Summary 13
Data Dictionary 14

Paul J. Adam
Cohort 3
August 2001

Page 1 of 14
 Paul J. Adam
Cohort 3

YOURDON ESSENTIAL MODEL

The Yourdon Essential Model was chosen for the analysis. First, the Environmental Model was
created in order to define the system boundaries and interfaces: then the Behavioural Model was
undertaken in order to define the system functions.

Environmental Model
Statement of Purpose
The purpose of the coffee machine is to accept payment for the customer,
dispense coffee, tea and/or chocolate (all of which have the options of added milk
and / or sugar) and return any excess money to the customer as change.

Notes on the Statement of Purpose

The Statement of Purpose is not intended to be complete or fully descriptive: that is the role of
the later elements of the Environmental Model and of the Behavioural Model.
It might be compared to the Single Statement of Need that begins the MoD "Smart Acquisition"
process: a description of the system's core functionality without excessive detail, to allow the
analysis and design of a solution.
This Statement of Purpose defines the machine's primary function, which is to dispense a family
of hot drinks in exchange for payment. More detailed analysis is left to the lower-level
modelling.

Context Diagram
The context diagram for the coffee machine is shown at Figure 1.

POWER WATER
SUPPLY SUPPLY

ELECTRICITY DRINKABLE WATER

BEVERAGE COFFEE PAYMENT

CUSTOMER MACHINE CUSTOMER
ORDER CHANGE
DIAGNOSTIC
RESUPPLY
REPAIR &

DATA

MAINTENANCE

Figure 1 - Context Diagram

Page 2 of 14
 Paul J. Adam
Cohort 3
Notes on the Context Diagram
Data dictionary items are, where appropriate, identified by bold, all-capitals text: e.g.
CUSTOMER.
The CUSTOMER Box
Originally the CUSTOMER box would have been a single terminator. However, the
CUSTOMER has two distinct, related interactions with the coffee machine. Selecting and
receiving a BEVERAGE, and making PAYMENT and receiving CHANGE, are two distinct
operations.
While the choice of beverage may influence price, this is not fixed (the machine may charge
different prices for different drinks, or operate a flat fee per cup).
Paying for the drink chosen should logically precede its provision, but unless all items are priced
the same then CHANGE cannot be given until the drink has been chosen. Also, change may not
be given immediately, since the option to make a large payment and purchase more than one
drink should be considered.
Thus, the CUSTOMER element was split into two in order to show these two interactions more
clearly and to avoid constraining the implementation.

Critique
The Context Diagram is sometimes described as a "level 0 data flow diagram". It provides a
useful purpose in formalising the boundaries of the system and defining what is internal to the
system, what lies outside the boundary, and what interfaces cross into and out of the system.
In this instance, it was relatively easy to prepare the Context Diagram and define the interfaces
and terminators, but doing so first (this was the first element of the model created) provided a
solid basis on which to work.

Event List
The Event List consists of three types of event: Direct events (driven by discrete control inputs),
Indirect events (requiring analysis and processing), and Temporal events (driven by a clock or
schedule).

Direct Events
D1 CUSTOMER selects BEVERAGE
D2 CUSTOMER tenders PAYMENT
D3 COFFEE MACHINE dispenses BEVERAGE
D4 COFFEE MACHINE dispenses CHANGE

Indirect Events
I1 PAYMENT exceeds PRICE
I2 (PAYMENT - PRICE) exceeds CHANGE AVAILABLE
I3 BEVERAGE not available
I4 DRINKABLE WATER not available
I5 HOT WATER not available

Temporal
T1 MAINTENANCE inspects and resupplies COFFEE MACHINE

Page 3 of 14
 Paul J. Adam
Cohort 3
Notes on the Event List
The Event List initially appeared reasonably simple. However, some areas seem uncertain. For
instance, should "supply of water" be an element in the Event List?
If the machine is connected to the mains water supply, then there is no discrete event of "water
arrives": but at first sight this rules out the design possibility of a standalone machine having a
water reservoir rather than a mains supply.
However, in that implementation then water would join the consumable items replenished by
MAINTENANCE, and therefore omitting the supply of water in the Event List would not
constrain or limit the implementation.
This list grew as the behavioural model was constructed in more detail, and more significant
events affecting system behaviour were identified. (For instance, loss of water supply was one of
the first events identified, with inadequate HOT WATER being added during construction of
the Data Flow Diagram and the definition of that term)

Page 4 of 14
 Paul J. Adam
Cohort 3

Behavioural Model
The first element of the Behavioural Model created, was the Data Flow Diagram (DFD)

Data Flow Diagram

The top-level Data Flow Diagram for the hot drink vending machine is shown at Figure 2.
Drinkable Water
Beverage
Hot
BOIL Water DISPENSE
WATER BEVERAGE
Beverage
Dispensed
Water Available
BEVERAGE Refill Beverages
Authorise AVAILABILITY
Select Beverage
Refill Change
BEVERAGE
REQUESTED
CONTROL Change to Dispense
COFFEE CHANGE
MACHINE AVAILABLE

Beverage Unavailable
Water Unavailable Deduct Cost
Change Unavailable Dispense Change
PAYMENT
Insufficient Payment Deduct Dispensed
Change

Tender Payment Collect Money

Figure 2 - Level 1 Data Flow Diagram (terminators not shown)

Notes on the Data Flow Diagram

The DFD was created first, in order to rationalise and expand upon the Context Diagram and
pick up elements of the Event List.
The required functions of the COFFEE MACHINE are to accept customer selections of a
beverage, accept payment, dispense the beverage and issue change. Maintenance activities are
required to support that action.
Beverage Availability
The datastore BEVERAGE AVAILABILITY represents the availability or otherwise of the
various components.
This representation is implementation-free. The machine may produce beverages by measuring
out a quantity of tea/coffee/chocolate and adding milk or sugar from reservoirs, or it may use
three magazines of cups which are pre-filled with tea/coffee/chocolate and are filled as needed
with hot water to which milk and/or sugar is added as needed, or any of many other combination
of methods. All that is required, at this level, is that the machine is aware of whether it is able to
dispense a requested beverage.

Page 5 of 14
 Paul J. Adam
Cohort 3
Change Available
This datastore represents the availability of change with which to refund any excess of
PAYMENT after a beverage has been dispensed and its cost deducted from PAYMENT.
During the evolution of the DFD, this evolved considerably, with (for instance) the need for
DISPENSED CHANGE to also be deducted from PAYMENT.
Authorise
This control dataflow is used to keep all "intelligence" inside the CONTROL COFFEE
MACHINE function. It is generated from a simple logical function that requires PAYMENT ≥
PRICE AND BEVERAGE REQUESTED  BEVERAGE AVAILABLE AND WATER
AVAILABLE = TRUE in order to be TRUE.

Water Available
Authorise

BEVERAGE
REQUESTED
AUTHORISE

BEVERAGE Sufficient Deduct Price

AVAILABILITY Payment
PAYMENT

Figure 3 - Level 2 Data Flow Diagram for "Authorise" signal (terminators not shown)

Critique
The Data Flow Diagram was difficult to initially prepare and took some time to evolve into its
final form. However, the effort produced a useful clarification of the COFFEE MACHINE
system.
The first pass was little more than a restatement of the Context Diagram, where the function of
CONTROL COFFEE MACHINE handled almost all functions. This evolved into something
close to the form seen in Figure 2 where, still without excessive detail, a clearer understanding of
how the system would operate was derived.
It continued to require revision, for instance when error handling was being considered and the
issue of water supply had to be addressed: the issue of how the water was raised to the required
temperature was not clear and the DFD had to be revised to reflect that.
Breaking the diagram down to a further level of detail, as done to define the generation of the
AUTHORISE signal, provided more clarity. For instance, the creation of the AUTHORISE
signal not only triggers the provision of a beverage, but must also deducts the cost of the
dispensed BEVERAGE from the PAYMENT datastore.

Page 6 of 14
 Paul J. Adam
Cohort 3

State Transition Diagrams

The State Transition Diagram was considered as a modelling tool for this system. However,
attempting to create it was not entirely successful. The State Transition Diagram for the
acceptance of payment is shown in Figure 4.

IDLE

Timeout reset BEVERAGE selected

Display PRICE

WAITING FOR
PAYMENT

PAYMENT tendered

Display PAYMENT

DISPENSING
BEVERAGE

PAYMENT tendered

Display PAYMENT

DISPENSING
CHANGE

Figure 4 - Partial State Transition Diagram

This indicates the perceived problem: the State Transition Diagram, at this level, does not handle
the checks of beverage availability, of adequate payment, or of the availability of sufficient
change.

Critique
I had difficulty in defining the hot drinks vending machine as a state-based machine, since it is
event-driven and has many finite actions and decision points rather than defined states. The State
Transition Diagram does not appear to be the best tool for analysing this particular system.
Requiring that "BEVERAGE selected", "PAYMENT inserted" and "CHANGE dispensed"
must be valid, without including the necessary checks to do so, is an assumption that weakens
the model by hiding this necessary processing in an assumed detail.
It also makes it difficult to model the alternative states that might follow "BEVERAGE
selected" if that beverage proved to be unavailable: attempting to do so produces a flowchart,
rather than a State Transition Diagram

Page 7 of 14
 Paul J. Adam
Cohort 3

Entity Relationship Diagrams

The Entity Relationship Diagram was considered to be useful in formalising the relationships
existing within "CONTROL COFFEE MACHINE". Figure 5 defines the relationship governing
whether a BEVERAGE can be dispensed. (Interestingly, it is extremely similar to Figure 3 -
either suggesting I've got the methods wrong, or that they converge on a logical solution)

WATER
AVAILABLE

CUSTOMER Requests BEVERAGE

BEVERAGE
AVAILABILITY PAYMENT

Figure 5 - Entity Relationship Diagram for Beverage Request

For a beverage to be dispensed, four conditions must be met. The customer must have entered a
request, the customer must have tendered sufficient payment, the beverage required must be
available and there must be water available with which to make it.
Figure 6 shows the relationship diagram for dispensing change:

PAYMENT Compare CHANGE

CHANGE
AVAILABILE

Figure 6 - Entity Relationship Diagram for Dispensing Change

When change is dispensed, the remaining balance held in the machine is compared to the
CHANGE AVAILABLE and the appropriate sum dispensed.

DRINKABLE Heats and HOT WATER

WATER measures

Figure 7 - Entity Relationship Diagram for "HEAT WATER"

Page 8 of 14
 Paul J. Adam
Cohort 3

BEVERAGE

COFFEE TEA CHOCOLATE

Figure 8 - Entity Relationship Diagram for BEVERAGE

COFFEE

COFFEE, BLACK, COFFEE, BLACK, COFFEE, WHITE, COFFEE, WHITE,

NO SUGAR SUGAR NO SUGAR SUGAR

Figure 9 - Lower level Entity Relationship Diagram for BEVERAGE

The Entity Relationship Diagram in Figure 8 defines the breakdown of BEVERAGE into the
type (tea, coffee, chocolate). Figure 9 shows the breakdown from one type to its subtypes (with
or without milk and sugar) and could be duplicated for the other two types of beverage.
CHANGE
AVAILABLE

1p COIN 2p COIN 5p COIN 10p COIN 20p COIN 50p COIN £1 COIN £2 COIN

Figure 10 - Entity Relationship Diagram for CHANGE AVAILABLE

Page 9 of 14
 Paul J. Adam
Cohort 3
Figure 10 shows the data subtypes for CHANGE AVAILABLE. Not all of these may be used in
practice (if, for instance, the machine does not accept £2 coins or any notes) but defining all the
coins that might be expected to make up CHANGE AVAILABLE allows them to be removed
later if the implementation requires.

Critique
The Entity Relationship Diagram was not intuitive to use, probably due to unfamiliarity. I had a
distinct tendency to create flowcharts to analyse the logic of events, rather than create a proper
ERD. It did, though, allow clearer definition of the system's functions and of data elements.

Page 10 of 14
 Paul J. Adam
Cohort 3

Error Handling
The Event List identified, and the Data Flow Diagram and to a lesser extent the Entity
Relationship Diagrams confirmed, the error conditions (also identified as Indirect Events IE1-5),
as follows:
I1 PAYMENT exceeds PRICE (the lack of this constitutes an error)
I2 (PAYMENT - PRICE) exceeds CHANGE AVAILABLE
I3 BEVERAGE not available
I4 DRINKABLE WATER not available
I5 HOT WATER not available
The definitions of, and methods by which the system would address, those errors are given as
follows.

Insufficient Payment
This condition exists when insufficient payment has been tendered, to meet the price of the
chosen item. It is handled by refusing to dispense the required beverage until additional payment
is inserted, sufficient to equal or exceed the cost of the selected beverage.

Change Unavailable
This condition exists when insufficient CHANGE AVAILABLE exists to refund the remaining,
unused PAYMENT.
It presents one of the more interesting problems in designing the system, since until CHANGE
AVAILABLE is compared to the outstanding PAYMENT it may not be known whether the
machine will be able to dispense CHANGE.
One approach, often used in practice, might be to assess CHANGE AVAILABLE against the
highest single token of PAYMENT accepted by the machine. Thus, if the machine accepts £1
coins, then a displayed "Exact Money Only" light could be illuminated once the CHANGE
AVAILABLE was insufficient to refund (£1-PRICE). This would on some occasions lead to
incorrect warning and lost sales, but might be preferred to the frustration of a customer inserting
a large-value coin and failing to receive adequate change.

Beverage Unavailable
This condition exists when a given BEVERAGE cannot be dispensed due to a lack of one or
more elements (e.g. if "coffee with sugar but not milk" was demanded, then "Beverage
Unavailable" would exist if either coffee or sugar were not available.
Reporting this error condition is an interface and implementation issue. The machine might
allow user input of the BEVERAGE desired and either display PRICE or an "unavailable"
warning; or it might have twelve buttons (one for each BEVERAGE) with separate
"unavailable" warnings for each; there are a wide variety of means by which this error state can
be communicated.
By contrast, handling the error is simple: if the BEVERAGE is not available, then it will not be
dispensed.

Drinkable Water Unavailable

This condition exists when the supply of DRINKABLE WATER fails or is exhausted. It is
handled by shutting down the BOIL WATER function and reported by indicating the machine
is out of service (typically by exterior warning light).

Hot Water Unavailable

Page 11 of 14
 Paul J. Adam
Cohort 3
This condition exists when there is no HOT WATER available. Depending on the
implementation, this may be a transient condition (e.g. the machine is heating water to working
temperature) or permanent (e.g. the heating element has malfunctioned).
While HOT WATER is unavailable, BEVERAGE cannot be dispensed. Reporting of this
condition will depend on interface and implementation.

Page 12 of 14
 Paul J. Adam
Cohort 3

Summary
In general, Yourdon analysis felt like an effective means of analysing the system's functions and
modelling it. It compelled a logical and structured analysis of the system's functions and purpose,
and required a consistent approach to be taken throughout.
 The Environmental Model was effective in defining the system's boundaries and
interfaces, allowing a solid point of reference for future analysis.
 The most valuable type of Behavioural Model was found to be the Data Flow Diagram
since it modelled the operations that the system would have to perform.
 The State Transition Diagram did not appear to be an effective tool in building a model
for this system.
 Entity Relationship Diagrams supported and complemented the Data Flow Diagrams in
breaking down the system's functions and defining what it needed to do in response to the
various inputs and data states.
An advantage of the model was that it was fairly easy to keep it implementation-free. While it
suggested many possible methods of providing a solution, it was possible to remain at a
functional level that defined what had to be done, without defining how it was to be done. This
does, however, limit some details of error reporting and handling: some interface designs would
allow BEVERAGE AVAILABILITY to be displayed, others might not display that data until
the customer had made a selection.
One significant difficulty experienced was keeping the various elements of the model
synchronised. During construction or amendment of one model, care had to be taken to ensure
that the other models were adjusted accordingly, and updating the Data Dictionary in response to
changes and evolution of the model proved to be a very time-consuming task.
A minor problem was the lack of a good package to handle diagram construction. The drawing
tools in Microsoft Word™ were usable, but not ideal: this added to the difficulty in harmonising
models after amendments. (This is really only a drawing issue.)

Overall, the Yourdon model was felt to provide an effective tool for analysing the functions of
the coffee machine.
Some parts of it were not effective for this application, but the strength of the Yourdon method
appears to be its flexibility: with the option of using some or all of Data Flow, State Transition
and Entity Relationship to create a behavioural model, it should be possible to model most types
of system.
The one significant weakness was that some functions could not be fully defined without
constraining the implementation.

Page 13 of 14
 Paul J. Adam
Cohort 3

Data Dictionary
AUTHORISE A command signal sent to the "Dispense Beverage" function from "Control Coffee
Machine". Required conditions are that BEVERAGE REQUESTED must be capable
of being serviced from BEVERAGE AVAILABILITY; WATER AVAILABLE must be
true: and PAYMENT must exceed PRICE.
BEVERAGE The drink requested by the customer: it consists of tea, coffee or chocolate, with the
options of being served plain, with milk, with sugar, or with milk AND sugar (twelve
states possible). It has an associated PRICE.
BEVERAGE AVAILABLE The status of the machine's consumable items for each of the twelve available
BEVERAGEs
BEVERAGE REQUESTED The customer input, which specifies the BEVERAGE demanded.
BOIL WATER The process of turning DRINKABLE WATER into HOT WATER
COFFEE MACHINE The BEVERAGE vending machine: the system under evaluation.
CHANGE AVAILABLE The quantity of CHANGE available for dispensing to the CUSTOMER. This covers
both the cash sum stored in the machine, and the denominations available.
CHANGE TO DISPENSE The balance of the customer's payment (after deducting the PRICE of the
BEVERAGEs which have been dispensed)
CUSTOMER The person requesting a BEVERAGE from the machine and tendering PAYMENT in
exchange.
DIAGNOSTIC DATA Information on the COFFEE MACHINE's operational status, e.g. remaining quantities
of consumable items, levels of change, functional status et cetera.
DISPENSED CHANGE The balance of the customer's payment (after deducting the PRICE of the
BEVERAGEs which have been dispensed) which can be returned from the CHANGE
AVAILABLE
DRINKABLE WATER Potable water which is boiled and used to make the beverages
ELECTRICITY Mains electricity supply. Single phase alternating current, at a voltage of 230V -10%
+6%, at a frequency of 50Hz.
HOT WATER This consists of DRINKABLE WATER that has been raised to the temperature
needed and in the quantity required to make the BEVERAGE.
MAINTENANCE The person, group or department responsible for
ORDER The CUSTOMER's selection of BEVERAGE
PAYMENT The money tendered by the CUSTOMER in exchange for the BEVERAGE. May
exceed the price of the BEVERAGE.
POWER SUPPLY The supply which provides ELECTRICITY to the system/
PRICE The cost of the BEVERAGE. May be constant for all types of BEVERAGE, or there
may be different values assigned to different types of BEVERAGE.
REFILL BEVERAGES A MAINTENANCE activity, consisting of resupplying the tea, coffee, chocolate, sugar
and milk. It may or may not also include refilling the water supply, depending on the
system implememtation.
REPAIR & RESUPPLY Routine maintenance (e.g. cleaning), resupply of consumables, removal of
accumulated money and recharging of the CHANGE dispensing system,
WATER SUPPLY The supply which provides DRINKING WATER to the system/

Page 14 of 14