ASSIGNMENT FINAL REPORT

Qualification Pearson BTEC Level 5 Higher National Diploma in Computing

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

Submission date Date Received 1st submission 9/8/2024

Re-submission Date Date Received 2nd submission

Student Name PHAM VAN NHAT Student ID BS00403

Class SE06201 Assessor name NGUYEN SI THIN

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 NHAT

Grading grid

P1 P2 P3 P4 M1 M2 D1
 ASSIGNMENT GROUP WORK
Qualification Pearson BTEC Level 5 Higher National Diploma in Computing

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

Submission date Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student names & codes Final scores Signatures

1. PHAM VAN NHAT- BS00403 NHAT

2. DOAN DUC TAM - BD00300 TAM

Group number:
3. CHAU NGUYEN NGOC AN - BD00254 AN

Class Assessor name

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.
P5 P6 P7 M3 M4 D2
 OBSERVATION RECORD
Student

Description of activity undertaken

Assessment & grading criteria

How the activity meets the requirements of the criteria

Student
Date:
signature:

Assessor
Date:
signature:

Assessor
name:
r Summative Feedback: r Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

 TABLE OF CONTENT

TABLE OF CONTENT........................................................................................................................................5

LIST OF TABLES AND FIGURES.........................................................................................................................7

LIST OF THE ACRONYM..........................................................................................................................10

INTRODUCTION.........................................................................................................................................11

CHAPTER 1 INVESTIGATE THE IMPACT OF SOLID DEVELOPMENT PRINCIPLES ON THE OOP

PARADIGM(LO1).......................................................................................................................................12

1.1 Investigate the characteristics of the object- orientated paradigm, including class relationships and
SOLID principles.(P1)..................................................................................................................................12

1.1.1Object-oriented model:.........................................................................................................................12

1.1.2 There are principles guiding the construction and organization of the program:................................12

1.1.3 Class Relationships..............................................................................................................................15

1.1.4 SOLID Principle..................................................................................................................................18

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

1.2.1 Clean Coding Techniques....................................................................................................................22

1.2.2 Impact on Data Structures and Operations.........................................................................................22

CHAPTER 2. DESIGN A LARGE DATASET PROCESSING APPLICATION USING SOLID

PRINCIPLES AND CLEAN CODING TECHNIQUES..............................................................................27

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

2.1.1 Design and use SOLID principles........................................................................................................27

2.1.2 Use case diagram.................................................................................................................................28

2.1.3 A package diagram...............................................................................................................................31

2.1.4 A class diagram....................................................................................................................................33

2.1.5 An explanation of how SOLID............................................................................................................34

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

2.2.1 Automated testing................................................................................................................................38

2.2.2 Types of automatic testing:..................................................................................................39

2.2.3 Experimental design.............................................................................................................................42

CONCLUSION.............................................................................................................................................57

REFERENCES..............................................................................................................................................58
 LIST OF TABLES AND FIGURES
Figure 1 - 1. OOP........................................................................................................................................................12

Figure 1 - 2 Encapsulation..........................................................................................................................................13

Figure 1 - 3 Abstraction - Abstract Class.....................................................................................................................13

Figure 1 - 4 Abstraction- Interface.............................................................................................................................14

Figure 1 - 5 Inheritance..............................................................................................................................................14

Figure 1 - 6 Polymorphism- Method Overloading......................................................................................................15

Figure 1- 7 Polymorphism- Method Overriding.........................................................................................................15

Figure 1 - 8. UML........................................................................................................................................................16

Figure 1 - 9 Inheritance..............................................................................................................................................16

Figure 1 - 10 Composition..........................................................................................................................................17

Figure 1 - 12 Realization/ Implementation:...............................................................................................................17

Figure 1 -13 Dependencies.........................................................................................................................................18

Figure 1 -14 Association.............................................................................................................................................18

Figure 1 - 15. SOLID....................................................................................................................................................19

Figure 1 - 16 S - Single-responsibility Principle...........................................................................................................19

Figure 1 - 17 O - Open-closed Principle......................................................................................................................20

Figure 1 - 18 L - Liskov Substitution Principle.............................................................................................................20

Figure 1 - 19 I - Interface Segregation Principle.........................................................................................................21

Figure 1 - 20 D - Dependency Inversion Principle......................................................................................................21

Table 1 - 1 Principles and methods of clean code......................................................................................................24

Figure 1 - 21 Variable names are meaningful to the data structure..........................................................................24

Figure 1 - 22 Modularity in data operations...............................................................................................................25

Figure 1 - 23 Annotations for complex data structures:.............................................................................................25

Figure 1 -24 Consistency in using data structures......................................................................................................26

Figure 2 -1 A use case diagram..................................................................................................................................28

Table 2 - 1 Use Case Diagram.....................................................................................................................................29

Figure 2 - 2 A package diagram..................................................................................................................................31

Figure 2 - 3 Package Diagram for System...................................................................................................................32

Figure 2 - 4 A package diagram...................................................................................................................34

Figure 2 - 5 Check Account of SRP..............................................................................................................................35

