From the identified use cases and basic trading knowledge, we will describe the conceptual model. In RUP (Rational Unified Process), we speak about « domain model ».
Warning: the conceptual model is not a software components model.
It is primarily a domain analysis of the studied business. Here we are interested in the business concepts of the software to build.
At the end of this exercise, we will identify key entities of the domain, properties of these entities, relationships between entities, as well as business actions made on these entities.
I find this model very relevant as the first entry design.
We do not try to separate business data from business treatment, or to refactor the code, or to define the navigation path between entities. We stay at a higher level of abstraction: business.
However, each information identified in the conceptual model will not necessarily be conveyed in the same way at the class diagram of the business entities that we will design.
In the previous task, we saw how the stock and more generally financial values appears as the key business concept of the application and of any trading application in general.
So we will not be surprised to find the stock as the central entity.
First, we will define the stock properties. Then we discuss the stock position among the other entities.
Thirdly, we will take an interest in the Quotation entity, representing the prices of a share.
A business data particulary important.
Finally, we will focus on the StockChart entity, which stands for the chart stock.
The other entities are simple to understand and fairly poor in business information, I will not dwell on them.
1) Stock entity properties
It is essential to identify an action by a code that will serve as a unique identifier. Things are unfortunately not so simple.
Today there are two main ways to identify an action: ticker and ISIN.
We will take account of course not SICOVAM code, a french identification code, abandoned for quite a long time (in the year 2003) for the ISIN.
Ticker suffers from two major defects. First, it is dependent on the stock market. So in a place (or market) of trading, the ticker is different. Second, it is potentially unstable over time. Indeed, as a mnemonic code, it is usually represented as an abbreviation of the associated stock. For example, the Orange company that was formerly France Telecom saw its ticker evolved from FTE to ORA.
In the case of Orange, there are two different tickers for the same company. But to be more precise, as the ticker is dependent on the stock market, there are two tickers by stock market … We understand why we had to quickly find a replacement for the Ticker: the ISIN.
The ISIN is a code that identifies a stock in an unique way.
Its structure is standardized (ISO 6166). It contains 12 alphanumeric characters without any link with the value which it represents and is not dependent on the market where the stock is traded. This identifier is an identifier which we could qualify as almost technical. In fact, it is not totally technical because the first two letters identify the country in which the security was issued.
According the quotation providers you use, ticker or ISIN can be provided.
Also, we will keep both. Each share will have two independent identifiers.
Besides, trading application users need the label of stocks. On one hand, we do not know all the codes by heart and, secondly, the stock chart, with as caption only a code is not very meaningful.
2) The Stock : a central entity
From the point of view of the data integrity, the stock is self-sufficient but most of the other entities have no existence without stock.
To draw a parallel with the world of databases, the stock could be a master table in which other entities have a reference on(slave tables).
We can note that the *, * relationship between the stock list and the stock is the exception.
To position the relationship 1, * as the other entities associated with the stock would have been not user-firendly because each action could not appear in more than one list.
3) The quotation entity
The entity Quotation represents for a specific period (day, time, etc …), the stock price. In reality, there are several price to be taken into account in determining the stock price. To keep things simple, we will remain on the most commonly used price in EOD (End Of Day): the famous OHLC (opening price, highest price, lowest price and closing price). We add too the date and the exchanged volume of the stock.
Of course a quotation knows to which stock it refers.
The currency attribute is not required in our use cases but it turns out be very useful when performing calculations on a portfolio.
4) The graphical entity of a Stock : StockChart
In a conceptual model excluding behavior aspects, this entity would not exist. But the domain model can not miss the stock graph because his dsplays if primordial.
And it’s a good thing.
Refocusing us on business needs. Remember, the UC-5 is: Display in a chart the price of a selected stock. Here, we are not in a simple visual formatting such as UC 2 (Display stocks lists) and UC4 (Display stocks from a selected stocks list.).
The price of a stock displayed as a chart materializes business information with singular value.
We can qualify StockChart as a composed information mixing visual and business. It has a display method of treatment () whose purpose is of course to display the stock price on a graph. We shall soon see how to materialize this concept during the implementation phase.
4) Domain model or data conceptual model
