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