CS 446 Notes 1, 27Sept 1995
Notes for CS 446 -1 Fall Quarter 1995-1994 Gio Wiederhold
Experimental Seminar on Large Scale Software Construction.
We are meeting in History Corner 124, A pleasant room, but was overfull.
Since some students left early, let's see what attendance is next Monday, if it
stays too full, we'll have to request a larger room.
Format: Small (graduate mainly) seminar.
Undergraduate attendance by consent, based on prior software experience.
Readings and reports by participants. Some presentations by outside,
mainly non-academic experts. Extensive time for critique of read and
presented material. Design of an experiment to adapting an existing
large software system to another task. Preparation of a report to
guide further work and research. Creation of critically annotated
Presentations limited to half of class period, remainder
discussion, analysis, synthesis, generalization. Notes will be
provided at every class, including results from the prior class'
Large scale software (LSSW) construction is characterized by concerns for
longevity, maintenance, and continuing adaptation tochanging environments. We
can assume that LSSW always uses multiple, dispersed, and heterogeneous
computing platforms: hardware, operating systems, communication protocols.
The programming issues of LSSW differ from those that progamming and data
structures focus on. One characteristic is incoherence / coherence of
structures, control, ontologies, changes, and authority.
Needed are new concepts to unify existing peoposals and experience.
What are the problems of scaling programming up? What are the
problems of top-down design. Can existing programs become new building
blocks for composition? How can new methods be established, measured,
Software Engineering: A disciplined approach to construction of software,
invented in 1970. Is there a better term to include maintenance?
Architecture: Components plus principles or rules for their assembly.
[GarlanSOSS:92/94]: Roman Temple vs. gothic cathedral vs Buckminster
Maintenance: unscheduled work to fix bugs (10%?),
adapt SW to externally mandated cahnges (tax rules, company cahnges
and policies, growth, iterfaces with another product) or functional
changes needed to keep customers.
Specification: Initial wishes, must be understood by customer and
Integration: Assembling systems mainly out of existing packages or services (often remote). Thess tasks require no or little coding in a programming language that gives control over most hardware features. It's become
a larger fraction of the workforce.
SW Validation: satisfies the customer?
What does that mean? What is the contract?
SW Verification: meets the specifications.
How complete can specifications be?
How can they be expressed?
Big problem is maintenance: 80% of SW cost, not addressed in most
CS classes. See Maintenance is good
for you Report on the topic Mediation and
Current technologies [Blum: Software Engineering, A Holistic View
Oxford 1992, Chapter 1&2] Approaches to Software Design using
There are problems with the Engineering approach.
Waterfall model, with (LSSW):
- 1. Requirements specification ->
- .... 2. Overall design -> (Partitioning ->)
- ........ 3. Detailed Designs ->
- ............ 4. (Module) code and debug ->
- ................ 5. (Module) test ->..
- ................ 5B.(Integration -> Integration test ->)
- .................... 6. Preoperation and validation ->
- ........................ 7. Delivery ( and installation ) ->
............................(here end most engineering concerns)
- ............................8. Operation and Maintenance
............................................ (~80 of cost) .
Spiral models = A cyclical waterfall, with feedback from phase 6
-> 3 or 2 or 1 [Boehm; IEEE Computer Vol.21 No.5 May 1988, pp.
61-72.] When in the spiral is the product real? When is it
Growing systems: how can systems be augmented after operation? How
does that affect the waterfall or spiral?
(Rapid) prototyping: always build a throw-away system. Feasible?
What can be left out? Validation of prototype versus real system?
What are the risks for the real system? How can the real system be
validated if there is more to it? How long can the prototype operate?
Can one grow systems from functional prototypes.
Composition: Rapid assembly of LSSW from (largely) pre-existing
modules. Visual programming. Windows model. Materialization of
scripts. Rebuild LSSW insteadof maintenance? Effect on customers?
Here components are services: nearly imutable, not owned by programmer.
Negotion needed for changes.
Example of a service: A database.
end of note 1.