Adv Programming

Higher Nationals
Internal verification of assessment decisions – BTEC (RQF)

INTERNAL VERIFICATION – ASSESSMENT DECISIONS
Programme title HND in Computing - Application Dev / Software Eng. Pathway
Assessor K. Ushamini Internal Verifier
Unit(s) Unit 20 – Advance Programming
Assignment title
Student’s name Sivarasa Pakeen

List which assessment criteria Pass Merit Distinction
the Assessor has awarded.
INTERNAL VERIFIER CHECKLIST
Do the assessment criteria awarded match

those shown in the assignment brief? Y/N
Is the Pass/Merit/Distinction grade awarded

justified by the assessor’s comments on the Y/N
student work?
Has the work been assessed Y/N
accurately?
Is the feedback to the student:
Give details:
• Constructive? Y/N
• Linked to relevant assessment criteria? Y/N
• Identifying opportunities for Y/N
improved performance?
Y/N
• Agreeing actions?
Does the assessment decision need
Y/N
amending?
Assessor signature Date
Internal Verifier signature Date

Programme Leader signature (if required)
Date
Confirm action
completed
Remedial action taken
Give details:
Assessor signature Date
Internal Verifier
Date
signature
Programme Leader
Date
signature (if
required)
Higher Nationals - Summative Assignment Feedback Form
Student Name/ID Sivarasa Pakeen / PA 90546

Unit Title Advance Programming
Assignment Number Assessor
14.02.2022 Date Received 1st
Submission Date
submission
Date Received 2nd
Re-submission Date
submission
Assessor Feedback:
LO1. Examine the key components related to the object orientated programming paradigm,
analysing design pattern types.

Pass, Merit & Distinction Descripts P1 M1 D1
LO2. Design a series of UML class diagrams
LO3. Implement code applying design patterns
LO4. Investigate scenarios with respect to design patterns

Grade: Assessor Signature: Date:

Resubmission Feedback:
Grade: Assessor Signature: Date:

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 board.
Assignment Feedback
Formative Feedback: Assessor to Student
Action Plan
Summative feedback
Feedback: Student to Assessor
Assessor Date
signature
[email protected] 14.02.2022
Student Date
signature
Pearson Higher Nationals in
Computing
Unit 20 – Advance Programming
General Guidelines
1. A Cover page or title page – You should always attach a title page to your
assignment. Use previous page as your cover sheet and make sure all the details are
accurately filled.
2. Attach this brief as the first section of your assignment.
3. All the assignments should be prepared using a word processing software.
4. All the assignments should be printed on A4 sized papers. Use single side printing.
5. Allow 1” for top, bottom , right margins and 1.25” for the left margin of each page.
Word Processing Rules
1. The font size should be 12 point, and should be in the style of Time New Roman.
2. Use 1.5 line spacing. Left justify all paragraphs.
3. Ensure that all the headings are consistent in terms of the font size and font style.
4. Use footer function in the word processor to insert Your Name, Subject, Assignment
No, and Page Number on each page. This is useful if individual sheets become
detached for any reason.
5. Use word processing application spell check and grammar check function to help
editing your assignment.
Important Points:
1. It is strictly prohibited to use textboxes to add texts in the assignments, except for the
compulsory information. eg: Figures, tables of comparison etc. Adding text boxes in
the body except for the before mentioned compulsory information will result in
rejection of your work.
2. Carefully check the hand in date and the instructions given in the assignment. Late
submissions will not be accepted.
3. Ensure that you give yourself enough time to complete the assignment by the due date.
4. Excuses of any nature will not be accepted for failure to hand in the work on time.
5. You must take responsibility for managing your own time effectively.
6. If you are unable to hand in your assignment on time and have valid reasons such as
illness, you may apply (in writing) for an extension.
7. Failure to achieve at least PASS criteria will result in a REFERRAL grade.
8. Non-submission of work without valid reasons will lead to an automatic RE FERRAL.
You will then be asked to complete an alternative assignment.
9. If you use other people’s work or ideas in your assignment, reference them properly
using HARVARD referencing system to avoid plagiarism. You have to provide both in-
text citation and a reference list.
10. If you are proven to be guilty of plagiarism or any academic misconduct, your grade
could be reduced to A REFERRAL or at worst you could be expelled from the course
Student Declaration
I hereby, declare that I know what plagiarism entails, namely to use another’s work and to
present it as my own without attributing the sources in the correct form. I further understand
what it means to copy another’s work.
1. I know that plagiarism is a punishable offence because it constitutes theft.

2. I understand the plagiarism and copying policy of Edexcel UK.
3. I know what the consequences will be if I plagiarise or copy another’s work in any of the
assignments for this program.
4. I declare therefore that all work presented by me for every aspect of my program, will
be my own, and where I have made use of another’s work, I will attribute the source
in the correct way.
5. I acknowledge that the attachment of this document signed or not, constitutes a
binding agreement between myself and Pearson, UK.
6. I understand that my assignment will not be considered as submitted if this document
is not attached to the assignment.
Student’s Signature: Date:

[email protected] 14.02.2022
Higher National Diploma in Business
Assignment Brief
Student Name /ID Number Sivarasa Pakeen / PA90546
Unit Number and Title Unit 20 – Advance Programming
Academic Year 2018/19

2021/22
Unit Tutor K. Ushamini
Assignment Title
Issue Date
Submission Date 14.02.2022
IV Name & Date
Submission format
The submission is in the form of an individual written report about. This should be written in a concise,
formal business style using single spacing and font size 12. You are required to make use of headings,
paragraphs and subsections as appropriate, and all work must be supported with research and
referenced using the Harvard referencing system. Please also provide an end list of references using
the Harvard referencing system. Please note that this is an activity-based assessment where your
document submission should include evidences of activities carried out and of team working. To carry
out activities given on the brief, you are required to form groups, comprising not exceeding 15
individuals.
The recommended word count is 4,000–4,500 words for the report excluding annexures. Note that
word counts are indicative only and you would not be penalised for exceeding the word count.
Unit Learning Outcomes:
Learning Outcomes
By the end of this unit students will be able to:
LO1. Examine the key components related to the object-orientated programming
paradigm, analysing design pattern types.
LO2. Design a series of UML class diagrams.
LO3. Implement code applying design patterns.
LO4 Investigate scenarios with respect to design patterns.
Assignment Brief and Guidance:
BOC Software solutions is leading software company in Kandy as system analyst you have to build
an application for Family Dental Care (FDC) considering given scenario.
Family Dental Care (FDC) is a leading up market dental surgery located in Kandy. It provides
all types of dental treatments to patients which include extractions, nerve fillings, maxillofacial
surgeries (i.e. surgeries involving jaw bone) and sophisticated dental implants. It is visited by
prominent dentists and dental consultants with post graduate qualifications, some of whom are
working at the Faculty of Dental Science at the University of Peradeniya.
Patients consult doctors by appointment. On their first visit, patients are required to register by
entering their personal details such as name, address, national identity card number and contact
number. A small fee is charged from the patient during registration. A separate fee is charged for
each treatment given.
Doctors too must get registered at FDC by providing personal details such as name, address, date
of birth, national ID number and contact number. In addition, consultants must provide the name
of their post graduate qualification along with the country of the University that granted it and
ordinary dentists should indicate the number of years of experience.
FDC consists of four fully equipped surgery rooms so that four patients can be accommodated at
any given time. FDC also contains a dental scan room which can be attended by one patient at a
time. The dental scan machine is operated by one of the dentists of the FDC facility. Normally, a
dentist without appointments for a given time slot (say, between 5 PM and 6 PM) is assigned to
the machine by the manager. When that time slot finishes, another doctor who is free will be
assigned.
The staff of FDC is made up of a manager, four nurses (one for each of the four surgery rooms)
and a receptionist who handles registrations and appointments.
An information system is required to keep track of patients, doctors, appointments, treatments
given to patients and payments. The system must also maintain information about the staff. It
has been decided to use an object oriented approach to design and implement the system.
Task 1
Examine the Object oriented concepts given below. Provide diagrams and code snippets from
suitable specific programming language to supplement your explanations.
i) Class
ii) Object
iii) Message
iv) Encapsulation
v) Inheritance
vi) Polymorphism
vii) Aggregation/composition
Task 2
Design and build the detailed UML class diagram for the Family Dental Care system. Your
solution should demonstrate all inter-class relationships namely Association, Inheritance and
Aggregation/composition. The classes should include attributes and methods needed.
Draw the class diagram for the explained system. Including all notations and details and ensure that
the diagram has the required functionalities. Analyze the class diagram provided above and derive
code scenarios related to the UML diagram.
Task 3
Determine and briefly discuss the range of design patterns and describe at least one
design pattern from the three available types of design pattern. Provide suitable UML
diagrams for the given patterns and analyze the relationship between object-oriented
paradigm and design patterns providing a suitable example.
Task 4
Scenario 1
FDC owns a very expensive, state of the art dental scan machine (a device far superior to a
traditional dental X-ray machine) manufactured by Toshiba, Japan. FDC will be own just one such
machine in the foreseeable future. When modeling and implementing FDC system in software,
you must ensure that only one instance of that machine is created.
You may include suitable attributes for the machine such as serial number, make, country of
origin and cost. Implementation should allow the user to enter details of the dental scanner and
create the sole instance of that machine.
Scenario 02
Below table provides the hierarchy of the Employees and their monthly salary in FDC.
Emp Id Name Position Salary

