Must know things about UML Class Diagrams
In this post, I will write about all the things I learned about UML class diagrams
UML stands for Unified Modeling Language.
UML allows us to communicate 3 types they are Structure, Behaviour, and Interaction.
Structure diagrams show the structure of things. Class diagrams and Deployment diagrams are examples of structure diagrams.
Class Diagram: Represents object-oriented classes with fields, methods, relationships, etc.
Deployment Diagram: Illustrates how different system components are deployed
Behavior diagrams show how things behave. Activity diagrams and State Machine diagrams are examples of behavior diagrams.
Activity Diagram: Illustrates the flow between a series of steps or actions.
State Machine Diagram: Represents states and transitions between those states
Interaction diagrams show how things interact with each other. A sequence diagram is an example of an Interaction diagram.
Sequence Diagram: Illustrates a sequential flow of communications between components
In this post, I will talk about the Class diagram.
UML Class Diagrams consist of three sections, Class Name, Attributes, and Operations.
Class Names are written in bold.
Abstract class names are written in italics.
Static attributes and operations are underlined.
Attributes refer to the properties or fields or a class. They are expressed as follows,
<visibility><name>: <type> = <default value> <{modifier}>Visibility refers to the access modifiers on the attributes, and UML supports the following access modifiers.
- + (public)
- - (private)
- ~ (package)
- # (protected)
The name of an attribute is used to identify the attribute.
The type of the attribute refers to the data type that it will use (Long, String, Integer …)
The default value of an attribute is optional and may be left blank.
The modifier is optional and serves to provide additional information on the attribute, such as {readOnly}
Operations refer to the behaviors or methods of a class. They are expressed as follows
<visibility><name>(<parameter list>): <return type>Visibility and Name are self-explanatory — they serve the same purpose as they do on attributes.
The parameters refer to the parameters(method arguments) that will be passed to the operation when it is invoked. They are represented as follows : <parameter name>: <parameter type>
The return type refers to the type of the result returned by the operation, such as String or Integer.
Class Diagrams — Relationships
Object-oriented classes have relationships between them — they extend each other (inheritance), they depend on each other (dependency), they interact with each other (association), or they form part of each other (aggregation and composition).
Relationships also have multiplicity, which shows how many instances of a class can exist on each side of a relationship.
Dependency relationships exist when classes depend on each other in such a way that a change to one class may affect the other, such as when one class accepts an instance of another class as a parameter to a method.
Dependency relationships are represented by arrows on dashed lines. Stereotypes can be indicated within guillemets to provide further detail on the nature of the relationship.
A dependency relationship can exist when we have a Library class that manages Book objects. Since the Library class has a method that returns a Book, changes to the Book class could result in changes to the Library class (based on how Book objects are created).
public class Library {
public Book findBook(String name) {
//Do some book stuff.
return new Book();
}
}
class Book {
private String name;
private String author;
private String isbn;
//Getters/setters omitted.
}Generalization relationships exist when one class extends another class (making it a specialization of the parent class, like a Car is a specialization of a Vehicle).
Generalization relationships are represented by a triangular arrow on a solid line.
Operations and attributes in the parent class also exist in the child classes, without being explicitly specified.
A generalization relationship can exist when we have a system that keeps track of vehicle rentals, where we have various specialized vehicles.
public class Vehicle {
private String manufacturer;
private int yearOfManufacture;
public String getManufacturer() {
return manufacturer;
}
public void setManufacturer(String manufacturer) {
this.manufacturer = manufacturer;
}
public int getYearOfManufacture() {
return yearOfManufacture;
}
public void setYearOfManufacture(int yearOfManufacture) {
this.yearOfManufacture = yearOfManufacture;
}
public boolean isAvailableForRental() {
//Execute some logic.
return true;
}
}
class Truck extends Vehicle {
private double engineCapacity;
private double loadBinSize;
public double getEngineCapacity() {
return engineCapacity;
}
public void setEngineCapacity(double engineCapacity) {
this.engineCapacity = engineCapacity;
}
public double getLoadBinSize() {
return loadBinSize;
}
public void setLoadBinSize(double loadBinSize) {
this.loadBinSize = loadBinSize;
}
}
class Boat extends Vehicle {
private double length;
private int numberOfEngines;
public double getLength() {
return length;
}
public void setLength(double length) {
this.length = length;
}
public int getNumberOfEngines() {
return numberOfEngines;
}
public void setNumberOfEngines(int numberOfEngines) {
this.numberOfEngines = numberOfEngines;
}
public static void main(String[] args) {
Boat boat = new Boat();
boat.setManufacturer("Boat Company");
boat.setYearOfManufacture(2018);
boat.setLength(5.5);
boat.setNumberOfEngines(2);
Vehicle vehicle = boat;
}
}Association relationships often exist when classes have variables of other types, that they can invoke operations on.
Association relationships are represented by an arrow on a solid line.
Association relationships can be bi-directional, in which case both classes can reference each other.
Association relationships can also include multiplicity, where we can have one instance on one side and exactly zero or one instance on the other side, or one instance on one side zero or more instances on the other side (* refers to any number of instances), or any other combination.
An association relationship can exist when we model the relationship between doctors and patients, where a doctor can have any number of patients and a patient can only be treated by one doctor at a time.
public class Doctor {
private String name;
private String registrationNumber;
private List<Patient> patients = new ArrayList<Patient>();
public void addPatient(Patient patient) {
this.patients.add(patient);
}
//Getters/setters omitted.
}
class Patient {
private String patientId;
private String name;
private int age;
//Getters/setters omitted.
}Aggregation relationships exist when we aggregate (or bring together) objects of one class in another class.
Aggregation relationships are represented by an unfilled diagram on the ‘owning’ side of the relationship.
Objects on both sides of an aggregation relationship can exist in isolation.
Aggregation relationships can have multiplicity.
An association relationship can exist when we model teams and players. A player can exist without belonging to a team, and a team can exist without any players.
public class Team {
private String name;
private String slogan;
private String city;
private List<Player> players = new ArrayList<>();
//Getters/setters omitted.
public void addPlayer(Player player) {
this.players.add(player);
player.setTeam(this);
}
public void removePlayer(Player player) {
this.players.remove(player);
player.setTeam(null);
}
}
class Player {
private String name;
private int age;
private String homeTown;
private Team team;
//Getters/setters omitted.
public void setTeam(Team team) {
this.team = team;
}
}Composition relationships are when objects are composed of (or made up of) other objects.
Composition relationships are represented by a filled diamond on the ‘owning’ side.
Objects in a composition relationship cannot, conceptually, exist in isolation. This isn’t always easy to enforce in code.
If the parent object in a composition relationship is destroyed, so are the child objects.
A composition relationship can exist when we model a system for creating web pages — pages cannot exist without a page header and a page body, and each PageHeader and PageBody object must belong to a WebPage object.
public class WebPage {
private final PageHeader header;
private final PageBody pageBody;
public WebPage(PageHeader header, PageBody pageBody) {
this.header = header;
this.pageBody = pageBody;
}
}
class PageHeader {
private String title;
private String charset;
//Getters/setters omitted.
}
class PageBody {
private String body;
//Getters/setters omitted.
}Class Diagrams — Advanced Concepts
Notes are used to add additional information to UML Class Diagrams (and other UML diagrams).
Notes are represented by a rectangle with the top-right corner folded over.
Notes can exist on the diagram itself, or they can be linked to specific elements with a dashed line.
Template classes are parameterized to operate on specific types.
Template classes are represented by a generic type in a dashed block on the top-right corner of the class.
Template classes correspond to generic classes in languages like Java and C#.
A template class can be used to represent a Container class that can hold objects of a specific type.
Derived attributes are class attributes that can be calculated based on other values on a class (or outside of it, such as the current date).
Derived attributes are indicated by a forward slash (/) preceding the attribute name (e.g. /age: int ).
We can use notes to indicate how derived attributes are calculated (although we could also show this on a sequence- or activity diagram).
We can use a derived attribute to model a class that calculates a customer’s age.
Keywords are used to provide additional metadata on a class or class element.
Keywords of a class (the ones that we use in this course) are indicated in guillemets.
Constructors are special operations used to create instances of a class.
Constructors share the name of the class and do not specify a return type.
Constructors can be indicated with the ‘constructor’ keyword.
Constructors can also be indicated without the ‘constructor’ keyword since one can easily infer that an operation is a constructor.
Interfaces and Enumerations
Interfaces define contracts for behavior, but without implementing that behavior.
Enumerations, or enums, are classes that provide a fixed set of literal values.
I learned these things from: udemy.com/course/uml-class-diagrams-for-programmers
