I really like activity diagrams whereas I find it hard to warm up to state diagrams, but I will try.. :) I would suggest considering a state 'Bike Assessed' which then could give rise to ' Bike Repaired' - leading back to 'Available for HIre' - or another state ' Bike Junked' which would result in a stop state.
I like state diagrams - they provide a cross check on activity sequences and enable logic to be assessed (since the object only changes state when processes make it do so)
Try to avoid arrows crossing as they are potentially confusing. Also I feel that a bike is stolen when on hire (unless the bike shed is raided)so the arrow for that end state should come fro the on hire box. The end state arrow for a junked bike may be better originating in the repair box as the reparer would assess it - wht do you think?
I really like activity diagrams whereas I find it hard to warm up to state diagrams, but I will try.. :)
ReplyDeleteI would suggest considering a state 'Bike Assessed' which then could give rise to ' Bike Repaired' - leading back to 'Available for HIre' - or another state ' Bike Junked' which would result in a stop state.
I agree with Al, state diagrams are not much fun.
ReplyDeleteYou could consider using some things you have used as processes between states as states themselves "stolen" and "damaged" could also be states.
I like state diagrams - they provide a cross check on activity sequences and enable logic to be assessed (since the object only changes state when processes make it do so)
ReplyDeleteTry to avoid arrows crossing as they are potentially confusing. Also I feel that a bike is stolen when on hire (unless the bike shed is raided)so the arrow for that end state should come fro the on hire box. The end state arrow for a junked bike may be better originating in the repair box as the reparer would assess it - wht do you think?
ReplyDelete