Higher Nationals - Summative Assignment Feedback Form

Student Name/ID Huynh Doan Tan Phat – GCD201482

Unit Title Unit 20: Advanced Programming

Assignment Number 1 Assessor Nguyen The Nghia

Date Received
Submission Date
1st submission
Date Received 2nd
Re-submission Date
submission
Grading grid

P1 P2 M1 M2 D1 D2

Assessor Feedback:
*Please note that constructive and useful feedback should allow students to understand:

a) Strengths of performance
b) Limitations of performance
c) Any improvements needed in future assessments
Feedback should be against the learning outcomes and assessment criteria to help students understand how these
inform the process of judging the overall grade.

Feedback should give full guidance to the students on how they have met the learning outcomes and
assessment criteria.

Grade: Assessor Signature: Date:

Resubmission Feedback:
*Please note resubmission feedback is focussed only on the resubmitted work

Grade: Assessor Signature: Date:

07.03-BM/ĐT/HDCV/FE 1/0 1/31

 Internal Verifier’s Comments:

Signature & Date:

* Please note that grade decisions are provisional. They are only confirmed once internal and external
moderation has taken place and grades decisions have been agreed at the assessment.

07.03-BM/ĐT/HDCV/FE 1/0 2/31

 STUDENT ASSESSMENT SUBMISSION AND DECLARATION
When submitting evidence for assessment, each student must sign a declaration confirming that the work is their
own.

Student name: Assessor name:

Huynh Doan Tan Phat Nguyen The Nghia

Issue date: Submission date: Submitted on:

17 June 2024 17 June 2024 CMS

Programmed:

BTEC

Unit: 1651 - Advanced Programming

Assignment number and title: 1

Plagiarism
Plagiarism is a particular form of cheating. Plagiarism must be avoided at all costs and students who break the
rules, however innocently, may be penalised. It is your responsibility to ensure that you understand correct
referencing practices. As a university level student, you are expected to use appropriate references throughout
and keep carefully detailed notes of all your sources of materials for material you have used in your work,
including any material downloaded from the Internet. Please consult the relevant unit lecturer or your course
tutor if you need any further advice.

Student Declaration
Student declaration

I certify that the assignment submission is entirely my own work and I fully understand the consequences of
plagiarism. I declare that the work submitted for assessment has been carried out without assistance other than
that which is acceptable according to the rules of the specification. I certify I have clearly referenced any
sources and any artificial intelligence (AI) tools used in the work. I understand that making a false declaration is
a form of malpractice.

07.03-BM/ĐT/HDCV/FE 1/0 3/31

Student signature: Date: 17 June 2024

07.03-BM/ĐT/HDCV/FE 1/0 4/31

Table of Contents
Plagiarism .................................................................................................................................................................. 3

Table of Figure .............................................................................................................................................................. 7

I. Introduction........................................................................................................................................................... 8

II. OOP general concepts...................................................................................................................................... 8

1. Introduce OOP. ................................................................................................................................................ 8

1. Advantages and Disadvantages ....................................................................................................................... 8

a) Advantages of OOP: .................................................................................................................................... 8

b) Disadvantages of OOP: ............................................................................................................................... 8

2. Properties of Programming with Objects......................................................................................................... 9

a) Class: ........................................................................................................................................................... 9

b) Object: ....................................................................................................................................................... 10

c) Attribute .................................................................................................................................................... 10

d) Methods ..................................................................................................................................................... 11

e) Encapsulation: ........................................................................................................................................... 11

f) Inheritance: ................................................................................................................................................ 13

g) Polymorphism: .......................................................................................................................................... 16

h) Abstraction: ............................................................................................................................................... 18

3. Class Diagrams .............................................................................................................................................. 19

3.1. Definition .............................................................................................................................................. 19

3.2. Relationships between classes............................................................................................................... 19

a) Association ................................................................................................................................................ 20

07.03-BM/ĐT/HDCV/FE 1/0 5/31

 b) Inheritance ................................................................................................................................................. 20

