umldomain-driven-designabstract-classclass-diagramdomain-model

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


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:

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: Solution for first Task:

First Update:

Solution for first Task:

Second Update:

enter image description here

Could someone help me with this? Thanks :)


Solution

  • 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:

    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:

    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:

    This would lead to a diagram like:

    enter image description here