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 (and exact data structures like "List" to show the multiplicity) explicitly as below.

Identify methods of Domain Classes

Recap the refined sequence diagram of the Transfer funds below.

According to the sequence diagram there are two Account objects namely SrcAccount and DesAccount. Account class has debit(amount), credit(amount), record(trans), rollbackDebit(amount) and rollbackCredit(amount) methods which are all called by TransferController class.

Transaction class does not have methods.

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.

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

  2. TransferController class routes requests from UI to Account and Transaction and returns results back to the UI. 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. We follow the simple MVC architecture introduced in your javascript lessons.

In order to define the attributes and methods of the new classes, we look at the messages passed to 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 (tfd). According to the sequence diagram, the methods in UI class is show(msg) which are return messages from controller.

  2. Considering TransferController class, we have to first identify its methods namely, validateInput(tfd) sending the customer details and transfer(tfd) sending the amount to be withdrawn. The corresponding outputs are validationStatus and transferStatus (success or fail)

    The methods it calls are accountBalance() , debit(amount), credit(amount), and new Transaction(src,des,amount). According to these methods, we can deduce the possible attributes of TransferController class.

    Note that TransferController class can derive fromAccount ,toAccount and amount attributes of the Account and Transaction classes by processing the TransferFormData sent from UI. TransferController then instantiates Account and Transaction objects to call the corresponding methods.

    On the other hand, outputs received by TransferController class can be used to call the UI methods instantly. Therefore, TransferController class does not have any attribute.

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.

  1. UI temporarily uses TransferController for validation purposes and route transfer message to Account class. UI does not save the reference to the TransferController as an attribute. Instead, UI creates TransferController object inside inputTransferDetails() method which calls validateInput(tfd) and transfer(tfd) internally. UI depends on TransferController.

  2. TransferController temporarily uses Account objects for balance checking and transfer. It also temporarily creates and uses Transaction object for transfer method. It already receives tfd from the UI class, hence do not need to store any details of Account to reference later. Therefore, TransferController depends on Account and Transaction.

For dependancy relationships we do not show multiplicity since, it is temporary usage. The final solution class diagram for "transfer funds" is as follows.

Tips on Sequence Diagram Creation to Easy Transformation for Solution Class Diagram

  1. Message should consist of what to do (method name), inputs,return message and return message type. It is a good practice to show all the return messages explicitly (including empty messages)

  2. Limit UI classes for input (tfd) attribute and show(msg) method.

  3. Limit Controller classes to be stateless. Use Controller class as a router between UI and Domain classes.

    1. As long as a value is sent as method argument, no need to have an attribute to store it. Since UI class always store the input data, it can be sent to Controller as method arguments. Controller does not need to store it.

    2. Controller class can instantiate domain class objects, and pass arguments to domain class methods based on the arguments it receives from UI.

    3. Outputs the Controller object receives from Domain objects can be reused (with some transformations) inside the caller method of Controller object. Therefore no need to store additional Domain class status attributes in Controller class.

    4. If we need to store the state across a UI sequence (Ex: Booking ID from Booking UI to Payment UI), we can keep it inside the UI class. Therefore, Controller receives all the state information from UI and send it to the Domain classes without storing it. It is also possible to store the state in the Domain class and propagate it to UI class via the return message without Controller class storing it.

  4. Can keep input messages to Controller and return messages from Controller unnamed, and have a meaningful name, after rest of the sequence diagram is drawn. (Ex: UI sends tfd to Controller. Controller calls accountBalance() , debit(amount) credit(amount) in the Account. Finally, Controller sends transfer_success message to UI. This entire sequence can be named transfer(tfd)).