高级软件架构设计师实战

1高级软件架构设计师实战康凯软件系统开始坏死的病症一个软件系统开始坏死时表现的病症有:硬化Rigidity——系统变得越来越难以变更,修复或增添新功能的代价高昂;脆弱Fragility——对系统的任何哪怕是微小的变更都可能造成四处(甚至是与变更处没有逻辑上的关联之处J崩溃;绑死Immobility——抽取系统的任何局部用来复用都非常困难;胶着Viscosity——以与原有设计保持一致的方式来对实施变更已经非常困难,诱使开发人员绕过它选择容易但有害的途径,其结果却使系统死的更快。

什么是软件架构软件架构的概念很混乱。如果你问五个不同的人，可能会得到五种不同的答案。软件架构概念主要分为两大流派：组成派：软件架构=组件+交互。决策派：软件架构=重要决策集。组成派和决策派的概念相辅相成。软件架构要层次化并隔离关注点复杂性是层次化的。--《人月神话》好的架构设计必须把变化点错落有致地封装到软件系统的不同局部(即关注点别离)。通过关注点别离，到达“系统中的一局部发生了变化，不会影响其他局部”的目标。软件单元的粒度：粒度最小的单元通常是“类”。几个类紧密协作形成“模块”。完成相对独立的功能的多个模块构成了“子系统”。多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”。一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”。软件单元的粒度是相对的。同一个软件单元，在不同场景下我们会以不同的粒度看待它。架构(Architecture)与框架(Framework)。框架只是一种特殊的软件，框架也有架构。可以通过架构框架化到达“架构重用”的目的，如很多人都在用Spring框架提供的控制反转和依赖注入来构建自己的架构。软件架构的作用如果一个工程的系统架构(包括理论根底)尚未确定，就不应该进行此系统的全面开发。--BarryBoehm,《EngineeringContext》一个缺陷充满的系统，将始终是一个缺陷充满的系统。--TimothyC.Lethbridge,《面向对象软件工程》软件架构设计为什么这么难？因为它是跨越现实世界与计算机世界之间鸿沟的一座桥。软件架构设计要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。需求->架构设计->软件架构->系统开发->软件系统软件架构对新产品开发的作用：上承业务目标。下接技术决策。控制复杂性。先进行架构设计，后进行详细设计和编码实现，符合“基于问题深度分而治之”的理念。组织开发。软件架构方案在小组中间扮演了“桥梁”和“合作契约”的作用。利于迭代开发和增量交付。以架构为中心进行开发，为增量交付提供了良好的根底。在架构经过验证之后，可以专注于功能的增量提交。提高质量。软件产品线：指具有一组可管理的、公共特性的、软件密集性系统的集合，这些系统满足特定的市场需求或任务需求，并且按照预定义方式从一个公共的核心资产集开发得到。软件产品线架构：针对一个公司或组织内的一系列产品而设计的通用架构。软件架构对软件产品线开发的作用：固化核心知识；提供可重用资产；缩短推出产品的周期；降低开发和维护本钱；提高产品质量；支持批量定制；架构师应当为工程相关的不同角色而设计：架构师要为客户负责，满足他们的业务目标和约束条件。架构师要为用户负责，满足他们关心的功能需求和运行期质量属性。架构师必须顾及处于协作分工“下游”的开发人员。架构师必须考虑“周边”的管理人员，为他们进行分工管理、协调控制和评估监控等工作提供清晰的根底。软件架构视图——让设计建模更明白、更有效张云贵2010-05-21“系统架构图”？架构设计的多重视图从根本上来说是因为需求种类的复杂性所致。比方一个媒体发布系统：功能需求：用户可以通过浏览器浏览媒体的发布。据此初步设计出采用浏览器插件的方案；约束条件：不能影响用户浏览器的平安性；细化设计方案，需要对插件进行认证，自动判别客户端是否存在，及版本比较；自动下载注册等。使用期质量属性：为保证浏览的流畅，应减少中间等待的时间，因此应对下一步需使用的媒体做预测等。制作发布期的质量保证：保证在遇到较大的媒体时能保持浏览的流畅，应在发布时将视频等流式化。软件系统的需求种类复杂什么是软件架构视图个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的方法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。多视图方法是软件架构归档的方法，更是指导我们进行架构设计的思维方法。逻辑架构逻辑架构关注功能。其设计着重考虑功能需求。开发架构开发架构关注程序包。其设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。运行架构运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和平安性等。物理架构物理架构关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。数据架构数据架构关注持久化数据的存储方案。设计着重考虑“数据需求”。关系逻辑视图。逻辑视图不仅关注用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比方逻辑层一般会映射到多个程序包等。运行视图。和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行视图比较关注的正是这些运行时单元的交互问题。物理视图。和运行视图的关系：运行视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

软件生命周期与软件架构介绍22软件架构师的定位系统架构师的职责：一、理解系统的业务需求，制定系统的整体框架〔包括：技术框架和业务框架〕二、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。系统架构师的目的：对系统的重用、扩展、平安、性能、伸缩性、简洁等做系统级的把握。系统架构师能力要求：一、系统架构相关的知识和经验。二、很强的自学能力、分析能力、解决问题的能力。三、写作、沟通表达、培训。23角色软件架构师SoftwareArchitect定义主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色24职责领导与协调整个工程中的技术活动〔分析、设计和实施等〕推动主要的技术决策，并最终表达为软件构架确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”确定设计元素的分组以及这些主要分组之间的接口为技术决策提供规那么，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现25专业技能技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力。具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。对工程开发涉及的所有问题领域都有经验，包括彻底地理解工程需求，开展分析设计之类软件工程活动等。具备领导素质，以在各小组之间推进技术工作，并在工程压力下做出牢靠的关键决策。拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得工程成员的信任。26以目标导向和主动的方式来不带任何感情色彩地关注工程结果，构架师应当是工程背后的技术推动力，而非设想者或梦想家〔追求完美〕精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。27软件架构师的知识体系软件架构师作为整个软件系统结构的总设计师，其知识体系、技能和经验决定了软件系统的可靠性、平安性、可维护性、可扩展性和可移植性等方面的性能。因此一个优秀的软件架构师必须具备相当丰富的知识、技能和经验。通过比照软件架构师和系统分析师在软件开发中的职责和角色，不难发现软件架构师与系统分析师所必需的知识体系也是不尽相同的，系统分析师的主要职责是在需求分析、开发管理、运行维护等方面，而软件架构师的重点工作是在架构与设计这两个关键环节上。因此在系统分析师必须具备的知识体系中对系统的构架与设计等方面知识体系的要求就相对低些；而软件架构师在需求分析、工程管理、运行维护等方面知识的要求也就相对低些。28成为一名合格的软件架构师必须具备的知识信息系统综合知识体系软件架构知识体系29？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ…30软件架构师在干什么？思考、思考、再思考深入理解、准确把握建设的业务需求分析所有可见的问题、障碍、风险充分参考已有的成功方案，降低风险交流、讨论、博弈、质疑对构思中的方案不断提出质疑，防止漏洞广泛听取各层面的意见，开拓思路反复质疑、逐步完善已有的设计构思在动手实现之前验证设计方案的正确性31软件架构师的知识结构软件知识最好要有系统开发全过程经验。对IT建设生命周期各个环节有深入了解，包括：系统/模块逻辑设计、物理设计、代码开发、工程管理、测试、发布、运行维护等。深入掌握1-2种主流技术平台上开发系统的方法。了解多种应用系统的结构。了解架构设计领域的主要理论、流派、框架。32软件架构师的知识结构业务知识深入了解系统建设的业务需求。了解系统的非功能需求和运行维护需求。了解企业IT公共设施、网络环境、外部系统。33软件架构师的思维方式基于框架的思维架构设计的层次〔Enterprise，Application，etc〕IT的生命周期〔What，Why，Where，How，When，etc〕成功经验以及方法论的指导合理把握技术细节把握各个层次应有的内容合理忽略不应有的技术细节34软件架构师的思维方式风险管理意识采用成功经验、防止不应有的风险多方位的开放思维多维度、多方向、包容性、防止排他性分析、质疑、抽象、归纳没有绝对好的架构设计，只有相对优秀的方案注意：并不存在通用的设计方法。我们认为，给定的某种固定的方法总是会顾此失彼，而且这种不平衡性不太容易觉察。如果给定的某种方法所注重的方面与系统需求不吻合，那么这种方法就会将设计引入歧途。所以我们给出的是一些技巧，任何一次设计过程，都需要设计师仔细分析系统的需求和相关的约束条件，灵活运用众多的设计技巧，针对不同的设计方案进行取舍，做出合理的决策。35为了有效地控制设计工作的复杂性，一般把设计活动分为总体设计和详细设计两个层次。总体设计主要关注于体系结构和接口这些全局性的内容，而详细设计主要关注于每个模块内部的数据结构和算法。至于数据，那么在设计的各个层次都会涉及。软件设计是一个迭代的过程，是一个逐步细化和求精的过程。因此，总体设计和详细设计之间的划分并不是绝对的。哪些是总体设计任务，哪些是详细设计任务，取决于设计师对于整个工程的把握，并没有一个统一的标准。设计师在设计时实际是在做一系列的设计决策，来满足系统的行为目标，质量目标和开发目标。如果一个结构对于完成这些目标非常重要，那么它是构架的一局部。相反，如果它可以留到以后再完善，那么它不是构架的组成局部。因此，总的说来，一个设计是不是属于构架设计，要看你当前的设计目标。36管理陷阱随着管理性责任的增加，你所从事技术性工作的时间就会显著减少。这样，因为在完成技术性任务和保持职业技能上花费时间的减少，你可能会失去技术优势。软件架构师和管理者有很大的差异：软件架构师是直接的技术奉献者；而管理者那么是通过协调其他人员的活动来间接做出奉献。他们往往一起协作，构成高效的管理团队。以经验看，把两者结合起来却不能长久地工作。作为一名软件架构师，如果你已经建立起个人的职业原那么的话，就有可能防止成为管理者。架构和设计应该做到何种程度38软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。分而治之的两种方式分而治之的缘由：问题太复杂了，超出了人们能够“一蹴而就”的范围。〔接口和实现别离〕一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。二、先不研究整个问题，而是研究问题的一局部，分割问题。这种分而治之的方式称为“按问题广度分而治之”。〔比方展现层、业务层和数据层的开发〕39随着软件设计工作越来越复杂，将架构设计和详细设计别离已成为普遍的做法。将设计分为架构设计和详细设计，是对“按问题深度分而治之”思想的运用。所谓架构设计，就是关于如何构建软件的一些最重要的设计决策;详细设计针对每个局部的内部进行设计。可以这么说，软件架构设计应当解决的是全局性的、涉及不同“局部”之间交互的设计问题，而不同“局部”的设计由后续的详细设计负责。40面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径：一方面：“软件系统的架构涵盖了整个系统，尽管架构的有些局部可能只有‘一寸深’”。构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。没有“把问题研究那么深、那么细”，属于“按问题深度分而治之”41另一方面，因为“架构中包含了关于各元素应如何彼此相关的信息”，从而可以把不同模块分配给不同小组分头开发，而软件架构设计方案在这些小组中间扮演“桥梁”和“合作契约”的作用。每个小组的工作覆盖了“整个问题的一局部”，各小组之间可以互相独立地进行并行工作，这种“分割问题，各个击破”的策略，属于“按问题广度分而治之”。这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。例如，用户界面层、数据管理层、系统交互层

。42架构要进行到什么程度软件架构是团队开发的根底，应明确规定后期分头开发所必须的公共设计约定，为分头开发提供足够的指导和限制。另一方面，具体的架构设计程度还会因软件工程的不同而不同。架构设计对软件的不同局部的设计程度并不是整齐划一的。(通信机制、持久化机制、消息机制等对应的公共模块；具体的业务功能模块在架构设计中往往设计程度不深。〕归纳：由于工程的不同、开发团队情况的不同，软件架构的设计程度会有不同;软件架构应当为开发人员提供足够的指导和限制。43高来高去式架构设计的病症不能为开发人员提供足够的指导和限制的那种架构设计方案。高来高去式架构设计现象极为普遍，危害：缺少来自架构的足够的指导和限制，开发人员在进入分头开发阶段之后会碰到很多问题，并且容易造成管理混乱，沟通和协作效率低；对软件质量非常关键的全局性设计决定被拖延到分头开发期间草率决定；没有完成化解重大技术风险的职责；团队成员对架构师意见大，团队士气受到打击。44病症一：缺失重要架构视图。给团队的不同角色提供指导。病症二：架构设计方案停留在概念性架构的层面，全局性的设计决策最后由具体开发人员从局部视角考虑并确定下来，造成技术和管理上的种种问题。病症三：名不副实的分层架构。对各层之间交互接口和交互机制的设计严重缺乏。45架构设计过程重型和轻型方法重型方法：偏重于方案、过程和中间产物敏捷方法：更加看重人和沟通。人和沟通永远是第一位的，而方案、过程和中间产物，只是保证沟通、实现目标的手段。并非方案、过程、中间产物不重要，但不能本末倒置。评判软件成功的标准：很多。对敏捷方法：首先在于交付可用的软件。为了保证软件的可用性，需求是根本。对于架构设计工作，从需求出发来设计架构，是保证软件可用性的根本的保证。

如何开始架构设计工作考虑的平台、语言、开发环境、数据库等误区：架构设计就是写一些空话，套话。误区：对与客户具体情况密切相关的问题却未系统考虑。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，主要的因素是管理思想的演化，也就是说，对业务领域的理解进步了，架构才有可能进步。因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用。软件约束条件与架构的影响资金时间业务运行环境开发团队实现技术等63领域模型设计领域模型〔DomainModel〕商业建模范畴的概念：同行业企业的业务模型必定有很大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，即领域模型。技术建模范畴的概念：用编程语言来实现商业领域模型。关系：对行业经验积累缺乏的软件公司，开发软件由需求驱动，而非商业的领域模型驱动。商业领域模型与编程语言的不是一对一的对应关系。例如用EJB2模型，需要最少两个以上的EJB，即一个SessionBean，处理面向流程的控制逻辑，一个EntityBean，处理面向持久化的实体逻辑〔持久化操作附着在EntityBean的Home接口上〕。如果是更加复杂的领域模型，那么需要更多的EJB，一般一个领域模型需要多个EntityBean和多个SessionBean。使用基于POJO模型的实现，那么粗颗粒度的EJB要继续细分：一个EntityBean对应三个以上POJO：一个或者多个实体类，DAO接口、DAO接口实现类；一个SessionBean要切分为多个业务Bean。6465层次结构领域模型从EJB到轻量级框架66层次结构表现层〔present〕业务层业务层外观业务效劳层领域对象管理/效劳/仓库层领域对象层持久层数据访问层数据库67领域模型中的各种角色：实体--有唯一的标识,并且要有属性和行为(非GET/SET)，添加了行为，使其具有生命力。往往在设计时，实体的形为最难决断。为确定行为，我们必须识别它们的责任和协作。类的责任是指该类要做、知道、或决定的一切，由一个或多个方法完成。类中有属性和关联，协作就是为完成自己的责任所调用其它关联类。值对象--没有标识没有行为。如Address类。工厂---定义创立实体的方法，封装实例化对象并将一些关联对象注入。仓库(repository)管理实体的集合,主要有查找和删除实体的方法.实现类可以调用执久化层(如Hibernate，Ibatis)效劳(Service)，实现整个应用程序的工作流(workflow)。效劳包含那些无法指派的单个实体的行为，由作用于多个对象方法组成。如可以调用repository查找到实体对象，然后委派给这些对象。效劳和facade很像，但不一样，它不处理以下事情：1〕执行事务。2〕收集返回给表现层的数据。3〕脱钩对象。4〕其它事情。效劳可以说是业务的协调者，业务逻辑可以分散到实体对象中。682、层次之间的交互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〕69注：在Facade或Service中如果需要查询DomainModel对象中的属性值，调用DomainModel对象的getDataInfo()方法得到DataInfo对象，通过DataInfo对象查询所需数据，包括Service返回给Façade业务处理结果中所包含的业务数据。7071领域模型失血模型贫血模型充血模型胀血模型72失血模型DO只有属性及其getter/setter方法，没有任何业务逻辑。缺点：行为与数据别离，很多情况导致维护与理解困难。73贫血模型DO包含不依赖于持久化的领域逻辑；依赖持久化的领域逻辑归入Service层。Service(业务逻辑，事务封装)DAODO优点：各层单向依赖，结构清楚，易于实现和维护。设计简单易行，底层模型非常稳定。缺点：DO局部的持久化逻辑被放入Service层，不够OO。Service层过重。74充血模型与贫血模型类似，不同处在于如何划分业务逻辑：绝大多业务逻辑都应该放在DO里(包括持久化逻辑)，而Service层很薄，仅仅封装事务和少量逻辑，不和DAO层打交道。Service(事务封装)DODAO优点：符合OOService层很薄，只充当Facade的角色，不和DAO打交道。75缺点：DAO和DO双向依赖。如何划分Service层逻辑和Domain层逻辑没有确定的规那么，取决与设计人员自己的理解。Service层封装事务，须对所有的DO逻辑提供相应的事务封装方法，造成重定义所有的Domainlogic。Service的事务化封装的意义等于把OO的Domainlogic转换为过程的Service事务脚本。充血模型在domain层实现的OO在Service层又变成了面向过程。76胀血模型取消Service层，只剩下DO和DAO层，在DO的domainlogic上面封装事务。DO(事务封装，业务逻辑)DAO(RoR甚至合并为一层〕

优点：分层简化符合OO缺点：service逻辑也强行放入DO，引起了DO不稳定。DO暴露给web层过多的信息，可能引起不必要的耦合。77原那么：业务对象封装了内在的业务逻辑，而应用效劳封装了外在于业务对象的业务逻辑。78EJB到轻量级框架EJBPOJO〔业务逻辑〕+轻量级框架〔[Hibernate、JDO、iBATIS]〔持久化〕、Spring〔事务管理、平安〕〕79EJBEJB：编写分布式业务应用程序的Java标准架构。提供大量效劳：声明型事务,EIB容器自动启动、提交和回滚事务。业务逻辑能参与由远程客户发起的分布式事务。提供声明型平安，大局部情况下不再摇要编写平安代码求〔bean部署描述符里的条目指定准可以防问某个具体bean〕。80例：在两个账号间进行转账的效劳。8182新设计是面向对象、基于POJO,而非基于EJB的过程式。它使用构建在JDBC上的持久层框架来访问数据库,并不直接使用JDBC。业务逻辑由POJOfacade而非会话bean进行封装。事务由Spring框架而非EJB容器进行管理。业务逻辑向表现层返回实际的业务对象,而不是DTO。应用程序通过将组件的依赖作为setter或构造子参数传入来进行组装,而不是之前采用Java命名和目录接口(JNDI)查询的组件。由于该设计面向对象,并采用上述轻量级技术,因此较之前看到的EJB版本对开发人员要友好。83基于轻量级框架设计的好处是，它提供事务和持久化时并不要求应用程序类实现任何特殊接口。甚至当应用程序的类需要运行在事务里或是持久的时候，它们仍是POJO，设计者可以继续享受POJO的种种好处。8485面向对象的优点：整个设计更易理解和维护。它并不是一个无所不能的大型类,而是由大量小类组成,每个类只共有假设干职责。此外,诸如Account、BankingTransaction和OverdraftPolicy类都与现实世界的概念对应,因此易于理解。其次,面向对象设汁也更易测试:所有类都能并且应当进行独立的测试。EJB只能通过调用它的public方法如Transter进行测试,难度大。(只能测试p-blic方法暴露的复杂功能,无法测试其中简单的局部〕。面向对象象设计更易扩展,它可使用设计模式，如Stategy和Template等。EJB风格的过程式设计往往需耍修改核心代码。86不适合用面向对象的场合：大量数据集合的关系操作。以数据库为中心的管理程序：这个领域所对应的现实世界是一个面向关系的世界，表与表的关联表达的是彼此的业务关系。复杂的SQL固然不好维护，但业务真是复杂到简单的SQL都难以描述的程度，采用面向对象描述那么更加困难，维护也更困难，同时还损失了效率。比较大的事务。性能要求高的地方。〔直接用Sql或者存储过程；牺牲可维护性和可复用性〕上层流程。87消除DTO88部署POJO程序899091用GRASP模式指导设计9293949596979899100101102103104105106107108109110质量属性驱动架构设计策略软件质量及质量模型软件质量是一个复杂的概念，不同的人从不同的角度来看软件质量问题，会有不同的理解。从用户的角度看，质量就是满足客户的需求；从开发者的角度看，质量

就是与需求说明保持一致；从产品的角度看，质量就是

产品的内在特点；从价值的角度看，质量就是客户是否

愿意购置。

在软件工程开发过程中，工程经理眼中的质量就是能“令人满意”地工作以完成预期功能的软件产品。所谓“令

人满意”，包括功能、性能、接口需求及其他指标，如可靠性、可维护性、可复用性和正确性。然而在实际工作中，一旦出现问题时，工程管理人员必须权衡利弊，作出取舍，在满足某一个指标的同时，牺牲另外一个或几个指标。比方为了按期交货，需对软件功能进行分类，在第

一个版本中实现优先级较高的功能，在第二个版本中实

现优先级较低的功能。因此，工程经理需要一个对其工作有指导意义的质量模型和度量方法。该模型一方面可以帮助工程经理生产出符合标准的软件产品，另一方面帮助工程经理识别可能影响产品质量的风险。为什么那么多软件产品需要重新设计？难以维护？运行速度太慢？稳定性差？无法进行功能扩展？易遭受平安攻击？无视包括质量属性需求在内的非功能需求是致命的。质量属性分为：运行期质量属性开发期质量属性各类需求架构设计的不同影响高可移植性对硬件和平台相关特性进行封装、隔离高性能精心规划职责模型在质量属性方面需求折衷质量属性分析的位置质量属性分析是概念性架构设计的重要步骤。通过质量属性分析，制定出满足非功能需求的高层设计决策。质量属性分析所处的位置如下图”属性-场景-决策”表法运用“关键需求决定架构”的策略，使质量属性分析的“输入”集中到关键质量属性需求。“属性-场景-决策”表方法提倡通过一组具体场景将要到达的质量属性需求目标细化，再根据场景制定架构决策。“属性-场景-决策“表法“属性-场景-决策”表法的好处:可操作性强。质量熟悉需求是笼统的目标，而一组质量场景使之明确化。防止过度设计。借助“属性-场景-决策”表对质量场景进行评估，通过权衡场景发生的概率和遗漏它的代价，决定是否应满足该场景的要求。便于系统升级时参考。例：可扩展性质量属性运用“属性-场景-决策”表方法，细化PMTool的可扩展性需求，制定架构决策，如下表所示：非功能需求对软件架构的影响比功能需求更大。“属性-场景-决策”表可以帮助软件架构师以一种更透明、更可操作的方式完成从质量属性需求到质量场景的细化，最终根据具体的场景有针对性地设计架构决策。架构的目标正确性correctness可靠性〔Reliable〕：软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。健壮性robustness平安性〔Secure〕：软件系统所承担的交易的商业价值极高，系统的平安性非常重要。可伸缩性〔Scalable〕：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。可定制化〔Customizable〕：同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。可扩展性〔Extensible〕：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可复用性reusability可维护性〔Maintainable〕：软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。兼容性compatibility可移植性portability易用性easeofuse高效性efficiencytimeliness,economyandfunctionality客户体验〔CustomerExperience〕：软件系统必须易于使用。

市场时机〔TimetoMarket〕：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。131软件可维护性软件的可维护性概述软件可维护策略软件可扩展性〔Extensibility〕设计策略软件灵活性〔Flexibility〕设计策略软件可插入性〔Pluggability〕设计策略132软件的可维护性概述软件可维护性的定义：软件能够被理解、校正、适应及增强功能的容易程度。软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，也是用户十分关心的几个问题。软件的可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。对于不同类型的维护,这七种特性的侧重点也是不相同。133可维护性和可复用性一般来说，一个易于维护的系统，就是复用率较高的系统；一个复用率较好的的系统，就是一个易于维护的系统。但是，实际上，可维护性和可复用性是两个独立的目标。软件维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以比较容易和平稳的方式参加到已有的系统中去，从而使这个系统能够不断的的焕发出活力。一个可维护性较好的系统，应当允许维护工作能够以容易、准确、平安和经济的形式进行。134导致可维护性较低的原因：1.过于僵硬：在系统中参加一个新的功能，不管大小都很难，不仅意味着建造一个独立的新的模块，而且因为这个新功能会涉及很多其他模块，最后成跨越几个模块的改动。2.过于脆弱：与软件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么关系的另外一个地方发生故障。3.复用率低：所谓复用，就是指一个软件的组成局部，可以在同一个工程的不同地方甚至另一个工程中重复使用。复用率低，指当一段代码，函数，模块的功能可以在新的模块或新的系统使用，但是已有代码依赖于其他很多东西，很难分开。1354.黏度过高：一个改动可以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架进行。第一种方法对系统的未来有利，第二种方法是权宜之计，可以解决短期的问题，但是会牺牲中长期的利益。如果一个系统中使用第二种方法比使用第一种方法容易，那么就是黏度过高。设计的目标：1.可扩张性2.灵活性3.

插入性136系统的可复用性：复用性的重要性：1.较高的生产效率2.较高的软件质量3.恰当使用复用可以改善系统的可维护性统的复用和面向对象的系统设计中复用的区别1.传统的复用：代码的剪贴复用；算法的复用；数据结构的复用。2.面向对象的设计的复用：在OO中数据的抽象化、继承、封装和多态是几个重要的语言特性，这些特性使得一个系统可以在更高的层次上提供可复用性。137数据的抽象化和继承关系使得概念和定义可以复用；多态性使得实现和应用可以复用；抽象化和封装可以保持和促进系统的可维护性。138可复用和可维护性的关系1.适当的使用复用，可以提高可维护性，即支持可维护性的复用，就是在保持甚至提高系统的可维护性的同时，实现系统的复用。2.适当提高系统的可复用性可以提高系统的可扩展性：系统的可扩展性由“开-闭”原那么、里氏代换原那么、依赖倒转原那么和组合/聚合复用原那么所保证。3.适当提高系统的可复用性，可以提高系统的灵活性。系统的灵活性由“开-闭”原那么、迪米特法那么、接口隔离原那么所保证的。4.适当提高系统的可复用性，可以提高系统的可插入性。系统的可插入性由“开-闭”原那么、里氏代换原那么、组合/聚合复用原那么和依赖倒转原那么所保证。139复用原那么：1.“开-闭”原那么:OCP2.里氏代换原那么:LSP3.依赖倒转原那么:DIP4.接口隔离原那么:ISP5.组合/聚合复用原那么:CARP6.迪米特法那么:LoD140软件可维护策略从下面五个方面来阐述如何提高软件的可维护性：1.建立明确的软件质量目标如果要程序满足可维护性七个特性的全部要求，那么要付出很大的代价，甚至是不现实的，但有些可维护性是相互促进的，因此要明确软件所追求的质量目标。2.使用先进的软件开发技术和工具利用先进的软件开发技术能大大提高软件质量和减少软件费用。面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法，用面向对象方法开发出来的软件系统，稳定性好，比较容易修改，比较容易理解，易于测试和调试，因此，可维护性好。1413.建立明确的质量保证质量保证是指为提高软件质量所做的各种检查工作。质量保证检查是非常有效的方法，不仅在软件开发的各阶段中得到了广泛应用，而且在软件维护中也是一个非常主要的工具。为了保证可维护性，以下四类检查是非常有用的：(1)在检查点进行检查。(2)验收检查。(3)周期性的维护检查。(4)对软件包的检查。4.选择可维护的语言程序设计语言的选择对维护影响很大。低级语言很难掌握，很难理解，因而很难维护。一般来说，高级语言比低级语言更容易理解，第四代语言更容易理解，容易编程，程序容易修改，改进了可维护性。1425.改进程序的文档程序文档是对程序功能、程序各组成局部之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。程序文档对提高程序的可阅读性有重要作用。为了维护程序，人们必须阅读和理解程序文档。143一些经验1。首先在软件设计的时候就应尽量考虑全面，防止在后期开发到一定阶段之后在进行需求和功能上的改动。软件设计完成之后需要所有的工程负责人，工程经理，主要程序员，主要的测试人员一起讨论，讨论通过之后才能进行开发。2。强调开发人员的代码标准。公司一定要形成自己的编程标准，所有的开发人员须遵守。

3。软件开发的时候必须遵守一定的流程标准。例如代码统一放在vss中进行管理，每次checkin之前必须完成codereview，须有两个同事一起检查等，尽量在前期发现问题。1444。重视测试。除了单元测试与集成测试，由非开发人员和非设计人员来进行的黑盒测试非常重要。测试组未确认质量过关的软件不可release。

5。重视文档。设计文档，需求文档，程序架构文档，测试文档，用户手册，白皮书，等都应完善。

6。在经历多个工程以后，要总结出一套对质量和可维护性的度量方法和标准，才能持续不断改进。145软件可扩展性设计策略应用框架(ApplicationFramework)软件设计师用这个词描述有助于软件应用开发的一组可重用的设计和代码。“结构”一词着实反映了任何框架的本质。在应用开发中，一个相当复杂的应用包含了如此之多的不断变化的细枝局部，而结构帮助我们将这些不断变化的细枝局部，组织成易于理解的少数几个局部。“应用框架”为开发者提供了结构和模板，开发者以此为基线〔Baseline)来构建他们的应用系统。用户界面1.模型-视图控制器(Model-ViewController,MVC)2.MacApp3.MFC业务领域1.SanFrancisco通用应用开发1.CommonPoint2.Java语言和运行时虚拟机的Java环境应用框架作用模块化(modularity)可重用性(reusability)可扩展性(extensibility)简单性(simplicity)可维护性(maintainability)应用框架解析----框架开发过程在明确了需要应用框架之后，首先要确定框架开发过程包括的四个主要阶段：分析、设计、实现和稳定。分析设计构造稳定范围目标文档测试培训架构识别通用点和扩展点实现应用框架解析----框架开发过程框架开发的通用技术：通用点(Commonspots)扩展点(Hotspots):占位符号/扩展点黑盒框架(Black-boxframework)白盒框架(White-boxframework)灰盒框架(Gray-boxframework)设计模式(Designpattern)其中，通用点、扩展点、设计模式是用于开发框架的技术，黑盒、白盒、灰盒是开发框架的方法。151软件可复用性软件的可复用性概述软件复用是将已有的软件及其有效成分用于构造新的软件或系统。它不仅是对软件程序的复用，还包括对软件生产过程中其它劳动成果的复用，如工程方案书、可行性报告、需求分析、概要设计、详细设计、编码(源程序)、测试用例、文档与使用手册等等。因此，软件复用包括软件产品复用和软件过程复用两局部的内容。152从对复用产品的了解程度和复用方式看，也可分为白盒复用与黑盒复用。黑盒复用指对已有产品或构件不需作任何修改，直接进行复用，这是理想的复用方式。它主要基于二进制代码的复用，包括可执行程序的复用和基于库〔包括动态链接库和静态库〕的复用。白盒复用指根据用户需求对已有产品进行适应性修改后才可使用。白盒复用一般为源代码一级的复用，以及相应的测试用例、文档等的复用。无论白盒复用还是黑盒复用，都需要花费一定的代价熟悉和掌握被复用的软件系统。作为经济上的考虑，要求复用的代价必须大大小于重新开发的代价，否那么就不应该考虑。153软件复用的一个关键因素是抽象。软件的复用性很大程度上取决于对可复用对象的认识深度或者说可复用对象的抽象层次。抽象层次越高、与具体环境和特定细节越无关，那么它被未来系统复用的可能性也越大。领域分析那么是进行抽象的有力工具。软件复用根本原那么必须有可以复用的对象，所复用的对象必须是有用的；复用者需要知道如何去使用被复用的对象。154在复用软件设计中，根据面向对象原理，可考虑几个方面：1〕封装性2〕重载3〕继承4〕聚合5〕多态性中间件及相关软件是商业化的软件复用。仅看程序方面，软件复用后的制品也不只包括中间件软件，还包括软件框架、应用框架、通用业务构件等多种可复用形式。155常见问题：在编程相关的各种书籍中一直在强调代码的可重用性，之前所写的代码也一直遵循着这一规那么，但是最近越来越感觉这种规那么很麻烦，当费力心机的想使一段代码变得可重用，就不得不加上各种条件的判断，代码中充满了各种if...else...使代码变得很难看懂，有时自己都会被各种不同的属性与条件判断搞晕，这样的代码对于后期的维护来说肯定是十分困难的。所以我现在都是把不同的业务逻辑用不同的方法实现，即使有些逻辑是相似的，我也使用了不同的方法，虽然这样造成了许多重复代码，但是这样的代码看起来逻辑更清晰，也更利于后期的维护，包括转交给别人时也更容易让人看懂，尽管这样会造成代码量的增加。所以现在对代码的可重用性这个问题很困惑。156建议：在面向对象的语言里，如果ifelse大多，也许说明抽象不够。多态、功能边界定义不够、模块细化不够。抽象错误的情况下考虑代码级别的重用是比较伤神的。业务描述真正正确以后,维护方案也真正就浮现出来了。反之业务错了可维护性设计也会预测错误,设计无用接口。误区：面向对象使代码、逻辑更简单。157软件架构模式软件架构软件架构概论架构的目标架构的种类软件框架常见的架构模式软件架构概论系统架构是一个软件系统从整体到局部的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，那么是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件〔ArchitectureComponent〕、联结器〔Connector〕、任务流〔Task-flow〕。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器那么描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流那么描述系统如何使用这些元件和联结器完成某一项需求。建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过慎重的研究和考察。架构的种类根据我们关注的角度不同，可以将架构分成三种：逻辑架构物理架构系统架构逻辑架构软件系统中元件之间的关系，比方用户界面，数据库，外部系统接口，商业逻辑元件等等。物理架构软件元件是怎样放到硬件上的以下图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理效劳器、WEB效劳器、应用效劳器、报表效劳器、整合效劳器、存储效劳器、主机等等。系统架构系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作是架构设计工作中最困难的工作。架构的两要素元件划分和设计决定。逻辑元件：一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出奉献，是非常重要的信息。设计决定：进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。基于数据库的系统架构：一般有多少个数据表，就会有多少页的架构设计文档。比方一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。从概念性架构到实际架构就是多(Lessismore.)。--密斯·凡德罗概念性架构是对系统设计的最初设想。一般来说，实际的软件架构设计过程是，先进行概念性架构的设计，把最关键的设计要素和交互机制确定下来，然后再考虑具体技术的运用，设计出实际架构。架构设计中的关键要素及解决策略策略是制胜的关键。--张明正，《挡不住的趋势》最好的软件开发人员都知道一个秘密：美的东西比丑的东西创立起来更廉价，也更快捷。--RobertC.Martin,《软件之美》时间就是系统架构的生命。--PhilippeKruchten方法产生于恐惧。面对时间紧迫的压力，我们有理由质疑那种不顾时间花销、一味追求软件架构高质量的做法。软件架构是软件系统质量的核心，必须足够重视，但在不适当的时候“用时间换完美”会毁掉整个工程。架构设计并非“好的就是成功的”，而是“适合的才是成功的”。方法论

AlistairCockburn的七条定理，总结为：沟通和反响。RUP、XP重量之争软件架构设计中的关键要素及解决策略：

关键要素

策略

----------------------------------------------- -----------------------1.是否遗漏了至关重要的非功能需求？

全面认识需求。2.能否驯服数量巨大且频繁变化的需求？

关键需求决定架构。3.能否沉着地设计软件架构的不同方面？

多视图探寻架构。4.是否及早验证架构方案并作出了调整？

及早验证架构。软件架构设计过程总览一般的软件过程：需求分析的几个概念需求捕获vs需求分析vs系统分析需求捕获是获取知识的过程，知识从无到有。需求分析是挖掘和整理知识的过程，它在已掌握知识的根底上进行。系统分析？如果说需求分析致力于“做什么”，那么系统分析那么涉及“怎么做”。软件架构师不必是需求捕获专家，也不必是编写《软件需求规格说明书》的专家。但他一定应在需求分类、需求折衷和需求变更的研究方面是专家，否那么他和其他软件架构师相比，就输在了“起跑线”上。概念性架构设计概念性架构设计的迭代方式：1.鲁棒性分析；2.引入架构模式；3.质量属性分析。鲁棒性分析所谓鲁棒性分析是这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，形成以职责模型为主的初步设计。鲁棒性分析是从功能需求向设计方案过度的第一步，所获得的初步设计是一种理想化的职责模型，它的重点是识别组成软件系统的高级职责块、规划它们之间的关系。鲁棒性分析填补了分析和设计之间的鸿沟。鲁棒图包含三种元素：边界对象、控制对象和实体对象。引入架构模式较为经典的几种架构模式：分层、MVC、微内核、基于元模型的架构、管道-过滤器等。质量属性分析“属性-场景-决策”表方法：细化架构设计架构细化工作主要表达在基于五视图方法进行架构细化：

约束

↓

┌───────┐

领域模型->│基于五视图方法│

关键需求->│

│->架构方案

概念架构->│进行架构细化│

└───────┘

↑

经验逻辑架构设计中，“发现通用机制”是应被特别强调的。机制(Mechanism)是模式的实例。机制是特定上下文中重复出现的问题的特定解决方案。具有良好架构的系统具备概念完整性。它通过对系统架构建立一种清晰的认识来发现通用的抽象和机制。利用这种共性使最终产生的系统结构更为简单。实现并验证软件架构好的策略必须是一再求证、测试、发现瑕疵漏洞，另想途径或方法来弥补策略缺乏，有时甚至得全盘放弃，重新筹划。--张明正，《挡不住的趋势》架构原型对功能性需求的实现非常有限，那么“架构验证”要验证什么？答案是要验证架构对质量属性需求的支持程度，包括运行期质量属性和开发期质量属性。验证架构的两种方法：原型法。对于工程型开发，常采用“原型法”。即对一组架构设计决策在非功能需求方面的满足程度进行验证。该原型往往是演进型，而非抛弃型。框架法。对于产品型开发，采用“框架法”有更多优点。该方法将架构设计方案用框架的形式实现，并在此根底上进行评估验证。在框架实现后，在框架根底上实现局部应用的功能，即实现一个小的垂直原型，从而进行实际非功能测试和开发期质量属性评价。软件框架什么是框架框架与架构的区别常见的框架为什么要用框架因为软件系统开展到今天已经很复杂了，特别是效劳器端软件，设计到的知识，内容，问题太多。在某些方面使用成熟的框架，可以防止重复做已有的根底工作，而只需要集中精力完成系统的业务逻辑设计。框架一般是成熟，稳健的，可以处理系统很多细节问题，比方，事物理，平安性，数据流控制等问题。框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，使用框架的开发者可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台〔如J2EE〕和高层业务逻辑之间的中间层。185常见的JAVA框架EJBStrutsSpringHibernateIBatisJSFtapestryWAFTurbineCOCOONECHOJATOTCFExt…186.NET框架.NET框架是创立、部署和运行Web效劳及其他应用程序的一个环境。它包括三个主要局部：公共语言运行时、框架类和ASP.NET。.NET框架对Web站点的支持：ASP.NET在编写Windows软件〔使用ATL/COM、MFC、VB或标准Win32〕方面，与当前创立应用程序的方式相比.NET都具有的优势。C++框架标准库DinkumwareC++Library、RogueWaveStandardC++Library、SGISTL、STLportGUIMFC、QT、WxWindows、Fox、WTL、GTK、BCG、XtremeToolkit网络通信ACE、StreamModule、SimpleSocket综合P::Classes、ACDK-ArtefakturComponentDevelopmentKit、dlibC++library、ChilkatC++Libraries、C++PortableTypesLibrary(PTypes)、LFC其他库Loki、ATL、FC++:TheFunctionalC++Library、FACT!、Crypto++BoostRegex正那么表达式库SpiritLLparserframework，用C++代码直接表达EBNFGraph图组件和算法Lambda在调用的地方定义短小匿名的函数对象conceptcheck检查泛型编程中的conceptMpl用模板实现的元编程框架Thread可移植的C++多线程库、Python把C++类和函数映射到Python之中Pool内存池管理smart_ptr智能指针XMLXerces、XMLBooster、PullParser、Xalan、CMarkup、libxml++

科学计算Blitz++、POOMA、MTL、CGAL游戏开发Audio/Video3DC++Programming Library、KlayGE龚敏敏、OGRE线程

C++Threads、ZThreads序列化

s11n、SimpleXMLPersistenceLibrary字符串

C++StrLibrary、CommonTextTransformationLibrary、GRETA190不同层次的模式架构模式(ArchitecturalPattern)设计模式(DesignPattern)代码模式(CodingPattern)区别：在于三种不同的模式存在于它们各自的抽象层次和具体层次。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质。架构模式的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。代码模式是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。架构模式(ArchitecturalPattern)软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在开展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解。众多软件架构概念都是围绕“组成”和“决策”两个视角展开的。Booch、Rumbaugh和Jacobson的定义架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。IEEE610.12-1990软件工程标准：架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的根本组织结构，以及指导上述内容设计与演化的原理〔Principle〕。Garlan的定义架构包括组件〔Component〕、连接件〔Connector〕和约束〔Constrain〕三大要素。组件可以是一组代码〔例如程序模块〕，也可以是独立的程序〔例如数据库效劳器〕。连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系。“约束”一般为对象连接时的规那么，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的效劳，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。Shaw的定义：“软件系统的架构将系统描述为计算组件及组件之间的交互”。架构＝组件＋交互几种典型的架构模式系统软件分层(Layer)管道和过滤器(PipesandFilters)黑板(Blackboard)开发分布式软件经纪人(Broker)客户/效劳器〔Client/Server〕点对点〔PeertoPeer〕交互软件模型-视图-控制器〔Model-View-Controller〕显示-抽象-控制〔Presentation-Abstraction-COntrol〕其它面向对象风格(ADT)基于消息播送且面向图形用户界面的Chiron2风格基于事件的隐式调用风格(Event-based,ImplicitInvocation)…分层(Layer)从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中。

软件为什么要分层？

为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个局部。完成这一目标的一种好方法就是在层上工作，将一个应用程序的主要功能别离到不同的层或者级中。分层模型从本质上讲，层代表了一个应用程序主要的功能。一般地，我们将应用程序功能分为三个方面，对应3层架构模式。它们是数据层〔datalayer〕、商务层〔businesslayer〕和表示层〔presentationlayer〕。数据层：包含数据存储和与它交互的组件或效劳。这些组件和效劳在功能上和中间层相互独立〔尽管在物理上不必一定相互独立--它们可以在同一台效劳器上〕。中间层：包括一个或者多个组件效劳，它们应用商务规那么、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一局部，中间层负责处理来自数据存储或者发送给数据存储的数据。表示层：从中间层获得信息并显示给用户。该层同时也负责和用