Chapter 4 Product Design

1. Chapter 4Product Design

2. Objectives of Design • As all other aspects of object-oriented system development, design can be deployed in an iterative or top-down development context • The design phase takes the results of the analysis phase and evolves these results further • The results of the design phase feeds directly into the implementation phase

3. Product Design versus Class Design • Product design concerns itself with creating effective interactions • Between the system and human users • Between distributed elements of the system • Between software system and solutions for data persistence (e.g. database management systems) • Class design concerns itself with determining class definitions: • Attributes • Method signatures • Class semantics

4. Product Design Overview • Product design addresses the externalstructure of the software • External structure includes all software components that interact with external resources, such as • Solutions to data or object persistence • Means by which distributed processes interact over a network (process architecture) • User Interfaces

5. Object Persistence • Object persistence seeks to retain object information on some persistent storage medium as a file or through a DBMS • Object streaming solutions work for situations were all object information can reside in memory at once • Because most commercial DBMSs are relational in contrast to object-oriented, some translation between the object and relational representations must be made

6. Evaluating Object Persistence • Security • Hacker proof • Allows reconstruction in face of malicious use • Information growth • Solution still works with increased data volume • Concurrency • Concurrency solution allows for increased users

7. LMS Case Study: Object Persistence • LMS may contain hundreds of thousands of book entries as well as thousands of other library resources • Large volumes of data are not well suited to object streaming • A DBMS is called for to provide • Concurrent access by multiple users • Security enforcement of different access levels for various user categories • Allow for increased data capacity

8. LMS Case Study: Relational Representation of Data Book Relational Tables Resource List Patron Address Patron

9. Process Architecture • Software systems may consist of processes interacting over a network • Process architecture lays out the machines (nodes) that will host the processes making up the system • Process architecture determines the behavior of the distributed processes • Deployment diagrams are used to model distributed processes

10. Sample Deployment Diagram GameServer GameClient Internet GameClient GameClient

11. Modeling Interprocess Communication • Deployment diagrams show the distribution of process over multiple nodes but do not indicate howthese processes communicate • State machines may be used to model communication between processes • The idea behind using state machines for modeling interprocess communication is that the system enters a new state when messages are exchanged between processes

12. UML Notation for State Machines State with substates Initial State State Name Final State State Name Intermediate State Trigger State transition with event trigger

13. Sample State Machine Showing Interprocess Communication { Server State} Player Joining Game Communicate remaining tokens player name available tokens selected token Get player name Select token { Client States}

14. Modeling Multiple Threads of Control • Classes that consist of a separate thread of control are modeled as active classes • Active classes are rendered with thick rectangles as shown below Active class Regular class

15. User Interfaces • The user interface enables users to interact with the software system to accomplish some set of tasks • The user interface consists of interaction techniques that facilitate this human-machine communication • It is a good idea to keep the design for the user interface and the design of the functionality of the remaining system separate

16. The Role of the User Interface User Application Functionality Internal Representation User Interface External Representation

17. User Interface Design • Five factors related to user interface quality • Ease of learning • Speed of use • Frequency of user errors • User satisfaction • Knowledge retention

18. Guidelines for User-Friendly Interfaces • Use easy to learn instructions • Make help functions context-sensitive • Present logically related functions together and consistently • Create graphical interfaces whenever possible • Allow actions to be activated quickly

19. Know the User • There are three broad categories of users • Novice • Rarely uses the computer • Knowledgeable intermittent user • Has sporadic experience with computer systems • Frequent user • Comfortable with computer systems in general

20. Rules for Interface Design • Be consistent • Provide shortcuts • Offer useful feedback • Design a beginning, middle and end for each sequence of actions • Prevent catastrophic mistakes • Verify deletion tasks

21. More Rules for Interface Design • Allow easy reversal of most actions • Allow user to focus on task not the interface • Do not rely on user memory • Display only currently relevant information

22. Interaction Styles • Menu Selection • Form Fill-in • Command Language • Natural Language • Direct Manipulation

23. Guidelines for Designing Menus • Be consistent • Use distinctive items • Be concise • Put keywords first in the item name • Create groups of logically similar items

24. Guidelines for Designing Effective Forms • Use a meaningful title • Give brief but clear instructions • Organize fields logically • Make form visually appealing • Use familiar labels • Create boundaries around data-entry fields • Allow the cursor to be moved conveniently

25. More Guidelines for Designing Effective Forms • Allow easy error correction • Prevent errors when possible • Provide error messages when invalid values are entered • Clearly mark optional fields • Explain individual fields • Clearly signal completion of data-entry

26. Design Guidelines for Command Languages • Limit the number of commands • Choose meaningful, distinctive command names • Abbreviate consistently • Select a consistent command syntax structure • Use prompts to help intermittent users • Consider using command menus to help intermittent users

27. Design Guidelines for Direct Manipulation Interfaces • Use easy to use icons • Avoid misleading analogies • E.g. Window’s trash bin allows retrieval for discarded items, otherwise this would be misleading • Do not violate cultural stereotypes • Use icons for appropriate purposes • Carefully design iconic interaction

28. Design Summary • Create solution for object persistence • Develop user interface designs • Determine process architecture

29. Working in Teams • To improve development team dynamics, engage an impartial observer • By meeting during class time and getting class feedback • By having the instructor observe all development teams during class time • By inviting another development team to observe one of your meetings

30. Possible Obstacles to Effective Meetings • Poor agendas • Dysfunctional communication during the meeting (silence or domination) • Not adhering to the agenda • Discussion may not sufficiently focus on meeting objectives specified by the agenda • Team members are not listening to each other during discussion