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.

|improve this question
  • 1
    Do you want to know whether it is allowed according to the UML standard or according to some other standard? Or do you just want motivated opinions? – www.admiraalit.nl Sep 10 at 10:46
  • Just want some motivated opinions, maybe that they didn't contradict the standard. The homework is about logical coherence and domain analysis rather than strictly respect some standard – artas Sep 10 at 11:00
  • Sending to DeliveredProduct seems odd. Like asking the cow for its filet. You ask some DeliverySystem about that (like the butcher for the cow's filet). – qwerty_so Sep 10 at 12:40
  • @qwerty_so maybe i can use Shipping class that represent an active shipping (the van with the product) with associated the product that is shipping and that maintain information about it position (GPS). And insert a DeliveryService class wich access DeliveredProduct and Shipping for control the product position and/or state. So in the sequence I can use this DeliveryService as a bridge between user and information? seems less odd? – artas Sep 10 at 13:07
  • Yes. That should do. I guess the above is just a sketch for the question. However, I think it should be reasonable or commented accordingly. – qwerty_so Sep 10 at 13:40
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.

|improve this answer
  • while I agree on the practical aspects and that it is ok to use actors in a sequence diagram, I disagree on the formal correctness: UML specs says that a sequence diagram is an interaction diagram (17.8) and interactions “are units of behavior of an enclosing classifier (17.2.3.1). whereas an actor is a behaviored classifier (18.1.2) an actor is nonetheless external to the system and therefore not part of an enclosing classifier. This makes this usage ambiguous. See also softwareengineering.stackexchange.com/questions/376282/… – Christophe Sep 10 at 13:26
  • @Christophe One could use :User instead. However, I'd guess that anyone will understand the above notation. Your question is about actors receiving messages and that's a different story. – qwerty_so Sep 10 at 13:38
  • @Christophe, (1) We could consider the universe to be the enclosing classifier. (2) I didn't say this 'common practice' is formally correct. (3) Artas has indicated in a comment that formal correctness is not his primary concern. (4) Nevertheless, your comment is a valuable addition to my answer for those who are interested in formal correctness. Thank you! – www.admiraalit.nl Sep 10 at 13:50
  • @www.admiraalit.nl Thanks for this feedback. The (1) is a very nice one ;-) – Christophe Sep 10 at 14:42
  • @qwerty_so I think the arguments are symmetric for sending & receiving. I wanted to point out that the UML semantic would be ambiguous. For ex: shall I understand that the actor lifeline is a UI class playing the middleman with the real external actor ? or is it the actor itself, in which case, would this mean that ProductDelivered has also the responsibility of the UI ? And what does it mean that the message is synchronous with a user reading asynchronously a screen ? This kind of semantic would better be represented with a robustness diagram; the sequence would then be btw analysis classes. – Christophe Sep 10 at 15:02
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.

|improve this answer
  • Also get's my vote. Things become difficult once you go into details. I'm trying to go with Einstein's simplicity (which I now found out is not from Einstein: quoteinvestigator.com/2011/05/13/einstein-simple) – qwerty_so Sep 10 at 22:37
  • "What does your diagram add to the narrative of your track shipped product use case?" : (1) A picture tells more than a thousand words; (2) It is part of an object-oriented analysis model; it shows the distribution of responsibilities over multiple classes. This is recommended by traditional OO methodologies like the Rational Unified Process. Personally, I do not recommend to create analysis models, as I explain in admiraalit.nl/admiraal/WhichUMLmodels.pdf – www.admiraalit.nl Sep 11 at 6:49
  • @www.admiraalit.nl what I tried to say is that OP's diagram does not say more than his narrative and needs much more space and brainpower to do so; and all the responsibilities of the app are on the single class; storage does not even appear in the scenario. EBC was illustrative. Any approach clarifying a little more the classes needed and their responsibility would help. – Christophe Sep 11 at 6:59
  • @www.admiraalit.nl interestingly, the figure 3 in the section "what is really needed" of your article shows an EBC decomposition of the classes, which is my first bullet; i just propose to show the dynamics of the interaction between these classes (either with sequence, or with a robustness diagram which is quite popular in agile modeling). But I agree that activity could also be a good fit, especially given the simple and rather linear requirements. – Christophe Sep 11 at 7:08
  • Figure 3 is EBC on business process level (note the diagonal lines in the lower right corners of the symbols), i.e. a business boundary class is not a UI class, but a boundary where the organization communicates with entities outside the organization (irrespective of any IT systems supporting this communication). – www.admiraalit.nl Sep 11 at 8:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.