面向对象分析模型总结

《面向对象分析模型总结》由会员分享，可在线阅读，更多相关《面向对象分析模型总结（120页珍藏版）》请在金锄头文库上搜索。

1、1OOA&D方法总结2面向对象的概念包括以下两种情况： （1）用来构成系统模型的某种基本成分，称为建模元素 （2）在建模中需要遵守的某种原则，不代表任何模型成分主要概念主要建模元素 对象、类（所有的对象都通过类来表示） 属性、操作（类属性和实例属性，被动操作和主动操作） 一般-特殊关系，一般-特殊结构 整体-部分关系，整体-部分结构 关联 （二元关联、多元关联） 消息 （控制流内部的消息，控制流之间的消息）3主要原则（1）抽象 什么叫抽象？ OO方法广泛地运用抽象原则，例如： 系统中的对象是对现实世界中事物的抽象， 类是对象的抽象， 一般类是对特殊类的进一步抽象， 属性是事物静态特征的抽象，

2、操作是事物动态特征的抽象。 过程抽象 任何一个完成确定功能的操作序列，其使用者都 可把它看作一个单一的实体，尽管实际上它可能 是由一系列更低级的操作完成的。 数据抽象 根据施加于数据之上的操作来定义数据类型，并 限定数据的值只能由这些操作来修改和观察。4（2）分类 分类就是把具有相同属性和操作的对象划分为一类， 用类作为这些对象的抽象描述。 不同程度的抽象可得到不同层次的类，形成一般-特殊 结构（又称分类结构）。 强调：在类的抽象层次上建模（3）封装 （4）继承 （5）聚合 （6）关联（7）消息通信 即要求对象之间只能通过消息进行通讯，而不允许在 对象之外直接地存取对象内部的属性。5（8）粒度

3、控制人们在研究问题时既需要微观的思考，也需要宏观的思 考。因此需要控制自己的视野：考虑全局时，注重其大 的组成部分，暂时不详察每一部分的具体的细节；考虑 某部分的细节时则暂时撇开其余的部分。这就是粒度控 制原则。引入包（package）的概念，把模型中的类按一定的规则 进行组合，形成一些包，使模型具有大小不同的粒度层 次，从而有利于人们对复杂性的控制。6（9）行为分析以对象为单位描述系统中的各种行为 任何行为都归属于某个对象，用对象的操作表示。 对象的操作只作用于对象自身的属性。 通过消息描述对象之间的行为依赖关系 如果一个对象操作的执行需要另一个对象为它提供 服务，则在模型中表现为前者向后者

4、发送消息。 认识行为的起因，区分主动行为和被动行为 用主动对象的主动操作描述主动行为 用对象的被动操作描述被动行为 认识系统的并发行为 在分析阶段根据，根据系统的需求和事物的主动性 来认识系统的并发行为。在设计阶段，根据具体的 实现条件确定系统中需要设计哪些控制流。 7模型及其规约在分析阶段和设计阶段建立的系统模型分别称为OOA模型 和OOD模型 正规理解：一个系统模型，应包括建模过程中产生的图形 、文字等各种形式的文档。因为，所谓“模型”是指某一级别 上的系统抽象描述，构成这种描述的任何资料都是模型的 一部分。习惯说法：目前大部分OOA/OOD著作谈到“模型”，一般是 指OOA或OOD过程中

5、产生的图形文档。一般习惯将模型和模型规约分别讨论OOA和OOD模型包括需求模型、基本模型和辅助模型，通 过模型规约 做详细说明8基本模型类图 面向对象的建模中最重要、最基本的模型图 集中而完整地体现了面向对象的概念 为面向对象的编程提供了直接、可靠的依据 可以从三个层次来看 对象层特征层关系层需求模型用况图 每个用况是一项系统功能使用情况的 说明，把每一类参与者对每一项系统 功能的使用情况确切地描述出来，便 全面地定义了系统的功能需求 辅助模型其他各种图 对类图起到辅助作用，提供更详细的建模信息，或者从不 同的视角来描述系统。例如包图、顺序图、活动图等模型规约 对上述各种模型图及其模型元素的详

