1. Object-Orientated Analysis, Design and Programming
Presentation by
Dr. Phil Legg
Senior Lecturer Computer Science
2: Object and Class Design
Autumn 2016

2. Session Aims Introduce the concept of objects and classes.
Present methods for identifying classes given textual descriptions of required system functionality.
Illustrate the benefits of highly cohesive and loosely coupled classes.
Explain the UML class and object notion.
Introduce the term encapsulation and show the benefits of applying encapsulation to classes.

3. What is an Object? An object knows something – its data
An object knows how to do something – its functions
E.g. a Bank account object may know the balance of the account and provide functions to add or withdraw funds.
In object-orientated programming languages object behaviour is implemented in the form of methods.

4. Example: A “Film” class
Classes and Objects
A class is a blueprint for an object. The class defines the generic behaviour of an object and the type of data it may store
Objects that behave in a manner specified by a class are called instances of that class.
Example: A “Film” class
data could include title of the film and the certification rank Methods could be modifying certification rank
One instance of the Film class could contain details of the film “The Godfather” and another “The Dark knight”.
Each of the instances stores exactly the same type of data, film name, certification and classification yet each one represents a different film.

5. Classes and Objects Objects are instances of classes
Classes define the behaviour and the data types for an object
Values of the data held in instances of the same class will typically vary.
Instances of the same class provide exactly the same services (subject to the data not controlling the flow).

6. In-Class Activity Group discussion of Classes and Objects
-Why do we use classes and objects?
-Advantages and disadvantages of
design using classes and object?

7. StarUML design tool (other tools: ArgoUML, Visual Paradigm)
UML Notation
StarUML design tool (other tools: ArgoUML, Visual Paradigm)

8. UML Notation: Class Every class must have a name, e.g. Student
An attribute (data) is a named property of a class that describes a range of values that instances of the property may hold, e.g. every customer has a name and an address.
An operation is an implementation of a service that can be requested from any object of the class to affect behaviour, e.g. setName

9. Identifying Classes
So where & how do I find my classes, i.e. the classes that relate to my design problem?
Two design techniques:
Textual analysis of use case
Class responsibilties

10. Textual analysis of use cases
Analyse Nouns (in use cases etc.)
Cluster classes from objects
Whole object / component parts
Reject synonyms
Evaluate scope

11. CRC Process Classes, Responsibilities and Collaborations
Once you have a reasonable list of candidate classes in your OO design you can further evaluate their place in a particular system by identifying their responsibilities
what do they need to know
what they do, and
who they need to work with to do this – their collaborations.
The process is referred to as the Classes Responsibilities and Collaborations process or more commonly as the CRC process.

12. CRC Process
Write the names of all candidate classes on a series of cards.
Work through the textual narrative of the system requirements, i.e. the use case descriptions assigning responsibilities to classes, e.g. determining doing something, knowing something and decision making.
Classes that have no responsibilities can be removed because they do not add value to the system

13. Design Quality
Design quality is an elusive concept. Quality depends on specific organisational priorities
A 'good' design may be the most efficient, the cheapest, the most reliable, the most maintainable, etc.
We will focus on the maintainability of the design

14. Maintainability
According to IEEE Standard Glossary of Software Engineering Terminology  maintainability is defined as:
"The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment."
The maintainability of software depends on a few different factors. In general, it must be easy to
understand the software (how it works, what it does, and why it does it the way it does),
easy to find what needs to be change,
easy to make changes and
easy to check that the changes have not introduced any bugs.

15. Designing for Maintainability
Design Criteria Design for maintainability from the outset:
Cohesion
Loose Coupling
Understandable
Adaptability

16. Encapsulation
Encapsulation refers to the process of an object controlling outside access to its internal data.
Client only knows how to call the methods, not how the methods are implemented.
Data attributes are made private, i.e. protected from being directly accessed from outside
Visible methods (services) are made public

17. Encapsulation
The main benefit of encapsulation is that the programmer may change the implementation of the object without affecting the whole program, if he or she preserves the interface of the object.
Any change of the data representation will affect only the implementation of the methods.
By keeping data private and providing public well-defined service methods the role of the object becomes clear to other objects. This increases usability.

18. Cohesion A measure of how well a component 'fits together’
A component should implement a single logical entity or function
Cohesion is a desirable design component property as when a change has to be made, it is localised in a single cohesive component …

19. Coupling and Dependency
A measure of the strength of the inter-connections between system components
Loose coupling means component changes are unlikely to affect other components
Shared variables or control information exchange lead to tight coupling
Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing
Avoid placing too many responsibilities with a single object.
Create object that knows how to do one task and they are able to do that task well

20. Understandability Related to several component characteristics
Cohesion. Can the component be understood on its own?
Naming. Are meaningful names used?
Documentation. Is the design well-documented?
For each class
For each method

21. Adaptability A design is adaptable if:
Its components are loosely coupled
It is well-documented and the documentation is up to date
There is an obvious correspondence between design levels (design visibility)
Each component is a self-contained entity (highly cohesive)

22. Maintainability Checklist
Answering the following questions will help you judge the maintainability of your software:
Can I find the code that is related to a specific problem or change?
Can I understand the code? Can I explain the rationale behind it to someone else?
Is it easy to change the code? Is it easy for me to determine what I need to change as a consequence? Are the number and magnitude of such knock-on changes small?
Can I quickly verify a change (preferably in isolation)?
Can I make a change with only a low risk of breaking existing features?
If I do break something, is it quick and easy to detect and diagnose the problem?
Ref:

23. Top 10 OO Design Principles
DRY (Don't Repeat Yourself) - avoid duplication in code.
Encapsulate what changes - hide implementation detail, help maintenance
Open Closed design principle - open for extension, closed for modification
SRP (Single Responsibility Principle) - one class should do one thing and do it well
DIP (Dependency Inversion Principle) - don't ask, let framework give to you

24. Top 10 OO Design Principles
Favour Composition over Inheritance - code reuse without cost of inflexibility
LSP (Liskov Substitution Principle) - sub type must be substitutable for super type
ISP (Interface Segregation Principle) - avoid monolithic interface, reduce pain on client side
Programming for interface - help maintenance, improve flexibility
Delegation principle - don't do all things by yourself, delegate it

25. Recap
Classes exist in code and are the blueprints used to create objects
Objects are instances of classes and exist at runtime
Encapsulation is achieved by making data private and services public
We seek to develop classes that are highly cohesive and loosely coupled

26. In-Class Activity Using the UWEfilm case study from last week
- Identify candidate classes
- Identify significant attributes for your classes
Create a class diagram in a UML modelling tool
Group discussion on the design process
of a class diagram