I was reading through a tutorial on UML Class diagrams and I'm having problems understanding Association Classes and why this MileageCredit class isn't part of the FrequentFlyer class in the below example (taken from figure 11 of the tutorial here):
Assuming that it's a one-to-one relation between FrequentFlyer and MileageCredit (if a person had two FrequentFlyer memberships they'd still have different frequentFlyerNumber numbers) then I would just put these baseMiles and bonusMiles properties in the FrequentFlyer Class itself.
Could someone please explain why this is wrong?
MileageCredit is an AssociationClass, which means this is simultaneously an Association (linking) Flight and FrequentFlyer) and a class that describes this Association. This fact is depicted by a dashed line connecting the class and the association. Note that acording to the UML specification those class and association together create one entity.
In your example there is Association (that is called MileageCredit) between FrequentFlyer and a Flight. You may assume that this shows a Flight taken by a FrequentFlyer. As for these Association you need additional information (number of award and bonus miles that are awarded to the FrequentFlyer for this Flight) this association has this extra Class describing this information.
If you created baseMiles and bonusMiles on FrequentFlyer that would have absolutely no relationship to the Association - it would be only information about total points awarded to the FrequentFlyer.
Related
I have an assignment for school where I'm asked to represent the system of a company that I am to upgrade with a domain model and draw a conceptual class diagram with the four most important use cases of the system. I don't really understand the difference between the two, can someone help me ?
In short
Domain model and a conceptual mean different things to different people. There is no universal authoritative definition of these terms.
Nevertheless, objectively a domain is more than interrelated classes. If we consider that conceptual means independent of any solution implementation, we can claim that a conceptual class diagram is a subpart of the domain model.
Some more arguments
A domain model describes the elements of the real word for which a software shall provide a solution.
For example, for a real estate application:
you’d have “business objects” such as real estate assets (houses, flats, …), owners, tenants, sellers, buyers, agents, contracts, payments, geographical regions, etc.
But you would also have domain logic, such as the lifecycle of things: at first a party can be a prospect for an asset, then an interested prospect after a visit, then a tenderer if a bid is submitted, the. a buyer if the bid is accepted. The domain model can also describe business rules, e.g. if a tenderer proposes a price below the price demanded by the seller, the agent has to insure agreement of the seller before continuing negotiations.
DDD practitioners would also remind us that domain entities and aggregates (the things) are related to domain events that express what happens to entities and aggregates.
Hence, a domain is more than interrelated classes. If you’re bot convinced, imagine a Model-View-Controller application where the Model would ignore the business logic: would it be useful?
The term “conceptual” means something abstract that is independent of any concrete implementation. In this regard, a conceptual class diagram refers in principle to a diagram of classes that describes the domain, independently of any concrete/implementable solution.
As a consequence, a conceptual class diagram in UML only describes a static subpart of the domain model. Because by construction, the class diagram is designed for representing the static structure of classes. UML foresees other diagrams to describe the dynamic aspects of a system or its domain, such as activity diagrams, sequence diagrams or state diagrams, that allow to focus on some dynamic parts of the domain.
So a conceptual class diagram can only be a part of the domain model.
You’ll nevertheless find articles and peers who use the term “domain model” to refer to the “model of the entities of a domain”. This is a misleading shortcut in the language.
I am learning UML and I've focused on a Netflix-like project on which to practice on.
I've put together a class association diagram, but have been told that the multiplicities are incorrect. The multiplicities in red represent what I think they should be changed to.
Could someone please offer some clarity of where I have gone wrong?
Please, ask any questions that would help gain a fuller understanding of the diagram in reference to the project.
Thanks in advance.
Movie Catalog - User: The 0..* multiplicity is correct. There can be an arbitrary number of users and not only a single one. That would only work if that Netflix was made for a very single person. And that would be pointless, I guess.
Movie - Membership - Member: This represents an association class for the user to track payments (and access, etc.). So it must be the 1, not 0..*. The stream is sent for that single Membership where it is accounted. An association class has a n-1-1-m relation.
In your model it looks like this:
And from my POV it is:
since the Membership is just used to control access to the movies. It is arguable whether there is only a 1-1 relation and not a (preferable) m-1 relation between Member and Membership.
When class is associated with another, like Flight in the linked image, which has zero or one Plane associated with it, should this not be reflected in the class' attributes?
That is, shouldn't class Flight in this example have an assignedPlane field alongside its flightNumber, departureTime and so on... otherwise how can Flight be said to 'be aware' of its associated Plane?
No.
Showing an association in diagram is equivalent to having an attribute of a specific class. If there is an association(with a role) then this role is an attribute of respective Class.
For reference please see the Figure 9.12 (with description) in section 9.5.5 of UML 2.5 specification.
If you would have an attribute 'assignedPlane : Plane' in class Flight, then the role 'assignedPlane' on the association would be redundant. But merely having the role 'assignedPlane' on the association does not imply that class Flight is aware of it. If Flight would be implemented as a Java class or a class in any other OO programming language, it is not clear from your class diagram whether or not class Flight has any reference to (or knowledge of) the assignedPlane.
If you want to communicate to your audience that class Flight owns a reference called 'assignedPlane' to zero or one instance of Plane, then you could add a thick dot (or a small filled circle) at the end of the association. Here is an example from the UML 2.5 specification:
In this example, 'size' is an attribute of Window, although it is displayed as an association. If you would have a class diagram that shows all attributes of Window, then 'size : Area' would be one of them.
The dot notation is a relatively new notation and it is not widely used. Instead, many designers use the arrow notation, also shown in figure 9.12. According to UML, this so-called navigability arrowhead specifies that the associated instance of Area can be accessed efficiently from Window, irrespective of how and why this is the case. Most designers would assume that it means that Window has an attribute 'size : Area', but strictly speaking, this is not what the UML specification says.
Using both the arrow and the dot, as in figure 9.12, is valid, but redundant.
Does double association exist in UML? Let's say, for example that i have two classes: User and Account with their own attributes which are not important and that in the User class there should be exactly two attributes of type Account.
In this type of scenario when making the UML class-diagram should there be a double association or is there another way to emphasise the fact that there are two attributes of that type?
Thanks
In fact to model "a double association", I would use two associations which are useful to speficy a different role for each association as depicted below .
As i read through software engineering appendix 1 from Roger Pressman book that
an association between two classes means that there is a structural
relationship between them
what structural relationship means?
UML differentiates 'structural' and 'behavioural' models. Class Diagrams, Package Diagrams and a few other capture the structural aspects. State/Sequence/Activity Diagrams capture behavioural aspects.
'Structural' means it holds over time. For example, the association between Order and OrderLines ("Order consists of 1 or more OrderLines / OrderLine is part of exactly one Order"). Or Dog and Person ("Dog is owned by exactly one Person / Person owns many Dogs"). Used well, Associations capture invariant rules from the problem domain. To use the Dog example: the association says a Dog can't ever be owned by more than one Person at any given time. Doesn't matter if the Dog is running, sitting, or eating: it must have exactly one Owner. Note also the owner could change over time: but there can never be more than one at any point.
An alternative is to think of Associations as the kind of thing that might be captured using foreign keys in a relational database.
hth.