How to depict nested action/activities in a UML Activity Diagram? - uml

I would like to create an activity diagram in which one of the actions is depicted with its sub-actions.
To better clarify I would like to be able to depict something like the following diagram
The problem in my case is that SubActivity1 does not have any input parameter. I just want SubActivity1 to start its execution when OpaqueAction1 is completed.
I know that it is possible to use a CallBehaviorAction to express that an Action will result in the execution of another Activity like in the following diagram
But, in this way I cannot depict the sub-actions in the same activity diagram.
I also thought of using a StructuredActivityNode like in the following diagram
here the problem is that I am not able to show the name of the StructuredActivityNode. I do not know whether this is an issue of the tool that I am using (Papyrus) or it is a general issue.

What you always can do it to use diagram frames and place them inside an activity:
If you need to pass parameters and make use of them inside an activity you can do it this way:
The action pin on Action1 takes the parameter to process it. As you see, you can also place the contents of an Activity manually inside its frame.
An activity is completed when it has reached its last action. More explicitly you should use a flow final to show that. I omitted it in the first example since your examples lacked it. But I usually place it at the end of each (sub-)flow.

Related

How to pass variables between a nested activity diagram and its calling action in Cameo Systems Modeler?

I want to re-use code abstracted out as activity diagrams in Cameo Systems Modeler. I plan to make them functions which accept input variables and return other variables.
I am noticing that None gets passed out of the sub-diagram to its calling parent. How can I overcome this limitation?
I have already added input and output nodes to the model for the nested activity, and they appear both in the parent view and the nested view. I got a yellow/orange "warning" around the nested activity diagram which provided a clickable menu with a warning triangle symbol and options to automatically add the input(s) and output(s) to the nested activity diagram.
If I want to re-use these activity diagrams, do I have to make sure the input and output variables of the calling parent match what shows in the nested diagram? I believe I have done that and yet I cannot figure out what is wrong.
I was hoping that the variable would be passed up to the calling parent, but it is not getting passed. I have even "debugged" by setting breakpoints and watching what happens in the nested diagram, and the problem is the interface with the caller, not in the nested diagram.
I understand your question as: "How to pass objects from CallBehaviorActions to the called Activity and back?"
Actually, that should be straight forward. Just define an Activity with ActivityParameterNodes. When you drop such an Activity on the diagram of another Activity, Cameo will create a CallBehaviorAction with matching Pins. That's it.
Of course, you can also create matching Pins manually.

How to show repeatable activities in UML diagram

