-
Notifications
You must be signed in to change notification settings - Fork 0
Appendix 1.1: All Thoughts on the Supplemental Constraints
This page contains all purposed ideas from the team members about the uncaptured constraints from the domain model. The final 5 most interesting constraints are selected from this list. We kept this as part of the documentation. We believe those ideas can be used to check if the later implementation conforms to the requirements from the project scenario.
1. Only the owner may set up the service
indicated in the domain model
2. cannot make an appointment during essential service time
For each Appointment<br /> self.serviceChosen.currentDetail.timeLength < (self.serviceChosen.pastDetail.downtimeEndAt - self.serviceChosen.pastDetail.downtimeStartAt) and self.appointmentTime > self.serviceChosen.pastDetail.downtimeStartAt
3. only one main service in one service combo
indicated in the domain model
4. every customer account has a unique username and password
for each CustomerAccount<br /> for c1,c2 in self (c1<>c2) implies (c1.customerID<>c2.customerID)
5. appointment cannot be updated or canceled by the customer on the day of the appointment
For each Appointment<br /> isCancellable = false it is true that getDate() = appopintmentData
6. service name must be unique
for each Service<br /> for s1,s2 in self (s1<>s2) implies (s1.serviceName<>s2.serviceName)
7. servece combo must contain more than one single service
improve domain mode: change the multiplicity of otherServices to 1..*. Covered by version 1.1.
Proposed by Mike Wang and Cheng Chen
8. Services must have a name which is not null or empty
9. Service names must be only text. No special symbols, emojis, etc.
10. Service must be able to have french accents so it can be bilingual.
11.OwnerAccount must exist before any services can be created
12.OwnerAccount must exist before the business name, address, phone number, etc is written.
13.Start of service duration time must be before the end time.
14.Service duration cannot be zero.
15.Service or service combo cannot be deleted if a future appointment exists for that service.
16.Service combos must be done in the specified order.
17.Customer usernames must be unique (captured in umple code).
18.CustomerAccount must be created before an associated appointment can be created.
19.When a CustomerAccount is deleted, all its associated appointments are deleted.
20.When a service is updated, all appointments with that service are updated too.
21.Appointments cannot be booked during down time (holidays, days off, lunch breaks, another appointment…)
22.Cannot update or cancel an appointment on the day of the appointment.
23.Cannot change the hours to time off if there’s an appointment booked for that time (ex cannot take a vacation day if you have appointments that day)
24.The system can only have one account logged at a time.
Proposed by Catherine Caron and Antoine Wang
26.ServiceCombo cannot have the same Service twice.
For each ServiceCombo: For s1, s2 in services: S1 <> s2
27.Appointment cannot be at the same time as any other appointment, nor be scheduled during Vacation and lunchbreak.
For all a1, a2 in appointments: For all s1 in a1.services, s2 in a2.services: (s1.startTime) Incomplete
For each a in Appointment: (self.appointmentTime < self.calendar.dailySchedule.lunchBreakStartTime and self.appointmentTime + a.service.timeLength < self.calendar.dailySchedule.lunchBreakStartTime) or self.appointmentTime > self.calendar.dailySchedule.lunchBreakEndTime
28.There can only exist 1 owner:
For all accounts: size of (account.isOwner) == 1
29. ServiceCombo cannot be the same as another ServiceCombo.
Meaning that combos are allowed to have the same main service, but there has to be a difference in the rest of the services.
30. Service cannot be the same as another Service
The services also got unique names as identifiers.
31. Account name and password must be unique?
Proposed by Jed Lamari-Saysset and Thomas Jarvis
Concerns and Questioned Constraints:
1.When a customer creates an appointment, they create a Service. They need to receive a list of all possible Services. Does this go through the Service Class to the FlexiBookSystem?
In that case do we know the created Service exists within the List of Services held in the Flexi-Book-System? Or do we need to add constraint that created service must exist within this list?
Concern solved by version 1.1 of the model.
2. Is the business opening at weekend?
3. Customer ID must be unique -> is this within domain model? There is no ID attribute, but the account's name is unique to ensure there is no duplicate accounts.