This image above shows my interpretation of the USEP enrollment system using a use case diagram. According to "wikipedia.com", use case diagram consists of use cases (actions done or processed in the system) , actors (persons involved in the system), relations (determines which actor performs a use case) and boundaries (system boundaries and system boundaries). I based my answer on that description of a use case diagrams.

I will discuss the objects involved in my use case diagrams.

Actors:

Enrollee is considered the customer of this enrollment system. He is the basis of all basic use cases inside the use case diagram.

Treasurer is the actor that collects and assess a student in student fees such as local council fees, publication fees, organization fees and other student collected fees.

Adviser is the actor that identifies the subjects allowed for a student to enroll upon.

Librarian is the actor that registers the student as an officical bearer of an library card.

Cashier is the actor that assess the payments needed for an enrolle to enroll and also collects tuition fees and other university fees.

Encoder is the actor that encodes the subjects of the enrollee.

Registrar is the actor that register the subjects of the enrollee as official subjects of the enrollee.

Use Cases:

Assess Student is the use case used when an actor needs to assess an enrollee.

Pay Assesment is the use case used when an actor performs an action related to payment and collection.

Identify Subjects is the use case used when an actor performs an action that relates to determining subjects which the enrollee wants.

Encode Subjects is the use case used when an action is related to encoding of subjects.

Register Students is the use case used when an actor performs an action that relates to registration.

I would like to further discuss my diagram. As you can see I placed actor on two sides. Those actors seen in the left side are actors that has no direct access to the automated system while those in the right side are the one that has access to the automated system. If you can see no all actors have relationship with uses cases because that action is not done by the actor. He may be involved but he does not directly performs that action. Like the use case "Encode Subjects", only the encoder has access to the computer and it is not the enrollee that directly encodes the subjetcs in the software. The above statement are also used to justify why i did not relate other actors into a use case.