Chapter 14 Architectures and Frameworks

1. Chapter 14Architectures and Frameworks

2. Process Phases Discussed in This Chapter Requirements Analysis Design Framework Architecture Detailed Design Implementation Key: = main emphasis = secondary emphasis x x Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

3. Learning Goals for This Chapter Understand … • … the goals of software architecture • … the meaning of “frameworks” • … express a software architecture • … show a full class model • … show a full state model • … show a component model • … build frameworks • … complete a detailed design Be able to … Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

4. An Architecture for a Video Store Application Rentals Videos Customers Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

5. A Sequence for Obtaining The Class Model 0. Framework (some or all pre-existing) More general 2. Create architecture -- typically use framework 3. Create remaining design classes -- to complete the class model -- possibly use framework 1. Create domain classes -- from requirements analysis Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

6. Models To express requirements, architecture & detailed design Use-case model “Do this ...” e.g.*, engage foreign character Class model “with objects of these classes ...” e.g., with Engagement … classes Target Application Data Flow model “in this way ...” e.g., character scores flow from … to … State model “reacting to these events ...” e.g., when foreign character enters * Video game example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

7. Role of Use Case Models Use-case model: Business use case Use case elaborated by ... Sequence diagram Scenarios Target Application Class model Data flow model State model

8. Role of Class Models Use-case model Class model Consists of ... package class Target Application methods Data flow model State model Jacobson et al

9. Role of Component Model Use-case model Class model 1 Target Application Data Flow model State model Processing element Data type organized by ... Data store Sub-processing element Jacobson et al

10. Data Flow Diagram: Explanation of Symbols Processing element Get deposit Input User Account # & deposit Output Direction of data flow Printer Data type Validate deposit …... balance query Create account summary account data account database Data store Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

11. Partial Data Flow Diagram for ATM Application member banks Get deposit Get inquiry User bank name error error account # account # & deposit account display Validate inquiry Validate deposit Display account Make inquiry account # account # & deposit Printer account data balance query Do deposit transaction Create account summary deposit transaction account data account database Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

12. Detailed Data Flow Diagram for a Banking Application Expand details …….. Customer. getDetails() Account. getDeposit() balance User Customer balance Customer screen template unacceptable ATM users local log Deposit- screen. display() Account. getPass- word() Account. verifyPass- word() status Pass- word Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

13. Partial Encounter Video Game State Model Setting up Preparing Player clicks qualities menu Complete setup Foreign character enters area Waiting Engaging Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. Using Conditions in State-Transition Diagrams state condition Waiting [foreign character present] Player moves to adjacent area event [foreign character absent] Engaging condition state Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

15. Encounter State-Transition Diagram Setting qualities Reporting Player dismisses report window Setting up Player completes setup Player dismisses set qualities widow Player requests to set qualities Player requests status Foreign character enters area Waiting Foreign character enters area Player moves to adjacent area Encounter completed Player quits Engaging [foreign character present] [foreign character absent] Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

16. Role of State Models Use-case model Class model Target Application Component model State model: “reacting to these events” States Substates decompose into ... Transitions Jacobson et al Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

17. Design Goal At Work: Correctness/Modularity We want to decompose designs into modules, each well-knit, and depending on few others. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

18. Cohesion and Coupling component 1 2 3 4 component Bridge 5 6 High cohesion Low coupling   component Steel truss  High coupling Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

19. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

20. Architecture and Modularization of Encounter Video Game EncounterGame EncounterGame «facade» EncounterCharacters EncounterCast «facade» EncounterEnvironment EncounterEnvironment «facade» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

21. To Begin Selecting a Basic Architecture 1. Develop a mental model of the application. • as if it were a small application e.g., personal finance application ... … “works by receiving money or paying out money, in any order, controlled through a user interface”. 2. Decompose into the required components. • look for high cohesion & low coupling e.g., personal finance application ... … decomposes into Assets, Sources, Suppliers, & Interface. 3. Repeat this process for the components. 4. Consider using Façade for each package. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

22. Key Concept: Modules Must …  … each have high cohesion, but be loosely coupled. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

23. A Classification of Software Architectures Garlan & Shaw • Data Flow • Data flowing between functional elements • Independent Components • -- executing in parallel, occasionally communicating • Virtual Machines • Interpreter + program in special-purpose language • Repositories • Primarily built around large data collection • Layered • Subsystems, each depending one-way on another subsystem Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

24. Design Goal At Work: Reusability We classify architectures so as to use them for several applications. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

25. Example of Data Flow Architecture and Corresponding Class Model Requirement: Maintain wired financial transactions. Architecture (data flow) account data account data deposit transaction result account data deposit data Bank data transaction Log analyze record transaction withdrawal data transaction result Comm withdraw bank address account data A Class model: Transaction analyze() record() Account withdraw() deposit() Bank 1 * Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

26. Repository Architecture App 1 database App 3 App 2 Applications mostly storage,retrievals, and querying. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

27. Layered Architecture 3D engine layer «uses» Role-playing game layer Characters RolePlayingGame Layout . . . . «uses» Application layer Encounter Characters Encounter Environment Encounter Game . . . . Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

