面向对象分析与设计.docxVIP

PAGE PAGE 10 第三章 UML 是一种建模语言，用于对软件系统制品进行规约。可视化 构造和文档化， 也可以用于业务建模以及其他非软件系统的建模。因此他只是一种建模语言，而不是一种建模方法 UML 用于建立系统的分析模型和设计模型，而不是用于编程 UML 的主题部分并不是一种形式化语言，它只是部分的采用了形式化语言的定义方式，而且也不是严格的形式化 第四章 抽象是面向对象方法中使用最为广泛的原则： 1：系统中的对象是对现实世界中事物的抽象 2：类是对象的抽象 3：一般类是对特殊类的抽象 4：属性是事物静态特征的抽象 5：操作是事物动态特征的抽象 粒度控制： 人在面对一个复杂的问题时，不可能在同一时刻纵观全局，又能洞察秋毫。因此需要控制自己的视野；考虑全局时，注重其大的组成部分；暂时不去详细考察每一部分的具体细节；考虑某个部分的细节时暂时撇开其余部分和宏观上的问题， 这就是粒度控制。 行为分析： 采用如下行为分析原则，以控制行为的复杂性： 以对象为单位描述系统中的各种行为； 通过消息描述对象之间的行为依赖关系 认识行为的起因，区分主动行为和被动行为认识系统的并发行为 用况图： 把用况、参与者以及它们之间的关系用一些图形符号进行可视化表示， 便得到用况图（use case diagram） 用况图是直接描述需求的，因此它是一个需求模型 模型图中表达不尽的信息，需要以文字和表格等方式做进一步描述，这就是模型规约。 OOA 与 OOD 的关系： 不同的目标、内容和抽象层次： 通过 OOA 和 OOD 所得到的系统模型分别成为 OOA 模型和 OOD 模型，它们都是对系统的抽象描述，但是属于不同的抽象层次。 OOA 的主要内容是研究问题域和系统责任，运用面向对象的观点发现问题域中与系统责任有关的对象，认识对象的内部特征和各类对象之间的关系，目标是建立一个直接映射问题域，符合用户需求的 OOA 模型。 OOD 的主要内容是以 OOA 为基础，针对选定的实现平台进行系统设计，目标是产生一个能够在选定的软硬件平台上实现的 OOD 模型。 系统的体系结构是对系统的部件和连接部件以及这些部件通过连接件进行交互的规约。 第五章 需求分析（requirements analysis）是软件工程中的经典术语之一，其确切含义应该是对用户需求进行分析，旨在产生一份明确、规范的需求定义。 无论是结构化方法中的数据流图还是面向对象方法中的类图，都不是直接描述用户需求，而是描述了一个满足用户需求的系统模型。确切的讲，这些工作应该叫做系统分析 系统边界（system border）是指系统内部的所有成分与系统以外各种事物之间的分界线。在系统边界以内，是系统本身包含的全部对象；在系统边界以外，是与系统进行信息交换的各种事物，即人员、设备和外系统等各种参与者。 系统成分是指在系统模型中给出定义并且在程序中加以实现的系统元素。 参与者（actor）是指在系统之外（透过系统边界）与系统进行交互的实际事物。发现参与者的基本思路是：分析用户所要求的每一项功能是由哪些人员、设备或外系统来使用的，或者说每一项功能的执行需要哪些人员、设备或外系统与系统进行信息交互。 所谓“外系统”包括当前系统的子系统、上级系统以及没有上下级关系但是与本系统交换信息的任何其他系统 用况是对参与者使用系统的一项功能时所进行的交互过程的描述，其中包含由双方交替执行的一系列动作。 这个定义包含了如下几个意思： 1：一个用况只描述参与者对单独一项系统功能的使用情况 2：早期文献中的用况是一种文字描述，不是程序。 3：用况陈述了参与者和系统在交互过程中双方所做的事 4：在所有的用况中，由参与者首先发起的对话最为常见，但有些对话也可能是由系统首先发起的 5：用况的典型做法是描述参与者和系统彼此为对方直接的做了些什么事，不描述怎么做，也不描述间接的做了什么 6：用况对参与者和系统双方行为的描述应力求准确、清晰。在不引起误解的前提下允许用简练的语言概括的说明每一方的行为，但这种概括的最大限度是，不要把双方的行为混在一起不分彼此。 7：一个用况所描述的功能可以分别由多种参与者使用 用况图： 参与者：用一个人体形状的符号表示，旁边注明参与者的名称。用况：用一个椭圆表示，在椭圆内或者它的旁边给出用况的名称 开发过程与建议： 基于用况的需求模型的开发包括以下活动： 1：确定系统边界 2：发现参与者 3：定义用况 4：建立用况之间的关系 5；确定参与者和用况之间的关系 6：绘制用