|
要讨论软件架构设计在软件开发中的重要作用首先让我们来了解一下目前国内软件的开发现状 总的来说国内的多数企业仍然是采用瀑布模型作为软件开发过程的主要模型虽然在采用瀑布模型的同时可能会引入原型法以及诸如MSF等其它软件开发方法与过程但随着项目时间的推进这种瀑布模型会慢慢演化为边做边改模型 从事过软件项目开发的专业人士都有这样的困惑:为什么到了项目接近尾声的时候仍然还有那么多没有解决的问题？ 理论上讲应该是先分析后设计再编码那为什么项目在交货以后我们还在不断的编写设计文档？为什么每次客户需求发生变更我们又要投入大量的资源来应对不断变化的客户需求？为什么软件开发会碰到这么多困难我们天天加班加点不断地去解决开发中碰到的种种问题可是问题越解决越多得到的效果却那么不尽人意？ 项目出现这些问题原因很多概括起来可以分为两种:管理因素和技术因素国内普遍重视管理因素而忽视技术因素所以出现层出不穷的问题也就无法避免 软件架构设计属于技术因素它位于软件开发过程的前期阶段架构设计的过程是分析客户需求挖掘非功能性需求并将客户需求所定义的领域知识转化为软件系统模型的过程由此可见架构设计所涵盖的范围非常广泛 目前国内对于软件架构的认识还存在这样或那样的误区难道只有当设计人员在为软件项目配备了充足的资源然而却得不到预期的结果时才会反思:是不是软件开发本身出现了问题? 架构设计源于客户需求 在进行需求分析的过程中系统分析员将客户需求转化为计算机模型然而在这个过程中系统分析员本身的特性也就决定了这一角色很难把握住客户的非功能性需求 需求需要挖掘尤其对于大型的软件系统而言光靠系统分析员这个单一的角色很难完成需求分析与挖掘的艰巨任务在需求分析的过程中架构设计师更为关注的是系统的非功能性需求例如稳定性可扩展性可维护性安全性高效性等等这些需求都是需要挖掘的 如何挖掘？挖掘方式取决于核心需求举个很简单的例子客户需要实现两个系统的数据传输这是个核心功能性需求而在这个需求的背后还包括了传输过程要求可靠需要采用一种特定的数据格式进行传输由于数据包含一定的机密因素因此需要加密并需要选择合适的加密算法等等一系列的非功能性需求 此时架构设计师不仅需要了解客户本身的功能需求还需要能够发掘非功能需求因此优秀的架构设计师一定是一个经验丰富的需求工程师需求分析让架构设计师知道我需要考虑哪些因素而深厚的软件技术功底让架构设计师知道如何去考虑这些因素可见架构设计源于客户需求 架构设计源于对知识的不断积累 首先应该认识到没有对领域知识软件系统特性与软件技术等的深刻理解就无从谈及架构设计而深厚的领域知识与技术经验则是源于不断的积累 目前市场上确实很多产品在架构上已经非常成熟和稳定但这些产品的成熟架构也是通过长期不断的实践与积累才逐步形成的经验丰富的架构设计师可以在开发产品的同时总结出一套架构模式这对维护产品的体系结构以及开发同类产品都有深远的意义 从另一个角度讲产品的架构并非一成不变随着技术的不断创新与发展新技术一定会被应用到现有的系统架构中此时软件架构可能需要进行调整我们也不能再说我们没有必要去关心这些产品架构了 架构设计是一种取捨过程 实现某一非功能性需求可以有很多种方法但并不是每种方法都是最合适的这在架构设计的过程中需要做出取捨例如为了使得软件系统具有易扩展易更改的能力我们可以采用插件体系结构或内嵌脚本系统结构两者都可以使得软件系统具有方便扩展的能力 然而如果客户的业务流程会经常变化或者软件系统产品会应用到具有不同业务流程的多个客户时采用后者可能会更加符合软件本身的特点 当今IT业技术层出不穷在特定的应用场景中采用何种技术何种模式最合适这就是架构设计的取捨JAVA和NET孰好孰坏？讨论这样的问题也不再有意义软件工程大师Martin Fowler曾经说过:架构师是对所有重要事情做出决定的人这一决定也囊括了取捨 架构设计将服务于整个开发过程 良好的架构设计不仅使得软件系统能够满足客户需求它更为软件系统带来了安全性稳定性可扩展性等属性而这些属性在应对客户需求变更提高软件可测试性与可维护性降低维护成本提高开发效率等各方面都起着非常重要的作用 客户所需要的是可以用于生产实践的最终产品他们自然不会去关心你的软件系统采用何种设计和架构但作为软件系统的分析者设计者和开发者我们必须为软件产品寻求一种合理的架构设计因为它不仅能够使系统满足非功能性需求而且能够降低开发成本和维护费用 总之架构设计是软件开发过程的重要组成部分它不是单纯的技术也不具有一种特定的形式更不是与客户需求无关的良好的软件架构能够服务于整个开发过程有效地降低项目风险确保项目能够朝着健康的方向发展因此我们必须重视架构设计在软件开发中的重要作用 |
