terminal

codeando_simple

terminal

menu

terminal

search_module

guest@codeandosimple: ~/system/search $ grep -r "" .

Press [ENTER] to execute search

Status

Engine: Ready

Database: Online

Index: V2.1.0_LATEST

bash -- cat uml-classes.md
guest@codeandosimple: ~/blog/uml $ cat class-diagram.md

Class Diagram_

// "We are what we repeatedly do. Excellence, then, is not an act, but a habit." - Aristotle

A class diagram describes the types of objects (their attributes, operations and constraints) present in the system and the static relationships that exist between them.

There are basically two types of relationships:

  • Associations: A Customer makes an Order

  • Subtypes: A Teacher is a subtype of Person

# Components: Classes

Represented by rectangles divided into three sections:

  • Class Name: The top part shows the name of the class.

  • Attributes: The middle section lists the properties or data that the class maintains.

  • Methods: The bottom section details the operations or functions that the class can perform.

Representation of a class

In code:

public class Order {
    // Private attributes
    private Date date;
    private int quantity;
    private double price;

    // Constructor
    public Order(Date date, int quantity, double price) {
        this.date = date;
        this.quantity = quantity;
        this.price = price;
    }

    // Public methods
    public void dispatch() {
        // Implementation of the dispatch method
    }

    public void close() {
        // Implementation of the close method
    }

    // We could add access methods (getters) and
    // modification methods (setters) for the private attributes
}

# Relationships: Association

A simple line that connects two classes and represents a relationship between them, such as collaboration or interaction.

Multiplicity indicates the number of objects participating. The "*" between Customer and Order indicates that a Customer can have many associated Orders; the "1" indicates that an Order comes from a single Customer.

Association Relationship
public class Customer {
    private String name;
    private String address;
    private List<Order> orders; // List of associated orders

    public Customer(String name, String address) {
        this.name = name;
        this.address = address;
        this.orders = new ArrayList<>();
    }

    public void addOrder(Order order) {
        orders.add(order);
    }
}

If we add Navigability (with Order pointing to Customer):

Navigability in Association

# Inheritance

A line ending in a triangle pointing toward a superclass, indicating that one class inherits from another.

Inheritance Relationship
public class CorporateCustomer extends Customer {
    private String contactName;
    private double creditLimit;

    public CorporateCustomer(String name, String address, String contact, double limit) {
        super(name, address);
        this.contactName = contact;
        this.creditLimit = limit;
    }
}

# Aggregation and Composition

Aggregation (Weak Relationship)

An object is related to others, with the latter having their own existence. If the library is deleted, the books can still exist.

Aggregation

Composition (Strong Relationship)

The existence of one depends on the other; the part cannot exist without the whole. If the polygon is deleted, its points are deleted.

Composition

# Interfaces and Visibility

An interface is a class without implementation (operations without a body or attributes). <<interface>> and dashed lines are used for implementation.

Interface in UML

Visibility symbols:

  • + Public
  • - Private
  • # Protected

# Complete Diagram

Complete class diagram

Purpose and Usage

  • Design: Essential for defining the code structure before implementing it.

  • Documentation: Details how the system is built for future maintenance.

  • Communication: Facilitates common understanding between developers and analysts.

# Conclusion

The class diagram is a vital instrument in UML and software engineering. It not only helps developers think and design in a structured and organized way, but it also ensures that the development team shares a common understanding of the system's design.