6、细而确切的定义和 解释。 9OOA模型框架基本模型：类图模 型 规 约需求模型：用况图辅助模型：包图顺序图活动图 对象层特征层关系层10OOD模型框架 从两个侧面来描述人机交互部分数据接口部分控制驱动部分问题域 部分从一个侧面看： OOD模型包括几个主要部分？ 一个核心加三个外围需 求 模 型辅 助 模 型类 图模型规约从另一侧面看： OOD模型每个部分 如何用OO概念表达？ 采用与OOA相同的概念及 模型组织方式11确定系统边界发现参与者定义用况发现对象定义对象 的特征定义对象 间的关系原型开发建立模型规约建立需求模型建立基本模型建立 包图建立辅助模型建立 活动图建立 其他图建立 顺序图建模

7、过程OOA 过程12问题域部分设计输入OOA模型人机交互部分设计控制驱动部分设计数据接口部分设计构件化与系统部署向OOP输出OOD模型OOD 过程13OOA与OOD的关系一致的概念与表示法 OOA和OOD采用一致的概念和表示法，从而不存在分析与 设计之间的鸿沟。不同的内容、目标和抽象层次OOA：研究问题域和用户需求，运用面向对象的观点发现 问题域中与系统责任有关的对象，以及对象的特征和相互 关系。目标是建立一个直接映射问题域，符合用户需求的 OOA模型。OOD：在OOA模型基础上，针对选定的实现平台进行系统 设计，按照实现的要求进行具体的设计，目标是产生一个 能够在选定的软硬件平台上实现的OO

8、D模型。OOA模型：抽象层次较高，忽略了与实现有关的因素 OOD模型：抽象层次较低，包含了与实现平台有关的细节 14在软件生存周期中的位置 可适应不同的生存周期模型分析 (OOA)设计 (OOD)编程 (OOP)测试维护瀑布模型强调严格的阶段 划分和前后次序先做完OOA再进行 OOD演化集成测试编程 (OOP)设计 (OOD)分析 (OOA)喷泉模型各个阶段之间没有 严格的界限，其活 动可以交叠和回溯有些工作既可在 OOA中进行，也可 在OOD中进行 各阶段概念和表示 法的一致为采用这 种模型提供了条件15OOA与OOD的分工两种不同的观点第二种观点的理由：（1）过分强调“分析不考虑怎么做”

9、将使某些必须在OOA考虑的问题得不到完 整的认识。 （2）把仅与问题域和系统责任有关的对 象的描述在分析阶段一次完成，避免设 计阶段重复地认识同一事物，减少了工 作量总和。 （3）对那些与问题域和系统责任紧密相 关的对象细节，分析人员比设计人员更 有发言权。 （4）由于OOA和OOD概念和表示法的一致 ，不存在把细化工作留给设计人员的必 然理由。 （5）OOA阶段建立平台无关的模型（PIM ），OOD阶段针对不同的平台建立平台专 用模型（PSM）可在最大程度上实现对 OOA结果的复用。关键问题：对象的特征细节（如属 性的数据类型和操作流程图），是 在分析时定义还是在设计时定义？做 什 么怎 么

10、 做分析设计第 一 种 观 点问题域与 系统责任与实现有 关的因素分 析设 计第二种观点16从MDA看OOA与OOD的关系模型驱动的体系结构（model-driven architecture，MDA ） 是OMG的一个技术规范，是一种加强模型能力的系统开 发途径。 模型驱动（ model-driven ）：用模型来对系统的理解、设 计、构造、部署、操作、维护和更改进行指导。 体系结构（ architecture ）：是对系统的部件和连接件以及 这些部件通过连接件进行交互的规约。 平台（platform）：是一组子系统和技术，它通过一些接口 和专用规则提供了一个连贯的功能集合，任何由该平台支持

