The problem is the following: A race has participants and the race has a starting line ordered by a number assigned to the participants. Each participant can use a vehicle and need to registry the information of the vehicles. So the information are: Race: name, location, time, ... Car: race start number, year of manufacture, model, ... Bike: race start number, model, wheel size, ... Horse carriage: race start number, number of horses, ...
What would be the best way to create the class diagram and get the starting line with the vehicles ordered by the race start number?
Case A: raceStartNumber are distributed in different Entities. It would be necessary to do a mapping by raceStartNumber and order the elements obtained.
Case B: All the vehicles would be ordered on the starting line, but the vehicle class would always have two associations such as null.
So, which case do you think is better? Would there be any other way to do it?
There is never a best solution. You always have tradeoffs, just that some might be less significant.
Your 2nd example is just wrong in that you use composite aggregation rather than generalization. You would need an open triangle instead of the diamond and omit the multplicities.
Regarding the options you should study Composition over inheritance.
As noted by #Ister your first approach has also a major flaw. This is that the raceStartNumber is an individual property of each vehicle. And there's nothing that constraints them to be unique.
Generally you will not model these id properties unless you have some requirement. The id of objects is implicit (in programming languages it's usually the memory address of the instance).
I will not go into more details since this site is not meant for reviews.
Related
I am modeling a course management system with the following requirements:
2 roles: Student can choose course; Administrator can make courses and then make groups for course, based on list of students who chose that course and based on list of tutors for that course.
In one course students can go only in one group, and teacher can teach more groups in one course. But student can go in 1 or more courses.
This diagram is a sketch of a class diagram. There is too much redundancy and I don't know how to solve it. Please help me to model my domain and ignore the mistakes in UML syntax or multiplicitycardinality.
More precisely, how can I make association between students and groups, and tutors and groups without redundancy, because I already have associations with courses?
Let's focus indeed on the domain model:
The direct association between Student and Course corresponds to the student's choice. The choice may or may not be fulfilled. And if it is fulfilled, it's only when the groups are made.
The indirect association between Student and Course via Group corresponds not only to fulfilled choices, but also to practical organisation of courses.
The two paths that exist are not redundant, but the representation of two different realities.
For the tutor, it's similar: the direct association tells what the tutor is able to do, and the indirect one tells what he/she has to do. So the model looks fine in this regard.
In some cases you could simplify (hint: not here)
In some situation a choice/plan can be combined with a fulfilled choice/implementation, by merging associations. For example, if there wasn't your group requirement, you could have only one association class between Student and Course and use a state of your association class to make the difference. But this will not work here, given your requirements.
You could also trick with the requirements. For example, you could have for every course a dummy group that corresponds to students that chose the course and are not assigned to a group. But shortcuts in the design can (and often will) backfire. Here for example, it would add complexity (need to create a dummy group for every course, make a difference between the dummy group and the real groups in almost every activity). Moreover, this trick would constrain your solution. For instance, not having an association class for the choice will prevent from enabling the students to prioritise their courses or providr other elements that facilitate the creation of groups that do not yet exist (e.g. pre-existing skill level).
In summary: your model should primarily aim at addressing the requirements. Premature optimisation is the root of all evil, in modelling as well.
I have short question about class diagrams. In my book we have class Person and class Gender and agregation arrow between them(with diamond pointing to person). Now, in general when I want to decide whether we have agregation or not I am using one of these two rules:
1.When you destroy class that is whole, than part can exist without it;
2.Class that is part in agregation relation, can be mutual to one or more wholes.
Now if we look at this example and rule number 2, it is OK, because one gender is mutual to one or more persons. But for the first one, if there is not person, than we can't talk about gender right?So I would set composition here. Probably I am missing main difference between these two. Any help is appriciated.
In general
Your rule about when using aggregation is not wrong. But it's unnecessarily complex. There is a simpler much simpler rule about when you'd better use aggregation: never.
This may sound provocative, but the hard truth is that the meaning of aggregation is not defined in the UML specifications, which makes it ambiguous and subject to a lot of unnecessary time-consuming debates:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. (...) Precise semantics of shared aggregation varies by application area and modeler.- UML specifications 2.5.1, page 112.
I know, it comes as a shock. For years in my career, I have myself selected very carefully aggregation whenever there was a part-whole relation with non-exclusive ownership. But when I came accross James Rumbaugh famous quote, I challenged my own assumptions and realized how vain and subjective this quest was:
Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.- James Rumbaugh in Unified Modeling Language Reference Manual, chapter 14.
So, whenever you have aggregation in a model, you could simply replace it with an association without real loss of information.
In your specific example
The association: Person ----- Gender expresses perfectly that a person has a gender, and that several persons can share the same gender.
If you want to be super-accurate, you could use the dot notation (with a small dot on Gender side). This would convey the information that Person owns the end of the association.
Composition would definitely be wrong here, because it's an exclusive ownership and no two persons could share the same gender.
Aggregation is ambigous: what is the whole, what is the part? If gender is a part, wouldn't character be a part as well. And what with the name, then ?
A final remark: if you want to implement this with Person having a gender:Gender property (an OOP mechanism called "object composition") the, you don't need aggregation (even if it's a popular practice).
First, don't think i'm trying to get the job done by someone else, but i'm trying to design a class diagram for a domain model and something I do is probably wrong because I'm stuck, so I just want to get hints about what i'm not doing correctly to continue...
For example, the user needs to search products by categories from a product list. Each category may have subcategories which may have subcategories, etc.
The first diagram I made was this (simplified):
The user also needs to get a tree list of categories which have at least one product.
For example, if this is all the categories tree:
Music instruments
Wind
String
Guitars
Violins
Percussion
Books
Comics
Fiction
Romance
I can't return a tree of Category which have at least one product because I would also get all subCategories, but not each sub category has a product associated to it.
I also can't remove items from the Category.subCategories collection to keep only items which have associated products because it would alter the Category entity, which may be shared elsewhere, this is not what I want.
I thought of doing a copy, but than I would get 2 different instances of the same entity in the same context, isn't it a bad thing ?
So I redesigned to this:
Now I don't get a collection of child categories I don't want with each Category, I only know about its parent category, which is ok.
However, this creates a tree of categories which is navigable only from the bottom to the top, it makes no sense for the client of ProductList who will always need a top -> bottom navigation of categories.
As a solution I think of the diagram below, but i'm not sure it is very good because it kinda dupplicates things, also the CategoryTreeItem does not seems very meaningful in the domain language.
What am I doing wrong ?
This is rather an algorithmic question than a model question. Your first approach is totally ok, unless you were silent about constraints. So you can assign a category or a sub-category to any product. If you assign a sub-category, this means as per this model, the product will also have the parent category. To make it clear I would attach a constraint that tells that a product needs to be assigned to the most finest know category grain. E.g. the guitar products would be assigned to the Guitar category. As more strange instrument like the Stick would get the Strings category (which not would mean its a guitar and a violin but just in the higher category.
Now when you will implement Category you might think of a method to return a collection of assignedInstruments() which for Guitar would return Fender, Alhambra, etc. You might augment this assignedInstruments(levelUp:BOOL) to get also those instruments of the category above.
Generally you must be clear about what the category assignment basically means. If you change the assignment the product will end up in another list.
It depends on the purpose of the diagram. Do you apply a certain software development method that defines the purpose of this diagram in a certain context and the intended readers audience?
Because you talk about a 'domain model', I guess your goal is to provide a kind of conceptual model, i.e. a model of the concepts needed to communicate the application's functionality to end users, testers etc. In that case, the first and the second diagram are both valid, but without the operations (FilterByCategory and GetCategories), because these are not relevant for that audience. The fact that the GUI only displays a subset of the full category tree is usually not expressed in a UML diagram, but in plain text.
On the other hand, if your intention is to provide a technical design for developers, then the third diagram is valid. The developers probably need a class to persist categories in the database ('Category') and a separate class to supply categories to the GUI ('CategoryTreeItem'). You are right that this distinction is not meaningful in the domain language, but in a technical design, it is common to have such additional classes. Please check with the developers if your model is compatible with the programming language and libraries/frameworks they use.
One final remark:
In the first diagram, you specified multiplicity=1 on the parent side. This would mean that every Category has a parent, which is obviously not true. The second diagram has the correct multiplicity: 0..1. The third diagram has an incorrect multiplicity=1 on the composition of CategoryTreeItem.
From my perspective your design is overly complex.
Crafting a domain model around querying needs is usually the wrong approach. Domain models are most useful to express domain behaviors. In other words, to process commands and protect invariants within the correct boundaries.
If your Product Aggregate Root (AR) references a Category AR by id and this relationship is stored in a relationnal DB then you can easily fulfill any of the mentionned querying use cases with a simple DB query. You'd start by gathering a flat representation of the tree which could then be used to construct an in-memory tree.
These queries could be exposed through a ProductQueryService that is part of the application layer, not the domain as those aren't used to enforce domain rules or invariants: I assumed they are used to fullfil reporting or UI display needs. It is there you could have a concept such as ProductCategoryTreeItemDTO for the in-memory representation.
You are also using the wrong terms according to DDD tactical patterns in your diagrams which is very misleading. An AR is an Entity, but an Entity is not necessarily an AR. The Entity term is mostly used to refer to a concept that is uniquely identified within the boundary of it's AR only, but not globally.
CONTEXT: I have an abstract class Student. From this class I derive three concrete classes SchoolStudent, UnderGradStudent, PostGradStudent. I have another class Vehicle. A school student must NOT drive a vehicle however, an undergrad or a postgrad student may or may not drive a vehicle.But every vehicle must be driven by somebody hence the Vehicle class has a reference to a student.
PROBLEM: I have association between classes UnderGradStudent & Vehicle and another association between PostGradStudent & Vehicle. However, I am a little confused about the multiplicity.
As I understand the problem, the UML class diagram should look something like this:
However, I suspect the above diagram suggests that each Vehicle will have one UnderGradStudent as well as one PostGradStudent.
Is the above diagram correct as to what I want to model corresponding to the context?
As you've drawn this UML diagram, it implies (but does not say correctly) that a Vehicle must be driven by both one UnderGradStudent and one PostGradStudent. It also implies that an UnderGradStudent can drive any number of Vehicles and a PostGradStudent can drive any number of Vehicles (at the same time). I don't think that's what you intended. The reason I say "implies" is that you have overlaid two associations on one end. Last I checked, that is invalid UML.
I think you wanted to say that a Vehicle may be driven by up to one Undergrad Student or Postgrad Student. To say that, I recommend the following model:
What this says is:
A valid instance of Student must be one of School Student, Undergrad Student, or Postgrad Student (and not multiply classified)
A valid instance of Allowed Driver must be one of Undergrad Student or Postgrad Student (and not multiply classified)
A Vehicle can be driven by up to one Allowed Driver (at a time)
An Allowed Driver drives up to one Vehicle (at a time)
This describes a valid situation at any point in time, which is really useful. Think of it as a way to evaluate the validity of any frame in a movie.
If you need to record all the drivers of every vehicle ever, you would need to make many changes. A Person actually plays the role of a Student (among other roles, usually), and that role can change over time. You would need to record the start and end time of every role change and the start and end time of every driver / vehicle change. Think of this as recording all the frames in a movie, but without the ability to express the validity of any given frame in the movie. You lose that ability when you relax multiplicities.
You can get the benefits of the "single frame" and the "whole movie" approach by combining all of the associations I mentioned.
Your problem will easily be solved by using a 0..1 multiplicity near the *Student classes from the Vehicle. This will tell the reader that both are allowed to have a related optional vehicle. To avoid both using the same car you need to attach a constraint like this:
Alternatively you can do it the following way:
I'm not good in writing OCL but you could formalize the constraint as well.
I have a problem with my UML diagram and I'll be happy if you help me. I have relationships like
Object A (1)<>----(0..*) Object B
Object B (1)<>----(0..*) Object A
and I'd like to unite them. How can I do it? Thanks a lot.
Can you please define the term "unite them"? What exactly would you like to achive? An example could probably help.
Meanwhile, I can try to guess and give you two possible solutions. Maybe they help you to rephrase your question or even to find the solution:
In the Solution 1, I've just made a single relationship that describes both of yours. This can be used if there is only a single and clear criterion of the linkage between the objects. A typical n..m relationship. Objects A will each hold a collection of related objects B and vice versa.
For example a Person (A on the diagram) can join several Clubs (B) and a Club can have several members - there is only one logical relation behind this situation - membership.
Solution 2 is where there are actually 2 different ways to relate between those elements, each one 1..n. So, A holds a collection of Bs and B holds collection of As, but they are unrelated.
Extending the same example - a Person (A) can join only 1 Club (B) and a Club can have many members and hold their reference (col_a on the diagram). In the same time, a Club can have only 1 owner, and a Person can own several Clubs (col_b). Here we have two different logical relations - membership and ownership.
Of course, other multiplicities and navigabilities are possible, this is just an example to give you an idea.
Does one of these situations sound like yours?
UPDATE (after the 1st comment):
So, here is the updated solution 1:
This is an aggregation used here, and this is more a Group-member relationship. It suits perfectly the description of my first solution up there. Members (B) can be "shared" between the Groups (A) and Gruop does not have any special control over their lifetime.
The real Whole-part relationship would employ composition instead of aggregation (visually depicted with a black diamond, instead of a white one). Its semantics it that Whole object has a full control over the life of the contained objects (parts). In consequence, the Parts cannot be shared between several Wholes and must be destroyed if the Whole itself is destroyed.
Now you just need to find out which situation describes your problem the best, pick-up on of this solutions and eventually fine tune the multiplicities.
Here is a way you could represent this scenario in UML.
One server can contain 0 or many Functions (ie. aggregate relationship).
Each function must belong to one server. Or if it is a distributed function then it can belong to many servers.