• 本栏目热门文章

• 本栏目最新文章

• 电子商务项目-需求分析与建模第二部分

• 时间：2006-03-16 07:37 AM 来源：沪江电子商务网 作者：y 阅读： 次

电子商务项目-需求分析与建模第二部分 （1）

作者：kingshare 发文时间：2006.03.14

4、UML中的用例及用例图概述

（1）用例及用例图产生的技术背景概述

• 在软件系统的分析与设计中，必须要了解并准确描述用户的功能需求，以便于确定建立的对象。
• 很长时间以来，无论是传统的软件开发方法还是面向对象的开发方法，都采用自然语言（如中文）来描述对系统的需求
• 其缺点是没有统一的格式，缺乏描述的形式化，随意性较大，常常产生理解上的含混及不确定性。
• 在这种背景下，有关专家提出了用例（Use Case）的概念及其图形表示方法——用例图，这种方法很快得到广泛的应用。

（2）参与者和用例

• 参与者（Actor）表示系统用户能扮演的角色(role)，这些用户可能是人、也可能是其他的计算机或者一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外，并且它们必须能刺激系统部分并接收返回。

• 在本项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。
• 在前面的学校课程管理系统中的示例中则有三个Actor 在不同的应用中互动。这三个Actor分别是学生，讲师以及系统管理者。而学生Actor 使用了系统中浏览课程以及注册课程的功能，而系统管理者Actor 则是负责管理注册的学员，编排课程以及确认课程。讲师则是主导课程的Actor，他可以浏览，开办以及移除课程(当然，必须是这个讲师自己的课程)

（3）所要注意的问题

• 参与者主要是指角色而非具体的个人

• 用户与参与者之间的关系

ü 一个用户可以抽象为多个参与者，如：张三即可以是网上书店的读者，也可以是管理员

ü 一个参与者可以包含多个用户，如：网上书店的读者可以是张三和李四

（4）用例（UseCase）及其定义

• 它描述了当主角之一给系统特定的刺激时系统的活动，是主角通过系统完成一个过程时出现的一组事件，最终以实现一种功能。l
• 通常，用例侧重于功能，但不重点描述该功能的实现细节。l
• 用例的大小划分一般以事件流在10个步骤左右为好。l

（5）用例的分类

• l 业务用例（Business Use Case）
  指系统提供的业务功能与参与者的交互，表现问题领域中各实体间的联系和业务往来活动。它用于建立问题领域的业务用例模型。
• l系统用例（System Use Case）
  指参与者与系统的交互，它表现了系统的功能需求和动态行为。

注意：用例确定的只是交流的目的，而不是交流的手段

客户并不需要了解执行者、用例这些概念。用例能告诉开发团队“去向客户了解什么”（目的），不能告诉你如何向客户去了解（手段）；

手段可以有很多种，文档研究、问卷调查、访谈、观察、研究竞争对手、开会、原型、场景演示…，使用用例思维来指导这些交流手段，会使交流更有目的，更加高效。因为以场景方式表达的需求本来就比一条条列出的需求要便于交流。

（6）用例的层次化

按照抽象层次，用例图可以划分为系统层（最高层）、子系统层（可以再细分）和对象类层（最低层）。

• 系统层用例图描述系统提供的全部服务。l
• 子系统层用例图描述子系统提供的服务，它的外部交互者可以是其他的子系统或高一层的参与者。l
• 对象类层的用例图描述对象类提供的功能片或操作，它的外部交互者可以是其他对象类或高一层活动者。l

（7）用例建模的主要步骤

• 确定边界（区分敌我---找出系统外部的活动者和外部系统，确定系统的边界和范围）和参与者l
• 确定用例（功能实现的）优线级和相互依赖关系l
• 对用例进行分层（适当分解和细化用例，用例需要细化到什么程度？）l
• 编写主成功场景，并尽可能列出所有扩展条件。编写扩展处理的步骤。l

责任编辑:yangjz