In this way, activities can be nested within each other and can be represented with different levels of detail. Calling, in itself, is an action the outcome of the call is another activity: With this symbol an activity can be called from within another activity. Specific actions are calling other actions, receiving an event, and sending signals. The action can possess input and output information The output of one action can be the input of a subsequent action within an activity. That does not necessarily mean that the action cannot be subdivided in the real world, but in this diagram will not be refined any further: ActionĪn action is an individual step within an activity, for example, a calculation step that is not deconstructed any further. A border can surround the activity, meaning the entire activity diagram. The execution of an activity can contain parallel flows. Fundamental elements of the activity are actions and control elements (decision, division, merge, initiation, end, etc.):Įlements are connected by so-called “activity edges” and form the “control flow”, which can also be casually called ‘flow’. In our context, an activity represents a business process (Figure 3.16). Refining diagrams does not mean describing process details that are performed within the business system, which often leads to an unnoticed shift to the internal view (Figure 3.15): Figure 3.15 Activity diagram “Passenger Services” with a low level of detail (“High Level”) Figure 3.16 Activity diagram of the activity “Passenger checks in” ActivityĪn activity diagram illustrates one individual activity.

In the external view, activity diagrams, just like use case diagrams, exclusively represent business processes and activities from the outside perspective. We, on the other hand, regard this fact as a great advantage, since users of object-oriented methods, as well as users of functional thinking patterns, find a common and familiar display format, which is a significant aid for business-process modeling.īecause it is possible to explicitly describe parallel events, the activity diagram is well suited for the illustration of business processes, since business processes rarely occur in a linear manner and often exhibit parallelisms.Īctivity diagrams can be developed in various degrees of detail. Purists of the object-oriented approach probably dislike this fact. In the external view, we use activity diagrams for the description of those business processes that describe the functionality of the business system.Ĭontrary to use case diagrams, in activity diagrams it is obvious whether actors can perform business use cases together or independently from one another.Īctivity diagrams allow you to think functionally. Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate activities.

Activity diagram definition in uml