《电子商务系统分析与设计 Part3.2.ppt》由会员分享，可在线阅读，更多相关《电子商务系统分析与设计 Part3.2.ppt（100页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、电子商务系统规划方案的评估电子商务系统规划方案的评估 4.4.43.最终电子商务系统规划报告最终电子商务系统规划报告电子商务系统规划报告的基本内容应当包括：(1)系统背景描述系统背景描述(2)企业需求描述企业需求描述该部分的主要内容一般包括：.企业核心业务描述 .企业现行的组织结构及主要协作伙伴 .核心业务分析(3)电子商务系统设计的原则及目标电子商务系统设计的原则及目标该部分的主要内容包括：.企业实施电子商务的基本策略；.电子商务系统所要达到的目标；.规划和设计原则；.实施商务流程再造的原则；.技术原则；.实施原则；.投资费用原则。电子商务系统规划方案的评估电子商务系统规划方案的评估 4.4
2、.4(4)商务模型建议商务模型建议这一部分的内容包括：.商务模式分析和建议 .商务模型 .电子商务环境下企业核心商务流程说明 .未来客户服务 .外部信息系统接口 .内部系统整合 .未来电子商务系统的环境(5)目标系统的总体结构目标系统的总体结构该部分的主要内容包括：.系统的体系结构 .系统各层次的构成及作用(6)应用系统方案应用系统方案它的主要内容包括：.应用软件结构 .应用的功能 .主要应用流程描述 .数据与数据库 .应用支持平台 .应用互联接口电子商务系统规划方案的评估电子商务系统规划方案的评估 4.4.4(7)网络基础设施网络基础设施该部分的主要内容包括：.网络基本结构 .因特网及接入
3、.因特网结构 .Extranet及数据交换 .网络互联方式(8)系统安全及管理系统安全及管理该部分的主要内容包括：系统安全体系安全策略安全体系计算机系统安全交易安全系统管理网络管理服务器管理授权与审计电子商务系统规划方案的评估电子商务系统规划方案的评估 4.4.4(9)系统性能优化及评估系统性能优化及评估它的主要内容包括：系统可靠性数据及设备备份灾难恢复可用性性能优化方案系统负荷均衡并发事务控制高性能软件等(10)系统集成方案系统集成方案其主要内容有：系统平台选择平台结构软件及中间件硬件系统集成设备集成方案应用集成方案电子商务系统规划方案的评估电子商务系统规划方案的评估 4.4.4(11)系统
4、开销与投资系统开销与投资 此部分说明系统建设各个部分的开销及投资计划。该部分说明电子商务系统实施的基本过程及相关的保障措施、其具体内容应当包括：系统实施的主要任务实施进度安排实施过程的分阶段目标实施人员组织(12)商务系统收益分析商务系统收益分析 该部分说明系统投产后可预见的收益，主要是经济效益分析。由于电子商务系统涉及的不仅仅是技术问题，而且涉及到组织、管理甚至法律、人文环境等因素，所以对于相关的配套措施在这一部分阐述。第第5章章 电子商务系统的分析电子商务系统的分析 5.2 5.2 电子商务系统分析电子商务系统分析 5.1 5.1 统一标记语言简介统一标记语言简介 5.3 5.3 利用利用
5、ROSEROSE工具进行工具进行ATMATM机实例分析机实例分析 统一标记语言简介统一标记语言简介 5.1l面向对象是软件开发的最佳实践，而UML是基于面向对象技术的lUML（Unified Modeling Language）统一建模语言，是一种面向对象的建模语言，它的主要作用是帮助用户对软件系统进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。lUML是编制软件蓝图的标准化语言，可以用于对复杂软件系统的各种成分的可视化说明和构造系统模型，以及建立软件文档。UML统一建模语言的重要内容可以由以下五类图（共9种图形）来定义：用例图（Use Case Diag
6、ram）；静态图（Static diagram）；行为图（Behavior diagram）；交互图（Interactive diagram）；实现图（Implementation diagram）；用例图（用例图（Use Case Diagrams）5.1.1 UML中的用例图描述了一组用例、参与者以及它们之间的关系。用例图包括以下3方面内容。（1）用例（Use Case）：是计算机系统提供的有意义的功能块。（2）参与者（Actor）：是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。（3）关系：它反映
7、了参与者或者用例发起（使用）另外一个用例（功能点）的关系。用例图实例用例图实例：用例图（用例图（Use Case Diagrams）5.1.1用例图实例用例图实例：活动图（活动图（Activity Diagram）5.1.2 活动图是流程图的一种，用来描述活动以及活动之间的控制流。它能够用在业务建模中来描述业务中的工作流，在系统分析中确定用例的行为，在设计中确定系统复杂部分的详细操作。它一般包括活动和转移、泳道的描述。1.活动和转移活动和转移 一项操作可以描述为一系列相关的活动。活动仅有一个起始点，但可以有多个结束点。一个活动可以顺序地跟在另一个活动之后，这是简单的顺序关系。活动间的转移也允许
8、带有条件表达式，在活动图中使用一个菱形的判断标志。判断标志可以有多个输入和输出转移，但在活动的运作中仅触发其中一个输出转移。活动图（活动图（Activity Diagram）5.1.2活动和转移的描述符号如下：活动和转移的描述符号如下：初始状态（初始状态（Start state)这个状态是活动图的人口点。从初始状态到另一个活动或状态之间只有一个单独的转换。一个活动图中应该只有一个开始状态。终结状态（终结状态（End stste)这个状态代表活动图的出口点。在一个活动图中可能有多个终结状态。活动活动（Activity）在活动图中，活动表示一个工作要进行的步骤。活动名需要用简洁的短语，来表示活动的
9、行为；状态（状态（State）状态常用来表示等待一个事件。状态可能有入口、出口和事件动作。转换（转换（Transition)该符号给出了活动（或状态）之间的转换。活动图（活动图（Activity Diagram）5.1.2决策点（决策点（Decision point)决策点的引入能够把一个转换转人许多可选的分支之一。决策点有许多输入转换和输出转换。输出转换所其有的标签是保证条件。保证条件负责决定究竟进入下面的哪一个分支。条件要写在方括号中，可以是英文也可以是像OCL这样更形式化的语言。分叉分叉转换转换表示并行开始的两件事。表示所有活动都结束了，新活动才能开始。连接转换连接转换活动图（活动图（A
10、ctivity Diagram）5.1.2活动图实例：活动图实例：活动图（活动图（Activity Diagram）5.1.22.泳道（泳道（Swimlanes）活动图说明发生了什么，但没有描述该项活动由谁来完成。泳道解决了这一问题。泳道用矩形框来表示，属于某个泳道的活动放在该矩形框内，将对象名放在矩形框的顶部，表示泳道中的活动由该对象负责。2个带泳道活动图的实例：活动图（活动图（Activity Diagram）5.1.2图图5.5 图书馆借书图书馆借书活动图活动图状态图（状态图（Statechart Diagram）5.1.3 状态图通过对对象的状态以及状态间的转换建模来展现系统动态行为。
11、它用来描述一个特定对象的所有可能状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移，它是活动图的另外一种形式，使用的符号大部分相同。1.状态状态 所有对象都具有状态，状态是对象执行了一系列活动的结果。当某个事件发生后，对象的状态将发生变化。状态图中定义的状态有：初态、终态、中间状态、复合状态。一个状态可以进一步地细化为多个子状态，我们将可以进一步细化的状态称作复合状态。2.转移转移 状态图中状态之间带箭头的连线被称为转移。状态的变迁通常是由事件触发的，此时应在转移上标出触发转移的事件表达式。如果转移上未标明事件，则表示在源状态的内部活动执行完毕后自动触发转移。状态图（状态
12、图（Statechart Diagram）5.1.3 状态图实例：状态图实例：顺序图（顺序图（Sequence Diagram）5.1.4概念：概念：顺序图（Sequence Diagram）是强调消息时间顺序的交互图。交互图（Interaction Diagram）描述了一个交互，它由一组对象和它们之间的关系组成，并且还包括在对象间传递的信息。顺序图描述类系统中类和类之间的交互，它将这些交互建模成消息交换，也就是说，顺序图描述了类以及类间相互交换以完成期望行为的消息。它主要用于细化用例图，它将系统中支持用例的对象连接在一起。使用顺序图对系统建模时，可以遵循如下规则：l 设置交互的语境，这些语
13、境可以是系统、子系统、操作、类、用例和协作 的一个脚本。l 通过识别对象在交互中扮演的角色，根据对象的重要性，将其从左向右的 方向放在顺序图中。l 设置每个对象的生命线。l 从引发某个交互的信息开始，在生命线之间按从上向下的顺序画出随后的消息。l 设置对象的激活期，这可以可视化实际计算发生时的时间点、可视化消息 的嵌套。l 如果需要设置时间或空间的约束，可以为每个消息附上合适的时间和空间 约束。l 给某控制流的每个消息附上前置或后置条件，这可以更详细化的说明这个 控制流。顺序图（顺序图（Sequence Diagram）5.1.4两个顺序图的实例两个顺序图的实例：顺序图（顺序图（Sequenc
14、e Diagram）5.1.4两个顺序图的实例两个顺序图的实例：协作图（协作图（Collaboration Diagram）5.1.5概念概念：协作图（Collaboration Diagram）可以被视为顺序图的扩展，但它除了展现出对象间的关联外，还可表达对象间的消息传递。协作图用于描述相互合作的对象间的交互关系和链接关系。与顺序图的比较与顺序图的比较：虽然顺序图和协作图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，而协作图则着重体现交互对象间的静态链接关系。描述协作图的符号有描述协作图的符号有：对象（对象（Object）协同图中的对象通常只作为类的一个实例。活动
15、者（活动者（Actor）活动者常在协同图中出现，在协同图中活动者是剧本中触发动作常见的源事件。协作图（协作图（Collaboration Diagram）5.1.5关联（关联（Association）关联是对象之间或对象和活动者间的一条直线，表示它们之间所进行的通信。消息（消息（Message）消息画在关联的旁边，用一个箭头指示出消息的方向。消息可以标上序号，用来表示时间顺序。如果一条传播路线上有多个消息，那么，这些消息要列在一起用一个箭头表示。协作图（协作图（Collaboration Diagram）5.1.5协作图的协作图的2个实例：个实例：打印服务器的协同图打印服务器的协同图 协作图（
16、协作图（Collaboration Diagram）5.1.5协作图的协作图的2个实例：个实例：借书人借书用例的合作图借书人借书用例的合作图 类图（类图（Class Diagram）5.1.6概念：概念：类图（class diagram）是描述类、接口、协作、以及它们之间关系的图。类图的内容：类图的内容：（1）类（2）接口（3）协作（4）依赖（一个类使用另一个类）、泛化（一个类是另一个类的特殊化）、实现（一个类是另一个的实现）和关联关系（彼此之间存在联系）。2个类图的实例：个类图的实例：图图5.11 电梯控制系统的部分类图电梯控制系统的部分类图 图图5.12 图书馆借阅系统的类图图书馆借阅系统
17、的类图对象图对象图 5.1.7概念概念：对象图（Object Diagram）是表示在某一时刻一组对象以及它们之间的关系的图。对象图可以被看作是类图在系统某一时刻的实例。对象图的实例对象图的实例：显示类的类图和显示类的实例的对象图显示类的类图和显示类的实例的对象图对象图对象图 5.1.7 对象图建模过程：对象图建模过程：l 确定参与交互的各对象的类，可以参照相应的类图和交互图；l 确定类间的关系，如依赖、泛化、关联和实现；l 针对交互在某特定时刻各对象的状态，使用对象图为这些对象建模；l 建模时，系统分析师要根据建模的目标，绘制对象的关键状态和关键 对象之间的连接关系。包图包图 5.1.8 对
18、于一个大型的系统总是存在这样的软件方法问题：怎样将大系统拆分成小系统。UML 中这种分组机制叫包（包（Package）。不仅是类，任何模型元索都运用包的机制。分组方法可以是任意的，但在UML 中，最有用的和强调最多的原则就是依赖，即把相互之间具有一定依赖关系的类组合到一个包中。包图主要显示由类组成的包以及这些包之间的依赖关系。组件图组件图 5.1.9概念概念：组件图用来描述软件组件以及组件之间的关系，组件本身是代码的物理模块，组件图则显示了代码的结构。在UML中，每一个组件图只是系统实现视图的一个图形表示，也就是说任何一个组件图不能描述系统实现视图的所有方面，当系统中的组件合在一起，这时才表示
19、系统完整的实现视图，而其中的一个组件图只表示实现视图的一部分。2个组件图实例个组件图实例：网上购物系统订货模块的组件图网上购物系统订货模块的组件图联网游戏软件系统的组件图联网游戏软件系统的组件图 部署图部署图 5.1.10概念概念：部署图显示了运行软件系统的物理硬件，以及如何将软件部署到硬件上，常常用于帮助理解分布式系统。在部署图中可以包括包和子系统，它们可以将系统中的模型元素组织成更大的组块。部署图中还可以包含组件，这些组件都必须存在于部署图中的节点上。部署图描述了运行系统的硬件拓扑。在实际使用中，部署图常被用于模拟系统的静态配置视图。系统的静态配置视图主要包括构成物理系统的组成部分的分布和
20、安装。部署图中的元素：部署图中的元素：（1）节点：是定义运行时的物理对象的类，它一般用于对执行处理或计算的资源进行建模。节点通常具有如下两方面内容：能力（如基本内存，计算能力，二级存储器）和位置（在所有必须的地理位置上均可得到）。在建模过程中，可以把节点分成两种类型：l 处理器（Processor）：这是能够执行软件构件、具有计算能力的节点。l 设备（Device）：没有计算能力的节点，这些设备通常是通过其接口为外界提供某种服务。在UML中，图形上节点使用一个三维立方体来表示。（2）组件：是组件图中的基本元素，它是系统中可替换的物理部件，并包装提供某些服务的接口。（3）关系：组件图中通常包括依
21、赖和关联关系。从概念上理解，部署图也是一种类图，其描述了系统中的节点以及节点间的关系。部署图中的依赖关系使用虚线箭头表示，它通常用在部署图的组件和组件之间。部署图部署图 5.1.10部署图实例：部署图实例：图图5.16 系统物理结构的部署图系统物理结构的部署图电子商务系统分析电子商务系统分析 5.2电子商务系统分析的概念：电子商务系统分析的概念：电子商务系统分析工作主要是从概念上对系统进行描述，其主要工作包括需求分析和功能分析。需求分析侧重于获得系统功能需求和非功能需求。功能分析阐述了如何以用例模型的方式来描述系统功能需求。整个系统分析阶段的主要成果包括用例模型（用例图）、概念模型（类图）、系
22、统行为描述（顺序图）等和其他的一些相关文档，这些工作成果可以作为下一阶段设计工作的起始点。注意：注意：在面向对象的分析设计方法中，系统分析与系统设计的划分点并不像传统的结构化方法那么明显，其主要的区别在于对系统描述的抽象层次上，在分析阶段的描述大都是基于逻辑意义上的，而设计阶段更加强调对系统实施的支持。需求的捕获需求的捕获 5.2.1 需求捕获的主要工作步骤包括：l 获得候选需求：列举候选需求，生成候选需求清单；l 理解系统环境：以业务模型、领域模型或术语表的方式描述系统环境；l 捕获功能需求：采用用例模型来表达系统功能需求；l 捕获非功能需求：针对用例或整个系统建立特殊需求说明，也可以以特殊
23、用例的方式来描述一些非功能需求。必须注意的是，需求是在不断改变的所以在迭代式的开发方法中将通过某种手段来对需求进行可控的更新。每次迭代都可能会增加一些新的需求。需求的捕获需求的捕获 5.2.11.获得候选需求获得候选需求获得候选需求的过程获得候选需求的过程：在系统开发的整个生命周期中，系统投资者、用户、分析人员和开发人员等系统利益相关者都会提出很多好的、关于系统建设的想法，这些想法中会包含一些真正的系统需求。为此，需要及时地以清单的方式记录和保留这些原始想法，把它们作为候选需求，并根据实际情况在下一步的系统建设中或以后的系统版本中有选择地实现它们。当有新的想法加入时，这份候选需求清单会增长，当
24、有些候选需求被证实为无效或成为真正需求并转换为系统开发过程中的其他成果（如用例）时，这份清单会缩减。候选需求清单每个候选需求的描述候选需求清单每个候选需求的描述：每个候选需求都有一个简短的名字和简要的解释与定义，并可能会包含一些对该需求进行详细描述的其他属性，可能包括的其他属性有：l 状态l 估计实现成本l 优先级l 可能带来的风险级别l 对企业的影响范围。为了有效得到候选需求清单，可以采用的策略和方法为了有效得到候选需求清单，可以采用的策略和方法：l 记录客户、用户、分析人员和开发人员时系统的想法；l 对各种想法的含义和内涵进行广度和深度搜索，记录搜索过程中的新想法；l 考虑环境对系统的影响
25、，并决定是否加入到候选需求中。需求的捕获需求的捕获 5.2.1案例：案例：网上购物系统需求清单 下表给出了本系统的候选需求清单的部分内容，其中需求的获得依赖于对系统环境的调查和理解，而需求的各个属性的取值则与该需求对系统的影响度和重要度相关。序号需求名称需求说明状态优先级风险1网上订单提交能够通过Internet提交订单标准的关键关键的2产品信息查询能够在Internet查公司的所有产品详细信息标准的关键关键的3产品信息维护对公司销售的产品信息进行维护标准的关键关键的4订单状态查询客户和员工均可以对订单的状态进行详细查询标准的关键关键的5订单支付给客户提供网上支付未来需要的可选普通的6客户信息
26、管理对客户信息进行维护标准的重要重要的7客户信息查询可根据条件对客户信息查询标准的重要重要的8客户信用级别定义根据客户购买记录进行客户信用级别定义建议的可选普通的9客户信用额度计算按照一定的计算方法进行客户信用额度的计算建议的可选普通的10产品价格策略维护对公司的不同产品制定不同的价格策略未来需要的可选普通的需求的捕获需求的捕获 5.2.12.理解系统的环境理解系统的环境概念概念：系统环境是系统所处的业务、技术环境的综合描述，包括对环境中的重要概念和过程的描述。概念的描述：概念的描述：对环境中的重要概念的描述采用领域模型的方式，通过领域建模来描述领域中的主要对象，并将这些对象按照它们的关系连接
27、起来。确定这些对象并给这些对象命名有助于建立术语表，以确保参与系统的每个人都能够较好的根据领域知识进行交流。同时，领域模型有助于建立系统概念模型并确定相应的分析类。过程的描述：过程的描述：对环境中过程的建模通过业务模型来完成。分析人员通过建立系统业务模型能够了解软件系统所处的环境和业务过程，业务模型能够将这些信息进行体现，并表现环境中存在或可以察觉到的过程，从而详细说明软件系统所要支持的业务过程。需求的捕获需求的捕获 5.2.1(1)领域模型领域模型 领域模型能捕获系统环境中最重要的对象类型，描述对象类型之间的关联关系。领域对象代表了系统工作的环境中存在的事情或发生的事件。很多的领域对象或类可
28、以从需求规格说明中找到，或者通过与领域专家，业务人员的交流获得。领域类通常有三种典型的形式：l 业务对象，表示业务中可操作的东西例如订单、合同、账户等；l 系统需要处理的现实世界中的对象和概念，如大楼、车辆等；l 将要发生或已经发生的事件，例如货物抵达、订单申请等。领域模型通常由领域分析人员完成，通过讨论会、面谈、阅读原始材料等方式来获得，领域模型通常使用UML 图和其他建模语言来将结果文档化。领域建模的目的是理解和描述在领域环境中最重要的类和对象，规模适中的领城模型一般需要1050 个这样的类，规模更大的系统可能需要更多的类。需求的捕获需求的捕获 5.2.1(2)业务建模业务建模 通常，我们
29、通过业务过程图来描述业务领域的问题。我们的目的是将整个业务领域作为一个过程集进行描述。过程图不必严格精密它应该全面而不是精确。对于网上购物系统，这些活动包括：l 销售 所有销售活动和这些活动的记录；包括所有形式的销售；包含获取订单、分配和税收、用户管理、用户的购买和支付活动、追踪购买的质量与定价等。l 仓储 所有入、出库活动和这些活动相关的记录；包括在库商品的管理，出库单，入库单，库存量的修改等。l 财务 所有与钱相关的活动。l 采购 所有采购活动和这些活动的记录；包含采购计划和采购单，收货单，供应商管理。可见，在抽象层，这些是公司行为总的划分，这样划分容易取得广泛的一致。对于网上购物系统，销
30、售活动的第二层分解可能为：l 合同磋商与销售相关的商品的价格，质量，售后服务等。l 订货与订货有关的所有活动l 货物交付与交货有关的活动l 接受退货与退回不想要的或不满意的货物相关的所有活动l 给顾客开发票与开发票相关的所有活动l 接受付款与接受付款有关的所有活动。需求的捕获需求的捕获 5.2.1网上购物系统中接受付款的第三层可能为：l 标识付款的订单l 打印付款收据 图图5.17目前为止定义的所有过程层次的过程图目前为止定义的所有过程层次的过程图需求的捕获需求的捕获 5.2.1(3)术语表术语表术语表的说明术语表的说明：在理解系统环境的过程中，我们提到领域模型是了解系统对象的一种重要方法和手
31、段。利用UML 图，领城模型不仅能够反映系统对象而且能够体现系统对象之间的关系。但是不容忽视的是，如果将所有的候选类都用领域模型来表达，则需要花费的工作量是非常大的，而这对保证系统开发的进度是不利的，需求阶段的工作应该更多地集中到捕获系统功能性需求和非功能性需求上。此时把在领域范围内选取的候选类保存在术语表中将是一个更为明智的选择。此外，针对一些非常小的业务领域，也没有必要为其建立对象模型，只是采用一张简单的术语表就可以了。术语表实例术语表实例：序号名称相关解释标识符号1客户从公司采购商品的组织或个人Customer2购物车用来临时存放用户购买的商品ShopBag3订单一张说明客户购买的商品种
32、和数量的表单Order4发票客户付款时的收据Invoice5产品公司销售的各种产品Product6信用额度说明客户最多可以赊欠的资金数额Credit7标准价每个产品都有一个标准价，但根据不同客户的价格策略的不同，产品的销售价格会有所不同StandardPrice表表5.2网上购物系统术语表网上购物系统术语表需求的捕获需求的捕获 5.2.13.非功能性需求非功能性需求 基本上，功能性需求具体描述了系统做什么，而非功能性需求则描述了系统做得有多好。用例具体描述了功能，但是，它们也可以作为搜集、记录非功能性需求的一种方法。应当考虑某些典型的非功能性需求，它们可能对系统产生影响。在用例定义阶段获得非功
33、能性需求是一个恰当的考察点。(1)可承载性可承载性 系统或用例的可承载性表述了在给定时间内系统能被使用的次数，这一因素与Internet应用的出现尤其相关。可承载性需求将对设计与实现产生重大影响。系统的各个部分可能有不同的可承载性需求。(2)安全性安全性 公司所拥有的数据是珍贵的。不同的安全级别是适当的，随功能而定。用例可能涉及到数据在公共网络上的传输。防止信息泄露和第三方欺诈性的通信。需求的捕获需求的捕获 5.2.13.非功能性需求非功能性需求 (3)紧急程度紧急程度 用例的紧急程度说明了用例有多么重要。(4)使用与响应的频率使用与响应的频率 用例的使用频率将对用例的设计产生巨大影响。理解使
34、用频率有助于设计人员明白需要花费多大努力来进行代码优化。某些用例的响应时间是很关键的，尤其是在实时应用中。对于某些过程控制系统而言，所需的响应时间的要求是毫秒级的。(5)可用性可用性 便于使用。(6)可靠性可靠性 可靠性包括了有效性、从错误中恢复的能力和精确性。(7)其他非功能性需求其他非功能性需求(8)补充需求说明补充需求说明 补充需求说明用来描述这些不与任何特定用例相关联的非功能性需求，它可以采用传统的需求规格说明中陈述需求的格式进行描述，并与用例模型一起用于分析和设计。功能分析功能分析 5.2.2 需求捕获的主要工作是获得系统需求，建立待开发系统的模型，而用例可以帮助我们更好地了解系统需
35、求并以规范化的格式进行描述。功能分析的工作就是要以用例的方式来描述系统功能，其主要工作成果是用例模型，功能分析的主要工作包括：l 识别参与者和系统边界l 识别系统用例l 建立用例模型并识别用例间关系l 划分用例的优先级别并确定时间安排计划l 对部分关建用例进行详细描述l 对部分关键用例建立界面原型 功能分析功能分析 5.2.2 1 识别参与者和定义系统边界识别参与者和定义系统边界 概述与注意的问题概述与注意的问题：参与者（Actor，一个外部的主动者）是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者通过向系统输入和请求系统输出某些事件来触发系统用例的执行。一个参与者代表的角色有：
36、人、硬件设备，或者是另一个系统。参与者实质上是一个角色，而不是一个人。一个人能够以多种不同的角色使用系统。功能分析功能分析 5.2.2挑选参与者的步骤：挑选参与者的步骤：l 考虑所有可能与系统运行有关的人员、设备和其他系统，包括给系统提供数据或需要系统提供数据的各种角色；l 根据系统需要，确定参与系统维护和操作的参与者；l 对于每个参与者，判断是否能够确定至少一个用户来扮演这个角色。并实现这个角色所应该具有的功能，这样可以避免凭空想象各种参与者；l 对于获得的多种参与者，要注意尽量减少功能重叠的地方，对它们进行合理的组织和合并。例如对于网上购物系统来讲，购买台式机产品的顾客和购买笔记本产品的顾
37、客都是企业顾客的特例，可以当作同一个参与者“顾客”来处理。概念与注意的问题：概念与注意的问题：系统边界标识了什么在系统之内和什么在系统之外，并进而能够识别什么是系统的职责 从不同的考察角度来看待整个系统，可能会得到不一样的系统边界范围，不同的边界范围对系统的后续开发工作会产生一定的影响。功能分析功能分析 5.2.22个实例：个实例：图图5.19 系统边界系统边界功能分析功能分析 5.2.22.建立用例模型建立用例模型(1)用例的识别用例的识别 UML中用椭圆形来表示一个用例，名称写在下方或者内部。识别系统中的用例的两种方法识别系统中的用例的两种方法：第一种识别用例的方法是基于参与者的方法。识别
38、出与系统或组织有关的参与者 对每个参与者，识别出他们发起或参加的执行过程第二种识别用例的方法是基于事件的方法。识别出系统必须响应的外部事件把事件与参与者和用例联系起来功能分析功能分析 5.2.2检查用例是否齐全：l 每个参与者的特定任务是什么？l 是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？l 是否有参与者将有关突发性的、外部的改变通知系统？l 哪些用例支持或维护系统？l 用例是否包括了所有功能需求？用例的命名：l 按照企业组织的系统开发统一标准来命名；l 名称格式采用“动词名词”的动宾结构；l 名称应具有一定意义，直观且易于理解；l 用例的名称具有惟一性。功能分析功能分析 5
39、.2.2(2)识别用例间关系识别用例间关系 用例图中的关系用例图中的关系：在UML图中，关系用连接用例与活动者的线表示，下图，这意味着活动者使用用例。图图5.22 UML中活动者与用例之间的联系中活动者与用例之间的联系功能分析功能分析 5.2.2 在关系中，可以用箭头，如下图。箭头的方向表明谁发起了交互，而不是信息的流向。图图5.23 UML中活动者向用例发起对话中活动者向用例发起对话功能分析功能分析 5.2.2 用例之间的关系用例之间的关系：包含（Include）或扩展（Extend）。包含关系意味着所有其他的用例都可以使用这个具有同一功能的子用例。图图5.24 用例间的包含关系用例间的包含
40、关系(一个用例总是包含另一个用例的行为一个用例总是包含另一个用例的行为)功能分析功能分析 5.2.2 扩展关系则主要用于表示：l 可选择的行为；l 在特定条件下才发生的行为，如警告信息；l 基于操作者的选择而进行的几种不同流程。图图 5.25用例间的扩充关系用例间的扩充关系(一个用例只是偶尔被另一个用例所调用一个用例只是偶尔被另一个用例所调用)功能分析功能分析 5.2.2 (3)用例图用例图 概念说明概念说明：识别了系统用例后，可以用图和说明的方式来组织和整理用例模型，以说明用例之间的关系和用例与参与者之间的关系。用例图是用例模塑的图形显示，描述了系统的一组用例、用例的参与者以及用例和参与者之
41、间的关系。同时，还可以以文档的方式从整体上解释用例模型。描述参与者与用例如何进行交互，并描述用例之间如何彼此相关联。步骤：步骤：第一步可以根据不同的方式进行用例的组织，包括按照角色组织、按照系统的不同考察角度、不同的层次等进行划分；第二步是确定共享的用例，进行用例抽象，从而定义用例之间的包含关系；第三步是确定各用例的扩展或可选部分，即定义用例之间的扩展关系。最后可以根据对每个用例的仔细分析进一步确定用例之间的其他关系，并对用例建立简要说明。功能分析功能分析 5.2.2评审用例图的判定条件评审用例图的判定条件：l 是否已经将所有必需的功能性需求捕获为用例；l 每个用例的具体动作序列是否是正确的、
42、完整的和易于理解的；l 是否已经确定了一些价值很小或根本没有价值的用例，若有则重新考虑是否应该包含它们。l 用例的组织和用例之间的关系是否合理和正确。用例图实例：用例图实例：功能分析功能分析 5.2.2(4)识别用例常见的错误识别用例常见的错误 第一个常见错误是把用例当作单独的步骤、操作或事务的处理。第二个常见错误是过多或过少的用例。确定一个用例是否合适有两个准则：l 有价值的结果准则l 具体参与者准则第三个常见错误是关系过于复杂。以下方法可以帮助控制用例模型之中的各种关系：l 系统边界的确认l 角色的组合和合并；l 注意用例识别的角度，从用户而不是从系统角度来识别和命名用例，用例应该反映用户
43、的真正目标和需求。功能分析功能分析 5.2.2其他常见的一些错误还包括：其他常见的一些错误还包括：l 角色名称互相矛盾；l 用例规格叙述过长；l 用例规格叙述混乱；l 用例没有正确地描述功能；l 用例令用户难以理解3.用例排序用例排序 概念与说明概念与说明：按照迭代开发的观点，系统开发的任务分为多次迭代来完成，即分为多个开发周期来完成，每个开发周期会从事新的用例的开发，或者是对前一个或多个周期的扩展。用例的分类：用例的分类：对用例按照一定的标准来进行类别划分或顺序排列，其目的是找出对系统最为重要的用例，确定高级别的用例集，并在早期的开发周期中优先完成，以降低整个系统开发的风险，提高系统开发成功
44、率。用例分类步骤：用例分类步骤：l 定义用例的级别，分五个级别l 对每个级别内的用例按照功能实现的重要性进行排序。功能分析功能分析 5.2.2用例分类中的排序标准：用例分类中的排序标准：l 用例是否时体系结构设计有重要影响；l 用例是否为含有高开发风险、时间紧迫或功能复杂的用例；l 是否涉及重要技术研究或者新技术和高风险；l 是否代表核心的或关键的组织业务流程；l 是否为不需要花费很多努力就可以从中获得重要信息和线索的用例；l 用例能否产生直接经济效益或者降低成本。实例：实例：用例顺序开发周期安排难度验证用户身份1开发周期一实现较简单计算信用额度2开发周期一功能复杂、高风险审核顾客信用3开发周
45、期一实现较简单下订单4开发周期一主要功能，对体系结构有重要影响产品库存更新5开发周期一主要功能，对体系结构有重要影响生成错误报告6开发周期一实现较简单查询订单状态7开发周期二实现较复杂功能分析功能分析 5.2.24.用例的详细描述用例的详细描述 名称名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。概述或简要描述概述或简要描述 单列一节概述该用例完成什么通常是有益的。参与者参与者列出此用例涉及的参与者和负责发起此用例执行的主参与者。触发器触发器触发者是开始此用例的事件。触发者并不必须向该系统输入事件。前置条件前置条件前置条件概述在用例可以开始前，什么必须为真。通常前置条件说明
46、在指定的一个用例运行前，另一个什么用例必须执行。典型的前置条件可以是“用户已成功登录”。后置条件后置条件后置条件概述当用例完成时什么是真。在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么和不发生什么。事件路径或脚本事件路径或脚本基本的或正常德事件路径，通常应当作为不中止的交互序列出现。对事件路径中的交互通常加以编号，以便于以后参照。可选和例外事件路径可选和例外事件路径可选和例外事件路径可以完整写出。然而通常只须在基本事件路径中的分叉点简单地指
47、明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的条件。扩展点扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。扩展本身应当作为单独得用例写出；否则，可以指明可选的事件路径。包含包含这一节简单地概述包含在已定义的用例中的用例。在哪些地方包含发生应当在事件路径中指明。描述格式：描述格式：功能分析功能分析 5.2.2描述的实例描述的实例：l 名称：下订单标识：GenerateOrderl 说明：客户根据需要通过Internet提交采购订单前置条件：查找到合适的采购商品后置条件：生成用户订单或因为有错误生成错误报告扩展：“生成借误报告”包含：“信用审核
48、”，“登录”相关的商业规则：信用审核规则BR01，超期检查规则BR02 基本操作流程（基本路径）基本操作流程（基本路径）:1）顾客通过浏览产品目录来选择要购买的产品；2）Ex2.1，Ex2.2，Ex2.3顾客确定类型和数量放入购物篮；3）Ex3.1顾客填写订单的必要信息如：送货时间和进货地点等并将订单提交给系统；4）Ex4.1系统生成顾客订单并传到生产和送货部门，并更新库存。功能分析功能分析 5.2.2可选操作流程（备选路径）可选操作流程（备选路径）:备选过程Ex2.1：该型号产品缺货1.将该型号产品缺货的情况通知客户；2.返回浏览产品目录，重新选择产品。备选过程Ex2.2：该型号产品缺货1.
49、将该型号产品缺货的情况通知客户；2.顾客进入预约单。备选过程Ex2.2：用户修改购物篮信息1.顾客进入购物篮，修改产品数量或删除产品；备选过程Ex3.1：用户信息不全1.将顾客信息不全的情况通知顾客；2.顾客重新填写订单的必要信息。备选过程Ex4.1：系统错误1在生成顾客订单并传到生产和送货部门，和更新库存的过程中系统出现 任何错误，应及时通知顾客。2顾客重新下订单。交互图的分析交互图的分析5.2.3概概述述：在系统分析中还需要把这些用例功能翻译成计算机系统中的对象组之间可能实现的交互。顺序图和协作图就是这样的两种方法，它们从不同的角度来研究需求分析阶段搜集来的用例，将用例定义中相互作用的对象
50、串在一起来描述系统行为的过程，而这些对象可以是前面分析过程产生的，也可以是根据需要进行创建的。1.顺序图的分析顺序图的分析 概念与说明概念与说明：顺序图是二维图，根据对象间的交互，用图形记录了对象交互的顺序。系统顺序图展示了一个用例的特定事件发生的过程中与系统直接发生交互的外部参与者、参与者所发起的外部事件以及系统为响应事件而做的各个行为等。顺序图通向设计。最初的顺序图不会过多关心微小的细节，也可能会遗漏一些需要在设计阶段加入的重要元素。设计阶段还需使用顺序图，此时可能需要向顺序图中加入细节和组织对象。交互图的分析交互图的分析5.2.3对于“下订单”的简单用例，我们可以使用顺序图来详细描述。“