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: 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

7. 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

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

9. Email application Server Client Client
client sends message to server
Later, recipient’s 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. Application partition
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 What is presentation, application logic, shared data?
Presentation: Web browser
Application logic
Shared data

15. Schwab
What is presentation, application logic, shared data?

16. 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.

17. Departments
Enterprise-to-enterprise
Commerce
Consumer
Enterprise

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

19. 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

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

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

22. 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

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

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

25. 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

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. 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

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

30. 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?

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.