CS 446 Notes 1, 25Sept 1996
Notes for CS 446-1 Fall Quarter 1996-1996 Gio Wiederhold and David Luckham.
Experimental Seminar on Large Scale Software Construction.
We are to meet in Gates 459, but since it is small, we are sure to
have to move to larger quartrs (likely Gilbert 119).
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 one half hour, to leave the remainder for
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,
The topics in building large scale software can be placed in
Process Model: the steps in developing software
Interwoven with that are topics as
- A system architecture
- Module acquisition (purchase or programming)
- Module testing
- System testing
- System adapatation or maintenance
- System replacement
that occur in all phases.
- Design validation
- Performance prediction and measurement
New tools and technologies are emerging that address thise topics,
but no coherent overall structure exist yet. There also still many
disagreements on the validity and scope of these technologies.
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
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.
Maintenance: unscheduled work to fix bugs (10%?),
adapt SW to externally mandated changes (tax rules, company cahnges
and policies, growth, interfaces with another product) or functional
changes needed to keep customers.
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?
A big problem is maintenance: it amounts to 80% of SW cost,
and is 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):
The waterfall model creates isolated structures, or
that do not take module interchange and reuse into account
- 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. Often cvalled a
appraoch. It is also used in visual programming. Windows model.
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.
Each of these alternatives of system construction implies a certain
process. These processes have been promted by various agencies
(USC software center [Barry Boehm] for the Spiral model,
SEI Software Maturity Model, ISO 9000 standard).
For these various design approaches tools are needed, and here is where
some science can come in: Specification languages, architecture
definition languages, object-oriented apparoaches.
A scientific approach requires feedback, and hence metrics. There is
some resaerch in that area [Victor basili @ Un.of Maryland], but
little measurement is done in practical software engineering.
Examples of systems of interest to us
- Long-lived systems: DOS, FORTAN, OS, SABRE (airline reservations)
- Legacy systems (valuable resources, but not up to modern standards):
databases with valuable contents as Stock prices, employee records
- Persistent systems: FAA TAAS for air-traffic control, phone switching systems, refinery control
- Rapidly configurable systems (DARPA PSOS initiative)
- Secure systems
end of note 1996-1. Go back