Skip to content

50.003 - Solution Class Diagrams

Learning Outcomes

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

  1. Explain the concept of Solution class diagrams.
  2. Describe the difference between Domain class diagrams and solution class diagrams
  3. Derive solution class diagrams

Solution class diagrams - Introduction

A solution class diagram is the structure of a software System. It Provides an implementation perspective and extends Domain Class diagram with Methods (processSomeThing()), Visibility Modifiers (-accountId, +getId()) and Architecture Layers (ControllerClass). It also adds value to Sequence Diagrams by representing messages as class methods.

Solution class diagrams - Derivation

The two inputs for a solution class diagram are the domain class diagram and the sequence diagram. The idea is to integrate methods and new classes (relationships too) introduced in Sequence diagram to the existing structure of the domain class diagram.

Identify Data Types of the Attributes

Let's first recap the domain class diagram that we did in previous week for TransferFunds scenario.

You can observe that the methods are omitted and explicit type details are not mandatory. We first refine the domain class diagram attributes with their data types explicitly as below.

Identify and Define the new Classes

Then we need to identify the new classes introduced in the sequence diagram. Here UI and TransferController classes are added.

Recap the sequence diagram of the Transfer funds below.

  1. UI class acts on behalf of the customer here to collect the her inputs to send them to the system.

  2. TransferController class routes requests from UI to Account and Transaction. This class is the middle party which makes UI class and Domain classes (Account, Transaction) isolated.

Remark: Database class or Repository class could have been considered in the sequence diagram. In this example, we assume that database classes will be added in later refinements to the sequence diagram.

In order to define the attributes and methods of the new classes, we look at the messages passed the the sequence diagram.

  1. Since UI receives input from customer, we can model an attribute InputDetails and the corresponding output message according to the sequence diagram. Note that data type of InputData is abstracted as TransferFormData. According to the sequence diagram, the methods in UI class are exactly the showInputStatus() and showInsufficientFunds() which are return messages from controller.

  2. When it comes to the TransferController class, we have to first identify its methods namely, validateInput() sending the customer details and checkBalance() sending the amount to be withdrawn. The corresponding outputs are validationStatus and isSufficientBalance.

    The methods it calls are accountBalance() , debit() and credit().

    According to these methods, we can deduce the possible attributes of TransferController class. -inputStatus, -isSufficientBalance and -recordStatus. Note that TransferController class can derive fromAccount and toAccount by processing the inputDetails sent from UI. Hence, there is no need to have fromAccount and toAccount as Transferontroller class attributes.

    The methods and the new attributes can be used to define UI and TransferController classes as below.

Identify the new relationships

Inheritance

The relationships are introduced with the new classes UI and TransferController. We first check for the inheritance relationships and conclude that there is no inheritance to highlight here (If more detail needed we may add some inherited classes of UI).

Object Usage (uses relationship)

According to the sequence diagram, UI->TransferController and TransferController->Account are the message paths.

Then we check the directions of the relationships. Here, TransferController class is always accessed by the UI class and not viceversa. Similarly, Account class is accessed by TransferController class and not viceversa. Therefore we conclude the directions of the new relationships.

Finally, we evaluate the strength of the two relationships.

UI temporarily uses TransferController for validation purposes. UI does not save the reference to the TransferController as an attribute. Therefore, UI depends on TransferController.

On the other hand, TransferController temporarily uses Account objects and does not store them. Therefore, TransferController depends on Account.

The final solution class diagram for transfer funds is as follows.