Good Practices
Name
•The activities name is made up of an infinitive verb and an object.
•The name must clearly identify the objective of the activity. For example, "Create request", "Authorize request", "Notify rejection", and so on.
•The first letter must be used in uppercase and the others in lowercase. Short names or abbreviations must not be used.
•It is recommended to avoid long names, they usually denote that certain details of the activity affect their name. The name must represent the objective while details are documented within the activity.
•The use of "and" and "or" in the names of activities must be avoided. These types of compound names can mean that they are actually two different activities.
For example, if the activity is called “Review and approve request”, you must consider which is the correct option. If the same participant performs both actions at the same time, then the most relevant action must be chosen and used to name the activity, then it can be assumed that the primary objective is approval and the review is a subtask. The correct name is “Approve request”. On the other hand, if it is considered that both actions have the same relevance and are made at different times, then it is convenient to separate them as “Review request” and “Approve request”.
Repetition
•Multiple instances of the same task should not be diagrammed to represent multiple participants.
•It is recommended to use roles or agents so that the participant assignment is made accordingly, when executing the process.
Typing
•It must be indicated each activity type.
•It is recommended to be careful selecting the appropriate type, which allows a correct interpretation of the diagram.
Automatic Tasks vs Automatic Actions
•There are certain actions, such as sending an email, executing a rule, etc. that can be modeled in different ways in Deyel:
a)Representing them explicitly in the model, through shipping type activities, business rule, services, etc.
b)Specifying automatic actions that are executed when starting or ending a user activity or manual activity.
•The recommendation is that the tasks to be viewed individually have to be modeled as different activities and the type of each one is selected.
•Those others that do not need to be visually explicit, should be modeled as automatic actions of user activity. For example, a rule that retrieves the initial value of a field before executing the user activity,
•It is important to maintain a uniform criterion in this regard and also consider that long diagrams are not convenient.
