UML学习重点汇总.docx

《UML学习重点汇总.docx》由会员分享，可在线阅读，更多相关《UML学习重点汇总.docx（11页珍藏版）》请在三一办公上搜索。

1、UML学习重点汇总第一章 OOM&软件建模概述 UML 通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。 特点：统一标准，面向对象，可视化、表达能力强，独立于过程，UML很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程 第二章 UML构成 1. UML的“4+1视图” 从某个角度观察系统构成系统的一个视图，每个 兼职经理全职经理Web站点主机关系数据库面向对象数据库公布项目进度表项目经理生成Web站点项目管理系统邮件系统发送邮

2、件项目数据库5活动图泳道图 泳道将活动图中的活动化分为若干组，并把每一 视图都是系统描述的一个投影，说明了系统某个侧面的特征。 用例视图逻辑视图组件视图进程视图配置视图 2. UML的模型图： 模型图是一组UML模型元素构成的有向图表示，它通常由一组节点, 及节点之间的连线组成。 (1) 用例视图：用例图 (2) 静态模型：类图、对象图、包图、构件图和配置图 (3) 动态模型：活动图、顺序图、状态图和协作图 3. 用例图. 用例图是表达用例和参与者及其关系的载体。关系包括：关联关系，依赖关系 实现关系： 3. 用例图(续)用例之间关系1. 3. 用例图(续)用例之间关系2. 3. 用例图(续)

3、用例与参与者 用例Use Case：一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值。 描述了从参与者角度看系统做了什么 用例模型本身不是面向对象建模技术。 参与者Actor: 是指在系统外部与系统交互的人或其他系统，以某种方式参与了系统内用例的执行。 4. 交互式视图图(顺序图、协作图 ) 1）协作图：采用图的形式展示对象间的交互 2）顺序图：采用栅栏格式展示对象间的交互 顺序图与协作图的优缺点： 顺序图 强调消息的时间顺序及对象生命线 大量详细表示法选项 强制在右侧增加新对象，消耗空间大 协作图 强调结构组织，复杂交互表达更容易 空间利用率

4、高，和方便添加新对象 不宜查询消息的顺序，表示法选项少 5 活动图 活动图用于表示完成一个操作所需要的活动，或者是一个用例实例的活动。活动图适合描述动作流和并发处理行为。 5活动图实例 组指定给负责这组活动的业务组织即对象。泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。 每个活动只能明确地属于一个泳道。 6 状态图 状态图(State Diagram)一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作。并不是所有类都有相应的状态图。状态图只适用于：具有若干个确定状态，类的行为在这些状态下会受到影响且被不同的状态改变。 状态图与活动图的区别与联系

5、相同的图形符号。 描述一个系统或对象在生存周期的状态或行为。 描述系统或对象在多进程中同步或异步操作并发行为。 用条件分支来描述系统或对象的行为控制流。 联系： 触发状态发生迁移的机制不同。活动状态迁移不需要事件触发，活动执行完毕可以直接进入下一个活动状态。 描述多个对象共同完成一个操作的机制不同。活动图置于责任区中，责任区将活动按责任目标和组织归属的原则分类。状态图采用状态嵌套方式描述多对象协作。 7、类图 类图表示系统中类及类和类之间的关系，用于对系统的静态结构进行描述。类用来表示系统中需要处理的事物. 类的关系： 关联：关联表示两个类的对象之间存在某种语义上的联系。 聚集：聚集也称为聚合

6、，关联的特例 聚集表示类与类之间的关系是整体与部分的关系。 泛化：UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。 依赖和细化。 2) 类的关系关联 间具有细化关系。细化用来协调不同阶段模型之间的关系。 第七章 模式与对象设计 构件图 构件图由构件、接口及构件之间的关系组成。构件图主要用于系统的静态实现视图模型，通过构件的依赖关系描述系统软件的组织结构，展示系统不同物理构件及其关系。 系统业务模型：业务过程和文档。 系统开发管理模型：开发期间产物及关系 系统实现模型：系统实现的构件建模 第六章 从需求到设计 包图 概念性的模型管理工具，用于将大型的软件系统中

