uml

UML的作用：

消除了不同建模语言之间的差异

提供了一个客户、需求分析、架构设计、软件实现和运维部署部门之间共同交流的语言

集成了优秀的开发实践成果和经验

UML分类:

静态图：类图，对象图，包图

行为图：状态图，活动图

用例图：用例图

交互图：顺序图，协作图

实现图：组件图，部署图

Rose的四种视图模型

用例视图

用例视图中包括了系统中的所有参与者、用例和用例图，必要时还可以在用例视图中添加顺序图、活动图等

由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图
参与者(Actor)是指存在于系统外部并直接与系统交互的人、系统或设备等。
参与者按是否使用系统核心功能可分为主要参与者与次要参与者

用例之间的关系包括：
       ① 泛化关系(generalization)
       ② 包含关系(include)
       ③ 扩展关系(extend)

逻辑视图
逻辑系统关注系统是如何实现用例中所描述的功能的，主要是对系统功能性需求提供支持，即为用户提供服务方面，系统所应提供的功能。逻辑视图下的模型元素包括类图、顺序图和状态图等
组件视图
组件视图用来描述系统中各个实现模块以及它们之间的关系。组件视图包括模型代码库、执行文件、运行库和其它组件信息，按照内容来划分有包、组件和组件图组成。
部署视图
部署图显示系统的实际部署情况，它是为了便于理解系统在一组处理节点上的物理分布。部署视图中包括进程、处理器和设备。

类图：

类图显示了系统的静态结构，而系统的静态结构构成了系统的概念基础。
类图的组成：名称+属性+操作(方法)
类的名称必须是名词，不需要前缀或后缀，可以多个名称组合，单词首字母大写。正体字表示类可实例化，斜体字说明类为抽象类
类的属性：
可见性：public、protected、private、Implementation
命名方法：首字母小写
属性类型与初始值 
类的操作
可见性：public、protected、private、Implementation
参数
返回类型

类之间的关系

依赖(Dependency)

类一方的改动将引起另一方的变动。这是一种典型的临时关系，代表了类之间的一种短暂的交互。依赖关系在 Java 语言中体现为局部变量、方法的参数或者对静态方法的调用，如工具类，现实生活中人与锤子。

泛化(Generalization)

泛化定义了一般元素和特殊元素之间的分类关系，如果从面向对象程序设计语言的角度来说，类与类之间的泛化关系就是平常所说的类之间的继承关系。如人与男人和女人的关系 。

实现(Realization)

实现是一种类与接口的关系, 表示类是接口所有特征和行为的实现
实现用带三角箭头的虚线表示，箭头指向接口  

关联(Association)

关联关系是类与类之间的联结，它使一个类知道另一个类的属性和方法 ，关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。在 Java 中，关联关系是通过使用成员变量来实现的。 如人与车

聚合：聚合关系描述的是部分与整体关系的关联，描述了“has a”的关系，汽车整车与发动机、座椅的关系

聚合关系是关联关系的一种，是更强的关联关系。
聚合是整体和部分之间的关系，例如汽车由引擎、轮胎以及其它零件组成。
聚合关系也是通过成员变量来实现的。但是，关联关系所涉及的两个类处在同一个层次上，而聚合关系中，两个类处于不同的层次上，一个代表整体，一个代表部分。

组合：组合关系是一种更强形式的关联，整合控制成员的生命周期，如公司与部门的关系

UML类图关系中合成关系是关联关系的一种，是比聚合关系还要强的关系。
代表整体的对象负责代表部分对象的生命周期

关联关系的多重性

在UML中，多重性可以用下面的格式表示：
0..1
0..*（也可以表示为0..n）
1（1..1的简写）
1..*（也可以表示为1..n）
*（即0..n）
7
3,6..9
0（0..0的简写）（表示没有实例参与关联，一般不用）
可以看到，多重性是用非负整数的一个子集来表示的。

对象图：

对象图是类图的一个实例, 用于显示系统执行时的一个可能的快照. 即在某一个时间上系统可能出现的样子. 对象图用带下划线的对象名称来表示对象.

顺序图：

定义 顺序图是显示对象之间交互的图，这些对象之间是按时间顺序排列的。
水平方向 对象维
 垂直方向 时间维

顺序图--建模元素：

顺序图中包括的建模元素有：对象（参与者实例也是对象）、生命线（lifeline）、消息（message）等。
生命线用一条虚线表示, 消息用从一个对象的生命线到另一个对象的生命线的箭头表示. 箭头以时间的顺序在图中上下排列.
异步（asynchronous）消息的发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接收者返回消息或控制。异步消息的接收者和发送者是并发工作的.
返回（return）消息表示从过程调用返回，是可选的，以带箭头的虚线表示

协作图：

协作图是用于描述系统的行为是如何由系统的成分协作实现的图，协作图中包括的建模元素有对象（包括参与者实例、多对象、主动对象等）、消息、链等。

活动图：

活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发），JBPM就是以活动图为基础。

① 活动
② 泳道
③ 分支
④ 分叉和汇合
⑤ 对象流 

活动图--活动：

活动（activity）表示的是某流程中的任务的执行，它可以表示某算法过程中语句的执行.
在活动图中需要注意区分动作状态和活动状态这两个概念.
动作状态是原子的，不能被分解，没有内部转移，没有内部活动、动作状态的工作所占用的时间是可忽略的。动作状态的目的是执行进入动作（entry action），然后转向另一个状态。
活动状态是可分解的，不是原子的，其工作的完成需要一定的时间。可以把动作状态看作是活动状态的特例

活动图：泳道

