logo资料库

西安交通大学研究生面向对象技术考试要点.doc

发布时间：2022-06-08 发布人：admin 分类：说明书 资料大小：1.99M 资料格式：doc 举报 版权申诉
第1页 / 共7页
第2页 / 共7页
第3页 / 共7页
第4页 / 共7页
第5页 / 共7页
第6页 / 共7页
第7页 / 共7页
资料共7页，全文预览结束
    1.绪论 软件=程序+数据+文档；软件工程=过程+方法+工具（过程：when、in what order 方法：what）；软件过程：是指一 套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关 Artifacts（计划、文档、模型、编码、测 试、手册等）组成。三种方法：UP（the unified process），The OPEN Process，OOSP(The Object-Oriented Software Process)。 2.软件工程模型回顾 软件过程的基本模型：线性顺序模型：瀑布模型 (Waterfall)；进化模型：原型法模型 (Prototyping)；基于构件的开 发模型 (Component-Based Development)。迭代模型：增量模型 (Incremental)；螺旋模型 (Spiral)其他(Formal,RAD,4GT) 2.1 瀑布模型（Royce，1970）历史最悠久、应用最广泛，虽然 Royce 提出的瀑布模型支持反馈环，但大多数使用 该过程模型的机构均将其视为严格线性的过程模型。瀑布模型的流程 (无反馈环)：分析→设计→编码→测试。 缺点：①实际项目很少按照该模型给出的流程进行。虽然线性容许迭代，但这种迭代是间接的，且极容易导致混乱。 ②客户常常很难清楚地给出所有需求，但该模型却要求非得如此，并且不能忍受项目开始阶段自然存在的不确定性。 ③客户必须有足够的耐心，因为软件产品的运行版本一直要等到项目开发周期的晚期才能得到。④如果直到检查运 行程序时才发现大的错误，其后果很有可能是灾难性的。⑤线性顺序会导致“阻塞状态”，即等待时间 > 开发时间。 2.2 原型法模型（Bernard Boar，1984）帮助客户明确其需求 (以增量方式进行)原型法模型的流程 (环状)规格描述、 开发和验证等阶段交织在一起；原型的本质：“口香糖 + 打包绳”。 优点①开发者与客户之间的误解，可通过对系统功能的“示范”而被识别出来。②客户在使用原型法模型期间，可 以发现新的需求或找出未发觉的问题。③可大量节约开发成本，并可提高系统的应变能力。 缺点①原型只包含局部功能，难以掌握系统的整体动态状况。②许多机构认为在原型上花费过多资源是一种浪费， 因为原型一般 (二般呢？……) 无法成为真正的系统而必须抛弃。③维护工作较为困难。 2.3 基于构件的开发 (Component-Based Development，CBD)出发点：复用；基础：庞大的可复用软件构件库 + 构件 的集成框架；CBD 的典型代表：统一软件开发过程 (Unified Software Development Process，USDP)优点①能显著减 少软件开发工作量 (70%)，从而能显著降低开发成本 (84%) 和开发风险。②软件产品可以尽快交付客户。缺点①需 求折衷无法回避，可能导致系统与客户实际需求背离。②当可复用构件的新版本不受开发者的掌控时，系统的演化 能力将可能受损。未来：面向对象技术将使 CBD 如虎添翼，因为面向对象技术能够开发出大量可复用的构件。 2.4 增量模型：融合了瀑布模型的基本成分和原型法模型的进化特征；每一个线性序列产生软件的一个可发布的“增 量”；任何增量的处理流程均可以结合原型法模型；第一个增量往往是核心的产品 增量模型 vs.原型法模型：与原型法模型最大的不同在于，增量模型特别强调每一个增量均发布一个可操作产品， 亦即早期的增量是最终产品的“可拆卸”版本。优点①不必等到最终产品完成，客户便可以从早期增量受益。②客 户可以把早期增量作为原型，并为后期增量提出需求。③尽管某些增量可能存在问题，但是整个项目的风险较低。 局限性①增量不能太大②每个增量均应具备一定功能③客户需求与增量大小之间的映射应匹配。发展：极限编程。 2.5 螺旋模型（Boehm，1988）吸收了瀑布模型和原型法模型的优点；增加了风险分析；使软件的增量版本的快速 开发成为可能。优点①使用原型实现作为降低风险的机制。②在系统开发初期，风险性高的部分首先被考虑，从而 能及早发现错误、降低风险并减少开发成本。③在编写软件时，已有产品可供运行或“示范”。 缺点①客户对该模型的可控性常常产生疑虑。②开发者需要具备和掌握较多风险评估的知识和技术。③如果某个大 风险未被及时考虑，会给后续开发造成困难。 2.6 形式化模型（Formal）的局限性：开发很费时、很昂贵。具有使用形式化模型所必需背景的开发者寥若晨星， 尚需多方面的培训。当客户对形式化模型一无所知时，开发者无法将该模型作为和客户进行通信的机制。 2.7 快速应用开发（RAD）强调极短的开发周期；是线性顺序模型的一个“高速”变种；与增量模型具有相似性；通 过使用基于构件的建造方法实现快速开发；RAD 主要用于信息系统开发。缺点①对于大型软件开发项目必须有足够 的人力资源支持②要求客户和开发者均应在短的时间框架内完成各自相应的快速活动，任何一方爽约均会导致项目 失败③当系统难以模块化时，或者当高性能是系统的主要指标时，RAD 将可能失效④RAD 不适合技术风险高的情况 2.8 第四代技术（4GT）是多种软件过程模型的综合；包含了一系列软件工具；开发者在更高抽象层次上描述软件规 格；软件工具根据开发者的软件规格描述自动生成源代码。优点①显著缩短了软件的开发时间②显著提高了建造软 件的生产率。缺点①目前的 4GT 工具易用性不够高②目前的 4GT 工具生成的源代码太低效③使用 4GT 工具开发 的大型软件产品的可维护性令人生疑。未来：4GT 与基于构件的模型相结合后，将可能成为软件开发的主流方法。 1
    解空间 模拟 现实世界 问题空间 领域知识 领域知识 抽象 领域知识 生成知识 设计知识 计算机系统 类是创建对象的模板 3.面向对象概述 问题空间中，对象是现实世界中存在的实体应用所关心的抽象， 概念、规则、事件、或者具有明确边界和意义的具体事物。 解空间中，对象是问题空间中的对象在计算机系统中的表示， 封装 (encapsulation) 了数据和行为的通信单位。对象的非严格 记法：<对象> ::= <接口，数据，行为>。 对象的基本特征①每个对象均有自己的惟一标识，从而区别于 其他对象。②对象之间通过消息进行通信。③对象总是处于一 定的状态。④对象有若干种行为。⑤对象的行为分为三类：创 建新对象、与其他对象通信、改变自身状态。⑥对象的状态只能被自身的行为所改变。⑦某个对象的状态可以由多 个其他对象的状态构成 。 问题空间中：类代表着具有类似性质的一组对象；类中的每一个对象即为类的不同实例。解空间中：类是对一组对 象的抽象，集中了该组对象的共同特性。类实际上是具有特定功能的模块。类 vs. 对象：静 vs. 动。 抽象数据类型 (Abstract Data Type，ADT)是对一组对象的更高层次抽象。ADT = 数据 + 操作。 ADT vs. 类：类=ADT+实现(可能只是部分)；类“瘦”极限(未进行任何实现)=ADT；“胖”极限(完全实现)，有效类。 类间关系：继承 (inheritance)；聚合 (aggregation)；关联 (relationship)。 继承的含义：是一种“求同存异”的高度抽象方式。（一般化(generalization)，具体化(specialization)）。一般化、具 体化、继承等术语均是复用思想的体现；一般化和具体化是对同一个类间关系 的不同角度审视：父类是子类的一般化 (从父类角度看)；子类是父类的具体化 (从子类角度看)。继承强调一般化 / 具体化关系中共享属性和操作的机制。 聚合的含义：表示“部分——整体”关系（组元类 (component class)，组合类 (assembly class)）。组合对象的存在依赖于组元对象。性质：传递性 (递归聚合 的基础)；逆对称性。 关联的含义：对象实例之间的物理或概念联结被称为链；关联是对一组语义与结构相似的链的抽 象；链是关联的实例。聚合 vs. 继承：聚合更强调对象实例之间的关系，本质上是“与关系”(is part of ,ISP)继承更关注对象类之间的关系，本质上是“或关系”(is a,ISA)。聚合 vs. 关联：聚合是关联 的一种特殊形式；聚合与关联之间的模糊差异无关紧要。 消息是对象之间进行通信的构造或结构；消息分为请求消息和完成消息两种；消息模式：发送对象、接收对象、内 容。事件指对象之间一次消息的传递；多个事件按照时间顺序可构成事件序列。消息 vs. 事件：静 vs. 动。 消息与对象：一个对象能接收不同形式不同内容的多个消息。相同形式的消息可以送往不同的对象。对于相同形式 的消息，不同对象可以有 不同的解释，可以做出不同的反应。消息与方法：对象接收到有效消息后，总会以某种 行为做出适当反应。期间，对象行为复用了类操作的代码实现(即类方法)。消息与方法可视为同义词。消息与代码 无关，而方法是操作的代码实现。消息传递 vs. 过程调用：当同一发送对象在不同时刻向同一接收对象多次发送相 同消息时，接收对象依其当前状态不同可以做出不同反应。消息传递可以异步进行，从而允许并行与分布执行。如 果过程体中只有局部变量，当同一调用者用相同参数值调用同一过程时，其调用结果在任何时刻都必然相同。过程 调用只能同步，其本质是串行执行。 多态性：含义：同一个操作可以是多个不同类的行为。不同对象接收到同一个消息后，可产生完全不同的反应。同 一个消息可调用不同的方法。意义：允许每个对象以自己最合适的方式去响应共同的消息，从而增强软件的灵活性 和可复用性。面向对象的特性：标识惟一性；分类性；多态性；继承性。面向对象的主题：抽象；封装；归并数据 与行为；共享/复用；强调对象结构而不是程序结构。面向对象 = 对象 + 分类 + 继承 + 消息 一般化 具体化 4. 典型面向对象方法摘要 面向对象方法的发展：面向对象方法最早于 1986 年提出。刚一开始就有五、六种面向对象方法。之后的五年间迅 速涌现出了 50 余种面向对象方法。部分著名学者：Grady Booch；James Rumbaugh；Ivar Jacobson；Coad、Yourdon； Shlaer、Mellor；Martin、Odell。六种典型面向对象方法：①面向对象分析与设计 (OOA/OOD)，Grady Booch②对象 建模技术 (OMT)，James Rumbaugh③面向对象软件工程 (OOSE)，Ivar Jacobson④面向对象分析与设计 (OOA/OOD)， Coad & Yourdon⑤面向对象系统分析 (OOSA)，Shlaer & Mellor⑥面向对象分析设计 (OOAD)，Martin & Odell 2
    4.1 面向对象分析与设计 (OOA/OOD)四种模型：逻辑模型、物理模型、静态模型、动态模型；六种图：类图、对象 图、交互图、状态迁移图、模块图、进程图；两种过程：宏观过程、微观过程。 4.2 对象建模技术(OMT)发展历程：通用电气 1991 年的 OMT-1、1994 年的 OMT-2；三种模型①对象模型：对象图、 对象数据词典②动态模型：事件、事件追踪图、状态图③功能模型：数据流图、输入/输出、功能/限制。 两项任务①系统设计：系统功能结构图②对象设计。 4.3 面向对象软件工程 (OOSE)发展历程：爱立信 20 世纪 60 年代后期，Jacobson 首次提出“用例”思想 。 20 世纪 80 年代后期，Jacobson 将“用例”引入 OO 领域。特点：更强调需求分析阶段；核心：用例 (Use Case)。 4.4 面向对象分析与设计 (OOA/OOD)Yourdon 是传统结构化分析设计方法的泰斗；分析阶段五个层：类/对象层、结 构层、主题层、属性层、服务层；设计阶段四个组元：人机接口组元、问题域组元、任务管理组元、数据管理组元。 4.5 面向对象系统分析 (OOSA)发展历程：1988 年提出，受关系型数据库设计中实体关系模型影响；特点：完整的面 向对象分析方法；分析阶段三个模型①信息模型：实体关系图②状态模型：状态迁移图③处理模型：活动数据流图 5. 典型面向对象方法 5.1 对象建模技术(OMT) 参见 4.2 模型 ：含义①是为了理解事物而对事物做出的一种抽象。②忽略了事物不必要的细节，对原始实体的处理更容易。 ③不同角度抽象出该系统，使用精确表示来构造模型，验证能否满足系统需求，逐渐将详情细节加入模型以完成模 型的实现。目的①能用于进行物理实体的测试。②能方便与用户的交流。③具有可视性。④主要目的是减少复杂性。 抽象：含义：①是人为了处理复杂性而具备的一种基本能力。②是对问题的某些性质的局部观察。③总是针对某种 目的进行，因为目的决定哪些性质是重要的、哪些是不重要的性质。④同一事物可能存在许多不同的抽象，这取决 于事物的目的。⑤所有抽象均是不完全、不精确的。目的①是强调相对某种目的而言的重要性质而忽略那些无关紧 要的性质。②是将事物限制到人所能处理的范围内。 对象模型←→数据结构：对象模型表示静态的、结构化的系统的“数据”性质。描述手段是含有对象类的对象图。 动态模型←→控制结构：表示瞬时的、行为化的系统的“控制”性质。动态模型的描述手段是状态图。 功能模型←→计算结构：功能模型表示变化的系统的“功能”性质，只考虑系统“干什么”而不关心系统“何时干” 或“如何干”。功能模型的描述手段是数据流图。 5.1.1 对象模型：含义：描述的是现实世界中对象的静态结构，即对象的标识、属性、操作及对象之间的关系。对象 模型是动态模型、功能模型不可或缺的框架，是活动的基础。内容：确定对象、类；编写类、属性、关联的数据词 典；在类之间加入关联；为对象和链添加属性；使用继承组织和简化对象类；测试存取路径；将类组合成模块。 5.1.2 动态模型：含义：描述的是对象中与时间和操作次序有关的各种因素，关心的是对象的状态如何变化以及如何 控制。内容：编写典型的交互序列脚本；确定对象之间的事件并为各种脚本编排事件跟踪；准备系统的事件流图； 画出具有重要动态行为的各个类的状态图；检查状态图中共享事件的一致性和完整性。 动态模型和对象模型之间的关系：①状态图描述了一个类中一个对象的全部或部分行为，状态等于这个对象的属性 值和链值，事件表示为对象模型的操作。②状态细化了对象可能有的属性值和链值，每个子状态限制了该对象可能 有的值。③类的动态模型可以被其子类所继承，子类既继承了祖先状态，也继承了祖先的转换。④合成状态是一个 或多个并发状态的聚合。⑤事件比状态更基础，因为事件不仅依赖一个对象类，而且依赖于它的状态。 5.1.3 功能模型：含义：描述的是系统内值的变化，以及通过值的变化表现出来的系统功能、映射、约束、功能的依 赖条件。内容：确定输入值和输出值；画出数据流图以表示功能之间的依赖关系；描述各功能；确定约束；详细说 明优化标准。功能模型、对象模型、动态模型等之间的关系：①就功能模型而言，对象模型表示了功能模型中的动 作者、数据流、数据存储的结构；动态模型则表示了功能模型中处理的执行次序。②就对象模型而言，功能模型表 示了类上的操作和每个操作的变量，因而也表示了类之间的客户/服务器关系；动态模型则表示了每个对象的状态 和当对象接收事件时/当对象改变状态时所 执行的操作。③就动态模型而言，功能模型表示了动态模型中未定义的 动作和活动的定义；对象模型则表示了是什么改变了状态/是什么接收了操作。 5.1.4 系统设计过程：将系统分解成多个子系统；确定问题中固有的并发性；将各子系统分配给处理器及任务；根据 数据结构、文件、数据库来选择数据存储的基本策略；确定全局资源、制定控制资源访问的机制；选择实现软件控 制的方法；考虑边界条件；建立权衡的优先级。系统设计文档 = 系统基本体系结构 + 高层决策策略 5.1.5 对象设计的步骤：从其他模型获得对象模型上的操作；设计实现操作的算法；优化数据的访问路径；实现系统 设计中的软件控制；为提高继承而调整类体系；设计关联的实现；确定对象属性的明确表示；将类、关联封装成模 块。对象设计文档 = 细化的对象模型、功能模型 、动态模型 3
    5.2 面向对象软件工程 (OOSE) 参见 4.3 5.2.1 OOSE 的五个模型：需求模型 (RM)；分析模型 (AM)；设计模型 (DM)；实现模型 (IM)；测试模型 (TM)。 5.2.2 三种对象类型：实体对象；界面对象；控制对象 5.2.3 OOSE 的过程主要包含三个步骤：分析、构造和测试：分析步骤产生需求模型和分析模型。构造步骤的输入是 需求模型和分析模型，其输出是设计模型和实现模型。测试步骤的输入是实现模型。 5.3 面向对象分析与设计 (OOA/OOD) 参见 4.1 5.3.1 Booch 方法概述：宏观过程的五个活动：建立软件的核心需求（概念化）；建立系统期望行为的模型（分析）； 创建实现时的体系结构（设计）；通过反复细化得到实现（演进）；管理交付后的演进（维护）。宏观过程是增量式。 微观过程的四个活动：识别给定抽象层次上的类和对象；识别这些类和对象的语义；识别这些类和对象之间的关系； 说明这些类和对象的接口，然后说明这些类和对象的实现。微观过程是迭代式的。 5.3.2 Booch 方法的四种模型：逻辑模型 vs.物理模型：逻辑模型描述构成问题空间或定义系统体系结构的关键抽象 和机制的存在及含义。物理模型描述系统环境或实现中的具体软件和硬件构成。逻辑模型的手段：对象图、类图物 理模型的手段：类图、对象图、模块图、进程图。 静态模型 vs. 动态模型：静态模型描述类(对象)的属性、关系等静态方面。动态模型描述类(对象)之间的交互关系。 动态模型的手段：状态转换图、交互图；每个类都可能有一个状态转换图，表示类实例的事件顺序行为。交互图与 表示场景的对象图结合后，用于显示消息的时间或事件顺序。 5.3.3 Booch 方法的六种图 ⑴类图：含义：类图描述类和它们之间的关系。作用：分析阶段，类图表示那些提供系统行为的实体的共同角色及 责任。：设计阶段，类图用于捕获构成系统体系结构的类结构。 四种类间关系：关联、继承、具有和使用。类可以有反身关联。关联的势是关联的装饰。继承、具有和使用等三种 基本类间关系是关联的细化。一般地，继承中没有循环，也没有势装饰。“具有”亦即聚合。反身聚合和循环聚合 都有可能。“使用”表示客户/提供者关系。 ⑵对象图：含义：对象图描述对象和在对象之间的关系(即消息)。作用：分析阶段，对象图用于提供系统行为中主 要场景及次要场景的语义。设计阶段，对象图用于描述系统逻辑设计中机制的语义。 ⑶模块图：含义：模块图描述模块和它们之间的依赖性。作用：设计阶段，模块图用来描述类和对象对模块的分配， 从而显示系统体系结构的物理分层和划分。 ⑷进程图：含义：进程图描述过程(进程)如何被分配给特定的处理器，这种图用于需要在分布式环境中应用的面向 对象系统。作用：进程图用于表示处理器和设备的物理集合 ⑸状态转换图：含义：状态转换图描述给定类的状态空间、引起状态转换的事件以及状态改变所导致的活动。一个 状态转换图或表示单个类的动态模型，或表示整个系统的动态模型。作用：分析阶段，状态转换图用于描述系统的 动态行为。设计阶段，状态转换图捕获单个类或类协作的动态行为。 ⑹交互图：含义：交互图描述对象图中不同对象间的动态交互影响。作用：交互图与对象图相对应；交互图只是对 象图的另一种表示方式。 交互图 vs. 对象图：交互图更容易读出以相对顺序传送的消息。对象图适用于许多带有复杂调用的对象，并允许包 括其他信息，如链、属性值、角色、数据流和可见性等。在生命周期早期，交互图在捕捉场景语义方面优于对象图。 伴随着细化的不断进行，对象图逐渐称为重点，因为其语义更有表现力。 5.3.4 Booch 方法的优点：提供了多种模型化工具，具有完整的文件。提供了各种活动的产生和机制。开发步骤明 确，且无间隙性。 5.3.5 Booch 方法的缺点：图示工具较为复杂。 4
    6. 统一建模语言（UML） 6.1 UML 的释义：是由单一元模型支持的一组图示法；U 的两重含义：有效消除了原有各种建模语言之间的差异； 统一了存在于不同类型系统中的需求分析、设计、实现、以及内部概念中的观点和认识。元模型是一种用以定义 UML 语言概念的图；为 UML 中的所有元素在语法上和语义上提供了单一的、通用的和确定的描述。不仅能使开发者在 语义上取得一致，而且能使工具间的信息交换和复杂系统的设计在语义上保持高度一致。 促成 UML 的第一个大事件：Rumbaugh 于 1994 年离开通用电气，然后与 Rational 公司的 Booch 结盟。促使 OMG 积 极介入 UML 标准化的根本原因：工具厂商们担心，如果 Rational 公司控制着标准，那么很有可能会给它带来不公平 的竞争优势。1997 年 11 月 17 日，UML1.1 被 OMG 接纳为标准。在 UML1.x 的各个版本之间，大部分变动都是对 UML 所 作 的 较 为 深 奥 晦 涩 的 考 虑 ， 只 有 UML1.3 例 外 。UML2.0 始 UML 规 范 被 分 割 为 两 个 互 补 规 范 UML Infrastructure，UML Superstructure。三友：Grady Booch、Ivar Jacobson 和 Jim Rumbaugh*实际上，“三友”中只有 Rumbaugh 是设计并撰写 UML 规范的核心组成员。RUP 是一种支持 UML 使用的过程。只是一个过程框架。 6.2 UML 的使用：三种使用方式：用作草图，用作蓝图，用作编程语言。用作草图：最常见的使用方式，重点在于 有选择的交流而不是完整的规格说明。用作蓝图：特别强调规格说明的完整性。 用作草图 vs.用作蓝图：草图故意不完整以突出重要信息，蓝图则打算全面以便将编程简化成相当机械的活动。草 图是探究性的，蓝图是定义性的。作编程语言：开发人员绘制 UML 图，然后将其直接编译成可执行代码。此时 UML 即源码。需要特别复杂的工具。主要质疑：对于大多数编程任务而言，图示形式并不比文字形式更富有成效。 用作草图 vs.用作编程语言：草图绘制人员将图看作 UML 的精髓。但是 UML 的创建者们却把图看成次要的，而把元 模型看作 UML 的精髓，图只是元模型的表现。这一看法对蓝图绘制人员和 UML 编程用户非常有意义。 6.3 UML 图摘要：类图：类、特征和关系；顺序图：对象之间的交互，强调顺序；对象图：实例的样形；包图：编 译时的层次结构；部署图：制品在节点上的部署；用例图：用户如何与系统交互；状态机图：事件如何改变生命期 中的对象；活动图：过程行为，并行行为；通信图：对象之间的交互，强调链；复合结构图：运行时类的分解；构 件图：构件结构，构件连接；交互概观图：顺序图和活动图的混合；定时图：对象之间的交互，强调定时。 6.4 类图：含义：类图表述系统中各个对象的类型以及其间存在的各种静态关系。也表明类中的特性和操作以及用 于对象连接方式的约束。以术语“特征”(feature)作为涵盖类之特性和操作的一般术语。特性 (properties)：表示类 的结构特征。尽管特性是一个单一概念，但是它可以出现在两种截然不同的表示中：属性和关联。属性表示即为类 框中的一行正文；关联表示即为两个类之间的一条实线，方向从源类到目标类。 选择属性表示还是关联表示：对小事使用属性表示(如日期、布尔值)，对较为重要的类使用关联表示(如客户、订单)。 重数(multiplicity)特性的重数指出可以具有该特性的对象数目。任选：意味着下界为 0；强制：意味着下界为 1 或可 能更大。单值：意味着上界为 1。多值：意味着上界大于 1。双向关联(bidirectional association)：双向关联是一对连 接在一起互为其逆的特性。其中逆连接的含义：如果遵照两个特性，应该返回到包括起点的集合。 操作(operations)是类知道要去施行的动作。恒态操作(query)：突出恒态操作是有益的，因为即使改变恒态操作的执 行顺序，也不会改变系统行为。改态操作 (modifier)，也称为命令。 操作 vs.方法：恒态操作与改态操作的区分不同于获得方法与置送方法的区分，对获得方法和置送方法的区分完全 是类内部的事。操作是针对对象提出的过程说明，而方法却是过程体。 一般化(generalization)：概念角度，一般化体现的是超类型和子类型。软件角度，一般化就是继承。子类继承超类的 所有特性，并且可以撤销超类的任何方法。子类型(subtype)和子类(subclassing)：前者即接口继承，后者即实现继承。 依赖(dependency)：如果一个成分的某种改动会引起另一成分的改动，称这两个成分之间存在一种依赖。依赖失控 的话，对系统的每一改动将引起越来越多的改动，从而导致广泛的涟漪效应(ripple effect)。应使依赖减至最小程度。 约束规则：绘制类图时做的最多的事便是指明约束，类图的最大危险在于仅仅专注于结构而忽略了行为！ 聚合(aggregation) vs. 组合(composition)聚合是“整体－部分”关系。UML 中包含了聚合，但几乎没有任何语义。 在组合关系中，虽然一个类可以是多个其他类的成分，但是它的任何一个实例却只能是一个拥有者的成分。 分类(classification) vs. 一般化(generalization)分类是指对象与其类型之间的关系，使用 ISA 短语。分类不具有传递性。 在对若干个 ISA 关系进行串接时；分类后面可以跟一般化，反之不然。分类关系不能串接，因为它没有传递性。 关联类(association class)允许为关联添加属性、操作以及其他特征。关联类可以作为一个完全类。 主动类(active class)；主动类的各个实例执行并控制自身的控制线程。主动类的最好例子是命令处理程序。 6.5 顺序图：是最常见的一种交互图。一个顺序图只描述单个用例的行为。在 UML1 中，顺序图中的参加者即为对 象。在 UML2 中，参加者的作用复杂化了。顺序图擅长描述对象之间的交互，但是它不大擅长描述行为的精确定义。 顺序图是对各个对象如何交互的一种形象化表示，而不是一种针对控制逻辑的建模方法。描述循环行为与条件行为 并不是顺序图之所长。 5
    集中式控制顺序图 vs.分布式控制顺序图：集中式控制顺序图比较简单，所有处理都在一处进行。分布式控制顺序 图能使变动的影响局部化，而且它能创建更多使用多态而不是条件逻辑的机会。 6.6 对象图：是在某个时刻系统中各个对象的一个快照。描述的是实例而不是类，又被称为实例图。对象图的成分 是实例规格说明，而不是真正的实例。实例规格说明是部分定义的实例。类图可以对结构进行精确定义，可能很难 理解，配合对象图就可以使局面改观。 6.7 包图：包图描述包及其依赖。对于大型系统而言，绘制包图是进行大规模控制的最重要手段之一。每个包表示 一个名字空间，亦即每个类在拥有它的包中必须有一个惟一的名字。公用类是包接口的组成部分，可以为其他包中 的类所使用；私用类则是隐蔽的。共同封闭原则：一个包中的各个类应该由于类似的原因而改变。共同复用原则： 一个包中的各个类应该一起被复用。包图表示一种编译时刻的聚组机制。虽然包最通常的用法是对类进行分组，实 际上包可以对 UML 中的任何构造进行分组，以形成更高层的单元。包间依赖实际上概括的是内容之间的应用依赖。 依赖关系不具有传递性。必须从每个包外表中挑选一个“包”，并将它们结合起来使用。体现了层次名空间特征。 6.8 部署图：部署图指出“哪些软件片断运行于哪些硬件片断上”，以此来描述系统的物理布局。在部署图中，节点 是可作为软件宿主的东西。 6.9 用例图：用例是获取系统功能需求的一种技术。描述系统用户与系统本身之间的典型交互，用例提供了系统是 如何被使用的叙述。一个用例代表着一组场景，这组场景具有共同用户目标。用例的全部价值在于其内容而非图。 每个用例都必须有一个主参与者(primary actor)，由它请求系统提供服务，常常是用例的发起者，其他的参与者和系 统通信，这些参与者称为次参与者(secondary actor)。用例的每个步骤是参与者与系统之间交互的一个元素，说明是 谁在施行该步骤。步骤只应说明参与者的意图，而不应涉及参与者所使用的技巧。不应使用功能分解把用例分解成 子用例、子子用例，浪费时间。用例图与结构化方法中的语境图也很类似：它描述了系统边界以及与外界的交互。 6.10 状态机图：为了描述单个对象的生命期行为，需要对单个类绘制状态机图。初始伪态与初态是两个不同概念。 初始伪态并不是一个状态，但有一个指向初态的箭头。终态表示状态机完成，意味着对象的删除。 转换(transition) 表示从一种状态到另一种状态的运动。转换标记分为三部分，即 trigger-signature /guard/ activity。 trigger-signature 通常是事件；guard 是一个布尔条件；activity 是转换中执行的行为。转换标记的三部分都可以缺少， trigger-signature 缺少表示立即进行转换。 guard 缺少表示如果事件发生总能进行转换。activity 缺少表示转换中什 么事都没有做。往往把对象的状态视为对象各个域中所有数据的组合。但是，状态机图中的状态可以是更为抽象的 概念，即不同的状态意味着对事件不同的反应方式。状态机图擅长于表述跨用例的对象行为，不太擅长于表述包含 若干协作对象的行为。 内部活动指将事件、监护、活动等置入状态框内，相应地状态可以不进行转换而直接利用内部活动对事件做出反应。 进入活动 (entry activity)：进入一个状态时所执行的活动。 退出活动 (exit activity)：离开一个状态时所执行的活动。 内部活动与自转换(self-transition)类似。自转换是指循环回到相同状态的转换。内部活动与自转换的区别在于，内部 活动不能引发进入活动和退出活动，而自转换则可以。 活动状态 (activity state)状态机图中可以存状态：对象做一项正在进行中的工作。正在进行中的活动以“do /”作为 标记。称为做活动 (do-activity)。做活动与正常活动两者的主要区别在于：正常活动“瞬时”发生并且不能被正常 事件中断，而做活动耗费一定时间并且可以被中断。 正常活动用动作(action)一词表示，而做活动则使用活动(activity)一词表示。 超态：当若干状态共享共同的转换和内部活动时，引入超态，并将共同的转换和内部活动与超态联系起来。 并发状态：某些状态可以被拆分成几个并发运行的正交状态图。 历史伪态 (history pseudostate)：发自历史伪态的箭头指明在没有历史时 (即首次) 所呈的状态。 6.11 活动图(activity diagram)含义：活动图是一种描述过程逻辑、业务过程以及工作流的技术。活动图在很多方面与 流程图的作用类似，但是活动图支持并行行为描述，而流程图则不能。在 UML 的各个版本之间，活动图的变化最 明显。活动图曾被看作状态机图的特例。这种看法给工作流建模人员带来了太多问题，因此 UML2 去掉了这种联系。 活动图上的节点称为动作，而不能称为活动。活动图中与并发行为有关的两个术语：分叉(fork)：有一个入流和几个 并发的出流。汇合(join)：仅当所有的入流均已到达时，才能处理出流。汇合用于对并行行为进行同步。活动图对令 牌(token)的使用：初始节点创建一个令牌，随后将其传递给下一个动作；下一个动作继续这样的传递。在分叉处， 当一个入流令牌到达后，分叉就在其每个出流上均产生一个令牌。在汇合处，只有当所有入流的令牌均已到达时， 汇合才会在出流上产生一个令牌。 6
    对于多重入流的情形，UML1 隐含着合并，而 UML2 则隐含着汇合。因此，应显式地标明汇合或合并，以免混淆。 划分(partition)活动图能指出发生了什么，但不能指出是谁在做 什么。活动图应该把注意力集中于做了什么，而不是由谁做行 为的哪一部分。如果非要说明谁做什么，则需要对活动图进行 划分。当划分是一维情形时，往往又被称为泳道 (swim lane)。 泳道是 UML1 中所用的惟一形式。UML2 可以使用二维的格。 信号(signals)活动图有明确定义的起点，即它对应于程序或例 程的启用。活动图中的动作也可以对应于信号。信号用于指明 活动接收来自外部过程的一个事件。此时，活动不断监听信号， 而图则定义活动如何反应。活动图除了接收信号之外，也可以 发送信号。汇合规格说明：缺省情况下，当所有入流的一个令 牌已抵达汇合时，它才会往出流上发出一个令牌。有时，某些 流需要带多个令牌，以表达更丰富的规则。在这种情形下，应 使用汇合规格说明。汇合规格说明是一个附着在汇合上的布尔 表达式。每当一个令牌抵达汇合时，都要对它求值。如果它为 真，就发出一个输出令牌。 通信图(communication diagram)含义：通信图着重阐述交互中 各个参加者之间的数据连接。与顺序图不同，通信图允许自由 放置参加者，通过一些连线来描述各个参加者如何相连，并利 用编号来说明消息顺序。通信图除了能描述作为关联实例的链 之外，也可以描述瞬时链，后者只在交互的语境中发生。通信 图中的消息编号应采用嵌套形式，以便解决自调用的模糊性。 通信图对控制逻辑没有提供任何精确的图示法。 复合结构图(composite structure diagram)含义：是 UML2 的新 成分，目标是把一个复杂对象层次性地分解成若干部分。 包 vs.复合结构：包是编译时刻的聚组；复合结构是运行时刻 的聚组；在实践中如何有效使用复合结构？尚不清楚。 构件图(component diagram)含义：构件图主要用于描述各种软件构件之间的依赖关系。 交互概观图(interaction overview diagram)含义：交互概观图是将活动图与顺序图嫁接在一起的图。可以看作活动图。 此时，活动图中的各个动作被换成了多个小顺序图。也可以看作顺序图。此时，顺序图被分解了。 定时图(timing diagram)含义：定时图的着眼点在于定时约束。 7
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料