I should portray the following connections between cinemas, movies and movie distributors in an UML class diagram:
A movie distributor lends a certain movie to several cinemas.
A movie distributor lends a certain movie to a certain cinema, but not to other cinemas.
At most one movie distributor lends a movie to a cinema.
But a movie for different cinemas can have different movie distributors.
A movie distributor can lend several movies to the same cinema.
Right now my UML diagram looks like this:
I derived the multiplicities from the following statements:
class Movie Distributor - statement 3 from above (at most)
class Cinema - statements 1 and 2 from above: I interprete these statements as "a movie distributor lends a film to at least 1 cinema
class Movie: statement 5 (several movies)
I struggle definitely with statement 4 and I'm not sure about my interpretations of the other statements too.
You may be on the right direction for the multiplicities. However, did you spot the challenge of several classes being involved in the same association?
To solve this you can:
introduce a fourth object that models the Rental, in addition to the Movie, Distributor and Cinema.
use a ternary association between the already identified classes.
use an association class to represent pne of the three clasdes. But this does not seem suitable here, as it would not aknowledge that movies, cinemas and disributors exist independently of their relationships.
use an association class to tepresent the rental
Edit
In view of your diagram, let's first remind the principles of multiplicity in ternary associations, since it's far from being obvious:
The multiplicity says something about how many times an instance may be present in this associations for any given tuple of linked instances.
Let's apply it successively. THis will without suprise confirm your own analysis:
For a given Distributor and a given Cinema, there can be 0..* Movies lent. That's (5).
For a given Cinema and a given Movie, there can be 0..1 Distributor making the lend. That's (3)
For a given Movie and a given Distributor, the lend can be for 1..* Cinema. That's (1) and (2). (This also means that it make no sense to lend no movie)
The item 4 is missing, but it's only a consequence of the others. (4) means that we take a given movie:
Nothing says that a given Movie can have only one Distributor. So we are allowed to imagine cases with several distributors for the same movie, isn't it ?
Nothing says that a given Movie is shown only in one Cinema. So we are allowed to imagine the same movie in several cinemas.
Taking both together, we have a movie with several distributors and several cinemas.
Now nothing requires that there should be only one Movie for a pair of Cinema/Distributor (otherwise the multiplicity of Movie would be 0..1 and not 0..*
By deduction, a movie can be combined with several cinemas and distributors, with different distributors involved.
Related
I have the following UML diagram:
Where VarietyCategory could take values like size and colour, and Variety for size could be S, M, L, and for colour could be green, red.
Now I can have a stock per combination of varieties, taken from the Cartesian product of all the variety categories a merchandise have (for example, 5 S-green items and 10 M-red items). How can I add this information to the UML diagram?
I guess I'm seeing this as an optional association class from Merchandise to the space defined by the Cartesian product of all the VarietyCategorys with a quantity attribute specifying the stock for that given combination, but I can't see how to express that in UML.
After thinking a bit I've come up with this, but this doesn't seem to fully convey the intention, as I had to put a note to specify a multiplicity depending on another part of the diagram, along with the constraint of selecting a variety from each variety category:
Any better ideas on how to do this?
The problem
This is indeed a popular scenario in some industries such as apparels, where each item in the catalogue is configurable regarding size, color and style.
The stock of a configurable merchandise such as "Shirt" does not make sense except for statistical purpose, but what really matters is the stock of the configured merchandises, e.g. {Item: "Shirt", size: "M", color="white", style:"italian colar"}. Here it's even more complicated, since the configuration elements are dynamic.
Your solution
Your second diagram models this very well by using a combination that you've called Flavor. So for the shirt, each possible combination of the configuration variables (Variety), e.g. the tuple ( "M","white","italian colar) would be a distinct flavor. Your association would class would hold the stock quantity of the Flavor.
The multiplicity on the Variety side would be by deduction 1..*. The constraint then needs to express that for an occurence of Flavor, the size of set of associated Variety occurrences is the same than those indirectly associated with the Merchandise. A full-text expression like you did is just fine. The other alternative would be to express this with a complex OCL predicate, which is very difficult considering some missing role names and the multiple indirections. Btw, most readers wouldn't anyway understand it.
However, I would not keep this solution:
Its main weakness is that the Flavor seems independent from the Merchandise, whereas in reality it only makes sense for a given Merchandise (your constraint proves it).
It is not easy to manage more complex stock, for example if you'd have a stock per warehouse.
Better alternatives
If you'd consider Flavor as a flavor of a given Merchandise, you could make this explicit and simplify the design: Flavor would become the configured Merchandise (instead of just a combination of Variety) and could make it a component of the Merchandise composite.
You could then simplify and store the stock quantity at the level of the Flavor . Or you could manage the stock quantity in an association class between the Flavor and a Warehouse (which you could not really do with your current model).
Everywhere you'd use a Merchandise, you'd use a Flavor instead, facilitating for example the ordering or the shiping of configured products, which is much more difficult if you'd keep the flavor independent of the merchandise.
To avoid confusion, it would nevertheless be better to rename Flavor in something more explicit that reminds that it's a product that you manage in your system.
A product variant (like Tesla's Model 3 in Pearl White with Sport Wheels) for a product (like Tesla's Model 3) has all features of the product (like a top speed of 140 mph) and additionally a set of attribute-value slots for all variation attributes of the product (like "Paint" and "Wheel" in the case of Tesla's Model 3). This is described by the following class diagram:
The diagram includes data samples next to classes for illustrating their meaning.
Notice that using composition for associating variation attributes to products and variation attribute values to variation attributes means that these attributes and their values are specific and not shared among products/attributes.
A corresponding relational database schema can be read off from this model:
products( id, vendor_id)
product_variation_attributes( id, product_id, name)
variation_attribute_values( id, product_variation_attribute_id, value)
product_variants( id, product_id, price)
variant_slots( product_variant_id, product_variation_attribute_id, variation_attribute_value_id)
This model/schema is compatible (modulo renaming) with the confirmed answers
https://stackoverflow.com/a/19200349/2795909 and https://stackoverflow.com/a/24941744/2795909.
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.
I need to draw an UML class diagram which is made from the following statements.
A house has an address and consists of several rooms. Each room has a size. It can either be a bedroom, a living room, or a kitchen. A house consists of at least one of each kind of rooms.
The last statement is a constraint, and I need to add it in my diagram.
UPD: The whole task was the following.
Draw a UML class diagram representing exactly the following scenario:
A family consists of an arbitrary number of children and one or two parents. Every
family member is a person with a name and an age. Children are able to play games and
parents can go to work and they can cook something in the kitchen. A family lives in a
house which has an address and which consists of several rooms. An arbitrary number
of families can live in a house. Each room has a size. It can either be a bedroom, a living
room, or a kitchen. A house consists of at least one of each kind of rooms. An arbitrary
number of persons sleeps in a bedroom.
In case you wish to keep the Association between House and Room, you could create additional Associations to the individual room types, sub-setting the Room end.
The {subsets Room} means that these should be considered a part of the general Room association.
{subset} can be removed, because if one end of the association {redefine}, then the other must be a {subset}. End Association House (from Kitchen) {redefine} end of the Association House (from Room), because their names are the same.
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.
After some confusion with mixing use case and class diagrams, managed to clear some doubts and come up with the following class diagram. Felt more comfy with this than use case. Hope am not wrong. Would like some feedback on any errors and improvements on it. Thank you.
Question:
A new library has books, videos, and CDs that it loans to its users. All library material
has a unique identification number and a title. In addition, books have one or more authors,
videos have one producer and one or more actors, while CDs have one or more artists.
The library maintains one or more copies of each library item (book, video or CD). Copies of all
library material can be loaned to users. Reference-only material can only be loaned for a
maximum of two hours and can’t be removed from the library. Other material can be loaned for
up to two weeks. For every loan, the library records the user, the loan date and time, and the
return date and time. For users, the library maintains their name, address and phone number.
Draw a class diagram for the description above.
Class Diagram: link to diagram
Don't use notes for multiplicities 1..*. Edit associations or their ends instead and write it there.
Write multiplicities on ends, not in the middle of the line.
Arrows should be subscribed by names of attributes.
Libraries can have many Videos, books, CD's and so on. So, there multiplicities should be in both ends.
No arrows on the line is the same as arrows on both ends. Check it on the right sides.
Write attributes inside blocks when they are of types not present on the diagram. If they are not, put their names on the opposite ends of the associations, near arrows.
You should use some empty diamonds on the left side.
You should decide the multiplicity of the producer.
Divide Title from Copy. And maybe, from Edition.
Don't mix plural and singular - hold to some system. I use plurals only for collections, but you needn't take it, of course. Plurals in class names are senseless - all classes apart from singletones have many instances.
You don't need toconnect library to CD and Video - they are merely subsets of Books. And books already are connected. The same with three lists in the Library block.
Loan should be connected to Book.
According to standards, loan() is a constructor of the class Loan. It can't be in another class.