泳道（swimlane）是活动图中的区域划分，根据每个活动的职责对所有活动进行划分，每个泳道代表一个职责区。泳道和类并不是一一对应的关系，泳道关系的是其所代表的职责，一个泳道可能由一个类实现，也可能由多个类实现。

活动图——对象流：对象流属于控制流，所以如果两个活动之间有对象流，则控制流就不必重复画出了

活动图：分支

在活动图中，对于同一个触发时间，可以根据不同的警戒条件转向不同的活动，每个可能的转移是一个分支（branch）
在UML中表示分支有两种方法，如图8.14所示，这两种标识方法的区别是，右边的活动图采用菱形符号表示分支。

活动图——分叉（fork）和汇合（join）

分支表示的是从多种可能的活动转移中选择一个，如果要表示系统或对象中的并发行为，则可以使用分叉（fork）和汇合（join）这两种建模元素。
分叉表示的是一个控制流被两个或多个控制流代替，经过分叉后，这些控制流是并发进行的；
汇合正好与分叉相反，表示两个或多个控制流被一个控制流代替。

状态图：用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件，以及因状态转移而伴随的动作

基本概念：

状态：指在对象的生命期中的某个条件或状况，在此期间对象将满足某些条件、执行某些活动或等待某些事件。
转移（transition）是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个具体事件发生而且某个特定的警戒条件满足时进入第二个状态。
事件（event）是对一个在时间和空间上占有一定位置的有意义的事情的详细说明。事件产生的原因有调用、满足条件的状态的出现、到达时间点或经历某一时间段、发送信号等。
活动是在状态机中进行的一个非原子的执行，由一系列动作组成 
动作（action）是一个可执行的原子计算。也就是说，动作是不可被中断的，其执行时间是可忽略不计的。

包图：

由包和包之间的关系组成，包的图标就如同一个带标签的文件夹。

包提供了一种用于组织各种元素的分组机制。在UML中，包用来对元素进行分组，并为这些元素提供命名空间。包所拥有的或者引用 的所有的元素称为包的内容 ，包没有实例 

组件图：

用来建立系统中各组件之间的关系，各组件通过 功能组织在一起。

在UML中，组件使用在左侧有两个小矩形的大矩形来表示 

组件图可以用来设计系统的整体构架

部署图：

用来帮助开发者了解软件中的各个组件驻留在什么硬件位置，以及这些硬件之间的交互关系。

节点 ：用来表示一种硬件，可以是打印机，计算机等。节点的标记符号是一个三维框，在框的左上方包含了节点的名称 

通信关联：节点通过通信关联建立彼此的关系，采用从节点到节点绘制实线来表示关联。

OO设计的原则：

对于OO设计，主要是要求丝毫的设计结果要能适应系统做新的需求变化，一旦需求发生变化，整个系统不用做变动或做很少的变动 就可以满足新的需求

开闭原则（Open/Closed Principle,OCP）

指的是一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的，这个原则说的是，在写模块的时候 ，应该尽量使得模块可以扩展，并且在扩展时不需要对模块的源代码进行修改。开闭原则最初是由Bertrand Meyer提出来的，在所有的OO设计原则中，这个原则是最重要的。

为了达到开闭原则的要求，在设计时要有意识地使用接口进行封装等，采用抽象机制，并利用OO中的多态技术。

里氏代换原则（Liskov Substitution Principle, LSP）

Liskov替换原则最早是由Liskov于1987年在OOPSLA会议上提出来的，这个原则指的是子类可以替换父类出现在父类能出现的任何地方。

依赖倒置原则（Dependency Inversion Principle,DIP）

指的是依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体的类。

在面向对象的设计中，依赖关系上下左右好是相反的，即与具体实现有关的类是依赖于抽象类或接口的。

接口分离原则（Interface Segregation Principle,ISP）

指的是在设计时采用多个与特定客户类（client）有关的接口比采用一个通用的接口要好。也就是说，一个类要给多个客户类使用，那么可以为每个客户类创建一个接口，然后这个类使用所有这些接口，而不要只创建一个接口，其中包含了所有客户类需要的方法，然后这个类实现这个接口。

软件开发方法——瀑布模型

瀑布模型也称为生命周期模型，其核心思想是按照相应的工序将问题进行简化，将系统功能的实现与系统的设计工作分开，便于项目之间的分工与协作 ，即采用结构化的分析与设计方法将物理实现与逻辑实现分开。

软件开发方法——原型法

原型法第一步是建造一个快速原型，实现客户或未来用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。第二步则在第一步的基础上开发客户满意 的软件产品。

软件开发方法——RUP

RUP（Ration Unified Process）是IBM Rationals oftware提出的软件工程实施过程，RUP是一种迭代的，以架构为中心的，用例驱动的软件开发方法

极限编程实践：

完整团队：项目的所有参与者（开发人员，业务分析师，测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员 ， 这个场所的墙上随意地挂着一些大幅的显著图表，以及能够显示项目进度的其它的一些东西。

计划游戏：计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现 的特性

客户测试：作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。

简单设计：团队保持设计恰好和当前的系统功能想匹配，它通过了所有的测试，不包含任何重复，表达出了编写者想要表达的所以东西，并且包含尽可能少的代码 

结对编程：所有的产品软件都是由两个程序员，并排坐在一起在同一台机器上构建的。

测试驱动开发：程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过 

改进设计：随时改进糟糕的代码，保持代码尽可能的干净，具有表达力。

持续集成：团队总是使系统完整地被集成。

集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码

编码标准：系统中所有的代码看起来就好像是被单独一个——非常值得胜任的人编写的。

隐喻：团队提出一个程序工作原理的公共景象。

可持续的速度：团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