![]() Communication with a human actor is by nature asynchroneous. I would reconsider using a synchroneous message here, though. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used. Describing how an actor will interact with the system is one outcome of analysing the use cases. ![]() More important is, whether it is useful to do this. But these are only formal considerations. Or you could introduce a Context Class, that contains the Actor and the system. However, it is allowed to not model the context and let the interaction be its own context. Of course, the context of this interaction cannot be the system, since the actor is outside of the system. This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details). ![]() Another alternative?Ī less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous. And I’m not sure that your system is designed for responding to arbitrary messages from the user. If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability) It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. You should consistently keep this logic, as you did in your diagram. The flow of messages shows which object is the sender of the message and which object responds. If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object. Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question.you model the organisatiin that uses your IT system. As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e.The actor being external to your system, it’s not a part of any enclosing classifier in your system.Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier: The practice of showing an actor in an interaction diagram is well accepted and quite common.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |