UBIQUITOUS LANGUAGE: HOW TO CREATE IT?2015 10 15
Author: Tomaš Maconko
This is the second post in a series of blog posts about Ubiquitous Language. It describes how it can be created.
During the analysis of business domain the team can split the whole domain into subdomains which will become the bounded contexts. Each bounded context contains its own list of participants, properties, use cases and states that can be used as a dictionary in Ubiquitous Language.
DOMAIN CONTEXT EXAMPLE
For example, we got the following short context description for a project reques
Shop owner requested to create a system for POS’es to allow customers use shop specific prepaid and postpaid (credit) cards. The system should allow operators to register customers, edit customers’ information, and provide customers the cards. With prepaid card customer can pay the amount not higher that the card has. With postpaid (credit) card customers can pay amount of money the card has or get a credit with not higher amount than the credit limit. Credit amount must be paid by the specified term that can be configured in system.
Business analyst has to carefully review the system context and discuss the requirements with shop owner. After that the requirements should be written down in certain form.
From the current business domain context we extract the shop context and in this case the requirements can be following:
- The operator has to be able to register new customer. Operator should fill the following fields for customer: first name (r), last name (r), birth date (r), emailaddress (r), where (r) – required fields.
- The operator has to be able to generate new prepaid card for customer. Prepaid card should have card number (u), where (u) – unique field. Also prepaid cardhas to contain the balance that is increased by a deposit transaction and decreased by withdrawal transaction. Balance should never go below 0. Customercan have only one prepaid card.
- The operator has to be able to generate new postpaid card for customer. Postpaid card should have card number (u), where (u) – unique field. Also postpaid card has to contain the balance that is increased by a deposit transaction and decreased by withdrawal transaction. Balance can go 0, so then customer gets a credit amount, which cannot be higher than max credit limit. Credit amount must be paid by specified term. Customer can have only one postpaid card.
- The operator has to be able to block the customer’s card, so it cannot be used when it’s lost.
- The operator has to be able to activate customer’s card either after customer found his or her card or card was generated.
- The operator has to be able to deposit amount to customer’s card. This action should initiate the transaction that should contain card number of card andamount.
- The operator has to be able to withdraw amount from customer’s card. This action should initiate the transaction that should contain amount and card’s card number.
- From the requirements we can figure out who are the participants of system, what they can do with it and what results will it provide.
THE FORMAT CAN BE DIFFERENT
The list of requirements provided above lets us to create a dictionary of items that will be used for system during the whole development process.
The format of ubiquitous language can be different. There are many forms of ubiquitous language dictionaries, so everyone can choose in their own what kind of form they want to use. It can be left as requirement specification with marked words in any way you want. This can be provided as user stories with highlighted keywords, use case diagrams, class diagrams or classic dictionary with keyword and description for it.
In the following picture we provide an example of ubiquitous language in form of class diagram (the context is taken from previous examples):
Together with this diagram there should be a use case diagram where we can see the actions that can be performed in the system with its keywords and descriptions.
Ubiquitous Language is not another artifact of software development process, but is used to solve the communication problems. In this post we have shown that the creation of Ubiquitous Language is quite easy. But it is important to carefully follow this language during the project.
In next post we will provide an example of how to map contepts from UL to source code constructs.
How to reduce planned downtime for OpenEdge applications with Pro2?2023 05 23
Learn more about how Pro2 can reduce downtime for Progress OpenEdge applications.More
Special offer for companies considering cloud migration2023 05 09
Baltic Amadeus, together with Microsoft, offers cloud assessments that help business organisations adopt cloud technologies more easily.More
Discover the magic of ABL: three reasons to love it2023 05 03
Read more about Progress OpenEdge ABL and what benefits it provides in programming.More