A001 Anton Director 1,000,000 LKR
A002 Chamod Dentist 600,000 LKR
A003 Supuni Dentist 600,000 LKR
A004 Madhavi Dentist 600,000 LKR
A005 Piyal Nurse 200,000 LKR
A006 Kamal Nurse 200,000 LKR
A007 Kapila Nurse 200,000 LKR
All the Nurses are working under the Dentists and Chamod(Dentist) is working under the
Supuni(Dentist) and Madhavi(Dentist) is working under the Anton(Director).
Develop a system to display the details of all employees and your system should display which
employee is working under which employee clearly.
Scenario 03
Patients who need dental scans are kept in a First in First Out queue. Assume that you have found
an already developed Queue container in a software library. It provides standard queue operations
to insert and remove data (known as enqueue and deque respectively). However, you need some
specific operations such as search() to look up a particular patient and showAll() to list all the
patients in the queue. These additional operations are not provided by the library unit.
For each of the above scenarios:

Select and Justify the most appropriate design pattern for each of the above given scenarios then
Define and Draw class diagrams for above mentioned design patterns and develop code for the above
scenarios (except for the 3rd Scenario) using an appropriate programming language. Critically evaluate
why you selected the above design patterns and compare your answer with the range of design
patterns available.
Grading Rubric
Grading Criteria Achieve d Feedback
LO1 Examine the key components

related to the
object-orientated programming
paradigm,
analyzing design pattern types
P1 Examine the characteristics of the
object-orientated paradigm as well as the
various class relationships.
M1 Determine a design pattern from
each of the creational, structural and
behavioral pattern
types.
D1 Analyse the relationship between the

object-orientated paradigm and design
patterns.
LO2 Design a series of UML class diagrams
P2 Design and build class diagrams using

a UML tool.
M2 Define class diagrams for specific
design patterns using a UML tool.
D2 Analyse how class diagrams can be
derived from a given code scenario using a
UML tool.
LO3 Implement code applying design

patterns
P3 Build an application derived from UML
class diagrams.
M3 Develop code that implements a

design pattern for a given purpose.
D3 Evaluate the use of design patterns
for the given purpose specified in M3.
LO4 Investigate scenarios with respect to
design Patterns
P4 Discuss a range of design patterns
with relevant examples of creational,
structure and behavioral pattern types.
M4 Reconcile the most appropriate

design
pattern from a range with a series of
given scenarios.
D4 Critically evaluate a range of design
patterns against the range of given
scenarios with justification of your
choices.
HND in Computing and Systems
Development
Table of Contents
Introduction to Object-oriented programming (OOP) ......................................................... 9
Advantages of Object oriented Programming .................................................................. 9
Disadvantages of Object oriented Programming ........................................................... 10
Class ........................................................................................................................... 10
Objects ....................................................................................................................... 11
Method ....................................................................................................................... 12
Final Method .............................................................................................................. 14
Abstraction ................................................................................................................. 17
Encapsulation ............................................................................................................. 19
Inheritance .................................................................................................................. 21
Polymorphism ............................................................................................................ 26
Association ................................................................................................................. 30
Aggregation ................................................................................................................ 30
Composition ............................................................................................................... 31
Introduction to UML Diagram ........................................................................................... 33
Types of UML Diagram ................................................................................................. 33
Class Diagram ............................................................................................................ 34
UML class notation .................................................................................................... 34
Perspective of Class Diagram .................................................................................... 36
Relationships between classes ................................................................................... 37
Inheritance (or generalization) ................................................................................... 37
Association ................................................................................................................. 39
Cardinality .................................................................................................................. 39
Aggregation ................................................................................................................ 40
Composition ............................................................................................................... 40
Dependency ................................................................................................................ 40
S. Pakeen Advance Programming Pearson No: PA 90546 Page 1 of 93

Development
Realization ................................................................................................................. 41
Example of Class Diagram ........................................................................................ 42
Class Diagram of Family Dental Care ....................................................................... 42
Inheritance of Class Relationships ............................................................................. 43
Interfaces designing for the Family dental Care ........................................................ 44
Object Oriented Concept for Family Dental Care System ............................................. 51
Encapsulation Code.................................................................................................... 51
Polymorphism Code ................................................................................................... 52
Inheritance Code ........................................................................................................ 52
Abstract Code ............................................................................................................. 53
Design Pattern ............................................................................................................ 54
Creational Design Pattern .............................................................................................. 54
Types of Creational Patterns ...................................................................................... 54
Singleton Pattern ........................................................................................................ 55
Factory Pattern ........................................................................................................... 56
Abstract Factory Pattern............................................................................................. 58
Builder Pattern ........................................................................................................... 58
Prototype Pattern ........................................................................................................ 58
Structural Design Patterns .............................................................................................. 58
Adapter Pattern .......................................................................................................... 59
Bridge Pattern ............................................................................................................ 59
Filter Pattern ............................................................................................................... 59
Composite Pattern ...................................................................................................... 59
Decorator pattern ........................................................................................................ 61
Facade pattern ............................................................................................................ 61
Flyweight pattern ....................................................................................................... 61
Proxy pattern .............................................................................................................. 62

Development
Behavioral Patterns ........................................................................................................ 62
Chain of responsibility ............................................................................................... 63
Command Pattern ....................................................................................................... 63
Interpreter ................................................................................................................... 63
Iterator Pattern............................................................................................................ 64
Mediator Pattern ......................................................................................................... 65
Memento Pattern ........................................................................................................ 65
Observer Pattern ......................................................................................................... 65
State Pattern ............................................................................................................... 66
Strategy Pattern .......................................................................................................... 66
Template Pattern ........................................................................................................ 66
Relationship Between object- oriented paradigm and design patterns .......................... 66
Scenario 1 ....................................................................................................................... 68
Singleton Design for the Scenario ............................................................................. 68
Class Diagram for the Scenario 1 .............................................................................. 68
Scenario 2 ....................................................................................................................... 71
Composite Design Pattern for the Scenario 1 ............................................................ 71
Class Diagram for the scenario 2 ............................................................................... 72
Scenario 3 ....................................................................................................................... 75
Iterator Design Pattern for the Scenario 3 .................................................................. 75
Class Diagram for the Scenario 3 .............................................................................. 76
References .......................................................................................................................... 77

Development
Table of Figures
Figure 1 OOP Concept ......................................................................................................... 9
Figure 2 create a class using the class keyword ................................................................. 10
Figure 3 Code for creating class ........................................................................................ 11
Figure 4 Code for Objects .................................................................................................. 12
Figure 5 Objects output ...................................................................................................... 12
Figure 6 syntax of declare a method .................................................................................. 12
Figure 7 code for Static method ......................................................................................... 13
Figure 8 Output of Static method code ............................................................................. 13
Figure 9 Code for final method .......................................................................................... 14
Figure 10 Output of final method code ............................................................................. 15
Figure 11 Code for Abstract method.................................................................................. 15
Figure 12 Output of Abstract method ................................................................................ 15
Figure 13 Method Call diagram ......................................................................................... 16
Figure 14 Code for method call ......................................................................................... 16
Figure 15 Output of method call code ............................................................................... 16
Figure 16 Code for Abstraction ......................................................................................... 18
Figure 17 Output of Abstraction code ................................................................................ 18
Figure 18 Code for Abstract interface ................................................................................ 19
Figure 19 Output of Abstract interface code ..................................................................... 19
Figure 20 Example for Encapsulation ................................................................................ 20
Figure 21 Code for Encapsulation ..................................................................................... 21
Figure 22 Output of encapsulation code ............................................................................ 21
Figure 23 derived class inheritance .................................................................................... 22
Figure 24 Inheritance syntax in Java.................................................................................. 22
Figure 25 Code for inheritance .......................................................................................... 22
Figure 26 Output of inheritance code ................................................................................ 23
Figure 27 Single Level Inheritance .................................................................................... 23
Figure 28 Code for Single level ......................................................................................... 24
Figure 29 Output of Single level ........................................................................................ 24
Figure 30 Multiple Inheritance .......................................................................................... 24
Figure 31 Multilevel Inheritance ........................................................................................ 25
Figure 32 Hierarchical inheritance ..................................................................................... 25
Figure 33 Hybrid inheritance ............................................................................................. 26

Development
Figure 34 Compile-time Polymorphism diagram .............................................................. 27

