系统建模与分析设计

《系统建模与分析设计》由会员分享，可在线阅读，更多相关《系统建模与分析设计（94页珍藏版）》请在金锄头文库上搜索。

1、需求分析与用例建模*1软件工程方法n用例用于表示系统所提供的服务，它定义了系统是如何 被参与者所使用的，它描述的是参与者为了使用系统所 提供的某一完整功能而与系统之间发生的一段对话。 n用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用 例驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现 用例为目标。n在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形 式组织成用例模型。然后分析并设计系统来满足这些用例，因此在 用例模型之后就是分析模型，接着是设计模型和实施模型。在实现 了整个系统之后，还将根据用例模型设计出测试模型来对系统进行 验证。n这些模型之间并不是线性转变的，它

2、们是一个迭代、增量的开发过 程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭 代，每次都将越来越精化。 1 客户需求分析与用例建模Date2软件工程方法1.1 建造需求模型用例建模 用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对 典型用例的分析，使开发者能够有效地了解用户的需求。对于正在构造的新系统用例描述系统应该作什么?对于已构造完毕的系统用例则反映了系统能够完成什么样的功能? 用例建模的主要目标是：将需求规约变为可视化模型，并得到用户确认； 给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求； 提供从功能需求到系统分析、设计、实现各阶段的度量标准

3、； 为最终系统测试提供基准，据此验证系统是否达到功能要求； 为项目目标进度管理和风险管理提供依据。 Date3软件工程方法用例图中包含系 统、角色和用例 等三种模型元素 ，以及它们之间 的关系。贸易经理风险分析进行交易交易估价更新帐目使用使用扩展营销人员超越边界评价销售人员记账系统设置边界Date4软件工程方法n用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。n 它驱动了需求分析之后各阶段的开发工作,不仅 在开发过程中保证了系统所有功能的实现,而且被 用于验证和检测所开发的系统,从而影响到开发工 作的各个阶段和 UML 的各个模型。n 用例模型由由若干

4、个用例图构成，用例图中主要描用例图构成，用例图中主要描 述执行者和用例之间的关系。述执行者和用例之间的关系。在UML中,构成用 例图的主要元素是用例和执行者及其它们之间的 联系。Date5软件工程方法确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。 用例建模的步骤：Date6软件工程方法1.2 用例图 图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关

5、系 3）泛化关系角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例Date7软件工程方法1.3 定义系统的边界和范围 系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。定义系统：要定义系统的范围和边界1定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。2定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。Date8软件工程方法1.4 确定执行者（参与者，角色）n执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表

6、示。n执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设 备、甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中 ，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者n角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系 统交换信息。n角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户 交流的起点。一个执行者可用启动多个用例，而一个用例也可以被多 个执行者启动。Date9软件工程方法1.寻找和确定执行者通过向用户

7、提问来识别角色：n谁使用系统提供的主要功能？（主要角色）n谁来维护、管理系统？（次要角色）n谁需要借助于系统完成日常工作任务？n系统需要控制的硬件设备有哪些？n系统需要与其他哪些系统交互？n系统从哪儿得到信息？n对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。Date10软件工程方法ATM系统的Actor1、谁使用ATM系统的主要功能（提款）？答：储户2、谁使用ATM系统的支持以完成日常工作任务？答：出纳员？还不肯定，先放在这里3、谁来维护、管理并保持系统正常运行？答： ATM系统工程师，银行人员Date11软件工程方法5、ATM系统需要处理哪些设备？答：信用卡6、谁对AT

8、M系统运行的结果感兴趣？答：银行会计、储户4、该系统需要和哪些系统交互？答：目前还不清楚Date12软件工程方法Date13软件工程方法2.定义执行者时应该注意的问题n1）执行者之间可以有继承关系Date14软件工程方法n（2）执行者代表一种角色而不是具体某个人n（3）对同一个人担任角色的限制n（4）执行者可分成主执行者和副执行者n（5）执行者还可细分为主动执行者和被动执行者n主动角色：Use Case的动作序列是由他先发起的，通常 系统返回最后结果主叫方，采购人员，票据录入员等n被动角色：系统通过调用角色来完成Use Case的动作序 列（或其中的某一个动作）不是初始动作的发起者当系统需要它

9、们帮助的时候最终是为了满足主动角色的需要通常是机器或其他系统Date15软件工程方法1.5 确定用例n用例，就是一件事情，要完成这件事情，需要做一系列 的活动；而做一件事情可以有很多不同的方法和步骤， 也可能会遇到各种各样的意外情况，因此这件事情是由 很多不同情况的集合构成的，在UML中我们称之为场景 。一个场景就是一个用例的实例。n从本质上讲,一个用例是用户与计算机之间的一次典型交 互作用。在UML中,用例被定义成系统执行的一系列动作 （功能）。Date16软件工程方法1.用例的特征响应性。一个用例不自动执行，总是有执行 者启动。n这件事必须由一个执行者发起，执行者的 愿望是用例存在的原因。

