Architectural design and multiprocessor architecture

Architectural design

Architectural design is the early design process that identifies the sub-systems making up a system and the framework for sub-system control and communication. Its output is the software architecture: a description of how the system is organised as a set of communicating components. It is the link between requirements engineering and detailed design.

It normally covers three activities: system structuring (decomposing the system into sub-systems), control modelling (centralised or event-based control between sub-systems) and modular decomposition (breaking sub-systems into modules).

Why it is important

1. Stakeholder communication – the architecture is a high-level picture that managers, customers and developers can all discuss.
2. Meets non-functional requirements – performance, security, safety, availability and maintainability depend mainly on the architecture (e.g. localising critical operations for performance, layered structure for security).
3. System analysis – it allows early checking of whether the system can meet its requirements before large costs are spent.
4. Large-scale reuse – a well-defined architecture can be reused across systems with similar requirements (product lines).
5. Basis for work division – sub-systems can be assigned to separate teams and developed in parallel.
6. Hard to change later – mistakes in architecture are very costly to fix after implementation, so it must be decided carefully early.

Multiprocessor architecture

A multiprocessor architecture is the simplest distributed system architecture. The system is made of a number of processes, and these processes may run on different processors. Each processor is dedicated to a part of the work, and processes communicate with each other by message passing or shared memory.

Key features:

• Used mostly in large real-time systems that collect information from sensors, make decisions and send signals to actuators.
• Process allocation to processors may be fixed in advance (pre-determined) or controlled by a dispatcher at run time.
• Gives better performance and reliability because work is shared and a processor can be replaced if it fails.

Example: traffic control system (Sommerville)

+-------------+   +--------------+   +---------------+
| Sensor      |   | Traffic flow |   | Traffic light |
| processor   |   | processor    |   | control proc. |
|-------------|   |--------------|   |---------------|
| Sensor      |-->| Display      |-->| Light control |
| control     |   | process      |   | process       |
| process     |   |              |   |               |
+-------------+   +--------------+   +---------------+
      ^                  |                   |
      |                  v                   v
 traffic flow        operator            traffic
 sensors and         consoles            lights
 cameras

• The sensor processor runs the sensor control process that reads vehicle counts and camera data.
• The traffic flow processor runs the display process that analyses flow and shows it on operator consoles.
• The traffic light control processor runs the light control process that switches signals based on the flow data.

Each processor does one job, so the timing needs of each part can be met independently. Data flows from left to right: sensor readings are passed to the flow processor, and the computed flow decides how the light controller sets the signals. If more junctions are added, more sensor processors can be added without changing the others.

Process allocation: in this system the allocation of processes to processors is fixed at design time. In more general multiprocessor systems a dispatcher decides at run time which process runs on which processor, based on load, which balances work but makes timing harder to predict.