I have a class called pet, which is dynamically associated to either 1 dog or cat but not both at the same time.
What's the name for this type of dynamic association? How can I represent this in a UML class diagram while making it clear that each pet is associated to either one dog or cat but not both at the same time?
Is what you're after simply inheritance? Pet seems to me to be an abstract concept, where as Dog and Cat would be concrete concepts. My initial solution in your situation would probably be to have an abstract Pet class (which cannot be instantiated) which is specialized to Dog and Cat (which can).
If you are really keen to have an instance of a Pet which is associated with an instance of either a Cat or a Dog, then you'd probably have to manage this by inheritance anyway. Something like this perhaps:
The wording of your question is bit funny when reading it as a model of the real world (a domain model).
In the real world, a pet is not associated with an animal. Rather, a pet IS an animal. Consequently, the class pets is a (role) subclass of animals, in a domain model, based on the meaning of the term "pet" in English.
The concept of role classes is not very well supported by mainstream OOP languages. An object may play many roles (that is, instantiate many role classes) at the same time (multiple classification) and it may cease to play a role, that is, cease to instantiate the corresponding role class (dynamic classification).
Maybe you are not interested in making a domain model first, before making a (technology-independent) design model, which you may then turn, e.g., into a Java or C# class model.
Maybe you want to jump to a C++ class model directly, without first trying to understand the underlying domain concepts.
You can do this, but I don't think it's a good idea.
Related
I am making a class diagram. I have a Person class and an Address class. I am thinking there is a 'Has-A' relation between the Person class and Address class (Aggregation):
Am I right in marking the relationship as association?
Does it depend on us how we want the model the relationship?
For example, if I have two classes, Book and Library, I could say that Books shall not exist without a Library (composition) or I could say that Books may exist independent of library(Aggregation).
There is no one correct answer. There are many valid ways to model a scenario. In this case you could either mark the relationship between Person and Address as an association (more specifically aggregation), or you could mark it as a complex attribute.
Yes, details like that should be discussed with stakeholders / people who understand the domain you are modelling.
Is the association right?
Yes, you are right: a simple association expresses perfectly that a Person has an Address. Nobody could claim on the base of your narrative that your model would be wrong.
But modeling is a form of communication: You may well chose a different notation to add nuance in what you express, and you may decide for different semantics to tell how you see things in view of your needs.
Does it depend on us? Notation
In our example, you may want to clarify what you mean with the association by giving it a name:
Or you may prefer to clarify the role of the address in the association:
Or in complex diagrams you may prefer the shorter but equivalent property notation, nevertheless keeping in mind that "A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not":
Does it depend on us? Semantics
You could go for aggregation, but I'd strongly discourage it since UML does not define any semantic for it. So there's no benefit compared to a simple association.
You could consider composition. It might in general not be the best choice, as addresses exist independently of the persons. But in an application that creates separate Address objects for each Person, it could reveal how you intend to manage addresses.
Or you may want some richer semantics, for example with an association class to tell that people could have plenty of addresses of different kinds:
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.
Currently I am trying to model a UML diagram for cars. I have the problem that besides the combustion engines also electric cars exist.
When you look at the diagram, you can see that the Golf has the data type Fuel for the attribute consumes, while the e-Golf has the data type EnergyType.
How would you adapt this diagram?
Inheritance is meant differently. You already define consumes an enumeration in the abstract class. Now in the inheriting ones you do not override this attribute but just assign fixed values. Plus you use a wrong notation in that case. It would be rather consumes: Energytype = electrical energy (etc.). This type anyway is superfluous since you would have it in the class type itself. A concrete electric car is of the type you want. So that enumeration would contain the possible concrete class types (if needed at all). Now you should rather concentrate on what the different car types are. The only common thing is probably the chassis which will be defined in the abstract car.
N.B. thinking this way of cars is what the dinosaurs actually do and which is why they have so much trouble. E-cars are much more different than classic cars. Basically you need to go back to the seats for humans inside for the abstract car.
Amendment
could be a way to express a car (there are lots and lots of ways to show variants and it takes weeks and months to get to something appropriate for cars). You see that the abstract car (written in italics) has no attributes but just associations with role names. Some to abstract classes and one to a concrete class (note that this is just something meant as example). The abstract classes just have associations and contain attributes which are agreed to be common to that thing.
Now if you're building some concrete car configuration you will only have concrete classes:
The MySuperNewCar has an electric drive with 4 wheels and 2 leather seats. I repeated the abstract classes in this diagram. But that's not needed (since you probably would already guess so).
So, thats one way to describe a car. There are much more ways which need long discussions. In any way you should get a consultant aboard who's talking UML fluently (in other words who's good at modeling things).
I would advise to use different names for attributes with different types. Instead of 'consumes' you could use 'energyType' and 'fuelType'.
So I'm currently self-teaching myself UML and I took an online quiz to help strengthen my understanding of it.
One of the questions asked:
How do you model the following situation with a UML2 class diagram:
"There are multiple different bird species, e.g. blackbird, thrush,
and starling."
And two available options were:
The diagram on the top is correct (and I understand why), however, the diagram on the bottom is incorrect. Why is this? Since the three birds inherit from the abstract class bird and conform to any abstract methods, aren't they all birds?
There's two possible answers to this I think:
The top is incorrect logically since you can't create an instance of a Bird on its own. Bird is an abstract classification of all bird species. You can only create Thrushes, Starlings and Blackbirds. I'm not sure what a Bird instance would look like, but it would be supernatural.
The bottom is incorrect syntactically because the abstract constraint should be applied after the class's name and type.
Personally I think I'd let the #2 one go (it's a mistake, who cares?) and focus on #1 which is, if I was in the business of birds, more important.
The UML 2.5 spec says on p. 98
The isAbstract property of Classifier, when true, specifies that the Classifier is abstract, i.e., has no direct instances: every instance of the abstract Classifier shall be an instance of one of its specializations.
So whether or not Bird is adorned with the keyword abstract results in the restriction of being able to not/instantiate it. If you need a Bird instance you leave it away. If you want to create an animal index you will probably have the abstract Bird which tells what you need to basically include in a bird's description. But you don't describe it by itself.
In your case, both diagrams are "correct" in general. It just depends on the context you did not explain properly. You can fulfill the requirement with both since there is no requirement that you may not instantiate Bird.
The requirement in the quiz says:
There are multiple different bird species, e.g. blackbird, thrush, and starling
But it does not says anything about what information you should hold about the bird species. So my first assumption is that the user would only be interested in the type.
The UML diagram:
is a valid solution for this requirement.
The two options in your quiz are also both valid solutions depending on how you look at the requirement. The requirement gave three examples which are all modelled explicitly in both solutions. "e.g." means there could be other birds and this fact is better described with the first solution. In the second solution you can have no instances of "Bird" that are not in the list of examples.
But this solution would only make sense if you could have some attributes and operations which are not shown - IMHO the minimum would be to keep track of the bird type - it is very awkward to retrieve this from the class name in most implementation environments.
Personally I do not think it is a good way to explain inheritance with such examples as in your quiz. Inheritance is costly in implementation (e.g. in most programming languages you end up with separate source code files per inherited class) and this cost should give you a certain benefit. This is mostly the case when the things to be depicted differ in theie attributes and behavior and you need different implementations. "Blackbird" and "Bluebird" might differ only in color (the color attribute is the discriminator). IMHO in this case it is better to have:
than
I have a question about modeling associations between classes and interfaces. As far as I know, an interface specifies what an object can do; without providing the state or functionality (When to use an interface instead of an abstract class and vice versa?). Also, my book on OOAD (Object Oriented Modeling and Design by James Rubaugh)states that an association describes a group of links with common structure and common semantics, between object instances.
Now, suppose I have the following entities:
1) ICar Interface: Defines the operations a car can do
2) BMW : A class that realizes the ICar interface
3)IWheel : An interface defining the wheel capabilities
4) LuxuryWheel : A class that realizes the IWheel interface
Now, to model the relationship between BMW and LuuryWheel, which of the following do you think is correct, in a design perspective? I have shared my thoughts on each one
A) Create an association between ICar and Iwheel. BMW class can create concrete instances of LuxuryWheel class. This is highly flexible but couples car's capabilities with Wheel' s capabilities. Also, the definition of association says the relation is between instances.
B) Create an association between the BMW class and LuxuryWheel class. Solves the particular problem; but tightly couples BMW to Luxury wheels
C) Create an association between BMW class and Iwheel interface. This way BMW can use any type that realizes the IWheel interface.
Option C) looks better to me. Please share your thoughts.
I agree with Vladimir that, since you want to model cars and wheels with the help of interfaces, the association between them (which is actually a composition) should be modeled between the interfaces ICar and IWheel, as in the following diagram:
Since the classes BMW and LuxuryWheel realize the interfaces ICar and IWheel, they also need to realize/implement this association/composition, e.g. with the help of a 4-valued reference property BMW::wheels, or with the help of 4 different reference properties in BMW: leftRearWheel, rightRearWheel, leftFrontWheel, rightFrontWheel.
In order to get robust solution, create association between ICar and IWheel interfaces. It is possible , because interfaces are types. Connecting interfaces using association means, that any instance of classifier which realizes ICar interface must be associated to instance of classifier which realizes IWheel. You also define abstract classes for car and wheel and make association between them. The result will be similar.
Simply speaking a car can support different type of motors. So you must think to an additional class that permit to add different type of motors. In this case relation between interfaces or classes must be do it with some additional interface.