基于用例的需求分析方法_ 13

基于UML的面向对象的系统分析与设计基于UML的面向对象的系统分析与设计引言：在当今信息社会中，随着科技的不断进步和应用的不断扩展，各行各业都离不开计算机系统的支持。

为了满足用户的需求，开发出高质量、高效率的系统就显得尤为重要。

而面向对象的系统分析与设计作为一个重要的环节，可以帮助我们更好地理解用户需求并将其转化为实现系统的蓝图。

本文将介绍基于UML的面向对象的系统分析与设计方法，并通过一个实例来演示其应用过程。

一、基于UML的系统分析与设计基础1.1 面向对象的概念面向对象是一种思想方式和编程方法，它将问题领域的实体抽象为类，通过类的组织和交互来描述系统的行为。

面向对象的设计方法使得系统更易于理解、维护和扩展。

1.2 UML的介绍UML（Unified Modeling Language）是一种用于面向对象系统建模的标准化语言，它提供了丰富的符号和图形表示方法，可以帮助分析和设计人员更好地表达复杂的系统结构和行为。

二、基于UML的系统分析与设计方法2.1 需求分析系统的需求分析是整个分析与设计过程的起始点，通过与用户的交流和讨论，了解用户的需求并进行准确定义。

在这一阶段，分析人员可以运用UML中的用例图、活动图等工具来分析和描述用户需求。

2.2 类建模在需求分析阶段的基础上，分析人员将用户需求转化为类模型。

通过识别和分析系统中的实体、属性和行为，可以确定类的结构和关系。

在这一阶段，可以运用UML中的类图来进行类的建模。

2.3 行为建模在类建模完成后，需要进一步分析和设计系统的行为。

行为建模通常包括状态图、顺序图和活动图等。

通过这些图形化表示，可以描述系统中各个类之间的交互和信息流动，保证系统的正确性和健壮性。

2.4 设计模式的应用设计模式是一种被广泛应用的解决问题的模板，它提供了一些经验性的指导原则和设计思路。

在系统分析与设计过程中，分析人员可以借鉴各种设计模式，通过复用已有的解决方案来提高系统的可靠性和效率。

１ 用例 及 其 形 式 化 定 义
用 例从终 端用 户 的观点 对系统 建 模 ，它在需 求 诱导 时被 创建 ．用 例是 代 表 系统 中各 个项 目相 关人 员 之 间就 系统 的行 为所达成 的契 约．根据 执 行 者 作 出 的请 求 和 请 求 涉 及 的 条 件 ，系 统 将 执 行 不 同 的行 为 序 列， 每一 行为 序列称 之 为一个 场 景．一个用 例是 多个 不 同场景 的集合 Ｊ 是 ， 编写 用例 过 程 中 ， 例 的 ．但 在 用 行 为序列 是 南多个 句子组 成 的．一些 编写 者用 这些语 句描 述 的是 简单 的执行 步 骤 ，而 另一 些 则描 述 的 是一 个 过程 中所需 执行 的活 动 ，这就 造成 了语 法形式 的不统 一 ， 得 所建 的用例 模 型变 得 混乱 不 清 ．我 们 的解 使 决办法 是规定 所有 的语句 都 采 用 同一 种 语 法 形式 ，即每 个 句 子 描述 的是 一 个 过 程 中所 需 执 行 的 一个 任 务 （ａ ｋ ．用 例 中的事件 流是 一个 过程 需要执 行 的任务 （ａｋ 的序 列． ｔｓ ） ｔｓ ） 另 一个 问题在 于对 用例 的描述 ，ＵＭＩ规 范 没 有规 定 采 用何 种 方 式来 描 述 用 例．不 同 的使 用 者 描述 用 例的方 式各不 相 同 ，易导 致不 一致 性 、二 义性 等问题 ．对 用例 描述 进行 形式 化 是一种 解 决 办法 ．目前 已
例 是文本 形式 的 ，缺乏 对具 有并 行 、并 发等特 征 的行 为的表示 能 力．Ｐ ｔｉ ｅｒ 网能通 过 图形 方 式对 这 些 行 为进 行 建模 ， 而且 由于它具 有坚 实 的数学 基础 ，是完 全形式 化 的 ，所 以可以很 方便 地 实现模 型 的仿 真 和检验 ． 本 文在 给出用 例及其 相关 概念 的形式 化 定 义 的基 础 上 ， 建 了从用 例 到 Ｐ ｔｉ 构 ｅｒ 网模 型 的映 射算 法 ，提 出了一种 基 于用例 和 Ｐ ｔｉ ｅｒ 网的业务 过 程建模 方法 ．以用例 来 捕获 需 求 ，用 Ｐ ｔｉ 来 图形 化用 例 ， 通 过 ｅｒ 网 并 引入工作 流 中任务 （ａ ｋ 这一 概念 来统 一 了用例 描述 的语法 形式 ． ｔｓ ）

