UML activity diagram: Difference between revisions

The educational technology and digital learning wiki
Jump to navigation Jump to search
mNo edit summary
 
(45 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Stub}}
{{Stub}}
'''SORRY''' this page is broken. Had to remove an uml extension for security reasons - [[User:Daniel K. Schneider|Daniel K. Schneider]] ([[User talk:Daniel K. Schneider|talk]]) 16:56, 21 August 2013 (CEST). Some day we could try [https://www.mediawiki.org/wiki/Extension:PlantUML PlanUML] - [[User:Daniel K. Schneider|Daniel K. Schneider]] ([[User talk:Daniel K. Schneider|talk]]) 17:45, 22 April 2016 (CEST)


== Definition ==
== Definition ==
Line 5: Line 8:
'''UML activity diagrams''' refer to [[software engineering]] method modeled with [[UML]] to describe work flows, business processes and other procedures.
'''UML activity diagrams''' refer to [[software engineering]] method modeled with [[UML]] to describe work flows, business processes and other procedures.


UML activity diagrams are a kind of behavior diagram. UML activity diagrams seem to be somewhat similar '''UML state machine diagrams''' which in turn are similar to [[Petri net]]s.
UML activity diagrams are a kind of behavior diagram, i.e. is a kind of [[UML behavioral modeling]]. UML activity diagrams are somewhat similar '''UML state machine diagrams'''.  Both are somewhat similar to [[Petri net]]s.


See also: [[UML]]
See also: [[UML]], [[UML behavioral modeling]], [[coUML]] (an extension for learning design), [[BPMN]] (a business process workflow notation language)


== Architecture of activity diagrams ==


The basic concept of activity and all other behavior diagrams are '''actions'''. {{quotation|An action is the fundamental unit of behavior specification. An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty. This clause defines semantics for a number of specialized actions, as described below. Some of the actions modify the state of the system in which the action executes. The values that are the inputs to an action may be described by value specifications, obtained from the output of actions that have one output (in StructuredActions), or in ways specific to the behaviors that use them. For example, the activity flow model supports providing inputs to actions from the outputs of other actions. ([http://www.omg.org/technology/documents/formal/uml.htm UML, version 2.1.2])}}.
== Introduction ==
 
Activity modeling means to describe sequencing and conditions of actions. Such descriptions commonly are '''control flow''' and '''object flow''' models.


Simple Activity diagrams consist of:
Simple Activity diagrams consist of:
* Initial node.
* Initial node.
* Activity final node.
* Activity final node.
* Activities in between
* Activities in between
<uml>
Begin.start;
Activity.eat("Eat something really good", "from the fridge");
Activity.read("Read a book");
End.finish;
topToBottom(20)(start, eat, read, finish);
drawObjects(start, eat, read, finish);
clink(transition)(start, eat);
clink(transition)(eat, read);
clink(transition)(read, finish);
</uml>


{{quotation|The starting point of the diagram is the initial node, and the activity final node is the ending. An activity diagram can have zero or more activity final nodes. In between activities are represented by rounded rectangles.}} ([http://en.wikipedia.org/wiki/Activity_diagram Wikipedia], retrieved 11:08, 4 June 2008 (UTC).
{{quotation|The starting point of the diagram is the initial node, and the activity final node is the ending. An activity diagram can have zero or more activity final nodes. In between activities are represented by rounded rectangles.}} ([http://en.wikipedia.org/wiki/Activity_diagram Wikipedia], retrieved 11:08, 4 June 2008 (UTC).
== Architecture of activity diagrams ==


=== Basic Nodes ===
=== Basic Nodes ===


According to Conrad Bock (2003), there there are three kinds of node in activity models:
 
According to Conrad Bock (2003), there there are three kinds of nodes in activity models:
# Action nodes operate on control and data values that they receive, and provide control and data to other actions.
# Action nodes operate on control and data values that they receive, and provide control and data to other actions.
# Control nodes route control and data tokens through the graph. These include constructs for choosing between alternative flows (decision points), for proceeding along multiple flows in parallel (forks), and so on.
# Control nodes route control and data tokens through the graph. These include constructs for choosing between alternative flows (decision points), for proceeding along multiple flows in parallel (forks), and so on.
# Object nodes hold data tokens temporarily as they wait to move through the graph. Figure 3 shows the notation for some of the activity nodes to be discussed. Contrary to the names, control nodes coordinate both data flow and control flow in the graph, and object nodes can hold both objects and data
# Object nodes hold data tokens temporarily as they wait to move through the graph. Below, the notation for some of the activity nodes to be discussed. Contrary to the names, control nodes coordinate both data flow and control flow in the graph, and object nodes can hold both objects and data


[[image:activity-diagram-nodes.gif|frame|none|Major nodes types for activity diagrams. Conrad Bock: UML 2 Activity and Action Models, Journal of Object Technology, 2, (4) 43-53. http://www.jot.fm/issues/issue_2003_07/column3]]
; Action nodes
 
<uml redraw>
; Activity nodes
Activity.do("Do something nice");
* Represented by a rectangle with rounded corners
drawObjects(do);
</uml>
* Represented by a rectangle with rounded corners (drawn in slightly different ways depending on the software used ...)
* Action nodes should have a label
* Action nodes should have a label


; Object nodes
; Object nodes
* Represented by a rectangle with a label
* Represented by a rectangle with a label (i.e. UML class boxes)
<uml>
EClass.obj(iClassNameOnly)("Blog entry")()();
drawObjects(obj);
</uml>


; Decision and merge control node
; Decision and merge control node
* Represented by a lozange
* Represented by a lozange
<uml>
Branch.test;
drawObject(test);
</uml>


; Fork and join control node
; Fork and join control node
* Represented by a line
* Forks and joins are represented by a horizonal or vertical line (and incoming and outgoing flows)
* One or more activities can fork.
* One or more activities can join
* One or more activities can join
* One or more activities can fork
 
<uml redraw>
Fork.forkA("h", 100);
Fork.forkB("v", 20);
leftToRight(10)(forkA, forkB);
drawObjects(forkA, forkB);
</uml>


; Initial node
; Initial node
* Represented by a fat black dot
* Represented by a fat black dot
* There can be only one
* There can be only one initial (starting) node
<uml redraw>
Begin.b;
drawObject(b);
</uml>


; Final nodes
; Final nodes
* A fat black dot inside a circle (bull's eye symbol)
* A fat black dot inside a circle (bull's eye symbol)
* A circle with an x represents the end of a flow (not the whole activity)
* A circle with an x represents the end of a flow (not the whole activity)
<uml redraw>
End.e;
FlowFinal.f;
leftToRight(20)(e,f);
drawObjects(e,f);
</uml>
Below is a complete example (copied June/2008 from the [http://metauml.sourceforge.net/activity-diagram.html MetaUML website]):
User eats until he has had enough. Then he both reads a book and listens to
some music, until he stops.
<uml>
Begin.b;
Activity.eat("Eat something good", "from the kitchen");
Branch.enough;
Fork.fork("h", 50);
Activity.read("Read a book");
Activity.listen("Listen to music", "(and ignore it)");
Fork.join("h", 50);
End.e;
leftToRight.top(10)(read, listen);
Group.readListen(read, listen);
leftToRight(30)(b, eat);
topToBottom(20)(eat, enough, fork, readListen, join, e);
drawObjects(b, eat, enough, fork, readListen, join, e);
clink(transition)(b, eat);
clink(transition)(eat, enough);
link(transition)(pathStepX(enough.e, eat.e, 80));
clink(transition)(enough, fork);
clink(transition)(fork, read);
clink(transition)(fork, listen);
clink(transition)(read, join);
clink(transition)(listen, join);
clink(transition)(join, e);
item(iGuard)("still hungry")(obj.sw = enough.e + (20, 0));
item(iGuard)("had enough")(obj.nw = enough.s + (0, -4));
</uml>
=== Flows ===
Flows (or edges) describe connections between 2 actions. These edges can be drawn with '''arrows''' in various ways.
Usually in activity diagrams, actions are simply connected through an unlabelled arrow.
In addition, you also can include an object in the flow. These objects can carry data. Finally,
instead of objects one can use "pins".
The control flow is modeled in terms of '''tokens'''. The start node will create a token which then goes to next action. After the action executes, the token will go to the next action. When it encounters a fork, the fork will create a token for each of its outbound flows. The opposite happens for joins. It will produce an outbound token once all inbound tokens arrived.
; Simple flows
* Simple flows are represented by an arrow from an activity showing parameters with pins from a node to another
<uml>
Activity.A("Do A ...");
Activity.B("Do B ...");
leftToRight(20)(A,B);
drawObjects(A,B);
clink(transition)(A,B);
</uml>
; Simple flows with connectors
An arrow to a '''connector''' (a small circle with a letter) and then from a same connector to a activity node does the same job as a simple arrow. (not shown here)
; Flows with objects
* Activity node to object node to activity node (with arrows). Object nodes
<uml>
Activity.A("Write down impressions");
Class.obj("Blog entry")()();
Activity.B("Reflect on the written");
leftToRight(30)(A,obj,B);
drawObjects(A,obj,B);
clink(transition)(A,obj);
clink(transition)(obj,B);
</uml>
; Flows with pins
* These are similar to flows with objects. A pin represents data needed and data produced.
* The flow is represented by an arrow and a pin is a small rectangle added to an activity rounded rectangle (no picture here)
; Decision flows
* Outgoing arrows from decision nodes are usually labeled.


=== Signals ===
=== Signals ===
Line 64: Line 193:
; Output signal (send)
; Output signal (send)
* Represented by a convex polygon
* Represented by a convex polygon
=== Activity edges (links) ===
; Control edges
These edges can be drawn with '''arrows''' in various ways:
* Represented by an arrow from an activity node to another
* Represented by an arrow from an activity showing parameters with pins from a node to another
* An arrow to a '''connecto'''r (a small circle with a letter) and then from a same connector to a activity node
* Activity node to object node to activity node (with arrows)
; Object Flow edges
* Represented by an arrow


=== Partitions and subactivities ===
=== Partitions and subactivities ===


; Subactivities
; Subactivities
* Activities can be decomposed into subactivities
* Activities can be decomposed into subactivities. They can have input or output parameters.
* A rake in an action node signals a subactivity
* A rake in an action node signals a subactivity
* The subsidiary activity diagram has an input and an output parameter (object nodes)
* The subsidiary activity diagram has an input and an output parameter (object nodes)
Line 86: Line 203:
; Partititions
; Partititions
* An activity can be partitioned in a swimlanes
* An activity can be partitioned in a swimlanes
* Each represents a player (see examples below)
* Each swimlane (partition) typically represents a player or role (e.g. learner A, learner B, group A, teacher). See below for some examples


=== Partitions ===
== Typical patterns ==
 
Activity diagrams can be partioned according to roles (e.g. learner A, learner B, group A, teacher)


== Typical patterns ==
Inspired from [http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html Activity Diagram] and [http://www.omg.org/technology/documents/formal/uml.htm Unified Modeling Language (UML), version 2.1.2] specification.
Inspired from [http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html Activity Diagram] and [http://www.omg.org/technology/documents/formal/uml.htm Unified Modeling Language (UML), version 2.1.2] specification.


Line 158: Line 272:
* [http://www.jot.fm/issues/issue_2003_07/column3/ UML 2 Activity and Action Models] by Conrad Bock, U.S. National Institute of Standards and Technology
* [http://www.jot.fm/issues/issue_2003_07/column3/ UML 2 Activity and Action Models] by Conrad Bock, U.S. National Institute of Standards and Technology
* [http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html Activity Diagram], UML 2 Diagrams, Visual Paradigm Gallery.
* [http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html Activity Diagram], UML 2 Diagrams, Visual Paradigm Gallery.
* [http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_users_guide/activitydiagram.html Poseidon user guide - Activity diagram] (Gentleware)


; Standards
; Standards
* [http://www.omg.org/technology/documents/formal/uml.htm Unified Modeling Language (UML), version 2.1.2]. There are two specifications that comprise the UML 2.1.2 specification: Superstructure and Infrastructure. There are also two specifications that relate to the UML2 specification (Diagram Interchange and Object Constraint Language).
* [http://www.omg.org/technology/documents/formal/uml.htm Unified Modeling Language (UML), version 2.1.2]. There are two specifications that comprise the UML 2.1.2 specification: Superstructure and Infrastructure. There are also two specifications that relate to the UML2 specification (Diagram Interchange and Object Constraint Language).


== References ==
== References ==


Bock, Conrad (2003). "UML 2 Activity and Action Models", ''Journal of Object Technology'', vol. 2, no. 4, July-August 2003, pp. 43-53. http://www.jot.fm/issues/issue_2003_07/column3
* Bock, Conrad (2003). "UML 2 Activity and Action Models", ''Journal of Object Technology'', vol. 2, no. 4, July-August 2003, pp. 43-53. http://www.jot.fm/issues/issue_2003_07/column3


* Fowler, M. (2000). UML distilled (3rd ed.). Upper Saddle River, NJ: Addison-Wesley. ISBN 0321193687
* Fowler, M. (2000). UML distilled (3rd ed.). Upper Saddle River, NJ: Addison-Wesley. ISBN 0321193687
Line 174: Line 289:
[[Category: Educational modeling languages]]
[[Category: Educational modeling languages]]
[[Category: Design methodologies]]
[[Category: Design methodologies]]
[[Category: UML]]
[[Category: Workflow]]

Latest revision as of 17:45, 22 April 2016

Draft

SORRY this page is broken. Had to remove an uml extension for security reasons - Daniel K. Schneider (talk) 16:56, 21 August 2013 (CEST). Some day we could try PlanUML - Daniel K. Schneider (talk) 17:45, 22 April 2016 (CEST)


Definition

UML activity diagrams refer to software engineering method modeled with UML to describe work flows, business processes and other procedures.

UML activity diagrams are a kind of behavior diagram, i.e. is a kind of UML behavioral modeling. UML activity diagrams are somewhat similar UML state machine diagrams. Both are somewhat similar to Petri nets.

See also: UML, UML behavioral modeling, coUML (an extension for learning design), BPMN (a business process workflow notation language)


Introduction

Activity modeling means to describe sequencing and conditions of actions. Such descriptions commonly are control flow and object flow models.

Simple Activity diagrams consist of:

  • Initial node.
  • Activity final node.
  • Activities in between

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

“The starting point of the diagram is the initial node, and the activity final node is the ending. An activity diagram can have zero or more activity final nodes. In between activities are represented by rounded rectangles.” (Wikipedia, retrieved 11:08, 4 June 2008 (UTC).

Architecture of activity diagrams

Basic Nodes

According to Conrad Bock (2003), there there are three kinds of nodes in activity models:

  1. Action nodes operate on control and data values that they receive, and provide control and data to other actions.
  2. Control nodes route control and data tokens through the graph. These include constructs for choosing between alternative flows (decision points), for proceeding along multiple flows in parallel (forks), and so on.
  3. Object nodes hold data tokens temporarily as they wait to move through the graph. Below, the notation for some of the activity nodes to be discussed. Contrary to the names, control nodes coordinate both data flow and control flow in the graph, and object nodes can hold both objects and data
Action nodes

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

  • Represented by a rectangle with rounded corners (drawn in slightly different ways depending on the software used ...)
  • Action nodes should have a label
Object nodes
  • Represented by a rectangle with a label (i.e. UML class boxes)

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Decision and merge control node
  • Represented by a lozange

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Fork and join control node
  • Forks and joins are represented by a horizonal or vertical line (and incoming and outgoing flows)
  • One or more activities can fork.
  • One or more activities can join

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Initial node
  • Represented by a fat black dot
  • There can be only one initial (starting) node

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Final nodes
  • A fat black dot inside a circle (bull's eye symbol)
  • A circle with an x represents the end of a flow (not the whole activity)

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Below is a complete example (copied June/2008 from the MetaUML website):

User eats until he has had enough. Then he both reads a book and listens to some music, until he stops.

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Flows

Flows (or edges) describe connections between 2 actions. These edges can be drawn with arrows in various ways.

Usually in activity diagrams, actions are simply connected through an unlabelled arrow. In addition, you also can include an object in the flow. These objects can carry data. Finally, instead of objects one can use "pins".

The control flow is modeled in terms of tokens. The start node will create a token which then goes to next action. After the action executes, the token will go to the next action. When it encounters a fork, the fork will create a token for each of its outbound flows. The opposite happens for joins. It will produce an outbound token once all inbound tokens arrived.

Simple flows
  • Simple flows are represented by an arrow from an activity showing parameters with pins from a node to another

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Simple flows with connectors

An arrow to a connector (a small circle with a letter) and then from a same connector to a activity node does the same job as a simple arrow. (not shown here)

Flows with objects
  • Activity node to object node to activity node (with arrows). Object nodes

Diagrams error (with plantuml command): /bin/bash: plantuml: command not found

Flows with pins
  • These are similar to flows with objects. A pin represents data needed and data produced.
  • The flow is represented by an arrow and a pin is a small rectangle added to an activity rounded rectangle (no picture here)
Decision flows
  • Outgoing arrows from decision nodes are usually labeled.

Signals

Actions in a diagram also can respond to signals (instead of the flow)

Time signals
  • Represented like an hour glass
Input Accept signal (accept)
  • Represented by a concave pentagon (a smashed-in rectangle)
Output signal (send)
  • Represented by a convex polygon

Partitions and subactivities

Subactivities
  • Activities can be decomposed into subactivities. They can have input or output parameters.
  • A rake in an action node signals a subactivity
  • The subsidiary activity diagram has an input and an output parameter (object nodes)
Partititions
  • An activity can be partitioned in a swimlanes
  • Each swimlane (partition) typically represents a player or role (e.g. learner A, learner B, group A, teacher). See below for some examples

Typical patterns

Inspired from Activity Diagram and Unified Modeling Language (UML), version 2.1.2 specification.

(stub section, needs to be completed).

Accept Event Action
  • An action that waits for the occurrence of an event meeting specified conditions
Activity Final
Data Store
Decision Node
Flow Final
Fork Node
InitialNode
Join Node
Merge Node
Object Node
Send Signal Action
Object Flow

Examples

A simple example

The following example taken from D7.2 UNFOLD outcomes 2 contains the following elements:

  • A start node
  • An end node
  • Two join/break (the fat lines)
  • Three activities
UML activity diagram example

Educational examples

Activity diagrams can be used to describe learning designs of CSCL scenarios. A good example are collaborative learning flow pattern (Hernández-Leo et al., 2005b).

Below some more pictures that show that activity diagrams are popular withing the IMS Learning Design community.

The next example shows a diagram for competency-based learning with two major alternatives, advising-then-anticipating and anticipating-then-advising. (IMS LD Best Practice specification)

Activity Diagram for Competency-based learning. Source: IMS

The following example taken from the IMS LD Best Practice specification shows a diagram for problem-based learning

Activity Diagram for Problem Based Learning. Source: IMS

Links

Summaries of UML activity diagrams
Introductions to activity diagrams
Standards
  • Unified Modeling Language (UML), version 2.1.2. There are two specifications that comprise the UML 2.1.2 specification: Superstructure and Infrastructure. There are also two specifications that relate to the UML2 specification (Diagram Interchange and Object Constraint Language).

References

  • Fowler, M. (2000). UML distilled (3rd ed.). Upper Saddle River, NJ: Addison-Wesley. ISBN 0321193687
  • Hernández-Leo, D., Asensio-Pérez, J.I., Dimitriadis, Y., Bote-Lorenzo, M.L., Jorrín-Abellán, I.M., Villasclaras-Fernández, E.D. (2005b). Reusing IMS-LD Formalized Best Practices in Collaborative Learning Structuring. Advanced Technology for Learning 2(4):223-232. http://dx.doi.org/10.2316/Journal.208.2005.4.208-0865 - PDF
  • IMS Global Learning consortium (2003). IMS Learning Design Best Practice and Implementation Guide, HTML, retrieved 11:08, 4 June 2008 (UTC).