EXPERIMENT 1

AIM:
To model the "Course Registration System" with various UML (Unified
Modeling Language) diagrams.

ABSTRACT:

The course registration project helps the user to know the procedures
followed in universities to enroll students for a particular course. The
limitation of the existing system are : the system is not efficient to meet the
needs, the system is very slow and time consuming, not more than one
choice can be given by a student, the number of seats left out and the course
details cannot be [Link] problems that are overcome are the existing
system uses spreadsheet as backend now the proposed system uses access
as backend, the basic requirement of the system has being improved, it has
become user friendly.

PROBLEM STATEMENT

A university needs to develop a Course Registration System to streamline

the process of student enrollment and course management. The current
manual system is error-prone, time-consuming, and lacks efficiency. The
university wants to create a digital system that allows students to register
for courses, professors to manage their courses, and administrators to
oversee the entire process. The system should also provide various UML
diagrams to facilitate design and documentation.

SYSTEM REQUIEMENT SPECIFICATION

SCOPE

a. In this specification, we define about the system requirements that are

about from the functionality of the system.
b. It tells the users about the reliability defined in use case specification.

OBJECTIVES

a. The main purpose of creating the document about the software is to know
about the list of the requirement in the software project part of the project
to be developed.
b. It specifies the requirement to develop a processing software part that
completes the set of requirement.

FUNCTIONAL REQUIREMENTS:
• User Registration and Authentication
• Student Functions
• Professor Functions
• Administrator Functions
• Course Catalog Management
• Notification System

NON-FUNCTIONAL REQUIREMENTS:

• Performance
• Scalability
• Reliability
• Data Integrity
• Error Handling and Recovery

HARDWARE REQUIREMENTS
• Database storage should be provisioned based on expected data
volumes, with room for growth
• Redundant network connections and switches for high availability
• Implement a robust web server like Apache, Nginx, or Microsoft IIS.

SOFTWARE REQUIREMENTS

• operating system such as Linux (e.g., Ubuntu Server, CentOS, Red Hat
Enterprise Linux) or Windows Server
• Back-End: Java, Python, Ruby on Rails, PHP, [Link], .NET
 • Front-End: HTML5, CSS3, JavaScript (frameworks like Angular, React, or
[Link])
• web application framework like Django(Python) to streamline
development and provide structure to the codebase

USECASE DIAGRAM
The main actors are represented at the top: "Student," "Administrator,"
and "Professor."
The "Course Registration System" is the central system being interacted
with.
The use cases are represented below the system, listing the actions that
each type of user (actor) can perform within the system.
Key actions include user authentication (login), course management (add,
modify, close), course registration, monitoring, generating UML diagrams,
and more

CLASS DIAGRAM:
A class diagram describes the type of objectors in the system the various
kinds of static relationship that exist among them.
• Course represents the courses offered by the university. It has attributes
like courseCode , title , description , department , and a reference to the Schedule
class.
• Schedule represents the schedule for a course, including startDate , endDate ,
and a list of TimeSlot objects.
• TimeSlot represents the time slots within a course schedule, with attributes
like dayOfWeek , startTime , and endTime .
• User is the base class for all user types (Student, Professor, Administrator),
with common attributes like username and password .
• Student and Professor are subclasses of User and have their specific
attributes. Student has a studentID and a list of Course objects representing
the courses they are registered for. Professor has a professorID and a list of
Course objects representing the courses they teach.
• Administrator is also a subclass of User with its specific attribute adminId.
ACTIVITY DIAGRAM:
This diagram represents the graphical representation of workflows of
stepwise activities and actions with support for choice, iteration and
concurrency. It shows the overall flow of control.
The process starts with the "Start Process" activity.
The student is required to log in to the system for authentication.
After logging in, the student can search for available courses.
The student can view details about a specific course, such as the schedule and
available seats.
The student can register for a course, drop a course, or modify their course
registration.
The student can also view their course schedule.
The process ends with the "End Process" activity

INTERACTION DIAGRAM
The student starts by logging into the system.
The system authenticates the student's credentials.
The student searches for available courses, which results in a list of courses.
The student can view the details of a specific course.
The student registers for a course, drops a course, or modifies their course
registration, with each action resulting in a confirmation.
The student can also view their course schedule, which provides information
about the courses they are registered for
 COMMUNICATION DIAGRAM
• The "Student" and "Course Registration System" are represented as objects.
• The arrows between the objects indicate the flow of communication and
interactions.
• Messages exchanged between objects are labeled with the corresponding
actions, such as "Login," "Authentication," "Search for Courses," and so on
COMPONENT DIAGRAM:
Component diagrams are used to visualize the organization and relationship
among components in a system.
The "Course Registration System" depends on the "Web Server" and
"Application Server" to function.
The "Application Server" interacts with both the "Database Server" for data
storage and "UML Tools" for UML diagram generation.
STATECHART DIAGRAM:

• The "Course" entity has four states: "Open Enrollment," "Closed

Enrollment," "In Progress," and "Completed."
• Transitions between states occur based on specific events or conditions. For
example:

• A course starts in the "Open Enrollment" state when it's available for
registration.
• When the enrollment period ends, it transitions to the "Closed
Enrollment" state.
• When the course is actively being taught, it enters the "In Progress"
state.
• Finally, when the course is completed, it moves to the "Completed"
state.
PACKAGE DIAGRAM

• The "Course Registration System" is represented as the top-level package.

• Sub-packages are used to group related functionalities:

• "Users Management" encompasses classes related to user

authentication and management.
• "Course Management" includes classes related to course creation,
modification, and viewing.
• "Registration Management" represents classes responsible for
handling student registrations and course enrollment.
• "Schedule Management" includes classes for managing course
schedules and time slots.
• "UML Tools Integration" represents the package responsible for
integrating UML diagram generation tools
DEPLOYMENT DIAGRAM:
Deployment diagrams are used to visualize the topology of the
physical components of a system where the software components are
deployed.
RESULT:
Thus the Course Registration System application was successfully designed and the
output was verified.