UML(用例类时序)..doc

用例图： 描绘不同系统用户群是如何同这个系统交互。用例定义和描述用户从系统中获取价值的各种方法。 创建一个用例模型需要三个步骤： 1 确定使用这个系统的人群 2 确定这些人群是如何从系统中获取价值 3 用一个简单易懂的视图来描述这些用户以及他们如何使用系统 第一步： 寻找参与者(actor) 确定使用该系统的各种人群，一种人群称为参与者(actor)，使用这个系统或被这个系统使用的其他系统也是参与者。 参与者定义：指在某个系统的外部并和该系统交互的一群人或一个系统。 例：下列小组都是参与者 1 银行客户和柜员分别是单独的参与者，因为他们有着不同的需求和权限 2 大多数游戏系统中，男人和女人没必要分成单独的参与者 3 学生和登记管理员是单独的参与者，有不同的需求和访问 第二步： 寻找用例(use case) 系统为参与者提供一个独立的价值所采用的方式称之为用例. 用例必须是集中的，并有一个明确的目标 如果用例满足以下条件，则是集中的： 1 用例应带来独立的好处 2 可以用20-30个单词来描述这个好处 3 参与者能通过一次会话完成该用例 例： 银行系统有输入帐号、选择帐号、取款、存款、选择源帐号、选择目标帐号、资金转移等功能，如果将这些动作都作为用例则显得太细，不能满足独立条件。比如，没有一个用户会在选择一个帐号后就满意的离开！但是，如果只为一个用例---资金管理，则又显得太笼统。好的用例应提供一个具体的用途！ 取款、存款、转账等都可以是好的用例，均提供了具体的用途！ 第三步 描述参与者与用例 UML中，参与者用棒形人表示，用例用带标记的椭圆来表示 参与者指向用例的带箭头的实线表示这个参与者触发该用例，比如： 利用用例描述需求： 1 用例描述 说明用例的概况和特征，比如，前置条件、后置条件、性能需求、安全要求、部署约束等。 前置条件—包括参与者启动这个用例之前必须完成的所有其他用例 后置条件—包括这个用例对系统所作的所有改变 部署约束—描述访问这个用例的所有约束 2 事件流 描述参与者在完成用例的过程中发生的一系列的交互行为。 银行ATM： 1 用户插入卡，输入PIN，系统显示包含用户名的欢迎信息，并提供取款、存款、转账等选项 2 用户选择取款，系统显示所有可供选择帐户 3 用户选择帐户，系统要求用户输入金额 4 用户输入一个正整数，系统询问用户数额是否正确 5 用户确定金额是正确的，系统显示感谢信息，取出钱、打印帐单并返回客户的卡 以上就是一个事件流，但描述的是一切都正常运行时的交互情况，还有一些可能的其他情况的事件流，所以，事件流分为三种： 1 正常或基线事件流，以上事件就是这种事件流 2 可选事件流 描述由参与者引起的变更，比如，参与者放弃取款、输入错误数据等，一个用例可能有几种不同的可选事件流，以上取款的可选事件流包括输入一个无效的PIN或者取款金额过多等。 3 异常事件流 由系统引发的事件，比如网络故障、磁盘错误等 3 活动图 集中显示一个用例所有事件流的UML图。活动图描述一个开始状态、系统执行的活动、执行下一个活动时需做的判断以及一个或多个结束点。 *实心的圆圈代表用例的开始 *圆角的矩形代表系统执行的活动 例 以下是上面ATM取款事件流的活动图： 注意：一个用例可以被多个参与者执行，反之，一个参与者可以执行多个用例 类图 标记静态内容及其类之间的关系。在一个类图中，我们能够查 看一个类的成员变量和成员函数。我们也能查看一个类是否继承自另外一个类，是否拥有对 另外一个类的引用。简而言之，我们能够描绘出类之间的源代码依存关系。 Figure 3-1 展现了一个类图的最简单的形式，这个名叫 Dialler 的类代表一个简单的长 方形。这个图代表的东西并不比右边的代码要多。 这是表现一个类的最常用的方法，大多数图的类有一个能够清楚表达的命名就可以了。 一个类的图像符号被细分成几个框格，最上面部分表示类的名字，第二个框格表示类的 变量，第三个框格表示类的方法。Figure 3-2 展示所有的框格及对应的源代码。 请注意在类图像符号里，在变量和函数的前面一个字符，一个“-”表示变量或函数是私有（private），“#”表示变量或函数是受保护(protected)的，“+”表示变量或函数是公开的(public)。 紧接在变量或参数名称的冒号（：）号之后，表示了变量的类型或一个函数的参数的类型。同样地，函数的返回值的类型是在函数后面的冒号之后反映的。 1 关联 (Association) 类之间的关联大多用来表示变量实例持有着对其他对象的引用。举一个例子，在Figure 3-3中，我们看到在Phone和Button之间一个关联，这个箭头的方