Object Oriented Analysis And Design

http://burks.bton.ac.uk/burks/pcinfo/progdocs/oocourse/ooc/obj14/lesson14.htm Object oriented analysis and design Object modelling is useful for designing computer systems, whether those systems are to be implemented in object-oriented languages or not. Most designs are likely to need more than an object-oriented language, such as a database. Object modelling also has a use outside of the design of computer systems. It is an excellent analysis method, and it can be used in business process reengineering, in social science research, or any complex environment where it is important to capture the structure and functionality of some world.

Why Design? Even the most professional programmers feel the temptation to sit down and produce code at the earliest possible moment. Therein lie many of the ills of the software engineering industry. Design is a process which involves • • • •

communication creativity negotiation agreement

It is a human process, to produce products for human consumption. Too often the communication, negotiation and agreement aspects are left out. Object modelling provides a notation which is clear, consistent, and which can be used to communicate within a software development team, and with the clients and other thirdparties which the team need to deal with.

Design methods Traditionally systems were constructed using the waterfall method. This was based on the idea that clients would formally agree a requirements document. A design would then be put together, which would be further agreed. Then the system would be implemented, and then there would be an endless process of maintenance. Modern ideas move away from this. Iterative methods are considered more appropriate for many system development approaches. This still follows the notion of analysis, design and implementation, but on a cyclical basis, where subsequent cycles build on earlier cycles.

Objects

We begin at the beginning. The world is made of objects. Just open your eyes and ears. They are out there. Bank customers, students, cats, elephants, cars, balls of string, atoms, molecules, tubs of ice cream, Madonna, stars, bureaucrats, Robin Hood. The world is built of objects. Objects are built of smaller objects, and so ad infinitum. Objects combine to make bigger objects. We already live in an object-oriented world. The first thing an object analyst must do is to remove the scales from his or her eyes. Object modelling consists of looking for objects. Of course, there has to be some boundary. Even sitting at ones desk one can see more objects than one could reasonably list. But that is where the beauty of object modelling comes in. It uses observation. Objects can be described by their attributes and operations. Attributes are the changeable characteristics of an object. Cats have colour, size and weight. Operations are the things an object does or can have done to it. Cats can catch mice, eat, miaow, worm up to owners, and be stroked. In our notation we draw an object such as a cat like this.

The name is shown at the top. The attributes are listed underneath. The operations are listed below that. Actually, strictly speaking, this is a class diagram. But we will explain that later. In an object model, all data is stored as attributes of some object. The attributes of an object are manipulated by the operations. The only way of getting at the attributes is through an operation. Attributes may sometimes be objects in their own right (more of that later). In an object model, all functionality is defined by operations. Objects may use each others operations, but the only legal way one object can manipulate another object is through an operation. An operation may inform, say "mass of ball", or change the state of an object, say "throw ball". Object modelling is about finding objects, their attributes and their operations, and tying them together in an object model. Nothing more. Here are some more objects:

Do not be constrained to be those dull systems that most software engineers drag out. Object modelling can be used to design lots of things. The trick comes in knowing what objects are appropriate, and what their appropriate attributes and operations are. Remember entity-relationship models having a notion of entity. These are really objects. All we are doing in object modelling is relabelling entity modelling. However, we put the emphasis on capturing and grouping together both functions and data (operations and attributes in our terminology). That is the elegant simplicity of object modelling. object models look remarkably like entity-relationship models. We will now look one powerful way of arranging objects - inheritance hierarchies.

Inheritance Often we will find that there are objects which have something in common. It is then useful to create an abstract object which groups together the common features, and to use inheritance to define the original objects.

Designing complex class hierarchies takes time and good design requires experience. But the basic principles outlined above, with some intuitive guidelines, are the basis for the design of good, re-usable designs. Re-use can be viewed from two directions. Components can be re-used, which is a sort of bottom-up approach to re-use. Or designs can be re-used. Both elements are important in the production of re-usable software. Experience shows that describing things using hierarchies is an easy and comprehensive way of communicating both structure and functionality.

Relationships and Object Models

Aggregation We can make up objects our of other objects. This is known as aggregation. The behaviour of the bigger object is defined by the behaviour of its component parts, separately and in conjunction with each other. Here is a simple example of a juggler:

