Activity Diagram Modeling
Services are represented by operations, contained by interfaces. Each interface will generate a file bearing the same name in the service project. Each operation will generate a function in the matching file. All services are contained in a global <<PK_SERVICE>> stereotyped package.
Figure 4 – Services treeview
The following screenshot shows previous image’s "Entities Creation Services" diagram, in which is only one interface.
Figure 5 – Services summary
Most of the time, an operation is stereotyped. The only case when an operation does not bear any stereotype is when the parent interface is stereotyped. The behavior of that operation is then defined by its interface’s. A stereotyped interface cannot contain more than one operation.
Figure 6 – Stereotyped interface
The stereotypes on CRUD operations generated with the Blu Age Operation wizard are to be used with precise parameter and return types.
|Stereotype||Parameter type||Return type||Description|
|find_by_id||BO||BO||Returns a BO with an ID that matches the ID of the parameter.|
|find_by_properties||BO||List||Returns a list of BOs matching the parameter attributes.|
|find_all||no parameter||List||Returns the BO list of all entries in the table.|
|create||BO||boolean||Adds an entry in the database with the properties of the parameter.|
|update||BO||boolean||Updates the database entry with the properties of the parameter.|
|delete||BO||boolean||Deletes the database entry bearing the ID of the parameter.|
|create_all||List of BOs||boolean||Adds an entry in the database for each BO in the parameter list.|
|update_all||List of BOs||boolean||Updates the database entries corresponding to the BOs in the parameter list.|
|delete_all||List of BOs||boolean||Deletes all the database entries corresponding the BOs in the parameter list.|
The following image is an example of service in which are all the CRUD operations that can be generated with the Blu Age Operation wizard.
Figure 7 – Service with CRUD operations
You can define a service whose behavior is configurable by stereotyping it <<process>>. When declaring a process operation, you have to create an activity diagram bearing the same name.
Figure 8 – Process service treeview
This activity diagram has to start by calling the process operation of the same name. Each instance used in this diagram (other than an in or return parameter, or a "pin in" resulting from an operation call) must be defined.
To create an object node, click on "Object Node" (MagicDraw tab):
Figure 9 – Process service activity diagram
You can use Business Object functions or other operations from any package in these diagrams.
There are many possibilities to model a process diagram:
To create an opaque action, click on "Action -> Opaque Action" (Magicdraw tab):
For instance, you can use an opaque action to set a value to a Business Object attribute, to add a value to a list, to instantiate:
Figure 10 – Example of different opaque actions
To define the code to execute in the opaque action, fill the "body" attribute of the action:
Figure 11 – Configuration panel for opaque actions
The code written in an opaque action must match the generated application technology: if your application is a Java application, all you opaque actions must contain Java code. In the same way, using a type requiring an import won't generate the matching import line. You will need to write the fully qualified name for the type to be recognized.
This feature allows to use conditions in process diagrams. To create a conditional instruction, you have to create a decision node (MagicDraw tab):
Next, bind the decision node with an operation and double-click on this link. You will obtain the following properties window:
Figure 12 – Configuration panel - conditional process diagram
Fill the fields "Guard" and "Weight". Guard is the condition itself to verify, and Weight is used to define the order in which the decision links are dealt with (for instance we can choose "10" for the first decision link and "20" for the second, "10" will be the first case to be checked).
Then, bind the decision node to a new operation or a decision node (in order to close the conditionnal processing, use a "Decision node", not a "Merge node").
The result for our example is the following process diagram:
Figure 13 – Example of a conditional process diagram
Modeling a "while" instruction requires the use of an "Expansion Region" (MagicDraw tab):
This behavior is controlled by a boolean parameter, which can be either a previously defined instance or an expression to be evaluated.
In the upper right corner, the four arrows represent the iteration condition definition:
Double-click on it and fill in the name and type (boolean for a "while" behavior).
Figure 14 – Configuration panel - while process diagram
Then model the actions you want to execute inside the region. The instructions must start with an "Initial Node", and end with an "Activity Final". The instructions will be repeated as long as the while condition is verified. Do not forget to deal with the condition variable inside the expansion region so as to avoid an infinite loop.
The result of our "while" example is the following process diagram:
Figure 15 – Example of a while process diagram
Unlike the "while" loop, the "for" loop iterates on a list. Indeed, an iteration is done for each object in the list/table passed as parameter.
To create a "for" instruction, click on "Expansion Region" (MagicDraw tab):
In the upper right corner, the four arrows represent the iteration instance:
Double-click on it and fill in the name and type (List).
Then, double-click on the region itself, a panel will be displayed. Go to the "variables" tab and click on the "create" button. Fill name and type of the variable. This variable represents the current object of the list for each iteration.
Figure 16 – Configuration panel - for process diagram
Then model the actions you want to execute inside the region. The instructions must start with an "Initial Node", and end with an "Activity Final".
The result of our "for" example is the following process diagram:
Figure 17 – Example of a for process diagram
This scenario allows to manage exceptions with modeling. Exception are used to display errors of execution.
To create an exception in a process diagram, click on "Opaque action" (MagicDraw tab):
Place it next to the operation you want to add an exception on. Add an "Input Pin" to this opaque action. Then, click on "Exception Handler" (MagicDraw tab): and drag it from the output pin of the operation to the input pin of the opaque action.
Double-click on the opaque action, to fill the body (value to trigger the exception).
Figure 18 – Configuration panel - Exception action
The result of our "exception" example is the following process diagram:
Figure 19 – Example of a Exception process diagram
To model a switch, you have to create an Interface and use the following configuration:
- create a main operation bearing the stereotype <<dispatch>>, with each variable needed in the cases as a parameter of this operation,
- create one process operation per case, also stereotyped <<dispatch>>, with parameters named after the ones of the main dispatch operation,
- set the "condition" tagged value (boolean expression) of each case process operation, the language used in this condition can be BAGS if you set the "language" tagged value to "bags",
- create a default case (process operation), whose condition is set to "default" or left blank.
Figure 22 – Example of dispatch service Here is an example of tagged valued configuration for a case operation:
Figure 23 – Example of case operation tagged value configuration When using the dispatch service, make a call to the main dispatch operation.
The main operation's return type can be something else than void. In that case, if a case operation's return type is different than void, it will be used to set the main return.
Here is an example of case process operation:
Figure 24 – Example of case operation