Wednesday 12 September 2012
OOAD
Object-oriented analysis and design (OOAD)
Objects and inheritance
Introduction:
Welcome to the world of object-oriented programming. You are about to embark on learning a method which is fun, elegant, easy to understand, powerful and comprehensive.
The intention of this course is to emphasise the fun as much, if not more, than the other characteristics. After all, what is the point of learning something to make life duller.
So if we sometimes see examples which appear off the wall, do not worry. There is a serious side to object-oriented systems too.
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. Therefore, do not think that this is a wasted exercise if you cannot convince your manager to let you use C++, Smalltalk or whatever flavour of the month language is out there.
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 third-parties 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. There are variants on this, and we will discuss later how to drive and control this process.
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 my desk I can see more objects than I 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, weight and a preference for either Kit-E-Kat or Whiskers.
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:
Some of these objects may seem jokey, but they could reasonably be part of a system, be it a computer game or a multimedia story. 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.
By now you should be getting the idea that object modelling is, at its simplest level, very straightforward. The trick comes in knowing what objects are appropriate, and what their appropriate attributes and operations are. It is a question of focus. We will consider some ways of controlling focus later in the course.
How do objects relate to other concepts in design methods?
Remember entity-relationship models? SSADM, JSD and so on have 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. We will look at object models later which look remarkably like entity-relationship models (because they are).
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. For example, consider our two fairy story creatures:
Now we can see that they both have the same operations "arrive" and "meet". We can therefore create an abstract creature:
which has the common operations. We can then draw the original objects grouped under the abstract object as follows
By this device Red Riding Hood has also appetite, nose and teeth as operations. The latter two may be of relevance when she goes to charm the woodcutter, provided they are petite and pearly bright respectively.
Okay, so let's have some more practical examples for those of you who have to do real work. Firstly, the frighteningly dull student-lecturer example. You can do the same with the equally dull employee-customer example.
Inheritance can pass down an arbitrarily deep hierarchy. A slightly more complicated hierarchy is given below to describe objects which can be juggled.
The big deal about inheritance
Inheritance is considered good for the software re-use and for clarity of description.
Re-use
When new objects are created which are similar to other objects, they can have many of their attributes and operations ready defined. Let us suppose we now introduce Grandma into our fairystory hierarchy.
Here we get a Grandma who already had an appetite, nose and teeth and who can arrive and meet. Actually these are not in the normal scope of the fairy story, but the principle should be clear.
We might be writing a simple geometry program:
Now to add circles we simply put in another object under 2D shape.
So the circle object need not define the area and position attributes or the get area operation.
It is now possible to buy or obtain ready-built class hierarchies written in object-oriented languages which can be extended in this way to produce a new application.
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.
Objects and inheritance
Introduction:
Welcome to the world of object-oriented programming. You are about to embark on learning a method which is fun, elegant, easy to understand, powerful and comprehensive.
The intention of this course is to emphasise the fun as much, if not more, than the other characteristics. After all, what is the point of learning something to make life duller.
So if we sometimes see examples which appear off the wall, do not worry. There is a serious side to object-oriented systems too.
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. Therefore, do not think that this is a wasted exercise if you cannot convince your manager to let you use C++, Smalltalk or whatever flavour of the month language is out there.
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 third-parties 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. There are variants on this, and we will discuss later how to drive and control this process.
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 my desk I can see more objects than I 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, weight and a preference for either Kit-E-Kat or Whiskers.
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:
Some of these objects may seem jokey, but they could reasonably be part of a system, be it a computer game or a multimedia story. 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.
By now you should be getting the idea that object modelling is, at its simplest level, very straightforward. The trick comes in knowing what objects are appropriate, and what their appropriate attributes and operations are. It is a question of focus. We will consider some ways of controlling focus later in the course.
How do objects relate to other concepts in design methods?
Remember entity-relationship models? SSADM, JSD and so on have 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. We will look at object models later which look remarkably like entity-relationship models (because they are).
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. For example, consider our two fairy story creatures:
Now we can see that they both have the same operations "arrive" and "meet". We can therefore create an abstract creature:
which has the common operations. We can then draw the original objects grouped under the abstract object as follows
By this device Red Riding Hood has also appetite, nose and teeth as operations. The latter two may be of relevance when she goes to charm the woodcutter, provided they are petite and pearly bright respectively.
Okay, so let's have some more practical examples for those of you who have to do real work. Firstly, the frighteningly dull student-lecturer example. You can do the same with the equally dull employee-customer example.
Inheritance can pass down an arbitrarily deep hierarchy. A slightly more complicated hierarchy is given below to describe objects which can be juggled.
The big deal about inheritance
Inheritance is considered good for the software re-use and for clarity of description.
Re-use
When new objects are created which are similar to other objects, they can have many of their attributes and operations ready defined. Let us suppose we now introduce Grandma into our fairystory hierarchy.
Here we get a Grandma who already had an appetite, nose and teeth and who can arrive and meet. Actually these are not in the normal scope of the fairy story, but the principle should be clear.
We might be writing a simple geometry program:
Now to add circles we simply put in another object under 2D shape.
So the circle object need not define the area and position attributes or the get area operation.
It is now possible to buy or obtain ready-built class hierarchies written in object-oriented languages which can be extended in this way to produce a new application.
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.
Subscribe to:
Posts (Atom)