This content has been marked as final. Show 2 replies
geeksaint wrote:Seems a bit algebraic to me (although very well described). Hoary old analysts like me tend to prefer names (and moreover descriptive names) to letters; otherwise the old 7 ± 2 rule quickly comes into effect.
I would really appreciate your comments and criticisms on the description of the problem.
Also, you seem to be concentrating on sets and groupings, whereas I think I would be more interested in covering the elemental entities first (Teacher, Student, Room, TimeSlot, Subject etc - Note that all those names are singular, a suggestion given to me many moons ago when I was starting out).
These are sometimes called "actors" (although the term can also refer to the users of the system), and are a good basis for understanding the parameters of your problem/system.
Next, I would have a think about what your system needs to do. Concentrating too much on groupings tends to lead to premature implementation (the "oh yes, we're going to need one of those" approach), whereas deciding what it needs to do focuses your mind on the actual requirements. You might also want to consider who is going to use this system.
One thing that springs immediately to mind is the need to assign "lessons" (ie, gathering a group of Students in a specific Room at a specific time with a specific Teacher for a specific Subject). Again, don't go overboard about how this is done; just identify it as a requirement. There'll be plenty of time for the "how" once you've identified the "what".
Just one more thing about those individual entities: You've identified a "Room", but what about a Sports lesson or a Field day? What is the "Room" then? Might there be a better name? I suspect there's absolutely nothing wrong with a Room, but possibly as part of a greater whole (Venue?).
Finally, there is no "right" approach. Anything that makes you think about the problem is likely to improve the design.