Figure 35 Code for Compile-time Polymorphism ............................................................. 28
Figure 36 Output of Compile-time Polymorphism ............................................................ 28
Figure 37 Code for Runtime Polymorphism ...................................................................... 29
Figure 38 Output of Runtime Polymorphism .................................................................... 29
Figure 39 Association ........................................................................................................ 30
Figure 40 Aggregation code ............................................................................................... 30
Figure 41 Code for Aggregation 2 ..................................................................................... 31
Figure 42 Code for Composition ....................................................................................... 32
Figure 43 Output of Code for Composition ....................................................................... 32
Figure 44 UML Class notation........................................................................................... 34
Figure 45 Class operations (methods) ................................................................................ 35
Figure 46 Class Visibility .................................................................................................. 35
Figure 47 Parameter Direction ........................................................................................... 36
Figure 48 Perspective of Class Diagram ............................................................................ 37
Figure 49 Relationships of Class diagram ......................................................................... 37
Figure 50 Inheritance diagram ........................................................................................... 38
Figure 51 Inheritance Example - Shapes ........................................................................... 38
Figure 52 Simple Association ............................................................................................ 39
Figure 53 Cardinalities ....................................................................................................... 39
Figure 54 Example for Aggregation .................................................................................. 40
Figure 55 Example for Composition .................................................................................. 40
Figure 56 Example for Dependency .................................................................................. 41
Figure 57 Realization ......................................................................................................... 41
Figure 58 Example of Class Diagram ................................................................................ 42
Figure 59 Class Diagram of Family Dental Care ............................................................... 42
Figure 60 Login Form ........................................................................................................ 44
Figure 61 Manager Dashboard ........................................................................................... 44
Figure 62 Doctor Form ...................................................................................................... 45
Figure 63 Staff Form .......................................................................................................... 45
Figure 64 Patient Form ...................................................................................................... 46
Figure 65 Room Form ........................................................................................................ 46
Figure 66 Appointment Form ............................................................................................ 47
Figure 67 Code for the Login function .............................................................................. 47

Development
Figure 68 Code for Dashboard function ............................................................................ 48

Figure 69 Code for Insert Function .................................................................................... 48
Figure 70 Code for Update function .................................................................................. 49
Figure 71 Code for Delete function ................................................................................... 49
Figure 72 Code for Search function ................................................................................... 50
Figure 73 Code for Show table data dunction.................................................................... 50
Figure 74 Encapsulation Code 1 ........................................................................................ 51
Figure 75 Encapsulation Code 2 ........................................................................................ 51
Figure 76 Polymorphism code ........................................................................................... 52
Figure 77 Inheritance Code ................................................................................................ 52
Figure 78 Abstract Code .................................................................................................... 53
Figure 79 Abstract show table ........................................................................................... 53
Figure 80 UML of Singleton design pattern ...................................................................... 55
Figure 81 Singleton Design Pattern code ........................................................................... 56
Figure 82 UML for Factory Pattern ................................................................................... 56
Figure 83 Factory Pattern Code ......................................................................................... 57
Figure 84 Factory Pattern Code ......................................................................................... 57
Figure 85 UML for Abstract Factory Pattern ..................................................................... 58
Figure 86 UML for Composite Pattern .............................................................................. 59
Figure 87 Composite Pattern Code .................................................................................... 60
Figure 88 Composite Pattern Code 2 ................................................................................. 60
Figure 89 Composite Pattern Output ................................................................................. 61
Figure 90 UML diagram for interpreter ............................................................................. 63
Figure 91 UML Diagram for iterator design pattern .......................................................... 64
Figure 92 Implementation code ......................................................................................... 64
Figure 93 Implementation code 2 ...................................................................................... 65
Figure 94 UML Diagram for Observer Pattern .................................................................. 66
Figure 95 Class Diagram for the Scenario 1 ...................................................................... 68
Figure 96 Scenario 1 Implementation code ....................................................................... 69
Figure 97 Scenario 1 Implementation code 2 .................................................................... 69
Figure 98 Scenario 1 Implementation code 3 .................................................................... 70
Figure 99 Output of Scenario 1 implementation code ....................................................... 70
Figure 100 Class Diagram for the scenario 2 ..................................................................... 72
Figure 101 Scenario 2 Implementation code ..................................................................... 73

Development
Figure 102 Scenario 2 Implementation code 2 .................................................................. 73

Figure 105 Output of Scenario 2 Implementation code ..................................................... 75
Figure 106 Class Diagram for the Scenario 3 .................................................................... 76
Table of Tables
Table 1 Comparison between static and non-static method ............................................... 14
Table 2 Difference between abstract class and Interface .................................................. 17

Development
ACKNOWLEDGEMENT
I would like to express my deepest appreciation to all those who provided me the Possibility
to complete this assignment a special gratitude I give to our lecturer Miss K. Ushamini
Whose contribution in stimulating suggestions and encouragement, Helped to me
coordinate my project especially in writing this assignment documentation.
Furthermore, I would also like to acknowledge with much appreciation of the crucial rote
of the staffs of ESOFT campus. Who gave the permission to use all required equipment’s
and the Necessary materials to complete this assignment. I have to appreciate the guidance
given by the assignment coordinator Mr. S. Premnath. In addition, other Lecturers of
ESOFT campus Jaffna Branch that has improved my working skills and thanks to their
Comment and advices.
S. Pakeen
HND in computing & Systems Development
ESOFT Metro Campus Jaffna

Development
Introduction to Object-oriented programming (OOP)

Object-oriented programming (OOP) is a computer programming model that coordinates
software design around data, or objects, rather than functions and logic. An object can be
defined as a data field that has different attributes and behavior. OOP focuses on the objects
that developers want to handle rather than the logic expected to manipulate them. The
organization of an object-oriented program also makes the method profitable to
collaborative development, where projects are divided into groups. Further benefits of OOP
include code reusability, scalability, and efficiency.
Figure 1 OOP Concept
Advantages of Object oriented Programming

 Reuse
"Write once and use many times" you can achieve this with a class.
 Redundancy
Inheritance is a nice feature for data redundancy. If you need the same functionality in
multiple classes, you can write a generic class for the same functionality and subclass that
class.
 Easy maintenance
Existing code is easy to maintain and modify because new objects can be created with little
difference from existing ones.
 Security

Development
By using data hiding and data abstraction, only the required data will be exposed, thus
keeping the data safe.
Disadvantages of Object oriented Programming
 The size
Object-oriented programs are much larger than other programs.
 An effort
It takes a lot of work to create object-oriented programs.
 Speed
Object-oriented programs are slower than other programs due to their size.
Class
A class is a user-defined blueprint or prototype from which objects are created. It outlines
the set of properties or methods that are general to all objects of one type. In general, class
declarations can incorporate these components, in order:
 Modifiers: A class can be public or holds the default access  class keyword:
 Class keyword is used to generate a class.
 Class name: The name should commence with an initial letter (capitalized by
convention).
 Superclass (if any): The name of the class’s parent (superclass), if any, preceded
by the keyword extends. A class can only elongate (subclass) one parent.
 Interfaces (if any): A comma-separated list of interfaces implemented by the class,
if any, preceded by the keyword implements. A class can implement more than
one interface.  Body: The class body enclosed by braces, { }.
In Java, we can create a class using the class keyword. For instance,
Figure 2 create a class using the class keyword
Here, fields (variables) and methods represent the state and behavior of the object,
respectively.
 Fields are used to store data
 Methods are used to perform some operations

Development
Figure 3 Code for creating class
In the above example we created a class called Bicycle. It contains a field called gear and
a method called braking ().
Here is the Bicycle prototype. Now we can create as many bikes as we want using the
prototype. And all bikes will share prototype spaces and methods.
Objects
It is a fundamental unit of Object-Oriented Programming and depicts real-life entities. A
typical Java program generates many objects, which as you know, communicate by
invoking methods. An object consists of
 State: It is depicted by attributes of an object. It also reveals the properties of an
object.
 Behavior: It is represented by the methods of an object. It also reflects the
response of an object with other objects.
We create classes and define the main () method in another class. It's a better way than
before.

Development
Figure 4 Code for Objects
Output:
Figure 5 Objects output
Method
In the Java programming language, a method is a part of a program that contains a set of
instructions or code. In a Java program, like a cake recipe, a method has a set of instructions.
When a method is called, a set of statements within the method is executed. (study, 2022)
Declaring a Java Method
The syntax of declare a method is
Figure 6 syntax of declare a method

Development
Here,
 ReturnType: Specifies what type of value a method returns. For example, if a
method's return type is int, it returns an integer value.
 If the method does not return a value, the return type is null.
 MethodName: is an identifier used to refer to a specific method in a program.
 Method body: Contains programming expressions used to perform some task. The
method body is enclosed in curly braces { }. (programiz, 2022)
Static method
A static method in Java is a method that belongs to the class, not the object. A static method
can only access static data. It is a method that belongs to the class, not to the object
(instance). A static method can only access static data. You can't access non-static data
(instance variables). (Hartman, 2022)
Figure 7 code for Static method
Figure 8 Output of Static method code
Non static method

A non-static method in Java belongs to an object of a class and is similar to a paper pattern
made from original design or original dress. (study, 2022)

Development
Comparison between static and non static method
Table 1 Comparison between static and non-static method
Final Method
Final modifier to terminate implementations of classes, methods and variables.
We can declare a final method, once you declare a final method, it cannot be overridden.
Therefore, you cannot modify a final method of a subclass.
The main purpose of terminating a method is so that no one outside changes the content of
the method. (Usharani, 2022)
Figure 9 Code for final method