c) Realization / Implementation .................................................................................................................... 21

d) Dependencies............................................................................................................................................. 22

e) Aggregation ............................................................................................................................................... 22

f) Composition .............................................................................................................................................. 23

4. Use Case Diagram .......................................................................................................................................... 24

III. Design and build class diagrams using a UML tool. ..................................................................................... 26

1. Scenario ......................................................................................................................................................... 26

2. Use Case Diagram ......................................................................................................................................... 27

3. Class Diagram ................................................................................................................................................ 29

4. OOP concepts displayed in the class diagram: .............................................................................................. 30

IV. Conclusion ..................................................................................................................................................... 31

References .................................................................................................................................................................. 31

07.03-BM/ĐT/HDCV/FE 1/0 6/31

Table of Figure
Figure 1.Object............................................................................................................................................................ 10

Figure 2.Encapsulation................................................................................................................................................ 11

Figure 3.Encapsulation................................................................................................................................................ 12

Figure 4.Inheritance .................................................................................................................................................... 13

Figure 5.Inheritance .................................................................................................................................................... 14

Figure 6.Polymorphism ............................................................................................................................................... 16

Figure 7.Polymorphism ............................................................................................................................................... 17

Figure 8.Abstraction.................................................................................................................................................... 18

Figure 9.Relationship in OOP ...................................................................................................................................... 19

Figure 10.Association .................................................................................................................................................. 20

Figure 11.Inheritance .................................................................................................................................................. 21

Figure 12.Realization / Implementation ..................................................................................................................... 21

Figure 13.Dependencies ............................................................................................................................................. 22

Figure 14.Aggregation................................................................................................................................................. 23

Figure 15.Composition ................................................................................................................................................ 23

Figure 16 Include......................................................................................................................................................... 24

Figure 17.Extend ......................................................................................................................................................... 25

Figure 18.Use Case Diagram ....................................................................................................................................... 27

07.03-BM/ĐT/HDCV/FE 1/0 7/31

 I. Introduction.
• This article's goal is to give a broad introduction of design patterns and object-oriented
programming (OOP). It goes over fundamental OOP concepts and design patterns and provides an
example of how to use them in a vehicle rental program.

II. OOP general concepts.

1. Introduce OOP.
• Programming languages that employ objects are referred to as object-oriented programming, or
OOPs, as the name would imply. Real-world concepts like inheritance, hiding, polymorphism, etc.,
are intended to be implemented in programming through object-oriented programming. OOP's
primary goal is to bind together the data and the functions that work with it, preventing access to
the data by any other portion of the code except that function.

1. Advantages and Disadvantages

a) Advantages of OOP:
• Modularization: OOP allows dividing source code into separate objects, thereby reducing
complexity and making it easier to manage and reuse source code.

• Reusability: Classes and objects in OOP can be reused in many different projects, saving
programming time and effort.

• Encapsulation: OOP allows hiding information inside objects and class details, allowing access
only through public methods, helping to protect data and ensure consistency of the system.

• Flexibility: OOP allows source code to be easily changed and extended by adding or changing
classes and objects, without affecting other parts of the system.

b) Disadvantages of OOP:
• Complexity: OOP can become complex and confusing if not designed and implemented properly.

• Overhead: OOP can require more resources than other programming methods, such as memory
and execution time.

07.03-BM/ĐT/HDCV/FE 1/0 8/31

 2. Properties of Programming with Objects.

a) Class:
• A class is a data type that is defined by the user. By making an instance of that class, you can
access and use its member functions and data members. It symbolizes the collection of attributes or
operations shared by every item of a certain kind. An object's blueprint is analogous to a class.
• For instance, think about the car class. Even while different automobiles may have different names
and brands, they will all have certain characteristics in common, such as four wheels, a speed limit,
a mileage range, etc. In this case, the class is car, and the attributes are wheels, speed restrictions,
and mileage.
• example:
public class Car
{
public string Brand { get; set; }
public string Color { get; set; }

public void StartEngine()

{
Console.WriteLine("Engine started");
}

public void StopEngine()

{
Console.WriteLine("Engine stopped");
}
}

