Grady Booch
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Grady Booch as PDF for free.
More details
- Words: 6,894
- Pages: 31
Grady Booch From Wikipedia, the free encyclopedia Jump to: navigation, search
Grady Booch in 2002. Grady Booch (born February 27, 1955) is an American software engineer, and Chief Scientist, Software Engineering in IBM Research. Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh.
Contents [hide] •
1 Biography
•
2 Work ○
2.1 IBM 1130
○
2.2 Booch method
•
3 Publications
•
4 References
•
5 External links
[edit] Biography He earned his bachelor's degree in 1977 from the United States Air Force Academy and a master's degree in electrical engineering in 1979 from the University of California, Santa Barbara. [1] He is former Chief Scientist of Rational Software (acquired by IBM on February 20, 2003), where he worked until March 18, 2008. Afterwards he became Chief Scientist, Software Engineering in IBM Research, and series editor for Benjamin Cummings.
In 1995 he was inducted as a Fellow of the Association for Computing Machinery. He was named an IBM Fellow in 2003, soon after his entry into IBM, and assumed his current role in March 18, 2008.
[edit] Work Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh. He also developed the Booch method of software development, which he presents in his book, Object Oriented Analysis and Design. He advises adding more classes to simplify complex code. Booch is also a design pattern enthusiast.[citation needed] In the 1980s, Booch wrote one of the more popular books on programming in Ada.
[edit] IBM 1130 Booch got his first exposure to programming on an IBM 1130.[2] ... I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and lateevening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
[edit] Booch method
Class diagram The Booch method is a technique used in software engineering. It is an object modeling language and methodology that was widely used in object-oriented analysis and design. It was developed by Booch while at Rational Software. The notation aspect of the Booch method has now been superseded by the Unified Modeling Language (UML), which features graphical elements from the Booch method along with elements from the object-modeling technique (OMT) and object-oriented software engineering (OOSE). Methodological aspects of the Booch method have been incorporated into several methodologies and processes, the primary such methodology being the Rational Unified Process (RUP).
Object Lesson 1 - 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.
Course Aims - Creating Beautiful Systems This course aims to provide you with 1. A simple, clear, analysis and design notation. 2. A good basic understanding of the concepts of object oriented systems. 3. A method for construction of analyses and designs. 4. Some discussion of the implementation of designs.
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
Inheritance means that all the attributes and operations of an abstract object are available in the specialised object below. The triangle in the diagram indicates inheritance. The point of the triangle indicates where operations and attributes are inherited from. Now we can enter a debate about whether nose, teeth and appetite are characteristics of all creatures or not. It they are, we can revise the diagram above as:
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.
Or more interesting (only a bit):
Inheritance can pass down an arbitrarily deep hierarchy. A slightly more complicated hierarchy is given below to describe objects which can be juggled.
Now we see that a tennis ball has attributes diameter and weight, and operations catch, pick up, drop,throw and bounce. Objects accumulate all the attributes and operations of the objects above them in an inheritance hierarchy.
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 fairy story 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.
Clarity The notion of breaking the world down into hierarchies of types is not as old as the hills, but it goes back at least as far as the Ancient Greeks: all men are mortal, Socrates is a man, so Socrates is mortal. The reductionist, classification approach is embedded in Western thought, and should be natural for most people to follow. Experience shows that describing things using hierarchies is an easy and comprehensive way of communicating both structure and functionality.
Summary of this lesson •
Objects are a natural way of representing things.
•
Objects are described by their attributes and their operations.
•
Objects can be organised in inheritance hierarchies.
Exercises 1. Describe two of the following objects in terms of their attributes and operations: motor car, sheep, kite, hospital, elephant, garden, school, bacon, teddy bear, bank customer, bus. 2. Devise a simple inheritance hierarchy for two of the following: geometry, sports teams, politicians, rodents, viral infections, restaurants.
3.Object Lesson 2 - Relationships and Object Models 4. Aggregation 5. 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. You will have met a similar idea in program decomposition. Here is a simple example of a juggler:
6.
7. 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. 8. By analysing our juggler object and breaking it down into component objects, we now have a better understanding of our object. Also, we have discovered two new operations, scratch head and kick. 9. The diamond in the diagram indicates that one object is made up of another object. The numbers are indicative of how many - more will be said about this shortly. 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. 10. 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. 11. Let us look at another example.
12.
13. A car engine lubricant is made up of a number of base oils blended with an additive
package. The additive package consists of one or more detergents to keep engine surfaces clean, one or more dispersants to suspend particles in the oil to be carried to the filter, one or more anti-oxidants to slow up the thermal decay of the oil, and a viscosity improver to control the viscosity of the oil at different temperatures. A research scientist will experiment with different oils by running engines containing the oils and analysing the effect of the engines on the oils. 14. Let us look at another example.
15. 16. For the purposes of assessing the care provision for someone, it is necessary to know
their assets, any disabilities they have, any disease they have, any carers they have. Assets are made up of liquid assets, such as cash in the bank, and non-liquid assets such as their home. Carers may be family carers or care packages provided by various services. A care
package may be made up of a number of social care packages, such as home helps, and health care packages such as GP service and hospital services. 17. 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.
18.Delegation 19. The behaviour of an object which is made up of other objects is usually defined by the
behaviour of the smaller objects. For example
20.
21. 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. 22. 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. However, the arguments for and against multiple inheritance (inheriting from more than one parent) are lengthy and can be side-stepped for now.
23.Relationships
24. 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.
25.One to one relationships
26. 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. 27.
28. Thus a man marries one woman (at a time) and a woman marries one man (at a time). A cat eats one canary (before being battered to death by the little old lady who owned the canary). Canaries do not (in general) eat cats, so the eats relationship is one way.
29.One to many relationships
30. Sometimes one object can be related to many objects. This is indicated by different marks at the end of the line.
31.
32. 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.
33.
34. Zero or more suitors court the Princes. The black dot at the end of the line indicates zero or more.
35. 36. Before an adequate suitor comes along, as is well known, a princess will kiss at least one
frog, and possibly many more if she gets a taste for them. Frogs, being well mannered creatures and not wishing to appear in the gossip columns, never let more than one Princess kiss them.
37.Many to many relationships
38. Sometimes objects at either end of a relationship may be related to many objects at the other end.
39.
40. A dog may bite zero or more postmen. A postman may be bitten by zero or more dogs.
41.
42. A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.
43.Object Models 44. We now have the notation to describe quite complicated systems. The process of objectoriented analysis and design is one of elaborating an object model, increasing its detail and scope until enough is known to construct a computer system (if indeed that is what is wanted). 45. Here is a simple model for the Red Riding Hood story
46.
47. Another example is one to describe patient referrals by GP's to specialists.
48.
49. Another example is for a lift system:
50.
51. The object model is the principal output of an analysis and design process. The distinction between analysis and design is much greyer in object-oriented development. Essentially it is one of detail. Analysis usually omits concerns about how a system is to be developed, and some of the objects may not be fully decomposed. 52. The object model is the central pillar of an analysis or design. It defines the computable elements. The dynamic and functional models discussed later all must result in objects, attributes and operations being defined in the object model. It is comprehensive and complete in terms of defining functionality, specifying not only the data but also the operations on the data.
53.Exercises 54. Construct an object model for one of the following: the football league, star wars, a personnel system, Cinderella, an automatic washing machine, a video hire shop, a kitchen.
Object Lesson 3 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. All we are going to do in the rest of the course is give you some tools to look for objects. But for the present, we will rely on native wit. Begin by looking at the real world. Open your eyes and your ears. 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. Let us suppose that you are analysing a system for a motor museum. The system is to produce a multi-media guide to the museum. A preliminary list of objects might be:
car, bus, vehicle, number plate, exhibit, manufacturer, date of manufacture, value, position, weight, size, photograph, tools, shop, garage, ticket, owner, history No doubt we could go on. However, the above list is probably enough to illustrate our needs.
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. The obvious thing above is to examine the following group car, bus, vehicle, number plate, exhibit, photograph, tools, garage It would seem that these could all be grouped together under the object exhibit. The question is, can these all be considered to be one object. In this case, the answer is probably yes. In the museum the behaviour of cars, photographs, and garages are not radically different, so we can group them together. We can differentiate between the individual objects on the basis of an attribute, say type. Our first object is therefore: We are then left with the list of candidate objects: exhibit, manufacturer, date of manufacture, value, position, weight, size, shop, ticket, owner, history
Look for attributes Attributes are themselves objects, but with trivial behaviour - essentially all you do is record their value. Considering the above list, the following are probably attributes of exhibit: exhibit, date of manufacture, value, position, weight, size, owner So we have the exhibit object as: And we are left with the candidate objects: exhibit, manufacturer, shop, ticket, history We might have considered manufacturer as an attribute, but it may be useful to separate out manufacturer information later in the design. So we keep it for the time-being. The time to fold it in as an attribute is when we find it has no discernible behaviour of its own.
Irrelevant objects Sometimes an object is irrelevant because of what you are designing the system for. Here the ticket object may be very relevant for a sales desk system, but not for a multi-media system. Likewise, the shop is irrelevant. So we strike these out and we are left with the following objects. exhibit, manufacturer, history We have these objects potentially linked in the following way.
Both exhibits and manufacturers may have histories. By factoring out manufacturers, the system may be able to trace from an exhibit not only its history, but also that of its manufacturer, and maybe allow someone to search for all the objects in the museum held by a given manufacturer. The fleshing out of the objects with attributes and operations can be developed hereon in. A first cut of this might be:
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 The design of the process progresses by the construction of a series of prototypes. The prototypes are constructed using the most productive tools in terms of speed of development. The final system, when constructed, is functionally equivalent to the final prototype, but it is implemented in the most suitable technology for use of the system. For example, a patient monitoring system, requiring lots of graphical displays from a digital feed, might be prototyped in a spreadsheet because the spreadsheet has very powerful graphics. However, when the system is built it would have to be implemented to run on a specific computer with a limited display and limited amount of memory, without a spreadsheet license. Using iterative design methods, a series of prototypes could be developed using a spreadsheet until functionality is finally agreed. The final prototype would then be used as an active specification for the final system which might be written in C. Prototyping is useful in the following contexts •
at the beginning of a project
•
in research-oriented projects where there needs to be some exploration of different ways of solving problems
•
where there is a need to clearly define interfaces
•
where the client needs reassurance that progress is being made
The weaknesses of prototyping are: •
the prototype is often taken on as a final system
•
there can be difficulty explaining a long lag between first prototype and final system
•
inevitably there will be some differences between the final system and the final prototype because of different interface mechanisms
Evolutionary development This process involves a staged implementation of the system. Analysis and design of the next stage is after successful implementation of the previous stage. Evolutionary development is useful if: •
a partial implementation of the proposed system is of some use
•
it is not replacing another system which cannot be integrated appropriately at each stage of development
•
The weaknesses of evolutionary development are:
•
disruption caused by each stage of implementation
•
difficulty controlling the end-point of development
Boxing Computer systems development is constrained by money, time and personnel available to develop, implement and install. The idea of boxing is to drive the iterative process of development by checkpointing at key stages according to one of the three constraints. Time-boxing involves setting a time limit on each iteration of the cycle. As the time limit nears, the system is implemented, irrespective of whether the planned functionality is fully implemented. The system is reviewed, and the plans for the next stage take into account what has been achieved and what has been learnt. Money-boxing is similar to time-boxing, except that the reviews are triggered by expenditure limits. Personnel-boxing involves controlling the process using the time of certain personnel. Boxing has an advantage of driving the system, and forcing changes of plan as the system development progresses.
Charters Rather than produce a contract defining all functionality to be delivered in a cycle, it is possible instead to construct a charter. A charter prioritises the functionality which should be delivered in the cycle. The charter can over-specify what is expected in the cycle, in case progress is faster than anticipated.
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 object-oriented 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.
The Full-Lifecycle Object-Oriented Testing (FLOOT) methodology is a collection of testing techniques to verify and validate object-oriented software. The FLOOT lifecycle is depicted in Figure 1, indicating a wide variety of techniques (described in Table 1) are available to you throughout all aspects of software development. The list of techniques is not meant to be complete – instead the goal is to make it explicit that you have a wide range of options available to you. It is important to understand that although the FLOOT method is presented as a collection of serial phases it does not need to be so: the techniques of FLOOT can be applied with evolutionary/agile processes as well. The reason why I present the FLOOT in a “traditional” manner is to make it explicit that you can in fact test throughout all aspects of software development, not just during coding.
Figure 1. The FLOOT Lifecycle.
Table 1. Testing techniques. FLOOT Technique Description Black-box testing Boundary-value testing Class testing Class-integration testing Code review Component testing Coverage testing Design review Inheritance-regression testing Integration testing
Testing that verifies the item being tested when given the appropriate input provides the expected results. Testing of unusual or extreme situations that an item should be able to handle. The act of ensuring that a class and its instances (objects) perform as defined. The act of ensuring that the classes, and their instances, form some software perform as defined. A form of technical review in which the deliverable being reviewed is source code. The act of validating that a component works as defined. The act of ensuring that every line of code is exercised at least once. A technical review in which a design model is inspected. The act of running the test cases of the super classes, both direct and indirect, on a given subclass. Testing to verify several portions of software work together.
Method testing Model review Path testing Prototype review Prove it with code Regression testing Stress testing Technical review Usage scenario testing User interface testing White-box testing
Testing to verify a method (member function) performs as defined. An inspection, ranging anywhere from a formal technical review to an informal walkthrough, by others who were not directly involved with the development of the model. The act of ensuring that all logic paths within your code are exercised at least once. A process by which your users work through a collection of use cases, using a prototype as if it was the real system. The main goal is to test whether the design of the prototype meets their needs. The best way to determine if a model actually reflects what is needed, or what should be built, is to actually build software based on that model that show that the model works. The acts of ensuring that previously tested behaviors still work as expected after changes have been made to an application. The act of ensuring that the system performs as expected under high volumes of transactions, users, load, and so on. A quality assurance technique in which the design of your application is examined critically by a group of your peers. A review typically focuses on accuracy, quality, usability, and completeness. This process is often referred to as a walkthrough, an inspection, or a peer review. A testing technique in which one or more person(s) validate a model by acting through the logic of usage scenarios. The testing of the user interface (UI) to ensure that it follows accepted UI standards and meets the requirements defined for it. Often referred to as graphical user interface (GUI) testing. Testing to verify that specific lines of code work as defined. Also referred to as clear-box testing.
I’d like to share a few of my personal philosophies with regards to testing: 1. The goal is to find defects. The primary purpose of testing is to validate the correctness
of whatever it is that you’re testing. In other words, successful tests find bugs. 2. You can validate all artifacts. As you will see in this chapter, you can test all your
artifacts, not just your source code. At a minimum you can review models and documents and therefore find and fix defects long before they get into your code. 3. Test often and early. The potential for the cost of change to rise exponentially motivates
you to test as early as possible. Figure 2 compares the average cost to address defects found by various agile and traditional approaches to testing. The goal is to reduce the feedback cycle as much as possible. 4. Testing builds confidence. In Extreme Programming Explained Kent Beck makes an
interesting observation that when you have a full test suite, a test suite is a collection of tests, and if you run it as often as possible, that it gives you the courage to move forward. Many people fear making a change to their code because they’re afraid that they’ll break it, but with a full test suite in place if you do break something you know you’ll detect it and then fix it. 5. Test to the risk of the artifact. The riskier something is, the more it needs to be
reviewed and tested. In other words you should invest significant effort testing in an air traffic control system but nowhere near as much effort testing a “Hello World” application. 6. One test is worth a thousand opinions. You can tell me that your application works,
but until you show me the test results, I will not believe you.
Figure 2. Comparing the average cost of change of various defect finding techniques.
Other Reading: •
Agile Testing Strategies
•
AMDD and TDD Go Hand-In-Hand
•
Examining the cost of change curve (explains why FLOOT is so important).
•
The FLOOT was first introduced in Building Object Applications That Work, was evolved in Process Patterns, and once again in The Object Primer.
•
Model Reviews: Best Practice or Process Smell?
•
Quality in an Agile World
•
Test-Driven Design (TDD)
•
Validating Agile Models
•
Whence Data Quality? A Survey Into the Current State of DQ ○
•
Discussion and source data downloads are here
Why Agile Software Development Works: Improved Feedback The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to
give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Translations: •
Chinese
•
French
•
Spanish
Introduction This article gives an overview of the Object Modelling Technique (OMT), which is fully described in the book by Rumbaugh et al. (Object-Oriented Modelling and Design, Prentice-Hall 1991). OMT has been used as the basis for Select's new C++ Designer product.
Why we chose OMT Prior to starting the C++ Designer development, we reviewed most of the OO methods which were available at the time, including Booch, Coad-Yourdon and Shlaer-Mellor. In making our choice, we considered the following factors: •
The method should support all of the main OO semantics - i.e. inheritance (is a kind of), aggregation (is a part of) and association (is related to)
•
It must cover both analysis and design to a reasonable extent and give a smooth transition between the various stages of the life-cycle - especially between the design phase and C++ code.
•
It should provide support, or at least form a good basis for providing support, for realtime as well as MIS systems.
•
It should not be over complex.
•
It should, where possible, use familiar techniques in order to reduce the learning curve for users experienced in structured methods.
•
It should be an open standard - i.e. it should be published, public and well known.
•
The book in which the method is described should be readable and reasonably complete and consistent.
•
Training courses and consultancy should be available on both sides of the Atlantic from a variety of sources.
•
Other CASE vendors should be supporting, or considering support for, the method.
After a great deal of internal and external debate, we finally settled on OMT: •
The combination of the object, dynamic and functional models gives OMT the ability to support many different kinds of applications, including real-time systems (although the authors don't make any claims for this area). In addition, the transition between analysis and design is smooth and fairly well defined.
•
OMT is based on Yourdon, but with a strong object-oriented bias. This means that the learning curve is relatively small for the large number of developers who are already trained in Yourdon and other similar methods.
•
The book by Rumbaugh et al is reasonably clear and complete. Some aspects, especially those relating to integration between the three models are not presented very consistently, but such criticisms can be levelled at most software engineering books.
•
OMT is supported by several training and consultancy organisations in both Europe and the US. This is extremely important for vendors of low-cost CASE tools, since it removes the risk of customers feeling that they are entirely dependent upon the developer of the tool.
•
OMT was developed in the General Electric Research and Development Center, New York and has been used for some time in that environment. In the UK, companies such as Object Designers Ltd have been using OMT as the basis for their OO developments over the last two years. In addition, we have found several major clients who are starting OMT pilot projects (e.g. British Aerospace and Serco).
OMT Overview OMT uses three integrated models to describe a system; the object, dynamic and functional models. Only the first of these is supported by C++ Designer, however Select will be adding a full OMT toolkit to their range later this year.
The Object Model
The object model is central to the method and uses a diagram which is similar to the ERDs used in Yourdon. Classes and their attributes and operations are shown, together with relationships between classes. The relationships which can be drawn include inheritance, aggregation and association. The modelling syntax is rich enough to represent the majority of 00 constructs in common use. The diagram shows the symbol for a class in OMT notation. The attributes and operations correspond to C++ data and function members.
Here we are illustrating single inheritance. The land and water vehicle classes are subclasses of vehicle.
Now we've added multiple inheritance by introducing an amphibious vehicle.
The diamond symbol is used to show aggregation or 'part-of relationships
.
The above diagram shows how the notation would be used for the design of a petrol station control system. Note that we have also used the association notation (e.g. between the CONSOLE and the PUMP), which is similar to a relationship in entity-relationship notations.
The Dynamic Model The dynamic model consists of a state transition diagram (STD) for each of the classes in the object model. The STD notation is that defined by Harel (1987), which allows for decomposable states. This is richer and more powerful than that commonly used in Yourdon.
The Functional Model The functional model uses a hierarchy of data flow diagrams (DFDs) in a similar fashion to the Yourdon method. However, the DFDs are not very well integrated with the object and dynamic models and it is difficult to imagine many projects making extensive use of the functional model. Some aspects of the functional model are, however, quite useful. For example, the context diagram is vital for defining the scope of the system. Also, it may be possible to strengthen the real-time aspects of the method by introducing the concept of a processor and task model using DFDs.
Summary OMT is a very useful, expressive object-oriented analysis and design method. The object model allows a smooth transition from analysis, through design, to code - especially when systems are implemented in an OO language such as C++. The dynamic model is very useful for illustrating the way in which the system responds to events. However, the functional model must be used with great care in order to avoid distorting the structure of the final application.
Overload Journal #1 - Apr 1993 + Design of applications and programs Browse in : All > Journals > Overload > 01 (12) All > Topics > Design (149) Any of these categories - All of these categories
Grady Booch in 2002. Grady Booch (born February 27, 1955) is an American software engineer, and Chief Scientist, Software Engineering in IBM Research. Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh.
Contents [hide] •
1 Biography
•
2 Work ○
2.1 IBM 1130
○
2.2 Booch method
•
3 Publications
•
4 References
•
5 External links
[edit] Biography He earned his bachelor's degree in 1977 from the United States Air Force Academy and a master's degree in electrical engineering in 1979 from the University of California, Santa Barbara. [1] He is former Chief Scientist of Rational Software (acquired by IBM on February 20, 2003), where he worked until March 18, 2008. Afterwards he became Chief Scientist, Software Engineering in IBM Research, and series editor for Benjamin Cummings.
In 1995 he was inducted as a Fellow of the Association for Computing Machinery. He was named an IBM Fellow in 2003, soon after his entry into IBM, and assumed his current role in March 18, 2008.
[edit] Work Booch is best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh. He also developed the Booch method of software development, which he presents in his book, Object Oriented Analysis and Design. He advises adding more classes to simplify complex code. Booch is also a design pattern enthusiast.[citation needed] In the 1980s, Booch wrote one of the more popular books on programming in Ada.
[edit] IBM 1130 Booch got his first exposure to programming on an IBM 1130.[2] ... I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and lateevening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
[edit] Booch method
Class diagram The Booch method is a technique used in software engineering. It is an object modeling language and methodology that was widely used in object-oriented analysis and design. It was developed by Booch while at Rational Software. The notation aspect of the Booch method has now been superseded by the Unified Modeling Language (UML), which features graphical elements from the Booch method along with elements from the object-modeling technique (OMT) and object-oriented software engineering (OOSE). Methodological aspects of the Booch method have been incorporated into several methodologies and processes, the primary such methodology being the Rational Unified Process (RUP).
Object Lesson 1 - 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.
Course Aims - Creating Beautiful Systems This course aims to provide you with 1. A simple, clear, analysis and design notation. 2. A good basic understanding of the concepts of object oriented systems. 3. A method for construction of analyses and designs. 4. Some discussion of the implementation of designs.
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
Inheritance means that all the attributes and operations of an abstract object are available in the specialised object below. The triangle in the diagram indicates inheritance. The point of the triangle indicates where operations and attributes are inherited from. Now we can enter a debate about whether nose, teeth and appetite are characteristics of all creatures or not. It they are, we can revise the diagram above as:
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.
Or more interesting (only a bit):
Inheritance can pass down an arbitrarily deep hierarchy. A slightly more complicated hierarchy is given below to describe objects which can be juggled.
Now we see that a tennis ball has attributes diameter and weight, and operations catch, pick up, drop,throw and bounce. Objects accumulate all the attributes and operations of the objects above them in an inheritance hierarchy.
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 fairy story 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.
Clarity The notion of breaking the world down into hierarchies of types is not as old as the hills, but it goes back at least as far as the Ancient Greeks: all men are mortal, Socrates is a man, so Socrates is mortal. The reductionist, classification approach is embedded in Western thought, and should be natural for most people to follow. Experience shows that describing things using hierarchies is an easy and comprehensive way of communicating both structure and functionality.
Summary of this lesson •
Objects are a natural way of representing things.
•
Objects are described by their attributes and their operations.
•
Objects can be organised in inheritance hierarchies.
Exercises 1. Describe two of the following objects in terms of their attributes and operations: motor car, sheep, kite, hospital, elephant, garden, school, bacon, teddy bear, bank customer, bus. 2. Devise a simple inheritance hierarchy for two of the following: geometry, sports teams, politicians, rodents, viral infections, restaurants.
3.Object Lesson 2 - Relationships and Object Models 4. Aggregation 5. 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. You will have met a similar idea in program decomposition. Here is a simple example of a juggler:
6.
7. 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. 8. By analysing our juggler object and breaking it down into component objects, we now have a better understanding of our object. Also, we have discovered two new operations, scratch head and kick. 9. The diamond in the diagram indicates that one object is made up of another object. The numbers are indicative of how many - more will be said about this shortly. 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. 10. 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. 11. Let us look at another example.
12.
13. A car engine lubricant is made up of a number of base oils blended with an additive
package. The additive package consists of one or more detergents to keep engine surfaces clean, one or more dispersants to suspend particles in the oil to be carried to the filter, one or more anti-oxidants to slow up the thermal decay of the oil, and a viscosity improver to control the viscosity of the oil at different temperatures. A research scientist will experiment with different oils by running engines containing the oils and analysing the effect of the engines on the oils. 14. Let us look at another example.
15. 16. For the purposes of assessing the care provision for someone, it is necessary to know
their assets, any disabilities they have, any disease they have, any carers they have. Assets are made up of liquid assets, such as cash in the bank, and non-liquid assets such as their home. Carers may be family carers or care packages provided by various services. A care
package may be made up of a number of social care packages, such as home helps, and health care packages such as GP service and hospital services. 17. 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.
18.Delegation 19. The behaviour of an object which is made up of other objects is usually defined by the
behaviour of the smaller objects. For example
20.
21. 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. 22. 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. However, the arguments for and against multiple inheritance (inheriting from more than one parent) are lengthy and can be side-stepped for now.
23.Relationships
24. 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.
25.One to one relationships
26. 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. 27.
28. Thus a man marries one woman (at a time) and a woman marries one man (at a time). A cat eats one canary (before being battered to death by the little old lady who owned the canary). Canaries do not (in general) eat cats, so the eats relationship is one way.
29.One to many relationships
30. Sometimes one object can be related to many objects. This is indicated by different marks at the end of the line.
31.
32. 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.
33.
34. Zero or more suitors court the Princes. The black dot at the end of the line indicates zero or more.
35. 36. Before an adequate suitor comes along, as is well known, a princess will kiss at least one
frog, and possibly many more if she gets a taste for them. Frogs, being well mannered creatures and not wishing to appear in the gossip columns, never let more than one Princess kiss them.
37.Many to many relationships
38. Sometimes objects at either end of a relationship may be related to many objects at the other end.
39.
40. A dog may bite zero or more postmen. A postman may be bitten by zero or more dogs.
41.
42. A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.
43.Object Models 44. We now have the notation to describe quite complicated systems. The process of objectoriented analysis and design is one of elaborating an object model, increasing its detail and scope until enough is known to construct a computer system (if indeed that is what is wanted). 45. Here is a simple model for the Red Riding Hood story
46.
47. Another example is one to describe patient referrals by GP's to specialists.
48.
49. Another example is for a lift system:
50.
51. The object model is the principal output of an analysis and design process. The distinction between analysis and design is much greyer in object-oriented development. Essentially it is one of detail. Analysis usually omits concerns about how a system is to be developed, and some of the objects may not be fully decomposed. 52. The object model is the central pillar of an analysis or design. It defines the computable elements. The dynamic and functional models discussed later all must result in objects, attributes and operations being defined in the object model. It is comprehensive and complete in terms of defining functionality, specifying not only the data but also the operations on the data.
53.Exercises 54. Construct an object model for one of the following: the football league, star wars, a personnel system, Cinderella, an automatic washing machine, a video hire shop, a kitchen.
Object Lesson 3 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. All we are going to do in the rest of the course is give you some tools to look for objects. But for the present, we will rely on native wit. Begin by looking at the real world. Open your eyes and your ears. 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. Let us suppose that you are analysing a system for a motor museum. The system is to produce a multi-media guide to the museum. A preliminary list of objects might be:
car, bus, vehicle, number plate, exhibit, manufacturer, date of manufacture, value, position, weight, size, photograph, tools, shop, garage, ticket, owner, history No doubt we could go on. However, the above list is probably enough to illustrate our needs.
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. The obvious thing above is to examine the following group car, bus, vehicle, number plate, exhibit, photograph, tools, garage It would seem that these could all be grouped together under the object exhibit. The question is, can these all be considered to be one object. In this case, the answer is probably yes. In the museum the behaviour of cars, photographs, and garages are not radically different, so we can group them together. We can differentiate between the individual objects on the basis of an attribute, say type. Our first object is therefore: We are then left with the list of candidate objects: exhibit, manufacturer, date of manufacture, value, position, weight, size, shop, ticket, owner, history
Look for attributes Attributes are themselves objects, but with trivial behaviour - essentially all you do is record their value. Considering the above list, the following are probably attributes of exhibit: exhibit, date of manufacture, value, position, weight, size, owner So we have the exhibit object as: And we are left with the candidate objects: exhibit, manufacturer, shop, ticket, history We might have considered manufacturer as an attribute, but it may be useful to separate out manufacturer information later in the design. So we keep it for the time-being. The time to fold it in as an attribute is when we find it has no discernible behaviour of its own.
Irrelevant objects Sometimes an object is irrelevant because of what you are designing the system for. Here the ticket object may be very relevant for a sales desk system, but not for a multi-media system. Likewise, the shop is irrelevant. So we strike these out and we are left with the following objects. exhibit, manufacturer, history We have these objects potentially linked in the following way.
Both exhibits and manufacturers may have histories. By factoring out manufacturers, the system may be able to trace from an exhibit not only its history, but also that of its manufacturer, and maybe allow someone to search for all the objects in the museum held by a given manufacturer. The fleshing out of the objects with attributes and operations can be developed hereon in. A first cut of this might be:
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 The design of the process progresses by the construction of a series of prototypes. The prototypes are constructed using the most productive tools in terms of speed of development. The final system, when constructed, is functionally equivalent to the final prototype, but it is implemented in the most suitable technology for use of the system. For example, a patient monitoring system, requiring lots of graphical displays from a digital feed, might be prototyped in a spreadsheet because the spreadsheet has very powerful graphics. However, when the system is built it would have to be implemented to run on a specific computer with a limited display and limited amount of memory, without a spreadsheet license. Using iterative design methods, a series of prototypes could be developed using a spreadsheet until functionality is finally agreed. The final prototype would then be used as an active specification for the final system which might be written in C. Prototyping is useful in the following contexts •
at the beginning of a project
•
in research-oriented projects where there needs to be some exploration of different ways of solving problems
•
where there is a need to clearly define interfaces
•
where the client needs reassurance that progress is being made
The weaknesses of prototyping are: •
the prototype is often taken on as a final system
•
there can be difficulty explaining a long lag between first prototype and final system
•
inevitably there will be some differences between the final system and the final prototype because of different interface mechanisms
Evolutionary development This process involves a staged implementation of the system. Analysis and design of the next stage is after successful implementation of the previous stage. Evolutionary development is useful if: •
a partial implementation of the proposed system is of some use
•
it is not replacing another system which cannot be integrated appropriately at each stage of development
•
The weaknesses of evolutionary development are:
•
disruption caused by each stage of implementation
•
difficulty controlling the end-point of development
Boxing Computer systems development is constrained by money, time and personnel available to develop, implement and install. The idea of boxing is to drive the iterative process of development by checkpointing at key stages according to one of the three constraints. Time-boxing involves setting a time limit on each iteration of the cycle. As the time limit nears, the system is implemented, irrespective of whether the planned functionality is fully implemented. The system is reviewed, and the plans for the next stage take into account what has been achieved and what has been learnt. Money-boxing is similar to time-boxing, except that the reviews are triggered by expenditure limits. Personnel-boxing involves controlling the process using the time of certain personnel. Boxing has an advantage of driving the system, and forcing changes of plan as the system development progresses.
Charters Rather than produce a contract defining all functionality to be delivered in a cycle, it is possible instead to construct a charter. A charter prioritises the functionality which should be delivered in the cycle. The charter can over-specify what is expected in the cycle, in case progress is faster than anticipated.
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 object-oriented 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.
The Full-Lifecycle Object-Oriented Testing (FLOOT) methodology is a collection of testing techniques to verify and validate object-oriented software. The FLOOT lifecycle is depicted in Figure 1, indicating a wide variety of techniques (described in Table 1) are available to you throughout all aspects of software development. The list of techniques is not meant to be complete – instead the goal is to make it explicit that you have a wide range of options available to you. It is important to understand that although the FLOOT method is presented as a collection of serial phases it does not need to be so: the techniques of FLOOT can be applied with evolutionary/agile processes as well. The reason why I present the FLOOT in a “traditional” manner is to make it explicit that you can in fact test throughout all aspects of software development, not just during coding.
Figure 1. The FLOOT Lifecycle.
Table 1. Testing techniques. FLOOT Technique Description Black-box testing Boundary-value testing Class testing Class-integration testing Code review Component testing Coverage testing Design review Inheritance-regression testing Integration testing
Testing that verifies the item being tested when given the appropriate input provides the expected results. Testing of unusual or extreme situations that an item should be able to handle. The act of ensuring that a class and its instances (objects) perform as defined. The act of ensuring that the classes, and their instances, form some software perform as defined. A form of technical review in which the deliverable being reviewed is source code. The act of validating that a component works as defined. The act of ensuring that every line of code is exercised at least once. A technical review in which a design model is inspected. The act of running the test cases of the super classes, both direct and indirect, on a given subclass. Testing to verify several portions of software work together.
Method testing Model review Path testing Prototype review Prove it with code Regression testing Stress testing Technical review Usage scenario testing User interface testing White-box testing
Testing to verify a method (member function) performs as defined. An inspection, ranging anywhere from a formal technical review to an informal walkthrough, by others who were not directly involved with the development of the model. The act of ensuring that all logic paths within your code are exercised at least once. A process by which your users work through a collection of use cases, using a prototype as if it was the real system. The main goal is to test whether the design of the prototype meets their needs. The best way to determine if a model actually reflects what is needed, or what should be built, is to actually build software based on that model that show that the model works. The acts of ensuring that previously tested behaviors still work as expected after changes have been made to an application. The act of ensuring that the system performs as expected under high volumes of transactions, users, load, and so on. A quality assurance technique in which the design of your application is examined critically by a group of your peers. A review typically focuses on accuracy, quality, usability, and completeness. This process is often referred to as a walkthrough, an inspection, or a peer review. A testing technique in which one or more person(s) validate a model by acting through the logic of usage scenarios. The testing of the user interface (UI) to ensure that it follows accepted UI standards and meets the requirements defined for it. Often referred to as graphical user interface (GUI) testing. Testing to verify that specific lines of code work as defined. Also referred to as clear-box testing.
I’d like to share a few of my personal philosophies with regards to testing: 1. The goal is to find defects. The primary purpose of testing is to validate the correctness
of whatever it is that you’re testing. In other words, successful tests find bugs. 2. You can validate all artifacts. As you will see in this chapter, you can test all your
artifacts, not just your source code. At a minimum you can review models and documents and therefore find and fix defects long before they get into your code. 3. Test often and early. The potential for the cost of change to rise exponentially motivates
you to test as early as possible. Figure 2 compares the average cost to address defects found by various agile and traditional approaches to testing. The goal is to reduce the feedback cycle as much as possible. 4. Testing builds confidence. In Extreme Programming Explained Kent Beck makes an
interesting observation that when you have a full test suite, a test suite is a collection of tests, and if you run it as often as possible, that it gives you the courage to move forward. Many people fear making a change to their code because they’re afraid that they’ll break it, but with a full test suite in place if you do break something you know you’ll detect it and then fix it. 5. Test to the risk of the artifact. The riskier something is, the more it needs to be
reviewed and tested. In other words you should invest significant effort testing in an air traffic control system but nowhere near as much effort testing a “Hello World” application. 6. One test is worth a thousand opinions. You can tell me that your application works,
but until you show me the test results, I will not believe you.
Figure 2. Comparing the average cost of change of various defect finding techniques.
Other Reading: •
Agile Testing Strategies
•
AMDD and TDD Go Hand-In-Hand
•
Examining the cost of change curve (explains why FLOOT is so important).
•
The FLOOT was first introduced in Building Object Applications That Work, was evolved in Process Patterns, and once again in The Object Primer.
•
Model Reviews: Best Practice or Process Smell?
•
Quality in an Agile World
•
Test-Driven Design (TDD)
•
Validating Agile Models
•
Whence Data Quality? A Survey Into the Current State of DQ ○
•
Discussion and source data downloads are here
Why Agile Software Development Works: Improved Feedback The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to
give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
Translations: •
Chinese
•
French
•
Spanish
Introduction This article gives an overview of the Object Modelling Technique (OMT), which is fully described in the book by Rumbaugh et al. (Object-Oriented Modelling and Design, Prentice-Hall 1991). OMT has been used as the basis for Select's new C++ Designer product.
Why we chose OMT Prior to starting the C++ Designer development, we reviewed most of the OO methods which were available at the time, including Booch, Coad-Yourdon and Shlaer-Mellor. In making our choice, we considered the following factors: •
The method should support all of the main OO semantics - i.e. inheritance (is a kind of), aggregation (is a part of) and association (is related to)
•
It must cover both analysis and design to a reasonable extent and give a smooth transition between the various stages of the life-cycle - especially between the design phase and C++ code.
•
It should provide support, or at least form a good basis for providing support, for realtime as well as MIS systems.
•
It should not be over complex.
•
It should, where possible, use familiar techniques in order to reduce the learning curve for users experienced in structured methods.
•
It should be an open standard - i.e. it should be published, public and well known.
•
The book in which the method is described should be readable and reasonably complete and consistent.
•
Training courses and consultancy should be available on both sides of the Atlantic from a variety of sources.
•
Other CASE vendors should be supporting, or considering support for, the method.
After a great deal of internal and external debate, we finally settled on OMT: •
The combination of the object, dynamic and functional models gives OMT the ability to support many different kinds of applications, including real-time systems (although the authors don't make any claims for this area). In addition, the transition between analysis and design is smooth and fairly well defined.
•
OMT is based on Yourdon, but with a strong object-oriented bias. This means that the learning curve is relatively small for the large number of developers who are already trained in Yourdon and other similar methods.
•
The book by Rumbaugh et al is reasonably clear and complete. Some aspects, especially those relating to integration between the three models are not presented very consistently, but such criticisms can be levelled at most software engineering books.
•
OMT is supported by several training and consultancy organisations in both Europe and the US. This is extremely important for vendors of low-cost CASE tools, since it removes the risk of customers feeling that they are entirely dependent upon the developer of the tool.
•
OMT was developed in the General Electric Research and Development Center, New York and has been used for some time in that environment. In the UK, companies such as Object Designers Ltd have been using OMT as the basis for their OO developments over the last two years. In addition, we have found several major clients who are starting OMT pilot projects (e.g. British Aerospace and Serco).
OMT Overview OMT uses three integrated models to describe a system; the object, dynamic and functional models. Only the first of these is supported by C++ Designer, however Select will be adding a full OMT toolkit to their range later this year.
The Object Model
The object model is central to the method and uses a diagram which is similar to the ERDs used in Yourdon. Classes and their attributes and operations are shown, together with relationships between classes. The relationships which can be drawn include inheritance, aggregation and association. The modelling syntax is rich enough to represent the majority of 00 constructs in common use. The diagram shows the symbol for a class in OMT notation. The attributes and operations correspond to C++ data and function members.
Here we are illustrating single inheritance. The land and water vehicle classes are subclasses of vehicle.
Now we've added multiple inheritance by introducing an amphibious vehicle.
The diamond symbol is used to show aggregation or 'part-of relationships
.
The above diagram shows how the notation would be used for the design of a petrol station control system. Note that we have also used the association notation (e.g. between the CONSOLE and the PUMP), which is similar to a relationship in entity-relationship notations.
The Dynamic Model The dynamic model consists of a state transition diagram (STD) for each of the classes in the object model. The STD notation is that defined by Harel (1987), which allows for decomposable states. This is richer and more powerful than that commonly used in Yourdon.
The Functional Model The functional model uses a hierarchy of data flow diagrams (DFDs) in a similar fashion to the Yourdon method. However, the DFDs are not very well integrated with the object and dynamic models and it is difficult to imagine many projects making extensive use of the functional model. Some aspects of the functional model are, however, quite useful. For example, the context diagram is vital for defining the scope of the system. Also, it may be possible to strengthen the real-time aspects of the method by introducing the concept of a processor and task model using DFDs.
Summary OMT is a very useful, expressive object-oriented analysis and design method. The object model allows a smooth transition from analysis, through design, to code - especially when systems are implemented in an OO language such as C++. The dynamic model is very useful for illustrating the way in which the system responds to events. However, the functional model must be used with great care in order to avoid distorting the structure of the final application.
Overload Journal #1 - Apr 1993 + Design of applications and programs Browse in : All > Journals > Overload > 01 (12) All > Topics > Design (149) Any of these categories - All of these categories
