50.003 - Class Diagrams¶

Learning Outcomes¶

By the end of this unit, you should be able to

1. Explain the concept of Problem Domain.
2. Explain the concept of Domain model.
3. Explain the Relationships, Associations, Multiplicity and Association class
4. Derive a Domain Model for a given problem.

Problem Domain¶

Understanding problem domain is essential before designing a software system to solve a given problem. The problem domain refers to the specific area of expertise or application relevant to the problem being addressed. It includes the real-world concepts that users interact with such as products, orders, invoices, customers, deliveries etc.

When it comes to developing software system, we need to identify the context of the system being developed. For example, if we need an order management system, the context defines the entities in the order management like products, order, invoices etc.

The context helps to define the scope of the system being developed. For example, for an order management system, we may not consider the venue as a part of the system.

Domain Concepts¶

We can visualize domain concepts in categories. This will help defining system boundaries and identify entities and relationships separately for the problem domain model described next.

Problem Domain Model¶

A Problem Domain Model is a structured representation of real-world business concepts. It serves as a foundation for understanding the system's environment and helps guide requirements and design decisions. The domain model stems from the refined scope in "Problem Domain" defined previously.

Problem domain model defines the concepts in problem domain as entities and relationships. It may take the form of simple diagrams, glossaries etc. which enhances clarity of the problem domain identified. Problem domain model is still an abstract representation which need to be filled with more details.

Domain Class Diagram¶

Domain class diagram formally shows a problem domain model. Each class represents an entity in the problem domain model and the corresponding attributes (Ex: In an order management system - Customer, Order). Class diagram also shows the relationships between the domain classes (Ex: In an order management system, Customer places Order shows the relationship between Customer and Order). Note that behaviors like "register (customer), cancel (order)" are not modelled in domain class diagram. In contrast, solution class diagram (different from domain class diagram) models entities and relationships of the system implemented, with added details of the entity behavior.

Domain Class Notation¶

Class diagram represents classes with a rectangle with 3 splits. The text in the splits (from top to bottom) represent class name, class attributes and behaviors respectively.

Attributes are variables denoting specific details about the class. In case of domain class diagram, the bottom is empty since the behaviors are not represented.

The following example shows three domain classes in an order management system.

---
title: Order management system
---
classDiagram
    class Customer{
    -custNumber
    -address
    -phone
     -order: Order
    }


    class Order{
      -orderID
     -orderDate
      -cust:Customer
    -amount
    -item:OrderItem

    }

    class OrderItem
    OrderItem : -itemID
    OrderItem : -quantity
    OrderItem : -price

Domain Class Relationships and Notation¶

There can be different relationships among the domain classes.

Inheritance - When a class A is a kind of class B, we say that "class A inherits class B". See the notation below.

classDiagram
  classA --|> classB

For example, we can add a new class (onlineOrder) and show that it is another Order type.

---
title: Order management system
---
classDiagram
    OnlineOrder --|> Order

    class Customer{
    -custNumber
    -address
    -phone
     -order: Order
    }


    class Order{
      -orderID
     -orderDate
      -cust:Customer
    -amount
    -item:OrderItem

    }


    class OnlineOrder
    OnlineOrder : -orderID
    OnlineOrder : -platformName
    OnlineOrder : -orderDate
    OnlineOrder : -amount

    class OrderItem
    OrderItem : -itemID
    OrderItem : -quantity
    OrderItem : -price

1
2
3

class OnlineOrder extends Order{
  //your code
}

classDiagram
  classA <.. classB

Association - An association is a stronger form of dependancy which necassitates one class having a reference to another class as an attribute. Having such a reference is called Navigability. If classA has a reference of classB, then we say, "classA can navigate to classB" and in other words, "classA has classB"

When the navigation is to a single direction, we have a unidirectional association. Additionally, having mutual navigability defines a bidirectional association.

classDiagram
  classA --> classB

1
2
3
4
5

class Customer{
  constructor(order){
    this.order= order//order is an object of Order
  }
}

---
title: Order management system
---
classDiagram
    OnlineOrder --|> Order
    Customer -- Order
    Order --> OrderItem
    class Customer{
    -custNumber
    -address
    -phone
     -order: Order
    }


    class Order{
      -orderID
     -orderDate
      -cust:Customer
    -amount
    -item:OrderItem

    }


    class OnlineOrder
    OnlineOrder : -orderID
    OnlineOrder : -platformName
    OnlineOrder : -orderDate
    OnlineOrder : -amount

    class OrderItem
    OrderItem : -itemID
    OrderItem : -quantity
    OrderItem : -price

Further refinements can be done for the directional associations mentioned above. They can be classified as aggregation or composition which denote whole-part relationships.

Aggregation : Aggregation is a directional association from classA to classB which says classA is a part of classB and classA can also operate independent of classA.

classDiagram
  classA --o classB

In most programming language syntax, association and aggregation are shown in a similar way. We need more context ("has-a" or "is-part-of") to differentiate them.

in code,

1
2
3
4
5

class Customer{
  constructor(order){
    this.order.add(order) //order object is a part of customer object and outlives customer
  }
}

Composition : Composition is a directional association from classA to classB which says classA is a part of classB. This is a stronger association than aggregation. In composition classB object is created by classA object while classB object is destroyed when the classA object is destroyed. Therefore the life cycle of classB object is bounded by the life cycle of classA.

In code,

1
2
3
4
5

class Order{
  constructor(name,amount){
    this.orderitems.add(new OrderItem(name,amount)) //orderitem is a part of Order, when order deleted, orderitem also deleted
  }
}

