8.4.

Examining Other UML Diagrams

Class diagram
Class diagrams are the most popular UML diagrams used for the implementation of software
application. It is very important to learn the how to draw the class diagram.
It is basically a graphical representation of the static view of the system and represents different
aspects of the system. So a collection of class diagrams represent the complete system.
Following figure represents the class diagram. It is divided into four compartments.
I.The top section represents the name the class.
II.The second one show the attributes of the class.
III.The third section describe the operations performed by the class.
IV.The fourth section is optional and it is used to show the extra components

Object Notation:
Object is represented in the same way as the class. The only difference is the name which is
underlined as shown in the figure given below.
An object is the actual implementation of a class .It is also known as the instance of a class.

The following points should be considered while drawing a class diagram:

i.The name of the class should be meaningful.
ii.Each element and their relationships needs to be identified in advance.
iii.Attributes and methods of each class needs to be clearly identified.
iv.Unnecessary properties will make the class diagram complicated,So for each class minimum
number of properties should be specified.
v.Use notes wherever required to describe the aspect of the diagram. Because the class diagram
it should be understandable to the developer.
vi.The diagram needs to be drawn on plain paper and rework as many times as possible to make
it correct before making the final version.
The following figure represents the class diagram of an Order System . The class diagram has
been drawn considering all the points mentioned above:

Where to use Class Diagrams?

Describing the static view of the system.

To show the collaboration among the elements of the static view.
Describing the functionality performed by the system.
Development of software applications using object oriented languages.

Sequence Diagram
It is used to model the life line of an object, the activation and the message passing. Sequence
diagrams are two-dimensional diagrams: one dimension (usually the vertical) is used to display
evolution through time, the other to distinguish between different objects. An object is a vertical
line with a thick bar on the line which indicates the life line of an object. Message passing is
modeled by arrows pointing from one object to the next at a certain state transition on the life lines
of both objects. When message passing is instantaneous, the arrows are horizontal.
As mentioned the aim of a sequence diagram is to define event sequences, which would have a
desired outcome. The focus is more on the order in which messages occur than the message.
However, the majority of sequence diagrams will communicate what messages are sent and the
order in which they tend to occur.
Lifelines

When drawing a sequence diagram, remember that lifeline notation elements are placed across
the top of the diagram. Lifelines are representative of roles or object instances that take part in the
sequence being modeled. From a visual perspective, lifelines are shown as a box with a dashed
line descending from the center of the bottom edge. Name of the lifeline is placed inside the box.
Additionally, the lifeline name is underlined. What this means is that the lifeline represents a
specific instance of a class in a sequence diagram.

Message
For the sake of readability, the first message of a sequence diagram always starts at the top and
is located on the left side of the diagram. Subsequent messages are then added to the diagram.
To show an object or lifeline sending a message to another object, you draw a line to the receiving
object with a solid arrowhead (if a synchronous call ) or with a stick arrowhead (if an asynchronous
call). The method /message name is placed above the arrowed line. The message sent to the
receiving object represents an method/operation that the receiving object?s class implements.

Example : Make a call

Below sequence diagram describes the process of making a phone call. The objects involved are
caller, phoneNetwork, the person who is called and an accounting system. Various messages are
passed between the objects.

Activity Diagram
Activity diagrams are related to program flow plans, are used to illustrate activities. It is used for
the description of business processes that describe the functionality of the business system.
In activity diagrams actors can perform use cases together or independently from one another.

It allow us to think functionally. It is possible to explicitly describe parallel events, the activity
diagram is suitable for the illustration of business processes, since business processes rarely occur
in a linear manner and often exhibit parallelisms.
Activity diagrams can be developed in various degrees of detail and can be refined step by step.
In the external view, activity diagrams exclusively represent business processes and activities from
the outside perspective. Refining the activity diagrams does not mean describing process details
that are performed within the business system, which often leads to an unnoticed shift to the
internal view.
Activity
An activity diagram illustrates/represents one individual activity. In our context, an activity
represents a business process Fundamental elements of the activity are actions and control
elements (decision, division, merge, initiation, end,etc).

Elements are connected by activity edges to form the control flow, which can also be called as flow
. The execution of an activity may contain parallel flows. A border can surround an activity(entire
activity diagram).
Action
An action is defined as an individual step within an activity.For example, a calculation step that is
not possible to break down any further. It does not mean that the action cannot be subivided , but
in this diagram will not be refined further.

