李晓卡-文献综述.docVIP

毕业设计（论文） 文献综述 题目名称：项目的架构思想 院系名称：计算机科学与技术 项目的架构思想 摘要： 架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。事实上，结构是架构的基础属性。架构会以各种形式展一个架构的重要部分不仅仅是最终结果，架构本身，而是他为什么是如此的原因。一个结构组件可能是一个子系统，进程，库，数据库，计算结点，馈赠系统，按需产品等等。一个架构是一个系统的抽象，可以帮助架构师管理复杂性。非功能需求经常是架构师所关注的最重要的需求。好的架构设计没有统一的模式的，任何模式只有针对问题，才有意义。作为架构设计来说，必须需求分析有足够的理解，这样才能有针对性地解决问题，才可能设计出真正优秀的作品来。软件架构设计是一个系统工程，它需要系统构架师有很宽的知识面，从需求分析、架构设计到类设计甚至代码实现一直到项目管理都需要有透彻的理解，这之间的关系是你中有我，我中有你，是不可能截然分开的。 关键词： 架构 组件 系统工程 结构 计算节点 模式 子系统 1.引言： 架构、框架、模式是一种从大到小的关系，也是一种组合关系。 架构一般针对一个行业或一类应用，是技术和应用完美的结合。一个框架可能使用了多个模式，而一个架构有可能应用了多个框架，这样一个大型系统的设计基本从主骨干到骨架基本能够被设计者考虑设计到，也可以想见，一个系统被细化成了很多工作量，例如一个部分细化到工厂模式，那么就可以要求程序员实现工厂模式的代码即可由此，控制了大型软件质量，也提高开发效率，同时使得项目变得易于管理和协同，由此可见，一个大型项目的架构设计非常重要。 3. 从系统工程的角度构建架构 需求是设计的源泉，设计方案是对需求的应对。架构策略需要从系统工程的角度来思考。 在设计产品时，产品的需求绝帝国了合适的架构方法。反过来研究和评审所提出的架构是另一种解释需求的方法，并且会使需求更加明确。这两种方法都围绕这这样一种思维过程：“如果我正确理解需求，那么这种方法可以满足这种需求，既然我手中有一个最初的架构或原型，它是否有助于我更好地理解需求呢？”经典瀑布式过程要求在需求开发的时候把所有需求都定义清楚，但在即便如此开发过程中仍然受到需求变更之苦。人们思维方式常常出现的缺失是：当一件事出现困难的时候，总是认为是自己还做得不够好，而不去考虑这件事做法的本身是不是有问题？人们总认为专家制定的规范是不会错的，而不去看一看专家在制定这些规范的时候做了什么假定？规范本身是不是随着社会的进步而变化着？当需求发生变化的时候，总认为自己做的还不够规范，于是进一步强化规范，明确条块分隔，结果造成项目更加困难。正是这样的现实，才迫使人们回过头来想，需求发生变化的原因到底是什么？这才有敏捷过程的提出，而敏捷过程又对需求分析和架构设计提出了占星的需求。 多维度敏捷开发前期的需求开发并不需要太关注某个具体细节，更多的是从整体上考虑和分析问题。在你可以开始实现各个部分需求前，不必为整个产品进行完整、详细的设计。然而，在你进行编码前，必须设计好每个部分。 子系统和架构：子系统是伴随着软件复杂性的增长而且日渐重要的一个概念，当软件规模越来越大，所有的软件系统都会划分为模块或者子系统进行开发。任何复杂系统，都可以分解成小问题也就是子系统，每个子系统都可以合理的解释和证明、成功的设计与制造，然后在集成到整个系统中去。子系统还可以分解成子系统，这种分解或逐步细化的过程一直进行下去，子系统本身的开发也需要经过架构设计这一关。从高层次来说，架构的重心主要是子系统之间的协作，从子系统来说，架构的重心主要是模块之间的协作。如果从粒度的角度来看问题。粒度最小的单元是“类”，几个类紧密协作形成“模块”，完成相对独立功能的多个模块形成“子系统“，多个子系统相互配合满足一个完整的需求，从而构成软件“系统”，一个大型企业来说往往使用多套系统，多套系统通过相互操作形成“集成系统”。 框架和架构：框架是可以通过某种回调机制进行扩展的软件系统或者子系统。框架的概念主要来自于对“重用概率”的分析。一个软件单元被重用，单元粒度越大，重用概率越低，但是重用价值越大。反之，单元粒度越小，重用概率越高，但是重用价值越小。这个矛盾，仅仅通过分析是解决不了的。框架的智慧在于，在单元粒度比较大的情况下，追求高的重用概率。人们对于架构和框架实际上还存在喝很多混淆，认为架构就是框架。其实一句话就可以区别出来，框架是一个软件，但架构不是软件而是一种设计一种思想一种结构。 软件架构是比具体代码更高一个抽象层次的概念，架构必须被代码体现和准寻，但任何一段具体的代码都代表不了架构。不论是架构技术还是框架技术，都是为了解决软件日益复杂所带来的困难，而采取的“分而治之”的结果。架构的思维是先大局