Like other types of diagrams, UML Class diagrams allow you to visualize, in this case, the design of a class. Since classes are at the root of Object Oriented Design, this is one of the most common diagrams you will find yourself creating.
A class diagram will contain:
- The class name,
- The class’s attributes,
- The operations (methods), and
- The relationships between this class and other classes.
What is a Class
A Class is a blueprint for an object. It describes how the object will be created, what attributes it will have, and what it can do.
Objects and classes go hand in hand. We can’t talk about one without talking about the other.
The point of Object-Oriented Design is not about objects. Rather it’s about classes, because we use classes to create objects.
So while a class describes what an object will be, but it isn’t the object itself. If you think of the blueprint notion from above, a blueprint of a building, isn’t the building. But it will tell the builders exactly what will go where. For a building this includes things you cannot see, like wiring, HVAC duct works, plumbing, etc.
While the blueprint will describe the building in great detail, it still isn’t the building, until the builder comes along and follows the blueprint. In fact, following the blueprint, you can make multiple copies of the building. We see this all the time in preplanned neighborhoods where there are only a few types of houses, to commercial buildings like a WAWA gas station.
Likewise, we’ll create an object from the class in our programming language. Each time we build an instance (of that object) we go to our class definition (blueprint) and build from it.
Our class definition can be built from our class diagram, as we specify what is being built (the class name), the attributes about it, and what that object can do (it’s methods). Additionally, we’ll reference any dependencies or associations with other class objects.
UML Class Notation
A class is shown as a rectangle. It will be sub divided into three sections (for the class name, the attributes, and the methods). However, only the class name is required.
A class can have a signature or be without a signature. The signature is the return type of the method. If you use signatures, then you will also need to define the attribute types. Both the signature and type refer to the data types within a programming language, and they can be built in, or used from a different class you’ve defined.
Class Visibility
You may have noticed that the attributes have minus signs in front of them, and plus signs in front of the operations (methods).
This is for defining the visibility of these attributes and operations to other classes. The accessor types are below:
- plus (+) – publicly visible
- hash (#) – protected
- minus (-) – private – only that class can see it.
Uses for a Class Diagram
A developer can use a class diagram for several ways.
They can define very abstract concepts to see the project as a big picture. This is sometimes called a conceptual view, or a 30,000 foot view. The idea being if you’re flying high in a plane, you can still see cities and lakes, and large things like that, but smaller details are hidden from view.
You can move in closer to the details with a Specification style. Here you focus on abstract data types (ADT). You will have the class names, attributes, and maybe some of the operations (but not getters and setters). The idea is more refined than the conceptual view, but the details are still not fully there. However, another skilled developer should be able to pick up the project and develop it.
Finally, the most detailed type of diagram is the Implementation. It has everything the Specification style has, plus all of the getters and setter methods defined. If the language you will be developing in has data types, it will be defined as well.
The goal for the implementation is to be able to hand it off to a junior developer and have them follow the diagram to create a project.
UML Class Diagrams was originally found on Access 2 Learn
