Tuesday, 16 December 2008

GoGreen Bikes - sequence diagram for 'Issue Bike' (new customer)

While constructing the sequence diagram, I was forced to think carefully about how the classes communicate with each other. This led reconsideration of the methods of my classes, so I revised my class diagram accordingly.



Posted by at

4 comments:

Anusha said...

Hai Al your Sequence diagram is good.In the diaram there is BikeList and Bike, i thing BikeList is a part of Bike so why dont you go for only Bike.

23 December 2008 at 15:03
Al said...

It's the other way round - Bike is part of BikeList.

A class is supposed to be "A tight coupling or association of data structures with the methods or functions that act on the data". I needed methods that would need access to attributes of all the bikes e.g. a method which searched all the bikes and returned all those of a particular type, so it seemed more logical to me to have a class whose attribute represented ALL the bikes.

24 December 2008 at 10:30
Anonymous said...

Exactly how the method should expose the need to revise aspects of system design when you investigate different views of relationships and interaction!

I read your sequence diagram as the receptionist changing customer details every time that there is a hire - surely dealing with customer details should be a separate sequence?

30 December 2008 at 10:37
Al said...

This sequence diagram is for new customers only - I specified this in brackets in the title - and for new customers, details would always have to be recorded.

I didn't have dealing with customer details as a separate sequence because I didn't think it 'stood on its own' as a piece of functionality that could crop up in other use cases...what do you all think?

3 January 2009 at 16:50

Post a Comment

Subscribe to: Post Comments (Atom)