Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams
can be used to describe the business and operational step-by-step workflows of components in a
system. An activity diagram shows the overall flow of control.

Construction
Activity diagrams are constructed from a limited repertoire of shapes, connected with arrows.
The most important shape types:

 rounded rectangles represent activities;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial state) of the workflow;
 an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the order in which activities happen.
Class Diagram
In software engineering, a class diagram in the Unified Modelling Language (UML) is a
type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the classes.

The class diagram is the main building block in object oriented modelling. They are being
used both for general conceptual modelling of the systematics of the application, and for
detailed modelling translating the models into programming code. The classes in a class
diagram represent both the main objects and or interactions in the application and the objects
to be programmed. In the class diagram these classes are represented with boxes which
contain three parts.

A class with three sections.

 The upper part holds the name of the class

 The middle part contains the attributes of the class, and
 The bottom part gives the methods or operations the class can take or undertake

In the conceptual design of a system a number of classes are identified and grouped together
in a class diagram, which helps to determine the statical relations between those objects. With
detailed modeling the classes of the conceptual design are often split in a number of
subclasses.

In order to further describe the behavior of systems these class diagrams can be
complemented by state diagram or UML state machine.

Visibility

To specify the visibility of a class member (i.e., any attribute or method) there are the
following notations that must be placed before the member's name.[2]:

+ public visible to all elements that can access the contents of the namespace that owns it.

# protected visible to elements that have a generalization relationship to the namespace that owns it.

– private only visible inside the namespace that owns it.

owned by a namespace that is not a package, and is visible to elements that are in the
same package as its owning namespace. Only named elements that are not owned by
packages can be marked as having package visibility. Any element marked as having
~ package
package visibility is visible to all elements within the nearest enclosing package (given
that other owning elements have proper visibility). Outside the nearest enclosing package,
an element marked as having package visibility is not visible.
State Machine Diagram
UML state machine, known also as UML statechart, is an object-based variant of Harel
state chart adapted and extended by the Unified Modeling Language . UML state machines
overcome the main the limitations of traditional finite state machines while retaining their
main benefits. UML statecharts introduce the new concepts of hierarchically nested states and
orthogonal regions, while extending the notion of actions. UML state machines have the
characteristics of both Mealy machines and Moore machines. They support actions that
depend on both the state of the system and the triggering event, as in Mealy machines, as well
as entry and exit actions, which are associated with states rather than transitions, as in Moore
machines.

The term "UML state machine" can refer to two kinds of state machines: behavioral state
machines and protocol state machines. Behavioral state machines can be used to model the
behavior of individual entities (e.g., class instances). Protocol state machines are used to
express usage protocols and can be used to specify the legal usage scenarios of classifiers,
interfaces, and ports.
Component Diagram
A component diagram in the Unified Modeling Language, depicts how components are
wired together to form larger components and or software systems.

Overview
Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component. This illustrates
the service consumer - service provider relationship between the two components.

An assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector is
a connector that is defined from a required interface or port to a provided interface or port."

When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to the
corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as
specified by its ports) to the internal realization of that behavior by the component’s parts."

Components diagrams can be used to illustrate the structure of arbitrarily complex systems.
The example above illustrates what a typical Insurance policy administration system might
look like. It is possible to envisage that each of the components depicted in the above
diagram will, in turn, have other component diagrams illustrating their internal structure.
Deployment Diagram
A deployment diagram in the Unified Modeling Language serves to model the physical
deployment of artifacts on deployment targets.

Deployment diagrams show "the allocation of Artifacts to Nodes according to the

Deployments defined between them."

Deployment of an artifact to a node is indicated by placing the artifact inside the node.

Instances of nodes (and devices and execution environments) are used in deployment
diagrams to indicate multiplicity of these nodes. For example, multiple instances of an
application server execution environment may be deployed inside a single device node to
represent application server clustering.
Sequence Diagram
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart.

Sequence diagrams are sometimes called Event-trace diagrams, event scenarios, and timing
diagrams.

Overview
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.

For instance, the UML 1.x diagram on the right describes the sequences of messages of a
(simple) restaurant system. This diagram represents a Patron ordering food and wine,
drinking wine then eating the food, and finally paying for the food. The dotted lines
extending downwards indicate the timeline. Time flows from top to bottom. The arrows
represent messages (stimuli) from an actor or object to other objects. For example, the Patron
sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.

The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence
Diagram with added support for modeling variations to the standard flow of events.
Use Case Diagram
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the
functionality provided by a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for which
actor. Roles of the actors in the system can be depicted.

The use case diagram shows the position or context of the use case among other use cases. As an
organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system
behavior, a common understanding between the customer/owner/user and the development team.

Diagram building blocks

Actor Generalization

One popular relationship between Actors is Generalization/Specialization. This is useful in defining

overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from
the specialized to the more general actor.

Use Case Relationships

Three relationships among use cases are used often in practice.

Include

In one form of interaction, a given use case may include another. "Include is a Directed Relationship
between two use cases, implying that the behavior of the included use case is inserted into the
behavior of the including use case".

The first use case often depends on the outcome of the included use case. This is useful for extracting
truly common behaviors from multiple use cases into a single description. The notation is a dashed
arrow from the including to the included use case, with the label "«include»".

Extend

In another form of interaction, a given use case (the extension) may extend another. This relationship
indicates that the behavior of the extension use case may be inserted in the extended use case under
some conditions. The notation is a dashed arrow from the extension to the extended use case, with the
label "«extend»".

Generalization

In the third form of relationship among use cases, a generalization/specialization relationship exists.
A given use case may have common behaviors, constraints and assumptions to the general use case,
describe them once, and deal with it in the same way, except for the details in the specialised cases.
The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general
use case.
Timing diagram
A timing diagram in the Unified Modeling Language 2.0 is a specific type of interaction
diagram, where the focus is on timing constraints.

Timing diagrams are used to explore the behaviors of objects throughout a given period of
time. A timing diagram is a special form of a sequence diagram. The differences between
timing diagram and sequence diagram are the axes are reversed so that the time is increased
from left to right and the lifelines are shown in separate compartments arranged vertically.

There are two basic flavors of timing diagram: the concise notation, and the robust notation.
Object diagram
An object diagram in the Unified Modeling Language (UML), is a diagram that shows a
complete or partial view of the structure of a modeled system at a specific time.

An Object diagram focuses on some particular set of object instances and attributes, and the
links between the instances. A correlated set of object diagrams provides insight into how an
arbitrary view of a system is expected to evolve over time. Object diagrams are more
concrete than class diagrams, and are often used to provide examples, or act as test cases for
the class diagrams. Only those aspects of a model that are of current interest need be shown
on an object diagram.

Instance Specification

Each object and link on an object diagram is represented by an InstanceSpecification. This

can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well
as attributes and other structural features using slots. Each slot corresponds to a single
attribute or feature, and may include a value for that entity.

The name on an instance specification optionally shows an instance name, a ':' separator, and
optionally one or more classifier names separated by commas. The contents of slots, if any,
are included below the names, in a separate attribute compartment. A link is shown as a solid
line, and represents an instance of an association.