UML

Introduction

Class notes’ definition

UML stands for Unified Modeling Language. It is a standardized visual language for specifying, constructing, visualizing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

UML is used by software developers, business analysts, and system engineers to model the design of a system and communicate that design to others.

Why is it useful?

  • It allows all team members to be on the same page by providing a common language; thus, people from different disciplines can understand and discuss system design in a concise and precise way (13)
  • It allows to identify issues either in the design or in the team dynamics (13)
  • It allows to solve any found issue even before coding the system (13)
  • It helps understanding the problem to solve, the client requirements, the market needs, the core, etc… (21)
  • It serves as a project documentation (13)

Class diagram and relationships

Inheritance

classDiagram
    class SuperClass {
    }
    class SubClass {
    }
    SuperClass <|-- SubClass : Inheritance

Inheritance is a relationship between classes, where one class is a subclass of another class and inherits the properties and behavioral of the superclass. This is represented in UML by a solid line with a closed, filled arrowhead pointing from the subclass to the superclass:

Composition

classDiagram
    class Client {
    }
    class BankAccount {
    }

    Client o-- BankAccount : Composition

Composition is a strong type of association that represents a whole-part relationship between two classes, where the parts cannot exist independently of the whole. This is represented in UML by a solid line with a closed diamond shape pointing from the whole to the part.

Aggregation

classDiagram
    class Person {
    }
    class Hand {
    }

    Person *-- Hand : Aggregation

Aggregation is a weaker type of association that represents a whole-part relationship between two classes, where the parts can exist independently of the whole. Thisis represented in UML by a solid line with an open diamond shape pointing from the whole to the part.

Association

classDiagram
    class Customer {
    }
    class Ticket {
    }

    Customer --> Ticket : Association

Association is a relationship between two classes that represents a connection or relationship between them (as in generic relationship). This is represented in UML by a solid line with an open arrowhead pointing from one class to the other.

Dependency

classDiagram
    class MovieManager {
    }
    class Movie {
    }

    MovieManager ..> Movie : Dependency

Dependency is a relationship between two classes that indicates that one class depends on the other for its functionality. This is represented in UML by a dashed line with an open arrowhead pointing from the dependenet class to the class it depends on.

Use / Realization

classDiagram
    class ShoppingList {
    }
    class Item {
    }
    
    ShoppingList ..|> Item : Use / Realization

Use is a relationship between two classes that indicates that one class uses the other in some way. This is represented in UML by a dashed line with an open, unfilled arrowhead pointing from the using class to the class being used.

Entity realtionship types: multiplicity

  • What is it? A way to define relationship between different types of entities using cardinality (cuantitative method)
  • Why is it required? It helps programmers to understand and go deep within the problem
  • What is it for? It is used as tool that allows us to propose solutions to our problem at the coding stage
  • How is it used? It is used when taking decisions regarding the necessity of each entity within the proposed solution

Multiplicity is a combination between cardinality and participation, where:

  • Cardinality denotes the maximum number of possible relationship ocurrences in which a certain entity can participate in (in simple terms: at most)
  • Participation: denotes if all or only some entity ocurrences participate in a relationship (in simple terms: at least)

One-to-One (1:1)

One-to-Many (1:n)

Many-to-Many (n:m)

Many-to-many requires a middle-man table (assignment table) for both entities to share that info

classDiagram
    direction TB
    class User {
        -int userId
        -String name
    }

    class Book {
        -int bookId
        -String title
        -Enumerator bookStatus
    }

    class Borrows {
        -User user
        -Book book
        -Date initialBorrow
        -Date endBorrow
    }

    class bookStatus {
        <<enumerator>>
        - Available
        - Lost
        - Borrowed
    }

    User ..> bookStatus
    User "1" --o "*" Borrows : Who borrows
    Book "1" --o "*" Borrows : What is borrowed