More Architectural Design

Tom Kelliher, CS 319

Dec. 1, 2000

Administrivia

Announcements

Meeting on 12/11 in HS 133 3:00-5:00pm. John responsible for hydration. Tom responsible for frozen dairy confections. Will responsible for sentient... Oh, never mind. Ed responsible?

Course evaluation Monday.

Assignment

Read Chapter 14.

From Last Time

Architectural design.

Outline

1. Control models.

2. Modular decomposition.

3. Domain Specific Architectures.

Coming Up

Object-oriented design.

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.