1 DEFINING TERMS

1 Defining terms

1.1 Software Engineering

A doctor, a civil engineer and a software engineer were arguing about what was the oldest profession in the world. The doctor remarked, “Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world.” The civil engineer interrupted, and said, “But even earlier in the book of Genesis, it says that God created the order of the heavens and the earth out of the chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world.” The software engineer leaned back in her chair, smiled, and then said confidently, “Ah, but who do you think created the chaos?”

What is software engineering?

We make an analogy between the development of systems (actually, not necessarily exclusively software systems) and the development of, say, an engine or a bridge (hereinafter “engine” for short).

Specifically:

• use a defined process, with clear phases each of which has an end-product (system specification, test spec, whatever)

• concerned with meeting a clear set of requirements defined at the beginning of the project, so

• regard testing (and more generally, verification and validation) as just as essential as building the product itself

• use a store of relevant knowledge (and components?)

• make sensible use of tools

Slide 1

1 DEFINING TERMS  1.1 Software Engineering

Why do software engineering?

So what’s so great about an engineering approach to software? After all, software isn’t a physical object, it doesn’t have to be manufactured – it’s pretty different from most engineered artifacts. It’s clear we have a problem. (Ariane 5, Taurus, Denver baggage handling system, ...) But is an engineering approach a solution? Discussion point: what are the similarities and differences between software and engines, and the way they’re developed? What should they be?

Slide 2

1.1.1 The problem We have a software crisis that doesn’t seem to want to go away. There are numerous well-known examples, and you probably know others. For example:

• Ariane 5

• Taurus

• Denver baggage handling system

• CONFIRM travel booking system

• ...

According to Scientific American, September 94:

• On average, large projects take 50% longer than they were planned to do

• Three-quarters of large projects are operational failures

• One-quarter of large projects are cancelled (My tertiary source for this: Larry Paulson’s notes on software engineering, which towards the beginning have some good notes on several software disasters: see link on course home page.)

1.1.2 Similarities and differences between software and engines: Here’s a conglomeration of things people did say in the meeting and things I expected them to say about the similarities and differences between software and “other engineered artifacts”.

Similarities • Designed to solve a problem

• May have to recall faulty products

• May fail under unforeseen circumstances

• Expensive to develop

• Disastrous to get wrong: severe consequences in terms of – lives

– money

– business reputation (and hence survival)

– jobs

– time Differences:

1. Defining the problem to be solved is usually much harder for software than for engines. Therefore: will get it wrong, and pay the price.

2. No (interesting) “manufacturing” (replication) stage – more like building a bridge than building an engine. What about mass-produced word-processors etc.? Why do I say this isn’t really “manufacturing”?

3. Software is an “invisible medium” in the sense that unless we take positive steps to alter this, the customer and the product won’t meet till very late in the development. But:

4. prototyping (building something as a demonstration) may actually be easier in software than hardware: use this to mitigate the previous point.

5. Software can be arbitrarily complex

6. Therefore people often consider software to be much more fluid than a physical artifact: customers may expect, and developers may promise, very high levels of flexibility, late changes, etc. Combined with (1), get

7. Defining interfaces may be harder for software than hardware, partly because of the (mistaken?) perception that it’s easier to change software interfaces.

8. If software has a fault, it’s there all the time in every copy: concepts like “1 in 10000 units has a fault” aren’t meaningful.

9. Software failures are usually repeatable, and often catastrophic: “graceful degradation” is the exception rather than the rule.

10. Software has no theory of tolerances.

11. Software may be temporarily broken: sometimes restarting it can make it just as good (or bad) as it was before (compare and constrast kicking the television when its screen goes fuzzy).

12. Software doesn’t wear out (though it may become obsolete when, e.g., operating systems change – but that’s not the same, is it?)

13. Maybe software failure tends to be less noticeable than engine failure? Is this true? If true, is it just an effect of the cultural expectation that software will fail? People tend to be more tolerant of software failure?

1 DEFINING TERMS  1.2 Modules

14. Quality of raw materials – in particular, the idea of using different versions of a material of different qualities to match the desired quality of the end product – doesn’t really have a counterpart in software. (But might it, if we really had a wide variety of components?)

15. The tools we use to develop software are more likely to be faulty themselves than the ones we use to develop other engineered artifacts.

16. Can’t exhaustively test most software. (Think about the senses in which this is something you can’t do for engines, etc., either. But you can take it through one representative of every equivalence class of situations where it should perform??)

1.2 Modules

Before we go on to questions about objects and components, let’s revise a question you covered in PM:

What is a module?

A piece of code with a well-defined interface which encapsulates some information about the code. E.g.

• subroutine!

• library function

• ML module

• Class

• Component

But this is no use unless we have the right modules with the right interfaces.

Slide 3

Why use modules?

Already in 1965, Edsgar Dijkstra was explaining that software systems beyond a certain size are too complex to be completely understood by any one person. So aim of modules is to increase

• the understandability of the code, and hence

• the probability of correctness, and

• the ease of maintenance.