An action can contain input and output information The output of one action can be the input of a
subsequent action within an activity. Specific actions are sending signals,calling other actions and
receiving an event.
Calling an Activity(Action)
With the following symbol an activity can be called from within another activity. Calling in itself is
an action, the outcome of the call is an another activity. Activities can be nested within each other
and can be represented with different levels of details.

Accepting a Time Event(Action)

At a particular point in time, this action starts a flow in the activity diagram.A hourglass symbol is
used to represent the acceptance of a time event.

An example of a time event is triggering reminders after the deadline for payment has passed.
Sending Signals(Action)
It means that a signal is being sent to an accepting activity.

The accepting activity accepts the signal with the corresponding action ' accepting an event ' and
can react accordingly(according to the flow that originates from this node in the activity diagram).
Edge (Control Flow)
Edge is represented by arrows. It connects the individual components of activity diagrams and
illustrate the control flow of an activity.
Within the control flow an incoming arrow starts a single step of an activity, once that step is
completed the flow continues along the outgoing arrow. A name is attached to an edge.

Decision Node
The diamond represents a decision node or a conditional branch point. It has only one input and
two or more outputs.

Each output has a condition attached to it, which can be represented/ written in brackets. If a
condition is met, the flow proceeds along with the appropriate output. An else output can also be
defined.
Merge Node
Merge node has several inputs and only one output. It is used for merging of flows. It is represented
by the diamond given below.

Fork
A fork has only one input and two or more outputs. For the branching of flows in two or more
parallel flows we use a synchronization bar, which is represented as a vertical line or thick
horizontal. Branching allows parallel flows within an activity.

Join
For the consolidation of two or more parallel flows we can use a synchronization bar, which is
represented as a thick vertical or horizontal line. It takes two or more inputs and gives only one
output.

Initial Node
Initial node is the starting point of any activity. An activity can contain more than one initial node,
in this case several flows will start at the beginning of an activity. It is also possible that an activity
has no initial node, but can be initiated by an event .

Activity Final Node

It indicates that an activity is completed. Activity diagram can contain more than one exit in the
form of activity final nodes.

If several parallel flows are present within an activity, all flows are stopped at the time the final
node is reached.
Flow Final Node
It terminates a flow. It is represented as below. Reaching a flow final node has no effect on other
parallel flows that are processed within the activity at the same point in time.

Activity Partition
The individual elements of an activity diagram can be divided into 'partitions' or individual areas.
Various criteria can lead to the creation of these partitions organization entities, locations ,cost
centers, etc.

Individual steps of an activity would be assigned to these partitions. Each partition is set apart from
its neighboring partition by a or vertical horizontal continuous line, from this stems the term swim
lanes. Each partition receives a name. Partitions can be arranged in a two dimensional manner, in
the above diagram the activity diagram is divided into individual cells like a grid.
Example : Passenger Check-in
In the following figure, we can start reading at the initial node or with the acceptance of the event
passenger arrive sat check-in (1), and continue along the arrows of the control flow (2).
The third action Passenger Checks In(3) means that at this point the activity passenger check in
is processed.

If we follow the control flow, next we will come to a decision node or conditional branch (4), if the
check-in is OK then the next step along the control flow can continue. Otherwise (5), the passenger
cannot fly and the passenger task service is completed. This is represented by a the black dot with
border(the activity final node).
After successful check-in (7) we come to a black cross bar. All arrows that come from this black
bar (7) symbolize flows that are processed simultaneously( the luggage is being loaded onto the
airplane (9) and the passenger is boarding the airplane (10) ).
Between point (8) and point (11) the flows are independent from each other. Simultaneously
processed Flows (9 and 10) are merged at the second cross bar (11). It means that only when the
passenger is on the plane (10) and the luggage has been loaded onto the plane (9), then the
control flow continue below the cross bar (11).
In this example, one more action (12) and subsequent to that the final state (13) follow, meaning
that after the passenger is on the plane (10) and the luggage has been loaded onto the plane (9),
the airplane can taxi towards the runway (12).

We can see here that the last action airplane taxis toward runway (12) is only defined as a single
action, even though this process is very complex and could be described in many other activity
diagrams.
Following figure illustrates the activity diagram with partitions .

The above diagram is divided into two partitions passenger (1) and passenger services (2). The
passenger carries out showing ticket at Check-In counter (3), checking luggage (4) and paying
fee (5). All other actions of passenger services (2) and are carried out by passenger services.
Please refer the below link for further information about UML Diagrams
http://sourcemaking.com/uml/introduction
http://www.cragsystems.co.uk/uml_tutorial/