Development
Output:
Figure 10 Output of final method code
Abstract method
A bodyless (implementationless) method is known as an abstract method. A method
should always be declared in an abstract class, that is, you can say that if a class has an
abstract method, it must also be declared abstract. (beginnersbook, 2022)
Figure 11 Code for Abstract method
Output:
Figure 12 Output of Abstract method

Development
Method Call
When a program calls a method, control of the program is transferred to the called method.
An invoked method returns control to the caller when the return statement is executed or
the closing brace that terminates the method is reached.
Figure 13 Method Call diagram
Figure 14 Code for method call
Figure 15 Output of method call code

Development
In the above example, we created a method called addNumbers(). The method takes two
parameters a and b.
Abstraction
abstraction is the quality of working with ideas, not with events. For example, when you
consider an email example, complex details such as what happens as soon as you send an
email and the protocol your mail server uses are hidden from the user. So, to send an email,
just enter the content, provide the recipient's address, and hit send.
Similarly, in object-oriented programming, abstraction is the process of hiding
implementation details from the user, only functionality will be provided to the user. In
other words, the user will have information about what the object does, not how it does it.
Difference between abstract class and Interface
Abstract Class Interface
An abstract class can have both abstract

The interface can only have abstract
and non-abstract methods. methods.
Does not support multiple inheritance. Supports multiple inheritances.
You can provide the implementation of
You cannot provide the implementation of
the interface. the abstract class.
An abstract class can have public abstract
An interface can only have public abstract
and protected methods. methods.
An abstract class can have a final, static,
or static-final variable with any access The interface can only have one public
static final variable.
specifier.
An abstract class can have both abstract
The interface can only have abstract
and non-abstract methods. methods.
Table 2 Difference between abstract class and Interface

Development
Figure 16 Code for Abstraction
Output:
Figure 17 Output of Abstraction code
The simple abstraction example above has a Car class. In this Car class, we have an abstract
method for speed(). So we inherit this class in the Suzuki class. Inside the Suzuki class, we
implement the acceleration method.
The above example simply shows how an abstract class is defined, inherited, and then used
in a program.
Abstract interface
An interface in Java is defined as an abstract type that defines the behavior of a class. An
interface is a type of protocol that establishes rules about how a particular class should
behave.
An interface in Java can contain abstract methods and static constants. By default, all
interface methods are public and abstract. (softwaretestinghelp, 2022)

Development
Figure 18 Code for Abstract interface
Output:
Figure 19 Output of Abstract interface code
The above program demonstrates the simple example of interfaces in Java. Here, we declare
an interface called Polygon_Shape and then the Rectangle class implements it.
Encapsulation
The whole idea of encapsulation is to hide implementation details from users. If a data
element is private, this means that it can only be accessed within the same class. No external
class can access a private data member (variable) of another class.
However, if we configure public getters and setters to update (eg: void setSSN (int ssn))
and read (eg: int getSSN ()) private data fields, then the outer class will be able to access
those private data fields through public methods. .
Therefore, the data can only be accessed using public methods, which makes private fields
and their implementation hidden from external classes. That is why encapsulation is known
as data hiding. Let's look at an example to better understand this concept. (beginnersbook,
2022)
To perform encapsulation in Java –
 Declare the variables of a class as private.
 Provide public setter and getter methods to transform and view the values of the
variables.

Development
Advantages of Encapsulation
The main benefit of using encapsulation is the security of the data. Advantages of
encapsulation include:
 Encapsulation shields an object from unwanted access by clients.
 Encapsulation permits access to a level without revealing the complex details below
that level.
 It decreases human errors.
 Analyzes the maintenance of the application
 Makes the application more comfortable to understand.
Figure 20 Example for Encapsulation
How to achieve or implement Encapsulation in Java

 There are two important points whereby we can achieve or implement encapsulation
in Java program.
 Declaring the instance variable of the class as private. so that it cannot be accessed
directly by anyone from outside the class.
 Provide the public setter and getter methods in the class to set/modify the values of
the variable/fields.

Development
Figure 21 Code for Encapsulation
Output:
Figure 22 Output of encapsulation code
In the example above, three data members (or data fields) are private and cannot be
accessed directly. These fields can only be accessed through public methods. The
empName, ssn, and empAge fields are converted to hidden data fields using the OOP
encapsulation method.
Inheritance
Inheritance in Java is a concept that passes the properties of a class to other classes; for
example, the relationship between father and son.
In Java, a class can inherit the attributes and methods of another class. A class that inherits
properties is called a subclass or child class. The class from which properties are inherited
is called the superclass or parent class.
In inheritance, derived classes take on the properties of a base class.

Development
Figure 23 derived class inheritance
Inheritance syntax in Java
Figure 24 Inheritance syntax in Java
Figure 25 Code for inheritance

Development
Figure 26 Output of inheritance code
The extended keyword extends a class and is an indicator that another class inherits the
class. When you say that class B extends class A, it means that class B inherits the
properties (methods, attributes) of class A. Here, class A is a superclass or parent class and
class B is a subclass or child class.
Types of Inheritance
There are the following types of inheritance:
 Single Inheritance
 Multilevel Inheritance
 Multiple inheritance
 Hierarchical inheritance
 Hybrid inheritance
Single Level Inheritance
Sub classing from the same base class is called single inheritance.
Figure 27 Single Level Inheritance
In Inheritance, we can access superclass methods and variables. We can also access
subclass methods and variables through subclass objects only. We have to take care of
superclass and subclass methods, and variable names shouldn’t conflict.

Development
Figure 28 Code for Single level
Figure 29 Output of Single level
Multiple Inheritance
The definition of a class derived from multiple base classes is known as "multiple
inheritance". In this case, there is more than one superclass and there may be one or more
subclasses.
Multiple inheritance is available in C++ object-oriented programming, but it is not
available in Java.
In some cases Java developers want to use multiple inheritance. Fortunately, Java
developers have interface concepts that suggest developers can achieve multiple
inheritance by using multiple interfaces.
Figure 30 Multiple Inheritance

Development
Multilevel Inheritance
In multilevel inheritance in Java, a class extends another class that has already been
extended from another class. For example, if there is a class A that extends to class B, and
class B extends from another class C, then this scenario is known to follow multilevel
inheritance.
We can take three classes as an example: car class, car class and SUV class. Here the
Vehicle class is the grandma class. The Car class extends the Vehicle class, and the SUV
class extends the Car class.
Figure 31 Multilevel Inheritance
Hierarchical inheritance
In hierarchical inheritance in Java, multiple derived classes extend a single base class. In a
nutshell, more than one child class extends a parent class or a parent class has more than
one child class.
For example, consider the parent class Car. Now consider the child classes Audi, BMW,
and Mercedes. In hierarchical inheritance in Java, the Audi class, the BMW class, and the
Mercedes class all three extend the Car class.
Figure 32 Hierarchical inheritance

Development
Hybrid inheritance
Hybrid inheritance in Java is a combination of inheritances. In this type of inheritance,
more than one type of inheritance is observed. For example, if we have class A and class B
that extend class C, and then there is another class D that extends class A, then this type of
inheritance is known as hybrid inheritance.
Why? Because we can clearly see that there are two types of inheritance here: hierarchical
and unique inheritance.
In the diagram below, we see another example of hybrid inheritance. (mygreatlearning,
2021)
Figure 33 Hybrid inheritance
Polymorphism
 Polymorphism is the ability of an object to take on many forms. The most common
use of polymorphism in OOP occurs when a parent class reference is used to refer
to a child class object.
 Any Java object that can pass more than one IS-A test is considered to be
polymorphic. In Java, all Java objects are polymorphic since any object will pass
the IS-A test for their own type and for the class Object.
 It is important to know that the only possible way to access an object is through a
reference variable. A reference variable can be of only one type. Once declared, the
type of a reference variable cannot be changed.
 The reference variable can be reassigned to other objects provided that it is not
declared final. The type of the reference variable would determine the methods that
it can invoke on the object.
 A reference variable can refer to any object of its declared type or any subtype of
its declared type. A reference variable can be declared as a class or interface type.

Development
Types of Polymorphism
In Java, polymorphism is mainly divided into two types:
 Compile-time polymorphism
 Runtime polymorphism
Compile-time Polymorphism
It is also known as static polymorphism. This type of polymorphism is achieved by function
overloading or operator overloading.
Figure 34 Compile-time Polymorphism diagram
Method Overloading: When there are multiple functions with the same name but
different parameters, these functions are said to be overloaded. Functions can be
overloaded by changing the number of arguments and/or changing the type of arguments.

Development
Figure 35 Code for Compile-time Polymorphism
Figure 36 Output of Compile-time Polymorphism

Development
Runtime Polymorphism
Also known as dynamic method dispatch. It is a process in which a function call of an
overridden method is resolved at runtime. This type of polymorphism is achieved by
overriding a method. On the other hand, method overriding occurs when a derived class
has a definition for one of the member functions of the base class. This basis function is
said to be zero.
Figure 37 Code for Runtime Polymorphism
Figure 38 Output of Runtime Polymorphism

