Hello,
my personal view:
The quickest way is to
- buy a book
- make a training
- get a coach for you and your team
Let me try to say it with some words. Forgive me for oversimplifying.
In UML an activity is a behavior. A behavior (an activity) can describe the behavior of a simple C-function or of a whole system, a part of a system or something else like a business process.
An activity diagram describes an behavior. Therefore it's a good idea to have an activity diagram for each activity.
An activity, an activity diagram may contain arbitrary activities, actions, or control elements like decisions.
Actions are atomic operations where the modeler has no intention to refine them by means of UML.
Actions may be a bit confusing because of the many existing kinds. For the start you may need:
- Atomic action (just the text and specification inside)
- call operation action (call a method of a class)
- call behavior action (call a behavior, an activity)
These elements together with:
- Init
- Final
- Decision
- Merge
- Fork
- Join
you have your basic toolset.
For the start: Learn to make valuable models. Think of yourself of an author who wants to explain your problem at hand to the invisible reader.
Stereotypes or tagged values are no concept to start with.
In my opinion most of the value of an UML model isn't generating a code but understanding the problem. After managing this you can look to code generation.
In mechanics we have:
- side view
- front view
- top view
In UML we also have different views (diagram types) to our system at hand.
Therefore: Think about the best model kind for each type of problem. You may use a pincer to nail a nail into the wall.
Good luck,
Helmut
