1、2软件架构辨析 市场体系结构 软件架构34MS e-Gov Architecture Framework56MS Application Reference Architecture7市场体系结构的特点 面向客户而非面向软件开发者。对于商业产品的特色宣传非常有效，但对开发者远远不够。市场体系结构与开发流程脱节。8软件构架的特点 好的软件构架满足它们的需求，并富有弹性和基于构件。一个富有弹性的软件构架能够：改进可维护性和可扩展性 实现经济性显著的可重用度 将开发团队成员间的工作清楚地分割开 封装对硬件和系统的依赖9为什么需要软件构架 最终开发出的目标系统总是由多个组成部分所构成，这种结构如果没有
2、预先定义，很难保证系统的构建过程能自发创建出一个一致而满足需求的交付。当前的软件规模已大到需要采用团队开发的模式，多个开发人员的分工协作，必然依赖于一种对开发内容的合适划分，以减少相互干扰、缩短工期的关键路径，从而提高开发效率、加快项目进度软件构架无疑是其中最关键的一类划分，它将被用来计划、管理与执行系统开发的各项活动。模块/构件化10为什么需要软件构架 目标系统总是要面临各种变数，项目组期望系统在发生变更、部署到新环境中时，仍然保持既有的稳定、可靠和性能目标系统应具备一种健壮性。系统的构建要经历一个不断增添新功能、加入新行为的过程，项目组期望做得比较容易、开销较低，且在此过程中不存在重大的风
3、险目标系统应具备一种可扩展。这些质量属性归根结底要落实到软件构架之上。11增量式开发的前提 迭代生命周期模型开始逐渐替代传统的瀑布模型，然而要真正实现其增量式开发的目标，却需要满足若干关键的前提条件：向已有交付添加新功能非常容易(可扩展)；后续的增量不会破坏已有的交付，使得迭代退化为返工(健壮)。这些条件最终归结为在大批量的增量开发之前，要构建一个构架基线，它同时提供可扩展性与健壮性。设计良好的对象可以方便地添加新的行为，而封装性为其对变化提供免疫力，基于对象的构架在微观上便具有更强的可扩展性与健壮性。分层(分包、子系统)架构在大粒度上隔离关注面，同样从宏观上增强了可扩展性与健壮性。12健壮性
4、与可扩展性 要实现健壮性与可扩展性等质量特性，主要有两个途径尽可能降低系统的冗余程度，同时隔离不同的关注面(实质是高内聚、低耦合，例如：将稳定部分与可变部分隔离，将用户交互与业务、数据等功能域分离，将功能和非功能的实施代码分离)。隔离关注面，使得扩展或变更时，对系统的修改局部化，对其它部分造成的影响被限制在较小范围内，避免出现那种牵一发而动全身的情形；高内聚的结构也利于聚焦于各部分的设计适应性上。低冗余，使得即使要变更，变更所触及的部分也尽可能地少；系统被改动的地方越少当然就越健壮，同时开销也小、实施也更容易。13如何理解软件构架 软件系统进行分解的顶层结构，包括其组成元素，元素之间、元素与外
5、部的关系关注构架的静态方面，即系统大粒度(宏观)的总体结构(例如分层、子系统的划分等)系统中解决各类关键的重复问题的通用解决方案关注构架的动态方面，侧重于系统内部关键行为的共同特征(已经包含了微观细节，例如构架机制)系统设计中影响深远(构架敏感)的各项最重要决定：这些决定严重影响系统的实施，一旦作出并被贯彻，其变更的代价将及其高昂(例如构架的样式、复用策略、开发中将贯彻的设计原则等)14软件构架的意义 软件构架的静态方面，其着眼点在于保持目标系统的最终交付在结构上的一致性；为分工协作提供划分依据，并避免结构上的重叠和冗余。软件构架的动态方面，其着眼点在于保持目标系统在关键行为实现上的一致性，突
6、出系统的既有风格；同时通过为各类关键重复问题提供通用解决方案来提高复用度，避免实施代码的冗余。上述两个方面，共同提供了构造目标系统过程中的健壮性与可扩展性大量的功能实现将在这个构架基础上被不断添加，而同时系统整体上仍然保持既有的一致和完整。15架构的分层 业务应用层(Business Application)由应用开发者开发 应用框架层(Application Framework)特定领域框架层 跨领域框架层 基础框架层(Foundation Framework)操作系统层1617从经济的角度考虑架构软件架构的设计与开发用户培训18软件体系结构 软件体系结构至少有十几种思想流派。Zachman
7、框架 开放分布式处理 领域分析 Rational41视图模型 软件体系结构风格 供应商驱动的方案 Sun Enterprise JavaBeans MS.Net 体系19Zachman框架 来源于IBM 传统的体系结构，设计为非面向对象。2021开放分布式处理（ODP）构件可以最大程度的进行互操作和重用。对系统和处理方式加以标准化，只是增强软件可操作性和重用性的一种权宜之计，并不能彻底解决问题。分布式处理：借助计算机网络将分布在不同地点的构件(对象)组织在一起，进行信息处理。分布式处理中的构件可能由不同的厂商开发、生产，因而构件之间可能存在不一致的接口；另外，构件之间的通信也可能使用不同的协议
8、。这种兼容异质成分的分布式处理，称为开放分布式处理。22RMODP的元模型体系 ISO/ITUT RMODP定义的抽象层次(视角)：企业视点(Enterprise Viewpoint)purpose，scope and policies 信息视点(Information Viewpoint)semantics of information and information processing 计算视点(Computational Viewpoint)functional decomaosition 工程视点(Engineering Viewpoint)infrastructure requir
9、ed to support distribution 技技术视点(Technology Viewpoint)choices of technology for implementation23领域分析 是一种支持软件复用的系统的管理过程。将项目专有需求转化为一般的领域需求。通用功能被用来做水平框架和可复用软件体系结构的基础。2441视图模型 逻辑 实现 进程 部署 用例 与UML紧密相连25软件体系结构风格 MVC风格 管道过滤器风格 客户服务器风格 层次系统 仓储（数据库和黑板）风格 面向对象风格 基于消息广播且面向图形用户界面的Chiron2风格 基于事件的隐式调用风格基本理念 IT行业的
10、人才结构与软件架构师的定位 软件架构师应掌握的知识体系 软件架构设计的特点、层次、分类 软件架构的主要理论、方向和趋势 软件工厂，实现软件开发的产业化27软件架构师在干什么？软件架构师在干什么？思考、思考、再思考 深入理解、准确把握建设的业务需求 分析所有可见的问题、障碍、风险 充分参考已有的成功方案，降低风险 交流、讨论、博弈、质疑 对构思中的方案不断提出质疑，避免漏洞 广泛听取各层面的意见，开拓思路 反复质疑、逐步完善已有的设计构思 在动手实现之前验证设计方案的正确性28软件架构师的知识结构软件架构师的知识结构 软件知识 最好要有系统开发全过程经验。对 IT 建设生命周期各个环节有深入了解
11、，包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。深入掌握1-2种主流技术平台上开发系统的方法。了解多种应用系统的结构。了解架构设计领域的主要理论、流派、框架。29软件架构师的知识结构软件架构师的知识结构 业务知识 深入了解系统建设的业务需求。了解系统的非功能需求和运行维护需求。了解企业 IT 公共设施、网络环境、外部系统。30你知道那些知识？MFC，Msf，mof，rup，j2ee，spring，soa，junit，ORM，。net Mvc，uml，xml，corba，mda，mdd，webservice Rss，web2。0，ajax，serlet，hibe
12、rnate Ioc，aop，ruby on rails Rup Bpel Workflow engine LBS Oracle CMMI MQ31软件架构师的思维方式软件架构师的思维方式 基于框架的思维 架构设计的层次（Enterprise，Application，etc）IT 的生命周期（What，Why，Where，How，When，etc）成功经验以及方法论的指导 合理把握技术细节 把握各个层次应有的内容 合理忽略不应有的技术细节32软件架构师的思维方式软件架构师的思维方式 风险管理意识 采用成功经验、避免不应有的风险 多方位的开放思维 多维度、多方向、包容性、避免排他性 分析、质疑、抽
13、象、归纳 没有绝对好的架构设计，只有相对优秀的方案33软件架构设计过程举例软件架构设计过程举例 应用系统逻辑架构设计 目标：提供系统架构方案、满足业务需求、为物理设计提供依据。主要环节 根据系统主要的应用场景，确定系统概念架构。34软件架构设计过程举例软件架构设计过程举例 调研已有的成功参考架构和相关模式 提出系统逻辑架构，包括分层的整体逻辑架构、子系统/模块组成以及边界划分根据。讨论逻辑架构的依据、优缺点、以及已经考虑和参考的其它方案。设计相关子架构，包括：数据架构、子系统架构、安全架构、网络架构等。验证架构设计、确认能够满足业务需求和其他关键指标，如性能要求、费用限制等。35软件架构设计的
14、一些特点 处于软件系统建设的上游 需要全面考虑多方面的因素 对于同一个问题，可以有多种设计结果 是在各种制约条件下取得的较好折衷方案 科学+经验+艺术“系统架构”往往被滥用需求分析需求分析架构设计架构设计系统设计系统设计系统开发系统开发测试上线测试上线软件架构的层次层次特征说明Enterprise 关注 整个机构、企业所有 IT 系统的整体能力 从整体着眼、与业务紧密相关、与IT 规划相关最高层，人数极少Application 负责应用系统的架构，奠定系统建设的基础 关注系统内部的构成和子系统/模块的分划 需要负责与外部相关系统的互联互通系统架构最高层，大型系统需要有一个架构组System/S
15、ub-System 根据应用系统的逻辑架构制定相应的技术实现方式，设计系统的物理架构一个系统建设项目中常常有多个Component 负责系统模块的实现机制和详细结构设计 为系统开发建设奠定基础常常由系统工程是担任Data/Information 负责应用系统的信息和数据模型和结构 通常包括数据库模型和结构设计常常由数据库专家负责Security 负责系统的安全架构设计 涉及系统所有层面的安全措施需要由安全专家负责，极缺Network 系统内部、外部的网络拓扑设计常常由网络集成商负责Others 不同建设项目常常有一些特殊需求软件架构的分类软件架构的分类分类特征说明概念架构 关注 整个机构、企业
16、所有 IT 系统的整体能力 从整体着眼、与业务紧密相关、与IT 规划相关逻辑架构 系统子系统、模块分划 功能边界的确定 分布式计算系统设计的特点物理架构 针对代码开发 与采用的语言、技术平台紧密相关数据架构 数据库设计部署架构 针对系统硬件部署 与逻辑架构不同 分布式系统有许多特别的性能和安全考虑成为软件架构师的途径成为软件架构师的途径 软件架构 巨大的知识海洋 门槛相对较高、职业生涯非常长 相对独立于技术的新陈代谢 适合于喜欢学习的人 不断学习、增加积累、注重经验 注意学习方法论、框架 不断增加各种系统架构的知识 经验积累非常重要成为软件架构师的途径成为软件架构师的途径 在与高手和同行合作中
17、提高水平 与高手的合作是最佳途径 同行之间的交流也非常有效 在每一个项目中进行创新 40软件生命周期进程模型 RUP与XP Agile与CMM MSF41传统的瀑布式开发 能够较好地解决：软件项目复杂性和一致一方面的问题42瀑布式开发推迟了风险的规避 无法解决：软件项目可变性和不可视性方面的问题43将瀑布开发迭代地应用于系统增量 最早的迭代触及最重大的风险(例如需求或项目可行性风险)。每次迭代产出一个可执行(可以通过测试等较客观的途径加以验证)的交付，是系统的一个增量。每次迭代都包含集成与测试。44迭代式开发促进风险规避45迭代式开发的特点 严重的风险在(项目)大规模投入之前被解决 初期的迭代
18、能获取更早的用户反馈 测试与集成是连续的(增量式)客观(可验证)的里程碑提供了短期的焦点 进度的度量直接依靠对实施成果的评估(而非主观的估计)部分的实现可以被先行部署46迭代：风险驱动的开发模型 在RUP先启阶段的迭代中，项目组必须解决开发目标与范围、以及技术和商业可行性的根本风险值不值得做，能不能做。而到了精化阶段的迭代，项目组关注的焦点则转到构架风险上可否大量投入去做。进入项目中成本最高的构建阶段后，控制成本、进度和开发质量的风险将成为所有成员的责任准备好交付给用户了?最后到了迁移阶段，项目组将面临从客户和用户方面引入的各种风险(日程安排、需求变更等)客户是否满意。49 RUP、XP、Ag
19、ile 都强调迭代开发的方式 50RUP rational统一开发过程 rational公司提供的软件开发过程方法，RUP告诉你软件开发应该做那些事情，分为哪些阶段，每件事情应该做到什么程度。RUP基本是一种根据风险大小安排次序的迭代过程，强调在开发早期找到相对稳定的构架，以免后期因为修改构架而增加太多工作量，另外RUP使用use case捕获需求作为每一次迭代开发的开始。51 XP 极限编程 是一种指导你如何去开发的思想。XP的核心是尽可能把所有的事情简化。XP反对在开发过程中生成太多文档，不鼓励过多考虑未来的需求，鼓励尽可能早期进行尽可能全面的测试，鼓励周期尽可能小的迭代开发以便是系统尽可
20、能早的投入使用。另外还注重双人编程、CRC和重构技术。52 XP在很多方面都和我们传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布得软件开发的全过程。每个周期都进行充分的测试和集成。好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的风险。53 在软件设计
21、中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件得合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中的熵值。54 在开发团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。55 在进行软件架构设计之前就进
22、行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。56 在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长。57 角色轮换就是在项目 项目的集体负责 保证8小时工作制，避免加班。有
23、充分的培训、有每个人的提升空间 推行淘汰制 有效的招聘制度。强有力的后勤保障制度和轻松的企业文化 结对编程58 人员分工灵活，保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。每天或隔天，开一个站立会议（保证开会时间尽量短）XP的实施方法就要求能适应工作中出现的问题，不断对XP进行改进，而不能照搬套用。XP采用和建立一个通常框架相反得方法来适应需求，而是尽量简单。59XP 与CMM、RUP 的比较 CMM 告诉组织为了系统化地建立、实施和改进软件开发过程应该做些什么，但没有说明如何去做以及采用哪些具体的技术
24、、策略和方法。CMM 是一套通用的过程实践标准，适用面很广。实施CMM 要求组织在过程的制度化建设上付出大量努力，通常被认为是重载（heavy-weight）的模型。60 XP 是一个针对某种特定环境（需求变化快的小型团队）的具体过程实施模型和方法论。它其实是一种演进式的原型化方法（evolutionary prototyping），具有沟通高效、设计简单、反馈迅速等特点，因而是一种轻载（light-weight）、敏捷（agile）的过程方法。把XP 的实践方法与CMM 的KPA（关键过程域）进行对照。可以看出XP部分满足或大部分满足了CMM 2-3 级KPA 的要求，而基本上没有涉及CMM
25、 4-5 级的KPA。这说明XP 的做法基本符合了CMM 的目标和KPA，但还不完备。61 总体上看，XP 侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题。XP 缺少的一个重要内容是“制度化”，它不含有被CMM 认为是使良好的工程和管理实践制度化的关键基础设施和管理要件。62 RUP（Rational Unified Process）是一个风险驱动的基于UML 和构件式架构的迭代递增型开发过程（框架）。RUP 定义了4 个阶段（起始、细化、构造、移交）和9 个科目（业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境）。这些阶段对应着关键里程碑的划分，而
26、不同科目的工作流和活动在生命周期的迭代中可以并发进行，具体执行的程度则可以调节。63 RUP 对于角色、流程、工件和活动的要求是灵活的、可配置的，所以它广泛地适用于各种类型和规模的项目。RUP 集中体现了6 个软件开发的最佳实践方法：迭代式开发、需求管理、构件式架构、基于UML 的可视化建模、持续校验质量、变更管理。64 RUP 是一种以架构为中心的开发过程，而这正是大、中型项目成功的关键。XP 的编码和设计活动融为一体，弱化了架构的概念，这是它与强调架构设计的RUP 的最大不同。架构的内涵要远大于一些简单的隐喻，它要考虑结构、行为、环境、使用、功能、性能、可靠性、弹性、重用、可理解性、约束和
27、权衡乃至美学等诸多方面的因素。设计架构的目的不是为了完美地表示系统的全部细节，而是为了消除最主要和最关键的架构风险。65 RUP 细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。XP 没有包含业务建模、部署等概念，反映了它以编程为中心、节省一切的哲学。当然两者也有不少共同点。例如，它们的基础都是面向对象方法（取代传统的结构化方法），都重视代码、文档的最小化和设计的简化，采用动态适应变化的演进式迭代周期（取代传统的瀑布型生命周期）、需求和测试驱动并鼓励用户积极参与等。66 RUP 提供了非常丰富的内容，总体来说是一个重载的过程。通过定制RUP 这个通用的过程框架
28、，去掉项目不必要的工件和中间环节，把XP 的做法（比如短小的迭代周期、结对编程、测试优先的设计和重构）吸收进来，也可以实现RUP 过程的敏捷和轻量化。Robert Martin甚至从RUP中裁剪出了一个酷似XP 的最小化RUP 过程dxMART01。67总结 XP、RUP 乃至其他工程和管理方法可以统一起来使用，姑且成之为统一软件过程（Unified Software Process，USP）。例如，一个大项目团队在起始和细化阶段采用RUP 方法完成需求分析和架构设计，在构造和移交阶段采用XP 的做法来实现部分子系统或模块。“轻载”、“敏捷”是美丽的词汇，无人会拒之于门外。XP、RUP 的目标
29、是一致的提高团队效率、开发出高质量的软件，而区别就在于各自的侧重点不同，从而导致两者的适用情况和应用范围有差异。然而，它们是可以互补的，无论是以架构为中心，还是以代码为中心，灵活运用的关键就在于掌握其中的最佳实践方法，实施RUP、XP 或者融合了两者的过程（比如USP）都将有助于组织更好地实现CMM 目标。69MSF MSF是一套大型系统开发指南，它描述了如何用组队模型、过程模型和应用模型来开发Client/Server结构的应用程序，是在微软的工具和技术的基础上建立并开发分布式企业系统应用的参考。70 MSF将一个项目中不同阶段的工作人员分为六个角色，体现了项目开发的六个重要质量指标，它们在
30、全球是一致的。产品经理：了解用户特征，尤其是商业特征，明确用户的需求以及需求的期望值。之所以强调用户需求的期望值，是因为用户的商业化特征比较强，需求无尽，无法界定到底如何才算需求得到了满足。而确定了需求期望值后，用户的商业目的就非常明确，实施起来也比较顺畅。程序管理员：负责制定计划，每天找出完成该计划的风险所在，排除风险，每天交付应该完成的内容，确保计划按质、按量实施。71 用户教育：设计友好的用户界面，对用户进行培训，确保用户能够并且愿意和喜欢使用开发出的产品。开发：开发者在开发前期就参与用户需求分析和项目计划制定，他最清楚具体的开发过程。在开发期开始后，他负责进行代码开发，在每一个阶段，交
31、付每一项内容的代码。测试：负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每一个错误(bug)，而是要找到代码错误之间的关系，解决最根本的错误，掌握错误的状态，从而迅速排除错误。72 后勤：后勤人员负责将实验室的产品商品化，变成实际可以运行的产品，达到最初制定的商业目的，取得商业效益。这项工作在以往的项目中可能比较简单，因为实验室的环境可能和实际环境几乎一致或差别不大。而现在却不同了，实验室环境可能十分简单，而实际环境可能非常复杂，比如分布式环境、Internet/Intranet环境等，尤其是大企业，实际环境比实验室环境复杂得多，因而将实验室产品运用到实际环境中是一项非常重要的工作。这项工作没有完成好，往往使整个项目前功尽弃，功亏一篑。
