电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 敏捷思维架构设计中的方法学(11) 精化和合并-1 [打印本页]

作者: look_w 时间: 2018-4-16 22:07 标题: 敏捷思维架构设计中的方法学(11) 精化和合并-1

Context建立架构愿景，为架构的设计定义了主要的设计策略和实现思路。应用分层的原则则对整个的软件进行了结构上的划分，并定义了结构的不同部分的职责。而现在，我们需要对初步完成的模型进行必要的改进。
Problem我们如何对初始架构模型进行改进？
Solution对模型进行改进的活动可以分为精化和合并两种。我们先从精化开始。
首先，我们手头上的初始架构模型已经包括了总原则（参见架构愿景模式）和层结构（参见分层模式）两部分的内容。现在我们要做的工作是根据需求和架构原则来划分不同的粗粒度组件。粗粒度组件来源于分析活动中的业务实体。把具有很强相关性业务实体组合起来，形成一个集合。集合内部存在错综复杂的关系，同时集合向外部提供服务接口。这样的集合就称为粗粒度组件。粗粒度组件对外的接口和内部的实现是相区分的。粗粒度组件的形式有很多，Java平台上的Jar文件、Windows平台上的dll文件，甚至古老的.o或.a文件都可以是粗粒度组件的表现形式。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。一个系统中可能包括会计子系统、库存管理子系统。但是提供会计粗粒度组件或是库存管理粗粒度组件是没有什么意义的。因为这样的粗粒度组件的范围过于广泛，难以发挥重用的价值。
粗粒度组件是可以（可能也是必须）跨越层次的。粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。这样看起来，它所属的轴向和层次的轴向是相互垂直的。
粗粒度组件来源于需求。需求阶段产生的需求说明书或是用例模型将是粗粒度组件开发的基础。在拥有了需求工件之后，我们需要对需求进行功能性的划分，将需求分为几个功能组，这样我们基本上就可以得到相应的粗粒度组件了。如果系统比较庞大，可以对功能组再做细分。这取决于粗粒度组件的范围。过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系，最后的结果也将包含大量的组件和复杂的逻辑。过大的范围，则会造成粗粒度组件难以重用，导致粗粒度组件称为一个子系统。
假设我们需要开发一个人力资源管理系统。经过整理，它的需求大致分为这样几个部分：

组织结构的设计和管理：包括员工职务管理和员工所属部门的管理。
员工资料的管理：包括员工的基本资料和简单的考评资料。
日常事务的管理：包括了对员工的考勤管理和工资发放管理。

对于前两项的功能组，我们认为建立粗粒度组件是比较合适的。但是对于第三项功能组，我们认为范围过大，因为将之分为考勤管理和工资管理。现在我们得到了四个粗粒度组件。分别是组织结构组件、员工资料组件、员工考勤组件、员工工资组件。
在得到了粗粒度组件之后，我们的工作需要分为两个部分：第一个部分是定义不同的粗粒度组件之间的关系。第二个部分是在粗粒度组件的基础上定义业务实体或是定义细粒度组件。

不同的粗粒度组件之间的关系其实就是前文提到的粗粒度组件的外部接口。如果可能，在粗粒度组件之间定义单向的关联（如上图所示）可以有效的减少组件之间的耦合。如果必须要定义双向的关联，请确保关联双方组件之间的一致性。在上图中，我们可以清晰的看出，组织结构处于最底层，员工资料依赖于组织结构，包括从组织结构中获得员工的所属部门，以及员工职务等信息。而对于考勤、工资组件来说，需要从员工资料中获取必要的信息，也包括了部门和职务两方面的信息。这里有两种关联定义的方法，一种是让考勤组件从组织结构组件中获得部门和职务信息，从员工资料中获得另外的信息，另一种是如上图一样，考勤组件只从员工资料组件中获得信息，而员工资料组件再使用委托，从组织结构中获得部门和职务的信息。第二种做法的好处是向考勤、工资组件屏蔽了组织结构组件的存在，并保持了信息获取的一致性。这里演示的只是组件之间的简单关系，现实中的关系不可能如此的简单，但是处理的基本思路是一样的，就是尽可能简化组件之间的关系，从而减少它们之间的耦合度。
考虑另一种的需求情况，在原先的系统的基础上，我们又增加了会计子系统部分，其中的一个粗粒度组件是对部门、员工进行成本分析。在原先的模型基础上，我们增加了对分层的考虑。从下图中，我们可以看到，组织结构组件已经发挥了它的重用性，被成本分析组件使用了。从分层上考虑（参见分层模式），我们将组织结构组件划分到工具层，而将其它的组件划分到领域层，并在领域层中进行子系统级的划分。从某个角度上来说，这种做法类似于一个分析模型的建模过程。总之，这个过程中，最重要的就是定义好不同的组件的关系。尽管这中分析是初始的、模糊的。

在得到了粗粒度组件模型之后，我们需要对其进行进一步的分析，以得到细粒度的组件。细粒度的组件具有更好的重用性，并使得架构设计的精化工作更进一步。按Jacobson推荐的面向对象软件工程（OOSE）的做法，我们需要从软件的目标领域中识别出关键性的实体，或者说是领域中的名词。例如上例中的员工、部门、工资等。然后决定它们应该归属于哪些粗粒度组件。先识别细粒度组件还是先识别粗粒度组件并没有固定的顺序。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)