UML及对象开发方法介绍.doc

_ 精品资料 目目 录录 1引言引言-1 1.1目的目的-1 1.2使用使用对对象象-1 1.3使用使用说说明明-1 2快速入快速入门门-2 2.1总览总览-2 2.2UML 核心概念核心概念 -2 3知知识识介介绍绍-3 3.1UML 基基础础知知识识 -3 3.1.1UML 对提供软件质量有什么帮助？ -3 3.1.2UML 可以应用在哪些不同类型的系统？ -4 3.1.3UML 有哪些公共机制？ -4 3.1.4UML 类图分析 -4 3.1.5UML 状态图分析 -6 3.1.6UML 序列图分析 -7 3.1.7UML 活动图分析 -7 3.1.8UML 组合结构图分析 -8 3.1.9UML 组件图分析 -9 3.1.10UML 部署图分析 -9 3.1.11UML 用例图分析-10 3.2嵌入式嵌入式对对象开象开发发 -11 3.2.1软件开发的主要活动及其各个角色所起的作用？-11 3.2.2嵌入式实时系统的面向对象的开发过程？-12 3.2.3对象分析的作用及主要活动？-13 3.2.4系统设计阶段的主要活动？-13 3.2.5系统设计阶段标识并发的指导原则？-14 3.3面向面向对对象的象的设计设计知知识识 -17 3.3.1面向对象的优点有什么？-17 3.3.2软件的可维护性与可复用性的概念及关系？-18 3.3.3“开闭”原则（OCP Open-Closed Principle）？ -19 3.3.4里氏代换原则（LSP Liskov Substitution Principle）？-19 3.3.5依赖倒转原则（DIP Dependency Inversion Principle）？-19 3.3.6接口隔离原则（ISP Interface Segregation Principle）？ -19 3.3.7合成/聚合原则（CARP Composition/Aggregation Principle）？ -19 3.3.8迪米特法则（LoD Law of Demeter）？-20 3.3.9对象设计原则总体分析-20 3.3.10什么是模式 -21 3.3.11创建模式分析及其运用中的演化过程-21 4参考参考-24 _ 精品资料 4.1关于关于 -24 4.2参考文献参考文献 -24 _ 精品资料 1引言 1.1目的 本手册作为公司 UML 及对象开发方法应用知识培训使用。仅介绍一些 UML 和面向对象开发 方法的基本知识，对其中更多的细节，请查看相应参考书籍。 1.2使用对象 本手册主要是为初次 UML 及面向对象知识的读者。 为了能更好地理解本手册，需要具备如下的基本知识： 计算机基本知识。 UML1.0 基本知识。 1.3使用说明 本手册仅供入门级使用，如果熟练掌握，仍需进一步研究相关知识。 _ 精品资料 2知识介绍 2.1UML 基础知识 2.1.1总览 我们知道，现实世界中事物之间的关系是一种很复杂的关系。每个人在面对某一个系统或事 物时，都会有自己的理解。软件工作者一个重要的任务就是理解系统的本质关系，然后将这种本质 关系通过软件构造出来。如何使理解一个系统内事物及事物之间的关系，如何使系统相关利益者能 够理解系统并达成一致，首要的任务是给出一种标准的、易于理解的表达方式，让所有利益相关者 在共同的表达方式下，通过协作来达到不断理解系统的任务。模型就是一个能够很好达到这个目标 的工具。简单的说，模型就是对现实的简化。我们通过建立模型来更好的理解我们正在开发的系统。 其根本原因是因为我们不能完整地理解一个复杂的系统，所以我们要对其关系进行抽取，对其建立 模型。 统一建模语言（Unified Modeling Language UML）就是一种绘制软件蓝图的标准语言。通过 UML，能够建立一个所有人基于共同标准语言的模型。UML 主要使用 OO（面向对象）方法来建立模 型的。UML 最重要贡献不是其表达 OO 有多么精妙，而在于其统一了 OO 建模方法。UML 中的 U 有两个方面的含义：一是它有效地消除了原有建模语言间的差异；二是它统一了存在于不同类型系 统中的需求分析、设计、实现，以及内部概念中的观点和认识。 UML 的主要目标是： 使用 OO 概念为系统（不仅是软件）建模； 为概念产品与可执行产品之间建立一个清晰的耦合； 创建一种人和机器都可以使用的语言。 UML 致力于一种标准的建模语言，而不是标准的建模过程。尽管 UML 必须应用于过程，但实 践证明，不同的开发机构和不同的问题域，其建模过程不完全相同。因此，UML 首先把重点放在通 用的元模型（用带有文字说明的 UML 符号表示），用来统一语义；然后才是通用的符号表示，用以表 示语义提供的表示方法。同时，使用图形符号和正文语法为系统建模，用来描述用户的层次模型，在 语义上是 UML 元模型的实例。 （注：模型的内容包括：语义、表示法和语境的描述。 ） 在我们学习 UML 的同时，需要将 UML 运用到开发过程中，因此，我们还需要学习一些开发 方法，尽管这些方法需要我们根据现实情况加以灵活运用，但了解一些基本的开发方法仍是非常有 必要的。在本文中，主要介绍一些主流的面向对象的开发方法。 2.1.2UML 核心概念 UML 的主旨是让用户能够定义他的系统的模型。我们知道，一个系统的组成主要由三部分组成， 即：系统拥有的事物、系统中事物之间的关系和系统中事物所处的环境。我们要用建立的模型表达出 系统的特征，就必须从各个角度描述出这三部分。 模型主要由语义和这些语义的用户视图两部分组成。用户模型最重要的部分是系统的语义定义。 这些语义主要有三个主要的方面：结构、行为和功能。模型的结构方面是识别建立系统和各个“事物”， 模型的行为方面定义了在系统运行时，结构元素是如何工作和交互的。显然，这可以用来描述系统 的“关系”。系统的功能方面，则用于描述系统的运行为用户提供什么有价值的行为。系统功能中提到 的功能，说明了我们模型所关注是对用户有价值的系统，通过对功能的描述，让人们集中注意力到 这些有价值的行为上来。另，模型对“环境”的描述是通过在对结构和行为的描述中增加限制来实现 的。 在 UML 标准中，根据结构和行为的分类，主要由以下用户视图组成。结构视图包括：类图、组件 图、组合结构图和部署图。行为视图主要有：交互图、状态图、活动图和用例图。这些视图的主要作用 如下： 类图：主要表达事物及事物之间的静态关系。 组件图：主要表达系统静态实现视图。 组合结构图：主要表达系统中某些静态事物与动态行为之间的关系。 部署图：主要表达系统的静态实施视图。 交互图：又可分为协作图和顺序图。重点在于描述系统中多个事物之间相互协作完成某项功能。 协作图和顺序图可以相互交换，但其中还是有细微的差别，协作图强调系统间事物的的协作关系， _ 精品资料 而顺序图更强调事物协作流的时间顺序一些。 状态图：显示一个状态机（包括简单状态、转换、嵌套组成状态）的图。重点在于描述单个事物状 态之间的迁移，这与交互图是不同的。 活动图：UML 活动图是状态图的一种扩展形式，它展示出对象执行某种行为时或者在业务过程 中所要精力的步骤和判定点。活动图与状态图的主要区别是，状态图图出显示的是状态，而活动图 突出显示的是活动。 用例图：主要用来描述潜在的用户所看到的系统的功能的视图。其重点在于描述系统为潜在用 户提供什么有价值的行为。 如果有人问哪种图最好？回答是都好。它们只是描述系统的一个视角，其最终目的都是想从某 一个方面来表达系统的特征，要全面的理解系统，就需要从多方面来观察系统。当然，这些图中，也 有轻重，其中核心的三种图是：类图、顺序图和状态图。 我们一般使用类图来看系统的结构关系，使用顺序图来观看系统中各元素是如何交互的，要看 某个元素孤立的行为，可以先通过用例获取系统功能（该用例包含要看的元素），待状态图或活动图 细化后，就可以看到每个元素的行为了。单个对象的行为规范说明一般用状态图捕捉（如果对象以离 散方式作用于事件）或用活动图捕捉（如果不是离散方式）。整体的协作行为还是用顺序图来捕捉。 在 UML 2.0 中，除了基本语言部分外，它提供了垂直语言单元，其主要的语言架构如下图： 此外，垂直语言单元按级别组织成三层，通过在那些可用的层上增加建模能力可以形成相互连 续的更高层。这就对模块性提供了更多的空间，即使对一个已给定的语言单元，你也有可能只使用 某些特定的子集。其中，语言基础部分包括有：类、动作（Action）和公共机制。 这样的架构意味着，你可以学习和使用 UML 那些最适合你的部分。你不再需要为了有效地使 用 UML 去熟悉它所有的内容，就如同你不必为了说好英语而去学习英语里所有的内容一样，从这 点来说，它可能比学英语更简单。随着你经验的增长，如果有必要你可以逐渐引入更强大的建模概 念。 2.1.3UML 对提供软件质量有什么帮助？ 我们知道软件开发的难点在于一个项目的参与包括领域专家、软件设计开发人员、客户及用户。 他们之间交流的难题成为软件开发的最大难题。UML 的重要性在于，表示方法的标准化有效地促进 了不同背景人们的交流，有效地促进软件设计、开发和测试人员的相互理解。无论分析、设计和开发 人员采取何种不同的方法或过程，他们提交的设计产品都是使用 UML 来描述的，这有地促进了相 互的理解。 在开发方法上，UML 尽可能地结合了世界范围内面向对象项目的成功经验，因而它的价值在于 它体现了世界上面向对象方法实践最好经验，并以建模语言的形式把它们打包，以适应开发大型复 杂系统的要求。 在从多成功的软件设计与实现的经验中，最突出的两条：一是注重系统架构的开发，一是注重过 程的迭代和递增性。尽管 UML 本身没有对过程有任何定义，但 UML 对任何使用它的方法提出的地 是：支持用例驱动，以架构为中心，以及递增和迭代地开发。 注重架构意味着不仅要编写出大量的类和算法，还要设计出这些类和算法之间简单而有效地协 _ 精品资料 作。所有高质量的软件中似乎大量是这类的协作，而近年出现的软件设计模式也正是为这些协作起 名和分类，使它们更易于重用。最好的架构就是“概念集成”，它驱动整个项目注重开发模式并力图使 它们简单。 迭代和递增的开发过程反映了项目开发的节奏。不成功的项目没有进度节奏，因为它们总是机 会主义的，在工作中是被动的。成功的项目有自己的进度节奏，反映在它们有一个定期的版本发布 过程，注重于对系统架构进行持续的改进。 通过 UML 及其在开发过程中正确的应用，都会对软件开发质量有很大的提高。 2.1.4UML 可以应用在哪些不同类型的系统？ UML 常见的应用于：信息系统、技术系统、嵌入式实时系统、分布式系统、系统软件和商业系 统。 2.1.5UML 有哪些公共机制？ 在 UML 中，定义了一些各个表达方式中通用的表达的机制，也就是公共机制。在 UML 中主要 使用 4 个公共机制：规格说明、修饰、公共划分和扩展机制。 规规格格说说明（明（description）：）：UML 不只是一种图形语言。实际上，在它图形表示法的每部分背后都 有一个规格说明，这个规格说明提供了对构造志的语法和语义的文字叙述。UML 的规格说明提供 了一个语义底版，它包含了一个系统的各模型的所有部分，并且各部分相互联系，并保持一致。 UML 的图只不过是对底版的简单视觉投影，每一个图展现了系统一个特定的方面。 修修饰饰： ：UML 中大多数元素都有唯一的和直接的图形表示符号。通过对这些元素增加附加的修 饰来完成对其最重要的方面提供可视化表示。如抽象类使用斜体表示，public 的属性在前面加图形 “”。如下图： 其中，注释是一种能单独存在的修饰，是附加在元素或元素集上用来表示约束或注释的图形符 号。其图形如下： 约束的图形表示是用花括号括住的注释，约束可用专门的约束标准语言表达（OCL）。 公共划分：公共划分：有两种划分方法，即：类和对象的划分，接口和实现的划分。 扩扩展机制：展机制：主要有构造型（stereotype）和约束（constraint）。如下图： 构造型使用双尖括号括住的部分，这里是 domain，表示抽象类属于 domain 构造型， “属性 1”的 类型为整数，后用花括号括住的部分 unique，表此属性的约束为“此属性 1 在系统中保持唯一”。 2.1.6UML 类图分析 在 UML2.0 中，类图可以由类、接口、类实例、端口、各种关系和公共机制组成。要了解这些概 _ 精品资料 念的具体含义，请参见面向对象基本知识的书籍和 UML 相关基础书籍。下图画出了类图中涉及的 主要元素： 在 UML2.0 中，类图主要增加了 association class（关联类）、association End（关联终端）、端口、 提供的接口、需要的接口等新元素。 在 UML 中，各个类之间存在着各种关系，其中主要有的三种关系是：依赖、泛化和关联。 依赖是一种使用关系，它说明一个事件规格说明的变化可能影响到使用它的另一个事件，但反 之未必。其图形是：一个虚线的的箭头。 泛化就是我们平常说的继承，是一般事件和该事物的较为特殊的种类之间的关系。其图形是一 个带三角形的箭头。如： 关联是一种结构关系，它指明一个事件对象与另一个事件的对象的联系。连接两个类的关联称 为二元关联，连接 N 个类的关联称为 N 元关联。关联的表示主一根直线。除了基本形式外，还有 4 种应用于关联的修饰： 名称、角色、多重性和聚合。如下图示例： 具体元素的意义请参见相关 UML 标准。 _ 精品资料 2.1.7UML 状态图分析 在 UML2.0 中，状态图已作为一种单独的图。同时支持嵌套和状态间并发，如下图。 先看一下下面这个图： 一个状态有以下几个部分： 名称（如图中状态 1）； 进入（如图中 entry/Data Activity）/退出（exit/Final Nodes）动作； 子状态（如子状态 1）； 延迟事件； 状态有初态（上图中黑点）和终态（上图中外有圆圈的黑点）两个特殊状态。 转换是指两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个特 定事件发生而某个特定条件满足时进入第二个状态。转换有 5 个部分： 源状态； 目标状态； _ 精品资料 事件触发（如上图转换中的 finish）； 监护条件（如上图转换中的a0）； 动作（如上图转换中的/Process Order）。 在嵌套状态图中，有进入点和退出点等。要了解更多信息，请参见相关 UML 标准。 2.1.8UML 序列图分析 在 UML2.0 中，序列图作了较大改进，增加了对其它序列图引用的支持，增加了序列图的嵌套： 左边的图中使用了 Interaction Use（在图左上角用 ref 来标记）来引用其它序列图 a1 和 a2，这两 个 Interation Use 被放在 Combined Fragment（这是个可选单元，因此用 alt 标记）中。右边的图是一 个 Combined Fragment 的序列图（因为想要标记循环不，所以用 loop 标记）。 Combined Fragment 相当于子序列图（也能够嵌套），这个子序列图有多个标记来标记这个子序 列图的类型。在 UML2.0 中，主要有以下几种类型： Alt（多行为可选单元）；Opt（单行为是否选择）；Break（中止退出）；Par（并发）；Seq（操作数弱排序） ；Strict（操作数强排序）；Loop（循环）；Critical（关键区域）；Neg（追踪无效）；Assert（断言）；Ignore（忽 略消息）；Consider（考虑消息）等。 2.1.9UML 活动图分析 在 UML2.0 中，活动图中去除了泳道，强化了对嵌套和支持，与状态图明确分开，增加了 activity(注意与 action 区别)。 _ 精品资料 具体元素的意义请参见相关 UML 标准。 2.1.10UML 组合结构图分析 在 UML2.0 中，组合结构图是一种新的图，它联合了静态（如类）和动态（如协作）两种结构在一 张图，消除了以前 UML 中单纯靠协作来联系活动的缺点（对用户来说想联系活动与静态结构的关 系非常不明显）。 下面是一个典型的组合图： 其中协作事件如：retail:Sale 和 wholesale:Sale，retail 和 wholesale 是协作事件的名称，Sale 是其 所属的协作，Broker、producer 和 consumer 是部件。其中的 Sale 的协作图如下： _ 精品资料 综合来说，整个组合图表达的意思是，Sale 就是买卖关系，BrokeredSale 是指代理商销售的协 作是指：代理商作为买者通过批发（协作事件 wholesale:Sale）从 producer 那里买来物品，代理商作为 卖者通过零售（协作事件 retail:Sale）卖物品到消费者那里。 从上可知，组合结构图通过将活动（协作和协作事件）与静态结构（部件）关联起来，让用户明白 某种静态关系与动态关系的关联。具体元素意义请参见相关 UML 标准。 2.1.11UML 组件图分析 在 UML2.0 中，组件图增加了嵌套功能，以及端口、提供和要求的接口等新元素： 具体元素意义请参见相关 UML 标准。 2.1.12UML 部署图分析 在 UML2.0 中，部署图增加了嵌套功能，以及设备、deployment spec、device、artifact、executale Environment、communication Path 等新元素，下图是一个示例图： _ 精品资料 具体元素意义请参见相关 UML 标准。 2.1.13UML 用例图分析 在 UML2.0 中，用例图未做大的改动，只是增加了 subject（主题），此功能类似于子系统： 具体用例图的使用请参见与用例相关书籍。 _ 精品资料 2.2面向对象开发过程 2.2.1软件开发的主要活动及其各个角色所起的作用？ 上图画出了一个软件开发大概的过程，实际的过程应当是反复、迭代递增来实现的。这其中，需 注意的是：需求和阶段所做的大部分工作应当是与用户实现的系统的逻辑（包括业务逻辑和概念逻 辑等）方面有关的事情，只是到了只是到了设计阶设计阶段才会更多的考段才会更多的考虑软虑软件方面的件方面的问题问题。当然，实际上，这种划 分并不是绝对的。在大部分情况下，分析人员（负责业务分析、需求分析、领域分析）很少同时在业务 和技术领域具有深厚的知识背景。这就意味着，在需求阶段和分析阶段，客户、开发人员和测试人员 就应当根据系统复杂度，来适度的参与到需求和分析阶段来，保证建立的需求是能够实现客户需求 的、可行的软件。 （谁谁做决策并不重要，重要的是做决策并不重要，重要的是谁谁参与了决策。参与了决策。 ） 还有一点要注意，上述开发过程是一个迭代的、逐步递增的过程。这不同与传统的瀑布型开发方 法。在这种新型的开发过程中，每个参与到过程中的角色都需要重新定义其角色，下面是对迭代开 发中各个角色的职责分析。 分析人分析人员员：主要负责与客户交互和需求。在迭代的开发中，分析人分析人员员不不应该应该孤立的指定需孤立的指定需 求求。这主要要注意如下方面： 建立与最终客户的持续交互以确保开发人员可以创建的正确的系统。 鼓励尽早地开发和实现系统的关键能力部分，以加深你对什么需求将满足业务需要的理解。 从一开始就与开发人员和测试人员一起优化需求。 为需求选择适当的详细程度，可以根据你的项目和当前的生命周期阶段而定。 同时，分析人分析人员员提出提出过过度度预预想的需求是不明智的想的需求是不明智的。一旦你的需求达到一定的细化程度，最经济的 实现方法是对系统进行部分的实现以可以向最终用户进行演示。在细化预想的需求上花费过多的时 间会使你的注意偏离降低关键风险的初衷。 开开发发人人员员：首先，开开发发人人员员需要在确立需求中扮演更多需要在确立需求中扮演更多积积极的角色极的角色。另外，迭代开迭代开发认为发认为 质质量是量是项项目中每一个人的目中每一个人的职责职责。现代的最佳实践包括测试测试先行先行的设计：首先你要指出你首先你要指出你应该进应该进行什行什 么么测试测试，然后再构建能，然后再构建能够够通通过这过这些些测试测试的的软软件件。这样创建高质量的代码是我们重点要考虑的事情。 总之，除了简单的实现需求规格说明，开发人员必须在决定什么对整个系统是必要的方面承担更多 的任务。这包括帮助确保需求是正确的和在可接受的成本下创建出高质量的系统。 测试测试人人员员：传统的软件开发，当项目快要结束时，开发出来的软件才被交给测试人员，让 测试人员通过找到软件的缺陷来为软件“注入质量”。在迭代的开发方法中，测试人员仍然要负责确 定系统的质量是否足以发布，但是他们确保完成高质量系统的方法却从根本上发生了变化。首先， 测试测试人人员应员应当成当成为团队为团队中中质质量量问题问题方面的指方面的指导导者者。同时，在在项项目早期就引入目早期就引入测试测试，这个时候，测试更 关注找到“影响大”的问题，而不是验证代码是不是已经可以交付了。这就需要测试人员与分析人员 和开发人员密切合作，以便他们能够理解在每个迭代中什么是需要被测试的。此外，测试测试人人员员必必须须 与分析人与分析人员员和开和开发发人人员员一起工作以确保需求和一起工作以确保需求和设计设计是可是可测试测试的的。通过理解架构及迭代过程，测试测试人人 分析阶段 设计阶段 编码阶段 测试阶段 需求阶段 _ 精品资料 员员必必须须建立可持建立可持续续的自的自动动化化测试测试。 项项目目经经理理：传统的情况下，项目经理通过询问团队成员已完成什么活动来确定项目的状 态。他们假设所有的活动完成时，项目也就完成了。然而，就像很多项目经理知道的那样，事情很少 是按照计划进行的。甚至是如果你创建了更为详细的计划，结果也是令人惊讶的。无论我们如何努 力预期未来，我们也不能预期每一件事情。 因为我们不能预测未来，软软件件项项目目经经理需要理需要对对他他们们的一些关的一些关键键的策略的策略进进行行风险风险管理管理。并 定定时时公开公开项项目当前面目当前面临临的的风险风险，持，持续续的重新的重新评评估估风险风险，并且使用，并且使用风险风险来来为项为项目工作目工作进进行行优优先先级级的划的划 分分。那么，我们怎样知道项目的风险当前的状况是如何的呢？我们有什么方法来测量呢？这需要我 们改变以往的测量方法，代替基于完成活代替基于完成活动动的的测测量方法，采用基于可演示量方法，采用基于可演示 的的结结果的方法果的方法测测量量。这主要是基于结果的管理。应用基于结果的管理策略意味着将重点放 在风险上并正面的处理它。因为一个软件开发项目的主要结果是软件本身，所以你所交付的产物应 该是成功的主要量度。你可以使用像一系列被通过的软件测试、代码中的缺陷的数量和他们的精确 度等等的指标评估你的软件质量。换名话说，移到迭代开发就意味着要通要通过过根据指定目根据指定目标标和需求和需求产产 生的可生的可测试测试、可演示的、可演示的结结果，而不是通果，而不是通过计过计算有多少活算有多少活动动、 、产产物或者是工作物或者是工作产产品被完成来品被完成来评评估估项项目目 的状的状态态。为了评估项目的稳定性，你也应该跟踪需求、设计和代码中的冗余。 更少的也更少的也许许是更好的是更好的。项目经理应当根据你项目的需要确定文档的详细级别。决定合适的详细 级别的方法是关注风险和结果：如果你添加详细信息到某一产物可以减少风险或者改进特定结果的 质量（包括维护阶段），那么这个投入是值得的，否则，在更有生产力的活动上花费时间是更好的。如 在在项项目早期，目早期，对对整个整个项项目做出整体目做出整体计计划，但划，但仅仅对仅仅对当前的和下一个迭代生成当前的和下一个迭代生成详细计详细计划划。 信任你的信任你的团队团队。 。给给他他们们足足够够的知的知识识和和职责让职责让他他们们全全全全负责产负责产 品的品的质质量。帮助他量。帮助他们团结们团结在一起工作。在一起工作。 质质量保量保证证和方法和方法专专家家：主要关注以下几点： 为项目选择适当的形式级别（更多的不总是更好的）。 关注在整个项目周期中保证质量，但是可以是灵活的。最好的到达高最好的到达高质质量的做法不是量的做法不是仅仅仅仅 通通过疯过疯狂的狂的检查检查和和测试实现测试实现的，而是通的，而是通过过在在给给定定时间时间上上对对需求、架构、需求、架构、设计设计、 、实现实现、 、检查检查和和 测试测试的良好平衡上的良好平衡上实现实现的的。 采用风险驱动的过程方法。过程应该允许项目经理对项目当前风险情况采用战术性的行动。 2.2.2面向对象的开发过程？ 在嵌入式实时系统开发中，面向对象技术的使用仍然有一些没有解决的难题。主要问题是面向 对象的垂直体系，而嵌入式实时系统需要实时性、高可靠性、高性能需求，这就需要根据这些特殊需 求来组合一些日常逻辑上不在一起的对象，这显然是一个横向组合。如何将垂直体系横切，是一个 非常头痛的问题。 下面介绍一种嵌入式实时开发的面向对象的开发过程： 抽象程度开发阶段UML 模型描述 系统需求需求用例图、组合图使用用例描述功能需求，撰写需求规格 说明书 子系统分析(逻辑 域) 子系统分析类图、组合图、顺序 图、活动图、状态图 通过划分子系统从隔离高层逻辑，通过 子系统领域建模理解子系统内概念关系 子系统架构系统体系结 构设计 类图、组件图通过子系统和构件视图设计系统架构 子系统设计系统设计类图、状态图、顺序 图、活动图、组合图、 部署图 通过并发和资源视图、分布视图、安全性 和可靠性视图、部署视图获取系统其它 关注方面，根据分解原则获取系统设计 整个过程中，最复杂的阶段是从子系统设计阶段，因为子系统设计中不仅要考虑子系统分析的 逻辑域的关系，同时考虑并发、资源、分布、安全等方面，如何将面向对象的垂直和性能优化的横切 _ 精品资料 综合起来，设计一个性能和逻辑都比较利于理解和维护软件系统，将是考验软件开发者经验的重要 指标。 2.2.3对象分析的作用及主要活动？ 对象分析阶段一个重要的工作是领域建模。在很多情况下，领域模型只是领域中一些关键概念 的草图，可以用来传递和分辨想法。领域模型常常用分析模型中的类图表达。 我们知道，系统往往是通过行为联系到事物的，编程者起初关注在行为，在需要时引入事物， 这在过程化编程中很典型，如何组织行为是主要的驱动力，事物从属于行为。 面向对象思想使用一种不同的思路，首先关注事物（对象），行为从属于事物，然而，需求往往 用行为语言表达，混在一起的行为被分割，分配到不同的对象，从早期开始， ”将责任分配到合适的 位置”成为 OO 的信条，如果我们做好了这一步，构建和修改系统将会更容易和易于成功。 你或许会问，既然需求以行为方式表达，为什么我们不以这种方式来构造系统呢？ 领域模型试图分离出系统中变动部分和非变动部分，在相当抽象的层次上，领域中的事物以及 事物间的关系在相当长的时间内非常稳定（可能达数个世纪），我们假定这种关系在将来变化时仍 将保持，如果程序的逻辑结构和领域内的稳定结构相匹配，那么程序的结构就可以适应变化，因此 如果我们希望程序能够适应变化，它的结构必须和领域保持一致。(这是符合高层抽象比低层抽象 更稳定的原则的。例：人是比男人和女人更高的抽象，那么人在概念上比男人和女人更稳定。比如出 现两性人，打破了男人和女人二分概念，但此两性人仍然是人，人这个概念保持不变。) 同样，领域中的实体所承担的责任也是长时间不变的，至少在基本的、抽象的层面。因此如果 系统基于实体、实体关系、实体责任构建，程序的逻辑结构就可以具有一个稳定的核心。虽然变化 的属性：比如系统架构方面、系统使用方面可能会发生变化。 系统架构方面，比如持久化、表现层、系统管理等在实现时会有很多方式，或多或少可以从领 域模型的稳定部分分离出来，比如说，系统的非功能性变化会引起系统架构方面的变化，转换基于 系统架构和领域模型的完全分离，一种系统架构可以适应不同领域的系统，一个领域模型也可以因 操作环境的不同而使用不同的系统架构来实现。 （期望达到架构和领域模型相互影响最小） 企业需求变化时，系统的使用也将发生变化。如果系统结构适应用户行为的结构，当用户需求 变化时，系统的结构也要相应变化，如果用户行为需求映射到领域模型的逻辑结构（记住，系统的相 当抽象层次的领域模型的逻辑结构一般是稳定的），当用户想得到不同的行为时，只需改变这种映 射，用户想得到新的行为是可能会发生的，但只是在现有系统结构的合适部分上增加，而不是对整 个系统进行重构。系统构建如果围绕领域中稳定不变的部分构建核心的逻辑结构，就能够适应领域 使用的变化，这是 OO 系统获得灵活性的基础。 OO 方法论中另一个难点是如何将责任分配在合理的位置，这个问题是个很重要的问题。广泛 使用的 OO 系统必须保持灵活，但实际上，往往并非如此。OO 系统保持灵活性的能力在于以不同 的方式使用已有对象，因此如果你想以不同的方式使用系统，你所要做的就是让系统以不同的方式 使用系统中的对象，然而，这依赖于一个假定，对象可以以不同的方式使用，如果责任分配合理，对 象表达了正确的概念，它就可以以不同的方式使用，如果责任分配不合理，那么改变系统对象的使 用方式往往需要改变系统内核。 如果系统不需保持对未来变化的灵活性，那么责任分配问题就不需关注,建造这样的系统可能 会容易些，但修改系统可能要花费更大力气。OO 中对象的责任往往是由其环境中与其交互的对象 所要求其完成的行为，和这个对象实现的复杂度来完成的。这就要求我们在对象的设计中是保持变 化的，是根据环境的变化和复杂度的要求来不断重构的。 对象分析阶段主要包括使用协作来描述用例，建立领域（分析）模型，这些领域（分析）模型应当 是力图最少引进设计元素的。下图是一个简单过程： 用例协作 领域模型设计模型 用顺序图或 活动图等实 现协作 用类图实现 领域（分析） 模型 _ 精品资料 2.2.4系统设计阶段的主要活动？ 我们知道，软件分析阶段重点的是领域逻辑上的问题，在设计阶段，需要系统从领域视角转到 软件视角，这是一个很复杂的转换。也有很多种转换方法，下面介绍一种适合于嵌入式开发的转换 方法，这其中的阶段需要根据设计软件的复杂来来裁剪和增加的。 系统设计阶段一部分是做高层的体系结构设计，另一部分设计是在编码时完成的。当项目需要 大量软、硬件协同设计或项目复杂到必须分成多个小组时，就可能需要细致的体系结构分析。此时 从软件角度来分析的目的是使小组能在体系结构分到他们的片段上工作，有一个框架以使他们能 从体系结构中拉出需要的元素。 系统体系结构的一般分析活动，可能有如下过程： 定义子系统的体系结构； 定义子系统的接口及交互协议； 定义子系统的联合协作以实现系统的用例。指定协作中的每个子系统充任什么角色，但不 细化子系统的内部结构； 将系统的用例和需求分解为子系统的用例和需求。每个需求和用例都应分配到合适的子 系统上； 做系统的算法分析和控制法则规范说明，展示系统的连续性和成片连续性的行为； 将子系统按技术学科分解：电子、机械、化学、软件。 系统用到的主要表示法是子系统图。该图与类图无异，示出了子系统视图中的主要元素：子系 统、行为者、接口、关联。子系统的协作行为主要使用顺序图示出，单个子系统需求的规范说明用前 述需求阶段同样的技术，只是此刻是在子系统层次上。软硬件的分解用部署图示出。接口可用类 图或正文的接口规范说明示出，类图可显示地