1 DEFINING TERMS  16/10/97  1.3 Objects

The secret of OO

When OO achieves these aims, it is usually not because of any of the things that are specific to OO. It’s because

• the object oriented approach takes modularity, encapsulation and abstraction as fundamental

• and OOPLs make them (comparatively!) easy, the obvious way.

OO is a religion: it’s the people who become oriented towards objects. So people who say you can do OO in any language (even in ML!) are right and wrong. You can’t sensibly do all OO things: but you can think objects, which is the important part.

Slide 9

Encapsulation, abstraction

encapsulation The process of hiding all the details of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. The terms encapsulation and information hiding are usually interchangeable.

abstraction The essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply-defined conceptual boundaries relative to the perspective of the viewer; the process of focussing upon the essential characteristics of an object.

(From Booch’s glossary, again.) I will try not to use the term “data abstraction”, which usually seems to mean the process of abstracting away from data, i.e. encapsulating it.

Slide 10

Possibly more down-to-earth definitions of encapsulation and abstraction: abstraction is the stuff you want in the interface, or the process of identifying it. Encapsulation is what you have when you don’t have anything else in the interface.

1 DEFINING TERMS  16/10/97  1.4 Components

Back to earth: encapsulation

Format of data is a problem! In OO it’s the classic example of something that should normally be hidden. (Opposite of old COBOL approach which attempts to control data by putting it centrally in one place.) But there’s more to it than this: once we hide data, we also hide knowledge about whether or not it exists! information hiding E.g. suppose an application refers to a Point in 2D space, and can get both its Cartesian co-ordinates (x, y) and its polar co-ordinates (r, θ). Do we store both sets, or do we store one and use that one to calculate the other on demand? The outside world shouldn’t know or care. Slogan for C++ programmers: public data members are Bad.

Slide 11

That’s all I want to say about object concepts for now: in particular, I have deliberately not mentioned inheritance or polymorphism. We’ll come back at least to the question of inheritance later, when we consider class diagrams.

1.4 Components

2 DEVELOPMENT METHODS  16/10/97

What and why are components?

This is much more controversial. Basically in the component-based engineering approach of this course, what components really are is

an attempt to get round the fact that the object-based approach was not (always, usually) leading to desired levels of reuse, by choosing a new name meaning “thing we will be able to reuse” in the hope that this would make reuse happen.

So a component is a unit of reuse; object orientation is a (not the only) suitable method of implementing components. Not every component is an object; not every object is a component.

Somewhat dangerous analogy:

a component is to an object as a molecule is to an atom

Slide 12

Ivar Jacobson in OOSE says:

By components we mean already implemented units that we use to enhance the programming language constructs. These are used during programming, and correspond to the components in the building industry (that is, windows, doors and so on). They must be powerful, have simple well-defined interfaces, be simple to find, understand and use, and have a wide area of application.

and later in Software Reuse:

A component is a high-quality type, class or other UML workproduct, designed, documented and packaged to be reusable. A component is cohesive and has a stable interface. Components include interfaces; subsystems; use cases, types, actors, or classes; and attribute types. Components also include other workproducts, such as templates, or test case specifications.

In other words, if you’re happy to reuse it, it’s a component! Some, but not all, modules will be components; some, but not all classes will be components.

Note that this is different from the UML definition of the term: UML defines a component to be a physical unit of code. This course will take ideas like Jacobson’s, not the UML version, as the primary meaning of “component”.

2 Development methods

So far we’ve defined the terms in the title of the course, and given some idea of why we should be interested in each of them. But how do they fit together? We’ve briefly discussed the relationship between objects and components, and why components are desired by software engineers. We haven’t discussed how software engineers can use (or create) components, nor what object oriented software engineering might be.

It’s possible, and used to be common, to use object orientation as a programming technique within a conventional, data and functionality based, software engineering process.

2 DEVELOPMENT METHODS  16/10/97  2.1 History: The Three Amigos

More feasibly, one can use a conventional structured analysis method with object oriented design. (This is what BT used typically to do in the late 80s, for example: by the early 90s, when I was there, a concensus had pretty well formed that experience had shown that it was better to use an all-OO development.) However, the main benefits of object orientation come from a close and clear connection between system objects and problem domain objects; this is easiest to obtain if the whole development process focusses on objects. That is, rather than identifying separately the functionality of the system and the data on which it operates, we identify the key problem domain entities which have, naturally as it were, both state and behaviour. Moreover, using an iterative method requires a process with no watersheds to prevent you from revisiting and revising decisions made earlier.

2.1 History: The Three Amigos

The methods war As object orientation has become fashionable, and now has moved through from being fashionable into the mainstream of softwar development, a plethora of object oriented development methods has naturally been put forward, each with ideas and notations which overlap, but are not identical. Three of the most popular (my guess is, in this order) were:

1. Grady Booch’s method, occasionally called OOD

2. James Rumbaugh’s OMT

