安徽工业大学uml系统建模与分析设计复习资料.doc

《论述》基于 UML 的软件开发的 一般过程
答：UML 是按 OO 思想进行系统建模时使用的一组表示法，它并不对采用何种 OO 分析、设计以及
开发过程模型构成限制。基于 UML 的软件开发通常是以体系结构为中心，用例驱动的迭代
和增量式开发，并结合职责分配模式进行具体设计。开发过程可以包括计划和细化、迭代
的构造和实施 3 大阶段。在经过一个初步的计划和细化阶段后，进入若干 迭代构造开发周
期，每个周期都包含分析、设计、构造和测试步骤。
（1）计划和细化：通过各种传统的需求获取手段（调查、访谈、原型等）得出 系统目标、
系统功能和系统属性，撰写系统规格说明。基于参与者和外部事件（动宾词组）构建用例，
以增 进对领域过程和功能需求的 理解《做什么》。按照风险 、业务主线及对体系结构的影
响程度（系统属性）划分用例的优先级，并据此决定用例的时间调度。对高优先 用例采用
扩展格式细化。同时建立概念模型草案、系统体系结构草案。
（2）分析阶段：根据当前周期的用例描述，采用概念目录列表、非正式分析或 事务模式，
识别出相关概念，建立初始概念模型，根据通用关联列表和信息存储的需要，为概念模型
添加关联和属性。将用例分解为系统事件，并对应系统操作，建立系统顺序图；分析系统
操作被调用后系统状态（概念）的变化，为系统操作建立契约，进一步理解系统行为《做
的效果》。
（3 ）设计阶段：设计一个合理的体系结构，建立真实用例 。针对每个系统操作，使用操
作契约和契约的后置条件以及用例描述文档作为起点，按照职责分配模式或 BCE 模式为
对象 （来自概念模型）分配职责 ，通过协作图体现对象间的 交互《怎么做》。同时参照概
念模型和协作图中的消息，建立设计类图，并根据可见性要求设计关联
（4）构造和测试阶段：从设计类图创建类的定义（属性和方法原型），根据协作 图创建方
法实现。用 OOPL 实现设计制品到代码的映射，对系统进行相关的测试。
进入下一个迭代周期，在制品同步以后，识别更多的需求，选取所需开发的用例，更新用例
图，扩展概念模型，并运用泛化、包和聚合等技术概括日益增多新概念，拓展系统顺序图和
系统操作契约；运用更多的职责分配模式进行设计（并根据需要设计与外部系统、其他子系
统、持久化设施的交互机制）；进一步构造并测试。
《论述》：
请谈一谈对 OOD 中“一个中心”：开闭原则（OCP），“两个基本点”：高聚，低耦 合，“四项基本原则”：
Liskov 替换原则（L SP）,依赖倒置原则（DIP）,接口分离 原则（ISP），单一职责原则(SRP）的理解
开闭原则（OCP）
OO 中最重要的设计原则,指一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的
低耦合度：是在设计过程要记住的一个原则，它是一个时刻需要注意的隐含设计目标。是一个检验标准。
高聚合度：确保将复杂性保持在可控制的围，也是一个检验标准。
Liskov 替换原则
子类可以替换父类出现在父类能出现的任何地方. 软件实体如果使用的是一个基类，那么一定适用于其子
类，而且它根本不能察觉出基类对象和子类对象的区别。
依赖倒置原则–依赖关系应该是尽量依赖接口（或抽象）类，而不是依赖于具体类. 即针对接口编程，不
要针对实现编程。
接口分离原则
一个类对另外一个类的依赖是建立在最小的接口上。设计时采用多个与特定客户类（Client）有关的接口比
采用一个通用接口更好.
单一职责原则:就一个类而言，应该有且仅有一个引起它变化的原因。
《论述》前 5 个常用 GRAS P 职责分配模式的名称、要点或意图
专 家(expert)：将职责 分配给信息专 家——掌握为 了履行职责所 必需的信息的 类（谁懂的 多
就让 谁干）
创建者(creator)：大的对 象有责任创建小的对象，这是 OOD/P 中最常见的任务。
高聚合度或高聚(high cohesion)：是一个检验标准，用于判断一个类中的各个职责之间相
关程度 和集中程度（可重用性的因）。
低 耦合度或低耦 合(low coupling)：是一 个检验标准， 用于判断类 间依赖程度 是否较小（可
重用性的外在表现）。
控制者(controller)：谁来统一协调 处理一个用例的各个系统事件，以使状态信息保持一致？
《论述》后 4 个常用 GRAS P 职责分配模式的名称、要点或意图
• 多态：当相关的可选择的方法或行为随着类型变化时，将行为的职责——使用多态(Polymorphism)的操作——
分配给那些行为变化的类型
• 纯虚构：给一个人造类分配一组