An activity (Engl. Activity ) is a model element in the Unified Modeling Language (UML), a modeling language for software and other systems. It models the behavior of a system by describing how elementary behavior modules, so-called actions , are combined with the help of control and data flows to form more complex behavior.
Elementary building blocks of an activity
An activity arranges actions as elementary behavior modules in a network consisting of nodes and edges. The UML2 knows three types of activity nodes:
- Actions are the elementary building blocks of behavior
- Object nodes are auxiliary nodes that are used to specify the flow of objects through the network
- Control nodes are activity nodes that in one way or another control the flow of control or data in an activity
Activity edges are divided into two main groups:
- a control flow is an activity edge over which no object tokens flow
- an object flow is an activity edge over which objects can flow from one object node to the next
The figure on the right shows an example of the graphical notation of an activity. Various possible components, for example forms of object and control nodes as well as examples of object or control flows are shown.
If a complex behavior is modeled as an activity, the corresponding model and, above all, an associated graphic representation in an activity diagram can become so extensive that it can only be recorded, conveyed and maintained with difficulty. It is therefore necessary to break down extensive activities into smaller, clearer parts. Two techniques are known for this in UML2.
Activities can be nested. The procedure is similar to how a program is structured in subprograms that are called from a main program. A part of an extensive activity, the "main program", is outsourced to an independent activity, the "sub-program". In the main activity, only one action appears, which represents the call of the sub-activity. The UML2 provides the action
CallBehaviorActionfor this. It is marked with a special symbol, a stylized rake, in the upper right corner.
Use control structures
The Structured programming requests since the 1960s that software from the three elementary components sequence , selection and loop is set up to allow them to more efficiently create, test, and maintain. This principle was formulated to counter the use of the so-called goto statement . It was assumed that this and other technology contributed to the software crisis in the 1960s. The principles of structured programming in computer science are now taken for granted.
Although UML2 is not a programming language but a specification language, modelers are faced with similar problems when specifying the behavior of a system as programmers are confronted with programming implementation. This is especially true for the specification of behavior with the help of activities. The counterpart to the jump instructions in classic programming are the arbitrary control and object flows that can lead to poorly structured behavioral specifications.
So that instead of the well-known “software crisis” there is no “model crisis” in the future, UML2 also provides the control structures known from structured programming for the modeling of activities. To the so-called structured node (engl. StructuredNode ) include, in particular
- the sequence node (engl. SequenceNode )
- the decision node (English ConditionalNode )
- the loop node (engl. LoopNode )
The UML2 specification does not reveal how these nodes are to be represented graphically. The figure uses the suggested representation from UML crystal clear ( Lit .: Jeckle 2004). The structured node is drawn with a dashed, rounded rectangle. In this example it is a question of a decision node that is divided into three areas: a section for checking a condition (“if part”), a “then part” and an “else part”.
An activity models behavior by indirectly determining which elementary actions are carried out in which order. The importance of an activity is given by the fact that at least mentally small data packets, so-called tokens , wander along the activity edges and have an effect on the activity nodes. For each type of activity node and activity edge, rules are defined how to deal with these tokens, under which conditions, for example, tokens are temporarily stored, retained, doubled, or forwarded individually or as a group. All the rules for the individual types of activity nodes are summarized in the set of rules for how a modeled activity is to be interpreted, i.e. what meaning it has.
Basically, the rules for the flow of tokens in an activity are based on the rules of similar formal models, such as the Petri nets . For example, in analogy to Petri nets, the principle applies that an action in an activity is started when a token is pending on each incoming activity edge. On the other hand, UML2 defines far more detailed rules for the flow of tokens through an activity than in Petri nets. There are two main reasons for this. First, activities have many additional types of knots that are not found in Petri nets. Second, properties such as the capacity of activity edges and object nodes as well as the streaming mode of activity parameter nodes determine the token flow.
In principle, however, the following three rules apply to the flow of tokens:
- Cache only in object nodes . Object nodes, for example pins or activity parameter nodes, can hold tokens. In contrast, control nodes such as decision-making or parallelization nodes do not serve as intermediate storage for tokens. A token always flows from one object node to another object node.
- Full traversal (Engl. Traverse-to-completion ). Source nodes offer tokens for the outgoing activity edges and a token only moves from a source node along one or more activity edges to a destination node when the whole path is "free", that is, when all nodes and edges involved forward the token and when the end Node can accept the token. In this case, a token traverses the "free" path either completely or not at all. There are no tokens that get stuck halfway.
- Token competition (English token competition ). If the detailed rules for activity nodes and activity edges show that a token can leave an object node via more than one activity edge, i.e. if more than one path is possible, then the token moves over any of the possible edges. The selection is not fixed, which does not necessarily mean that it is random. Rather, it is up to implementations of the specified behavior how they make the selection.
- Christoph Kecher: "UML 2.0 - The Comprehensive Manual" Galileo Computing, 2005, ISBN 3-89842-573-8
- Conrad Bock: UML 2 Activity and Action Models , in Journal of Object Technology, vol. 2, no.4, July-August 2003, pp. 43-53
- Conrad Bock: UML 2 Activity and Action Models Part 2: Actions , in Journal of Object Technology, vol. 2, no. 5, pp. 41-56
- Conrad Bock: UML 2 Activity and Action Models Part 3: Control Nodes , in Journal of Object Technology, vol. 2, no. 6, pp. 7-23
- Conrad Bock: UML 2 Activity and Action Models Part 4: Object Nodes , in Journal of Object Technology, vol. 3, no. 1, pp. 27-41
- Mario Jeckle , Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins: UML 2 crystal clear. Hanser-Verlag, 2003, ISBN 3-446-22575-7