3. Ivar Jacobson’s OOSE and Objectory

(Each had a major book which appeared in the early 90s). As you see, each method is championed by a single inventor, who in each case is a highly experienced and respected expert in the field of OO development. Like most people, I expected that we would for the foreseeable future have more or less this situation, the “methods war” with each method having its proponents.

The methods war is over: we won However, it isn’t turning out that way. Booch was and is in charge of Rational Software (yes, the developers of Rose). In 1994 Rumbaugh also joined Rational, and the two of them declared that they intended to merge their methods. (Fowler’s nice phrase is “achieve standardisation the Microsoft way”.) Needless to say, the rest of the software industry wasn’t too happy about this.

But resistance was futile. In 1995 Rational bought Ivar Jacobson’s company Objectory, and it was all over bar the shouting. An early draft of documentation for the so-called Unified Method was produced (and volubly discussed on comp.object, of course, as well as elsewhere. Unfortunately by that time I was trying to get to grips with this strange new – to me – programming language, ML, and missed most of the fun!)

Later the focus was shifted away from developing a unified method towards developing a unified modelling language, and so we have UML, which has been submitted for ratification by the OMG. Interestingly, there is still a common process, called Objectory after Jacobson’s method, but incorporating ideas from all three people. More on this in a moment, since we’ve raised the question of what a development method is, and what a modelling language is, and what the significance of the shift is.

2.2 What is a “development method”?

A development method prescribes a process for developing software, which implies that it prescribes a particular life-cycle for the product. You’ve probably seen at least two different life-cycles:

2 DEVELOPMENT METHODS  16/10/97 2.2 What is a “development method”?

Waterfall model

[figure: Analysis; Design; Coding; Testing; Integration]

Slide 13

Problems with waterfall (Boehm 86)

• The waterfall model does not adequately address the concerns of developing program families and organizing software to accommodate change.

• The waterfall model assumes a relatively uniform progression of elaboration steps

• The waterfall model does not accommodate the sort of evolutionary development made possible by rapid prototyping capabilities and 4th generation languages

• The waterfall model does not address the possible future modes of software development associated with automatic programming capabilities, program transformation capabilities, and ‘knowledge based software assistant’ capabilities.

Slide 14

(See reference Boehm) Note that Boehm was writing more than ten years ago, and that “automatic programming capabilities” are no longer a “possible future mode of software development” – although for various practical reasons (cost of the tools, and the fact that with current techniques you need a very detailed design to take advantage of them) automatic programming capabilities, or code generation, is still not common, it is a reality. For example, it’s part of what Rose can do.

Iterative development

[figure: Analysis; Design; Evolution; Modification]

Slide 15

However, this isn’t the end of the story. This purely iterative approach works well for small, fast developments, but even there, there will be a stage before the project is definitely decided on, and a stage after it has been “finally” delivered, which it’s sensible to separate out. It’s also normally essential, for management and political reasons, to have a plan for what the iterations will be and what will be covered by each, rather than simply taking as many as a required. The Objectory process puts its main spiral inside its Construction phase:

Objectory process

Inception ends with commitment from project sponsor to go ahead: business case for the project and its basic feasibility and scope known.

Elaboration ends with

• basic architecture of the system in place,

• a plan for construction agreed

• all significant risks identified

• major risks understood enough not to be too worried

Construction (definitely iterative) ends with a beta-release system

Transition is the process of introducing the system to its users

Slide 16

These phases may differ wildly between projects in how long they take and what their deliverables are. For example, for a small or straightforward project (or one with a laid-back sponsor!) the inception phase might be a development manager having a short chat with the project sponsor. At the other extreme, it might require a series of high-level board meetings and a formally signed off business case. (Remark: Fowler seems to put less in the Inception phase than the Rational web site suggests.)

The book (“The Objectory Software Development Process”) was due to be published this Autumn, like the UML user guide and reference manual: but I see that all have now been delayed to next Spring or Summer. In the meantime there is a high-level description of the process on the Rational web site. We will not say much more than this about any particular process in this course, although in the final section we will discuss (at the metalevel, if you like) the desirability of having a defined process (how defined, and by whom?) and the implications and problems.

I think that unification of process will be much harder and more interesting and less likely to happen in reality than the unification of modelling languages, because it will have to either expose, solve or fudge real differences of approach between the three people.

For example, something which is not really discussed in any of my favourite OO books (or any others I know) is the question of the level of abstraction at which each iteration happens. For example, both the Booch method and Jacobson’s OOSE involve an iteration in which each iteration includes a complete analysis, design, implement, test cycle. The obvious thing is to assume that these methods agree on the point. However, this is not really so. Jacobson makes an important point of the idea that each iteration should deliver the functionality of at least one new use-case (see next lecture) – that is, in each iteration we change the system resulting from the previous iteration enough to add some new user-level functionality. His iterations are vertical slices through the eventual system, though he does recognise that the way in which a piece of functionality is delivered may change in later iterations.