Development
Association
The term "association" refers to a relationship that exists between two distinct classes that
is established through their Objects. One-to-one, one-to-many, many-to-one, and many-to-
many associations are all possible. An Object communicates with another object in Object-
Oriented programming to leverage the capabilities and services provided by that object.
The two types of association are composition and aggregation.
Figure 39 Association
Aggregation
Aggregation in Java is a two-class relationship that is best described as a "has-a" and
"whole/part" relationship. It's a more advanced form of the association relationship. The
aggregate class has ownership of another class because it has a reference to it. Each
referenced class is regarded as a subset of the aggregate class. (thoughtco, 2022)
Aggregation code
Figure 40 Aggregation code

Development
Figure 41 Code for Aggregation 2
Composition
A has-a relationship is implemented using the composition design technique in Java.
Composition can be utilized in the same way that Java inheritance is used for code reuse.
An instance variable that references to other objects is used to create the composition.
Composition is defined as when one item contains another object and the enclosed object
cannot exist without the other object. Composition is a means of describing a reference
between two or more classes using instance variables, and an instance must be constructed
before it can be used.

Development
Composition Code
Figure 42 Code for Composition
Figure 43 Output of Code for Composition

Development
Introduction to UML Diagram

UML is an abbreviation for Unified Modeling Language. In short, UML is a modern
approach to modeling and documenting software. In fact, it is one of the most popular
business process modeling techniques.
It is based on schematic representations of software components. As the old proverb says,
“a picture is worth a thousand words.” Through the use of visual representations, we can
better understand potential flaws or errors in software or business processes.
The UML was created out of the chaos around software development and documentation.
In the 1990s, there were several different ways of representing and documenting software
systems. There was a need for a more unified way to visually represent these systems, and
as a result, UML was developed between 1994 and 1996 by three software engineers
working at Rational Software. It was later adopted as a standard in 1997 and has remained
the standard ever since with only a few updates. (tallyfy, 2022)
Use of UML Diagram
UML has been used primarily as a general-purpose modeling language in the field of
software development. However, it has now found its way into the documentation of
various business processes or workflows. For example, activity diagrams, a type of UML
diagram, can be used as a replacement for flowcharts. They provide a more standardized
way of modeling workflows and a richer set of features to improve readability and
efficiency.
Types of UML Diagram
There are several types of UML diagrams, and each has its own purpose, whether developed
before or after implementation (as part of documentation).
The two broadest categories, covering all other types, are UML Behavior Chart and UML
Structure Chart. As the name suggests, some UML diagrams attempt to analyze and
represent the structure of a system or process, while others describe the behavior, actors,
and constituent components of the system. The different types are divided as follows:
Behavioral UML Diagram
 Activity Diagram
 Use Case Diagram
 Interaction Overview Diagram
 Timing Diagram
 State Machine Diagram

Development
 Communication Diagram
 Sequence Diagram
Structural UML Diagram
 Class Diagram
 Object Diagram
 Component Diagram
 Composite Structure Diagram
 Deployment Diagram
 Package Diagram
 Profile Diagram
Class Diagram
A class is a blueprint for an object. Objects and classes go hand in hand. We cannot talk
about one without talking about the other. And the whole point of object-oriented design is
in classes, not objects, because we use classes to create objects. So a class defines what an
object will be, but not the object itself.
In fact, classes define the type of objects, and objects are usable instances of classes. Every
object is created from the same blueprint set and therefore contains the same components
(properties and methods). Its default meaning is that an object is an instance of a class and
an object. Objects have states and behaviors.
UML class notation
A class represents a concept that encompasses state (attributes) and behavior (operations).
Each attribute has a type. Every transaction has a signature. The class name is the only
required information.
Figure 44 UML Class notation

Development
Class name
The class name appears in the first section.
Class features
 The attributes are shown in the second section.
 The attribute type is displayed after the colon.
 Attributes are mapped to member variables (data members) in the code.
Class operations (methods)
 Operations are shown in the third section. These are the services that the class
provides.
 The return type of a method is displayed after the colon at the end of the method
signature.
 The return type of the method parameters is displayed after the parameter name,
followed by a colon. Operations map to class methods in code
Figure 45 Class operations (methods)
Class Visibility
The +, -, and # symbols in front of an attribute and operation name in a class indicate the
visibility of the attribute and operation.
Figure 46 Class Visibility

Development
 + specifies common attributes or actions

 - defines special attributes or actions
 # denotes protected attributes or processes
Parameter Direction
Each parameter in a process (method) can be assigned in, out, or out, which determines its
direction according to the caller. This versatility is displayed in front of the parameter name.
Figure 47 Parameter Direction
Perspective of Class Diagram

The choice of point of view depends on how far you have progressed in the development
process. For example, when formulating the domain model, I rarely went beyond the
conceptual perspective. Analysis models are typically a combination of conceptual and
specification points of view. The development of a design model typically starts from a
specification perspective and moves to an implementation perspective.
The diagram can be interpreted from several points of view:
 Conceptual: Represents domain concepts.
 Specification: Focuses on Abstract Data Type (ADT) interfaces in software.
 Implementation: describes how classes will implement their interfaces.
Perspective influences the amount of detail that will be provided and the types of
relationships worth presenting. As we mentioned earlier, the class name is the only
information required.

Development
Figure 48 Perspective of Class Diagram
Relationships between classes

UML is not just pretty pictures. When used correctly, the UML conveys exactly how code
should be implemented from diagrams. When interpreted correctly, the implemented code
will correctly reflect the designer's intent.
If you still can't recognize them, no problem, this section is intended to help you understand
UML class relationships. A class may be involved in one or more relationships with other
classes. Relationships can be one of the following types:
0
Figure 49 Relationships of Class diagram
Inheritance (or generalization)

Generalization is a taxonomic relationship between a more general classifier and a more
specific classifier. Every instance of a particular classifier is also an indirect instance of the
general classifier. Thus, a particular classifier inherits the properties of a more general
classifier.

Development
 Represents an “is-a” relationship.

 The abstract class name is shown in italics.
 SubClass1 and SubClass2 are Superclass’s specialties.
The figure below shows an example of an inheritance hierarchy. SubClass1 and SubClass2
are descended from Superclass. The link is displayed as a straight line with a hollow arrow
pointing from child to parent.
Figure 50 Inheritance diagram
Inheritance Example - Shapes

The figure below shows an example of inheritance with two styles. Although the connectors
are drawn differently, they are semantically equivalent.
Figure 51 Inheritance Example - Shapes

Development
Association
Associations are relationships between classes in a UML class diagram. They are
represented by a straight line between classes. Associations are usually referred to as a verb
or a verb phrase that reflects the real problem area.
Simple Association
 Structural relationship between two peers.
 There is a relationship between class 1 and class 2.
The figure below shows a simple association example. There is a relationship between class
<<control>> Class1 and class <<limit>> Class2. The relationship is displayed as a straight
line connecting two classes.
Figure 52 Simple Association
Cardinality
Cardinality is expressed in terms of:

 One to one
 One to many
 Many to many
Figure 53 Cardinalities

Development
Aggregation
A special type of association.
 It represents a "part" of the relationship.
 Class2 is part of Class1.
 Many instances of class 2 (indicated by *) can be associated with class 1.
 Class1 and Class2 objects have different lifetimes.
The figure below shows an example of aggregation. The relationship is displayed as a solid
\line with a clear diamond at the end of the association associated with the class that
represents the population.
Figure 54 Example for Aggregation
Composition
 A special type of gathering in which the parts are destroyed when the whole is
destroyed.
 Class 2 objects live and die with class 1.
 Class 2 cannot stand on its own.
The figure below shows an example composition. The association is displayed as a straight
line with a solid diamond at the end of the association, depending on the class that
represents the whole or combination.
Figure 55 Example for Composition
Dependency
An object of one class can use an object of another class in its method code. If the object is
not stored in any field, it is modeled as a dependency relationship.
 A special type of association.
 Two classes exist if changes in the definition of one can cause changes in the other
(but not vice versa).

Development
 Class1 depends on Class2

The figure below shows an example of dependency. Relationships are displayed as a dotted
line with an open arrow.
Figure 56 Example for Dependency
The figure below shows another example of a dependency. The Person class can have a has
Read method with a Book parameter that returns true if the person has read the book
(perhaps by checking some databases).
Realization
A Realization is a relationship between a design class and an object that contains relevant
implementation-level details. This object is said to implement the blueprint class. In other
words, you can think of it as the relationship between an interface and a class that
implements it.
For example, the owner interface can specify methods for taking and deleting ownership.
The Person and Corporation classes should implement these methods, perhaps in very
different ways.
Figure 57 Realization

Development
Example of Class Diagram
Figure 58 Example of Class Diagram
Class Diagram of Family Dental Care
Figure 59 Class Diagram of Family Dental Care

