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.

Actors

• 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}.

 

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.

• 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.
  • 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.

• Message Branching: It shows a conditional statement execution.

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.

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.

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.

 

Component Diagrams

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

• 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

 

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.