classDiagram
  classA --* classB

If the association is bi-directional and one direction (classA to classB) has aggregation, we can show it as below diagram. 1. strong association from classB to classA (aggregation from classA to classB)

1. General association from classA to classB.

   classDiagram
     classA --* classB
     classA --> classB

Check the order management system example with composition and aggregation.

---
title: Order management system (Tightly coupled)
---
classDiagram
    OnlineOrder --|> Order
    Customer --o Order
    Customer--> Order
    Order --> OrderItem
    class Customer{
    -custNumber
    -address
    -phone
     -order: Order
    }


    class Order{
      -orderID
     -orderDate
      -cust:Customer
    -amount
    -item:OrderItem

    }


    class OnlineOrder
    OnlineOrder : -orderID
    OnlineOrder : -platformName
    OnlineOrder : -orderDate
    OnlineOrder : -amount

    class OrderItem
    OrderItem : -itemID
    OrderItem : -quantity
    OrderItem : -price

---
title: Order management system (Low coupling)
---
classDiagram
    OnlineOrder --|> Order
    Customer o-- Order
    Order *-- OrderItem
    class Customer{
    -custNumber
    -address
    -phone
     -order: Order
    }


    class Order{
      -orderID
     -orderDate
    -amount
    -item:OrderItem

    }


    class OnlineOrder
    OnlineOrder : -orderID
    OnlineOrder : -platformName
    OnlineOrder : -orderDate
    OnlineOrder : -amount

    class OrderItem
    OrderItem : -itemID
    OrderItem : -quantity
    OrderItem : -price

Non binary Associations and Notation¶

All the associations we covered above are binary associations where exactly two classed were associated. There are other types of associations such as Unary, Ternary, and most generally n-ary.

Here, we precisely define the association between class A and class B in terms of class A objects and class B objects. Association between class A and class B means, some objects of class A associate with one or more objects of class B.

1. In Unary association a class associates with itself. In other words object of a given class can associate with another object of the same class. It is shown by a self directed edge.

       classDiagram
           Person -- Person : is married to
       class Person

   In the above example, there are objects in the person class where each of them are married to another person(s). We can also represent the bounds for the number of associated objects. This is called multiplicity and will be discussed in the next section.

2. In Ternary association, three classes can associate together. In other words 3 objects from each class can be associated.

In the above example, an association can be defined as a supplier supplies a product to a store.

Multiplicity in Associations and Notation¶

Given a binary association classA -- classB, for a chosen object in classA, it can interact with zero or more objects in classB. This is the most general case. The multiplicity labels defines precise lower and upper bounds for the number of associated objects in classB.

Consider the association between Order and OrderItem. Given 1 Order, there can be 1 or more Order items assuming Order is created only when there is a non empty list of OrderItems. This is represented in the Fig: 1, with "1" at the Order end and "1..*" at the OrderItem end. "1..*" means the minimum number of OrderItems is 1 and the maximum number of OrderItems can be any number (represented by the placehoder "*")

Similarly Fig: 2 denotes what is the minimum and maximum number of Orders exist for 1 OrderItem. Since there is exactly one Order for a given OrderItem, we show "1" at the Order end which is short hand for "1..1" (meaning min of 1 and max of 1).

Fig: 1 OrderItems per Order	Fig: 2 Orders per OrderItem

To obtain the combined multiplicity diagram we remove the Order end "1" from Fig: 1 and OrderItem end "1" from Fig: 2. Then we have the combined multiplicity diagram as Fig 3 below.

Fig: 3 Combined Multiplicity

Association Class and Notation¶

Some times, the association between two classes have some details worth modelling in the class diagram itself. This modelling is done via a separate class connected via a dashed line to the association link.

An example could be an existing association between a Student and a CourseSection. The student's grade for a CourseSection is neither an attribute of Student nor an attribute of CourseSection. The grade attribute belongs to the association between the Student and the CourseSection which we name as CourseEnrollment.

The following table shows the different types of multiplicities that can be represented in a class diagram.

Derive a Domain Class Diagram¶

1. Extract Candidate Classes: Analyze the use case descriptions to identify nouns and noun phrases, which often correspond to potential classes. Focus on entities that play a role in achieving the use case goals. (Ex: "Customer," "Account," and "Transaction")

2. Determine Class Attributes and Relationships: For each identified class, determine its relevant attributes and how it relates to other classes. (Ex: "Account" class attributes "accountNumber", "balance"; Account class Associated with "Customer" class.)

3. Create the Domain Class Diagram: Using the classes, attributes, relationships, construct the domain class diagram.

Derive a Domain Class Diagram for Transfer Funds¶

1. Use Case Goal: Enable a customer to transfer funds between accounts.

2. Identified Classes and Attributes:

   1. Customer: customerId, name, email, account
   2. Account: accountNumber, balance, Transaction
   3. Transaction: transactionId, amount, date, fromAccount, toAccount

   

3. Relationships:

   1. A customer has an account or multiple accounts. An account can associate with a single customer (If we ignore joint accounts). We show a general association from Customer to Account.

   2. An account is a part of transaction. An Account can be involved zero or more Transactions. A transaction relates to exactly two accounts. We show an aggregation relationship from Transaction to Account since transaction can outlive the accounts involved.

   

   We show the multiplicity requirements as follows.

   

   It should be noted that the choice of the nature of association (Dependancy, Association, Aggregate, Composition) depends on the specific requirements and design considerations.

   It is possible to include a list of transactions as an attribute in Account class here. Here, we leave it for solution class diagram, which is closer to the implementation.