07.03-BM/ĐT/HDCV/FE 1/0 9/31

 b) Object:
• It is a foundational piece of Object-Oriented Programming that symbolizes actual entities. An
instance of a class is called an object. Memory is allocated when a class is instantiated, or when an
object is formed, but not when the class is defined. An object possesses a state, identity, and
behavior. Every object has code to manipulate the data as well as data. It is sufficient to understand
the kind of message accepted and the sort of answer returned by the objects in order for them to
communicate with one another, without needing to know specifics about each other's data or code.
• For example, "Dog" is a real-life object with features such as color, breed, barking, sleeping, and
eating.

Figure 1.Object

• example:
Car myCar = new Car();
myCar.Brand = "Toyota";
myCar.Color = "Red";
myCar.StartEngine();

c) Attribute
• A property is a declarative tag that you can use to inform your program runtime about the behavior
of various elements such as collections, enumerators, classes, methods, and structures. Using an
attribute, you can provide program declaration information. Square brackets ([]) above the element
they are intended to serve as a visual cue that the tag is declarative.

• Compiler instructions and such additional data, comments, descriptions, methods and classes can
be added to the program using attributes. Predefined properties and custom built properties are two
types of properties provided by Net Framework.

07.03-BM/ĐT/HDCV/FE 1/0 10/

31
 d) Methods
• A method is a block of code which only runs when it is called.

• You can pass data, known as parameters, into a method.

• Methods are used to perform certain actions, and they are also known as functions.

e) Encapsulation:
• Data encapsulation is the process of grouping related information into a single unit. It is the
connection point between the code and the data it works with. When a class is encapsulated, its
variables and data are not visible to other classes and are only accessible via the member functions
of the class in which they are specified. It's also called data-hiding because, similar to
encapsulation, the data in a class is concealed from other classes.

Figure 2.Encapsulation

07.03-BM/ĐT/HDCV/FE 1/0 11/

31
 Figure 3.Encapsulation

• The 'name' and 'age' are declared private, meaning they can only be accessed from within the
'Person' class. This prevents other parts of the program from directly accessing and changing their
values.

• 'SetName' and 'SetAge' are used to assign values to 'name' and 'age'. Make sure not to assign a
Negative value to 'age'.

• 'GetName' and 'GetAge' return the current values of 'name' and 'age'.

07.03-BM/ĐT/HDCV/FE 1/0 12/

31
 f) Inheritance:
• Inheritance is an essential component of OOP (Object-Oriented Programming). Inheritance is the
capacity of a class to inherit traits and properties from another class. We inherit properties from
other classes when we write a class. Because they can be inherited from another class that already
has them, we do not need to write all of the properties and functions when we build a class. The
user can minimize redundancy in the code by using inheritance to reuse it whenever possible.

Figure 4.Inheritance

07.03-BM/ĐT/HDCV/FE 1/0 13/

31
 Figure 5.Inheritance

07.03-BM/ĐT/HDCV/FE 1/0 14/

31
 • Class 'Animal' is a base class with a 'name' field, an 'Eat' method, and a virtual method
'MakeSound'.

• Class 'Dog' is a derived class that inherits from the 'Anima'l class using the ':Animal' syntax. 'Dog'
has a constructor that takes a name and passes it to the base class using the 'base' keyword. The
'MakeSound' method is overridden to provide specific behavior to the 'Dog' class. 'Dog' has a
private method 'WagTail' that is only available in the 'Dog' class.

• Create a 'Animal' object, then use the 'Eat' and 'MakeSound' methods. Make an instance of the
'Dog' object and invoke the override 'MakeSound' method, the private 'Dog.WagTail' method, and
the methods inherited from 'Animal.Eat'. This illustrates polymorphism by using the 'Dog' object
as the type of 'Animal,' using the 'MakeSound' method of 'Dog' rather than the 'Animal' method.

