Designing a domain model (class diagram) for a financial software

Question

During my preparation for an exam in software engineering, I came across the following task in an old exam:

For a client, you create a new financial software whose task is, among other things, to perform tax calculations. The following requirements have been communicated to you by the Client:

• The system must be able to:
  • calculate and display VAT for different countries and tax rates (Germany 19%, Austria 20%, Switzerland 8%).
  • calculate and display the income tax according to country-specific tax tables (separate table for Germany, Austria, Switzerland).
• The system must allow the user to:
  • enter the tax relevant data (gross amount for VAT, annual income for income tax)
  • print the result of the tax calculation on a network printer.
  • send the result of the tax calculation to the appropriate tax office.

Task 1: Capture the requirements communicated by the client in a domain model (class diagram) with the following information: classes, attributes, methods, relationships, multiplicities, relationship name.

Solution: I am not sure how to define the right classes, relationships and multiplicities. But I tried it and came to the following incomplete solution:

First Update:

Second Update:

Could someone help me with this? Thanks :)

Answer 1

Review of your diagram

I propose you to read your first diagram, and leave it as an exercise to cross-check if it really meets the requirements:

• "A tax rate is composed of a country" (top composition). So countries do not exist independently of tax codes. Is this really what you meant? And does anything in the requirements tell that there is only one tax rate per country?
• "A tax rate is composed of an (optional) income tax rate, and an (optional) VAT rate" (double composition in the middle). Ouh!?
• "Every income tax rate has its own tax category(ies)" (bottom composition). Isn't the idea of categories to group similar income tax rates?
• "A tax rate aggregates tax administrations, and a tax administration may appear in several aggregates" (aggregation). Why should an administration be aggregated in tax codes?

First recommentation: read in your course the difference between association, aggregation and composition. THe use of aggreegation and composition are in principle exceptional and there must be strong reasons to use use it.

Some more questions:

• Where are the names of the relations?
• What requirement justifies the tax administration? If it is justified, should'nt it be related to a country?
• Is printing some elements really part of the domain model or does it already belong to some user-interface?

Second recommendation: only show elements taht you can reasonably derive from the requirements, and avoid any user-interface related behaviors.

Edit: your final diagram following our exchanges in the comment section represents much better what you wanted to represent initially. You could add the multiplicity 1..* rate for 1 category. You could also add a separator, in order to show classes consistently with a property and operation sections, even if one of the two is empty. The design is still basic, since all properties/attributes are public which is not recommended (but for I suppose you did this to avoid a lot of extra getters/setters in your design).

Alternate approach:

Your narrative describes one single use-case, which is perform tax calculation and consists of entering the calculation data, printing it and sending it. The actors are probably some clerc of your customer and perhaps tax offices.

I find the following candidates for classes chronologically, when reading the narrative: VAT, country, tax rate, income tax, "country-specific tax tables", gross amount, annual income, tax calculation, tax office. Let's have a closer look:

• Tax office is very unclear: is there a network printer per tax office? how is the relevant tax office determined? are there one office per country, or can the organisation be more complex?
• VAT and income tax are very different:
  • for VAT there are different rates per country. The applicable rate is always known, and the calculation is based on the applicable rate and the gross value.
  • For income tax the narrative speaks of country-specific tax tables: this means that the rate might not be known in advance, but depend on the taxable income level. (e.g. in Austria there is a minimum, and beyond it's flat rate; but in France, there is a normal rate, and a reduced rate for the first 500K€). In reality, income tax is much more complicated, since it may also depend on the legal form of the enterprise, or what is done with the income (re-invested vs. distributed), but let's keep it simple for the exercise. The wording leaves an ambiguity whether there is one table per country or several.
  • You could nevertheless generalize the concept of tax, if you'd want, considering in this exercise, that its amount is calculated for a base amount (gross amount or annual income).
• The tax calculation is not fully clear: is it just the user interface, or is the calculation actually some domain object. This would give us:

This would lead to a diagram like: