Software Architecture

1. Software Architecture What is a Software Architecture? • High-level description of a complex software system • Includes both diagrams and text • Simplified diagrams often used for marketing (e.g. Apple’s OS X) Chapter 10 - System Architectures

2. Software Architecture • All systems have an architecture, but what are the benefits of designing (and specifying) one? • Stakeholder communication • System analysis (reasoning about non-functional requirements) • Reuse • Project management (concurrent development) Chapter 10 - System Architectures

3. Software Architecture What is a Software Architecture? Answers questions like: • What are the primary subsystems? • What is the division of labor? • How will the subsystems communicate? • What will the subsystems communicate? Chapter 10 - System Architectures

4. Subsystems A subsystem is a system in its own right whose operation does not depend on services provided by other systems. Subsystems are composed of modules, and have defined interfaces used for communication with other subsystems. Sommerville, p. 217 . • Design/implementation often delegated to different engineering teams • Development can proceed in parallel • Separation of responsibility • Minimal inter-subsystem communication Chapter 10 - System Architectures

5. Software Architecture • Subsystem breakdown guided by: • Performance • Minimize communication among subsystems • Security • Use layered architecture, with critical assets in inner layers • Safety • Isolate safety-critical components • Availability • Redundancy, replication of services • Maintainability • Subsystems’ modules with self-contained components Chapter 10 - System Architectures

6. Software Architecture • Software System Architecture • System structuring • Control models • Modular decomposition • Domain-specific architectures Chapter 10 - System Architectures

7. Structural Models • The Repository • The Client-Server Model • The Abstract Machine Chapter 10 - System Architectures

8. The Repository Model • Shared data is stored in centralized location (the repository subsystem), and accessed by various (other) subsystems • Shared data is passed from one subsystem to the next (pipeline architecture) • E.g., compiler Chapter 10 - System Architectures

9. CASE toolset architecture Chapter 10 - System Architectures

10. The Repository Model • Characteristics • Sharing model is published as repository schema • Pros • Efficient way to share large amounts of data • Data integrity localized to repository module • Cons • Subsystems must agree (i.e., compromise) on a repository data model. • Schema evolution is difficult and expensive • Distribution can be a problem Chapter 10 - System Architectures

11. Client-Server Architecture • Subsystems are viewed as independent processes. • Set of stand-alone servers which provide specific services such as printing, data management, etc. • Set of clients which call on these services. Servers can be clients of other servers. • Communication network Chapter 10 - System Architectures

12. Client-Server Architecture Film and picture library Chapter 10 - System Architectures

13. Client-Server Architecture Characteristics • Pros • Makes effective use of networked systems. May require cheaper hardware • Easy to add new servers or upgrade existing servers • Availability (redundancy) may be straightforward • Cons • Data interchange can be hampered by different data layouts • Communication may be expensive • Data integrity functionality must be implemented for each server • The “naming” problems Chapter 10 - System Architectures

14. Abstract Machine Model • Organises the system into a set of layers (or abstract machines) each of which provide a set of services • Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected • Can’t model all systems this way Chapter 10 - System Architectures

15. Abstract Machine Model • Examples • Version Management System • Operating System (e.g., Linux) • Runtime Language Environments (e.g., Java) Chapter 10 - System Architectures

16. Abstract Machine Model Version management system Chapter 10 - System Architectures

17. Chapter 10 - System Architectures

18. Control Models • How subsystems behavior is coordinated • Orthogonal to system structure • Two broad categories • Centralized control • Master subsystem • Event-based control • Each subsystem able to respond to external events Chapter 10 - System Architectures

19. Control Models Centralized Control • Master subsystem has responsibility for managing execution of (other) subsytems • Call-Return Model • Manager Model Chapter 10 - System Architectures

20. Control Models Centralized Control • Master subsystem has responsibility for managing execution of (other) subsytems • Call-Return Model • Subsystems invoked using traditional subroutine/function calls • Applicable in sequential execution only • Manager Model Chapter 10 - System Architectures

21. Call-Return Model (figure) Chapter 10 - System Architectures

22. Control Models Centralized Control • Master subsystem has responsibility for managing execution of (other) subsytems • Call-Return Model • Manager Model • Subsystems run as separate processes • Manager starts/suspends/stops processes • Implied in concurrent systems, can be useful in sequential ones Chapter 10 - System Architectures

23. Control Models Event-Based Control • No master controller • Subsystems react to external events • Subsystems can signal events to others • Specific examples • Spreadsheet (cell state changes) • Soar, Linda (AI-inspired production systems) • Ethernet Chapter 10 - System Architectures

24. Event-Based ControlBroadcast Models • Event is broadcast to all subsystems • “Appropriate” subsystem responds • Conflict resolution? • Event Handler • Subsystem can register interest in particular events • Handler passes off to registered subsystem • Reduces overhead on uninterested subsystems Chapter 10 - System Architectures

25. Event-Based ControlBroadcast Models • Pros • Simple to evolve (add/remove/change event handlers) • Subsystems don’t need to know others by name • Cons • Caller doesn’t know if/when event will be handled • Conflict resolution Chapter 10 - System Architectures

26. Event-Based ControlInterrupt-Driven Models • Preferable to broadcast models for real-time reaction • Interrupt handlers • Hardware supported • Triggered by raising of interrupt event • Assume control of subsystems • E.g. air-bag deployment; fire-control systems Chapter 10 - System Architectures

27. Event-Based ControlInterrupt-Driven Models • Pros • Allows for fast responses; context switches • Cons • Complex to program • Difficult to validate (reproducing timings) • Number limited by hardware Chapter 10 - System Architectures

28. Modular Decomposition • Decomposition of subsystems into modules • Models include: • System architectural models • Object-oriented model(to be discussed in future lecture) • Data-flow model Chapter 10 - System Architectures

29. Modular DecompositionData-Flow Model • Data flows through transformation stages (a.k.a. pipes and filters) • Sequential flow: batch processing model • Examples: • Regular invoice/bill processing • Bank statement generation • Report generation Chapter 10 - System Architectures

30. Domain-Specific Architectures • Can be useful to frame, guide architectural design for a specific domain • Generic Models • Generalized architecture of real applications in domain • Often proprietary (e.g. product-line architectures) • Reference Models • Idealized architecture for an application domain Chapter 10 - System Architectures

31. Generic ModelsExample:Compiler (Data-flow) Chapter 10 - System Architectures

32. Generic ModelsExample:Compiler (Repository) Chapter 10 - System Architectures

33. Reference Models Example:The OSI Networking Model • OSI = Open Systems Interconnection • A layered model for communication systems (similar to Abstract Machine Model) Chapter 10 - System Architectures

34. Domain-Specific Architectures Example:The OSI Networking Model The Seven Layers: 7. Application 6. Presentation 5. Session 4. Transport 3. Network 2. Data Link 1. Physical Chapter 10 - System Architectures

35. Software ArchitectureKey Points • Software architect responsible for deriving a structural system model, a control model and a sub-system decomposition model • Large systems rarely conform to a single architectural model • System decomposition models include: • repository models • client-server models • abstract machine models Chapter 10 - System Architectures

36. Software ArchitectureKey Points • Control models include: • centralized control models • event-driven models • Modular decomposition models • data-flow models • object-oriented models • Domain-specific architectural models • abstractions of existing systems • idealized reference models Chapter 10 - System Architectures