2CPP05 - Modelling an Object Oriented Program

MODELING AN OBJECT ORIENTED PROGRAMMichael Heron

Introduction• In this lecture we are going to take a little detour into the

world of UML.• A small detour, to support us in later weeks.

• UML is a language of diagrams and syntax designed to communicate the intention and design of object oriented programs.

• For our purpose, we are going to discuss only one part of it.• The Class Diagram

Class Diagrams• One of the reasons why software development has such a

complex vocabulary of jargon is the need for experts to communicate succinctly.• This is what all formal software design techniques are about.

• It is extremely useful when we talk about the design of objects for us to have some kind of shared vocabulary.• Hence the introduction of this diagram.

Class Diagrams• You won’t be expected during this module to be able to

break complex problems down into objects and classes of your own.• You’ll learn more about that in third year.

• All I would like of you with relation to class diagrams is that you can read them and interpret them.• And at a push, write up your own.

Object Oriented Programs• Object oriented programs introduce new complexities of

interaction.• Objects have a relationship to classes.• Objects may be composed of other objects.• Objects define their own behaviours and attributes.• Objects can offer several levels of indirection to other objects.

• Gaining a clear perspective on how an object oriented program fits together is key to developing and maintaining OO code.

Object Relationships• Objects can contain references to other objects.

• This is known as composition.• This is a has a relationship.

• Composition relationships also imply a multiplicity (or cardinality).• Where there is a 0 or 1 relationship, it is known as a composition.• Where it is more, it is an aggregation.

• Formal UML notations have more precise differentiations of composition.

Object Relationships• An object may be a specialisation of another object.

• This is known as inheritance in object orientation.• This is a is a relationship.

• More specialised forms of inheritance exist.• We’ll talk about these as we go along.

• For now, we will look only at the case that a class can inherit the properties of another in their entirety.

Examples• A Car:

• Has an engine (composition)• Has four wheels (aggregation)• Has 2 or more doors (aggregation)• Is a vehicle (inheritance)

• A Cat:• Has four legs (aggregation)• Is an animal (inheritance)• Has a tail (composition)

Object Oriented Programs• The relationship between objects and classes becomes

very complex in many computer programs.• Some means of representing this complexity ‘at a glance’

is useful.• This is what a class diagram is used for.• It gives the static view of a program’s architecture.

• Other techniques exist too.• They vary in effectiveness.

Class Diagrams• At their simplest, class diagrams are just boxes with lines

connecting them to other boxes.• They show the relationship between classes only.

Class Diagrams• At the next level of usefulness, class diagrams also

contain information about attributes and methods.• Attributes in the second row• Methods in the third

• At their best, class diagrams contain class relationships, methods, attributes, and the visibility of each.• They also explicitly show multiplicity.

Class Diagram with Attributes

Why Use A Class Diagram?• There are several reasons why usig a class diagram leads

to a more complete view of a project.• It shows the relationship between classes in a way that allows you

to trace accessibility.• It shows at a glance the amount of coupling in a project.• It shows at a glance the amount of cohesion in a project.• It shows at a glance the impact of change.

Coupling and Cohesion• One of the biggest problems OO developers have is

ensuring a good OO design.• What is a good OO design, you ask?

• Certainly for people unfamiliar with how OO is best done, it’s hard to objectively rate an object architecture.

• Two objective measures exist for this though.• As a rule, we are aiming for high cohesion and low

coupling.

Coupling• Coupling relates to the amount of interconnectedness of

classes.• We want this to be as low as is reasonably possible.

• A coupling relationship is any composition, aggregation, or inheritance.

• The more connections made between objects and classes, the harder it is to make any changes.• Because of the knock-on effect associated.

Coupling• If your program has high coupling, there are several

disadvantages built in:• Changes in one object may result in unexpected side-effects

elsewhere in a program.• Often the cause is not at all obvious.

• Classes are difficult to understand at a glance.• They make use of so much external functionality.

• Classes are difficult to test.• They cannot be easily extracted from their context.

Coupling• There are several types of coupling that exist.

• It’s not just the amount of coupling that matters, but also the type of coupling.

• Content coupling is when one class directly accesses data local to another class.• This is terrible and should be avoided always.

• Data coupling is when a public interface is used to exchange to exchange parameters.• This is better.

• There are other kinds.• We don’t have to go into them to any great degree for now.

Cohesion• Cohesion is the level to which an object adheres to a

single set of responsibilities.• We want this as high as is reasonably possible.

• In a good object oriented program, each object has one firmly defined responsibility.• If you have a BankBalance class, it should contain only the

functionality for manipulating the balance.• It should not contain, for example, the address of its owner.

Cohesion• The dangers that come from low cohesion are the same

as that of high coupling.• They’re really just two ways of reflecting the same basic concept.

• Low cohesion is an insidious problem.• Programs with low cohesion tend to become even less coherent

over time.

• It is a consequence of badly analysed and badly designed programs.• You’ll learn how to do this properly in third year.

The Tension of OO Development• Object Oriented programs are a tension between coupling

and cohesion.• We increase cohesion by increasing coupling.• We reduce coupling by decreasing cohesion.

• As OO developers we have to find a happy medium between the two.• In some cases, simple rationalisation of a design can remove

problems.

Impact of Change• Both of these concepts are a way of objectively rating the

impact of change in a program.• What makes a program easy to work with?

• Clearly written code.• Comments (seriously)• Changes do not have unexpected consequences.

• The latter of these three is what the impact of change defines.

Impact of Change• One of the reasons we restrict visibility of variables and

methods is to manage the impact of change.• If you are a Respectful Developer, you avoid making changes that

will impact on code you did not write.• Lest terrible vengeance be visited upon you and your kith and kin

• The lower the visibility, the better.• Changing a private variable for example only impacts the class in

which it is defined.

Impact of Change• In a multi-developer environment you have to assume that

if functionality is available, it has been used.• Someone saw your calculate_awesome() method and thought ‘hey,

that does exactly what I want’

• If it can be used, you can’t idly make structural changes.• Refactoring is fine• Redesign is not

The Class Diagram• The best quality of class diagrams shows the impact of

change at a glance.• Where there are lots of arrows, there be coupling issues.• Where there are huge lists of methods and attributes in a class,

there be likely cohesion problems.• Where there are lots of public methods and attributes, there be

likely impact of change issues.

The Class Diagram• In multi-developer projects, the class diagram represents

the ‘best understanding’ of how a program is being developed.• It’s kind of an informal contract with your fellow developers.

• One of the benefits we get from object orientation is an easy of development and integration.• But only if everyone is communicating effectively.

Summary• Class diagrams are a useful shorthand notation for

classes.• I tell you about them so you’ll know them when you see them.

• In addition, they help visualize certain structural problems in object oriented program.• Seeing the problems is the first step in resolving them of course.