Understanding UML Classes: A Comprehensive Guide

In the realm of software engineering and object-oriented design, the Unified Modeling Language (UML) serves as a standardized way to visualize the design of a system. One of the fundamental building blocks in UML is the concept of a class. This article will delve into the key concepts of classes in UML, provide examples, and explain their significance in software design.

What is a Class in UML?

A class in UML is a classifier that describes a set of objects sharing the same features, constraints, and semantics (meaning). It is represented as a solid-outline rectangle containing the class name, and optionally, compartments separated by horizontal lines that contain features or other members of the classifier.

Key Characteristics of a Class

Class Name: The name of the class should be centered and in boldface, with the first letter capitalized if the character set supports uppercase.

Compartments: A class can have multiple compartments:

  • Name Compartment: Contains the class name.
  • Attribute Compartment: Lists the attributes of the class.
  • Operation Compartment: Lists the operations (methods) of the class.
  • Additional Compartments: May include constraints or other details.

Features of a Class

The features of a class are its attributes and operations. When a class is shown with three compartments, the middle compartment holds a list of attributes, and the bottom compartment holds a list of operations.

Attributes

Attributes are the properties of a class. They are represented by instances of properties owned by the class. Attributes can represent navigable ends of binary associations. Objects of a class must contain values for each attribute that is a member of that class, in accordance with the attribute’s characteristics, such as its type and multiplicity.

Operations

Operations are the methods or functions that a class can perform. They define the behavior of the class. Operations are listed in the bottom compartment of the class rectangle.

Static Features

Static features can represent characteristics of the classifier itself rather than its instances. Static features are underlined. There are two semantics for static features:

  • Different Values: Static features may have different values for different featuring classifiers.
  • Same Value: Static features may have the same value for all featuring classifiers.

Inheritance of values for static features is permitted but not required by UML 2.

Visibility

Attributes and operations can be grouped by visibility. Visibility keywords or symbols can be given once for multiple features with the same visibility. For example:

  • Public: +
  • Private: -
  • Protected: #

Structured Classes

In UML 2.5, classes became structured, encapsulated, and behavioral by extending encapsulated classifiers and behavioral classifiers. This means any class may have some internal structure and ports. Structured classes support encapsulation (information hiding) through ports, limiting the visibility of classifiers to the scope of the namespace of the containing structured class.

Example of a Structured Class

Library Services: This is a structured class encapsulated through the searchPort port. The nesting of classifiers defined within the scope of the structured class limits the visibility of the classifiers to the scope of the namespace of the containing structured class and thus supports encapsulation (information hiding) through ports.

Abstract Classes

UML 2.4 mentions abstract classes but provides no definition. We can relate the definition of an abstract classifier to an abstract class. An abstract class is intended to be used by other classifiers (e.g., as the target of generalization relationships). Attempting to create an instance of an abstract class is undefined—some languages may make this action illegal, while others may create a partial instance for testing purposes. The name of an abstract class is shown in italics or using the keyword {abstract} after or below the name.

Example of an Abstract Class

SearchRequest: This is an abstract class that cannot be directly instantiated. It exists only for other classes to inherit from and to support reuse of the features declared by it.

Standard Class Stereotypes

There are several standard UML stereotypes that apply to classes:

Name Description
«Auxiliary» An auxiliary class supports another more central or fundamental class, typically by implementing secondary logic or control flow. It is often used for specifying the secondary business logic or control flow of components during the design phase.
«Focus» A focus class defines the core logic or control flow for one or more supporting classes. It is used for specifying the core business logic or control flow of components during the design phase.
«ImplementationClass» The implementation of a class in some programming language (e.g., C++, Smalltalk, Java) in which an instance may not have more than one class. This is in contrast to a UML class, for which an instance may have multiple classes at one time and may gain or lose classes over time.
«Metaclass» A class whose instances are also classes.
«Type» A type class specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects. It may have attributes and associations, and behavioral specifications for type operations may be expressed using activity diagrams.

