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 25 Date Received 1st submission

Re-submission Date Date Received 2nd submission

Student Name P Student ID B

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.

Student’s signature NHAT

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 OF CONTENT

TABLE OF CONTENT........................................................................................................................................3

LIST OF TABLES AND FIGURES.........................................................................................................................3

LIST OF THE ACRONYM............................................................................................................................7

INTRODUCTION...........................................................................................................................................8

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

PARADIGM(LO1).........................................................................................................................................9

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

1.1.1Object-oriented model:...........................................................................................................................9

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

1.1.3 Class Relationships..............................................................................................................................13

1.1.4 SOLID Principle..................................................................................................................................15

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

1.2.1 Clean Coding Techniques....................................................................................................................20

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

CHAPTER 2. DESIGN A LARGE DATASET PROCESSING APPLICATION USING SOLID

PRINCIPLES AND CLEAN CODING TECHNIQUES..............................................................................24

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

2.1.1 Design and use SOLID principles........................................................................................................24

2.1.2 Use case diagram.................................................................................................................................25

2.1.3 A package diagram...............................................................................................................................28

3
2.1.4 A class diagram....................................................................................................................................30

2.1.5 An explanation of how SOLID............................................................................................................31

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

2.2.1 Automated testing................................................................................................................................35

2.2.2 Types of automatic testing:..................................................................................................36

2.2.3 Experimental design.............................................................................................................................40

CONCLUSION.............................................................................................................................................46

REFERENCES..............................................................................................................................................47

4
 LIST OF TABLES AND FIGURES
Figure 1 - 1. OOP..........................................................................................................................................................9

Figure 1 - 2 Encapsulation..........................................................................................................................................10

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

Figure 1 - 4 Abstraction- Interface.............................................................................................................................11

Figure 1 - 5 Inheritance..............................................................................................................................................11

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

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

Figure 1 - 8. UML........................................................................................................................................................13

Figure 1 - 9 Inheritance..............................................................................................................................................13

Figure 1 - 10 Composition..........................................................................................................................................14

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

Figure 1 -13 Dependencies.........................................................................................................................................15

Figure 1 -14 Association.............................................................................................................................................15

Figure 1 - 15. SOLID....................................................................................................................................................16

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

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

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

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

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

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

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

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

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

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

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

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

Figure 2 - 2 A package diagram..................................................................................................................................29

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

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

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

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

Figure 2 - 7 OCP.........................................................................................................................................................34

Figure 2 - 8 LSP...........................................................................................................................................................34

Figure 2 - 10 DIP.........................................................................................................................................................36

Figure 2 - 11 Automated testing................................................................................................................................36

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

Figure 2 - 5 xUnit........................................................................................................................................................38

Figure 2 - 6 Fact..........................................................................................................................................................39

Figure 2 - 8 ClassData.................................................................................................................................................40

Figure 2 - 9 MemberData...........................................................................................................................................40

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

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

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

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

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

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

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

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

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

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

Figure 2 - 20 Test results............................................................................................................................................46

Table 2 - 2 Test report................................................................................................................................................46

7
 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

8
 INTRODUCTION
The university sought to modernize its student information system to improve efficiency and
maintainability. To achieve this goal, students will collaborate in teams to design and implement a robust
Student Information Management System (SIMS) that adheres to object-oriented principles, SOLID
principles, coding practices Clear and combines many designs.

My team has been selected to deploy this system. As a first step, your team will conduct a basic
analysis of user requirements and system design. This foundational work will ensure the development of
SIMS meets the needs of the university and sets the standard for future improvements.

9
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.

10
 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:

11
 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

12
 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

13
 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

14
 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

15
 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]

16
 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.

17
- 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

18
 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.

19
 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.

20
→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.

21
 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:

Table 1 - 1 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.

22
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:

23
 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.

24
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.

25
- 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.

26
 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

27
- 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

28
- 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.

29
 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.

30
- 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:

31
 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

32
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.

33
 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

34
 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.

35
 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

36
 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

37
 - 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

38
 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

39
- 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

40
 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

41
- 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.

42
 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.

43
 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.

44
 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

45
 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.

46
 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.

47
 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).

48