Development
Each class is represented by a box with three stacked parts carrying the class name,
attributes, and operations in this FDC class diagram. Each class in this diagram has multiple
attributes and operations for various reasons. There are fifteen classes in the Family Dental
Care (FDC) System. Person, Patient, Doctor, Ordinary, Consultant, Staff, Nurse, Manager,
Receptionist, Appointment, Building, Surgery Room, Scan Room, Scan machine, and
Allocation are the classes. The Patient, Doctor, and Staff classes all derive from the Person
class. The Nurse class, Manager Class, and Receptionist class all inherit the Staff class.
Inheritance of Class Relationships
The Patient, Doctor, and Staff classes all inherit the Person class. This is because all three
classes share the attributes of the Person class. As a result of inheriting from the Person
class, the code will not be repeated. The Staff class gives rise to the Nurse, Manager, and
Receptionist classes.
Composition
Both the Surgery Room and Scan Room courses have a Composition relationship with the
FDC Building class. Because the Surgery Room and Scan Room classes are both dependent
on the FDC Building class, their life cycles are intertwined.
Aggregation
In this scenario, the Scan Room and Scan Machine classes have an aggregation relationship.
Because each of the Scan Room and Scan Machine classes has its unique life cycle.
Association
The appointment class, the manager class, the receptionist class, the patient class, and the
doctor class are all linked. The reason for this is that the appointment class has a fixed link
with the management, receptionist, patient, and doctor classes. Similarly, there is a link
between the allocation class and the management, doctor, and nurse classes.

Development
Interfaces designing for the Family dental Care
Login form
Figure 60 Login Form
Manager is the user login in the Family Dental Care system. manager have distinct access
levels, for example, the manager can manage all types of data with all of the system's
options.
Manager Dashboard
Figure 61 Manager Dashboard

Development
On the management dashboard, there are five forms to choose from. Among these are the
Patient, Doctor, Staff, Appointment, and Allocation forms.
Doctor Form
Figure 62 Doctor Form
Managers can fill up the doctor form with information such as doctor id, doctor type, name,
nic number, age, gender, email, address, qualification and contact number. However, if the
doctor type is prominent, the qualification and country textboxes will be disabled;
otherwise, they will be enabled.
Staff Form
Figure 63 Staff Form

Development
Managers can register staff with their staff id, first name, last name, gender, age, email,
address, job type, and contact number in the staff form. However, if a receptionist logs in,
the form will be blocked and the delete option will be enabled.
Patient Form
Figure 64 Patient Form
Patient id, first name, last name, nic no, gender, age, blood group, address, and contact
number can all be entered into the patient form by the management. However, if a
receptionist logs in, the form will be blocked and the delete option will be enabled.
Room Form
Figure 65 Room Form

Development
Staff can register rooms using this form by selecting a room type such as scan room, surgery
room 1, surgery room 2, surgery room 3, or surgery room 4.
Appointment Form
Figure 66 Appointment Form
Managers can fill out the appointment form with a single click on the room details button
to acquire room registration information. Patient and doctor information is recorded in the
table. By clicking data, the receptionist or manager can fill out the form.
Code for the Login function
Figure 67 Code for the Login function

Development
Code for Dashboard function
Figure 68 Code for Dashboard function
Code for Insert Function
Figure 69 Code for Insert Function

Development
Code for Update function
Figure 70 Code for Update function
Code for Delete function
Figure 71 Code for Delete function

Development
Code for Search function
Figure 72 Code for Search function
Code for Show table data dunction
Figure 73 Code for Show table data function

Development
Object Oriented Concept for Family Dental Care System

Encapsulation Code
Figure 74 Encapsulation Code 1
Figure 75 Encapsulation Code 2
The Family Dental Care system was created using Object-Oriented concept encapsulation
to secure sensitive data such as login username and password. The Encaptext class has
private attributes for controlling and restricting external access, as well as public getter and
setter methods for indirectly accessing them. As a result, unwanted access and theft of the
username and password will be prevented.

Development
Polymorphism Code
Figure 76 Polymorphism code
The Dashboard class inherits the JFrame class. The action performed () function does not
need to be written in the polymorphism class because to the presence of the action
performed() method in the class JFrame. As a result, it is possible to override that function
and provide a new implementation for the Dashboard class.
Inheritance Code
Figure 77 Inheritance Code
The inheritance notion can be utilized to gain access to the JFrame class's methods and
properties in the desired class. Inheritance reduces code repetition while also allowing for
code extension. This allows you to use the JFrame's methods and attributes in the specified
class. The JFrame class was inherited by the doctor class, and its methods were used in the
doctor class.

Development
Abstract Code
Figure 78 Abstract Code
Figure 79 Abstract show table
The data in the database of the family dental care system is extracted using the
showTableData () method. As a result, other parties should not profit from the
implementation specifics of data extraction. As a result, the process of pulling data from
the database should be hidden from other classes utilizing the Abstraction concept. As a
result, the abstract class was created, along with the show table data method as an abstract
method within it. The implementation of the method was provided by the child
class'showTable.'

Development
Design Pattern
Design patterns are tried-and-true techniques to solving certain challenges. A design pattern
is not a framework, and therefore cannot be implemented directly in code.
There are two basic applications for design patterns:
 They give a standard language for developers to communicate about specific issues.
If a developer informs another developer that he uses a Singleton, the other
developer (should) understand exactly what that means.
 Good practices are captured in design patterns, which are solutions that have been
effectively applied to issues. An inexperienced developer can learn a lot about
software design by learning these patterns and the corresponding problem.
Object-oriented design principles are the foundation of design patterns.
 Not an implementation, but a program to an interface
 Object composition is preferred over inheritance.
Design Patterns are classified as follows:
 Creation Patterns
 Structure Patterns
 Behavior Patterns (vogella, n.d.)
Creational Design Pattern
The way objects are created is the subject of creational design patterns. When a decision
must be made during the instantiation of a class, these design patterns are employed (i.e.
creating an object of a class).
Types of Creational Patterns
 Factory Method Pattern
 Abstract Factory Pattern
 Singleton Pattern
 Prototype Pattern
 Builder Pattern
 Object Pool Pattern

Development
Singleton Pattern
According to the Singleton Pattern, all you have to do is "create a class with only one
instance and offer a global point of access to it."
To put it another way, a class must make sure that only one instance is produced and that
only one object can be utilized by all other classes.
The singleton design pattern is divided into two types.
 Early Instantiation is the process of creating an instance before it is loaded.
 Lazy Instantiation is the process of creating an instance only when it is needed.
(javatpoint, n.d.)
UML of Singleton design pattern
Figure 80 UML of Singleton design pattern

Development
Singleton Design Pattern code
Figure 81 Singleton Design Pattern code
Factory Pattern
A Factory Pattern, also known as a Factory Method Pattern, states that you should only
create an interface or abstract class for producing objects and leave it up to the subclasses
to pick which class to instantiate. In other words, subclasses are in charge of creating the
class instance.
Virtual Constructor is another name for the Factory Method Pattern. (javatpoint, 2022)
UML for Factory Pattern
Figure 82 UML for Factory Pattern

Development
Factory Pattern Code
Figure 83 Factory Pattern Code
Figure 84 Factory Pattern Code

Development
Abstract Factory Pattern

According to the Abstract Factory Pattern, you can create families of linked (or dependent)
items by simply defining an interface or abstract class without identifying their particular
sub-classes. This means that a class can return a factory of classes using Abstract Factory.
As a result, the Abstract Factory Pattern is a level higher than the Factory Pattern.
Kit is another name for an Abstract Factory Pattern. (Anon., 2022)
Figure 85 UML for Abstract Factory Pattern
Builder Pattern
"Construct a complex thing from small objects using a step-by-step technique," according
to the Builder Pattern.
When an object cannot be generated in a single step, such as when de-serializing a complex
object, it is commonly utilized.
Prototype Pattern
The Prototype Pattern refers to the cloning of an existing object rather than constructing a
new one, and it can also be altered to meet specific needs.
If the cost of producing a new object is high and resource-intensive, this approach should
be followed. (javatpoint, 2022)
Structural Design Patterns
In terms of class compositions and object structures, Structural Patterns is focused with
giving solutions and efficient standards. They also rely on inheritance and interfaces to
allow numerous objects or classes to interact and form a single functioning unit.
The Structural Patterns in Java that are covered in this article are:
 Adapter
 Bridge
 Filter

Development
 Composite
 Decorator
 Facade
 Flyweight
 Proxy
Adapter Pattern
As the name implies, the Adapter pattern adapts one interface to another. Similar to how a
scanner functions as a bridge between a paper and a computer, it acts as a link between two
unrelated, and sometimes even completely incompatible interfaces.
A computer cannot save a paper as a PDF document, but a scanner that combines the
functions of both may scan it and store it on the computer.
Bridge Pattern
The Bridge pattern separates abstract classes from their implementations and serves as a
link between them. Both the abstract class and the implementation can change structurally
without impacting each other in this way.
If this is still unclear, look at the implementation to see how it's done.
Filter Pattern
When we require a way to filter through a set of objects using distinct custom criteria, we
utilize the Filter pattern. We can chain criteria to create a finer filter in a decoupled manner.
Composite Pattern
When we need to treat a large set of items in a same or identical fashion, we employ the
Composite pattern.
This is commonly done by the class that "owns" the collection of objects and provides a set
of methods to treat them all equally as if they were one.
Figure 86 UML for Composite Pattern

Development
Composite Pattern Code
Figure 87 Composite Pattern Code
Figure 88 Composite Pattern Code 2

