UML与设计模式原则
UML_Concept
1、UML概述
（1）统一建模语言是一种直观化 明确化 构建和文档化软件系统产物的通用可视化建模语言 它捕捉了被构建系统的有关决策和理解 用来理解 设计 浏览 配置 维护以及控制系统的信息。
（2）UML捕捉系统静态结构和动态行为的信息。
（3）UML还包括用包来分解模型的组织性结构 它允许软件团队将系统分解为可工作的单元 对包之间的依赖进行理解和在复杂的开发环境中管理模型单元的版本。
（4）UML不是编程语言。
UML目标
（5）UML是所有建模人员可以使用的通用建模语言 它基于许多计算机团体的共识 是一种非私有的语言。
（6）UML不是完整的开发方法。
2、UML概念范围
静态结构：精确的模型必须首先定义讨论的各种事物 即应用中的关键概念 它们的内部 特征和相互之间的关系。
动态行为：有两种方式来建模行为 一种是通过与外界交互的对象的生命史 另一种是使 用一系列对象的通信模式 这些相互连接的对象交互实现行为。
实现构造: UML模型对逻辑分析和物理实现均可以表达 一定的构造代表了实现单元 构 件是与一系列接口一致和为其提供实现的物理 可替换的系统组成部分。
模型组织：计算机可以处理大型的模型 但人不可以 大型系统中 建模信息必须划分成 条理分明的单元 以使开发团队可以并发的工作在不同的部分 即使在小型系统中 人类 的理解能力需要模型内容被组织到适度大小的包中。
扩展机构：无论语言的设施多么完备 人们总是需要对其进行扩展 我们对 UML提供了 有限的扩展能力 无需对基本语言进行修改 我们相信它可以容纳日常的大多数扩展需要 UML扩展机制包括版型 约束和标签值。
3、静态视图
静态视图对应用领域的概念建模 以及将内建的概念作为应用实现的一部分 该视图不 描述时间相关的行为 因而是静态的 时间相关的行为由其它视图描述 静态视图的主要 组成部分是类和关系 关联 继承和各种依赖 如实现和使用 类是对应用领域或应用方 案概念的描述 类视图围绕着类组织 其它元素属于或附加于类 静态视图显示为类图
名称的由来是因为它们主要的重点是类的描述。
4、用例视图
用例视图对外部用户 --称为活动者 --所感知的系统功能进行建模用例是用活动者和系统之间的交互来表达 条理分明的功能单元 用例视图的目的是列举活动者和用例显示活动者在每个用例中的参与情况。
设计模式原则
(1)单一职责原则：一个类应该仅有一个引起它变化的原因，一个类应该有自己专门负责的职责且只负责该类，将属于该类的职责归属为此类，在变化时，谁负责哪个方面，一目了然，便于查找以及后期的修改。
典型例证：用户的属性与用户的行为应该分为两个类，在该原则的基础上一个接口在实际应用中可以分为两个接口，同时，根据实际应用的情况，也有将两个有强耦合关系的职责结合到一个接口下使用的情况，但是出于代码健壮性考虑，接口一定要做到符合单一原则，类的尽量做到一个原因引起一个变化。
(2)里氏替换原则：在有关于继承的问题上，有以下四点
1.子类必须完全实现父类的方法。在子类无法完整实现父类方法的时候，则断开继承关系，采用依赖的等关系代替继承的实现。
2.子类可以有自己的个性。我们的理解是子类可以有自己的专属方法，以及行为。
3.覆盖或实现父类的方法时输入参数可以被放大。结论：子类要实现类且不歪曲父类意图则在子类覆写方法时，前置条件要相同或更宽松。
4.覆写或实现父类的方法时输出结果可以被缩小。简单来理解就是子类类型的范围要在父类类型的范围内或从属于父类的类型。
(3)依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
依赖有三种写法：1.构造函数传递依赖对象。2.Setter方法传递依赖对象。3.接口声明依赖对象。
(4)接口隔离原则：因为我们做出这个接口最终的服务对象是要为客户端进行服务，因此我们首先需要将该客户端所需要的接口找出来，不需要的进行删除。
然后就考虑到保证接口的纯洁性，接口要尽量小，且要高内聚，有定制服务，设计有限度。
(5)迪米特法原则：一个对象对其他对象应该有基本的了解，知道它行使什么功能，而需要使用到的类则实行低耦合要求。
1.在写程序时，做到最简单化，无关关联尽量减少。
2.为了降低修改数据所造成的影响，有时需要降低两个方法的耦合性。
3.当一个方法出现在任何地方都可以时，那么就将它放在本类中。
4.类或接口在客户端变更，则服务端也要进行更新。
(6)开闭原则：软件实体应该扩展来实现变化，而不是通过修改原有代码实现变化。
并通过这个原则实现“拥抱变化”，这样不仅完成了想做的修改，同时提高了复用性，可维护性，且符合开发要求。
