Lecture 4 – Part 1

Object Oriented Programming

OOD&A in Focus
The Design and Development Process

Unit Coordinator: Dr. Andreas Shepley

This unit was designed and developed by Dr. Andreas Shepley
This lecture will cover…

• The design process – 5 core principles of OOD&A

• Functionality – solve the problem!
• Robustness – toughen up your code!
• Flexibility – how easy is it to make changes?
• Reusability – minimize repetition
• Extendibility – frameworks by architects
• Functionality
• Use cases
• Requirements list
• UML diagrams
OO Design and Analysis
Five core principles
• OO Programming is all about creating good software.
• To create good software it must be functional, robust, flexible,
reusable and extendible.
• Functional software is software that does what it is meant to.
• Robust software works in the real world. It is able to handle
misuse, not just the best-case scenario!
• Flexible software is easy to change, maintain and adapt to meet
an ever-changing world.
• Reusable software minimizes repetition, saving time and money
and reducing the development time.
• Extendible software is so well designed that it can be used as a
framework to solve all sorts of problems. Frameworks are
designed by architects (they are the top-dogs who earn the big
bucks!)
Functionality
Solve the problem!
• The first step in writing good software is to ensure that your program
achieves its goal.
• It MUST solve the problem it is meant to solve.
• To do this, it is important to:
• Fully understand the problem you’re solving AND
• Figure out what you need to do BEFORE you figure out how
you will do it.
• A program exists within a system.
• A system is made up of all the components of a program, as well as
the data it collects and interacts with, and any hardware.
• Users are outside the system – they interact with the system.
• It is important to understand what the system does to understand
what you need to code.
Functionality
Use cases
• A use case describes what the system does: the steps that a
system takes to achieve a goal or perform a task.
• A use case must be value-adding, i.e., the outcome/goal must be
important.
• A use case should have a clear beginning and be externally
initiated, e.g., a user does something.
• A use case should have a clear end, i.e., it must be clear that a
process is complete.
• Create one use case for each goal - a use case can have alternative
paths/scenarios, but they must reach the same goal.
• Each use case should outline a sequence of events that reveals how
users and/or data and/or hardware interact with the system.
• Use cases are very useful when designing a requirements list.
Functionality
Use cases – for less technical audience
Example: Greek Geek reaches out to you, with the following message:

“Hi, I’m after someone who can create an app for me. As a proud,
introverted geek, I’m well acquainted with the challenges that the geek
community face when it comes to connecting with like-minded geeks and I
want to change that! I have in mind an app that allows geeks to provide key
info about themselves, e.g., what makes them a geek, their favourite
computer games, as well as the obvious, e.g., age, gender, etc.. The app
should consider which geeks best suit each other (of course, allow the user
to express their preferences!) It should then provide the geek with contact
details so they can reach out to their potential match. I want it to be a safe,
fun app to use, where geeks have a lot of control over how they interact
with other geeks.”

Let’s see how many use cases we can identify?

Functionality
Identifying use cases
“Hi, I’m after someone who can create an app for me. As a proud,
introverted geek, I’m well acquainted with the challenges that the geek
community face when it comes to connecting with like-minded geeks
and I want to change that! I have in mind an app that allows geeks to
provide key info about themselves, e.g., what makes them a geek,
favourite computer games, as well as the obvious, e.g., age, gender,
etc.. The app should consider which geeks best suit each other (of
course, allow the user to express their preferences!) It should then
provide the geek with contact details so they can reach out to their
potential match. I want it to be a safe, fun app to use, where geeks
have a lot of control over how they interact with other geeks.”

This message appears to suggest 3 main scenarios 1) a geek adds their