A juggler has two hands and two feet. He or she uses hands to catch, drop, pick up and throw a ball, and perhaps from time to time scratch his or her head. He or she may also kick a ball with his or her foot. By analysing our juggler object and breaking it down into component objects, we now have a better understanding of our object. The diamond in the diagram indicates that one object is made up of another object. The numbers are indicative of how many. Now the behaviour of a juggler is entirely defined by the behaviour of his or her hands and feet. Of course, real jugglers are made of quite a bit more, but for the purposes of considering their juggling skills we can focus on just the bits of them that are involved in juggling. Hands and feet could be broken down into their constituent parts, say palms and fingers, soles and toes. However, that does not seem to help us to understand juggling, so the decomposition above is probably enough. One of the important analysis and design tools we have is the break-down of complex objects into their constituent parts. It provides a meaningful and sensible decomposition, and it provides scope for re-use of components. Further, the constituent components are often easier to design than large, complex components - this is the thesis on which the early ideas of structured programming were based.

Delegation The behaviour of an object which is made up of other objects is usually defined by the behaviour of the smaller objects. For example

To start a car, you start the engine. Thus the start operation on the car involves calling the start operation on the engine. This is known as delegation. The engine then will switch on the ignition system, switch on the starter motor then switch off the starter motor. This is further delegation. To stop the car, there will be a call to stop the engine, which in turn will make a further call to switch off the ignition. You may read elsewhere about the benefits of multiple inheritance. Most of the features of multiple inheritance can be simulated using delegation, with safer consequences.

Relationships Objects can be related in other ways than by inheritance and aggregation. Any relationship between real world objects can be modelled: cats eat canaries, dogs bite postmen, the woodcutter murders the wolf, cars run over little old ladies, employees work for organisations, patients visit hospitals, patients stay in hospitals.

One to one relationships In a one-to-one relationship, one object is associated with exactly one of its related objects. This is modelled by a straight line drawn between the objects. If the relationship is one-way, then an arrow is used to indicate the direction. The line can be labelled.

One to many relationships Sometimes one object can be related to many objects. This is indicated by different marks at the end of the line.

A player plays for one football team. There are at least 11 players for a given football team. Football teams do not play for players.

Many to many relationships Sometimes objects at either end of a relationship may be related to many objects at the other end.

A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.

Analysis - the rudiments of an approach The first reaction to any project with any complexity is "how do we get started?". Where do you begin? The starting point for object-oriented analysis is to identify candidate objects and their relationships. In fact, this is the be-all and end-all of object-oriented analysis. The first stage can be a simple brain-storming of the possible objects. One method is to go through all the nouns in any documentation about the world you are analysing, and considering these as candidate objects

Removing synonyms and/or generalising The first stage is to try and group together items which are either just different names for the same thing, or whether there is a common generalisation

Look for attributes Attributes are themselves objects, but with trivial behaviour - essentially all you do is record their value. Considering the above list

Irrelevant objects Sometimes an object is irrelevant because of what you are designing the system for.

The process of development The approach to development recommended here is an iterative one. It involves repeated refinement of the object model. The process needs to be controlled by an appropriate project management process, involving reviews and checkpointing.

There are a variety of techniques for driving this cycle. Prototyping Evolutionary development

Why object modelling lends itself to iterative methods The problem with traditional systems developments has been that notations differ in each of the phases of development. There is then a translation problem and consistency problem at each phase transition. Consequently changes upstream have always been resisted. Object modelling uses the same notation for both analysis and design, and if objectoriented languages and databases are used, the notation persists through to implementation. Design is essentially a fleshing out of the analysis, by further refining and adding detail to the objects produced by the analysis, and by adding new objects, say for the purposes of providing interfaces. Object modelling, by using a consistent notation in each phase, results in more productive CASE tools, which can generate the code outlines for the implementation.

Dynamic Modelling Dynamic modelling tries to capture how objects behave and how they interact. In this way, we can find new operations, attributes and relationships for the object model. Dynamic models are perhaps the most effective way of uncovering the behaviour of systems.

Event traces - building scenarios As we were going to tread dynamic modelling as a form of plot construction for stories, let us begin by looking at a trace of events

