I've a question regarding the following diagram
My Qustion is in the relation between driver - Car and Passenger and Cars.
1- The * at driver end means that a car can be driven by many drivers, which is a relationship between the both classes at the lifetime of the system.
2- In the other case the relation ship between car and passengers are realtime relation ship, that at maximum only 0-7 passengers can be on the same car.
Did i get something wrong?
How should i think about the relationships, is it realtime relationship between objects or relationship on the lifetime of the car
That actually looks like nonsense :-)
It means that a Driver operates 1 or more Cars. Multi-tasking might be some new capability of human beings (I doubt that). So driving two cars the same time will be tough, but then * cars?
The drawback with such class diagrams is that you can not see what kind of relation is meant. I assumed operates but it may well mean owns. A role name would clarify this ambiguity.
Both current as historical relations can be expressed using associations.
In the case of Driver the current driver, and everyone who ever drove the car can be expressed using two different associations.
A Car can only have one CurrentDriver, and a Driver can only drive one Car at a time, but there can be many HistoricalDrivers who may have driven many different Cars over time.
The fact that you model Engine and Wheel as aggregations somewhat surprises me. An aggregation is in fact a shared AggregationKind, and I've never seen an Engine or a Wheel being part of two cars at once. I don't really see a reason why you would not use compositions here.
Related
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).
I am trying to create a system for managing vaccines against covid.
The system supports 3 different vaccines but each citizen can only get one and the system has to differentiate between the citizens who are older than 65, the AstraZeneca vaccine cannot be given to people older than that age.
Below I tried to create a basic UML class diagram. However I'm pretty sure I'm missing something since the vaccine should be also connected to the AstraZeneca class?
The diagram is confusing, since it only shows associations, but regrouping them in an unexpected manner. It looks more like a decision tree than a real class diagram.
First improvements you need to consider:
Pfizer BioNTech, Moderna and AstraZeneca are each a Vaccine: you should show this with a generalization from the specific vaccine to the general vaccine.
age 65+ seems not a good candidate for a class: in most OO languanges an object of a class keeps the class during its whole life. But citizen do not change class at 65. Age is a (derived) property of Citizen. The wording "astrazeneca vaccine cannot be given to people older than 65" moreover is an expression of a constraint.
Finally, if you manage vaccines, you need to manage also shots. When you write "citizen can only get one" you probably mean "one kind": the vaccines that you mention do in principle require 2 shots. And in most countries around the world, the two shots have to be of the same vaccine, which is another contraint. The remaining question is then if 65+ constraint applies to the first shot or the second?
This would lead us to a diagram that looks as follows:
Additional thoughts:
You could manage the shots by making the association Vaccination an association class.
There is an issue in the regarding the open/closed principle: if you'd add new vaccines, you might have to add different constraints on some. Alternatives:
Make Vaccine an abstract class (or an interface), with some more operations that need to be implemented by the concrete classes: getRequiredMinAge(), getRecommendedMinAge(), getRecommendedMaxAge(), getrequiredMaxAge(), instead of hard-coding the constraint.
Use a method Vaccine::checkCompatibility(c: Citizen) transfering the constraint verification to the Vaccine class
One could wonder if subclassing the vaccines is really required.
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've been working on putting together a rough conceptual model of an E-commerce website that basically allows users to resell concert tickets. It's purely conceptual and not something i'm actually making!
Anyway I've put together a domain model and I was hoping for some feedback. I've made class model before and modelled databases but found it quite difficult differentiating between them.
I've seen the words rich and anaemic thrown around a lot and I believe my model is anaemic. Would simply notating more behaviour make it rich?
Are my relationships correct? Have I correctly used my aggregations and compositions?
I would love any suggestions on improvements.
Thanks in advance.
You have the right idea, but some of the UML is incorrect and a (business) domain model shouldn't have a User.
Some examples of problems I see:
A User is probably not a Bidder and a Seller; rather, a User can play a Role of Bidder or Seller.
Generalizations do not have multiplicities.
It makes no sense to me for a Ticket to HAVE an Artist. A Ticket generally allows a Person to be admitted into a Show, and an Artist performs at a Show.
Compositions can have at most one composing class.
I would remove compositions and aggregations from a conceptual model. Otherwise, I don't think it's anemic as a conceptual model. The next step would be to add behavior to it as an OOA model and generate some code from it. Please see Leon Starr's How to Build Articulate UML Models article for more help.
As Jim says, you're not entirely clear on how composition and aggregation work. This example might be helpful. Tom Pender (author of "The UML Bible") uses it in his classes.
Suppose you have a car factory and you make cars. A car has an engine. In order to be a car, it has to have one; if you haven't put it in it isn't a car yet. But also, the engine is part of a car. The only reason to have the engine is to put it in the car. So, the engine has no identity or lifetime independently of the car. That's composition.
Now, suppose you have a junkyard. Same car, many years later. You can sell any items off the car and it will still be that car. If you sell the engine, the car will be the car without an engine. That's aggregation.
So, in a manufacturing context, a car is a composition of parts, and in a junkyard context, a car is an aggregation of parts. The point is that in composition, the lifetime of the parts is tied to the lifetime of the car, and in aggregation, it isn't.
Looking at your Ticket object, I would say that Venue and Artist are in a composition association with it. While the Venue and Artist certainly are not dependent on the ticket for their existence, you have to keep in mind the context. You're doing e-commerce. Your artist and your venue interact with the e-commerce system via tickets, and not in any other way. So composition. On the other hand, tickets are most certainly NOT composed of Orders. If that were so, there would be no such thing as an unordered ticket! So, tickets and orders have a simple association, not aggregation or composition.
As for your bidder and seller, they are users. So you have your inheritance arrows backwards. If Bidder and Seller have specialized user behavior that is independent of one another (e. g. "OfferBid" and "AcceptBid"), then they need to be modeled as specializations of the User class. If they do not, then they are just two users that are acting in different roles, and can be modeled as such.
I have a Proffesor table in a database. I would like to create an UML diagram for the code-behind part.
The class structure would be:
- a Proffesor class that maps the information from the database table (id, first name, etc)
- a ProffesorDAL class which connects to the DB and queries it in order to add,remove,update Proffesor instances
- 3 forms which add/delete/update proffesors, by accesing the ProffesorDAL class
I thought that the forms-ProffesorDAL relationship is a composition relationship. Is this correct?
How about the ProffesorDAL-Proffesor relationship, could it be aggregation or is it just association? What's the best UML relationship for the forms-Proffesor relationship?
Thanks!
I'd start by assuming association and from there to analyse and design if there should be a stronger relation between the two.
My question goes "Does it own it". Example I'd say a Car owns 4 wheels (among a long list of other items).
In my standard design I have a BLL between my UI and DAL. I start by assuming a loose association between my three, later I reach the conclusion that the BLL and DAL are somewhat closely connected and could benefit from a strong tie.
As for the Professor class, I assume this to be a Model class. Model classes I only have a loose connection / knowledge to - meaning they appears only as parameters (association). My DALs do not have a strong connection with my Model classes (aggregation). They are but Message bringers, complex ints and bools.
The UML Aggregation relationship is almost worthless - it creates far more confusion than value. It has only one useful property, namely that if used in a recursive relationship, the resulting object structure is acyclic.
It's really not worth getting hung up about. My advice would be to use a simple binary association and concentrate on getting the cardinality right. That's a lot more useful and valuable.
hth.