2CPP05 - Modelling an Object Oriented Program


Published on

This is an intermediate conversion course for C++, suitable for second year computing students who may have learned Java or another language in first year.

Published in: Software, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2CPP05 - Modelling an Object Oriented Program

  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Class Diagram with Attributes
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.