《高级系统架构设计ppt课件.ppt》由会员分享，可在线阅读，更多相关《高级系统架构设计ppt课件.ppt（268页珍藏版）》请在三一办公上搜索。
1、1,高级系统架构设计,康凯,高级系统架构设计,内部教程注意保密,第一单元：软件架构视图,软件系统开始坏死的症状,一个软件系统开始坏死时表现的症状有:硬化Rigidity系统变得越来越难以变更,修复或增添新功能的代价高昂;脆弱Fragility对系统的任何哪怕是微小的变更都可能造成四处(甚至是与变更处没有逻辑上的关联之处)崩溃;绑死Immobility抽取系统的任何部分用来复用都非常困难;胶着Viscosity以与原有设计保持一致的方式来对实施变更已经非常困难,诱使开发人员绕过它选择容易但有害的途径,其结果却使系统死的更快。,4,好的设计表现,如果设计能实现如下目标，那么就是好的设计了。（Ste
2、ve McConne）一:最少的复杂度 简单说就是要易于理解。二:易于维护 为做维护工作的程序员、也为自己着想。（代码大多数时候做维护的还是自己 ）（函数名或代码能“望文知意”吗？）三：松耦合 作为软件设计的军规之一。各部分的关联少意味着测试、集成、维护的时候可以更轻松。,5,四：可扩展 唯一不变的就是变化。如果作品不能适应变化的话，基本上就可以贴上不合格的标签了。记住开闭原则。总之：在给自己软件加功能的时候不要对底层甚至架构大动干戈就对了。五：高扇入六:低扇出 超过约七个就算高扇出了.七：可移植 单纯；MVC；模块化；抽象八：高内聚,6,九：精简性 能少不多，不能觉得模式好，就有事没事都加上
3、。程序员不能觉某个功能可能有用你就加上.因为这会增加测试等方面的任务,而且程序员认为用户会喜欢的用户未必会满意十：层次性 层次性，三/四层架构。好处：换了数据库而不必管上层。更好的分工。经验不足的人写的初级代码可以禁闭起来。以后可重构、换掉, 也就减少了复杂度。 十一：使用标准技术 熟悉度高。如使用相同的框架,代码风格应该使用相同的标准，多借用现有模式，不要自己发明通用框架，熟悉的东西容易理解。,什么是软件架构软件架构的概念很混乱。如果你问五个不同的人，可能会得到五种不同的答案。 软件架构概念主要分为两大流派：组成派：软件架构 = 组件 + 交互。决策派：软件架构 = 重要决策集。 组成派和决
4、策派的概念相辅相成。,软件架构要层次化并隔离关注点软件单元的粒度架构(Architecture)与框架(Framework)软件架构设计为什么这么难？跨越现实世界与计算机世界之间鸿沟软件架构设计要完成从面向业务到面向技术的转换。 需求 - 架构设计 - 软件架构 - 系统开发 - 软件系统,软件架构对新产品开发的作用：上承业务目标。下接技术决策。控制复杂性。先进行架构设计，后进行详细设计和编码实现，符合“基于问题深度分而治之”的理念。组织开发。软件架构方案在小组中间扮演了“桥梁”和“合作契约”的作用。利于迭代开发和增量交付。以架构为中心进行开发，为增量交付提供了良好的基础。在架构经过验证之后，
5、可以专注于功能的增量提交。提高质量。,软件产品线：指具有一组可管理的、公共特性的、软件密集性系统的集合，这些系统满足特定的市场需求或任务需求，并且按照预定义方式从一个公共的核心资产集开发得到。 软件产品线架构：针对一个公司或组织内的一系列产品而设计的通用架构。 软件架构对软件产品线开发的作用：固化核心知识；提供可重用资产；缩短推出产品的周期；降低开发和维护成本；提高产品质量；支持批量定制；,架构师应当为项目相关的不同角色而设计：架构师要为客户负责，满足他们的业务目标和约束条件。架构师要为用户负责，满足他们关心的功能需求和运行期质量属性。架构师必须顾及处于协作分工“下游”的开发人员。架构师必须考
6、虑“周边”的管理人员，为他们进行分工管理、协调控制和评估监控等工作提供清晰的基础。,架构设计的多重视图从根本上来说是因为需求种类的复杂性所致。比如一个媒体发布系统：功能需求：用户可以通过浏览器浏览媒体的发布。据此初步设计出采用浏览器插件的方案；约束条件：不能影响用户浏览器的安全性；细化设计方案，需要对插件进行认证，自动判别客户端是否存在，及版本比较；自动下载注册等。使用期质量属性：为保证浏览的流畅，应减少中间等待的时间，因此应对下一步需使用的媒体做预测等。制作发布期的质量保证：保证在遇到较大的媒体时能保持浏览的流畅，应在发布时将视频等流式化。,逻辑架构逻辑架构关注功能。开发架构开发架构关注程序
7、包。其设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。运行架构运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。物理架构物理架构关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。数据架构数据架构关注持久化数据的存储方案。设计着重考虑“数据需求”。,关系,逻辑视图。逻辑视图不仅关注用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。开发
8、视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。运行视图。和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行视图比较关注的正是这些运行时单元的交互问题。物理视图。和运行视图的关系：运行视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。,软件生命周期与软件架构介绍,20
9、,软件架构师的定位,系统架构师的职责：一、理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架）二、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。系统架构师的目的：对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。系统架构师能力要求：一、系统架构相关的知识和经验。二、很强的自学能力、分析能力、解决问题的能力。三、写作、沟通表达、培训。,21,职责领导与协调整个项目中的技术活动（分析、设计和实施等）推动主要的技术决策，并最终表达为软件构架确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”确定
10、设计元素的分组以及这些主要分组之间的接口为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现,22,专业技能技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力。具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等。具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策。拥有优秀的沟通能力
11、，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任。,23,以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。,24,软件架构师的知识体系,软件架构师作为整个软件系统结构的总设计师，其知识体系、技能和经验决定了软件系统的可靠性、安全性、可维护性、可扩展性和可移植性等方面的性能。因此一个优秀的软件架构师必须具备相当丰富的知识、技能和经验。通过对比软件架构师和系统分析师在软件开发中的职责和角色
12、，不难发现软件架构师与系统分析师所必需的知识体系也是不尽相同的，系统分析师的主要职责是在需求分析、开发管理、运行维护等方面，而软件架构师的重点工作是在架构与设计这两个关键环节上。因此在系统分析师必须具备的知识体系中对系统的构架与设计等方面知识体系的要求就相对低些；而软件架构师在需求分析、项目管理、运行维护等方面知识的要求也就相对低些。,25,MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRu
13、by On RailsRupBPELWorkflow EngineLBSOracleCMMIMQ,26,软件架构师在干什么？,思考、思考、再思考深入理解、准确把握建设的业务需求分析所有可见的问题、障碍、风险充分参考已有的成功方案，降低风险交流、讨论、博弈、质疑对构思中的方案不断提出质疑，避免漏洞广泛听取各层面的意见，开拓思路反复质疑、逐步完善已有的设计构思在动手实现之前验证设计方案的正确性,27,软件架构师的知识结构,软件知识最好要有系统开发全过程经验。对 IT 建设生命周期各个环节有深入了解，包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。深入掌握1-2种主流
14、技术平台上开发系统的方法。了解多种应用系统的结构。了解架构设计领域的主要理论、流派、框架。,28,软件架构师的知识结构,业务知识深入了解系统建设的业务需求。了解系统的非功能需求和运行维护需求。了解企业 IT 公共设施、网络环境、外部系统。,29,软件架构师的思维方式,基于框架的思维架构设计的层次（Enterprise， Application， etc）IT 的生命周期（What， Why， Where， How， When， etc）成功经验以及方法论的指导合理把握技术细节把握各个层次应有的内容合理忽略不应有的技术细节,30,软件架构师的思维方式,风险管理意识采用成功经验、避免不应有的风险多
15、方位的开放思维多维度、多方向、包容性、避免排他性分析、质疑、抽象、归纳没有绝对好的架构设计，只有相对优秀的方案,注意：并不存在通用的设计方法。我们认为，给定的某种固定的方法总是会顾此失彼，而且这种不平衡性不太容易觉察。如果给定的某种方法所注重的方面与系统需求不吻合，则这种方法就会将设计引入歧途。所以我们给出的是一些技巧，任何一次设计过程，都需要设计师仔细分析系统的需求和相关的约束条件，灵活运用众多的设计技巧，针对不同的设计方案进行取舍，做出合理的决策。,31,32,软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。分而治之的两种方式,33,第二单元：架构设计的GRASP原则,34,
16、35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,第三单元：架构设计过程,重型和轻型方法重型方法：偏重于计划、过程和中间产物敏捷方法：更加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产物，只是保证沟通、实现目标的手段。并非计划、过程、中间产物不重要，但不能本末倒置。评判软件成功的标准：,如何开始架构设计工作考虑的平台、语言、开发环境、数据库等误区：架构设计就是写一些空话，套话。误区：对与客户具体情况密切相关的问题却未系统考虑。IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术？要针
17、对需求设计架构。每个客户都有自身特点，如何才能够设计出符合客户利益的架构？软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往很难做到，但是如果不解决问题，风险又居高不下。,58,内容一：商业架构设计,软件功能需求对架构的影响软件质量需求对架构的影响软件商业质量属性分析软件约束条件与架构的影响确定架构目标系统功能分解（系统、子系统、模块）和部署模式,架构设计就是铺设软件的主管道。根据什么来制定主管道的粗细、路径等因素？是根据城市的人口、地理位置、水源等因素。对应到软件设计，城市的各因素就是软件中的各种需求：功能需求、非功能需求、变化案例等。例：城市中自来水管的架设是一项非常的复杂的
18、工程。为了需要满足每家每户的需要，自来水管组成了一个庞大的网络。在这样一个复杂的网络中，如何完成铺设的任务呢。一般的做法是，先找出问题的根源，也就是水的源头。从水源铺设一条管道通至城市，然后根据城市的区域划分，设计出主管道，剩下的就是使用的问题了，每家每户的管道最终都是连到主管道上的。因此，虽然自来水网络庞大复杂。但是真正的主管道是比较简单的。,一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化案例决定架构的范围。功能需求决定软件能够做些什么。我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了性能、效率上的一些约束、规则。而我们的技术架构要能
19、够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个架构的范围。例：一个字处理软件，功能需求可以简单概括为格式化用户输入的文字，非功能需求可能是格式化大小为1000K的一段文字的处理速度不能低于10S，变化案例可能是推出多种语言版本。则在设计业务架构时，我们会集中于如何表示文字、图象、媒体等要素，此外需要有另外的技术架构来处理速度问题，比如缓冲技术，对于变化案例，我们也要考虑相应的架构，比如把字体独立于程序包的设计。,架构设计的两项工作分析：分析是分析需求设计：设计软件的大致结构。很多方法论分离二者，其实无一定的界
20、限，做分析的时候会想到如何设计，而思考如何设计反过来又会影响分析的效果。可以说，两者间是相互联系和不断迭代的。,需求与架构都应迭代进行一点一点的作需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用的流程是一种迭代式的流程，这里我们将会面临着如何对待上一次迭代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间产物，那么这种维护的成本未免过大。因此，敏捷方法论的基本做法是，扔掉那些已经没有用处的中间产物。软件要比文档重要。生成中间产物的目的都是为了生成最终的程序，对于这些已经完成作用的模型，没有必要付出额外的维护成本。,架构设计中的一些提示（也是抛弃模型的必要条件）：简单化：简单
21、的模型和简单的程序。模型和程序越复杂，就需要更多的精力来处理它们。因此尽可能简化它们，为的是更容易的处理它们。高效沟通渠道：通过增强沟通的效果来减少对中间产物的需要。试想若随时能从客户处得到需求的细节资料，则前期需求调研就没有必要做得太细。角色交叉轮换：开发人员间建立起交换角色的机制，能够尽量的避免各子系统诸侯割据的局面。清晰的流程：或明确的过程。过程在方法论中是重点，敏捷方法论也不例外。开发人员能够清楚的知道，今天做什么，明天做什么。过程不是给别人看的，而是给自己用的。,工具：好用的工具能够节省大量的时间，工具并不仅指CASE工具，还包括版本控制工具、自动测试工具、画图工具、文档制作和管理工
22、具。使用工具要注意成本和效益的问题。标准和风格：语言标准不同是沟通的很大障碍。语言从某个角度来看属于一种标准、一种风格。因此，一个团队如果采用同样的编码标准、文档标准、注释风格、制图风格，那么这个团队的沟通效率一定非常高。如果上述的环境都不具备，或是欠缺好几项，那你的文档的模型还是留着的好。,仅针对需求设计架构不要做未来才有用的事情。有时我们会把架构考虑得非常复杂，主要原因是把很多未来的因素放入到现在来考虑。或在开发第一个产品的时候就试图做成完美的框架。以上的这两种思路有没有错呢？没有错，这只是如何看待投入的问题，有人希望开始的时候多投入一些，这样后续的投入就会节省下来。但在现实中，由于需求的
23、不确定性，希望通过增加开始阶段的投入来将降低未来的投入往往是难以做到的，框架的设计也绝非一蹴而就的，因此这种做法并不好。同其它很多事物一样，架构设计应保持简单性和迭代过程！,66,内容二：逻辑架构设计,软件架构立方体图软件架构模式和架构师经验的引入使用质量场景属性进行迭代架构设计综合初步设计，确定高层分割(分层 分服务 分区 通信),引入模式模式帮助我们抓住重点。为了解决设计文档编辑器引出的七个问题，一共使用了8种不同的模式。这8种模式的组合其实就是架构，因为它们解决的，都是系统中最高层的问题。架构也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式；对于交
24、互系统，我们使用MVC（模型-视图-控制器）模式。模式本来就是针对特定问题的解，因此，针对需求的特点，我们也可以采用相应的模式来设计架构。,PetShot案例在MVC图背后隐藏着的需求：系统需要支持多种用户界面，包括为普通用户提供的HTML界面，为无线用户提供的WML界面，为管理员提供的Swing界面，以及为B2B业务设计的WebService界面。这是系统最重要的需求，因此，系统的设计者就需要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好处，可以在添加功能的同时
25、，不涉及界面的改动，反之亦然。（耦合度的问题）。MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它呢？,抓住重点架构是一种抽象，即架构设计摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优先级最高、风险最大的那部分需求。考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶段投入过多的时间，因此关键点在于我们要能够在架构设计中把握住需求的重点。比如，分布式系统和交互系统，分布和交互就是这两个系统的
26、重点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而宠物商店的范例也是类似的，除了MVC的架构，还有很多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图管理的前端控制器等。但是这些相对于MVC模式来说，属于局部的，优先级较低的部分，可以在架构确定后再来设计。,72,内容三：物理架构设计,数据模型视图结合逻辑架构，设计物理部署,73,内容三：架构重构,软件架构重构还是重写软件架构重构技巧软件架构复用架构重构的4种方案及模式,74,单元四：业务逻辑层架构设计,75,领域模型设计,领域模型（Domain Model）商业
27、建模范畴的概念： 同行业企业的业务模型必定有很大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，即领域模型。技术建模范畴的概念：用编程语言来实现商业领域模型。,76,层次结构,表现层业务层业务层外观业务服务层领域对象仓库层领域对象层持久层数据访问层数据库,77,领域模型中的各种角色：实体-有唯一的标识,并且要有属性和行为(非GET/SET)，添加了行为，使其具有生命力。往往在设计时，实体的形为最难决断。为确定行为，我们必须识别它们的责任和协作。类的责任是指该类要做、知道、或决定的一切，由一个或多个方法完成。类中有属性和关联，协作就是为完成自己的责任所调用
28、其它关联类。值对象-没有标识没有行为。如Address类。工厂-定义创建实体的方法，封装实例化对象并将一些关联对象注入。仓库(repository)管理实体的集合,主要有查找和删除实体的方法.实现类可以调用执久化层(如Hibernate，Ibatis)服务(Service) ，实现整个应用程序的工作流(workflow)。服务包含那些无法指派的单个实体的行为，由作用于多个对象方法组成。如可以调用repository查找到实体对象，然后委派给这些对象。服务和facade很像，但不一样，它不处理以下事情：1）执行事务。2）收集返回给表现层的数据。3）脱钩对象。4）其它事情。服务可以说是业务的协调者
29、，业务逻辑可以分散到实体对象中。,78,79,领域模型,失血模型贫血模型充血模型胀血模型,80,失血模型,DO只有属性及其getter/setter方法，没有任何业务逻辑。缺点：行为与数据分离，很多情况导致维护与理解困难。,81,贫血模型,DO包含不依赖于持久化的领域逻辑；依赖持久化的领域逻辑归入Service层。Service(业务逻辑，事务封装) DAODO优点：各层单向依赖，结构清楚，易于实现和维护。设计简单易行，底层模型非常稳定。缺点：DO部分的持久化逻辑被放入Service层，不够OO。Service层过重。,82,充血模型,与贫血模型类似，不同处在于如何划分业务逻辑：绝大多业务逻辑
30、都应该放在DO里(包括持久化逻辑)，而Service层很薄，仅仅封装事务和少量逻辑，不和DAO层打交道。Service(事务封装)DO DAO优点：符合OOService层很薄，只充当Facade的角色，不和DAO打交道。,83,缺点：DAO和DO双向依赖。如何划分Service层逻辑和Domain层逻辑没有确定的规则，取决与设计人员自己的理解。Service层封装事务，须对所有的DO逻辑提供相应的事务封装方法，造成重定义所有的Domain logic。Service的事务化封装的意义等于把OO的Domain logic转换为过程的Service 事务脚本。充血模型在domain层实现的OO在
31、Service层又变成了面向过程。,84,胀血模型,取消Service层，只剩下DO和DAO层，在DO的domain logic上面封装事务。DO(事务封装，业务逻辑)DAO(RoR甚至合并为一层） 优点：分层简化符合OO缺点：service逻辑也强行放入DO ，引起了DO不稳定。DO暴露给web层过多的信息，可能引起不必要的耦合。,85,原则：业务对象封装了内在的业务逻辑，而应用服务封装了外在于业务对象的业务逻辑。,86,EJB到轻量级框架,EJBPOJO （业务逻辑） + 轻量级框架（Hibernate、JDO、iBATIS（持久化）、Spring（事务管理、安全）,87,EJB,EJB：
32、编写分布式业务应用程序的Java标准架构。提供大量服务：声明型事务, EIB容器自动启动、提交和回滚事务。业务逻辑能参与由远程客户发起的分布式事务。提供声明型安全，大部分情况下不再摇要编写安全代码求（bean部署描述符里的条目指定准可以防问某个具体bean）。,88,例：在两个账号间进行转账的服务。,89,90,91,消除DTO,92,93,第五单元：质量属性驱动架构设计策略,软件质量及质量模型软件质量是一个复杂的概念，不同的人从不同的角度来看软件质量问题，会有不同的理解。从用户的角度看，质量就是满足客户的需求；从开发者的角度看，质量就是与需求说明保持一致；从产品的角度看，质量就是产品的内在特
33、点；从价值的角度看，质量就是客户是否愿意购买。,为什么那么多软件产品需要重新设计？ 难以维护？ 运行速度太慢？ 稳定性差？ 无法进行功能扩展？ 易遭受安全攻击？ 忽视包括质量属性需求在内的非功能需求是致命的。,质量属性分为： 运行期质量属性 开发期质量属性 各类需求架构设计的不同影响 高可移植性对硬件和平台相关特性进行封装、 隔离 高性能精心规划职责模型在质量属性方面需求折衷,”属性-场景-决策”表法 运用“关键需求决定架构”的策略，使质量属性分析的“输入”集中到关键质量属性需求。 “属性-场景-决策”表方法提倡通过一组具体场景将要达到的质量属性需求目标细化，再根据场景制定架构决策。,例：可扩
34、展性质量属性,运用“属性-场景-决策”表方法，细化PM Tool的可扩展性需求，制定架构决策，如下表所示：,架构的目标,正确性correctness可靠性（Reliable）：软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。健壮性robustness安全性（Secure） ：软件系统所承担的交易的商业价值极高，系统的安全性非常重要。可伸缩性（Scalable） ：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。,可定制化（Customizable） ：同样的一套软件，可以根据客户群的不同和市场需求的变化进
35、行调整。可扩展性（Extensible）：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可复用性reusability可维护性（Maintainable）：软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。,兼容性compatibility可移植性portability易用性ease of use高效性efficiencytimeliness,economy and functionality,客户体验（Customer Experience）：软件系统必须易于使用。市场时
36、机（Time to Market）：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。,106,1.多态(polymorphism)和针对接口的编程3.数据驱动(Data-Driven Design)4.元数据驱动设计5.反射驱动(Meta-data or Reflective )6.解释器驱动7.脚本引擎技术9. 缓存技术8. 后台批处理机制设计,107,多态(polymorphism)和针对接口的编程基类提供的契约允许针对基类接口编写的“多态”代码对特定的期权起作用，同时有助于对派生类的存在保持“健康的不知情”。各种各样“具体的”Option类型可以被添
37、加或删除而不会影响到只关心基类Option的通用代码。比如说，如果在某一个地方出现一个AsianOption对象，那么只知道Option的多态代码也能够操作它。出于同样的原因，像AmOption和EurOption这样具体的期权类型只需要知道基类就可以了（它们实现了基类的契约），改变通用代码对它们毫无影响。,108,数据驱动的使用表驱动法状态机,109,元数据驱动设计开发元数据本身并不是元数据驱动应用程序的本意。使用元数据来驱动服务在系统边界的传播是一个更为正确的方法。元数据可以应用于基础结构和应用程序服务分界的描述，以及整合的服务执行的配置数据。使用元数据，在商业（应用程序）和技术（基础结构
38、）领域，在商业分析和软件基础结构之间就元数据模型达成一致。这就达成了应用程序和基础结构之间的行为协议。,110,元数据驱动运用元数据脚本+脚本解释器元数据驱动的用户界面基于元数据的服务编排动态数据表设计工作流引擎数据仓库ETL工具,111,反射驱动(Meta-data or Reflective )反射与IOC反射与AOP及动态代理反射在规则引擎中的作用,112,解释器驱动如果应用程序的逻辑非常复杂，例如，AutoCAD的各种绘图指令，而且用户可能以非常复杂的方式使用这个系统，一个较好的体系就是提供面向领域的一组指令（语言），系统解释这种语言，产生相应的行为，用户使用这种指令（语言）完成复杂的
39、操作。实例：大量的开发工具、二次开发工具体现了这一思想：实际上是给用户提供了一种面向领域的语言，然后核心解释执行这一语言的指令和指令序列。从而扩充产品的功能，方便用户按照自己的需要定制系统。优点：常好的扩展性，用户可以实现对软件系统的二次开发 缺点：软件开发复杂，特别是这种指令集的设计非常困难。,113,脚本引擎基本数据类型高级数据类型：枚举，数组，结构，类，指针，引用，函数指针函数子过程,114,后台批处理机制设计后台批处理的设计意义遇到成千上万的数据需要处理批量多文件加载数据预读长任务中的防错,软件可维护性,软件的可维护性概述软件可维护策略软件可扩展性（Extensibility）设计策略
40、软件灵活性（Flexibility）设计策略软件可插入性（Pluggability）设计策略,115,软件的可维护性概述,软件可维护性的定义：软件能够被理解、校正、适应及增强功能的容易程度。软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，也是用户十分关心的几个问题。软件的可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。对于不同类型的维护,这七种特性的侧重点也是不相同。,116,可
41、维护性和可复用性一般来说，一个易于维护的系统，就是复用率较高的系统；一个复用率较好的的系统，就是一个易于维护的系统。但是，实际上，可维护性和可复用性是两个独立的目标。软件维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以比较容易和平稳的方式加入到已有的系统中去，从而使这个系统能够不断的的焕发出活力。一个可维护性较好的系统，应当允许维护工作能够以容易、准确、安全和经济的形式进行。,117,导致可维护性较低的原因：1.过于僵硬：在系统中加入一个新的功能，不管大小都很难，不仅意味着建造一个独立的新的模块，而且因为这个新功能会波及很多其他模块，最后成跨越几个模块的改动。2.过于脆弱：与软
42、件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么关系的另外一个地方发生故障。3.复用率低：所谓复用，就是指一个软件的组成部分，可以在同一个项目的不同地方甚至另一个项目中重复使用。复用率低，指当一段代码，函数，模块的功能可以在新的模块或新的系统使用，但是已有代码依赖于其他很多东西，很难分开。,118,4.黏度过高：一个改动可以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架进行。第一种方法对系统的未来有利，第二种办法是权宜之计，可以解决短期的问题，但是会牺牲中长期的利益。如果一个系统中使用第二种方法比使用第一种方法容易，那么
43、就是黏度过高。设计的目标：1. 可扩张性2. 灵活性3.插入性,119,系统的可复用性：复用性的重要性：1. 较高的生产效率2. 较高的软件质量3. 恰当使用复用可以改善系统的可维护性统的复用和面向对象的系统设计中复用的区别1.传统的复用：代码的剪贴复用；算法的复用；数据结构的复用。2.面向对象的设计的复用：在OO中数据的抽象化、继承、封装和多态是几个重要的语言特性，这些特性使得一个系统可以在更高的层次上提供可复用性。,120,数据的抽象化和继承关系使得概念和定义可以复用；多态性使得实现和应用可以复用；抽象化和封装可以保持和促进系统的可维护性。,121,可复用和可维护性的关系1. 适当的使用复
44、用，可以提高可维护性，即支持可维护性的复用，就是在保持甚至提高系统的可维护性的同时，实现系统的复用。2. 适当提高系统的可复用性可以提高系统的可扩展性：系统的可扩展性由“开-闭”原则、里氏代换原则、依赖倒转原则和组合/聚合复用原则所保证。3. 适当提高系统的可复用性，可以提高系统的灵活性。系统的灵活性由“开-闭”原则、迪米特法则、接口隔离原则所保证的。4. 适当提高系统的可复用性，可以提高系统的可插入性。系统的可插入性由“开-闭”原则、里氏代换原则、组合/聚合复用原则和依赖倒转原则所保证。,122,复用原则：1. “开-闭”原则:OCP2. 里氏代换原则:LSP3. 依赖倒转原则:DIP4.
45、接口隔离原则:ISP5. 组合/聚合复用原则:CARP6. 迪米特法则:LoD,123,软件可维护策略,从下面五个方面来阐述如何提高软件的可维护性：1.建立明确的软件质量目标如果要程序满足可维护性七个特性的全部要求，那么要付出很大的代价，甚至是不现实的，但有些可维护性是相互促进的，因此要明确软件所追求的质量目标。2.使用先进的软件开发技术和工具利用先进的软件开发技术能大大提高软件质量和减少软件费用。面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法，用面向对象方法开发出来的软件系统，稳定性好，比较容易修改，比较容易理解，易于测试和调试，因此，可维护性好。,124,3.建立明确的质量保
46、证质量保证是指为提高软件质量所做的各种检查工作。质量保证检查是非常有效的方法，不仅在软件开发的各阶段中得到了广泛应用，而且在软件维护中也是一个非常主要的工具。为了保证可维护性，以下四类检查是非常有用的： (1)在检查点进行检查。 (2)验收检查。 (3)周期性的维护检查。 (4)对软件包的检查。4.选择可维护的语言程序设计语言的选择对维护影响很大。低级语言很难掌握，很难理解，因而很难维护。一般来说，高级语言比低级语言更容易理解，第四代语言更容易理解，容易编程，程序容易修改，改进了可维护性。,125,5.改进程序的文档程序文档是对程序功能、程序各组成部分之间的关系、程序设计策略、程序实现过程的历
47、史数据等的说明和补充。程序文档对提高程序的可阅读性有重要作用。为了维护程序，人们必须阅读和理解程序文档。,126,一些经验1。首先在软件设计的时候就应尽量考虑全面，避免在后期开发到一定阶段之后在进行需求和功能上的改动。软件设计完成之后需要所有的项目负责人，项目经理，主要程序员，主要的测试人员一起讨论，讨论通过之后才能进行开发。 2。强调开发人员的代码规范。公司一定要形成自己的编程规范，所有的开发人员须遵守。 3。软件开发的时候必须遵守一定的流程规范。例如代码统一放在vss中进行管理，每次check in 之前必须完成code review，须有两个同事一起检查等，尽量在前期发现问题。,127,
48、4。重视测试。除了单元测试与集成测试，由非开发人员和非设计人员来进行的黑盒测试非常重要。测试组未确认质量过关的软件不可release。 5。重视文档。设计文档，需求文档，程序架构文档，测试文档，用户手册，白皮书，等都应完善。 6 。在经历多个项目以后，要总结出一套对质量和可维护性的度量方法和标准，才能持续不断改进。,128,应用框架作用,模块化 (modularity)可重用性 (reusability)可扩展性 (extensibility)简单性 (simplicity)可维护性 (maintainability),软件的可复用性概述,软件复用是将已有的软件及其有效成分用于构造新的软件或系
49、统。它不仅是对软件程序的复用，还包括对软件生产过程中其它劳动成果的复用，如项目计划书、可行性报告、需求分析、概要设计、详细设计、编码(源程序)、测试用例、文档与使用手册等等。因此，软件复用包括软件产品复用和软件过程复用两部分的内容。,130,从对复用产品的了解程度和复用方式看，也可分为白盒复用与黑盒复用。黑盒复用指对已有产品或构件不需作任何修改，直接进行复用，这是理想的复用方式。它主要基于二进制代码的复用，包括可执行程序的复用和基于库（包括动态链接库和静态库）的复用。白盒复用指根据用户需求对已有产品进行适应性修改后才可使用。白盒复用一般为源代码一级的复用，以及相应的测试用例、文档等的复用。无论
50、白盒复用还是黑盒复用，都需要花费一定的代价熟悉和掌握被复用的软件系统。作为经济上的考虑，要求复用的代价必须大大小于重新开发的代价，否则就不应该考虑。,131,软件复用的一个关键因素是抽象。软件的复用性很大程度上取决于对可复用对象的认识深度或者说可复用对象的抽象层次。抽象层次越高、与具体环境和特定细节越无关，则它被未来系统复用的可能性也越大。领域分析则是进行抽象的有力工具。软件复用基本原则必须有可以复用的对象，所复用的对象必须是有用的；复用者需要知道如何去使用被复用的对象。,132,在复用软件设计中，根据面向对象原理，可考虑几个方面：1）封装性2）重载3）继承4）聚合5）多态性中间件及相关软件是
