Re: [UML Forum] Help with school project with UML diagram

[H. S. Lahman]

Responding to Z...

It's refreshing that you actually did some work. Alas, many students come on the forum and just ask us to solve the problem for them.

I need to present a new railway information system. the system enables the customers to order a ticket and to do a check-in with extra payment.

at first release, the customers can do it only by phone, second release- by website, last release - by smartphone app.

Is the attached diagram is good enought?

It is pretty close; I mostly just have a couple of quibbles...

You have two Order A Ticket uses cases. Presumably they do the same thing, so you only need one. Just have the Call and Web versions link to the same one.

Check In, Pay Extra, and Pay for Ticket are a little different because of Dispatcher vs. System. However, unless there is some sort of very different and important logic within those uses cases for those scenarios, you usually do not need to worry about that. (If there is such logic, they need different names because they are not the same use case.) Typically there will be some sort of context identity for the scenario and the use case would simply have a conditional step to send a message to the correct actor.

The general rule of thumb is that if the use cases have different steps, they are not the same and require different names. OTOH, if they have exactly the same steps (including conditional steps), then they are the same and you only need one of them in the diagram. [Caveat: in a very large use case, this could lead to arrows cluttering things up badly. In that case, one can make the case that if the have the same name they are the same and can appear in different places for aesthetic reasons. However, everyone needs to be on that page. In this case, I don't know what is in those use cases, so I don't know whether they are same. I think you want to avoid that kind of confusion in the audience when documenting the diagram.]

I don't think you need dependency qualifiers here. Ordering a ticket or checking in is always done in the scenario. All you are doing is separating it out as logically distinct. (I am biased because the methodology I use does not use dependency relationships at all because they are really only relevant to OOP, not OOA/D where one uses UML.)

Similarly, I don't think you need the include qualifiers here. The rule of thumb I use is that I will use <<include>> only if the invocation of that use case is conditional. The problem I have with <<include>> is that one can argue any chain of use cases that are not directly invoked by an actor are included behavior in some use case that is invoked by an actor, so all the relationships should be includes. I think one need some unambiguous criteria for drawing a line in the sand for whether a use case is "in" another use case or not.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

[david reye]

Hi Itay Z,

Can I suggest some points to consider.

1. I only see one Actor here - the Customer - and three systems -  Release1, Release2 and Release3.  Dispatcher and System are not actors - they are the systems (or part thereof in the case of Dispatcher) that are the subject of the use cases. The system (the use case "subject") is already represented by the box around the set of use cases. You have these for Release 1, 2, 3.

2. Your primary use cases are "Call Train's Reservation Dispatch", "Visit Train's WebSite" and "Enter Train's App". Do these represent anything of value to the Customer? No - they are just the entry points. I think your primary use cases are "Order a Ticket" and "Check In", which are refined in each iteration of the system. (Expressing user goals is a conventional use of Use Cases, not something mandated by UML).

3. Include/Extend relationships between use cases in different systems is worrisome. I think it is unlikely to be correct. See if you can work around it. If a use case changes between releases (in its behaviour or by including a new use case or an extension point), then it is a new use case. Define a new use case - with the same name is okay if it's a different system - and use «refine» to show that they are related.

Cheers,

David

On 28/04/2013, at 12:24 AM, Itay Z wrote:

I need to present a new railway information system. the system enables the customers to order a ticket and to do a check-in with extra payment.

at first release, the customers can do it only by phone, second release- by website, last release - by smartphone app.

Is the attached diagram is good enought?

thanks

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
<UseCase Diagram.jpg>

David Reye

Software Systems Consultant

email: david...@codeworks.com.au

mobile: +61 404 471451

[H. S. Lahman]

Responding to reye...

>
> 1. I only see one Actor here - the Customer - and three systems -
> Release1, Release2 and Release3. Dispatcher and System are not
> actors - they are the systems (or part thereof in the case of
> Dispatcher) that are the subject of the use cases. The system (the use
> case "subject") is already represented by the box around the set of
> use cases. You have these for Release 1, 2, 3.

I agree that a case can be made for ReleaseN actors. However, I think
that depends on the problem space. One can envision Release 1 being
nothing but some I/O tools for a manual system where the grunt work is
done by a human dispatcher, while Releases 2 and 3 are actual software
to automate the process.

> 2. Your primary use cases are "Call Train's Reservation Dispatch",
> "Visit Train's WebSite" and "Enter Train's App". Do these represent
> anything of value to the Customer? No - they are just the entry
> points. I think your primary use cases are "Order a Ticket" and "Check
> In", which are refined in each iteration of the system. (Expressing
> user goals is a conventional use of Use Cases, not something mandated
> by UML).

This is a good point that I should have thought of in my response.

[H. S. Lahman]

Responding to Z...

Do you think this diagram is better? I added more things that I need to present. my intention is to do one diagram of each release.  can this diagram do the job for Release 1?

I still agree with Reye that Call Reservation Dispatch sounds like an entry point rather than a use case. Does it have any functionaltiy at all? What kind of steps would be in it? For example, if it represents a phone number the customer must call and making a connection, those steps would justify a use case. But if all it means is that "release 1 begins here", then it is not.

Making multiple diagrams is fine. In this case that could add clarity and focus on essential problem space concerns (releases). However, it can also result in confusion if a use case, like Order a Ticket, appears in multiple diagrams. Is it the same use case or does it have different requirements? Either way, everyone viewing the diagram should be clear about it via some associated documentation, development standard, etc..