-1

I am incredibly new to Domain Models and I am trying to build up my understanding. I have created this domain model around a scenario which I will provide. I feel this model is simple and as a result, feels incorrect and might be missing elements I might not have thought of although, I cannot think of what else might need to be included in a domain model given the scenario. The idea is to demonstrate the relationship between real world class entities which I feel I have managed to achieve.

Scenario: Management Application that allows you to create users, projects, companies and issue tickets. The projects are assigned to companies, the users are assigned to projects and the issue tickets are assigned to the users. Tickets have a status which can be changed.

enter image description here

Changes

Implementing proposed changes. I think this is a better way to represent the idea based on the feedback returned, especially in regards to the use of composition. I have also updated the multiplicities to better represent the scenario.

enter image description here

Further changes

enter image description here

Krellex
  • 613
  • 2
  • 7
  • 20
  • 2
    multiplicity between `User` and `Project` seems off. Only a single user can be assigned to a project? Also, the composition between `Issue Ticket` and `User` surely is wrong. I can't imagine that a ticket is made out of users, and that a user is deleted if the ticket is deleted. – Geert Bellekens Oct 18 '21 at 13:19
  • In this particular case I was trying to say that the ticket cannot exist without a user. At ticket creation, a user must be assigned else the ticket will not be created, it would be a ticket that belongs to no one. With this scenario in mind, would the composition still be incorrect? – Krellex Oct 18 '21 at 18:37
  • Composition is about life time responsibility. There are some answers here on SO (some good and some not so good). Your idea however is not correct. – qwerty_so Oct 18 '21 at 21:15
  • The lowerbound of 1 at the User side already makes sure there is always a User connected to a ticket. Composition is about whole-part relations. – Geert Bellekens Oct 19 '21 at 06:27
  • @GeertBellekens This would be the same for Project > Company? The multiplicity would be enough, the aggregation should be removed? – Krellex Oct 19 '21 at 06:29
  • I see that you changed it to a shared aggregation and reversed it's direction, but that doesn't make it much better in my opinion. There might not be a whol/part relation at all here. – Geert Bellekens Oct 19 '21 at 07:13
  • I think I understand what you are saying. But if a child needs to be assigned to the parent before it can be created i.e. Ticket needs to belong to a User at creation, else it cannot be created. However if a user is deleted the Ticket can still exist. This would be an aggregation relationship between the two? – Krellex Oct 19 '21 at 08:13

2 Answers2

1

It entirely depends on the purpose of your model.

Some models might be created to stimulate discussion and further discovery. Some might be required for the senior stakeholders to approve. Some might be for developers to work from. Others might be for marketing material.

Your model is ok for stimulating discussion and further discovery.

Neil W
  • 7,670
  • 3
  • 28
  • 41
  • Thanks for the reply. How could I go about improving the diagram in order to be useful for developers and approval from stockholders. I'm not sure what a diagram, that requires approval from stakeholders might look like. I feel it does well in providing an idea for developers to work from. – Krellex Oct 18 '21 at 11:33
  • 2
    It's a team sport! Speak with the developers. They'll ask the questions and you can go on that journey of discovery of the details with them and enrich the model together as you go. Don't try to create a developer-ready model without developers. You. Will. Fail. – Neil W Oct 18 '21 at 11:57
1

The diagram should stay as simple as possible, but not more.

In this specific case:

  • The two specializations of User might be too complex for the need: a User stays a User, isn’t it? If you really need to take into account differences between categories of users, and especially if the category changes over time, you'd better consider (object) composition over inheritance (or better worded for UML: prefer association over inheritance).
  • The associations might be too simple or incomplete. For example, before an Issue ticket gets assigned to a User, isn’t it also associated to a Project or a Company? It is not clear either if User is also associated to Company (e.g. multi-tenant cloud scenario) or if there is no such association (e.g service provider scenario, where the company is in fact a customer company).
  • Some associations may hide association classes, e.g. do you expect to monitor how many time a user worked on a ticket?
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • 1
    In general, it's not correct to say that "an instance of a class stays an instance of that class for all its lifecycle". This holds, e.g., in Java, but not in general OO modeling (with UML class diagrams). Just consider a class representing a role type, such as `Student`. A person that happens to become a student does not keep being a student for her entire life. – Gerd Wagner Oct 18 '21 at 21:57
  • @GerdWagner Could you explain how an object could change class in UML ? Maybe I missed something, but so far my undestanding is based on: 9.2.3.2 says: "An instance of a Classifier is also an (indirect) instance of each of its generalizations". So in you example, an instance of Student would be an instance of Person. I have not found any evidence that a classifier may change instance or stop being an instance of a classifier. In your example, I'd therefore model Person and Student as distinct class, and I'd see Student as a role that is associated to a Person. – Christophe Oct 18 '21 at 22:15
  • Where have you found evidence of an instance being unable to change its types in UML? – Jim L. Oct 19 '21 at 00:01
  • In general, it is better for dependent things, like user roles, to be associated with independent things, like people, rather than to be made subclasses, precisely because some languages (e.g. Java) make multiple classification or reclassification difficult. UML is ambivalent, though. – Jim L. Oct 19 '21 at 00:08
  • @JimL. That is an interesting thought. I have indeed not found any direct evidence that the type cannot be changed in UML. However, I think this is a consequence of a combination of other clauses, and that changeability would lead to some inconsistency. But this is worth a dedicated question. Meanwhile I removed my debatable statement since it was secondary and mainly there to introduce composition over inheritance. – Christophe Oct 19 '21 at 06:24
  • In general OO modeling, which is not lmited by the implementation-imposed restrictions of OO languages like Java or C#, we may have dynamic classification and multiple classification at the conceptual level in domain models, and possibly also in design models. Only in Java implementation models, we have to get rid of these patterns. – Gerd Wagner Oct 19 '21 at 11:53