基于NET的需求分析和解决方案设计07.docx
《基于NET的需求分析和解决方案设计07.docx》由会员分享，可在线阅读，更多相关《基于NET的需求分析和解决方案设计07.docx（17页珍藏版）》请在冰豆网上搜索。
基于NET的需求分析和解决方案设计07
第7章表示层的设计
本章概述
前面已经学习了设计业务解决方案的过程，且主要着重于构思阶段和计划阶段，计划阶段包括概念设计、逻辑设计和物理设计过程。
但是，任何由用户使用的应用程序如果没有经过与用户之间的交互，这个应用程序的设计就不算完整。
用户交互依靠应用程序表示层（presentationlayer）来实现。
应该在物理设计过程中设计应用程序的用户界面。
在本章中，将学习应用程序表示层的设计，还将学习表示层的两个部分——用户界面（UI,userinterface）和用户处理组件――以及如何设计它们。
教学目标
●解释业务解决方案表示层的功能
●设计能满足用户需要和业务需求的用户界面
●设计用户处理组件
教学重点
●设计能满足用户需要和业务需求的用户界面
●设计用户处理组件
教学难点
●创建一个与用户交流的友好的平台，需要通过老师不厌其烦的讲解一些具体的例子，才能使学生领悟到其中的一些感觉
教学资源
课本
知识点
7.1用户界面设计的基础
7.2设计用户界面
7.3设计用户处理组件
习题
习题1-对应知识点用户界面设计的基础
习题2-对应知识点设计用户界面
习题3-对应知识点设计用户界面
习题4-对应知识点设计用户界面
习题5-对应知识点设计用户处理组件
教师光盘
幻灯片
教师光盘：
\Powerpnt\2710B_07.ppt
多媒体视频
教师光盘：
\Powerpnt\
习题解答
教师光盘：
\tPrep\answer
先修知识
在正式开始学习本章内容以前，学生须具备下列知识基础。
先修知识
推荐补充
了解Windows程序设计的基础知识。
《基于VB.NET的Windows程序设计》
了解WEB类程序设计的知识。
《面向.NET的Web应用程序设计》
连接XMLWebService开发的知识。
《XMLWebService开发》
建议学时
课堂教学（2课时）
教学过程
7.1用户界面设计的基础
教学提示：
Microsoft解决方案物理设计概述主要达到两个目的。
●解释用户界面组件的功能。
（略讲）
●确定能够应用于用户界面设计中的隐喻与元素。
（略讲）
教学内容
教学活动
教学提示
讲授：
简单的表示层包含由图形用户界面（GUI，graphicaluserinterface）所承载的用户界面组件，GUI可以是MicrosoftWindows®窗体或MicrosoftASP.NETWeb窗体。
比如我们经常浏览的淘宝网，可能需要两个用户界面：
一个是客户使用的电子商务Web站点的用户界面，另一个是销售代表使用的基于Windows窗体应用程序的用户界面。
第一个是给我们大家看的，让大家从站点上可以看见各种商品的文字信息，图片信息，3D演示等。
同时提供大家电子交易的平台，类似我们使用的支付宝。
而另外一套给销售代表使用的Windows窗体应用程序用户界面是给淘宝网工作人员使用的。
让他们能够维护大家的定单和交易信息。
两种用户界面都必须提供以下能力：
查看现有产品，向购物车中添加产品，并将指定的付款细节作为结算处理的一部分。
该过程可以提取到一个独立的用户处理组件中，使得应用程序易于维护。
在构思和计划阶段中进行调研、分析和优化所得出的信息是表示层设计的输入
讲解课本:
7.1.1
阅书：
7.1.1
幻灯：
第4页
讲授：
表示层的第一部分是用户界面。
在某些方面，界面甚至可以被认为是业务应用程序中最重要的部分，因为对大多数用户来说，界面就是应用程序。
一个设计良好的用户界面有助于保证业务应用程序的成功并被用户所接受。
比如大多同学使用的MSN,这个软件从一开始的4.2版本到现在的7.5版本，包括现在正在公测的LiveMessage。
除了在功能上面有大面积的改观之外，大家能体会到的最大的改观就是在界面上。
界面的设计应该说是越来越美观。
用户界面组件在模型-视图-控制器（MVC，Model-View-Controller）模式中充当视图或控制器角色，或者两者兼有。
Model-View-Controller（MVC）模式基于用户输入将域的建模、显示和操作分为三个独立的类：
模型。
模型用于管理应用程序域的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）。
视图。
视图用于管理信息的显示。
控制器。
控制器用于解释用户的鼠标和键盘输入，以通知模型和/或视图进行相应的更改。
讲解课本：
7.1.2
阅书：
7.1.2
幻灯：
第6页
●ＭＶＣ请参考链接：
讲授：
现在我们来看一下用户界面组件的功能：
讲解课本：
7.1.3
比如：
我们的界面上，不管是WEB类的还是WINDOWS类的应用程序，我们都会接触到众多的输入框，下拉列表等。
从中我们可以得到我们需要和机器交互的数据。
我们经常会在进行一些操作的时候，得到一些弹出式提示。
同时在进行输入的同时，界面会对我们输入的数据进行检查和格式化。
而不会让我们随心所欲的输入一些非法数据。
同时在数据进行处理的时候，我们会在界面上看见LOADING的字样，前面这些例子都是用户界面组件在我们实际应用中体现出的功能。
阅书：
7.1.3
幻灯：
第8页
讲授：
我们来看一下用户界面设计的指导方针：
讲解课本：
7.1.4
阅书：
7.1.4
幻灯：
第9页
讲授：
通过使用熟悉的隐喻来表示用户界面元素，提供了一种将用户知识与经验转移到用户界面设计的方法。
隐喻依靠用户识别而不是用户的记忆。
比起让用户记住一个特定命令的名字，用户更容易识别一个与熟悉对象相关联的含义。
讲解课本：
7.1.5
阅书：
7.1.5
幻灯：
第11页
讲授：
用户通过界面来判断应用程序的优劣。
如果界面无法为用户提供一个良好的体验，对应用程序开发所做的全部努力就失去价值了。
“以貌取人”的现象其实还是广泛存在于人们心底的。
其实我们大家在拿到一款新的Windows操作系统的时候，往往大家都会因为它比前一个版本在界面上有了很大的变革，首先给了大家一个很直观的视觉刺激而认为这个版本的Windows肯定很好用。
这就是良好的界面带给软件的功效。
设计良好的界面的特点：
●直观设计
●最适宜的屏幕空间利用
●合适的外观
●易于导航
●受控导航
●填充默认值
●输入验证
●菜单
●高效事件处理
讲解课本：
7.1.6
阅书：
7.1.6
幻灯：
第13页
7.2设计用户界面
教学提示：
本节主要达到一个目的。
●学会如何创建和设计用户界面。
（精讲）
教学内容
教学方法
教学提示
讲授：
首先我们需要创建用户界面的一个雏形。
但我们在实际的开发环境内也必须实现这样的一个仿真环境。
讲解表7-1
同时也要为所有的界面创建一个流程图。
从而可以知道所有的界面直接的调用关系。
比如：
一个小型的图书馆管理系统。
首先会有一个登陆界面，给用户输入用户名和密码。
然后可以让用户进入菜单画面选择需要进入的管理模块，然后再进入各个管理模块后，进行各个功能的管理。
讲解课本：
7.2.1
阅书：
7.2.1
幻灯：
第16页
讲授：
在计算机应用程序中，用户帮助常常被忽略或实现的不尽如人意。
有几个可用的选择来提供应用程序用户帮助。
但这确实为一个软件产品非常重要的组成部分。
比如我们使用的OFFICE软件，就会有一个小助手帮助提示我们每一步操作该如何进行。
或者我们使用的VS开发软件，也有配套的MSDN作为我们的开发手册来使用。
这些都是一些非常好的帮助文档。
我们可以有以下几个选择：
●在线帮助
比如微软的MSDN和TECHNET
●工具提示
比如我们将鼠标移动到某些控件上之后，会跳出一些必要的提示。
●状态显示
状态显示是一个提供说明或消息的有效方法，这些说明或消息可能不太适用于工具提示。
为了提供状态显示，可以使用状态条控件或标签控件。
●向导
类似我们安装程序的时候提供一步步完成的阶段。
●辅助功能帮助
比如有的软件会附加一些FLASH小视频作为软件使用的说明演示。
讲解课本7.2.2
阅书：
7.2.2
幻灯：
第18页
讲授：
当设计应用程序时，选择最佳用户界面模型非常重要。
因为用户界面可以影响部署、用户交互方式和相关的数据，以及在应用程序与用户进行交互时保持状态的方法。
一般用户界面的实现模型和技术包括：
●基于Windows用户界面
比如我们平时去图书馆使用的图书查询系统，这就是一种基于Windows的用户界面。
●基于Web用户界面
比如我们使用的TAOBAO网络的用户界面就是一个WEB界面的范畴。
●移动设备用户界面
比如我们使用手机中的一些应用软件的界面。
●基于文档用户界面
比如一些EXCEL文件，其中使用VBA编写了宏。
讲解课本7.2.3
阅书：
7.2.3
幻灯：
第19页
讲授：
许多瘦客户端技术都是有关服务器端的，而目前有许多Web服务器平台和框架（ASP、ASP.NET、JSP及其他）可供选择。
每种平台都具有一些特定的功能，试图简化编写瘦客户端应用程序的过程，但它们都通过一系列HTML页面来向客户端上的浏览器提供用户界面。
瘦客户端应用程序可以很简明地定义为：
使用浏览器来提供应用程序（以HTML定义的）用户界面的执行环境的客户端应用程序。
除了呈现用户界面和允许用户与之交互外，浏览器还提供一般的安全性、状态管理和数据处理功能，外加所有客户端逻辑的执行环境。
对于后者，浏览器通常会提供一个脚本引擎和承载其他可执行组件（如JavaApplets、ActiveX和.NET控件等）的能力（虽然大多数定义并不认为这些可执行组件属于瘦客户端技术—参见下面的混合型应用程序）。
体系结构被构建为使用瘦客户端表示层的应用程序可以分解为一些页面，而每个页面都在被请求时“部署”到客户端。
每个页面都包含用户界面说明，并通常会包含少量客户端脚本逻辑和少量状态/数据（视图状态、Cookies、XML数据岛等）。
图1所示为一种瘦客户端表示层体系结构的图形表示。
图1：
瘦客户端体系结构的图示
浏览器与客户端环境（硬件和在客户端上运行的其他软件应用程序）交互的能力是有限的。
它的确提供了一种使得能够在客户端上存储少量数据（通过Cookies）的机制，有时还提供缓存页面的能力，但除了作为分别提供简单的会话管理或跟踪，以及基本的只读脱机功能的一种方法外，这些功能作用有限。
浏览器还提供安全性基础结构，以便使不同的应用程序（页面）能够分配到更多或更少的权限，这样，它们就可以围绕状态（如Cookies）执行不同的任务，就可以承载组件和执行脚本。
InternetExplorer通过不同的区域、受信任站点、分级等实现了这些功能。
为了提供更丰富、响应效果更佳的用户界面，一些Web应用程序采用了DHTML和类似的技术来提供更为丰富的用户界面。
虽然这些技术是非标准的，即并不是所有的浏览器都以相同的方式支持它们，但它们的确提供了在Web页面中包括更高级的用户界面元素（如下拉菜单、拖放等）的能力。
新一代的“胖客户端”又叫“智能客户端”。
它在传统的九十年代中期以来的客户机/服务器结构中的胖用户接口上作了一些改变。
在传统的胖客户端中，通过使用标准的界面——使用典型的界面组件，如菜单、上下文菜单、工具栏、分层次的数据视图、数据表格、图等，用户可以很方便地和收集或展示的数据进行交互，这给终端用户提供了很高的可用性和效率。
在此之外，智能客户端加入了基于Web的配置，增加了对自动版本更新、联机/脱机操作、以一种可控制的安全的方式管理客户端安全等的支持。
讲解课本：
7.2.4
阅书：
7.2.4
幻灯：
第24页
讲授：
我们现在来看一下一个例子：
讲解课本：
7.2.5
阅书：
7.2.5
幻灯：
第26页
讲授：
当我们设计完成后，必须去验证我们的设计是不是符合我们当初设计的需求：
讲解课本：
7.2.6
阅书：
7.2.6
幻灯：
第28页
讲授：
最后我们看一下交付成果有哪些：
讲解课本：
7.2.7
阅书：
7.2.7
幻灯：
第29页
7.3设计用户处理组件
教学提示：
本节主要达到一个目的。
●设计用户处理。
（略讲）
教学内容
教学方法
教学提示
讲授：
我们现在来看一下用户处理组件有哪些功能？
讲解课本：
7.3.1
阅书：
7.3.1
幻灯：
第32页
讲授：
现在我们来看一下分离用户处理与用户界面的任务有哪些？
讲解课本：
7.3.2
阅书：
7.3.2
幻灯：
第34页
讲授：
最后我们来看一下设计用户处理的指导方针。
讲解课本：
7.3.3
阅书：
7.3.3
幻灯：
第35页
总结
经过本章的学习，我们了解了下列的知识和内容。
●解释业务解决方案表示层的功能
●设计能满足用户需要和业务需求的用户界面
●设计用户处理组件
在第八章中，我们将进行数据层的设计的学习，让大家能理解数据层的设计在ＭＳＦ中起到什么作用．
布置作业
完成书后习题1-5
案例教学
对应本书光盘“CASESTDY\第七章\阅读文档\”,通过对这些文档资料对表示层的设计有一个整体的了解。
案例
城市电力
背景
城市电力是一家为民用和工业用户提供电力服务的大型公司。
公司有超过50万居民用户。
每月，账单都被打印出来并邮寄给这些用户。
大多数人通过邮政付费。
然而，越来越多的居民用户使用银行提供的在线付费服务支付账单。
公司雇佣你为用户账单支付创建网站，并为付款提示创建XMLWEB服务。
你将使用微软.NET框架。
当新的支付提示解决方案实施后，银行不用为个人用户存储月度账单数据。
银行将使用账单支付应用程序，从XMLWEB服务获得数据。
一旦客户使用银行在线服务支付账单，银行的应用程序会查询XMLWEB服务来提供正确的账单数量。
现有IT环境
现有的财务应用程序为城市电力管理用户的付账流程。
这个程序接收用户的电力使用数据，然后创建并打印月度账单。
财务应用程序运行在位于公司网上的大型机。
大型机有一个使用二进制协议的TCP/IP接口。
在接口上的通信十分缓慢。
另一个现有应用程序接收银行付费。
该程序使银行能够代表用户向城市电力提交电费。
银行付费应用程序运行在与公司网隔离的网上。
这个网络与公司网通过防火墙和专线连接在一起。
会见IT部门IT经理
如果我们提供任何对外的界面，那么只有经过身份认证的用户才能使用。
这些界面也必须使用安全传输。
我们的大型机已满负荷运转，我不希望在上面增加任何新的应用程序或者数据。
现在，我们不为用户存储身份认证证书。
然而，所有的用户都有唯一的账号。
用户必须创建密码并在使用新的用户网站付费时输入。
我希望对付款提示解决方案的管理应尽量简单。
我希望所有的银行都能使用这项服务。
作为现有银行付费应用程序的组成部分，我们已经有大部分银行的身份认证证书。
这些证书可以通过COM接口从银行付费应用程序连接。
商业利益相关者首席执行官
可靠性对我们的服务很重要。
新的解决方案须对居民用户和银行合作伙伴开放。
安全也很重要。
没有经过身份认证的用户不能浏览和客户相关的账单数据或付款提示数据。
一些银行计划，除非我们提供与客户相关的付款提示数据，他们就停止我们电费账单的付款。
一些银行计划，除非我们提供付款提示服务，他们就停止我们电费账单的付款。
经济部门首席经济师
我们希望降低处理纸质账单的成本。
我们希望尽量多的居民用户在线支付账单。
现在，一些用户使用银行提供的付费服务。
然而，银行不能从我们这里获得账单数据。
因此，客户必须在付费应用程序中输入每个账单信息。
这种方法导致频繁的账单错误和客户满意度下降。
我们需要一个付款提示应用程序来解决这个问题。
这个程序允许银行查询我们的电脑，获得每个客户的详细账单数据，同时使我们能够控制那些在线账单。
另外，我们需要一个客户网站，使客户能够浏览和支付月度账单。
一些客户不能连接到银行提供的付费服务。
我们希望每个客户都能使用一张或多张信用卡支付账单。
一些客户喜欢用信用卡每月手工支付账单。
另一些客户喜欢使用信用卡每月自动支付账单。
我们必须支持客户不同的喜好。
业务流程
居民客户账单可以在一个月的10个不同日期里到期。
每个客户都被分配到10天里的一天。
现有的财务应用程序存储每位客户的到期日。
读表员工读出居民客户的电力使用数。
然而，每个表一年只读4次。
因此，大部分月度账单的计数是估计的。
每个账单计数在账单到期日30天前生成。
账单计数要根据实际估计使用量作出相应调整。
现有财务应用程序的界面只为当前账单期提供数据。
问题案例城市电力
1．你为付款提示推荐哪种解决方案？
A.银行使用XMLWEB服务连接客户账单数据
B.每个银行都有XMLWEB服务用于提交付款提示数据
C.银行向XMLWEB服务提供客户账单数据
D.每个银行都有XMLWEB服务用于接收提示数据
答案：
A
2．你正为解决方案创建功能说明。
说明应包括哪些付款提示需求？
A.当数据改变时，与安全的接口通信，大批量装载客户账单数据
B.为大批量装载客户账单数据提供安全的接口
C.为个人客户账单数据提供安全的XMLWEB服务
D.与安全的XMLWEB服务通信，大批量装载客户账单数据
答案：
C
3．你正进行解决方案的概念设计。
设计应包含哪些实体？
（多选）
A.表读数
B.客户
C.账单时间表
D.银行
E.信用卡
答案：
B,D,E
4．你正验证解决方案的逻辑数据模型。
客户实体应包含哪些属性？
（多选）
A.密码
B.客户标识
C.银行标识
D.账单标识
E.信用卡号
答案：
A,B
5．你要为付款提示模块中的身份认证机制进行物理设计。
你应该怎么做？
A.在SOAP报头内传递身份认证证书
B.在每个网络方法中包含WindowsPrincipal参数
C.建立一个有认证参数的独立身份认证服务
D.在每个网络方法中包含GP参数
答案：
A
6．简单逻辑错误经常发生在日常构建中。
你需要在构建过程中进行改进。
你应采取哪些行动？
（多选）
A.开发者须建立和实施模块测试
B.开发者须在登记前编码
C.所有错误必须记录在错误追踪应用程序中
D.开发者须为类、方法和属性编写注释
E.在所有的集合上实施质量保证测试
答案：
A,B,E
升级会员 