How to represent "collections of things" in UML's class and sequence diagrams?

Question

Let's say you are trying to model a rent-with-driver service. You have a Driver class to represent the informations about the drivers. Each driver can have one or more (1..*) cars available, represented in a Car class (I guess). Each driver can also insert one or more (1..*) shifts during which they are available (shifts are characterized by an area, a day a starting_time and an ending_time), and for this reason I imagined a Shift class was needed. A User class can search() for available cars in a given area at a given time.

You have to draw the class diagram of this system and the sequence diagram of the search() use case.

How do you represent the Shift class in such scenario?

I mean, all those classes clearly don't represent a single entity, but rather a set of data of that type. Now, for a user or a driver you can easily represent them by taking a single user or a single driver object and they will summarize the behaviour of all of them pretty good. But how do you do this with the Shift class? The search() operation must be done on the whole dataset rather than on a single object and a single object clearly doesn't hold all the information about all the shifts. Plus, surely a shift object doesn't have a getAvailableCars() method, since, again, it hold the informations about a single shift.

It goes without saying that something like this (which is what I come up with until now about the sequence diagram)

looks too simplistic to be correct.

Should I introduce a ShiftsList class and a CarsList class? Should I just treat it as a set of objects in some other way?

I can imagine how I would model a problem like this with an E/R diagram since in that case the Shift entity would be a database's table, which is a set of data by design, but I'm having a really hard time trying to put this in UML.

Answer 1

Just a quick answer. I think you touched only the very tip of an iceberg. If you want to plan the shifts, the whole thing gets a bit more complex than one Shift class.

1. You don't want to model user as part of the domain (he is not). User is modelled as an actor in Use Case model. He interacts with the system, not with the real life objects (things).
2. Think about drivers inserting shifts, this model rarely works. Usually you need kind of a manager to synchronize and plan things (Shift Plan class, which contains [0..*] Shifts), so that you don't have extremes (a day without any driver or a day when all drivers are on shift, but not enough customers etc.)
3. The relationship between the driver and the car is this: "The driver drives the car". That's the most important information. There is no real relation between a driver and all available cars in real life, until he drives one. We model real life relations in order to deliver the real life value.
4. You probably want to model areas as an enumeration to keep things consistent.

Hope this helps to get you started in the right direction. Keep us informed of your progress ;)

Regards, Trueanalysis

Answer 2

In the class diagram you get a * cardinality relationship, which you could qualify as a composition. It allows the class holding the "search" function (the front-end) to reference all the Shift instances.

You should think first of the signature of the front-end, that carries the data for your system, i.e. a set of Driver, a set of Car...

It carries the high level operations : i.e. void addAvailability(driverName:String, carLicense:String, area:String, ....)

and also what are the parameters to the search function (? not given in question)

Probably, you want a class "Availability" to store the data the drivers are making available. It carries a reference to a Driver (1 cardinality) and the area/date pair. Or perhaps a list of corresponding Shift instances.

Then depending on the parameters of the search, you want Availability to have a "matches(searchCriterion):bool".

To model an iteration in a sequence diagram you do have the "loop" fragment, but is it really useful ?

Do the sequence diagram of when the "matches" function returns true, you'll be fine. Put one lifeline for the User (an actor) that invokes operations on the front-end class (search). The front-end invokes matches() on a shift, if it's true queries to find the associated driver, then his car(s). Draw the returned value ({"Joe's mercedes"}) on the return arc to the actor.

Answer 3

Your design sounds reasonable, except I would replace User with Driver.

Do not model lists in UML. A list is a way to realize an association with 0..* multiplicity.

The available cars is just a returned Car class with multiplicity 0..*.