Start Diagramming!

<- Previous

5a. UML Elements - Class

We will start with the star of UML Class Diagrams, the "Class" element.

What is a Class?

"The purpose of a Class is to specify a classification of objects and to specify the Features that characterize the structure and behavior of those objects."

To properly describe why Classes are so useful, let's start with a hypothetical scenario. Let's say you are helping a friend assemble a bookshelf. Your friend lays out all of the tools and asks you to hand them the tool they need when they ask for it. Your friend starts by asking, "Will you hand me the thing that is long and has a metal top thing that's kind of heavy and has a thing on the end that you can pull things out with and it has a thing that pounds the other things with you swing the other end of the thing?" You might be able to guess a little bit what they are asking for by the description, so you hand them the "hammer". Phew! You guess right. Next they ask for "the thing with the more round thing that turns the other thing that goes into the other thing, but the one that's not as heavy, but kind of heavier than the other things and also has a top thing thats got 4 things around the top of the thing." Okay, now you are completely lost. "What are you talking about?!" 🤨

This might actually sound like a situation you have been in before. But it clearly isn't the most efficient way to describe a tool. What if instead your friend first asked, "Can you hand me the longest hammer?" and for the next tool, "Can you hand me the 2nd largest Phillips screwdriver?" We can probably agree that's easier to understand what someone is trying to describe. As humans, we have a hard time thinking of everything as the same type just with different characteristics. Instead it's easier for our brains to group similar things together and give them names.

Well, that's one of the purposes of Classes. In software, you may be able to get away with describing all objects that you are modeling purely by their attributes and characteristics, but it's much simpler to "classify" similar objects together into groups or categories that all share a small subset of the same characteristics. A Class is just that, a way to classify similar objects under the same name.

Class vs Instance

It's important to remember that Classes are NOT the instance themselves, they are instead a description of ALL of the individual instances or objects in the same category. For example, when you refer to a "Screwdriver" you are generally referring to a category of all individual screwdrivers, not the screwdriver that I own in my garage.

One last note: Many refer to these instances of Classes as "objects". I personally like the word "instance" so I will use that terminology in the rest of this course. But keep in mind you can easily replace the word "object" for "instance".

An instance is considered "instantiated" when you create a new instance of a Class. This new instance has all of the characteristics and behaviors that every other instance of that Class so you can treat them the same.

Class attributes and operations

As mentioned previously a Class describes it's instances with a name, but it also describes instances by describing the structure and behavior that the instance is capable of. We call the structure descriptions "attributes" and the behavior descriptions as "operations". We won't go into detail on each of these concepts here because we will cover these later.

How do you know when to create a new Class?

This is a tricky question and elicits different answers depending on who you ask.

A general rule is when you want to treat something differently than something else, you usually create a new Class. For example, you don't need to create multiple "Order" classes (e.g. "ToyOrder", "GroceryOrder", "ApplianceOrder") unless you plan on treating them differently.

Another general rule is that when a set of instances has vastly different attributes or behaviors than another set of instances, you usually create a new Class. For example, a "Person" has a "first name", "phone number", and "credit card." Whereas an "Order" has an "order number", "total dollar amount", and "promotion codes". Both of them may even share similar attributes like "address" or "weight", but it still makes sense to separate them into separate Classes.

Comparison to Object-Oriented Programming Languages

You may already be familiar with classes in Object-oriented programming languages. Classes in UML Class Diagrams are the same concept as what you create in OOP languages.

Abstract Syntax

To illustrate what a Class is, UML provides abstract syntax which we have recreated in UML Class Diagrams.

Class Abstract Syntax
Class Abstract Syntax
Class Abstract Syntax Inherited Attributes
Class Abstract Syntax Inherited Attributes
Class Abstract Syntax Inherited Operations
Class Abstract Syntax Inherited Operations

Next ->