Development
Composite Pattern Output
Figure 89 Composite Pattern Output
Decorator pattern
The Decorator pattern is used to change a single instance of a class at runtime by wrapping
the original class in a decorator class.
Changing or adding features to the decorator object will have no effect on the structure or
functionality of the original object in this fashion.
It differs from traditional inheritance in that it occurs at runtime and affects only one
instance, whereas inheritance occurs at compile time and affects all instances.
Facade pattern
The Facade pattern gives the client a basic, top-level interface that allows them to access
the system without having to understand its logic or inner workings.
Flyweight pattern
The Flyweight pattern is concerned with minimizing the JVM's and memory's workload.
This is essential for devices with limited memory, as well as program optimization.
When a program needs to construct a large number of instances of the same class, a
common pool is built so that identical ones can be reused rather than being created each
time.
The String Pool in Java is the most well-known implementation of this design pattern.
Strings are utilized more frequently than any other object in the language, and as a result,
they required a significant amount of resources. The efficiency of Java was greatly
improved by generating a pool of common Strings and assigning multiple reference
variables to the ones with the same content, and only producing new Strings when no match
is discovered.

Development
Proxy pattern
When we want to limit the capabilities and functions of a class by using another class that
limits them, we utilize the Proxy pattern.
The client accesses the original class through the interface defined by this proxy class.
Because all of the client's requests run via our proxy class, he can't do anything with the
actual class out of sequence. (Landup, 2022)
Behavioral Patterns
The interaction and responsibility of objects are the focus of behavioral design patterns.
The interaction between the objects in these design patterns should be such that they may
readily communicate with one another while being loosely connected.
In order to prevent hard coding and dependencies, the implementation and the client should
be loosely connected. (javatpoint, 2022)
The Gang of Four offers a wide range of design patterns, including behavioral design
patterns. This section includes one example of a class (Template Method) and one example
of an object (Template) (State). Gamma, Helm, Johnson, and Vlissides collectively offer
eleven behavioral patterns:
1. Chain of Responsibility
2. Command
3. Interpreter (class type)
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10. Template Method (class type)
11. Visitor

Development
Chain of responsibility
Sender transmits a request to a chain of objects in chain of responsibility. Any object in the
chain can handle the request.
"Avoid tying the sender of a request to its receiver by giving different objects a chance to
handle the request," according to the Chain of Responsibility Pattern. In the process of
dispensing money, an ATM, for example, employs the Chain of Responsibility design
pattern.
Command Pattern
According to the Command Pattern, "Encapsulate a request in an object and deliver it to
the invoker object as a command. The invoker object searches for a relevant object that can
handle this command and passes the command to that object, which then performs the
command”
Interpreter
"To define a representation of grammar of a particular language, as well as an interpreter
that uses this representation to interpret sentences in the language," according to an
Interpreter Pattern.
In general, the Interpreter pattern can only be used in a limited number of situations. The
Interpreter pattern can only be discussed in terms of formal grammars, although there are
superior solutions in this field, which is why it is not widely utilized.
UML diagram for interpreter
Figure 90 UML diagram for interpreter

Development
Iterator Pattern
Iterator Pattern is used "to progressively retrieve the elements of an aggregate object
without disclosing its underlying implementation," according to GoF.
Cursor is another name for the Iterator pattern.
We are now using Iterator instead of Enumeration in the collection structure.
UML Diagram for iterator design pattern
Figure 91 UML Diagram for iterator design pattern
Implementation code
Figure 92 Implementation code

Development
Figure 93 Implementation code 2
Mediator Pattern
"To define an entity that captures how a set of objects communicate," says the Mediator
Pattern.
Consider an issue to explain the Mediator pattern. When we first start developing, we have
a few classes that interact with one another to produce results. Consider how, as
functionality expands, the logic becomes more complex. So, what happens next? We add
more classes, and they still interact, but maintaining this code is becoming increasingly
tough. As a result, the Mediator pattern solves this issue.
The mediator pattern is intended to simplify communication among various objects or
classes. This pattern creates a mediator class that generally handles all communication
between different classes while also promoting code maintainability through loose
coupling.
Memento Pattern
"To restore the state of an object to its prior state," according to a Memento Pattern.
However, it must do so without breaking Encapsulation. In the event of a mistake or failure,
such a scenario is useful.
Token is another name for the Memento pattern.
One of the most commonly used operations in an editor is undo, sometimes known as
backspace or ctrl+z. The undo action is implemented using the Memento design pattern.
This is accomplished by saving the object's current state as it changes.
Observer Pattern
"Just construct a one-to-one dependency so that when one object changes state, all its
dependents are notified and changed immediately," according to the Observer Pattern.
Dependents or Publish-Subscribe are other names for the observer pattern.

Development
UML Diagram for Observer Pattern
Figure 94 UML Diagram for Observer Pattern
State Pattern
"The class behavior changes based on its state," according to a State Pattern. We generate
objects that represent distinct states and a context object whose behavior changes as its state
object changes in State Pattern.
Objects for States is another name for the State Pattern.
Strategy Pattern
"Defines a family of functionality, encapsulates each one, and makes them
interchangeable," according to a Strategy Pattern.
Policy is another name for the Strategy Pattern.
Template Pattern
"Just define the skeleton of a function in an operation, deferring some stages to its
subclasses," according to the Template Pattern. (javatpoint, 2022)
Relationship Between object- oriented paradigm and design patterns
A paradigm can also refer to a problem-solving or goal-achieving technique. A

programming paradigm is a method of solving a problem using tools and techniques
available to us according to a given approach, or we might say it's a way of solving a
problem using tools and techniques available to us according to a specific approach. Many
programming languages exist, but they all need the use of a technique or strategy, which is
referred to as a paradigm.

Development
The software is made up of a number of classes and objects that communicate with one
another. All calculations are conducted on objects, which are the smallest and most
fundamental entities. Rather than the technique, the attention is on the facts. In this
framework, classes represent all real-world entities. Because objects are instances of
classes, they have a state and behavior of their own. The methods are state, attributes, and
behavior. State denotes the object's fields, attributes denote the object's attributes, and
behavior denotes what you do with the object's state. Objects communicate with one
another by sending and receiving messages.
Design patterns describe the best practices used by experienced object-oriented software
engineers. Design patterns are solutions to typical problems that software developers face
when writing code. Over a lengthy period of time, several software engineers employed
trial and error to arrive at these solutions.
In design patterns, the union design pattern is a structural pattern that depicts the inheritance
relationship between a superclass and its subclasses. When an object in OOP outsourced
one of its defined responsibilities to an associated help object rather than completing it
itself, the delegation design pattern is utilized. In a design pattern, each class implements
an interface or virtual methods using typical OOP approaches. A factory method is a
creational pattern that helps with object creation without exposing the user to creational
logic. As a result, design patterns and good OOP make it easier to alter complex programs
and reduce the amount of changes and global issues.

Development
Scenario 1
Singleton Design for the Scenario
FDC possesses a very expensive, state-of-the-art dental scan machine, which is
significantly superior to a standard dental X-ray machine built by Toshiba, Japan, according
to the situation. In the near future, FDC will only own one of these machines. At the same
time, they demanded that when modeling and implementing the FDC system in software,
only one instance of the scan machine be created.
The various types of design patterns in Java have been examined. When looking at the
design patterns for scenario 1, we found one that was a match and used the singleton design
pattern. The Singleton pattern assures that a class has only one instance and gives that
instance a global point of access. It gets its name from the singleton set, which is a set with
only one element. FDC's scanning machine is a Singleton. The FDC owner establishes a
single object creation restriction, limiting the number of machines that can be created in
the system.
As a result, the singleton pattern is used to control only one instance. It can't build a new
object because it makes the constructor private. As a result, it can use the singleton design
pattern to govern the production of new instances.
Class Diagram for the Scenario 1
Figure 95 Class Diagram for the Scenario 1

Development
Implementation Code
Figure 96 Scenario 1 Implementation code
Figure 97 Scenario 1 Implementation code 2

Development
Figure 99 Output of Scenario 1 implementation code

Development
Scenario 2
Composite Design Pattern for the Scenario 1
The Family Dental Care Hospital employs a number of people, including a director,
doctors, and nurses, depending on the situation. The director appears to be FDC's CEO.
Nurses assist the dentist. To represent the full hierarchy, the system constructs objects
depending on the tree's structure. As a result, Madhavi was assigned to work under the
direction of the director, Chamod was allocated to work under Supuni's supervision, and
nurses were assigned to work under each dentist's supervision. Additionally, the employees
were given their id, name, job, and salary while they were working.
In Java, different sorts of design patterns were investigated. One was deemed to be suitable
for applying the composite design pattern after analysis. A Java design solution is the
Composite Pattern. Because they specify groups of items, Composite Design patterns can
be implemented in the same way as a family tree hierarchy. As a result, in the case of a
staff hierarchy, the Composite design pattern is more suited.
After studying among the design patterns, the iterator pattern is utilized to traverse a
container and retrieve the container's elements. As a result, it is not appropriate for it. The
Observer pattern, on the other hand, provides a one-to-many relationship between objects,
ensuring that when one object changes state, all of its dependents are automatically notified
and updated. As a result, it is unable to establish an employee hierarchy. The singleton
pattern restricts the number of instances of a class to one. Because only one object is
necessary to coordinate actions across the system, it cannot be in hierarchy order.
As a result, not all patterns will be suitable for the scenario in the first second. Based on a
case study and a pattern evaluation. For the second case, the composite pattern was
determined to be an acceptable design pattern. As a result, the composite pattern designates
a group of objects. The purpose of a composite is to "compose" items into tree structures
in order to depict part-whole hierarchies relevant to scenario 2.

