软件工厂方法(二）：软件工厂应用
基于实践的高度抽象之上，加上理论的加工就成为了方法论。在自己没有很好的方法时，我们可以采用别人的方法，只需要在应用时结合自己的实际情况，有选择的结合不同方法以满足我们的要求。在上篇《软件工厂方法》中，介绍了软件工厂由四个基础构建块组成，分别是产品线工程，架构框架，模型驱动开发和构建指南。我前期的主要工作内容有报表引擎、企业报表和GCC应用，本文将基于我的这些工作内容描述一下软件工厂的一些概念以及应用（部分内容摘自上篇）。
报表引擎开发
领域工程是产品线中的主要概念之一，它分为纵向领域和横向领域。纵向领域是根据系统类别而组织的领域，GSP引擎、报表引擎等就属于这一领域。横向领域主要处理业务领域，企业报表、材料管理等属于这一领域。领域之间有3中关系，报表引擎在实现表达式时参考了GSP引擎的实现，企业报表使用了报表引擎，成本管理软件包含了材料管理系统。
领域工程开发活动大纲
1. 领域分析
a) 领域定义
i. 目标和风险承担者分析。
在实现原有报表3.0功能的基础上，提高复杂交叉表功能，增强报表运算能力，解决造价产品和项目管理产品的现有报表问题，完成后替代报表3。需求收集阶段汇总了各项目组的问题。
ii. 领域范围界定和上下文分析
1. 应用领域和现有系统的分析
参考了报表3.0的应用场景以及现有功能，分析了水晶报表、SAP程序报表以及国内的一些报表厂商的软件，如润乾软件、博易智软等软件，最后决定选择润乾报表模型作为我们公司应用的报表模型
2. 领域特征的确定
报表引擎不考虑作为多个产品发布，所以特征模型相当于一个功能列表
3. 与其他领域关系的确定
报表引擎实现中使用了公司的表达式引擎，当时GSP也引用了表达式引擎，所以在实现GRP的表达式部分时参考了表达式在GSP的部分应用。
b) 领域建模
i. 关键概念的确定
报表引擎设计阶段，参考润乾报表，分析其扩展模型，确定了其中的主要概念
|
名称 |
说明 |
|
单元格 |
报表由行列整齐的格子组成，这些格子我们称为单元格，所有的单元格组成了报表。 |
|
主格和附属格是互相关联的，当A单元格扩展时，B单元格被 同步复制，此时A单元格称为B单元格的主格，B单元格称为A单元格的附属单元格。 |
|
|
横伸主格 |
如果A单元格横向扩展则A为横伸主格 |
|
纵展主格 |
如果A单元格纵向扩展则A为纵展主格 |
|
多个连续的单元格通过合并操作后显示为一个大的格子，合并后的格子成为合并单元格 |
|
|
单元格属性值和表达式 |
单元格的大部分属性都有属性值和表达式两种。 |
|
单元格的层次坐标 |
通过单元格的坐标表示法唯一标识扩展后的格子 |
2. 领域设计
a) 整个实现架构的确认和规范
参考报表3的实现方法确定了主要架构
b) 领域特定语言的确认和规范
第一阶段实现通用Excel设计器，后续阶段扩充其他设计器
3. 领域实现
4. 领域测试
工作流程
产品线工程中分为领域工程和应用工程，应用工程需要提供反馈给领域工程，这种循环反馈才能确保平台一直都能有效的生产出最终产品。下图是应用报表引擎的工作流程。先内部开发后经过一两天培训后进入应用阶段，应用过程中不断反馈问题到领域工程中。
何时考虑开发领域
横向领域还包括规则引擎、工作流引擎，为什么先处理报表引擎？作为横向领域的报表引擎被多个领域使用的，并且项目组现有应用已经不能满足，从风险角度和和使用价值来看优先级别都比较高，所以最先考虑开发报表引擎部分。
在考虑其他基础领域时，也需要有技术积累，不能等项目组急着需要时再和项目组开发一起进行，这样风险很高。对于基础性强，风险高的需要单独考虑实现，风险低的可以结合项目应用是再实现，但不管哪种都必须是基于产品需求来开发的。
GCC应用
架构组成部分
上图是DSM的核心概念，首先根据问题空间来定义一个模型语言，基于模型内容之上通过生成器产生框架可以使用的配置或者代码，然后在目标应用中使用。
特定领域开发是一种用于解决重复发生的问题的方法，每次发生的问题都有很多方面是相同的，而这些相同的方面可以一次性的解决。对于问题的每次发生，就用这个特殊语言建立模型，然后把模型插入到解决方案的固定部分。解决方案中的固定部分采用传统的设计、编码和测试技术实现。根据要解决问题的规模和种类，固定部分可以称为框架（Framework）。
基本开发过程
- 找出所有问题中的固定部分，并把这些固定部分放在通用架构或平台中
2. 找出所有问题的变化部分，并设计一种DSL，DSL的表达式或模型可以给出问题的一个解决方案。
模型和框架整合
把解决方案的固定部分与由模型表达的变化部分整合在一起。一般有两种方式完成整合。第一种是解释方法：固定部分保护一个解释器，用来解释变化部分的DSL。这种方式比较灵活，但这种方法的缺点是性能较差，而且不容易调试。第二种是代码生成方式：代码变化部分的特定表达式或图表可以被完全转化成代码，与解决方案的其他部分一起编译。这个转换过程更复杂，但在可扩展性、性能和可调试性上有优势。
在GCC中，对UI层的开发使用了类似的方法。现在一个模块需要使用元数据工具来生成UI模型数据，在程序运行时会有一个AutoUI组件负责直接读取这些数据，提供生成界面和配置数据绑定等编辑方式和注册规则，然后GCC框架调用AutoUI提供的功能来完成UI层的工作。
DSL楼梯形定制
在设计DSL时，需要考虑多个级别的定制，不能因为不支持而导致不能实现的情况。可以定义一个DSL楼梯形定制方案，简单、普通、专家、平台。例如对于AutoUI来说，如果只是开发一张普通字典或者报表时，可以使用元数据工具的生成字典和报表快捷方式。对于一般情况下的模块开发时，可以使用元数据工具生成实体以及属性。对于项目组个性的编辑方式，如下拉周期等，可以在专家级别处理，由开发人员扩展并注册AutoUI编辑方式来解决。对于当前不能解决的，在反馈过程中不断在平台级别进行扩充。
优点
- 让我们有能力在问题空间工作，避免以往用通用语言表述问题容易犯的一些错误，降低了犯错的机会
- 通过在问题空间工作，可以让不熟悉如何实现技术的人，包括测试人员也能够修改模型的部分内容。
- 高度抽象后，开发更统一规范，速度和质量都有所提高
- …
采用DSL的一个作用就是，使工作更贴近于客户的理解而不是实现本身。由于目前只应用了部分DSL概念，要得到更多效果，就必须投入精力设计实现一个完整的DSL，并将其整合到整个解决方案中。
企业报表开发
组件开发是基于已开发的组件，然后像搭积木一样搭建一个系统。而产生式编程基于提供的一些组件、框架和配置工具，可以生成应用工程。
领域工程
类似于报表引擎开发中，也可以基于领域工程开发活动大纲开展工作。简单描述如下：
1. 领域分析
a) 领域定义
i. 目标和风险承担者分析。
GCC的企业报表主要满足五冶公司上报报表的数据统计处理，此功能亦可用于其他集团公司。
ii. 领域范围界定和上下文分析
1. 应用领域和现有系统的分析
此业务与公司原有统计项目组的业务有点类似，并参考了其他一些报表厂商的软件
2. 领域特征的确定
包含自定义字典、自定义录入表单、报表定义、报表查看、套表生成、审核等功能
3. 与其他领域关系的确定
使用报表引擎，审核功能基于GCC框架
b) 领域建模
i. 关键概念的确定
业务上主要概念有层级下发、层级汇总
ii. 关键概念的特征建模
共同点：都存在录入字典和表单、都需要定制和查看报表、需要审批
可变性：不同的报表定义样式由报表引擎处理，不同的录入字典和表单、审批流、权限配置由元数据和GCC应用框架支持
2. 领域设计
a) 整个实现架构的确认和规范
企业报表是建立在GCC应用程序框架和报表引擎基础之上的扩充功能，满足企业集团多级机构之间报表分发汇总的业务需求。
应用工程
上图是软件产品线工程框架图。框架分为两个阶段：领域工程和应用工程。领域工程产出平台的公共核心资产，应用工程是基于领域工程的结果构建系统的过程。对一个新的具体应用做需求分析的时候是利用已有的领域模型，通过领域分析提供的各种通用功能、支持的变量配置、提供的扩展等来描述客户需要。如果新的需求在领域模型中不存在，则可以定制，或者反馈到领域工程来扩充领域的支持范围。
在整个开发生命周期中，存在9个子流程，八个流程互相匹配成四组类似流程，需求、设计、实现和测试在领域工程和应用工程都存在，每一匹配组的流程都紧密相连。领域工程的子流程目的在于满足通用需求，而在应用工程是为了生产可供使用的产品。应用工程的子流程需要提供反馈给领域工程，这种循环反馈才能确保平台一直都能有效的生产出最终产品。
在企业报表开发过程中，我主要处理的是领域工程范围的内容，提供了报表定义、报表查看、套表等基础组件、支持框架和工作计划，并在应用工程应用过程中，不断根据项目组应用反馈完善领域工程内容。而项目组主要专注与项目业务，基于领域工程提供的功能来应用企业报表功能。
规模化产品开发方法－产品线工程 100222.pdf
欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]
