Using Activity diagrams, chronological cycles can be graphically depicted as they are described in use cases. Single activities and their interdependencies are shown. Use cases can also be described with natural language, so-called scenarios, whereby the overview remains intact only for very simple processes. With Activity diagrams, however, it is possible to show even very complex processes with many exceptions, variations, branches and repetitions in a clear and coherent manner. In practice, it is now customary to cancel descriptions of scenarios expressly in diagrams in order to trace the contained expressions when covered during implementation, and to set up test cases.
The semantics of the individual model elements differs greatly from the model elements in UML 1.x despite the same terminology. In UML 1.x, the activity element yields to the action, whereas an entire activity model is now called Activity. A number of references to the UML versions can be found at the end of the chapter on Activity diagrams.
Activity describes the procedural order of actions. It is represented by a rectangle with rounded corners. The Activity's nodes and edges are located within the rectangle. In the upper left corner is the name of the Activity. Within an Activity you will find Actions. There are several types of Actions available: normal (an atomic working step), CallBahaviourAction and CallOperationAction for referencing behavior defined somewhere else. It's also correct to draw Activities within Activities - for better structuring.
As with every behavior in UML, an Activity can also have parameters. Inbound or outbound objects in an Activity model are identified as parameters of that Activity. These objects are placed on the Activity rectangle and also below the name of the Activity with type designations listed.
The following example shows an activity for the production of sixpacks. This activity has two parameters: an inbound parameter, produced bottles in the condition [empty], and an outbound parameter, new sixpack. The precise declaration of activity parameters are at the top left directly under the name of the activity.
Fig. 17: Example of an Activity, "Production of Sixpacks"
This activity shows various kinds of nodes and edges.
The rounded rectangles are actions. The small rectangles on the actions are so-called pins. They provide the entry and exit parameter values for the Actions.
Up to UML 1.x Activity-Diagrams have been defined as a mixture of State-Diagrams, Petri nets and Process-Diagrams, leading to problems, practical and theoretical ones.
Starting with UML 2.x the token semantics of Petri nets has been applied, providing precise rules for the logical flow and flow of objects, including parallelization, synchronization and merging of paths. A token corresponds to an executing thread, which can be generated and destroyed. The token represents the progress of the logical flow or of the data-/object flow. By this formal specification of the semantic of Activity-Diagrams it's possible to apply an automatic verification of Activity-Diagram, namely a simulation.
Due to the revision, a change of terms is in effect:
· The rudimental, indivisible steps are now named Actions (and not Activities).
· A collection of steps, means a complete Activity-Diagram or a part of it, are called now Activities.
· While in UML 1.x each token incoming by a transition started a working step, now an implicit synchronization is in progress, that means all incoming object- and control flows have to reach the element to start its behavior.
· Similarly the dropout of an Action or Activity occurs at the moment when all legs can be "fired". Formerly the legs have been named transitions and the author had to specify conditions, ensuring that only one transition was selected. Now the firing is delayed for all legs until all conditions for all legs become true.
· There are new elements:
- Activities may have object nodes as input- or output parameters.
- Pre- and post-conditions for Activities can be specified now.
- Starting- and final activities are now named Initial node and final node.
The connections between actions differentiate between control flow and object flow. In notation both angles are the same: a solid line with open point.
Object flows can either be expressed with a straight line with an arrowhead between object-pins (a small rectangle on the boarder of an activity or action) or by pointing to or from an object, datastore or central buffer node.
A control flow connects actions and activities. When insert card is finished, the token moves through the control flow towards check card if check card is ready to be activated.
By an object flow, beside control data (or physical or logical objects) are transmitted. If several tokens are arriving, FIFO (first in, first out) is the applied rule. Instead of the pin-notion, an object symbol may be used.
An object stream is a special cases of object flow: a continuous flow of data (objects), like a conveyor band.
Object flows and control flows may be separated too. A central buffer node or a data store can be used for storing data temporarily or permanently.
Items may be stored in the basket (Central Buffer Node) and may be retrieved later. If the process is cancelled before the recall happens, data are lost - in contradiction to datastore.
A program flow junction is created by using a diamond (decision) symbol. A decision may have any number of outgoing legs (usually at least 2). Showing up more legs, it's treated as a switch. Alternatively a switch can be expressed as a sequence of decisions - wasting editing time and space in the drawing, this is unusual. Each outgoing leg of a decision must have a [Guard] !
Hint: Guards must cover all possibilities and must not overlap.
Two outgoing legs with the guards [x<0] and [x>0] ... incomplete, x=0 cannot be handled!
Two outgoing legs with the guards [x≤0] and [x≥0] .. overlapping when x=0, disjunct junction not possible → not correct!
Several outgoing legs on an activity or action without a guard define splitting (=parallelization)! To avoid a mix-up with the implicit junction, it's a usual style not to use the implicit junction at all but the decision (diamond) symbol. After a decision, always a disjunct selection is in progress.
Fig. 19: Parallelization and Junction - implicit vs. explicit
By a decision an alternate path is selected. To realize a loop, a merge symbol is needed.
Connecting the false path directly to the activity select appointed date will simply be wrong: Two incoming lines are allowed in UML, but this expresses an implicit join - synchronization - on all incoming paths a token will be needed to start select appointed date!
Suggestion: Avoid implicit semantic at all.
Fig. 20: Merging
Program flow is divided with a splitter (Fork, Parallelization symbol). The token hitting the fork generates a token for each outgoing leg, going their way now independently. Independence does not mean simultaneous - the behavior may happen simultaneous or not. If an outgoing token of the fork cannot be taken immediately by the subsequent element, its stored in a FIFO list until the subsequent action/activity can take it.
Fig. 21: Synchronization = Join
Independent processes can be consolidated by a Join Node (i.e. synchronization). A join node may have two or more incoming legs. For continuation it's necessary that on each incoming leg a controlflow- or objectflow-token reaches the join node. If this condition is true,
· all controlflow-tokens and identical objectflow-tokens are consolidated to one, singular token.
· All incoming objectflow-tokens are forwarded, but identical ones are consolidated into one each and are forwarded in a single instance only.
Fig. 22: JoinSpec
A join node has an implicit AND semantic. If only some of the arriving tokens shall be sufficient to continue with the synchronized path, UML provides the Join Specification (JoinSpec) feature. By this you may specify a condition, sufficient for synchronization. In our example, theatre selection and one of the payment methods are sufficient.
Activities can be hierarchically composed. An action can be reconstituted from a number of detailed actions. The inbound and outbound edges of this constructed activity and the detail models must correspond. With this cascading of diagrams, one can retain an overview of more complex processes. This subcategorisation into sub- or detail-models can be helpful and also necessary in many regards: a) Adequate subdivision to maintain standard paper format, and b) Creation of detailed classifications that are included in various documents and approved by various responsible persons.
A call to an activity is represented by a Call Behavior Action.
Call Behavior Actions can be identified fork symbol in the lower right corner of the action.
In the figure Enter PIN beyond the Activity update display is called within the loop as well as after exiting the loop. update display is defined only once, but called by the actions several times.
To use this calling feature instead of copying the activity is strictly recommended. Please note: You can only call activities by Call Behavior Actions!
Fig. 23: Calling an Activity by an Action
Call Operation Actions are similar to Call Behavior Actions, not calling a behavior (activity) but an operation directly - the operation is defined somewhere else, for example as an operation of a class. In the figure above, the operation FetchKey of the class ATM is called by the action key. This is intended by several quality systems - like SPICE, CMMI, ... Independently this small effort will pay back later on, when a change request has to be implemented.
Enterprise Architect provides possibilities for structuring elements: A structured (=composite) element contains a link to a diagram where the reader will find detailed information concerning the element.
Graphically composite elements can be identified by a chain symbol in the right, lower corner.
This is not defined within the UML-specification, but offers a very powerful possibility to structure diagrams.
To cascade diagrams enables to achieve a good overview and an easy drill-down-feature to reach more details. This will be necessary and/or helpful to:
a) deal with a limited printout format properly and
b) to separate the content in a way, where different reviewers with different competency and/or authorization level can agree easily.
Fig. 24: Structured (composite) activities
Single actions in the activity diagram are usually carried out by a responsible actor. In order to illustrate the allocation of the single actions to the actors in a diagram, so-called Swimlanes can be introduced. These vertical or horizontal lanes symbolize the actor and guide the activities through the graphical assignment of the individual actions to a lane in that actor's area of responsibility. Comment: This is represented only graphically, not logically!
Alternatively to swimlanes Enterprise Architect offers partitions, graphically very similar to swimlanes, but logically represented in the model. This allows a sorting of elements in the project browser by partitions, entering of detailed properties for the partition and - last but not least - pointing to an instance classifier carrying the definition of the task owner. The next figure gives an example of partition usage.
Controlflows or objectflows are connecting activities and actions. Processes defined by that are "synchronous" processes - determining the flow through possible subsequent working steps.
By usage of signals (Send Signal Action, Receive Signal Action and Timer Action) processes can be uncoupled, can be transformed into asynchronous processes.
By a Send Signal a broadcast signal is emitted. All Receive Signals, for which this signal is designated, will be activated. To enhance the readability dependency connectors may be used pointing from the Receive Signal to the Send Signal element!
Fig. 25: Send / Receive
The figure above shows that place Order is a Send Action that is taken by the Receive Action named accept Order by the Internet Book Shop
Hint: Receive Signal Actions do not need to have an incoming leg. UML uses the rule, that any element without an incoming leg will earn a token when the activity diagram comes to life. The exception is the interrupt region - elements within such a region without an incoming leg will earn a token at the moment when the flow enters the region.
An Interruptible Activity Region defines a special part of a process. When the region is entered by the token coming from Read Card, the process can be interrupted at any time. When the "normal" token crosses the border of the region behind the activity Enter Pin both receive symbols (Time Event is also a receive) lose their tokens.
If an interrupt reaches the Receive of Cancel Button or the time defined in the timer elapses, the "normal" token is destroyed and a token runs along the interrupt flow connector (lightning symbol) to the outside also killing all tokens of the not yet fired receives within the region. Please note: The interrupt flow must lead from an receive inside the region to an element outside of the region. UML provides no definition how the disintegration of the "normal" token is handled. Usually disable/enable sections are used in the detailed description of activities like Enter Pin to express if the interrupt is immediately in effect or will be cached until the enable-statement is reached.
In out example above enter Pin can be interrupted either by the cancel-button or be the elapse of the timer 45sec.
Fig. 26: Interrupt Region
| Name/Symbol | Verwendung |
| Action | The Action symbol is a rectangle with rounded corners. By definition, an action is a single step which can't be further subdivided, nor be broken up by outside influences. |
| Structured Activity | The symbol for combined activities is the Activity symbol with two small activity symbols drawn into the lower right-hand corner. |
| Call Behavior Action | A Call Behavior Action allows to call any behavior (activities) by this element. This will avoid redundant definitions of activities. |
| Call Operation Action | A Call Operation Action calls a discrete behavior of a structure element, for example a call to an operation of a class or a use case or ... The names of the element and of the behavior will be shown as <Element name>∷<behavior name>. |
| Control flow | Two actions are connected with an arrow when the activity flow changes from one action to another. The arrow points in the direction of program flow. The arrow can receive a condition as a label when the program flow takes place in this condition only. This is the case when numerous transitions emerge from one activity, or if flow is split by a diamond symbol. |
| Junction, Merge | Program flow can either branch out or be re-united with a diamond symbol. Should one transition enter and several exit, then this is a Decision. Should several enter and only one exit, this is a Merge, in which case no labeling is used. |
| Object | Objects are represented by a rectangle in which the name and condition of an object are given |
| Object Flow | An object flow describes the transmission of control from an action/activity to the next one and additionally transfers data/objects. This can be expressed by object nodes or an object between the actions/activities. Objects and object pins are instances of a class, a Central Buffer Node (transient buffer node) or a Datastore (persistent buffer node). Object nodes and objects may have a type (:card) and optional they may define an actual state ( [unread] ). |
| Fork (Splitter) | Using this element (Fork), program flow can be split into several program flows which run parallel. |
| Synchronisation | This element merges program flows which were separated by the splitter. A Synchronization can also take place which halts processing until all parts of the entire flow have arrived at the Synchronization element. This AND-semantic may be redefined by a Join Specification. |
| Entry Point | The entry point which starts processing after a use case is triggered is illustrated as a filled-in circle. When many start points are available, the concerned process branches are started parallel. If no start point is available, all nodes with no entry edge are interpreted as start points. To ensure proper understanding, one start point per process should be defined. |
| Activity Final | After all actions of an activity have been processed, program flow ends this activity. This point is shown with an end point – its symbol is a small filled circle surrounded by a larger circle. An activity diagram may have as many end points (Activity Final) as desired; endlessly running processes must not have one; if one wishes to express the end of an activity at numerous points, then the paths must not be merged. Warning: The Token which ends up here is not cancelled, but rather returned to the superordinate element that was allowed to jump to the current diagram. The sub-process (all still running tokens in the diagram) will be terminated! |
| Flow Final | Cancel, Flow Final, means that a Token reaching this symbol will be cancelled. The process branch is cancelled here. Should further Tokens exist, the entire process will be continued; if it's the final Token, then the entire process is ended. |
| Swimlanes/Partition | To model program flow with actions not belonging to the same areas of responsibility, like to different packages, areas of responsibility (Swimlanes) can be modeled with vertical or horizontal lines. The name of this area between two lines is labeled at the top with the name of the responsible actors' instance. |
| Send Signal Action | A Send Signal is an action used in a process to transmit asynchronous messages to other processes |
| Receive Signal Action | A Receive Signal is an Action waiting for a signal (event). At the moment the event is arriving, the defined action is performed and the flow is continued. Receive Events are used to model asynchronous behavior. If a Receive Signal Action has no incoming leg, and the element carrying the Receive Element (region, diagram) is active, it's ready to "fire". |
| Time Event | A Time Event generates an output (token) periodically. The output continues the subsequent flow. It may be used together with an interruptible activity region. If a Time Event Action has no incoming leg and the element carrying the Time Event Element (region, diagram) is active, it's ready to "fire". |
| Interruptible Activity Region | An Interruptible Activity Region is an area which can be left by events (Receive Events, Time Events). Actually performed actions/activities will be stopped and the alternate leg (interrupt flow, lightning symbol) will be used. |
| Datastore | ADatastore is a persistent buffer node. It's used to take data/objects out of an object flow. By this you can express an access to already stored data or a persistent writing of data. |
| Central Buffer Node | ACentral Buffer Node is a transient buffer node. It has the same behavior as a Datastore, but the stored content will be destroyed when the activity ends – when an Activity Final is reached. This is the semantic of a local variable within an operation within O-O programming languages. |
| Interrupt Flow | An Interrupt Flow is used to exit from an Interruptible Activity Region. |
In this example, a process for preparing a party is modeled. The model has been divided into several structured diagrams.
Fig. 27: Example of Activity: Prepare for Party
The first diagram describes three activities processed sequentially: Shopping, Cooking and party. Shopping is modeled as structured activity, showing the subsequent activities inside of Shopping.
From Shopping an object flow transfers foods bought towards the activity Cooking. The types Food and Dish have been modeled as classes and may be described in detail there, for example be adding attributes like calories, weight, etc. .
Cooking has been modeled by a separate diagram. The activity cooking receives Food as Input and forwards Dish as an output. Cooking start with concurrent processes: preparing foods is performed while a song is sung. When the song ends, this thread is terminated.
The activity prepare dish transforms foods into a dish. If the dish is not enjoyable, it's disposed and a pizza will be ordered.
The ordering is a Send Signal Action covered by take pizza order, a Receive Signal Action. This triggers another process, not shown in the current diagram.
While waiting for the pizza, watch TV is started - within a Interruptable Activity Region, which can be left be the ringing of the delivery boy or by a timer set to 1 hour. Either the pizza is delivered within one hour - it will be paid and served then - or the timer elapses and some sandwiches are prepared and served, both by merging the flow at the merge node.
After putting the dish on the plate, the activity cooking is finished.
Source: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/activity-diagram
Posted by: vanbruntmylesees.blogspot.com
0 Komentar