I'm working on a project and trying to show one of the Use Cases in a UML activity diagram.
I'd like to use it in order to show that the requirements for this particular use case are met.
I'd also like to use it to develop the test cases that will need to be written for this use case.
I've ordered the "UML 2.0 In A Nutshell" book but until that arrives I'm trying my best from articles and youtube clips so the diagram may not conform to the proper standards.
Question 1:
I've tried to show that the ExecuteInThread function as a whole has a try catch block to stop any exception bubbling up and crashing the app but I'm not sure if I've shown that correctly?
Question 2:
I'd also like to show is that updating the task status to Failed / In Progress / Completed is done on the database and if the database is unavailable it retries 10 times to connect before it fails.
Is it possible to have a repeatable block on the side I could refer to for each Update activity to show this?
Question 3:
I've read that at the level of the use case I should not be showing any implementation details.
I'm guessing this means avoid showing there's a database involved at all and not to show any try / catch logic unless it impacts the user's actions. Am I doing completely the wrong thing here?
The retry logic is a requirement for this use case though so my first attempt was to include it given it would help with writing the test cases and showing application resilience.
Diagram:
Question 1:
Any action can be protected by an exception handler. This is the zigzag-line in your diagram. The action at the other end is the handler body. I must not have incoming or outgoing control or object flows. When the exception handler finishes, the protected action produces tokens on its outgoing flows, as if it has ended normally. The handler body should also have an input pin typed by the exception. This way it can distinguish different exceptions and the protected action can tranfer information about the problem.
Structured activity nodes are also actions and can be protected by an exception handler. In your diagram I guess Execute Task in Thread is such an action. The official notation uses a dashed border and the keyword «structured».
Edit: After discussion with #bruno.
If you want to use Exceptions, you should probably rethink how you group the actions. A protected action will always finish successfully, if its exception handler body doesn't raise a new exception. That means the body must try to recover from the exception and potentially retry the behavior of the protected action (there is no UML element for retrying, you will have to do it on foot). If that doesn't work, the handler body must reraise the exception (after having made sure that everything is in good order, i.e. that the class invariant is still holding).
This might seem a bit over complicated. Why not simply use a decision node after the action execute task with the guard [successfull]. I would use ReceiveSignalActions in use case flows only to model interactions from outside of the system, that can influence the flow of the use case.
Question 2:
You can create an activity update task status and call it from all the update actions. The status itself could be a value pin on this call action. Inside the update activity you can show a loop with decision and merge nodes that counts the trials. However, it will probably be easier to just write in the description, that it can be Irepeated 10 times.
This is the way how a repeatable set of actions can be modeled. It is not possible to do that in the same diagram. I would however be allowed to expand one of the call actions, so that the called activity is shown there. You have to try, whether your tool does offer this possiblity. Some tools only offer to show any diagram embedded in another diagram. This is not standard and will not be interchangable between tools.
Question 3:
I agree that the database and the number of retries are technical details that are not the focus of the use case analysis.
It could be interesting, though, if the system would not just display an error message, but would need to offer alternative ways to achieve the desired result. If for example the system shall then offer to save the update to an usb stick. Since this requires additional interaction with the user and gives rise to a new functional requirement for the system, it makes sense to analyse it within the use case. If it is just an occasional technical problem, I would not cover it.
If you need a way to capture this requirement in your model, I would just add a user defined extension for textual requirements. Not all requirements are coming from use cases. Many tools already have their own extension for this.

Simplify an activity diagram

I'm working on my graduation project which is an online quiz website. now i'm drawing the UML activity diagram but it gets too complex and i can't add more details because at the end it must be printed in the project documentation in A4 papers.
can i split the diagram into multiple diagrams?. and if i did this should i repeat the login/registration actions in the beginning of each diagram?
Use structured activities to form logical groups. You can instantiate these activities as call behavior actions where needed.
Assume you have an activity Login
(the lying 8 is an invention of Enterprise Architect to indicate an embedded diagram; not UML standard)
which looks inside like
(just very simplified).
Now you can instantiate that like
where the fork indicates the action is a call behavior.
Adding activity parameters it would even be possible to parametrize these. Just like you would do when calling a function in a programming language.

Can I create a nested activity diagram in UML?

For eg: I have an activity diagram depicting the flow of an API. Now that API calls an internal/static function. So, is it possible to depict the called function activity diagram with the caller activity diagram?
There are a couple of ways to achieve nesting in EA. One would be to create an Activity for the sub-process and invoke that.
You can nest the actions in an activity and use that in the main flow as invocation (when dragging the Activity on the diagram use as "Invocation" rather than as "Link"). It then looks like
From the browser (well, it's EA) you can choose Add/Composite Structure Diagram. Here you can layout the subprocess (e.g. like)
When you double click the invocation it will open this structure diagram.
Additionally you can use this diagram and drag it onto the (enlarged) invocation so it would show its guts:
The way it's shown in uml-diagrams.org is not possible for the diagram representation in EA (or I don't know how to do that). However, you can add ObjectNodes to Activities from the browser's Add context menu. These can be use in the referenced way.

activity diagram - how to show multiple objects passed between two actions?

Background
I have one action (action_a) that calls an operation(operation_x) on another action (action_b).
The parameters to operation_x are as follows:
action_b.operation_x( param_1, param_2 )
I'm trying to work out how to document the parameters being passed in UML activity diagrams.
Option 1
One option may be to use a comment?
Option 2
Another option may be to use activity parameters, but it doesn't seem right to show two flows from action_a for one operation call?
Question
How can I show multiple objects being passed?
Option 2 is close, but the edges coming out of action_a are not right, and I don't think it's legal to show the call and the details on the same diagram. Please see my other answer.

Resources