UML2 Quick Reference - dice-project/DICE-Simulation GitHub Wiki

The Unified Modeling Language (UML) is a standard which provides a language to describe different systems. UML is a domain-independent language, although its origins are in the object-oriented modeling. A UML model consists of elements such as packages, classes, and associations. The corresponding UML diagrams are graphical representations of parts of the UML model. These diagrams contain graphical elements (nodes connected by paths) that represent elements in the UML model.

UML modeling can be generally divided into two semantic categories: behavioral modeling and structural modeling. In addition to these main categories, there are some supplemental modeling constructs that have both behavioral and structural aspects (e.g., deployment diagrams, use cases) which may complement behavioral and/or structural models. This section will focus in the former category, i.e., behavioral modeling.

Specifically, we describe below the interesting parts of the activity diagrams and sequence diagrams specification which are of interest from the point of view of the DICE Simulation Tool.

Activity Diagrams

An Activity, as specified in the UML standard, is a kind of Behavior that is specified as a graph of nodes interconnected by edges. A subset of the nodes are executable nodes that embody lower-level steps in the overall Activity. Object nodes hold data that is input to and output from executable nodes, and moves across object flow edges. Control nodes specify sequencing of executable nodes via control flow edges. Activities are essentially what are commonly called control and data flow models.

The following figure shows the main concepts (i.e., metaclases) used to create activity diagrams together with their relationships.

The most relevant elements from the transformation to analysis models point of view are:

  • UML::Packages::Model — A Model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose.

  • UML::Activities::Activity — An Activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units (ActivityNodes).

  • UML::Activities::ActivityNode (abstract) — ActivityNode is an abstract class for points in the flow of an Activity connected by ActivityEdges.

  • UML::Activities::ActivityEdge (abstract) — An ActivityEdge is an abstract class for directed connections (i.e., with source [1..1] and target [1..1]) between two ActivityNodes.

  • UML::Activities::ControlFlow — A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are used to control the execution of ExecutableNodes.

  • UML::Activities::ControlNode (abstract) — A ControlNode is an abstract ActivityNode that coordinates flows in an Activity.

  • UML::Activities::InitialNode — An InitialNode is a ControlNode that offers a single control token when initially enabled.

  • UML::Activities::FinalNode (abstract) — A FinalNode is an abstract ControlNode at which a flow in an Activity stops.

  • UML::Activities::ActivityFinalNode — An ActivityFinalNode is a FinalNode that terminates the execution of its owning Activity.

  • UML::Activities::ForkNode — A ForkNode is a ControlNode that splits a flow into multiple concurrent flows.

  • UML::Activities::JoinNode — A JoinNode is a ControlNode that synchronizes multiple flows.

  • UML::Activities::DecisionNode — DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens.

  • UML::Activities::MergeNode — A MergeNode is a ControlNode that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.

  • UML::Actions::Action (abstract) — An Action is the fundamental unit of executable functionality. The execution of an Action represents some transformation or processing in the modeled system. Actions provide the ExecutableNodes within Activities and may also be used within Interactions.

  • UML::Actions::OpaqueAction — An OpaqueAction is an Action whose functionality is not specified within UML.

The figure below shows an example activity diagram using the standard notation. It is composed by an InitialNode (Start), an ActivityFinalNode (End), three OpaqueActions (A1, A2 and A3), a DecisionNode (D) and a MergeNode (M).

Sequence Diagrams

Interactions are presented in the UML standard as a mechanism to get a better grip of an interaction situation for an individual designer or for a group that needs to achieve a common understanding of the situation. Interactions are also used during the more detailed design phase where the precise inter-process communication must be set up according to formal protocols. The most visible aspects of an Interaction are the messages between lifelines. The sequence of the messages is considered important for the understanding of the situation. The data that the messages convey and the lifelines store may also be very important, but the Interactions do not focus on the manipulation of data even though data can be used to decorate the diagrams.

The figure below shows the UML metaclases that may be used to create activity diagrams.

The most relevant elements from the transformation to analysis models point of view are:

  • UML::Packages::Model — As aforementioned a Model captures a view of a system with a certain purpose.

  • UML::Interactions::Interaction — Interactions are units of behavior, and focus on the passing of information with Messages between the ConnectableElements. Interactions are the top-level elements of a UML sequence diagram.

  • UML::Interaction::Lifeline — A Lifeline represents an individual participant in the Interaction. Lifelines represent only one interacting entity (via the represents association to ConnectableElement).

  • UML::Interactions::InteractionFragment (abstract) — InteractionFragment is an abstract notion of the most general interaction unit. An InteractionFragment is a piece of an Interaction. Each InteractionFragment is conceptually like an Interaction by itself. InteractionFragments are the main constituent parts of an Interaction. An InteractionFragment may either be contained directly in an enclosing Interaction, or may be contained within an InteractionOperand of a CombinedFragment. As a CombinedFragment is itself an InteractionFragment, there may be multiple nesting levels of InteractionFragments within an Interaction.

  • UML::Interactions::CombinedFragment — The semantics of a CombinedFragment is dependent upon the contained InteractionOperand. Typical operators are alt (for alternative behaviors), opt (for optional behaviors) or par (for parallel execution paths).

  • UML::Interactions::InteractionOperan — As previously introduced, an InteractionOperand is a region within a CombinedFragment.

  • UML::Interactions::ExecutionSpecification (abstract) — An ExecutionSpecification is a specification of the execution of a unit of Behavior or Action within the Lifeline. The duration of an ExecutionSpecification is represented by two OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.

  • UML::Interactions::BehaviorExecutionSpecification — An ExecutionSpecification linked to a Behavior.

  • UML::Interactions::ActionExecutionSpecification — An ExecutionSpecification linked to an Action.

  • UML::Interactions::OccurrenceSpecification — An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions.

  • UML::Interactions::ExecutionOccurrenceSpecification — An ExecutionOccurrenceSpecification represents moments in time at which Actions or Behaviors start or finish.

  • UML::Interactions::MessageOccurrenceSpecification — A MessageOccurrenceSpecification specifies the occurrence of Message events. A MessageOccurrenceSpecification is a kind of MessageEnd. Messages are generated either by synchronous Operation calls or asynchronous Signal sends.

  • UML::Interactions::MessageEnd — MessageEnd is an abstract specialization of NamedElement that represents what can occur at the end of a Message.

  • UML::Interactions::Message — A Message is simply the trace between a message send event and a receive event.

The figure below shows an example sequence diagram using the standard notation. It describes the interaction of a user with a two tier application. The figure contains three Lifelines represented by dotted lines: one for user (which is an instance of the User classifier), a second one for ui (which represents and instance of UI) and a third one for backend (which is an instance of the Backend classifier). The three white boxes drawn on top the lifelines represent ExecutionSpecifications (either ActionExecutionSpecifications or BehaviorExecutionSpecifications). The arrow labeled with displayReport(id) represents a message from user to ui requesting the operation displayReport defined by the UI classifier. The operation takes as an argument the id value. Similarly, the arrow labeled with getReport represents a message from ui to backend. Finally, the dashed arrows labeled with report, represent the reply messages from the backend to the ui, and from the ui to the user.