This document discusses class diagrams and their use in modeling object-oriented programs. Class diagrams visually represent the relationships between classes, including composition, aggregation, and inheritance. They can reveal high coupling between classes and low cohesion within classes, both of which make programs harder to maintain and change. The document recommends aiming for high cohesion and low coupling in object-oriented design.

1. MODELING AN OBJECT
ORIENTED PROGRAM
Michael Heron

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

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

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

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

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

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

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

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

10. Class Diagrams
• At their simplest, class diagrams are just boxes with lines
connecting them to other boxes.
• They show the relationship between classes only.

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

12. Class Diagram with Attributes

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

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

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

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

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

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

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

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

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

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

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

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

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

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