Figure 2 - 6 AccountManagement of SRP...................................................................................................................35

Figure 2 - 7 OCP.........................................................................................................................................................36

Figure 2 - 8 LSP...........................................................................................................................................................36

Figure 2 - 10 DIP.........................................................................................................................................................38

Figure 2 - 11 Automated testing................................................................................................................................38

Table 2 -1 Advantages and disadvantages.................................................................................................................40

Figure 2 - 5 xUnit........................................................................................................................................................40

Figure 2 - 6 Fact..........................................................................................................................................................41

Figure 2 - 8 ClassData.................................................................................................................................................42

Figure 2 - 9 MemberData...........................................................................................................................................42

Figure 2 - 10 Test case 1 - Add student to the system when email is invalid.............................................................43

Figure 2 - 11 Test case 2 - Add student with valid email............................................................................................43

Figure 2 - 12 Test case 3 Add student with email containing special characters........................................................44

Figure 2 - 13 Test case 4 Add student with missing email domain.............................................................................44

Figure 2 - 14 Test case 5 Add student with containing spaces...................................................................................45

Figure 2 - 15 Test case 6 Add student with email missing ‘@’ symbol.......................................................................45

Figure 2 - 16 Test case 7 Add student with email having invalid top- level domain...................................................46

Figure 2 - 17 Test Case 8 Add student with email exceeding length limit..................................................................46

Figure 2 - 18 Test Case 9: Add student with email having multiple '@' symbols.......................................................47

Figure 2 - 19 Test Case 10 Add student with email containing uppercase letters......................................................47

Figure 2 - 20 Test results............................................................................................................................................48

Table 2 - 2 Test report................................................................................................................................................48

 LIST OF THE ACRONYM
OOP Object-Oriented Programming

SISM Student Information System Management

SRP Single Responsibility Principle

OCP Open/Closed Principle

LSP Liskov Substitution Principle

ISP Interface Segregation Principle

DIP Dependency Inversion Principle

E2E End-to-End

MVC Model-View-Controller
 INTRODUCTION
From the report in asm1 we continue in asm2

In the field of computing, cognitive skills include a deep understanding of essential facts, concepts,
principles and theories. These skills enable individuals to model and design computer-based systems,
facilitating understanding, communication, prediction and evaluation of trade-offs. The ability to
recognize and analyze specific criteria and specifications of a problem, along with planning effective
strategies, is important. Furthermore, evaluating the performance and future development of computer-
based systems, along with deploying appropriate theories, practices and tools, is an integral part of their
design, implementation and evaluation.

Practical computing skills include evaluating systems based on quality attributes and potential trade-
offs, managing projects within given constraints and recognizing risks and safety aspects. Proficiency in
the use of tools for building and documenting computer applications, along with critical evaluation and
analysis of complex problems, is essential. These skills are essential in delivering solutions within budget.

❖ This report consists of the following chapters:

CHAPTER 1 INVESTIGATE THE IMPACT OF SOLID DEVELOPMENT PRINCIPLES ON THE OOP

PARADIGM(LO1)

 (P1) Investigate the characteristics of the object- orientated paradigm, including class relationships
and SOLID principles.

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

CHAPTER 2. DESIGN A LARGE DATASET PROCESSING APPLICATION USING SOLID PRINCIPLES AND CLEAN
CODING TECHNIQUES

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

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

CHAPTER 3 BUILD A DATA PROCESSING APPLICATION BASED ON A DEVELOPED DESIGN(LO3)

 P5: Build a large dataset processing application based on the design produced

CHAPTER 4 PERFORM AUTOMATIC TESTING ON A DATA PROCESSING APPLICATION(LO4)

 P6: Examine the different methods of implementing automatic testing as designed in the test plan.

 P7: Implement automatic testing of the developed application

CHAPTER 1 INVESTIGATE THE IMPACT OF SOLID DEVELOPMENT PRINCIPLES ON THE OOP
PARADIGM(LO1)

1.1 Investigate the characteristics of the object- orientated paradigm, including class
relationships and SOLID principles.(P1)

1.1.1Object-oriented model:
 Definition of OOP:

- Object-oriented programming (OOP) is a programming model based on the concept of "objects", which
can contain data in the form of fields (usually called properties or attributes) and code in the form of
procedures (usually called as methods). General structures in OOP include classes, objects, properties,
constructors, and methods.

Figure 1 - 1. OOP

1.1.2 There are principles guiding the construction and organization of the program:
 Encapsulation: Encapsulation is the concept of wrapping data and the methods that operate on the
data within a single unit or class. This helps protect the data from outside interference and misuse.
 Figure 1 - 2 Encapsulation

 Abstraction: Abstraction is the process of hiding the complex implementation details and showing
only the essential features of the object. This can be achieved using abstract classes and interfaces.

- Abstract Class:

Figure 1 - 3 Abstraction - Abstract Class

- Interface:
 Figure 1 - 4 Abstraction- Interface

 Inheritance: Inheritance is a mechanism where a new class inherits the properties and behaviors of
an existing class.

Figure 1 - 5 Inheritance

 Polymorphism: Polymorphism allows objects to be treated as instances of their parent class rather
