软件架构设计

第十讲软件架构设计目标管窥架构设计现状架构设计方法如何确定架构驱动因素非功能需求设计方法论通用过程太笼统架构分析架构分析可以被视为需求分析的规格化，其关注强烈影响”架构“的需求。例如，为系统识别高度安全方面的需求。架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题为什么架构分析如此重要？因为它有助于：降低在系统设计中丢失某些重要因素的风险。避免在低优先级的问题上花费过多的精力有助于产品与业务目标的一致架构分析架构分析（architectureanalysis）是在功能性需求（例如处理销售等）的语境中，识别和处理系统非功能性需求（例如安全需求等）的活动。其包括识别变化点和最具有可能性的进化点。例：可靠性和容错需求如何影响设计？采购子构建的许可费用如何影响收益率？可适应性和可配置性需求如何影响设计？商标名称的选择如何影响架构？架构分析识别和分析对架构有影响的非功能性需求。虽然与功能性需求也有关系（特别是可变性方面），但是应该对非功能性需求给予非常彻底的关注。通常，这些都被称为架构因素（或者称为架构驱动者）对于这些在架构方面具有重要影响的因素，需求分析可供选择的办法并创建解决这些影响的解决方案。这就是架构决策。架构分析软件系统的架构将系统描述为计算组件及组件之间的交互”组件“可以指子系统、框架（Framework）、模块、类等不同程度的软件单元，它们可以担负不同的计算职责。软件架构的要素：组件及组件之间的交互组件交互MVC架构作为”组件+交互“的例子ViewControllerModel创建读取通知调用服务关注点分离之道好的架构设计必须把变化点错落有致地封装到软件系统的不同部分，为此，必须进行关注点分离好的架构必须使每个关注点相互分离，也就是说系统中的一部分发生了改变，不会影响其他部分。即使需要改变，也能够清晰地识别出哪些部分需要改变。如果需要扩展架构，影响将会最小化。已经可以工作的每个部分都将继续工作。P19图2-4P20图2-5P20图2-6对于面向对象的软件开发而言，经常有下列软件单元：粒度最小的单元通常是“类”几个类紧密协作形成“模块”完成相对独立的功能的多个模块构成了“子系统”多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”类、模块、子系统、系统、集成系统，都是软件单元的具体形态，只不过粒度不同罢了P21图2-7P22图2-8框架是软件，架构不是软件框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。P24图2-9框架和架构的关系P25图2-10理解架构真实的软件其实是“由组件递归组合而成”的：组件的粒度可以很小，也可以很大；任何粒度的组件都可以组合成粒度更大的整体。即所谓的粒度多样性问题组件粒度的界定，必须在具体的实践上下文中才有意义；你的大粒度组件，对我而言可能是原子组件。即所谓的粒度相对性问题P27图2-11图2-12作为复合整体的软件单元才有架构，架构规定了它如何被设计的重要决策回到实践P28图2-13框架VS.类库P29图2-14框架的分类P31图2-16框架的开发过程框架的整个开发过程，包括四个主要的阶段，即分析阶段、设计阶段、实现阶段和稳定阶段。P32图2-17架构设计的5视图法好的方法如路标，对实践者有启发和指引作用。软件架构师的工作：要满足性能、持续可用性等方面的需求，架构师必须深入研究软件系统运行期间的情况、制定相应的设计决策，这些需求被称为软件的“运行期质量属性”；而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研究软件系统开发期间的情况，制定相应的设计决策，这些需求被称为软件的“开发期质量属性”；约束是一类特殊的需求，带有一定强制性，架构师制定的架构决策必须满足这些限制；为了满足功能需求，架构师必须规划组成软件系统的所有模块，为他们分配不同职责，使这些模块可以通过协作完成功能需求架构设计的5视图法软件架构师必须明确区分功能需求、约束、运行期质量属性和开发期质量属性等不同种类的需求，基于多视图的架构设计方法在一定程度上将各类需求分别对待，通过不同的架构设计视图分别满足它们，从而确保重要的需求一一被满足。架构设计5视图，包含了逻辑架构、开发架构、运行架构、物理架构、数据架构等5个架构设计视图P64图5-1架构设计的5视图法逻辑架构：逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块和类等开发架构：开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发结构中的多个程序包；再比如开发架构中的源码文件可以包含逻辑架构中的一到多个类（在C++里一个源码文件可以包含多个类，即使在Java里一个源码文件也可以同时包含一个类和几个内部类运行架构：运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。运行架构和开发架构的关系：开发架构一般偏重程序包在编译使其的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题物理架构：物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题：物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的数据架构：数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。数据架构和物理架构的关系：对于很多集成系统，数据需要在不同系统之间传递、复制和暂存，这往往要涉及到不同的物理机器；也就是说，如果需要，可以把数据放在物理架构之中考虑，以便体现集成系统的数据分布与传递特征。架构设计的5视图法P65图5-2MySql的概念性架构QueryEngineTransactionControlBufferManagerTransactionControlTransactionControlDepends-onLegend界面设计需求分析时间工作内容需求分析期间开始界面设计启发需求需求分析领域建模为交流提供公共的领域词汇提供探索问题领域的语境项目启动领域建模需求分析架构设计详细设计详细设计详细设计需求捕获重新认识需求详述设计引起变更促成设计决策变更冲击设计需求捕获重新认识关键需求其余需求设计变更性小变更性大决定架构验证架构P200表14-2概念性架构实际架构开发实现关键设计元素关键交互机制逻辑架构数据架构开发架构运行架构物理架构详细设计编码实现基于５视力方法进行架构细化关键需求概念架构约束架构方案经验分析模型问题空间解空间设计模型系统分析员系统设计师《描述》《描述》《描述》《描述》方法缺少针对性设计层次论架构设计方法在OO过程中的位置什么是对架构关键的需求包括功能需求、质量（属性）需求、商业需求三类任何功能需求，都是由一条特定的“模块协作链”完成的。对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、最典型的功能需求。对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点支持的质量属性需求。商业需求又称业务需求（其实对应的英文都为BusinessRequirement）。它关注：客户群、企业现状、未来发展预算、立项包括开发、运营、维护在内的整个软件生命周期因素商业层面的目标、期望和限制等什么是对架构关键的需求具体步骤第一步：全面整理需求研究《愿景和范围文档》研究《软件需求规格说明书》参加需求讨论会询问客户、用户、领域专家、系统分析员突破字面意思分析遗漏需求第二步：分析约束性需求商业需求因素（第二步）商业需求因素（第二步）案例：银行系统（第二步）第三步：确定关键功能需求核心功能–标志：业务层的接口要反映这些功能必须实现的功能–往往来自甲方的要求。覆盖了系统架构的一些方面，而其他功能没有例如……实现风险高的功能例如……第四步：确定关键质量属性需求考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求；接下来，充分考虑这些质量属性之间的相互制约、或相互促进关系，以调整不同质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要；同时，必须满足各种约束性需求。不再拍脑袋：从场景到决策“属性-场景-决策表”方法整体质量观：如何权衡决策案例案例总结回顾包含非功能需求在内的一组关键需求，驱动了架构设计“属性-场景-决策表”是有效的非功能需求设计方法谢谢大家！