高级系统架构师

111高级系统架构师•架构设计思想与原理•常见高层架构•主流架构•小粒度软件架构222高级系统架构师•架构设计思想与原理•常见高层架构•主流架构•小粒度软件架构333V型软件开发生命周期模型定义开发过程生成的产品，应当测试每一个交付结果。444UP统一过程架构设计过程分为二个阶段：高层设计阶段和详细设计阶段哲学需求开发体系架构设计用户界面设计数据库设计模块设计实现与测试555UP中的架构设计和原理—9个核心工作流,代表了所有角色和活动的逻辑分组情况666这是开发过程沿时间的动态组织结构。软件生命周期被分解为周期，每一个周期工作在产品新的一代上。UP将周期又划分为四个连续的阶段。初始阶段细化阶段构造阶段交付阶段每个阶段终结于良好定义的里程碑--某些关键决策必须做出的时间点，因此关键的目标必须被达到。阶段和迭代--时间轴777初始阶段初始阶段的目标是为系统建立商业案例和确定项目的边界。本阶段的主要目标如下：•明确软件系统的范围和边界条件，括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定•明确区分系统的关键用例（Use-case）和主要的功能场景•展现或者演示至少一种符合主要场景要求的候选软件体系结构•对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)•估计出潜在的风险(主要指各种不确定因素造成的潜在风险)•准备好项目的支持环境888细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。本阶段的主要目标如下：1.确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。2.针对项目的软件结构上的主要风险已经解决或处理完成。3.通过完成软件结构上的主要场景建立软件体系结构的基线。4.建立一个包含高质量组件的可演化的产品原型。5.说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。6.建立好产品的支持环境。999构建阶段在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。本阶段的主要目标如下：•通过优化资源和避免不必要的返工达到开发成本的最小化•根据实际需要达到适当的质量目标•据实际需要形成各个版本（Alpha,Beta,andothertestrelease）•对所有必须的功能完成分析、设计、开发和测试工作•采用循环渐进的方式开发出一个可以提交给最终用户的完整产品•确定软件站点用户都为产品的最终部署做好了相关准备•达成一定程度上的并行开发机制101010交付阶段交付阶段的目的是将软件产品交付给用户群体。本阶段的主要目标如下：•进行Beta测试以期达到最终用户的需要•进行Beta测试和旧系统的并轨•转换功能数据库•对最终用户和产品支持人员的培训•提交给市场和产品销售部门•和具体部署相关的工程活动•协调Bug修订/改进性能和可用性(Usability)等工作•基于完整的Vision和产品验收标准对最终部署做出评估•达到用户要求的满意度•达成各风险承担人对产品部署基线已经完成的共识•达成各风险承担人对产品部署符合Vision中标准的共识111111统一软件开发过程最佳实践和概念1.短时间分区式的迭代和适应性开发2.使用对象技术3.在早期迭代中解决高风险和高价值的问题4.不断的让用户参与评估、反馈5.在早期的迭代中建立内聚的核心架构6.不断的验证质量，提早、经常和实际的测试121212高级系统架构师•架构设计思想与原理•常见高层架构•主流架构•小粒度软件架构131313常见高层架构－客户服务结构C/S141414常见高层架构－多极体系结构151515常见高层架构－流处理体系结构气象台大型运算161616常见高层架构－代理体系结构Corba（CommonObjectRequestBrokerArchitecture,公共对象请求代理体系结构）MQ银行排队问题：排队系统与客户系统连接171717常见高层架构－聚合体系结构即时战略游戏控制权转移181818常见高层架构－联邦体系结构军方高层体系结构(HLA)是一个使得仿真再用和相互交互更为容易的通用目的结构体系191919常见高层架构－基于包图的表示202020常见高层架构－架构设计方法比较•1，没有一种方法能够适用于所有的应用领域，所以合理的架构设计，往往应该更应该看重方法和思想的融合，把合适的方法到合适的地方。•2，设计“优劣程度”的评定标准，大都建立在不可证明的假设的基础之上，所以“优劣程度”评定本身是没有意义的，这种讨论更多的是给出设计的方向，和改进架构的方向，过分强调某项指标往往会得到一个拙劣的设计。•3，“设计”首先是解决问题的活动，而解决问题的过程和办法是因人而异的，架构风格往往和架构师本人的风格有关。•4，方法是重要的，但只有在支撑环境中运用它们才能得到成功，因此不同的支撑环境，往往更适应某种方法，但是各种思想的融合，是得到优秀设计的基础。212121高级系统架构师•架构设计思想与原理•常见高层架构•主流架构•小粒度软件架构222222主流架构－struts232323主流架构－AJAX242424主流架构－AJAXXMLHttpRequest对象252525主流架构－ORM1.Hibernat：全自动，注意性能问题2.Ibatis：半自动262626主流架构－SOA•面向服务的架构(Service-OrientedArchitectureSOA)是一种形式化的分离服务的架构风格。•面向服务的架构关注的是哪些是服务向用户提供的功能，哪些是需要这些功能的系统，这种分离，使用一种服务合约（ServiceContract）的机制来完成的。•272727主流架构－SOASOA有以下特性：•服务具有明确的接口（合约）与策略。•服务通常代表业务功能或者领域。•服务拥有模块化的设计。•服务被松散的耦合在一起。•服务是可以被发现的。•服务的位置对客户是透明的。•服务是独立于传输层的。•服务是独立于平台的。服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。构建SOA架构时应该注意的问题•服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务。•通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。282828高级系统架构师•架构设计思想与原理•常见高层架构•主流架构•小粒度软件架构292929面向对象的设计模式与小粒度软件架构封装变化与面向接口编程303030面向对象的设计模式与小粒度软件架构使用适配器模式（Adapter）调适接口313131面向对象的设计模式与小粒度软件架构纵向处理：模板方法（TemplateMethod）323232面向对象的设计模式与小粒度软件架构横向处理：桥接模式（Bridge）333333面向对象的设计模式与小粒度软件架构代理模式：软件开发需要协同工作，希望开发进度能够得到保证，为此需要合理划分软件，每个成员完成自己的模块，为同伴留下相应的接口。343434面向对象的设计模式与小粒度软件架构观察者模式：定义对象一对多的依赖关系，当一个对象发生变化的时候，所有依赖它的对象都得到通知并且被自动更新。353535面向对象的设计模式与小粒度软件架构树状结构：组合模式363636高级系统架构师2•架构设计方法学–设计方案的选择–分工－经济学中的机会成本–沟通成本–文档–测试•架构设计实践–持久化存储–表结构设计–引入新技术的风险–Ejb的缺点–Spring简介–Eai简介373737架构设计方法学－面向过程的方法面向过程方法又称为结构化方法，起源于20世纪70年代，主要由面向过程分析、面向过程设计和面向过程编程三部分组成。•面向过程分析：帮助开发人员定义系统需要做什么（处理需求），系统需要什么样的输入和输出，面向过程分析的主要工具是数据流图（DFD）,这是一种显示面向过程分析中产生的输入、处理、存储和输出的图形模型。•面向过程设计：面向过程设计是为下列事务提供指导：程序集是什么，每个程序应该实现哪些功能能，如何把这些程序组成一张层次图。面向过程设计的主要工具是结构图，这是一种表达程序模块层次的图形模型。•面向过程编程：具有一个开始和结束的程序或者程序块，并且程序执行的每一步都由三部分组成：顺序、选择或者循环结构，实现这种思想的最典型的语言就是C。整个面向过程设计的根本目标是：把复杂的系统分解成简单模块的层次图。383838架构设计方法学－面向对象的方法面向对象的方法由面向对象分析（OOA）、面向对象设计（OOD）以及面向对象编程（OOP）三部分组成。•面向对象分析（OOA）：定义在系统中工作的所有类型的对象，并显示这些对象如何通过相互作用来完成任务，主要工具是统一建模语言（用例图、活动图、状态图）。•面向对象设计（OOD）：定义在系统中人机进行通讯所必需的所有类型的对象，并对每种类型的对象进行细化，以便可以用一种具体的语言来实现这些对象。(类图)•面向对象编程（OOP）：用某种具体语言（C++、Java、C#等）来实现各种对象的行为，包括对象间的消息传递。393939架构设计方法学－体系结构设计的基本方法•面向过程思想的本质是复杂功能按一定的层级逐级分解子功能模块，始终围绕实现处理功能的“过程”来构造系统。这种金字塔型的架构在需求不变更的情况下是很稳定的；然而用户需求大都会发生变化，因此，这种变化对于基于过程的设计来说是灾难性的。用这种方法设计出来的系统结构常常是不稳定的，用户需求变化往往造成系统结构的较大变化，从而需要花费很大的代价才能实现这种变化。优点：层次清晰、容易理解缺点：应变复杂需求的能力差•面向对象设计的思想是以现实世界对象所具有的特点（状态、行为）来思考设计的。同时这些对象具有这些特征：封装、继承、多态；优点：以现实世界的角度思考问题，对于复杂需求有很强的应变能力缺点：以面向对象的思维来设计系统，而现实世界的事物间的层次、关系是很复杂的，这样设计出来的系统架构不清晰，不易理解。404040架构设计方法学－体系结构设计的基本方法的应用•综合两种设计方法的优略：•在总的架构设计方面，我们应该采取面向过程的的设计方法，以保证整个系统架构的稳定性、程序架构的清晰性，•而在每个具体的分层，应该采用面向对象的设计方法，以保证能应对复杂的业务需求。•典型架构：J2EE架构414141架构设计方法学－经济学案例－分工1农场主牧场主牛肉24土豆3240农场主牧场主牛肉12土豆1620农场主牧场主牛肉3土豆3210424242架构设计方法学－经济学案例－分工2农场主牧场主牛肉13土豆1824•在这个案例中牧场主无论生产何种产品都比农场主有优势（经济学上称为比较优势）•机会成本：为获得某事物而必须放弃的东西牧场主生产1斤牛肉的机会成本是10斤土豆，而农场主生产1斤牛肉的机会成本是16斤土豆。牧场主生产牛肉的机会成本比农场主小的多，比较优势比较大通过贸易可以获得双赢的局面434343架构设计方法学－经济学案例－分工3•同样的相对于软件工程领域，机会成本这个概念也是非常有用的。•每个开发人员都有自己的比较优势，无论是从经济学的角度考量还是从软件的开发维护难度考量，我们都提倡分工。让每个人关注于自己相对擅长的领域，这样可以提供总的生产力。问题：对于软件工程领域，是不是分工越细越好呢？答：不是，单单从机会成本角度考量，似乎分工越细，总的生产力就越高。但是IT业还要有个重要的因素要考量：沟通成本对于一个项目如果分工太细，势必会大大增加我们的沟通成本。那分工的粒度如何确定呢？每个行业有每个行业的分工粒度的适用范围。以一般的B2B商业应用领域常用的软件架构J2EE为例：web层、业务逻辑层、持久化层。这样的分工并不是我们自己凭空想出来的，是商业应用开发多年发展得到的一个经验值。避免教条主义并不是每个软件开发公