than their actual class. The most common use of polymorphism is when a parent class reference is
used to refer to a child class object.
 - Method Overloading (Compile-time Polymorphism):

Figure 1 - 6 Polymorphism- Method Overloading

- Method Overriding (Run-time Polymorphism):

Figure 1- 7 Polymorphism- Method Overriding

1.1.3 Class Relationships

a) Definition of UML:

- Unified Modeling Language (UML) is a standardized modeling language that provides a general-
purpose, developmental, modeling framework for specifying, visualizing, constructing, and documenting
the artifacts of software systems. A class diagram is a type of static structure diagram that describes the
structure of a system by showing its classes, their attributes, operations (or methods), and the
relationships among the objects.[2]

Figure 1 - 8. UML

b) Identify Real-World Scenarios:

 Real-world scenarios for different types of class relationships include:

 Inheritance:Inheritance is used to describe the relationship between the base class and derived
class. In an inheritance relationship, the child class will inherit all the properties and methods of the
parent class. At the same time, the child class can add different information than the parent class

Figure 1 - 9 Inheritance

 Composition: Is the relationship between the whole and a part of the class. When the overall object
does not exist, the parts will not exist.
 Figure 1 - 10 Composition

 Aggregation: Represents the relationship between the whole and part of the class, in which parts
can exist independently of the overall object.

Figure 1- 11 Aggregation

 Realization/ Implementation: Used to define the relationship between interface and implementing
classes, a class implementing an interface must implement all the methods that the interface has
declared

Figure 1 - 12 Realization/ Implementation:

 Dependencies: Is a relationship where changes in one layer can affect the other layer. A change in
one layer can affect other tests in another layer
 Figure 1 -13 Dependencies

 Association: A class property contains references to instances of other classes. There is a connection
between this object and another object. Composition and Aggregation also belong to association
relationships

- There are four types of links: two-way links, one-way links, character links, and multiple number links

Figure 1 -14 Association

1.1.4 SOLID Principle

a) SOLID Introduction

- SOLID is a set of software design principles intended to make source code easy to maintain, extend, and
reuse. These principles were introduced by Robert C. Martin (aka Uncle Bob) and are the foundation of
object-oriented programming (OOP) and good software design.[3]
 Figure 1 - 15. SOLID

 Purpose: The goal of the SOLID principles is to improve the flexibility, scalability, and maintainability
of software by creating systems that are easy to understand, change, and extend.

b) SOLID types

 S - Single-responsibility Principle

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

- Meaning: Makes code clearer and easier to understand, reduces dependencies between parts of the
system, and makes maintenance and extension easier.

Figure 1 - 16 S - Single-responsibility Principle

 O - Open-closed Principle

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

- Meaning: Allows system functionality to be expanded without changing existing source code, helping to
minimize errors and increase stability.
 Figure 1 - 17 O - Open-closed Principle

 L - Liskov Substitution Principle

- Definition: Objects of a derived class must be able to substitute for objects of the base class without
changing the correctness of the program.

- Meaning: Ensures that subclasses can be used in place of the superclass without damaging the
correctness of the application.

Figure 1 - 18 L - Liskov Substitution Principle

 I - Interface Segregation Principle

- Definition: Classes should not be forced to depend on interfaces they do not use. Instead, specific
interfaces should be created with a clear purpose.
- Meaning: Reduce dependencies and increase flexibility by creating smaller, more specific interfaces
instead of large, generic interfaces.

Figure 1 - 19 I - Interface Segregation Principle

 D - Dependency Inversion Principle

- Definition: High-level modules should not depend on low-level modules. Both should depend on
abstract interfaces. Abstract interfaces should not depend on details. The details should depend on the
abstract interfaces.

- Meaning: Reduce dependencies between modules, increase extensibility and source code reuse.

Figure 1 - 20 D - Dependency Inversion Principle

c) Benefits of SOLID

 Ease of Maintenance: SOLID principles help create code that is easy to read, understand, and
maintain. This helps minimize the time and effort required to fix errors and make changes.

 Source Code Reuse: Classes and modules designed according to SOLID principles are highly
reusable, helping to reduce the effort of redeveloping source code for different projects.

 Increased Flexibility and Scalability: Systems that follow SOLID principles are easily extended and
adapted to meet new requirements without having to change existing code.

 Minimize Risk and Errors: By separating responsibilities and reducing dependencies between
modules, SOLID principles help minimize risk and errors when making changes or adding new
features.

 Improves Development Process: SOLID principles encourage good development practices and
help create a more structured and organized software development process.

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

1.2.1 Clean Coding Techniques

 Meaningful Naming: Use descriptive and unambiguous names for variables, functions, classes, and
other identifiers. Avoid abbreviations unless they are widely understood.

→Example: Instead of naming a variable ‘a’, use ‘age’ if it stores the age of a person.

 Modularity: Break down the code into small, self-contained modules or functions, each responsible
for a single piece of functionality. This makes the code easier to understand, test, and maintain.

