|
作为软件生命周期前期的重要部分，架构设计要完成项目从面向业务到面向技术的转换，是跨越现实世界与计算机世界之间鸿沟的一座桥梁。完成架构设计的过程是软件架构设师们思考、总结并提炼的过程。软件架构设计对项目以后是否能继续正常进行、项目最终质量的好坏都起到很关键的作用。 首先介绍软件架构的概念，以利于后面内容的展开。这是一个有很多版本的定义。IEEE标准中对架构是这样定义的：架构是在组件及其彼此间和与环境间的关系引导设计发展原则中体现的系统的基本结构。 UMAL1.5中对架构的定义是： 架构是系统的组织结构和相关行为；架构可被重复分解为通过接口，互联部分的关系和结合部相互作用的部分；通过接口相互作用的部分，包括类、 组件和子系统。虽然它们有些区别，但是核心思想都是相通的。架构要包括各个颗粒度或粗或细的元素（组件）和定义他们之间的交互关系；架构还是许多重要问题的决策，这些问题包括： 软件系统的组织 选择组成系统的结构元素与他们之间的接口，以及当这些元素相互协作时所体现的行为 如何把这些元素组成更大的子系统 用于指导这个组织结构的架构风格：这些元素以及他们的接口、协作和组合 总之，我们不用去苛求定义的一致性，我们要领会它们是关于元素与重要决策的精神。形式只是其内容的表现，而深刻理解其内容的精髓，将在实践中给我们带来莫大的好处。下面我们就将展开软件架构设计的内容。 在需求获取和需求分析阶段，如何能够正确理解并提取需求，是成功项目的先决条件。软件的需求，可以从用户和开发人员两个不同的视角来看。从用户的角度看，又可以分为功能性需求和非功能性需求。我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。 在全面的认识需求并掌握了需求的相互影响后，我们还要掌握软件所属领域各种概念与问题，做到对项目整体需求情况“心中有数”。理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的。如果把这些需求都做成用例，那么一定是一个数量很庞大的用例集。分析功能需求与非功能需求，可以先抓住对整个软件起决定作用的部分关键需求，并把他们形成列表。我们可以辅助用例图，来更直接的搞清软件的用户与这些需求之间的关系。如下图就是一个项目管理系统的用例图。从张图很清晰的看出该项目用户与这些需求的关系，还可以总结出各个需求所属的模块。这样我们就可以进行很关键的概念性架构设计了。 概念架构界定了系统的高层组建、以及他们之间的关系；他对系统进行分解但不陷入细节；借此项目各方人员可以进行交流；它包括架构图以及各组件的非正式规约（无接口细节）。他针对重大需求、特色需求、高风险需求，给出高层次的解决方案。 鲁棒图是设计概念架构一个很好的工具与思考方式。我们可以通过鲁棒图展开案例，构造系统的理想化的模型。如下图，是一个“项目管理系统”案例，通过它我们可以发现并分析对象，初步看出用户的操作与数据的组成与流转。（具体鲁棒图的定义、语法、元素、规则等细节就不在这里介绍了） 下图是鲁棒图中的元素与MVC的对应，通过他我们可以看到，如果有了鲁棒图，概念架构设计的下一步似乎容易了很多。 我们似乎已经有了比较独立的小系统，接下来，我们又要提炼了：形成初步的概念架构，而我们期待已久的“分层、分区”（架构模式）就要出现了。这当然需要一些水平和经验。我们可以先大致“分层、分区”（确定架构模式），然后结合鲁棒图完成里面的内容。如下图所示，我们可以看到鲁棒图如何帮助我们完成初步概念架构。 形成初步概念架构后，我们还需要考虑非功能实现需求，实现高层设计决策。非功能需求在这里提出就是要早发现问题，早作出决策。这里推荐使用“目标-场景-决策”表（使用方法建议大家自学，我这里不介绍了）来帮助我们完成之一工作。通过分析需求、目标与质量属性、约束，我们把可预见的风险、问题、约束想象到场景中，并填写到表中相应位置，我们自然会得到我们想要的决策，补充我们的概念架构。如下图，就是通过“目标-场景-决策”表得到决策的过程。 好了，我们已经有概念架构了，但是他显然还是无法指导开发、规划、实施、运行，所以现在我们需要细化软件架构。软件的架构设计必须考虑到项目的各个方面，根据前期工作确立的领域模型、关键需求、系统约束等进行设计，必须从系统用户、开发人员、系统管理员、部署管理员、数据管理员等人员的角度去分析并解决问题。我们不可能只提交一个图就告诉大家所有的事情都怎么做，就像一个学生的一门成绩无法完整的显示他的学习状况，只有提交所有成绩才可以评价他学习的好坏。5视图就是一个很好的设计思路与应用。如同下图所示，他反映了软件的各个方面，对概念架构的细化其实就是完成他们的过程。当然要根据实际情况决定选择全部还是其中的几个视图。 展开介绍5视图的完成过程需要很大篇幅去介绍，这里就不进行了。但是我们可以总结一下各个架构的功能。其中： 逻辑架构：负责划分子系统（包括分层的细化、分区、机制的提取）、确定接口。 开发架构：并行开发的基础（包括定义程序单元与相互的关系、开发技术的选型） 运行架构：系统“运行时”架构（包括引入控制流、确定控制流相互关系） 物理架构：物理节点与部署结构（包括物理拓扑、软件到硬件的影射） 数据架构：数据的组织与存储格式 细化软件架构工作完成了，我们可以对我们的架构进行评审。无论是内部评审、外部评审还是专家评审，在评审会议之前，我们要进行充分的准备工作，如准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目。在会议前应将这些资料发给与会人员，请他们抽空先了解一下。在进行评审会时，要学会控制会议的进度，提高会议的效率。当然，在会议上，同行们可能会提很多问题或意见，而且可能很尖锐，但一定要虚心接受，并做好记录。还有要强调一点的是，在大张旗鼓开始下一步工作之前，花点时间进行架构评审这一步还是很重要的。架构设计实在太重要了，如果这里都不合理，后面的大量工作就会被白白浪费掉。 架构设计的重要性，也决定了架构设计的风险性。架构设计中决定了很多重要的设计决策，而这些重要决策是否能够在复杂的软件系统中真正实现我们对软件质量和需求的预期，即使做了充分的架构评审，我们有时还是会心中没底。鉴于不同软件项目规模的大小和其重要性，我们可以选择进行软件系统架构的验证工作—为软件架构设计方案实现一个小规模的原型，对该原型进行测试与评审，来继续评估架构的合理性，从而进一步降低项目的风险性。 软件的架构是系统在其环境中的最高层概念，它要兼顾系统完整性、经济约束条件、审美等要求。它不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。在进行架构设计的时候，既不要“高来高去”或“过度设计”，也不要只简单的分分层和包、画一个大体的轮廓图就草草了事了。正确的软件架构设计，应该既包括战略全局上的设计，也包括战术细节（关键路径）上的设计。有了这种科学的态度和方法，我们有理由相信自己团队决策的正确性和有效性。而我们精心的架构设计，不但满足系统用户、开发人员、系统管理员、部署管理员、数据管理员等各个角色的要求，更为项目的最终成功打下了最坚实的基础。（中国软件评测中心 李征宇 ） |
|
|
