Software Engineering Modern Approaches Eric Braude and Michael Bernstein
Chapter 18: Software Architecture
Learning Goals of This Chapter How do you classify “software architectures?” What are data flow architectures? What are three-tier architectures and their generalizations? What makes database-centric systems a separate type of architecture? What are service-oriented architectures? What are the IEEE standards for expressing designs? What do real-world architectures look like? Planning Maintenance Testing The Software Development Lifecycle Requirements analysis Implementation Design Phase most relevant to this chapter is shown in bold © 2010 John Wiley & Sons Ltd.
Categorization of Software Architectures (Shaw & Garlan) Dataflow architectures Pipes and Filters Batch sequential Independent components Client-server systems Parallel communicating processes Event systems Service-oriented (added) Virtual machines Interpreters Rule-based systems Repository architectures Databases Hypertext systems Blackboards Layered architectures © 2010 John Wiley & Sons Ltd.
Partial Data Flow Diagram for ATM Application member banks Get deposit Get inquiry User bank name error account # error account # & deposit account display Validate deposit Validate inquiry Display account Make inquiry account # account # & deposit Printer account data balance query Do deposit transaction Create account summary deposit transaction account data account database © 2010 John Wiley & Sons Ltd.
Platforms in Data Flow Architectures: An Example ATM Get deposit Get inquiry Display account Consortium server Bank server Make inquiry Do deposit transaction Create account summary Validate deposit Validate inquiry © 2010 John Wiley & Sons Ltd.
Pipe and Filter Architectures stream > filter pipe filter filter filter filter pipe filter < stream © 2010 John Wiley & Sons Ltd.
Example of Pipe & Filter Data Flow Architecture Requirement: Maintain wired financial transactions. account data deposit account data transaction result account data deposit data Bank data transaction Log analyze record transaction Comm withdrawal transaction result bank address withdraw account data © 2010 John Wiley & Sons Ltd.
Example of Batch Sequential Data Flow Architecture Requirement: Manage bank funds available for mortgages & unsecured lending. Architecture: Collect mortgage funds Mortgage pool Account balances Collect unsecured funds Unsecured pool © 2010 John Wiley & Sons Ltd.
Class Model for Batch Sequential Data Flow Accounts package Bank package Bank getMtgPool() getUnsecurePool() Customer Account © 2010 John Wiley & Sons Ltd.
Platforms for Communicating Processors comunication execution © 2010 John Wiley & Sons Ltd.
Example of Parallel Communicating Processes Architecture Requirement: Manage ATM traffic. Architecture beginning with first session: Customer_n :Customer: session_m :Session customer_n_ checking :Account ‡ 1 2 3 create retrieve* 4 5 deposit deposit* (more work) (thread detail omitted)* © 2010 John Wiley & Sons Ltd.
Example of Parallel Communicating Processes Architecture Requirement: Manage ATM traffic. customer_ s_saving : Account Architecture: 1 Customer_n :Customer: session_m :Session session_k :Session customer_n_ checking :Account 2 3 customer s :Customer create retrieve* create retrieve* 4 5 deposit deposit* withdraw withdraw* (thread detail omitted)*
Class Model For Parallel Example Customers Sessions * Account deposit() withdraw() retrieve() Session * Customer © 2010 John Wiley & Sons Ltd.
State Design Pattern Applied to Encounter RolePlayingGame RPGame handleEvent() state GameState handleEvent() { state.handleEvent(); } EncounterGame © 2010 John Wiley & Sons Ltd.
Virtual Machine Architectures: Leveraging Interpreter to Facilitate Creation of Appliations Application 1 Interpreter Program 1 written in language understood by interpreter Application 2 Interpreter Program 2 written in language understood by interpreter © 2010 John Wiley & Sons Ltd.
A Typical Repository Architecture GUI Analysis process 1 Analysis process n Control …... …... DBMS Database Key: Control flow: Data flow: © 2010 John Wiley & Sons Ltd.
Layered Architecture 3D engine layer Role-playing game layer «uses» Characters RolePlayingGame Layout «uses» Application layer Encounter Characters Encounter Environment Encounter Game © 2010 John Wiley & Sons Ltd.
Application Framework Library Framework Layer Application Layer Framework Layer StarOffice API Application Framework Library SVX Library Infrastructure Layer From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3 © 2010 John Wiley & Sons Ltd.
Layered Architecture Example Using Aggregation “uses” Ajax bank printing Layer Accounts Layer Ajax bank common library Layer Vendor-supplied Layer Class model: (relationships within packages not shown) Ajax bank printing Printer Formatter Page Accounts Vendor-supplied layer not shown Account Customer Ajax bank common library AjaxLogo AjaxDisclaimer Regulations © 2010 John Wiley & Sons Ltd.
Service-Oriented Architectures Based on components that provide functionality according to an interface spec. Principally via Web services In the spirit of façade objects Not necessarily OO Example: An application concerning orders. Wouldn’t assume an Order class known to all Instead: Define an order schema; reference when Web services involve orders
Service-Oriented Architectures 2 of 2 “Fire and forget” Stateless as much as possible Extensible Additional functionality easily added Discoverable Account for Quality of Service E.g., security Many of these points are from Service-Oriented Architecture by T. Erl
Service-Oriented Architectures 3 of 3 “Fire and forget” Stateless as much as possible Extensible Additional functionality easily added Discoverable Account for Quality of Service E.g., security Many of these points are from Service-Oriented Architecture by T. Erl
Layering for Service-Oriented Architectures Appplication A (.NET) Application B (JEE) Appplication C (Legacy) «uses» Service Interface Layer «uses» Business Process Layer Adapted from Erl: “Service-Oriented Architectures” © 2010 John Wiley & Sons Ltd.
3-Tier Architecture Aternative VSGUIs VSOperations VSData Presentation tier Middle tier Data tier © 2010 John Wiley & Sons Ltd.
Alternative Architecture for a Video Store Application DVDs DVRentals VSCustomers © 2010 John Wiley & Sons Ltd.
Comparing Architectures Three-tier Alternative Understand-able? Yes Flexible? Yes: GUI easy to change Yes: Basic building blocks easy to identify. Reusable? Not very: Each layer is special to Video Store rentals. Yes: Easy to generalize to generic rentals Easy to construct? Perhaps Yes: Clear potential to use Façade. © 2010 John Wiley & Sons Ltd.
IEEE 1016-1998 SDD Example Table of Contents 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 2. References 3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description 4. Dependency description 4.1 Inter-module dependencies 4.2 Inter-process dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description 6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail Architecture © 2010 John Wiley & Sons Ltd.
Schedule Following Architecture Selection Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Freeze requirements Milestones Complete testing Release to production Characters I Integration & Test I Encounter Characters I Characters II RolePlaying Game I Iteration 1 Encounter Characters II Encounter Game I RolePlaying Game I Integration & Test II Layout I Encounter Game II Encounter Layout I Iteration 2 Layout I Encounter Layout II © 2010 John Wiley & Sons Ltd.
RPG Framework for Role-Playing Video Games RolePlayingGame Characters state RPGame handleEvent() GameCharacter 0..n { state.handleEvent(); } GameState handleEvent() RPGEvent GameEnvironment GameLayout 2 GameArea Artifacts For future releases GameAreaConnection © 2010 John Wiley & Sons Ltd.
Architecture / Modularization of Encounter EncounterGame EncounterGame EncounterCharacters EncounterCast EncounterEnvironment EncounterEnvironment © 2010 John Wiley & Sons Ltd.
RPG Framework for Role-Playing Video Games RolePlayingGame Characters state RPGame handleEvent() GameCharacter 0..n { state.handleEvent(); } GameState handleEvent() RPGEvent GameEnvironment GameLayout 2 GameArea Artifacts For future releases GameAreaConnection © 2010 John Wiley & Sons Ltd.
FrameWork / Application Dependency Characters GameEnvironment RolePlayingGame Role-playing game layer (framework) «uses» Encounter video game layer EncounterGame «uses»* «uses» EncounterCast EncounterGame EncounterCharacters EncounterEnvironment * by member classes implemen- ting framework interfaces EncounterEnvironment © 2010 John Wiley & Sons Ltd.
Architecture of Eclipse 1: Overall Plug-In Development Environment depends on Java Development Tools Adapted from “Contributing to Eclipse” p5 Platform © 2010 John Wiley & Sons Ltd.
Architecture of Eclipse UI Workbench JFace Java Development Tools SWT Java Core Core: Workspace Core: Runtime [“Contributing to Eclipse p282] © 2010 John Wiley & Sons Ltd.
Architecture of Eclipse 2: The Platform UI Workbench JFace Plug-In Development Environment Standard Widget Toolset Java Development Tools Platform depends on Core Workspace Runtime A Key: A depends on B. [Adapted from “Contributing to Eclipse” p283] B © 2010 John Wiley & Sons Ltd.
OpenOffice Architecture Application StarOffice API Dependent Framework Layers Infrastructure System Abstraction VCL Operation System / GUI Edited, from http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3 © 2010 John Wiley & Sons Ltd.
OpenOffice Architecture © 2010 John Wiley & Sons Ltd. From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3