→Example: Instead of having a large function that performs multiple tasks, split it into smaller functions,
each performing a single task.

 Consistency: Follow a consistent coding style and conventions throughout the codebase. This
includes consistent naming conventions, indentation, and use of braces.

→Example: If you follow camelCase for variable names, use it consistently for all variable names.

 Comments: Use comments to explain the purpose and logic of the code, especially in complex
sections. Avoid redundant comments that merely restate what the code does.

1.2.2 Impact on Data Structures and Operations

a) The encryption techniques are clear
 Meaningful variable names: Use descriptive variable, function, class, and other identifiers that are
clear and unambiguous. Avoid using abbreviations unless they are widely understood.

 Modularity: Dividing source code into small, independent modules or functions, each responsible for
a specific function. This makes the code easy to understand, test, and maintain.

 Comments: Use comments to explain the purpose and logic of the code, especially in complex
sections. Avoid redundant comments that simply reiterate what the code already does.

 Consistency: Adhere to consistent coding style and conventions throughout the source code. This
includes naming, indentation, and use of brackets.

❖ Why is clean code important:

Easier to understand: Clean code is easy to read and understand,

 Maintainability: When code is clean, making changes, adding features, or fixing bugs becomes much
simpler.

 Collaboration: Facilitates teamwork It minimizes misunderstandings and errors caused by unclear

code.

 Extensibility: It ensures that components can be reused and extended without extensive rewriting.

 Debugging and testing: Clear and concise code paths make it simpler to trace the source of the
problem.

 Performance: Properly structured code will manage resources more efficiently

 Adaptability: Refactoring is easier than clean code making refactoring less risky and more
manageable.

 Principles and methods of clean code:

Principles and methods Description

Meaningful Names Use descriptive and unambiguous names for

variables, functions, and classes.

Single Responsibility A class or function should have one and only one
reason to change.

