1. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design

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

3. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 3 Objectives l To introduce architectural design and to discuss its importance l To explain why multiple models are required to document a software architecture l To discuss how domain-specific reference models may be used as a basis for product-lines and to compare software architectures

4. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 4 Topics covered l Software architecture l Architectural styles l Domain-specific architectures

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

6. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 6 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

7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 7 Advantages of explicit architecture l Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders l System analysis Means that analysis of whether the system can meet its non-functional requirements is possible l Large-scale reuse The architecture may be reusable across a range of systems

8. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 8 Architecture attributes l Performance Localize operations to minimize 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

9. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 9 Topics covered l Software architecture l Architectural styles l Domain-specific architectures

10. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 10 Architectural styles l The architectural model of a system may conform to a generic architectural model or style l An awareness of these styles can simplify the problem of defining system architectures l However, most large systems are heterogeneous and do not follow a single architectural style

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 Repository model characteristics l Advantages Efficient way to share large amounts of data Sub-systems need not be concerned with how data is produced. Centralized management e.g. backup, security, etc. l Disadvantages Sub-systems must agree on a repository data model, which is inevitably a compromise Data evolution is difficult and expensive No scope for specific management policies Difficult to distribute efficiently

14. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 14 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

15. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 15 Film and picture library

16. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 16 Client-server characteristics l Advantages Distribution of data is straightforward Makes effective use of networked systems. Easy to add new servers or upgrade existing servers l Disadvantages No shared data model so sub-systems use different data organization. data interchange may be inefficient Redundant management in each server No central register of names and services - it may be hard to find out what servers and services are available

17. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 17 Abstract machine model l Used to model the interfacing of sub-systems l Organizes 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

18. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 18 Version management system

19. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 19 Centralized control l A control sub-system takes responsibility for managing the execution of other sub-systems l Call-return model Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems l Manager model Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement

20. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 20 Call-return model

21. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 21 Real-time system control

22. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 22 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

23. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 23 Broadcast model l Effective in integrating sub-systems on different computers in a network l Sub-systems register an interest in specific events. When these occur, control is transferred to the sub- system which can handle the event l Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them l However, sub-systems don’t know if or when an event will be handled

24. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 24 Selective broadcasting

25. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 25 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

26. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 26 Interrupt-driven control

27. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 27 Object models l Structure the system into a set of loosely coupled objects with well-defined interfaces l Object-oriented decomposition is concerned with identifying object classes, their attributes and operations l When implemented, objects are created from these classes and some control is used to coordinate object operations

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

29. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 29 Data-flow models 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

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

31. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 31 Topics covered l Software architecture l Architectural styles l Domain-specific architectures

32. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 32 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, idealized 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

33. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 33 Generic models l Compiler model is a well-known example although other models exist in more specialised application domains Lexical analyser Symbol table Syntax analyser Syntax tree Semantic analyser Code generator l Generic compiler model may be organised according to different architectural models

34. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 34 Compiler model

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

36. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 36 Reference architectures l Reference models are derived from a study of the application domain rather than from existing systems l May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated l OSI model is a layered model for communication systems

37. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 37 OSI reference model Application

38. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 38 Architectural Styles l Repository l Client-Server l Abstract Machine Model (Layered Model) l Call-and-Return Model, Manager Model l Event-Driven Model (Broadcasting, Interrupt- driven) l Object Model l Data Flow Model (Pipe Filter model)

39. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 39 Key points l The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model l Large systems rarely conform to a single architectural model l System decomposition models include repository models, client-server models and abstract machine models l Control models include centralised control and event-driven models

40. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 40 Key points l Modular decomposition models include data-flow and object models l Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models