Programming in the large Bertrand Meyer Chair of Software - - PowerPoint PPT Presentation

Programming in the large - Lecture 21

1

Chair of Software Engineering

Programming in the large

Bertrand Meyer

Last update: 21 June 2004

Programming in the large - Lecture 21

2

Chair of Software Engineering

Lecture 21: Software lifecycle models

Programming in the large - Lecture 21

3

Chair of Software Engineering

Arguments for the waterfall

(After B.W. Boehm: Software engineering economics) The activities are necessary

(But: merging of middle activities)

The order is the right one.

Programming in the large - Lecture 21

4

Chair of Software Engineering

DESIGN AND IMPLEMENTATION

The waterfall model of the lifecycle

FEASIBILITY STUDY

PROJECT PROGRESS

REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION DISTRIBUTION

Programming in the large - Lecture 21

5

Chair of Software Engineering

Problems with the waterfall

Late appearance of actual code. Lack of support for requirements change — and more generally for extendibility and reusability. Lack of support for the maintenance activity (70%

• f software costs?).

Division of labor hampering Total Quality Management. Impedance mismatches. Highly synchronous model.

Programming in the large - Lecture 21

6

Chair of Software Engineering

Quality control?

Analysts Designers Implementers Testers Customers

Programming in the large - Lecture 21

7

Chair of Software Engineering

Impedance mismatches

As Management requested it. As the Project Leader defined it. As Systems designed it. As Programming developed it. As Operations installed it. What the user wanted.

(Pre-1970 cartoon; origin unknown)

Programming in the large - Lecture 21

8

Chair of Software Engineering

The Spiral model (Boehm)

Figure from: Ghezzi, Jazayeri, Mandrioli, Software Engineering, 2nd edition, Prentice Hall

Programming in the large - Lecture 21

9

Chair of Software Engineering

The Spiral model

M.C Escher: Waterval

Programming in the large - Lecture 21

10

Chair of Software Engineering

Tasks

Analysts Designers Implementers Testers

Programming in the large - Lecture 21

11

Chair of Software Engineering

Seamless development

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes Specification

Programming in the large - Lecture 21

12

Chair of Software Engineering

Seamless development

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes

Design

Specification

STATE, USER_COMMAND...

Programming in the large - Lecture 21

13

Chair of Software Engineering

Seamless development

Implementation

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes

Design

Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

Programming in the large - Lecture 21

14

Chair of Software Engineering

Seamless development

Implementation

V & V

TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER, ...

Example classes

Design

Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

Programming in the large - Lecture 21

15

Chair of Software Engineering

Seamless development

Implementation

V & V

TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER, ...

Example classes

Design

Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

Genera- lization

AIRCRAFT, ...

Programming in the large - Lecture 21

16

Chair of Software Engineering

deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is

• - Fill the vat.

require in_valve.open

• ut_valve.closed

deferred ensure in_valve.closed

• ut_valve.closed

is_full end empty, is_full, is_empty, gauge, maximum, ... [Other features] ... invariant is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum) end

Analysis classes

Programming in the large - Lecture 21

17

Chair of Software Engineering

Reversibility

S V D I S G

Programming in the large - Lecture 21

18

Chair of Software Engineering

Seamless development

Use consistent notation from analysis to design, implementation and maintenance. Advantages: Smooth process. Avoids gaps (improves productivity, reliability). Direct mapping from problem to solution, i.e. from software system to external model. Better responsiveness to customer requests. Consistency, ease of communication. Better interaction between users, managers and developers.

Programming in the large - Lecture 21

19

Chair of Software Engineering

Single model principle

Use a single base for everything: analysis, design, implementation, documentation... Use tools to extract the appropriate views.

Programming in the large - Lecture 21

20

Chair of Software Engineering

The cluster model

I

V

D

S G

I

V

D

S G

I

V

D

S G Cluster 1 Cluster 2

I

V

D

S G Cluster n

I

V

D

S G

I

V

D

S G

Feasibility study Division into clusters

Programming in the large - Lecture 21

21

Chair of Software Engineering

The cluster model: extreme variants (1)

“Clusterfall”

I

V

D

S G

I

V

D

S G

I

V

D

S G

Cluster 1

I

V

D

S G

Feasibility study Division into clusters Cluster n

Programming in the large - Lecture 21

22

Chair of Software Engineering

The cluster model: extreme variants (2)

“Trickle”

I V D S G

Cluster 1 Feasibility study Division into clusters Cluster n

I V D S G I V D S G

Programming in the large - Lecture 21

23

Chair of Software Engineering

Generalization

Prepare for reuse Possible tasks: Remove built-in limits Reorganize inheritance hierarchy Abstraction (e.g. introduce deferred classes) Improve documentation

Programming in the large - Lecture 21

24

Chair of Software Engineering

Cluster development

Bottom-up development: from the most general clusters (providing utility functions) to the most application-specific ones. Flexible scheduling of clusters – depending on resources, team experience, customer and management demands. Waterfall is one extreme; “trickle” is the other. Sub-lifecycle sequencing: specification, design and implementation, validation, generalization. Relations between clusters: each cluster may be a client of lower-level ones.

Programming in the large - Lecture 21

25

Chair of Software Engineering

Quality goals: the Osmond curves

Envisaged Release

Desirable

Other qualities

Functionality

Common

1 2 3 4

Programming in the large - Lecture 21

26

Chair of Software Engineering

The advice

Add functionality at constant quality

Programming in the large - Lecture 21

27

Chair of Software Engineering

Complementary material

OOSC2: Chapter 28: The software construction process

Programming in the large - Lecture 21

28

Chair of Software Engineering

End of lecture 21