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.

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.

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

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.

Client host Client host Server host

Part of the rationale Specialization: Sharing: 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

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

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

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

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

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

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

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

amazon.com What is presentation, application logic, shared data? Presentation: Web browser Application logic Shared data

Schwab What is presentation, application logic, shared data?

Question What types of social applications would be appropriate for a client/server architecture? Deferred applications need a server -- you wouldn’t want communication to fail because a client was turned off, and there is often a “consolidation” function (example chatroom) Immediate applications can be done peer-to-peer -- if a client is turned off, no point to the application anyway. Also avoids server bottlenecks. Server may still have a role is filtering or consolidation.

Departments Enterprise-to-enterprise Commerce Consumer Enterprise

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

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

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

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

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

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

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

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

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

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

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

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

Shortcomings of client/server Departmental solution Proliferates non-interoperable technologies and applications Hardwired applications lose flexibility Major goal: flexibility to meet new business opportunities and new organizational structures More tiers to logically decouple roles Away from stovepipe: horizontal as well as vertical structure What are some goals and likely characteristics of future enterprise architectures?

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

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

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.

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

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

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.

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”

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.

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

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.

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.

Prototyping the user interface Rapid prototyping encourage the incremental development approach

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.

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.

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.

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.

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.