07.03-BM/ĐT/HDCV/FE 1/0 15/

31
 g) Polymorphism:
• Polymorphism refers to the existence of several forms. To put it simply, polymorphism is the
capacity of a message to be presented in multiple formats. For instance, a person may possess
multiple traits simultaneously. Like a man who is also a husband, a father, and a worker. Thus, a
person exhibits distinct behavior depending on the circumstance. We refer to this as
polymorphism.

Figure 6.Polymorphism

07.03-BM/ĐT/HDCV/FE 1/0 16/

31
 Figure 7.Polymorphism

• The base class 'Animal' has a virtual MakeSound function that derived classes can override, as well
as a 'name' field."Dog" and "Cat" are derived from the Animal class and implement their own
actions by overriding the MakeSound function.
• Generate objects of type "Animal," such as "Dog" and "Cat."
• Make an array called "Animal" that includes the "Dog" and "Cat" objects.
• As you traverse the array, invoke the 'MakeSound' function. The 'Animal' method is called instead
of the proper 'MakeSound' method of each object (bark for 'Dog' and meow for 'Cat') because of
polymorphism.

07.03-BM/ĐT/HDCV/FE 1/0 17/

31
 h) Abstraction:
• Abstraction is the technique of expressing important aspects of complicated systems while
concealing unneeded information. Its main goal is to define an object's properties and behavior
without disclosing how it is internally implemented.

Figure 8.Abstraction

• The abstract class 'Vehicle' contains an abstract method 'Drive'. In order to override the 'Drive'
method, subclasses must implement the abstract class, which cannot be created directly.
The 'Car' and 'Motorcycle' classes extend the 'Drive' function and are derived from the 'Vehicle'
class.
• Two objects, "Car" and "Motorcycle," are created as types of "Vehicle" in the "Main" method.
Each object has a 'Drive' method that when called, uses polymorphism to run the proper method
(motorcycle or automobile) for that kind of object.

07.03-BM/ĐT/HDCV/FE 1/0 18/

31
3. Class Diagrams

3.1. Definition
• A class diagram is a kind of UML (Unified Modeling Language) diagram that is used to show the
relationships and structure of classes in a system graphically in software engineering. Software system
design and documentation are aided by the standard modeling language known as UML. They provide
help for both the design and documentation phases of the software development process, making them
an essential component.

3.2. Relationships between classes

• Layers are related to each other in specific ways. In particular, relationships in class diagrams
include many different types of logical connections. The following are the types of logical
connections that can be made in

Figure 9.Relationship in OOP

07.03-BM/ĐT/HDCV/FE 1/0 19/

31
 a) Association
• A property of one class may include a reference to an instance, or instances, of another class,
according to the definition of association.
• The most widely used relationship between a class and another class is association, which denotes
a relationship between an object type and another object type. Associative linkages also include
combinations and aggregations, although the relationships between the two groups of affiliations
are not as strong.
• There are four different types of associations: multiple-number affiliations, self-association, one-
way associations, and two-way associations.
• For example: cars and drivers, one car corresponds to a particular driver, and one driver can drive
multiple cars.

Figure 10.Association

• One-way relationships, often known as self-associations, have an arrow in UML diagrams, while
bidirectional associations might have two arrows or none at all. \
• To show how many items are in the respective class in a multiplicity connection, you may add a
number straight to the corresponding line.
o 1..1: Only one
o 0..*: Zero or more
o 1..*:one or more
o 0..1: No or only one
o m..n: at least m, at most n (m<=n)

b) Inheritance

• Inheritance, also known as generalization, refers to the relationship between a parent class and a
child class. The terms "base class" and "derived class" refer to the parent class and child class,
respectively.
• In an inheritance relationship, the parent class has all the properties, methods, and subclasses, and
the subclass inherits all the functions of the parent class. In addition to the same information as the
parent class, subclasses also contain additional information.
• For example: buses, taxis, and cars are cars, they all have names, and they can all be on the road.

