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

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.

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.

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.

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

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?

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

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

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

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

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.

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

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

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.

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

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

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.

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 …

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

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

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)

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: http://software.ac.uk/resources/guides/developing-maintainable-software

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

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

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

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