DRY (Don't Repeat Yourself) Avoid duplication of code by abstracting common

functionalities.

KISS (Keep It Simple, Stupid) Keep your code simple and avoid unnecessary
complexity.
 YAGNI (You Aren't Gonna Need It) Don't add functionality until it is necessary

Consistent Style Use consistent coding style and conventions

throughout the codebase.

Write Tests Write automated tests to ensure code correctness

and facilitate refactoring

Refactoring Regularly refactor code to improve its structure

and readability.

Documentation Provide clear and concise documentation for

complex code sections.

Code Reviews Regularly conduct code reviews to catch issues and

share knowledge.

Table 1 - 1 Principles and methods of clean code

b) Impact on Data Structure and Operations

 Variable names are meaningful to the data structure:

Figure 1 - 21 Variable names are meaningful to the data structure

- Impact: Meaningful variable names make the purpose of the 'studentAges' and 'courseIds' lists clear,
making them easier for readers to understand and reducing the possibility of errors.

 Modularity in data operations:

 Figure 1 - 22 Modularity in data operations

- Impact: Modular functions improve readability and reuse. Each function only performs a single task,
making the code easier to test and maintain.

 Annotations for complex data structures:

 Annotations for complex data structures:

Figure 1 - 23 Annotations for complex data structures:

- Impact: Annotations clarify the structure and purpose of the graph, making it easier for new
programmers to understand how the graph is represented.

 Consistency in using data structures:

 Figure 1 -24 Consistency in using data structures

- Impact: Consistent use of a dictionary to store user information makes code more readable and reduces
the cognitive burden on the programmer, making data management and processing easier.
CHAPTER 2. DESIGN A LARGE DATASET PROCESSING APPLICATION USING SOLID
PRINCIPLES AND CLEAN CODING TECHNIQUES

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

2.1.1 Design and use SOLID principles

❖ Scenario

Currently, the school is looking for ways to systematize the student information system to improve
efficiency and maintainability. Our team will work to design and implement a robust SIMS that follows
object-oriented, SOLID principles, clean code, and multiple design partners.

 Require function:

 Course management:

- Provides functionality for administrators to manage courses offered by the university.

- Assign students to courses based on their program of study.

 User authentication and authorization:

- Ensure secure user authentication for students, faculty, and administrators.

- Implement role-based access control to restrict system functions based on user roles.

 Require function:

- The system must allow for efficient registration of new students.

- Collect and store necessary student information, including personal information and academic records.

 Unreasonable requests:

- Scalability: The system must be scalable to accommodate increasing numbers of students and courses
over time.

- Efficiency: Ensures the system meets user requirements within acceptable timeframes, even during
peak usage periods.

- Accessibility: Ensure systems are accessible to users with disabilities, adhering to accessibility
standards.
- Reliability: The system must be reliable, with minimal downtime for maintenance or unexpected
failures.

- Security: Implement strong security measures to protect sensitive student information and ensure data
integrity.

- Usability: User-friendly interface design, suitable for users with different levels of technical expertise.

2.1.2 Use case diagram

- A use case diagram is a diagram that describes the interactions that can occur between a user and a
system. This diagram includes use cases as well as different user types of the system and is often
accompanied by several other types of diagrams. Use cases are represented by circles or ellipses, and
actors are often represented as human figures.

Figure 2 -1 A use case diagram

 Use Case Diagram includes the following main components:

Ingredient Illustration Description

 Use cases Different scenarios where the system is used to perform
specific functions.

Associations Relationships between different use cases and other

system components or actors.

Actor Individuals or entities interacting with the system.

Include Common functionalities that are included in multiple use

cases.

Extend Optional extensions that enhance the basic functionality

of the use cases.

Table 2 - 1 Use Case Diagram

 Describe the use case of the system:

 Manage Classes

- Actor: Teacher

- Description: The teacher can create, update, and delete classes. This includes assigning students to
classes and managing class schedules.

 Create, Delete and Update Student Scores

- Actor: Teacher

- Description: The teacher can input, modify, and remove student scores for various assignments, exams,
and overall grades.

 View Student Information

- Actor: Teacher, Admin

- Description: Both teachers and administrators can access detailed information about students,
including personal data, academic records, and enrollment status.

 Log In/Out

- Actor: Student, Teacher, Admin

- Description: All users (students, teachers, and administrators) can log into and out of the system
securely using their credentials.
 View Student Points

- Actor: Student, Teacher

- Description: Students can view their own grades and points. Teachers can also view the grades and
points of the students they are responsible for.

 View Course

- Actor: Student

- Description: Students can browse and view details of the courses they are enrolled in or interested in
enrolling.

 View Account in Course

- Actor: Student

- Description: Students can access their personal accounts to manage their course enrollments and view
their academic progress.

 Manage Users

- Actor: Admin

- Description: Administrators can manage user accounts, including creating, updating, and deleting
accounts for students, teachers, and other administrators.

 Generate Reports

- Actor: Admin

- Description: Administrators can generate various reports related to student performance, course
enrollments, and overall system usage.

 System Settings

- Actor: Admin

- Description: Administrators can configure and manage system settings, including security settings,
system parameters, and other administrative functions.

 Associations:

- Actors such as Students, Teachers, and Admins interact with the system to perform the described use
cases.

- Use cases like "Log In/Out" are fundamental and are associated with all actors for accessing the system.

- Actions such as managing classes, scores, and users are more specific to roles like Teachers and Admins.
 Include:

- The "Log In/Out" use case is included in all scenarios where a user needs to access the system.

- "View Student Information" and "View Student Points" are included in the functionalities for both
Teachers and Students.

 Extend:

- "Generate Reports" can be extended by additional reporting capabilities based on specific

requirements.

- "System Settings" can be extended to include more detailed administrative functions as needed.

2.1.3 A package diagram

- A package diagram is a type of diagram in Unified Modeling Language (UML) used to describe the logical
structure of a software system. It allows modeling packages and relationships between them.

Figure 2 - 2 A package diagram

❖ Package Diagram for System:

 Figure 2 - 3 Package Diagram for System

 Describe package diagram of system:

 Account Package:

- account management: Likely a class for managing accounts.

- IAccount: An interface for account-related operations.

- account: A class implementing the IAccount interface.

 Person Package:

- Person: A general class representing a person.

- Admin: A subclass of Person representing administrative personnel.

- Teacher: A subclass of Person representing a teacher.

- Student: A subclass of Person representing a student.

 Student Package:

- Student Point: A class for managing student points.

- IStudent Point: An interface for operations related to student points.

- Student In formation Management: A class for managing student information.

- Student Point Management: A class for managing the points of students.

 Education Package:

- Course: A class representing a course.

- ICourse: An interface for course-related operations.

- Class: A class representing a class.

- IClass: An interface for class-related operations.

- Course In formation Management: A class for managing course information.

- Class In formation Management: A class for managing class information.

- View Account In Course: Possibly a class for viewing account details within a course context.

2.1.4 A class diagram

- A class diagram is a type of diagram in Unified Modeling Language (UML) used to describe the static
structure of a software system by representing classes, attributes and attributes. their methods, as well
as the relationships between classes.

❖ Class diagram for system:

 Figure 2 - 4 A package diagram

2.1.5 An explanation of how SOLID

a) Explanation

 Use Case Diagram Explanation

- Use case diagrams outline how different actors interact with SIMS. Administrators can manage users,
generate reports, and configure system settings. Teachers can manage classes, enter grades, and view
student profiles. Students have the ability to view grades, class schedules, and update their personal
information. Parents can view their child's grades and class schedule. This diagram helps visualize the
different functions provided by the system from the user's perspective.

 Class Diagram Explanation

- The class diagram illustrates the structure of the SIMS system. Users are represented by common
attributes such as ID, name, email, and password. Roles determine access levels in the system. Students
have their grades and class schedules, while teachers manage their classes and assign students to them.
Classes contain students and grades are associated with students. Administrators have specific actions
related to managing users, generating reports, and configuring settings. This structured approach ensures
clarity in system design and helps understand the relationships between different entities.

 Package Diagram Explanation

- A package diagram shows how classes are grouped into logical packages. ‘UserManagement’ handles
classes related to user management such as Users, Roles, and Administrators. ‘AcademicManagement’
handles academic-related functions including Teachers, Classes, Students, and Grades. This organization
promotes modularity and encapsulation, allowing for easier maintenance and extension of SIMS
applications.

