软件设计流程

《软件工程知识体系》是由 IEEE 出版的一本书，通常被称为 SWEBoK，它总结了整个软件工程领域公认的知识体系。

书中指出，软件设计的定义如下：

具体来说，软件设计可以分为两个层次：

组件是软件解决方案的一部分，组件外的接口包括所需接口（软件运行所需的接口）和提供接口（软件提供给其他组件的接口）。

这两个设计过程（架构设计和详细设计）应产生一套模型和工件，记录主要的决定，并解释为什么做出了非同小可的决定。将来，开发人员可以随时参考这些文档，以找出架构决策背后的理由，从而确保决策经过深思熟虑，并将这一思考过程传承下去，使代码更具可维护性。

这些流程中的第一个流程，即架构设计，对于整个团队来说可能相当具有创造性和吸引力。无论如何选择，这一过程的结果都应该是一个组件图，通过接口将组件相互连接在一起。

这个过程通常有利于普通开发人员小组，而不是专业团队。专业团队通常是由某一特定产品知识领域的专家组成的小组，他们在架构师的主持下，在有时间限制的环境中共同解决某一特定问题。通常情况下，特别是在涉及到遗留问题时，这种设计工作可能需要广泛的知识来提取必要的架构约束。

尽管如此，为了防止这一过程变成委员会设计或暴民规则，你可能需要遵循一些基本规则：由一名架构师主持会议，并从组件级图表开始工作，而无需进一步深入研究。在会议前模拟组件图，并在会议中根据需要对其进行编辑，通常会有所帮助，这有助于确保团队在不深入研究 "如何" 的情况下，保持在修正图表的轨道上。

在我所处的一个环境中，有一位非常细致的工程师，他是工程团队的负责人；他坚持在进行架构设计时立即深入研究组件的细节，这将使流程迅速瓦解，变得毫无条理；他会在会议中临时开始会议。事实证明，在这些架构会议上绘制组件图对于维持会议秩序、确保操作事项和详细设计事项不会过早介入至关重要。除非直接改变软件的创建方式，否则有关托管方式和托管地点的操作事宜通常不属于软件工程的范畴。

下一步是详细设计；它解释了如何构建一个组件。在构建过程中使用的设计模式、类图和必要的外部资源都可以在此时决定。无论设计有多好，软件开发人员都需要对设计进行细微的修改，以增加更多细节或充实架构过程中的一些疏漏。设计之前的流程必须足够详细地指定组件，以方便构建，并让开发人员不必考虑架构的太多细节。开发人员应该根据与代码密切相关的工件（例如详细设计）来开发代码，而不是根据高级需求、设计或计划来编码。

另外，让我们记住，单元测试可以构成设计的一部分（例如，在使用测试驱动开发时），每个单元测试都可以指定一个设计元素（类、方法和特定行为）。虽然将代码逆向工程到设计工件中是不现实的（尽管有些人声称这是现实的），但将体系结构表示为代码是可能的，如果你愿意的话；单元测试就是实现这一目标的方法之一。

正如本书前面所提到的，设计模式在软件设计中起着至关重要的作用；通过设计模式，可以设计出更复杂的软件，而无需重新发明轮子。

好了，现在来看看创造性设计模式。