In a UML model, the static representation of the system is a set of CDs. Each class may have an associated Activity Diagram (ACD) to show the internal behaviour and/or algorithm for the class. The class ACD shows one or more parallel sequences of possible behaviour, distributed along a timeline, which in turn may have branches and optional synchronisation.
As a Cradle modelling domain (the Essential or Implementation Domains) can contain any number of UML models, there may be several sets of CDs, each of whose classes may have an ACD.
ACDs can also be drawn at any level in the UML model, to represent time sequenced behaviour at any level. The activities in the ACDs are intrinsically shareable, such that any given activity can appear on more than one ACD. Also, the activities shown in ACDs can also be shown in Physical Architecture Diagrams (PADs) as shared equipments and on extended Function Flow Block Diagrams (eFFBDs) / Behaviour Diagrams (BDs) as shared functions. This allows the UML and non-UML models in a domain to be linked.
The ACD can show the sending and receipt of messages, which are the means by which classes communicate, by calling each others’ operations, as shown on the associated CD.
An ACD depicts a set of component activities that are required to accomplish the behaviour of a class. The ACD shows these component activities along a vertical timeline, which may be split into branches and associated synchronisation points to show concurrency. In this sense, the ACD provides some of the semantic capabilities of the eFFBD available in the non-OO notations.
ACDs contain a time-sequenced representation of the functionality of a class, and correlate with the class’s associated Statechart.
ACDs are hierarchical. Their connectivity is:
ACDs are available in models in both the Essential and Implementation Domains.
Shared equipment symbols in PADs and AIDs can appear as an activity in a UML Activity Diagram (ACD) and as a shared function in an extended Function Flow Block Diagram (eFFBD).
This allows representations of the same piece of behaviour, in UML and non-UML contexts.
ACDs are numbered the same as the class to which they refer.
For ACDs not showing the behaviour within a class, any form of identifying number can be used. Where hierarchies are created, the levels are connected with the dot-decimal convention.
An example ACD is:
The symbols available in ACDs are:
Symbol | Name | Description | Definition | Expansion |
---|---|---|---|---|
Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None | |
Initial State | A condition at the beginning of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. | None | None | |
Final State | A condition at the end of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. | None | None | |
Activity | A component part of the behaviour of a class or a general piece of behaviour at any level in the model/system. | Activity specification | None | |
Decision Activity | An activity that selects between transitions on the basis of guard conditions. | None | None | |
Synchronisation Bar | A synchronisation point for activities. | None | None | |
Send Signal | Sending a message to an instance of another class, calling an operation of another class. | None | None | |
Receive Signal | Receiving a message from another class, a call of one of this class’s operations by another class. | None | None | |
Picture | Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. | None | None | |
Activity Trigger | A transition that links activities. | Flow data definition | None | |
Item | Represents a requirement or system note in the diagram. | None | None | |
Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None | |
Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |