ASSIGNMENT 1 FRONT SHEET

Qualification Pearson BTEC Level 5 Higher National Diploma in Computing

Unit number and title Unit 20: Applied Programming and Design Principles

Submission date 28/06/2024 Date Received 1st submission 28/06/2024

Re-submission Date Date Received 2nd submission

Student Name Le Thi Huyen Trang Student ID BC00149

Class SE06201 Assessor name Le Nhat Quang

Student declaration
I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand
that making a false declaration is a form of malpractice.

Student’s signature

Grading grid

P1 P2 M1 P3 P4 M2 D1

1
❒ Summative Feedback: ❒ Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

2
Table o Contents
Introduction .................................................................................................................................................... 5

CONTENS ........................................................................................................................................................ 6

I. INVESTIGATE the characteristics of the object- orientated paradigm, including class relationships and
SOLID principles. (P1) ................................................................................................................................. 6

1. Object-Oriented Paradigm (OOP) Characteristics. ............................................................................. 6

2. Class Relationships. ............................................................................................................................ 6

3. SOLID Principles. ................................................................................................................................. 7

II. Explain how clean coding techniques can impact on the use of data structures and operations when
writing algorithms. (P2) .............................................................................................................................. 9

1. Clean Coding Techniques ................................................................................................................... 9

2. Impact on Data Structures and Operations ..................................................................................... 11

III. Design a large data set processing application, utilising SOLID principles, clean coding techniques
and a design pattern. (P3) ........................................................................................................................ 13

1. Use Case Diagram: ............................................................................................................................ 13

2. Class Diagram: .................................................................................................................................. 15

3. ERD ................................................................................................................................................... 18

4. Explanation of SOLID Principles........................................................................................................ 18

5. Package Diagram: ............................................................................................................................. 21

IV. Design a suitable testing regime for the application, including provision for automated testing. (P4)
.................................................................................................................................................................. 23

CONCLUSIOn ................................................................................................................................................. 26

REFERENCES ................................................................................................................................................. 27

3
 LIST OF FIGURES

Hình 1: Use Case Diagram. ........................................................................................................................... 13

Hình 2: Class Diagram. .................................................................................................................................. 15
Hình 3: ERD ................................................................................................................................................... 18
Hình 4: Package Diagram.............................................................................................................................. 21

4
 INTRODUCTION

In today's rapidly evolving educational landscape, the efficient management of student information is
crucial for universities and educational institutions. The Student Information Management System (SIMS)
is designed to address the complexities involved in handling student data, course enrollments, academic
records, and user management. By leveraging modern software design principles and practices, the SIMS
aims to provide a robust, flexible, and maintainable solution that meets the needs of both administrators
and students.

The SIMS integrates various functional components into a cohesive system, ensuring streamlined
operations and improved data accuracy. Key features include managing student records, course
offerings, enrollments, academic programs, departmental structures, and user roles. The system also
supports role-based access control to enhance security and data integrity.

In developing the SIMS, we adhere to the SOLID principles of object-oriented design, ensuring that the
system is not only effective but also scalable and easy to maintain. These principles guide the design and
implementation of our classes and relationships, promoting a modular and adaptable architecture.

This document outlines the structure and components of the SIMS, detailing the classes involved,
their attributes, and the relationships between them. The provided class and package diagrams offer a
visual representation of the system, highlighting the organization and interactions of various elements.
Through this approach, we aim to deliver a comprehensive and user-friendly solution for managing
student information, ultimately contributing to the institution's operational efficiency and educational
excellence.

5
 CONTENS

I. INVESTIGATE THE CHARACTERISTICS OF THE OBJECT- ORIENTATED PARADIGM, INCLUDING CLASS

RELATIONSHIPS AND SOLID PRINCIPLES. (P1)

1. Object-Oriented Paradigm (OOP) Characteristics.

❖ Encapsulation:

Definition: Bundling of data (attributes) and methods (functions) that operate on the data into a
single unit, called a class.

Impact: Protects the internal state of an object and only exposes a controlled interface for interaction,
reducing system complexity and increasing security.

❖ Inheritance:

Definition: Mechanism where one class (subclass/child class) inherits attributes and methods from
another class (superclass/parent class).

