UML 图总结

极限编程，敏捷开发

    只保留必不可少的文档，先实现功能再重构，但是要写单元测试，拥抱变化（心态）

文档最重要的是接口。

UML图用来无歧义的沟通交流架构，必须是粗粒度的，。

对于一个形式主义者，很容易陷入大量 UML 的细节之中，代价。

类图是静止的，很难看下去，时序图更易吸收。把握主线，不必面面俱到，不可掌控

1、想看懂开源项目的所有细节是不可能的，应该把握整体的骨架,java会随着应用发展，变得越来越大，越来越复杂，如c++一样，不要过多强调特性。任何东西都需要代价。

2、任何一个项目也是会变得越来越大，不要追求精简，这是不现实的。比如structs2，很多冗余代码，这是历史原因，客观原因,就算推翻重来，N年以后还是会冗余。

“+”表示Public

“#”表示protected 

“-”表示private

依赖 A - - - -> B ,类A使用到类B，是种偶然关系，弱关联关系，在构建领域对象时，并不知道这种关系。

A <- - - - - -  B调用返回

关联 A -------> B ,类B作为类A的一个属性出现，构建领域对象时，知道这种关系。

聚合 A 1 <>-------> 3 B,关联的一种强化。也是关联关系。A包含B

继承 A ---------|> B

实现 A - - - - -|> B

依赖是方法级别的，其他是类级别的。关联，聚合，组合是一致的，只能从语义级别来区分

你和你的心脏之间是composition关系（心脏只属于你自己），部分的生命周期不能超过整体的生命周期

你和你买的书之间是aggregation关系（书可能是别人的）

你和你的朋友之间是association关系（关联对象一般是平等的）

依赖是A类中的某个方法调用B类（一般B作为参数传入）

1，定义用例-->定义领域模型-->定义交互图-->定义设计类图

        

2，领域模型

3，

        不要试图描述所有的细节-要不要画出来---取决于你想表达什么

        迭代增量模型就是一个不断沟通的过程

        低耦合--降低与不稳定对象之间的依赖        

        servlet对象由容器tomcat创建

        

        聚合-A包含B，但B不能包含A,A销毁后，B可以存在；如汽车和轮子

        组合-A包含B，但B不能包含A,A销毁后，B也销毁；如，DB中表和字段

java3件宝

        1，框架ssh

        2，模式，对经验的总结，问题的解决方案，最重要的是“提出问题”

                分析模式，设计模式

        3，领域模型(domain model)

                业务里面的词汇，概念模型，词汇文档

        

UML,之前有上百种建模语言，多样性，UML不是万能的。UML仅仅是一组符号、一个标准的图形表示法。

整个Rational Unified Process流程都是"用例驱动"的

五类图（共9种图形，当然可以增减UML图种类以满足需求）来定义：　

比如类图拆分成：类功能图，类细节图，类名字图用于活动图。

　　第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。　

　　第二类是静态图 (Static diagram)，包括类图、对象图和包图。

                类图描述的是一种静态关系，在系统的整个生命周期都是有效的。　

                        关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。

　　                对象图是类图的实例，因此对象图只能在系统某一时间段存在。　

　　                包由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。　

　　第三类是行为图（Behavior diagram）

                状态图是对类图的补充，并不需要为所有的类画状态图。

　　          活动图描述约束关系，活动图可以归并一组顺序图，活动图--泳道、分支、合并　

状态图描述一个对象的状态转换，

活动图/流程图描述了一组顺序的或并发的活动，面向过程，一组对象参与。

　　第四类是交互图（Interactive diagram）

                顺序图显示对象之间的动态合作关系，强调时间和顺序

                协作图描述对象间的协作关系，强调上下级关系

　　第五类是实现图 ( Implementation diagram )

                构件图描述代码部件的物理结构及各部件之间的依赖关系。

                部件图有助于分析和理解部件之间的相互影响程度。　

