0

question

Can an actor "talk" directly with an object of the system in a sequence?

example

For an homework I need to model a "tracking service" for some shipping company. The functional requisites for the system are:

  • Allow user to receive information about shipping of specific product starting from a shipping code( if is on way the position, if is arrived the storage in wich is stored)

So I made a use case diagram, a class diagram in wich there are only:

  • DeliveredProduct class: that describe the delivered product, having a "state" and "shipping code" attribute and some method like (getPosition, computeShippingCode etc..)
  • Storage class: Wich is associate with DeliveredProduct and mantain information about wich product are in a specific Storage

I don't insert some User class because the system doesn't mantain any information about user (they access directly with some shipping code), it's right?.

Now I'm making a sequence for "get information about shipping" use case and I have made this:

image

Can i use "DeliveredProduct" as abstraction of the part of the system that "handle" the information about shipping processing?

I prefer to avoid to insert some partecipant like "system" or "application" in the sequence. Is it possible?

Thank's in advance.

artas
  • 27

2 Answers2

1

Yes, it is common practice to let an actor send messages directly to parts of the system, not to the system as a whole.

I say 'parts' instead of 'objects' because in UML 2, the life lines in sequence diagrams correspond to parts, not to individual instances and are therefore not underlined. If you use UML 1 however, you should use objects and underline them.

In your example, I would expect the actor to send a message containing the shipping code to Storage, then Storage requests delivery information from DeliveredProduct and then Storage returns that information to the actor.

Often, sequence diagrams have life lines that represent the user interface, or particular parts of the user interface (often called boundary classes). In that case, the actor exchanges messages with the user interface life line and the user interface exchanges messages with entities like Storage or DeliveredProduct.

Disclaimer: Because it is homework, I expect you have some text book recommending some particular way of modeling. I don't know if this answer is consistent with that text book.

www.admiraalit.nl
  • 1,103
0

Is it legal ?

In principle, actors are not supposed to appear in sequence diagrams, since these diagrams are meant according to the UML specs to represent interactions within an enclosing classifier (see discussion around admiraalit's answer and here).

But it is a common and accepted practice, especially if the other interacting elements are sub-systems or higher-level components, as you can see in some examples here. And one could also argue that the enclosing classifier is the business system (i.e. the company with its users and IT systems). But be aware that the semantic of your diagram is then ambiguous: does the actor represent an UI class ? or does it represent the real user ? In which case whata are the semantic of synchronous vs. asynchronous messages ?

If your homework is about UML, you should better avoid it. If it is about design, you could keep it, but ....

What is the added value of your sequence diagram ?

What does your diagram add to the narrative of your track shipped product use case ? And what is the responsibility of the DeliveredProduct class: is it an entity ? is it responsible for the user interface ? what is the relationship with the storage class ?

Other approach

You could follow the EBC approach:

  • Decompose the use case into three groups of classes: Boundary (User-interface or API for external system), TrackProduct (Control = use case), and Product as well as Storage since these are obviously persistent data of your domain model (Entities).
  • Adapt your class diagram accordingly
  • Make a sequence diagram without actors, but with the boundary, the control and the entities. If you have decomposed your use cases, you may also involve control classes corresponding to the sub-use cases.

This has the advantage of being UML compliant without any doubt, and clarify the responsibilities of each class.

If you'd still want to show your user on the diagram, make sure that it communicates only with the boundary class and never ever with another one. In this case you could still argue UML compliance but avoid ambiguity.

Note that this would be an alternative to the robsustness diagram that are not UML but still a powerful tool based on a communication diagram.

By the way: It is not clear if your tracking service is also supposed to update the location.

Christophe
  • 81,699