Use Case Diagrams - Are arrows absolutely necessary?

https://stackoverflow.com/questions/455373

19-08-2019
|

Question

Is it absolutely necessary to use "arrows" to show association between an actor and a use case in a use case diagram?

I recently had to draw one for my Software Engineering assignment. But after doing a bit of research online on many articles, papers, online books and lecture notes from numerous other universities, it seemed that majority of use case diagrams regardless of how much potential they have to show some kind of "flow" or "navigability", have no arrows, while some examples have arrows.

So I consulted my friend who is a final year student and has already studied what I have told me I shouldn't have arrows between my actor and use case and even his Requirements Engineering lecturer taught students not to use arrows. So I made a conscious decision not to use arrows and used solid lines instead to show my use case associations.

Here is my diagram- click

However, when I received the marks for my assignment, I was astonished to find out that I was given a zero for not using arrows. Even if it was mandatory to use them, there is an abundance of evidence that a solid line can be used for bi-directional association. So shouldn't I receive at least some marks for it?

Obviously I asked for an explanation from my lecturer who I will see next week to discuss this point, but if she tells me I should have used arrows, what argument can I make against it? I would be grateful if someone can kindly give me good advice with appropriate references to some professional sources.

Thank you very much for reading and I hope to read your response soon.

EDIT

Thank you guys. I really appreciate the answers you have given me. This whole confusion started because the only notation the lecturer provided was a single,very simple example of library use case diagram in one of the lecture notes, which had arrows. But it was not made very clear that it was the definitive notation. Another reason I didn't think it was mandatory is because when it came to explaining notations for drawing a data-flow diagram, she made it abundantly clear to using her specific notations, but it is not that uncommon for DFD's to have different notations in different sources, whereas I could find very little evidence to make the use of arrows in use-case diagrams necessary.

That said, even before going through without arrows, I remember asking one of the tutors (not the lecturer) during a tutorial session what's the difference between having and arrowed line and a solid line and he said there is none and I could use both. Obviously for that I only have my word and from what you guys have said, I doubt anyone in an academic position would admit to telling something that could put them in a defensive position. My mistake was not speaking to the lecturer directly, but in hindsight I obviously would have done it.

Anyway, I will speak to her regarding all this information and request her to take this "honest mistake" into consideration. It's also not just the use case diagram but a couple of other questions that I lost an unusual amount of marks on, especially when my answers are almost identical to the model answers she provided. I also know a lot of other students who have requested their assignments get remarked.

Hopefully she will be kind and use good judgement to improve my mark. I will post back here when I find out.

Thanks again for your help and please post any other info/suggestions you may have. :)

EDIT 2

Sorry guys, I have another question.

Here is the scenario that was given in the assignment to draw the use case diagram.

CONTHETICKET is a ticket agency dealing in Concert and Theatre tickets. Concert and theatre venues provide CONTHETICKET with a constant stream of information on forthcoming events, which is then used by the Manager to compile a fixture list for use by the sales staff in responding to customer calls. The manager selects some events for which CONTHETICKET will purchase a number of tickets in advance, thereby benefiting from discounts negotiated with the venues.

He personally sends the orders for the tickets together with the agreed payments to the venues, and once tickets are received, he files them in the ticket File.

When customers ring the sales team, their ticket requests are checked against the ticket file. If pre-purchased tickets are available they are put in an envelope marked with the customer's name and address, and filed in a provisional orders file. If not, the sales team fills out a ticket request form and put it in a tray for collection by the post clerk.

The payments section checks the provisional orders file daily. They send an invoice to the customer and await payment. A copy of the invoice is kept on file. When a payment is received, the payments section match the payment with the appropriate invoice, and if satisfied place another copy of the invoice in a despatch file with instructions to despatch the tickets.

The post clerks checks the despatch file each day and retrieves the appropriate tickets from the provisional orders file and sends them to the appropriate customers.

As you can see from my diagram I have an "Concert & Theatre Venues" as an actor.

From The Elements of UML 2.0 Style, Scott W. Ambler:

"An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML Use Case diagrams)."

However, on my marked assignment, the lecturer commented that it should not be an actor. Can you please tell me whether or not you think it should be an actor and why.

My rationale behind it is CT&V are supplying event information which is then used by the manager to order/file tickets, also supplied by CT&V.

Thank you very much.

Solution

The Good News

your diagram is correctly drawn and your instructor is mistaken:

arrows are inappropriate in use-case associations because they are binary associations
arrows are required for Extends, Includes, and Uses relationships - see this diagram for an example of all three

the UML specification v1.4.2 [PDF Warning] Sections 4.11.3 Well-Formedness Rules and 5.42.2 Binary Association are quite clear on these points:

