1. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software system

2. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures

3. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 3 Software architecture l The design process for identifying the sub- systems making up a system and the framework for sub-system control and communication is architectural design l The output of this design process is a description of the software architecture

4. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 4 Architectural design l An early stage of the system design process l Represents the link between specification and design processes l Often carried out in parallel with some specification activities l It involves identifying major system components and their communications

5. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 5 Architectural design process l System structuring The system is decomposed into several principal sub-systems and communications between these sub-systems are identified l Control modelling A model of the control relationships between the different parts of the system is established l Modular decomposition The identified sub-systems are decomposed into modules

6. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 6 Sub-systems and modules l A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. l A module is a system component that provides services to other components but would not normally be considered as a separate system

7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 7 Architectural models l Different architectural models may be produced during the design process l Each model presents different perspectives on the architecture

8. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 8 Architectural models l Static structural model that shows the major system components l Dynamic process model that shows the process structure of the system l Interface model that defines sub-system interfaces l Relationships model such as a data-flow model

9. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 9 Architecture attributes l Performance Localise operations to minimise sub-system communication l Security Use a layered architecture with critical assets in inner layers l Safety Isolate safety-critical components l Availability Include redundant components in the architecture l Maintainability Use fine-grain, self-contained components

10. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 10 System structuring l Concerned with decomposing the system into interacting sub-systems l The architectural design is normally expressed as a block diagram presenting an overview of the system structure l More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed

11. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 11 The repository model l Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems Each sub-system maintains its own database and passes data explicitly to other sub-systems l When large amounts of data are to be shared, the repository model of sharing is most commonly used

12. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 12 CASE toolset architecture

13. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 13 Client-server architecture l Distributed system model which shows how data and processing is distributed across a range of components l Set of stand-alone servers which provide specific services such as printing, data management, etc. l Set of clients which call on these services l Network which allows clients to access servers

14. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 14 Abstract machine model l Used to model the interfacing of sub-systems l Organises the system into a set of layers (or abstract machines) each of which provide a set of services l Supports the incremental development of sub- systems in different layers. When a layer interface changes, only the adjacent layer is affected l However, often difficult to structure systems in this way

15. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 15 Control models l Are concerned with the control flow between sub-systems. Distinct from the system decomposition model l Centralised control One sub-system has overall responsibility for control and starts and stops other sub-systems l Event-based control Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

16. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 16 Event-driven systems l Driven by externally generated events where the timing of the event is outwith the control of the sub-systems which process the event l Two principal event-driven models Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing l Other event driven models include spreadsheets and production systems

17. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 17 Interrupt-driven systems l Used in real-time systems where fast response to an event is essential l There are known interrupt types with a handler defined for each type l Each type is associated with a memory location and a hardware switch causes transfer to its handler l Allows fast response but complex to program and difficult to validate

18. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 18 Modular decomposition l Another structural level where sub-systems are decomposed into modules l Two modular decomposition models covered An object model where the system is decomposed into interacting objects A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model l If possible, decisions about concurrency should be delayed until modules are implemented

19. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 19 Invoice processing system

20. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 20 Data-flow models l Functional transformations process their inputs to produce outputs l May be referred to as a pipe and filter model (as in UNIX shell) l Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems l Not really suitable for interactive systems

21. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 21 Domain-specific architectures l Architectural models which are specific to some application domain l Two types of domain-specific model Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems Reference models which are more abstract, idealised model. Provide a means of information about that class of system and of comparing different architectures l Generic models are usually bottom-up models; Reference models are top-down models

22. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 22 Real-time Software Design l Designing embedded software systems whose behaviour is subject to timing constraints

23. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 23 Real-time systems l Systems which monitor and control their environment l Inevitably associated with hardware devices Sensors: Collect data from the system environment Actuators: Change (in some way) the system's environment l Time is critical. Real-time systems MUST respond within specified times

24. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 24 Definition l A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced l A ‘soft’ real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements l A ‘hard’ real-time system is a system whose operation is incorrect if results are not produced according to the timing specification