线性的。还没有办法用图来逼真地反映在面向对象开发过程中各个阶段之间的复杂交互。有 部分分析工作在设计之前实行,但有些分析工作与其它部分的设计与实现并行进行。 开发可复用的软件构件是软件开发 过程的一部分。面向对象方法以类作为信息系 客户输入 单元,并分别考虑类的生存期与应用生統描述 存期。类生存期可包含在图68中的类开 发阶段中,可与应用生存期集成 分析 应用 分析 (2)类生存期 高层 在面向对象软件开发过程中特别重 视复用。软件构件应独立于当初开发它 们的应用而存在。构件的开发瞄准某些 局部的设计和实现,它们可用于当前问 实例 开发 题的解决,但为了在以后的项目中使用, 组装 建立 它们还应当足够通用。在以后的应用开 发中,可以调整这些独立构件以适应新(维护 问题的需要。因此,应使得类成为一个 可复用的单元,图69提出了一个类生存 图6.8一个基于复用的应用生存期 期 类生存期与应用生存期交叉。在应用 生存期的每一个阶段都可做类的标识。类 类的规 格说明 生存期有自己的步骤,与任一特定应用的 从既存 开发无关。按照这些步骤,可以完整地描 从废弃 述一个基本实体。而不仅仅考虑当前正在 型开发 开发的系统。系统开发的各个阶段都可能 既存类 复用 渐增式 会标识新的类。随着各个新类的标识,类 生存期引导开发工作逐个阶段循序渐进。 实现 例如,在应用分析中已经标识了对 个图形显示设备的要求。如果这样一个图 测试用 形显示设备类不存在,就应着手开发。但 例和测试 是,用到显示器所有可能操作的应用寥寥 的开发 求精和 无几。若把这些操作的开发当做一个特定 维护 应用系统开发的一部分,那么只可能标识 图6.9类生存期 和实现该系统所要求的那些操作。但如果 考虑让构件独立于应用,就必须能够综合出超出当前系统需求的开发要求,生成一种能表示 成一个完全的概念的模型并可建立为以后其它系统复用的类 在纯面向对象的系统开发中,一个应用程序就“是”一个类。基本的类,像ist类,可 不涉及应用,但基本类的实例要聚合到其它类的定义中。这些类依次又聚合到更复杂的类定 义中,最终将会遇到一个类,它涉及整个应用 下面概括了类生存期各个阶段主要做的事情 ①类的规格说明:对每一个类都要开发它的规格说明,无论是在哪一个阶段标识的类 都是如此。类的规格说明定义了施加于对象的数据存储上的一组操作。这组操作应工作在封 装在对象内部的数据存储上,或返回关于对象状态的信息。操作的名字应能反映这个操作本 身的含义。类的规格说明必须足够完整,使得它能够与在类资源库中的那些可复用的类的规 格说明做比较
6 线性的。还没有办法用图来逼真地反映在面向对象开发过程中各个阶段之间的复杂交互。有 一部分分析工作在设计之前实行，但有些分析工作与其它部分的设计与实现并行进行。 开发可复用的软件构件是软件开发 过程的一部分。面向对象方法以类作为 单元，并分别考虑类的生存期与应用生 存期。类生存期可包含在图 6.8 中的类开 发阶段中，可与应用生存期集成。 (2) 类生存期 在面向对象软件开发过程中特别重 视复用。软件构件应独立于当初开发它 们的应用而存在。构件的开发瞄准某些 局部的设计和实现，它们可用于当前问 题的解决，但为了在以后的项目中使用， 它们还应当足够通用。在以后的应用开 发中，可以调整这些独立构件以适应新 问题的需要。因此，应使得类成为一个 可复用的单元，图 6.9 提出了一个类生存 期。 类生存期与应用生存期交叉。在应用 生存期的每一个阶段都可做类的标识。类 生存期有自己的步骤，与任一特定应用的 开发无关。按照这些步骤，可以完整地描 述一个基本实体。而不仅仅考虑当前正在 开发的系统。系统开发的各个阶段都可能 会标识新的类。随着各个新类的标识，类 生存期引导开发工作逐个阶段循序渐进。 例如，在应用分析中已经标识了对一 个图形显示设备的要求。如果这样一个图 形显示设备类不存在，就应着手开发。但 是，用到显示器所有可能操作的应用寥寥 无几。若把这些操作的开发当做一个特定 应用系统开发的一部分，那么只可能标识 和实现该系统所要求的那些操作。但如果 考虑让构件独立于应用，就必须能够综合出超出当前系统需求的开发要求，生成一种能表示 成一个完全的概念的模型并可建立为以后其它系统复用的类。 在纯面向对象的系统开发中，一个应用程序就“是”一个类。基本的类，像 list 类，可 不涉及应用，但基本类的实例要聚合到其它类的定义中。这些类依次又聚合到更复杂的类定 义中，最终将会遇到一个类，它涉及整个应用。 下面概括了类生存期各个阶段主要做的事情。 ① 类的规格说明 ：对每一个类都要开发它的规格说明，无论是在哪一个阶段标识的类 都是如此。类的规格说明定义了施加于对象的数据存储上的一组操作。这组操作应工作在封 装在对象内部的数据存储上，或返回关于对象状态的信息。操作的名字应能反映这个操作本 身的含义。类的规格说明必须足够完整，使得它能够与在类资源库中的那些可复用的类的规 格说明做比较。 图 6.8 一个基于复用的应用生存期 图 6.9 类生存期
②类的设计与实现:此时尽可能利用既存类提供为当前应用所需要的功能。图6.9给 出了利用既存类的三个途径: 原封不动地复用既存类。 对既存类进行演化以得到满足要求的类。演化可以是横向的,也可以是纵向的。横向 的演化生成既存类的一个新的版本,而纵向的演化将从既存类导出新类。 重新开始进行开发。 一个新的继承结构将建立两种类:一种是抽象类,它概括了将要表达的概念:另一种是 具体类,它要实现这个概念。 ③求精和维护:维护活动是针对应用系统的,但求精过程是针对类和结构的。因为我 们利用抽象进行开发,因此,维护活动每时每刻都可能修改这些抽象。随着经验的增长,还 可以标识抽象的抽象,使得继承结构通过一般化,增加新的层次。 为便于类的调整,应尽量做到定义与实现分离,实现概念封装和信息隐蔽,使得类具有 更大的独立性。在使用一个类或复用一个类时,类与类之间产生一种相互依赖关系。但对 个类的公有界面所做的多次修改不应影响使用它的那些类,在公有界面上增加新的操作不应 改变既存的软件。需要谨慎处理的是删除操作或改变操作的特征。 (3)面向对象软件的开发过程 面向对象软件的开发过程开始于问题论域,经历从问题提出到解决的一系列过程。下面 具体说明在过程中的这些步骤。 ①分析阶段:分析阶段包括两个步骤:论域分析和应用分析。它们都要标识问题论域 中的抽象。在分析中,需要找到特定对象,基于对象的公共特性把它们组合成集合,标识出 对这个问题的一个抽象。同时要标识抽象之间的关系,并建立对象之间的消息连接。 论域分析:论域分析开发问题论域的模型。论域分析应当在应用分析之前进行,我 们在了解问题之前应当对问题敞开思想考虑,考察问题论域内的一个较宽的范围,分析覆盖 的范围应比直接要解决的问题更多 应用分析:应用(或系统)分析细化在论域分析阶段所开发出来的信息,并且把注意 力集中于当前要解决的问题。因为通过论域分析,分析人员具有了较宽的论域知识,因而能 开发出更好的抽象 ②高层设计:在一个纯面向对象环境中,软件体系结构设计与类设计常常是同样的过 程,但还是应当把体系结构设计与类的设计分开。在高层设计阶段,设计应用系统的顶层视 图。这相当于开发一个代表系统的类,通过建立该类的一个实例并发送一个消息给它来完成 系统的“执行 ③类的开发:根据高层设计所标识的对各个类的要求和类的规格说明,进行类的开发 因为一个应用系统往往是一个类的继承层次。对这些类的开发是最基本的设计活动 ④实例的建立:建立各个对象的实例,实现问题的解决方案 ⑤组装测试:按照类与类之间的关系组装一个完整的应用系统的过程中进行的测试。 各个类的封装和类测试的完备性可减少组装测试所需要的时间 ⑥维护:维护的要求将影响应用和各个类。继承关系可支持对现有应用的扩充,或者 加入新的行为,或者改变某些行为的工作方式。 应用系统的维护:包括在系统的操作中定位故障、在既存的系统中加入新的行为 应用的维护能够简化对类实例的定位、修改其类的实现、通过改变消息或接收消息的次序来 改变应用中特殊对象的角色。新的行为可通过定义新的类和建立实例来实现。 类的维护:把类的实现与其规格说明分离可局部化修改的影响。一般情况下,修正 问题要求应尽可能不改变类的界面。然而,为了在系统中增加新的行为,偶尔会有改变界面 的需求
7 ② 类的设计与实现 ：此时尽可能利用既存类提供为当前应用所需要的功能。图 6.9 给 出了利用既存类的三个途径： ▪ 原封不动地复用既存类。 ▪ 对既存类进行演化以得到满足要求的类。演化可以是横向的，也可以是纵向的。横向 的演化生成既存类的一个新的版本，而纵向的演化将从既存类导出新类。 ▪ 重新开始进行开发。 一个新的继承结构将建立两种类：一种是抽象类，它概括了将要表达的概念；另一种是 具体类，它要实现这个概念。 ③ 求精和维护 ：维护活动是针对应用系统的，但求精过程是针对类和结构的。因为我 们利用抽象进行开发，因此，维护活动每时每刻都可能修改这些抽象。随着经验的增长，还 可以标识抽象的抽象，使得继承结构通过一般化，增加新的层次。 为便于类的调整，应尽量做到定义与实现分离，实现概念封装和信息隐蔽，使得类具有 更大的独立性。在使用一个类或复用一个类时，类与类之间产生一种相互依赖关系。但对一 个类的公有界面所做的多次修改不应影响使用它的那些类，在公有界面上增加新的操作不应 改变既存的软件。需要谨慎处理的是删除操作或改变操作的特征。 (3) 面向对象软件的开发过程 面向对象软件的开发过程开始于问题论域，经历从问题提出到解决的一系列过程。下面 具体说明在过程中的这些步骤。 ① 分析阶段 ：分析阶段包括两个步骤：论域分析和应用分析。它们都要标识问题论域 中的抽象。在分析中，需要找到特定对象，基于对象的公共特性把它们组合成集合，标识出 对这个问题的一个抽象。同时要标识抽象之间的关系，并建立对象之间的消息连接。 ▪ 论域分析 ：论域分析开发问题论域的模型。论域分析应当在应用分析之前进行，我 们在了解问题之前应当对问题敞开思想考虑，考察问题论域内的一个较宽的范围，分析覆盖 的范围应比直接要解决的问题更多。 ▪ 应用分析 ：应用(或系统)分析细化在论域分析阶段所开发出来的信息，并且把注意 力集中于当前要解决的问题。因为通过论域分析，分析人员具有了较宽的论域知识，因而能 开发出更好的抽象。 ② 高层设计 ：在一个纯面向对象环境中，软件体系结构设计与类设计常常是同样的过 程，但还是应当把体系结构设计与类的设计分开。在高层设计阶段，设计应用系统的顶层视 图。这相当于开发一个代表系统的类，通过建立该类的一个实例并发送一个消息给它来完成 系统的“执行”。 ③ 类的开发 ：根据高层设计所标识的对各个类的要求和类的规格说明，进行类的开发。 因为一个应用系统往往是一个类的继承层次。对这些类的开发是最基本的设计活动。 ④ 实例的建立：建立各个对象的实例，实现问题的解决方案。 ⑤ 组装测试：按照类与类之间的关系组装一个完整的应用系统的过程中进行的测试。 各个类的封装和类测试的完备性可减少组装测试所需要的时间。 ⑥ 维护：维护的要求将影响应用和各个类。继承关系可支持对现有应用的扩充，或者 加入新的行为，或者改变某些行为的工作方式。 ▪ 应用系统的维护 ：包括在系统的操作中定位故障、在既存的系统中加入新的行为。 应用的维护能够简化对类实例的定位、修改其类的实现、通过改变消息或接收消息的次序来 改变应用中特殊对象的角色。新的行为可通过定义新的类和建立实例来实现。 ▪ 类的维护 ：把类的实现与其规格说明分离可局部化修改的影响。一般情况下，修正 问题要求应尽可能不改变类的界面。然而，为了在系统中增加新的行为，偶尔会有改变界面 的需求
3.面向对象分析(OOA)与模型化 面向对象分析过程分为论域分析和应用分析。论域分析建立大致的系统实现环境,应用 分析则根据特定应用的需求进行论域分析 (1)OOA分析的基本原则和任务 为建立分析模型,要运用如下的5个基本原则:①建立信息域模型;②描述功能;③ 表达行为:④划分功能、数据、行为模型,揭示更多的细节:⑤用早期的模型描述问题的 实质,用后期的模型给出实现的细节。这些原则形成OOA的基础 OOA的目的是定义所有与待解决问题相关的类(包括类的操作和属性、类与类之间的关 系以及它们表现出的行为)。为此,OOA需完成的任务是: ①软件工程师和用户必须充分沟通,以了解基本的用户需求 ②必须标识类(即定义其属性和操作) ③必须定义类的层次 ④应当表达对象与对象之间的关系(即对象的连接): ⑤必须模型化对象的行为 ⑥反复地做任务①一⑤,直到模型建成 (2)OOA概述 目前已经衍生许多种OOA方法。每种方法都有各自的进行产品或系统分析的过程,有 一组可描述过程演进的图形标识,以及能使得软件工程师以一致的方式建立模型的符号体系。 现在广泛使用的OOA方法有以下几种: ① Booch方法:Boch方法包含“微开发过程”和“宏开发过程”。微开发过程定义 了一组任务,并在宏开发过程的每一步骤中反复使用它们,以维持演进途径。 Booch ooa宏 开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系,以及进 行一系列求精从而实现分析模型 ② Rumbaugh方法: Rumbaugh和他的同事提出的对象模型化技术(OMD用于分析 系统设计和对象级设计。分析活动建立三个模型:对象模型(描述对象、类、层次和关系), 动态模型(描述对象和系统的行为),功能模型(类似于高层的DFD,描述穿越系统的信息流)。 ③Coad和 Yourdon方法:Coad和 Yourdon方法常常被认为是最容易学习的OOA 方法。建模符号相当简单,而且开发分析模型的导引直接明了。其OOA过程概述如下: 使用“要找什么”准则标识对象 定义对象之间的一般化/特殊化结构 定义对象之间的整体/部分结构 标识主题(系统构件的表示) 定义属性及对象之间的实例连接 定义服务及对象之间的消息连接 ④ Jacobson方法:也称为OOSE(面向对象软件工程)。 Jacobson方法与其它方法的不 同之处在于他特别强调使用实例( use case)—一用以描述用户与系统之间如何交互的场景。 Jacobson方法概述如下: 标识系统的用户和它们的整体责任 通过定义参与者及其职责、使用实例、对象和关系的初步视图,建立需求模型; 通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子 系统和模型,建立分析模型。 ⑤wirs- Brock方法: Wires-Brok方法不明确区分分析和设计任务。从评估客户规 格说明到设计完成,是一个连续的过程。与Wirs- Brock分析有关的任务概述如下:
8 3. 面向对象分析(OOA)与模型化 面向对象分析过程分为论域分析和应用分析。论域分析建立大致的系统实现环境，应用 分析则根据特定应用的需求进行论域分析。 (1) OOA 分析的基本原则和任务 为建立分析模型，要运用如下的 5 个基本原则：① 建立信息域模型；② 描述功能；③ 表达行为；④ 划分功能、数据、行为模型，揭示更多的细节；⑤ 用早期的模型描述问题的 实质，用后期的模型给出实现的细节。这些原则形成 OOA 的基础。 OOA 的目的是定义所有与待解决问题相关的类(包括类的操作和属性、类与类之间的关 系以及它们表现出的行为)。为此，OOA 需完成的任务是： ① 软件工程师和用户必须充分沟通，以了解基本的用户需求； ② 必须标识类(即定义其属性和操作)； ③ 必须定义类的层次； ④ 应当表达对象与对象之间的关系(即对象的连接)； ⑤ 必须模型化对象的行为； ⑥ 反复地做任务①―⑤，直到模型建成。 (2) OOA 概述 目前已经衍生许多种 OOA 方法。每种方法都有各自的进行产品或系统分析的过程，有 一组可描述过程演进的图形标识，以及能使得软件工程师以一致的方式建立模型的符号体系。 现在广泛使用的 OOA 方法有以下几种： ① Booch 方法 ：Booch 方法包含“微开发过程”和“宏开发过程”。微开发过程定义 了一组任务，并在宏开发过程的每一步骤中反复使用它们，以维持演进途径。Booch OOA 宏 开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系，以及进 行一系列求精从而实现分析模型。 ② Rumbaugh 方法 ：Rumbaugh 和他的同事提出的对象模型化技术(OMT)用于分析、 系统设计和对象级设计。分析活动建立三个模型：对象模型(描述对象、类、层次和关系)， 动态模型(描述对象和系统的行为)，功能模型(类似于高层的 DFD，描述穿越系统的信息流)。 ③ Coad 和 Yourdon 方法 ：Coad 和 Yourdong 方法常常被认为是最容易学习的 OOA 方法。建模符号相当简单，而且开发分析模型的导引直接明了。其 OOA 过程概述如下： ▪ 使用“要找什么”准则标识对象； ▪ 定义对象之间的一般化∕特殊化结构； ▪ 定义对象之间的整体∕部分结构； ▪ 标识主题(系统构件的表示)； ▪ 定义属性及对象之间的实例连接； ▪ 定义服务及对象之间的消息连接。 ④ Jacobson 方法 ：也称为 OOSE(面向对象软件工程)。Jacobson 方法与其它方法的不 同之处在于他特别强调使用实例(use case)——用以描述用户与系统之间如何交互的场景。 Jacobson 方法概述如下： ▪ 标识系统的用户和它们的整体责任； ▪ 通过定义参与者及其职责、使用实例、对象和关系的初步视图，建立需求模型； ▪ 通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子 系统和模型，建立分析模型。 ⑤ Wirfs―Brock 方法 ：Wirfs―Brock 方法不明确区分分析和设计任务。从评估客户规 格说明到设计完成，是一个连续的过程。与 Wirfs―Brock 分析有关的任务概述如下：
评估客户规格说明: 使用语法分析从规格说明中提取候选类; 将类分组以表示超类 定义每一个类的职责 将职责赋予每个类 标识类之间的关系 基于职责定义类之间的协作; 建立类的层次表示 构造系统的协作图 ⑥统一的OOA方法(UML) 统一的建模语言(UM)已经在企业中广泛使用,它把 Booch、 Rumbaugh和 Jacobson等 各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。UML允许软件工程 师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。 在UML中用5种不同的视图来表示一个系统,这些视图从不同的侧面描述系统。每一 个视图由一组图形来定义。这些视图概述如下: 用户模型视图:这个视图从用户(在UML中叫做参与者)角度来表示系统。它用使用 实例( use case)来建立模型,并用它来描述来自终端用户方面的可用的场景。 ■结构模型视图:从系统内部来看数据和功能性。即对静态结构(类、对象和关系)模 型化 行为模型视图:这种视图表示了系统动态和行为。它还描述了在用户模型视图和结 构模型视图中所描述的各种结构元素之间的交互和协作。 实现模型视图:将系统的结构和行为表达成为易于转换为实现的方式 环境模型视图:表示系统实现环境的结构和行为。 通常,UML分析建模的注意力放在系统的用户模型和结构模型视图,而UML设计建模 则定位在行为模型、实现模型和环境模型。 (3)论域分析( Domain Analysis) 论域分析是基于特定应用论域,标识、分析、定义可复用于应用论域内多个项目的公共 需求的技术。它的目标是发现和创建一组应用广泛的类,这组类常常超出特定应用的范围, 可以复用于其它系统的开发。 论域分析可以被视为软件过程的一种保护伞活动,是与任一软件项目都没有牵连的软件 工程活动。论域分析员的工作是设计和建造可复用的构件,供许多工作在类似的但不一定相 同的应用项目中的人员使用 论域分析过程的关键输入/输出参看图6.10。主要的过程活动有: 技术文化 领域知识源 现有 查 论域 分析 论域分析模型 当前/未来需求 6.0论域分析的输入/输出 ①定义要研究的论域:分析员首先隔离感兴趣的业务论域、系统类型或产品分类,再 抽取OO项和非OO项。其中,OO项包括既存应用的类的规格说明、设计和代码;支持类 (GUI类或数据库存取类);与论域相关的市售构件库:测试用例等。非OO项包括方针、步
9 ▪ 评估客户规格说明； ▪ 使用语法分析从规格说明中提取候选类； ▪ 将类分组以表示超类； ▪ 定义每一个类的职责； ▪ 将职责赋予每个类； ▪ 标识类之间的关系； ▪ 基于职责定义类之间的协作； ▪ 建立类的层次表示； ▪ 构造系统的协作图。 ⑥ 统一的 OOA 方法(UML) 统一的建模语言(UML)已经在企业中广泛使用，它把 Booch、Rumbaugh 和 Jacobson 等 各自独立的 OOA 和 OOD 方法中最优秀的特色组合成一个统一的方法。UML 允许软件工程 师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。 在 UML 中用 5 种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。每一 个视图由一组图形来定义。这些视图概述如下： ▪ 用户模型视图 ：这个视图从用户(在 UML 中叫做参与者)角度来表示系统。它用使用 实例(use case)来建立模型，并用它来描述来自终端用户方面的可用的场景。 ▪ 结构模型视图 ：从系统内部来看数据和功能性。即对静态结构(类、对象和关系)模 型化。 ▪ 行为模型视图 ：这种视图表示了系统动态和行为。它还描述了在用户模型视图和结 构模型视图中所描述的各种结构元素之间的交互和协作。 ▪ 实现模型视图 ：将系统的结构和行为表达成为易于转换为实现的方式。 ▪ 环境模型视图 ：表示系统实现环境的结构和行为。 通常，UML 分析建模的注意力放在系统的用户模型和结构模型视图，而 UML 设计建模 则定位在行为模型、实现模型和环境模型。 (3) 论域分析(Domain Analysis) 论域分析是基于特定应用论域，标识、分析、定义可复用于应用论域内多个项目的公共 需求的技术。它的目标是发现和创建一组应用广泛的类，这组类常常超出特定应用的范围， 可以复用于其它系统的开发。 论域分析可以被视为软件过程的一种保护伞活动，是与任一软件项目都没有牵连的软件 工程活动。论域分析员的工作是设计和建造可复用的构件，供许多工作在类似的但不一定相 同的应用项目中的人员使用。 论域分析过程的关键输入∕输出参看图 6.10。主要的过程活动有： 图 6.10 论域分析的输入∕输出 ① 定义要研究的论域 ：分析员首先隔离感兴趣的业务论域、系统类型或产品分类，再 抽取 OO 项和非 OO 项。其中，OO 项包括既存应用的类的规格说明、设计和代码；支持类 (GUI 类或数据库存取类)；与论域相关的市售构件库；测试用例等。非 OO 项包括方针、步 领 域 知 识 源 论 域 分 析 模 型 论 域 分 析 技术文化 现有应用 客户调查 专家建议 当前∕未来需求 类的分类法 复用标准 功能模型 论域语言
骤、计划、标准和指南:既存的非OO应用的规格说明、设计和测试信息;度量、市售非OO 软件等。 ②分类从论域抽取的项:对所有的项进行归类并定义各个种类的一般定义特征。提出 种类的分类模式并定义每个项的命名惯例。适当的时候建立分类的层次。 ③收集论域中各个应用的有代表性的样例:为了完成这个活动,必须保证在问题中的 应用具有适合已定义的某些种类的项。 ④分析样例中的每一个应用:分析员接下来要做的事情是 标识候选的可复用的对象 指明标识对象为可复用的理由 定义可复用对象的适合性 估计在论域中可做到对象复用的应用的百分比 用名字标识对象并使用配置管理技术控制它们。一旦标识了对象,分析员应当估计 个典型的应用能够使用可复用对象构造的百分比。 此外,论域分析员还应建立一组复用指南,并给出一个例子,说明如何使用论域对象来 建立新的应用 总之,论域分析实际上是一种学习,涉及与应用论域有关的所有知识。论域的边界可能 很模糊,很多是凭借经验和实际考虑(如可用资源)。主要思想是想把考虑的论域放宽一些 把相关的概念都标识到,以帮助更好地掌握应用的核心知识。当用户改变他们对系统的需求 寸,范围广泛的分析可以帮助预测这些变化。 (4)应用分析 应用分析的依据是在论域分析时建立起来的论域分析模型,并把它用于当前正在建立的 应用当中。客户对系统的需求可以当做限制来使用,用它们缩减论域的信息量。就这一点来 说,保留的信息受到论域分析视野的影响。论域分析产生的模型并不需要用任何基于计算机 系统的程序设计语言来表示,而应用分析阶段产生影响的条件则伴随着某种基于计算机系统 的程序设计语言的表示。响应时间需求、用户界面需求和某些特殊的需求,如数据安全等 都在这一层分解抽出。 许多模型识别的要求是针对不止一个应用的。通常我们着重考虑两个方面:应用视图和 类视图。必须对每个类的规格说明和操作详细化,还必须对形成应用结构的类之间的相互作 用加以表示。 4.面向对象设计(OOD) OOA和OOD之间有密切的衔接关系,从OOA到OOD是一个逐渐扩充模型的过程。 分析处理以问题为中心,可以不考虑任何与特定计算机有关的问题,而OOD则把我们带进 了面向计算机的“实地”开发活动中去。通常,OOD分为两个阶段,即高层设计和低层设计 高层设计建立应用的体系结构。低层设计集中于类的详细设计。 (1)高层设计 高层设计阶段开发软件的体系结构,构造软件的总体模型。在这个阶段,标识在计算机 环境中进行问题解决工作所需要的概念,并增加了一批需要的类。这些类包括那些可使应用 软件与系统的外部世界交互的类。此阶段的输出是适合应用软件要求的类、类间的关系、应 用的子系统视图规格说明。通常,利用面向对象设计得到的系统框架如图6.11所示。 ①高层设计模型 个典型的高层设计模型即客户一服务器模型,它构造起应用软件的总体模型,这个模 型导出的体系结构既可在过程性系统中使用,又可在面向对象的系统中使用 客户一服务器模型的想法是让系统的一个部分(服务器子系统)提供一组服务给系统的
10 骤、计划、标准和指南；既存的非 OO 应用的规格说明、设计和测试信息；度量、市售非 OO 软件等。 ② 分类从论域抽取的项 ：对所有的项进行归类并定义各个种类的一般定义特征。提出 种类的分类模式并定义每个项的命名惯例。适当的时候建立分类的层次。 ③ 收集论域中各个应用的有代表性的样例 ：为了完成这个活动，必须保证在问题中的 应用具有适合已定义的某些种类的项。 ④ 分析样例中的每一个应用 ：分析员接下来要做的事情是： ▪ 标识候选的可复用的对象； ▪ 指明标识对象为可复用的理由； ▪ 定义可复用对象的适合性； ▪ 估计在论域中可做到对象复用的应用的百分比； ▪ 用名字标识对象并使用配置管理技术控制它们。一旦标识了对象，分析员应当估计一 个典型的应用能够使用可复用对象构造的百分比。 此外，论域分析员还应建立一组复用指南，并给出一个例子，说明如何使用论域对象来 建立新的应用。 总之，论域分析实际上是一种学习，涉及与应用论域有关的所有知识。论域的边界可能 很模糊，很多是凭借经验和实际考虑(如可用资源)。主要思想是想把考虑的论域放宽一些， 把相关的概念都标识到，以帮助更好地掌握应用的核心知识。当用户改变他们对系统的需求 时，范围广泛的分析可以帮助预测这些变化。 (4) 应用分析 应用分析的依据是在论域分析时建立起来的论域分析模型，并把它用于当前正在建立的 应用当中。客户对系统的需求可以当做限制来使用，用它们缩减论域的信息量。就这一点来 说，保留的信息受到论域分析视野的影响。论域分析产生的模型并不需要用任何基于计算机 系统的程序设计语言来表示，而应用分析阶段产生影响的条件则伴随着某种基于计算机系统 的程序设计语言的表示。响应时间需求、用户界面需求和某些特殊的需求，如数据安全等， 都在这一层分解抽出。 许多模型识别的要求是针对不止一个应用的。通常我们着重考虑两个方面：应用视图和 类视图。必须对每个类的规格说明和操作详细化，还必须对形成应用结构的类之间的相互作 用加以表示。 4. 面向对象设计（OOD） OOA 和 OOD 之间有密切的衔接关系，从 OOA 到 OOD 是一个逐渐扩充模型的过程。 分析处理以问题为中心，可以不考虑任何与特定计算机有关的问题，而 OOD 则把我们带进 了面向计算机的“实地”开发活动中去。通常，OOD 分为两个阶段，即高层设计和低层设计。 高层设计建立应用的体系结构。低层设计集中于类的详细设计。 (1) 高层设计 高层设计阶段开发软件的体系结构，构造软件的总体模型。在这个阶段，标识在计算机 环境中进行问题解决工作所需要的概念，并增加了一批需要的类。这些类包括那些可使应用 软件与系统的外部世界交互的类。此阶段的输出是适合应用软件要求的类、类间的关系、应 用的子系统视图规格说明。通常，利用面向对象设计得到的系统框架如图 6.11 所示。 ① 高层设计模型 一个典型的高层设计模型即客户－服务器模型，它构造起应用软件的总体模型，这个模 型导出的体系结构既可在过程性系统中使用，又可在面向对象的系统中使用。 客户－服务器模型的想法是让系统的一个部分(服务器子系统)提供一组服务给系统的