一、认识UML
UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。
UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言（UML）是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。
在UML系统开发中有三个主要的模型：
功能模型
从用户的角度展示系统的功能，包括用例图。
对象模型
采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图、包图。
动态模型
展现系统的内部行为。 包括序列图、活动图、状态图。、
二、对象
1. 定义
有自己标识的任何东西，也可以说任何一个有幸或无形的事物。
一件事、一个实体、一个名词等
2. 属性
各种标识信息
如名称、编号等等
3. 行为
可以执行的各种操作或者行为信息
如打印、行走、跳、叫等等
4. 描述对象
通过UML对象图进行描述
5. 封装
将对象的相关属性、行为封装到一个类中。
是防止程序员互相干扰的一种方式
6. 关联和聚会
关联
关联是一种弱连接，可以是一部分但并不是完全依赖的
如汽车、司机、一个乘客的或另一个乘客的关系
聚合
把对象放在一起形成一个更大的对象，形成了聚合。
整体对部分有很强的依赖
如电视机的配件，取出来还是配件，但是电视机没了配件就无法使用了
7. 图和树
树
层次结构的另一个名称
通常将聚合表示为树
图
对象之间的任意集合
常常用来标识关联
8. 链接和可导航性
链接就是各个对象图中的连接
通过添加箭头可以进行导航，标识一个对象指导另一个对象在哪
9. 消息
每个对象都至少会与另一个对象建立联系。
孤立的对象对任何人来说都没有意义。
对象建立联系后就可以进行协作，执行更复杂的任务。
对象间协作时通过相互发消息进行写作。
10. 启动操作
对象 接收消息后执行某个操作，即消息启动操作
11. 协作示例
对象与对象之间的消息交互
消息回应
消息参数
12. 面向对象程序的工作原理
通过创建对象，然后连接在一起，让他们通过消息彼此协作。
第一个消息通常有main函数担任，也就是程序入口点（entry point）
13. 垃圾收集
当对象的生命周期结束后采取措施清理他们。
具体语言不一样，有的语言有垃圾收集器，有的没有
C++没有垃圾收集器，需要使用“智能指针”，当对象生命周期结束后删除对象。
14. 类
封装一组对象的公共属性
类的层次
层次结构公共名称
继承
火车继承了陆上交通工具的特性
一般化/具体化
火车比陆上交通工具更具体，路上交通工具比火车更一般化
父类/子类
陆上交通工具是火车的父类，火车是路上交通工具的子类
超类/子类
陆上交通工具是火车的超类，火车是路上交通工具的子类
基类/派生类
陆上交通工具是基类，火车是派生类
15. 类定义的内容
类名
在代码的其他地方引用类
字段
类对象存储的信息
构造函数
对象初始化
消息
使用对象的方式提供其他对象
方法，如getName（）之类的
操作
告诉对象如何操作
方法中的具体执行语句
注释
代码的注释，用来告诉程序员如何使用或维护（编译器会自动忽略）
16. 共享数据和共享操作
开放的公共属性或方法
17. 类型
数据类型或者各种类
18. 术语
属性
一小段信息
如颜色、高度、名称等等
字段
对象内部的指定值
操作
一段执行代码
方法
操作的同义词
消息
从一个对象发送到另一个对象的请求
如方法名代表的就是消息
调用
执行操作
执行
调用的同义词
关联
两个对象之间的直接或间接连接
聚合
强关联，隐含某种层次结构
复合
强聚合，部分在整体的内部，整体可以创建和销毁部分
接口
对象理解的一组消息
协议
通过网络传消息的认可方式
行为
对象所有操作的集合
19. 重用代码
重用系统中的函数
重用对象中的方法
重用系统中的类
在系统之间重用函数
在系统之间重用类
在所有的系统之间重用类
示例
函数库
类库
设计模式
框架
三、继承
1. 引言
子类继承超类的所有字段、消息和方法（以及断言）
2. 设计类层次结构
3. 给类层次结构添加实现代码
4. 抽象类
至少有一个抽象方法的类
抽象方法可以是该类本身的方法，也可以是从超类继承来的。
优点
允许更丰富、更灵活的建模
可以共享跟多的代码，因为可以编写具体的方法来使用抽象的方法。
5. 重定义方法
原因
继承的方法是抽象的，需要具体化
子类中的方法需要完成一些额外的工作
可以为子类提供更好的实现代码，更高效或更准确
6. 实现栈类
使用继承实现栈
直接继承类似List的类
使用复合实现栈
将List放于Stack内
继承和复合
继承
优点
自然的
优雅的
允许编写一般的代码，便于复用
缺点
很难做的很好
在发现设计中的不足时很难改变
客户程序员很难理解
层次结构会泄露给客户代码，也很难改变
复合
优点
较容易开发
较容易改变
客户容易理解
不会泄露给客户代码
7. 多重继承
优点
非常强大
允许私有继承
更接近真实情况
允许混合继承
缺点
比较复杂
导致名称冲突
导致重复继承
编译器更难编写
运行时系统更难编写
8. 使用继承的原则
不要过度使用
不要认为必须使用继承，甚至总是使用继承
继承可以使用复合或者属性替代
类应该是其超类的一个类型
类应该是其超类的扩展
四、类型系统
1. 引言
类型系统是一个简单的概念
他是一组禁止误用值（原型和对象）的规则
确保提供代码的某些说明
提高运行时系统的性能
2. 动态和静态类型系统
3. 多态性
多态变量
多态消息
4. 动态绑定
定义：在运行期间把消息关联到方法上
使用UML依赖（dependency），即为封口的虚线箭头
5. 多态性规则
使用尽可能搞得抽象级别来编程
应确保，只要可能，每个类的类型都是隐藏在引用与所有相关类的一般消息中
6. 类型转换
7. 显示类型转化
8. 使用模板进行泛化
泛型的使用
五、软件开发的方法学
1. 引言
学习方法学的必要性
方法学有助于对编码设置规则
即使只是了解方法学的基本步骤，也能增进对问题的理解，提高解决方案的质量
编写代码知识软件开发的其中一个活动
在每个阶段，方法学都指定了下一步的工作，不必为下一步做什么而烦恼
方法学有助于编写除扩展性更高、可靠性更高、更易于调试的代码
文档说明
等待时间少了
工作能及时交付，且不超过预算
用户、销售员、经理和开发人员之间有更好的交流，开发更有序，误解和浪费资源的情况也比较少
可重复性
更准确的成本
优秀的方法学解决的问题
规划：确定需要做什么
调度：确定完成工作的时间
分配资源：估计和获得人力、软件、硬件和其他需要的资源
工作流：较大开发工作中的子过程（如体系结构，给问题域建模，规划开发过程等
活动：工作流中的各个任务
测试组件
绘制类图
详细列出使用情况等
任务：方法学中由人完成的部分
开发人员
测试人员
销售人员
等
制品：开发成果
软件
设计文档
培训计划
手册等
教育：如有必要，培训人员，以完成他们的任务，确认最终用户的如何学习使用新系统的方法。
2. 软件开发中的经典阶段
需求
什么是我们的上下文
要达到什么目的
分析
要处理什么实体
如何确保由正确的实体
设计
如何解决问题
在完成的系统中要什么硬件和软件
如何实现解决方案
源代码和支持文件有哪些
规范
哪些规则控制着系统组件之间的接口
可以去除模糊，确保正确吗？
实现
如何编写组件，复合规范的要求
如何编写漂亮的代码
测试
完成的系统满足要求吗？
可以攻破系统吗？
部署
系统管理员必须做什么？
如何培训最终用户？
维护
可以找出和更正错误吗？
可以改进系统吗？
3. 软件工程和瀑布方法学
4. 新方法学
螺旋式方法学
迭代式方法学
递增式方法学
合并方法学
5. 面向对象的方法学
UML、RUP和XP
统一建模语言UML
基于UML的螺旋式，迭代式，递增式方法，RUP（Rational Unified Process）
极限编程XP（extreme programming）
用例图（use case diagram）
用例是对客户、用户或系统谁用另一个系统或业务的方式的惊天描述
类图
显示了在业务或系统本身中存在哪些类
通信图
通信图显示了对象之间的协作
部署图
显示了已完成的系统如何部署到一台或多台机器上
类图（设计级别）
更详细，使用更多的可用表示法
顺序图（时序图）
显示了对象之间的交互
六、收集需求
1. 引言
两个目标
检查业务上下文
开发软件的原因
理解业务
描述系统需求
系统功能
约束条件
性能
开发成本
资源
系统需求
功能需求
必须完成的工作
非功能需求
其他需求，如客户自定的浏览器，界面等
2. 系统的诞生
从某个位置开始
顾客可能提供了详细的文档
专用布局和目录
也可能只提供了任务概述
新业务的简短概述
3. 用例
开始于一个参与者
之后是业务或系统
最后返回到参与者
每个用力的作用都应是参与者的价值
4. 业务说明
标识业务参与者
编写项目术语表
标识业务用例
在通信图中演示用例
在活动图中演示用例
5. 开发人员的说明
系统用例模型
参与者表（带有描述）
用例列表（带有描述）
用例图
用例细节（包括所有相关的非功能需求）
用例调查
辅助需求（不符合任何用例的系统需求）
用户界面草图
改进的术语表
用例的优先级
使参与者特殊化
用例的关系
特殊化
继承
包含
一个用例有第二个用例提供的步骤，该用例就包含第二个用例。
源用例没有目的用例就不能工作
包含在其他用例中的用例可以独立存在
标识为箭头开放的虚线，从包含的用例指向被包含的用例，标上关键字<<include>>
扩展
一个用例给第二个用例增加步骤，即扩展第二个用例。
源用例即使没有目用例也能工作的很好
拓展另一个用例的用例通常只能作为扩展的用例存在。
标识为箭头开放的虚线，从扩展的用例指向被扩展的用例，标上关键字<<extend>>
UML中带有开放箭头的虚线标识依赖性，但在用例图中，说的是用例关系，而不是依赖性。
系统用例的细节
用例号和标题
用例是否为抽象的
与其他用例的关系
前提条件（执行用例前必须满足的条件）
步骤（假定满足了前提条件）
后置条件（在完成用力后保证满足的条件）
异常路径和这些情况下应该做什么
与这个用例相关的非功能需求
前提条件、后置条件和继承
一个用例特殊化另一个用例是，会继承父用例时，会继承父用例的前提条件，作为起点。子用例添加的新前提条件只会弱化继承的前提条件（使用or合并）
对于后置条件，子用例的起点就是父用例的后置条件。子用例添加的新后置条件，只能强化继承的后置条件（使用and合并）
子用例添加的前提条件和后置条件对父用例的前提条件和后置条件没有影响。
辅助需求
用户界面草案
系统用例的优先级
按照实现的优先级给系统需求分级，尤其时在递增开发过程中。
七、分析问题
1. 引言
分析是找出系统要处理什么的过程，而不是确定如何处理的过程
2. 为什么要进行分析
分析可以防止在cedilla理解问题之前设计解决方案。
即使有了系统用例模型，对问题的理解仍是不全面的，因为用例关注的是外部
用例处理的是参与者和系统边界之间的交互操作-系统本身是一个黑盒子。
3. 分析过程概述
步骤
1. 使用系统需求模型查找候选类，以描述与系统相关的对象，并在类图上建立他们
2. 确定类之间的关系（相关、聚合、复合、继承）
3. 确定类的属性（对象的已指定的简单特性）
4. 检查系统用例，确定已有的对象支持他们，在检查过程中微调类、属性和关系
5. 需要时更新术语和非功能需求-用例本身不需要更新，但可能需要某些更正
一般情况下，不要给客户展示对象操作和通信图。
4. 静态分析
确定类
标识类的关系
绘制类图和对象图
绘制关系
关系
继承
实线上的白色箭头从子类指向超类
聚合
带有一白菱形的线条
复合
带有一黑菱形的线条
关联
未修饰的线条
多重性
除继承外的关系，在两端标识参与关系运行时对象的数量（关系中的多重性）
n
表示n
m..n
m到n范围内的任意数值（包含m和n）
p..*
从p到无从大的任意数值
*
0..*的缩写
0..1
可选
属性
属性
对象的一个特性
如大小、位置、名称、价格、字体等等
关联类
有形对象和无形对象
错误的建模
大量没有用的属性
多余的冗余信息
正确的建模
分离有形概念和无形概念
好的对象
5. 动态分析
进行动态分析的原因
确认类图时完整、正确的
相信当前的模型可以在软件中实现
验证最终系统上用户界面的功能
绘制用例的实现过程
边界、控制器和实体
参与者
边界
实体
对象
控制器
封装了复杂或凌乱过程的系统内部对象
通信图中的元素
给类添加操作
职责
状态建模
八、设计系统体系结构
找出体系结构，为所有用例支持实际的，有效的解决方案
系统设计中的步骤
系统拓扑
硬件和过程如何在网络上分布
选择技术
编程语言
数据库
协议等
设计并发策略
并发意味着事情同时发生，多过程、用户、机器
软件必须能 协调这些事情
软件安全策略
各个安全方面的正确处理和控制
选择子系统部分
开发若干个软件，然后确保这些软件可以有效的进行通信
把子系统分解为层或其他子系统
每个子系统一般都需要进一步分解为可管理的块，然后才能进行详细设计
决定机器、子系统和层如何通信
通信策略通常时其他步骤的一个副产品
选择联网的系统拓扑
三层体系结构
分解重要的部分
使用正确的机器完成工作
改进性能
改进安全性
保护投资
灵活
可以容纳不同类型的用户
个人计算机
网络计算机
互联网和万维网
内联网
外联网和虚拟私人网络
客户机-服务器与分布式体系结构
用UML描述网络拓扑
主机用UML关键字<<device>>表示
并发设计
设计优秀的并发系统的外观和操作方式与单用户版本没有区别
业务服务对并发用户和单用户时相同的
为了确保业务对象的并发操作的安全，只需田间消息和支持对象；因此，业务消息（和相关的属性）可以单独设计
安全设计
数字加密和解密
一般安全规则
防止未经授权就访问服务器，无论五一还是恶意
界定内部网络的敏感信息
预期公司交易的业务信息
业务策略
个人信息
信用引用机构的信息
与国家安全相关的信息等
防止盗取导出的信息
确保在内联网外部传递的信息只能由指定的接收者读取
保护员工和顾客的密码
防止服务器代码访问不需要的资源
防止客户机代码访问不需要的资源
防止未经授权就访问客户的资源
防止客户受到无意的上海
分解软件
系统和子系统
业务应有许多不同的系统，每个系统都由不同的开发小组实现
通过设计优良的接口以定义明确的受控方式来传送
层
单层系统的层
两层和三层系统中的层
转换层
持久层
位于业务层与数据库层之间
去除了业务层对所使用的存储机制的依赖
层中的消息流
事件
使用事件的消息流
九、选择技术
1. 引言
选择技术可以做出正确的选择，同时确定对特定记录的独特特性的依赖程度。
2. 客户层技术
多层系统上运行在客户机上的软件
邮件、HTML、js、JAVA等
3. 客户层到中间层的协议
HTTP
Secure Sockets Layer,SSL
Remote Method Invocation, RMI(远程方法调用)
专用协议
IMAP
电子邮件
AIM
AOL即使消息传输
NNTP
USENET新闻
HTTP/CGI
HTML窗体
FTP
文件传输
Telnet
远程登陆
Subtopic
通用协议
TCP/IP
低级传输，也成为套接字
JRMP
用于JAVA对JAVA的通信
IIOP
用于CORBA通信，类似月RMI，但由多种实现语言
4. 中间层技术
服务器应用程序一般时多线程的代码，为高通过量设计的
服务器应用程序监听某些客户连接的端口
5. 中间层到数据层的技术
在中间层上包含数据库-客户代码，一边访问运行在数据层上的DBMS
6. 其他技术
身份验证
XML
事件和消息
SOAP
Web服务
7. 一般前端配置
HTML/CGI和脚本
HTML/CGI和服务小程序
RMI
CORBA
公共对象请求代理程序体系结构
EJB
8. 后端配置
9. JAVA电子商务配置
10. UML包
组合相关的类
包可以用于表示
层
子系统
可重用的库
框架
应一起部署的类
...
十、设计子系统
1. 引言
把概念性的分析模型装换位可实现的类
2. 把分析的类模型映射为设计的类模型
映射操作
变量类型
字段的可见性
访问器
映射类、属性和复合
映射其他类型的关联
一对一关联
一对多关联
多对多关联
关联类
通用标识符
3. 使用关系数据库实现存储
数据库管理系统
DBMS用于
使用数据定义语言（Data Definition Language，DDL）创建一个模型，用来描述要从存储的数据
使用数据操作语言（Data Manipulation Language，DML）添加、删除和更新数据库中的数据
使用数据库查询语言（Data Query Language,DQL)从数据库中检索数据
关系模型
表
健
把对象模型映射为关系模型
映射实体类
映射关联
一对一关联
一对多关联
多对多关联
关联表
映射对象状态
4. 最终确定用户界面
以用例为指导
简单
使用选项卡
使用向导
避免使用多个窗口
5. 设计业务服务
使用代理和副本
给业务服务分类
会话标识符
业务服务的实现
6. 使用模式、框架和库
7. 事务
保守并发和开放并发
使用事务和对象的一般规则
组织对象和访问路径，以减少重叠
使用主键，是数据库访问都有各自的主题
使事物尽可能短
上层中的事务
处理多个活动
控制多个任务
控制多个线程
线程安全
不变性
固定值
JAVA中的同步
十一、可重用的设计模式
1. 引言
1.1. 设计模式使开发人员避免重复的一种方式。
1.2. 模式简史
1.3. 目前的软件模式
2. 模式模板
3. 常见的设计模式
3.1. 观察器模式
定义对象之间的一对多依赖关系，当一个对象改变状态时，它的所有依赖对象都会自动获得通知。
3.2. 单一模式
确保类只有一个实例，并提供访问它的一个全局点。
3.3. 多重模式
3.4. 迭代器模式
为顺序访问集合对象的元素提供一种方式，且不爆露其底层表示法。
3.5. 工厂方法和抽象工厂
为创建对象而定义接口，但让子类确定实例化哪个类。
工厂方法允许类把实例化推迟到子类。
3.6. 状态模式
允许对象在其内部状态变化时改变其行为。
对象开起来会改变其类。
3.7. 门面模式
为子系统中的一组接口提供统一的接口
门面模式（Facade）定义了使子系统易于使用的高级接口。
3.8. 适配器模式
把类的一个接口口转换为另一个客户机需要的接口。
适配器允许接口不兼容的类一起工作。
3.9. 策略模式和模板方法
定义一系列算法，封装每个算法，使他们可以交互，策略允许算法随使用他的用户的不同而不同。
3.10. 次轻量级模式
使用共享来有效的支持大量细化的对象
次轻量级模式不一定使100%共享的。
3.11. 复合模式
把对象复合到树结构中，表示部分-整体层次结构。
复合模式允许客户机统一的处理各个对象和对象的复合。
3.12. 代理模式
为另一个对象提供代理或占位符，以控制对它的访问。
4. 使用模式
5. 发现、合并和调整吗模式
十二、指定类的接口
1. 引言
2. 规范的定义
3. 正式规范
4. 非正式规范
5. 动态检查
6. 面向对象的规范
OCL
7. 按合同设计
合同和继承
减少错误检查代码
履行合同
应用程序防火墙
十三、不间断的测试
1. 引言
在开发过程中测试代码
优点
提高软件质量（测试人员越多越好）
降低测试阶段的成本
给程序员展示他们正取得进展（而不仅仅生成代码行）
在测试阶段，减少与程序员相关的错误量
有助于程序员因样式或性能原因而重新组织代码，无需破坏已编写好的代码
2. 测试术语
测试test
错误error
故障fault
失败falure
更正fix
验证verification
有效性验证validation
规范
黑盒子测试
白盒子测试
3. 测试的类型
测试过程
单元测试
完整性测试
系统测试
单元测试
完整性测试
Alpha测试
beta测试
用例测试
组件测试
构建测试
负载测试
渗透测试
应力测试
安装测试
接收测试
衰退测试
说明文档测试
安全测试
衡量标准
4. 测试的自动化
负载工具
测试框架
性能监视工具
衡量标准收集工具
规范检查工具
断言检查工具
5. 准备测试
6. 测试策略
7. 测试内容文章来源：https://www.toymoban.com/news/detail-511825.html
8. 测试驱动的开发文章来源地址https://www.toymoban.com/news/detail-511825.html
到了这里，关于面向对象分析与设计 UML2.0 学习笔记的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