Booch, on the other hand, is careful not to be rigidly prescriptive; indeed, although people talk about “the Booch method” it’s arguable that this isn’t a process so much as a discussion of how to go about design, together with an (extremely useful) collection of techniques. (It certainly does not have the scope to be, without alteration, a Methodology in the sense of the Heffalump Trap below, which we may consider an advantage!) However, his iterations are presented in the context of what he calls “round-trip gestalt design”, capturing the idea that design neither top-down nor bottom-up. An iteration need not deliver new user-level functionality, indeed, will often not result in an implemented system at all. It may instead move you down to a lower level of abstraction, deepening rather than widening your understanding of the system.

Whichever process we choose, we need a language in which to express our designs, and this should almost certainly be diagram-based, since experience suggests that’s how we naturally think about systems. It’s inconceivable that a single diagram could capture everything about our design; and indeed that might not be desirable, since we probably want to abstract different aspects of interest in different contexts. So we will build different models of our design, reflecting different aspects, and will express each model using a diagram.

Models of a system

We will want to distinguish models on several axes. For example:

• A static model describes the elements of the system and their relationships

• A dynamic model describes the behaviour of the system over time

Again, we may take a

• logical view: which parts notionally belong together?

• physical view: which parts will run on the same computer?

We probably won’t need to fill in all the squares...

Slide 17

Crucial point: The diagram is not the design: the diagram is a model of the system designed – it captures the design in a form which can be discussed.

This implies, for example, that when you draw several diagrams to do with one design, there will be burdens of consistency checking: it is essential that all your diagrams really are models of one design, which will of course not be possible for arbitrary collections of diagrams! (For example, if your static structure diagram shows that Class Foo has no relationship with Class Bar, your dynamic diagram had better not show an object of class Foo sending a message to an object of class Bar.) Some of this consistency checking can be automated (see Check Model on Rose’s Tools menu, for example).

There is an interesting question about the sense in which the notation can be given a rigorous or formal semantics, and this has been partly addressed by the developers of UML: but I’m not going to go into that here.

Is a unified modelling language, and/or a unified method, a good idea? You decide. I think the UML is a good idea, given that the language is big enough to encompass quite a wide range of models: I’ve been in the situation of finding it hard to talk to someone about their design because I didn’t understand the notation in which they’d expressed it, and that seems silly. Probably more important even than communication between individuals: some kind of modelling language is probably essential for describing large components. So if we want to do component-based software engineering, we don’t want to be impeded in our search for suitable components by the fact that we don’t understand their descriptions. So we’d better have a single modelling language for describing them. On the other hand the idea that there will be a single method (so that, say, you might not be able to claim to be doing a professional job of object oriented development unless you were doing it their way) I find a bit scary. It depends a lot on what the method looks like, and how prescriptive it is.

What is a good modelling language?

It should be:

1. Expressive enough: that is, we can express important aspects of the design, and we can meaningfully reflect changes in the design which we make during analysis and design as changes in the models

2. Easy enough to use, so that it aids clear thought rather than getting in the way

3. Widely used?

4. Supported by suitable tools?

5. Unambiguous

Slide 18

Fowler quotes as “an old joke”: Q: What’s the difference between a methodologist and a terrorist? A: You can negotiate with a terrorist.

Be aware that there are different, possibly conflicting sets of interests around.

1. The interests of the methodologists (in this case, Rational!) are in convincing you that their method will solve all your problems, and that if you follow their method you won’t have to think about this. If your managers believe this, they will buy the Methodologists’ tools and training, and the Methodologists will become rich

2. The interests of the users of the system are complex: on the one hand, they want a reliable cheap system quickly. On the other hand, they also want to be able to get their future systems...

3. The interests of the developers are to keep their jobs, and to keep their jobs interesting. Does this conflict with 1?

4. The interests of the managers, again, are complex. They need to satisfy their customers, but not at the expense of future customers.

We’ll come back to these issues in the final part of the course when we consider such “people issues”. In the mean time, you might like to have a look at Rational’s Objectory pages, bearing in mind that they are methodologists.

Heffalump Trap 1

Don’t be seduced by Methodology

There is a big difference between methodology and Methodology. A methodology is a basic approach one takes to get the job done, consisting of:

• a tailored plan (specific to the work at hand)

• a body of skills necessary to effect the plan

A Methodology is an attempt to centralize thinking. All meaningful decisions are taken by the Methodology builders, not by the staff assigned to do the work. The overt case for the Methodology includes standardization, documentary uniformity, managerial control and state-of-the-art techniques. The covert case is simpler and cruder: the idea that project people aren’t smart enough to do the thinking. (adapted from Peopleware p115)

Slide 19

New references

Peopleware: productive projects and teams Webster, Bruce F. Pitfalls of Object-Oriented Development M and T Books Boehm, B. A spiral model of software development and enhancement Aug 86 Software

Engineering Notes, vol 11 (4) p23