To achieve this: a module should be meaningful. More specifically, it should have high cohesion and low coupling.

Slide 4

Dissenting voices

Not for the last time, we’ve given one definition of a term when there are others. Another widely used definition of module – supported by language concepts in e.g. Ada – is that it is a physical collection of code, even a unit of compilation. But there is normally still an expectation of a clear interface, and we will take that as the defining feature. On the third hand, Meyer says that a step to Object Oriented Happiness is to obey the maxim: “Every non-simple type is a module, and every high-level module is a class.” Q: What does this mean?

1 DEFINING TERMS  1.3 Objects

Slide 5 Here are two more definitions:

1. From the glossary of Booch:

module A unit of code that serves as a building block for the physical structure of a system: a program unit that contains declarations, expressed in the vocabulary of a particular programming language, that form the physical realization of some or all of the classes and objects in the logical design of the system. A module typically has two parts: its interface and its implementation.

2. From Liskov, B. 1980, A Design Methodology for Reliable Software Systems, in Tutorial on Software Design Techniques. 3rd ed. New York, NY:IEEE Computer Society, p66 (quoted by Booch):

modularization consists of dividing a program into modules which can be compiled separately, but which have connections with other modules. We will use the definition of Parnas: ‘The connections between modules are the assumptions which the modules make about each other’ ”

Actually, we’re probably happier with Parnas’ definition than with Liskov’s addition! It does raise an interesting question, though, which we will notice and then largely pass by:

What is an interface, anyway? In what sense do we expect it to document the assumptions that may be made about modules? Doesn’t this sound like a real specification, rather than just the names and signatures of the functions? But the latter is all we normally get in present-day interfaces.

1.3 Objects

What is an object?

Something you can do things to.

An object has state, behaviour and identity.

State can affect behaviour.

Behaviour can affect state.

Objects communicate by sending messages: the behaviour of an object on receipt of a message is “up to the object”.

A class defines the structure and behaviour of similar objects. (That is, their implementation, not just the interfaces they provide.)

Slide 6

Let’s look at that definition of an object a little more closely. It’s drawn from Booch, and I’m going to use Booch’s examples and definitions quite extensively here because I think they’re the best I’ve seen.

So what’s a thing, anyway? Clearly not just a physical thing, though many objects do represent physical things – and it’s worth remembering that the first time objects arose explicitly was in Simula, where they did represent real world objects, the objects being simulated. The crucial property of an object is that it has well-defined boundaries. These are conceptual boundaries, not necessarily physical ones. Q: Which of these might be objects: hammer, sphere, chemical process, love, fog, river, anger, cat, greyness, grey cat?

State: properties of an object together with values of those properties. For example; if we consider the property “number of orders placed” its value may be 3. Every property has a value. Some properties will have static values: that is, the value of the property will not vary during the lifetime of the object. Other properties will have dynamic values.

Behaviour: the way an object acts and reacts, in terms of its state changes and message passing.

Identity: (a slightly controversial aspect). That property of an object which distinguishes it from all other objects. That is, objects are not just values. An object has a continuing existence: if our application refers to two objects each of which has a string property with value “Edinburgh”, it makes sense to ask whether they are the same object or not. (Whereas, for example, if the constant string “Edinburgh” occurs twice, it doesn’t.^{1} This is probably only controversial if you are a pure functional programmer; and there are some distinguished ones who say you can do OO in a purely functional way. To me, this seems pretty pointless, but maybe someday I’ll be convinced...

Why use objects?

Things people hope to get from objects include:

• Reduced costs, especially

– maintenance costs

– costs of later similar systems, via reuse

(More controversially: reduced cost of first system??)

• Reduced (average) time to market

• Increased reliability

• Match users’ model of the world, so

– capture requirements more easily and accurately

– follow changes in user requirements better

– allowing more naturally interacting systems: direct manipulation etc.

Slide 7

1(Unless you’re programming in Smalltalk, in which case you have to understand mutable constants!)

Next time

No meeting on Monday!

Instead, I’d like you to:

1. do some basic playing with Rose. Use the on-line help (which is the best place to start) and the UML tutorial.

I’m not expecting you necessarily to finish this, or to end it knowing UML! I just want you to be confident using Rose from the start. Feel free to experiment. Any problems, ask (me or each other).

2. fill in the short Web questionnaire which will (by Monday) be on the course home page.

Next Thursday, back here for more advanced OO concepts.

Slide 8

See notes on course home page on using Rose.

Today’s new references

Started with a version of a very old joke: this version translated from the American of Booch’s heading to Chapter 1 of the very important book Booch, G. Object Oriented Design with Applications, Benjamin/Cummings

– now (sadly?) replaced by various separate books by Booch – bu also, Objectory book by Booch, Rumbaugh and Jacobson coming soon: it may be worth not purchasing any book on OO just now.) Dijkstra, E., Programming considered as a human activity, in Proceedings of the 1965 IFIP Congress, pub. North Holland. Anything from Programming Methodology Basic object concepts from Software System Design Dilbert Sunday Strip, 28/9/97 (relevant to the questions we considered today).