b) Apply the SOLID principle

 Single Responsibility Principle (SRP):

Each class and package is designed to have a single responsibility. For example, ‘UserManagement’
package only handles user-related activities while ‘AcademicManagement’ focuses on academic
functions. This ensures classes have clarity about their roles.

Figure 2 - 5 Check Account of SRP

Figure 2 - 6 AccountManagement of SRP

 Open/closed principle (OCP):

Classes are designed to be open to extension but closed to modification. For example, new roles or user
types can be added by extending existing classes (like User) without changing their core implementation.
 Figure 2 - 7 OCP

 Liskov Substitution Principle (LSP):

Derived classes (e.g. Student, Teacher, Administrator) can replace their base class (User) without
affecting the correctness of the application. This principle ensures compatibility and flexibility within the
class hierarchy.

Figure 2 - 8 LSP

 Interface Segregation Principle (ISP):

Interfaces (not shown explicitly in the diagram for brevity) are used to define specific contracts. For
example, interfaces can separate functionality required by different user roles, ensuring classes
implement only what they need.

Figure 2 - 9 ISP

 Dependency Inversion Principle (DIP):

High level modules (like Admin, Teacher, Student) depend on abstraction (interface) rather than concrete
implementation. This allows for easier decoupling and management of dependencies, facilitates easier
unit testing, and more flexibility in changing implementations.
 Figure 2 - 10 DIP

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

2.2.1 Automated testing

- Use software tools to run tests on your code automatically to ensure it functions as expected and to
catch errors early in the development process. Automated tests can include unit tests, integration tests,
and end-to-end tests, providing a safety net that helps maintain code quality as changes are made. This
practice enables continuous integration and continuous deployment (CI/CD), fostering faster and more
reliable software development.

Figure 2 - 11 Automated testing

 Benefits of automated testing in the application development process:

 Run tests faster, allowing for frequent testing and quick feedback.

 Eliminate human error, ensuring steps are performed correctly every time.

 Reduce manual effort, save human resources.

 Test regularly, support continuous integration and continuous deployment (CI/CD).

 Manage and process large amounts of data effectively.

 Integrates well with modern development methods such as Agile and DevOps.

2.2.2 Types of automatic testing:

 Unit Testing:

- Definition: Tests individual units or components of the software to ensure they work as intended.

- Purpose: Validates the smallest parts of an application independently.

 End-to-End (E2E) Testing:

- Definition: Tests the complete workflow of the application from start to finish.

- Purpose: Ensures the entire application flow works correctly from the user’s perspective.

 User Interface (UI) Testing:

- Definition: Tests the graphical user interface to ensure it meets specifications.

-Purpose: Validates that the UI behaves as expected and is user-friendly.

 Advantages and disadvantages

Test Type Advantages disadvantages

Unit Testing - Detect errors early. - Limited range.

- Generate code documentation automatically. - Requires in-depth knowledge.

- Ensure high code quality. - Do not test the user interface.

- Quick testing.

End-to-End (E2E) - Test the entire system. - Long testing period.

Testing
- Detect integration errors. - Complicated and difficult to
maintain.
- Guaranteed user experience.
- Poor fault tolerance.
 User Interface (UI) - Make sure the user interface works properly. - Long testing period.
Testing
- User interaction testing. - Difficult to maintain.

- Display error detected. - Depends on the environment.

Table 2 -1 Advantages and disadvantages

 Testing application

▪ xUnit: A modern, extensible testing framework focused on simplicity

▪ NUnit: A widely used testing framework, with a rich feature set and extensive plugin ecosystem.

▪ MSTest: Default framework provided by the Microsoft Visual Studio toolkit, providing tight

integration with Visual Studio and supported by Microsoft.

▪ Integration Testing: Testing integration between SIMS components.

 xUnit

Figure 2 - 5 xUnit

 Fact: Use [Fact] attribute to check. It's simple and modern, with a focus on scalability.
 Figure 2 - 6 Fact

 Theory: is the way of creating test cases based on data. It includes the following 3 data attributes:

- InlineDataTest: Constant values or small sets of data are defined directly within the test method.

Figure 2 - 7 InlineData

- ClassData: A separate class implementing IEnumerable<object[]> is used to provide the test data.
 Figure 2 - 8 ClassData

- MemberData: The test data is defined in a static property or method of the same class.

Figure 2 - 9 MemberData

2.2.3 Experimental design

In designing the test mode for this student information management application, I will use xUnit

 Test case 1 - Add student to the system when email is invalid

- Description: Check the behavior of adding students with invalid email addresses and that student will
not be added to the system

Figure 2 - 10 Test case 1 - Add student to the system when email is invalid

 Test case 2 - Add student to the system when phone number is invalid

- Description: This test case ensures that a student with a valid email format is successfully added to the
system.

Figure 2 - 11 Test case 2 - Add student with valid email

 Test Case 3: Add student with email containing special characters