18
（5）可与数据建模工具ERin集成使用 BPwin可与数据库工具ERwin双向同步。使用BPwin可进一步验证 ERwin数据模型的质量和一致性，抓取重要的细节，如数据在何处使 用，如何使用，并保证需要时有正确的信息存在。这一集成保证了新 的分布式数据库和数据仓库系统在实际中对业务需求的支持。 （6）符合美国政府FIPS标准和IEEE标准 支持美国军方系统的IDEFO和IDEF3方法，使得开发人员能够从静 态和动态角度对企业业务流程进行建模，支持传统的结构化分析方法 并能根据DFD模型自动生成数据字典。此外BPwin还支持模型和模型 中各类元素报告的自动生成，生成的文档能够被Microsoft Word和 Excel等编辑。 （7）易于使用，支持Unicode 可以在各种不同语言环境的Windows平台上使用。
1
2.开发人员 需求工程涉及的角色（不要与人相混淆，角色是指 一种职责，同一个人可以担当多种角色）包括客户方 （客户、系统使用者）、系统分析师、项目开发及管 理人员。其中系统分析师起到桥梁工程师的作用，负 责完成用户“业务世界（可系统化业务对象）”逻辑 向由软硬件组成的“电脑世界”逻辑的获取和转换过 程。 3. 需求工程3个阶段 需求工程包括需求获取、需求生成和需求验证3个阶 段。
◎商业驱动（产品线瞄准的是长期的商业战略，而不是仅仅走 单）； ◎架构驱动（产品线工程依赖一个通用的参考架构，特定项目 架构都基于参考架构进行开发）；
◎两阶段生命周期（每个产品基于平台开发，产品和平台有各 自的开发团队和开发生命周期）。
16
四、需求分析 CASE工具的具体使用
1．BPwin简介 BPwin 美国 Computer Association公司出品的用于业 务流程可视化、分析和提高业务处理能力的建模CASE环 境。采用BPwin不但能降低与适应业务变化相关的总成本 和风险，还使企业能识别支持其业务的数据并将这些信 息提供给技术人员，保证他们在信息技术方面的投资与 企业目标一致。因此，BPwin作为信息化的业务建模工具 被广泛地、成功地应用于许多位居《财富》500强的大企 业、国防部及美国政府等其他部门。

精选课件
9
3.2.2 识别参与者(actor)
对于一个大系统，难以列出所有用例的清单。此时，应先 列出所有的参与者，然后在对每个参与者列出他所需的所 有用例。即提供了一种获取用例的系统化过程。
“参与者”（活动者、执行…者）是指在系统之外，透过系 统边界与系统进行有意义交互的任何事物。
精选课件
10
3.2 识别参与者
精选课件
14
思考：识别参与者？
• 寻呼台系统：用户如果预定了天气预报，系统每天定
时给他发天气消息；如果当天气温高于35度，还要提 醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 用户？气温？时间？
时间作为参与者，一种习惯用法，用于激活那些系统定 期的、自动执行的用例
精选课件
15
3.2.2 识别参与者：参与者与系统边界
精选课件
40
3.2.4 用例之间的关系
Generalization 泛化关系中，子用例继承父用例的行为和含义，子用例也 可以增加新的行为和含义或覆盖父用例中的行为和含义
<<include>> Include
一个用例（称作基本用例）的行为包含了另一个用例（称 作包含用例）的行为
<<extend>> Extend 扩展关系比泛化关系用更多的规则限制，基础用例提供扩 展点，扩展用例只能在这些扩展点上增加新的行为。
精选课件
19
识别参与者：棋牌馆管理系统
目标：构建一个棋牌馆管理系统 问题描述： 客户通过Internet预订座位，检查座位详情，如果没有空闲 的座位或满意的座位，可以选择进入等候队列。 总台服务员在客户到棋牌馆时，根据客户的预订信息，安排 客户座位。 当客户要离开棋牌馆时，客户到总台服务员办理结账，可以 采用两种方式，一种是现金结账，另一种是银行卡结账，而 银行卡结账将通过与银联POS系统交互来完成。