Impact: Promotes code reuse and establishes a natural hierarchy, making the system easier to extend
and maintain.

❖ Polymorphism:

Definition: Ability of different classes to be treated as instances of the same class through a common
interface, allowing methods to be used interchangeably.

Impact: Enhances flexibility and reusability of code, as objects of different classes can be manipulated
through a common interface.

❖ Abstraction:

Definition: Simplification of complex systems by modeling classes based on essential features while
hiding unnecessary details.

Impact: Reduces programming complexity and allows focus on high-level functionality.

2. Class Relationships.

• Association:
6
 Real-World Scenario: A Student can enroll in multiple Course objects, and a Course can have multiple
Student objects.

Example: Student ↔ Course.

• Aggregation:

Real-World Scenario: A Department contains Professor objects, but professors can exist
independently of the department.

Example: Department contains multiple Professor.

• Composition:

Real-World Scenario: A University contains Campus objects, and if the university is closed, campuses
are also closed.

Example: University contains multiple Campus.

3. SOLID Principles.

• Single Responsibility Principle (SRP):

Definition: A class should have only one reason to change, meaning it should have only one job or
responsibility.

Importance: Improves maintainability and clarity by ensuring each class has a focused purpose.

• Open/Closed Principle (OCP):

Definition: Software entities should be open for extension but closed for modification.

Importance: Enhances scalability and reduces the risk of introducing bugs when adding new features.

• Liskov Substitution Principle (LSP):

Definition: Subtypes must be substitutable for their base types without altering the correctness of the
program.

Importance: Ensures reliable and predictable behavior in polymorphic systems.

• Interface Segregation Principle (ISP):

7
 Definition: No client should be forced to depend on methods it does not use.

Importance: Promotes modularity and reduces dependencies by having specific interfaces for
different functionalities.

• Dependency Inversion Principle (DIP):

Definition: High-level modules should not depend on low-level modules. Both should depend on
abstractions.

Importance: Promotes loose coupling and makes the system more flexible and easier to test.

8
II. EXPLAIN HOW CLEAN CODING TECHNIQUES CAN IMPACT ON THE USE OF DATA STRUCTURES AND
OPERATIONS WHEN WRITING ALGORITHMS. (P2)

1. Clean Coding Techniques

1.1. Meaningful Names:

Description: Use descriptive and unambiguous names for variables, functions, and classes.

Impact: Improves readability and maintainability.

Readability: Descriptive names allow developers to understand the purpose of a variable, function, or
class without needing additional context.

For example, totalStudents is more descriptive than ts.

Maintainability: When code is easy to understand, it is easier to maintain and update. This reduces
the likelihood of introducing bugs when making changes.

1.2. Functions:

Description: Write small, single-purpose functions.

Impact: Enhances readability and reusability.

Readability: Small functions that do one thing are easier to understand. For instance, a function
named calculateAverageGrade() clearly indicates its purpose.

Reusability: Single-purpose functions can be reused in different parts of the application without
modification. This reduces code duplication and promotes DRY (Don't Repeat Yourself) principles.

1.3. Comments:

Description: Use comments to explain the purpose and rationale behind code decisions.

Impact: Helps others understand the code's intent.

Code Intent: Comments provide context and explain why certain decisions were made, which is
helpful for future maintainers of the code. However, comments should not replace well-written code
that is self-explanatory.

9
1.4. Error Handling:

Description: Manage errors gracefully and predictably.

Impact: Enhances the reliability and robustness of the system.

Reliability: Proper error handling ensures that the system can handle unexpected situations without
crashing. For example, checking for null values before accessing object properties prevents
NullPointerException.

Robustness: Predictable error handling provides a better user experience and makes the system more
stable.

1.5. Code Formatting:

Description: Maintain consistent indentation, spacing, and style.

Impact: Makes code easier to read and maintain.

Readability: Consistent formatting allows developers to read and navigate the code more easily. For
example, consistent use of indentation and line breaks makes the structure of the code clear.

Maintainability: Uniform formatting helps maintain a coherent codebase, making it easier to manage
and modify over time.

1.6. Refactoring:

Description: Regularly improve the code structure without changing its behavior.

Impact: Enhances readability, reduces complexity, and improves maintainability.

Readability: Refactoring makes code more understandable by simplifying complex logic and removing
redundant code.

Complexity: Reduces the cognitive load required to understand the code by breaking down complex
tasks into simpler components.

Maintainability: Continuous refactoring keeps the codebase clean and manageable, preventing it from
becoming outdated and difficult to work with.

10
2. Impact on Data Structures and Operations

2.1. Efficient Use of Data Structures:

Description: Clean coding ensures that appropriate data structures (e.g., arrays, lists, hash tables) are
used for specific problems.

Impact: Leads to efficient algorithm performance.

Efficiency: Using the right data structure for a problem can significantly improve the performance of
algorithms. For example, using a hash table for fast lookups instead of a list.

Resource Management: Efficient data structures optimize memory usage and processing time, leading
to better resource management.

2.2. Algorithm Clarity:

Description: Clean coding makes algorithms more understandable and maintainable.

Impact: Clear variable and function names make the purpose and mechanics of an algorithm evident.

Understandability: Well-named variables and functions clearly convey the logic of the algorithm,
making it easier to follow and debug.

Maintainability: Clear algorithms are easier to update and improve, reducing the risk of errors when
making changes.

2.3. Modular Code:

Description: Clean coding promotes modularity, allowing data structures and algorithms to be reused
across different parts of the application.

Impact: Enhances code reuse and simplifies maintenance.

Reusability: Modular code components can be easily reused in different contexts, reducing
duplication and fostering consistency.

Maintainability: Modularity makes it easier to isolate and fix issues, as changes in one module have
minimal impact on others.

11
2.4. Performance and Optimization:

Description: Cleaner code makes it easier to identify performance bottlenecks and optimize
algorithms.

Impact: Improves the efficiency and responsiveness of the application.

Performance: Clean code simplifies the process of profiling and optimizing algorithms, leading to
faster execution times.

Optimization: Clear and well-structured code makes it easier to pinpoint inefficiencies and apply
optimizations, such as refining data structures or improving algorithmic complexity.

12
III. DESIGN A LARGE DATA SET PROCESSING APPLICATION, UTILISING SOLID PRINCIPLES, CLEAN
CODING TECHNIQUES AND A DESIGN PATTERN. (P3)

1. Use Case Diagram:

Hình 1: Use Case Diagram.

1.1. Classes in the System

Student: Represents information about a student. The attributes include student_id, student_name,
date_of_birth, address, email, and phone_number.

Course: Represents a course. The attributes include course_id, course_name, course_description, and
credits.

Program: Represents an academic program. The attributes include program_id, program_name, and
program_description.

Enrollment: Represents the enrollment of a student in a course. The attributes include enrollment_id,
enrollment_date, student_id (foreign key to Student), and course_id (foreign key to Course).

User: Represents a user of the system. The attributes include user_id, username, password, and role
(indicating if the user is a student, faculty, or admin).

Role: Represents different roles that a user can have. The attributes include role_id and role_name.
13
UserRole: Represents the relationship between users and their roles. The attributes include user_id
(foreign key to User) and role_id (foreign key to Role).

1.2. Relationships Between Classes

Student to Enrollment: A Student can have multiple Enrollments, meaning a student can enroll in
multiple courses. This is a one-to-many relationship (1-N).

Course to Enrollment: A Course can have multiple Enrollments, meaning a course can have many
students enrolled in it. This is a one-to-many relationship (1-N).

Program to Course: A Program can include multiple Courses, meaning a program consists of various
courses. This is a one-to-many relationship (1-N).

Student to User: Each Student can have one User account, meaning a student can log into the system
with one account. This is a one-to-one relationship (1-1).

User to Role: A User can have multiple Roles, and a Role can be assigned to multiple Users. This is a
many-to-many relationship (N-N).

14
2. Class Diagram:

Hình 2: Class Diagram.

• Classes and Attributes

• Student

student_id: A unique identifier for each student.

student_name: The name of the student.

date_of_birth: The student's date of birth.

address: The address of the student.

email: The email address of the student.

phone_number: The phone number of the student.

15
 • Course

course_id: A unique identifier for each course.

course_name: The name of the course.

course_description: A description of the course.

credits: The number of credits the course is worth.

• Program

program_id: A unique identifier for each program.

program_name: The name of the program.

program_description: A description of the program.

• Enrollment

enrollment_id: A unique identifier for each enrollment.

enrollment_date: The date when the enrollment occurred.

student_id: A foreign key referencing Student.

course_id: A foreign key referencing Course.

• User

user_id: A unique identifier for each user.

username: The username of the user.

password: The password of the user.

role: The role of the user (e.g., student, faculty, admin).

• Role

role_id: A unique identifier for each role.

role_name: The name of the role.

• UserRole

16
user_id: A foreign key referencing User.

role_id: A foreign key referencing Role.

❖ Relationships
• Student to Enrollment

Relationship: One-to-Many

Explanation: A single student can enroll in multiple courses. Thus, one Student can have many
Enrollments.

• Course to Enrollment

Relationship: One-to-Many

Explanation: A single course can have multiple students enrolled in it. Thus, one Course can have many
Enrollments.

• Program to Course

Relationship: One-to-Many

Explanation: A single program can include multiple courses. Thus, one Program can have many Courses.

• Student to User

Relationship: One-to-One

Explanation: Each student has exactly one user account in the system. Thus, one Student has one User.

• User to Role

Relationship: Many-to-Many

Explanation: A user can have multiple roles, and a role can be assigned to multiple users. This is
represented through the UserRole join table, which links User and Role.

17
3. ERD

Hình 3: ERD

4. Explanation of SOLID Principles

4.1. Single Responsibility Principle (SRP)

Definition: A class should have one, and only one, reason to change, meaning that a class should have
only one job or responsibility.

Explanation: By adhering to SRP, we ensure that each class in our system is focused on a single task or
responsibility. This makes the system easier to understand, test, and maintain. When requirements
change, only the classes directly related to the changed requirements will need to be modified.

Example: In a Student Information Management System, a class `Student` might be responsible for
managing student data, while a class `StudentPrinter` might be responsible for printing student
information. The `Student` class should not be concerned with how the data is presented or printed.

18
4.2. Open/Closed Principle (OCP)

Definition: Software entities (classes, modules, functions, etc.) should be open for extension but
closed for modification.

Explanation: This principle suggests that the behavior of a module can be extended without modifying
its source code. This can be achieved through inheritance and polymorphism. By doing so, we protect
existing code from changes and reduce the risk of introducing bugs.

Example: Suppose we have a `Course` class. If we want to add new types of courses (e.g., online
courses, lab courses), we should be able to do this by extending the `Course` class and adding new
functionality rather than modifying the existing `Course` class.

4.3. Liskov Substitution Principle (LSP)

Definition: Objects of a superclass should be replaceable with objects of a subclass without affecting
the correctness of the program.

Explanation: This principle ensures that a subclass can stand in for its superclass without the client
code needing to know the difference. To adhere to LSP, subclasses should not override or change the
expected behavior of their superclasses.

Example: If we have a base class `User` and a subclass `AdminUser`, an instance of `AdminUser`
should be usable anywhere an instance of `User` is expected, without causing unexpected behavior.

4.4. Interface Segregation Principle (ISP)

Definition: A client should not be forced to depend on interfaces it does not use.

Explanation: This principle encourages the creation of small, specific interfaces rather than large,
general-purpose ones. This ensures that implementing classes only need to be concerned with the
methods that are relevant to them.

Example: If we have a `User` interface with methods like `login` and `registerCourse`, it may make
sense to split this into two interfaces, `Authenticatable` (with `login` method) and `CourseRegistrable`
(with `registerCourse` ` method). A class that needs only authentication functionality would implement
`Authenticatable` but not `CourseRegistrable`.

19
4.5. Dependency Inversion Principle (DIP)Definition:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Explanation: This principle aims to reduce the coupling between high-level and low-level modules by
introducing abstract interfaces. By doing so, we can change the low-level details without affecting the
high-level policy.

Example: In a university system, instead of a `CourseManager` class depending directly on a

`Database` class to retrieve course data, it could depend on an `ICourseRepository` interface. The actual
implementation of `ICourseRepository` could be a class that retrieves data from a database or an API.
This makes `CourseManager` flexible and easy to test.

4.6. Applying SOLID Principles to the Student Information Management System

In the context of a Student Information Management System, applying SOLID principles ensures that:

SRP Each class has a single responsibility, such as managing student data, handling course
enrollments, or printing reports.

OCP: The system can be extended with new features (like new types of users or courses) without
modifying existing code.

LSP: Subclasses (like `AdminUser` and `StudentUser`) can be used interchangeably without affecting
the system's functionality.

ISP: Classes depend only on the interfaces they need, making the system more modular and easier to
understand.

DIP: High-level modules, such as a `CourseManager`, depends on abstractions like `ICourseRepository`

rather than concrete implementations, making the system more flexible and easier to test.

20
5. Package Diagram:

Hình 4: Package Diagram.

• Relationships:

Student to EnrolledStudent: A student can enroll in multiple courses.

EnrolledStudent to Course: Enrollment is associated with courses.

Course to CourseSubject: Courses can include multiple subjects.

CourseSubject to Subject: Each subject can be part of multiple courses.

Course to Semester: Courses are offered in specific semesters.

Student to Major: Students are enrolled in majors.

21
Major to Department: Majors are part of departments.

Course to Department: Courses are offered by departments.

AppUsers to UserRoles: Users can have multiple roles.

UserRoles to Roles: Roles are associated with users.

22
IV. DESIGN A SUITABLE TESTING REGIME FOR THE APPLICATION, INCLUDING PROVISION FOR
AUTOMATED TESTING. (P4)

Actual
No Test Case Description Expected Result
Result

Create a new Create a new student Student record is created

1 student record with correct details

Assign a student Assign a student to a Student is assigned to the

2
to a department specific department correct department

Enroll a student in Enroll a student in a Enrollment record is created

3 a course specific course with correct student and
class

Create a new Create a new department Department record is created

4 department record with correct details

Create a new Create a new course Course record is created with

5
course record correct details

Assign a course to Assign a course to a Course is assigned to the

a department specific department correct department
6

Create a new Create a new instructor Instructor record is created

7
instructor record with correct details

Assign an Assign an instructor to a Instructor is assigned to the

instructor to a specific class correct class
8
class

23
 Create a new Create a new class record Class record is created with
9
class correct course and semester

Assign a class to a Assign a class to a specific Class is assigned to the

10 semester semester correct semester

Create a new Create a new semester Semester record is created

11
semester record with correct details

Create a new user Create a new user record User record is created with
12 correct details

Assign a role to a Assign a role to a specific User is assigned the correct

13
user user role

Create a new Create a new program Program record is created

14
program record with correct details

Assign a student Assign a student to a Student is assigned to the

15
to a program specific program correct program

Create a new Create a new major record Major record is created with
16
major correct details

Assign a major to Assign a major to a Major is assigned to the

17
a program specific program correct program

Check student Enroll a student in Student can be enrolled in

18 enrollment in multiple classes multiple classes without
multiple classes issues

24
 Validate email Check email format when Only valid email formats are
19 format creating student or accepted
instructor

Duplicate record Check for duplicate System prevents duplicate

20 check for student records student records
students

25
 CONCLUSION

In conclusion, the development of a Student Information Management System (SIMS) that adheres to
modern software design principles is crucial for enhancing the efficiency, maintainability, and scalability
of the system. By implementing the SOLID principles and leveraging various design patterns, we can
ensure that the system is robust, flexible, and easy to extend.

The class diagram and package diagram illustrate the organization of the system into coherent and
logically grouped components, which simplifies understanding and maintenance. The class diagram
focuses on the relationships between individual entities, such as students, courses, programs,
departments, users, and roles, while the package diagram provides a higher-level view of how these
entities are organized into distinct modules.

26
 REFERENCES

1. Actian (2024). Available from

https://docs.actian.com/openroad/6.2/index.html#page/Programming/Class_Relationships.ht
[accessed 27 June 2024].
2. Stackify (2019). What Are OOP Concepts in Java? 4 Primary Concepts. [online] Stackify. Available
at: https://stackify.com/oops-concepts-in-java/ [Accessed 28 Jun. 2024].

27