in uml - system sequence diagram, can the system ask input from the actor (see attached picture)
In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.
Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...
Preliminary remark
The practice of showing an actor in an interaction diagram is well accepted and quite common.
Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:
The actor being external to your system, it’s not a part of any enclosing classifier in your system.
As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question
Be consistent
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.
The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. 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. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)
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. And I’m not sure that your system is designed for responding to arbitrary messages from the user.
Another alternative?
A 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.
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).
Short Answer: Yes
Of course, the context of this interaction cannot be the system, since the actor is outside of the system. However, it is allowed to not model the context and let the interaction be its own context. Or you could introduce a Context Class, that contains the Actor and the system. But these are only formal considerations.
More important is, whether it is useful to do this. I would say, it can be. Describing how an actor will interact with the system is one outcome of analysing the use cases. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used.
I would reconsider using a synchroneous message here, though. Communication with a human actor is by nature asynchroneous. You never know, whether the message arrives, whether the actor understands it and whether the actor responds with the appropriate reply message.
PS: The reply message should show the name of the message it replys to, not some arbitrary text. If you want, you can show the return value after a colon (confirmationInput():Answer)
Confirmation is vague.
As a response to user input this part would be missing in your SD. Being incomplete would not be wrong. In that case you just describe that part which starts from the confirmation.
As part of some system activity (e.g. you have a control process which detects over-heating and asks the user to continue with a shut down or so) that part would not show the start of the use case being likely something like "Observe XY".
In any case using system as life line to the right seems pretty much pointless. One would be interested in which object of the system is asking for confirmation.
The question is always: what does the editor of the diagram want to tell someone else.
Related
Why DOESN'T this Star UML Sequence Diagram have the activation "rectangle" in the Control object? Am I doing something wrong? Should I set something in Star UML?
How can I add the activation "rectangle" in the Control object?
The simple answer is: because that's how the designers of Star UML designed it to be.
In Star UML if nothing initiates (triggers) the Execution Occurrence (that's the formal name of that rectangle) then... there is no Execution Occurrence. If you want to have it, you need to trigger it somehow (e.g. by self-referencing Initiation message).
I didn't find any option to change that behaviour. I haven't been using the Star UML for quite some time but since the free version has been abandoned earlier than I've started using it, I believe nothing has changed since.
If you're using the newer, proprietary version, you can send a request to the dev team of Star UML to add it as a functionality.
Well, this is because no tool I know of implemented sequence diagrams correctly. According to UML it should be possible to define ExecutionSpecifications (aka activations) independent of any Messages.
However, many tool vendors seem to assume, that an ExecutionSpecification must be started by a message. I can see, where they come from, since every execution has a cause. The problem is that sequence diagrams are not about causality, but about possibly occurring sequences of events. Sequence diagrams don’t mean, that this is the only possible sequence.
If we accept that the tool wants to start an ExecutionSpecification with a Message, the behavior of Star UML is consistent. Please note that a create message (i.e. messageSort=createMessage) does not call the constructor:
UML: A CreateObjectAction is an Action that creates a direct instance of a
given Classifier and places the new instance on its result OutputPin.
The Action has no other effect. In particular, no Behaviors are
executed
I know, this is about Actions, but why should a create message be different? Also, there is a constraint that stops create messages from having a signature:
signature_refer_to
The signature must either refer an Operation (in which case messageSort is either synchCall or asynchCall or reply) or a Signal (in which case messageSort is asynchSignal).
That means, you cannot reference a constructor in the create message. You will need to call the constructor explicitly. The sender of this message is the same Lifeline that created the new object. It should not be a self message, since this is not what is happening in reality and is therefore a workaround.
There is another option. You can make the class an active class.
An active object is an object that, as a direct consequence of its creation, commences to execute its classifierBehavior
Many tools show an ExecutionSpecification covering the whole lifeline for an active Class. Maybe your Class is meant to be active?
PS: Of course, this is not completely correct, since the classifier behavior also needs to be started explicitly:
A StartObjectBehaviorAction is a CallAction that starts the execution […] of the classifierBehavior of an object
That means, it doesn’t start automatically. We need an ActionExecutionSpecification to start it. Very few tools support this :-(
I have a flow of events and alternative events for a Login use case.
Basic Flow:
The actor enters his/her name and password.
The system validates the entered name and password and logs the actor into the system.
Alternative Flows:
Invalid Name/Password: If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.
I come up with this diagram:
I was said that there is no need for an intermediate Login Screen life line. How should I design the diagram now, according to conditions given above?
This diagram is not bad. It is however somewhat confusing, because:
Login is not really a use-case, even if it's a popular practice. This has however no impact on your SD diagram itself.
Showing actors in a sequence diagram is not formally correct, even if it's a popular practice.
Login Screen is in fact a part of System, which creates a kind of implicit redundancy.
Don't worry about too much about the two first points, if this is the kind of practices that your teacher showed you.
The last point could easily be addressed:
The last lifeline could be more specific about the internals (example here), or,
Keep only two lifelines, one for the actor and one for the system. THis is in my view the better alternative when you use actors in a SD.
Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?
Example:
No, you should use general purpose dependency instead, with optional title.
However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).
If there is a well defined interface between those systems, you can indicate that as well like this:
Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).
In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow.
I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing.
The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred.
The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...
If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.
A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.
There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.
EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.
I am new to the world of UML and have so far learnt the basics of use case, activity and deployment UML diagrams. I have a requirement of where users interact with a system e.g. user sending an email, which is then processed by a system and then sent to an agent (person) who then responds and interacts once again with a system.
I am having a hard time picturing these requirements and whether it should be a combination of use case, activity or deployment. Can I intermingle them? What is standard practice?
As you know, use cases are used to capture requirements. When identifying and detailing use cases, you look at the problem from the perspective of users. Only focus on what an actor expects the system to do. First step is to identify the use cases and actors and then detail the use case flows.
1- Identify the use cases and actors
In your example send email could be a use case initiated by the end user (your actor). What happens next (e.g system sending a notification to the agent) could be modeled as part of the flow of this use case.
Another use case could be the agent actor handling what they have to do after receiving the notification from the system (a prerequisite of this use case could be that a notification has been received).
Note that you could combine these two use cases together and have the agent as a secondary actor (secondary actor interacts with the use case but does not initiate it). Whether you do this or not, is a modeler's choice and depends on the size of use cases, number of use cases and many other things.
2- Detail the use cases
After identifying use cases and actors, you should detail use cases. The most important part is to detail the use case flow (step by step interactions of actor and system). This can be written as text or drawn as an activity diagram.
So to answer your question: yes it is possible and very common to combine activity diagrams and use cases; that is an activity diagram drawn to show the flow of steps of a use case.
Deployment diagrams on the other hand are totally irrelevant to the requirement elicitation phase. They model the physical structure of the system and how hardware components and software components interact.
In fact, it is very odd that you have learned component diagrams before class diagrams, sequence diagrams, state diagrams and many other diagrams.
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).