10、不存在没有执行者的用 例，也不应该主动启动另一个用例。Date17软件工程方法n回执性。 用例执行完毕，向执行者提供可识别的 返回值。用例的执行结果对参与者来说是可观测 的和有意义的。如，系统会监控参与者在系统里的操作，并在参与者删除数据之 前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不 应该作为用例出现。因为这是一个后台进程，对参与者来说是不可 观测的，它应该在系统用例分析阶段定义。又比如，登录系统是一个有效的用例，但输入密码却不是。这是 因为登录系统对参与者是有意义的，这样他可以获得身份认证和授 权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？Date18软件工程方法完

11、整性。 用例表示一个完整的功能，必须是 一完整的描述。 必须以向执行者提供返回值作为 该用例完整性的标志。Date19软件工程方法n用例的特征-动宾短语n用例必然是以动宾短语形式出现的。即，这件事必 须有一个动作和动作的受体。n例如，喝水是一个有效的用例，而“喝”和“水”却不是 。虽然生活常识告诉我们，在没有水的情况下人是 不会做出喝这个动作的，水也必然是喝进去的，而 不是滑进去的.n但是我们所见的很多用例中类似“计算”，“统计”，“报 表”，“输出”，“录入”之类的并不在少数。Date20软件工程方法2寻找和确定用例n业务用例：开始阶段，在确定用户需求过程中， 系统分析员通过与客户交流建立业

12、务模型来发现 和确定的用例。n系统用例：系统构造阶段，系统分析和设计人员 在进行系统分析和设计时，根据系统的需求建立 的用例。n在系统开发的开端阶段，应把注意力集中在业务 用例上，在精化阶段和构建阶段再考虑系统用例 。Date21软件工程方法建立用例模型时，可询问？n用户(执行者)需要系统提供哪些业务功能,即系统能做什 么?n用户最关心系统中哪些事件?从功能观点看,这些事件表示 什么?n用户要了解系统在工作中发生了哪些事件及其结果?n用户自己需要做什么?n用户是否要在系统中创建、删除、读、修改或存储某类 业务数据？n系统为了维持正常运转需要增加的功能和信息的交互； n这些信息从何而来，到哪里去

13、？ n实现当前系统（可能是人工系统而不是自动化系统）的 关键问题是什么？Date22软件工程方法n通过与用户反复交流，确定主要业务用例和次要 业务用例。n对于建立的每一个业务用例，都需要一组系统用 例来辅助和支持。（不严谨）n系统用例是执行者与系统的交互，它描述了系统 的功能需求和动态行为。n系统用例用于建立系统用例模型，可通过分析系 统的业务流和控制流来寻找和确定系统用例。（ 活动图）Date23软件工程方法如何获得用例访谈n您对系统有什么期望？n您打算在这个系统里面做些什么事情？n您做这件事的目的是什么？n您做完这件事情希望有一个什么样的结果？一个明确的有效地目标才是一个用例的来源。一个真

14、实的目标应当完备地表达执行者的期望。一个有效地目标应当在系统边界内，由主角发动，并具有 明确的后果。n应当先建立业务用例模型，然后再从业务用例模型向系统 用例模型映射。 n注意用例图的层次，从系统到子系统逐层建立用例图。Date24软件工程方法目标和步骤的误区Date25软件工程方法怎样确定用例的粒度？n用例的粒度（用例的大小）可大可小，一 般一个系统宜控制在20个用例左右。n用例是系统级的、抽象的描述，不是细化 的（是做什么，非怎样做）n对复杂的系统可以划分为若干子系统处理 。n用例粒度的划分最标准的方法应该是：以该 用例是否完成了参与者的某个完整目的为依 据的。Date26软件工程方法nA

15、TM取钱的场景中，取钱，读卡，验证账号 ，打印回执单等都是可能的用例？n客户代表说：我希望这台ATM能支持跨行业务 ，我插入卡片输入密码后，可以让我选择是 取钱还是存钱；为了方便，可以设置一些默 认的存取金额按钮；我可以修改密码，也可 以挂失；还有我希望可以交纳水费、电费和 电话等费用；为了安全起见，ATM上应当有警 示小心骗子的提示条，还有摄像头；如果输 入三次密码错误，卡片应当被自动吞没。Date27软件工程方法判断题n支持跨行业务n插入卡片n输入密码n选择服务n取钱n存钱n挂失卡片n交纳费用n警示骗子n三次错误吞没卡片Date28软件工程方法n支持跨行业务错，这是一个业务规则，限定业务的

16、范 围n插入卡片 错，这是一个过程步骤，不是完整目标n输入密码 错，这是一个过程步骤，不是完整目标n选择服务 错，这是一个过程步骤，不是完整目标n取钱对，这是一个完整有效的目标n存钱对，这是一个完整有效的目标n挂失卡片 对，这是一个完整有效的目标n交纳费用 对，这是一个完整有效的目标n警示骗子 错，已超出了边界范围n三次错误吞没卡片 错，这是一个业务规则，限定业务的 范围Date29软件工程方法3.描述用例n用例名：n简单名： n路径名：Date30软件工程方法用例文字描述n更详细地描述用例的功能v 用例编号v 用例名v 用例描述v 参与者v 前置条件v 后置条件v 基本路径1, .X X X X2. .X X X Xv 扩展点2a. .X X X X2a1. .X X X Xv 变异点v 补充说明Date31软件工程方法v 用例编号:001v 用例名:ATM取款v 用例描述:储户使用信用卡，在AT