4.11.3 Well-Formedness Rules: "Actors can only have Associations to UseCases, Subsystems, and Classes and these Associations are binary."

5.42.2 Binary Association: "A binary association is drawn as a solid path connecting two classifier symbols"

The Bad News

that being said, if your instructor told you to use arrows and you didn't, then you may have no recourse - that's one of the drawbacks of academia: some professors expect students to merely regurgitate what they are told, even if it is wrong. You can appeal to the Dean of the department, arguing that the professor is instructing the students contrary to the established standard, but that will most likely bring you nothing but grief. I do think you would have a strong case though, because giving you a zero on a correct diagram because you did not draw incorrect arrows seems excessive, harsh, and unjustifiable.

But I have met professors who were always right, even when they were clearly wrong. Most, however, are reasonable/logical people who are happy to correct misinformation appropriately.

Caution: Tread lightly

Assume it's an honest mistake, and ask the professor to explain why he expected arrows when the official OMG UML spec says not to use them (and hence every compliant UML tool for Use Cases will not draw arrows on a binary relationship). If you go in there guns blazing you may or may not get satisfaction, but you may also create animosity that could make the rest of the semester (and possibly beyond) quite unpleasant.

EDIT: I do believe that older tools and standards used single arrowheads (not triangles or filled, just 'wings') on use-case diagrams, but this is no longer done. Perhaps the professor's standards - or software - is just out of date ;-)

OTHER TIPS

Everyone else has already answered regarding the arrow thing. Let me just give you some advice about academia.

Most of the technical things you learn will either be wrong or just useless. In you professional life it won't matter as anything you will use as a professional will be things you learn there and then according to the specific needs of that situation.

What you will learn is the general overview of things, and this is something you won't get in your professional life because there no one has the time to look at it that way. There you will use the wrong tools to solve the wrong problems, usually because of some stupid reason like "because the higher-ups decided it that way".

So take this as a learning experience. To succeed as a professional you just have to learn that the right way to do things is a hard thing to achieve, and doing it on your own, as in this case, will probably get you in more trouble than just scoring zero.

Practice doing the wrong thing to achieve your goals: Do the arrowy thing and get your score.

Integreate the knowledge that everyone will always be wrong (including you): Don't take your teaches word for anything, read alternative views and form an opinion later when you have the experience.

Practice the art of getting involved in the political side of things to get a say on such matters. There is a way to get other to do the right thing, but it involves a lot of social engineering and hard work.

Just don't waste your time. Some things are just not worth the effort to correct...

Though it's unfortunate, I'd have to stick with "If that's how they told you do it, and you didn't do it that way, that's the score you get".

In my experience, the relationships could be either one- or two-way, so I think you'd have to distinguish between the two.

Your instructor, giving you a 0 for not using arrows in your use diagram, is an example of him teaching you the wrong things about Software Engineering.

Creating a spec for a software product, out in the real world, is not getting your arrows right.

It's about creating a living document that forms the foundation behind your project. The key aspects of any spec is that:

The project team actually reads it
The document is effective at capturing your intent

The idea that what you should be learning is how to draw in your arrows the right way is ridiculous. If you get a chance, you should read this article:

http://www.joelonsoftware.com/articles/fog0000000024.html

It captures my sentiments excellently.

It sounds like to get through your class you need to pretend to be interested in UML arrows. My advice to you is:

Do what is necessary to get a good grade in the class
The second you finish the final exam PLEASE forget everything you learned in that class, because it's only going to harm you.
Pickup up a copy of this book, and read it. The whole thing.

See here:

Arrows indicating the origin of the invocation are optional, so it seems it is at the discretion of your instructor but it could be an arguable point.

BTW in my experience graduate school is the worst place to learn software engineering. YMMV.

I think to you have strong case here ;)

Referencing the current UML specfication (2.1.2)

Page 595, Constraints, 2
UseCases can only be involved in binary Associations.

Taking this into consideration what is the point showing navigability on an association? As the interaction between the subjects (eg. Use Case and actor) is by definition bi-directional (eg. actor does something, system responds and so on).

You will also find sample Use Case diagrams in this document to further your point.

Of course for other Use Case constructs such as includes and extends arrows make sense and is required. However from your included Use Case diagram you haven't made use of these and should not be penalized for it.

Good luck

PS: Using my UML modelling tool of choice, Enterprise Architect, it doesn't allow me to visually indicate navigability on an assocation.

Hopefully she will be kind and use good judgement to improve my mark. I will post back here when I find out.

Thanks again for your help and please post any other info/suggestions you may have. :)

Licensed under: CC-BY-SA with attribution

Not affiliated with StackOverflow