用例分析技术小结_用例图太多-优快云博客

转自:http://blog.youkuaiyun.com/icu/archive/2006/03/07/617638.aspx

前言

现在RUP如日中天，需求分析是第一步，可以看作是高级系统分析员的必备知识，那么，如果用面向对象的分析技术来描述需求呢？

在一个需求分析过程中，主要有项目描述，风险分析，用例图以及描述，项目建议这几部分。

其中最重要的，也是最需要学习的就是用例的描述。那么用例的描述关键点在哪里呢？

确定系统边界

确定清晰的系统边界，就是要确定系统中有什么？系统外有什么？通过执行者和用例来确定系统边界。

那么，我们第一步就是要找出执行者，执行者是一个角色，我们可以根据以下几个问题来思考决定一下：谁在使用系统？谁在维护？谁在启动?谁在关闭？谁从这个系统获得信息？谁为这个系统提供信息？是否有自动的事情在预计时间发生？等等方式，来确定执行者。

找出了执行者，那就要确定用例，用例是系统的一个行为，为执行者产生可以估量的价值结果。

用例的描述一般都是动名词结构。

需要构建一张表，清楚的以名词解释的形式，把用例和执行者进行简单的定义。

如果用例图过于大，那就分开，也可以采用包的形式。

其中用例图的中的箭头表示是单向还是双向，要根据交付的信息看。

如果是外部定时发生的事情，可以把时间也作为执行者。

需求在系统之内，无法被执行者看到，那么这个需求就不用在用例图中体现。

归档用例

归档用例就是把用例用文档的方式表示。基本用例主要包括：前置条件（前置条件就是用例开始时候，必须要处在一个什么状态）后置条件（用例结束，系统处在什么状态）事件流。（事件流是一系列的陈述句）。

事件流中包含一些循环语句。可以采用for ,while循环。

用例是一个传达工具，只有向读者传达系统如何工作的时候才有效。

用例要从执行者的观点来写。

对于非事件流的需求，可以在用例的特殊需求中描述。

事件流分为两部分：基本路径和可选路径。

一切正常运转就是基本路径。

不同于基本路径而允许选择不同的事件序列的路径，就是可选路径，也可以说各种异常情况的处理也是可选路径。

可选路径，最好用不同的段落编号来标示。

什么是场景？场景就是一种贯穿用例的特定路径。

用例的包含：如果你发现在写各种用例的时候，要经常copy同一部分的内容，那么就说明你有了一部分通用的行为，那么就可以用一种包含关系来抽象这种通用行为。包含用例一定要有被包含用例，这个用例才算完整。

用例的扩展：在不改变原始用例的情况下，增加用例的行为。重要关注的一个概念是扩展点，当到达这个扩展点，如果条件为真，就是这个扩展条件的前置条件为真的话，这个扩展的步骤将被执行。

用例的继承：用例的继承代表一个用例（子）是另外一个用例（父）的特殊实现，执行者的继承意味着一个执行者（子）可以完成另外一个执行者（父）的任务。

接口：接口不是执行者和用例的一部分。接口是执行者和用例相互作用的一种描述。

文档中的文字可以简洁的描述系统，那么有些文字分支很多的时候，采用图就是一个非常好的方式，图形化用例也是一个不错的手段。我们可以用三种图来细化和具体化用例。

活动图：描述用例的步骤。活动图描述满足用例需求而进行的活动以及活动之间的关系。（有些书把活动图定义为状态图的子集）

时序图：描述执行者和系统的相互作用。时序图中，每个实体下面有虚线，代表对象生命周期。确认的返回值，是采用虚线箭头来表示。

在学会写用例以后，那就有一个问题，用例写到什么程度好呢? 就是用例细化到什么程度为好。要回答这个问题，需要考虑三个问题：谁需要阅读并审批这个文档？谁需要使用这个文档？我们要这个文档做什么？用例可能是给最终用户和开发者的，或者管理者的，决定多少细节放到用例中是一个很重要的事情。可以对同一个用例做不同细节程度的版本，交给不同的人看，要注意维护这种对应关联关系。

用例文档模板：