11、 的应用都可以使用平台所提供的功能而不必关心其实现细 节。 平台无关模型（platform independence model，PIM）： 独立于任何一种平台特征的模型。 平台专用模型（platform specific model，PSM）：与特定 类型的平台特征有关的模型。17模型转换（model transformation）：由系统的一个模型转化 成同一个系统的另外一个模型。它是MDA最为关键的部分，其 核心问题是从PIM转换到PSM 。 MDA提倡：在系统开发中首先建立平台无关模型（PIM）， 然后将它转换为平台专用模型（PSM）技术18把MDA的观点运用于OOA和OODOOA：只

12、针对问题域和系统责任，不涉及实现条件 因此可得到一个平台无关的OOA模型OOD：在OOA模型基础上针对特定实现条件进行设计 转换成一个平台专用的OOD模型好处：使整个OOA模型可以在针对不同的实现平台的设 计中得到复用 19需求模型用况图需求分析和系统分析需求分析的确切含义是对用户需求进行分析，旨在产生一份明确、规范的需求定 义。OOA的主要内容是研究问题域中与需求有关的事物，把它们抽象为系统中的对象 ，建立类图。确切地讲，这些工作应该叫做系统分析，而不是严格意义上的需求 分析。早期的OOA缺乏一个良好的基础对需求的规范描述。需求说明需求分析健壮分析需求模型分析模型分析过程Jacobson方法

13、（OOSE）提出用况（use case）概念，解决了对需求的描述 问题，其分析过程如下：20问题域（抽象的来源）OOA模型 （类图）抽象OOA是将问题域中的事物抽象为系统中的对象系统责任（抽象的目标）抽象的目标是系统责任需求用况的概念解决了对需求的描述问题需求模型 （用况图）21基本思路问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？ 如何规范地定义用户需求？考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么 作用，描述其外部可见的行为。系统是由一条 边界包围起来 的未知空间只通过有限 的几个接口 与外部交互系统边界以外 是与系统进行 交互的参与者把内外交互情况描

14、 述清楚，就确切地 定义了系统的需求22系统边界系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界 线。 系统：被开发的计算机软硬件系统，不是指现实系统。 系统成分：在OOA和OOD中定义并且在编程时加以实现的系统元素 对象对 象对象对象对象对象对象参与者(人员)参与者(设备)参与者(外系统)参与者：在系统边 界以外，与系统进 行交互的事物 人员、设备、外系 统系统边界与参与者23现实世界中的事物与系统之间的关系分四种情况（1）被抽象为系统中的对象汽车飞机奖杯钟表起重机职员楼房天平（2）只作为系统外部的参与者与系统交互（4）与系统无关操作员（3）既是系统中的对象，本身又作为参与者与

15、系统交互24人员 系统的直接使用者 直接为系统服务的人员 设备 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 计算机设备 外系统 上级系统 子系统 其它系统如何发现参与者 考虑人员、设备、外系统25什么是用况 I. Jacobson： 用况是通过使用系统功能的某些部分而使用系统的一种具体方式。每个 用况包括一个由参与者发动的完整的事件过程。它详细说明了参与者和 系统之间发生的交互。因此，一个用况是一个由参与者和系统在一次对 话中执行的特定的相关事务序列。全部用况的集合则说明了所有可能存 在的系统使用方式。 对象技术词典： 1对一个系统或者一个应用的一种单一的使用方

16、式所进行的描述。 2关于单个参与者在与系统的对话中所执行的处理的行为陈述序列。 UML： 对系统在与它的参与者交互时所能执行的一组动作序列（包括其变体） 的描述。？本书的定义： 用况是对参与者使用系统的一项功能时所进行的交互过程的描述，其中包含由 双方交替执行的一系列动作。用况（use case）26术语“use case”的准确含义使用情况 是对一项系统功能使用情况的一般描述，它对于每一次使用都普遍适应，既不 是应用实例，也不是举例说明。几点说明：（1）一个用况只描述参与者对单独一项系统功能的使用情况；（2）通常是平铺直叙的文字描述，UML也允许其他描述方式；（3）陈述参与者和系统在交互过程中双方所做的事；（4）所描述的交互既可能由参与者发起也可能由系统发起 ；（5）描述彼此为对方直接地做什么事，不描述怎么做；（6）描述应力求准确，允许概括，但不要把双方的行为混在一起；（7）一个用况可以由多种参与者分别参