Progressing the analysis with event traces At first it can be a little disconcerting to approach problem-solving in this way. Where is the flow of control? This seems too simple. The answer is that we eat a banquet one mouthful at a time. We climb mountains one step at a time. Great floods arrive in raindrops. There is no wisdom in trying to do everything at once.

What do you do with the event traces? As you develop an event trace you will find the following: • • •

There are objects missing from your object model - so add them. There are operations missing from your object model - so add them There may be attributes you have overlooked - so add them

•

Perhaps there are objects and operations which you thought at first were appropriate, but now look unused - so remove them.

This follows the philosophy that everything in object modelling is to do with expanding the object model.

Dynamic modelling - state diagrams

Initial states are represented by a black blob. Intermediate states are represented by round-cornered boxes. Final states are represented by bulls-eyes. Events are represented by arrows with labels giving a name. An event usually corresponds to an operation in the object model. Basically any system which you can reasonably model on a computer jumps from state to state. Even those apparently continuous games are made up of objects which change their state very quickly.

An example of an object model for a simple computer Let us look at the example of designing a computer. Of course, one is unlikely to be asked to design a computer this way, but it is an interesting way of exploring the method so far using a relatively complicated application that computer scientists are familiar with. Our first notions of a computer might be:

Object Modelling with Activity Models Activities are logically arranged groups of events. Dynamic modelling, through event traces, is one way of linking events to objects, thereby defining object behaviour and identifying new objects. Activities can be used in a similar way to identify operations on objects. This can be done by simply producing a matrix; a simplified example from the PLANEC application is illustrated below. This is for the ARRANGE RESOURCES activity. PROVIDER, FUNDER and RESOURCE are three of the candidate objects for the PLANEC system.

A similar cross-referencing process can be used to identify attributes.

Functional modelling - data flows Data flow modelling is a common component of many software engineering methodologies in. It is exceptionally useful for analysing and describing systems where there is a large amount of calculation

involved. However within the object modelling community it seems to be losing ground in favour of other techniques - object interaction diagrams can cover most of the needs met by data flow diagrams. They tend to be less effective and more arbitrary in producing designs. They are included here for completeness. Data flow models consist a of a number of processes which exchange information. A process transforms information it receives and passes the transformed information on to other processes or to objects in the system. Data flow models can be used to uncover new operations and new attributes for the object model. Sometimes new objects can be discovered too. Processes are drawn as bubbles, with the name of the process written inside. Arrowhead lines are used to connect processes to each other and to objects in the system. The lines are labelled with the information that is being passed. Objects are drawn as rectangular boxes, just as in the object model, but usually with just the name of these objects and not the attributes and operations. Let us look at a simple example.

The next stage is to devise operations and attributes to support the calculations. From the above we can probably deduce the following attributes and operations for the Customer, Invoice, Sales and Product objects - of course there will be more attributes and operations derived from other techniques or other data flow diagrams.

Use Cases One of the most fundamental problems in software engineering is determining the requirements of a system. The notion of use-cases, introduced by Jacobson is an excellent approach. It complements the activity modelling approach developed by Lunn described earlier in the course, and has wider application. The use-case approach requires the analyst to determine all the potential actors involved in a system. Actors are external to the system and make use of it. An actor is typically a

person, but may be a third-party organisation or another computer system. One person may in fact be multiple actors, say a shop assistant may be a customer of the same shop at another time. We model actors, not individuals. An actor makes use of a system in different ways. Each of these ways is known as a usecase. A use-case may involve a number of actors, just as an individual actor may make use of several use-cases. We draw little stick men to represent actors and ovals to represent use-cases. In a banking system where a customer can withdraw money, we would draw:

Of course, to withdraw money, a customer must have put money in, so there is at least one more use-case.

Now it might be that the system which is being implemented in the bank needs to involve a cashier for depositing, but that to withdraw money the customer has to use the cash machine. The cashier is then an actor.

And so we build our model of the ways the system is used. We might add two more usecases of the bank system. Here is a simple use-case model for a computer:

Programmers are distinguished from ordinary users of the computer by the fact that they compile and edit programs as well as running them (for testing) and printing files. Edit and compile use-cases make use of the run-program use case (editors and compilers being just programs to be run). Use-cases are simple to describe to potential users of the system, and therefore should be used in the dialogue as part of requirements analysis.