07.03-BM/ĐT/HDCV/FE 1/0 20/

31
 Figure 11.Inheritance

c) Realization / Implementation
• Implementation (Implementation) is mostly used to define the link between interfaces and
implementation classes.
• An interface is a group of methods, which also includes an abstract class. A class implements an
interface and its methods implement every method in the interface declaration in an
implementation relationship.
• For example, automobiles and ships are vehicles, and the vehicle is only an abstract idea of a
mobile tool, whereas the ship and vehicle perform particular mobile duties.

Figure 12.Realization / Implementation

07.03-BM/ĐT/HDCV/FE 1/0 21/

31
 d) Dependencies
• Dependency: Suppose that class B depends on class A and a change in class A results in a change
in class B.

• Dependencies are often represented in class methods that take an object from another class as
input.

• The "using" connection is a dependency relationship. When something is changed, it can have an
impact on other things that depend on it. Dependencies are used to show when one item depends
on another item. For example: Vehicles run on fuel. The car will not start if it runs out of gas.

Figure 13.Dependencies

e) Aggregation
• Aggregation: The connection between a whole and a component that allows them to be separated.

• Member objects are a component of the overall object, but they can also exist separately from that
object. Aggregate relationships also represent the relationship between the whole and part of the
class.

• For example, although they are generally related, bus drivers, work clothes, and hats are not. On
other drivers, protective clothing and helmets are fine. Bus drivers are also allowed to wear other
business attire, including baseball caps.

07.03-BM/ĐT/HDCV/FE 1/0 22/

31
 Figure 14.Aggregation

f) Composition
• Composition is the relationship between the whole and the inseparable parts.

• An associative connection describes a relationship between the entire class and a subset of it, both
of which have a constant lifetime. Some things will cease to exist once the total entity disappears,
and they will all disappear in the same lifetime. For example, humans consist of a head and a body.
Both exist together and are inseparable.

Figure 15.Composition

07.03-BM/ĐT/HDCV/FE 1/0 23/

31
 4. Use Case Diagram
• A usecase is a method for describing how users and systems interact in a particular setting and
for a particular goal. It is the outcome that users hope to achieve from the system or the manner
in which systems communicate with one another, and the interaction has to take place in a
particular setting. The objective of this interaction description is to convey a given idea, and
the use case needs to convey the requirements from a certain user perspective.
• Relationships in usecase diagrams:
o Include:
▪ In use cases, Include is defined as a required relationship between Use Cases. In
terms of meaning, Include in English means to include, that is, if we say Use Case A
has a relationship with Use Case B, then Use Case A includes Use Case B. For Use
Case A to occur then it must happen. Use of CaseB was achieved.
▪ These connections are indicated by dashed arrows, the arrowhead pointing towards
the parent function (use case B). At the same time, users who want to perform the
course registration function must log in.
o Example:

Figure 16 Include

07.03-BM/ĐT/HDCV/FE 1/0 24/

31
 o Extend:
▪ Extend refers to the expanded link between Use Cases. Extend is an optional
relationship between Use Cases that may or may not exist, whereas Include is a
required relationship. If Use Case B is an extension of Use Case A, then Use
Case B is merely optional and only happens under particular circumstances.
▪ A dashed arrow with its head pointing in the direction of the parent function
(use case A) is used to symbolize extend. We can utilize the lost password
feature in addition to the login function.
o Example

Figure 17.Extend

07.03-BM/ĐT/HDCV/FE 1/0 25/

31
III. Design and build class diagrams using a UML tool.
1. Scenario
• The IT company I work for assigned me a project to improve its now-outdated self-driving car
rental system. To help employees handle cars more efficiently and replace human management,
they want to improve the self-driving car rental system.

• I was tasked with creating UML diagrams and system design for a self-driving car rental
management system.

• The system needs to manage different types of cars, rental transactions, and customer information.
Here is a high-level description of the scenario:

o The car rental system offers various types of cars, including sports cars, electric cars, and
regular cars.