实际中(1+4个)

        静态图：类图

        动态图：顺序图/协作图-->用例图-->活动图-->状态图

        #####个人观点：用例图--类图--状态图--活动图--顺序图#####

        

        1，类图：

                1，实体类（领域模型）-记录数据-侧重内部细节

                2，控制类-侧重方法

                3，边界类，界面类-与用户打交道的

        2，顺序图-只考虑正常最主要路径-设计阶段

                发起者actor

                只画出主路径（主场景）即可

        

        3，用例图：

                1，参与者actior-程序员不是最终用户

                        系统外部的（系统边界）

                        如果商店是系统边界，那么actor就是客户（购买者）

                        如果终端是系统边界，那么actor就是收银员

                2，场景

                        主场景（成功），交替场景（失败）

                3，用例-一组主场景和交替场景的组合，不是用例图

                用例详述：(文字文档）

                        用例描述

                        参与者

                        前置条件：Actor访问系统

                        后置条件：Actor查询到所要的零件

                        基本路径（10步左右）

                        扩展点（可能非常重要，可能50步以上）

                        补充说明

                        ##注：

                        用例名-从用户出发，用行业术语，非计算机术语

                        

                如何发现用例

                        1，选择系统边界

                        2，确定actor(多少部门，岗位)

                        3，确定actor的目标

                        4，定义用例

                

                用例关联的术语

                        1，包含关系include

                        2，扩展关系extend

                        3，泛化关系

        

        4，活动图-类似-流程图

        5，状态图

        

OOD5大原则

        SRP-单一职责原则

        OCP-开闭原则

        LSP-liskov替换原则

        DIP-依赖倒转原则

        ISP-接口隔离原则

        

继承复用 PK 组合复用

 组合是通过引用已有类（一般为抽象类,父类）或接口来实现复用的组合在运行时通过多态可以动态替换被组合的对象。

果继承得来的某个方法在子类中不适用，这时就需要重写该方法。而这样又很有可能违反LSP设计原则

当子类B对父类A的依赖性是稳定的，用继承不会有任何问题。否则用组合那只要写个A的子类A1   在实例B的时候传入不同的A就行

  实际上应该很少去继承一具体的类，大多数时候应该考虑继承抽象类和去实现接口。类的复用基本是三种方式，组合，代理，继承。应该使用组合还是继承，判断的标准应该是新类是否需要向上转型，也就是说新类是否需要复用接口。

思考一个问题的时候，目的是很重要的，必须不断问自己的目的是什么。同样为的是复用类，采用不同的方法会有不同的效果。但是首要考虑的应该是降低类的复杂度，这也是OOP思想的出发点。

  向上转型，A的对象可访问B从A中继承来的和B复写A的方法。其它的方法都不能访问。即使是A 中的私有成员方法（这句？）。

然后子类Truck,Plane,Train分别实现cost方法

再构造一个工厂类为客户制造子类实例http://zhidao.baidu.com/question/72034787.html?fr=ala0

然后子类Truck,Plane,Train分别实现cost方法

再构造一个工厂类为客户制造子类实例

public class ConveyanceFactory{

 public static Conveyance getConveyance(String which){

  if(which.equils("Truck")){return new Truck();}

  else if(which.equils("Train")){return new Train();}

  else if(which.equils("Plane")){return new Plane();}

  else{return null;}

 }

} 

服务程序的方法实现：

public double transportCost(String type,Double weight,Double space){

Conveyance c;Double cost;

c = ConveyanceFactory.getConveyance("type");

cost = c.cost(weight,space);

return cost;

}

父类--》子类是向下转型，强制转换。

子类--》父类是向上转型，自动转换。

----------------复用

继承复用 PK 组合复用

 组合是通过引用已有类（一般为抽象类,父类）或接口来实现复用的组合在运行时通过多态可以动态替换被组合的对象。

果继承得来的某个方法在子类中不适用，这时就需要重写该方法。而这样又很有可能违反LSP设计原则

当子类B对父类A的依赖性是稳定的，用继承不会有任何问题。否则用组合那只要写个A的子类A1   在实例B的时候传入不同的A就行

  实际上应该很少去继承一具体的类，大多数时候应该考虑继承抽象类和去实现接口。类的复用基本是三种方式，组合，代理，继承。应该使用组合还是继承，判断的标准应该是新类是否需要向上转型，也就是说新类是否需要复用接口。

思考一个问题的时候，目的是很重要的，必须不断问自己的目的是什么。同样为的是复用类，采用不同的方法会有不同的效果。但是首要考虑的应该是降低类的复杂度，这也是OOP思想的出发点。

  向上转型，A的对象可访问B从A中继承来的和B复写A的方法。其它的方法都不能访问。即使是A 中的私有成员方法（这句？）。

然后子类Truck,Plane,Train分别实现cost方法

再构造一个工厂类为客户制造子类实例http://zhidao.baidu.com/question/72034787.html?fr=ala0

然后子类Truck,Plane,Train分别实现cost方法

再构造一个工厂类为客户制造子类实例

public class ConveyanceFactory{

 public static Conveyance getConveyance(String which){

  if(which.equils("Truck")){return new Truck();}

  else if(which.equils("Train")){return new Train();}

  else if(which.equils("Plane")){return new Plane();}

  else{return null;}

 }

} 

服务程序的方法实现：

public double transportCost(String type,Double weight,Double space){

Conveyance c;Double cost;

c = ConveyanceFactory.getConveyance("type");

cost = c.cost(weight,space);

return cost;

}