- Description: This test case checks if a student with an email containing special characters ('.' in this
case) is added correctly to the system.
 Figure 2 - 12 Test case 3 Add student with email containing special characters

 Test Case 4: Add student with missing email domain

- Description: This test case tests the scenario where the email is missing the domain part after '@',
ensuring the student is not added.

Figure 2 - 13 Test case 4 Add student with missing email domain

 Test Case 5: Add student with email containing spaces

- Description: This test case verifies that a student with an email containing spaces is not added to the
system, as spaces in emails are invalid.
 Figure 2 - 14 Test case 5 Add student with containing spaces

 Test Case 6: Add student with email missing '@' symbol

- Description: This test case ensures that a student with an email missing the '@' symbol is not added to
the system.

Figure 2 - 15 Test case 6 Add student with email missing ‘@’ symbol

 Test Case 7: Add student with email having invalid top-level domain

- Description: This test case checks if a student with an email having an invalid top-level domain (e.g.,
'.comm' instead of '.com') is not added to the system.
 Figure 2 - 16 Test case 7 Add student with email having invalid top- level domain

 Test Case 8: Add student with email exceeding length limit

- Description: This test case verifies that a student with an email exceeding the typical length limit is not
added to the system.

Figure 2 - 17 Test Case 8 Add student with email exceeding length limit

 Test Case 9: Add student with email having multiple '@' symbols

- Description: This test case ensures that a student with an email containing multiple '@' symbols is not
added to the system.
 Figure 2 - 18 Test Case 9: Add student with email having multiple '@' symbols

 Test Case 10: Add student with email containing uppercase letters

- Description: This test case checks if a student with an email containing uppercase letters is successfully
added to the system.

Figure 2 - 19 Test Case 10 Add student with email containing uppercase letters

After that, I ran the test

 Figure 2 - 20 Test results

Test Case Expected output Actual output Evaluation

1 True True Pass

2 False False Pass

3 True True Pass

4 True True Pass

5 False False Pass

6 False False Pass

7 False False Pass

8 True True Pass

9 False False Pass

10 True True Pass

Table 2 - 2 Test report

=> So I have completed designing a suitable test mode for several functions of the student information
management application.
CHAPTER 3 BUILD A DATA PROCESSING APPLICATION BASED ON A DEVELOPED
DESIGN(LO3)

3.1 Build a large dataset processing application based on the

design produced. (P5)
3.1.1 Requirements analysis and design:
Scenario: The university administration has recognized the necessity of upgrading its student
information system management (SISM) to enhance efficiency and ensure long-term security. The goal of
the new system is to streamline processes, improve the user experience, and adhere to best practices in
software design and development. To accomplish this, we have been assigned the task of designing and
implementing a robust SISM that aligns with object-oriented principles, SOLID principles, clean code
practices, and incorporates various design patterns.

Our team has been chosen to implement the new SISM for the university. We understand the
importance of thoroughly analyzing user requirements and system design before proceeding to the
development phase.

Figure 1 - 1. Student information system management

a) Identify functional and non-functional requirements:

❖ Functional requirements:

▪ Student registration

- The system allows registration of information for new students

- Records and stores student information including personal information and academic records

▪ Course management

- Provides functions for administrators to manage courses

- Assigns students to courses based on their academic performance

▪ User authentication and authorization

- Ensures secure authentication for students, instructors, and administrators

- Implements role-based access control to restrict system functions

❖ Non-functional requirements:

▪ Scalability: The system must be scalable to accommodate increasing numbers of students and courses
over time.

▪ Performance: Ensures the system responds to user requests in a timely manner, even during peak
usage periods.

▪ Security: Implement strong security measures to protect sensitive student information and secure all
data.

▪ Ease of use: Design a user-friendly interface that is suitable for users with different technical skills.

▪ Reliable: The system must be reliable, with minimal downtime for maintenance or unexpected issues.

b) Use case diagram:

After evaluating the situation and identifying the functional and non-functional requirements of the
student system, we crafted a use case diagram. This diagram aims to thoroughly depict the interactions
between the system's components and its users, showcasing the various functions and features the
system offers to address the needs of all involved parties.
 Figure

c) Class diagram:

Based on an in-depth analysis of the system requirements and specifications, we move on to the design
phase by creating a class diagram for the student information management system. This important step
provides a detailed representation of the system’s architecture, introducing the various components,
their properties, and the relationships between them. The class diagram acts as a blueprint, clarifying the
complex interactions between the system’s components and its users.
 Figure

3.1.2 Building applications

Once we finished the requirements analysis and design phase, the next stage of the project involved
developing a web application for the student information management system. We chose to implement
the application using the MVC

a) Login:

b) Home page:

c) Student information management:

d) Course information management:

e) Student Points Management:

f) Register the class:

g) Account management:
 3.1.3. How the application helps in handling large data sets
- The student information management application provides significant advantages for handling large
datasets in schools:

 Efficient Database Integration: It utilizes a robust database capable of efficiently storing and
retrieving extensive amounts of student and other relevant information.

 Query Optimization: Queries are carefully optimized to minimize response times, ensuring quick
