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.
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?
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 DFDs 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.
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. Should this be an actor and if so, 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.
your diagram is correctly drawn and your instructor is mistaken:
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"
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.
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 ;-)