7、大量的建模元素有序的组织起来。 运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中，对包中的元素作为一个整体对待，并 2) 类的关系聚集 聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。 。 2) 类的关系依赖 两个类之间有依赖，表明其中一个类.客户类.依赖于另一个类所提供的某些服务。 2) 类的关系细化 当对同一个事物在不同抽象层次上描述时，这些描述之系统物理配置模型：数据文件、日志、安装/卸载等文件且控制它们的可视性和存取。包拥有内容，包括类、接构件建模 口、组件、节点、协同。Use Case、图，甚至其它包。 集成系统模型：对API建模，帮助利用已有

8、组件。 第三章 Unified Process (1) 构件: 系统中遵从并实现一组接口的物理的、可替换UP的构成：二维的面向对象开发模型，兼顾技术和管理。 的软件模块。构件是软件复用的基本物理实现单元，是工作流:过程工作流(业务建模+需求+分析与设计+实施+逻辑元素模型的物理包 测试+部署)和3个支持工作流 4个阶段：初始细化构造交付 UP的迭代策略。 UP的迭代开发策略:以体系结构为中心，以质量管理和 风险控制为目标，以用例为驱动，采用迭代式以螺旋上 升的模式进行软件开发。 (2) 构件的接口:一个构件可以定义对其他构件可见的接第四章 初始阶段(Inception) 口。 构件间依赖通过指

