More Architectural Design

Tom Kelliher, CS 319

Next Lecture

Announcements

From Last Time

1. Sign-offs.

Outline

1. Control models.

2. Modular decomposition.

3. Domain Specific Architectures.

Assignment

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.