9面向对象方法学引论述.ppt

(2) 受限泛化 给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法。 预定义的约束有4种： 多重、不相交、完全和不完全。这些约束都是语义约束。 多重继承：一个子类可同时多次继承同一个上层基类。 不相交继承：与多重继承相反，即一个子类不能多次继承同一个基类。如果图中没有指定{多重}约束，则是不相交继承，一般的继承都是不相交继承。 完全继承：父类的所有子类都已在类图中穷举出来了，图示符号是指定{完全}约束。 不完全继承：与完全继承恰好相反，父类的子类并没有都穷举出来，随着对问题理解的深入，可不断补充和维护。不完全继承是一般情况下默认的继承关系。 4. 依赖和细化 (1) 依赖关系 依赖关系描述两个模型元素（类、用例等）之间的语义连接关系： 其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素。 (2) 细化关系 当对同一个事物在不同抽象层次上描述时，这些描述之间具有细化关系。 假设两个模型元素A和B描述同一个事物，区别是抽象层次不同，如果B是A的更详细的描述，则称B细化了A，或称A细化成了B。 细化用来协调不同阶段模型之间的关系，表示各个开发阶段不同抽象层次的模型之间的相关性，常常用于跟踪模型的演变。 9.5 动态模型 动态模型表示瞬时、行为化的系统的“控制”性质，它规定对象模型中对象的合法变化序列。 通常，用UML提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为。 每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型。 动态模型是基于事件共享而互相关联的一组状态图的集合。 超时 到达 下楼 上楼 到达 上楼 到达 在底楼 向上移动 向底楼移动 向下移动 空闲 电梯的运行 9.6 功能模型 功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求。 通常，功能模型由一组数据流图组成。在面向对象方法学中，数据流图远不如在结构分析、设计方法中那样重要。 UML提供的用例图也是进行需求分析和建立功能模型的强有力工具。在UML中把用用例图建立起来的系统模型称为用例模型。 用例图包含的模型元素有系统、行为者、用例及用例之间的关系。 符号表示： 9.6.1 用例图 1. 系统 系统被看作是一个提供用例的黑盒子，内部如何工作、用例如何实现，这些对于建立用例模型来说都是不重要的。 系统方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能。 2. 用例 一个用例是可以被行为者感受到的、系统的一个完整的功能。 在UML中把用例定义成系统完成的一系列动作，动作的结果能被特定的行为者察觉到。 这些动作除了完成系统内部的计算与工作外，还包括与一些行为者的通信。 用例通过关联与行为者连接，关联指出一个用例与哪些行为者交互，这种交互是双向的。 用例具有下述特征： 代表某些用户可见的功能，实现一个具体的用户目标； 总是被行为者启动的，并向行为者提供可识别的值； 必须是完整的。 3. 行为者 行为者是指与系统交互的人或其他系统，它代表外部实体。使用用例并且与系统交互的任何人或物都是行为者。 行为者代表一种角色，而不是某个具体的人或物。事实上，一个具体的人可以充当多种不同角色。 4. 用例之间的关系 扩展关系 向一个用例中添加一些动作后构成了另一个用例，这两个用例之间的关系就是扩展关系，后者继承前者的一些行为，通常把后者称为扩展用例。 使用关系 当一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般说来，如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例（称为抽象用例）。 一个用例模型由若干幅用例图组成。 创建用例模型的工作包括： 定义系统 寻找行为者和用例 描述用例 定义用例之间的关系 确认模型 其中，寻找行为者和用例是关键。 9.6.2 用例建模 1. 寻找行为者 获取用例首先要找出系统的行为者，可以通过请系统的用户回答一些问题的办法来发现行为者。 下述问题有助于发现行为者： 谁将使用系统的主要功能（主行为者）？ 谁需要借助系统的支持来完成日常工作？ 谁来维护和管理系统（副行为者）？ 系统控制哪些硬件设备？ 系统需要与哪些其他系统交互？ 哪些人或系统对本系统产生的结果（值）感兴趣？ 2. 寻找用例 一旦找到了行为者，就可以通过请每个行为者回答下述问题来获取用例： 行为者需要系统提供哪些功能？自身需要做什么？ 行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？ 系统中发生的事件需要通知行为者吗？行为者需要通知系统某些事情吗？从功能看，这些事件能做什么？ 行为者的日常工作是否