1、电子商务项目-需求分析与建模第一部分作者：kingshare 发文时间：2006.03.14一、项目设计实现的总体流程概述1、系统需求：系统应该有什么功能。2、系统分析：我们应该解决什么问题，重点在于理解问题。3、系统构架：通过某种特定的平台，而达到完成整体软件的功能。4、系统设计（各个功能模块的设计）：怎样解决，重点在于明确所要解决的问题。5、系统实现：采用什么技术和手段（语言、工具）5.0 开发工具和服务器平台应用服务器采用 BEA Weblogic 8.1、数据库是 MSSqlserver2000 并采用连接池技术；5.1 构建数据源5.1.1 设计数据库5.1.2 设计各个数据库表之间
2、的实体关系5.1.3 设计系统中的各种人员的角色5.1.4 设计出该项目中数据库的各个数据表5.1.5 在 WebLogic 等应用服务器中配置 JDBC 数据源 5.2 在 JBuilder 中建立 Project5.3 设计 Web 应用程序5.4 设计各个 EJB 组件5.4.1 MDB 5.4.2 SessionBean（有状态和无状态 SessionBean）5.4.3 实体 Bean5.4.4 设计各个实体 Bean 之间的关联5.5 编程实现各个模块5.5.1 设计 MVC 的表示层 JSP 页面以向 Servlet 控制器发送各种 http 请求5.5.2 编程 MVC 的控制
3、层 Servlet 控制器 访问模型层中的有状态 SessionBean 访问模型层中的无状态 SessionBean 访问模型层中的 Message Facased 中的 MDB EJBBean5.5.3 设计 MVC 模型层中的 MDB 以有状态 SessionBean5.5.4 设计 MVC 模型层中无状态 SessionBean 以向 MVC 的控制层 Servlect 返回各种服务请求的结果。5.5.5 设计 MVC 模型层中有状态 SessionBean 以访问实体层 CMP Bean5.5.6 设计 MVC 模型层中 EJB 实体层 CMP Bean 以访问后台数据库表中的（EJ
4、B QL）6、系统测试 Web 客户端方式的功能测试 Java Application 应用程序客户端方式的的功能测试（可选实现方式- 根据自己的需要） 各个业务 EJB 组件7、系统部署 发布 Web 应用程序和各个 EJB Bean 组件到 WebLogic 服务器试运行 正式运行8、系统维护9、本项目所应该考虑的一些问题的技术实现（1）本项目的安全性和权限管理 基于 Web 服务器端的 Filter 技术 基于 WebLogic 的基本验证方法 基于 WebLogic 的 Form 表单方式的验证方法 基于 EJB 的安全认证（2）本项目中的异常等错误处理（3）本项目中的中文编码问题处理
5、（4）JSP 和 Servlet 等 Web 服务端的性能优化的问题9、项目开发中团队的组建二、利用 UML 进行系统建模1、UML 概述（1）UMLUML（Unified Modeling Language）统一建模语言， UML 是构建软件系统模型的标准化语言，它提供了描述软件系统模型的概念和图形表示法，同时由于它采用面向对象的技术、方法，因此能准确方便地表达面向对象的概念，体现面向对象的分析与设计风格。它是编制软件蓝图的标准化语言，用于对复杂软件系统的各种成分的可视化地说明和构造系统模型（建模是人类对客观世界和抽象事物之间联系的具体描述），以及建立软件文档。因为模型的作用就是使复杂的信息
6、关联简单易懂，它使我们容易洞察复杂堆砌而成的原始数据背后的规律，并能有效地使我们将系统需求映射到软件结构上去。（2）UML 的诞生 面向对象建模的标准语言的产生背景目前人们普遍开始采用面向对象的分析与设计，但是很少有开发人员使用形象化的设计方法，其主要原因就是缺乏统一的语言语义来为复杂软件系统的组件定义、可视化、构建和编制文档。而 UML 的出现彻底的改变了这一现状，并成为了面向对象建模的标准语言。 关于 UML 的形成James Rumbaugh 加入 Rational 公司，与 Grady Booch 共同发布了 UM 的0.8 版(1994)；Rational 收购 Objectory
7、公司，三人一起工作，发布了 UML0.9 版(1995)；0.9 版带动了诸如 IBM、HP 以及 Microsoft 等众多公司的加入；OMG 发布了 UML1.1(1997)2、为什么要使用 UML在工程设计中，工程师使用各种工程图来进行沟通。软件设计中通过使用UML，可以以 OO 的方式来进行系统的分析、设计，并且已经被 OMG（Object Management Group）标准化了。UML 的使用目的如下： UML 易于使用，能够进行可视化建模； 与具体的实现无关，可应用于任何语言平台和工具平台； 与具体的过程无关，可应用于任何软件开发的过程； 简单并且可扩展，具有扩展和专有化机制，
8、便于扩展，无须对核心概念进行修改；3、软件开发方法（1）软件生命周期法生命周期法认为：每一个软件系统都有一定的生命周期。软件的生命周期是指一个软件系统从其提出、调查到分析、设计和有效使用，直至被淘汰或取代的整个期间。软件生命周期法就是按软件生命周期的各个阶段划分任务，按一定的规则和步骤，有效地进行软件开发的方法。通常一个软件系统的生命周期可分为五个阶段：需求阶段、分析阶段、设计阶段、实施（编码）阶段、运行与维护阶段瀑布型模型来进行开发注意：生命周期法要求在开始系统设计前，系统分析人员就十分明确用户的要求，能作出准确的需求分析。（2）原型法基于“2/8”原则先根据用户的最主要要求，开发出能实现系
9、统最基本功能的一个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。原型法分 4 个阶段：确定用户需求；设计原型；使用、评价原型；修改、完善原型。注意：当用户的要求不明确或难以确定时，采用原型法进行开发是恰当的。（3）面向对象的方法面向对象是一种用计算机语言模拟现实生活的技术。而传统的语言是基于时序的，是计算机观点的语言，和人们熟悉的社会观点是不同的。在软件发展初期时，这并不是什么很大的问题，但是当软件规模越来越大，变化的速度越来越快的时候。人们发现两种观念有了冲突。例如，订单这个对象是人类社会的一个普遍的商业名词，它是相当稳定的。所不同的只是处理规则有
10、所不同，但在传统的语言中，订单的名词并不是关心的重点，关心的重点反而放在了订单的处理时序上。偏偏这部分的处理是不稳定的，所以就引发了变化的问题。而面向对象采用现实世界系统的思考方式，侧重于建立订单这个类型，并构造订单类型的体系，然后再建立规则。所以，他和现实世界的变化频度是基本一致，变化起来也就比较容易。（4）统一过程（RUP）开发方法 RUP 可以用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构。在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception) 、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段 (T
11、ransition)。 纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构。有 9个核心工作流，分为 6 个核心过程工作流(Core Process Workflows)和 3个核心支持工作流(Core Supporting Workflows)。注意：与传统的瀑布模型相比较，迭代过程具有以下优点： 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
12、由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。4、实现 UML 建模的工具Rose、together 和 Visio 等5、UML 在软件开发过程中的应用（1）UML 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。（2）在需求分析阶段可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统(用例) 的功能要求。（3）分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制，需要识别这些类以及它们相互间的关系，并用 UML 类图来描述。为实现用例 ,类之间需要协作，这可以
13、用 UML 动态模型来描述。（4）在设计阶段只对问题域的对象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、通讯和并行性等问题的类)。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。（5）编程(构造) 是一个独立的阶段其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML 建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。（6）UML 模型还可作为测试阶段的依据系统通常需要经过单元测试、集成测试、系统
14、测试和验收测试。不同的测试小组使用不同的 UML 图作为测试依据； 单元测试使用类图和类规格说明； 集成测试使用部件图和合作图； 系统测试使用用例图来验证系统的行为； 验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。6、利用 UML 建模（1）为什么要建模软件系统也是一种非常复杂的系统，它的最终表现形式为可运行的目标代码。但是最终的软件代码是非常复杂的，包含了太多的细节信息，直接阅读代码很难对系统有一个全面的了解。我们需要有一个中间过程来得到这些结果，同时也需要对系统进行简化和抽象，这就是我们通常所说的系统设计。利用统一建模语言 UML 来对系统结构进行全面的分析设计，即
15、构建系统模型的过程，这就是可视化建模(Visual Modeling) 。可视化建模技术已经成为一种成熟标准的软件开发技术规范。（2）什么是模型 模型是对现实世界的简化和抽象现实世界中的系统是纷繁复杂的，直接去认识现实世界并且解决其中的问题是非常困难的。所以人们往往会构造一个模型来对现实世界中的复杂系统进行简化和抽象，通过这种简化和抽象来帮助设计人员加深对于系统的认知，在进行简化和抽象时我们抓住的是问题的本质，而过滤掉很多其他非本质的因素，从而帮助我们来简化问题的复杂性，有利于问题的解决。模型在现实世界中大量存在，无论是研制飞机还是制造汽车，设计师们都会利用模型来研究目标课题的某一个侧面，如汽
16、车的风阻系数、飞机机身的空气动力布局等等。在研发过程的大部分阶段中，设计师都不会去构造一个真实的系统来进行研究，因为这样的话成本太高了（或甚至是不可能的），同时问题本身没有得到足够的简化，很难找到问题的正确答案。 模型是沟通的手段我们平时所见的模型有的是一种概念上的模型，如刚才提到的数学模型；有的是对实际系统外观的一个缩小，如轮船、飞机模型；还有的是对设计思想的一种展示，如建筑物的设计图纸等等。无论是哪一种模型，它的另外一个主要目的是帮助人们进行思想上的沟通，数学模型使别人了解你的逻辑思路，飞机模型向观众展示飞机的外观，设计图纸将设计师的设计思想传递给建筑工人。 模型可以精确地描述系统语言和文
17、字是人们进行沟通的主要手段，但语言和文字往往有二义性存在，较难保证人们的理解完全一致。所以在工程技术中，我们更多地是使用各种各样的模型来进行思想的沟通，模型可以精确地描述系统，同时保证整个系统开发过程的语义的一致性。（3）可视化建模技术的好处 有效管理系统复杂度面向对象方法最基本的原则就是抽象，把一类具有相同属性和行为的实体抽象成为一个类(Class)，再通过把类实例化成对象(Object)来映射现实世界中的某一个具体实体。对象通过操作(Operation)来对外对供相应的服务，在对象模型中我们只需要描述对象所实现的功能，而封装了操作实现的细节。与软件代码相比，对象模型描述的也是同一个系统，但
18、它展示的是系统结构中最关键的元素以及它们之间的关系，所有的编码细节都已经被忽略掉了，从而有利于开发人员把握理解整个系统。 增强团队的沟通对象模型同时也作为软件设计的蓝图，记录了开发人员的设计思想。对于设计者而言，对象模型提供了一个工具来帮助他来整理设计思路，整个的设计过程都可以被记录下来；同时，也避免开发者在整个系统架构明确之前就陷入编码的细节之中，对于模型的调整修改相对于代码的改动要简单得多。另一方面，对象模型也使得设计的结果很容易被其他人所理解，设计者的设计意图可以被完整的传递而不发生信息的失真。可视化建模采用的是标准的统一建模语言 UML，所有的开发人员都应该采用这种统一建模语言来进行系
19、统的设计，从而保证大家工作的结果是所有人都可以理解的。这也是 UML 语言的设计目的之一，即使用 UML 来统一整个开发团队的沟通手段。 提高系统设计的可重用性面向对象技术最基本的原则就是抽象，即把整个系统的功能尽可能地分配到多个类中去，每个类应该只做并且做好一件事情。因为每个类实现的功能比较单一，所以可以有更多的机会被重用。同时尽量利用构件化的思想把关系比较紧密的类组合成构件，构件具有定义明确的功能并且以接口的形式对外提供服务。基于构件的架构具有最大的可重用性，一方面可以重用现有的商业构件来搭建系统，另一方面当前系统中的构件也可以被其他的系统所重用。（4）可视化建模方法设计一座建筑需要从多个
20、不同的角度（结构、外观、水电等）来设计很多张设计图纸，开发一个软件系统同样需要从多个角度来对系统架构进行完整的设计。在 UML 中采用了“4+1 View”模型来进行可视化建模工作，“4+1 View”指的是：用例视图、逻辑视图、进程视图、实施视图、部署视图。这几种视图从不同的角度来对系统进行完整的描述。它们在 RUP 中被称为“架构视图(Architecture View)”，即通过这样几种视图可以完整地展示系统的架构。三、电子商务（EbookStore、EBank ）项目的系统功能需求1、获取用户需求（1）什么是用户需求它主要是说明系统所必须符合的条件或者应该具备的的功能，也即它用来描述系
21、统应该和不应该做什么也即决定本系统应该有什么功能，从而开发者和用户可以创建一个初始化的商业联系。表达需求可以采用多种不同的方式，如你可以用商业的概念、该领域的术语、框图或者其它方法将功能性的需求写成文档。需求分析活动其实本来就是一个和客户交流，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）以明确项目目的的过程。（2）获得用户需求的目的通过需求分析，其主要的目的是为了获得和描述系统中所有的要求，以及生成一个在该系统中定义关键域类的模型。从而在开发者与需求者之间建立相互理解和沟通。（3）如何获取用户需求 了解客户方的所有用户类型以及潜在的类型。然后，根据
22、他们的要求来确定系统的整体目标和系统的工作范围。 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。 可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等性能和安全等方面的要求）、环境限制、设计约束等类型。（4）应用要点 在这个阶段中，开发者一般不应该考虑具体的代码或程序细节。将那种以“如何实现 ”的表述方式转换为 “实现什么”的方式，因为需求分析阶段关注的目标是“ 做什么” ，而不是 “怎么做”； 用例仅能捕获功能性需求，不适合捕获非
23、功能性需求。 避免下面的情况出现 o 跨过需求，直接进入了设计甚至实现阶段。 o 因为在需求方面任何小的疏漏都可能导致进展不利乃致失败，因为太多的工作被浪费在错误的方向上。 o 用你的想法来理解客户的需求设计不应该成为需求收集的一部分，将需求与设计分离是至关重要的。我们常常是提出问题，然后是解决问题。而不是有了一个解决方案之后，再找一个问题去适合它。问题的解决方案必须在问题已经被确定、形成文档、理解和达成共识之后产生。如果设计在需求之前提出，则系统用的就是自己的需求，并不能代表用户的利益。在设计之前完整地定义问题永远都是明智的。要做到这些的方法只有一个，就是站在用户的角度而不是设计者的角度看待
24、系统。 o 从一开始你就没听清客户要的是什么很多时候，用户并不知道自己要什么？需要我们去引导。当系统存在多个用户时，你会发现不同的用户在需求方面是矛盾的。2、确定需求的流程（1）需求工作流 找出功能性需求 找出非功能性需求 优先排序需求 跟踪用例和需求（2）功能性需求的工作流 找出参与者和用例 优先排序用例 详述用例 组织用例模型 原型化用户界面（3）餐馆定座系统需求示例 功能性的需求 服务生可以通过系统查询是否有满足条件的桌子尚未定出 服务生可以通过系统为顾客定座以及取消定座 服务生可以查询客户以往的消费情况 非功能性的需求 系统的响应查询时间应该小于 10 秒 系统必须 7X24 小时服务，每天可以有 30 分钟的维护时间，同时只能在0 点到 1 点之间 环境限制在局域网络的环境中完成此功能注意：不难看出，需求本身就是对客户而言产品必须满足的条件或具备的能力。对于用户需要产品做的事情，比如要完成的样子我们称之为功能性需求。还有一些不能算做产品要实现的功能，但是为了达到用户的期望值必须完成的一些附加需求，比如多长时间完成称之为非功能性需求。（4）本电子商务项目的需求示例-由学员自己来决定
