Web软件设计与实现.ppt

第十二章Web软件设计与实现,12.1WebApp概述,WebApp特点网络密集性每一个WebApp都驻留在网络上，并且必须为大量不同客户群体的需要提供服务并发性大量的用户可能会同时访问某个WebApp不可预测的负载访问WebApp的用户数目每天都可能会有数量级的变化性能敏感性（performancesensitive）。如果一位WebApp用户（对于访问、服务器端的处理、客户端的格式化和显示）必须要等很长时间，该用户就可能会转到其他地方。高可用性（highavailability）。虽然说期待百分之百的可用性是不现实的，但是流行的WebApp的用户通常要求基本的“24/7/365”（全天候）的可访问性。,12.1WebApp概述,数据驱动（datadriven）。很多WebApp的主要功能是借助于超媒体来向最终用户展示文本、图像、音频和视频内容。内容敏感性（contentsensitive）。内容的质量和美学性依然是WebApp质量的重要决定因素。持续演化（continuousevolution）。传统应用软件随一系列计划好的时间间隔发布而演化即时性（immediacy）。虽然说即时性（也就是把软件尽快推向市场的强制性要求）是很多应用领域的特点，但是将WebApp投向市场常常是几天或者几周的事情安全性（Security）。由于WebApp是通过网络进行访问的，所以即使可能也很难限制访问这个应用的最终用户的数量。美学性（aesthetics）。WebApp吸引力的一个不可否认的部分是它的外观和感觉。,12.1WebApp概述,WebApp类型信息型（informational）WebApp。你决定去构建一个主页面和一些支持页面来描述单位以及它的产品和服务。你已经完成的是构建一个信息型WebApp包含一些只读的内容和简单的导航和链接。下载型（download）WebApp。允许访问者去下载产品说明的功能。这个WebApp现在合并了信息和下载的功能。可定制型（customizable）WebApp。你想通过使用术语和展示对在Web站点上展示的内容进行裁剪以满足每种顾客的特殊需要。即创建一个使每个用户可定制的新应用。交互型（interaction）WebApp。在访问者中营造一种社区的氛围，在这里人们可以聊天、互相问答、提供产品的证明等。使它支持聊天室的特性。你现在已经为自己的WebApp提供了一个交互组件。用户输入型（userinput）WebApp。实现基于表单的输入，使每个报价请求都以一种可预知的方式进行组织。虽然你要使用其他自动操作来生成报价单，但是至少不必去转录形式各异的输入和信息源。,12.1WebApp概述,面向事务型（transactionoriented）WebApp。基于表单输入的报价单可以很好地工作，但是CPI的管理层很快意识到整个报价过程可以自动化。他们为你提供了一系列计算硬件和建立在基于表单输入之上的监控定价的算法。现在，基于用户通过表单提供的输入，立即提供给他们一个报价。用户和WebApp之间的事务就产生了。面向服务型（serviceoriented）WebApp。以图形的方式输入对一个空间的描述，然后就能得到针对那个空间的安全系统在设计上的支持。这种服务可以直接带来销售收益。另外，它强调了CPI和SafeHome产品的总体质量。门户型（portal）。随着时间的推移，你付出的艰辛工作收到了每天几千个访问者回报。CPI的员工每天会收到几百个与安全相关的问题，他们没有时间去一一回答。为了解决这个问题，你开始提供一些有这些问题的答案的站点的链接。不久以后，站点的一部分引导用户成为了很多种有用的信息源。SafeHomeA现在已经有了门户的特征。数据库访问型（databaseaccess）。你的生产线和客户的基数急剧地增加，因此，很有必要去建立三个新的数据库：1）所有SafeHome的产品及其技术规格说明书、定价（对于客户范畴）、安装指南以及交付和可用性信息；2）所有与客户相关的信息；3）所有与监控相关的信息。这些数据库可以通过WebApp的用户输入要素的特征进行查询。数据仓库型（datawarehousing）。CPI正快速地变成安全性产品的一个主要国际供货商。为了满足众多国家的需要，你必须使用当地的建筑规章、供货商、安装商等类似的信息，需要获得对多个数据库的访问并提取对客户有用的信息。你开始为SafeHomeAWebApp构建一个大规模的数据仓库组件。,12.1WebApp概述,12.2Web工程,Web工程主张用一种敏捷（agile）而规范的框架来构建高质量的WebApp敏捷一个敏捷团队是一个灵活的团队，可以恰当地响应变化变化就是软件开发自身很大的一部分框架（Framework）定义了若干可以被应用到所有WebApp项目中的框架活动（activity），为完整的Web工程过程建立了基础，而不考虑项目的复杂性。框架还包含了一组适用于整个WebE过程的保护性活动（umbrellaactivity）。,12.2Web工程,下面的WebE活动是一个通用框架（genericframework）的一部分，可以应用于绝大多数的WebApp工程：沟通（communication）包含了与客户（和其他的利益相关者）之间大量的交流与协作，还包括需求获取和其他的相关活动。计划（planning）为WebE工作建立一个增量计划（incrementalplan）。它描述了将要发生的WebE动作、将要实施的技术任务、可能的风险、将需要的资源、将要生产的工作产品以及一个工作进度计划。建模（modeling）包含了有助于开发者和客户更好地理解WebApp需求的模型的创建，以及实现这些需求所进行的设计。构建（construction）把HTML、XML、Java以及类似代码的生成和用于发现代码中错误的测试结合起来。部署（deployment）把一个WebApp的增量交付给客户进行评估，并基于评估提供反馈。,12.2Web工程,每一个Web工程动作都由一组任务进行表示，这些任务中的每一个都是由Web工程工作任务、相关工作产品、质量保证点和项目里程碑等组成的。保护性活动（例如，风险管理、质量保证、内容管理）应用于WebE全过程,12.2Web工程,WebE方法沟通方法（communicationmethod）。定义了便于Web工程师和其他的WebApp利益相关者（例如，最终用户、业务客户、问题域专家、内容设计者、团队负责人、项目经理）之间进行沟通的方法。沟通技术在需求获取和评估一个WebApp增量时显得尤为重要。需求分析方法（requirementanalysismethod）。为如下的几个方面提供了基础：理解一个WebApp要交付的内容，提供给最终用户的功能，以及通过WebApp内的导航时，各种类型的用户所需要的交互模式。设计方法（designmethod）。包括了一系列的设计技术，用来描述WebApp的内容、应用和信息架构、界面设计和导航结构。构建方法（constructionmethod）。把一套各种各样的语言、工具和相关的技术应用于创建WebApp的内容和功能之中测试方法（testingmethod）。包括对内容和设计模型的技术评审和各种各样的测试技术。这些测试技术针对于组件级和架构级问题、导航测试、可用性测试、安全性测试和配置测试。一系列的保护性活动（以及相关的方法）对一个成功的Web工程来说也是必不可少的。其中包括项目管理技术（例如，评估、计划进度、风险分析）、软件配置管理技术和评审技术。,12.2Web工程,Web工程的最佳实践1.即使WebApp的细节很模糊，也要花一些时间去理解业务要求和产品目标。很多WebApp开发者错误地认为，（非常普遍的）模糊的需求使他们可以不用去确认将要开发的系统具有一个合理的商业目标。最终的结果（常常）是好的技术工作因为错误的原因为错误的用户构建了错误的系统。如果利益相关者不能阐明WebApp的业务需求，就要加倍谨慎。如果利益相关者不能清楚地确定产品（WebApp）的一系列明确的目标，就不要进行下去，直到他们确定之后再继续开发。2.使用基于场景的方法来描述用户如何与WebApp进行交互。应该说服利益相关者去设计场景，通过场景来反映各种用户如何与WebApp进行交互。然后，这些场景可以被用于：1）项目计划和跟踪；2）指导分析和设计建模；3）作为测试设计时的重要输入。3.制定一个项目计划，即使这个计划很粗略。基于所有的利益相关者都能接受的过程框架，建立项目计划。因为项目的时间线很短，所以要使用一个细粒度的时间表。例如，在很多情况下，项目的进度计划和跟踪应当以天为单位。4.花费一些时间来对你将要构建的系统进行建模。通常，综合性的分析和设计文档并不会作为Web工程工作的一部分进行开发。然而，有针对性的图形化模型确实可以阐明重要的工程问题。,12.2Web工程,Web工程的最佳实践5.对模型进行一致性和质量的评审。结对走查和其他类型的评审都应当贯穿于整个WebE项目。在评审上花费的时间会带来很重要的价值，因为它通常会减少返工，并产生高质量的WebApp，从而提高客户的满意度。6.使用那些能够让你尽可能多地使用可重用组件来构建系统的工具和技术。有各种各样的WebApp工具可用于WebApp构建的几乎每一个方面。在这些工具中，有很多都能够使Web工程师可以使用可重用的组件来构建应用的重要部分。7.如果可以重用，就不要重新开发。已经开发出了很多针对WebApp的设计模式。这些模式使WebE团队可以使用一些已经证明过的模板来快速开发架构的、导航和组件级的细节。8.不要依赖于早期用户来调试WebApp在发布系统之前，设计全面的测试并执行这些测试。WebApp的用户通常都只会给WebApp一次机会，一旦WebApp执行错误，用户就会到别的地方去永远都不会再回来。正因为这样，即使必须要拖延最终期限，“先测试，后部署”也应该是首要的原则。,12.3定义框架,在为WebE定义一个过程框架之前，我们必须重申在大多数WebApp项目中都会遇到的一些事实：1.需求随着时间演变。当你开始一个WebApp项目的时候，业务策略的一些元素、交付的内容和功能、互操作性问题以及问题的其他很多方面都可能有一些不确定性。2.变化会经常发生。因为不确定性是大多数WebApp项目的一个固有组成部分，所以需求的变化是很寻常的。另外，用户的反馈（基于对已交付增量的评估）和不断变化的业务环境都可能引发变化。3.时间线非常短。这减少了对大量工程文档的创建，但是这并不排除一个简单的事实，那就是必须以某种方式对问题分析、设计和测试都进行文档化。,12.3定义框架,12.3定义框架,12.3定义框架,沟通（communication）。在WebE过程中，沟通的特点在于如下3种WebE动作：规划（formulation）、提取（elicitation）和协商（negotiation）计划（planning）。确定WebApp增量的总体数目，同时为将要部署的下一个WebApp增量产生大体的项目计划。估计增量所需的资源，考虑风险，选择任务并安排其进度，同时项目的跟踪和监控也将开始。在大多数情况下，计划的工作产品由任务定义和WebApp增量开发所需时间段（通常以周计）的时间线进度表组成建模（modeling）。传统软件工程的分析和设计任务被应用到WebApp开发中，合并并且最终融入到WebE建模活动之中。其目的是开发用来定义需求的敏捷的分析和设计模型，同时展示一个可以满足需求的WebApp。构建（construction）。WebE工具和技术用于构建已经模型化的WebApp。一旦构建出WebApp的增量，就会执行一系列快速测试，以确保发现设计中（如内容、架构、界面和导航）存在的错误，并对WebApp的其他特征进行附加测试。部署（deployment）。WebApp对它的操作环境进行配置，然后交付给最终用户，评估阶段就开始了。评估结果反馈给WebE团队，必要时对增量进行修改。,12.4分析与设计,分析模型的重点在于WebApp的内容、交互（包括导航）模式和功能，以及技术配置判断是否需要一个需求模型表示WebApp的内容识别内容之间的联系精化并扩展用户场景复审使用场景为复杂场景创建一个交互模型状态是行为的一个外部可见的模式,12.4分析与设计,设计内容界面设计（interfacedesign）。描述用户界面的结构和组织形式。包括屏幕布局的表示、交互模式的定义以及导航机制的描述。美学设计（aestheticdesign）。也称作图形设计，描述了WebApp的“外观和感觉”。包括颜色方案、几何布局、文本大小、字体和位置、图形的使用以及相关的美学决策。内容设计（contentdesign）。针对作为WebApp的一部分进行展现的所有内容，定义其布局、结构和轮廓，建立内容对象之间的关系。导航设计（navigationdesign）。针对WebApp的全部功能，描述内容对象之间的导航流程。架构设计（architecturedesign）。确定WebApp的全局超媒体结构。组件设计（componentdesign）。开发实现功能组件所需要的详细处理逻辑，以实现一个完整的WebApp功能。选择合适的设计模式,Web设计,Web设计主要可分为体系结构设计导航设计界面设计一个良好的Web设计需要满足以下要求设计要尽可能的简单布局要尽可能的美观整体的一致性,体系结构设计,体系结构主要线性结构网格结构层次结构,体系结构设计,不同的体系结构比较,导航设计,导航设计，主要可以分为两部分可以对不同的用户权限给出不同的导航路径给同一类用户一个共同的导航语义在导航设计时，需要为同一类用户建立一个语义导航单元，这样方便后继的管理。在导航设计时，需要考虑建立合适的导航约定和帮助。,界面设计,Web工程中界面在用户心目中具有非常重要的地位。界面可以说是Web工程给人的第一印象，只有让用户对第一印象产生好感觉时，用户才有可能使用WEB工程的其它功能导航和内容。所有的用户界面需要易使用，易操作，直观，一致。除此之外，界面还要求有助于用户浏览，界面需要显示用户当前所在的网站或工程的路径。,界面设计,Web界面设计要考虑的三个问题:浏览者目前的位置浏览者目前可以进行的操作浏览者可以导向的目标,界面设计,Google简洁的界面,界面设计,WEB工程自己的设计原则页面速度页面正确所有的菜单和界面的风格应该统一链接指示应明显界面功能明显清晰通常都需要使用表格等工具,构件级设计,Web应用程序逐渐形成变得模板化，功能化。这种处理功能主要包括数据库查询以及其它操作与外部企业系统的数据接口用户的注册和认证Web工程师必须设计和构建一些程序构件，它们和普通软件在形式上是一致的。利用构件技术，可以很方便地组建各种不同的Web应用程序。,构件级设计,理想的构件模型,12.5构建,构建活动的进行，你将执行两个WebE动作：代码生成和测试代码生成构建和获取所有的内容，并把内容集成到WebApp架构之中。哪些WebE技术和工具将被用来构建内容和功能组件？在构建过程中，可以使用哪些已经存在的表单、模板和模式？选择适合于产生HTML代码的工具集。工具集能专有地使用吗？专门的功能是否必须要手工编码？实现每个页面的布局、功能、表单和导航能力。所有的内容都可用于集成到增量的每一个Web页面中吗？到所有功能的链接都已经实现了吗？已经使用了哪些链接机制？实现所有的计算功能。必须要实现哪些表单、脚本和数据库接口？计算算法是否已经进行了充分的设计？功能是部署在客户端还是服务器端？处理配置问题。在客户端和服务器端将支持什么样的浏览器、插件和操作系统环境？,12.5构建,测试测试所有的WebApp组件（内容和功能）。在用户任务的环境下，将测试哪些组件？设计的测试能完全用于测试功能吗？测试导航。在用户任务的环境下，将测试哪些链接？哪些用户场景可以应用到WebApp增量来开发合适的导航测试？设计的测试能完全用于导航结构吗？测试可用性。为了让使用简单化，必须测试哪些交互机制？哪些用户场景可以应用到WebApp增量来开发合适的可用性测试？已设计的测试可以确保每个可用性场景都是被支持的吗？测试（要求的）安全性和性能。我们如何应用所有的安全性过滤器并测试增量的总体性能？已设计的测试可以保证客户端和服务器端的功能都是安全的吗？测试不同配置的WebApp增量。一系列所有的技术性配置都已经开发了吗？设计的测试可以在所有的操作配置下应用WebApp增量吗？,12.6保护活动,保护活动（umbrellaactivity）。虽然可以定义很多的保护活动，但是只有4个对成功的Web工程项目而言是关键性的：变更管理（changemanagement）。在开发每一个增量的时候，管理变更的影响，集成所有WebApp内容管理工具。质量保证（qualityassurance）。定义并执行有助于确保每个工作产品和部署的增量都有很高质量的一些任务。风险管理（riskmanagement）。在开发增量的时候，考虑项目和技术风险。项目管理（projectmanagement）。在开发增量的时候，跟踪并监控其过程。,12.7举例一,案例1-1网络书城系统分析与设计需求描述网络书城的主要功能就是让用户能够足不出户就可以购买到自已想要的书籍，所以网络书城系统主要提供如下功能：用户能够使用本网站完成图书的浏览、查询和购买。普通用户只能浏览图书信息，浏览分为3种方式：按类别浏览、按条件浏览、查询图书。普通用户通过注册成为注册用户，注册后的用户可以登录，密码忘记后可以找回密码，登录后可以修改注册资料。注册用户登录后可以进行在线图书购买，购买的图书存放在购物车中，可以对购物车中的商品数量进行修改、删除，调整好购物车中内容后，可以把该内容保存到订单中，在保存订单的时候要求用户填写送货地址和联系方式。订单提交后用户可以开始一次新的购物过程。对于后台系统，要求可以进行商品目录的维护，商品的图片可以上传到服务器，特价商品维护，订单可以查询详细信息，订单确认和订单发送。,12.7举例一,12.7举例一,12.7举例一,文件夹和包的设计,12.8举例二,系统分析的目的就是为系统设计提供系统的逻辑模型。系统设计再根据这个逻辑模型迸行物理方案的设计。系统分析需求描述论坛是一种基于网络的交流工具，一个论坛主要具备以下几个基本功能：用户通过注册成为注册用户，注册后的用户可以登录。用户可以浏览贴子，能对帖子进行查询，但不能发表主题或回复帖子。注册用户后可以发表主题或回复帖子，也可以修改帖子。管理员可以管理版面，管理主题，管理用户，管理帖子。,12.8举例二,总体设计1功能模块设计2数据库设计,12.8举例二,12.8举例二,系统分析的目的就是为系统设计提供系统的逻辑模型。系统设计再根据这个逻辑模型迸行物理方案的设计。系统分析需求描述论坛是一种基于网络的交流工具，一个论坛主要具备以下几个基本功能：用户通过注册成为注册用户，注册后的用户可以登录。用户可以浏览贴子，能对帖子进行查询，但不能发表主题或回复帖子。注册用户后可以发表主题或回复帖子，也可以修改帖子。管理员可以管理版面，管理主题，管理用户，管理帖子。,系统结构设计系统采用分层结构，整体上分四层：视图层、控制层、业务逻辑层和数据访问层。主项目的名称为bbs，数据访问层和业务逻辑层采用EJB的无状态会话Bean及HiberanteJPA技术实现，项目名称为bbs-ejb(以下简称EJB项目）。视图层和控制层采用JSF技术实现，项目名称为bbs-war（以下简称WAR项目）。如图8-3所示。EJB项目划分包如下：bbs.idao（数据访问层接口包），bbs.dao（数据访问层实现类包），bbs.iservice（业务逻辑层接口包），bbs.service（业务逻辑层实现类包），bbs.model（数据模型类包，也称实体类包）。如图8-4所示。在WAR项目中，控制层主要利用受管Bean实现，划分包如下：bbs.action（控制类包），mon（其他辅助类），如图8-5所示。视图层利用JSF技术实现，放在【Web页】文件夹下，划分子文件夹如下：forum（版块），theme（主题），message（帖子），user（用户），common（公共），css（样式表），images（图像），resources（资源）。,12.8举例二,12.8举例二,实体类（数据模型）设计用户实体类BbsUser登录实体类BbsLogin角色实体类BbsRole版块实体类BbsForum主题实体类BbsTheme帖子实体类BbsMessage,12.8举例二,12.8举例二,接口设计数据访问接口设计数据访问层基接口IBaseDao。用户数据访问接口IBbsUserDao。登录数据访问接口IBbsLoginDao。版块数据访问接口IBbsForumDao。主题数据访问接口IBbsThemeDa