Class Diagram - yshehab/SchoolRoomBooking GitHub Wiki

Updated 9.12.13 to reflect changes made in use cases

/images/class_diagram.jpg

Initial.

/images/class_diagram_2.jpg

The above diagram isn't right, now that I've done some of the use cases I can see that it will cause us problems. And I think that we can aim a wee bit higher! So here is the new class diagram...

/images/class_new.jpeg

Invariants

  1. The is only a single booking for a given room, date and timeslot
  2. If a booking is linked to a member and not linked to a permit then that member must be linked to school via the worksAt association and the room is linked to school via the isIn association.
  3. If there is no associated charge object with a booking then the cost attribute of booking is 0
  4. The cost of an account is the sum of the cost attributes of all the bookings associated with the permit that the account is associated with
  5. The cost of an account may not be 0
  6. If a permit is linked to aMember via the isResponsibleFor association and linked to anOrganization via the hasPermit association then aMember and anOrganization are linked via the isMemberOf association

Some extra information

  1. Charge might strike you as odd, it is. It's based upon a whole load of information. For example the PTA gets 2 free lets a year, after which it has to pay the going rate and that often depends on whether the school is deemed open or closed and if they are actually fund-raising etc..... There are a whole load of these rules, for now I suggest that we just hard code a few as an enum and do things properly further down the line. ?
  2. There are booking made by staff who work at the school, which are always free and which we don't want to produce permits for. Which is why we have the makes association.

Discussion

  • Whats the deal with permits? Can the local Hells Angel Chapter get one or do they need authorizing?
  • Funnily enough yes! The only rules are that organizations that deal with children, political parties during a run up to an election and martial arts groups need to jump through hoops. We can assume that the user will have vetted the organization for now. neo
  • How are accounts settled?
  • Oddly. At the moment I produce the account send it off to the council and the school gets paid at that point. It's up to the council to ensure that the account gets settled. In the end I'll need a text file or a print-off but I suggest that we deal with that as a feature that will get added during the next iteration. neo
  • Do you need details for a contact person for an organisation?
  • The member associated with the permit is generally the contact
  • Do we need invariants along the lines of:
  • If two or more organizations have the same name they must have different addresses (or emails?)
  • If two or more members have the same name they must have different addresses (or emails?)
  • If two or more organizations have the same address they must have different names.
  • If two or more members have the same address they must have different names.
  • Note: there are many more variants on this to do with shared email addresses, room names, room types. This will impact on the UI, for instance how do you select a member if two members can have the same name?