1

I am confused about the cardinality/ multiplicity when designing class diagrams. My main confusion is when to represent 1---* relationship. For ex in case of passenger and seat classes, passenger will be allotted to one seat, where as the seat can be allotted to one passenger at A POINT IN TIME but over a period of its existence it can be allotted to many passengers.

So should the seat--->passenger be 1-1 or 1-*?

Christophe
  • 68,716
  • 7
  • 72
  • 138
avatar
  • 35
  • 7

2 Answers2

1

Let's summarize:

  • At one precise moment in time:
    • each Passenger will be allocated to exactly one Seat (1). Open question: does the Passenger exists already before the allocation (i.e. 1 or 0..1) ?
    • each Seat can have one allocated Passenger but it may remain empty (so 0..1)
  • Over their lifetime:
    • each Passenger can have been allocated to many seats (one per flight)
    • each Seat can have had many Passenger allocated.

Conclusions: the relation between Seat and Passenger is *-* (many to many)

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks CHristopher. When do we need to consider is it over a period of time or at a time? Is it a question to the customer like I need to ask them are you looking for over a period of time or at a point in time? or should it always be for every design u consider over a period of time? – avatar Apr 01 '16 at 15:55
  • It depends on your customer's needs. So you have to ask him/her questions that help you to clarify. Don't hestitate to ask questions under different angles. For example: does he/she want to find back the history of the seat allocation ? does he/she expect that seats can be allocated in advance (a Passenger could then reserve seats for several travels) ? are there legal requirements (finding back the seats in case of law enforcement investigation) ? and so on... Real life is full of many to many relationships – Christophe Apr 01 '16 at 16:16
-1

It all depends what you model.

  • If we're modelling a booking per trip it will be a Seat 1 --- 0..1
    Passenger.
  • If we're modelling a booking per trip and have just a number of seats per each class (but a particular seat isn't assigned) it can be SeatClass 1 --- 0..SeatClass.availableSeats Passenger.
  • If we're modelling a system to analyse passenger behaviour (e.g. to offer best seat for a particular passenger) it will be a Passenger 1 <>--- * Seat.
  • If we're modelling a system to analyse the seat utilisation it can be Seat 1 <>--- * Passenger.

etc.

I can imagine lots of other possibilities.

The idea is you model a particular system and you need to represent particular business need. Multiplicity will depend on that. As a rule of thumb you are interested in a situation in a point of time (note that in my two last examples you're handling a history of seats assignments at a point of time).

So my conclusion is: there is no simple answer.

Ister
  • 5,958
  • 17
  • 26