Module 4: User Services Contents Overview Introduction to User Services Technologies Design and Implementation Considerations 20 Market Purchasing 24 Best Practices 27 Lab 4: User Services 28 Review 35 Information in this document is subject to change without notice The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property  2000 Microsoft Corporation All rights reserved Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, Microsoft Press, MSDN, MS-DOS, PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries Other product and company names mentioned herein may be the trademarks of their respective owners Program Managers: Rhy Mednick, Susie Parrent Instructional Designer: Susie Parrent Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud Media Management: David Mahlmann Editing Manager: Lynette Skinner Editor: Mick Alberts, Jennifer Linn Production Manager: Miracle Davis Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training Solutions, Inc.) Build Coordinator: Eric Wagoner Graphic Artist: Scott Serna Test Lead: Eric Myers Manufacturing Manager: John Williams Group Product Manager: Juan Fernando Rivera Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer Manufacturing Manager: Rick Terek Operations Coordinator: John Williams Manufacturing Support: Laura King; Kathy Hershey Lead Product Manager, Release Management: Bo Galford Group Manager, Courseware Infrastructure: David Bramble General Manager: Robert Stewart Module 4: User Services iii Instructor Notes Presentation: 60 Minutes This module provides students with knowledge about creating the logical and physical designs of user services Lab: 60 Minutes After completing this module, students will be able to: ! Describe the logical and physical designs of user services ! Describe the differences between thin client and rich client physical designs and the technologies that are involved in each ! Create a physical design for a thin client solution ! Create a physical design for a rich client solution ! Describe the logical and physical designs for the Market Purchasing user services Materials and Preparation This section provides the materials and preparation tasks that you need to teach this module Required Materials To teach this module, you need the following materials: ! Microsoft® PowerPoint® file 1910A_04.ppt ! Module 4: User Services ! Lab 4: User Services Preparation Tasks To prepare for this module, you should: ! Read all of the materials for this module ! Complete the lab iv Module 4: User Services Module Strategy Use the following strategy to present this module: ! Introduction to User Services The purpose of this section is to introduce students to the logical and physical designs of user services The focus of the logical design is on the creation of a metaphor for the user/system interaction The focus of the physical design is on the selection criteria for the technologies that will be used to implement the metaphor One of the selection criteria will involve whether to choose a thin client or a rich client In the topic “The Business Problem,” emphasize that the selection of an appropriate metaphor is an art rather than a science ! Technologies The purpose of this section is to introduce students to the technologies that can be used in the physical design of user services The technologies are separated into five categories: protocol, content presentation, data exchange, parsing and rendering, and components In each technology category topic, review the important technology items This section also includes a demonstration of an Extensible Markup Language (XML)/extensible style language (XSL) viewer For more information about Simple Object Access Protocol (SOAP), go the Web site located at http://msdn.microsoft.com/xml/general/toolkit_intro.asp and read the article “Web Services and the SOAP Toolkit for Visual Studio 6.0.” ! Design and Implementation Considerations The purpose of this section is to present the design and implementation considerations for choosing a thin client vs a rich client In the topic “Implementation Considerations,” review the table of features and the justifications for the choices between thin client and rich client designs This is an opportunity to solicit student participation in the discussion about the justifications ! Market Purchasing The purpose of this section is to review the logical and physical designs of Market Purchasing and to explain the justification for the choices made The logical design metaphor is a frame-based structure with multi-level menu selections This model was chosen because it provides simplicity of interaction The physical design uses a thin client when possible for speed and a rich client for interactions with the user that would be difficult to implement with a thin client ! Best Practices In this section, emphasize that discovering a “real world” metaphor that is easy to use and implement is crucial to good user services logical design This might not be achievable, however The alternative solution is to create a generic menu-based interface, as in the case of Market Purchasing Module 4: User Services Lab Strategy ! Lab 4: User Services The purpose of Lab is for students to learn to design user services Students probably will not derive answers that correspond exactly to the design of Market Purchasing This is acceptable as long as the student answers are justified and reflect the principles discussed in the module Discuss with students their answers to Lab v Module 4: User Services # Overview Topic Objective To provide an overview of the module topics and objectives ! ! Design and Implementation Considerations ! Market Purchasing ! In this module, you will learn about user services and how to create a logical design and a physical design for user services Technologies ! Lead-in Introduction to User Services Best Practices This module provides students with knowledge about how to create the logical and physical designs of user services After completing this module, you will be able to: ! Describe the logical and physical designs of user services ! Describe the differences between thin client and rich client physical designs and the technologies that are involved in each ! Create a physical design for a thin client solution ! Create a physical design for a rich client solution ! Describe the Market Purchasing user services logical and physical designs Module 4: User Services # Introduction to User Services Topic Objective To provide an overview of the section topics and objectives Lead-in ! The Business Problem ! Business Requirements In this section, you will learn about the business problem facing designers that must implement user services The focus of this presentation is on the implementation of user services as Web clients User services can be developed by using Microsoft® development tools such as Microsoft Visual Basic®, Microsoft Visual C++®, and Microsoft Office to create a rich user experience that uses the full capabilities of the user computing environment (often referred to as rich clients) Technologies such as dynamic HTML (DHTML) and ActiveX® controls can provide varying degrees of richness of functionality Alternatively, lighter-weight HTML front ends (often referred to as thin clients) can be developed by using Microsoft FrontPage® or Microsoft Visual InterDev® and hosted on Internet Information Services (IIS) These HTML-based applications allow greater reach to clients in intranet and Internet solutions with technologies such as Active Server Pages (ASP) In this section, User services will be placed in the proper context of the business problem A discussion about the business requirements of user services will follow Module 4: User Services The Business Problem Topic Objective User Services To provide background about the business problem Lead-in In this topic, you will learn about the business problem facing designers that must implement user services Facade Layer Web Services Facade Business Facade Food Menu User services represents a translation of the use cases of a conceptual design to a metaphor A metaphor is an underlying model for representing the interaction between a user and the information system that is supporting the user in the particular system An example of a user services metaphor is a shopping basket used on an e-commerce site or an airplane seating chart in an airline reservation system The metaphor governs the way data is represented and input is gathered In particular, the metaphor should facilitate the following activities: ! Data presentation Data presentation is the format in which data is presented to a user Data can be presented in text or as part of a metaphor For example, in Market Purchasing, the items purchased can be represented either as lines on a requisition form or as items in a shopping basket The requisition form and the shopping basket represent metaphors for the Market Purchasing user interface The data must be presented as an integral part of the metaphor ! Sending user input to business services A secondary role of user services is to send data to the business services Access to business services is controlled by a facade The discussion of facades will be presented in Module 5, “The Facade Layer.” ! Receiving results from business services The complement of sending data to business services is receiving results from business services ! Data capture User services, as represented by the metaphor, should facilitate the capture of data from a user as part of the interaction between the user and the system For example, the Enter New Requisition use case must capture the user’s selections for country, requisition class, vendor, and part class Module 4: User Services ! Data validation User services plays a critical role in data validation by presenting to the user only the valid choices In the logical design of user services, we have progressed a long way from the text-based data entry, in which data was not validated until it was submitted to business services Today, data validation occurs at the source ! Providing task guidance for the user A successful user services metaphor is one that is intuitive and easy to use The successful user services metaphor guides the user (imperceptibly) through the activities like an invisible hand ! Displaying errors to the user Users can always make mistakes Accepting responsibility for mistakes and correcting them is a stressful human endeavor Successful user services provide a friendly and nonstressful mechanism for notifying users of errors and allowing them to correct them An even better approach is to try to design the user interface to help users avoid errors altogether, by using elements such as drop-down list boxes or spin boxes The logical design of user services includes a specification of the metaphor Metaphors enable a business application to imitate the actual business process by implementing the representation of the artifacts used by the business One of the most obvious metaphors in information technology (IT) applications is the menu A menu in a restaurant provides a customer with a list of available choices When you try to select a choice that is not currently available, the waiter notifies you of the situation and recommends that you make another selection A computer menu provides similar functionality The computer menu, however, can list only the available choices from which you can select Using metaphors that represent the artifacts of a business or organization enables the IT representation to present a reality with which the user is familiar Following are some examples of metaphors used in business environments: ! Cash registers representing sales in a retail environment ! Pushpins representing a note ! A form representing a requisition A more detailed discussion of the logical design issues of user services and using business metaphors is presented in Module 11, “Designing the Presentation Layer,” of the MSDN Training Course 1608A: Designing Business Solutions It should be noted that business rules are never implemented or enforced in user services 22 Module 4: User Services Rich Client Design Topic Objective To provide a discussion of design considerations for a rich client Lead-in In this topic, you will learn about the constraints for which a rich client design holds an advantage ! Network Constraints ! Security Constraints ! Cost of Ownership Constraints A rich client is one that is capable of performing processing on the client computer The rich client could be a Web page that uses dynamic HTML or ActiveX controls downloaded to the client, or it could be a Win32® client such as a Visual Basic executable running on the client computer The design considerations for a rich client can be summarized with three terms: speed, security, and increased functionality If you need to have a Web-based application with user services that can return results quickly and efficiently, then the optimal choice for a physical design is the rich client In addition, the rich client user can implement security through the operating system and has access to the services provided by the operating system Finally, in terms of total cost of ownership, which takes into account not only the cost of the client but also the cost of servicing those clients and the additional load on the middle-tier servers, the optimal solution is again the richclient physical design Module 4: User Services 23 Implementation Considerations Topic Objective To provide a discussion of implementation considerations for a rich client Development Time X Lead-in Robustness X Maintenance X Upgradeable X Thin Client In this topic, you will learn about the benefits and drawbacks of a rich client design Rich Client Turnaround Time X Scalability X In trying to justify the selection of a rich client as the physical design for user services, five criteria can be measured: ! Development time In general, the development time for a thin client is shorter than that for a rich client This is because it is it is more difficult to create and implement distributed solutions for a rich client ! Robustness In general, a thin client design is more robust than that of a rich client, mainly because of the server-side robustness ! Maintenance In general, a thin client design is more maintainable than a rich client design because all the code exists in one place on the server ! Upgradeable In general, it is easier to upgrade a thin-client design than a rich client design because all of the design changes can be implemented in one place and there are no difficulties in propagating the changes to the client computers ! Performance Because every activity within a page of a thin client design typically requires access to a Web server, the turnaround time of a thin client for any operation is usually slower than that of a rich client design Moreover, the number of users that can be supported by a thin client is significantly more limited than that of a rich client design 24 Module 4: User Services # Market Purchasing Topic Objective To provide an overview of the section topics and objectives Lead-in ! Market Purchasing Logical Design ! Market Purchasing Physical Design In this section, you will learn about how the logical and physical design was applied to the Market Purchasing user services In this section, you will learn how the logical and physical design guidelines were applied to the user services of Market Purchasing Module 4: User Services Market Purchasing Logical Design Topic Objective To provide an overview of the Market Purchasing user services logical design Lead-in In this topic, you will learn how the Market Purchasing user services logical design was implemented The logical design of the user services for Market Purchasing, as shown in the slide, incorporates several principles: ! The metaphor for creating a requisition is that of a shopping basket When you select products for a requisition, they are added to the basket until you are ready to submit or save the requisition ! The logical design of Market Purchasing allows data capture as well as a data display of the results, which are all based on a requisition view ! The menu options are context dependent For example, requestors only see menu options for creating and finding requisitions Managers also see a menu option for approving requisitions Administrators see an additional menu option for administration The menus will change depending on the type of user that is logged on 25 26 Module 4: User Services Market Purchasing Physical Design Topic Objective To provide an overview of the physical design of the Market Purchasing Web services facade layer ! User Services Implemented as Web Pages ! Rich Client Used for Some of the Difficult Interactions Lead-in In this topic, you will learn how the physical design of the Market Purchasing Web services facade layer was implemented $ $ ! TreeView control for displaying categories Remote Data Services for maintaining disconnected data on administrative pages Thin Client Used for Everything Else The physical design of the user services for Market Purchasing implements the user services as a collection of Web pages Rich client features are used for difficult interactions with the user For example, a TreeView control is used to display hierarchical categories to the user Also, remote data services are used to cache disconnected data on the client browser On the administration pages, this allows tables from the database to be displayed As the administrator makes changes, the disconnected recordset is updated, and the changes are sent back to the server Because Market Purchasing is a corporate application, there are no bandwidth restrictions or browser restrictions that prevent this kind of solution Thin client is used for all other Web pages in Market Purchasing For example, logging on is implemented as a thin client since there is no need for rich services Module 4: User Services 27 Best Practices Topic Objective To provide a discussion of the best practices for the logical and physical designs of user services ! Use a “Real-World” Metaphor for the Logical Design of User Services Lead-in ! Use a Thin Client Physical Design for User Services When Portability Is the Main Concern ! Use a Rich Client Physical Design for User Services When Network Bandwidth Is the Main Concern In this topic, you will learn the three best practices for designing user services Three important points stand out with respect to the logical and physical designs of user services: ! The logical design of user services should be based on a metaphor The best metaphor to use is one with which a user working in the “real world” would feel an affinity ! For mobile users, it is better to create a thin client physical design that would impose little or no restrictions on the device and the method they use to access the system ! For enterprise users who have a need for full-feature, fast, and timely access to an enterprise application, a rich client physical design is the optimal choice 28 Module 4: User Services Lab 4: User Services Topic Objective To introduce the lab Lead-in In this lab, you will create the logical and physical design of User Services by using both thin and rich client technologies Explain the lab objectives: Objectives After completing this lab, you will be able to: ! Implement logical and physical designs of user services for both a rich client and a thin client Prerequisites Before working on this lab, you must: ! Complete Module 4, “User Services.” ! Complete Lab 3, “Logical Design and Behavioral Design Patterns.” Note The solution for this lab is in the install folder\Labs\Lab04\Solution folder Estimated time to complete this lab: 60 minutes Module 4: User Services 29 Exercise Designing and Implementing User Services for a Thin Client In this exercise, you will design user services for the Approve/Deny Requisition use case This use case allows a manager to approve or deny a requisition The manager logs on to the system and accesses a list of requisitions awaiting approval The manager selects a requisition, reviews the detail, if necessary, and approves or denies the requisition The requisition status is updated and the activity is logged ! Derive the logical design • Design a new class that will implement the Approve/Deny Requisition use case Name the class usr_ApproveDenyRequisition Define all methods for this class Identify the behavioral design pattern that can be used in this class Students will discuss their answers in Exercise 2, in the procedure "Examine the Market Purchasing solution," step 30 Module 4: User Services Exercise Updating the Logical and Physical Designs In this exercise, you will examine the solution for the Approve/Deny Requisition use case You will also update the logical and physical designs of Market Purchasing to reflect the solution ! Examine the Market Purchasing solution Examine the following solution to the Approve/Deny Requisition use case: usr_ApproveDenyRequisition Behavioral Patterns None Methods DisplayRequisitions SelectRequisition DisplayRequisitionDetail ApproveDenyRequisition What differences, if any, are there between your answer and this solution? Discuss the differences with others or with your instructor ! Modify the Market Purchasing logical design Click Start, point to Programs, and then click Microsoft Visio On the File menu, click Open, and then open the Market Purchasing.vsd file This file is in the install folder\Labs\Lab04\Start folder In the right pane, click the LD - User Services tab Add the usr_ApproveDenyRequisition class and its methods Save the design Module 4: User Services 31 ! Derive the physical design Which Web technologies should you use to implement the usr_ApproveDenyRequisition class? Thin client technologies such as HTML and ASP The user interface design specifies that for the Approve/Deny Requisition use case, a list of requisitions should be displayed for the manager There are three buttons for each requisition These buttons read Approve, Deny, and View Which Web files would you create to implement the usr_ApproveDenyRequisition class for this interface? ReqSearchRequisition.asp is the main file in Market Purchasing that displays the requisitions and buttons to approve, deny, or view the requisitions The buttons will call another page, ReqProceedRequisition.asp, passing values in the URL, which proceeds with the work of approving, denying, or viewing the requisitions Students should develop a scheme similar to this one, in which the ASP files implement the methods from usr_ApproveDenyRequisition and static HTML displays the results (either from the ASP files or through HTML files) ! Modify the Market Purchasing physical design Click Start, point to Programs, and then click Microsoft Visio On the File menu, click Open, and then open the Market Purchasing.vsd file This file is in the install folder\Labs\Lab04\Start folder In the right pane, click the PD - User Services tab Add the Web files that you derived to implement the usr_ApproveDenyRequisition class Save the design 32 Module 4: User Services Exercise Designing and Implementing User Services for a Rich Client In this exercise, you will design user services for the Modify Entity Data use case The Modify Entity Data use case allows an administrator to modify tables in the Market Purchasing database The tables that can be modified are category, part, requestor, vendor, country, and unit You will design a class that modifies the requestor table ! Derive the logical design • Design a new class that will implement the Modify Entity Data use case for the requestor table Name the class usr_ModifyRequestors Define all methods for this class Identify the behavioral design pattern that can be used in this class Students will discuss their answers in Exercise 4, in the procedure “Examine the Market Purchasing solution,” step Module 4: User Services Exercise Updating the Logical and Physical Designs In this exercise, you will examine the solution for the Modify Entity Data use case You will also update the logical and physical designs of Market Purchasing to reflect the solution ! Examine the Market Purchasing solution Examine the following solution to the Modify Entity Data use case for the requestor table: usr_ModifyRequestors Behavioral Patterns Iterator Methods Display Select New Delete AcceptChanges What differences, if any, are there between your answer and this solution? Discuss the differences with others or with your instructor ! Modify the Market Purchasing logical design Click Start, point to Programs, and then click Microsoft Visio On the File menu, click Open, and then open the Market Purchasing.vsd file In the right pane, click the LD - User Services tab Add the usr_ModifyRequestors class and its methods Save the design 33 34 Module 4: User Services ! Derive the physical design Which Web technologies should you use to implement the usr_ModifyRequestors class? Rich client technologies such as XML, DHTML, ActiveX, and RDS The UI design specifies that a list box of all requestor names should be displayed to allow administrators to modify requestors When the administrator selects a requestor from the list box, the information for that requestor (employee number, work phone, and so on) is displayed in fields on the screen The administrator can then update or delete information in the fields The administrator can also create new requestors by pressing a New button Given this information, which Web pages and controls would you use to implement this interface for the user_ModifyRequestor class? AdmRequestors.asp is the main file in Market Purchasing that displays requestors and allows changes to be made A ListView control displays the requestors A disconnected recordset contains all of the requestor information When a name is selected from the ListView control, the fields for the selected requestor are displayed from the disconnected recordset Buttons on the screen create, update, or delete requestors by using RDS to call a server component that performs the actual work on the database Students might present different answers Discuss the alternatives and advantages or disadvantages of their solutions ! Modify the Market Purchasing physical design Click Start, point to Programs, and then click Microsoft Visio On the File menu, click Open, and then open the Market Purchasing.vsd file This file is in the install folder\Labs\Lab04\Start folder In the right pane, click the PD - User Services tab Add the Web files that you derived to implement the usr_ModifyRequestors class Save the design Module 4: User Services Review Topic Objective To reinforce module objectives by reviewing key points ! Describe the logical and physical designs of user services ! Describe the differences between thin client and rich client physical designs and the technologies that are involved in each ! Create a physical design for a thin-client solution ! Create a physical design for a rich-client solution ! Describe the Market Purchasing user services logical and physical designs Lead-in The review questions cover some of the key concepts taught in the module What are the seven key functions of user services? Data presentation Sending user input to the facade layer Receiving results from the facade layer Data capture Data validation checking Providing task guidance for the user Displaying errors to the user What are the key technologies for content/presentation? HTML DHTML ASP XML What are the three design considerations that indicate the use of a thin client? Hardware and software constraints Deployment constraints Support constraints 35 36 Module 4: User Services What are the three design considerations that indicate the use of a rich client? Network constraints Security constraints Cost of ownership constraints ... ! Module 4: User Services ! Lab 4: User Services Preparation Tasks To prepare for this module, you should: ! Read all of the materials for this module ! Complete the lab iv Module 4: User Services. .. rich client solution ! Describe the Market Purchasing user services logical and physical designs Module 4: User Services # Introduction to User Services Topic Objective To provide an overview of... problem A discussion about the business requirements of user services will follow Module 4: User Services The Business Problem Topic Objective User Services To provide background about the business