Development
Class Diagram for the scenario 2
Figure 100 Class Diagram for the scenario 2
The two classes are the Employees FDC class and the Employees class. The Employees
FDC class contains the main method. The Employees class has characteristics such as ld.,
Name, Position, Salary, and subordinates. Employees (), add (), remove (), get Subordinates
(), and to String () are also included (). Furthermore, the Employees FDC class and the
Employees class have an association link. This is because the Employees FDC and
Employees classes have static associations.

Development
Implementation Code
Figure 101 Scenario 2 Implementation code

Development

Development
Figure 105 Output of Scenario 2 Implementation code
Scenario 3
Iterator Design Pattern for the Scenario 3
According to the scenario, patients who require dental scans are placed in a First in First
out (FIFO) queue. They wanted us to act as if we'd found a queue container that had
previously been developed in a software library. It allows you to use traditional ways to
insert and remove data from a queue (known as Enqueue and dequeuer respectively).
However, some particular operations are required, such as search () to locate a specific
patient and show All () to display a list of all the patients in the queue. These supplementary
services are not provided by the library unit.
A queue is an abstract data structure in this technique. Both ends of the line are open. The
first is always used to input data (enqueue), whereas the second is always used to delete
data (dequeue). The FIFO (First in, First Out) principle is used by Queue, which indicates
that the data item that was stored first will be accessed first. Because the FDC stores its
patient information in a container, it may be retrieved using the queue data structure. Since
enqueue, the available dequeue functions have needed to add new functions like search ()
and show All () to locate the list of patients in queues and search for patient details.
The Iterator Design Pattern is a good fit for this case. The Iterator Pattern is one of the most
basic and extensively utilized of these. There are numerous data sets for each language. An
iterator is required for each collection in order for it to receive items. It must ensure that its
implementation is not exposed during the process. As a result, the Iterator design Pattern is
a pattern that is tied to scenarios.

Development
Class Diagram for the Scenario 3
Figure 106 Class Diagram for the Scenario 3
Three classes and two interfaces are shown in the diagram. This includes the
IteratorPatternDemo, FDCData, and Name Iterator classes, as well as the Container and
Iterator interfaces. The class FDCData has a name attribute, as well as the getlterator ()
method. The driver class is called IteratorPatternDemo. There are also the methods has
Next (), next (), and Search in the name Iterator class (). get iterator is a method in the
container interface (). The Iterator interface provides the methods has Next () and next ()
as well (). The IteratorPatternDemo class and the FDCData class are linked. The FDCData
and Name Iterator classes also have an association link. Inheritance links between the
FDCData class and the Container interface are also discussed. Inheritance exists between
the Name Iterator class and the Iterator interface.
The method has Next () is used to go through the queue to see if a patient in need of a dental
scan is available. To acquire the names of the patients in the order of queue, the method
next () is utilized. The Search () method is also used to determine whether the patient's
name is available in the scan queue.

Development
References
www.javatpoint.com. (n.d.). Abstract Factory Pattern - Javatpoint. [online] Available at:
https://www.javatpoint.com/abstract-factory-pattern.
beginnersbook.com. (2014). Abstract method in Java with examples. [online] Available at:
https://beginnersbook.com/2014/01/abstract-method-with-examples-in-java/ [Accessed 14
Feb. 2022].
beginnersbook.com. (2013). Encapsulation in Java with example. [online] Available at:
https://beginnersbook.com/2013/05/encapsulation-in-java/.
GeeksforGeeks. (2017). Abstraction in Java. [online] Available at:
https://www.geeksforgeeks.org/abstraction-in-java-2/.
www.guru99.com. (n.d.). Java Static Method, Variable and Block with Example. [online]
Available at: https://www.guru99.com/java-static-variable-methods.html.
www.javatpoint.com. (2011). Factory Method Design Pattern - Javatpoint. [online]
Available at: https://www.javatpoint.com/factory-method-design-pattern.
www.javatpoint.com. (n.d.). Prototype Design Pattern - Javatpoint. [online] Available at:
https://www.javatpoint.com/prototype-design-pattern.
www.javatpoint.com. (n.d.). Behavioral Design Patterns - Javatpoint. [online] Available at:
https://www.javatpoint.com/behavioral-design-patterns.
www.javatpoint.com. (2011). Design Patterns in Java - Javatpoint. [online] Available at:
https://www.javatpoint.com/design-patterns-in-java.
www.javatpoint.com. (n.d.). Singleton Design Patterns - Javatpoint. [online] Available at:
https://www.javatpoint.com/singleton-design-pattern-in-java.
Stack Abuse. (n.d.). Structural Design Patterns in Java. [online] Available at:
https://stackabuse.com/structural-design-patterns-in-java/.
Team, G.L. (2021). Inheritance in Java and types of Inheritance in Java. [online]
GreatLearning Blog: Free Resources what Matters to shape your Career! Available at:
https://www.mygreatlearning.com/blog/inheritance-in-java/#what-is-inheritance-in-java
[Accessed 14 Feb. 2022].
www.programiz.com. (n.d.). Java Methods (With Examples). [online] Available at:
https://www.programiz.com/java-programming/methods.
Software Testing Help. (n.d.). Java Interface and Abstract Class Tutorial With Examples.
[online] Available at: https://www.softwaretestinghelp.com/java/java-interfaces-abstract-
classes/ [Accessed 14 Feb. 2022].

Development
Study.com. (2022). [online] Available at: https://study.com/academy/lesson/methods-in-

java-definition-example.html
Study.com. (2022). [online] Available at: https://study.com/academy/lesson/static-vs-non-
static-methods-in-java.html
Ceta, N. (2018). All You Need to Know About UML Diagrams: Types and 5+... [online]
Tallyfy. Available at: https://tallyfy.com/uml-diagram/.
M. A., A.I.S. (n.d.). Aggregation in Java: Definition and Examples. [online] ThoughtCo.
Available at: https://www.thoughtco.com/aggregation-2033995.
www.tutorialspoint.com. (n.d.). What is a final method in Java? [online] Available at:
https://www.tutorialspoint.com/What-is-a-final-method-in-Java

Adv Programming

Uploaded by

Copyright:

Available Formats

Adv Programming

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adv Programming

Uploaded by

Copyright:

Available Formats

Higher Nationals

Internal verification of assessment decisions – BTEC (RQF)

Programme title HND in Computing - Application Dev / Software Eng. Pathway

Assessor K. Ushamini Internal Verifier

Unit(s) Unit 20 – Advance Programming

Student’s name Sivarasa Pakeen

INTERNAL VERIFIER CHECKLIST

Do the assessment criteria awarded match

Is the Pass/Merit/Distinction grade awarded

Assessor signature Date

Internal Verifier signature Date

Assessor signature Date

Student Name/ID Sivarasa Pakeen / PA 90546

analysing design pattern types.

LO2. Design a series of UML class diagrams

Pass, Merit & Distinction Descripts P2 M2 D2

LO3. Implement code applying design patterns

Pass, Merit & Distinction Descripts P3 M3 D3

LO4. Investigate scenarios with respect to design patterns

Grade: Assessor Signature: Date:

Grade: Assessor Signature: Date:

Signature & Date:

Formative Feedback: Assessor to Student

Feedback: Student to Assessor

Word Processing Rules

1. I know that plagiarism is a punishable offence because it constitutes theft.

Student’s Signature: Date:

Student Name /ID Number Sivarasa Pakeen / PA90546

Unit Number and Title Unit 20 – Advance Programming

Academic Year 2018/19

Unit Tutor K. Ushamini

Submission Date 14.02.2022

IV Name & Date

Emp Id Name Position Salary

For each of the above scenarios:

LO1 Examine the key components

D1 Analyse the relationship between the

LO2 Design a series of UML class diagrams

P2 Design and build class diagrams using

LO3 Implement code applying design

M3 Develop code that implements a

M4 Reconcile the most appropriate

Advantages of Object oriented Programming .................................................................. 9

Disadvantages of Object oriented Programming ........................................................... 10

Final Method .............................................................................................................. 14

Introduction to UML Diagram ........................................................................................... 33

Types of UML Diagram ................................................................................................. 33

Class Diagram ............................................................................................................ 34

UML class notation .................................................................................................... 34

Perspective of Class Diagram .................................................................................... 36

Relationships between classes ................................................................................... 37

Inheritance (or generalization) ................................................................................... 37

S. Pakeen Advance Programming Pearson No: PA 90546 Page 1 of 93

Example of Class Diagram ........................................................................................ 42

Class Diagram of Family Dental Care ....................................................................... 42

Inheritance of Class Relationships ............................................................................. 43

Interfaces designing for the Family dental Care ........................................................ 44

Object Oriented Concept for Family Dental Care System ............................................. 51

Polymorphism Code ................................................................................................... 52