Hey all,
I’m pretty new at UML and working on the following project:
A train traveller can register himself on a website where he can enter the train he will take and his cell phone number. A dispatch at the train company registers all train departure and arrival times. If these times are delayed then they are reported. If the reported delayed trains are the same as the trains the user registered for, he will receive a message on his phone that his train is delayed.
Now the delay warning on his phone is only possible if he registered before and the delayed train reporting by the dispatch center is only possible if they keep track on all train times.
I partly understand what include (uses) and extend mean but im having trouble placing the arrowhead correctly.
Thanks for any help,
grts
Thibaut
nmbstimesys.pdf
Includes always points from the including use case to the use case which is included and extends always from the extending use case to the extended one, just as you would read it: “UC1 includes UC2” or “UC1 extends UC2”.
BTW: The arrowheads you use are meant for the generalization relationship (which doesn’t have a label attached to it). Extends and includes have “open” arrowheads. Also, the relations in a use case model are not quantified, hence there are no asterisks.
I don’t understand the arrow from “Report delayed trains” to “Send Delay Warning by SMS”, what is it supposed to mean? I see this as a possibility to have an extend relationship between the two (which would be the other way round) if there were other notification methods than by SMS (e.g. E-Mail). Then there should be an association of Train Traveller with “Report Delayed Trains”. The extension between “Send Delay Warning by SMS” and “Register on Website” isn’t quite clear to me. The requirement of the Train Traveller being registered should be stated as precondition in the use case description, the diagram is not the right place for that. What you’re saying in the diagram is that sending the delay warning is an extension of registering, i.e. a special case of registering. I would read it as if the user would always need to register when he receives a delay warning, which is probably not what you want to say. So you should delete that relationship.
The inclusion of keeping track of train times isn’t necessary either. This should only be done if the included use case is included by at least two other use cases. Otherwise there’s no benefit in seperating these use cases. Remember that use cases are mainly for communicating how the system works to customers, testers, programmers, designers, and all the other stakeholders of a project and that the real value of use cases comes from the descriptions and not from the diagram(s). The diagrams are only meant to give an overview of what actors and use cases there are and how they relate to each other. The whole dynamics is only within the descriptions!
Hi
NOTE:- Your Conventions used in diagram are not as per UML 2.0
Requirement is simple there are 2 major activities
-
“Register Train number” by [Train Traveller] with his “mobile number”
-
“Update Train Dep/Ariv Time” by [Time keeper] of all trains --: if it is delayed then—<>-- “Check train is registered” --: if it is registered then–<>— “Send SMS” at mobile number ( Train is delayed)
So we find 4 use case which are under " " and two primary actors [Train Traveller, Time Keeper] in second activity there are two level UC relationship.
Pradeep Kumar
Secure Meters Ltd.
