概念完整性
Brooks在他的经典巨著《人月神话》里面提到了概念完整性,并将软件维护软件的 “概念完整性” 作为软件开发的核心问题。软件工程之所以复杂、难以维护,根本原因在于软件迭代过程中概念完整性遭到了破坏。软件开发者不理解原先开发者的设计理念,对软件领域模型不足够了解,团队内部缺乏沟通和可维护性文档,甚至开发团队从来就没有意识到维护软件概念完整性的重要性。这群开发者从一定程度上讲,他们不算是一个团队,他们只是聚集在一定空间,时间范围内一起堆叠代码的孤岛程序员。
从模型分析到设计
以业务领域为中心,对于软件开发来说是极为重要的。我们说过,最重要的是,创建一个植根于领域、并精确反映出领域中的基本概念的模型。通用语言应该被充分运用在建模过程中,以推动软件专家和领域专家之间的沟通,以及发现应该被用在模型中的关键领域概念。建模过程的目的是创建一个优良的模型,下一步是将模型实现成代码。这是软件开发过程中同等重要的一个阶段。创建了一个优良的模型,但却未能将其成功地转换成代码将会得到质量有问题的软件。
任何领域都能被表达成多种模型,每一种模型都能以不同的方式被表现达代码。拥有一个在分析层面正确的模型,并不代表模型能被直接表达成代码。或者它的实现会违背某些软件设计原则,这是我们不建议做的事情。选择一个能够被轻易和准确地转换成代码的模型是很重要的。根本的问题是:我们应该如何完成从模型到代码的转换。
一个推荐的设计技术是创建分析模型,它被认为是与代码设计相互分离的、通常是由不同的人完成的。分析模型是业务领域分析的结果,此模型不需要考虑软件如何实现。这样的一个模型可用来理解领域,它建立了特定级别的知识,模型在分析层面是正确的。软件实现不是这个阶段要考虑的,因为这会被看作是一个导致混乱的因素。分析人员可能会过多深入到模型中某些组件的细节,但其他的部分却缺乏足够的细节。非常重要的细节直到设计和实现过程才被发现。设计阶段,开发人员不得不修改它,或者创建分离的设计。在模型和代码之间也不再存在映射关系。最终的结果是分析模型在编码开始后就被抛弃了
解决模型分析、设计一致性
1、加强分析人员、软件专家、领域专家内部的沟通交流。模型中的一些细节不容易表达为图形的形式,甚至也可能无法完全用文字来表达。开发人员理解这些细节非常困难。在某种情况下他们会对想要的行为做出一些假设,而这些假设有可能是错误的,最终会导致错误的程序功能。
2、举行团队领域模型相关内部会议,推动开发人员积极参与,开发人员如果能够参加分析讨论会议,并在开始做编码设计之前对领域和模型获得一个清晰完整的视图,他们的工作将会更有效率。
3、一种更好的方法是将领域建模和设计紧密关联起来,开发人员应该被加入到建模的过程中来。有了开发人员的参与,就会获得反馈,它能确保模型能够在软件中得到实现。写代码的人应该很好地了解模型,应该感觉到自己有责任保持它的完整性。从模型中提取出在设计中使用的术语和所分配的职责之后,代码就成了模型的表达方式,所以对代码的一个变更就可能成为对模型的变更。变更的影响相应地还会波及到项目的其余活动中
4、及时反馈软件设计的变更,以更好的模型设计决策,以及领域模型正确性的评估。如果哪里的代码不能表达最初模型的话,他们将会对代码做重构。如果分析人员从实现过程中分离出去,他会不再关心开发过程中引入的局限性,最终的结果是模型将不再适用。如果设计或者设计中的核心部分没有映射到领域模型,模型就没有什么价值,而软件是否正确也就令人怀疑。同时,模型和设计功能之间的映射如果很复杂,就会很难理解,当设计变更了实际上模型是不可能维护的。分析和设计之间出现了致命的割裂,这样一个活动(分析或设计)中产生的想法将无法对另外一个产生影响
5、将设计工作交给实施开发者,避免设计设施分离。国内盛行一些相对不良作风,出现不写设计,不参与实施工程师。软件设计是一个有着众多不可预见性并持续变化的工程,实施阶段发现设计,甚至模型分析不合理性难以避免。如果将设计工作交于基层工程师,可以更好的避免代码、模型不匹配。当然,对于初级工程师,应该加强干预设计,但不应该完全脱离实现