\underline{15 REUSE 4/12/97}

15 Reuse

Finally, let’s come back to the title of the course, specifically to components and review what we’ve done and what the effect may be. Recall that a component is, essentially, something which it’s possible to reuse.

The term reuse covers any situation in which work done for one software project is used to help another. Interpreted broadly this may even include any use of any software library!

Reuse

1. What can we reuse?

2. What are the dangers of ill-thought-out reuse?

3. Why is it hard to achieve high levels of reuse?

4. What are the characteristics of genuinely reusable components?

5. When can we do the extra work that making reusable components involves?

6. What difference does object orientation make?

7. What are the motivations for achieving high levels of reuse?

8. What are the interactions between quality culture and reuse?

Slide 95

What can we reuse?

• Most obviously, code: classes, functions

• Designs, even sections of analysis: remember design patterns

• Documentation, e.g. standard bits of user manuals?

• Tests, e.g. what happens if we run out of memory/disk

• (expertise, tools – may or may not count these as reuse)

Slide 96

Reuse can be achieved in a variety of different ways. Most simply, we can cut and paste. Code reuse is just about the only area in which anything else is regularly and consciously done (though Design Patterns may change this).

Code is often split into chunks intended to be self-contained enough for easy reuse and placed in a library – in OO, typically a class library. The library may be a commercial product, or an internal resource of varying degrees of organisation and formality.

Note that in OO reusing a component may not mean putting up with its functionality just as it is: a class can be reused by using it as the base class of a more specialised class. (See Open/Closed principle below).

What are the dangers of ill-thought-out reuse?

• It may not work – and if you didn’t write it, it’s easy for it to be harder to debug it than it would have been to write it in the first place

• It may not do exactly what you want, and you may end up twisting the requirements to fit what’s available (but beware: this is the classic excuse for never doing any reuse at all!)

• You may end up with many slightly incompatible versions of the same thing, which can be horribly confusing.

• It may work, but not be properly documented, and you may misunderstand it.

• You may have to import things you don’t need along with the functionality you want to reuse, getting software bloat.

Slide 97

Why is it hard to achieve high levels of reuse?

• It’s harder to reuse components the bigger they are

• Change may make “reusable” components outdated so they never get reused: any extra effort involved was wasted

• Avoid duplicating OS or library facilities: the easiest “reusable” things to build are useless because the functionality is already conveniently available (buying is almost always better than building)

• Finding the right thing, even when it’s there! Once component libraries get bigger than a few hundred things the searching problem is very serious

• NIH syndrome – not invented here! (Justifiable? Whose head is on the block if it doesn’t work?)

Slide 98

In the extreme, aiming for high reuse can be a sink for arbitrary amounts of effort, caricatured by Julia Vowler in Computer Weekly (11/1/96):

And if all this doesn’t keep you busy this year, then you could always launch a corporate object-oriented strategy, and spend the next five years defining every single business object in the organisation, and coding it into C++. By the time you finish they will all be available from third parties for sixpence each off the Internet.

So, most importantly, high levels of reuse can be achieved in the context of component based development: building things to reuse is a higher risk activity than buying things that somebody else built.

What are the characteristics of genuinely reusable components?

• sufficiently general, in the right way!

• properly documented with specification

• thoroughly tested

Not only does it cost, but it’s hard, and if you get it wrong the cost is wasted.

Slide 99

So there is some extra work to be done to make things reusable: e.g., a component has to be documented much more thoroughly if it is to be used later by people outside the project in which it was built, than if the documentation is only intended to be read by people who know a lot about the context and the current project.

When can we do the extra work that making reusable components involves?

Possibly the single main reason why reuse efforts fail is that the answer is “we can’t”. Here are some options (classification of Henderson-Sellars and Pant, Object World, 93):

• End of project: hard to find resources?

• G-C1 model: before delivery, so customer pays

• Two-library model: as time permits (will people remember?)

• Alternative core-technology model: permanent team to do reuse work (but are they the best people to do it, do they understand the components?)

Slide 100

What difference does object orientation make?

• OO encourages the high cohesion/low coupling style that is anyway good practice

• Object oriented analysis concentrates on problem domain objects, which are more stable than the functionality of a particular application.

• Aside from stability, problem domain objects are more likely to occur in several different contexts than functionality on them. A company can develop a collection of business objects reflecting the common entities in their own business.

• Inheritance allows developers to use the Open-Closed rule – develop classes that are both closed (usable now) and open (extensible/modifiable later). Maintenance done on a base class can automatically affect subclasses.

• Working in terms of objects makes missing but “obviously sensible” functionality more obvious.

Slide 101

One of the main claims for object orientation is that it enables higher levels of reuse than traditional software development methods. People do quote reuse percentages – sometimes as high as 70 percent – but beware, these are practically meaningless without a good definition of what’s being measured!

What are the motivations for achieving high levels of reuse?

• saves money … $$$$ …

• improved reliability, by cumulative debugging of reused components

• reduced market cycle time (quicker development)

• reduced effort (ditto)

• encourages modularity [Christmas tree unreproducable here, sorry]

Slide 102

What are the interactions between quality culture and reuse?

• Can reuse help us to achieve high quality software? Perhaps, by improving reliability and encouraging good modular design (see above)

• Can reuse prevent us from achieving high quality software? Perhaps, by encouraging us to bend the requirements to fit the available components.

• Can encouraging high quality (how?) enable reuse? High quality components are more likely to be reusable, and if things are routinely well documented and tested the gap between normal and “reusable” components may be less.

• Can encouraging high quality (how?) make reuse difficult? Well, a too-rigid quality assurance program can make reuse difficult to achieve, e.g. because a reused component may not have been built according to the current QA regs: is it OK to reuse it?

Slide 103

Major challenge for quality assurance: allow for component based design in a way which is flexible enough to get the benefits of reuse, but without compromising the quality of the product (too much).