access to large datasets.

 Data Partitioning: Data is segmented into smaller parts to accelerate processing and retrieval.

 Effective Memory Management: The system is designed to optimize memory usage, maintaining
stable and smooth operation.

→ As a result, the SISM application is an invaluable tool for schools, facilitating the efficient handling of
large data sets. It serves not just as a management tool, but as a versatile system that enhances overall
management efficiency.
CHAPTER 4 PERFORM AUTOMATIC TESTING ON A DATA PROCESSING APPLICATION(LO4)

4.1 Examine the different methods of implementing automatic testing as designed in

the test plan.(P6)

4.1.1. Automated testing methods

Automated testing: is a software testing technique that uses automated tools and scripts to execute test
cases without human intervention. This method aims to increase the efficiency, effectiveness, and
coverage of the testing process by automating repetitive and time-consuming tasks. Automated testing
helps in identifying defects, ensuring software quality, and reducing the time required to release
software updates.

Figure

 There are 3 common types of testing

a) Unit Testing

- Unit testing is a fundamental practice that involves testing individual units of source code, such as
functions or methods. These tests are designed to be executed rapidly and should not depend on
external infrastructure. During the development phase, testers act as the initial users of the source code,
which helps in identifying design flaws and enhancing overall quality.

 Application of Unit Testing: Unit testing allows us to test specific functions of an application to
ensure they work correctly.

b) Integration Testing
- Integration testing involves testing the interactions between different components, such as a database
query component. This type of testing necessitates the existence of infrastructure to facilitate these
interactions, which can make the process slower.

 Application of Integration Testing: Integration testing allows us to combine and test components
that interact with each other to ensure they function together as intended.

c) End-to-End (E2E) Testing

- End-to-end testing focuses on the complete behavior of the application from the user’s perspective.
This involves testing the entire application workflow on actual infrastructure to simulate real-world
scenarios.

 Application of E2E Testing: E2E testing is used to create test scenarios that mimic real user behavior,
such as testing the entire process from logging in to performing final actions, like adding a student.

d) Advantages and disadvantages of automatic testing types

Figure

Testing type Advantages Disadvantages

Unit Testing  Fast Execution: Unit tests run quickly,  Limited Scope: Does not test how
providing immediate feedback. components interact with each
other.
 Isolation: Tests individual pieces of code,
making it easier to identify and fix issues.  Frequent Updates: Test cases may
need frequent updates due to
 Early Bug Detection: Helps catch bugs
changes in code.
early in the development process.
 No Integration Testing: Cannot catch
issues that arise from component
 integration.

Integration  Component Interaction: Ensures different  Slower Execution: Takes longer to

Testing components of the application work run compared to unit tests.
together as expected.
 Infrastructure Required: Needs a
 Interface Validation: Identifies issues in the setup of the environment to test
interfaces between components. interactions.

 Data Flow: Detects problems in data flow  Complexity: More complex to write
and exchange between modules. and maintain compared to unit
tests.

End-to-End  Comprehensive Testing: Tests the entire  Time-Consuming: Takes a long time
(E2E) application flow from the user’s to execute and develop.
Testing perspective.
 Setup Complexity: Requires a
 Real User Scenarios: Mimics real user comprehensive and realistic test
interactions to ensure the application environment.
works as expected.
 Maintenance: Test scripts can be
 High Confidence: Provides high confidence brittle and require regular
in the overall system integrity. maintenance.

Table

4.1.2. Make a test plan

5.1 Implement automatic testing of the developed application.(P7)

 CONCLUSION
- The Student Information Management System (SIMS) project provides a key opportunity for the
university to improve operational efficiency and maintainability through modernization. By applying
object-oriented principles, SOLID principles, clean coding practices, and combining different design
patterns, our team aims to provide a robust and adaptable solution , meeting global demand. The
foundation of SIMS will be rooted in a thorough analysis of user requirements, ensuring that every
feature and functionality is closely aligned with the needs of administrators, teachers, students and
parents. . This user-centric approach not only enhances usability but also ensures that the system
remains intuitive and energy efficient.
 REFERENCES
Tr&#7847;n, V. (2024) OOP là gì? Chi tiết về lập trình hướng đối tượng, 200Lab Blog. 200Lab Blog.
Available at: https://200lab.io/blog/oop-la-gi/ (Accessed: 17 June 2024).

Herrera, M. (2023) As Easy as APIE: This Simple Disaster-Response Model Is Highly Effective, MHA
Consulting. Available at: https://www.mha-it.com/2022/07/28/apie/#:~:text=APIE%20is%20a%20simple
%20but,response%2C%20and%20Evaluate%20your%20response. (Accessed: 24 June 2024).

Oloruntoba, S. (2024) SOLID: The First 5 Principles of Object Oriented Design, DigitalOcean. DigitalOcean.
Available at: https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-
principles-of-object-oriented-design (Accessed: 24 June 2024).

Use case diagram (2024) Wikipedia. Wikimedia Foundation. Available at:

https://en.wikipedia.org/wiki/Use_case_diagram (Accessed: 24 June 2024).