Nonstandard but Routinely Used Class Stereotypes

Several nonstandard but routinely used class stereotypes are available in UML tools like IBM Rational Software Architect (RSA) and Sparx Enterprise Architect:

Name Description
«Boundary» Represents a system boundary, such as a user interface screen, system interface, or device interface object. It is often used in sequence diagrams to demonstrate user interactions with the system.
«Control» Used to model the flow of control or some coordination in behavior. Control classes describe the dynamics of the designed system and usually describe some “business logic”.
«Entity» Represents some information or data, usually but not necessarily persistent. Business entities represent “things,” items, documents, or information handled by business workers. System entities represent information or data processed by the system.

Class Templates

UML classes can be templated or bound. A template class allows for the definition of a class with formal template parameters that can be substituted with actual values when the class is instantiated.

Example of a Template Class

Array: This is a template class with two formal template parameters. The first parameter T is an unconstrained class template parameter, and the second parameter n is an integer expression template parameter. A bound class Customers substitutes T with Customer and n with the integer value 24, resulting in an array of 24 objects of the Customer class.

Conclusion

Classes in UML are essential for modeling the structure and behavior of a system. They provide a clear and standardized way to represent objects, their attributes, operations, and relationships. Understanding and effectively using classes in UML can significantly enhance the design and documentation of software systems, making them more maintainable and easier to understand.

By leveraging the concepts of class diagrams, object diagrams, and various UML tutorials and guides, developers can create robust and scalable software architectures. For more detailed information, refer to resources such as Wikipedia, OMG, Visual Paradigm, Archimetric, and Cybermedian, which offer comprehensive insights into UML and its applications.

References

  1. Visual Paradigm. (n.d.). UML Class Diagram Tutorial. Retrieved from https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
  2. Wikipedia. (2024, December 4). Class diagram. Retrieved from https://en.wikipedia.org/wiki/Class_diagram
  3. Cybermedian. (2024, August 19). A Comprehensive Guide to UML Class Diagram. Retrieved from https://www.cybermedian.com/a-comprehensive-guide-to-uml-class-diagram/
  4. ArchiMetric. (2024, August 23). Learning Class Diagrams with Visual Paradigm. Retrieved from https://www.archimetric.com/learning-class-diagrams-with-visual-paradigm/
  5. Visual Paradigm. (n.d.). UML Association vs Aggregation vs Composition. Retrieved from https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/
  6. Cybermedian. (2024, December 3). UML Diagrams: A Comprehensive Guide. Retrieved from https://www.cybermedian.com/uml-diagrams-a-comprehensive-guide/
  7. Visual Paradigm Guides. (2023, September 14). Object Diagram in UML: Bridging the Gap Between Classes and Instances. Retrieved from https://guides.visual-paradigm.com/object-diagram-in-uml-bridging-the-gap-between-classes-and-instances/
  8. Wikipedia. (2025, January 10). Unified Modeling Language. Retrieved from https://en.wikipedia.org/wiki/Unified_Modeling_Language
  9. Visual Paradigm
  10. Wikipedia
    • Class diagram – Wikipedia – This article provides an overview of class diagrams in UML, including their structure, attributes, operations, and relationships among objects.
    • Unified Modeling Language – Wikipedia – This article offers a comprehensive overview of UML, including its diagrams, structural views, and the hierarchy of UML diagrams.
  11. Cybermedian
  12. ArchiMetric
    • Learning Class Diagrams with Visual Paradigm – This guide provides a step-by-step tutorial on creating class diagrams using Visual Paradigm, covering key components and best practices for creating effective class diagrams.
  13. OMG (Object Management Group)
    • OMG UML Specification Version 2.5.1 – The official specification for UML 2.5.1, providing detailed information on UML diagrams, including class diagrams and their components.
    • UML 2.0 Infrastructure – The official specification for UML 2.4.1, offering insights into the infrastructure and foundational elements of UML.