minaleebtu / webapp-lee

0 stars 1 forks source link

Our information design model #3

Open durinfab opened 3 years ago

durinfab commented 3 years ago

This issue includes our first concept of the information design model

information_design_model

Feedback is appreciated!

minaleebtu commented 3 years ago

Here is my feedback of your design model.

I hope this can be helpful for you :)

AlistarMidCarry commented 3 years ago

Thank you for the feedback! We added an instrument enum. We also fixed the mailAddress

As I wrote in the information domain model, the participation of each ensemble into the event is not mandatory. Only when there's a meeting for each ensemble, the ensemble participates in the event.

Exactly, we modelled a situation where there has to be at least one ensemble to take part in an event, as events usually are made for ensembles and not single people or other groups.

Can't the data type of personInCharge of 'Event' be 'Member', not String type? Because the person in charge of the event is also one of the members in the club.

This would be problematic. For example: There is a concert planned by a person. This person is not neccessarily part of an invited ensemble or any other music group.

I guess the number of participants in the event can be 0 if no one wants to participate.

That is true. Thanks for the help!

This is the new diagram:

information design model(2)

minaleebtu commented 3 years ago

I can see only instrument part should be changed. First, the multiplicity could be '0 to many' or 'one to many'. For example, there would be a person who can play both of the guitar and lute. And I guess the range of instrument would be InstrumentEL not String type. Other things look fine :)

durinfab commented 3 years ago

We improved the instrument part. We decided to use a "0 to many" multiplicity because i.e. the manager of the ensemble must not necessarily play an instrument.

information_design_model3

minaleebtu commented 3 years ago

Yeap that would be nice