《软件架构分解》.pdf

软件架构分解 多维度的架构分解 对复杂的大规模软件系统，软件架构分解是架构设计中必不可少的关键 步骤 通过分解识别架构元素，同时也是解决非功能需求的重要手段之 一 本文从架构的定义出发，对架构形而上的本质给出了自己独特的理 解 在架构设计上提出了架构分解过程模型和多维度多层次分解模型  内容 什么是软件架构 如果期望有一个权威统一的标准定义，那答案是没有，目前存在多种软件架构的定 义，可以说百花齐放，百家争鸣 其中 IEEE1471-2000 的定义是这样的：系统的架 构是系统组件的基本组织形式，它们之间的关系以及和环境之间的关系，以及指导其 设计和演化的原则 该定义中的系统组件可以理解为架构元素，根据涉及到的系统范 围和层次，架构元素可以是子系统、模块、类等等 从架构设计的动态角度出发，我 们可以这样来定义软件架构：通过一系列架构决策，将系统分解为一些架构元素，并 定义这些元素之间的接口和交互关系、集成机制 架构决策就是在架构设计过程中做 出的一系列全局的决定和权衡取舍，例如将系统拆分成几个子系统、子系统的职责是 什么、子系统之间的接口是什么、采用什么通讯方式和集成机制、采用的开发语言和 技术框架等 架构形而上的本质 除了软件架构，众所周知，在建筑行业中也存在架构，而且建筑架构比软件架构历史 要悠久得多；在公司中存在组织架构 这就引发了我们的思考，对这些不同的架构， 它们的本质是什么？ 从抽象的形而上的角度来看，架构是架构作用力的平衡，如图 1 图 1 中左侧一个最初混沌的系统在架构作用力的相互作用下达到足够程度的平衡 右 侧的椭圆蕴含的意思是架构应该是有弹性的，里面的多个小圆表示在力的作用下分解 产生的架构元素 图 1.形而上的架构 什么是架构作用力 对一个建筑工程项目，会涉及到多方涉众，如建设单位、勘察单位、设计单位、施工 单位、工程监理单位、使用单位等等，他们对工程项目存在各种需求；同样在一个软 件系统中也会有多种涉众，例如系统用户、投资人、需求分析师、架构师、开发人 员、测试人员、客服人员、运维人员等等 这些涉众在架构层面有各自的架构需求， 例如系统用户除了要求满足他们的功能需求外，还有对系统的易用性、性能、可用性 等非功能性存在要求；开发设计人员希望系统架构清晰，便于理解，关注代码重用 性、扩展性、可维护性 架构师更关注于系统可伸缩性、可用性、性能等非功能需 求 这些需求必须在架构层面加以考虑，使这些涉众的需求在架构层面得到足够的满 足 从抽象的层次来看，涉众在架构层面的上述各种需求就是架构作用力，它们直接影响 和驱动架构设计 大师 Grady Booch 在他的The architecture of Web applications 一文中就已经关注软件中的作用力 （Forces in software ） 在架构中除 了存在这些外力外，在架构中也存在内力，就是架构元素之间的相互作用力，这里不 展开讨论 一个架构要满足所有的需求通常是不可能的，因为不同的涉众，他们之间的需求可能 是相互冲突的，也就是作用力的方向是相反的 作用力的大小主要体现在需求的优先 级上 架构设计过程中，架构师运用自己的经验，结合当前的技术，从全局考虑需求和约 束，进行折中和取舍，平衡这些涉众的作用力 在 IEEE1471-2000 规范中，将涉众在架构层面的各种需求称为关注点，从这个概念 来说架构分解就是关注点分离 架构分解 当我们看到一个复杂系统的架构视图时，可能会思考这些视图中的架构元素是怎么来 的 如何从混沌的铁板一块的整体架构演变成一个可伸缩高性能的分布式系统？