9、向所使用的构件接口来表示。 接1. 初始阶段的目标和任务： 口描述一个构件能提供服务的操作，是一个有操作而无做适当的调研，以形成对新系统的整体目的和可实现的类。包括输入和输出接口。 行性形成一个合理的意见。 建立项目的软件范围和边界条件，包括一个操作“前景”， “接受准则”和产品中包含什么，不包含什么 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案 针对主要的场景，确定或者演示至少一个备选的系统结9 部署图 构 由节点和节点之间的联系组成，描述了处理器、设备和对整个项目估计总成本和计划 (更详细的估计将安排在软件构件运行时的体系结构。 细化阶段中) 估计可能的风险 (不可预计性

10、的来源） 为项目准备支持环境 2. 初始阶段的制品： 用例模型用例描述，词汇表，补充性规格说明，前景， 业务规则 9 部署图结点 3. 用例描述 节点是存在于运行时的代表计算资源的物理元素，可摘要：简介描述用例，通常只给出主成功场景。 以代表一种物理硬件设备或软件元素。 非正式：用若干非正式段落来描述用例，通常给出多个包含：处理器和设备两种类型 不同场景。 详述：详细描述用例，通常给出所有的步骤及场景，并10 部署图结点间联系 给出前置和后置条件等细节 节点间通过物理连接发生联系，以从硬件方面保证注意：用例描述的方法 系统各节点之间的协同运行。包括通讯关联、依赖联系4. 用例的获取过程 等。

11、(1)选择系统边界 (2) 寻找参与者 (3)确定每个参与者的目标 (4) 定义用例 5. 用例的定义:一般为每一个用户目标定义用例 确定用例的经验方法： (1)老板测试：必须看到可量化的价值 (2) EBP：能够增加可量化的业务价值，并且以持久状态留下数据(3) 规模测试： 6. RUP与用例 (1)意义：记录功能需求；迭代计划的重要部分，预算的关键输入；实现驱动设计；影响用户手册和测试 (2) 初始阶段：确定系统目标、范围、涉众；绝大部分摘要描述、1020详述；确定是否继续开发 (3)细化阶段：8090被细化描述；分多次迭代 (4) 构造阶段：多次时间定量迭代；补充次要用例 第五章 细化阶

12、段(Elaboration) 1. 细化阶段的目标和任务: 8. 系统顺序图 表述系统是什么，而不解释它是如何做的，将系统作为黑盒子 系统顺序图 它展示了对一个特定的用例，外部的参与者产生的事件，它们的顺序以及系统内的事件 协作与耦合从较高层到较低层进行，避免从较低层到较高层的耦合 第七章 模式与对象设计 1 职责和职责驱动设计 类的契约和责任，分为：行为职责和认知职责。 在对象设计中，职责被分配给对象，称为RDD。 2 设计模式 设计模式：对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。即，对特定问题的描述或解决方案。 目的: 易于理解，维护，扩展和重用 3 GRASP模式

13、控制器，创建者，信息专家构建核心体系架构，解决高风险问题，完成绝大部分需求的定义，并估计并估计总体计划和资源，保证架构，需求和计划足够稳定，风险被充分规避，确定和解决项目中所有与架构密切相关的风险，从与架构密切相关的场景中确定一个基准体系架构，产生一个达到产品级质量水准的演化性原型，也可以是一个或更多个探索型抛弃型原型，能够展示基准的体系架构以合理的价格和合适的时间支持系统需求，建立一个支持环境 2. 核心活动: 尽快定义和验证体系架构，并确定体系架构基线 细化设想 为构造阶段建立详细的迭代计划并建立基线 细化开发用例并将其部署到开发环境中 细化体系架构并选择组件 3. 关键思想和实践 实行短

14、时间定量、风险驱动的迭代，及早开始编程，对架构核心和风险部分进行适应性设计，实现和测试，尽早，频繁，实际的测试，基于来自测试，用户，开发者的反馈进行调整，通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次 4. 制定迭代计划: 通过风险、覆盖范围和关键程度组织需求和迭代。 风险：技术复杂性；其他因素 覆盖性：在早期迭代中，系统中主要的部分都有所涉及 关键性：具有高业务价值的功能 在每个迭代前将用例和特征进行排序 迭代单位：(1)用例；(2)场景 5. 细化阶段的制品: 领域模型，设计模型，软件架构文档，数据模型，用例示意板，用户界面模型 6. 领域模型(Domain Mode

15、l) 领域模型是对真实世界中概念类的表示，而不是软件对象的表示。它不是用来描述软件类、软件架构领域层或有职责软件对象的一组图。 领域模型用一套类图表示，但类没有操作。领域模型可以显示：领域对象或者概念类；概念类之间的关联；概念类的属性 概念类来源：现实对象；业务对象；过程对象。 9. 操作契约 通过领域模型中的对象的状态变换(实例创建或删除;属性修改;关联形成或者打破)，定义了系统操作执行后的详细的系统行为. 契约CO2: enterItem 操作 : enterItem(itemID: ItemID, quantity: integer) 前提: There is a sale underw

16、ay 后置条件: 一个SalesLineItem的实例sli被创建；Sli与当前的 Sale 对象相关联；sli.quantity的数值被赋值，依据itemID的匹配， sli 与ProductSpecification相关联 第六章 从需求到设计 1. 软件的逻辑体系结构 逻辑架构是软件类的宏观组织结构，它将软件类组织成包，子系统和层等。 层：对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层。 常见的层： 用户界，应用逻辑和领域对象，技术服务 典型的分层模式 2. 软件架构 架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统的接口的选

17、择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。 3. 分层设计模式 系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰内聚的关注分离。较低的层是低级别和一般性服务，较高的层则是与应用相关。 ，高度内聚，低耦合 4 命令查询分类原则 CQS是针对方法的经典 OO 设计原则 Meyer88 。该原则指出，任何方法都可能使如下情况之一： 执行动作的命令方法，这种方法通常具有改变对象状态等副作用，并且是 void 的。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。 一个方法不应该同时属于以上两种类型。 5 对象的可见性 可见性Visibility 是对象看到或引用其它对象的能力. 为了使发送者对象能够向接收者对象发送消息，发送者必须具有接收者的可见性，即发送者必须拥有对接收者对象的某种引用或指针 属性可见性: B是A的属性 参数可见性: B是A方法中的参数 局部可见性: B是A中方法的局部对象 全局可见性: B具有某种方式的全局可见性