《Thinking in UML》读书笔记 6 : 分析类，设计类，关系，组件，节点

分析类

  官方定义:分析类用于获取系统中主要的“职责簇”，他们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念性简述，则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象--系统的设计类和子系统。分析类是跨越需求和设计实现的桥梁。

   分析类有三种：

   边界类（boundary）

    定义：边界类是一种对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件。并记录系统表示方式中的变更。

    常用场景：

    1.参与者与用例之间应当建立边界类。例如参与者通过一组网页来使用用例的功能。

    2.用例与用例之间如果有交互，应当为其建立边界类。相当于一个门面模式。

    3.如果用例与系统边界之外的非人对象有交互，例如第三方系统，应当为其建立边界类。如网关，soa组件。

    4.在相关联的业务对象有明显的独立性要求，即可能在各自的领域内发展和变化，但又希望互不影响时，也应当为其建立边界类。

   控制类（control）

    控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此他们的行为具有协调性质。

   实体类（entity）

    实体类是用于对必须存储的信息和相关行为建模的类，实体对象用于保存和更新一些现象的有关信息。

  分析类的三高

  1.高于设计实现，在为需求考虑系统实现的时候，可以不必理会复杂的设计要求。如应用的设计模式，系统框架等。

  2.高于语言实现，在需求考虑系统的时候，可以不必理会采用哪一种特性的语言来编码。

  3.高于实现方式，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体的实现方式。

  总结：一方面由于分析的抽象层次较高，基本上停留在“概念”阶段，考虑的信息量要少得多，多以能够让分析工作专注于实现需求上。另一方面也由于分析类的抽象层次较高，概括能力就很强，也就是比设计和实现要稳定。维护稳定的分析类比维护易变的设计类要投入更少的精力，更容易获得一个稳定架构来指导整个软件的开发。

 设计类

   设计类是系统实施中一个或多个对象的抽象；设计类所对应的对象取决于实施语言。

   1.类 ： 类的来源可以是用例实现对系统所需对象的需求，这是为实现业务需求而定义的；也可以是任何以前开发的对象模型，如现有的系统模块，采用的软件架构等。

   2.属性：属性是对象的特征，属性同时表明了对象的唯一性。在为对象建里属性的时候需要考虑的一个指导原则是只有对象单独具有的特征才能为其建模属性，否侧，应该是类与类的关联关系或者聚合关系。

   3.方法：访问对象或影响其他对象的属性或关系的唯一途径就是方法。

   4.可见性：类的属性和方法都有相似的可见性，每种语言各不相同。（公有，私有，保护，实施）

 关系

   关系式非常重要的语义，它抽象出对象之间的联系，让对象构成某个特定的结构。

  关联关系（association）

  A—B，它描述不同类的对象之间的结构关系，就像A知道B的存在一样。

  依赖关系（dependency）

  A----->B 它描述一个对象的修改回导致另一个对象的修改这样的关系。犹如B的修改会导致A的修改。

  扩展关系（extends）

  它特别用于在用力模型中说明向基本用例中的某个扩展点插入扩展用例。就像一个用例的“支流”一样。比如，你在接电话的时候，这时候有另一通电话打进来，这时候你而已选择保持通话去接这个刚来的电话，这个保持通话就是一个扩展，它是“可选”的，这与包含关系有区别。

  包含关系（include）

  它和扩展关系的唯一不同就在于他是必选的，例如你去银行办理业务的时候，无论是取钱，转账，查看账户资料的时候，都必须经过一个身份的验证，这一个验证的过程就是一个包含用例。

  实现关系（realize）

  用于在用例模型链接用例和用例实现，说明基本用例的一个实现方式。例如交纳电话费这个用例，可以选择营业厅交费，银行交费，预存话费，这3种方式都是交纳电话费的一个实现途径，所以他们是实现用例。

  精化关系（refine）

  用于用例模型，精化关系表示由基本对象可以分解为更明确，精细的子对象，这些子对象并没有增加，减少，改变经本对象的行为和属性。例如预存话费这个用例，可以分解为开立账户，存入现金，转账，支付划账等精化用例。

  泛化关系（generalization）

  泛化关系表示面向对象里面的继承。

  聚合关系（aggregation）

  用于类图，表达整体部分的语义，且部分可以单独存在，例如一个部门由许多人员构成，但部门解散了，人员依然存在。

  组合关系（composition）

  和聚合关系不同，如果整体部分消失，分部也消失，不能单独存在。

  组件

  组件式系统中实际存在的可更换部分，它实现的特定的功能。符合一套接口标准并实现一组接口。组件代表系统中的一部分物理实施，包括软件代码或其他等价物。

  一个组件应当具有如下的特点：

  1.完备性：组件包含一些类和缄口，一个组件应当能够完成一项或一组特定的业务目标。从调用者的角度来看，他不需要调用多个组件来完成一个业务请求。

  2.独立性：组件应当是可以独立部署的，与其他组件无依赖关系。最多仅保持关联关系。

  3.逻辑性：组件是从软件设计的观点来定义的，而不是从需求中直接导出的。组件的定义是为了规划系统结构，将一个复杂的系统分解成一个个具有完备功能的，可独立部署的小模块。

  4.透明性：组件的修改应当只涉及组件的定义以及组件中所包含的类的重新制定，而不应当导致类的修改。

 

  节点

  节点是带有至少一个处理器，内存以及可能还带有其他设备的处理元素，在实际工作中，一般说来服务器，工作站或者客户机都可以成为一个节点。节点是应用程序的部署单元。