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

Admininstrative Introduction

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 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' 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?

Topic categories

The topics in building large scale software can be placed in Process Model: the steps in developing software
  1. Requirements
  2. Specifications
  3. A system architecture
  4. Module acquisition (purchase or programming)
  5. Module testing
  6. Integration
  7. System testing
  8. System adapatation or maintenance
  9. System replacement
Interwoven with that are topics as that occur in all phases.
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.

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.
  • 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.
  • 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 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) .
    The waterfall model creates isolated structures, or Stovepipes, that do not take module interchange and reuse into account

    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. Often cvalled a Client-Server appraoch. It is also used in 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.

    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

    1. Long-lived systems: DOS, FORTAN, OS, SABRE (airline reservations)
    2. Legacy systems (valuable resources, but not up to modern standards): databases with valuable contents as Stock prices, employee records
    3. Persistent systems: FAA TAAS for air-traffic control, phone switching systems, refinery control
    4. Rapidly configurable systems (DARPA PSOS initiative)
    5. Secure systems

    end of note 1996-1. Go back