软件系统架构设计

1软件系统架构设计林国东Mail:[e-mail]2目录•第一单元：软件生命周期与软件架构介绍2•第二单元：技术架构视图─面向对象程序设计原则与模式24•用GRASP模式指导设计27•领域模型47•面向对象设计的基本原则71•第三单元：用UML辅助系统分析与设计103•UML简介及常见疑难问题辨析104•借鉴RUP的UML建模与分析117•第四单元：设计模式与软件设计思想131•设计模式132•常用的软件架构风格及适用情况分析172•SOA及分层架构设计212•第五单元：架构设计实践2253第一单元：软件生命周期与软件架构介绍4•IT行业的人才结构与软件架构师的定位•软件架构师应掌握的知识体系•软件架构设计的特点、层次、分类•软件架构的主要理论、方向和趋势•软件工厂，实现软件开发的产业化5软件架构师的定位•系统架构师的职责：•一、理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架）•二、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。•系统架构师的目的：•对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。•系统架构师能力要求：•一、系统架构相关的知识和经验。•二、很强的自学能力、分析能力、解决问题的能力。•三、写作、沟通表达、培训。6•角色•软件架构师SoftwareArchitect•定义•主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色7•职责–领导与协调整个项目中的技术活动（分析、设计和实施等）–推动主要的技术决策，并最终表达为软件构架–确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”–确定设计元素的分组以及这些主要分组之间的接口–为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻–理解、评价并接收系统需求–评价和确认软件架构的实现8•专业技能•技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力。•具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。•对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等。•具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策。•拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任。9•以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）•精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式。•具备系统设计员的所有技能，但涉及面更广、抽象级别更高。10软件架构师的知识体系•软件架构师作为整个软件系统结构的总设计师，其知识体系、技能和经验决定了软件系统的可靠性、安全性、可维护性、可扩展性和可移植性等方面的性能。因此一个优秀的软件架构师必须具备相当丰富的知识、技能和经验。•通过对比软件架构师和系统分析师在软件开发中的职责和角色，不难发现软件架构师与系统分析师所必需的知识体系也是不尽相同的，系统分析师的主要职责是在需求分析、开发管理、运行维护等方面，而软件架构师的重点工作是在架构与设计这两个关键环节上。因此在系统分析师必须具备的知识体系中对系统的构架与设计等方面知识体系的要求就相对低些；而软件架构师在需求分析、项目管理、运行维护等方面知识的要求也就相对低些。11•成为一名合格的软件架构师必须具备的知识–信息系统综合知识体系–软件架构知识体系12？•MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.Net•MVC，UML，XML，Corba，MDA，MDD，Web-Service•RSS，Web2.0，AJAX，Serverlet，Hibernate•IOC，AOP•RubyOnRails•Rup•BPEL•WorkflowEngine•LBS•Oracle•CMMI•MQ•…13软件架构师在干什么？•思考、思考、再思考–深入理解、准确把握建设的业务需求–分析所有可见的问题、障碍、风险–充分参考已有的成功方案，降低风险•交流、讨论、博弈、质疑–对构思中的方案不断提出质疑，避免漏洞–广泛听取各层面的意见，开拓思路–反复质疑、逐步完善已有的设计构思•在动手实现之前验证设计方案的正确性14软件架构师的知识结构•软件知识–最好要有系统开发全过程经验。–对IT建设生命周期各个环节有深入了解，包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。–深入掌握1-2种主流技术平台上开发系统的方法。–了解多种应用系统的结构。–了解架构设计领域的主要理论、流派、框架。15软件架构师的知识结构•业务知识–深入了解系统建设的业务需求。–了解系统的非功能需求和运行维护需求。–了解企业IT公共设施、网络环境、外部系统。16软件架构师的思维方式•基于框架的思维–架构设计的层次（Enterprise，Application，etc）–IT的生命周期（What，Why，Where，How，When，etc）–成功经验以及方法论的指导•合理把握技术细节–把握各个层次应有的内容–合理忽略不应有的技术细节17软件架构师的思维方式•风险管理意识–采用成功经验、避免不应有的风险•多方位的开放思维–多维度、多方向、包容性、避免排他性–分析、质疑、抽象、归纳–没有绝对好的架构设计，只有相对优秀的方案18信息系统综合知识体系•(1)计算机系统综合知识：包括计算机组成与体系结构、嵌入式系统和操作系统等方面的知识。•(2)系统配置和方法：包括系统配置技术和系统性能等方面的知识。•(3)典型系统应用：包括网络应用、数据库应用和多媒体系统等方面的知识。•(4)系统开发：包括程序设计语言、软件开发方法、需求分析和设计方法、测试评审方法、开发管理、应用系统构建、系统审计、外部资源使用和基于中间件的开发等方面的知识。•(5)安全性和可靠性技术：包括数据安全与保密、防闯入和防病毒、容错技术、可靠性模型与分析技术、系统可靠性、安全规章和保护私有信息规则等方面的知识。19•(6)标准化：包括标准化的基础知识、标准化分级、编码标准、数据交换标准、软件工程标准、信息安全标准、基于构件的软件标准和标准化组织机构等方面的知识。•(7)信息化基础：包括政府信息化与电子政务、企业信息化与电子商务、信息化的有关的法律和规定等方面的知识。•(8)数学和英语：至少具有大学以上的数学和英语基础知识。20软件架构知识体系•(1)系统计划：包括项目的提出和可行性分析、系统方案的制定、评价和改进、新旧系统的分析与比较、现有软、硬件和数据资源的有效利用等。•(2)软件架构设计：包括软件架构的概念、软件架构与设计、架构风格、特定领域的架构风格、基于架构的软件开发方法、架构评估、软件产品线和系统演化等。•(3)设计模式：包括设计模式的概念、组成、分类和实现、模式和软件架构的关系等。•(4)系统设计：包括处理流程设计、人机界面设计、文件与存储设计、数据库设计、网络应用系统的设计、系统运行环境的集成与设计、中间件与应用服务器、性能设计与性能评估等。•(5)软件建模：包括定义问题与归结模型、结构化系统建模与数据流图、面向对象系统建模、数据库建模和逆向工程等。•21•(6)分布式系统设计：包括分布式通信协议的设计、基于对象与web的分布式设计、基于消息和协同的分布式设计和异构分布式系统的互操作性设计等。•(7)嵌入式系统设计：包括实施任务调度和多任务设计、中断处理和异常处理、嵌入式系统开发设计等。•(8)系统可靠性分析与设计：包括系统故障模型和可靠性模型、系统的可靠性分析与可靠度计算、提高系统可靠性的措施、系统的故障对策和系统的备份与恢复等。•(9)系统的安全性和保密性设计：包括系统的访问控制技术、数据的完整性、数据与文件的加密、通信的安全和系统的安全设计等。•(10)复杂架构设计：包括操作系统的架构、编译器的架构和大型基础库的架构等。22软件架构师的任职条件•根据软件架构师的职责和角色定位，以及知识体系，从实践的角度考虑，合格的软件架构师应该具有以下能力和经验：•(1)具有8年以上的软件项目开发实际工作经验，其中至少有3年以上的代码编写工作经验，4年以上的基于面向对象和构件开发方法的软件产品设计经验。•(2)具有5个以上大中型开发项目的总体规划、方案设计经验，有大中型应用系统开发和实施的成功案例。•(3)对相关的技术标准有深刻的认识，对软件工程标准和规范有良好的把握。•(4)对.Net或Java技术及整个解决方案有深刻的理解及熟练的应用，精通WebService，熟练掌握流行的架构。23•(5)对设计模式有深刻的理解，并能在此基础上设计出适合产品特性和质量属性的框架。•(6)具有面向对象的分析、设计和开发能力，精通UML和XML，能熟练使用RationalRose、PowerDesigner等工具进行设计。•(7)具有良好的团队意识和协作精神，有较强的沟通能力和书面表达能力。•(8)具有旺盛的精力和学习能力，能快速掌握新技术和新方法。24第二单元：技术架构视图─面向对象程序设计原则与模式252627用GRASP模式指导设计2829303132333435363738394041424344454647领域模型48•层次结构•领域模型•从EJB到轻量级框架49层次结构•表现层（present）•业务层•业务层外观•业务层核心•领域对象管理/服务/仓库层•领域对象层•持久层•数据访问层•数据库50•领域模型中的各种角色：–实体--有唯一的标识,并且要有属性和行为(非GET/SET)，添加了行为，使其具有生命力。往往在设计时，实体的形为最难决断。为确定行为，我们必须识别它们的责任和协作。类的责任是指该类要做、知道、或决定的一切，由一个或多个方法完成。类中有属性和关联，协作就是为完成自己的责任所调用其它关联类。–值对象--没有标识没有行为。如Address类。–工厂---定义创建实体的方法，封装实例化对象并将一些关联对象注入。–仓库(repository)管理实体的集合,主要有查找和删除实体的方法.实现类可以调用执久化层(如Hibernate，Ibatis)–服务(Service)，实现整个应用程序的工作流(workflow)。服务包含那些无法指派的单个实体的行为，由作用于多个对象方法组成。如可以调用repository查找到实体对象，然后委派给这些对象。服务和facade很像，但不一样，它不处理以下事情：1）执行事务。2）收集返回给表现层的数据。3）脱钩对象。4）其它事情。服务可以说是业务的协调者，业务逻辑可以分散到实体对象中。51领域模型•失血模型•贫血模型•充血模型•胀血模型52失血模型•DO只有属性及其getter/setter方法，没有任何业务逻辑。•缺点：行为与数据分离，很多情况导致维护与理解困难。53贫血模型•DO包含不依赖于持久化的领域逻辑；依赖持久化的领域逻辑归入Service层。•Service(业务逻辑，事务封装)•DAO•DO•优点：•各层单向依赖，结构清楚，易于实现和维护。•设计简单易行，底层模型非常稳定。•缺点：•DO部分的持久化逻辑被放入Service层，不够OO。•Service层过重。54充血模型•与贫血模型类似，不同处在于如何划分业务逻辑：绝大多业务逻辑都应该放在DO里(包括持久化逻辑)，而Service层很薄，仅仅封装事务和少量逻辑，不和DAO层打交道。•Service(事务封装)•DO•DAO•优点：•符合OO•Service层很薄，只充当Facade的角色，不和DAO打交道。55•缺点：•DAO和DO双向依赖。•如何划分Service层逻辑和Domain层逻辑没有确定的规则，取决与设计人员自己的理解。•Service层封装事务，须对所