统一建模语言UML复习提要.pptVIP

统一建模语言UML 复习提要 UML（Unified Modeling Language） 是一种建模语言，由“基本词汇”和“语法构成”。 定义了建模所需要的基本元素，以及元素之间关系的规则， 以及如何用这些元素和最终绘制图形，建立模型映射现实世界。 创造了一种大家都认同的统一语言。 UML特点 统一 UML用一种统一的语言来覆盖整个软件过程（需求、分析、设计……），让不同的开发团队能顺畅沟通。 可视化 UML通过它的元模型和表示法，把文字等方式很难表达清楚的，隐晦的潜台词用简单直观的图形表达，准确直观的描述复杂的含义。 UML提供了相关元素来建立模型： 参与者 模型信息来源提供者，也是第一驱动者。 是整个建模过程的核心。 代表了现实世界中的“人”。 用例 表示驱动者的业务目标，即想做什么并且获得什么。 代表了现实世界中的“事” 场景、用例场景： 描述这件事是怎么做的，依据什么规则。 代表现实世界中的“规则”。 业务对象模型： 业务对象模型的视图说明在达成业务目标过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。 代表现实世界中的“物”。 UML建模基本过程 从现实世界到业务模型 UML采用用例来捕获现实世界的人要做的事， 再通过用例场景、模型视图将现实世界的人、事、物、规则这些构成现实世界的元素用UML描述出来。 将我们的现实世界映射到了对象世界。 从现实世界到业务模型 从业务模型到概念模型 在业务模型中，我们已经采用了对象视角。 进而将用例所代表的业务过程用“边界”、“控制”、“实体”以及“包”、“组件”等概念替代。 这些概念是可以被计算机理解的抽象化了的对象。 这些计算机可以理解的信息，是从映射了现实世界的业务模型转化而来，同样映射了现实世界。 业务模型到概念模型 从概念模型到设计模型 “边界”、“控制”、“实体”这些对象虽然是计算机可以理解的，但不是真正的对象实例，并不是可以执行的代码。 而从概念模型到设计模型的转化，验证了我们所设计出来的类是正确模拟现实世界的类，是符合需求目标的那些类。 概念模型到设计模型 UML核心元素、核心视图 参与者 是在系统之外与系统交互的某人或某事物。 定义参与者是我们进行抽象的第一步。 在建模过程中出于核心地位。 如何确定参与者 先确定系统边界，参与者位于系统外部。 以下问题可以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？ 参看ppt UML-3中确定参与者的相关例子。 用例 Use Case 是一种把现实世界的需求捕获下来的方法。 通俗的说： 用例就是一件事情（或者说是一个目标），要完成这件事情（或这个目标），需要做的一系列活动。 用例场景 做一件事情可以有很多不同办法或步骤，也可能会遇到各种各样的意外情况， 因此，这件事情是由很多不同的情况的集合构成的， 在UML中称之为用例场景。 一个用例场景就是一个用例的实例。 用例的构成 用例的特征 用例是相对独立的。 用例的执行结果对参与者来说是可观测的和有意义的。 用例必须由一个参与者发起，不存在没有参与者的用例。用例不应该主动启动，也不应该主动启动另一个用例。 用例的粒度 如何确定用例的粒度？ 参看ppt ，不同建模阶段，划分不同的粒度。 如何获取用例？ 参看ppt相关说明。 如何获取业务实体？ 参看ppt相关说明、示例 用例视图 是静态视图的一种。 采用参与者与用例作为基本元素，以不同的视角展现系统的功能性需求。 不同种类的用例视图： 参看ppt UML-4 业务用例视图 业务用例实现视图 概念用例视图 系统用例视图 系统用例实现视图 用例之间的关系： 扩展、包含、精化 类图 如何从用例场景中获取业务实体？ 参看ppt 业务实体 分析类 设计类 类间的关系 关系： 抽象出对象之间的联系，让对象构成某个特定的结构。 类型：具体参考ppt UML-3 关联关系 依赖关系 扩展关系 包含关系 实现关系 精化关系 泛化关系 聚合关系 组合关系 类图的建模围绕着三个层次： 概念层：由实体表达 说明层：由分析类表达 实现层：由设计类表达 随着抽象层次的逐步降低而逐步细化。 包图 包的作用 常用包的版型 包图的应用场合 活动图 活动图描述为了完成某一个目标需要做的活动以及这些活动的执行顺序。 活动图中的基本元素： 参考ppt UML-4 掌握如何对用例场景进行建模 状态图 显示一个状态机，用于对模型元素的动态行为进行建模