面向对象分析和设计第七章.pptVIP

# 面向对象分析与设计 第七章 系统分析 7.1、分析过程概述 在Ripple中，在客户满意之前，分析需要重复经历如下步骤： 1. 使用系统需求模型查找候选的类，以描述与系统相关的对象，并在类图上建立它们 2.确定类之间的关系（关联、聚合、组合、继承） 3.确定类的属性（对象的已指定的简单特性） 4.确定类的操作，检查系统用例，确定已有的对象支持它们，在检查过程中微调类、属性和关系，这个用例的实现过程将生成一些操作。 7.2、静态分析 静态建模设计确定系统的逻辑或物理部分，以及如何把它们连接在一起。也就是说，它描述了如何构建和初始化系统。 7.2.1 确定类 以系统用例的形式获得好的候选类，候选类常常在用例中用名词来表示，只要稍微实践一下，就可以快速删除表示下述含义的名词: (1)系统本身 (2)参与者 (3)边界 (4)小类型（字符串或数字） 7.2.1 确定类 7.2.2 正确运用抽象原则 在OOA中正确运用抽象原则 首先要舍弃哪些与系统责任无关的事物，只注意与系统责任有关的事物。 其次，对于与系统责任有关的事物，也不是把它们的任何特征都在相应的对象中表达出来，而要舍弃哪些与系统责任无关的特征。 如何判断事物是否与系统责任有关呢？一是该事物是否为系统提供一些有用的信息，或者它是否需要系统为它保存和管理某些信息。二是它是否向系统提供某些服务，或者，它是否需要系统描述它的某些行为。 7.2.3发现类的策略 1、考虑问题域 2、考虑系统边界 3、考虑系统责任 7.2.4审查和筛选 找到了候选类后，要对它们逐个进行审查，看看它们是不是OOA模型真正需要的，从而筛选掉一些对象。 1、舍弃无用对象 对于每个候选对象，要判断它在系统中是否真正有用，判断的标准是它们是否提供了有用的属性和服务 A.通过属性判断 B.通过服务判断 7.2.4审查和筛选 对象精简 如果系统中的对象的种类及数量过多，则将增加系统的复杂性，应该考虑是否能精简。重点审查 1、只有一个属性的对象 如果对象只有一个属性，应考虑它是被那些对象引用，看看能否合并到这些对象中去。 2、只有一个服务的对象 如果一个对象只有一个服务，没有属性，并且系统中只有一个类的对象请求这个服务，可以考虑将其合并到它的请求者对象中。 异常情况的检查和调整 1、类的属性或服务不适合该类的全部对象 2、属性及服务相同的类 3、属性和服务相似的类 4、对同一事物的重复描述 7.3标识类的关系 一旦有了候选类列表，就可以绘制出它们之间的关系。有四种类型的关系： 继承：子类继承了超类的所有属性和行为 关联：一种类型的对象与另一种类型的对象关联 聚合：强关联，一个类的实例由另一个类的实例构成。 组合：强聚合，组合的对象不能由其它对象共享，且与构成它的对象一起消亡。 7.3标识类的关系 继承与其它三种关系不同：继承描述了类在编译期间的关系，而其它三种关系描述了对象在运行期间的连接关系。根据UML标准，所有运行期间的关系都可以使用同一的术语关联association 但是大多数人把关联看作：既不是聚合也不是复合的关联关系 在关系之间选择时是很困难的，需要使用直觉、经验和推测。在分析过程中这些关系出现的频率。 关联 聚合 继承 组合 就涉及和实现而言，关联、聚合、组合之间的区别很难界定 7.4标识类的属性 属性是对象的一个特性，例如对象的大小、位置、名称、价格、颜色等。在UML中每个属性都可以指定一个类型，指定的这个类型可以使类或原型。（在分析阶段也可不指定类型，对提交的、或在设计阶段必须指定一个类型） 属性是描述对象静态特征的一个数据项。 服务是描述对象动态特征的一个操作序列。 属性的命名必须规范。 7.4.1发现属性的策略 针对每个对象提出并回答以下问题，从而启发自己从各种角度去发现对象的属性： 1、按一般常识这个对象应该有哪些属性 对象的某些属性，按一般常识就可以知道，例如人的姓名、职业、地址、电话等属性，但要注意，按照一般常识发现的属性未必都有用应该在审查时去掉。 2、在当前的问题域中，这个对象应该有哪些属性 对象的某些属性，只有认真研究问题域才能得到 例如商品的条形码。 7.4.1发现属性的策略 3、根据系统责任的要求，这个对象应具有哪些属性 4、建立这个对象是为了保存和管理哪些信息 5、对象为了在服务中实现其功能，需要增设哪些属性 6、对象有哪些需要区别的状态，是否增加一个属性来区别这些状态 7、用什么属性来表示整体-部分结构和实例连接 7.4.2审查和筛选 对于初步发现的属性，要进行审查和筛选。为此对每个属性提以下问题： 1、这个属性是否体现了以系统责任 该属性是否提供了系统用的着的信息，OOA应该只注意与系统责任有关的特征 2、这个属性是不是描述这个对象本身的特征