A brief introduction to UML

Unified Modeling Language (UML) is a standardized modeling language enabling developers to specify, visualize, construct and document artifacts of a software system. Thus, UML makes these artifacts scalable, secure and robust in execution. UML is an important aspect involved in object-oriented software development. It uses graphic notation to create visual models of software systems.

Some of the important components of UML are:

Use Case Diagrams

  • One of the most important, compulsory diagrams.
  • It will answer “What will the system will do?” not concern about how and where.
  • Used in the requirement phase of the SDLC.


  • Who of the system/end user of the system.
  • Two types of actors Primary and Secondary.
  • Primary: actively participants and they initiate the use case.
  • Secondary: passively participate in the use case.

Use Case: They represent action, represented by strong verbs.

Use Case Table: Represent the details of Use Case diagram in textual format. The basic content is as follows:

  • Use Case ID
  • Use Case Name
  • Description
  • Primary Actors
  • Trigger
  • Pre-condition
  • Assumption
  • Failed End conditions / action on them
  • Main Scenarios / action on them
  • Alternate Scenario / Action on them
  • Success Scenarios
  • Note and Open Issues

Use Case Relationship: There are two types of relationships Extend and Include.
Include: represent invocation of one use case by the other. (Like one function called by other function). Has-a relationship. Depicted by a dotted arrow.
Extend: extend existing use case. Work same as the base use case only that some new functionality will be inserted in the extended use case. Parent-child, Is-a relationship. Depicted by a solid arrow with Solid filled triangle arrow.

Class Diagrams

  • A prototype which helps us creates objects.
  • They define static part of the project, blueprint.
  • Three Sections:
    • Class Name
    • Properties/ Attributes
    • Methods
  • + indicates Public
  • # indicates protected
  • – indicates private.
  • Multiplicity
    • 0…* è zero or many instances
    • 1…* è at least one or more instances
  • Aggregation, check below notes for definition. The whole object can exist without the aggregated object. Depicted by an empty diamond arrow.
  • Composition, check below notes for definition. The Whole object does not exist without the aggregated object. Depicted by a dark Diamond Arrow.
  • Generalization and Specialization, Parent-Child relationship. The arrow points from Specialization to Generalization (i.e. from child to Parent).
  • Interface, represented as <interface name>. The attribute part is blank as the interface does not contain as attributes of its own.
  • Abstract Class, represented by class name {abstract}.

Class Diagram


Object Diagram

  • Objects are created from Classes, they contain live data.
  • They give a pictorial representation of class diagram at any point of time.
  • They should be only drawn to represent complicated relationship bet objects.


Sequence Diagram

  • They show interaction bet objects over a specific time period.
  • The message flow is shown vertically in waterfall manner i.e. starts from the top and flows to the bottom.

UML (A brief introduction)

  • Requests are shown with dark arrows and return requests are shown in dotted arrows.
  • Vertical rectangle shows the lifetime of the object.
  • There can be different kinds of messages in a Sequence diagram.
    • Synchronous message: are those messages where caller waits for the response. Represented by a dark arrow with bold dark head.UML (A brief introduction)
    • Asynchronous message: are those messages where the caller does not wait for the response. And does something else and return back when receives Represented by a dark arrow with a thin dark head.
    • Recursive Messages: object/Function calling itself like factorial.


  • Message Constraints: Represent the condition while executing the message. Shown by [] braces.

UML (A brief introduction)

  • Message Branching: It shows a conditional statement execution.

UML (A brief introduction)

Collaboration Diagram

  • They show the same information as Sequence diagram, but in a different way.
  • Sequence diagram we pay more attention to Time and sequence.
  • Collaboration diagram we pay more attention on the interaction of messages bet the objects.
  • Objects are represented by rectangles.
  • Messages are represented by an arrow and sequence number.
  • Conditional statements are denoted by [] brackets.

UML (A brief introduction)

For Each Collaboration: is represented by the () brackets.



Activity Diagram

  • Are used to capture complicated process flows in a system.
  • Used especially to explain complex pseudo code.
  • Start of an activity diagram is by a dark circle.
  • End of activity is denoted by a dark circle inside a white circle.
  • Activities are represented by ovals.
  • Decision making by diamond shapes.
  • Decision in side [] brackets.
  • Parallel Processing is indicated by dark solid lines.
  • Swimlanes are used to indicate the responsibility using partition as shown below.

UML (A brief introduction)

State Chart Diagram

  • They are rarely used diagram. They depict how an object responds to events.
  • If the project has scenarios where the object goes through a lot of complicated states and transitions then these diagrams should be used.
  • If we do not have such scenarios then Sequence, collaboration or activity would be enough.
  • There are 3 main things in State Chart Diagram:
    • Action: triggers an object state from one state to another.
    • Events: triggers the action.
    • Guard: is condition on which it evaluates which action to be triggered.


  • Start of diagram is by a dark circle.
  • End is denoted by a dark circle inside a white circle.
  • States are represented by ovals.
  • Events are left of “/” and actions are written on right hand side.

UML (A brief introduction)



Component Diagrams

  • Somewhat same as package diagram.
  • Package diagram shows logical grouping while component dig shows interactions.

UML (A brief introduction)

  • Components are represented by Rectangles.
  • Stereo types <> are used to represent the name of component.


Deployment Diagram

  • They show a static view how software and hardware in the application.
  • They show what components are installed on the hardware.
  • Hardware is shown with the solid box.


  • We can have more than 1 component on a single hardware.


Stereo Type

  • Are not diagrams, but way to define variations on existing UML diagrams.
  • Can be used with any diagram using “<>” signs.


UML Flow

UML (A brief introduction)


What are must have diagrams

Any standard technical document at least should have following diagrams,

  • Use case Diagram
  • Sequence Diagram
  • Class Diagram
  • Deployment Diagram
  • Component Diagram

these diagrams will make the document more relevant and helpful to the technical teams in immediate or long term.

Leave a Comment