包括系统简介，风险因素，系统级用例（一个或者多个反映系统中所有用例和执行者的图，没必要包含用例之间的关系，例如包含，扩展和泛化），体系结构，子用例，非功能性的需求包括可用性，系统，安全，持久性，冗余性，性能，规模，标准化等。

可以通过活动图来描述和表现用例之间的关系和流程。

划分大型系统：

如果是做一个大系统，那么把大系统划分为小系统就是一个非常重要的事情！先选出系统中最重要的部分。主要的体系架构有如下几种：

一、MVC结构，一层用来显示，一层用来控制，一层用来数据存储。例如JSP,Struct就是这种架构。

二、管道和过滤器体系结构。主要思想就是一个部分输入数据，处理数据，然后输出，下一个部分接收，处理，依次类推，例如freeRadius，JRadius就是这种架构。

三、面向对象的体系结构模式。系统是根据数据来定义，并且和各种功能相联系。可以使用用例验证体系结构，每一个子系统应该有：

---单一的功能性

---强聚合性---它的各个部分彼此之间具有很强的相互关系

----松耦合性---其工作的完成不太依赖于其他子系统

----与其他子系统最少的通信----子系统之间不进行大量的通信。

接口中的操作来自时序图。将每个子系统看作一个整体的系统，每个系统都有执行者和用例。不断的把大系统分为各种小系统，当系统足够小的时候，无需更多的划分就有足够的细节来实现。

主题摘要：主题摘要就是指我们在用例中使用或处理的东西。是创建系统的基本元素，是描述域的一种方式。简单的寻找主题摘要的方法是：查找用到的实体或数据。通过时序图来绘制场景，可以把系统对象换成主题摘要，把子系统也换成系统摘要，这样，发送给子系统的消息就改为发送给主题摘要和执行者的信息，并且最重要的是要确定主题摘要的行为，确定主题摘要以及他们的行为，就为类的设计打下了基础。

通过时序图，我们发现主题摘要，也就可以找出摘要必须作出相应得消息，然后把消息对应到用例的参与类中，参与类视图就是告诉我们要开发哪些类。

用例试图显示了系统中的工作流程，是黑盒测试和用户指南的基础。

子系统视图显示了构成该系统的子系统，是系统重用和维护的基础。

用例视图是展示了系统的外观，只系统视图是显示了构成该系统的子系统，一个是从客户角度，一个是从开发角度。

通常是在第一次迭代处理风险最高的，第二次迭代处理次之风险。

通过用例来估算工作：

1、执行者加权

执行者类型	描述	因子
简单	程序接口	1
普通	交互和协议驱动接口	2
复杂	（图形接口	3

2、用例加权：

用例类型	描述	因子
简单	最多3个事务，最多5个分析类	5
普通	4-7个事务，5-10个分析类	10
复杂	多于7个事务，多于10个分析类	15

事务的概念在这里是一个路径，包括可选路径，是一组原子操作。

用例的加权总数和执行者的加权总数相加，就得到了未经调整的用例点 (UUCP)

3、技术因子加权：计算项目技术的复杂性，可以利用技术复杂性因子。从0到5确定每一个因子的等级。0等级意味着这个因子与项目不相关，5代表它是最重要的。然后用因子去乘每个因子的权重，然后相加。

因子编号	因子描述	权重
T1	分布式系统	2
T2	响应性或吞吐能力	1
T3	最终用户效率	1
T4	复杂的内部处理	1
T5	代码必须可以重用	1
T6	易于安装	0.5
T7	易于使用	0.5
T8	可移植性	2
T9	易于更改	1
T10	并发	1
T11	包括特殊的安全性	1
T12	为第三方提供直接访问	1
T13	需要特殊的用户培训设施	1

TCF=0.6+(0.01*TFactor) TFctor=所有（权重 * 等级）相加之和。

4、小组的环境因子和权重. 从0到5确定每一个因子的等级。0等级意味着这个因子与项目不相关，5代表它是最重要的。

因子编号	因子描述	权重
F1	熟悉RUP	1.5
F2	使用经验	0.5
F3	面向对象经验	1
F4	领导分析能力	0.5
F5	动力	1
F6	稳定的需求	2
F7	兼职人员	-1
F8	有难度的编程语言	-1