软件架构设计模式与实践.ppt

1,软件架构设计模式与实践,康凯,目录,软件架构视图软件生命周期与软件架构介绍架构设计的GRASP模式质量属性驱动架构设计策略软件架构模式分析及其实际运用架构设计原则面向对象的设计原则架构设计验证数据访问层设计（持久层设计）借鉴RUP中的设计流程领域模型及业务逻辑层在架构设计中的实现设计模式本质SOA的设计思想软件架构实践软件系统架构实践与剖析,前言,软件系统开始坏死的症状,一个软件系统开始坏死时表现的症状有:硬化Rigidity系统变得越来越难以变更,修复或增添新功能的代价高昂;脆弱Fragility对系统的任何哪怕是微小的变更都可能造成四处(甚至是与变更处没有逻辑上的关联之处J崩溃;绑死Immobility抽取系统的任何部分用来复用都非常困难;胶着Viscosity以与原有设计保持一致的方式来对实施变更已经非常困难,诱使开发人员绕过它选择容易但有害的途径,其结果却使系统死的更快。,什么是软件架构软件架构的概念很混乱。如果你问五个不同的人，可能会得到五种不同的答案。软件架构概念主要分为两大流派：组成派：软件架构=组件+交互。决策派：软件架构=重要决策集。组成派和决策派的概念相辅相成。,软件架构要层次化并隔离关注点复杂性是层次化的。-人月神话好的架构设计必须把变化点错落有致地封装到软件系统的不同部分(即关注点分离)。通过关注点分离，达到“系统中的一部分发生了变化，不会影响其他部分”的目标。,软件单元的粒度：粒度最小的单元通常是“类”。几个类紧密协作形成“模块”。完成相对独立的功能的多个模块构成了“子系统”。多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”。一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”。软件单元的粒度是相对的。同一个软件单元，在不同场景下我们会以不同的粒度看待它。,架构(Architecture)与框架(Framework)。框架只是一种特殊的软件，框架也有架构。可以通过架构框架化达到“架构重用”的目的，如很多人都在用Spring框架提供的控制反转和依赖注入来构建自己的架构。,软件架构的作用如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。-BarryBoehm,EngineeringContext一个缺陷充斥的系统，将始终是一个缺陷充斥的系统。-TimothyC.Lethbridge,面向对象软件工程软件架构设计为什么这么难？因为它是跨越现实世界与计算机世界之间鸿沟的一座桥。软件架构设计要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。需求-架构设计-软件架构-系统开发-软件系统,软件架构对新产品开发的作用：上承业务目标。下接技术决策。控制复杂性。先进行架构设计，后进行详细设计和编码实现，符合“基于问题深度分而治之”的理念。组织开发。软件架构方案在小组中间扮演了“桥梁”和“合作契约”的作用。利于迭代开发和增量交付。以架构为中心进行开发，为增量交付提供了良好的基础。在架构经过验证之后，可以专注于功能的增量提交。提高质量。,软件产品线：指具有一组可管理的、公共特性的、软件密集性系统的集合，这些系统满足特定的市场需求或任务需求，并且按照预定义方式从一个公共的核心资产集开发得到。软件产品线架构：针对一个公司或组织内的一系列产品而设计的通用架构。软件架构对软件产品线开发的作用：固化核心知识；提供可重用资产；缩短推出产品的周期；降低开发和维护成本；提高产品质量；支持批量定制；,架构师应当为项目相关的不同角色而设计：架构师要为客户负责，满足他们的业务目标和约束条件。架构师要为用户负责，满足他们关心的功能需求和运行期质量属性。架构师必须顾及处于协作分工“下游”的开发人员。架构师必须考虑“周边”的管理人员，为他们进行分工管理、协调控制和评估监控等工作提供清晰的基础。,软件架构视图,让设计建模更明白、更有效,张云贵2010-05-21,“系统架构图”？,架构设计的多重视图从根本上来说是因为需求种类的复杂性所致。比如一个媒体发布系统：功能需求：用户可以通过浏览器浏览媒体的发布。据此初步设计出采用浏览器插件的方案；约束条件：不能影响用户浏览器的安全性；细化设计方案，需要对插件进行认证，自动判别客户端是否存在，及版本比较；自动下载注册等。使用期质量属性：为保证浏览的流畅，应减少中间等待的时间，因此应对下一步需使用的媒体做预测等。制作发布期的质量保证：保证在遇到较大的媒体时能保持浏览的流畅，应在发布时将视频等流式化。,软件系统的需求种类复杂,什么是软件架构视图个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。多视图方法是软件架构归档的方法，更是指导我们进行架构设计的思维方法。,逻辑架构逻辑架构关注功能。其设计着重考虑功能需求。开发架构开发架构关注程序包。其设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。运行架构运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。物理架构物理架构关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。数据架构数据架构关注持久化数据的存储方案。设计着重考虑“数据需求”。,关系,逻辑视图。逻辑视图不仅关注用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。运行视图。和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行视图比较关注的正是这些运行时单元的交互问题。物理视图。和运行视图的关系：运行视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。,软件生命周期与软件架构介绍,24,软件架构师的定位,系统架构师的职责：一、理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架）二、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。系统架构师的目的：对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。系统架构师能力要求：一、系统架构相关的知识和经验。二、很强的自学能力、分析能力、解决问题的能力。三、写作、沟通表达、培训。,25,角色软件架构师SoftwareArchitect定义主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色,26,职责领导与协调整个项目中的技术活动（分析、设计和实施等）推动主要的技术决策，并最终表达为软件构架确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”确定设计元素的分组以及这些主要分组之间的接口为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现,27,专业技能技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力。具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等。具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策。拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任。,28,以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。,29,软件架构师的知识体系,软件架构师作为整个软件系统结构的总设计师，其知识体系、技能和经验决定了软件系统的可靠性、安全性、可维护性、可扩展性和可移植性等方面的性能。因此一个优秀的软件架构师必须具备相当丰富的知识、技能和经验。通过对比软件架构师和系统分析师在软件开发中的职责和角色，不难发现软件架构师与系统分析师所必需的知识体系也是不尽相同的，系统分析师的主要职责是在需求分析、开发管理、运行维护等方面，而软件架构师的重点工作是在架构与设计这两个关键环节上。因此在系统分析师必须具备的知识体系中对系统的构架与设计等方面知识体系的要求就相对低些；而软件架构师在需求分析、项目管理、运行维护等方面知识的要求也就相对低些。,30,成为一名合格的软件架构师必须具备的知识信息系统综合知识体系软件架构知识体系,31,？,MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ,32,软件架构师在干什么？,思考、思考、再思考深入理解、准确把握建设的业务需求分析所有可见的问题、障碍、风险充分参考已有的成功方案，降低风险交流、讨论、博弈、质疑对构思中的方案不断提出质疑，避免漏洞广泛听取各层面的意见，开拓思路反复质疑、逐步完善已有的设计构思在动手实现之前验证设计方案的正确性,33,软件架构师的知识结构,软件知识最好要有系统开发全过程经验。对IT建设生命周期各个环节有深入了解，包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。深入掌握1-2种主流技术平台上开发系统的方法。了解多种应用系统的结构。了解架构设计领域的主要理论、流派、框架。,34,软件架构师的知识结构,业务知识深入了解系统建设的业务需求。了解系统的非功能需求和运行维护需求。了解企业IT公共设施、网络环境、外部系统。,35,软件架构师的思维方式,基于框架的思维架构设计的层次（Enterprise，Application，etc）IT的生命周期（What，Why，Where，How，When，etc）成功经验以及方法论的指导合理把握技术细节把握各个层次应有的内容合理忽略不应有的技术细节,36,软件架构师的思维方式,风险管理意识采用成功经验、避免不应有的风险多方位的开放思维多维度、多方向、包容性、避免排他性分析、质疑、抽象、归纳没有绝对好的架构设计，只有相对优秀的方案,注意：并不存在通用的设计方法。我们认为，给定的某种固定的方法总是会顾此失彼，而且这种不平衡性不太容易觉察。如果给定的某种方法所注重的方面与系统需求不吻合，则这种方法就会将设计引入歧途。所以我们给出的是一些技巧，任何一次设计过程，都需要设计师仔细分析系统的需求和相关的约束条件，灵活运用众多的设计技巧，针对不同的设计方案进行取舍，做出合理的决策。,37,为了有效地控制设计工作的复杂性，一般把设计活动分为总体设计和详细设计两个层次。总体设计主要关注于体系结构和接口这些全局性的内容，而详细设计主要关注于每个模块内部的数据结构和算法。至于数据，则在设计的各个层次都会涉及。软件设计是一个迭代的过程，是一个逐步细化和求精的过程。因此，总体设计和详细设计之间的划分并不是绝对的。哪些是总体设计任务，哪些是详细设计任务，取决于设计师对于整个项目的把握，并没有一个统一的标准。设计师在设计时实际是在做一系列的设计决策，来满足系统的行为目标，质量目标和开发目标。如果一个结构对于完成这些目标非常重要，则它是构架的一部分。相反，如果它可以留到以后再完善，则它不是构架的组成部分。因此，总的说来，一个设计是不是属于构架设计，要看你当前的设计目标。,38,管理陷阱随着管理性责任的增加，你所从事技术性工作的时间就会显著减少。这样，因为在完成技术性任务和保持职业技能上花费时间的减少，你可能会失去技术优势。软件架构师和管理者有很大的差异：软件架构师是直接的技术贡献者；而管理者则是通过协调其他人员的活动来间接做出贡献。他们往往一起协作，构成高效的管理团队。以经验看，把两者结合起来却不能长久地工作。作为一名软件架构师，如果你已经建立起个人的职业原则的话，就有可能避免成为管理者。,架构和设计应该做到何种程度,软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。分而治之的两种方式分而治之的缘由：问题太复杂了，超出了人们能够“一蹴而就”的范围。（接口和实现分离）一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。二、先不研究整个问题，而是研究问题的一部分，分割问题。这种分而治之的方式称为“按问题广度分而治之”。（比如展现层、业务层和数据层的开发）,40,随着软件设计工作越来越复杂，将架构设计和详细设计分离已成为普遍的做法。将设计分为架构设计和详细设计，是对“按问题深度分而治之”思想的运用。所谓架构设计，就是关于如何构建软件的一些最重要的设计决策;详细设计针对每个部分的内部进行设计。可以这么说，软件架构设计应当解决的是全局性的、涉及不同“局部”之间交互的设计问题，而不同“局部”的设计由后续的详细设计负责。,41,面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径：一方面：“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有一寸深”。构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。没有“把问题研究那么深、那么细”，属于“按问题深度分而治之”,42,另一方面，因为“架构中包含了关于各元素应如何彼此相关的信息”，从而可以把不同模块分配给不同小组分头开发，而软件架构设计方案在这些小组中间扮演“桥梁”和“合作契约”的作用。每个小组的工作覆盖了“整个问题的一部分”，各小组之间可以互相独立地进行并行工作，这种“分割问题，各个击破”的策略，属于“按问题广度分而治之”。这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。例如，用户界面层、数据管理层、系统交互层。,43,架构要进行到什么程度软件架构是团队开发的基础，应明确规定后期分头开发所必须的公共设计约定，为分头开发提供足够的指导和限制。另一方面，具体的架构设计程度还会因软件项目的不同而不同。架构设计对软件的不同部分的设计程度并不是整齐划一的。(通信机制、持久化机制、消息机制等对应的公共模块；具体的业务功能模块在架构设计中往往设计程度不深。）归纳：由于项目的不同、开发团队情况的不同，软件架构的设计程度会有不同;软件架构应当为开发人员提供足够的指导和限制。,44,高来高去式架构设计的症状不能为开发人员提供足够的指导和限制的那种架构设计方案。高来高去式架构设计现象极为普遍，危害：缺少来自架构的足够的指导和限制，开发人员在进入分头开发阶段之后会碰到很多问题，并且容易造成管理混乱，沟通和协作效率低；对软件质量非常关键的全局性设计决定被拖延到分头开发期间草率决定；没有完成化解重大技术风险的职责；团队成员对架构师意见大，团队士气受到打击。,45,症状一：缺失重要架构视图。给团队的不同角色提供指导。症状二：架构设计方案停留在概念性架构的层面，全局性的设计决策最后由具体开发人员从局部视角考虑并确定下来，造成技术和管理上的种种问题。症状三：名不副实的分层架构。对各层之间交互接口和交互机制的设计严重不足。,46,47,架构设计的GRASP模式,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,质量属性驱动架构设计策略,软件质量及质量模型软件质量是一个复杂的概念，不同的人从不同的角度来看软件质量问题，会有不同的理解。从用户的角度看，质量就是满足客户的需求；从开发者的角度看，质量就是与需求说明保持一致；从产品的角度看，质量就是产品的内在特点；从价值的角度看，质量就是客户是否愿意购买。,在软件项目开发过程中，项目经理眼中的质量就是能“令人满意”地工作以完成预期功能的软件产品。所谓“令人满意”，包括功能、性能、接口需求及其他指标，如可靠性、可维护性、可复用性和正确性。然而在实际工作中，一旦出现问题时，项目管理人员必须权衡利弊，作出取舍，在满足某一个指标的同时，牺牲另外一个或几个指标。比如为了按期交货，需对软件功能进行分类，在第一个版本中实现优先级较高的功能，在第二个版本中实现优先级较低的功能。因此，项目经理需要一个对其工作有指导意义的质量模型和度量方法。该模型一方面可以帮助项目经理生产出符合标准的软件产品，另一方面帮助项目经理识别可能影响产品质量的风险。,为什么那么多软件产品需要重新设计？难以维护？运行速度太慢？稳定性差？无法进行功能扩展？易遭受安全攻击？忽视包括质量属性需求在内的非功能需求是致命的。,质量属性分为：运行期质量属性开发期质量属性各类需求架构设计的不同影响高可移植性对硬件和平台相关特性进行封装、隔离高性能精心规划职责模型在质量属性方面需求折衷,质量属性分析的位置质量属性分析是概念性架构设计的重要步骤。通过质量属性分析，制定出满足非功能需求的高层设计决策。质量属性分析所处的位置如图所示,”属性-场景-决策”表法运用“关键需求决定架构”的策略，使质量属性分析的“输入”集中到关键质量属性需求。“属性-场景-决策”表方法提倡通过一组具体场景将要达到的质量属性需求目标细化，再根据场景制定架构决策。,“属性-场景-决策“表法,“属性-场景-决策”表法的好处:可操作性强。质量熟悉需求是笼统的目标，而一组质量场景使之明确化。避免过度设计。借助“属性-场景-决策”表对质量场景进行评估，通过权衡场景发生的概率和遗漏它的代价，决定是否应满足该场景的要求。便于系统升级时参考。,例：可扩展性质量属性,运用“属性-场景-决策”表方法，细化PMTool的可扩展性需求，制定架构决策，如下表所示：,非功能需求对软件架构的影响比功能需求更大。“属性-场景-决策”表可以帮助软件架构师以一种更透明、更可操作的方式完成从质量属性需求到质量场景的细化，最终根据具体的场景有针对性地设计架构决策。,架构的目标,正确性correctness可靠性（Reliable）：软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。健壮性robustness安全性（Secure）：软件系统所承担的交易的商业价值极高，系统的安全性非常重要。可伸缩性（Scalable）：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。,可定制化（Customizable）：同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。可扩展性（Extensible）：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可复用性reusability可维护性（Maintainable）：软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。,兼容性compatibility可移植性portability易用性easeofuse高效性efficiencytimeliness,economyandfunctionality,客户体验（CustomerExperience）：软件系统必须易于使用。市场时机（TimetoMarket）：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。,87,软件可维护性,重型和轻型方法重型方法：偏重于计划、过程和中间产物敏捷方法：更加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产物，只是保证沟通、实现目标的手段。并非计划、过程、中间产物不重要，但不能本末倒置。评判软件成功的标准：很多。对敏捷方法：首先在于交付可用的软件。为了保证软件的可用性，需求是根本。对于架构设计工作，从需求出发来设计架构，是保证软件可用性的基本的保证。,如何开始架构设计工作考虑的平台、语言、开发环境、数据库等误区：架构设计就是写一些空话，套话。误区：对与客户具体情况密切相关的问题却未系统考虑。IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术？要针对需求设计架构。每个客户都有自身特点，如何才能够设计出符合客户利益的架构？软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往很难做到，但是如果不解决问题，风险又居高不下。,架构设计就是铺设软件的主管道。根据什么来制定主管道的粗细、路径等因素？是根据城市的人口、地理位置、水源等因素。对应到软件设计，城市的各因素就是软件中的各种需求：功能需求、非功能需求、变化案例等。例：城市中自来水管的架设是一项非常的复杂的工程。为了需要满足每家每户的需要，自来水管组成了一个庞大的网络。在这样一个复杂的网络中，如何完成铺设的任务呢。一般的做法是，先找出问题的根源，也就是水的源头。从水源铺设一条管道通至城市，然后根据城市的区域划分，设计出主管道，剩下的就是使用的问题了，每家每户的管道最终都是连到主管道上的。因此，虽然自来水网络庞大复杂。但是真正的主管道是比较简单的。,一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化案例决定架构的范围。功能需求决定软件能够做些什么。我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了性能、效率上的一些约束、规则。而我们的技术架构要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个架构的范围。例：一个字处理软件，功能需求可以简单概括为格式化用户输入的文字，非功能需求可能是格式化大小为1000K的一段文字的处理速度不能低于10S，变化案例可能是推出多种语言版本。则在设计业务架构时，我们会集中于如何表示文字、图象、媒体等要素，此外需要有另外的技术架构来处理速度问题，比如缓冲技术，对于变化案例，我们也要考虑相应的架构，比如把字体独立于程序包的设计。,架构设计的两项工作分析：分析是分析需求设计：设计软件的大致结构。很多方法论分离二者，其实无一定的界限，做分析的时候会想到如何设计，而思考如何设计反过来又会影响分析的效果。可以说，两者间是相互联系和不断迭代的。,需求与架构都应迭代进行一点一点的作需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用的流程是一种迭代式的流程，这里我们将会面临着如何对待上一次迭代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间产物，那么这种维护的成本未免过大。因此，敏捷方法论的基本做法是，扔掉那些已经没有用处的中间产物。软件要比文档重要。生成中间产物的目的都是为了生成最终的程序，对于这些已经完成作用的模型，没有必要付出额外的维护成本。,架构设计中的一些提示（也是抛弃模型的必要条件）：简单化：简单的模型和简单的程序。模型和程序越复杂，就需要更多的精力来处理它们。因此尽可能简化它们，为的是更容易的处理它们。高效沟通渠道：通过增强沟通的效果来减少对中间产物的需要。试想若随时能从客户处得到需求的细节资料，则前期需求调研就没有必要做得太细。角色交叉轮换：开发人员间建立起交换角色的机制，能够尽量的避免各子系统诸侯割据的局面。清晰的流程：或明确的过程。过程在方法论中是重点，敏捷方法论也不例外。开发人员能够清楚的知道，今天做什么，明天做什么。过程不是给别人看的，而是给自己用的。,工具：好用的工具能够节省大量的时间，工具并不仅指CASE工具，还包括版本控制工具、自动测试工具、画图工具、文档制作和管理工具。使用工具要注意成本和效益的问题。标准和风格：语言标准不同是沟通的很大障碍。语言从某个角度来看属于一种标准、一种风格。因此，一个团队如果采用同样的编码标准、文档标准、注释风格、制图风格，那么这个团队的沟通效率一定非常高。如果上述的环境都不具备，或是欠缺好几项，那你的文档的模型还是留着的好。,仅针对需求设计架构不要做未来才有用的事情。有时我们会把架构考虑得非常复杂，主要原因是把很多未来的因素放入到现在来考虑。或在开发第一个产品的时候就试图做成完美的框架。以上的这两种思路有没有错呢？没有错，这只是如何看待投入的问题，有人希望开始的时候多投入一些，这样后续的投入就会节省下来。但在现实中，由于需求的不确定性，希望通过增加开始阶段的投入来将降低未来的投入往往是难以做到的，框架的设计也绝非一蹴而就的，因此这种做法并不好。同其它很多事物一样，架构设计应保持简单性和迭代过程！,引入模式模式帮助我们抓住重点。为了解决设计文档编辑器引出的七个问题，一共使用了8种不同的模式。这8种模式的组合其实就是架构，因为它们解决的，都是系统中最高层的问题。架构也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式；对于交互系统，我们使用MVC（模型-视图-控制器）模式。模式本来就是针对特定问题的解，因此，针对需求的特点，我们也可以采用相应的模式来设计架构。,PetShot案例在MVC图背后隐藏着的需求：系统需要支持多种用户界面，包括为普通用户提供的HTML界面，为无线用户提供的WML界面，为管理员提供的Swing界面，以及为B2B业务设计的WebService界面。这是系统最重要的需求，因此，系统的设计者就需要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好处，可以在添加功能的同时，不涉及界面的改动，反之亦然。（耦合度的问题）。MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它呢？,抓住重点架构是一种抽象，即架构设计摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优先级最高、风险最大的那部分需求。考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶段投入过多的时间，因此关键点在于我们要能够在架构设计中把握住需求的重点。比如，分布式系统和交互系统，分布和交互就是这两个系统的重点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而宠物商店的范例也是类似的，除了MVC的架构，还有很多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图管理的前端控制器等。但是这些相对于MVC模式来说，属于局部的，优先级较低的部分，可以在架构确定后再来设计。,架构设计和领域专家一个架构要设计的好，和对需求的理解是分不开的。因此在现实中，业务领域专家凭借着他对业务领域的了解，能够帮助开发人员设计出优秀的架构来。架构是需要抽象的，它是现实社会活动的一个基本模型，而业务领域的模型仅仅凭开发人员是很难设计出来的。在ERP的发展史上，MRP发展为MRPII，再发展到闭环MRP，直到发展成为现在的ERP，主要的因素是管理思想的演化，也就是说，对业务领域的理解进步了，架构才有可能进步。因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用。,软件约束条件与架构的影响资金时间业务运行环境开发团队实现技术等,104,领域模型设计,领域模型（DomainModel）商业建模范畴的概念：同行业企业的业务模型必定有很大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，即领域模型。技术建模范畴的概念：用编程语言来实现商业领域模型。,关系：对行业经验积累不足的软件公司，开发软件由需求驱动，而非商业的领域模型驱动。商业领域模型与编程语言的不是一对一的对应关系。例如用EJB2模型，需要最少两个以上的EJB，即一个SessionBean，处理面向流程的控制逻辑，一个EntityBean，处理面向持久化的实体逻辑（持久化操作附着在EntityBean的Home接口上）。如果是更加复杂的领域模型，则需要更多的EJB，一般一个领域模型需要多个EntityBean和多个SessionBean。使用基于POJO模型的实现，则粗颗粒度的EJB要继续细分：一个EntityBean对应三个以上POJO：一个或者多个实体类，DAO接口、DAO接口实现类；一个SessionBean要切分为多个业务Bean。,105,106,层次结构领域模型从EJB到轻量级框架,107,层次结构,表现层（present）业务层业务层外观业务服务层领域对象管理/服务/仓库层领域对象层持久层数据访问层数据库,108,领域模型中的各种角色：实体-有唯一的标识,并且要有属性和行为(非GET/SET)，添加了行为，使其具有生命力。往往在设计时，实体的形为最难决断。为确定行为，我们必须识别它们的责任和协作。类的责任是指该类要做、知道、或决定的一切，由一个或多个方法完成。类中有属性和关联，协作就是为完成自己的责任所调用其它关联类。值对象-没有标识没有行为。如Address类。工厂-定义创建实体的方法，封装实例化对象并将一些关联对象注入。仓库(repository)管理实体的集合,主要有查找和删除实体的方法.实现类可以调用执久化层(如Hibernate，Ibatis)服务(Service)，实现整个应用程序的工作流(workflow)。服务包含那些无法指派的单个实体的行为，由作用于多个对象方法组成。如可以调用repository查找到实体对象，然后委派给这些对象。服务和facade很像，但不一样，它不处理以下事情：1）执行事务。2）收集返回给表现层的数据。3）脱钩对象。4）其它事情。服务可以说是业务的协调者，业务逻辑可以分散到实体对象中。,109,2、层次之间的交互A、页面提交表单数据到Action，Action创建DTO对象并设置相应属性值为表单数据B、Action传递DTO对象给FacadeC、Facade中套用ServiceTemplate事务模板以加入事务管理，在ServiceTemplate中根据具体业务调用Factory或Reposistory，分别create或者load出DomainModel对象D、Facade传递DomainModel对象给ServiceE、Service执行具体业务逻辑（调用DomainModel对象相应的业务方法）F、Service调用Reposistory对状态已改变的DomainModel对象进行持久化操作（调用相应DAO）,110,注：在Facade或Service中如果需要查询DomainModel对象中的属性值，调用DomainModel对象的getDataInfo()方法得到DataInfo对象，通过DataInfo对象查询所需数据，包括Service返回给Faade业务处理结果中所包含的业务数据。,111,112,领域模型,失血模型贫血模型充血模型胀血模型,113,失血模型,DO只有属性及其getter/setter方法，没有任何业务逻辑。缺点：行为与数据分离，很多情况导致维护与理解困难。,114,贫血模型,DO包含不依赖于持久化的领域逻辑；依赖持久化的领域逻辑归入Service层。Service(业务逻辑，事务封装)DAODO优点：各层单向依赖，结构清楚，易于实现和维护。设计简单易行，底层模型非常稳定。缺点：DO部分的持久化逻辑被放入Service层，不够OO。Service层过重。,115,充血模型,与贫血模型类似，不同处在于如何划分业务逻辑：绝大多业务逻辑都应该放在DO里(包括持久化逻辑)，而Service层很薄，仅仅封装事务和少量逻辑，不和DAO层打交道。Service(事务封装)DODAO优点：符合OOService层很薄，只充当Facade的角色，不和DAO打交道。,116,缺点：DAO和DO双向依赖。如何划分Service层逻辑和Domain层逻辑没有确定的规则，取决与设计人员自己的理解。Service层封装事务，须对所有的DO逻辑提供相应的事务封装方法，造成重定义所有的Domainlogic。Service的事务化封装的意义等于把OO的Domainlogic转换为过程的Service事务脚本。充血模型在domain层实现的OO在Service层又变成了面向过程。,117,胀血模型,取消Service层，只剩下DO和DAO层，在DO的domainlogic上面封装事务。DO(事务封装，业务逻辑)DAO(RoR甚至合并为一层）优点：分层简化符合OO缺点：service逻辑也强行放入DO，引起了DO不稳定。DO暴露给web层过多的信息，可能引起不必要的耦合。,118,原则：业务对象封装了内在的业务逻辑，而应用服务封装了外在于业务对象的业务逻辑。,119,EJB到轻量级框架,EJBPOJO（业务逻辑）+轻量级框架（Hibernate、JDO、iBATIS（持久化）、Spring（事务管理、安全）,120,EJB,EJB：编写分布式业务应用程序的Java标准架构。提供大量服务：声明型事务,EIB容器自动启动、提交和回滚事务。业务逻辑能参与由远程客户发起的分布式事务。提供声明型安全，大部分情况下不再摇要编写安全代码求（bean部署描述符里的条目指定准可以防问某个具体bean）。,121,例：在两个账号间进行转账的服务。,122,123,新设计是面向对象、基于POJO,而非基于EJB的过程式。它使用构建在JDBC上的持久层框架来访问数据库,并不直接使用JDBC。业务逻辑由POJOfacade而非会话bean进行封装。事务由Spring框架而非EJB容器进行管理。业务逻辑向表现层返回实际的业务对象,而不是DTO。应用程序通过将组件的依赖作为setter或构造子参数传入来进行组装,而不是之前采用Java命名和目录接口(JNDI)查询的组件。由于该设计面向对象,并采用上述轻量级技术,因此较之前看到的EJB版本对开发人员要友好。,124,基于轻量级框架设计的好处是，它提供事务和持久化时并不要求应用程序类实现任何特殊接口。甚至当应用程序的类需要运行在事务里或是持久的时候，它们仍是POJO，设计者可以继续享受POJO的种种好处。,125,126,面向对象的优点：整个设计更易理解和维护。它并不是一个无所不能的大型类,而是由大量小类组成,每个类只共有若干职责。此外,诸如Account、BankingTransaction和OverdraftPolicy类都与现实世界的概念对应,因此易于理解。其次,面向对象设汁也更易测试:所有类都能并且应当进行独立的测试。EJB只能通过调用它的public方法如Transter进行测试,难度大。(只能测试p-blic方法暴露的复杂功能,无法测试其中简单的部分）。面向对象象设计更易扩展,它可使用设计模式，如Stategy和Template等。EJB风格的过程式设计往往需耍修改核心代码。,127,不适合用面向对象的场合：大量数据集合的关系操作。以数据库为中心的管理程序：这个领域所对应的现实世界是一个面向关系的世界，表与表的关联体现的是彼此的业务关系。复杂的SQL固然不好维护，但业务真是复杂到简单的SQL都难以描述的程度，采用面向对象描述则更加困难，维护也更困难，同时还损失了效率。比较大的事务。性能要求高的地方。（直接用Sql或者存储过程；牺牲可维护性和可复用性）上层流程。,128,消除DTO,129,部署POJO程序,130,131,软件架构模式分析及其实际运用,软件架构软件架构概论架构的目标架构的种类软件框架常见的架构模式,软件架构概论,系统架构是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心砖瓦，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。,建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过慎重的研究和考察。,架构的种类,根据我们关注的角度不同，可以将架构分成三种：逻辑架构物理架构系统架构,逻辑架构,软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件等等。,物理架构,软件元件是怎样放到硬件上的下图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。,系统架构,系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作是架构设计工作中最困难的工作。,架构的两要素,元件划分和设计决定。逻辑元件：一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。设计决定：进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。基于数据库的系统架构：一般有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。,从概念性架构到实际架构就是多(Lessismore.)。-密斯凡德罗概念性架构是对系统设计的最初构想。一般来说，实际的软件架构设计过程是，先进行概念性架构的设计，把最关键的设计要素和交互机制确定下来，然后再考虑具体技术的运用，设计出实际架构。,架构设计中的关键要素及解决策略策略是制胜的关键。-张明正，挡不住的趋势最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。-RobertC.Martin,软件之美时间就是系统架构的生命。-PhilippeKruchten方法产生于恐惧。面对时间紧迫的压力，我们有理由质疑那种不顾时间花销、一味追求软件架构高质量的做法。软件架构是软件系统质量的核心，必须足够重视，但在不适当的时候“用时间换完美”会毁掉整个项目。架构设计并非“好的就是成功的”，而是“适合的才是成功的”。,方法论,AlistairCockburn的七条定理，总结为：沟通和反馈。RUP、XP重量之争,软件架构设计中的关键要素及解决策略：关键要素策略-1.是否遗漏了至关重要的非功能需求？全面认识需求。2.能否驯服数量巨大且频繁变化的需求？关键需求决定架构。3.能否从容地设计软件架构的不同方面？多视图探寻架构。4.是否及早验证架构方案并作出了调整？及早验证架构。,软件架构设计过程总览一般的软件过程：,需求分析的几个概念需求捕获vs需求分析vs系统分析需求捕获是获取知识的过程，知识从无到有。需求分析是挖掘和整理知识的过程，它在已掌握知识的基础上进行。系统分析？如果说需求分析致力于“做什么”，那么系统分析则涉及“怎么做”。软件架构师不必是需求捕获专家，也不必是编写软件需求规格说明书的专家。但他一定应在需求分类、需求折衷和需求变更的研究方面是专家，否则他和其他软件架构师相比，就输在了“起跑线”上。,概念性架构设计概念性架构设计的迭代方式：1.鲁棒性分析；2.引入架构模式；3.质量属性分析。,鲁棒性分析所谓鲁棒性分析是这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，形成以职责模型为主的初步设计。鲁棒性分析是从功能需求向设计方案过度的第一步，所获得的初步设计是一种理想化的职责模型，它的重点是识别组成软件系统的高级职责块、规划它们之间的关系。鲁棒性分析填补了分析和设计之间的鸿沟。鲁棒图包含三种元素：边界对象、控制对象和实体对象。,引入架构模式较为经典的几种架构模式：分层、MVC、微内核、基于元模型的架构、管道-过滤器等。,质量属性分析“属性-场景-决策”表方法：,细化架构设计架构细化工作主要体现在基于五视图方法进行架构细化：约束领域模型-基于五视图方法关键需求-架构方案概念架构-进行架构细化经验,逻辑架构设计中，“发现通用机制”是应被特别强调的。机制(Mechanism)是模式的实例。机制是特定上下文中重复出现的问题的特定解决方案。具有良好架构的系统具备概念完整性。它通过对系统架构建立一种清晰的认识来发现通用的抽象和机制。利用这种共性使最终产生的系统结构更为简单。,实现并验证软件架构好的策略必须是一再求证、测试、发现瑕疵漏洞，另想途径或方法来弥补策略不足，有时甚至得全盘放弃，重新策划。-张明正，挡不住的趋势架构原型对功能性需求的实现非常有限，那么“架构验证”要验证什么？答案是要验证架构对质量属性需求的支持程度，包括运行期质量属性和开发期质量属性。,验证架构的两种方法：原型法。对于项目型开发，常采用“原型法”。即对一组架构设计决策在非功能需求方面的满足程度进行验证。该原型往往是演进型，而非抛弃型。框架法。对于产品型开发，采用“框架法”有更多优点。该方法将架构设计方案用框架的形式实现，并在此基础上进行评估验证。在框架实现后，在框架基础上实现部分应用的功能，即实现一个小的垂直原型，从而进行实际非