3

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)

sequence diagram for the search() use case

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.

Overflowh
  • 1,103
  • 6
  • 18
  • 40

3 Answers3

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..*.

Jim L.
  • 6,177
  • 3
  • 21
  • 47
  • 2
    "Do not model lists in UML" is something I found explained nicely when googling for it once (but can't find it again). So I just can confirm that. Using linked list or arrays are implementation details. Your business just focuses on the fact that there are many of a sort. – qwerty_so Jul 02 '15 at 18:40
  • Why you would replace `User` with `Driver`? It's the user of the system that searches for available cars, the driver is more like an employee. Yes I read that about list in *UML Distilled*, yet Fowler's first example uses a `List Order` class, so it's a bit confusing. Anyway, I edited the diagram to add the "returned Car class" part you said, and this is the result: https://i.imgur.com/QmmSI5V.jpg Is it what you meant? Thanks for the reply – Overflowh Jul 02 '15 at 19:05
  • 1
    You should be modeling the problem domain so your model is durable. User is relative to a particular solution, which is not as durable. The design you had before was better. You don't ask a car to return cars, unless you make the method a class static. It makes more sense to ask the Shift what cars are available within that shift. – Jim L. Jul 02 '15 at 19:09
  • Okay, I see your point about the `:Car` class. But on the other hand, it's a `User` who has the `searchCarsForRent()` method, not a `Driver` (and since a car doesn't return cars, I assume a shift doesn't return shifts either), so if I shift `aUser` with `aDriver`, won't it stop to have sense? – Overflowh Jul 02 '15 at 20:36
  • If you had no computers, who would do the searching? I think a customer asks an agent. When in doubt, ask a business SME, don't make stuff up. IT should resonate with the business, not the other way round. – Jim L. Jul 02 '15 at 20:40
  • Some employee, I guess, who will have to search through registers and things when a client asks to rent a car, and notify a driver available at the time chosen by the client that there is a pick up to do. _Edit_: Yes sure, but this is just an exercise. I feel like it would be kind of an overkill to go annoy someone who's working to ask about how they do their job to solve an exercise. – Overflowh Jul 02 '15 at 20:43
  • 1
    Find out what kind of employee from a business SME, then model it similarly to the way you described it. – Jim L. Jul 02 '15 at 20:47
1

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.

Yann TM
  • 1,942
  • 13
  • 22
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

trueanalysis.eu
  • 51
  • 5