Download to read offline
Uploaded byMichael Heron
2CPP05 - Modelling an Object Oriented Program
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.
More Related Content
Similar to 2CPP05 - Modelling an Object Oriented Program
2CPP05 - Modelling an Object Oriented Program
- 1. MODELING AN OBJECT ORIENTEDPROGRAM Michael Heron
- 2. Introduction • In thislecture 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 • Oneof 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 • Youwon’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 • Objectscan 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 • Anobject 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 • Attheir simplest, class diagrams are just boxes with lines connecting them to other boxes. • They show the relationship between classes only.
- 11. Class Diagrams • Atthe 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 withAttributes
- 13. Why Use AClass 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 relatesto 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 yourprogram 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 areseveral 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 isthe 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 dangersthat 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 ofOO 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 diagramsare 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.