《软件架构设计》 文摘

1.软件行业人才结构

  学历结构是橄榄型，能力结构是金字塔型。《华为研发》中写道，机会、人才、技术、产品是公司成长的主要牵动力。机会牵引人才、人才牵引技术、技术牵引产品、产品牵引更大机会。在这四牵动力中，人才所掌握的知识处于最核心的地位。软件企业应该定期分析和掌握本公司的员工能力状况、人才结构状况；员工专项技能的渐进提升（架构技能、设计重构技能）；研发骨干整体机能的跨越转型（高级工程师向架构师、系统工程师和技术经理的转型）。

2.软件架构概念

该书将软件架构的概念分为两大流派：组成派和决策派，帮助各级开发人员快速理清“什么是架构”的基础问题。

组成派：软件系统的架构将系统描述为计算组件及组件之间的交互。特点：关注架构实践中的客体-软件，以软件本身为描述对象；分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。

决策派：软件架构包含了关于以下问题的重要决策：软件系统的组织；选择组成系统的结构元素和他们之间的接口，及当这些元素相互协作时所体现出来的行为；如何组合这些元素，使他们逐渐组合成更大的子系统；用于指导这个系统的架构风格：这些元素以及它们的接口、协作和组合软件架构不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制和平衡、美学等。特点：关注架构实践中的主体：人，以人的决策为描述对象；归纳了决策的类型，支出架构决策不仅包括关于软件系统的组织元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。

解析：软件架构关注分割和交互（组成型）。架构是一系列有层次结构的决策：架构属于设计，但是并非所有的设计都属于架构。组件的粒度可以很小，也可以很大，任何粒度的组件都可以组合成粒度更大的整体，即粒度多样性问题。组件的粒度界定必须在具体实践上下文中才有意义。即粒度相对性问题。组件分为原子组件和复合组件两种，可通过相互交互完成更高级的功能。

架构设计是针对作为复合整体的“复杂软件单元”，架构规定了“复杂软件单元”如何被设计的重要决策；实际上，系统、子系统和框架都可以根据需要进行架构设计。

3.架构设计视图

架构视图的实践导向性很强，每个视图分别关注不同的方面，针对不同的实践目标和用途。一个架构视图是对于从某一视角或者某一点上看到的系统所做的简化描述，描述中涵盖了系统某一特定方面，而省略了与此方面无关的实体。架构视图是一种设计架构、描述架构的核心手段：架构设计和涵盖的内容和决策太多，超过了人脑“一蹴而就”的能力范围，采用“分而治之”的办法从不同视角设计；也为软件架构的理解、交流和归档提供方便，对架构设计思维有指导作用。多种架构设计视图中，最常用的是逻辑架构视图和物理架构视图。

3.1 逻辑架构

逻辑架构规定来了软件系统由哪些逻辑元素（逻辑层、功能子系统、模块）组成以及这些逻辑元素之间的关系。

设计逻辑架构的核心任务:比较全面地识别模块、规划接口，并基于此进一步明确模块之间的使用关系和使用机制。

3.2 物理架构

物理架构规定了组成软件系统的物理元素，这些物理元素之间的关系，以及它们之间部署到硬件上的策略。可以反映出软件对元素动态运行时的组织情况。“物理元素”就是进程、线程，及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线通信等则进一步反应了物理架构的动态行为。应用很广泛，如可能需要专门说明数据是如何产生、存储、共享和复制的。

3.3 设计实现

架构设计指导后续的详细设计和编程，详细设计和编程，贯彻和利用这些设计：1.逻辑架构中关于职责划分的决策，体现在层、功能子系统和模块等的划分决定，从静态视角为详细设计和编程实现提供切实的指导；逻辑结构规定了不同逻辑单元之间的交互接口和交互机制，而编程工作必须实现这些接口和机制。2.交互机制是指不同软件单元之间交互的手段。例子：方法调用、基于RMI的远程方法调用、发送消息等。3.物理架构关注软件系统在计算机运行期间的情况。物理视图中规定了软件系统如何使用进程和线程完成期望的并发处理，进程线程完成这些主动单元会调用哪些被动单位参与处理，交互机制为何等问题，从而为详细设计和编程实现提供切实指导。

4.粗粒度“功能模块”划分

4.1功能树

作为需求分析的手段，功能树是一种框架性工具，有助于需求分析人员一层层的选择确定系统必须具有的各项功能与特性。作为需求分析的成果，是一种功能表达结构，将“功能大类”、“功能组”、“功能项”的隶书和支持关系以树的形式呈现。

架构设计师跨越现实世界（问题领域）到计算机世界（解决方案）之间鸿沟的桥梁。需求分析的意图就是明确“问题领域”，将要解决的问题以“功能+质量+约束”的形式定义下来。需求再详细，也没有打破“系统是黑盒子”这一点。除非是极其简单的系统，否则必须区分“功能树”和“功能模块结构图”。“功能树”是一种功能分解结构，“功能模块结构图”是对系统进行结构分解的结果示意图；“功能树”是问题领域，“功能模块结构图”刻画的是解决方案；“功能树”是需求分析层面，“功能模块结构图”属于设计层面；“功能树”是架构师从上游（需求分析师）得到的，“功能模块结构图”是架构师自己设计出来的。

4.2借助功能树，划分粗粒度“功能模块”

1.获取功能树：软件规格需求说明书（SRS），它会系统化描述各项功能；如果没有显式画出功能树，目录的章节小节结构经常体现；关注《愿景文档》、《方案建议书》梳理需求北京、明确设计原则、刻画设计方案、对比方案优势；和需求分析人员业务人员沟通，获取信息，自己梳理功能树；分析产品查看之前产品或者查看市场材料中查看。

2.评审功能树

是否合理：一面向使用，体现使用价值；二是覆盖全面，没有范围遗漏。

3.粗粒度“功能模块”划分

一方面将业务上紧密相关的一组功能在实现上也常会涉及相同的函数、类、数据结构等，将这组功能映射到一个“功能模块”，有利于设计的高聚合、松耦合，有利于程序小组之间的分工。另一方面一些公共服务（报错处理、log日志、安全验证）会用于同时支持多组功能的实现，应该独立模块化为“通用模块”或者是“通用机制”中。

5.需求和用例

5.1用例图

描述软件系统为用户或外部系统提供的服务。最重要元素是参与者和用例，以此体现系统能为外部参与者提供功能；参与者是与系统进行交互的角色和系统，可以是系统的用户，也可以是直接和系统交互的系统；用例的名称应该以参与者的角度考虑，动词开头。

5.2用例简述、用户故事

通过简单的文字对用例的功能描述，一般而言都包含成功场景的简单描述。

5.3用例规约

对用例的详细描述，一般包括简要说明、主事件流、备选事件流、其前置条件、后置条件、优先级等。

用户规约主要目的是界定软件系统的行为需求（需求可划分为业务需求、用户需求、行为需求三个层次，行为需求是指软件系统为了提供用户所需的功能而必须执行哪些行为）。

5.4 用例实现、鲁棒图

协作。刻画为了实现用例定义的功能，必须考虑需要哪些类，类的一般交互关系。从功能需求到设计方案的过度，鲁棒图可以充当思维的纽带。

用例图从总体上反映了用户需求，用例简述是行为需求的简化描述，用例规格是规格级的行为需求，鲁棒图属于设计范畴，是初步设计。