.. (לתיקייה המכילה) | ||
How can we make the scheduling algoritm "flexible enough so that the algorithm can be easily replaced"? | |
Think about something similar to the Metrics/Statistics problem in assignment 3: a possible design there was to implement each metric/statistic in its own class, with a common parent class for all metrics/statistics which defines a common interface for all concrete classes. Such design enabled easy addition of new metrics/statistics, and also made the rest of your program aware of only the interface classes and not the concrete classes (less coupling). You can do something similar here: set a common algorithm interface class from which all concrete algorithms inherit; the interface class defines the specific function that runs the algorithm (which is pure virtual in the interface class), and the rest of your program "speaks" only to this interface class. Only place in which we need to know the concrete algorithm classes is the place in which we decide on the algorithm that will be used. For those who are familiar with design patters, or for those who would like to get familiar, you may look for the Strategy design pattern in the design pattern book. |
Is it possible to assume that all future degrees that might be added will fit to the current "thread" of degrees, or is it possible that a totally new degree (e.g. "nurse") will be added? | |
Let's put it this way: It is possible that in the future, we will add different "threads" of degrees (e.g. "junior nurse", "regular nurse" etc.) and that the system will require for a certain position a person of a degree belonging to one of the threads. For instance: "put a person of degree junior nurse in position Y"; in that case - only a nurse will be able to fulfill this position (and not a person of the other "thread"). |
Since shifts are scheduled on a monthly basis, I don't see any possibility to ensure that the first day shift of the month will not include staff members of last night's shift. | |
Basically you are right. Two possible solutions I could think of: - Add a built-in support for this, namely add this information as part of the input - Let the person who runs the program add constraints regarding the staff members in the first regular day shift. I think the second solution is fair enough. |
What do you mean by "By default all staff members except those who took part in the previous night shift should be presend during regular day shift"? Does a regular day shift has any constraints? Do we have minimal number of staff members to be on the shift? Is an empty shift is legsl (by tha default definition it is)? | |
OK, this is a delicate point here: Regular day shifts are "special", because unlike other shifts, the default for regular day shifts is that anyone except those that cannot be part of the shift are present, while in other shifts the default is that anyone except those specifically requested are not present. Also - it is possible that we will still require that certain positions will be taken by staff members of certain degrees during day shifts (like any other kind of shift). So, what I would do is treat these shifts as any other kind of shift (with their own constraints), and just add all staff members that are not constrained to the shift after scheduling all other shifts; think about how to do that. |