o Customers can register with the system by providing their personal information, such as
name, address, and contact details.

o Customers can rent cars from the rental system by specifying the type of car and the rental
period.

o Each rental transaction includes the customer, the rented car, the rental start date, and the
return date.

o The system should track the availability of cars and calculate rental fees based on the type
of car and rental duration.

07.03-BM/ĐT/HDCV/FE 1/0 26/

31
 2. Use Case Diagram

Figure 18.Use Case Diagram

07.03-BM/ĐT/HDCV/FE 1/0 27/

31
 • This is a use case diagram that shows the interactions between customers, employees, and the
system. Here is a breakdown of the use cases:

o Vehicle search: Customers can search for vehicles in the vehicle list system.

o Car loan: Customers can borrow to buy a car according to the list. This use case involves
"Checking vehicle eligibility", meaning the dealership will verify if the vehicle is available
to borrow.

o Return the car: Customers can return the car to the store. This use case also involves
"Check vehicle eligibility" as the employee will need confirmation for the vehicle return to
be successful.

o Edit vehicle: Staff can edit vehicle details.

o Add new vehicle: Employees can add new vehicles to the system.

o Delete vehicle: Employees can delete vehicles from the system.

• This diagram effectively captures the core functions of a self-driving car rental system as well as
the roles of both customers and employees within that system.

07.03-BM/ĐT/HDCV/FE 1/0 28/

31
 3. Class Diagram

Figure 19.ClassDiagram

07.03-BM/ĐT/HDCV/FE 1/0 29/

31
 • Diagram showing a few connections in OOP:
• Association: This type of relationship shows how two classes are connected, with things from one
class being linked with objects from the other. This figure illustrates the relationship in:
o Clients and automobiles: A vehicle that is rented by one or more customers is associated
with the list of borrowed cars under the Customer class.
o Employee and Vehicle: The AddCar, RemoveCar, and EditCar methods in the Employee
class show that the employee is in charge of managing the cars.
o Customer and employee: the Car Borrowing Management method in the Employee class is
used by the kernel to control the car-borrowing transaction between the customer and the
vehicle.
• Aggregation: This particular type of connection suggests a "has-a" link. Instances of one class
belong to it or are included inside it. The synthesis is shown in the schematic in:
o Store and Vehicles: There is a list of vehicles in the Store class (cars: List).
o Store and Customers: A list of customers is contained in the Store class (customer: List).
o Employees and Stores: A list of employees is contained in the Store class. A list of
Employees is available in the Store class (customer: List).

4. OOP concepts displayed in the class diagram:

• Inheritance: The classes "SportsCar" and "ElectricCar" are derived from the "Car" class, which
represents an "is-a" relationship between specific car types and a car in general.

• Association: A rental transaction involving a specific car is represented by an association between

the "Lease Transaction" class and the "Car" class.

• Encapsulation: Each class creates a distinct boundary for accessing and manipulating data by
encapsulating its own data and methods.

• Abstraction: Class diagrams hide internal implementation details while illustrating the main
components of the system.

07.03-BM/ĐT/HDCV/FE 1/0 30/

31
IV. Conclusion
• I feel that I have enough knowledge to design my own application that satisfies all the
requirements of the provided scenario, based on the knowledge I have shown above from my
research and study process.
• A brief introduction to OOP ideas and how it may help us write programs that are easier to
comprehend and quicker to code into apps will be covered at the outset of the report.
Encapsulation, abstraction, polymorphism, and inheritance are the traits of object-oriented
programming (OOP) that will be discussed next. The class diagram has now been explained, with
association, aggregation, and composition being some of the key links.

References
Anon., 2023. geeksforgeeks. [Online]
Available at: https://www.geeksforgeeks.org/introduction-of-object-oriented-programming/
[Accessed 16 6 2024].

Anon., 2023. learn.microsoft. [Online]

Available at: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/oop
[Accessed 16 6 2024].

07.03-BM/ĐT/HDCV/FE 1/0 31/

31