Question: What is the association error in the diagram and explain how it can be changed so it
avoids duplication?
What I think: I suspect inheritance between motorbike and cycles as motorbike is not a "kind of" cycles and aggregation engine and motor vehicle as the motor vehicle is not a part of the engine. However, there should only be one error.
I am not sure a motor bike is not a cycle because a bike can be a bicycle which is a cycle no ? Note also a bicycle can have an electric engine to assist : I have one, and it is not considered as a motor bike/cycle in the law. Anyway warning my English is low level.
Yes the aggregation is in the wrong direction, must be MotorVehicule <>---> Engine. Note it must not be a composition because the destruction of a vehicle does not imply the destruction of its engine(s). Note also a vehicle can have several engines, so the multiplicity is * rather than just 1. I prefer to not use 1..* because the engine(s) can be removed and even without engine the vehicle cannot move by itself it is still a motor vehicle.
The fact a FuelType can be 'electric' is bad for me because the electricity is not a 'fuel', better to rename FuelType to EnergySource or something like
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).
Please Look at the following example:
1) The chairs are made of wood .
2) Paper is made from trees .
3) Biogas is produced by the fermentation of waste.
4) Asphalt is produced through the refining of petroleum.
Should these be Composition or Dependency?
In general
You can exclude UML composition: composition implies an exclusive ownership. But chairs are not the only products made of wood.
Dependency is either too much (once the biogas is made, there is no dependency to waste anymore) or not enough (the wood of the chair is part of the chair; it's a stronger relationship than a need-to-know-about).
Moreover it is not clear if you want the Chair to be a class on its own or an instance of a class product.
Specific cases
"Made of" expresses a relationship with parts that make a product. A typical pattern here is the bill of material. The relation is a simple association. Some people tend to use UML aggregation, but UML specifications do not define precisely the semantics, so leave it out to avoid ambiguity.
Here a (very simplified) diagram:
"Made from" expresses a transformation process, where some of the original products disappear in the process and others are created. Paper is made from cellulose which is extracted from trees. But the original tree is not in the sheet of paper.
Typically in process industries, like chemicals, this is represented by a "recipe", which is a sequence of inputs (waste) and operation to obtain products (biogas) and co-products (fermented residual waste). In other industries, this is represented by a "routing" that is a sequence of operations performed on a BOM (in this case, the BOM would not only contain components as previously shown, but also raw products that are transformed by the operations in the routing).
I will not show a diagram because this is quickly very complex, but again, it'll use simple associations.
In the end, "made of" and "made from" would both be represented in UML with associations. But only the semantic that you attach to it will change.
I don't think that any "made of" is represented by some static relation. To make a wooden chair it just Depends on wood. There is no other relation here because you have some complicated process to turn wood into a chair. Or a tree into paper. Or anything else of your choices. In order to describe the relation you would need to describe the process. This is possible using activities. You could as well descibe physical components with UML. But that would take us too far apart from your question...
You might search for answers on composition here. But even these can be looked at controversial. Modeling reality yields a model. Which is not reality.
Your question highlights the difference between an ontology and an information model or application design. For example, in a conceptual ontology (which accounts for necessary and possible situations in the world rather than for data formats of observations and measurements), every person has a mother. In a particular database or application, that knowledge is usually irrelevant. What stuff is made of and how it is produced belongs more to a conceptual ontology, for which UML is not quite expressive enough. This is why languages such as First Order Logic (FOL) and OWL are used instead, and why some tools (such as my company’s) plug holes in UML. (One example of a hole in UML is the inability to express exactly the intersection of two classes.)
I answer this picture with composition Car 0.1 - Engine 1.1.
Is it true?
Can someone explain about relation Car and Engine?
The question is somewhat confusing since the title mention composition, but not the question you try to answer in the blue box.
We can deduce from the statement in the blue box:
"A Car has exactly one Engine" means 1..1 on the Engine end of the association.
The fact that a Car has an Engine and is not an Engine eliminates option (c), since the generalization represents an is-a relationship.
"An Engine has at most one Car" means 0..1 on the Car end of the association.
But "at most" implies that it could be less, so in other words, you can have an Engine with no Car. This makes option (b) somewhat ambiguous, since 1) the composition implies Engine to be owned by a Car which is responsible for its existence and storage; 2) nevertheless UML allows a part to be removed from the composite and survive independently (see note page 110 that clarifies this point); 3) but the composition symbol might mislead readers about the responsibilities regarding detached parts.
This leaves us options (a) and (d):
option (a) technically fulfils the requirements: the composition in that diagram says that Car cannot exist without an Engine, but the Engine can exist without a Car. However the semantics of UML composition say it is a part- whole relationship, where then Engine would be the whole and the Car the part. This is nonsense, which eliminates option (a)
option (d) technically fulfils the requirements: it is a normal 0..1/1..1 association. The open arrow says that this association is navigable from the Car to the Engine. It leaves unspecified whether the association is navigable in the opposite direction. The navigation is additional information which is not in the narrative, but it doesn't contradict it.
In conclusion, option (d) is the best one that validly fulfils the requirements. It just adds some more information about the association.
Option (b) would be acceptable, but does not appear a natural use for composition in view of the perceived ambiguity for some reader regarding the responsibilities for detached parts.
How to draw a component diagram where the same component is used in multiple places?
Do I simply draw the same component twice?
You are not clear about the use of instances. Components are just blueprints you can use and re-use.
In this example we use a Motor which is associated with either a Boat or a Car. It's an (abstract) component which means that the imagination cloud will include gas, diesel, steam, rubber band, electrical or any other kind of motor. The context where this is used might fence this a bit more. But it's definitely not meaning the motor in your personal car.
As you see this Motor can be re-used in the model to be associated with a Boat or Car. Also note that it's not clear here whether it's used for driving or to remote control the back mirror.
Now for something more concrete.
The Motor and Car are now two distinct physical things. Re-using the Motor with this serial number somewhere else would mean you could no longer use it in this Volkswagen.
If you have an interface between things you can re-use the same instance (though not at the same time)
like the above wheel could be easily re-mounted on different cars with the same mounting holes. (Don't bother that there's only one wheel for the car.)
Just as thought food: you can also use Generalization with components. E.g. you can classify different motor types. Components are not so much different from classes. It's more or less just that components are a cluster of different classes working together.
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.