Академический Документы
Профессиональный Документы
Культура Документы
The following use cases were elaborated for each actor, the Use cases are represented in bold
types.
Student
Professor
Registrar
Maintain curriculum.
A brief description is created for each use case. These descriptions are shown below:
The use case is started by the student. It provides the capability to create,
review, modify, and delete a course schedule for a specified semester. All
pertinent billing information is sent to the Billing System.
This use case is started by the professor. It provides the capability to request a
printed list of all students assigned to a specified course offering.
This use case is started by the professor. It provides the capability to select,
review, modify, and delete a list of courses to teach for a specified semester.
This use case is started by the registrar. It provides the capability to create,
review, modify, and delete student information.
Maintain curriculum
This use case is started by the registrar. It provides the capability to create,
review, modify, and delete professor information.
This use case is started by the registrar. It provides the capability to create,
review, modify, and delete a list of course offerings for a given semester.
Generate catalogue
This use case is started by the registrar. It provides the capability to generate a
catalogue containing a list of course offerings for a specified semester.
The Student Type Package makes up Tier 1 and is sub-divided into three sub-groups; these
are CertificateStudent, DiplomaStudent and DegreeStudent. All these three Sub-Classes
directly inherits the properties of their Super Class (Student Type), hence the Attribute of
these classes are Student Name, Department, Identity, and Address. These are the common
attributes that is inherited from the Super Class to the Sub-Classes. Subsequently Operations
that can be performed on these Classes includes; Admit() and Reject(); this means that a
student can either be admitted into the college or rejected.
Figure VII: Student Course Registration Activity Diagram with Swim Lane
The Activity Diagram shown above details all the sequential steps a student will take to
register for courses. As shown, this Activity diagram is modeled with a Swim-lane, each
swim-lane has a particular operation that is peculiar to it.
The Activity diagram is made up of four (4) swim-lanes, these are; Student, Course Portal,
Registrar and Bursar or Billing system. The operation carried out by a student registering a
course is as explained below;
1
The student Login into the Colleges Student Web portal, on successful login
he,
Browses through the Course Catalogue which presents him with various
courses for the semester and for which he has to register about four (4)
courses. Also in this phase, he has the privilege to Add/Drop courses.
On Successful payment the student becomes full qualified to attend classes for
the registered courses. This ends the students registration.
In this section, again a similar Activity diagram is show, but this time it is modeled without
swim-lanes, but the flow of event are logically represented and carried out. Just like in the
Swim-lane section all the steps necessary for a student to register for courses are the same
hence reference can be made to the illustration for that of the Swim-lane for details.
8. On the conformation of bill payment, the students become qualified and can attend
classes.