Explore

OOAD College Administration System

You are on a Quest to discover 4 things in the Land of your SUD:

Business Objects (business processes) and their composition ( = data and methods)

e.g. Student, Enrollment, Roster, Class

Use Cases: Do use case discovery by looking for who is doing is doing what: Figure out what the Actor’s GOAL is - this becomes the Use Case - you figure out what steps the Actor does to make things happen - these steps are the Business Processes and they become the Algorithms of the METHODS.

Use Cases are the Achievable Outcomes that users want to do when they are using your IT Application:

UC 1: The College Administrator Shall have a PORTAL to assign students to student rosters.

UC 2: The College Adminstrator Shall have a PORTAL to create programs and courses and assign courses to terms and programs.

Compositional Relationships between classes

For example:

Class has-a Roster, Course

Sequence relationships between data state changes in classes: These become your Method Call choregraphy which builds up your Method Choreography.

Apply Lexical Analysis to discover the ‘core business processes’ in your Business Domain:

Business Objects → UML Objects

Look for Data Attributes and methods.

Do Use Case discovery

Outputs:

UML Diagrams:

Class Interactions : Visualize Compositional Relationships via Shared Fields

OID Object Interaction Diagram : visualizes method choreography —→ This is the connecting information plumbing between the Use Cases and the Class Hierarchy.

Personas and use cases for a business domain related to a college delivering education and skills training. Here are 4 new personas:

How do you do Use Case discoveries:

Identify Actors with Goals and write down the series of work steps they do to deliver their goal.

Work steps become the business processes.

These become the Algorithms of the Methods of your Classes.

Actor: College Administrator

Needs ability to manage student enrollment and registration in courses

Wants to track student progress, grades

Requires functionality to manage course catalog

Use Cases for the Actor College Adminstrator:

Enroll student in courses and track progress towards degree

Manage course catalog, schedules, and instructor assignments

Generate reports on enrollment trends and student performance

Actor: Instructor

Must be able to view class rosters and student information

Needs to enter and manage course content, assignments, and assessments

Would like ability to communicate with students and provide feedback on their work

Wants to submit final grades and track student performance over time

Use Cases:

View class rosters and student profiles

Manage course content, assignments, and assessments

Communicate with students and provide feedback

Submit final grades and view student performance trends

Persona 3: Student

Wants to view available courses and register for classes

Needs access to course materials, assignments, and resources

Would like to track their own progress towards degree completion

Wants to view grades and transcript information

Use Cases:

Search and register for courses

Access course materials and submit assignments

View progress towards degree completion

Communicate with instructors and peers

Check grades and view unofficial transcript

Use Cases:

View student profiles and academic progress

Match students with job opportunities and internships

Manage employer partnerships and track recruitment activities

Generate reports on job placement rates and career outcomes

These personas and use cases should provide a good foundation for modeling the business domain and data entities required for a college education and skills training system. The system would need to handle student enrollment, course management, instructor interactions, student progress tracking, and career services.

Ready to Code

UML diagram depicting the entities, their compositional relationships, and their attributes and methods:

classDiagram Progrm "1" *-- "1..*" Class Class "1" -- "1" ClassRoster Program "1" *-- "1..*" Course Program "1" *-- "1..*" Term College_Administrator "1" -- "1..*" Student : Manages student enrollment Instructor "1" -- "1..*" Student : Tracks progress/grades

class Program { -collection of terms -courses per term }

class Class { +class_roster

+Instructor

+Course }

class ClassRoster

class Course

class Term

class Student { +registration() +enrollment() }

class College_Administrator { +Manage student enrollment +Track student progress/grades }

class Instructor { +progress tracking +grade logging } ```

Key points: 1. Program is composed of one or more Classes, Courses, and Terms. 2. Each Class has one Class Roster. 3. College Administrator manages one or more Students and their enrollments. 4. Instructor tracks progress and grades for one or more Students. 5. Student has methods for registration.// — or — let the Adminstrator be in charge of registration: this reduces coupling, ie Number of Method Calls. 6. College Administrator has methods to manage student enrollment and track progress/grades. 7. Instructor has methods for progress tracking and grade logging.

The composition relationships are shown with solid diamonds, while regular associations use simple lines. Methods are prefixed with + and attributes/fields with -.

Method Interaction Action Diagram to assist you will visualizing how to implement the use Cases:

Basic Purpose of an OID Object Interaction Diagram to give you a visual tool to plan how objects will communicate with each other via Method Calls:

Hyperlink:

Creating Object Interaction Diagrams for Business Domains⁠

⁠

Here's a method choreography/interaction diagram based on the given entities and their methods:

sequenceDiagram participant College_Administrator participant Student participant Instructor participant Program

College_Administrator->>Student: enrollStudent(studentId, programId) activate Student Student->>Program: getAvailableCourses() activate Program Program-->>Student: availableCourses deactivate Program Student->>Student: selectCourses(courses) Student->>Program: registerForCourses(studentId, selectedCourses) activate Program Program-->>Student: registrationConfirmation deactivate Program Student-->>College_Administrator: enrollmentConfirmation deactivate Student

loop Each Term Instructor->>Program: getEnrolledStudents(courseId) activate Program Program-->>Instructor: enrolledStudents deactivate Program

loop Each Student Instructor->>Student: trackProgress(studentId) activate Student Student-->>Instructor: progressUpdate deactivate Student

Instructor->>Student: logGrades(studentId, grades) activate Student Student-->>Instructor: gradesLogged deactivate Student end

Instructor->>College_Administrator: submitCourseGrades(courseId, studentGrades) activate College_Administrator College_Administrator->>College_Administrator: updateStudentRecords(studentGrades) College_Administrator-->>Instructor: gradesSubmitted deactivate College_Administrator end

College_Administrator->>Student: trackProgress(studentId) activate Student Student-->>College_Administrator: progressReport deactivate Student ```

This diagram showcases the interaction between the College Administrator, Student, Instructor, and Program entities.

1. The College Administrator enrolls a Student in a Program. 2. The Student retrieves available courses from the Program, selects courses, and registers for them. 3. The Instructor retrieves enrolled students for each course from the Program. 4. For each student, the Instructor tracks their progress and logs their grades. 5. The Instructor submits course grades to the College Administrator, who updates the student records accordingly. 6. The College Administrator tracks the progress of individual students.

The diagram uses activation bars to show the duration of each method's execution and the entity responsible for it. The loop fragments represent repeated actions for each term and each student.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.