28. Layered Architecture Example Using Aggregation Requirement: Print monthly statements Architecture: Vendor-supplied Layer Ajax bank common library Layer Accounts Layer “uses” Ajax bank printing Layer Class model: (relationships within packages and Vendor-supplied layer not shown) Accounts Ajax bank common library Account Customer AjaxLogo AjaxDisclaimer Regulations Ajax bank printing Printer Page Formatter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

29. Coad-Yourdon Use of Packages Problem domain package Interface package Data management package Task management package Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

30. Key Concept:  A Software Architectures is Essentially ... … a Data Flow, a set of Independent Components, a Virtual Machine, a Repository, or Layers. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

31. Design Goal At Work: Reusability We create frameworks because we want to reuse groups of classes and algorithms among them. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

32. Class Model vs. Architecture and Detailed Design Frameworkclasses DP Architecture DP Design classes DP Detailed design DP DP DP Domain classes Class Model for this application DP = design pattern Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

33. Class Model vs. Architecture and Detailed Design Frameworkclasses DP Architecture DP Design classes DP Detailed design DP DP DP Domain classes Class Model for this application DP = design pattern Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

34. Selected Framework Goals • Persistence Service • Store instances between executions • Identity Service • Identify objects sufficiently to retrieve them across executions • Pooling • - of objects: Reusing objects at runtime to save time and space • - of threads • - of database connections • Security Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

35. Key Concept: We Use Frameworks … … to reuse classes, relationships among classes, or pre-programmed control. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

36. Seeking Generalization: Bottom-up 1. Start with classes in class model 2. Look for generalizations Problem Procedure WinProblem WinProcedure Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

37. Seeking Generalization: Top-down 1. Start with libraries (e.g., MFC) 2. Look for opportunities to use library List ListIterator ScheduledEvents Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

38. RPG Video Game Layering RPGCharacters «framework package» Framework layer «uses» Application layer EncounterCharacters «application package» EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

39. FrameWork For Encounter Video Game Role-playing game layer (framework) RPGCharacters RPGEnvironment RolePlayingGame «uses» «uses» EncounterCharacters EncounterGame «uses» Encounter video game layer EncounterEnvironment Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

40. Role-Playing Game, and Encounter Packages -- showing domain classes Framework layer RPGEnvironment «framework package» RPGCharacters RolePlayingGame «framework package» «framework package» «uses» Application layer EncounterGame EncounterCharacters «application package» «application package» EncounterGame Engagement EncounterCharacter EngagementDisplay EncounterEnvironment PlayerCharacter «application package» ForeignCharacter Area EncounterAreaConnection PlayerQualityWindow ConnectionHyperlink Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

41. EncounterEnvironment Package EncounterEnvironment «application package» 1 ThumbnailMap EncounterAreaConnection «facade» EncounterEnvironment Hyperlink EncounterArea Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

42. EncounterEnvironment Package RPGEnvironment «framework package» GameCharacter GameArea 2 GameAreaConnection 1 ThumbnailMap EncounterAreaConnection «facade» EncounterEnvironment EncounterArea Hyperlink EncounterEnvironment «application package» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

43. Detailed Design of EncounterCharacters Package RPGCharacters «framework package» RPGCharacter EncounterCharacters «application package» EncounterCharacter PlayerCharacter «facade» EncounterCast ForeignCharacter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

44. Detailed Design of EncounterGameDisplays Sub-package MouseListener EncounterGameDisplays EncounterCast EncounterDisplayItem EncounterDisplay QualListDispl SetQualValueDispl QualValueDispl Reporting handleEvent() EngagementDisplay Preparing handleEvent() SetQualityDisplay Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

45. Detailed Design of EncounterGame Package RolePlayingGame { state.handleEvent(); } state GameState handleEvent() RPGMouseEventListener notifyOfEvent() RPGame handleEvent() EncounterGame Key: Domain class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

46. Detailed Design of EncounterGame Package RolePlayingGame RPGMouseEventListener notifyOfEvent() GameState handleEvent() RPGame handleEvent() EncounterGame <<singleton>> CharacterMovement Engaging handleEvent() Waiting handleEvent() Reporting handleEvent() SettingQualities handleEvent() Preparing handleEvent() Engagement EncounterGameDisplays sub-package EncounterGame Key: Domain class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

47. Detailed Design of RolePlayingGame Package GameState handleEvent() RPGame handleEvent() state { state.handleEvent(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

48. Detailed Design of RolePlayingGame Package MouseListener { rPGame.handleEvent(); } rPGame RPGMouseEventListener mouseEnter() GameState handleEvent() RPGame handleEvent() state { state.handleEvent(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

49. RPG Framework for Role-Playing Video Games RolePlayingGame Characters state RPGame handleEvent() GameCharacter 0..n { state.handleEvent(); } GameState handleEvent() GameEnvironment RPGEvent GameLayout 2 GameArea Artifacts For future releases GameAreaConnection Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

50. Design Goal At Work: Correctness We want to avoid re-implementing common server-side processes. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.