1. Chapter 14 Architectures and Frameworks

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

3. Learning Goals for This Chapter  … 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 … Understand … 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 Customers Videos Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

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

10. Data Flow Diagram: Explanation of Symbols Account # & deposit balance query User account database account data Get deposit Create account summary Validate deposit Printer Input Output Processing element Data type Direction of data flow 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 account # & deposit balance query account # & deposit account # User Make inquiry account database deposit transaction account data Get deposit Get inquiry Validate inquiry Do deposit transaction Create account summary Validate deposit error Printer member banks bank name Display account account # account data account display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

16. Role of State Models Target Application Class model State model: “reacting to these events” Use-case model Component model States Transitions Substates decompose into... 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 1 234 56 High cohesionLow coupling High coupling Bridge component    Steel truss Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

21. 1. Develop a mental model of the application. oas 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. olook 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. To Begin Selecting a Basic Architecture 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  Data Flow o Data flowing between functional elements  Independent Components o -- executing in parallel, occasionally communicating  Virtual Machines o Interpreter + program in special-purpose language  Repositories o Primarily built around large data collection  Layered o Subsystems, each depending one-way on another subsystem Garlan & Shaw 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. bank address account data Bank Maintain wired financial transactions. Bank data A Class model: Requirement: record Log transaction analyze deposit deposit data withdrawal data transaction result transaction Architecture (data flow) Account withdraw() deposit() account data Comm account data *1 Transaction analyze() record() Example of Data Flow Architecture and Corresponding Class Model transaction result withdraw Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

28. Layered Architecture Example Using Aggregation Class model: (relationships within packages and Vendor-supplied layer not shown) AjaxLogoAjaxDisclaimerRegulations Ajax bank common libraryAccounts AccountCustomer Ajax bank printing PrinterPageFormatter Vendor-supplied Layer Accounts Layer Ajax bank common library Layer Ajax bank printing Layer Requirement: Print monthly statements “uses” Architecture: 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. Domain classes Design classes Class Model vs. Architecture and Detailed Design Framework classes Detailed design Architecture 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. Domain classes Design classes Class Model vs. Architecture and Detailed Design Framework classes Detailed design Architecture 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 o Store instances between executions  Identity Service o Identify objects sufficiently to retrieve them across executions  Pooling o - of objects: Reusing objects at runtime to save time and space o - of threads o - 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 Procedure WinProblem Problem 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 ListIteratorList ScheduledEvents library Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

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

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

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

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

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

47. Detailed Design of RolePlayingGame Package RPGame handleEvent() GameState 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 RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } RPGMouseEventListener mouseEnter() MouseListener { rPGame.handleEvent(); } rPGame Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

49. RPG Framework for Role-Playing Video Games Characters RolePlayingGame RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } GameCharacter Artifacts GameArea RPGEvent GameAreaConnection 2 GameLayout 0..n GameEnvironment For future releases 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.

