Task: Go from domain model to business design model

We will turn our conceptual model in business design model (classes) that we will illustrate by a business class diagram.  From this diagram, we could create raw Java classes of entities.

1) Go from domain model to business design model

The conceptual model will help us to design our classes of business entities.
However, with UC, it suggests clues on the needs in terms of data access, service and presentation classes. We will soon interest in it when implementing UC.
Meanwhile, back to our conceptual model :

All conceptual entities will not necessary become business class.
1) We will identify conceptual entities which must not become business classes.
2) Then, we will introduce business classes not present in the conceptual model.
3) At last, we will study conceptual entities suitable to become business classes. Some will demand modifications. Other will not.
We also will precise the navigation direction between classes.
The design of business classes and the definition of relations between classes rely on two importants concepts in software design in general and more particularly in OOP : coupling and responsibility.
We want a as low as possible coupling between classes and a strong cohesion (we also refer to single and well-defined responsibility) in each class.
In our business class modeling, coupling is mainly conveyed by the associations between classes. Unidirectional association is a coupling but a lower coupling than bidirectional association.
Cohesion/Responsibility is mainly conveyed by logical relations between properties owns by the class.
If relations between properties of a class are strong, natural and logical, we have a strong cohesion, a well defined responsibility. The class is so able to transmit a semantic with a real meaning and a natural logic.
On the contrary, if relations between properties are weak, unatural, we have a weak cohesion, which results in a class with an ambiguous role and a not clear semantic. In order to compensate this lack of cohesion, it is common enough that a weak cohesion class will create a strong coupling with other classes to get and manipulate missing data in its core.
With that kind of bad design, we may easily end up with a Spaghetti code, so a not readable and maintainable code.

1. Conceptual entities not kept to become classes

We have two: StockChart and Quotations.
StockChart is a very important conceptual entity which will obviously be present in our implementation but it will be better located in the graphical layer of the application.
About the Quotations entity, in the scope of a basic application like ours, we could rely on a JFreeChart class in order to stand for stock prices (the DefaultOHLCDataset) class).
On the other hand, in an application offering richer use cases, DefaultOHLCDataset will certainly not be enough. But for the time being, I prefer stay simple and consistent.

2. Business classes not present in the conceptual model

• DefaultOHLCDataset is a JFreeChart class. In our class model, it will replace the conceptual entity : Quotations.
  Its qualified name is org.jfree.data.xy.DefaultOHLCDataset. This class implements the XYDataset interface,which defined data in coordinates format (x,y).
  With JFreeChart, you must implement this interface to display a temporal serie.
  DefaultOHLCDataset which has in its naming, the OHLC acronym (we have discussed about OHLC in  Design the conceptual model is a structure which carry the 4 quotation prices : the Open, High, Low and Close price. It will allow us to offer multiple ways to display the stock price: line, bar chart, candlestick, etc…
• StockLoaded will allow us to group data initially located in StockChart.
  So, the class will own a relation to a precise stock, a set of quotations (DefaultOHLCDataset class) and a starting and ending interval of the set of quotations.
  Having a class which owns these three data allows us to give a coherent responsibility  to StockLoaded to represent  the stock price. Transmitting these data individually between applicative layers would bring undesired complexity and coupling in terms of data transiting between layers and would be cumbersome.
• DateInterval will allow us to group two data : starting and ending interval and also to centralize the creation rules of a valid interval

3. conceptual entities suitable to become business classes

Quotation and Stock entity are naturally ready to become classes.
The direct coupling between this two classes is nevertheless not needed.
First, a stock can have thousand and thousands of quotations. Sometimes, we need quotations from this interval, other time, we need quotations from another interval. Put all existing quotations for a stock in Stock instance whatever the user needs, would create a obviously load problem.
Second, in the other way (Quotation to Stock), the coupling is also not needed.
We should never need to navigate from a quotation the related stock instance. Why ?
Because, a quotation doesn’t live alone. It is always related to a set of quotations needed to address a processing on one and one stock (cf. import  quotations for that stock, display price in chart for that stock, etc…). In the logical view, it’s the stock which must know the quotation. Not the reverse. But as we have seen : it’s not desired to do it for practical reasons. So no relations are needed between these two classes.
We will just add the unique identifier of the stock (isin code) in the Quotation class, mainly in order to handle the quotations import in our system.

4. Navigability between classes

As we have discuted, a not necessary coupling between classes should not be created.
In our model, no bidirectional navigation betweeen classes being useful, we will precise the direction of navigation between each class.
A well-designed implementation model avoids cyclic dependencies because it can be considered as an indirect high coupling.
We will so strive to avoid this kind of design.

2) Raw business class diagram

3) Raw classes creation

Quotation

public class Quotation{
    private String isin;
 
    private LocalDate date;
 
    private float open;
 
    private float high;
 
    private float low;
 
    private float close;
 
    private long volume;
}

DateInterval

import org.joda.time.LocalDate;
 
public class DateInterval {
 
    private LocalDate startDate;
 
    private LocalDate endDate;
}

Stock

package davidhxxx.teach.jfreecharttuto.model;
 
public class Stock {
 
    private String isin;
 
    private String name;
 
    private String ticker;
 
}

StockLoaded

package davidhxxx.teach.jfreecharttuto.model;
 
import org.jfree.data.xy.DefaultOHLCDataset;
 
public class StockLoaded {
 
    private DefaultOHLCDataset dataset;
 
    private DateInterval intervalIncluded;
 
    private Stock stock;
}

ListOfStock

package davidhxxx.teach.jfreecharttuto.model;
 
 
import java.util.List;
 
public class ListOfStock {
 
    private List<String> stocks;
 
}

ListOfStockList

package davidhxxx.teach.jfreecharttuto.model;
import java.util.List;
 
public class ListOfStockList {
 
    private List<ListOfStock> listOfStocks;
}