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.

Admin.Intro

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 bibliography.

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' discussion.

The Problem:

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, validated?

Definitions:

  • 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. Requires standards.
    Example: [GarlanSOSS:92/94]: Roman Temple vs. gothic cathedral vs Buckminster Fuller dome.
  • 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 implementor.
  • 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 Software Maintenance.

    Current technologies [Blum: Software Engineering, A Holistic View Oxford 1992, Chapter 1&2] Approaches to Software Design using 'Engineering Principles'

    There are problems with the Engineering approach.

    Design models:

  • Waterfall,
  • Spiral,
  • Rapid prototyping,
  • Composition
  • other

    • Waterfall model, with (LSSW):

    1. 1. Requirements specification ->
    2. .... 2. Overall design -> (Partitioning ->)
    3. ........ 3. Detailed Designs ->
    4. ............ 4. (Module) code and debug ->
    5. ................ 5. (Module) test ->..
    6. ................ 5B.(Integration -> Integration test ->)
    7. .................... 6. Preoperation and validation ->
    8. ........................ 7. Delivery ( and installation ) ->
      ............................(here end most engineering concerns)
    9. ............................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 validated?
    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.