1 / 47

object oriented design process.

object oriented design process. Apply design axioms to design classes, their attributes, methods, associations, structures and protocols. Design the access layer. Design the view layer classes

laurajones
Télécharger la présentation

object oriented design process.

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. object oriented design process. • Apply design axioms to design classes, their attributes, methods, associations, structures and protocols. • Design the access layer. • Design the view layer classes • Iterate and refine the whole design. Reapply the design axioms and if needed repeat the preceding steps.

  2. OBJECT ORIENTED DESIGN AXIOMS • AN axiom is a fundamental truth that always is observed to be valid and for which is no counterexample or exception. • A theorem is a proposition that may be self –evident but can be proven from accepted axioms. • The author has applied Suh’s design axioms to object-oriented design.

  3. Corollary • 1: Uncoupled design with less information content • Corollary 2: Single purpose • Corollary 3: Large number of simple classes • Corollary 4: Strong mapping • Corollary 5: Standardization • Corollary 6: Design with inheritance

  4. Axiom 1 deals with relations between system components and axiom 2 deals with the complexity of design. • AXIOM 1: THE INDEPENDENCE AXIOM: maintain the independence of the components. • AXIOM 2: THE INFORMATION AXIOM: minimize the information content of the design.

  5. Client host Client host Server host

  6. Part of the rationale • Specialization: • Clients specialize in user interface • Servers specialize in managing data and application logic • Sharing: • Many clients can be supported by few servers • Often data and logic are shared among applications and users

  7. “I want to collaborate with my colleague” “I want to access some information” Client Server Peer-to-peer Client/server

  8. Distinctions • Client-server • Asymmetric relationship • Client predominately makes requests, server makes replies • Peer-to-peer • Symmetric relationship

  9. Email application Server Client Client Email client sends message to server Later, recipient’s email client retrieves message from server Message is stored on POP server

  10. Chat application Server Client Client Chat server aggregates typing from all users and sends to all clients Other user’s clients display aggregated typing from chat server Chat clients send user’s typing to server

  11. Three-tier client/server Local-area network Application logic Presentation Note: many clients per application server, several application servers per data server Shared data

  12. Client Host architecture Web browser Web server Common gateway interchange Application logic Databases and DBMS Application partition

  13. Practice in defining tiers • Online bookseller (e.g. amazon.com) • Stock trading system (e.g. Schwab or E-trade)

  14. amazon.com

  15. Schwab

  16. Question • What types of social applications would be appropriate for a client/server architecture?

  17. Departments Enterprise-to-enterprise Commerce Consumer Enterprise

  18. software4u.com Customers Customer-service department Technical-support department Consumer Enterprise

  19. Consumer application Enterprise application Problem knowledge base Software documentation Customer audit Web browser Web browser Web browser Web server Web server Web server Customer care Customer logic Agent logic Technician logic Databases

  20. Customers Agents Technicians Agent logic Technician logic Customer logic Databases Accounts Products Orders

  21. Financial institution Book distribution centers Customers books4u.com Consumer Enterprise Inter-enterprise

  22. Merchandise Customers Orders Consumer e-commerce Inter-enterprise e-commerce Web browser Web server Book merchant Customer logic Fullfillment logic Outside links Databases Acquirer bank Book distributors

  23. Clients Acquirer bank Customer logic Fullfillment logic Databases Book distributors Merchandise Orders Customers

  24. Information providers Customers Stock market stocks4u.com Consumer Enterprise Inter-enterprise

  25. Products Orders Accounts Consumer e-commerce Inter-enterprise e-commerce Web browser Web server Stock trader Customer logic Trading logic Outside links Databases Information providers Financial markets

  26. Clients Information providers Customer logic Trading logic Databases Financial markets Accounts Products Orders

  27. Financial institution Customers flowers4u.com Local florists Consumer Enterprise Inter-enterprise

  28. Consumer e-commerce Inter-enterprise e-commerce Products Orders Accounts Web browser Push server Web server Push client Florist delivery Customer logic Fullfillment logic Outside link Databases Acquirer bank

  29. Customers Florists Fullfillment logic Customer logic Acquirer bank Databases Accounts Products Orders

  30. Shortcomings of client/server • Departmental solution • Proliferates non-interoperable technologies and applications • Hardwired applications lose flexibility What are some goals and likely characteristics of future enterprise architectures?

  31. Forms and entry windows • It provide access to data that users can retrieve , display, and change in the application.

  32. Dialog boxes • It display status information or ask users to supply information or make a decision before continuing with a task. • Ok or cancel

  33. Application windows • An application window is a container of application objects or icons. In other words , it contains an entire application with which users can interact.

  34. Guidelines for designing forms and data entry windows • In general, what kind of information will users work with and why? For eample, a user might want to change inventory information , entry orders or maintain prices for stock items. • Do users need access to all the information in a table • In what order do users want rows to appear? • Next identify

  35. Navigating rows in a table, such as moving forward and backward , and going to first and last record. • Adding and deleting rows. • Changing data in rows. • Saving and abandoning changes. • Menu push buttons

  36. Paper form such as a printed invoice, as the starting point for your design. • Users scan a screen in the same way they read a page of a book, from left to right and top to bottom. • When information is positioned vertically, align fields at their left edges. • When entering data, users except to type information from left to right and top to bottom, as if they were using a typewriter.

  37. Guidelines for designing dialog and error messages • A dialog provides an exchange of information or a dialog between the user and the application. • Your error message should be positive. For example instead of displaying “ you have typed an illegal date format” display the message “ enter date format mm/dd/yyyy”

  38. Guidelines for the command buttons layout • Layout out the major command buttons either stacked along the upper-right border of the dialog box or lined up across the bottom of the dialog box.

  39. Guidelines for designing application windows • A typical application window consists of a frame that defines its extent and a title bar that identifies what is being viewed in the window. • File menu-new, open , print, save • Edit menu- cut, copy, paste • View menu • Window menu • Help menu

  40. Guidelines for using colors • For all objects on a window , you can use colors to add visual appeal to the form. • You can use identical or similar colors to indicate related information. For example , savings account fields might appear in one color. • For an object background , use a contrasting but complementary color.

  41. Guidelines for using fonts • Use commonly installed fonts, not specialized fonts that users might not have on their machines. • Use bold for control labels, so they will remain legible when the object is dimmed. • Using too many font styles , sizes and colors can be visually distracting and should be avoided.

  42. Prototyping the user interface • Rapid prototyping encourage the incremental development approach

  43. Guidelines for designing dialog boxes and error messages: - • 1. Your error message should be positive. • 2. Your error message should be constructive. • 3. Your message should be brief and meaningful. • 4. Orient the controls in the dialog box in the direction people read.

  44. Guidelines for the command buttons layout: - • 1. Position the most important button • 2. If you see OK and Cancel buttons, group them together. • 3. If you include a Help command button, make it the last button in the set • 4. Avoid making this button the default button • 5. Make buttons a consistent length.

  45. Guidelines for designing application windows: - • 1. File Menu: this provides an interface for the primary operations that apply to a file. • 2. Edit Menu: Include general purpose editing commands on the Edit menu. • 3. View menu and other command menus • 4. Window menu • 5. Help menu – contains commands that provide access to Help information. • 6. Toolbars and status bars: special interfaces constructs for managing sets of controls.

  46. Guidelines for using colors: - • 1. You can use identical or similar colors to indicate related information. • 2. For an object background, use a contrasting but complementary color. • 3. You can use dim colors to make other elements less noticeable. • 4. using too many colors can be visually distracting and will make your application less interesting • 5. Allow the user to modify the color configuration.

  47. Guidelines for using fonts: - • 1. Use commonly installed fonts, not specialized fonts that user might not have on their machines. • 2. Use bold for control labels. • 3. Use fonts consistently within each form and among all forms in your application • 4. Using too many font styles, sizes and colors can be visually distracting and should be avoided.

More Related