1 / 39

Software Engineering Chapter 11 Architectural Design

Software Engineering Chapter 11 Architectural Design. Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant Professor Department of Computer Science and Information Engineering Da-Yeh University. Objectives. Understand why the architectural design of software is important

Download Presentation

Software Engineering Chapter 11 Architectural Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software EngineeringChapter 11Architectural Design Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant ProfessorDepartment of Computer Science and Information Engineering Da-Yeh University

  2. Objectives • Understand why the architectural design of software is important • Understand the decisions that have to be made about the system architecture during the architectural design process • Have been introduced to three complementary architectural styles covering the overall system organization, modular decomposition and control • Understand how reference architectures are used to communicate architectural concepts and to access system architectures Architectural Design

  3. Preamble • Large system are always decomposed into sub-systems • Provide some related set of services • Architectural design • Identifying these sub-systems • Establish a framework for sub-system control and communication • A critical link between the design and requirements engineering processes Architectural Design

  4. Preamble • Three advantages • Stakeholder communication • A high-level presentation of the system • System analysis • Required for making the system architecture explicit • Large-scale reuse • A compact, manageable description • How a system is organized • How the components interoperate Architectural Design

  5. Preamble • The system architecture affects non-functional system requirements • Performance • Localize critical operation • As little communication as possible • Security • A layered structure • Availability • Redundant components • Maintainability • Fine-grain, self-contained components Architectural Design

  6. Block diagram • Simple box-and-line diagram • Very abstract • Not show • The nature of component relationships • The externally visible properties of the sub-systems. • Useful for communication with stakeholders and for project planning • Not the only architectural representation • One of useful architectural models Architectural Design

  7. Packing robot control system Architectural Design

  8. Contents 11.1 Architectural design decisions 11.2 System organization 11.3 Modular decomposition styles 11.4 Control styles 11.5 Reference architectures Architectural Design

  9. Architectural design decisions • Architectural design • A creative process • To establish a system organization that will satisfy the functional and non-functional system requirements • System architects • Make a number of fundamental decisions • Profoundly affect the system and its development process Architectural Design

  10. Architectural design decisions • Is there a generic application architecture that can act as a template for the system that is being designed? • How will the system be distributed across a number of processors? • What architectural style or styles are appropriate for the system? • What will be the fundamental approach used to structure the system? Architectural Design

  11. Architectural design decisions • How will the structural units in the system be decomposed into modules? • What strategy will be used to control the operation of the units in the system? • How will the architectural design be evaluated? • How should the architecture of the system be documented? Architectural Design

  12. Architectural design decisions • Systems in the same application domain • Have similar architectures that reflects the fundamental domain concepts • A system architecture • May be based on a particular architectural model or style • Client-server organization • Layered architecture • May be a composite architecture • Combine different architectural styles Architectural Design

  13. Architectural design decisions • Architectural models may include • A static structural model • Sub-systems or components as separate units • A dynamic process model • Organized into process at run-time • An interface model • Define the services offered by public interfaces • A relationship model • Relationship between sub-systems • A distributed model • Be distributed across computers Architectural Design

  14. Contents 11.1 Architectural design decisions 11.2 System organization 11.3 Modular decomposition styles 11.4 Control styles 11.5 Reference architectures Architectural Design

  15. System Organization • Three organizational styles that are widely used • A shared data repository style • A shared service and servers style • An abstract machine or layered style • The above styles can be used separately or together Architectural Design

  16. The Repository Model • Sub-systems must exchange information so that they can work together effectively • Shared data is held in a central database or repository and may be accessed by all sub-systems • A system model based on a shared database is sometimes called a repository model • The repository is passive. • Each sub-system maintains its own database and passes data explicitly to other sub-systems Architectural Design

  17. CASE Toolset Architecture Architectural Design

  18. The Client-Server Model • The system is organized as • A set of services • Associated servers and clients • Access and use the services • Major components • A set of servers • Offer services to other sub-systems • A set of clients • Call on the services • A network • Allow the clients to access the services Architectural Design

  19. Film and Picture Library Architectural Design

  20. The Layered Model • Organize a system into layers • Each provide a set of services • Each layer can be thought of as an abstract machine • Also called an abstract machine model • Incremental development of sub-systems in different layers • When a layer interface changes, only the adjacent layer is affected. • An example – the OSI reference model of network protocol Architectural Design

  21. OSI Reference Model Architectural Design

  22. Version Management System Architectural Design

  23. Contents 11.1 Architectural design decisions 11.2 System organization 11.3 Modular decomposition styles 11.4 Control styles 11.5 Reference architectures Architectural Design

  24. Modular Decomposition Styles • After system organization • Decompose sub-systems into modules • No rigid distinction between system organization and modular decomposition • A sub-system • Does not depend on the services provided by other sub-systems • A module • Provide one or more services to other modules Architectural Design

  25. Modular Decomposition Styles • Two strategies • Object-oriented decomposition • A set of communicating objects • Function-oriented decomposition • Functional modules • Accept input data • Transform it into output data Architectural Design

  26. Object-Oriented Decomposition • Structure the system into • A set of loosely-coupled objects with well-defined interfaces • Advantages • Be modified without affecting other objects • Readily understandable • Representations of real-world entities • Reuse Architectural Design

  27. Invoice Processing System Architectural Design

  28. Function-Oriented Pipelining • Functional transformations process their inputs to produce outputs • May be referred to as a pipe and filter model (as in UNIX shell) • Not really suitable for interactive systems Architectural Design

  29. A Pipeline Model Architectural Design

  30. Contents 11.1 Architectural design decisions 11.2 System organization 11.3 Modular decomposition styles 11.4 Control styles 11.5 Reference architectures Architectural Design

  31. Control Styles • Sub-systems must be controlled • Two generic control styles • Centralized control • One sub-system has overall responsibility for control • Event-based control • Each sub-system can respond to externally generated events Architectural Design

  32. Centralized Control • One sub-system is designated as the system controller • Manage the execution • Two classes • Call-return model • Manager model Architectural Design

  33. The Call-Return Model Architectural Design

  34. The Manager Model Architectural Design

  35. Event-Driven System • An event vs. an input • The timing of the event is outside the control of the process that handles that event • Two event-driven control models • Broadcast models • Different computers on a network • Interrupt-driven models • Real-time systems Architectural Design

  36. A Broadcast Model Architectural Design

  37. An Interrupt-Driven Model Architectural Design

  38. Contents 11.1 Architectural design decisions 11.2 System organization 11.3 Modular decomposition styles 11.4 Control styles 11.5 Reference architectures Architectural Design

  39. The End

More Related