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