CIS224 Software Projects: Software Engineering and Research Methods
Workshop 2 (Thursday 12 October 2006) - Example answer
Each question is worth 5 marks.
1. Each actor in a use case analysis is either a user of the system in a particular role or something external to the
system that interacts with the system. For example, an actor might be another information system or a hardware
device like a scanner. Identify who or what the actors are in the “Purchase items in supermarket” use case.
Definite: Customer, Cashier, CardIssuerSystem (5/3 each)
Possible: Scanner, WeighingScales, Till, Printer, Card payment device (depends if define actor to be only
autonomous external systems. These are not autonomous - they are merely input devices used by the cashier.)
(5/6 each up to a maximum of 5)
2. Use the “noun identification technique” to identify a list of candidate classes for the supermarket till system.
((number of correct nouns – number of incorrect nouns) * 5 / 42)
bag containing fruit or vegetables
opportunity to use other method of payment
bar code
payment
BOGOF offer
payment notification
card account
PIN
card issuer system
price for the bag [of fruit or vegetables]
card refusal message
purchase
cash
receipt
cashier
request for customer to enter PIN
cheque
request for amount to be deducted from customer’s
card account
cheque guarantee card
scanner
conveyer belt
screen
credit card
set of similar items
customer
weighing scales
debit card
store's bank account
ENTER button
system
fruit
till
item
total amount
kind of fruit or vegetable
transaction
list of available fruit and vegetables
vegetable
method of payment
weight
number of customer's cheque guarantee card
number of items within a set of similar items
3. Obtain an initial class list for the supermarket till system by removing from your list those candidate classes
that should not be represented in the system. Briefly explain why each candidate class that you remove should
not be in the system.
Initial class list
cashier
item1
customer
set of similar items1
kind of fruit or vegetable*
store's bank account
1
transaction
till
scanner2
weighing scales2
Items removed from candidate class list:
bag containing fruit or vegetables - Special case of set of similar items (redundant).
bar code - attribute of an item or set of similar items.
BOGOF offer - Probably just stored as an attribute in an item and used to calculate price of set of similar items.
card account - this might be a class in the card issuer system, but probably not in the till system.
card issuer system - Outside the scope of the system. However, possibly represented by a wrapper class within
the system.
card refusal message - this is a signal or message not a class
cash, cheque, debit card, credit card - these are forms of payment so they are probably all possible values of an
attribute called "payment type" in an object representing a transaction.
cheque guarantee card – outside scope of system
conveyer belt - Outside the scope of the system and irrelevant to it. It is a manually operated device that does not
interact directly with our system.
ENTER button - part of the user interface devices, therefore too low-level to be of concern here.
list of available fruit and vegetables - Just a collection of fruit-or-veg objects.
method of payment – attribute of a transaction.
number of customer's cheque guarantee card - attribute of transaction or card account.
number of items within a set of similar items - Attribute of set of similar items.
opportunity to use other method of payment - An event: just an aspect of the process of payment.
payment - Vague - what does this mean exactly?
payment notification - a message or signal sent by the card issuer system.
PIN - Depends if PIN sent to card issuer via system or separately. System probably doesn't need to represent the
PIN of the customer.
price for the bag [of fruit or vegetables] - Attribute of a bag of fruit or vegetables.
purchase - Same as transaction (redundant).
receipt - printed document generated by a printReceipt() operation on Transaction object.
request for amount to be deducted from customer’s card account – event or signal, not a class.
request for customer to enter PIN - Event or signal, not a class.
screen - Normal element of user hardware, don't need to design system on such a low level.
system - Outside the scope of the system(!)
total amount - attribute of another class - possibly a transaction.
weight - attribute of set of similar fruit or vegetables
* Fruit and vegetables seem to be treated identically therefore they can probably be represented by the same
class.
1
- Not clear that we need both set of similar items and item. Could just have "set of similar items" class and
allow the multiplicity to be 1 to represent a single item.
2
- Possibly represented by wrapper objects within the system.
2
Marking method for this question: 5 * x/n where x is number of correctly kept or discarded classes and n is the
number classes correctly identified in question 2.
4. Draw a class diagram that shows how the classes in your initial class list are associated with each other. Label
each association and add multiplicities where appropriate.
There are various different possible solutions to this question. See question 5.
5. Can the class diagram that you have just drawn be simplified by allowing some of your classes to inherit from
other classes? If so, will you need to define new classes that are superclasses of the classes in your initial class
list? Draw a new class diagram that includes representations of the generalization relationships that exist
between the classes in your new design.
One possible answer might be as follows. Note that a complete design is not expected, so many details can be
missing. The important thing is that what you put makes sense.
Cashier
Customer
WeighingScales
+ getName()
+ getID()
+ getTransactions()
+ getTransactions()
+ getLoyaltyCardAcct()
+ getName()
1
+ getWeight()
1
0..1
1..*
Transaction
Scanner
ItemSet
Transaction
1
+ getBarCode()
0..*
1..*
0..* + getItemSets()
1
+ printReceipt()
+ getTotalAmount()
+ addItemSet()
+ getPaymentType()
+ setPaymentType()
+ getCreditCardPayment()
1..*
+ getItem()
+ getQuantity()
+ getCost()
0..*
0..*
1
1
StoreBankAccount
Item
+ creditPayment(totalAmount)
+ getID()
+ getDescription()
+ getUnitPrice()
+ isOnOffer()
BarCodedItem
FruitOrVeg
+ getBarCode()
+ setBarCode()
6. Suppose that you are about to start the first iteration of a spiral development process to develop a supermarket
till system. You need to specify the functionality that you will provide in the system that your team will deliver
at the end of the first iteration. Will you attempt to provide all the functionality required by the “Purchase items
in supermarket” use case at the end of the first iteration? If not, what subset of this functionality will you aim to
deliver at the end of the first iteration?
3
It would not be advisable to attempt to provide all the functionality at the end of the first iteration. The goal of
the first iteration should be to produce an initial prototype to show to the customer in order to ensure that the
developers and customers have a similar idea of what is required. For example, the system delivered at the end
of the first iteration should perhaps only provide the ability to pay with cash or cheque and maybe only be able
to deal with bar-coded items. It would thus not have to interact with the weighing scales. Also, the first system
should probably not include functionality for dealing with a customer loyalty card. The first version of the
system would probably also not be able to deal with special offers such as "buy-one-get-one-free".
7. Sketch a use case diagram for the system that you will aim to deliver at the end of the first iteration.
Again, there are many possible correct answers. Something like the following would be sufficient.
Scan item
Add item set to
purchase
Cashier
Calculate total amount
to be paid
Customer
Receive payment
Print receipt
4
8. Sketch a class diagram for the system that you will aim to deliver at the end of the first iteration.
Again, many possible correct answers. Something like the following would be sufficient.
Item
BarCodedItem
+ getID()
+ getDescription()
+ getUnitPrice()
+ getBarCode()
+ setBarCode()
1
0..*
Scanner
Transaction
1
+ getBarCode()
ItemSet
0..*
Transaction
+ getItemSets()
+ printReceipt()
+ getTotalAmount()
+ addItemSet()
1
1..*
+ getItem()
+ getQuantity()
+ getCost()
1..*
1
Till
+ getTillBalance()
+ creditCashCheque()
9. Do you think the “Purchase items in supermarket” use case description could be improved? Have any
important steps been left out? Does it contain irrelevant details? Does it contain errors?
Many possible answers. Credit given for anything sensible.
5