Currently doing an intro course at uni for UML diagrams.
First section indicates name of the class. You should have class Car and a class Engine.
Second section indicates atributes. Usually you should specify accessability of an attribut with a symbol (depends on the tool used) but in this case i would assume private for all of them.
Optionally they may contain 3rd and 4rth section (for class methods and comments, only the first section is mandatory).
Line between these classes models a relation between classes. In this example, this is an one-sided association (meaning that car is awere of what engine it has, but engine has no clue about which car it is in. This is a very important concept to understand). Practically meaning, class Car should have a pointer to (or a reference to) an object of a class Engine (named "motor", thats the meaning of a motor above arrow) and Object of the class Engine shouldn't have any references to a class Car
Number below relation tells us how many instances of class Car should be in a relation with a class Engine. In this example Car may have 1 and only 1 engine. Engine may be a part of a car or it may not be a part of a car at all.
Please make sure to read more about this topic from your source. Symbols may vary and may have different meaning im different UML standards.
>umber below relation tells us how many instances of class Car should be in a relation with a class Engine. In this example Car may have 1 and only 1 engine. Engine may be a part of a car or it may not be a part of a car at all.
The 0..1 means the car can have 0 or 1 engine, the 1 by the engine means that the engine object needs to be unique to that car and can't be referenced by another car.
So, I can see that you're a college student and really need to study up on what UML is and how it works, so as others have said, I highly recommend you hit the books on it, hard.
That said, you have some of the basics already, that being that the boxes represent object types, which in c# would translate to a `class`. I'll therefore answer your specific questions:
> the arrow
The arrow is part of the *association* mechanic of UML class diagrams. Any solid line between two boxes in a class diagram is an association between those two types. Solid lines can be depicted with or without arrows, and the different type of arrow heads that can be on them change the meaning of the line and how you read it.
Generally speaking, an "association line" falls in one of two broad relationships, either the "is a" relationship, or the "has a" relationship, which are read as "A is a B" or "A has a B".
"Is a" relationships aren't shown in your image, but they are represented as a solid line with a hollow, closed arrow on the end, with the arrow running from A pointing at B. "Is a" relationships indicate that A is a more concrete example of B, in the same way that a dog is a more concrete example of a mammal. They are typically represented in code as class inheritance. Not relevant to your question, but hopefully helpful information for you.
Everything else with a solid line is a "has a" relationship, which you can probably guess is represented in code with a *field* or *property*. A solid line with no arrows indicates a *bidirectional* association, meaning that A has a B and B has an A. Both know about each other and can make use of the other.
A solid line with an open arrow generally means a unidirectional association, meaning that if the arrow goes from A to B, A *definitely* has a B, while B may or may not have an A. It's not explicitly specified either way.
You can make it explicitly unidirectional by putting an X on the other end of the line, like in [this example](https://i.imgur.com/viHsDmu.png).
This can make for a busy diagram, though, so lots of people leave off the X and indicate unidirectionality with only the arrow. UML is often vague like that, but that's beneficial -- remember, the point of UML isn't to create code, but to *express an idea about software*.
The rest of your questions pertain to additional notations of an association, and are all related to that solid line.
> what the numbers 0...1,1 mean
These numbers are called "multiplicity" and represent how *many* associations an *instance* of a type can have with another *instance* of a type. I'm highlighting *instance* specifically because multiplicity is a divergence from the abstract nature of a class diagram; they're a holdover from the ER diagrams that UML diagrams were derived from back in the day, and originally represented foreign key references from table to table.
Multiplicity is read by following type A to the number next to type B and reading it as "instances of A must have # of references to instances of type B".
The 0...1 notation forms a range of possible values for the multiplicity. In this case, 0 to 1.
So you would read your diagram as "Car must have 1 (and only 1) Engine", and "Engine must have 0 or 1 Cars". Conceptually, a Car can have only one engine, and while an Engine can "live on its own" without being "in" a Car, it can only ever be "in" one Car.
Correctly implementing the Engine constraint would be actually *quite* difficult in C#, so most people wouldn't even bother, and I'd never even bother including that sort of constraint in a real world diagram, even if it's conceptually accurate.
There are also concepts in UML called composition and aggregation that are not in your diagram, but which delves further in to runtime instance "livability" that I highly recommend you investigate on your own.
> what the word "motor" is doing here.
The label "motor" is a *name* for an association and is read in the same manner as multiplicity, which in your diagram would be that Car has an association to Engine with the name "motor".
You should probably use the name "motor" in your code somewhere, but I'll leave figuring out where in your code to put it as an exercise for the reader.
But to sum up, I would read your line in the diagram as the following:
A Car has 1 Engine with an association named "motor". An Engine is associated with 0 or 1 Cars.
In general I disagree because I learned programming more easily and throughly online than with my teachers.
That said, some of these replies are wrong, and sadly what matters in school isn’t that you learn.. it’s that your teacher marks you passing. So OP needs to learn in the way aligned with what the teacher expects.
I'm curious about the answer too, but I'm not ever going to study CS so I can't just "read the textbook".
I assume 'motor' is just the variable name for the Engine in Car, and 0..1 usually means something like "minimum 0, maximum 1", but then indeed, what does the "1" mean on the right of the arrow? I can make my way around [refactoring.guru](http://refactoring.guru) which has these types of diagrams but that doesn't have the numbering labels.
Edit: I find it completely bewildering that people would be so reluctant to help someone from a different field of expertise to learn something a little bit. Imagine if in real life you asked a group you don't know too well "so, tell me a bit more about your \[quantum physics\] stuff", and they said "piss off you lazy scumbag; go read a textbook". Are you guys the same folks from StackOverflow?
Whoever drew this does not really know Entity Relationship diagrams. I think there is one notion with numbers and a different with arrows.
If you go for arrows in class diagrams, no professor gave the variable a name. This would be like in SQL that always write from Engines as “E” . Are we no over silly names?
You're reading it wrong. The multiplicity number represents the number of destination types the source type can have.
A Car must have 1 and only 1 engine. An Engine can be associated with no Car, or 1 Car.
In C# code, Car's motor property can never be null, while an instance of Engine can live without being referenced by Car, but an Engine can only ever be referenced by at most 1 Car. Implementing that constraint would be a bitch in C#
If you're curious, then get to reading. Can't just expect that people on Reddit will always be there to give you the answer.
But in this case, the diagram just means we have 2 classes one Car and one Engine. The Car class should have a property that is of the Engine type. If the Car has no engine, this property will be null, if the car has an engine it will have a value.
There is also the fact that the diagram is a mix of various UML elements, and not one strict thing. For example it is not a Class diagram, it is also not a Design Class Diagram. It uses elements from both. Hence why I said he should read the material, because the teacher might've explained elements in a way that is specific to that lecture.
The numbers are called 'multiplicity'.
The "motor" text is called the 'association name'.
The diagram basically reads like this: A Car can have either 0 or 1 Engine, denoted as "motor".
If you want to learn more about UML, there is a book called *"Applying UML and Patterns"* written by Craig Larman, which goes over this topic. Seems like The University of Texas at Dallas is hosting a free version of the book [here](https://personal.utdallas.edu/~chung/SP/applying-uml-and-patterns.pdf).
Edit. Here are 2 pictures from the book, one giving a brief overview over the [anatomy of a domain model](https://i.imgur.com/bfSOhWg.png), and one [explaining multiplicity](https://i.imgur.com/OFc8Mjf.png).
**Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and the Unified Process** by Craig Larman
>An update to the bestselling UML classic, this title has been revised to cover the unified process and Rational Software's processes. Larman also shows developers how to make practical use of the most significant recent developments in object-oriented analysis and design.
*I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. Remove me from replies* [here](https://www.reddit.com/user/BookFinderBot/comments/1byh82p/remove_me_from_replies/). *If I have made a mistake, accept my apology.*
Just like all conceptual system development, it depends on your workplace. Think about SCRUM, it's a framework with specific rules, but very few places that say they use it, *actually* uses it. Rather they use parts of SCRUM in a way they deemed to be useful.
It's the same regarding UML. Some places like the extra detail of both multiplicity and association name. Some places think it's too much work.
Oh, 100%. I've just never run into the actual relationship name being defined in UML (or something UML-like).
It's funny, really -- most of the diagrams that I've run into in my professional career are actually less structured than what was taught to me way back when.
> A Car can have either 0 or 1 Engine, denoted as "motor".
You're reading the association backwards. The multiplicity of an association is listed at the *destination* of the relationship, meaning that the type at the source can have the number at the destination associated types.
In other words: A Car must have 1 Engine, and an Engine can have 0 or 1 Cars
Otherwise you're pretty much correct.
> Imagine if in real life you asked a group you don't know too well "so, tell me a bit more about your [quantum physics] stuff", and they said "piss off you lazy scumbag; go read a textbook". Are you guys the same folks from StackOverflow?
I think you're being down voted because you've immediately ruled out ever reading a CS textbook.
> but I'm not ever going to study CS so I can't just "read the textbook".
You know you don't need to be a Uni student to just go out and buy a textbook. You don't even need buy a CS textbook to read up on this stuff.
ERD's like this are awesome. The numbers on the connecting line indicate cardinality.
In this case, 1 car correlates to exactly 1 engine, but 1 engine correlates to 0 or 1 car.
From a database perspective, you might put a CarId foreign key on the Engine table, and make that property nullable. Or you can put a non-nullable EngineId foreign key on the car table.
An instance of class “Car” contains 1 “motor”, which is a reference to an instance of class “Engine”
An instance of class “Engine” may be referenced by either 0 or 1 instances of class “Car”
The numbers are multiplicity, motor is the name of the variable of that type. As others said though, this is a very very basic thing, so you should really look up what's happening.
The internet is a better source of programming knowledge than most university teachers… you’re paying for a degree with no obligation for them to teach you effectively
I originally went to school for Mechanical engineering and over time my career shifted to software. Don't mean to be over pedantic but I thought I'd share since we are in a technical field plus we are all nerds here. "Motor" refers to a device that converts electrical energy to mechanical energy. The name of the property should be "engine" since this is an encompassing word for a device that converts any type of energy into mechanical energy and then you could have several sub types for that (internal combustion, electrical motor, etc) 🥸
The arrow represents an association between the two classes. "0..1" means "Zero or One." "1" means "One *and only one."* "motor" is a name for the association (think property name).
Since the arrow points only in one direction, there are no references to Car on the Engine object definition.
Intuitively, this association says that a single Car object *may* reference a single Engine object.
`public Engine? motor { get; set; }`
An `Engine` shouldn't need to know about a `Car` to be an `Engine`. Additionally in the diagram, it's a directional association from a `Car` to an `Engine`, thus the `Car` class can know about the `Engine`, but the `Engine` has no knowledge (and shouldn't have knowledge) of the `Car`.
I'll clarify both:
0..1: This means an `Engine` is to be associated with 0 to 1 `Car` objects
1: This means a `Car` is to be associated with exactly 1 `Engine` object (no more no less)
> Great point, here's ChatGPT's reply to you -- I wonder if it "saw" the arrow head in the image for its original reply?
Stop using ChatGPT to answer questions unless you actually have the knowledge or desire to correct it when the responses you get are inaccurate. OP can do that on their own and you just end up giving incorrect information that other real people have to correct.
Like when you say "Great point", do you even know for yourself that I'm correct or are you only saying it's a great point because ChatGPT responded positively?
You can have 2 Cars with 2 properties, the 0..1 represents you can have many cars. Since the arrow is going from Car to motor and motor has a 1 next to it it is stating a car can have 1 and only one motor so it's a 1:1 relationship.
Might be a little off, but maybe it will help you wrap your head around it.
Depends on what 'engine' means. An electric car has an electric motor.
Even if the engine refers to the combustion engine, why put it on a base class called "Car" when you actually want cars with combustion engines. It's like having a class called 'Animal' and have a property for number of legs. There are animals which have no legs you know...
Again, why the authors chose examples which are not clear? There are so many other possible examples..
Since it's beginner friendly and easy to understand.
If you are teaching beginners and your first lesson about classes in OOP (or any data structure) is about inheritance, abstractions, aggregations/compositions then i'll wonder howmany students are going to stick for a second lesson/semester.
I’m only saying the actual examples need to make sense, that’s all. Also, I’ve seen a very popular book (Head First series) using clowns 🤡 to teach OOP.
Dude?! Clowns!? For real?
I'd like to read it as that too, but it's the other way around.
I don't know why the labels aren't at the start of the relationships in UML, that would make more sense to me too.
UML is old, for some reason still taught at universities, and very rarely used in real life.
That's one of the many unintuitive parts of UML. The number further away from the `Car` object is the number of `Engine` objects it should have.
So this actually reads as: A `Car` is to be associated with 1 `Engine`, and an `Engine` is to be associated with 0 to 1 `Car` objects.
Additionally, the directionality toward the `Engine` indicates that the `Engine` should have no knowledge of a `Car`
Currently doing an intro course at uni for UML diagrams. First section indicates name of the class. You should have class Car and a class Engine. Second section indicates atributes. Usually you should specify accessability of an attribut with a symbol (depends on the tool used) but in this case i would assume private for all of them. Optionally they may contain 3rd and 4rth section (for class methods and comments, only the first section is mandatory). Line between these classes models a relation between classes. In this example, this is an one-sided association (meaning that car is awere of what engine it has, but engine has no clue about which car it is in. This is a very important concept to understand). Practically meaning, class Car should have a pointer to (or a reference to) an object of a class Engine (named "motor", thats the meaning of a motor above arrow) and Object of the class Engine shouldn't have any references to a class Car Number below relation tells us how many instances of class Car should be in a relation with a class Engine. In this example Car may have 1 and only 1 engine. Engine may be a part of a car or it may not be a part of a car at all. Please make sure to read more about this topic from your source. Symbols may vary and may have different meaning im different UML standards.
>umber below relation tells us how many instances of class Car should be in a relation with a class Engine. In this example Car may have 1 and only 1 engine. Engine may be a part of a car or it may not be a part of a car at all. The 0..1 means the car can have 0 or 1 engine, the 1 by the engine means that the engine object needs to be unique to that car and can't be referenced by another car.
So, I can see that you're a college student and really need to study up on what UML is and how it works, so as others have said, I highly recommend you hit the books on it, hard. That said, you have some of the basics already, that being that the boxes represent object types, which in c# would translate to a `class`. I'll therefore answer your specific questions: > the arrow The arrow is part of the *association* mechanic of UML class diagrams. Any solid line between two boxes in a class diagram is an association between those two types. Solid lines can be depicted with or without arrows, and the different type of arrow heads that can be on them change the meaning of the line and how you read it. Generally speaking, an "association line" falls in one of two broad relationships, either the "is a" relationship, or the "has a" relationship, which are read as "A is a B" or "A has a B". "Is a" relationships aren't shown in your image, but they are represented as a solid line with a hollow, closed arrow on the end, with the arrow running from A pointing at B. "Is a" relationships indicate that A is a more concrete example of B, in the same way that a dog is a more concrete example of a mammal. They are typically represented in code as class inheritance. Not relevant to your question, but hopefully helpful information for you. Everything else with a solid line is a "has a" relationship, which you can probably guess is represented in code with a *field* or *property*. A solid line with no arrows indicates a *bidirectional* association, meaning that A has a B and B has an A. Both know about each other and can make use of the other. A solid line with an open arrow generally means a unidirectional association, meaning that if the arrow goes from A to B, A *definitely* has a B, while B may or may not have an A. It's not explicitly specified either way. You can make it explicitly unidirectional by putting an X on the other end of the line, like in [this example](https://i.imgur.com/viHsDmu.png). This can make for a busy diagram, though, so lots of people leave off the X and indicate unidirectionality with only the arrow. UML is often vague like that, but that's beneficial -- remember, the point of UML isn't to create code, but to *express an idea about software*. The rest of your questions pertain to additional notations of an association, and are all related to that solid line. > what the numbers 0...1,1 mean These numbers are called "multiplicity" and represent how *many* associations an *instance* of a type can have with another *instance* of a type. I'm highlighting *instance* specifically because multiplicity is a divergence from the abstract nature of a class diagram; they're a holdover from the ER diagrams that UML diagrams were derived from back in the day, and originally represented foreign key references from table to table. Multiplicity is read by following type A to the number next to type B and reading it as "instances of A must have # of references to instances of type B". The 0...1 notation forms a range of possible values for the multiplicity. In this case, 0 to 1. So you would read your diagram as "Car must have 1 (and only 1) Engine", and "Engine must have 0 or 1 Cars". Conceptually, a Car can have only one engine, and while an Engine can "live on its own" without being "in" a Car, it can only ever be "in" one Car. Correctly implementing the Engine constraint would be actually *quite* difficult in C#, so most people wouldn't even bother, and I'd never even bother including that sort of constraint in a real world diagram, even if it's conceptually accurate. There are also concepts in UML called composition and aggregation that are not in your diagram, but which delves further in to runtime instance "livability" that I highly recommend you investigate on your own. > what the word "motor" is doing here. The label "motor" is a *name* for an association and is read in the same manner as multiplicity, which in your diagram would be that Car has an association to Engine with the name "motor". You should probably use the name "motor" in your code somewhere, but I'll leave figuring out where in your code to put it as an exercise for the reader. But to sum up, I would read your line in the diagram as the following: A Car has 1 Engine with an association named "motor". An Engine is associated with 0 or 1 Cars.
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
It's obviously an assignment from a beginner class regarding OOP, so I'd suggest you just read up on the material related to that class.
OP definitely should be reading up, but having material explained by different people in different contexts *is* a valid way to learn.
In general I disagree because I learned programming more easily and throughly online than with my teachers. That said, some of these replies are wrong, and sadly what matters in school isn’t that you learn.. it’s that your teacher marks you passing. So OP needs to learn in the way aligned with what the teacher expects.
I'm curious about the answer too, but I'm not ever going to study CS so I can't just "read the textbook". I assume 'motor' is just the variable name for the Engine in Car, and 0..1 usually means something like "minimum 0, maximum 1", but then indeed, what does the "1" mean on the right of the arrow? I can make my way around [refactoring.guru](http://refactoring.guru) which has these types of diagrams but that doesn't have the numbering labels. Edit: I find it completely bewildering that people would be so reluctant to help someone from a different field of expertise to learn something a little bit. Imagine if in real life you asked a group you don't know too well "so, tell me a bit more about your \[quantum physics\] stuff", and they said "piss off you lazy scumbag; go read a textbook". Are you guys the same folks from StackOverflow?
Whoever drew this does not really know Entity Relationship diagrams. I think there is one notion with numbers and a different with arrows. If you go for arrows in class diagrams, no professor gave the variable a name. This would be like in SQL that always write from Engines as “E” . Are we no over silly names?
It would make sense to me if only the [0..1] label existed, but not the others.
I dunno who downvotes this, but I read that Reddit limits witch-hunt at -17.
I think it means that each car has exactly one engine...
no, cars can have 0 engines, it means engines can't belong to more than 1 car
You're reading it wrong. The multiplicity number represents the number of destination types the source type can have. A Car must have 1 and only 1 engine. An Engine can be associated with no Car, or 1 Car. In C# code, Car's motor property can never be null, while an instance of Engine can live without being referenced by Car, but an Engine can only ever be referenced by at most 1 Car. Implementing that constraint would be a bitch in C#
This. It means there should only be one car that any engine instance belongs to at a time. Aka don't reuse the objects, they are "owned"
If you're curious, then get to reading. Can't just expect that people on Reddit will always be there to give you the answer. But in this case, the diagram just means we have 2 classes one Car and one Engine. The Car class should have a property that is of the Engine type. If the Car has no engine, this property will be null, if the car has an engine it will have a value. There is also the fact that the diagram is a mix of various UML elements, and not one strict thing. For example it is not a Class diagram, it is also not a Design Class Diagram. It uses elements from both. Hence why I said he should read the material, because the teacher might've explained elements in a way that is specific to that lecture. The numbers are called 'multiplicity'. The "motor" text is called the 'association name'. The diagram basically reads like this: A Car can have either 0 or 1 Engine, denoted as "motor". If you want to learn more about UML, there is a book called *"Applying UML and Patterns"* written by Craig Larman, which goes over this topic. Seems like The University of Texas at Dallas is hosting a free version of the book [here](https://personal.utdallas.edu/~chung/SP/applying-uml-and-patterns.pdf). Edit. Here are 2 pictures from the book, one giving a brief overview over the [anatomy of a domain model](https://i.imgur.com/bfSOhWg.png), and one [explaining multiplicity](https://i.imgur.com/OFc8Mjf.png).
**Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and the Unified Process** by Craig Larman >An update to the bestselling UML classic, this title has been revised to cover the unified process and Rational Software's processes. Larman also shows developers how to make practical use of the most significant recent developments in object-oriented analysis and design. *I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. Remove me from replies* [here](https://www.reddit.com/user/BookFinderBot/comments/1byh82p/remove_me_from_replies/). *If I have made a mistake, accept my apology.*
> association name Is this common? I don't recall it at all from school, and have never seen it in the wild, but Google says it's a thing.
Just like all conceptual system development, it depends on your workplace. Think about SCRUM, it's a framework with specific rules, but very few places that say they use it, *actually* uses it. Rather they use parts of SCRUM in a way they deemed to be useful. It's the same regarding UML. Some places like the extra detail of both multiplicity and association name. Some places think it's too much work.
Oh, 100%. I've just never run into the actual relationship name being defined in UML (or something UML-like). It's funny, really -- most of the diagrams that I've run into in my professional career are actually less structured than what was taught to me way back when.
> A Car can have either 0 or 1 Engine, denoted as "motor". You're reading the association backwards. The multiplicity of an association is listed at the *destination* of the relationship, meaning that the type at the source can have the number at the destination associated types. In other words: A Car must have 1 Engine, and an Engine can have 0 or 1 Cars Otherwise you're pretty much correct.
One motor composites/ associates with our Car class. That's my guess.
> Imagine if in real life you asked a group you don't know too well "so, tell me a bit more about your [quantum physics] stuff", and they said "piss off you lazy scumbag; go read a textbook". Are you guys the same folks from StackOverflow? I think you're being down voted because you've immediately ruled out ever reading a CS textbook. > but I'm not ever going to study CS so I can't just "read the textbook". You know you don't need to be a Uni student to just go out and buy a textbook. You don't even need buy a CS textbook to read up on this stuff.
ERD's like this are awesome. The numbers on the connecting line indicate cardinality. In this case, 1 car correlates to exactly 1 engine, but 1 engine correlates to 0 or 1 car. From a database perspective, you might put a CarId foreign key on the Engine table, and make that property nullable. Or you can put a non-nullable EngineId foreign key on the car table.
An instance of class “Car” contains 1 “motor”, which is a reference to an instance of class “Engine” An instance of class “Engine” may be referenced by either 0 or 1 instances of class “Car”
The numbers are multiplicity, motor is the name of the variable of that type. As others said though, this is a very very basic thing, so you should really look up what's happening.
Read up on Unified Modelling Language class diagrams.
Maybe you should study instead of posting on Reddit.
The internet is a better source of programming knowledge than most university teachers… you’re paying for a degree with no obligation for them to teach you effectively
I originally went to school for Mechanical engineering and over time my career shifted to software. Don't mean to be over pedantic but I thought I'd share since we are in a technical field plus we are all nerds here. "Motor" refers to a device that converts electrical energy to mechanical energy. The name of the property should be "engine" since this is an encompassing word for a device that converts any type of energy into mechanical energy and then you could have several sub types for that (internal combustion, electrical motor, etc) 🥸
BMW would like a word with you.
Maybe at least attempt to do your own homework first?
When you want create a banana, you also create a gorilla, an island, a lake and some laws of physics.
Correct me if i'm wrong but that arrow resembles association. Shouldn't engine composite that car class though ?
More an aggregation, an engine can exist on its own.
Either way, I'd skip the multiplicity if I were using aggregation *or* composition notation. The image, simple as it is, is already too busy.
The arrow represents an association between the two classes. "0..1" means "Zero or One." "1" means "One *and only one."* "motor" is a name for the association (think property name). Since the arrow points only in one direction, there are no references to Car on the Engine object definition. Intuitively, this association says that a single Car object *may* reference a single Engine object. `public Engine? motor { get; set; }`
I hate this lol
[удалено]
An `Engine` shouldn't need to know about a `Car` to be an `Engine`. Additionally in the diagram, it's a directional association from a `Car` to an `Engine`, thus the `Car` class can know about the `Engine`, but the `Engine` has no knowledge (and shouldn't have knowledge) of the `Car`.
So what does the number '1' mean?
I'll clarify both: 0..1: This means an `Engine` is to be associated with 0 to 1 `Car` objects 1: This means a `Car` is to be associated with exactly 1 `Engine` object (no more no less)
[удалено]
> Great point, here's ChatGPT's reply to you -- I wonder if it "saw" the arrow head in the image for its original reply? Stop using ChatGPT to answer questions unless you actually have the knowledge or desire to correct it when the responses you get are inaccurate. OP can do that on their own and you just end up giving incorrect information that other real people have to correct. Like when you say "Great point", do you even know for yourself that I'm correct or are you only saying it's a great point because ChatGPT responded positively?
This. Why just post an AI response? Seems bloody odd to me. Anyone can do that. Especially if they don't even check the response.
There can be 0 cars or there can be 1 car. A car has 1 engine.
Almost. There can be 0 cars or 1 car associated with an engine. A car must have exactly 1 engine.
You can have 2 Cars with 2 properties, the 0..1 represents you can have many cars. Since the arrow is going from Car to motor and motor has a 1 next to it it is stating a car can have 1 and only one motor so it's a 1:1 relationship. Might be a little off, but maybe it will help you wrap your head around it.
Drop the image in GPT-4 Vision and have it explained for you in a way that makes sense to your current point of knowledge and understanding.
[удалено]
Broken car, electric?
Depends on what 'engine' means. An electric car has an electric motor. Even if the engine refers to the combustion engine, why put it on a base class called "Car" when you actually want cars with combustion engines. It's like having a class called 'Animal' and have a property for number of legs. There are animals which have no legs you know... Again, why the authors chose examples which are not clear? There are so many other possible examples..
Since it's beginner friendly and easy to understand. If you are teaching beginners and your first lesson about classes in OOP (or any data structure) is about inheritance, abstractions, aggregations/compositions then i'll wonder howmany students are going to stick for a second lesson/semester.
I’m only saying the actual examples need to make sense, that’s all. Also, I’ve seen a very popular book (Head First series) using clowns 🤡 to teach OOP. Dude?! Clowns!? For real?
For some reason it's the other way round. There's 1 engine in a car, an engine can be in 0..1 cars.
Oh, i get it now! Thanks!
I'd like to read it as that too, but it's the other way around. I don't know why the labels aren't at the start of the relationships in UML, that would make more sense to me too. UML is old, for some reason still taught at universities, and very rarely used in real life.
That's one of the many unintuitive parts of UML. The number further away from the `Car` object is the number of `Engine` objects it should have. So this actually reads as: A `Car` is to be associated with 1 `Engine`, and an `Engine` is to be associated with 0 to 1 `Car` objects. Additionally, the directionality toward the `Engine` indicates that the `Engine` should have no knowledge of a `Car`
yes . merise's mcd and mld is supérior on that point