University Management System

• Learn teamwork.
  • Task distribution, communication and coordination.
  • Learn to break down tasks and define responsibilities.
  • Learn to use supporting tools for team collaboration.
• Apply problem definition techniques.
  • Learn to elicit and specify requirements.
  • Learn to use object-oriented analysis techniques.
• Create solution systematically.
  • Learn to create design models.

A university management system.

A new university is being established and your team is assigned to create a management system for that university. The management system manages, registration, payroll and HR.

In this project you will be using a combination of design patterns of all types: creational, structural and behavioral to design the software system. You are going to create one large class diagram containing all the classes of the design patterns. As such classes may be common between multiple design patterns. The following are the design pattern requirements:

1. Create Faculty objects. There are different types of faculty: Dean, Vice Deans, Chairs and regular faculty. (Factory Design Pattern)
2. Create Student objects. (Factory Design Pattern)
3. Create Course objects (these are courses with no labs). (Factory Design Pattern)
4. There can only be one Dean object (Singleton Design Pattern).

5. Create Course objects with lab objects as a set. Here the creation need to be a set. For example, SE225 course with the SE225 lab. No mixing and matching is allowed between the different courses and labs. (Abstract Factory Design Pattern)

6. The system should allow a faculty to print the list of student names registered in a course. The students can be structured as a linked list. (Decorator Design Pattern)

7. The system should allow the Dean to print the hierarchy of the college. The hierarchy top is the Dean who supervises Vice Deans and Chairs. The Chairs supervise regular faculty. The Vice Deans do not supervise anyone. The hierarchy forms a tree structure. (Composite Design Pattern)

8. The “Course” class offers a function called register( ) for Student objects to use to register the course. The “Lab” class offers a function called registerLab( ) for Student objects to use to register the lab. When a student wants to register a course, the student executes a function called register( ). However, whether registering in a course or a lab, the Student object will only call a function with the name register( ). (Adapter Design Pattern)

9. When a course exam date is changed, all students registered in the course should be notified. (Observer Design Pattern)

10. A course has a number of states. See the following statechart diagram for an illustration and the implication of the state on registration:

11. When a student registers in a course, the registration is handled by a registrar object (Façade Design Pattern). The registrar object checks the student account to make sure there is no overdue payments (job 1: separate object). The registrar then checks that the prerequisite is satisfied (job 2: separate object). The registrar finally registers the student in the course (if it is in the correct state as shown in the statechart diagram). (Combination of Façade and Chain of Responsibility Design Pattern)

12. The system should allow a user to iterate through the college’s faculty members either by rank (Professor – Associate Professor – Assistant Professor – Lecturer) OR by area of specialization (SE – ME – EE – IE – ARE)

Important Notes:

• You will need to create and add classes as you see fit for your design.

• Your design should also be based on your understanding of how a university works. For example, a faculty teaches a student a course
• State any assumptions you make.
• Whenever possible, document alternative design solutions.
• Submit via Moodle

• The submission is due before the class on the due date. Late submission will not be accepted.