what does this symbol mean?

UML diagram symbols

The notation of UML class, use case, sequence and activity diagrams: the boxes, arrows and relationships, and what each one means.

Test yourself: UML diagram symbols quiz

Class diagrams 8 symbols

Use case and sequence diagrams 4 symbols

Activity and state diagrams 4 symbols

About uML diagram symbols

UML, the Unified Modeling Language, is a standard set of diagrams for describing software: the parts a system is made of and how it behaves. It is published by the Object Management Group (OMG), a not-for-profit standards consortium; the current version, UML 2.5.1, dates from December 2017. A UML diagram is a picture of part of a model, drawn as shapes joined by lines: two classes linked by an association appear as two class boxes with a line between them. The symbols here are those of four of its diagrams: class, use case, sequence and activity diagrams. Each symbol has its own page.

The diagram types

UML 2.5.1 sorts its diagrams into two kinds. Structure diagrams show the static structure of a system, the parts of it that don't depend on time. Behaviour diagrams show its dynamic behaviour, the changes in it over time. The specification lists fourteen diagrams: activity, class, communication, component, composite structure, deployment, interaction overview, object, package, profile, state machine, sequence, timing and use case diagrams. OMG's own introduction to UML, written for UML 2.0 in 2005, counted thirteen, with no profile diagram, and split the behaviour diagrams further: the sequence, communication, timing and interaction overview diagrams are its four interaction diagrams. The specification adds that the boundaries between the kinds are not strictly enforced, and one diagram can mix them.

What a class diagram is

A class diagram is one whose main symbols are Class boxes. It shows the classes in a piece of software and the relationships between them: Association, Aggregation, Composition, Generalization (inheritance), Realization and Dependency, with a Multiplicity at the ends of a line to say how many objects take part. It is a static view: the University of Washington's software engineering course describes it as showing what interacts, but not what happens when it does.

What a use case diagram is

A use case diagram shows the kinds of users a system has and what they use it for. Its actors, stick figures, are the people and other systems outside it; its use cases, ovals, are the things it does for them; lines join each actor to the use cases it takes part in. Scott Ambler, in The Object Primer, describes it as an overview of a system's usage requirements, with the detail written in the use cases themselves.

What an activity diagram is

An activity diagram shows a workflow step by step. Actions are round-cornered rectangles joined by arrows, from an initial node to a final node, with decision and merge diamonds for alternative paths and fork and join bars for parallel ones. Course notes at the University of Pretoria describe activity diagrams as combining techniques from flow charts, event diagrams and Petri nets, and Ambler calls them the object-oriented equivalent of flowcharts and data flow diagrams.

What a sequence diagram is

A sequence diagram shows objects interacting, in time order. Each participant is a Lifeline across the top, and messages run between the lifelines as horizontal arrows, the first at the top and each later one below it. Kansas State University's CIS 400 textbook defines it as a diagram of object interactions arranged in chronological sequence.

Where UML came from

UML began as a merger of three object-oriented methods: Grady Booch's method, OMT and OOSE. Booch, James Rumbaugh and Ivar Jacobson developed it at Rational Software in the mid-1990s, and Robert C. Martin's column of 1997 records version 1.0 as released on 13 January that year. The Object Management Group adopted UML as a standard in 1997, and the International Organization for Standardization approved it as an ISO standard in 2005 (Kansas State's textbook). UML 2.0, a major revision, was formally adopted in 2005.

Diagrams that leave things out

Real diagrams rarely show everything. The specification itself lets compartments, multiplicities and navigation arrows be suppressed, and says that nothing can be inferred from their absence. The University of Washington's course calls UML partly a language shaped by usage and convention, and says it is fine to leave things out that a team doesn't need. Ambler warns that the notation in his own diagrams may not match the current UML. Where course notes and the standard differ, the symbol pages say which is which.

Sources

  1. OMG Unified Modeling Language (OMG UML), Version 2.5.1, OMG document formal/17-12-05, December 2017, Object Management Group, Title page; 1 Scope; 9.2.4; 11.5.4; Annex A: Diagrams
  2. What is UML?, updated July 2005 for the adoption of UML 2.0, Object Management Group
  3. UML (CIS 400 Textbook: Object-Oriented Design, Implementation, and Testing), Chapter 5, UML, Kansas State University, Department of Computer Science, UML
  4. UML Class Diagrams (CSE 403 lecture slides), Emina Torlak, CSE 403: Software Engineering, Fall 2016, University of Washington, Paul G. Allen School of Computer Science & Engineering (Internet Archive), Slides 7 and 9
  5. UML Tutorial: Part 1 -- Class Diagrams, Robert C. Martin, 1997, Northeastern University, Khoury College of Computer Sciences (course reading, CS U370, Fall 2007), Introduction
  6. COS121 Lecture Notes, Chapter 16: UML Activity Diagrams, Linda Marshall and Vreda Pieterse, 2015, University of Pretoria, Department of Computer Science, 16.1 Introduction; 16.2
  7. UML Use Case Diagrams: An Agile Introduction, Scott W. Ambler, excerpted from The Object Primer, 3rd edition, chapter 5, Agile Modeling (Ambysoft)
  8. UML Activity Diagrams: An Agile Introduction, Scott W. Ambler, excerpted from The Object Primer, 3rd edition, chapter 9, Agile Modeling (Ambysoft)
  9. UML Sequence Diagrams: An Agile Introduction, Scott W. Ambler, excerpted from The Object Primer, 3rd edition, chapter 11, Agile Modeling (Ambysoft)

Researched, edited and approved by Rory Hansen before publishing. Last reviewed October 9, 2026. How we research