More Architectural Design

Tom Kelliher, CS 319

Next Lecture


From Last Time

  1. Sign-offs.


  1. Control models.

  2. Modular decomposition.

  3. Domain Specific Architectures.


Read Chapter 14.

Control Models

Centralized and event-driven.

Centralized Control

  1. One sub-system designated controller and has responsibility for managing execution of other sub-systems.

  2. Two models:
    1. Call-Return model: Subroutines. Familiar programming language control. Only applicable to sequential systems.

      Applicable as a module control mechanism for controlling functions or objects.

    2. Manager model: Sub-Systems are parallel processes. System manager controls the start, stop, and coordination of other system processes.

      Sequential variation: manager sequentially calls other sub-systems as determined by global system state variables.

  3. Example:

    Note: this does not imply anything regarding structure.

  4. Control is expected to return to where it came from.

  5. Advantages: relatively simple to analyze control flow and determine response to inputs.

  6. Disadvantages: Exception handling is difficult. You either break the model or introduce a lot of redundant error-checking code.

  7. Manager model example of a ``soft'' real-time system:

  8. Another example: telnetd.

Event-Driven Systems

  1. Driven by externally generated events rather than system state variables.

  2. An event is an abstract signal with a range of values. Its timing is not controlled by the system.

  3. Examples: recalculation in a spreadsheet, rule-based expert systems, dataflow processing, physical I/O in an operating system.

  4. Two models:
    1. Broadcast:
      1. Events are ``broadcast'' to all sub-systems. Any sub-systems designed to handle that event respond. Useful in a distributed environment.

      2. Sub-Systems register an interest in events. When event occurs, event handler dispatches event to sub-system(s). (This is the ``broadcast.'')

      3. Distinction between this and central control.

      4. Sub-System communication via messages possible.

      5. Advantages: Simple to evolve system by adding new sub-systems which register their events. A sub-system can communicate with other sub-systems without knowing their names. The distributed nature is transparent.

      6. Disadvantages: Not knowing if/when a particular event will be handled. Not knowing how many responses will be generated.

        How easy will it be to trace control sequences, consider that sub-systems will be entering and registering their interests in events.

      7. Example:

    2. Interrupt-driven:
      1. Interrupt handler fields event and passes it off to the appropriate sub-system. Used in real-time systems with hard deadlines.

      2. Key: quick response. Achieved by table of interrupt vectors.

      3. Example:

      4. Vehicle airbag controller. Space shuttle control surfaces.

      5. Advantages: Very quick event responses.

      6. Disadvantages: Programming complexity, difficulty in validation, difficulty in replicating interrupt timing. Making changes if hardwares limits the system to a small number of interrupts (unless interrupts are shared, which then requires polling and slows response time).

        Interrupt limitation example: the PC and the ISA bus. Solution: the PCI bus.

Modular Decomposition

Modules are smaller than sub-systems, allowing alternative decomposition models. The previous models could still be used, though.

Defer the concurrency question as long as possible. Why?

Object Models

  1. System is decomposed into a set of communicating objects. Loosely coupled objects with well-defined interfaces.

  2. Invoice processing system example:

  3. A control model must be picked.

  4. Advantages: Loose coupling eases changes. Model of real-world increases understanding. Object reuse.

  5. Disadvantages: Naming and knowledge of interface make changes to those aspects difficult/impossible. Large, complex entities can be difficult to model.

Dataflow Models

  1. System is decomposed into a set of functional filters. AKA pipeline approach.

  2. Invoice processing system example:

    Less abstract than object model, processing sequence specified.

  3. Sequential or parallel. Item-by-item or batch processing.

  4. Batch sequential model for data processing systems. Billing, etc.

  5. Advantages: Reuse. Intuitive, because of worker's in/out boxes. Adding new transformations is simple. Implementation as either sequential or concurrent system feasible.

  6. Disadvantages: Common data exchange format required. (Unix solution: file model.) Difficulty in designing GUI interactive (events) systems.

Domain Specific Architectures

  1. Generic models: Derived from a number of real systems. ``Bottom-Up.'' Capture principal characteristics. Describe a limited class of system.

  2. Reference architectures: More abstract, describing a larger class of system. ``Top-Down.'' Not based upon real systems. Instead, reflect application domain.

Generic Models

  1. A compiler as the classic example:

  2. Contrast with the repository model of a compiler.

Reference Architectures

  1. A standard which can be used to compare real systems. Introduces terminology to an application domain.

  2. OSI reference model as the classic example:

  3. Intended to promote interconnection of conformant systems. A failure. Layering subverted.

Thomas P. Kelliher
Wed Nov 11 08:59:40 EST 1998
Tom Kelliher