高级软件架构师培训讲义


架构师与设计师 • 面向对象应用建模(Application Modeling) 的实践过程有3个目标: – 有步骤、分层次地演进系统构架。 – 将软件需求逐渐转变为软件的设计方案。 – 保障软件的设计方案能够适应实施环境。 • 应用建模实践过程由五项“任务”组成, – 全局分析 – 局部分析 – 全局设计 – 局部设计 – 细节设计 • 前两项任务以分析为核心; • 后三项任务以设计为核心。 • 五项任务中包括14个活动; • 活动进一步被细化为30个步骤。 RUP是成功经验集合 • Rational统一过程是千锤百炼的成功经验集合, 其中关于分析和设计的内容非常宽泛,本书介绍 的实践过程与Rational统一过程的“分析和设计” 规程(Discipline)相容,可以看作为Rational统 一过程在应用建模工作方面的一个实例。 • Rational统一过程的分析和设计规程是具有普遍 意义的流程框架,借鉴这一框架能够充分利用前 人的最佳经验(The Best Practices)。不过,实 践中没有可能,更没有必要“求全责备”或“惟命是 从”。 RUP核心思想 • 实践过程充分遵循Rational统一过程的核 心思想原则:Use Case驱动、体系构架为 核心的迭代化开发。 迭代策略 • 下图展现的框架可以被看作是一次迭代的过程。由于在 “全局分析”任务中引入了“选定分析局部”活动,实践过程 可以充分地支撑迭代化开发的策略。通常,“全局分析”任 务中的前几项活动在后续迭代中可以被略去。 过渡迭代后果 • 迭代化方法中通常不作过多的假设,尽量 降低对既往工作结果进行大面积否定的可 能。 • 在现实生活中,前期活动中过度的假设往 往会导致后续工作不得不将错就错,表面 上还能满足要求,但暗中牺牲了整体的质 量和持续发展的能力。 角色和分工 • 参与应用建模的人员主要分成两类角色: 系统构架师和设计师。 系统架构师职责(1) • 系统构架师负责领导和协调整个项目中的技术活动。 • 在个人综合素养方面,系统构架师应该具有领导才能,能 够在压力下作出关键性的决策并善始善终; • 能够赢得项目经理、客户、用户群体以及管理团队的认同 和尊敬,尤其要善于和项目经理紧密协作; • 在各个方面都能展现出面向目标的实干作风。在专业技能 方面,与其他角色相比,系统构架师通常具有全方位的技 能,其见解重在广度,而不是深度。 系统架构师职责(2) • 系统构架师不仅需要具备设计师的各项技能,而 且应该具有问题领域和软件工程领域的实践经 验,从而有能力在无法获得完整信息的情况下迅 速领会问题并根据经验作出审慎的判断。 • 如果项目较大,系统构架师将是一个团队,上述 的关键素质要求可由团队成员来分担,但其中要 有一名系统构架师具有足够的权威。 设计师职责 • 设计师的工作对象通常是系统的局部或者细节。 设计师应该掌握的技能包括: – 理解以Use Case建模技术捕获和描述的软件需求; – 在系统构架师的统一协调下,应用UML进行局部的面向 对象分析和设计; – 了解主流的实施技术(程序设计语言和开发环境)。 两种职责范围 • 系统构架师负责全局性的分析和设计问 题,设计师负责局部性的分析和设计问题 以及细节性的设计问题。 • 实践过程中并没有采用单一、的自项向下 的策略(从全局到局部),而是在一个迭代 中完成两次全局和局部的.过渡,每一次 过渡都为系统构架师和设计师之间提供了 沟通的机会,在本质上,为提升设计的质 量和完整性创造了有利的客观条件。 “全局分析”任务的责任人、依据、活动与结果 选用构架模式 识别关键抽象 标识分析机制 选定分析局部 “局部分析 ”任务的责任人、 依据、活动与结果 提取分析类 转述需求场景 整理分析类 “全局设计”任务的责任人、依据、活动与结果 确定核心元素 引入外围元素 优化组织结构 “局部设计”任务的责任人、依据、活动与结果 实现需求场景 实现子系统接口 “细节设计”任务的责任人、依据、活动与结果 精细属性与操作 明确类之间关系 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 软件流程实施方案选择 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 什么是软件工程过程? z 任何工业化生产都离不开过程 • 大规模、有组织、有序的 z 软件工程过程 • 合理使用软件生产制造技术,定义谁(Who)什么时候 (When)做什么(What),以及如何(How)达到确定目标 • 将用户需求转化为软件系统的所有活动的集合 • 开发一个新的产品 • 增强已开发产品的功能(修复bug,或者添加功能) RUP简介 软件工程过程 新建和改变的需求 新建和改变的系统 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 什么是有效的过程? z 保证产品质量 z 迅速减少项目风险(需求、技术、政治风险等) z 保证项目的可预测性(进度、成本、功能等) z 能够捕捉和提供最佳实践方法(Best Practice) z 促进领域内(软件开发)的共识和相互理解 RUP简介 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 议题 z RUP、EUP与XP z 微软MSF与MOF z Agile与CMMI 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 成功的软件开发 成功的软件开发 -面向对象分析与设计 -结构化设计方法 -基于构件的开发方法 开发技术 -RUP,CMM,XP -瀑布模型 -螺旋模型... 开发过程 -Rational ROSE -RUP Builder -青鸟支撑系统 CASE Tool ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 开发方法=建模语言+开发过程 z 建模语言 (Modeling Language) • 表述设计方法的表示法 • 主要是图形化的 z 开发过程 (Development Process) • 对开发中所采取步骤的指导 • 将建模语言置于特定语境(开发环境)之中 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 广义的开发过程 z 虽然我们这里说过程(Process),实际上它涵盖 了软件项目管理技术的各个方面,包括: • 软件度量 • 项目估算 • 进度控制 • 人员组织 • 配置管理 • 项目计划等 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 UML+RUP=最佳软件开发方法 基于团队的开发 统一过程统一建模语言乐谱乐器 交响乐演奏 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 RUP囊括了6项最佳实践方法 被证明可解决软件开发过程中的根本问题 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 RUP是一个通用过程框架 z RUP是可定制的(Customizable)通用过程框架 • 开发软件的种类 • 开发软件的规模 • 开发软件的应用领域 • 开发团队的组织形式 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 RUP Version 2002.05.00 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 统一过程中的迭代 细化阶段的 一次迭代 需求 设计 实现 测试 时间 核心工作流 分析 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 RUP的3大核心技术特点 z 用例(Use Case)/需求驱动的 z 以构架(Architecture)为中心的 z 迭代(Iterative)和增量的(Incremental) 开发方式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 用例驱动的用例驱动的RUPRUP 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 什么是用例(Use Case) z 软件系统的特征 • 服务于特定用户 z 用例描述用户(User)需求 • 用户:与所开发系统交互的人或其他系统 • 所有用例构成系统的全部功能和边界 z UML规范说明中的定义 • 用例:在不展现系统或子系统内部结构的情况下, 对系统或子系统的某个连贯的功能单元的定义和描 述。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 Use Case 基本模型元素符号 z Actor(参与者) • 表示与系统交互的任何事物 z Use Case(用例) • 定义了系统的一系列动作,并 向参与者提供有价值的结果 Actor Use Case 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 Use Case 举例 银行个人自动交易系统的Use Case图 取钱 存钱银行客户 转帐 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 RUP是用例驱动的 z 需求分析阶段用户需求用Use Case来表达 z 设计初期很多类根据Use Case来发现 z 构造阶段开发的管理和任务的分配按照Use Case来组织 z 测试阶段的实例根据Use Case来生成 需求 分析 设计 实现 测试 通过Use Cases将所有RUP工作流有机地结合起来 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 用例在RUP中的其他功能 z 是有序(planned)迭代开发的基础 z 为编写最终用户手册提供索引(index) z 抽取可单独出售的系统单元(Business Component) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 以构架为中心的以构架为中心的 RUPRUP 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 什么是构架 z 与建筑施工图的作用相似 • 从各个角度刻画系统的总体设计(结构、服务设施、供 暖、供水、供电…) • 去掉细节,突出系统的重要特征 z 软件构架(UML用户指南中的定义) • 系统的重要元素,如子系统、类、构件和节点,以及 它们之间通过接口实现的协作 • 软件系统的组织(结构与行为) • 构架风格(数据流风格、调用/返回风格等…) • 功能、性能、适应性、重用性、技术约束、美学考虑 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 构架模型+构架视图=构架描述 z 模型是概念和知识 z 视图是表达模型的方式 构架视图构架模型 可视化 构架描述 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 构架视图 对照 Kruchten 提出的 4+1 view of software architecture ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 统一过程以构架为中心 z 构架为用户和开发人员提供系统的整体视图 z 构架是系统实现的基础 z 为项目管理提供基本指导 z 构架描述是软件系统的主要制品 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 以构架为中心的优点 z 创建可重用的框架,使构架级的重用成为可能 z 从构架可以方便地得到其他制品 • 设计指南(包括使用模式和术语) • 形成产品结构系列(企业版、家用版…) • 开发队伍结构 z 简化基于构件的开发(Component-Based Development) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 迭代和增量的迭代和增量的 RUPRUP 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 统一过程是迭代和增量的过程 z 迭代 • 是统一过程中最小的开发时间单位,但它却包括了 软件开发的所有工作流,因此也可以被看作是“袖珍 瀑布模型” z 增量 • 是每次迭代所产生的,可增加系统功能的构造块 z 迭代&增量 • 迭代是开发方式,增量是开发结果 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 迭代工作流 需求 测试实现设计分析 一次迭代 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 迭代是什么 z 是一组明确活动(activities)的集合 z 是有序的、受控的开发方式 z 是能够产生内部版本的袖珍项目 z 是项目开发过程中具体执行的工作流 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 迭代不是什么 z 不是任意的探路 z 不是重复设计同样的东西 z 不是只影响开发人员 z 不是项目失败的理由 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 为什么采用迭代和增量的开发方法 z 降低风险 • 尽早处理关键风险和重要风险,同时将项目开发的 总风险分散到每次的迭代中 z 小步前进 • 允许系统灵活改变,更易于处理不断变化的需求 z 受控增长 • 避免回头式开发,允许连续的系统集成 z 增强信心 • 使用户和开发人员都可以看到系统中不断增加的可 运行功能,对项目进度充满信心 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 迭代开发对风险的处理 风险的 严重性 第1次 迭代 第2次 迭代 ... ... ... 第n-1次 迭代 第n次 迭代 初始 细化 构造 移交 迭代和 增量 瀑布方法 瀑布方法的集 成和测试阶段 时间 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 迭代开发实现持续的构造集成 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 34 用例驱动、构架中心和迭代与增量 z 用例驱动系统构架的设计 z 系统构架影响用例的实现 z 用例体现了系统的功能(function) z 构架反映了系统的表现形式(form) z 用例设定了目标,构架建立了模式,开发人员 根据目标和模式规划产品迭代开发的顺序 18 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 35 概述 Agile方法的产生 针对上述问题,产生了一系列轻载(Lightweight)方 法,如XP,SCRUM等。 2001年2月,新方法的一些创始人在美国犹他州成 立Agile 联盟(http://www.agilealliance.org/ ) Lightweight Agile ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 36 概述 Agile方法的含义 Agile方法是在保证软件开发有成功产出的 前提下,尽量减少开发过程中的活动和制 品的方法。笼统的讲就是,“刚刚好”( Just enough),即开发中的活动及制品既 不要太多也不要太少。 19 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 37 概述 Agile方法的实践效果 我预言XP对当今时代的作用可与CMM在八十年代和九十年代初的作用 相媲美 -- Tom DeMarco, Cutter Trends Report 新方法在实践中取得了巨大的成功 •IONA公司的Obix技术支持小组在采用了XP方法后,软件 生产率提高了67% • SPG( software productivity group) 的Capers Jones则称, SCRUM方法可提高生产率6倍 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 38 Agile方法的核心理念 z 基于适应而非预测 z 以人为导向而非过程导向 --Martin Fowler “New Methodology” 20 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 39 Agile方法的核心理念及特点 适应而非预测 开始 计划的结果 实际需要的结果 需求不可预测--Peter Wegner用数学的方法给出了严格的证明 按计划的过程 基于适应的过程 理论上来说,软件开发应是一个自适应的跟踪过程 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 40 Agile方法的核心理念及特点 适应而非预测 自适应系统是一个强反馈系统 ƒ 在软件开发中,需求的获取和分析、软件设计、编码 等实质上均为前馈环节,真正的反馈环节应该是用户 对可运行软件的使用、使用中的判断及判断后与开发 人员的信息交流。 ƒ 反馈和前馈这一回路的响应速度应大于被跟踪(或被 适应)的系统的变化速度,这就要求软件开发有快速 的产出能力 。 21 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 41 Agile方法的核心理念及特点 适应而非预测 特点 Agile方法通过快速、短迭代式的开发,不断产出 和演化可运行软件,根据用户的反馈信息作适 应性调整,然后进入下一轮快速短迭代式开发 。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 42 软件开发中,人的因素是第一位的 Agile方法的核心理念及特点 以人为导向而非过程导向 ƒ 人是过程的主体,而人的工作承受力是有限的 ƒ 软件开发中的大部分是需要创造力的设计工作, 软件人员是创造性的工作者 ƒ 软件人员有主观上做好工作的意愿 ƒ 软件开发的目的是为人提供方便,应首先着眼于 有用的可执行的软件,也就是首先考虑商务目标 ,而不是为过程而过程 22 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 43 Agile方法的核心理念及特点 以人为导向而非过程导向 强调软件开发中相关人员间信息交流 •软件开发中的中间过程和制品(文档), 追根究底其目的是为了交流 • 项目失败的原因最终都可追溯到某个信息 没有及时准确地传递到应该接收它的人 -- Alistir Cockburn • 人特别擅长面对面的交流,面对面交流的 成本要远远低于文档交流的成本 -- Alistir cockburn ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 44 Agile方法的核心理念及特点 Agile方法的一个共同特点: 努力营造诚信、开放的组织氛围,根据项目中 信息流通的具体情况,按高内聚、松耦合的 原则,将项目组划分为若干个小组(每个小 组以不超过10人为宜,组员均在一个工作间 内工作),通过小组内各种渠道的沟通,来 减少中间制品的工作负担,提高应变能力。 以人为导向而非过程导向 23 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 45 z 任何软件开发方法都有一个相应的价值系统(Value system),方法通过价值系统对过程予以指导,方法 只有在其应用周境(context)与价值系统相吻合时才 能发挥真正效力 z Agile联盟提出了“四个价值”、“十二个指导原则” Agile方法的核心理念及特点 Agile方法的价值系统和指导原则 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 46 Agile方法的核心理念及特点 Agile方法的价值系统 ƒ 较之于过程和工具,更注重人及其相互作用的价值 ƒ 较之于无所不及的各类文档,更注重可运行的软件的价值 ƒ 较之于合同谈判,更注重与客户合作的价值 ƒ 较之于按计划行事,更注重适应需求变化的价值 24 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 47 (1)在快速不断地交付用户可运行软件的过程中,将使用户满意放在第一位 (2)以积极的态度对待需求的变化(不管该变化出现在开发早期还是后期) (3)以几周到几个月为周期,尽快、不断地交付可运行的软件供用户使用 (4)在项目过程中,业务人员和开发人员最好能一起工作 (5)以积极向上的员工为中心建立项目组,给予他们所需的环境和支持,对 他们的工作予以充分的信任 (6) 在项目组中,最有用、最有效的信息沟通手段是面对面的交谈 Agile方法的核心理念及特点 Agile方法的指导原则 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 48 Agile方法的核心理念及特点 Agile方法的指导原则 (7)测量项目进展的首要依据是可运行的软件 (8) Agile过程高度重视可持续开发 项目发起者、开发者和用户应能始终保持步调一致 (9) 应时刻关注技术上的精益求精和设计的合理,这样能提 高软件的快速应变力 (10)简单化(尽可能减少不必要工作的艺术) (11)最好的框架结构、需求和设计产生于自组织的项目组 (12)项目组要定期对其运作情况进行反思,提出改进意见, 并进行相应的微调 25 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 49 Agile方法的核心理念及特点 Agile方法的适用范围 Martin Fowler认为:新方法不是到处可适用的 适合采用Agile方法的情况: z 需求不确定、易挥发(Volatile,意指今天的要求明天就不 需要了) z 有责任感和积极向上的开发人员 z 用户容易沟通并能参与 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 50 Agile与CMM (1)CMM更注重管理问题(组织过程的有效性和过程的系统化改进), Agile更注重技术和效率 (2)CMM提供了一个高度抽象的框架,有广泛的适用范围,Agile适用于小 组织和需求不定、有用户紧密参与的情况(在高可靠性要求和大型项目 组,或虚拟项目组中不宜采用) (3)CMM与Agile方法虽有一些公共的特点,但Agile方法只是满足或部分满 足了CMM2到3级中部分KPA(关键过程区域)的要求 (4) Agile方法提出了在某些周境(context)下非常有效的实践,与CMM方 法有一定的互补性,CMM着重于“应该做什么”,Agile则侧重于“如 何做” CMM的视角( Mark Paulk 的看法) 26 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 51 z XP方法从某种意义上来说是CMM2到5级的一 个垂直切片(满足了CMM2到5级中的部分 KPA目标要求) z 若将之应用于整个组织则还需更多的度量工 作,但他同时指出,XP方法中更多的度量不 是不可以做,而是要根据投入回报分析决定 是否有必要 Agile与CMM XP的视角( Ron Jeffries的看法) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 52 z CMM更注重质量,Agile更注重生产率 z CMM强调过程的可观测性,Agile强调可观测的结果(可运行软件 ) z CMM注重管理和过程,Agile注重技术和效率 z CMM注重组织,Agile注重个人 z CMM无所不包(Universal),Agile有明确的适用范围 z 它们都包含了一些软件工程的好的实践(Practices) Agile与CMM 个人观点(仅供参考) 结合点在哪里,如何Just Enough? 27 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 53 Agile 具体方法介绍 z Extreme Programming (简称XP) z SCRUM z Crystal Methodologies (简称Crystal) z Feature Driven Development(简称FDD) z Dynamic Systems Development Methodology(简称 DSDM) z Adaptive Software Development(简称ASD) z Pragmatic Programming等 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 54 什么是XP Kent Beck 1996 XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. -- Kent Beck. XP是勇气,交流,反馈和简单。 XP是软件开发过程中的纪律,它规定你:必须在编程前些测试,必须 两个人一起编程,必须遵守编程规范……。 XP是把最好的实践经验提取出来,形成了一个崭新的开发方法。 Extreme Programming 28 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 55 XP的增量过程 简单 设计迭代 计划 测试驱动 Pair开发 持续 集成 重构 1..N个 Iteration 发布 计划 1..N个 Release 小发布 发布 1..N个 Task ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 56 XP价值观 交流(Communication) 勇气(Courage) 简单 (Simplicity) 反馈 (Feedback) 简单即为在管用能完成事情的前提下,做最简单的事;交流即整个开发过程应该都 需要及时交流,这里交流侧重口头交流和能简单明了说明问题的文档交流,屏弃烦 琐杂乱的文档和计划等;反馈即整个项目任何时候都需要客户和内部人员的反馈, 以保证整个软件不断处于设计与编程与修复BUG的状态中;勇气即要求你必须有足 够信心对自己的代码乃至别人的代码进行重构。 29 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 57 十二条惯例和规则 z On-Site Customer (现场客户) z 计划项目 (Planning Game) z 频繁地小规模发布软件 (Small Releases) z 简单设计 (Simple Design) z 测试驱动开发 (Test Driven Development) z 持续集成 (Continuous Integration) z 集体拥有代码 (Collective Code Ownership) z 编程规范 (Coding Standards) z 重构 (Refactoring) z System Metaphor (系统隐喻) z Pair Programming (结对编程) z 平稳的工作效率 (Sustainable Pace) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 58 测试驱动开发(Test-Driven Develop, TDD) 失败 通过 时间 单元测试 100% 通过 设计 先写 单元测试 重构 运行 单元测试 编程 发现BUG 集成 先写 功能测试 User Story 运行 功能测试 30 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 59 重构 z 减少重复设计,优化设计结构,提高技术上的重用性和可扩 展性。 z 在Metaphor指引下的重构,是为商业模型服务的。不要把 重构变成不断的盲目精简代码。 z 重构和编程前的计划型设计(Planned Design)结合,使XP的 简单设计可行有效。 z XP提倡毫不留情的重构(Refactor mercilessly)。 z 任何人可以重构任何代码,前提是重构后的代码一定要通过 100%测试单元测试后才能被Check-in。 z 可以根据需要,将一个迭代的全部目标定为重构。 z 不要太在意什么是最简单的设计 —— 愿意在最后重构,比 知道如何做简单的设计重要得多。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 60 需求 分析 设计 编码 测试 集成 使用和维护 Planned Design XP Design 变化导致的成本增加 软件研发 异动曲线 简单设计 XP中的演进设计(Evolutionary-design) z 如果没有它和众多惯例规则之间的耦合,XP的演化设计就蜕化成CODE- FIX。 z XP的演化设计是在Up-front design和Refactoring之间找到新的平衡。 31 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 61 编程规范 z 规定了程序的风格,包括注释如何写,变量命名的规范,代码的格式等等。 z Teamwork 的前提之一,其它众多惯例和规则(如Pair Programming, Collective Code Ownership等)的前提之一。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 62 集体拥有代码 z “我们”的代码,而不是“我”的代码。 z 任何人可以改动任何一段代码,但改动后的代码必须通过所有相关的测试 。 z 简单设计,编程规范和Pair Programming,使阅读和修改Team内其他人的 代码变得实际可行。 32 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 63 Pair Programming 两个程序员使用同一台电脑共同开发。XP的必须组成部分,XP中最有争 议的规则之一。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 64 频繁地小规模发布软件 z 发布过程应该尽可能地自动化、规范化。 z 不断地发布可用的系统可以告诉客户你在做正确的事情。 z 客户使用发布的系统,可以保证频繁地反馈和交流。 z 保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。 z 降低开发风险。 z 随着开发的推进,发布越来越频繁。 z 所有的发布都要经过功能测试。 33 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 65 平稳的工作效率 平稳的工作效率指Team和个人在很长的时期内保持一定的 开发效率。 z 保证了项目速度和计划过程的有效性和准确性; z 保证了程序员可以持续地完成任务,Team可以持续地向 客户交付可运行的系统(见敏捷开发宣言); z 加班多导致开发效率和质量下降,简洁增加了开发成本; z Pair Programming已经加大了工作强度,并且和其它XP 的规则一起提高了工作效率,使少加班和维持平稳的工作 效率可能而且可行。 z 提倡平稳的工作效率,体现了XP以人为本的价值观。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 66 MSF是微软解决方案框架 z 框架不是具体的软件程序或解决方案 z 框架只是一组模型、原则、概念方法,以帮助使用者开 发良好解决方案为目的 34 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 67 MSF主旨和观点 z MSF对环境、采用的技术、项目的大小有较大的 适应性,这是MSF的第一个主旨 z MSF对软件开发还持以下独到的见解 • 用户的需求是变动的 • 需求是未来的,而不是当前的 • 资源永远的匮乏的 • 风险普遍存在 • 开发小组成员是协作的平等关系 • 认识是渐进的,过程是迭代的 • 技术模型也可以影响业务模型 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 68 MSF概念 z MSF • 是一系列的指导方针 • 目的在于用更快的速度、更少的人力、更小的风险 、更高的质量,成功交付信息技术解决方案。 35 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 69 两种模型 z 小组模型 • MSF提供了一个有机的建组模型,由不 同业务职能人员形成开发组,人员以角 色承担组内应负的职责 • 角色之间是协商和合作关系。小组的扩 大与缩减也都以角色承担工作量为准过程模型 MSF提供了一个既分阶段又有反复迭代的 软件开发模型 吸收了瀑布模型的经验和螺旋模型的优 点 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 70 三种管理准则 z MSF有三种管理准则:项目管理准则、风险管 理和就绪管理。 z MSF的项目管理 • 不设项目经理 • 项目管理活动尽量以当事人的意见为主 • 强调项目管理与风险管理紧密结合 • MSF项目管理非常重视实践 36 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 71 MSF的基本原则 z MSF八大基本原则 • 职责明确、责任共享 • 在一个共享的远景下工作 • 小组成员有职有权 • 重点是交付业务价值 • 灵活敏捷、主动应变 • 促进坦率沟通 • 在质量上投资 • 从各种经验中学习 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 72 关键概念 z MSF在形成自己的模型和准则时,为了体现MSF 的基本原则形成一些关键的概念,即支持MSF思 想的理念。 z MSF为每一种模型,每一种准则给出了关键概念 小组模型关键概念 • 角色平等 • 以客户为中心 • 都要有产品理念 • 零缺陷意识 • 乐于学习 • 有激情的小组最有效 37 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 73 经实践检验正确的经验 z 除了基本原则和关键概念之外。MSF还为每种 模型,每种准则提供了采用模型,实施管理时 的实际经验,这些经验是经过实际验证切实可 行的。 小组模型经验 • 组成多学科小组 • 同一地点办公 • 所有成员均参与设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 74 总结:MSF基本要素 风险管理准则 增加成功的潜力项目管理准则 管理和满足承诺 就绪管理准则 在正确的时间拥有 正确的技能 小组模型 过程模型 38 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 75 CMM CMM的基本概念 • 能力成熟度模型(Capability Maturity Model) •80年代,在美国国防部资助下,由卡内基梅隆大学软 件工程研究所(SEI)建立,用于评价 软件开发组织的软 件过程能力成熟度 • 后来此模型被用于软件开发组织内部的软件过程改 进。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 76 CMM 初始级 可重复级 已管理级 已定义级 优化级成 熟 度 风 险 CMM的基本概念 39 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 77 CMM CMM的基本概念 成熟度等级 关键过程方面(KPA) 公共特性 关键惯例 过程能力 目标 实现或实现制度化 基础设施或活动 指出 达到 涉及 描述 包含 由...组成 包含 CMM结构图 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 78 CMM CMM的基本概念 美国曾在1995年做过软件产业成熟程度的调查,发现在美国的软 件产业中: ƒCMM成熟度等级为初始级的竟占70%,其特征是软件开发过程 不能预测,风险度高; ƒ为可重复级的占15%,其特征是软件开发过程需小心谨慎方能避 免失败; ƒ为定义级的所占比例小于10%,其特征是软件开发过程相当稳 定,进展顺利且可以预测; ƒ为管理级的所占比例小于5%,其特征是软件过程预测准确、值 得信赖; ƒ为优化级的所占比例小于1%,其特征是软件过程能持续改善。 40 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 79 CMM PSP的基本概念 个体软件过程PSP(Personal Software Process),为基于 个体和小型群组软件过程的优化提供了具体而有效的 途径,例如 ƒ如何制订计划 ƒ如何控制质量 ƒ如何与其他人相互协作等等 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 80 CMM PSP采用的方法 ƒ PSP保障软件产品质量的一个重要途径是提高设计质量 ƒ 在软件设计阶段,PSP的着眼点在于软件缺陷的预防, 其具体办法是强化设计结束准则,而不是设计方法的选 择 41 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 81 CMM PSP的效用 研究表明: ƒ 绝大多数软件缺陷是由于对问题的错误理解或简单的 失误所造成的,只有很少一部分是由于技术问题而产 生的 ƒ 如果在设计阶段注入一个差错,则这个差错在编码阶 段要引发3~5个新的缺陷,要修复这些缺陷所花的费 用要比修复这个设计缺陷所花的费用多10倍 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 82 CMM PSP的效用 研究表明: ƒ 根据对参加培训的104位软件人员的统计数据表明, 在应用了PSP后,软件中总的缺陷减少了58.0%,在测 试阶段发现的缺陷减少了71.9%,生产效率提高了 20.8% 42 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 83 CMM TSP的基本概念 群组软件过程TSP(Team Software Process) , ƒ指导项目组中的成员如何有效地规划和管理所面临的 项目开发任务 ƒ告诉管理人员如何指导软件开发队伍始终以最佳状态 来完成工作 ƒTSP实施集体管理与自已管理自己相结合的原则,最 终目的在于指导一切人员如何在最少的时间内,以预 定的费用生产出高质量的软件产品 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 84 CMM TSP所采用的方法 ƒ 对群组软件开发过程的定义、度量和改进 ƒ 实施TSP的先决条件有3条: 9需要有高层主管和各级经理的支持,以取得必要 的资源 9项目组开发人员需要经过PSP的培训并有按TSP工 作的愿望和热情 9整个软件企业在总体上应处于CMM二级以上 43 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 85 CMM TSP所采用的方法 在实施TSP的过程中, ƒ要有明确的目标 9 开发人员在每一阶段开始,要做好工作计划 9如果发现未能按期按质完成计划,应分析原因, 以判定问题是由于工作内容不合适或工作计划不实 际所引起,还是由于资源不足或主观努力不够所引 起。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 86 CMM TSP所采用的方法 在实施TSP的过程中, ƒ开发小组应随时追踪项目进展状态并进行定期汇报 ƒ开发小组应经常评审自己是否按PSP的原理工作 44 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 87 CMM TSP所采用的方法 在实施TSP的过程中, ƒ开发人员应按自己管理自己的原则管理软件过程,如 发现过程不合适,应及时改进,以保证用高质量的过 程来生产高质量的软件 ƒ项目开发小组则按集体管理的原则进行管理,全体成 员都要参加和关心小组的规划、进展的追踪和决策的 制订等项工作 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 88 CMM 45 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 89 经验借鉴 国外某些大公司软件工程管理经验: ƒ软件工程管理方面的投资一般占软件开发费用的10%左 右 ƒ软件过程的重大修改也必须由高层管理部门启动 ƒ软件过程的改善还有待于全体有关人员的积极参与,否 则不仅他本人将失去从软件过程改善中获得提高的机会, 甚至还会成为过程改善的阻力 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 90 经验借鉴 ƒ软件过程成熟度的升级本身就是一个过程,有一个生命 周期。因此,过程改善工作需要循序渐进 ƒ要将CMM/PSP/TSP引入软件企业,最有效的途径是要 对单位主管和主要开发人员进行系统的培训 ƒ中小企业可以以CMM为框架,先从PSP做起,然后在此 基础上逐渐过渡到TSP,以保证CMM/PSP/TSP在企业中 根深蒂固 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 软件架构文档设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 z 软件配置管理 z 软件架构模版设计 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 SCM工作指南 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 议程 z 配置管理的基本概念 z 配置项标识 z 配置库目录结构 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 配置管理 (1)ISO 9000-3 :1997 配置管理是一个管理学科,它对配置项(包括软件项)的开发和支持生存期给与 技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大 小。 (2) W.Babich 的解释 软件配置管理能协调软件开发,使混乱减少到最小。软件配置管理是一种标识、 组织和控制修改的技术,目的是最有效的提高生产率。 (3) GB/T 11457 :1995《软件工程术语》国家标准 A.表示和确定系统中配置项的过程,在系统整个生存期内控制这些配置项的投放和更动 ,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。 B.对下列工作进行技术和行动指导与监督的一套规范: ——对配置项的功能特性和物理特性进行标识和文件编制工作; ——控制这些特性的更动情况; ——记录并报告这些更动进行的处理和实现的状态。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 为什么需要配置管理 忽视软件配置管理可能导致的混乱现象: • 发错了版本 • 安装后不工作 • 异地不能正常工作 • 已经解决的缺陷过后又出现错误 • 开发人员把产品拿出去出售赢利 • 找不到最新修改了的源程序 • 找不到编程序的人 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 SCM的主要职责(1) 变更控制 配置项标识 配置状态报告 工作产品的完整性、 一致性、可追踪性 配置审计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 SCM的主要职责(2) z 配置项 • 受配置管理控制和管理的基本单位。配置管理工作都是围绕配置项来进行。 z 配置标识 • 要进行配置标识,首先必须明确项目生命周期内所要产生的工作产品,然后 确定工作产品的命名和标识规则。总体原则是方便在配置管理工具中进行检 索和让项目组成员容易记住标识规则,同时确保在组织一级的标识规则一致 性。 z 变更管理 • 变更管理是项目管理的一个重点和难点,涉及的范围很广。实施高效的变更 管理至少应该包括二个部分,一是定义合理变更管理流程,一是采用自动化 工具来支持。在具体的实践中,应该对变更进行分类和分层,建立处理不同 变更的变更控制委员会(CCB)构成策略,既能保证项目组成员有一定的自主 权又不耽误高层经理对关键问题的把握。 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 SCM的主要职责(3) z 报告配置状态 • 报告配置状态的目的是向项目所有成员提供基线内容和状态、基线变更信息 ,也是实现资源共享的前提。此外,在项目生命周期中通过对配置项的变更 数据统计分析,有利于评估项目风险,有效控制项目的执行。报告的方式可 以多种多样,如Email,但应该把握好时机:变更请求被批准时;基线版本发 生变化时;项目组任何需要的时候。 z 配置审核 • 配置审核包括两方面的内容:配置管理活动审核及基线审核。配置管理活动 审核确保项目组成员所有配置管理活动遵循批准的软件配置管理方针和规程 ,比如检入(Check in)/检出(Check Out)的频度,工作产品成熟度提升 原则等。实施基线审核,保证基线化软件工作产品的完整性和一致性,并且 满足其功能要求。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 确定配置项 1、 系统规格说明 2、 软件项目计划 3、 软件需求规格说明书 a.图形分析模型 b.处理规格说明 c.原型 d.数学规格说明 4. 初步用户手册 5. 设计规格说明书 a.数据设计描述 b.体系结构设计描述 c.模块设计描述 d.接口设计描述 e.对象描述(采用面向对象技术时 ) 6. 源代码清单 7、 测试规格说明 a.测试计划和步骤 b.测试用例和记录的结果 8、操作和安装手册 9、 可执行程序 a.模块可执行代码 b.连接的模块 10、数据库描述 a.模式和文件结构 b.初始内容 11、联机用户手册 12、维护文档 a.软件问题报告 b.维护请求 c.工程变更指令 13.软件工程标准和规程 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 配置项标识 z 配置标识是软件生命周期中划分选择各类配置项、定义配置项的种 类、为它们分配标识符的过程。配置项标识的重要内容就是对配置 项进行标识和命名。 z 原则 • 唯一性 • 可追溯性 • 与同类配置项不同的信息,应纳入标识:这是为了便于区分、查找 • 同类配置项的标识方法统一 • 容易记忆 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 文档标识方法(1) z 配置项的相关标识信息 • 组名 • 项目名 • 文档内容 • 版本号 • 文档撰写时间 • 文档撰写作者 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 文档标识方法(2) z 标识项目信息 命名方式:[项目编号+文档名称] 例如:RDMIS_需求规格说明书 适用于:需求规格说明书、概要设计说明书、详细设计说明书、测试计划等等 z 标识版本变化 版本变化不通过文档命名来标识,对于基线文档,在CVS中是通过tag来标识。并 且,在文档的头信息中必须注明文档的版本号。 命名方式:[文档名称] 例如:RDMIS_概要设计说明书 适用于有版本变化的文档。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 文档标识方法(3) z 标识文档撰写时间 命名方式:[文档名称+撰写时间] 例如:RDMIS项目会议记录_20040708 适用于:会议记录、项目周报、工作周报等等 z 标识文档作者 命名方式:[文档名称+人员名称] 例如:项目周报_李平_20041227 适用于:项目周报、工作周报、年终工作总结等等 z 标识子系统或者模块名称 命名方式:[项目编号+子系统名称+文档名称] 例如:RDMIS_绩效考评_详细设计说明书 适用于:子系统详细设计说明书、系统模块设计说明书等等 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 文档标识方法(4) z 文档首页可以包括这些信息:项目名、文档名、文档作者、本文档 的版本更新历史、版本号、日期、修改的页码等。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 程序标识信息 z 每个源程序的首部应包括的信息为:功能描述 、创建日期、作者、版本号。 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 版本号 z 形式:主版本号.从版本号.维护版本号 z 主版本号 • 对系统作重大调整,在功能和性能上有大的变化时主版本号增加。第一次版 本号和第二次版本号为零。版本号升级由项目组长/室主任决定。 z 从版本号 • 与上一版本相比,对系统功能或性能进行了少量的增加或修改,从版本号增 加,主版本号不变。版本号升级由项目组长决定。 z 维护版本号 • 与上一版本相比,修改了小量系统bug,维护版本号增加,主版本号和从版本 号不变。版本号升级由项目组长决定。 z 通常来说,通过软件系统测试后系统版本号变为V1.0,软件系统第一次发布时版本 号为V1.0.0,从版本号和维护版本号均为0。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 CVS辅助标识方法 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 版本的演变 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 配置库的作用 • 记录与配置相关的所有信息 • 利用库中的信息可评价变更的后果 • 可利用库中的信息查询,例如: • 那些客户已提取了某个特定的系统版本? • 运行一个给定的系统版本需要什么硬件和系统的哪些版本? • 一个系统到目前已生成了多少版本,何时生成的? • 如果某一特定的构件变更了,会影响到系统的那些版本? • 一个特定的版本曾提出过那几个变更请求? • 一个特定的版本有多少已报告的错误? 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 三库 (1)开发库: 存放开发过程中需要保留的各种信息,供项目组成员使用。 (2)基线库: 在软件开发的某个阶段工作结束时,将工作产品存入或将有 关的信息存入。 (3)产品库: 在开发的软件产品完成系统测试之后,作为最终产品存入库 内,等待交付用户或现场安装。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 配置库目录结构 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 配置库使用说明(1) z 放入正确的位置,正确标识 • 因为CVS工具本身的问题,如果你将文件放在错误的位置,或者命名 不规范,SCM进行位置移动或者修改文件名称的时候,会造成历史版 本的丢失,想要找回历史版本很不容易,给配置管理造成一定的工作 量。 • 所以请大家在进行文件入库时,注意放入正确的位置,并且正确命名 ,以免造成历史版本丢失。 z 及时提交、更新 • 如果习惯将自己的工作产品放在个人目录下,请及时提交或者 更新到服务器上,让相关人员能够看到最新的文件 • 养成良好的工作习惯,每次要对某个文件进行修改时,请首先 UPDATE这个文件,从服务器上更新最新版本,以免在旧版本基 础上修改,造成冲突,无法提交。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 配置库使用说明(2) z 提交规范 • 文件提交到服务器上时,有“Enter the log message”,请大家一定要填写,主要填写几个方面 的内容:修改的目的,修改的主要内容(段落或者 函数名称),修改可能造成的影响。 • 尤其是进入编码和测试阶段,要求每个文件的提交 必须有log message。请大家注意! 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 提交规范 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 软件架构模版设计 z 指导原则 z 标准模版 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 体系结构设计 z 体系结构设计原则 • 文学中有科学,音乐中有数学,漫画中有现代数学的 拓扑学。漫画家可以“几笔”就把一个人画出来,不管 怎么美化或丑化,就是活像。为什么?因为那“几笔” 不是别的,而是拓扑学中的特征不变量,这是事物最 本质的东西。 • 体系结构是指软件系统的基本和主体的形态,也就是 软件系统中“最本质”的东西。一个软件系统的体系结 构设计得好不好,可以用“合适性、结构稳定性、可扩 展性、可复用性”这些特征量来评估。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 合适性:即体系结构是否适合于软件的“功能性需 求”和“非功能性需求”。 z 设计师可以充分发挥主观能动性,根据需求的特征,通过推理和归 纳的方法设计出合适的体系结构。经验不丰富的设计师往往把注意 力集中在“功能性需求”而疏忽了“非功能性需求”,殊不知后者恰恰 是最能体现设计水平的地方。 z 高水平的设计师高就高在“设计出恰好满足客户需求的软件,并且 使开发方和客户方获取最大的利益,而不是不惜代价设计出最先进 的软件。(以设计住宅为例)… z 对于软件系统而言,能够满足需求的设计方案可能有很多种,究竟 该选哪一种?此时商业目标是决策依据,即选择能够为开发方和客 户方带来最大利益的那个设计方案。大部分软件开发人员天生有使 用新技术的倾向,而这种倾向对开发商业产品而言可能是不利的, 切记切记。 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 结构稳定性 • 当前中国有几句流行的至理名言:“稳定压倒一切”、“发 展是硬道理”。发展的前提条件是稳定,社会如此,开 发软件产品也是如此。 • 体系结构一旦设计完成,应当在一定的时间内保持稳定 不变,只有这样才能使后续工作顺利开展。如果体系结 构经常变动,那么建筑在体系结构之上的用户界面、数 据库、模块、数据结构等等也跟着经常变动,用“树倒 猢狲散”来比喻很恰当,这将导致项目发生混乱。 • 高水平的设计师应当能够分析需求文档,判断出哪些需 求是稳定不变的,哪些需求是可能变动的。于是根据那 些稳定不变的需求设计体系结构,而根据那些可变的需 求设计软件的“可扩展性”。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 可扩展性 z 可扩展性是指软件扩展新功能的容易程度。可扩展性越好,表示软件 适应“变化”的能力越强。可扩展性越来越重要,这是由现代软件的商 业模式决定的: • 社会的商业越发达,需求变化就越快。 • 现代软件产品通常采用“增量开发模式”,开发商不断地推出软件产品的 新版本,从而不断地获取增值利润。 • 稳定性和可扩展性之间存在辨证的关系:如果系统不可扩展的话,那么 就没有发展前途,所以不能只关心稳定性而忽视可扩展性;而软件系统 “可扩展”的前提条件是“保持结构稳定”,否则软件难以按计划开发出来 ,稳定性是使系统能够持续发展的基础。所以稳定性和可扩展性都是体 系结构设计的要素。 • 如果每次变化都导致体系结构发生大的变动,那简直就是“伤筋动骨”, 这样的体系结构无疑是败笔之作。(例如房屋装修) 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 可复用性 z 复用就是指“重复利用已经存在的东西”。被复用的对象可以是有形的 物体,也可以是无形的知识财富。复用不是人类懒惰的表现而是智 慧的表现。因为人类总是在继承了前人的成果,不断加以利用、改 进或创新后才会进步。 z 复用的有利于提高产品的质量、提高生产率和降低成本。由经验可 知,通常在一个新系统中,大部分的内容是成熟的,只有小部分内 容是创新的。一般地可以相信成熟的东西总是比较可靠的(即具有 高质量),而大量成熟的工作可以通过复用来快速实现(即具有高 生产率)。勤劳并且聪明的人们应该把大部分的时间用在小比例的 创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才 能把工作做得又快又好。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 z 复用的意义很容易理解,人们也乐意复用以前的成果, 但是前提条件是该成果具有比较好的可复用性。可复用 性是指成果被复用的容易程度。 z 可复用性是设计出来的,而不是偶然碰到的。要使体系 结构具有良好的可复用性,设计师应当分析应用域的共 性问题,然后设计出一种通用的体系结构模式,这样的 体系结构才可以被复用。 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 体系结构设计流程 • 体系结构设计流程:6个步骤 • 《体系结构设计报告》模板见word文档 软件架构风险管理 „ 如何识别软件架构的风险 „ 如何规避软件架构风险 „ 软件架构风险管理与控制 如何识别软件架构的风险 (1)需求的不断变化 (2)架构师对于技术理解不足 (3)缺乏对行业的研究 (4)经验不足 (5)创造性的架构比重比较重 (6)没有形成一套构架的规范 (7)架构可执行性差 如何规避软件架构风险 „ 固化需求 „ 完善的业务原型 „ 完整架构规范 „ 验证架构的可执行性 „ 80%的经验架构+20%的创新架构 软件架构风险 管理与控制 风险管理过程 1.标识 2.分析和 优先级化 3.计划和 调度 4.跟踪和 报告5.控制 6.学习 风险标识 风险标识(1) „ 目标 „ 为小组创建一个他们面临的风险的列表 „ 输入 „ 是一般和项目风险相关的可用的知识,包括业务、技 术、组织和环境域 „ 风险标识活动 „ MSF风险管理准则强调风险标识在一个项目中要周期性 实施。 „ 风险标识可以是进度驱动的,可以是里程碑驱动的, 或事件驱动的。 风险标识(2) „ 结构化方法 „ 风险分类 „ 风险陈述 …… 规章 法律 环境的 …… 开发和测试环境 保障性 技术 …… 决策 使命和目标 过程 …… 最终用户 客户 人员 项目风险源的高层分类 风险标识(3) „ 结构化方法 „ 风险分类 „ 风险陈述 风险标识(4) „ 输出 „ 风险标识活动最基本的输出是对小组面临的风险的明 确的、无二义的、达成共识的陈述,用风险列表的方 式记录。 „ MSF风险管理建议小组必须创建表格记录的风险陈 述、根源和向下影响的信息 增加了附加的重复工作 ,产品交付延期 小组之间沟通很困难开发组在两个地方: 伦敦和洛杉机 组织 我们的产品将晚上市, 竞争对手会抢占市场份 额 开发时间会延长我们的开发人员正在 使用一种新的编程语 言。 技术变更 降低了客户满意度我们交付时可能会有更 多的缺陷 开发角色和测试角色 已被合并 人员不充 足 下游影响结果条件根源 分析和确定风险优先级 „ 风险优先级化确保小组首先处理最重要的 项目风险。 分析和确定风险优先级(1) „ 目标 „ 首要目标是确定风险列表中各项的优先级,确定哪些是需要分配 资源做计划的风险。 „ 输入 „ 切题的信息可来自组织风险政策和指南,行业风险数据库,模 拟、分析模型,业务单位经理,领域专家等。 „ 风险分析活动 „ 风险分析最易使用的一个方法是:使用两个被广泛接受的风险成 分,即概率(probability)和影响(impact),让小组对这两个风险成分 达成共识的估计,这两个量可以被相乘来计算一个简单度量,即 风险爆发(risk exposure) 分析和确定风险优先级(2) „ 风险概率 „ 概率的三值表示法 „ 概率的七值表示法 3高84%68%-99% 2中50%34%-67% 1低17%1%-33% 数值计分自然语言表述计算用概率值概率范围 7几乎确实93%87%-99% 6很可能79%73%-86% 5可能65%58%-72% 450-5050%43%-57% 3不可能35%29%-42% 2低21%15%-28% 1极不可能7%1%-14% 数值计分自然语言表述计算用概率值概率范围 分析和确定风险优先级(3) „ 风险影响 „ 金钱损失计分表 „ 风险影响计分表 $10 billion以上10 $1 billion - $10 billion9 $100 million - $1 billion8 $10 million-$100 million7 $1,000,000-$10 million6 $100,000-$1,000,0005 $10,000-$100,0004 $1000-$10,0003 $100-$10002 低于 $1001 金钱损失计分 不能完成使命延期超过1个月大于10%或更多严重的(critical) 对性能严重影响延期1个月少于10%高(high) 对性能中等程度影响延期2周少于5%中等(Medium) 对性能轻微影响延期1周少于1%低(low) 技术的进度费用超出限度标准 分析和确定风险优先级(4) „ 风险爆发 = 风险概率 * 风险影响 „ 风险概率和风险影响矩阵 321低= 1 642中等 = 2 963高 = 3 高 = 3中等 = 2高 = 1概率\影响 分析和确定风险优先级(5) „ 量化方法补充 „ 风险有加权的优先级矩阵 0.8434300.334.9816 0.842022000.3337.64 0.33442000.8483.596 0.5215000.5125.025 概率控制可 行性 控制费用 (千美元) 需要时间 (周) 影响 (千美元))概率排序值 分析和确定风险优先级(6) „ 输出 „ 风险主列表 „ 附加的分析方法 „ 风险陈述表 „ 最高风险列表 „ 使风险无效 附:风险主列表 „ 风险主列表 0.6230%某些产品功 能特性将不 能实现 无书面的 需求规格 说明 3 0.9245%交付时有更 多缺陷 新出编程 语言没有 标准 2 2.4380%在年底失去 资金 长项目进 度表 1 爆发影响概率结果条件优先级 附:风险主列表条目 可选捕获在特定时间框中实现风险控制的重要性实现的时间 可选记录下背景信息以便捕获小组提出风险的意图上下文 可选确保合适的影响估计对下游的影响 可选指导有效的干涉计划根源 要求描述更正措施应急计划和触发器 要求描述预防措施缓解计划 要求确保按照风险行动计划贯彻到底所有者 要求行动优先级化优先级(等级) 要求重要性的单项量度排序准则 要求量化损失严重性或机会费用的规模影响 要求量化发生的可能性概率 要求明确描述一个风险风险陈述 状态目的条目 附:风险陈述表格中的内容 一个风险标识符列表,小组用它来跟踪相互依赖的风险相关风险 一段文字,包含附加的背景信息,用于帮助澄清风险状况风险上下文 风险的整体威胁,是实际损失的可能性和潜在损失的规模量的平衡,小 组使用风险爆发来估量风险并排序,爆发是风险概率与影响的乘积 风险爆发 如果风险实际发生,影响的规模量,这个量可以是金钱的损失量,或用 1-10来表示的相对规模 风险影响 风险可能产生影响的类型的粗分类。风险影响分类 一个概率大于零,小于100%,代表一个能导致损失的风险实际发生的 可能性 风险概率 描述如果风险已经发生,将导致的损失的一段文字,它构成风险陈述的 第二部分 风险结果 描述会导致损失的已有条件的一段文字。它构成风险陈述的第一部分风险条件 风险来源领域的粗分类,用于当需要寻找重复发生的风险根源时,标识 领域 风险源 小组用唯一的名字标识一个风险,用于风险报告和跟踪风险标识符 意图条目 风险计划和调度 风险计划和调度(1) „ 目标 „ 为风险分析所标识的最高风险的控制开发详细 计划,并把它们集成到标准的项目管理过程 中,以确保它们完成。 „ 输入 „ 包括风险主列表,最高风险列表,来自风险管 理知识库中的信息,以及项目计划和进度表。 风险计划和调度(2) „ 计划活动 „ 研究 „ 接受 „ 避免 „ 转移 „ 缓解 „ 应急计划 风险计划和调度(3) „ 调度活动 „ 小组应该认识到风险控制活动是项目有机成 份,而不是自愿实施的额外活动。 „ 输出 „ 风险行动项 „ 风险行动表 „ 更新项目进度表和项目计划 风险跟踪和报告 风险跟踪和报告(1) „ 目标 „ 监视风险行动计划的状态 „ 监视与应急计划触发器相关的项目度量 „ 提示应急计划已触发,启动应急计划 „ 输入 „ 风险行动表 „ 相关项目的状态报告 „ 跟踪活动 „ 为每个风险创建特定风险状态报告 风险跟踪和报告(2) „ 风险状态报告 „ 风险报告运行在两个层次上,一个层次是小组 本身,另一个层次是向外部干系人报告。 „ 输出 „ 风险状态报告的目的是通告风险状态的变化, 报告缓解计划的进展 风险控制 风险控制(1) „ 目标 „ 成功执行为最高风险开发的应急计划 „ 输入 „ 风险行动表 „ 控制活动 „ 风险控制活动应利用标准的项目管理过程使启 动、监视和评估能沿着计划好的行动路线进展 „ 输出 „ 输出是标准的项目状态报告,它记录了应急计 划逐步完成的进展情况 从风险中学习 从风险 中学习 项目计划和进度 小组经验 风险 行动 表格 新风险 修改后的风险 分类 应急计划 缓解计划 风险 主列表 风险 状态 报告 风险知识库 风险政策 和指南 风险政策和指 南变更的建议 从风险中学习(2) „ 捕获风险学习 „ 风险分类记录学习的两个关键方面是:新风险;成 功的缓解策略 „ 管理从风险中学习 „ 在特定的风险分类域必须有专人负责 „ 风险分类应平衡两个方面的需求:风险覆盖的全面 性和复杂性及可用性。 „ 需要建立一个风险知识库来维护风险分类,定义, 诊断准则,评分系统,以及捕获使用它们的小组经 验反馈 „ 需要很好的管理风险审核过程,确保捕获所有的学 习经验。 从风险中学习(3) „ 上下文相关的风险分类 „ 对于特殊的、一再重复的项目上下文,要通过开发风 险分类来求精风险标识 „ 风险知识库 „ 在管理风险知识中提高成熟度 „ 最低层,没有知识库,在实施风险管理时从零开始。 „ 第二级将采用非形式的知识库 „ 第一级是为风险标识提供了一个更加结构化的方法。 如何描述和评估软件 架构质量 议题 „ 软件的质量建模 „ 评估软件架构质量的价值 „ 怎样改变软件架构的质量 „ 如何评价软件架构 „ 评估软件构架师的能力 软件的质量建模 „ 软件架构质量模型 „ 技术架构 „ 管理架构 „ 支撑架构 „ 业务架构 软件架构质量模型 隐喻 „ 软件质量的重要性是不言而喻的,但是当 所有人都意识到它的重要性的时候,却很 少有人能够清晰的描述出如何才能够提高 软件质量。 „ 软件质量框架的目的就在于提出一个评价 的原型,帮助我们分析一种方法和技术是 否能够提高软件质量。 什么才是一个高质量的软件? „ 满足用户的需求。这是最重要的一点,一 个软件如果不能够满足用户的需要,设计 的再好,采用的技术再先进,也没有任何 的意义。所以这一点非常的朴实,但却是 软件质量的第一个评判标准。 „ 合理进度、成本、功能关系。软件开发中所有的 管理都是围绕着这几个要素在做文章的,如何在 特定的时间内,以特定的成本,开发出特定功能 的软件。三者之间存在一种微妙的平衡。在 Planning „ 一个高质量的软件的开发过程中,项目成员一定 能够客观的对待这三个因素,并通过有效的计 划、管理、控制,使得三者之间达成一种平衡, 保证产出的最大化。 „ 具备扩展性和灵活性,能够适应一定程度 的需求变化。当今的社会已经变成一种变 化速度极快的设计了。变化就会对软件产 生冲击,所以一个质量优秀的软件,应该 能够在一定程度上适应这种变化,并保持 软件的稳定。 „ 能够有效的处理例外的情况。写过软件的 人都知道,实现主体功能的工作量其实不 大,真正的工作量都在处理各种例外。所 以,一个软件如果能够足够的强壮、足够 的鲁棒,能够承受各种的非法情况的冲 击,这个软件就是高质量的。 „ 保持成本和性能的平衡。性能往往来源于 客户的非功能需求,是软件质量的一个重 要的评价因素。但是性能问题在任何地方 都存在,所以需要客观的看待它。例如, 一段性能不错的代码可能可读性很差,这 就需要进行平衡,如果这段代码的性能是 整个软件的关键,那么取高性能而舍弃可 读性,反之则取可读性而舍弃高性能。一 个优秀的软件能够保持成本和性能之间的 平衡。 „ 能够可持续的发展。很少有软件组织只开 发一个软件的,所以,一个优秀的软件在 开发完成后,可以形成知识沉淀,为软件 组织的长期发展贡献力量。这是一个优秀 的软件应该要能够做到的。 软件质量框架的组成 „ 第一部分是前提,说明了软件框架的适用范围,以及适合 的环境,和方法学一样,没有泛之四海皆准的方法学,所 以软件质量框架也需要一个上下文环境。 „ 第二部分是价值观,价值观说明了软件质量框架中强调的 价值,在软件框架的结构和实践中,都将充分的的表现出 一开始我们定义的价值。 „ 第三部分是结构。结构定义了软件质量框架的组成部分, 以及软件质量框架和开发过程之间的关系。第四部分是文 章中着墨最多的部分,即优秀实践。 „ 优秀实践通过具体、实际的分析、举例,深入阐述了软件 质量框架的价值观和结构。 软件质量框架的前提 „ 平台前提:由于软件质量框架的实践将会涉及具体的技术 和代码,所以我们首先为软件质量框架定义了平台。软件 质量框架将会运行在J2EE平台上,使用对象分析技术(并 不一定是面向对象技术,我们可以采用以数据为中心的技 术)。 „ 组织前提:执行软件质量框架需要投入,需要付出,软件 质量框架最难的地方不是学习,而是执行。在一个组织 中,需要评估应用软件质量框架需要多少的投入,对目前 的开发过程有多大的助益。一般来说,组织的规模越大、 其开发过程和产品越复杂,就越适合采用软件质量框架。 „ 方法学前提:在敏捷方法学中,对规则和秩序有两种不同 的观点,一种是强调规则和秩序,以XP为代表,它对代码 都有要求;另一种则不那么强调,以自适应软件开发为代 表,它不要求程序员的具体行为。软件质量框架采用第一 种观点,要求组织中存在严谨的规则和秩序。 软件质量框架的价值观 „ 明确具体:对软件的管理必须是明确具体的。软件开发是 工程、也是艺术,需要紧密的协作和沟通,任何一个含糊 的指令都可能导致软件开发中出现错误,所以,在软件开 发中,任何一个指令都应该是相对明确的。为什么说是相 对呢?是和成本相对,指令越明确,成本就越高。例如, 你可以把需求文档写的非常的具体,但是你需要付出制作 和维护的代价。所以我们的明确性是一个考虑成本前提下 的特性。 „ 明确具体要从综合上考量。怎么理解呢?例如,XP中的用 户故事是非常不精确的,按道理说它是不明确,也是不具 体的。但是在整个开发周期中,将会有迭代、测试、现场 用户等多种手段使得用户故事明确具体起来,所以从整体 上看,它并不违反我们的价值观。产品质量是一个系统工 程,决不仅仅是QA部门的工作,。这个道理适用于制造 业,也适用于软件开发业。 „ 容错:软件开发是人的工作,人是无法避免错误 的。所以,软件质量框架中允许犯错。因为不犯 错是天方夜谭。你就算做了这方面的强制规定也 无法避免它的出现,反而会引发其它的问题,例 如隐瞒错误,或为了隐瞒错误而导致的额外成 本。所以正确的态度是允许发生错误,并建立一 套监测、管理、反馈、修改错误的体制。 „ 规范:在前提中,我们已经提到了,规范 是软件质量框架的基本态度。所以,软件 质量框架中强调规范,并使用规范来推动 框架的运作。 „ 测试:软件质量框架非常强调测试,测试 是保证质量的必由之路。测试要尽可能的 多,尽可能的频繁、测试结果要尽可能快 的反馈。这是软件质量框架对测试的基本 态度。测试是综合性的,软件开发过程中 的所有工件,都需要伴随着相应的测试工 件。这是基于一个简单的理念,如果你不 能够为你的工作制定一个完成的标准,你 又该如何开展你的工作呢? 软件质量框架的结构 „ 处于结构核心的是技术架构和管理架构。软件质量框架既 不是方法学,也不是一个软件,更像是两者的结合体。技 术架构和管理架构的融合体现了这一特性。软件质量框架 并不关心单个开发人员的效率,它关注的是开发团队整体 的效率。 „ 因此,管理架构在框架中的意义在于它定义了一套软件管 理的方法,能够对开发人员及其他们的工作进行管理。从 这一点来看,它的作用和软件工程方法学是一样的。但 是,在现实中我们发现软件组织在迈向软件过程的途中往 往因为现实的困难而止步不前。其中一个主要的原因是在 引入方法学的过程中生产效率降低了,而引起组织成员对 变革的怀疑和不满。 „ 软件质量框架还提供了一个技术架构,其 目的是明确的定义如何应用组织中涉及的 软件技术,以及管理软件技术的方法。技 术架构是具体的代码,相比起方法学来 说,它更加的具体,更容易为开发人员所 理解。而技术架构存在的目的,一方面是 进行技术积累,另一方面也是为管理架构 服务。 „ 技术架构和管理架构的下一层是支撑框 架。支撑框架包括代码、组件、文档,目 的是为技术架构和管理架构提供底层的支 持。 „ 处于结构最顶层的是业务架构。这个部分 对于任何一个软件组织来说都是不同的, 因为不同的软件组织的业务不同。业务架 构的目的是对业务进行建模和抽象,提取 出可重用的部分,以提高软件组织的生产 率。本文中不涉及该部分的内容。 软件质量框架的优秀实践 „ 一个开发团队要提高效率,就需要思考目前的管理活动中 有哪些要素是可以改进的:如何把一些事务性的操作变得 自动化,从而节约人力;如何找到更好的方法,让开发过 程更为合理,更注重软件的质量;如何在团队中传播优秀 的思想,让团队成员不断的学习和进取,自发的改进过 程。这些美好的愿望几乎是所有方法论和各种认证的共同 心声,但要完全做到可就太难了。 „ 优秀实践均是来源于软件开发界中的一些新思路和新理 论,它们能够为以上愿望的达成起到正面的作用。在组织 中引入用这些实践决不是一个容易的过程,但它们确实非 常的有效。不论是在成本控制上,还是在质量的改进上。 „ 日创建:一个组织应当拥有一个有效的工 作流程,这个工作流程能够指导软件开发 的进行。这个流程应当是具体的、可操作 的。随意的计划和从来不遵循的进度决不 是一个有效的工作流程。日创建实践提出 了一种对开发过程进行精细管理的方法, 它是量化软件管理的基础。有了日创建, 你会发现计划的制定和进度的监控是非常 容易的一件事情。 „ 测试驱动开发:软件质量的根源来源于测 试,测试做好了,软件质量就会好。这是 毫无疑问的。问题的关键在于怎么做测 试,才能保证测试的投入能够带来软件质 量的有效提升。测试驱动开发正是为了解 决这个问题而出现的。它不是一个完整的 方法论,可以和任何一种开发流程进行融 合。测试驱动开发不但能够改善测试效 果,还能够改进软件的设计。 „ 建立核心框架:框架是一种具有高度重用性的软 件,这个特性决定了它非常适合成为软件组织积 累知识的一种有效手段。传统的知识积累的方法 是文档,但是文档容易产生歧异,开发人员往往 也不愿意去阅读和理解文档。框架提供的是一种 综合的手段,包括文档、模型和代码。更容易理 解,更重要的是,开发人员必须在日常的工作中 使用框架,这使得他们对框架中的知识非常的熟 悉,并根据工作的需要来改进框架。 „ 面向组件编程:有效的组织在于有效的分工。体 力活动容易进行分工,脑力劳动则比较难,而软 件开发似乎就更难了。所以,长久以来我们都习 惯采用以功能块为单位的粗粒度划分方式。面向 组件编程采用更加细密的划分方式,并以服务作 为组件之间相互依赖的契约,不但定义了组件和 组件之间的关系,也规定了组件开发者、组件使 用者、组件测试者的权利和义务。从而能够进行 软件开发工作的分配、管理、QA等工作。 „ 从软件结构的角度来看,日创建和测试驱动开发 似乎偏向于管理架构,而建立核心框架和面向组 件编程则偏向于技术架构。事实上,他们既包含 了技术架构,也包含管理架构,彼此之间也有相 互关联。 „ 例如,面向组件编程在合理划分组件之后,就需 要一个有效的核心框架来集成组件,通过每个组 件都需要采用测试驱动开发方法来保证质量,同 时,日创建将会以组件为单位来进行每日的创 建,从而为进度估算提供有效数据。 „ 未来的一种可能性是UML2.0和MDA技术的 普及,以上的几个实践从以代码为核心转 变为以设计为核心,而另一种可能性是随 着以AspectJ为代表的AOP技术的普及和 J2SE1.5中引入的元数据机制,面向组件编 程将把Aspect作为组件的一种,而测试驱动 开发也会加入测试Aspect的相关内容,在日 创建中也会增加相应的处理AOP的步骤。 软件架构评估 高质量架构设计的障碍 „ 1、对软件开发过程中架构设计的重要性没有认 识。 „ 2、对软件架构师的角色缺乏理解。 „ 3、宽泛地认为设计是艺术形式的活动,而不是技 术活动。 „ 4、对设计的过程缺少理解。 „ 5、在开发组织中缺少设计经验。 „ 6、缺少软件架构设计的方法学和相应工具。 „ 7、不知道如何评估设计。 „ 8、在‘利益相关者’之间缺乏有效的沟通。 典型的评估方法 „ 1、Scenario-based Architecture Analysis Method (SAAM). „ 基于场景的架构分析方法。 „ 2、Architecture Trade-off Analysis Method (ATAM) „ 架构权衡分析评估方法 „ 3、SAAM Founded on Complex Scenarios (SAAMCS). „ 4、Extending SAAM by Integration in the Domain (ESAAMI). „ 5、Software Architecture Analysis Method for Evolution and „ Reusability (SAAMER). „ 6、Scenario-Based Architecture Reengineering (SBAR). „ 7、Architecture Level Prediction of Software Maintenance (ALPSM). „ 8、Software Architecture Evaluation Model (SAEM). „ 9、Cost Benefit Analysis Method (CBAM) Architecture Trade-off Analysis Method (ATAM) „ 架构权衡分析评估方法 „ 1、评估参与者 „ 1) 评估组独立于项目组,3-5人,中立,每个人 都有能力进行架构设计。 „ 2) 项目决策者项目负责人,架构师,客户代表 等构成 „ 3) 构架利益相关者开发人员,测试人员,维护 人员,用户等构成12人-15人。 Architecture Trade-off Analysis Method (ATAM) „ 2、角色表 要提出架构利益相关者没有想到的问题。提问者8 协助评估组长执行评估的步骤,方法。执行者7 记录并建议评估组如何改进评估。观察员6 协助评估组按既定的时间进行各个场景,步骤地评 估。 计时员5 会议本身的记录,整理并分发会议记录。会议记录员4 协助绘画,书写场景,捕捉场景的结论。场景记录员3 执行评估,推动基于场景的评估。选择并控制不同 的评估场景。推动评估分析活动。 评估组长[主持]2 构建评估组,协调,监督评估的报告的生成和交 付。 项目组长1 职责角色序号 „ 3、步骤及输出 Cost Benefit Analysis Method (CBAM) „ 1) 消耗和效益的上下文 „ 2) 步骤 评估软件构架师 的能力 角色和分工 „ 参与应用建模的人员主要分成两类角色: 系统构架师和设计师。 系统架构师职责(1) „ 系统构架师负责领导和协调整个项目中的技术活动。 „ 在个人综合素养方面,系统构架师应该具有领导才能,能 够在压力下作出关键性的决策并善始善终; „ 能够赢得项目经理、客户、用户群体以及管理团队的认同 和尊敬,尤其要善于和项目经理紧密协作; „ 在各个方面都能展现出面向目标的实干作风。在专业技能 方面,与其他角色相比,系统构架师通常具有全方位的技 能,其见解重在广度,而不是深度。 系统架构师职责(2) „ 系统构架师不仅需要具备设计师的各项技能,而 且应该具有问题领域和软件工程领域的实践经 验,从而有能力在无法获得完整信息的情况下迅 速领会问题并根据经验作出审慎的判断。 „ 如果项目较大,系统构架师将是一个团队,上述 的关键素质要求可由团队成员来分担,但其中要 有一名系统构架师具有足够的权威。 设计师职责 „ 设计师的工作对象通常是系统的局部或者细节。 设计师应该掌握的技能包括: „ 理解以Use Case建模技术捕获和描述的软件需求; „ 在系统构架师的统一协调下,应用UML进行局部的面 向对象分析和设计; „ 了解主流的实施技术(程序设计语言和开发环境)。 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 设计模式与软件架构设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 (1)面向对象软件架构设计思想 (2)使用UML进行软件架构设计 (3)设计模式的本质论 (4)设计模式与架构模式 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 面向对象本质论 —面向对象范式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 议题 z 功能分解模式分析 z 功能分解模式如何适应需求的变化 z 责任转移模式处理需求的变化 z 面向对象范式 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 问题的描述 z 编写代码访问存储在数据库中的几何形状的描 述,再把得到的几何形状显示出来。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 解决问题步骤 z 在数据库中查找几何形状的列表; z 打开形状列表; z 以某种规则将这个列表排序; z 在显示器上显示单个的几何形状; • 识别形状的具体类型 • 获得形状的位置 • 调用适当的函数,并传递形状的位置给它,来显示这 个形状 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 功能分解 z 分析者将问题拆分成多个功能步骤,这些步骤组合起来就 可以解决实际的问题。 z 把问题分解成小块来解决,比一次处理整个问题要简单。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 功能分解带来的问题 z 它不能帮助我们为未来可能发生的变化作准备。 z 它不能把帮助我们的代码优雅的演变。 z 变化的发生还为错误和意外结果的发生创造了机会-许多 错误都来自于代码的变化。 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 模块化方式处理变化 z 模块化可以帮助你写出更容易理解的代码,更 容易理解的代码也更容易维护; z 模块化并不能帮助你写出能应付所有可能出现 的变化代码 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 内聚和耦合 z 内聚度:是指程序中的操作之间联系紧密的程度。描述了 一个子程序的内部成分之间相互联系的强度。 z 耦合度:是指两个子程序联系的强度。描述了一个子程序 与其他子程序之间的联系强度。 z 耦合度与内聚度成反比。 z 目标:蒋建具有内部完整性(强内聚)的子程序,以及小 的、直接的、可见的、灵活的与其他子程序之间的联系( 松耦合) 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 责任转移模式处理需求变化 z 实际问题的描述:TechED2005大会上,我主讲了Report Builder,当参加会议的听众听完我的演讲后,需要到其他的 分会场去参加其他的技术演讲,我的一种做法是: • 获得参加会议的听众的人名单; • 对于名单上的每个人: • 查找他的下一技术演讲的题目; • 查找他的下一参会的地点; • 查找到他下一分会场的路径; • 告诉他怎样去下一个地点。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 不同实现方案 z 为了实现上述的过程,可能需要: • 获得本会场上人的名单的方法。 • 获得每个人的日程安排表的方法。 • 一个程序来告诉某个人如何从我的分会场到达另外一个分会场。 • 一个控制程序来为每一个人做需要的步骤。 z 另外实现的方案: • 把从本会场到其他会场的路径张贴出来 • 告诉所有的参会者按照张贴的路径到下一个分会场。 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 揭示问题的本质 z 第一种方法,对每个人都指明确地指出路径,必须注意许多细节 ,除了你之外的任何人对任何事情都没有责任。 z 用第二种方法,你给出了一个普遍的指令,并期望每个人都能自 己知道如何完成你给出的任务。 z 对比:第一种方案中你对所有事情负责,而第二种方案参会者对 他们自己的行为负责;组织方式的巨大差异。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 软件开发过程的视角 z 概念(conceptual) • 展示了问题领域中的概念; • 一个概念模型可以在对实现软件有很少或毫无注意的情况下勾勒出来。 z 规格(Specification) • 我们只看软件的接口,而不看软件的实现。 z 实现(implementation) • 置身于代码当中,使常规视角 z 目标: • 一个层次(概念层次)上通信而在另一个层次(实现层次)上执行; • 请求者不知道发生了什么,只知道概念上发生了什么。 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 面向对象范式 z 面向对象范式的核心是“对象”的概念 z 所有的东西都聚焦于对象 z 围绕对象-而非函数-组织代码 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 对象从不同视角观察 z 概念层:一个对象是一系列责任 z 规格层:一个对象是一系列可以被其他对象或 该对象自己调用的方法 z 实现层:一个对象是一些代码和数据 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 面向对象本质论 —设计原则 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 面向对象的设计目标 z 可维护性 z 可复用性 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 可维护性 z 现在存在的问题 • 过于僵硬 • 过于脆弱 • 复用率低 • 黏度过高 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 可维护性 z 设计的目标 • 可扩展性(Extensibility) • 新的功能可以很容易地加入到系统中 • 灵活性(Flexibility) • 允许代码修改平稳地发生,而不会涉及到许多其它模块 • 可插入性(Plug ability) • 可以很容易地将一个类抽出去,同时将一个可以很容易地将一个 类抽出去,同时将一个有同样接口的类加入进来。 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 可复用性 z 重要性 • 较高的生产效率 • 较高的软件质量 • 恰当使用复用可以改善系统的可维护性 z 传统的复用 • 代码的剪贴使用 • 算法的复用 • 数据结构的复用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 设计原则 z “开闭”原则(OCP) z 里氏代换原则(LSP) z 依赖倒转原则(DIP) z 接口隔离原则(ISP) z 组合/聚合复用原则 (CARP) z 迪米特法则(LoD) 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 “开闭”原则(OCP) z Open-Closed Principle (OCP) z 定义 • Software entities should be open for extension, but closed for modification. • 一个软件实体应当对扩展开放,对修改关闭 z “抽象化”是OCP的关键 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 z 解释 “臣启陛下臣启陛下……降一道招安圣旨……与它籍名在 箓……一则不动众劳师,二则收仙有道也”(《西游记》) 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 “开闭”原则(OCP) z 对可变性的封装原则 z Principle of Encapsulation of Variation (EVP) • 找一个可变的因素把它封装起来 • 一种可变性不应当散落到代码的很多角落里,而应当 被封装在一个对象里 • 一种可变性不应当与另一种可变性混合在一起 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 里氏代换原则(LSP) z Liskov Substitution Principle (LSP) z 定义 • 如果对某一类型为T1的对象o1,都有类型为T2的对象 o2,使得以T1定义的所有程序P在所有的对象o1都代 换成o2时,程序P的行为没有变化,那么类型T2是类 型T1的子类型 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 里氏代换原则(LSP) z 解释 •“白马,马也;乘白马,乘马也。骊马,马也;乘骊 马,乘马也。”(《墨子·小取》) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 里氏代换原则(LSP) z 解释 •“娣,美人也,爱娣,非爱美人也…”(《墨子·小取》) 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 依赖倒转原则(DIP) z Dependency Inversion Principle (DIP) z 要依赖于抽象,不要依赖于具体 • 抽象层次包含的是应用系统的商务逻辑和宏观的、对整 个系统来说重要的战略性的决定,是必然性的体现 • 具体层次则含有一些次要的,与实现相关的算法和逻辑 以及战术性的决定,带有相当大的偶然性 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 依赖倒转原则(DIP) z 表述 • Abstractions should not depend upon details. Details should depend upon abstractions.(抽象不应当依赖细 节,细节应当依赖抽象) • Program to an interface, not a implementation.(要针 对接口编程,而不要针对实现编程) 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 接口隔离原则(ISP) z Interface Segregation Principle (ISP) z 从一个客户角度来讲,一个类对另一个类的依赖 性应当建立在最小的接口上 z 原则 • 角色分割 • 定制服务 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 合成/聚合复用原则(CARP) z Composition/Aggregation Reuse Principle (CARP) z 定义 • 在一个新的对象里面使用一些已有的对象,使之成为新对象的一部 分,新的对象通过向这些对象的委派达到复用已有功能的目的 z 尽量使用合成/聚合,而不是继承 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 类图中的关系 z 一般化(Generalization)关系 z 表示类与类之间的继承关系,接口与接口之间的继承关系, 类对接口的实现关系 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 34 类图中的关系 z 关联(Association) 关系 • 表示类与类之间的联接,它使一个类知道另一个类的属性和方法 • 关联可以是单向的,也可以是双向的 18 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 35 类图中的关系 z 聚合(Aggregation)关系 • 是关联的一种,是强的关联关系,是整体与个体的关系。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 36 类图中的关系 z 合成(Composition)关系 • 是关联关系的一种,是比聚合关系强的关联。它要求普通的聚 合关系中代表整体的对象负责代表个体的对象的生命周期。合 成关系不能共享。 19 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 37 类图中的关系 z 依赖(Dependency)关系 • 是类与类之间的连接,依赖总是单向的。依赖表示一个类依赖 于另一个类的定义。 • 通常被依赖的对象以方法的参数或返回表示。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 38 迪米特法则(LoD) z Law of Demeter (LoD) 又称为最少知识原则 • Least Knowledge Principle (LKP) z 表述 • only talk to your immediate friends“只与你直接的朋友们通信” • Don’t talk to strangers “不要与陌生人讲话 ” • 每一个软件单位对其他的单位都只有最少的知识,而且局限于那 些与本单位密切相关的软件单位 20 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 39 迪米特法则(LoD) z 狭义迪米特法则 • 如果两个类不必彼此直接通信,那么这两个类就不应当发生直 接的相互作用。如果其中一个类需要调用另一个类的某一方法 的话,可以通过第三者转发这个调用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 40 迪米特法则(LoD) z “朋友”的确定 • 当前对象本身(this) • 以参量形式传入到当前对象方法中的对象 • 当前对象的实例变量直接引用的对象 • 当前对象的实例变量如果是一个聚集,那么聚集中的元 素也都是“朋友” • 当前对象所创建的对象 21 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 41 迪米特法则(LoD) z 狭义迪米特法则 • 与依赖倒转原则的互补使用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 42 迪米特法则(LoD) z 广义迪米特法则 • 封装(信息隐藏) • 模块将它所有的实现细节隐藏起来,彻底地将提供给 外界的API和自己的实现分割开来。 • 模块与模块间仅通过彼此的API相互通信,而不会理会 模块内部的工件细节。 22 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 43 迪米特法则(LoD) z 广义迪米特法则 • 控制信息过载 • 在类的划分上,应当创建弱耦合的类。类之间的耦合越弱,就越 有利于复用 • 在类的结构设计上,每一个类都应当尽量降低成员的访问权限 (Accessibility) • 在类的设计上,只要有可能,一个类应当设计成不变类 (Immutable) • 在对其它类的引用上,一个对象对其实例的引用应当降到最低 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 44 ICONIX 流程 23 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 45 最小UML建模技术 z 对于大多数问题而言,只需使用20%的UML, 就可以完成80%的建模工作。 z 实际中,好像总是没有足够的时间来完成建模 、分析和设计工作,总是过早地进入到编码阶 段。 z 足以很好地完成软件项目工作所需的、最小的 UML和建模技术子集。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 46 ICONIX主要元素 24 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 47 如何从用例到代码? ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 48 工作起点 z 假设: • 一些原型化的工作已经完成; • 确定了用户界面 • 已经开始确定系统的一些场景和用例 z 面向对象系统中 • 代码的结构是由类定义的。 • 编写代码前,必须知道所需的软件类是什么样的。 25 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 49 类图规定了代码的结构 z 获得一组非常详细的、设计级的(Design-level)类图。 z 设计级是指一种详细程度,这种级别的类图可以用作系统实际代码 的模板,准确地指出如何组织代码。 z 面向对象软件开发中,最困难的工作之一是分配行为,这需要就每 个要建立的软件函数做出决策。 z 对于每个函数必须决定将其放在那个类中。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 50 时序图将操作分配给类 z 时序图帮助你做出行为分配决策的理想工具。 z 需要根据用例获得时序图 z 如何跨越模糊用例与详细程度类似代码的时序图之间的 鸿沟? 26 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 51 健壮性图在需求与详细设计之间架起了 一座桥梁 z 使用健壮性图来填充模糊、朦胧的用例与非常详细、精确的时序图 之间鸿沟。 z 时序图的最上面是:特定场景涉及的一组对象 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 52 设计模式的本质论 27 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 53 什么是模式? z 在《在软件开发中理解和使用模式》一文中给出了这样 一个定义:模式是从解决具体问题抽象出来的,这种具 体问题在特定的上下文中重复出现。也就是说,每个具 体形式都对一种重复的问题采用重复的解决方案。 z 然而,模式不仅仅是解决方案,正是因为很多人认为设 计模式仅仅是解决方案,所以才导致设计模式的滥用和 设计过度。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 54 模式不是解决方案 z 模式不是解决方案,而是在某种环境中权衡各方面利弊 的一种方案的选择,这种选择是这些利弊平衡的结果, 获得好处的同时需要付出代价,并且结果中有有利的方 面,也有不利的方面。 28 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 55 什么是模式? z 在模式中,问题出现在一种特定的上下文(context)(或称 为“语境”),并且包含各种互相竞争的关切(forces)。目标 解决方案包括对这些关切的平衡,这种关切在模式中称 为“作用力”,这些作用力互相牵制。因此,模式不能简 单地看做是“特定场景的解决方案”,下面的定义更符合 模式的内在含义。 z 模式是被命名的有组织的信息,它捕获了在一定语境(场 景)中包含相关作用力的问题的解决方案的本质结构和内 在含义,这种解决方案被证明是成功的。 z 模式包含3个部分:相关的上下文、与上下文相关的作 用力系统和解决问题的方案。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 56 理解设计模式的结果和代价 z 在GOF的设计模式中充分讨论了模式的使用结 果,既有好的方面,也有不好的方面,即使用 模式是有代价的。 29 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 57 (1)对象过多 z 设计模式的精髓之一是将可变部分封装为对象,带来的好处是系统 更加灵活,易于维护,但也大量增加了对象。如果不恰当地使用设 计模式,会使系统难以调试。下面几个模式比较有代表性。 z (1)命令模式:将行为封装为对象,这样原来一个对象中的若干方法 变成了若干命令对象。如果将命令模式应用在一个GUI用户界面上 ,每一个菜单项就要生成一个命令对象,原来由一个对象完成的工 作现在可能需要十几个对象来完成。 z (2)状态模式:将不同的状态封装为对象,原来可能是通过判断语句 完成的工作分散到各个对象中完成。由于状态是动态决定的,因此 在设计测试用例时有难度。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 58 (2)更复杂的装配关系 z 很多设计模式依赖对象之间的关系,因此在初 始化时需要执行相应的装配工作,需要装配对 象的模式有如下几种。 •(1)生成器模式:需要装配生成器和导航器。 •(2)桥接模式:需要将代表逻辑的对象和代表实现的 对象进行装配。 •(3)观察者模式:需要将不同的观察者对象关联在一 起。 •(4)职责链模式:需要组装整条职责链。 30 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 59 (3)测试难度加大 z 这是前面两个结果导致的,由于对象的增多和对象间关 系的复杂,因此测试用例的设计难度增大。特别是很多 逻辑上的错误可能由装配关系不当造成,并且在编译时 很难发现。 z 解决测试难度大的方法是将测试用例文档化,即绘制测 试用例的对象图。这个话题超出了本书的范围,有兴趣 的读者可参考相关书籍。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 60 (4)程序结构复杂 z 设计模式关注的是如何使软件更具可维护性,因此从结 构上已经与原始的需求完全不同。加上很多功能是通过 对象的动态组合实现的,程序的动态结构变得与静态结 构同样重要。 z 从单纯的静态结构(例如类图)已经很难理解实现的方式 和最终的意图了,这也是经常是使用设计模式的代价之 一。 31 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 61 设计模式不能做什么 z 设计模式不是法则 z 不能提高开发速度或者形象开发速度 z 不是万能的 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 62 (1)设计模式不是法则 z 模式理论的精髓之一就是模式的使用是有前提和代价的 ,模式是在某种前提下,综合各方面因素后考虑得出的 结果。即在使用模式时总是要付出一定的代价,当然这 种代价是可以接受的。如果某个模式在所有场合中的使 用都是必然的,那么它就不能叫做模式了,而是一种必 须遵守的法则。例如“面向接口,而非实现编程”,是法 则而非模式。 32 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 63 (2)不能提高开发速度或者形象开发速度 z 如果以一个开发周期作为考核标准,恐怕没有人会使用 设计模式。设计模式并不能提高目前的开发速度,至少 其关注的目标并不是开发速度。很多情况下甚至会降低 开发速度,即使是正确地选择了设计模式。 z 这是因为设计模式可能会引入更多的对象和更复杂的对 象装配关系,从而使得程序有更多的动态状态,从局部 看来变得结构复杂,难以理解并且测试困难。如果仅仅 关注于形象进度,或者能够百分之百地确定需求没有变 化,那么设计模式并不是很好的选择。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 64 (3)不是万能的 z 设计模式的使用是自然而然的事情,很多情况下不使用 设计模式是因为不需要,问题还没有复杂到非用不可的 程度。我们是为了设计而使用设计模式,而不是为了使 用设计模式而设计。 z 当你的项目发现有如下问题之一时,就需要考虑重构代 码,可能会有某种模式适合。 •(1)代码无法进行单元测试。 •(2)需求的变动总是导致代码的变动。 •(3)有重复代码存在。 •(4)继承层次过多。 •(5)隐藏的依赖过多。 33 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 65 设计模式与架构模式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 66 软件顶层架构的设计 方法 结合实际需求,选取架构模式,再进行局部调整。 主要架构模式 z 流程处理模式 z 客户/服务器模式、 z 模型—视图—控制器模式 z 分层模式 34 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 67 软件顶层架构的设计 (1)流程处理模式。 z 流程处理系统以算法和数据结构为中心,其系 统功能由一系列的处理步骤构成,相邻处理步 骤用数据流通管道连接。 z 流程处理模式适用于批处理方式的软件系统, 不适合交互式系统。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 68 流程处理模式 z 流程处理模式具有三个 处理步骤。 z 步骤都使用公共的系统 服务(例如数据库访问 服务),命令处理和命 令处理的进度、结果都 通过用户界面。 35 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 69 客户/服务器模式 (2)客户/服务器模式。 客户端负责用户输入和处 理结果的呈现,服务端 负责后台业务处理。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 70 模型—视图—控制器(MVC)模式 (3)模型—视图—控制器模式 软件系统由模型、视图和控制 器三部分组成。 模型负责维护并保存具有持久 性的业务数据,实现业务处理功能, 并将业务数据的变化情况及时通知视 图。 视图负责呈现模型中包含的业 务数据,响应模型变化通知,更新呈 现形式,向控制器传递用户的界面动 作。 控制器负责将用户的界面动作 映射为模型中的业务处理功能并实际 调用之,然后根据模型返回的业务处 理结果选择新的视图。 MVC模式特别适合于 分布式应用软件, 尤其是Web应用系统 36 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 71 分层模式 (4)分层模式 z 将整个软件系统分为若干层次,最顶层直接面 向用户提供软件系统的操作界面,其余各层为 紧邻其上的层次提供服务。 z 分层模式可以有效降低软件系统的耦合度,应 用普遍。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 72 分层模式 层次划分的主要原则 z 易变化的部分,如用户界面、 与业务逻辑紧密相关的部件, 置于高层 z 稳定部分,如公共的技术服务 部件,置于低层; z 每层都尽量访问紧邻的下层, 避免越级访问,尤其要避免逆 向访问即,上层模块为下层模 块提供服务; z 将目标软件系统的外部接口置 入较低层次,系统其余部分对 外部系统的访问或操作通过这 些外部接口提供的服务来完成 。 37 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 73 软件架构 z 在全面了解软件架构样式的前提下,对于具体 的应用需求而言,影响顶层架构选取的主要因 素在于分析人员的经验以及他们对每种架构样 式与当前软件项目之间匹配程度的判断。 z 大型软件的顶层架构往往需要使用多种架构样 式。如,整个目标软件系统采用分层结构,在 系统的不同层次内再分别使用适宜的其他类型 的架构模式。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 74 确立软件架构考虑的因素 (1)架构中包的数量 包中软件元素过多,应对包进一步细分;如果 过少,则说明架构过早地陷入细节。 (2)架构中包之间的耦合度 包的依赖关系、连接关系应尽量简单、松散, 如,在分层结构中,通常要求某一层的软件元素 只与同层及下一层的元素存在依赖关系。 (3)软件元素的稳定性 抽取不稳定的软件元素的相对稳定部分,将不 稳定的软件元素分类聚集在少数几个包中,以提 高软件系统的可维护性。 38 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 75 确立软件架构 (4)软件元素的分类 将软件可选功能和必须实现功能的软件元素分 别置于架构的不同包或子包中。 (5)作为软件系统运行环境的物理网络拓朴 根据软件元素在分布环境中的布局,划分顶 层架构的包,使包的消息传递与物理节点的通 信相协调,顶层架构定义的通信关系支持后续 的分析和设计活动。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 76 确立软件架构 (6)软件元素的安全、保密级别。 根据安全访问的权限划分顶层架构中的包或者 子包。 (7)开发团队的技术专长。 根据开发人员在问题和技术领域的专长划分顶 层架构,使得每个包的开发都能充分发挥开发人 员和团队的技术专长 (8)调整软件架构,支持并行开发。 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 AOP开发实践 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 z AOP概述 z 使用AOP实现松散耦合 z 使用AOP组合两个业务逻辑 z 对象代理和过滤器 z 结论 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 什么是AOP? z AOP是Aspect Oriented Programming的简写, 中文通常译作面向方面编程,其核心内容就是 所谓的“横切关注点”。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 OO都是纵向结构的 z 使用面向对象方法构建软件系统,我们可以利 用OO的特性,很好的解决纵向的问题,因为, OO的核心概念,如继承等,都是纵向结构的。 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 AOP的目标 z 但是,在软件系统中,往往有很多模块,或者很多类共享某个行 为,或者说,某个行为存在于软件的各个部分中,这个行为可以 看作是“横向”存在于软件之中,他所关注的是软件的各个部分的 一些共有的行为,而且,在很多情况下,这种行为不属于业务逻 辑的一部分。 z 例如,操作日志的记录,这种操作并不是业务逻辑调用的必须部 分,但是,我们却往往不得在代码中显式进行调用,并承担由此 带来的后果(例如,当日志记录的接口发生变化时,不得不对调 用代码进行修改)。 z 这种问题,使用传统的OO方法是很难解决的。AOP的目标,便 是要将这些“横切关注点”与业务逻辑代码相分离,从而得到更好 的软件结构以及性能、稳定性等方面的好处。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 关注点切割图 软件模块 软件模块 软件模块 软件模块 业 务 逻 辑 业 务 逻 辑 业 务 逻 辑 业 务 逻 辑 操作日志 安全检测 事务处理 纵向关注点 横切关注点 软件的纵向和横向结构 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 AOP的自动耦合 z AOP,给我们的软件设计带来了一个新的视角 和软件架构方法。使用AOP,我们可以专注于 业务逻辑代码的编写,而将诸如日志记录、安 全检测等系统功能交由AOP框架,在运行时刻 自动耦合进来。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 使用AOP技术的情景 z 通常,我们可以在如下情景中使用AOP技术: • Authentication 权限 • Caching 缓存 • Context passing 内容传递 • Error handling 错误处理 • Lazy loading 懒加载 • Debugging 调试 • logging, tracing, profiling and monitoring(记录跟踪,优化,校准) • Performance optimization 性能优化 • Persistence 持久化 • Resource pooling 资源池 • Synchronization 同步 • Transactions 事务 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 议题 z AOP概述 z 使用AOP实现松散耦合 z 使用AOP组合两个业务逻辑 z 对象代理和过滤器 z 结论 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 Websharp Aspect z 我们选用一个开放源代码的Web sharp Aspect框架。这 个框架是基于Microsoft. Net平台的,并且是使用C#语言 开发的,所以,下面的示例代码使用了C#相关的语法。 z 关于这个框架的说明以及源代码,可以从下面地址下载 www.websharp.org 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 z 对于应用软件系统来说,权限控制是一个常见的例子。为了得到好 的程序结构,通常使用OO的方法,将权限校验过程封装在一个类 中,这个类包含了一个校验权限的代码,例如: public class Security { public bool CheckRight(User currentUser , Model accessModel , OperationType operation) { ……//校验权限 } } ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 z 然后,在业务逻辑过程中进行如下调用: public class BusinessClass { public void BusinessMethod() { Security s = new Security(); if (!s. CheckRight(……)) { return ; } ……//执行业务逻辑 } } 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 OO设计的问题 z 这种做法在OO设计中,是常见的做法。但是这种做法会带来以下的问题: • 不清晰的业务逻辑:从某种意义上来说,权限校验过程并不是业务逻辑执行 的一部分,这个工作是属于系统的,但是,在这种情况下,我们不得不把系 统的权限校验过程和业务逻辑执行过程掺杂在一起,造成代码的混乱。 • 代码浪费:使用这种方法,我们必须所有的业务逻辑代码中用Security类,使 得同样校验的代码充斥在整个软件中,显然不是很好的现象。 • 紧耦合:使用这种方法,我们必须在业务逻辑代码中显式引用Security类,这 就造成了业务逻辑代码同Security类的紧耦合,这意味着,当Security发生变 化时,例如,当系统进化时,需要对CheckRight的方法进行改动时,可能会 影响到所有引用代码。下面所有的问题都是因此而来。 • 不易扩展:在这里,我们只是在业务逻辑中添加了权限校验,哪一天,当我 们需要添加额外的功能,例如日志记录功能的时候,我们不得不同样在所有 的业务逻辑代码中添加这个功能。 • 不灵活:有的时候,由于某些特定的需要,我们需要暂时禁止,或者添加某 项功能,采用传统的如上述的做法,我们不得不采用修改源代码的方式来实 现。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 z 为了解决这些问题,我们通常会采用诸如设计模式等方 式,对上面的方案进行改进,这往往需要很高的技巧。 利用AOP,我们可以很方便的解决上述问题。 z 我们以Websharp Aspect为例,看看如何来对上面的代 码进行改动,以获得一个更好的系统结构。 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 z 首先,Security并不需要做任何修改。 z 然后,我们对BusinessClass做一个小小的改动: • 为BusinessClass添加一个名为AspectManaged的Attribute,并使得 BusinessClass继承AspectObject,然后,删除代码中对Security的 调用,这样,我们的代码就变成了如下的样子: [AspectManaged(true)] public class BusinessClass : AspectObject { public void BusinessMethod() { ……//执行业务逻辑 } } ……//执行业务逻辑 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 z 然后,我们为系统增加一个SecurityAspect。 public class SecurityAspect : IAspect { public void Execute(object[] paramList) { if(!Security.CheckRight(......)) { throw new SecurityException("你没有权限!"); } } } 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 z 最后,我们在系统配置文件中添加必要的信息: ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 z 我们就完成了代码的重构。当BusinessClass被调用的时候, AOP框架会自动拦截BusinessClass的BusinessMethod方法,并 调用相应的权限校验方法。 z 采用这种方式,我们在BusinessClass中没有显式引用Security类 及其相应方法,并且,在所有业务逻辑代码中,都没有必要引用 Security类。 z 这样,借助AOP机制,我们就实现了BusinessClass和Security 类的松散耦合,上面列出的所有问题都迎刃而解了。同时,这也 是一种易于扩展的机制,例如,当我们需要添加日志记录功能的 时候,只需要添加相应的Aspect类,然后在配置文件中进行配置 即可,而无需对业务逻辑代码进行任何改动。 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 议题 z AOP概述 z 使用AOP实现松散耦合 z 使用AOP组合两个业务逻辑 z 对象代理和过滤器 z 结论 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 使用AOP组合两个业务逻辑 z 使用AOP,我们不仅仅可以用来分离系统功能和业务逻 辑,就象上面我们做的那样,也可以用来耦合不同的业 务逻辑,得到更加灵活的软件结构。下面,我们通过一 个具体的案例,来看看怎么通过AOP,组合两个业务逻 辑过程。 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 我们假设有如下一个场景 z 我们设计了一个ERP系统,其中,库存管理系统需要同 财务系统相交互,例如,当某个库存商品报废的时候, 需要有相应的财务处理过程。因此,我们通常需要在库 存商品报废的业务逻辑中引用相关的财务处理逻辑。这 必然会造成两个部分的耦合。当然,为了使两个部分尽 量耦合程度降低,我们通常会使用Façade等设计模式来 进行解耦。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 z 由于某些原因,我们需要将库存管理系统单独出售,这就 需要我们需要从库存商品报废的业务逻辑中将引用的相关 的财务处理逻辑去除,这意味着我们需要修改原有的代码 。 z 为了解决这个问题,即可以随时将财务处理逻辑添加或者 从库存商品报废的业务逻辑中删除,我们可以采用一些方 法,例如,设置一些开关参数,在库存商品报废的业务逻 辑中,根据这些开关参数的值,来判断是否需要执行财务 处理逻辑。 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 z 问题是,这仍旧不是理想的解决方案。采用这种方式,你 必须事先知道所有需要设置的开关参数,并且,在业务逻 辑代码中添加相应的判断。 z 当为系统增加一个类似的需要灵活处理的部分时,开发人 员不得不添加相应的参数,并且修改相应的代码(添加相 应的判断代码)。 z 修改代码总是不好的事情,因为按照软件工程的要求,当 有新的需求是,尽量不要修改原来的代码,而是新增相应 的代码。但是,在这种情况下,你做不到。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 z 使用AOP,我们可以通过一种更加自然的方式来实现这个 目标。基本方法如下: • 首先,编写相关的库存商品报废业务逻辑,不需要添加任何其他 的内容,并且,把这个逻辑的代码设置为可AOP的。 • 其次,按照正常的方式,编写财务处理逻辑。 • 添加一个把库存商品报废业务逻辑和财务处理逻辑组合起来的 Aspect,这个Aspect可以拦截库存商品报废业务逻辑的执行,动 态的加入财务处理逻辑的过程,并且,在配置文件中进行配置。 • 这样,我们就通过一个Aspect,组合了这两个业务逻辑。并且, 我们随时可以通过修改配置文件的方式把财务处理从库存商品报 废业务逻辑中去除,而不用修改任何代码。 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 z 从上面的例子可以看出,采用AOP的好处是,我们可以 独立的编写各个业务逻辑,使得系统各个部分之间的耦 合度降到最低,然后,可以在系统中根据需要随时组合 两个逻辑,而不用修改原来的任何代码。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 议题 z AOP概述 z 使用AOP实现松散耦合 z 使用AOP组合两个业务逻辑 z 对象代理和过滤器 z 结论 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 对象代理和过滤器 z 应该认识到,完全的AOP实现,需要开发语言的支持。因 为对于AOP的研究,还正在进行之中,目前的开发语言, 都还没有完全支持AOP的,但是,我们可以利用现有的一 些语言功能,来实现AOP的部分功能。 z 上面所举的例子,在实现上,是利用了对象代理(Proxy)机 制。所谓Proxy,就是“为其他对象提供一种代理以控制对 这个对象的访问” ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 z 在WebsharpAspect中,当一个对象被标记为 AspectManaged后,这个类的实例的创建过程,以及方 法的调用会被WebsharpAspect控制。因此,当你在调 用如下语句: BusinessClass bc = new BusinessClass(); 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 z 你得到的实际上并不是BusinessClass类的一个实例, 而是他的一个代理(关于其中的实现机理,可以参见相 关的源代码)。 z 因此,当调用这个“实例”的方法的时候,所有的调用都 会被代理所捕获,代理会在实际的方法调用之前,透明 的执行一些预定义的操作,然后再执行实际的方法,最 后,在实际的方法调用之后,再执行一些预定义的操作 。这样,就实现了AOP的功能。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 z 注意,AOP并不仅仅等同于方法调用拦截,当然,这也是 最常用的和非常有效的AOP功能。 z 在某些开发中,我们可能使用过滤器来完成某些AOP功能 。例如,当用户访问某些资源时,我们可以对访问信息进 行一些过滤处理。一个常见的场景是,在JSP开发中,为了 实现对中文的正确处理,我们通常需要对浏览器同服务器 之间传递的数据进行转码处理,以获得正确的文字编码。 在每个Request中手工进行转码肯定不是一个好的解决方案 。 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 z 一个比较好的例子,是为应用程序编写一个Filter,自动进行转码处 理。例如,我们可以为TOMCAT写如下一个过滤器来实现转码: public class SetCharacterEncodingFilter implements Filter { public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain) throws IOException, ServletException { request.setCharacterEncoding(“gb2312”); chain.doFilter(request, response); } } ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 z 这样,我们就不必在具体业务处理中来进行手工的转码 。实现业务逻辑同转码这样的系统功能的分离。 z 目前,常见的Web服务器都提供类似的机制。例如,在 IIS中,也可以使用过滤器功能。传统的开发方式是使用 VC开发一个ISAPI Filter。在.Net发布后,可以使用 HttpHandler和HttpModule实现相同的功能,但是,开发 难度要低很多。 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 z 使用过滤器的另外一个场景,可以是权限控制。例如,在客户请求某个 Web页面的时候(这个Web页面通常同某个业务功能相关联),可以使用 过滤器截获这个请求,然后,判断这个用户是否具备对请求资源的访问 权限。如果是,那么,过滤器可以把这个请求放过去,什么都不做,否 则,过滤器可以重定向到某个页面,告诉用户不能访问的原因,或者, 直接抛出异常,交由前面的处理者处理。通过这种方式,我们可以同样 的分离诸如身份验证这样的系统功能和业务逻辑,实现更好的系统结构 。 z 通过象Web服务器这样的应用程序环境提供的功能,我们还可以实现其 他一些AOP的功能,构建更好的系统框架。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 34 议题 z AOP概述 z 使用AOP实现松散耦合 z 使用AOP组合两个业务逻辑 z 对象代理和过滤器 z 结论 18 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 35 结论 z AOP给了我们一个新的视角来看待软件的架构,有的时 候,即使不使用AOP技术,只使用AOP的某些观念和现 有的技术来搭建系统架构,分离某些本来是紧耦合的关 注点,对我们也是非常有益的。 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 软件架构 通用的服务模式 yangxiufeng@263.net ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 z 类工厂服务 z 缓存服务(内存服务) z 配置服务 z 异常处理服务 z 日志服务 z 加密服务 z 验证服务和授权服务 z 消息队列 z 部署服务 z 事务处理服务 z 帮助服务 z 数据验证服务 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 类工厂服务 z 基础架构平台构建 z 反射机制实现可插拔模型 z 不同软件架构平台实现机制 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 缓存服务 z 理解Caching的概念 z Caching解决了哪些问题 • Performance • Scalability • Availability z Caching是必须在设计时考虑的问题 • 理解.NET Framework和Windows操作系统提供的缓冲 技术 • 考虑面对的环境 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 z 理解状态—状态指的是在某个特定时刻,系统的数 据的状况 • 状态的生命周期 • 永久状态:在一个应用里永久有效的数据 • 进程状态:状态仅在进程范围内有效 • 会话状态:在一个特定用户的会话期间有效 • 消息状态:在一个消息的处理期间有效 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 z 状态的范围 • 物理范围:状态可被访问的物理的位置,例如: • 组织:状态可以被一个组织之内的任何应用所访问 • 应用服务器集群:状态可以被应用服务集群中的任何服务器所访问 • 机器:状态可以被一台服务器上的所有应用所访问 • 进程:状态可以被单个进程的多个AppDomain所访问(*) • AppDomain:状态仅在一个AppDomain之内可访问(*) • 逻辑范围: • Application:状态在某一个特定的应用内有效 • Business process:状态在一个逻辑上的业务流程中有效 •Role:状态在应用中的某个用户子集中有效 • User:状态仅对单个用户有效 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 z 状态的失效程度(staleness) • 失效程度就是我们缓冲的状态和原始数据之间的差别 程度 • 两方面影响: • 变化的可能性 • 变化的相关性 • 不同的状态的失效程度系统具有不同的容忍度 z 状态转变的过程 • 分析转变过程,帮助我们决定缓冲的数据形式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 z 为什么数据需要被缓冲 • 减少跨进程的通信 • 减少对数据库的访问 • 减少磁盘操作 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 Caching in the Business Services Layer z Caching in Service Interfaces z Caching in Business Workflows z Caching in Business Components z Caching in Business Entities ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 Caching in Business Entities z 模式一 Business Component Business Entities CacheActivity Custom Objects 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 Caching in Business Entities z 模式二 Business Component Business Entities Data CacheActivity Objects,XML, Datasets,Xml Nodes,etc. Business Entities Business Entities Factory Finds Invokes ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 Caching in the Data Services Layer z Caching in Data Access Components • 非交易的查询返回的原始数据 • Typed dataset schemas z Caching in Data Access Helpers • 配置信息 • 存储过程的参数 z Caching in Service Agents 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 Caching in the Data Services Layer z Caching in Service Agents Service Agents Service Application Business Logic Cache ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 Caching in the Security Aspects Data Presentation Business Authentication Authorization Secure Comm. Auditing Profile Mgmt Security Operational Mgmt Communication 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 Caching in the Operational Management Aspects Data Presentation Business Exception mgmt Monitoring Biz Monitoring Metadata Configuration Operational Mgmt Security Communication Service Location ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 配置服务 z 软件配置方式 z XML与软件配置 z 灵活设计软件配置文档 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 z 为应用系统提供了公用的配置管理解决方案,允许应用程序方便灵活地从不同 配置存储读写配置信息 z 隔离应用程序和配置数据的物理存储位置 • Storage Providers: 允许从不同的物理存储读写信息(如SQL/XML) • Transformers:将读取的配置数据经转换器转换为结构化数据 z 内置对XML的支持 z 改善安全性 (支持加密保存) z 配置文件监控器能够监测到配置文件的变化并发出事件通知 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 异常处理服务 z 设计异常处理机制 z 异常处理与XML 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 z 异常处理程序块为系统的不同层面提供了一致的例外处理策略 z 异常由配置工具进行定义和维护 – 不需要通过编码控制例外处理 z 定义 “异常策略”,可指定该策略发生时的行为 • 将异常写入日志 • 用另外一个异常进行封装 • 采用不同的异常替代以便隐藏敏感的异常信息 • 创建自己的Handler ,提供附加的处理行为 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 日志服务 z 日志实现机制 z 日志存储机制 z 日志设计 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 z 提供简单标准一致的Logging机制 z 能灵活指定哪类信息以何种格式输出、输出到 何处 • 实现了应用程序代码与日志策略的隔离 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 加密服务 z 加密服务方式 z 加密服务的工厂模式 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 z 简化了开发人员为敏感信息进行加解密工作 • 加解密任何类型(Stream/Byte)的信息 • 提高易用性(CreateHash / CompareHash) z 支持多种加解密算法 • 支持所有.NET提供的加密算法(*) • 通过DPAPI,对单台计算机上的信息进行无密钥加密 • 允许集成自己开发的加解密算法Provider z 提高集成性 • 算法与密钥可以通过配置工具进行配置 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 验证服务与授权服务 z 验证服务与单点登陆机制 z 树型权限与矩阵权限设计 z 复杂权限设计思想 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 消息队列 z 系统可靠性 z IBM MQ & MSMQ ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 部署服务 z 部署策略 z 部署设计 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 事务处理服务 z 本地事务与分布式事务 z 非数据性事务 z 事务补偿 z 事务设计策略 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 帮助服务 z 帮助文档 z 帮助层设计 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 数据验证服务 z 应用程序入口点 z 数据验证服务设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 面向方面的软件开发方法 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 需求开发的主要困难与对策 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 AgendaAgenda • 面向对象开发技术与开发范型变迁 • 横切关注点 • 横切关注点的建模与分离 • 弹性体系结构演变 • AOSD的应用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 软件开发范型的变迁软件开发范型的变迁 • Code-Fix模型 --最原始的开发方式 程序越来越大,难以掌握—软件危机 • 结构化开发:SA、SD、SP --自顶向下,逐层分解 数据与方法分离,内聚性不够—与现实世界模型不一致 • 面向对象开发:OOA、OOD、OOP –现实世界真实反映 • 其它:数据流理论 1970 1980 1990 结构化方法 数据流方法 面向对象 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 面向对象开发技术的核心特点面向对象开发技术的核心特点 • 结构化理论:将应用分解为功能模块、子功能模块、功 能接口;与现实问题域的东西没有直接联系! • 面向对象理论:系统模型是对问题域的直接映射,即从 现实世界中直接抽象出一个模型,然后在计算机中实现 出来。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 面向对象开发技术的历史变迁面向对象开发技术的历史变迁 面向对象程序设计 面向对象设计 面向对象分析 面向对象程序语言 19801960 1970 1990 Lisp Simula67 SmallTalk72 SmallTalk80 C Objective-C C++ Java 1970年 1990年 年 • 面向对象编程开启了面向对象 发展之门。 • 而面向对象分析、设计方法才 是OO思想的真正标志。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 面向对象开发技术的今天面向对象开发技术的今天——核心基础核心基础 • 核心基础:组件技术、UML建模技术 • 组件技术:大型项目与系统的必由之路 Æ需要支持多平台:SOA、ESB—连接组件 Æ拥有大量组件:重用、MDA—快速、廉价集成组件 Æ响应日益复杂的业务操作:EA(连通软件与业务的鸿沟)、PLE (处理产品线可变性)、反向工程(重用遗留系统) Æ框架:J2EE、.NET等 • 独立与厂商的组件描述语言--UML ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 • 显然仅有组件和UML是不够的,因为我们还需要知道 如何捕获组件!--答案就是最佳实践: Æ迭代开发 Æ体系结构为中心 Æ用例驱动 面向对象开发技术的今天面向对象开发技术的今天——最佳实践最佳实践 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 最佳实践最佳实践11——迭代开发迭代开发 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 最佳实践最佳实践22——用例驱动用例驱动 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 最佳实践最佳实践33——体系结构为中心体系结构为中心 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 AgendaAgenda • 面向对象开发技术与开发范型变迁 • 横切关注点 • 横切关注点的建模与分离 • 弹性体系结构演变 • AOSD的应用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 横切关注点横切关注点11——扩展扩展 • 嗯,一切似乎很完美。是什么打破了这一宁静? • 横切关注点是打乱这一规则的“破坏分子”! • 横切关注点包括两类: Æ扩展:在基组件之上定义的组件,它用来表示附加的服务或功能 非功能属性 --AOP原先的发现 Æ对等关注点:相互独立的功能点,各组件中参与类有较大的交叠 缠绕与分散 --Ivar博士的补充发现 弥补用例分析与实现的鸿沟 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 横切关注点横切关注点11——扩展扩展 • AOP就是基于对非功能属性实现中发现的“重复”。 • 例如:留存、事务处理、安全、 性能优化、错误处理、日志、 调试、度量等。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 横切关注点横切关注点22——对等关注点对等关注点 • 各个组件包含满足不同关注点的实现—缠绕状态 • 某个特定的关注点的实现分散在多个组件中—分散状态 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 横切关注点现行实行的不足横切关注点现行实行的不足 • 横切关注点1—扩展 Æ代码的大量重复,涉及到多个功能性类 Æ当横切关注点的需求发生变化时,会造成大量修改 Æ横切关注点的更新难以实现一致性 • 横切关注点2—对等功能点 Æ捕获对等功能点的用例本身就涉及了多个类,容易使分析与设计 的结果不能够有效地对应起来,影响了跟踪 Æ功能的修改,可能涉及多 个类,从而影响系统的弹性 Æ原有的用例建模在管理横 切关注点时存在问题 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 面向方面技术面向方面技术 • 本质:合成机制,分离横切关注点的方法 Æ可以实现将类之外的附加行为合并到类本身 Æ可以在编译时或运行时进行 Æ可以将不同的关注点的实现分离到不同模块中 • 核心概念 Æaspect:核心类元,模块化单元 Æintertype:aspect的方法,定义为“原有类名.新操作名”--类扩展 Æpointcut:在aspect中说明原有类中的扩展点(连接点) --操作扩展 Æadvice:捕获pointcut出现的特定事件 --操作扩展 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 AgendaAgenda • 面向对象开发技术与开发范型变迁 • 横切关注点 • 横切关注点的建模与分离 • 弹性体系结构演变 • AOSD的应用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 基于用例对横切关注点建模基于用例对横切关注点建模 • 用例是对横切关注点建模的最好工具 • 用例描述的关键是事件流 • 用例扩展: 预订房间的 执行点 扩展点 更新房间可用性 =基本事件流步骤5 扩展事件流 房间等候队列 pointcut ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 基于用例对横切关注点建模基于用例对横切关注点建模 • 用例包含: • 用例泛化: ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 基于用例捕获横切关注点基于用例捕获横切关注点 • 应用(application)用例和基础结构(infrastructure)用例 • 理解涉众关注点 Æ理解问题域(领域类,领域模型) Æ抽取系统特性(Feature List) Æ处理功能和非功能需求(应用用例、基础结构用例) • 捕获应用用例 Æ从特性中识别出参与者,合并为用例 Æ识别用例变量,并处理用例变量 Æ处理扩展用例 • 捕获基础结构用例 Æ抽象为<执行事务>用例对基本事务进行建模 Æ基础结构用例的结构化、描述基础结构用例 Æ处理系统范围的关注点 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 用例切片用例切片 • 用例的实现是协作 : • 协作标识了类及类的扩展 • 用例切片包括:协作 (交互图、类图)、特定的类、特定的扩展 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 基于用例切片实现分离基于用例切片实现分离 • 合并特定于某用例的类 : • 合并用例特定的类扩展: ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 基于用例切片组成系统基于用例切片组成系统 • 通过用例切片(use case slice)和非特定用例切片(non-uc-specific slice)来叠加出系统: ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 用例模块用例模块 • 对于某个用例而言,都包括不同的模型(用例描述、分析、设计、 实现、测试设计、测试实现),每个模型都可以组成一个切片,而 将这些切片放在一个单独的包中,就称为用例模块 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 AgendaAgenda • 面向对象开发技术与开发范型变迁 • 横切关注点 • 横切关注点的建模与分离 • 弹性体系结构演变 • AOSD的应用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 架构(架构(ArchitectureArchitecture)) • 什么是架构(体系结构)? Æ系统元素如何组织? Æ系统如何实现所需功能? Æ系统如何满足预期性能、可靠性和其它质量特性 Æ系统需要什么技术? Æ系统内部组织的结构是否能够弹性响应功能、技术、平台变化? Æ标准是否能够确保系统开发始终保持一致?采用什么设计模式? • 什么是好的架构 Æ分离功能需求 Æ从功能需求中分离出非功能需求 Æ分离平台特性 Æ将测试从已测单元中分离出来 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 架构基线架构基线 • 架构基线:最终系统的早期版本,Skinny System! Æ包含了最终系统所具有的子系统、组件和节点的骨架 ÆUP过程中,这一任务主要是在精化阶段完成 • 用例驱动架构基线:寻找出关键用例子集 Æ演练了系统的关键功能和特性 Æ涵盖了大部分的功能性、基础结构、平台特性等方面的风险 Æ突出了系统中的一些具有高复杂度或高风险性的部分 Æ是系统剩余系统的基础 • 迭代地建立架构基线 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 平台无关的结构(平台无关的结构(PIMPIM)) • 元素结构:基于包和类的分层结构 Æ组成部分主要是领域相关的类 Æ通常包括“应用层”和“领域层” Æ应用层的元素主要实现用中支持系统的主要参与者的工作流 Æ领域层则要包括了描述重要领域概念的元素 • 用例结构:在元素结构的基础上添加了实际的内容 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 叠加平台相关特性(叠加平台相关特性(PSMPSM)) • 选择平台 Æ系统的平台特性基于架构师选定的部署结构和进程结构 Æ我们需要将平台特性与平台无关的部分分离—最小化用例设计 • 最小化用例设计(minimal use-case design) Æ可执行,并采用默认编程语言实现 Æ是通过程序接口来激活的 Æ分布性、内部进程的通信和平台相关消息通信都与其分离 Æ所需的信息都在内存中 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 使功能需求保持分离使功能需求保持分离 11 • 分离功能需求的最好办法是用例(应用用例) Æ什么是特定于某用例的、什么是独立于用例的,什么是特定于某应用的、什么是 应用通用的 ,什么是领域通用的、什么是领域特定的。 Æ这些问题的答案用于指导:如何将类归入到层、包,如果将类扩展归入到相应的 切片、模型中 • 应用用例的分析 Æ考虑用例规约,必要时进行更新 Æ分析用例:识别出参与用例实现的分析类,并将行为分配给这些类 Æ在系统元素结构中将类组织成为层和包,在用例结构中将类和类扩展组织成切片 Æ将分析元素映射为设计元素、识别出接口及附加的设计元素 • 使功能需求在分析模型中保持独立 Æ根据类参与实现的用例,形成合适的元素结构 Æ将用例结构分为:针对某个特定用例行为的“用例切片”,不属于特定的某个用例 的“非用例特定切片” ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 使功能需求保持分离使功能需求保持分离 22 • 应用用例设计 Æ识别设计元素:从分析模型中标识设计元素,根据实现需要引入新的设计元素 Æ识别组件和接口:将分析为中的一部分演化为设计组件 Æ完善设计元素 • 使功能需求在设计模型中保持独立 Æ使类扩展保持分离:ReserveRoom类需要updateAvailability()和retrieveDetails() 两个方法。前者是“预订房间”特用,后者是公用。其处理方法有四种: 现行选择 编程困难 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 使功能需求保持分离使功能需求保持分离 33 • 使功能需求在设计模型中保持独立 Æ使操作扩展保持独立 1)总和:两个用例切片需要从相同操作得到不同的输出,并且操作的职责是提 供两种输出的合并 2)选择:当用例切片需要从同一个操作得到不同的输出,并且要求组合结果只 有一种输出 操作扩展声明包括 1)结构上下文:说明哪个操作是要增加的 2)行为上下文:说明扩展何时执行 3)说明附加行为 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 34 使扩展的功能需求保持分离使扩展的功能需求保持分离 11 • 面向方面技术能够使我们更好地在原有系统上进行扩展 Æ该扩展流程应该在pointcut UpdatingRoomAvailability返回没有空闲房时 Æ系统建立一个针对选定房间类型的带唯一标识符的待处理订单,然后将其放到等 候列表中,再将此唯一标识符返回给客户,用例结束。 • 识别类: ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 35 使扩展的功能需求保持分离使扩展的功能需求保持分离 22 • 识别Pointcut,并将用例行为分配给类 Æ标识结构上下文:确定在何处运行这些操作扩展来调用扩展用例 Æ标识行为上下文:定义职责中的何处需要调用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 36 使扩展的功能需求保持分离使扩展的功能需求保持分离 33 • 因此,得到了一个独立的用例切片完成该扩展用例 处理等候列表 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 37 使非功能需求保持分离使非功能需求保持分离 11 • 分离非功能需求最有效的工具是基础结构应用 Æ识别类 Æ标识Pointcut Æ将用例行为分配给类 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 38 使非功能需求保持分离使非功能需求保持分离 22 • 使基础结构用例保持分离 Æ细化元素结构 Æ在用例切片中使基础结构保持分离 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 39 使平台特性保持分离使平台特性保持分离 最小设计视角 合并了平台特性 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 40 AgendaAgenda • 面向对象开发技术与开发范型变迁 • 横切关注点 • 横切关注点的建模与分离 • 弹性体系结构演变 • AOSD的应用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 41 保持关注点分离带来的生产率提高保持关注点分离带来的生产率提高 • 假设某系统有N个独立的需求,假设每个的工作量需X,则总工作 量就是NX • 若N个需求未良好分离,就意味着每个需求的实现与其它需求的实 现相互交迭,最坏时可能是每个需求的实现与N-1个需求相关,如 果交迭部分的开发量是Y,则任务量就成了NX+N(N-1)Y • 假设N=20,X=20,Y=1,良好分离时工作量为400,未良好分离时 显然就是780,接近一倍。 • 随着Y值的增加,未良好分离的 体系结构就会带来越大的成本。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 42 从何处入手从何处入手 • 用例建模与分析:对涉众关注点捕获的正确性和精确性是十分重要 的。用例建模与分析适用于任何软件开发,不管是面向方面、面向 对象还是其它的。建议针对基础结构服务编写用例。建议多练习, 编写出客户和开发团队都易于理解的有效用例。 • 设计和实现:用例切片、用例结构、AOP都比较新,需要学习如 何对aspect和用例切片进行建模,如何描述Pointcut。建议选择一 个适用该方法解决的特定关注点。通过用例来描述它,并从此驱动 到编码、测试的全过程。 • 测试:基于用例切片,可以很轻松地 将测试引入的控制和工具代码轻松地 去除。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 43 在项目的不同阶段采用在项目的不同阶段采用 • 计划阶段:很容易着手,从需求开始,从头贯穿AOSD; • 细化阶段前期:已经完成了一部分迭代,有一些可以工作的用例和 几个基础结构服务,则可以在没有开发的部分上应用用例切片,对 已开发的基础结构服务可以考虑重新设计用例切片是否有价值; • 细化阶段后期:如果已有一个可靠的架构,基本上不建议做修订和 改变。但可以考虑用参数化pointcut来帮助你把基础结构服务和平 台特性融合到系统中。还可以使用AspectJ来判断层和包之间是否 存在依赖注入。 • 构建阶段:如果项目接近尾声,不必有太大改变,可以考虑会该方 法进行测试。 • 完善阶段:可以用来对原系统更好的进行扩展。 基于SOA架构设计 „ 服务的设计与原则 „ 面向服务架构的消息模式 „ 评估基于服务的集成技术的过程和准则 „ 服务模式与反模式 „ Web服务的体系结构 „ 改善web服务的协同工作能力 应用软件开发方法的演变过程 „ 应用软件开发方法的演变过 程: „ 面向过程; „ 面向对象; „ 面向组件; „ 面向服务。 „ 一个组件模型 „ 将应用程序的不同功能单元(服 务)通过这些服务之间定义良好 的接口和契约联系起来。接口是 采用中立的方式进行定义的,它 应该独立于实现服务的硬件平 台、操作系统和编程语言。 „ 构建在各种这样的系统中的服务 可以以一种统一和通用的方式进 行交互。 什么是面向服务的体系架构? 服务的设计与原则 service-oriented Architecture „ SOA(service-oriented Architecture,也叫面向服务的体系 结构或面向服务架构)是指为了解决在Internet环境下业 务集成的需要,通过连接能完成特定任务的独立功能实体 实现的一种软件系统架构。 „ SOA是一个组件模型,它将应用程序的不同功能单元(称 为服务)通过这些服务之间定义良好的接口和契约联系起 来。接口是采用中立的方式进行定义的,它应该独立于实 现服务的硬件平台、操作系统和编程语言。这使得构建在 各种这样的系统中的服务可以以一种统一和通用的方式进 行交互。 „ 传统的Web(HTML/HTTP)技术有效的解决了人与信息系 统的交互和沟通问题,极大的促进了B2C模式的发展。 „ WEB服务(XML/SOAP/WSDL)技术则是要有效的解决信息 系统之间的交互和沟通问题,促进B2B/EAI/CB2C的发 展。 „ SOA(面向服务的体系)则是采用面向服务的商业建模技术 和WEB服务技术,实现系统之间的松耦合,实现系统之间 的整合与协同。WEB服务和SOA的本质思路在于使得信息 系统个体在能够沟通的基础上形成协同工作。 „ 对于面向同步和异步应用的,基于请求/响应模式的分布 式计算来说,SOA是一场革命。一个应用程序的业务逻辑 (Business Logic)或某些单独的功能被模块化并作为服 务呈现给消费者或客户端。这些服务的关键是他们的松耦 合特性。 „ 例如,服务的接口和实现相独立。应用开发人员或者系统 集成者可以通过组合一个或多个服务来构建应用,而无须 理解服务的底层实现。举例来说,一个服务可以用。NET 或J2EE来实现,而使用该服务的应用程序可以在不同的平 台之上,使用的语言也可以不同。 SOA具有的特性(2-1) „ SOA服务具有平台独立的自我描述XML文档。Web 服务描述语言(WSDL, Web Services Description Language)是用于描述服务的标准语 言。 „ SOA 服务用消息进行通信,该消息通常使用XML Schema来定义(也叫做XSD, XML Schema Definition)。消费者和提供者或消费者和服务之 间的通信多见于不知道提供者的环境中。服务间 的通讯也可以看作企业内部处理的关键商业文 档。 SOA具有的特性(2-2) „ 在一个企业内部,SOA服务通过一个扮演目录列 表(Directory listing)角色的登记处(Registry) 来进行维护。应用程序在登记处(Registry)寻找 并调用某项服务。统一描述,定义和集成 (UDDI, Universal Description, Definition, and Integration)是服务登记的标准。 „ 每项SOA服务都有一个与之相关的服务品质 (QOS, quality of service)。QoS的一些关键元 素有安全需求(例如认证和授权),可靠通信 (译注:可靠消息是指,确保消息“仅且仅仅”发 送一次,从而过滤重复信息。),以及谁能调用 服务的策略。 SOA三大基本特征(1) „ 独立的功能实体 „ 在Internet这样松散的使用环境中,任何访问请求都有可能出错, 因此任何企图通过Internet进行控制的结构都会面临严重的稳定性 问题。SOA非常强调架构中提供服务的功能实体的完全独立自主 的能力。传统的组件技术,如.NET Remoting,EJB,COM或者 CORBA,都需要有一个宿主(Host或者Server)来存放和管理这些功 能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这 样当宿主本身或者其它功能部分出现问题的时候,在该宿主上运 行的其它应用服务就会受到影响。 „ SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行 自我恢复的技术,比如事务处理(Transaction),消息队列(Message Queue),冗余部署(Redundant Deployment)和集群系统(Cluster)在 SOA中都起到至关重要的作用。 „ 大数据量低频率访问 „ 对于.NET Remoting,EJB或者XML-RPC这些传 统的分布式计算模型而言,他们的服务提供都 是通过函数调用的方式进行的,一个功能的完 成往往需要通过客户端和服务器来回很多次函 数调用才能完成。在Intranet的环境下,这些调 用给系统的响应速度和稳定性带来的影响都可 以忽略不计,但是在Internet环境下这些因素往 往是决定整个系统是否能正常工作的一个关键 决定因素。因此SOA系统推荐采用大数据量的 方式一次性进行信息交换。 „ 基于文本的消息传递 „ 由于Internet中大量异构系统的存在决定了SOA系统必须采用基于 文本而非二进制的消息传递方式。在COM、CORBA这些传统的组 件模型中,从服务器端传往客户端的是一个二进制编码的对象, 在客户端通过调用这个对象的方法来完成某些功能;但是在 Internet环境下,不同语言,不同平台对数据、甚至是一些基本数 据类型定义不同,给不同的服务之间传递对象带来的很大困难。 由于基于文本的消息本身是不包含任何处理逻辑和数据类型的, 因此服务间只传递文本,对数据的处理依赖于接收端的方式可以 帮忙绕过兼容性这个的大泥坑。 „ 此外,对于一个服务来说,Internet与局域网最大的一个 区别就是在Internet上的版本管理极其困难,传统软件采 用的升级方式在这种松散的分布式环境中几乎无法进行。 采用基于文本的消息传递方式,数据处理端可以只选择性 的处理自己理解的那部分数据,而忽略其它的数据,从而 得到的非常理想的兼容性。 向服务架构(SOA)的原则 „ SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架 构抽象出来,将其功能以粗粒度的服务形式表示出来,每种服务都清 晰地表示其业务价值,那么,这些服务的顾客(可能在公司内部,也 可能是公司的某个业务伙伴)就可以得到这些服务,而不必考虑其后 台实现的具体技术。更进一步,如果顾客能够发现并绑定可用的服 务,那么在这些服务背后的IT系统能够提供更大的灵活性。 „ 但是,要得到种强大和灵活性,需要有一种实现架构的新方法,这是 一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计 师”,不仅要理解SOA,还要理解SOA的实践。在架构实践和最后得到 的架构结果之间的区别非常微妙,也非常关键。本文将讨论SOA的实 践,即:面向架构的设计师在构建SOA时必须要做的事情。 SOA的原则 „ SOA是一种企业架构,因此,它是从企业的需求 开始的。但是,SOA和其它企业架构方法的不同 之处在于SOA提供的业务敏捷性。业务敏捷性是 指企业对变更快速和有效地进行响应、并且利用 变更来得到竞争优势的能力。 „ 对架构设计师来说,创建一个业务敏捷的架构意 味着创建这样一个IT架构,它可以满足当前还未 知的业务需求。 „ 要满足这种业务敏捷性,SOA的实践必须 遵循以下原则(1): „ 业务驱动服务,服务驱动技术 „ 从本质上说,在抽象层次上,服务位于业务和技术 中间。面向服务的架构设计师一方面必须理解在业 务需求和可以提供的服务之间的动态关系,另一方 面,同样要理解服务与提供这些服务的底层技术之 间的关系。 „ 要满足这种业务敏捷性,SOA的实践必须遵 循以下原则(2): „ 业务敏捷是基本的业务需求 „ SOA考虑的是下一个抽象层次:提供响应变化需求 的能力是新的“元需求”,而不是处理一些业务上的 固定不变的需求。从硬件系统而上的整个架构都必 须满足业务敏捷的需求,因为,在SOA中任何的瓶 颈都会影响到整个IT环境的灵活性。 „ 要满足这种业务敏捷性,SOA的实践必须遵 循以下原则(3): „ 一个成功的SOA总在变化之中 „ SOA工作的场景,更象是一个活的生物体,而不是 象传统所说的“盖一栋房子”。IT环境唯一不变的就是 变化,因此面向服务架构设计师的工作永远不会结 束。对于习惯于盖房子的设计师来说,要转向设计 一个活的生物体要求崭新的思维方式。如下文所写 的,SOA的基础还是一些类似的架构准则。 SOA基础 „ 在IT行业有两个越来越普遍的发展方向,一个是架构方面 的,一个是方法学方面的,面向服务的架构设计师可以从 中有所收获。第一个就是MDA(模型驱动架构),由提出 CORBA的OMG模型提出。MDA认为架构设计师首先要对待 创建的系统有一个形式化的UML(也是由OMG提出)的模 型。MDA首先给出一个平台无关的模型来表示系统的功能 需求和Use Cases,根据系统搭建的平台,架构设计师可 以由这个平台无关的模型得到平台相关的模型,这些平台 相关模型足够详细,以至于可以用来直接生成需要的代 码。 SOA基础 „ MDA的核心就在于在设计阶段系统就已经完全描述,这 样,在创建系统的时候,几乎就没有错误解释的可能,模 型也就可以直接生成代码。但MDA有一些局限性:首先, MDA假设在创建模型之前,业务需求已经全部描述,而这 一点,在当前典型的动态业务环境中几乎是不可能的。第 二,MDA没有一个反馈机制。如果开发人员对模型有需要 改动的地方,并没有提供给他们这么一个途径。 SOA基础 „ SOA的另一个基础是敏捷方法(AM),其中非常有名的方 法是极限编程(XP)。象XP这样的AM提供了在需求未知 或者多变的环境中创建软件系统的过程。XP要求在开发团 队中要有一个用户代表,他帮助书写测试来指导开发人员 的日常工作。开发团队中的所有成员都参与到设计之中, 并且设计要尽量小并且非形式化。AM的目标是仅仅创建 用户想要的,而不是在一些形式化模型上耗费工作量。 AM的核心思想就在于其敏捷性-处理需求变更的敏捷 性。AM的主要弱点是其规模上的限制,例如,XP在一个 小团队和中型项目中效果不错,但是当项目规模增大时, 如果没有一个一致的清晰的计划,项目成员很难把握项目 中的方方面面。 SOA基础 „ 从表面看来,MDA和AM似乎是相对立的-MDA假定需求 是固定的,而AM恰恰相反。MDA的中心是形式化的模 型,而AM恰恰要避开它们。但是,我们还是决定冒险把 这些不同方法中的一些元素提取出来,放入到一个一致的 架构实践中。 „ 在SOA中有三个抽象层次,按照SOA的第一条准则:业务 驱动服务、服务驱动技术。AM将业务模型直接和实践连 接起来,表现在平台相关的模型之中。MDA并没有把业务 模型和平台无关模型分开来,而是把平台无关模型做为起 点。SOA必须连接这些模型,或者说抽象层次,得到单一 的架构方法。我们将从五个视图的架构实现方法来实现这 个连接。 SOA的五视图实现方法 „ 企业架构设计师发现他们的职业非常有竞 争力并且值得骄傲,因为他们要从很多方 面来通盘考虑IT系统。Kruchten(RUP的开 发负责人)将这些方面提取出来,在应用 到SOA时,我们称为五视图实现方法(five- view approach)。 SOA的五视图实现方法 „ 四个方框表示对一个架构的不同审视方法,分别代表不同 的涉众(stakeholder)。第五个视图,use-cASe视图涵盖 了其它视图,在架构中扮演的是一个特殊的角色。部署视 图将软件映射到底层平台和相关硬件上,是系统部署人员 对架构的视图;实现视图描述了软件代码的组织,是从开 发人员角度出发的视图;业务分析人员则利用过程视图进 行工作,它描述的是软件系统的运行时特性。最后,逻辑 视图表示的是用户的功能需求。在SOA中,面向服务的架 构必须能够以use-case视图中的用例将用户连接到服务, 将服务连接到底层的技术。 SOA的五视图实现方法 „ 为了表示面向对象的架构是如何工作在这些视图之上,让 我们将他们置于SOA元模型的上下文之中。SOA中两个领 域存在重叠:由业务模型和服务模型表示的业务领域和由 服务模型及平台相关模型表示的技术领域(两个领域共享 服务模型)。业务用户通过逻辑视图和过程视图处理粗粒 度的业务服务,根据变化的业务需求,按照需要将它们安 排在过程之中。另一方面,技术专家的工作是创建并维护 服务和地层技术之间的抽象层。表示这些服务的中间模 型,起到的是轴心的作用,业务以它为中心进行。 SOA的五视图实现方法 „ SOA元模型从MDA中继承平台无关模型和平台相关模型, 但是添加了AM和用户交互以及敏捷的反馈这两部分,后 者通过椭圆之间的双向箭头来表现。类似地,元模型通过 引入由中心的服务模型提供的中间层抽象解决了AM在伸 缩性方面的问题。这样,服务模型中的任何需求的变化, 都会反映到用户每天的业务处理中。同样,由于底层技术 是模型驱动的,技术专家也可以根据这些变化的需求迅速 而有效地作出应变。 SOA的五视图实现方法 „ SOA实践和过去解决企业架构传统方式的不同之处就在于 其对敏捷性的支持。如前所说,SOA的第三条原则就在于 它总在变化之中。这种恒在的变化性环境是SOA实践的基 石。如图所示,涉众(stakeholders,译者注:RUP中也 有这个词,表示软件开发中涉及到的各种角色如:用户、 设计人员、开发人员乃至测试人员等等。)在一个必需的 基础上影响到整个架构的变化。在当技术专家在每天的日 常工作中不断对变化的业务需求作出响应的这种情况下, 设计阶段和运行阶段之间的界限变得模糊起来,很难清晰 地分离这两个阶段。 剩下的部分 „ 我们已经为面向服务的架构提供了一个高层次的框架,其 中MDA和AM的元素帮助工具的使用者来创建和维护 SOA。但是,SOA中还缺少一些内容-那就是软件开发商 和专业的服务组织必需提供的。理想情况下,开发商必需 提供面向服务的业务流程、工作流以及服务的协调工具和 服务;另外,能够以一种敏捷的、平台无关的方式充分反 映业务服务的建模工具也是必须的;技术专家必须配备可 以从模型中自动生成代码,并在代码变化时更新模型的工 具,最后,开发商必须提供支持SOA的软件,帮助面向服 务的架构设计师以一种可信并且可伸缩的方式创建位于服 务和底层技术之间的抽象层次。幸运的是,这方面的产品 即将上市。 „ 另外,最重要的就是贯穿本文的自顶而下的SOA实现方法 了。今天关于Web services的大部分思考都是自底而上 的:“这是如何创建Web services的方法,现在,我们来使 用它们集成吧”,对Web services技术的这种方法是伟大的 第一步,因为它可以惊人地降低集成的开销,这是现在的 技术管理人员最乐意见到的了。但当经济进一步发展,IT 走出低谷,企业会寻求IT的帮助来提高组织战略意义上的 核心价值。使用面向服务的架构,IT可以提供给企业实现 业务敏捷性的这样一个框架。 为什么选择面向服务架构(SOA)? „ 不同种类的操作系统,应用软件,系统软件和应用基础结构 (application infrastructure)相互交织,这便是IT企业的现状。一些 现存的应用程序被用来处理当前的业务流程(business processes), 因此从头建立一个新的基础环境是不可能的。 „ 企业应该能对业务的变化做出快速的反应,利用对现有的应用程序和 应用基础结构(application infrastructure)的投资来解决新的业务需 求,为客户,商业伙伴以及供应商提供新的互动渠道,并呈现一个可 以支持有机业务(orGAnic business)的构架。 „ SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新 服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过 不同的渠道提供服务,并可以把企业现有的或已有的应用作为服务, 从而保护了现有的IT基础建设投资。 „ 如图1的例子所示,一个使用SOA的企业,可以使用一组 现有的应用来创建一个供应链复合应用(supply chain composite application),这些现有的应用通过标准接口 来提供功能。 服务架构 „ 为了实现SOA,企业需要一个服务架构,图2显示了一个 例子: „ 在图2中, 服务消费者(service consumer)可以通过发 送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以 提供一个业务规则引擎(business rules engine),该引擎 容许业务规则被合并在一个服务里或多个服务里。这种架 构也提供了一个服务管理基础(service management infrastructure),用来管理服务,类似审核,列表 (BIlling),日志等功能。此外,该架构给企业提供了灵 活的业务流程,更好地处理控制请求(regulatory requirement),例如Sarbanes Oxley(SOX),并且可以 在不影响其他服务的情况下更改某项服务。 面向服务架构(SOA)基础结构 „ 要运行管理SOA应用 程序,企业需要SOA 基础,这是SOA平台 的一个部分。SOA基 础必须支持所有的相 关标准,和需要的运 行时容器。图3所示 的是一个典型的SOA 基础结构。接下来的 章节将逐一讨论该结 构的每个部分。 SOAP, WSDL, UDDI „ WSDL,UDDI和SOAP是SOA基础的基础部件。WSDL用来 描述服务;UDDI用来注册和查找服务;而SOAP,作为传 输层,用来在消费者和服务提供者之间传送消息。SOAP 是Web服务的默认机制,其他的技术为可以服务实现其他 类型的绑定。一个消费者可以在UDDI注册表(registry) 查找服务,取得服务的WSDL描述,然后通过SOAP来调用 服务。 WS-I Basic Profile „ WS-I Basic Profile,由Web服务互用性组织(Web Services Interoperability Organization)提供,是 SOA服务测试与互用性所需要的核心构件。服务 提供者可以使用Basic Profile测试程序来测试服务 在不同平台和技术上的互用性。 J2EE 和 .Net „ 尽管J2EE和。NET平台是开发SOA应用程序常用的平台, 但SOA不仅限于此。像J2EE这类平台,不仅为开发者自然 而然地参与到SOA中来提供了一个平台,还通过他们内在 的特性,将可扩展性,可靠性,可用性以及性能引入了 SOA世界。新的规范,例如 JAXB(Java API for XML Binding),用于将XML文档定位到Java类;JAXR(Java API for XML Registry)用来规范对UDDI注册表(registry) 的操作;XML-RPC(Java API for XML-based Remote Procedure Call)在J2EE1.4中用来调用远程服务,这使得 开发和部署可移植于标准J2EE容器的Web服务变得容易, 与此同时,实现了跨平台(如。NET)的服务互用。 服务品质 „ 在企业中,关键任务系统(Mission-critical system,译 注:关键任务系统是指如果一个系统的可靠性对于一个组 织是至关重要的,那么该系统就是该企业的关键任务系 统。比如,电话系统对于一个电话促销企业来说就是关键 任务系统,而文字处理系统就不那么关键了。)用来解决 高级需求,例如安全性,可靠性,事物。当一个企业开始 采用服务架构作为工具来进行开发和部署应用的时候,基 本的Web服务规范,像WSDL,SOAP,以及UDDI就不能满 足这些高级需求。正如前面所提到的,这些需求也称作服 务品质(QoS,quality of services)。 „ 与QoS相关的众多规范已经由一些标准化组织 (standards Bodies)提出,像W3C(World WIDE Web Consortium)和OASIS(the Organization for the Advancement of Structured Information Standards)。下面的部分将会讨论一些QoS服务 和相关标准。 „ 安全 „ Web服务安全规范用来保证消息的安全性。该 规范主要包括认证交换, 消息完整性和消息保 密。该规范吸引人的地方在于它借助现有的安 全标准,例如,SAML(as Security Assertion Markup Language)来实现web服务消息的安 全。OASIS正致力于Web服务安全规范的制 定。 „ 可靠 „ 在典型的SOA 环境中,服务消费者和服务提供者之间 会有几种不同的文档在进行交换。 „ 具有诸如“仅且仅仅传送一次”( once-and-only-once delivery),“最多传送一次”( at-most-once delivery),“重复消息过滤”(duplicate message elimination),“保证消息传送”(guaranteed message delivery)等特性消息的发送和确认,在关键任务系统 (mission-critical systems)中变得十分重要。 „ WS-Reliability 和 WS-ReliableMessaging是两个用来解 决此类问题的标准。这些标准现在都由OASIS负责。 „ 策略 „ 服务提供者有时候会要求服务消费者与某种策略通 信。比如,服务提供商可能会要求消费者提供Kerberos 安全标示,才能取得某项服务。这些要求被定义为策 略断言(policy assertions)。一项策略可能会包含多 个断言。WS-Policy用来标准化服务消费者和服务提供 者之间的策略通信。 „ 控制 „ 当企业着手于服务架构时,服务可以用来整合数据仓 库(silos of data),应用程序,以及组件。整合应用 意味着例如异步通信,并行处理,数据转换,以及校 正等进程请求必须被标准化。在SOA中,进程是使用一 组离散的服务创建的。 „ BPEL4WS 或者 WSBPEL(Web Service Business Process Execution Language)是用来控制这些服务的 语言。WSBPEL目前也由OASIS负责。 „ 管理 „ 随着企业服务的增长,所使用的服务和业务进 程的数量也随之增加,一个用来让系统管理员 管理所有运行在多相环境下的服务的管理系统 就显得尤为重要。 „ WSDM(Web Services for Distributed Management)规定了任何根据WSDM实现的 服务都可以由一个WSDM适应(WSDM- compliant)的管理方案来管理。 „ 其它的qos特性,比如合作方之間的溝通和 通訊,多個服務之間的事務處理,都在WS- Coordination 和 WS-Transaction 標準中描 述, 這些都是OASIS 的工作。 SOA 不是Web服务 „ 在理解SOA和Web服务的关系上,经常发生混淆。根据 2003年4月的Gartner报道,Yefim V. Natis就这个问题是这 样解释的:“Web服务是技术规范,而SOA是设计原则。特 别是Web服务中的WSDL,是一个SOA配套的接口定义标 准:这是Web服务和SOA的根本联系。 „ ”从本质上来说,SOA是一种架构模式,而Web服务是利用 一组标准实现的服务。Web服务是实现SOA的方式之一。 用Web服务来实现SOA的好处是你可以实现一个中立平 台,来获得服务,而且随着越来越多的软件商支持越来越 多的Web服务规范,你会取得更好的通用性。 面向服务架构(SOA)的优势 „ SOA的概念并非什么新东西,SOA不同于现有的分布式技 术之处在于大多数软件商接受它并有可以实现SOA的平台 或应用程序。 „ SOA伴随着无处不在的标准,为企业的现有资产或投资带 来了更好的重用性。 „ SOA能够在最新的和现有的应用之上创建应用;SOA能够 使客户或服务消费者免予服务实现的改变所带来的影响; SOA能够升级单个服务或服务消费者而无需重写整个应 用,也无需保留已经不再适用于新需求的现有系统。 „ 总而言之,SOA以借助现有的应用来组合产生新服务的敏 捷方式,提供给企业更好的灵活性来构建应用程序和业务 流程。 采用服务驱动型方法的企业体验着 以下业务和 IT 好处(1) „ 面向服务架构的业务好处 „ 效率: 将业务流程从 “ 烟囱 ” 状的、重复的流程向维 护成本较低的高度利用、共享服务应用转变。 „ 响应: 迅速适应和传送关键业务服务来满足市场需 求,为客户、雇员和合作伙伴更高水准的服务。 „ 适应性: 更高效地转入转出让整个业务变得复杂性和 难度更小,达到节约时间和资金的目的。 采用服务驱动型方法的企业体验着 以下业务和 IT 好处(2) „ 面向服务架构的 IT 好处 „ 复杂性降低: 基于标准的兼容性,与点到点的集成相 比降低了复杂性。 „ 重用增加: 通过重用以前开发和部署的共享服务,实 现了更有效的应用程序 / 项目开发和交付。 „ 遗留集成: 用作可重用服务的遗留应用程序降低了维 护和集成的成本。 „ 如今的服务驱动型企业都在体验着开发的高效 率,服务的高可靠性和服务的高质量,以最大限 度获得业务机会所带来的这些好处。 SOA在国际市场上反响强烈 „ 自2004年初业界推出SOA后,Bea、IBM、ORACLE、微软等业界巨头 纷纷发布自己的SOA战略,建议用户在进行企业IT建设时考虑SOA。 „ ZapThink调研公司在最近发表的一份报告中预测,到2006年,基于 SOA架构(面向服务的架构)的中间件产品将成为网络化商业系统的主 要设计思路,其中70%的商业企业公司将使用SOA架构。 „ 按照Gartner的预测,到2008年,SOA将成为占有绝对优势的软件工 程实践方法,它将结束传统的整体软件体系架构长达40年的统治地 位。届时,将有60%的商业公司在进行商业IT建设时会转向SOA。 „ IDC预测到 2007年,包括软件、服务和硬件在内的SOA市场将达到 210亿美元,其中商业企业方面的市场将达到120亿美元。 „ 综上所述SOA已经成为大势所趋,有着广阔的市场空间和巨大的发展 潜力;而在商业企业中的应用,将成为SOA未来发展的一大亮点。 SOA已经引起国内商业企业的重视 „ 国内基于SOA架构Web服务目前还是集中在一些企业内部,而国内一 些有影响的行业用户正在搭建其核心业务系统,比如商业领域的流通 行业和销售行业的大集中正在起步。因此当商业企业需要更好地服务 客户,需要更好地与上、下游合作伙伴协同工作,并且自己内部的核 心业务之间也需要协同工作时,基于SOA架构中间件产品就会为这类 新的业务应用提供理想的底座,这种新的应用被称作面向服务的业务 应用。 „ 现在,很多商业企业都准备在2006年内开始规划使用这些基于SOA架 构的应用,可想而知,这些SOA架构的中间件产品将在两年内迅速发 展,并在五年内在整个IT行业内获得广泛应用。 商业企业信息化存在的问题 „ 商业企业信息系统多数处于封闭运行的状态,企 业之间、企业与上游供应商、下游消费者之间信 息不对称。商业企业之间无法形成协同效应。信 息系统即无法满足消费者的综合需求也无法达到 企业间的商务协同自动化和智能化的需求。信息 化的经济效益难以有效发挥。同时信息化标准不 健全,如电子交换接口标准、业务流程协同标 准;流通中的票证、单据格式标准;电子数据交 换所必须的结构化数据标准等。 商业企业信息化存在的问题 „ 采用传统的系统架构技术和传统的EAI和B2Bi技术则存在 系统封闭、厂商依赖性强、耦合度高、重用性差,扩展性 差、无法和上下游企业的系统建立统一的接口等问题。而 采用SOA 技术则可以有效解决上述问题,由于SOA基于 HTTP/SOAP/WSDL等开放式技术,对于特定厂商产品依赖 性小;系统开放、互操作性强,可以建立统一的WEB服务 用于和不同的上下游企业信息系统实现供应链协同。由于 SOA的松耦合特性、比较符合集团和各下属机构的商业关 系,业务流程整合和项目协调的阻力会有效降低。 商业企业信息化存在的问题 „ SOA以服务为基本单元,更加贴近于企业的商业活动,业 务梳理和建模的复杂度会有效降低,重用性也会有效提 高。另外采用SOA,企业IT系统所提供的服务会更容易扩 展、组合和变更,符合该集团目前业务发展变化较快的特 点,可以有效的降低该集团IT系统的长期拥有总体成本。 我们将该集团公司作为一个试点,推进SOA技术的运用, 来有效解决上述问题。 “协同商务”的新经济时代即将到来 „ 采用SOA技术最终将使得各个商业企业之间、各个关联的 经济实体之间实现高效实时的联接,使得整个产业链实现 自动化的协同商务,将会有力的提高商业企业的应变能 力,转变现有的商业运作模式,转变经济增长的方式。 SOA技术将促进信息系统在商业企业贸易活动中的全面渗 入和发展,对于简单的贸易活动,将会由信息系统自动化 实现;对于复杂的贸易活动,信息系统将会为企业管理人 员提供足够的决策信息并可以高效的执行决策。SOA技术 的应用将会全面提高商务的自动化、智能化和实时化水 平。 “协同商务”的新经济时代即将到来 „ 采用SOA技术实现协同商务可以提高城市范围内商流、物 流、资金流和信息流的运行效率,扩大北京市商业企业整 体规模效益,加强商业企业的整体对外竞争力,拉动经济 增长,降低企业运营成本,推动城市流通信息技术创新体 系的建立,提高北京市流通现代化水平,促进城市管理现 代化和城市社会经济信息化的进程。 “协同商务”的新经济时代即将到来 „ 采用SOA技术可以将将物流企业、物业企业、商业企业、 消费者整体整合在一起,对供应链关联企业、物流企业以 及网上支付体系、安全认证体系等环境建设具有明显的带 动作用,有利于促进支撑环境协同发展。 促进商业企业信息化标准的制定, 完善政府职能 „ 采用SOA技术为信息系统的沟通提供了技术基础,而随着 SOA在商业企业的应用,必将促进统一的商业领域电子商 务行业标准的发展和制定,对促进国家商业企业信息标准 体系的建立和完善具有重要支撑作用。 „ SOA技术为政府对商业经济的运行状况提供了实时监测和 指导的技术可能性,将从根本上改变政府对社会经济的管 理方式。 促进商业企业信息化标准的制定, 完善政府职能 „ 基于SOA的协同商务带来的最直接的好处就是由于贸易范 围的空前扩大而产生的全球贸易活动的大幅度增加,因而 提高了贸易环节中大多数角色的交易量,因此,全球范围 的经济形势将向一个良好的增长趋势发展。它还可以扩大 地方商业企业整体规模效益,加强商业企业的业务整合和 商业协同效应,提高商业企业的整体对外竞争力,通过协 同商务有效降低企业运营成本,推动城市流通信息技术创 新体系的建立,提高地方的流通现代化水平,促进城市管 理现代化和城市社会经济信息化的进程。 促进商业企业信息化标准的制定, 完善政府职能 „ SOA在商业企业的应用可以将物流企业、物业企业、商业 企业、消费者整体整合在一起,对供应链关联企业、物流 企业以及网上支付体系、安全认证体系等环境建设具有明 显的带动作用,可推动信息化各环节的全面应用与发展, 有利于促进产业链和支撑环境协同发展,从而也创造了更 多的就业机会和社会财富。 促进商业企业信息化标准的制定, 完善政府职能 „ 信息产业是知识经济的核心和主要的推动力,而企业信息 化又是目前信息产业中最具前途的发展趋势,因此说企业 信息化的发展,必将直接或间接地推动知识经济的浪潮。 这种知识经济有着大量的无形成本和高附加值,在东南亚 金融危机的同时,高科技给美国带来的是"高增长速度、 高就业率、低通货膨胀率"。这也是我国在宣传知识经济 的热潮中应注意的一个真正有价值的切入点。 „ SOA技术由于其前所未有的信息系统整合与自动协同能 力,成为继互联网以来又一个革命性的技术,将会把目前 基于WEB/互联网的知识经济推进到一个前所未有的新阶 段。 SOA 企业考虑事项 „ 服务驱动型企业在对客户、合作伙伴和雇员的高效化服务 方面得到了优化 -- 并加速了业务服务响应时间。然而,成 为服务驱动型企业,需要的不仅仅是产品的部署。对实现 服务驱动型架构感兴趣的企业将希望能与一个有经验的 SOA 提供商合作,它提供的服务可以保护企业在业务和 IT 方面的投入,他们考虑到了以下几个方面: „ 业务战略: 组织需要明确驱动关键业务流程的业 务战略,它将用于成形 SOA 的框架。一旦识别出 业务问题,就可以用一种一致的、可复用的方法 对其进行定义,并实现解决方案。在这个关键的 基础阶段,业务通常需要与一个拥有开发 SOA 业 务战略经验、并能共享横向和纵向市场最佳实践 的提供商进行合作。 „ 体系结构: 为了解决方案快速和动态的交付,企 业必须开发一种允许装配组件和服务的体系结构 框架。通过与有经验的 SOA 提供商合作,企业可 以获得相应的参考案例,以快速搭建一个关注复 用、避免 " 烟囱 " ( stovepipe )式应用程序和 IT 资源 " 孤岛 " 的体系结构。此外,有经验的 SOA 提供商还可以帮助企业对项目的易管理性进行设 计。 „ 构建模块: 不管是对体系结构还是对编程模型来 说, SOA 都是是思考构建软件模型的一种优秀方 式。与 SOA 提供商进行合作能让组织能够识别可 在 SOA 实现中使用或重用的构建模块代码、服 务、应用程序和组件。与有经验的 SOA 提供商进 行合作还有一个好处,企业可以获得对构造组 件、企业域( domains )、服务和规范数据模型 的参考经验。 „ 项目和应用程序: SOA 创造了一种在更强 大、更灵活的编程模式中搭建应用程序的 新方法。与 SOA 提供商合作的企业可以更 好地识别将被合并到 SOA 结构体系中的现 存的和正在使用的应用程序。有经验的 SOA 提供商还将引导项目基础架构的搭 建,并对正在进行中的项目提供有效的管 理。 „ 成本和收益: 在一个 SOA 项目中,开发和维护成 本将大大削减,。有经验的 SOA 提供商可以帮助 企业构造 SOA 基金模式,并构建 " 行动案例 " , 包括评估基础构造成本和效益、实现项目的最佳 投资回报( ROI )以及开发商务案例。 „ 组织和统辖: 组织需要为新的面向服务的 IT 组织识别角色和职责,并优化经验集便 于以后使用。有经验的 SOA 提供商可以帮 助企业实现这些目标,同时组织一个有效 的设计 " 复用工厂 " ( Reuse Factory ), 帮助定义统辖模式,并最终保证客户满 意。 服务描述 „ Services are described using a standardized interface (metadata) „ Defines the service, its operations, and input and output parameters „ Defines how the service is reached and its location „ Input and outputs may be simple parameters or XML documents „ An existing application can be given a service ‘façade’ „ The façade (e.g. an EJB) is then described as the service „ Web Services Description Language (WSDL) is the standard used to describe the service 服务描述: WSDL „ WSDL (Web Services Description Language) is an XML document that describes a Service using a number of key elements: „A Port Type defines what the service does, and is described by a number of operations. For each operation the data that it receives and sends is described by a Message „The Binding defines how the service (as described by the Port Type) is invoked e.g. SOAP/HTTP, SOAP/JMS. „The Port specifies the address where the service is located 服务调用 „ Services interact by exchanging data over an Enterprise Service Bus „ The Enterprise Service Bus is a logical architectural construct „ Provides inter-connectivity services „ Services interact with each other based on the quality of service requirements of the individual transactions „ ESB connects and integrates an enterprise's IT business „ In different locations, using different transports, across organizations „ ESB mediates service requests and responses „ Performs transformation and routing „ Enables connection type transparency „ ESB enables the use of multiple protocols „ e.g. SOAP/HTTP can be converted to SOAP/JMS and vice versa 企业服务总线(ESB) Central to the Workings of a Service Oriented Architecture Transport Services Synchronous/Asynchronous Persistent/Non-persistent Loosely-coupled/Tightly-coupled Event Services Publish and Subscribe Mediation Services Routing Transformation Standards Based HTTP/HTTPS with option for WS-ReliableMessaging JMS, JAX-RPC, SOAP WS-Security, WS-Policy, WS-Addressing 服务的编排术 „ Business processes are a set of activities carried out in a sequence „ Services can be choreographed to implement a business process „ i.e. each step or activity in a business process is implemented by a service „ The business process itself becomes a service „ Service choreography is described by the Business Process Execution Language (BPEL) „ A standard proposed to OASIS for process definition „ Service Choreography provides: „ Processes that combine applications and people „ Transactionality and compensation „ Manipulation of process data 服务的发现 „ A Service Registry or Directory „ Publishes service descriptions „ Finds business, services and service interfaces „ UDDI is a standard for a registry web service (see UDDI.org) „ Service discovery may be at design time or run time „ WebSphere Studio provides Web Services Explorer to publish and search UDDI „ UDDI Service entries contain URL of its WSDL „ A UDDI directory may be private to an enterprise „ WSDL for services may be stored in local files and directories „ ESB mediations may be used to determine service’s location at run time Service Registry SOA 的服务栈 „ SOA uses Web Services specifications to implement its features „ Many Web Services specifications are being standardized „ IBM and other vendors have implemented these specifications, anticipating the standards „ The Web Service function stack is rich and getting richer 如何构建SOA的系统 „ Develop a service oriented mentality „ Everything is a service „ Understand and define services „ Good service decomposition is the challenge „ Remember coarse granularity „ Some service implementations will exist, others will need to be created „ Determine service interfaces and interaction patterns „ What formats will be adopted for data exchange? „ What qualities of service will bound interactions? „ Where will mediation be required/appropriate? „ Define service orchestrations in terms of supported business processes „ Composite services will generally reflect business processes? „ What are the business processes? „ Business models in WebSphere BI Modeler can prove invaluable here 采用 SOA 的四个层次 实现单独的 Web 服务 面向服务的集成 企业范围内的 IT 转换 Enterprise applications Enterprise data Data Access ServicesApplication Access Services IBM Software Offerings Monitoring Services IBM商务整合的参考架构 Model, design, development, test tools Common Runtime Infrastructure WebSphere BI Modeler WebSphere BI Monitor Web Services Gateway WebSphere BI Event/Message BrokerWebSphere MQ WebSphere BI Adapters DB2 Information Integrator Classic WebSphere Studio DB2 Information Integrator WebSphere Business Integration Server WebSphere Business Integration Connect WebSphere Application Server Enterprise Service Bus Process Services Community Integration Services Application Services Information Services WebSphere Portal Server User Interaction Services Professional Services Network OGSA Enabled Storage OGSA Enabled Servers OGSA Enabled Messaging OGSA Enabled Directory OGSA Enabled File Systems OGSA Enabled Database OGSA Enabled Workflow OGSA Enabled Security OGSA Enabled Web Services OGSI – Open Grid Services Infrastructure Grid Services System Management Sevices Open Grid Services Architecture (OGSA) Applications Autonomic Capabilities OGSA OGSA Structure Grid 和 Web 服务 Grid Web The definition of WSRF means that Grid and Web communities can move forward on a common base WSRF Started far apart in apps & tech O G SI G T 2 G T 1 H T T P W S D L , W S - * W S D L 2 , W S D M Have beenconverging 网格计算与SOA „ 网格系统本身就是SOA „ 在网格服务上构建应用程序级 SOA ESB实现服务网格: 例证 MQ Message Brokers Application Servers Integration Server MQ PortalWeb Clients Web Browsers Legacy Applications „ The ESB within the enterprise will evolve based on QOS requirements required by service interactions „ This will be augmented by mediations running in Message Broker and/or the Web Services Gateway. 总结 „ Service Oriented Architecture provides the flexibility required to operate in an On-Demand Environment 1 ©中国科学院软件所 2006 Slide 1 企业软件构架介绍 ©中国科学院软件所 2006 Slide 2 The Need of Architecture The Winchester “Mystery” House z 38 years of construction – 147 builders 0 architects z 160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors z 65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors z No architectural blueprint exists 2 ©中国科学院软件所 2006 Slide 3 Why Enterprise Architecture z IT costs too much z Costs of managing complexity z Eliminate redundancy z Growing IT ecosystem z Demanding rate of change z Need for info sharing z Outsourcing (BPO) z Future-proofing If you donIf you don’’t have strong architecture strategy, everyone does their own t have strong architecture strategy, everyone does their own thing and you end up with six kinds of servers and (software) thing and you end up with six kinds of servers and (software) platforms platforms …… you get silos of everything and that explodes your costsyou get silos of everything and that explodes your costs”” Andy Miller VP of Technical Architecture, Corporate ExpressAndy Miller VP of Technical Architecture, Corporate Express ©中国科学院软件所 2006 Slide 4 Does Your IT Architecture Look Like… (needed a) (needed a) ……blueprint to bring order to blueprint to bring order to ““spaghetti layer of spaghetti layer of applications, boxes and wiresapplications, boxes and wires”” Toby Toby RedshawRedshaw VP of Strategy & Architecture MotorolaVP of Strategy & Architecture Motorola 3 ©中国科学院软件所 2006 Slide 5 软件复杂性的度数 更高的技术复杂性 - 嵌入式,实时的,分布式的,不可出错的 - 定制的, 空前的,可复用的 - 高性能的 低技术复杂度 - 大部分是4GL, 或基于组件技术的 - 应用反向工程 - 交互性能 较高管理复杂度 - 大范围 - 合同契约性 - 多数人控制的 -“项目” 较低的管理复杂度 - 小范围 - 非正式的 - 简单的资金运作 -“产品” 防御 MIS系统 防御 武器系统信息 交换 CASE工具 国际空中运输 控制系统 企业IS (IS应用的家庭服务) 商业 编译器 商业制表软件 IS应用 分布式对象 (订购实体) 小型科学模拟 大型组织/实体仿真模拟 一个比较中等的项目 - 5-10 人 - 10-15 个月的开发周期 -3-5 个外部界面 - 一些不可知的事情 & 风险 嵌入式 车用软件 IS应用 GUI/RDB (订购实体) Walker Royce 注:什么是4GL? ©中国科学院软件所 2006 Slide 6 软件中的影响因素 复杂度是我们的敌人,是我们的目标,我们要消灭它。 Jan Baan 技术混合 性能 吞吐量 容量 可用性 失败安全 出错容忍程度 功能 成本 兼容性 恢复能力 20年之后的挑战不是速度、成本和性能,而是复杂度的问题了。 Bill Raduchel, Sun微系统公司策略执行总裁 4 ©中国科学院软件所 2006 Slide 7 体系结构的域 体系结构 质量 处理 体系结构 表现方法 “什么” “为什么” “如何”“谁” 系统 功能 结构 S/W 需求 系统 质量属性 满足 压制 组织 构建 技巧 风险承担人 定义规则 生产 跟踪 定义技术 ©中国科学院软件所 2006 Slide 8 议题 (1)Zachman架构框架 (2)Meta Group企业架构 (3)Microsoft架构框架(MAF) (4)IBM企业架构(EA) (5)美国国防部架构框架(DODAF ) (6)美国联邦政府架构框架(FEA) (7)集成化结构框架(IAF) 5 ©中国科学院软件所 2006 Slide 9 Zachman架构框架 ©中国科学院软件所 2006 Slide 10 The enterprise architecture is the organizing logic for a firm’s core business processes and IT capabilities captured in a set of principles, policies and technical choices to achieve the business standardization and integration requirements of the firm’s operating model. Definition of Enterprise Architecture 6 ©中国科学院软件所 2006 Slide 11 DataData (What)(What) FunctionFunction (How)(How) NetworkNetwork (Where)(Where) PeoplePeople (Who)(Who) TimeTime (When)(When) MotivationMotivation (Why)(Why) Zachman Framework Scope (Ballpark) viewScope (Ballpark) view Owners View (Enterprise Model) Owners View (Enterprise Model) Designers View (System Model) Designers View (System Model) BuilderBuilder’’s View (Technology Model) s View (Technology Model) Out of Context View (Detailed Model) Out of Context View (Detailed Model) Operational View (Functioning) Operational View (Functioning) ©中国科学院软件所 2006 Slide 12 7 ©中国科学院软件所 2006 Slide 13 Meta Group企业架构 ©中国科学院软件所 2006 Slide 14 Enterprise Architecture Meta Group Enterprise Strategy Business Processes Business Business Architecture Architecture Applications Information Infrastructure Application Application Portfolio Portfolio Information Information Architecture Architecture Technology Technology Architecture Architecture The Meta Group Enterprise Architecture 8 ©中国科学院软件所 2006 Slide 15 Microsoft架构框架(MAF) ©中国科学院软件所 2006 Slide 16 Old Model MSF 3.0 + Views ContextualContextual ConceptualConceptual LogicalLogical PhysicalPhysical Aimed at business executives Aimed at business process owners Aimed at architects and designers Aimed at designers and developers 9 ©中国科学院软件所 2006 Slide 17 Business strategies & processes Applications to facilitate business process Information needed to manage business Technology to support business & application needs ContextualContextual ConceptualConceptual LogicalLogical PhysicalPhysical Business View Applications View Information View Technology View Old Model MSF 3.0 + Views ©中国科学院软件所 2006 Slide 18 Logical Stratum Models LogicalLogicalApplicationApplication ArchitectureArchitecture Logical DataLogical Data ModelModel DistributedDistributed SystemsSystems ArchitectureArchitecture • Entity Relationship Models • Class Models • XML Schemas • Technology Services Portfolio • Distributed Systems Architecture Model • CRUD Affinity Matrices • Function/Application Affinity Matrices 10 ©中国科学院软件所 2006 Slide 19 Viewpoints AssessAssess DesignDesign ImplementImplementPlanPlan RunRun BusinessBusiness ITIT Strategic Strategic ObjectivesObjectives TechnologyTechnology ArchitectureArchitecture Business Processes Business Processes and Entitiesand Entities Logical Logical Data CenterData Center Physical servers Physical servers and segmentsand segments Services, Messages, Services, Messages, Contracts, SchedulesContracts, Schedules XML, Database, Classes,XML, Database, Classes, CodeCode Manual ProceduresManual Procedures DSLsDSLs PatternsPatterns ProcessesProcesses FrameworksFrameworks ComponentsComponents AspectsAspects TransformsTransforms ConstraintsConstraints ©中国科学院软件所 2006 Slide 20 Set Of Related View Points… and artifacts for Model Driven Development Business Business CapabilitiesCapabilities Manual Manual ProceduresProcedures TechnologyTechnology ArchitectureArchitecture ConstraintsConstraints ReconciliationReconciliation Services, Messages, Services, Messages, Applications, EndpointsApplications, Endpoints XML, Projects, XML, Projects, DBsDBs, Classes, Code, Classes, Code Logical Logical Data CenterData Center Physical servers & Physical servers & segmentssegments DeploymentDeployment UnitsUnits Abstraction/Abstraction/ RefinementRefinement ConstraintsConstraints packaged intopackaged into deployed ondeployed on Business Processes Business Processes and Entitiesand Entities ReconciliationReconciliation Abstraction/Abstraction/ RefinementRefinement 11 ©中国科学院软件所 2006 Slide 21 Merging Models ContextualContextual ConceptualConceptual LogicalLogical PhysicalPhysical BusinessBusiness ApplicationsApplications InformationInformation TechnologyTechnology Business Business CapabilitiesCapabilities Manual Manual ProceduresProcedures TechnologyTechnology ArchitectureArchitecture ConstraintsConstraints ReconciliationReconciliation Services, Messages, Services, Messages, Applications, EndpointsApplications, Endpoints XML, Projects, XML, Projects, DBsDBs, Classes, Code, Classes, Code Logical Logical Data CenterData Center Physical servers & Physical servers & segmentssegments DeploymentDeployment UnitsUnits Abstraction/Abstraction/ RefinementRefinement ConstraintsConstraints packaged intopackaged into deployed ondeployed on Business Processes Business Processes and Entitiesand Entities ReconciliationReconciliation Abstraction/Abstraction/ RefinementRefinement ©中国科学院软件所 2006 Slide 22 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Customers Suppliers Logistics Providers Financial Service Providers Customer Facing Channel Partners Enterprise 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing Level 4Level 4 3. Fulfill Demand3. Fulfill Demand 3.3 Procurement3.3 Procurement 3.3.2 Purchasing3.3.2 Purchasing -- RequestRequest ResourcesResources -- CreateCreate PurchasePurchase RequisitionsRequisitions Create Purchase Requisitions Request Resources Module Map – Business Capabilities 12 ©中国科学院软件所 2006 Slide 23* Non-Functional Requirements Architecture Framework Microsoft Confidential -Build quality and quantity metrics -Reports Source code, compile time dependencies, test data, results, Compilers, build tools, system admin tools, test tools Operational metrics- Directory Implementation - Backup and recovery Batch files, scripts, utilities -Performance against SLA抯 - Operational metrics -Directory Design -Data storage design -Monitoring and tuning -Remote management Activity metricsSpecific data inputs, processing and outputs Task and activity based process models %Utilization Defect Rates Cycle Times Step Count Process control dashboard Application process models P&L DSOOperational dashboard Business unit process models Balanced scorecard EVA, ROE, ROAEnterprise level dashboard Enterprise process models Development process, events and schedule Fault management and recovery Event management Activity specific events, collaborations and state transitions Process schedule, events, collaborations and state transitions Business unit master schedule Business events and cycles Development team, system admin team, configuration mgmt team Development, test, and staging environment locations and accounts User administration- Detailed network models - Network monitoring Users, roles, permissions, security requirements High level network models Traffic analysis Specific roles, accounts, passwords and permissions Activitiy specific devices and locations Process level actors with roles and permissions Communication links and devices needed for process automation Business unit org chart with roles, security permissions and skill sets Business unit logistic network (nodes and links) Organizational unitsLocations where the enterprise operates Asset management metrics-Repository -Dependency maps Batch files, scripts, utilities -Restore known configurations -Promote code Users, roles, permissions, security requirements Logical and physical device information -Quality and predictability metrics -Reports -Test Cases -Test Data -Repository Automated test suites - integration - acceptance - performance Test plan with schedule and test cases Development team, buildmaster, Config mgmt team, QA mgmt Test environment -Software development efficiency and effectiveness -Reports - Repository - Test Data - IDE - Bug Tracking Tools - Debugging Tools - Test Tools - Modeling tools -Iteration plan with schedule and features - Integration schedule Users, roles and permissions Development environment including integration machine(s) Buildmaster Config Mgmt Engineer System Engineer Systems Architect Process Worker Process Owner General Mgr CEO Test Engineer Developer -Build quality and quantity metrics -Reports Non functional requirements - detailed level Non functional requirements - high level -Activity objectives Process control objectives Operational goals and objectives - Strategic scope - Economic intent - Change impact analysis - Rollbacks - Asset retention -Quality and predictability metrics -Reports -Software development efficiency and effectiveness -Reports Business Architecture Operational Architecture Development Architecture A D C B O N M L P Q Scorecard (Test) Data (What) Function (How) 2 3 74 Timing (When) People (Who) Network (Where) 65 Viewpoints Purpose (Why) 1 Unit Tests User Adoption Database instances , stored procs, etc. Source code Implemetation units, Executables J1 realizations Integration tests Interfaces defined Reuse Tables, indexes, views, queries Design level classes, component, subsystem and QoS I1 realizations Acceptance tests App SLA metrics Reuse Application level data models Application level -Domain models -Analysis model -H1 realizations -Cross application integration test -SLA metrics -Reuse - Enterprise data models - Data distribution strategies Enterprise level domain model and logical services Executable (vertical / horizontal slices) Design level collaboration models (sequence and interaction) Analysis level collaboration model Enterprise level collaboration models (sequence and interaction) Intuitive, easy to use executable interface relevant to user needs -Processes allocated to processors - Production environ - NFR* met Visual designs, wire frames, site maps Design level system architecture - addresses -subnets -processors Information architecture, interaction maps, story boards, security requirements Application level system archtecture - Nodes, devices - Links and segments - Processors Enterprise level user profiles including demographics, psychographics, technographics Enterprise level system architecture -Nodes -Links -Locations Developer Designer Architect Enterprise Architect - Abbreviated use case descriptions - Implement interfaces System level use cases Mechanisms NFR* Application level use cases Mechanisms NFR Enterprise level use cases Process refactorings NFR* Executable Architecture H K J I EE integration tests - Reuse - Transaction metrics XML Schemas, Half Maps,ETL, Batch feeds Design level service, component, and subsystem models - EE acceptance test - Performance against SLAs - Onboarding costs Enterprise level data flows and replication strategies EAI (API, method, data, user interface) - B2B integration -Global (GXA) - Message broker Design level collaboration models Define business process models -BPEL4WS -Rosetta PIPs Roles, permissions, security requirements - Integration NFR* met Partners. customers, suppliers, system actors -URI抯 for all trading partners -Integration servers and firewalls Designer Enterprise Architect System level use cases - Extended enterprise use cases - EAI use cases Integration Architecture F E Unit tests, system testsProfiles, database instances, stored procs XLANG, source code, scripts, batch files, executables XLANG Executable vertical and horizontal slices Users mapped to roles within organizations Process mapped to processors, links, protocolsDeveloper Abbreviated use case descriptions Implement interfaces G Enterprise Architectural Space Organizing Table Enterprise Architectural Space Organizing Table ©中国科学院软件所 2006 Slide 24 * Non-Functional Requirements Architecture Framework Microsoft Confidential -Build quality and quantity metrics -Reports Source code, compile time dependencies, test data, results, Compilers, build tools, system admin tools, test tools Operational metrics- Directory Implementation - Backup and recovery Batch files, scripts, utilities -Performance against SLA抯 - Operational metrics -Directory Design -Data storage design -Monitoring and tuning -Remote management Activity metricsSpecific data inputs, processing and outputs Task and activity based process models %Utilization Defect Rates Cycle Times Step Count Process control dashboard Application process models P&L DSOOperational dashboard Business unit process models Balanced scorecard EVA, ROE, ROAEnterprise level dashboard Enterprise process models Development process, events and schedule Fault management and recovery Event management Activity specific events, collaborations and state transitions Process schedule, events, collaborations and state transitions Business unit master schedule Business events and cycles Development team, system admin team, configuration mgmt team Development, test, and staging environment locations and accounts User administration- Detailed network models - Network monitoring Users, roles, permissions, security requirements High level network models Traffic analysis Specific roles, accounts, passwords and permissions Activitiy specific devices and locations Process level actors with roles and permissions Communication links and devices needed for process automation Business unit org chart with roles, security permissions and skill sets Business unit logistic network (nodes and links) Organizational unitsLocations where the enterprise operates Asset management metrics-Repository -Dependency maps Batch files, scripts, utilities -Restore known configurations -Promote code Users, roles, permissions, security requirements Logical and physical device information -Quality and predictability metrics -Reports -Test Cases -Test Data -Repository Automated test suites - integration - acceptance - performance Test plan with schedule and test cases Development team, buildmaster, Config mgmt team, QA mgmt Test environment -Software development efficiency and effectiveness -Reports - Repository - Test Data - IDE - Bug Tracking Tools - Debugging Tools - Test Tools - Modeling tools -Iteration plan with schedule and features - Integration schedule Users, roles and permissions Development environment including integration machine(s) Buildmaster Config Mgmt Engineer System Engineer Systems Architect Process Worker Process Owner General Mgr CEO Test Engineer Developer -Build quality and quantity metrics -Reports Non functional requirements - detailed level Non functional requirements - high level -Activity objectives Process control objectives Operational goals and objectives - Strategic scope - Economic intent - Change impact analysis - Rollbacks - Asset retention -Quality and predictability metrics -Reports -Software development efficiency and effectiveness -Reports Business Architecture Operational Architecture Development Architecture A D C B O N M L P Q Scorecard (Test) Data (What) Function (How) 2 3 74 Timing (When) People (Who) Network (Where) 65 Viewpoints Purpose (Why) 1 Unit Tests User Adoption Database instances , stored procs, etc. Source code Implemetation units, Executables J1 realizations Integration tests Interfaces defined Reuse Tables, indexes, views, queries Design level classes, component, subsystem and QoS I1 realizations Acceptance tests App SLA metrics Reuse Application level data models Application level -Domain models -Analysis model -H1 realizations -Cross application integration test -SLA metrics -Reuse - Enterprise data models - Data distribution strategies Enterprise level domain model and logical services Executable (vertical / horizontal slices) Design level collaboration models (sequence and interaction) Analysis level collaboration model Enterprise level collaboration models (sequence and interaction) Intuitive, easy to use executable interface relevant to user needs -Processes allocated to processors - Production environ - NFR* met Visual designs, wire frames, site maps Design level system architecture - addresses -subnets -processors Information architecture, interaction maps, story boards, security requirements Application level system archtecture - Nodes, devices - Links and segments - Processors Enterprise level user profiles including demographics, psychographics, technographics Enterprise level system architecture -Nodes -Links -Locations Developer Designer Architect Enterprise Architect - Abbreviated use case descriptions - Implement interfaces System level use cases Mechanisms NFR* Application level use cases Mechanisms NFR Enterprise level use cases Process refactorings NFR* Executable Architecture H K J I EE integration tests - Reuse - Transaction metrics XML Schemas, Half Maps,ETL, Batch feeds Design level service, component, and subsystem models - EE acceptance test - Performance against SLAs - Onboarding costs Enterprise level data flows and replication strategies EAI (API, method, data, user interface) - B2B integration -Global (GXA) - Message broker Design level collaboration models Define business process models -BPEL4WS -Rosetta PIPs Roles, permissions, security requirements - Integration NFR* met Partners. customers, suppliers, system actors -URI抯 for all trading partners -Integration servers and firewalls Designer Enterprise Architect System level use cases - Extended enterprise use cases - EAI use cases Integration Architecture F E Unit tests, system testsProfiles, database instances, stored procs XLANG, source code, scripts, batch files, executables XLANG Executable vertical and horizontal slices Users mapped to roles within organizations Process mapped to processors, links, protocolsDeveloper Abbreviated use case descriptions Implement interfaces G Enterprise Architectural Space Organizing Table Enterprise Architectural Space Organizing Table 13 ©中国科学院软件所 2006 Slide 25 Pattern Model ©中国科学院软件所 2006 Slide 26 Business: objectives, functions, processes Application: portfolio used in the organization Information: data entities and relationships Technology: software, hardware, etc. Business Imperatives Core Business Practice “Sense & Act” Product Leadership “Innovation” Operational Efficiency “Consistency” Value Chain “Scale” Customer Intimacy “Understanding” Digital Business Practice Software Strategies Software Enrichment Agile Infrastructure Information Supply Chain Digital Customer Relationship Microsoft Architectural Framework Transformation 14 ©中国科学院软件所 2006 Slide 27 IBM企业架构(EA) ©中国科学院软件所 2006 Slide 28 Enterprise applications Enterprise data Data Access ServicesApplication Access Services IBM Software Offerings Monitoring Services IBM商务整合的参考架构 Model, design, development, test tools Common Runtime Infrastructure WebSphere BI Modeler WebSphere BI Monitor Web Services Gateway WebSphere BI Event/Message BrokerWebSphere MQ WebSphere BI Adapters DB2 Information Integrator Classic WebSphere Studio DB2 Information Integrator WebSphere Business Integration Server WebSphere Business Integration Connect WebSphere Application Server Enterprise Service Bus Process Services Community Integration Services Application Services Information Services WebSphere Portal Server User Interaction Services 15 ©中国科学院软件所 2006 Slide 29 Optimize Operations IBM WebSphere 软件平台 WebSphere Studio An open comprehensive development environment for building dynamic e-business applications WebSphere Application Server A high-performance and extremely scalable transaction engine for dynamic e-business applications WebSphere Host Integration Software to leverage and extend legacy assets for new e-business solutions WebSphere Everyplace Software for extending e-business applications to mobile devices WebSphere Commerce Powerful sell- and buy-side solutions to handle the challenges encountered in customer and trading partner environments WebSphere Voice Software for enabling natural voice interactions with applications and data WebSphere Business Integration Software that delivers end-to-end integration through five proven capabilities: model, integrate, connect, monitor and manage WebSphere MQ Software to connect internal and external applications to exchange information reliably and securely WebSphere Portal A single point of personalized interaction with applications, content, processes and people ©中国科学院软件所 2006 Slide 30 美国国防部架构框架(DODAF ) 16 ©中国科学院软件所 2006 Slide 31 DODAF (3 Main Views) ©中国科学院软件所 2006 Slide 32 DoDAF Products 1/2 17 ©中国科学院软件所 2006 Slide 33 DoDAF Products 2/2 ©中国科学院软件所 2006 Slide 34 美国联邦政府架构框架(FEA) 18 ©中国科学院软件所 2006 Slide 35 Business Reference Model (BRM) • Lines of Business • Agencies, Customers, Partners Service Component Reference Model (SRM) • Service Layers, Service Types • Components, Access and Delivery Channels Technical Reference Model (TRM) • Service Component Interfaces, Interoperability • Technologies, Recommendations Data Reference Model (DRM) • Business-focused data standardization • Cross-Agency Information exchanges Business-Driven Approach Performance Reference Model (PRM) • Government-wide Performance Measures & Outcomes • Line of Business-Specific Performance Measures & Outcomes Federal Enterprise Architecture (FEA) The FEA is being constructed through a collection of inter-related “reference models” designed to facilitate cross-agency collaboration, and horizontal / vertical information sharing XML and Web Services ©中国科学院软件所 2006 Slide 36 The Draft FEA Performance Reference Model (PRM) consists of six measurement categories that address cross-cutting drivers of performance and span internal/external perspectives and outputs and outcomes Processes and ActivitiesProcesses and Activities PeoplePeople TechnologyTechnology Customer Results Customer Results Business Results Business Results Mission-critical results measured from a customer and business or program perspective Day-to-day activities and broader processes agencies conduct measured as driven by desired customer and business results People, technology, and other fixed assets measured through their contribution to processes and activities – and by extension customer and business results Strategic Outcomes Other Fixed AssetsOther Fixed Assets Value 19 ©中国科学院软件所 2006 Slide 37 The FEA Business Reference Model (BRM) is a function-driven framework for describing the Lines of Business performed by the Federal Government independent of the Agencies that perform them Internal Operations / Infrastructure Human Resources, Financial Management Admin Supply Chain Management Human Resources, Financial Management Admin Supply Chain Management Inter-Agency Intra-Agency Support Delivery of Services Legislative Management Business Management of Information IT Management, Regulator Management Planning and Resource Allocation Controls and Oversight Public Affairs Internal Risk Management and Mitigation Federal Financial Assistance Web Services Telephone -Voice -Interactive E-system to System Public/Private Partnerships Fax Face to Face Mail Program Admin ComplianceServices to Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R&D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transportation Workforce Management Program Admin Compliance Services to Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R&D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transportation Workforce Management Telephone -Voice -Interactive E-system to System/ Web Services Public/ Private Partnerships Fax Kiosk Face to Face Mail Internet/ Portal Intranet/ Portal On average 10 Cabinet Departments and agencies per Line of Business On average 21 Cabinet Departments and agencies per Line of Business All 24 Cabinet Departments and agencies per Line of Business ©中国科学院软件所 2006 Slide 38 Customer Services Process Automation Services Business Management Services Digital Asset Services Business Analytical Services Back Office Services Common Services Cross-Cutting Service Areas (i.e., Search, Security) Service Types Service Layers Components The Draft FEA Service Component Reference Model (SRM) – to be released for agency review shortly - consists of seven Service Layers with supporting Categories and Component Areas. The SRM is structured across horizontal and vertical service areas that can provide – independent of business function – a leverageable foundation for reuse of applications, application capabilities, components, functions, and business services. Performance Measures Business Process Access and Delivery Channels Conceptual 20 ©中国科学院软件所 2006 Slide 39 The SRM is supported by multiple Access and Delivery Channels that provide a foundation for accessing and leveraging capabilities Portal Marketplace Exchange Commerce Integration Delivery Channels Service Layers, Service Types, and Components Access Channels Mobile, Wireless Web Browser PDAKiosks Internet Intranet Extranet Peer to Peer System to System Others Electronic ChannelsWeb Service Private/Public Partnership Phone, Fax Face to Face Mail Accessing the Component (Example: Renewal of Drivers License ) Service Level Agreement to structure how Service Components are accessed and leveraged Conceptual ©中国科学院软件所 2006 Slide 40 Service Framework Service Platforms Service Access and Delivery Service Platforms Service Interface / Interoperability Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture Service Transport Service Requirements Delivery Channels Access Channels The Draft FEA Technical Reference Model (TRM) will provide an effective means by which Service Components can be leveraged, built, and deployed across the Federal Government… Conceptual - Mobile, Wireless, Web - Internet, Intranet, Extranet - Section 508, Privacy, Security - HTTP, HTTPS, WAP, TCP/IP - J2EE, Windows .NET -SOAP, XML, UDDI, WSDL 21 ©中国科学院软件所 2006 Slide 41 … as well as provide guidance and technology recommendations supporting the development and implementation of Service Components that embrace a Component- Based Architecture Partial List Security Presentation / Interface Business LogicData InterchangeData Management Security Presentation / Interface Business Logic Data Management Data Interchange Component Architecture - X.509 - NIST / FIPS 186 - Secure Socket Layers (SSL) - HTML - JSP, ASP, ASP.Net - DTHML, CSS, XHTMLMP - Java/J2EE (EJB) - C, C++, JavaScript - COM/COM+, C# - Visual Basic - XML - ebXML - RDF, WSUI - XSLT - XBRL, JOLAP, OLAP - JDBC, ODBC - ADO, ADO.Net ©中国科学院软件所 2006 Slide 42 The draft FEA Data Reference Model (DRM) is envisioned to support the classification of data across horizontal and vertical business areas / functions Business Areas / Functions Social Services Consumer Safety Public Health Trade Import / Export z Will heavily leverage XML and interoperability principles z Classifications of data will form the basis for the definition of business-driven XML Schemas z Will leverage industry vocabularies z XML Schemas will be stored within a central repository (e.g.., XML.Gov, FEAMS) z Security and data privacy are TOP priorities, records management z State and local government collaboration is essential Benefits, Tariffs, Quotas Immunizations, Vaccinations Food / Merchandise Inspection News, Events Conceptual Disease Tracking / Monitoring 22 ©中国科学院软件所 2006 Slide 43 Collectively, the FEA reference models support investment and e-Government planning by providing frameworks in which agencies can leverage existing services, technologies, and components across the Federal Government… Program Admin Compliance Services to Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R& D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transpo rtation Workforce Management Support Delivery of Services Internal Operations/Infrastructure Legislative Management Business Management of Information IT Management Planning and Resource Allocation Regulatory Management Controls and Oversigh t Public Affairs Internal Risk Management and Mitigation Federal Financial Assistance Human Resources Financial Management Admin Supply Chain Management Human Resources Financial Management Admin Supply Chain Management Inter-Agency Intra-Agency Program Admin Compliance Services to Citizens Public Asset Management Marketable Asset Management Defense & Nat’l Security Ops Diplomacy & Foreign Relations Disaster Management Domestic Economy Education Energy Management Insurance Public Health Recreation & National Resources Social Services R& D & Science Regulated Activity Approval Consumer Safety Environmental Management Law Enforcement Legal Revenue Collection Trade (Import/Export) Transpo rtation Workforce Management Support Delivery of Services Internal Operations/InfrastructureInternal Operations/Infrastructure Legislative Management Business Management of Information IT Management Planning and Resource Allocation Regulatory Management Controls and Oversigh t Public Affairs Internal Risk Management and Mitigation Federal Financial Assistance Human Resources Financial Management Admin Supply Chain Management Human Resources Financial Management Admin Supply Chain Management Inter-Agency Intra-Agency 1 A new performance gap is identified. How do I improve performance? 2 Is the business function being performed across the Government? FEA Business Reference Model (BRM) 3 4 Create Service Component, Advance FEA Capabilities Service Level Agreements 6 What Access Channels can be used to access the Component? (i.e., Web Service, Portal, etc) 5 Will the Components support the business need? What modifications are needed? What Service Components are being used to support the business and process? What performance measures, and outcomes are the Service Components supporting? Processes and ActivitiesProcesses and Activities PeoplePeople TechnologyTechnology Customer Results Customer Results Business Results Business Results Strategic Outcomes Other Fixed AssetsOther Fixed Assets Value Access and Delivery Channels Performance Reference Model (PRM) Service Component Reference Model (SRM) Yes No Buy, Build, Borrow Exhibit 300’s Same Business Process? ©中国科学院软件所 2006 Slide 44 … and provide a framework to support the creation and integration of cross-agency initiatives and business solutions U.S. Customs (New e-Gov Border Control Initiative) State IRS USDA FDA Justice PRM BRM SRM TRM DRM Acceptance of Cargo Look up the license plate of the vehicle. Are there any warrants for the driver? Check to see if the import company owes taxes, fines, or penalties Do not let “x” animals into the country. Know viruses and risks Does the driver fit the profile of any wanted suspects. What country, what origin? Is the food properly packaged? How much does a normal truckload of banana’s normally weight? Agency EA Service Component eGov Architecture Guidance Federal Enterprise Architecture Conceptual 23 ©中国科学院软件所 2006 Slide 45 集成化结构框架(IAF) ©中国科学院软件所 2006 Slide 46 Enterprise Services Architecture Entity Services Process Services Infrastructure Services Clients and Agents Technology Architecture Information Architecture Operational Requirements Entity Descriptions and Constraints Actors and RolesProcess Description Activity Services Activity Specification Business Processes 24 ©中国科学院软件所 2006 Slide 47 SOAP BPEL4WS WSCI HTTP,FTP,SMTP,etc ebXML CPA BPML BTP ebXML BPSS ebXML CPP ebXML Messaging ebXML Registries DAML-S Service Grounding RDF DAML-S Service Profile DAML-S Service Model DAML-S Service ModelBPML BTPWS-Transaction WS-Coordination CS-WS WSCL Discovery Contracts Business Process /Workflow WSDL-based Semantic- based ebXML UDDI WSEL WSDL Transactions Choreography Conversations Non-functional description Service Description XML-based messaging Network 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 软件架构方法论 yangxiufeng@263.net ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 (1)开发组织架构框架(TOGAF) (2)架构开发方法(ADM) (3)模型驱动架构(MDA) 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 开发组织架构框架(TOGAF) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 TOGAF Origins and Motivations z A customer initiative: • Formal user requirement developed 1994 • Main themes: • A single, unifying Architectural Framework for the IT industry • A framework for developing architectures to meet specific business needs  not a “one-size-fits-all” architecture 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 z Industry consensus z Technology- and tool-neutral z 8 years continuous development z Proven in practice z Publicly available: http://www.opengroup.org/public/arch TOGAF Today ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 TOGAF Structure and Components Building Blocks Information Base (architecture building blocks -future) Standards Information Base (standards) Technical Reference Model (services taxonomy) Architecture Development Method Resource Base Target Architectures TOGAF Foundation Architecture z Architecture Development Method z Foundation Architecture z Resource Base 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 架构开发方法(ADM) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 Architecture Development Method (ADM) ‰ Open, industry consensus method for IT architecture ‰ Quick-start foundation ‰ Practical, experience based guidance ‰ Requires continual validation against requirements 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 z Associated with detailed taxonomy of services • defines scope of each service category z Identifies system-wide capabilities (“qualities”), e.g.: • Internationalization •Security • Management Foundation Architecture: Technical Reference Model (TRM) Qualities Qualities Network Services Operating System Services Data Management Location & Directory Infrastructure Applications Business Applications Data Interchange International Operations User Interface Transaction Processing System & Network Management Security Software Engineering Graphics & Image Communication Infrastructure Application Programming Interface Communications Infrastructure Interface Qualities Qualities ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 Foundation Architecture: Standards Information Base (SIB) z A database of open industry standards • The complete set of Open Group endorsed standards • Content determined by Open Group consensus process z Structured according to TOGAF Technical Reference Model taxonomy z Regularly updated z Available for public web access • http://www.db.opengroup.org/sib.htm z Gateway to many linked resources 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 Resource Base z Resources available in applying the TOGAF Architecture Development Method; e.g. •ADML • Architecture Compliance Reviews • Architecture Principles • Architecture Views • Business Scenarios (requirements method) • Case Studies • IT Governance Strategies ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 TOGAF Development History z 1994: Requirement • Proof of Need z 1995: TOGAF Version 1 • Proof of Concept z 1996: TOGAF Version 2 • Proof of Application z 1997: TOGAF Version 3 • Relevance to practical architectures (Building Blocks) z 1998: TOGAF Version 4 • TOGAF in Context - the Enterprise Continuum z 1999: TOGAF Version 5 • Business Scenarios - architecture requirements z 2000: TOGAF Version 6 • Architecture views / IEEE 1471 • US DoD work (C4ISR Framework, C2STA) z 2001: TOGAF Version 7 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 模型驱动架构(MDA) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 What is the MDA?What is the MDA? ƒƒ An approach to IT system specification that An approach to IT system specification that separates the specification of system separates the specification of system functionality from the specification of the functionality from the specification of the implementation of implementation of thatthat functionality on a functionality on a particular technology particular technology platformplatform ƒƒ ““Design once, build it on any platformDesign once, build it on any platform”” 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 Basic concepts of MDABasic concepts of MDA ƒƒ A A modelmodel is a formal specification of the function, is a formal specification of the function, structure and/or behaviour of a systemstructure and/or behaviour of a system ƒƒ Examples:Examples: ƒƒ Source code is a modelSource code is a model ƒƒ An UMLAn UML--based specification is a modelbased specification is a model ƒƒ Models of different systems are structured explicitly Models of different systems are structured explicitly into:into: ƒƒ Platform Independent Models (PIM)Platform Independent Models (PIM) ƒƒ Platform Specific Models (PSM)Platform Specific Models (PSM) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 Platform Independent Model (PIM)Platform Independent Model (PIM) ƒƒ A A ““formalformal”” specification of the structure and specification of the structure and function of a system that abstracts away function of a system that abstracts away technical detailtechnical detail ƒƒ Expressed using UMLExpressed using UML 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 PIM: an examplePIM: an example ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 Platform Specific Model (PSM)Platform Specific Model (PSM) ƒƒ Specifies how the functionality specified in a Specifies how the functionality specified in a PIM is realized on a particular platformPIM is realized on a particular platform ƒƒ Expressed using UML extended with platform Expressed using UML extended with platform specific specific UML profilesUML profiles 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 PSM: an examplePSM: an example ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 MDA metamodelMDA metamodel MOF Other languages UML Metamodel PIM Mapping techniques PSM Mapping techniques PIM PSM Infrastructure <><> <><> <><> <><> 1..n1..n <><> 1..n1..n Refactoring from Refactoring from PSM to PIMPSM to PIM <><> 1..n1..n <><> 1..n1..n Mapping from Mapping from PIM to PIMPIM to PIM 1..n1..n Mapping from Mapping from PIM to PSMPIM to PSM 1..n1..n Mapping from Mapping from PSM to PSMPSM to PSM 1..n1..n <><> <><> 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 MDA in a SnapshotMDA in a Snapshot Core Core TechnologiesTechnologies Core Target Core Target PlatformsPlatforms Pervasive Pervasive ServicesServices Vertical Vertical DomainsDomains 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 User Interface Process ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 我们所讨论的问题 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 User Interface Components z 用户和应用进行交互的接口 • 输入: • 辅助用户输入,提供各种提示和帮助 • 响应用户操作所触发的各种事件 • 限制用户的输入 • 处理一些特殊的操作,如drag-drop,剪贴板操作 •… • 展现: • 格式化数据 • 特殊显示 • 将一些代码翻译成可显示的名称 • 其他(asp.net的页面cache、分页显示查询结果) z 从UI的应用类型划分 • 字符界面、窗体界面、Web界面、Plug-ins ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 与表现层的相关内容 z 如同一般的系统设计,表现层也需要一整套支 撑模块 • 配置管理、Cache管理、本地存储、状态管理 z 表现层的设计模式 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 搭建UI的框架 z 框架 • 一整套能够动态配置和加载的插件模型 • 启动时的加载项、动态的菜单项、工具栏,UIP组件… • 提供一个Controller,能够管理UI与UI之间的调用 • 一整套为各程序模块所使用的工具 • 上下文对象:用户信息、权限信息 • 访问Service的公共入口:集成认证 • 客户端的Cache:业务数据、MetaData、用户凭证 • 客户端的应用配置信息 • 客户端的本地存储机制 •UI的scheme • 异常处理机制和最终的异常处理点 •… z 应用程序的入口和框架之间关系 • 浏览器:可能是第一个引用的Control(Assembly) •WinForm应用:登录窗口、主窗口、Splash窗口、TrayIcon z 选择你的窗口应用类型:Dialog、SDI、MDI ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 UI与UI之间的调用 z WinForm应用 •Form与Form之间、Form与Control之间、Control与Control之间 z 浏览器应用 • 页面与页面之间、页面与其它浏览器之间、页面中的不同部分之 间 z 尽可能不要将UI与UI之间调用的代码写在UI Components 的代码当中 • 由专门的Controller来完成UI的加载 • 尽可能保证UI Components的重用性 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 User Interface Process是什么 z 根据状态的改变决定使用哪一个UI z 应用场景 • 有些UI之间的相互作用时,存在明确的处理顺序 • 一个向导型的界面。用户可以选择上一步、下一步或者结束 • 在一个购书网站,用户可以反复地浏览上架的图书,然后将选中的图书放进购 物车。最终会走到收银台结帐 • 这些类型的界面操作的特点 • 用户的操作流程可以用一张流程(导航)图来描述 • 导航图上每一个节点就是一个用户界面(窗口/页面) • 界面之间的跳转是由用户操作触发的 z 处理这种流程的控制器,我们称为User Interface Process Components • 隔离了UI与业务逻辑层 • 对流程中的UI进行了管理 • 提供了状态保存和传递的机制 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 购书流程图 z 网上购书的流程图 z 与一般的自动工作流有什么不同? • 谁来控制流程的流转方向? z 数据(状态)的传递隐含在流转过程 当中 Activity Transition Action1 Action2 … 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 Microsoft User Interface Process Building Block-View Controller和State BrowseCatalog.aspx 浏览目录 Error.aspx 错误 出错 Confirmation.aspx 确认 成功 Checkout.aspx 结帐 结帐 用户界面操作导航图-View 进入一个流程 买一本书 Controller Model 用户操作 的状态 数据 其他相关 数据 状态 状态 放进购物车 结帐 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 UIP接口设计 User Actions State Access State Change 流程管理接口 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 UIP Components需要考虑的问题 z 其他需要考虑的问题 • 如何将控制流程和窗口、页面等界面元素分开 • 流程的每一步都需要保存状态。如何能抽象出一个统一的状态模型,可以使状 态在留转过程中被保存和传递 • 最好能够用一套处理机制,能够满足WinForm程序和Web应用的需要 • 用户的在一个操作流程中可能会嵌套子流程,或者会转到别的流程 • 记录流程的流转的日志 • 流程的维护 • 流程改变对正在运行的流程的影响 • 能否通过某种特殊手段改变流程的状态? 用户界面组件 用户界面流程组件 本地存储 Presentation Layer ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 Microsoft User Interface Process Building Block z 为解决上述问题而提供的一组接口和类 z 再回到流程图 z User Interface Process Application Block(UIPB) 用一种XML格式来表现流程图 z 在UIPB中,会用一些接口/类来表示图中的内容 •ITask,用来表示整个流程 •IView,用来表示图中的(节点)界面 • State,表示界面的状态。例如购物车中的书名和数量 • ControllerBase,控制界面之间的跳转、控制Task的启动和结束 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 MS UIP Building Block的设计模式 z UIPB采用了MVC模式 •Views,任何实现了IView接口的类(Form或WebForm) • Model,State类,它保存的是界面上的信息以及控制 信息 •Controller,就是ControllerBase及其派生类 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 MS UIP Building Block的其它功能 z 保存状态 • 定义了IStatePersistence接口,应用可以自己定制自己的状态保存方式 z WinFormView,WebFormView • 实现了IView接口。 z ViewManager • 管理在流程中出现的View z UIP Config • 读取应用程序配置文件信息,根据配置文件构造相应对象和流程图 z UIP Manager •UIP的入口,启动一个新的流程或已知的流程 DemoTask task = new DemoTask(); //实现了ITask接口的定制流程 UIPManager.StartTask(“demoTask”, task); 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 定制导航图 z 在配置文件中定制的流程 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 MS UIP Building Block类交互图 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 一次用户操作的步骤 z 以买书为例 UIPManager.StartTask( "Shopping", new CartTask(“email@w.com”) ); 建立Controller 建立ViewManager 通过ViewManager 建立并显示第一个View View(购物车) 用户按下结帐按钮 调用Controller的CheckoutOrder方法 调用业务组件,根据所选的货物 生成订单 清空购物车 转到结帐的View ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 我们可以订制的部分 z 几乎任何部分都可以被应用替换 • Controller • 可以从ControllerBase类派生 •View • 可以从WinFormView和WebFormView派生,也可以自己实现IView接 口 • ViewManager • 可以实现IViewManager接口 • StatePersistenceProvider • 可以实现IStatePersistence接口,定制自己的状态保存 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 我们可以订制的部分 z 所有的自定义实现类,都可以配置在配置文件中 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 我们可以订制的部分 z 定制视图 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 总结 z 作为设计者,应该充分考虑到UI模型的复杂度 z 在UI与业务层之间,可以增加UIP层进行隔离 •UIP管理了什么 • 流程、状态、View… •UIP的Building Block仅是一个模型,离实用还有一段 距离 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 Business Layer Design ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 Agenda z Business Component z Business Workflow z Service Interface z Business Entities Design z O/R Mapping and Patterns z MBF 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 Application Design & Services Operational Management SecurityCommunication UI Components UI Process Components Business Workflows Service Interfaces Business Components Business Entities Users Data Sources Services Data Access Logic Components Service Agents ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 Business Component 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 什么是Business Component Business Component — 实现业务规则及执行业务 工作的组件 z 实现业务功能,是对特定业务逻辑和内部业务 流程的封装 z 负责发起事务,是根事务发起者,支持事务与 补偿交易 z 通过封装已存在的业务能够获得更高等级的操 作和业务逻辑 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 Business Component特点 z 由用户处理层,服务接口,以及其他业务处理组件调用 ,包含一些业务数据和操作,以及复杂的数据结构(文 档) z 它是事务的发起者,必须参与事务的投票 z 必须验证输入和输出 z 通过调用数据层组件来获取或修改应用数据 z 能够通过代理调用外部服务 z 能够调用其他业务组件(Business Component)以及发 起业务流程 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 Business Component 与 Transaction 为了保证业务处理的完整性,Business Component 必须提供事务的支持 z 它是事务的发起者,必须参与事务的投票 z 能利用Enterprise Service的特点发起或参与异构系 统的分布式事务,设置组件事务属性。 z 为业务处理提供补偿交易处理 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 实现事务方式 在.NET环境下实现事务的方式: z Database Transactions • Using stored procedure z Manual Transactions • ADO.NET manual transactions SQLCommand Cmd = New SQLCommand; SQLTransaction Txn = Conn.BeginTransaction(); // Set the Transaction in which the command executes Cmd.Transaction = Txn; • MSMQ manual transactions z Automatic Transactions • MTS/COM+ services to support automatic transactions [Transaction(TransactionOption.Required)] public class Class1 : ServicedComponent { ……} 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 应用Enterprise Services 应用Enterprise Services必须考虑几个方面: z 远程通道限制:只支持HTTP和DCOM-RPC通道。 z 强名称Strong-name Components组件:您必须在这些 组件和它们依次使用的所有组件上签名 z 部署(Deployment)方面,组件注册运行需要有 administrative权限,需要额外的部署步骤 z 安全(Security)方面. 选择是否采用Enterprise Service 基于角色的安全机制,它也是基于Windows authentication授权的机制,或直接采用.NET-base安全 机制 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 Business Component 与其他组件之间的关系 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 Business Component 设计 设计业务组件(Business Component)的推荐要点 z 对于大型的系统,在保证性能的前提下,保证组件结构的可扩展性 z 尽量保持组件之间的松耦合,允许并行、渐进及独立的开发与测试 z 尽可能采用基于消息的通讯 z 确定透过服务接口所暴露的处理流程是能处理多次重复信息的情况 。 z 选择事务边界要仔细,设置合适的事务隔离度 z 选择和保持用一致的数据格式作为输入和返回参数 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 Business Component常用模式 -Pipeline pattern Pipeline pattern管道模式:以顺序方式执行动作 与查询 z 管道Pipeline定义了完成业务功能所需一系列步 骤。 z 所有的步骤必须按照顺序执行。 z 每一步必须包含读写数据操作以便确认“pipeline state”管道状态, z 可以调用或不调用外部服务。步骤可以包含调 用异步服务 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 Business Component常用模式 -Event pattern Event pattern事件模式. 事件在特定的业务条件 发生,可以写相应的代码来响应这些事件。 z 如果有许多活动发生,但所有活动都收到相同 的启动数据且无法与彼此通讯,可以采用event pattern事件模式。 z 可以是并行或顺序执行。 z 执行顺序则不一定是固定的顺序。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 Business Component 与 Business Entity关系 z 管理业务实体的生命周期 • 业务功能组件包含管理业务实体生命周期的各种逻辑,如创建、删除 等。 z 根据业务需求选取业务实体集合 • 业务功能组件包含选择业务需求的业务实体集合的各种逻辑。 z 管理业务实体间的关系 • 业务功能组件包含管理业务实体间关系的各种逻辑,如:取得或设置 某一实体对于另一实体的关系。这些方法将被相应的业务实体对象上 用于表达实体关系的属性所使用。 z 设计业务功能接口以实现组件服务扩展 • 方法的设计要考虑颗粒度以适应组件服务对象的外挂需要 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 范例:可扩展的组件结构要求 z 功能组件的扩展应该不影响已有客户代码的正 常执行; z 功能组件的扩展应该是在运行期动态完成,而 不需要在编译期确定; z 功能组件的扩展可以以较小的颗粒度进行;最 后,不应该引入过多的开发量,同时保证代码 的可管理性和可维护性。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 范例:基于接口的可扩展性设计 «interface» 功能组件接口 + F oo ( ) + Bar ( ) 功能组件核心 + F oo ( ) + Bar ( ) 功能组件扩展1 + Foo ( ) + Bar ( ) 功能组件扩展2 + Foo ( ) + Bar ( ) 功能组件扩展N + Foo ( ) + Bar ( ) 功能组件客户组件 1 1 1 功能组件客户组件 功能组件核心 + Foo ( ) + Bar ( ) «use» 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 范例:基于接口的可扩展性设计整体功 能实现 : 功能组件扩展1 : 功能组件客户组件 : 功能组件核心 : 功能组件扩展2 1 : Foo ( a , b ) 2 : Foo ( a , b ) 3 : Foo ( a , b ) 4 : Bar ( ) 5 : Bar ( ) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 Business Workflows 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 什么是Business Workflow Business Workflow是具有各种不同功能的活动 相连的一组有相互关系的任务。 z 业务流程有起点和终点,而且它们都是可重复 的。它由多个Business Process组成。 z Business Process包含多个业务步骤,且具有一 定顺序 z 定义及协调长期执行Business Process,支持长 事务 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 Business Workflow特点 z 提供迅速实现业务规则和适应商业目标改变的 能力 z 提供衡量这些改变的影响的能力 z 将每一步业务操作、资源管理,以及流程独立 的分离 z 以前后一致的方式定义、改变和实现业务流程 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 Business Workflow 种类 z 基于人的业务流程 • 每个人都得面对他或她必须完成、批准或执行的电 子文档 z 基于规则的自动化流程 • 规则引擎指定一步一步的操作,基于产生的规则自 动执行业务应用,这种工作流现在也在朝支持基于 人的工作流的方向发展 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 Business Workflow 实现 z 流程引擎 • 实现业务流程同时管理活动的启用和终止或商业功 能 z 资源管理器 • 资源管理器使实现商业功能或活动所必须的资源具 有可用性 z 调度程序 z 审计管理器 z 安全管理器 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 Business Workflow Vs Business Component z Business Workflow: • 管理包含多个步骤以及长期执行交易的处理过程 • Business Process包含长事务 • 提供调用Business Process流程的接口,可让应用程序与其它 服务进行交流或协作 z 在下列状况时,可以只使用Business Component实现 业务处理流程: • 业务功能可以实现为单一交易 • 需要将功能和逻辑封装,给多个Business Process流程重复加 以使用 • 需要对数据和逻辑流程进行精密的控制 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 Business Workflow 标准 Microsoft 的 XLANG:用于 BizTalk 的业务模型语言,该语言是可运行 EAI 的 .NET 组件。BizTalk 编制(BizTalk Orchestration)是工作流引擎,BizTalk 编制设计器(BizTalk Orchestration Designer)是基于 XLANG 的可视化 业务流程模型工具。 XLANG 用于 Web 服务的业务流程执行语言(Business Process Execution Language for Web Services)是用于 Web 服务编制、 工作流和组合的 WSFL 和 XLANG 的协作合并。该语言还尚未被提交到 IT 标准组织。BPEL4WS CIP4 的工作定义格式(Job Definition Format)是一种即将使用的用于图形艺术(Graphics Arts)工业的工作流工业标准 ,该标准用于简化不同应用程序和系统之间的信息交换。 JDF RosettaNet 的伙伴接口流程(Partner Interface Process ):定义了贸易伙伴与指定的系统到系统(system-to-system)的 基于 XML 的对话之间的业务流程。许多 PIP 被用来定义各种伙伴情况。 PIPs W3C 的 Web 服务对话语言(W3C's Web Services Conversation Language):Hewlett-Packard 向 W3C 的提交,该提交 允许定义 Web 服务的抽象接口(也就是,Web 服务支持的企业级对话或公共流程),以及交换的 XML 文档及其 文档的排序。 WSCL Sun/BEA/Intalio/SAP 联盟的 Web 服务编排接口(Web Services Choreography Interface)“是一种基于 XML 的接口描述 语言,该语言描述了参与和其他服务的编排交互作用的 Web 服务所交换的信息流。” WSCI 电子商务过渡工作组(eBusiness Transition Working Group)继承了业务流程规范方案(Business Process Specification Schema(BPSS))的 ebXML 层中的工作流对话和编制,ebXML 定义了许多基于 XML 的电子商务的协议和层。 ebXML BPSS IBM Web 服务流语言(IBM Web Services Flow Language):指定了 Web 服务组合的两种类型 1)一个被认为是流模型 (flowModel)的可执行业务流程,和 2)一个被认为是统一模型(globalModel)的业务合作。与 SOAP、UDDI 和 WSDL 兼容。 WSFL 工作流管理联盟(Workflow Management Coalition,WfMC)中的 Wf-XML 和工作流参考模型(Workflow Reference Model):Wf-XML 是一种基于 XML 的工作流互操作性信息的编码。工作流参考模型是一种底层工作流系统体系结 构的描述。目前 Wf-XML 没有与 SOAP 和 WSDL 绑定。 Wf-XML 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 BizTalk Server实现Workflow z BizTalk Orchestration Designer创建描述 long- running, loosely coupled的业务处理流程。 z 利用XLANG Schedules Engine 调用编译生成 的XLANG Schedules 进行调度 z 执行Schedule的方式 z Biztalk Tracking数据库与业务活动监视(BAM) z 提供SSO和身份验证 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 BizTalk Server Orchestration 编组业务流程 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 Biztalk Server实现基于人的业务流程 基于人的业务流程:将人员和处理过程与单一编组引擎相集成。 z 流程引擎 • BizTalk Server 2004 engine z 调度 • Human Workflow Service动态改变流程中动作的执行顺序 z 审计 • Tracking 数据库和BAM业务活动监视 z 安全 • 它基于操作人员的角色进行安全控制 z 支持WebService调用 • 将Web services 方法作为一个.NET-based 的对象 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 BizTalk Human Workflow架构 z 允许人手工处理与业务流程进行交互,利用大家熟悉的工具例如Microsoft Outlook与业务流程处理进行交互。 BizTalk Server 2004 Engine Administration SOAP SOAP Tracking SOAP Human Workflow Services Microsoft Office: Word, Outlook, InfoPath, Excel Information about actions ASP.NET Other Clients 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 z 执行业务操作,简化授权机制, 克服传统工作流灵活性问题 • 实时地修改工作流模型 z 实时显示工作流的执行进度 • 工作流负责任务的响应,业务策 略和组织机构的变化 z 使得商务人员利用已有的知识 • 使用 Office 进行面向任务的操作 HWS Workflow Services 优点 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 Design Service Interface 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 Service Interface定义 服务接口Service Interface是服务提供的进入点: • 服务接口service interface是一个软件实体,它实现为 处理映射和转换服务的外观facade组件 • 与服务进行通讯,并强制执行通讯的处理流程及原则 • 服务接口暴露方法,这些方法可被个别调用或以特定 的顺序被调用 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 32 Service Interface作用 z 提供业务处理的调用点; z 实现了缓冲,映射,以及简单的格式和架构转换; z 不实现业务逻辑; • 通过Service Interface将应用程序业务逻辑与通信协议、数据 转换和服务合约SLA履行分开 z 进行消息安全控制 z 区隔内部系统实现 • 为对内部实现进行变更时,不需要变更服务接口 • 需要验证传进的消息 17 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 33 Design Service Interface z 设计服务接口特点: • 将服务接口视为应用程序的信任界限。 • 同一功能发布多种service interface服务接口,不同 的服务接口service interface可以执行不同的服务水 平协议SLA,以及不同事务处理能力。 • 实现facade外观组件,帮助隔离业务的变化 • 交易性传输 或非交易性的传输 • 尽可能提高与其它平台和服务的交互操作性 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 34 Service Interface 实现 服务接口使得使用者和提供者之间能够交换信 息,负责实现通信时的所有细节: z 网络协议 z 数据格式 z 安全性 z 服务级别协议 18 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 35 Facade Service interface设计模式 Façade design pattern z 目标:子系统提供单一接口给用户端 z 问题:子系统内的class分别提供部分功能,用户端必须调用个别的class, 导致两层间联系复杂,不易维护,违反Encapsulation原则 z 效果:简化设计,易于维护 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 36 实现服务接口的方式 根据要如何显露应用程序或服务的功能,实现 服务接口不同的方式有: z XML Web 服务 • 可以使用 ASP.NET Web 服务网页,或使用 SOAP 和 HTTP,通过 .NET Remoting显露某些组件。 z 消息队列方式 • 一般采用Enterprise Service中的Queues Component组件,用户监听程序,或Message Queuing Triggers 去发起调用 19 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 37 Business façade 组件 z 通过实现外观façade部分,可以将策略相关的程序代码(例如授权验证, 审计,验证,等等)整合于一处,使其可在处理各种通道的不同服务接口 service interface上重用。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 38 Service Interface事务管理 z 在设计交易界限时,保证操作可以在发生错误时 重试 • 保证建立事务的各种资源 • 标记事务发起组件的属性为"require transaction“ • 保证所有的子组件事务属性设置为"require transaction"或" support transaction"属性 z 利用Message Queuing的事务消息机制 z 如果消息机制不支持事务,必须在服务接口 service interface的代码中发起根事务 20 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 39 Service Interface 优缺点 优点 z 服务接口机制与应用逻辑分隔。 z 部署灵活性。 缺点 z 接口粒度设计 z 增加在更改服务所需的工作量。 z Service Interface 增加了复杂性和性能开销 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 40 例: ASP.NET Web Service实现 Service Interface [WebMethod] public Recording Get(long id) { /* */ } 定义一个提供互操作性合约 z 指定 XML 架构 • 使用 XML 架构定义数据 传输对象 z 数据传输对象 • 使用平台特有工具生成 数据传输对象 z 服务接口实现 • 指定了至少一个标记有 [WebMethod] 属性的方 法 21 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 41 Business Entities Design ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 42 Business Entities引入 z 应用程序的逻辑可能在设计中需要考虑多种数据格式 z 通过Business Entities提供了一个中间层 • 将显示数据与实际的存储区隔,保证了业务实体的独立性,提 高了可重用性 Business Workflows Service Interfaces Business Components Business Entities Data Sources Services Data Access Logic Components Service Agents <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> <><><><> <><><><> <<><<> Schemas of Messages coming back Schemas of Messages coming back and forth and forth –– internal or even external tointernal or even external to the enterprisethe enterprise Schemas of Schemas of DatabasesDatabases <><><><> <><><><> <<><<> 22 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 43 Business Entities作用 z 在中间业务层与表现层之间传送数据 z 将显示数据与实际的存储区隔 z 提供更大的可伸缩性 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 44 Business Entity的型式 z DataReader:具有最快的读取速度,用于Forward- ReadOnly的场合,不具有OO概念 z XML:可用于执行查询直接传回XmlReader,或由 DataSet做数据转换 z Generic DataSet:On-Memory database z Typed DataSet:兼具有Generic DataSet的优点与面向对 象设计的优点,多一些overhead z Custom Business Entities :最符合面向对象概念,程序 逻辑简单,但数据转换的overhead最大。 23 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 45 Represent Business Entities as XML 利用XML来表现业务实体,要注意: z 确定XML文档包含一个业务实体还是多个业务实 体的集合 z 用命名空间唯一确认表现业务实体的XML文档 z 为属性attribute和元素element选择合适的名称, 表现业务实体数据 可以用多种方法获取数据 z FOR XML, DataSet, Data reader ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 46 XML BE 优缺点 优点: z 国际标准支持 z 灵活性 z 互操作性 缺点: z 性能 z 保留类型精度 z 验证XML z 显示XML,不能在用户界面自动显示XML数据 z 解析XML,可以用微软.NET Framework类库提供的DOM或 XmlReader类 z XML排序 z 没有私有信息 24 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 47 Generic Dataset BE 普通DataSet是DataSet类的实例 z 灵活性 z 序列化 z 数据绑定 z 排序和筛选 z 用XML进行交互 z 元数据可用 z 乐观锁并发处理 z 可扩展性 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 48 Generic Dataset BE缺点 z 客户端代码必须通过DataSet中的集合来存取数 据,没有类型 String str = (String)dsProducts.Tables["Products"].Rows[0][ "ProductName"]; z 很高的实例化instantiation和调度marshal成本 z 私有信息保护 25 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 49 Typed DataSet BE 强类型DataSet包含强类型方法,属性,以及类 型定义,以显示DataSet中的数据和元数据 z 代码的可读性 String str = dsProducts.Products[0].ProductName; z 强类型DataSet提供的类型方法和属性相比普通 DataSet更容易使用 z 编译时类型检查 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 50 Typed DataSet BE 缺点 z 部署 z 支持Enterprise Services(COM+)调用,必须 有一个强名称strong name z 可扩展性的问题 z 继承,强类型dataset必须从DataSet继承,它就 不能从其他基类继承。 z 性能 26 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 51 Custom Business Entities 分类 z Custom Business Entity Component z Custom Business Entity Component With CRUD ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 52 Custom Business Entities z 实体组件包含数据的快照。它们的数据只能保证与发起 读取事务时上下文环境一致 z 组件储存数据值,并透过其属性加以显露。实体组件用 可设定状态的程序设计方式存取业务数据 z Business entity不直接存取数据库 z Business entities不初始化任何事务交易 z 应将Business entity设计为序列化 z 用户自定义实体组件并不是所有应用必须的一部分 27 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 53 Role of Custom Business Component ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 54 Custom Business Entities 设计建议 z 自定义业务实体实现要简单 z 从封装通用方法的基类(Base Class)继承 z Business entities实现一组公用的接口 z 利用内部数据集datasets或 XML 文件保存复杂 数据 z 将验证规则区隔为元数据 z 设计保证实体之间的关系 z 通过数据存取逻辑组件操作数据库数据 28 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 55 Custom Business Entities 实现原则一 z 为每个实体定义唯一标识 z 在类class或结构struct之间选择 z 显示业务实体的状态 z 在用户自定义业务实体custom Business Entity 中表现子集合以及层次数据 •.NET集合例如ArrayList • 数据集DataSet ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 56 Custom Business Entities 实现原则二 z 支持用户界面控件进行数据绑定 • 如何在Windows Forms中进行数据绑定 • 如何在Web Forms中进行数据绑定 z 为内部数据变化提供事件 z 对业务实体组件进行serializable序列化 • 利用XmlSerializer类进行XML序列化 • 利用BinaryFormatter或SoapFormatter类进行 Formatted serialization格式序列化 29 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 57 Custom Business Entities Component 具体实现 自定义业务实体组件类主要包含以下几个部分 : z 私有成员Private fields z 公共属性Public properties z 方法和属性Methods and proerties z 事件Event ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 58 Custom Business Entities 优点 z 自行控制序列化实现,有利于性能调优 z 区隔内部格式和应用程序所使用的数据结构描述 z 代码可读性 ProductDALC dalcProduct = new ProductDALC(); z 封装。给数据增加自己的操作 z 对复杂系统Modeling建模,用自定义实体类定义一个良 好的接口,将复杂的问题隐藏在类中 z 本地验证。 z 私有成员。可以隐藏你不想显露给调用者的信息 30 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 59 Custom Business Entities 缺点 z 业务实体集合。 • 一个业务实体对象表现单个的业务实体,而不是业务实体的集 合 z 序列化。在业务实体中必须实现自己的序列化机制 z 业务实体对象中表现复杂的数据关系和层次数据。 z 数据查询和排序 z 部署 z 对Enterprise Service (COM+)客户端的支持 z 可扩展性的问题 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 60 带CRUD操作的Custom Business Component 31 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 61 带CRUD操作的Custom Business Component的优缺点 z 带有CRUD操作的自定义业务实体类的优点: • 封装。自定义业务实体封装了下游数据存取逻辑组件的操作 • 接口调用,调用者只需要通过一个接口与业务实体数据打交道 。 • 私有成员。可以隐藏不希望显露给调用者的信息 z 带有CRUD操作的自定义业务实体类的缺点: • 处理业务实体类的集合 • 增加开发时间 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 62 实现业务实体组件 范例 Entity + S tatus + S ave ( ) + Load ( ) + IsDir ty ( ) + Validate ( ) Us e r Organization Region- BelongsTo 1 - BelongsTo 1 业务实体组件对应于逻辑设计中 的业务实体(business entity),它是一类业务数据包含 相关业务逻辑的封装,同时也是 一类业务数据与另一类业务数据 之间关系的封装。 •表达业务数据 •表达实体关系 •实现实体操作逻辑 32 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 63 实现业务实体组件 范例 业务实体对象的状态 InitializedCreated Modified DeletedSynchronized /Load /get entity instance /Save or Load /Delete /Save /touch /new Entity(Guid)/Manager.Create /Manager.Get(Guid) /touch ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 64 Business Entities 形式选择 z 如果应用主要需要集合类型的数据,并且需要 排序,查询或数据绑定等功能,推荐采用 DataSets z 如果应用主要用到实体数据,Custom Business Entities Component更好 33 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 65 业务层与数据层间传送数据 z DTO:数据传输对象。为了将业务实体对象与实际的关系数据存储 是一个松耦合的关系。在Business Layer与 数据库之间加入DTO对 象作为层间传输数据的载体 Business Workflows Service Interfaces Business Components Business Entities Data Sources Data Access Logic Components DTO ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 66 数据传输对象的设计 一个数据传输对象是一个没有业务逻辑但可串 行化(serializable)的数据实体,在实现上可 以是一个只有构造器和简单类型域成员(或属 性)的类或结构体。 z 内部唯一标识与外部唯一标识(int/Guid) z 数据实体成员 z 数据版本信息 – 用于支持并发检测 34 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 67 Business Entities vs Business Component z Business Component • 创建新的业务实体 • 取得业务实体 • 删除业务实体 z 并非所有的情况都必须有业务实体,Business Component可以直接调用DAL层 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 68 O/R Mapping and Patterns 35 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 69 Why ORM-结构不相适应 z NET数据类型与SQL数据类型不相匹配 •SQL自定义类型 • 数据库自己的定义 z 类型继承 • 没有通用的派生模式 z 实体关系 z 集合语义 数据操作方面: z .NET 对象唯一性确认与数据库记录比较 z 多态 z 对象之间的关联关系与数据库表联接 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 70 ORM作用与目标 z 通过结构化的映射使程序更鲁棒 z 减少错误代码 z 始终对性能进行优化 z 数据源独立性 ORM的目标就是: z 利用关系型数据库的优点 z 保持面向对象的语言对象方式 z 做更少的工作,减少DBA压力 36 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 71 ORM 实现 z Transparent Persistence :用面向对象的语言直接操作 关系型数据的能力 z Automatic Dirty Checking:自动进行数据同步问题的检 查 z Transitive Persistence:传递持久层 z Smart Fetching and Catching:实现Lazy Loading, Outer Join Fetching,Runtime SQL Generation功能 z Inheritance Mapping Strategies:派生映射策略 z Develop Tools ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 72 O/R Mapping具体实现方式 z 利用反射机制,在运行时自动产生SQL 语句, 执行OR Mapping的操作 z 通过ORM工具,生成代码,其生成的代码加入 工程中,通过生成的代码来实现OR Mapping z build-time code generation 37 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 73 Object-Relational Structural Patterns -Foreign Key Mapping z 用表之间的外键映射 对象之间的关联关系 z 如何将对象关系变化 存入数据库 • delete and insert • add a back pointer • diff the collection ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 74 Object-Relational Structural Patterns -Identity Field z 对象中保存数据库ID字段以便维护内存中对象与数据库行记录之间 的关系 z 选择Key • 有含义meaningful key还是meaningless key无含义的键 • 简单键simple还是compound组合键 • 选择键的类型 38 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 75 Object-Relational Structural Patterns- Serialized LOB z 将一个对象图进行序列化,变为一个大对象,并将它存 储在数据库中 z 序列化方法 • binary (BLOB) • textual characters (CLOB) z 用Serialized LOB时要小心唯一性的问题,要小心重复数 据 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 76 Object-Relational Behavioral Patterns -Unit of Work 维护对象列表用于记录受到 业务交易 操作痕迹,以处理数据更新问题,以 及并发问题的解决。 z 工作单元Unit of work是一个保存数据 库操作痕迹的对象,如何知道哪些对 象需要保留操作痕迹 • Caller registration • Object registration • Unit of work controller 39 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 77 Object-Relational Behavioral Patterns —Identity Map 建立一个包含一系列从数据库中获取的对象的内存图,在内存图中保存的每 个对象只装入一次,当引用数据时通过内存图来寻找对象 z 模式实现考虑 • Choice of Keys • Explicit or Generic • 一个类建一个Map还是整个Session建一个Map • 基于对象建立还是基于表建立 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 78 Object-Relational Behavioral Patterns—Lazy Load 一个对象并没有包含所有需要的数据,但知道如何去获取数据。 z 有四种实现Lazy Load的主要方法:lazy initialization, virtual proxy, vale holder, 以及ghost方法。 • Lazy initialization • Virtual proxy • Value holder • ghost 40 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 79 Object-Relational Metadata Mapping Patterns -Metadata Mapping 将O/R Mapping 的细节保存在元数据中 z 用Metadata Mapping模式最大的决策是元数据清单中的 信息如何被运行的代码读懂。有两种方法: • code generation :较少动态性 • reflective programming:速度慢,很难进行跟踪调试 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 80 Object-Relational Metadata Mapping Patterns -Query Object 一个表现数据库查询的对象,创建特定的Query Object查找方法, 它隐藏了SQL的参数方法 z Query Object特点 • 能根据不同的数据库生成不同的查询 • Query Object的通用特性是它能在语句中用内存中的对象查询而不是 数据库架构 • 消除多余的数据库查询,如果在一个会话中运行同样的查询,你可以 用它从Identity Map中选择对象 41 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 81 Object-Relational Metadata Mapping Patterns- Repository z Repository是domain与data mapping层的中间层,作为内存中业务 对象集合。Repository是一个由许多其它模式组成的复杂的模式。 它类似于一个小的面向对象数据库。 • Repository 都表现为简单的接口,客户端创建一个criteria对象描述它 们期望返回的对象的特征,以获取所需对象。 • 对于用Repository的代码,它表现为简单的业务对象的内存集合 • 用基于描述的方法进行对象选择 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 82 什么是ObjectSpaces z 用业务对象方式操作数据: Customer, Order, Address z 在对象和关系型数据库表之间进行映射 z 将业务逻辑和数据存取逻辑隔离起来 z 解决主要的不相适应的障碍 • 业务数据存储在关系型数据库中,但业务逻辑是用面向对象的编程方 式进行编写 • 在对象和数据库表之间用SQL语句来传递数据 • 用SQL来传递数据主要问题: • 业务改变容易破坏结构化数据的结构 • 业务逻辑与数据存取代码混在一起 • 随着应用的增长问题更加明显 z 是ADO.NET之上的一层 42 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 83 ObjectSpaces 架构 ADO.NET Command DataBase Translation Engine ADO.NET DataReader OR Mapping OP QueryObjects stream OP Engine or = GetObjectReader( typeof(C ustomer), “Name=‘Joe’”) foreach(Customer c in or) { … } Streaming Object query Mapping ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 84 Object Spaces 使用 43 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 85 ObjectSpaces 代码 ObjectSpace os = new ObjectSpace(“mapping.xml”); foreach (Customer c in os.GetObjects(typeof(Customer),“City = Seattle”)) { Console.WriteLine(c.Name); } string query = "SELECT * FROM T_CUSTOMERS WHERE C_CITY=‘Seattle’"; SqlCommand cmd = new SqlCommand(query, new SqlConnection(cnString)); cn.Open(); SqlDataReader r = cmd.ExecuteReader(); while (r.Read()) { Console.WriteLine(r.GetString(1)); } r.Close(); Data Access API Query ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 86 ObjectSpaces比较 中间层比较小,业务逻辑 主要是进行数据格式转换 ,需要跨平台交互 z直接用XML来表现数据 z格式化,支持跨平台应用 SQLXML 需要业务实体对象,不追 求纯粹的性能。 z采用业务对象编程 z通过元数据(XML文件)进行关系映射 z和数据库不是紧耦合 z更适应现实世界的对象 ObjectSpaces 要求高性能,高可控性, 以及一些特定的功能要求 ,适合采用关系型模型的 问题 z利用关系型模型 z性能高 z可控性强 z提供完整的数据库功能 DataSets and DataReaders in ADO.NET 什么时候用优势技术 44 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 87 Why ObjectSpaces in Visual Studio? z 对应于 J2EE: • EJB/CMP - MBF • JDO - ObjectSpaces • JDBC - ADO.NET z MBF的基础系统 • MBF是开发企业应用的描述性架构以及编程模型 z 将三种样式集成起来 • CLR (object-oriented) • SQL (relational) • XML (hierarchical) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 88 MBF 45 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 89 Why MBF —— 业务应用复杂且困难 即使是简单的业务应用开发都需要经过相当的努力才能达到目的 z 需要了解许多技术 • 多种编程语言: OO, SQL, XSL, HTML • 多种编程模型: OO, relational, messages, connected vs. disconnected z 没有一个完整的应用基础架构 – 业务开发人员希望精力集中于解决业务问题,而不是系统集成。 • 产品的维护比较困难 – 产品存在周期大于技术更新周期 z 分布式Web应用的难度 • 现在的应用要求适应多种需求,以及各种终端设备 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 90 Introduction: The MBF Basics z What: Microsoft Business Framework (MBF)提供了一个开发分布式,面向服务架 构应用的抽象和说明性编程架构. z Who: MBF组是由Great Plains, Navision, Daamgard, Solomon, Microsoft,以及其他业界 成员组成,其成员在建立业务应用平台/框架上有很多经验。 z When: MBF将通过两个Visual Studio 版本发布. z Where: MBF组是Visual Studio division一部分,并且MBF将独立于任何Microsoft Business Solutions 产品单独发布 46 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 91 Microsoft Business Framework Components Delivered with Whidbey Data Access Role-Based Security MetadataMsg & Integration Foundation Services Data TypesEntities Patterns .NET Enterprise Servers & Visual Studio .NET Tools Application Framework Deployment Tools Component Programming Model Business Solution Framework (Class Libraries) Customization User Interface Process Execution Reporting & Query Component Modeler Test Services Form Designer Process Designer Report Designer Deployment Packager Data Access Mapper ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 92 Business Entity Designer Provides alternate editing and viewing experience 47 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 93 MBF in Whidbey z 编程模式元素 • Entity, Activity, Operation • BI Entity, Business Component z 事件代理 z 基于角色的安全 z 元数据库 z Tools • Prescriptive code editor • Component Explorer • Data Access Mapper (White Horse) • Component Modeler (White Horse) • Code generators 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 Data Access ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 我们所讨论的问题 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 隔离BLL和数据访问逻辑的好处 z 增加代码重用性,例如GetProducts(),可以被 业务逻辑层的很多地方反复引用 z 尽可能消除业务逻辑层对数据源的依赖(由于数 据源改变所造成的影响极小化)。 DAL可以通过 配置文件进行改变(如ORACLE或SQL Server) z 隐藏了数据操作的细节,可以实现各种优化。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 DAL Components的实现 z DAL Components提供了一组无状态的方法来实 现对数据源的操作 • 如GetProducts,CreateProduct等 •DALC提供了对Database Schema的访问 z DAL Components的接口定义和划分 z DAL Components和交易 z DAL Components的输入输出参数 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 DAL Components的接口定义和划分 z 最好先定义好DAL Components的接口 • 这样可以通过不同Factory类来建立不同DAL实现类 z 如何划分DAL Components • 如果不使用Com+,可以考虑按照业务实体进行划 分,如IProductsDAL,IOrderDAL • 某一个Component最好只访问一种数据源 • 如果使用Com+,需要考虑交易模型问题 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 DAL Components和交易 z DAL Components通常不是交易的起点 • 如果DAL Components不是Com+的Components, 如何保证交易完整性? • 如何传递交易上下文? • 交易是否跨越不同的数据源(分布式交易)? ITransaction trans = (ITransaction)ContextUtil.Transaction; conn.EnlistDistributedTransaction(trans); 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 DAL Components的输入输出参数 z 方法调用的输入参数 • 一般读操作所要传递的参数-查询条件、分页信息 • 一般写操作需要转递的参数 • UpdateProduct(productID, name, price, …) z 方法调用的返回值 • 普通类型 • DataSet或定制的数据结构 • Stream类型的对象 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 DAL Components和存储过程 z 很多操作可以利用存储过程来实现 • 利于优化和提高性能 • 利于将某些两维表的结果集转换为另外一种两维表 z 但是需要考虑到那些操作不适合使用存储过程 • 查询/修改的条件或参数是变化的 • 存储过程尽量避免实现业务逻辑 • 有些操作用SQL语句很难写(字符串处理) 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 一个通用Data Access Helper z 作用 • 为DAL提供通用的数据访问接口 • 减少数据访问操作的代码 • 简化执行SQL语句和调用存储过程的代码 • 进行数据库连接的管理 • 包括数据库名称、认证信息等 • 在不同的数据源之间,可以提供统一的接口,如 SQL Server、ODBC、OLEDB等 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 Microsoft Data Access App Block z 作用-简化数据访问的代码 • 一个简单的查询 • 带参数的查询 SqlConnection conn = new SqlConnection(connection); SqlDataAdapter adapter = new SqlDataAdapter(); adapter.SelectCommand = new SqlCommand(query, conn); adapter.Fill(dataset); SqlConnection conn = new SqlConnection(connection); SqlDataAdapter adapter = new SqlDataAdapter(); SqlCommand cmd = new SqlCommand(query, conn); cmd. myCommand.Parameters.Add(“@category”, “Computer”); cmd. myCommand.Parameters.Add(“@name”, “Design Pattern”); adapter.SelectCommand = cmd; adapter.Fill(dataset); 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 Microsoft Data Access App Block z 可以简化成一句话调用 z DAAB可以将大多数数据访问减化成一句话的调用 • 将DataAdapter和Command的操作包装起来 • 简化带参数的查询 • 能够提取存储过程的参数并保存下来,简化存储过程的调用 •… DataSet ds = SqlHelper.ExecuteDataSet( connectionString, CommanType.Text, strSQL, new SqlParameter("@category", "Computer") new SqlParameter("@name", "Design Pattern") ); ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 简介SQLHelper类 z 封装了所有数据访问方法,全部是静态方法 z 关于查询,共分为五类方法 • ExecuteDataset, return DataSet • ExecuteNonQuery, return int • ExecuteReader, return SqlDataReader • ExecuteScalar, return object • ExecuteXmlReader, return XmlDocument • 以上每一类都对应着九种不同参数的重载 • connectionString, commandType, commandText • connectionString, commandType, commandText, commandParameters • connectionString, spName, parameterValues • connection, commandType, commandText • transaction, commandType, commandText •… 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 简介SQLHelper类 z 对参数的支持 string strSQL = "SELECT * FROM CUSTOMERS WHERE CUSTOMER_ID= @CUSTOMER_ID"; DataSet ds = SqlHelper.ExecuteDataSet( connectionString, CommandType.Text, strSQL, new SqlParameter("@CUSTOMER_ID", "LI_AN")); ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 简介SQLHelper类 z FillDataset系列,将查询结果填充到一个已经存 在的DataSet中 z 对存储过程有特殊的支持,可以获得存储过程 的参数类型定义,使得调用存储过程比较简单 SqlHelper.ExecuteDataset( _connectionString, CommandType.StoredProcedure, “Order_Select”, 1, //是存储过程的参数 “LI_AN” //是存储过程的参数); 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 简介SQLHelper类 z 通过强类型的DataRow调用存储过程 • 存储过程的参数定义是存储在Cache中(静态变量) CREATE PROCEDURE Order_Insert @Description varchar(100), @Amount money, @CustomerID int As Insert into [Order] ( [Description], Amount, CustomerID ) values ( @Description, @Amount, @CustomerID ) return SCOPE_IDENTITY() ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 简介SQLHelper类 z 对强类型的DataRow的支持 • Execute…TypedParams系列 • ExecuteNonQueryTypedParams • ExecuteDatasetTypedParams • ExecuteReaderTypedParams • ExecuteXmlReaderTypedParams • 参数特点:最后一个参数是一个DataRow Orders.OrderRow order = orders.Order.AddOrderRow(0, "New order", 100, 1); int count = SqlHelper.ExecuteNonQueryTypedParams( _connection, "Order_Insert", order); 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 Microsoft Data Access App Block存在的问题 z 如果企图实现OLEDB接口的 SQL Helper,只能将所有方法 重写 z 很难写出既支持OLE DB,又 支持SQL Server的应用程序 (ADO本身定义了 IDbConnection、 IDbCommand、 IDataAdapter…) z Execute系列函数需要传递连接 对象或连接串,如果用连接的 逻辑名称怎么办? z 如果我需要设置某一查询的超 时时间怎么办? ExecuteDataset, return DataSet ExecuteNonQuery, return int ExecuteReader, return SqlDataReader ExecuteScalar, return object ExecuteXmlReader, return XmlDocument 以上每一类都对应着九种不同参数的重载 connectionString, commandType, commandText connectionString, commandType, commandText, commandParameters connectionString, spName, parameterValues connection, commandType, commandTe transaction, commandType, commandTe … ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 DAAB 3.0简介 z 基于接口和工厂的设计,既支持了不同的数据 源,也提高了代码重用性 z 目前实现了SQL Server、OLE DB以及ODBC版 z 可以通过配置文件动态地决定使用哪一种实现 z 良好的测试程序 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 AdoHelper + GetConnection ( ) # GetDataAdapter ( ) # DeriveParameters ( ) + GetParameter ( ) + CreateHelper ( ) + CreateHelper ( ) + GetParameter ( ) # AttachParameters ( ) # AssignParameterValues ( ) # AssignParameterValues ( ) # PrepareCommand ( ) # ClearCommand ( ) + ExecuteDataset ( ) + ExecuteDataset ( ) + ExecuteDataset ( )... Odbc + Odbc ( ) + GetConnection ( ) # GetDataAdapter ( ) # DeriveParameters ( ) + GetParameter ( ) # PrepareCommand ( ) OleDb + OleDb ( ) + GetConnection ( ) # GetDataAdapter ( ) # DeriveParameters ( ) + GetPa ram eter ( ) SqlServer + S qlS erver ( ) + GetConnection ( ) # GetDataAdapter ( ) # DeriveParameters ( ) + GetParameter ( ) # ClearCommand ( ) + ExecuteXmlReader ( ) + ExecuteXmlReader ( ) + ExecuteXmlReader ( ) + ExecuteXmlReader ( ) + ExecuteXmlReader ( ) + ExecuteXmlReader ( ) + ExecuteXmlReaderTypedParams ( ) + ExecuteXmlReaderTypedParams ( ) ProviderA lias + «property» AssemblyName : string + «property» TypeName : string - _assemblyName : string - _typeName : string + ProviderAlias ( ) + «get» AssemblyName ( ) + «get» TypeName ( ) DAABSectionHandler + C re ate ( ) ADOHelperParameterCache ~ CloneParameters ( ) + CacheParameterSet ( ) + GetCachedParameterSet ( ) Only a summary of methods is shown... ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 可以通过继承ADOHelper定制自己的Helper类 z 可以通过重载GetConnection实现传递连接的逻辑名 z 可以通过重载PrepareCommand为Command对象属性 的设置 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 可以根据配置文件选择Provider z 配置文件 z 用于AdoHelper.CreateHelper(工厂) • AdoHelper.CreateHelper(“account”)
©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 总结 z DAL的设计需要注意哪些问题 • 方法之间调用的无状态性 • 接口定义与实现分开,注意接口的划分 • 方法调用的和返回的参数设计 • 交易!!! • 存储过程的使用 z Data Access Helper • 建议,从SqlServer Class或OleDbClass派生你自己的Helper类 • 无论是2.0版,还是3.0版,都没有提供数据库连接管理 z 参考文档 • Application Architecture for .NET: Designing Applications and Services • Data Access Application Block Documentation(MSDN) • Data Access Block 3.0 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 XML设计、数据架构规划 与数据库设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 议题 (1)数据库的设计原则 (2)数据库设计与类的设计融合 (3)数据库设计与XML设计融合 (4)数据库性能规划 (5)在数据库封装设计 (6)数据库安全设计 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 数据库的设计原则 z 范式规则 z 以空间换时间原则 z 事务设计原则 z 存储过程设计原则 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 数据库设计与类的设计融合 z 类设计与表设计 z ER设计 z 面向对象数据库设计 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 数据库设计与XML设计融合 z Xml Schema Document与Xml z XSD与表的设计 z 利用设计工具完成设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 数据库性能规划 z 分区设计 z 分层设计 z 分库设计 z 索引设计 z 数据分析技术 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 在数据库封装设计 z 数据库集成业务逻辑 z SQL 2005新特性与数据库设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 数据库安全设计 z 数据库加密设计 z 数据库自身安全设计 1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 通讯设计 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 通讯策略 z 三要素:同步性、格式和协议 z 模式: • 无连接:基于消息 • 有连接:DCOM/.NET Remoting/RMI z 考虑因素: • 扩展性 • 可用性 • 可管理性 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 通讯选择 z 应用间通讯: • 建议采用消息方式: • XML Web Service • Message Queuing z 应用内通讯: • 尽量使用基于消息机制的层间通讯 • 例外:事务/身份流 z 建议: • 尽量使用Queue和Cache技术 • 在UI、SI和SA上使用异步技术 • 评估封装异步操作实现同步操作 总线模型(1) z 消息总线同时应用于层间 和外部应用 z 优点 • 模块化提高集成性 • 异构平台 z 问题 • 业务层依赖UI层的信息 • 消息总线要支持多种通 讯 • 消息总线要实现满足层 间和外部应用的灵活性 和可用性 3 总线模型(2) z 消息总线只应用与外部 应用之间 z 优点: • 系统效率 • 设计和实现简单 z 问题: • 降低了系统的扩展能力 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 异步消息通讯机制的优点 z 扩展性和可用性 • 更短的响应时间 • 更容易实现负载均衡和容错 z 可实现透明的服务定位 z 更符合现实的业务模式 z 更容易定义SLA z 传输协议的无关性 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 异步消息通讯机制的缺点 z 无状态 z 无消息匹配机制 z 消息延迟 z 没有事务处理 z 可能存在重复性消息 z 无消息序列 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 异步处理需要考虑的问题 z 状态通知和轮询 z 处理超时情况 z 创建和执行补偿操作 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 基于消息的应用 z 核心应用 z 大型分布式系统 z 对外的服务应用 z 需要离线操作的应用 • 可能需要处理同步冲突 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 异步通讯 z 基于消息的技术 • Message Queue • XML Web Service z 基于连接的技术 • .NET Remoting •DCOM 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 Message Queue z 优点和特点 • 基于Internet的存储转发机制 • 确保顺序和可靠性的通讯机制 • 可以利用群集技术实现高可用性 z 设计要点 • 发送和接收方式 • 消息格式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 其它异步技术 z Queued Component z Message Queuing triggers z Custom Receivers z XML Web service proxy z NET Remoting channels 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 同步技术 z Channel技术 • 端点 • 协议 • 格式 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 同步,还是异步?这是个问题 1. 需要事务流或者安全认证信息? 9 DCOM 2. 开放给外部系统? 9 XML WebService • 需要封装业务功能? 9ASP.NET Webservice 8SOAP 3. 需要认证调用者? 9 以IIS为Hosting的.NET Remoting Channel 8 采用任意的.NET Remoting Channel 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 通讯的格式、架构和协议 z 决定因素: • 发送和接收的可控性 • 对性能和安全的要求 • 与企业外应用的交互要求
还剩383页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

benney

贡献于2015-01-27

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf