Lecture # 16 Finalizing the Application Design

1. SWE 316: Software Design and Architecture Lecture # 16Finalizing the Application Design Ch 14b • Be able to • … complete a detailed design Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

2. 2/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Process Phases Discussed in This Chapter Requirements Analysis Design Framework Architecture Detailed Design Implementation Key: = main emphasis = secondary emphasis x x

3. 3/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Relating Use Cases, Architecture, & Detailed Design 2. Domain classes 3. Architecure Cable 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.” (not specifically required) Auto * Pylon Road ** 4. Detailed Design Cable Roadbed Guardrail Auto Pylon Road added for detailed design * Use cases used to obtain domain classes. ** Use cases used to verify and test design.

4. 4/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Completing Detailed Design • Design the control of the application, • Design for database access • Design interaction with outside world. • Audit relationships among classes • eliminate unnecessary connections, • adding requried detail classes • clarify all classes • Ensure all required methods implemented

5. 5/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Designing control • Controlling an application: organizing the actions and events that it needs to progress through. • Global Control: for the entire application • Internally driven control • Externally driven control • Local control: of the parts 14.5.1

6. 6/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Architecture Options for Application Control KEY CONCEPT Control Applications • Internally driven • Externally driven • == “event-driven” • Does nothing until an even occurs • e.g., mouse actions • Each event causes a method to execute Application event • class … Globally: Event-driven (externally) or internally. … Locally: May collect control in its own class. event event

7. 7/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Designing for Interfaces • Styles of Object-Oriented Design for Application Interface • Internally-driven Interface Design • Class by classprocess • Externally-driven Interface Design • by use case -- or -- • by screen -- or -- • by user 14.5.2

8. 8/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Connecting to Databases • Ensure class model supports collection • Choose centralized or distributed storage architecture • Store data in relational or object-oriented database 14.5.3

9. 9/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Ensure Object Model Allows Data Capture Customer Teller Mediator for data capture Transaction Account

10. 10/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Data Management Architectures • Distributed : objects store themselves • Central: use specialized storage classes • to create instances • to destroy instances • to make efficient use of space • e.g. garbage collection

11. 11/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Distributed Data Storage Transaction float time Customer* cust CheckAccount* chAcc SavingsAccount* svgAcc store() Objects store themselves cassie: Customer “3 Main”: addr edward: Teller 54321: empNum trans129:Transaction time: 0932 cAcc16: CheckAccount 100: lastWithdrawal sAcc12: SavingsAccount 3003: balance

12. 12/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Centralized Data Storage Objects send their contents to a storage utility class or module transaction123: Transaction time: 0932 Data Storage Package attribute values Storage store(...) Object…:Class… Object…:Class…

13. 13/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Using Relational Databases with OO Transaction time customer account • Objects re-assembled in memory by application and database. • Data, not objects stored. DBMS tables DBMS: Database Management System

14. 14/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design OO Databases Transaction time customer account • Objects delivered to memory for re-use. • Objects, not data, stored. OODBMS tables

15. 15/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design OO Databases: Relationships Maintained

16. 16/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Relational DBMS vs. OO DBMS • RDBMS based on a data model • tables of rows & columns • ODBMS based on a programming technology (the OO method) • data model defined by the program

17. 17/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Completing the Design KEY CONCEPT Design Goal: Reusability • Replace ambiguous associations, • Expose all dependencies • Split selected classes for improved design. We reduce dependencies among classes to promote their reuse in other applications. 14.5.4

18. 18/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Examining Associations: Many-To-Many e.g. wedding gift registration system: Store Couple 1..n 1.. n ... may uncover a required class: an "event-remembered" or mediator (Registration in this case). 1..n 1 1..n 1 Store Registration Couple

19. 19/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Examining Associations: Class-to-Itself ... Business ... may uncover a required class: frequently an "event-remembered" 2...n Business JointVenture 2...n Business Merger

20. 20/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Examining Aggregations for Short Circuits 1..n 1..n Supermarket Shelf Item ------ But not every item is on a shelf ----- 1..n 1..n Supermarket Shelf Item Add: 0..n looseItem

21. Envision system growth Leverage inheritance properly 21/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Consider Splitting Classes Help WinProcedure WinProcedureHelp

22. 1. Required by… 22/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Completing Operations 1.1 Use-case model (sequence diagrams) 1.2 State Model (event handlers; functionality on entering states) Class Operations 1.3 Component model 1.4 Design Patterns 2. Design the algorithm for each operation (activity diagrams? pseudocode?)

23. 23/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Completing WinHelpOperations showCategoryOptions() Partial Component Model category String demoExample() WinHelp getProblem() match() getCategory() WinProcedureExample demoExample() u c u WinProblem getCategory() getVisible() savePrimaryParameters() showCategoryOptions() WinProcedure describe() c u u s c key: from... u: use case s: from state model c: from component model

24. 24/24 Intro Designing Control Designing for Interfaces Data Access Completing the Design Summary • Design for data capture • Design control • Design interfaces • Exploit abstraction • Reduce many-to-many associations • Finalize design of associations • Obtain all functions from use case-, state-, and component models • Design individual functions