51. What Are EJB’s ? 1  Server-side component architecture  Part of Java Enterprise Edition  Reusable, portable business components o no system-type code  “Inherently transactional, distributed, portable, multi-tier, scalable and secure” ( http://web2.java.sun.com/products/ejb/faq.html)

52. What Are EJB’s ? 2  Customized at deployment time  Supports o transactional behavior o security features o life-cycle features o state management of client sessions o persistence, etc.  Any protocol can be utilized: o IIOP, JRMP, HTTP, DCOM, etc Summary adapted from http://web2.java.sun.com/products/ejb/faq.html

53. Benefits of EJB’s  Portable across any EJB servers and Operating Systems  “Declarative” rather than algorithmic o Goal: customize, don’t create from scratch  Middleware-independent o independent of structure used between client and server Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

54. CONTAINER: Registers self with JNDI* Controls EJB … … life cycle … transactions … security EJB Architecture EJB container legacy application client callback 1 2 4? 3? * Java Naming and Directory Interface EJBean Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

55. Deployment Descriptor (expressed in XML) type:entity class:CustomerBean home: CustomerHome remote:Customer …. EJB Access client CustomerBean myMethod() … JNDI Entity Bean: business logic methods for the component Java naming and directory service CustomerHome create() … Customer myMethod() … Remote Interface 1 Home Interface: methods for creating a CustomerBean instance … CustomerHomeImpl CustomerImpl 4 2 3 7 5 6 8 EJB container EJBHome EJBObject Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

56. Context initialContext = new InitialContext( properties ); // (1.) CustomerHome customerHome = // (2.) javax.rmi.PortableRemoteObject.narrow // “casting” ( initialContext.lookup( “ applications/bank/customer ” ), CustomerHome.class ); Finding & Connecting to a Specific EJB 1. Embody location etc. of JNDI in a Properties object. 2. Look up the class implementing the bean’s home interface by name using JNDI.  Use methods of the home interface to acquire access to an instance of the class implementing the remote interface. Properties of JNDI Know: path to the container and name of the home class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

57. Instantiating and Using an EJB Context initialContext = new InitialContext( properties ); CustomerHome customerHome = javax.rmi.PortableRemoteObject.narrow ( initialContext.lookup ( “applications/bank/customer” ), CustomerHome.class ); // Create bean instance and return proxy for it (3.) Customer johnDoe = customerHome.create( “John Doe” ); johnDoe.deposit( 2395 ); // use the bean instance.. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

58. The Parts of the EJB Architecture (partial) Entity Beans EntityBean ejbLoad() ejbStore() Session Beans SessionBean ejbActivate() ejbPassivate() ejbRemove() setSessionContext() EJB Container Server EJBObject ejbCreate() ejbRemove() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

59. Entity Bean specific data such as record in a relational database persistent Session Bean (stateful or stateless) perform sequence of tasks within the context of a transaction logical extension of client program running processes on client's behalf remotely on server Message Bean (not covered in this book) - or - Types of EJ Beans 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

60. The Types of EJBs 2 EJB container « Session Bean » client « Entity Bean » Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

61. Key Concept:  Enterprise Java Beans  -- server-side Bean framework handling multiple client sessions, database access, persistence, etc. through control protocols. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

62. Relating Use Cases, Architecture, & Detailed Design 1. Use case (part of requirements) “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” 3. Architecure2. Domain classes Auto Road Auto Road 4. Detailed Design Cable Pylon (not specifically required ) added for detailed design GuardrailRoadbed * ** * Use cases used to obtain domain classes. ** Use cases used to verify and test design. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

63. Completing Detailed Design  Design the control of the application,  Design for database access  Design interaction with outside world.  Audit relationships among classes o eliminate unnecessary connections, o adding requried detail classes o clarify all classes  Ensure all required methods implemented Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

64. Architecture Options for Application Control  Internally driven  Externally driven o == “event-driven” o Does nothing until an even occurs o e.g., mouse actions o Each event causes a method to execute event Application class event Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

65. 1. create 2. create; display 4. create 3. enter characteristics Internal Control ProblemMenu WinProcedureDisplay WinProcedure WinHelp WinProblem Display 5. create; display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

66. Sequence Diagram for Internal WinHelp Control main() :WinHelp:WinProblem 1. create :ProblemMenu 2. create; display 3.1 enter characteristics 3.1 set values :WinProcedure 4. create :WinProcedureDisplay 5. create; display User 3.2 match Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

67. External Control ProblemMenu WinHelp WinProblem Display 2. mouse event 3. create 1. create Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

68. Sequence Diagram for External WinHelp Control main() :WinHelp:ProblemMenu 1. create; display 2. enter characteristics User 3. create 3.1 set values Etc. :WinProblem Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

69. Example For Local Control Design a retirement information system to handle typical transactions … o e.g., open, withdraw, deposit … on several types of accounts o e.g., passbook, savings, money-market funds Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

70. Solutions (after Jacobson) Now modify: o Add CD account o Add reporting Dep Bond FundDep Mutual FundDep Fixed Interest WithdrawDepositOpen Transact MutualFundBondFundFixedInterest Functional Solution OO Solution Account Functional module dependencies. Class model. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

71. New Account Type: Impact on Functional Decomposition Dep Bond Fund Withd. CDOpen CDDep CD (impacted by additional requirement) Dep Mutual FundDep Fixed Interest WithdrawDepositOpen key: Transact Functional module dependencies. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

72. New Account Type: Impact on OO Decomposition CDMutualFundBondFund FixedInterest Account (impacted by additional requirement) key: Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

73. Report Bond FundReport Fixed InterestReport MMF Deposit Reporting Function Impact on Functional Decomposition Report Transact WithdrawOpen (impacted by additional requirement) key: Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

74. Account report( ) Reporting Function: Impact on OO Approach object references MutualFundBondFund FixedInterest report( ) special to this application Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

75. Client theAccReport.report ( theAccount ) Stay with OO: Use Control Classes Account BondFund FixedInterest MutualFund IF Account type is... THEN... AccountReport report() Entity class Control class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

76. Key Concept:  Control Applications …  … Globally: Event-driven (externally) or internally. … Locally: May collect control in its own class. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

77. Styles of Object-Oriented Design for Application Interface  Internally-driven Interface Design o Class by class process  Externally-driven Interface Design o by use case -- or -- o by screen -- or -- o by user Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

78. WinHelp Internally-Driven Interface Design WinHelp WinProblem ExampleWinProblem Needs external data Supplies external data visible invisible 1 23 45 ExampleMenu ProblemMenu «creates» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

79. GUI Fragment for Setting WinProblem Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

80. Java Graphic-based UI for WinProblem WinProblem Button Label Frame BorderLayoutDialog ApplicationDialog DesktopDialog WinProblemDialog etc. WinHelp getProblem() suggestSolutions() callbacks Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

81. Externally-Driven Design For Interfacing manager comptroller foreman class model managerIF foremanIF comptrollerIF Graphics courtesy of Corel. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

82. A Vending Machine Interface Select $0.55 Return 75c CoolCola (Add cash) A GUI group Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

83. 1..n1..2 InfoSelectContainer AddCashReturnContainer TextComponent Container setLayout() show() Vending Machine Interface Object Model Command Button Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

84. Domain classes robotsrobotsrobotsrobots systemsystemsystemsystem operators Non-Human Users Robot interfaceSystem interface Operator interface Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

85. UI Example: Supermarket Counter $32 spend put back Counter amountSpent increment() decrement()..... Physical interfaceDomain class

86. Menu items prompt execUserSelection() TextComponent displayValue() CounterText CounterMenu execUserSelection() Counter amountSpent increment() decrement() UIDomain UI Example: Supermarket Aid ctd. create

87. Key Concept:  Design For Interfaces …  … Per use case (externally) – or – … Per class (internally). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

88. Data Access Issues 1.Ensure class model supports collection 2.Choose centralized or distributed storage architecture 3.Store data in relational or object-oriented database Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

89. Ensure Object Model Allows Data Capture Mediator for data capture Transaction Account CustomerTeller Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

90. Trial Data Access Example : Gymnastics 4 1 Team Contest name * Event apparatus * gender * junior/senior * Gymnast Judge score * 1 1 * Keep raw data with originator 1..n Club Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

91. Data Access Example : Gymnastics 4 1 Season year Club Team Contest name Event apparatus gender junior/senior Gymnast Performance record() Meet League Judge score 1..n1 * * 1 1 database Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

92. Data Management Architectures o Distributed : objects store themselves o Central : use specialized storage classes o to create instances o to destroy instances o to make efficient use of space o e.g. garbage collection Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

93. Distributed Data Storage Transaction float time Customer* cust CheckAccount* chAcc SavingsAccount* svgAcc store() cassie: Customer “3 Main”: addr edward: Teller 54321: empNum Objects store themselves cAcc16: CheckAccount 100: lastWithdrawal sAcc12: SavingsAccount 3003: balance trans129:Transaction time: 0932 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

94. Objects send their contents to a storage utility class or module attribute values Centralized Data Storage Storage store(...) transaction123: Transaction time: 0932 Object…:Class… Data Storage Package Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

95. Using Relational Databases with OO Transaction time customer account DBMSDBMS  Objects re- assembled in memory by application and database.  Data, not objects stored. tables Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

96. OO Databases OODBMSOODBMS  Objects delivered to memory for re-use.  Objects, not data, stored. objects Transaction time customer account Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

97. OO Databases: Relationships Maintained Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

98. Relational DBMS vs. OO DBMS o RDBMS based on a data model o tables of rows & columns o ODBMS based on a programming technology (the OO method) o data model defined by the program Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

99. Completing the Design o Replace ambiguous associations, o Expose all dependencies  Split selected classes for improved design. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

100. Design Goal At Work:  Reusability  We reduce dependencies among classes to promote their reuse in other applications. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

101. Examining Associations: Many-To-Many...... may uncover a required class : an "event- remembered" or mediator ( Registration in this case). 1..n 11 e.g. wedding gift registration system: StoreCouple StoreCouple 1..n Registration Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

102. Examining Associations: Class-to-Itself... Business JointVenture... may uncover a required class : frequently an "event-remembered" Business Merger 2...n Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

103. Examining Aggregations for Short Circuits Item 1..n Shelf 1..n ------ But not every item is on a shelf ----- 0..n Add: Supermarket Item 1..n Shelf 1..n Supermarket looseItem Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

104. Consider Splitting Classes o Envision system growth o Leverage inheritance properly WinProcedureHelp Help WinProcedure Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

105. Completing Operations Class Operations 1. Required by… 1.1 Use-case model (sequence diagrams) 1.2 State Model (event handlers; functionality on entering states) 2. Design the algorithm for each operation (activity diagrams? pseudocode?) 1.4 Design Patterns (chapters xx-xx) 1.3 Component model (see section xx) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

106. WinHelp getProblem() match() WinProblem getCategory() getVisible() savePrimaryParameters() showCategoryOptions() WinProcedure describe() getCategory() showCategoryOptions() demoExample() WinProcedureExample demoExample() Completing WinHelp Operations u c u u u s Partial Component Model c c key: from...u: use case s: from state model c: from component model categoryString Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

107. Summary 1. Determine the architecture (modularization) o Consider standard ones 2. Use and contribute to framework 3. Apply design patterns 4. Design for data capture 5. Design control 6. Design interfaces 7. Exploit abstraction 8. Reduce many-to-many associations 9. Finalize design of associations 10. Obtain all functions from use case-, state-, and component models 11. Design individual functions Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.