UML统一建模语言
- 格式：docx
- 大小：2.20 MB
- 文档页数：84
统一建模语言
Unified Modeling Language，5类、13种视图
第一部分 UML概述
为什么建模?
1、在一个现代化的工程中，人们要相互沟通和合作，就必须使用标准的工业化设计语言，用这些语言来对开发产品进行建模。
2、在实际的软件开发过程中，现实世界的复杂性以致用户经常不能精确地理解和描述将要开发的软件系统，建模可以使用户更好地理解需要开发的系统。
3、建模是开发优秀软件的所有活动中最核心的部分，其目的是把所要设计的结构和系统的行为联系起来，并对系统的体系结构进行可视化和控制。
4、建模过程把复杂的问题分解成为易于理解的小问题， 以达到问题的求解。
UML定义
1、UML是用于描绘软件蓝图的标准语言。
2、UML是一种语言，也就意味着它有属于自己的标准表达规则。它不是一种类似Java、C++的编程语言，而是一种分析设计语言，也就是一种建模语言。
3、UML是由图形符号表达的建模语言。
UML能做什么？
制造业、医疗卫生、军事领域......
图示：
要学UML吗？
你应该使用UML吗？是！旧的面向对象符号正在快速消失，新的书、文章将全部采用UML作为符号。如果你正要开始使用建模符号，你就该直接学习UML。－－Martin Fowler
UML 五大类、13种视图
五大类视图：
1、 用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
2、 结构视图：表示系统的静态行为，描述系统的静态元素如包、类与对象，以及它们之间的关系。
3、 行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
4、 实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
5、 环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。
UML 2.0的十三种图：
1、 用例图(用户视图)
2、 类图(结构视图)
3、 对象图(结构视图)
4、 包图 (结构视图，UML2.0)
5、 组合结构图 (结构视图，UML2.0)
6、 时序图(行为视图)
7、 通信图（行为视图，UML1.0 协作图）
8、 定时图 (行为视图，UML2.0)
9、 状态图(行为视图)
10、 活动图(行为视图)
11、 交互概览图 (行为视图，UML2.0)
12、 组件图(实现视图)
13、 部署图(环境视图)
第二部分 UML需求建模
用户视图
1种视图
以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
用例图 Use Case Diagram
1、用例图(Use Case Diagram): 又称为用况图，对应于用户视图。在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。
2、用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。
用例建模主要包括以下两部分内容：
用例图(Use Case Diagram)
用例描述文档 (Use Case Specification)
关系
关联关系
在用例图中，执行者和用例之间进行交互，相互之间的关系用一根直线来表示，称为关联关系(Association)或通信关系(Communication)。
泛化关系
执行者之间可以有泛化(Generalization)关系（或称为“继承”关系）:
1、当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
2、在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
3、泛化关系一般很少使用。
a、
b、
c、
包含关系
描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<
扩展关系
扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。
在扩展（extend）关系中，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。
扩展关系是通过在依赖关系上应用<
步骤
1、识别执行者
执行者——Actor
定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物。
引入执行者的目的：帮助确定系统边界。
思路
思路：
1、谁使用系统？
2、谁改变系统的数据？
3、谁从系统获取信息？
4、谁需要系统的支持以完成日常工作任务？
5、谁负责维护、管理并保持系统正常运行？
6、系统需要和哪些外部系统交互？
7、有没有自动发生的事件？
图例
2、识别用例
用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
用例要点
用例要点：
1、有意义的目标
2、价值结果由系统生成
3、业务语言，用户观点
4、注意用例的命名
5、用例的“粒度”
1、有意义的目标
2、价值结果由系统生成
3、业务语言而非技术语言
4、用户观点而非系统观点
5、用例命名
用例命名：慎用弱动词、弱名词
弱动词：进行、使用、复制、加载、重复
弱名词：数据、报表、表格、表单、系统
会掩盖真正的业务！
6、用例的“粒度”
粒度原则：
用例要有路径，路径要有步骤。而这一切都是“可观测”的。
1、最常犯错误－－把步骤当作用例
a) 把执行者动作当作用例
b) 把系统活动当作用例
2、警惕CRUD（增加、查询、修改、删除）泛滥！
错：
对.
a、也可以把包含复杂交互的路径独立出去形成用例：
7、形式检查
【执行者】使用系统来【用例】
3、绘制用例图
4、书写用例文档
1、用例是文本文档，而非图形；
2、用例建模主要是编写文本的活动，而非制图；
3、用例不是面向对象的，编写用例时也不会进行OO分析；
4、用例是经典OOA/D的关键需求输入。
用例的内容
前置、后置条件
前置条件：开始用例前所必需的系统及其环境的状态
后置条件：用例成功结束后系统应该具备的状态
注意：系统必须能检测到
涉众利益
基本路径
把基本路径单独分离，凸现用例的核心价值。
核心的核心：客户最想看到、最关心的路径
基本路径：
1、只书写“可观测”的（说人话）
2、使用主动语句
3、句子必须以执行者或系统作为主语
4、每一句都要朝目标迈进
5、分支和循环
6、不要涉及界面细节
用例交互四步曲
在步骤中写需求！
用例
1.
2.
3.
4.
