'Is that true that one bubble (use case) represent an activity diagram?
I ever made an activity diagram to represent a use case with 3 actors. I made a swimlane for each actor, so I have 3 swimlanes in an activity diagram. But my lecturer said that it was wrong because I should have more activity diagrams. He meaned that an activity diagram based on one bubble (use case) in use case diagram, not based on actor. However I browse more, then I found that my lecturer's words should be a sequence diagram, not activity diagram. So what's the true statement? My first activity diagram or my lecturer words?
Solution 1:[1]
Your instructor is right:
- Use-case diagrams are about what the systems has to offer to fulfil the requirements. Each use-case correspond to a set of behaviors that may be performed in interaction with the actors for helping them achieving their goals.
- The activity diagram is about how the system performs elementary behaviors, or more complex sets of behaviors
Use-case isn't about the internals of the system. It's about its purpose and main relation with the outside world. There is absolutely no sequential order between the use-cases shown in such diagram. A user may read it and get an answer to the question "what's in for me?".
Activity is on contrary not about the outside world and not about actors. It's about the internals of the system: its internal flows, which follow an order that can be deduced from the control and dataflow semantics. A developer may read it and get an answer to the question "How shall this work?"
If you know that certain activities are performed in interaction with certain actors, and if you think it's important, you may communicate this knowledge in the model with an activity partition, graphically represented as a “swimlane”. But be aware that partitions are not intended for being mapped to actors or other elements of the environment. Partitions allow to visually group activity nodes that have some characteristics in common. They are typically used to highlight which component or class is doing what.
In conclusion, there is not necessarily a direct mapping between activity and use-cases, since they represent different realities. However, if such a mapping exist, it's at least one activity diagram per use-case (bubble).
P.S: Slightly edited to avoid any confusion in the terminology: “swimline” is a non-UML term coming from process modeling, that describes a graphical layout, and “partition” is a subdivision of an activity diagram in the model
Solution 2:[2]
Activity diagrams don't have actors.
They are meant to show the message flow from one activity (use case) to another. You can read more details about this here.
The activity diagram serves the following main purposes, it:
- draws the activity flow of a system,
- describes the sequence from one activity to another, and
- describes the parallel, branched, and concurrent flow of the system.
Solution 3:[3]
There is no one way to specify a use case. UML doesn't describe how to do it. Therefore, many authors have different ideas on how to do it. So, your idea to use partitions (you called them swimlanes) to represent Actors is valid, as long as it helps you to communicate the use case to your stakeholders.
However, that doesn't help you, when your lecturer has a different opinion. He or she might have good reasons for this statement. Probably it worked well in the situations he or she experienced.
Some authors suggest to use interaction diagrams. Since a use case describes how actors use a system, in other words, how they interact with it, this could be a good choice. The problem here is, that most people only know sequence diagrams of interactions, and they are not well suited to describe all the different ways the use case goal can be reached.
Therefore, many people use activity diagrams, even though officially they can't describe the interaction between actors and the system. They are in fact meant to describe the inner workings of a system (that could of course also be a system of people). So, your activity diagram officially means, that the activity invokes behavior at the actors. I don't think that was what you had in mind.
Since many people nevertheless use activity diagrams for describing use cases, I think your interpretation of partitions is not so far off. I personally think, partitions make live of the modeler unnecessarily more difficult and would not use them.
If you choose to use activities to describe use cases, it should be one activity per use case.
Solution 4:[4]
One use Case represent a single feature of the system but does not show the process involved to fulfill the requirement, to show the process involved we use the activity diagram.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 | bhristov |
| Solution 3 | Axel Scheithauer |
| Solution 4 | Erick Kaira |
