- grey indicates possible classes
- red indicates unsuitable classes
GoGreen bikes
bicycle hire company
system
reception desk - irrelevant
type of bike - attribute of bike
woman's ten speed racer in blue - value of bikeType
mechanics
bike
store room - irrelevant
receptionist
bike number - attribute of bike
details - too vague
computer system
hire charge - attribute of bike
deposit charge - attribute of bike
cost of hire – attribute of hire transaction
customer
name - attribute of customer
address - attribute of customer
telephone number - attribute of customer
hire transaction
start date - attribute of hire transaction
estimated number of days - attribute of hire transaction
details - too vague
bike number - duplicate
customer - duplicate
system - too vague
receipt
clerk
account
amount charged - attribute of account
amount paid - attribute of account
job - irrelevant
records - too vague
date of return - attribute of hire transaction
return
extra charge - attribute of hire transaction
mechanic
damage - attribute of state of bike
system
deposit - duplicate
past hire transactions
state of bike - attribute of bike
specialist bikes
tandems - value of bikeType
penny farthings - value of bikeType
2 comments:
I love how you've used color here.
I would suggest considering bike as a parent class and the type of bike, penny farthing, etc, as a child class that derives attributes from the class 'bike'.
Thanks for the feedback!
I did consider having subclasses of Bike, but as I wouldn't be storing further attributes and I don't think I need further or different methods for different type of bikes I didn't think it would be worth it.
I suppose it depends on exactly what information we want to store about the specialist bikes...
Post a Comment