MODELING AN OBJECT
• 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
• For our purpose, we are going to discuss only one part of
• The Class Diagram
• One of the reasons why software development has such a
complex vocabulary of jargon is the need for experts to
• 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.
• You won’t be expected during this module to be able to
break complex problems down into objects and classes of
• 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
• 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
• 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
• 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
• 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.
• 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’
• 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.
• At their simplest, class diagrams are just boxes with lines
connecting them to other boxes.
• They show the relationship between classes only.
• 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.
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 relates to the amount of interconnectedness of
• We want this to be as low as is reasonably possible.
• A coupling relationship is any composition, aggregation, or
• The more connections made between objects and classes, the
harder it is to make any changes.
• Because of the knock-on effect associated.
• 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.
• 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
• This is terrible and should be avoided always.
• Data coupling is when a public interface is used to exchange to
• This is better.
• There are other kinds.
• We don’t have to go into them to any great degree for now.
• 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.
• 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
• It is a consequence of badly analysed and badly designed
• You’ll learn how to do this properly in third year.
The Tension of OO Development
• Object Oriented programs are a tension between coupling
• 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
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
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
• 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.
• Class diagrams are a useful shorthand notation for
• 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.