info to a database 2) a geek searches for a compatible geek and 3) a geek
blocks another geek with whom they don’t want contact.
Functionality: Use cases
Use case #1
A geek adds their info to the database so other geeks can find them
1. Geek opens app (external initiator = a geek).
2. App asks whether the geek wants to 1) add info to database OR 2)
search for a compatible geek 3) OR block a geek.
3. Geek chooses to add their info to the database.
4. Program prompts the geek to input the following:
1. A unique username.
2. Personal information including name, age, gender, star sign.
3. Their phone number.
4. A statement about what makes them a geek.
5. A list of favourite computer games.
5. Program writes geek info to the database.
6. Set up is complete – program outputs confirmation message (clear
end).
Functionality: Use cases
Use case #2
A geek searches for a compatible geek
1. Geek opens app.
2. App asks whether the geek wants to 1) add info to database OR 2) search for a
compatible geek 3) OR block a geek.
3. Geek chooses to search for a compatible geek.
4. Program requests user input preferences including preferred age, gender, star
sign, and favourite games.
5. Geek inputs relevant information.
6. Program searches the database for a compatible geek.
7. Program finds a suitable geek match or terminates if none found.
8. Program asks the geek if they want to contact their potential match.
9. Alternative 1: Geek affirms:
1. Program provides potential match’s contact details.
9. Alternative 2: Geek declines:
9. Program outputs message confirming decline and exits.
Functionality
Use case #3
A geek wants to block another geek
1. Geek opens app.
2. App asks whether the geek wants to 1) add info to database OR 2) search for a
compatible geek 3) OR block a geek.
3. Geek chooses to block a geek.
4. Program asks for the geek’s username.
5. Geek inputs their own username.
6. Alternative 1: Geek’s username not found.
1. Program outputs message instructing the geek to register – go back to step 1.
6. Alternative 2: Geek’s username found.
1. Program asks for target geek’s username.
7. Alternative 1: Geek provides invalid geek username.
1. Program searches for geek – target geek not in database.
8. Alternative 2: Geek provides valid target geek username.
1. Program adds target geek to the geek user’s set of blocked geeks.
9. Program outputs confirmation message: target geek blocked OR geek not found.
Functionality
Requirements list – for a more technical audience

• Given a description of a problem, and a set of use cases, you’re

ready to write a requirements list.
• A requirement is a specific need that indicates what a component of
a system should do.
• To create a good requirements list, ensure that you understand why
the program is needed, and how it will be used.
• Anticipate requirements by anticipating problems.
• Requirements must handle alternate paths.
• Requirements can be tested to ensure that the program solves the
problem.
• A requirements list is very useful when communicating your
understanding of what the program is meant to be doing.
Functionality
Writing a requirements list
Requirements List
1. A geek must be able to add their information to a database.
2. They must create a unique username and provide their 1) name 2) age, 3)
gender, 4) favourite games and 5) a statement on what makes them a
geek.
3. The geek must provide their phone number to enable contact with other
geeks.
4. A geek must be able to set preferences for their geek-search and be
suggested a suitable geek.
5. A geek must be able to block another geek to prevent unwanted contact
and to prevent an unwanted geek from being suggested as compatible.
6. A geek must be able to contact another geek if that geek comes up as
compatible.
Functionality
Designing the program
1. Once you have a list of requirements you can start designing the program
2. We can see that we need a Geek class to contain all the geek attributes
(e.g., name, age, star sign, etc.), as well as methods to access and change
those attributes.
3. It might also be good have an AllGeeks class, to contain the dataset of
Geeks, and useful methods, e.g., searching for a compatible Geek.
4. We also need another class, SeekAGeek, where our main method will be.
Here, we’ll interact with the program user, and create instances of the
Geek and AllGeek classes.
5. A useful way to represent classes is by using UML diagrams, which show
the class name, attributes, and methods.
Functionality: UML Diagrams
Geek AllGeeks
username: String geeks: Map<String,Geek>
name: String
gender: String addGeek(Geek)
age: int getGeek(): Geek
phoneNumber: long findDreamGeek(Geek): Geek
starSign: String
statement: String
favouriteGames: Set<String> SeekAGeek
blockedGeeks: Set<String>
filePath: String
getUsername(): String allGeeks: AllGeeks
getName(): String
main(String[ ] args)
getAge(): int
loadGeeks(): AllGeeks
getGender(): String
getPhoneNumber(): long signUp(): Geek
getStarSign(): String addGeekToFile(Geek)
getStatement(): String checkUsernameExists(String): Boolean
getFavouriteGames(): Set searchForGeek()
getBlockedGeeks(): Set blockAGeek()
blockGeek(Geek) addGeekToBlockedListOnFile(Geek)

See examples: Geek.java, AllGeeks.java and SeekAGeek.java

Happy coding! ☺