Software Process Management 软件过程管理

1、1,Unit Eight,Software Process Management Chen Gang International School of Software, WHU,2,软件过程管理,Unit Eight,第八单元 Rational统一软件过程 陈刚 武汉大学国际软件学院,3,目录,一、最佳的软件开发实践 二、RUP 三、静态结构：过程描述 四、动态结构：迭代开发 五、以架构为中心的过程 六、用例驱动的过程,Unit Eight,4,一、最佳的软件开发实践(1),Unit Eight,软件的价值,软件已经成为我们这个现代世界中不可缺少的一部分。 网络使构造和维护软件产品变得越来越困

2、难，而以循环的、可预测的方式构造高质量的软件产品仍很困难。,5,一、最佳的软件开发实践(2),Unit Eight,软件开发问题的症状和根本原因,症状 对于最终用户的需求理解得不够精确 不能处理需求变更 模块之间不兼容 软件不易维护和扩展 对项目的严重缺陷发现较晚 软件质量低劣 软件性能无法让人接受 一个不可靠的构造和发布过程,6,一、最佳的软件开发实践(3),Unit Eight,软件开发问题的症状和根本原因,根本原因 一次性的需求管理（不可重复） 模糊和不精确的交流 脆弱的架构 过度复杂 未检测出需求、设计和实现中的不一致 测试不足 对项目状况的估计过于主观 未解决存在的风险 无法控制变化

3、的传播 自动化程度不足,7,一、最佳的软件开发实践(4),Unit Eight,最佳的软件实践,软件的迭代开发 需求管理 应用基于构件的架构 为软件建立可视化的模型 对于软件质量进行持续的验证 控制软件的变更,8,一、最佳的软件开发实践(5),Unit Eight,软件的迭代开发,Figure The waterfall lifecycle,9,一、最佳的软件开发实践(6),Unit Eight,软件的迭代开发,Figure An iterative and incremental process,10,一、最佳的软件开发实践(7),Unit Eight,软件的迭代开发,迭代的软件开发可以提供

4、一系列的解决软件开发根本问题的方案： 可以在生命周期早期发现严重的需求理解错误 允许并鼓励用户反馈，从而抽取系统真正需求 使开发团队集中关注项目中最关键的问题，并屏蔽掉那些分散他们对项目真正风险注意力的问题 持续的、迭代的测试可以为项目状况给出客观评估,11,一、最佳的软件开发实践(8),Unit Eight,软件的迭代开发,迭代的软件开发可以提供一系列的解决软件开发根本问题的方案： 需求、设计和实现中的不一致能够在早期被发现 在整个项目的生命周期中，可以更加平均地分配整个团队，尤其是可以平均分配测试团队的工作量 团队可在过程中总结经验教训，不断改善开发过程 项目相关人员可以通过具体证据来了解

5、项目情况,12,一、最佳的软件开发实践(9),Unit Eight,需求管理,软件密集型系统的需求管理的挑战在于它们的动态性。 明确一个系统的真正需求是一个持续的过程。 管理项目需求可以提供一系列的解决软件开发根本问题的方案： 在需求管理中内建规程化的方案 人员之间的交流建立在已定义的需求之上 区分需求优先级，并进行过滤与跟踪 可以对功能和性能做出客观的评估 借助适当的工具支持，使用与外部文档的自动链接，可以为系统的需求、属性和轨迹提供库支持,13,一、最佳的软件开发实践(10),Unit Eight,应用基于构件的架构,构件Component 架构Architecture 一个系统的架构包含

6、关于以下元素的一系列的重要的结论： 软件系统的组织 组成系统的结构元素以及它们的接口的选择 它们的行为，通过这些元素之间的协作来说明 将这些结构元素和行为元素组合成为较大的子系统 指导组织的架构风格：这些元素和它们的接口，它们的协作和组合,14,一、最佳的软件开发实践(11),Unit Eight,应用基于构件的架构,使用基于构件的架构可以提供一系列的解决软件开发根本问题的方案： 构件有利于创建灵活性强的架构 模块化可以清晰地分离出系统中易于变化的元素 通过应用标准化的框架（如COM+、CORBA和EJB）和商业上可获取的构件使复用更加容易 构件为配置管理提供一个非常自然的基础 可视化建模工具

7、为基于构件的开发提供自动化支持,15,一、最佳的软件开发实践(12),Unit Eight,为软件建立可视化模型,Figure Modeling a system from different perspectives,16,一、最佳的软件开发实践(13),Unit Eight,为软件建立可视化模型,模型是现实的简化，它从一个特定的角度完整地描述了一个系统。 为软件建立可视化模型可以提供一系列的解决软件开发根本问题的方案： 通过用例和场景可以无二义性地详细说明行为 通过模型可以无二义性地理解软件设计 暴露出非模块化的和不灵活的架构 必要时可以隐藏细节 无二义性的设计可以更容易地反映出不一致性

8、高质量的应用程序应该从好的设计开始 可视化建模工具提供对UML建模的支持,17,一、最佳的软件开发实践(14),Unit Eight,对软件的质量进行持续的验证,在完成部署之后再去查找软件问题，所付出的代价要比在早期进行这项工作高出1001000倍。,Figure The cost of fixing problems,18,一、最佳的软件开发实践(15),Unit Eight,对软件的质量进行持续的验证,验证一个系统的功能测试活动的主要工作包括对每个关键场景进行测试。 对软件质量进行验证可以提供一系列的解决软件开发根本问题的方案： 对于项目状况的评估是客观而非主观的，因为我们评价的是测试结果

9、而非书面文档 这个客观的评估可以暴露需求、设计和实现中的不一致 测试和验证的工作关注的是高风险区域，因此增加了这些区域的质量水平和效率 可以尽早发现缺陷，从根本上降低修复它们的代价 自动化测试工具提供了对功能、可靠性和性能的测试,19,一、最佳的软件开发实践(16),Unit Eight,控制软件的变更,要将迭代过程和发布协调一致，就要在每次迭代结束时建立并发布一个已测试过的基线。 控制软件的变更可以提供一系列的解决软件开发根本问题的方案： 定义需求变更的工作流，且需求变更的工作流可重复 变更请求使交流更加清晰 独立的工作空间减少了并行工作的团队成员之间的相互干涉 变更率统计表为客观评估项目状

10、况提供了很好的度量 工作空间包含了所有制品，这样有利于保持一致性 变更的传播是可评估和可控制的 可以在一个健壮的、可定制的系统中维护变更,20,一、最佳的软件开发实践(17),Unit Eight,RUP,软件开发过程有四种角色： 为团队的活动顺序提供指导 详细说明开发哪些制品以及何时开发 指导每一个开发人员和整个开发团队的任务 为监控和度量项目的产品和活动提供标准,21,二、RUP(1),Unit Eight,什么是RUP,RUP是一种软件工程过程 RUP是一个过程产品 RUP也是一个过程框架 RUP以一种大多数项目和开发组织都能适应的形式，吸收了许多现代软件开发中的最佳实践。,22,二、R

11、UP(2),Unit Eight,作为产品的RUP,RUP本身也是一个软件产品： IBM公司定期地发布升级版本 利用网络技术可以在线交付RUP RUP与IBM公司的Rational系列软件开发工具集成，开发人员可以在这些他们使用的工具中获得过程指导,将过程作为一种软件产品有如下好处： 过程从不会过时 所有项目人员可通过公司内网访问过程配置的最新版本 便于查找及时更新的过程指导或策略，包括最新模板 通过超链接导航至开发工具或指导文档 可以很容易地包含特定项目或程序 每个项目或部门可管理他们自己的过程版本或过程变体,23,二、RUP(3),Unit Eight,作为产品的RUP,第一维代表过程被激

12、活时动态的一面：通过周期、阶段、迭代和里程碑表示。 第二维代表过程静态的一面：通过过程构件、活动、规程、制品和角色来描述。,Figure Process structuretwo dimensions,24,二、RUP(4),Unit Eight,RUP中的最佳软件实践：迭代开发,它可以使你考虑需求的改变。 集成工作不是最后结尾时的“大爆炸”；相反，元素是逐渐集成起来的。 迭代开发可以在早期降低风险，因为通常只有在集成过程中才能发现或找到风险。 对产品做战略性改变时，迭代开发提供了相应的变更管理方法。 迭代开发可以方便复用。 因为可以在几个迭代过程中不断修正错误，所以架构会变得更加坚固。 开发

13、人员可以在过程中不断学习。 开发过程本身也在不断地提高和精化。,25,二、RUP(5),Unit Eight,RUP中的最佳软件实践：需求管理,需求管理是一种系统性的方法，用于抽取、组织、交流、和管理软件密集型系统或应用程序中不断改变的需求。 有效的需求管理具有以下优点： 更好地控制复杂项目。 提高软件质量和客户满意度。 降低项目成本和延迟。 增强团队中的交流。,26,二、RUP(6),Unit Eight,RUP中的最佳软件实践：架构和构件的使用,RUP的设计活动，是以架构（Architecture，系统架构或软件架构）为中心的。 RUP提供了一个设计、开发、验证架构的系统性的方法。它还提供

14、了一个模板，用以描述建立在多重架构视图概念基础上的架构。 软件构件（Component）是软件、模块、包或子系统的一个重要部分，它完成了一个明确的功能，有着明确的界限，并能够集成到一个定义良好的架构中。,27,三、静态结构：过程描述(1),Unit Eight,RUP的模型,一个过程描述了谁做、做什么、怎么做和什么时候做。 RUP应用了五种主要的元素来描述：角色（谁做）、活动（怎么做）、制品（做什么）、工作流（什么时候做）、规程（上述四种元素的“容器”）。,28,三、静态结构：过程描述(2),Unit Eight,角色,角色定义了个人或团队的行为和职责。 每个角色都与一组内聚的活动相联系。 每

15、个角色的职责通常与某一特定制品（artifact）相联系，制品通常由角色创造、修改和控制。 角色可以分为五大类：分析人员、开发人员、测试人员、管理人员、产品和支持。,29,三、静态结构：过程描述(3),Unit Eight,活动,活动有明确的目的，通常是生产或更新制品（如模型、类或计划）。每个活动都被分配给一个特定的角色。 一些活动的例子： 计划迭代过程 寻找用例和活动者 评审设计 执行性能测试 活动分解为不同的步骤，步骤主要分为三类：思考步骤、执行步骤、评审步骤。,30,三、静态结构：过程描述(4),Unit Eight,制品（Artifact）,活动有输入制品和输出制品。制品是项目的有形产

16、品。 制品有以下不同的形式： 模型，如用例模型或设计模型。 模型元素一个模型中的元素，如类、用例或子系统。 文档，如一个业务案例或软件架构文档。 源代码。 可执行文件。 制品不等同于文档。制品很可能受到版本控制和配置管理的影响。 报告不同于一般的制品。它是由制品生成的相关信息。 制品集合包括：管理集、需求集、设计集、实现集、部署集。,31,三、静态结构：过程描述(5),Unit Eight,制品（Artifact）,Figure Major artifacts of the RUP,32,三、静态结构：过程描述(6),Unit Eight,制品（Artifact）,在一个迭代开发过程中，在你进

17、入下一个阶段之前，各种制品并不会在一个阶段产生、完成甚至固定下来。相反，信息集是在整个开发周期中不断完善的。,图 不断成长的信息集,33,三、静态结构：过程描述(7),Unit Eight,规程（ Disciplines ）,规程是用来组织过程活动的“容器”。 在RUP中有9个主要规程，分为6个技术性规程和3个支持性规程。 技术性规程包括： 业务建模规程 需求规程 分析和设计规程 实现规程 测试规程 部署规程 支持性规程包括： 项目管理规程 配置和变更管理规程 环境规程,34,三、静态结构：过程描述(8),Unit Eight,工作流（ Workflow ）,是一个产生具有能看到的价值的成果的

18、有意义的活动序列。在UML术语中，一个工作流可以表示为一个顺序图、协作图或活动图。 RUP使用三种类型的工作流： 核心工作流，它与每个规程都有关。 工作流细节，它精化了核心工作流。 迭代计划。,35,三、静态结构：过程描述(9),Unit Eight,36,三、静态结构：过程描述(10),Unit Eight,附加过程元素,在规程中组织的角色、活动、工作流和制品表示了RUP中静态结构的主干。但还有一些附加于活动或制品的元素，它们使得过程易于理解和使用。并为实践者提供全面的指导。 这些附件的过程元素是： 指南（guideline） 模板 工具指南（tool mentor） 概念,37,三、静态结

19、构：过程描述(11),Unit Eight,附加过程元素,Figure Adding templates, tool mentors, and guidelines,38,三、静态结构：过程描述(12),Unit Eight,过程框架,在静态结构中，RUP组成了一个过程框架（framework）。 角色、制品、活动、指南、概念和工具指南都是可以添加或替代的元素，从而发展和修改这个过程以满足组织的需要。 RUP组织都是建立在一个业界标准的基础之上的，该标准叫做“软件过程工程元模型”（Software Process Engineering Metamodel，SPEM）。,39,四、动态结构：迭

20、代开发(1),Unit Eight,顺序开发过程,阶现在越来越多的人开始指责顺序软件开发过程，即瀑布式模型。,Figure The sequential process,40,四、动态结构：迭代开发(2),Unit Eight,顺序开发过程：错误假设1需求是固定的,需求是会改变的。我们必须接受这个事实。 用户会改变：当开发周期较长时，用户会根据他的所见所闻改变其需要。 问题会改变。当已经完成或即将完成一个系统时，系统本身也会影响用户的想法。 技术基础会改变。 市场会改变。 不可能得到足够详细和精确的需求。形式化方法虽然做了有益的探索，但仍然无法被广泛接受。,41,四、动态结构：迭代开发(3),

21、Unit Eight,顺序开发过程：错误假设2我们可以在进行开发之前做出正确的书面设计,正确的设计意味着：正确性、高效性、可行性。 采用严格和复杂的技术，可以部分达到这些质量要求，但是这些技术很难使用，并且要求对问题有一个形式化的定义。 软件工程至今也没有达到这样的水平：保证做出的设计是问题的正确解决方案。,42,四、动态结构：迭代开发(4),Unit Eight,顺序开发过程：提出风险分析,在需求比较明确等情况下，顺序过程还是有作用的。 但是要完成一个充满了新意、未知和风险的项目，顺序过程就不起作用了。 无法预测将会遇到什么困难，更谈不上如何解决它们。唯一能做的就是将日程安排得宽松一些，然后

22、等待它们的来临。 软件开发是一个充满风险的领域，这就是提出要进行风险分析的原因。,43,四、动态结构：迭代开发(5),Unit Eight,顺序开发过程：延长时间、减少文书工作,如果软件开发人员知道他们的工作将在两三个月内完成，他们就会对最终的产品保持足够的关注。 如果开发周期很长，进展的度量是通过书面记录或图表而不是操作特征做出的。没有实际的东西，就没有激励开发人员的因素。 对当前活动的质量几乎没有反馈，在最后集成和测试时才能发现错误，但这可能要等很长时间。 对每一个活动，开发人员只进行一次，因此缺少改进的机会。 顺序过程过分重视文档的产生和固定，对以前工作步骤只有有限的反馈，而且这些反馈无

23、法被系统地考虑。,44,四、动态结构：迭代开发(6),Unit Eight,顺序开发过程：基于规模和基于时间的计划,在很多产业中，按时交付产品并为新的特性留一些回旋余地，比交付一个完整的、特性完备的、完美的系统要重要得多。 为了做到按时交付产品，你必须学会放弃或推迟完成一些特性以按时交付需要增加的有价值的部分，从而动态地调整产品内容。 基于时间的计划不适合迭代，而基于规模的计划则适合。,45,四、动态结构：迭代开发(7),Unit Eight,克服困难：迭代,为什么不把长期的大型项目分解为可连续应用瀑布模型的几个小部分？ 可先分析一部分需求和风险，设计、实现并确认了这一部分后，再做更多的需求分

24、析、设计、实现和确认，如此进行下去，直到整个项目完成为止。 这就是迭代开发。,46,四、动态结构：迭代开发(8),Unit Eight,克服困难：迭代,Figure From a sequential to an iterative lifecycle,47,四、动态结构：迭代开发(9),Unit Eight,克服困难：迭代,实际上，一个迭代过程不像一个瀑布项目，活动是按照一个更随机、巧妙、合适的方式来排列的。 迭代技术很容易说明，但不容易做到。问题包括： 它是如何将各阶段的结果聚合成一个产品的？如何避免在混乱中开始一个迭代周期？ 在每个迭代开发周期中，你选择做什么？你将要考虑哪些需求并考虑什

25、么样的风险？ 这个方法怎样解决在以前提出的主要问题？,48,四、动态结构：迭代开发(10),Unit Eight,获取控制：阶段和里程碑,从项目管理角度来看，需要一种方法对整个项目的进展进行评估，以确保不是漫无目的地从一个迭代过程进入另一个迭代过程，而是为了聚合产生出最终产品。 在里程碑（milestone）上，我们可以决定是继续、终止或是改变过程。 我们必须通过特定的短期目标来分割、组织迭代次序。将根据用例或特性完成的数量、测试通过用例的个数、是否满足客户的性能需求以及风险是否降低来度量项目的进展。,49,四、动态结构：迭代开发(11),Unit Eight,获取控制：阶段和里程碑,迭代过程

26、可以组织成4个阶段：初始、细化、构造、移交。 这些阶段与传统的顺序阶段互不相关，每个阶段以一个重要的里程碑结束。 这4个阶段构成一个开发周期，并产生一代软件产品。,Figure The four phases and milestones of the iterative process,50,四、动态结构：迭代开发(12),Unit Eight,获取控制：阶段和里程碑,软件产品产生于初始开发周期（initial development），以后的开发周期称为进化周期（evolution cycle）。 一个产品经历了几个进化周期后，就产生了新一代产品。,Figure Initial and e

27、volution cycles,51,四、动态结构：迭代开发(13),Unit Eight,获取控制：阶段和里程碑,阶段时间的长短会因为项目特定环境的不同而有很大差异。,在每个阶段中，都可以迭代地进行开发，而且每个阶段都包含了一个或几个迭代过程。,52,四、动态结构：迭代开发(14),Unit Eight,生命周期中焦点的转移,每一个迭代过程的工作流包括需求抽取和分析、设计和实现、集成和测试等各项活动。但从一个迭代过程到另一个迭代过程，重点关注的活动是不同的。,53,四、动态结构：迭代开发(15),Unit Eight,阶段重访：初始阶段,初始阶段的主要目标包括： 确立项目的软件范围和边界条件

28、。 识别系统的关键用例，也就是主要的行为场景。 展示至少一个针对某个主要场景的候选架构。 估计整个项目需要的费用和时间安排，并为即将到来的下一阶段（细化阶段）给出详细的评估。 评估风险（不确定性的来源）。,54,四、动态结构：迭代开发(16),Unit Eight,阶段重访：里程碑生命周期目标,评价初始阶段的准则如下： 项目相关人员是否已就项目定义、成本估计和进度安排达成一致。 通过主要用例的忠实度证实的需求理解。 对于成本和进度安排的评估以及优先权、风险和开发过程的可信度。 任何已开发的架构原型的深度和宽度。 实际成本和计划成本的对比。,55,四、动态结构：迭代开发(17),Unit Eig

29、ht,阶段重访：细化阶段,细化阶段的主要目标包括： 以实际能够达到的最快速度定义与确认架构，并将其基线化。 设置构想的基线。 为构造阶段的高可信度计划设定基线。 演示说明基线架构可以在合理的时间以及合理的成本支持这个构想。,细化阶段意味着从不稳定的、灵活的低风险操作进入到高投入、具有巨大惯性的高风险运作阶段。它的活动要确保架构、需求、计划有足够的稳定性，并确保已最大限度地降低风险。,56,四、动态结构：迭代开发(18),Unit Eight,阶段重访：里程碑生命周期架构,细化阶段的主要评价准则与以下问题有关： 产品构想是否稳定？ 架构是否稳定？ 可执行的演示中，主要风险因素是否已经过处理并已确

30、实解决？ 构造阶段计划是否足够详细精确？评估是否建立在可靠的基础上？ 如果在当前的架构语境中，执行当前的计划来开发完整的系统，是否所有的项目相关人员都认可当前的构想？ 实际资源消耗相对于计划消耗来说是否可以接受？,57,四、动态结构：迭代开发(19),Unit Eight,阶段重访：构造阶段,构造阶段的主要目标包括： 通过优化资源和避免不必要的浪费和返工，将开发成本降到最低。 以实际能达到的最快速度达到足够好的质量。 以实际能达到的最快速度生产一个可用的版本（alpha版本、beta版本和其他测试版本）。,58,四、动态结构：迭代开发(20),Unit Eight,阶段重访：里程碑最初的可操作

31、能力,构造阶段的主要评价准则与以下问题有关： 这个版本是否足够成熟稳定，可以在用户群中进行部署？ 是否所有项目相关人员都已准备好将产品向用户移交？ 实际的资源消耗与计划消耗相比是否可以接受？,59,四、动态结构：迭代开发(21),Unit Eight,阶段重访：移交阶段,移交阶段的主要目标包括： 使得用户可以自我支持。 项目相关人员共同完成部署基线，并与构想的评价准则相一致。 以实际可能的最快速度和最高性价比达到最终的产品基线。,60,四、动态结构：迭代开发(21),Unit Eight,阶段重访：里程碑产品发布,移交阶段的主要评价准则与以下问题有关： 用户是否满意 实际的资源消耗与计划消耗相

32、比是否可以接受？,61,四、动态结构：迭代开发(22),Unit Eight,迭代方法的好处,与传统的瀑布方法相比，迭代过程有以下优点： 更早地缓解风险 更容易地管理变更 提高了复用的程度 在整个过程中项目组可以不断地学习 提高整体产品质量,62,五、以架构为中心的过程(1),Unit Eight,模型的重要性,RUP有很大一部分内容是关注建模的。 模型是对现实的简化，它能帮助我们把握整体上不易理解的大型复杂系统。 模型帮助我们理解问题并确定解决问题的办法。 模型不是现实，但最好的模型与现实非常接近。 没有一个模型能涵盖软件开发的各个方面，因此需要多个模型来表示不同的方面。 这些模型要仔细协调

33、，以确保一致性和无冗余。,63,五、以架构为中心的过程(2),Unit Eight,架构,假设要描述一个系统的如下方面： 理解这个系统是做什么的。 理解系统是怎样工作的。 在系统的一部分上工作。 扩展系统。 对系统的部分进行复用，从而建立另一个系统。 而且这个描述要限定在一个比较小的篇幅内，那么你将完成一个系统架构的描述。 架构就是再去掉任何部分，就无法使人理解整个系统和解释它是如何工作的系统描述。,64,五、以架构为中心的过程(3),Unit Eight,架构的重要性,当系统为了适应新的需求而需要扩展和壮大时，架构将变得非常重要。 不好的架构（加上不成熟的过程）常常是项目失败的原意之一。 不

34、使用架构或使用了不好的架构，对于软件项目来说都是一个主要的技术风险。 对于一个以架构为中心的组织，需要做到以下三件事： 理解架构的目的 架构的表示 架构的过程,65,五、以架构为中心的过程(4),Unit Eight,架构的定义,架构包含了关于以下问题的重要决定： 软件系统的组织。 选择组成系统的结构元素和它们之间的接口，以及这些元素项目协作时所体现出的行为。 如何把这些元素逐渐组合成更大的子系统。 架构风格，它将指导系统组织及其元素、它们之间的接口、协作和组合的方式。 架构是设计的一部分，但不是全部。它只涉及一些重要的元素。 架构是和结构及组织有关的，但它并不限于结构，它也处理行为。,66,

35、五、以架构为中心的过程(5),Unit Eight,架构的表示,为了使不同的项目人员能够交流、讨论和推断架构，我们必须以他们都能理解的形式表示架构。 不同的项目人员所关心和感兴趣的是架构的不同方面。因此，一个完整的架构是多维的，而不是平面的。 架构视图（architectural view）是从某一特定角度或某一点上对系统所作的简化描述（抽象），描述中涵盖了系统的某一特定方面，省略了与此方面无关的实体。,67,五、以架构为中心的过程(6),Unit Eight,架构的表示：架构的4+1视图模型,68,五、以架构为中心的过程(7),Unit Eight,架构的表示：架构的4+1视图模型,逻辑视图

36、着重描述系统的功能性需求。逻辑视图是设计模型的抽象，确定了主要的设计包、子系统和类。 实现视图从打包、分层、配置管理（所有权、版本策略等）的角度描述了处于开发环境中的静态软件模块（源代码、数据文件、构件、可执行程序和其他相关的制品）的组织。 进程视图描述了系统在运行时的并发性任务、线程、过程及它们之间的交互作用。 部署视图展示了不同的可执行程序和其他运行时构件是如何映射到底层平台或计算机结点上的。 用例视图包括几个关键场景或用例。最初用来驱动架构的挖掘和设计，但后来用于验证不同的视图。,69,五、以架构为中心的过程(8),Unit Eight,架构的表示：模型和视图,以上关于架构的描述对于模型

37、同样适用。 模型是系统的完整表达，而架构视图只关注对于架构来说重要的方面。 一个架构中重要的元素是对于系统的结构和性能、健壮性、可发展性和伸缩性有着很大影响的元素，是对理解系统起重要作用的元素。 对架构来说，重要的元素包括： 主要的类，特别是那些为主要业务实体建模的类。 将行为赋予这些类的架构机制，如持续性机制和通信机制。 模式和框架。 接口。 主要过程或控制的线程。,70,五、以架构为中心的过程(9),Unit Eight,架构的表示：架构不仅仅是一个蓝图,创建架构，对它进行验证，然后设定基线，这些都是细化阶段的主要目标。 除了软件架构描述之外，最重要的制品就是架构原型。 原型实现了最重要的

38、设计决定，足以用来验证架构，即测试和度量架构。 原型使用后并不会被抛弃，它将贯穿构造阶段，不断进化，并将成为最终的系统。,71,五、以架构为中心的过程(10),Unit Eight,以架构为中心的过程,RUP定义了两个关于架构的主要制品： 软件架构描述（SAD），它描述了与项目有关的架构视图。 架构原型，它用于验证架构并作为剩余部分开发的基线。 这两个关键制品是其他三个制品的基础。它们是： 设计指南，由所做的架构选择决定，反映了模式和习惯用语的使用。 在开发环境中的产品结构，它建立在实现视图的基础之上。 基于实现视图结构的开发团队结构。 在构造阶段，重点转移到为架构的骨架增添内容。 分析和设计

39、过程描述了大部分关于架构设计的活动。同时，这些活动也贯穿了需求规程、实现规程和项目管理规程。,72,五、以架构为中心的过程(11),Unit Eight,架构的目标,智能控制： 架构可以使整个项目得到智能控制并保持智能控制，从而管理项目的复杂性并保持系统的完整性。 保持系统完整性是系统架构师的一贯目标。 通过建立一组通用的参考资料和一个通用的词汇表，达到在整个项目中能够有效地交流和相互理解的目的。 复用： 架构明确了主要的构件及其重要接口，从而可以考虑复用。 在同一领域不同功能的系列产品语境中，架构本身可以复用。 开发的基础： 架构为项目管理提供了基础。计划和人员配备按照主要构件线（层和子系统

40、）进行组织。 架构在细化阶段所做的工作为进一步开发奠定了基础，包括设计指南、规程、风格、模式和复用机制。,73,五、以架构为中心的过程(12),Unit Eight,基于构件的开发,CBD主张应用各种部件而不是手工开发每一个单个元素。有些构件是专门制造的，而另一些是通过搜寻和改造得来的。 构件是一个系统中非常重要、几乎独立的、可替换的部分，在定义良好的架构语境中完成明确的功能。 可以从几个不同的角度看构件： 运行时构件 开发构件（从开发组织的观点看 ） 业务构件,74,五、以架构为中心的过程(13),Unit Eight,其他的架构概念,架构风格： 减少了架构中可能出现的形式，并给架构的一致性

41、设定了某个确定的级别。 架构风格的例子有管道和过滤器、客户服务器、事件驱动风格等。 架构机制： 架构机制是用来为常见的问题提供普遍解决方案的一个类、一组类或一个模式。 架构机制例子有数据库管理系统（DBMS）、事件广播系统和事务服务器。 架构模式： 模式讨论并提出一个普遍解决方案，用于解决某种特定情形下重复发生的设计问题。 例子有模型-视图-控制器（MVC）和对象请求代理（ORB）。,75,六、用例驱动的过程(1),Unit Eight,定义：用例和活动者,用例（use case）：是一个系统执行的动作序列，这些动作对一个特定的活动者产生有价值的可见结果。 活动者（actor）： 是系统之外与

42、系统产生交互的人或事物。 其他几个关键术语：动作（action）、动作序列（a sequence of action）、系统执行（the system perform）、有价值的可见结果（an observable result of value）、特定的活动者（a particular actor）。,76,六、用例驱动的过程(2),Unit Eight,定义：用例和活动者,每一个用例代表一种系统能够提供给银行顾客客户（活动者）的价值。用例的集合组成了使用系统的所有可能的方式。用例名通常能传达出提供给活动者的价值。,Figure A use-case diagram for an ATM,77,六、用例驱动的过程(3),Unit Eight,定义：事件流,在需求规程中用例最重要的部分是它的事件流（flow of event）。事件流描述了活动者与系统之间的工作序列。 用例事件流最终要描述所有可能的过程。选择什么样的路径取决于以下几点：活动者的输入、系统内部状况、超时或出错。,78,六、用例驱动的过程(4),Unit Eight,定义：场景,我们并不想在一个单独用例中表示每一条可能的事件流；相反，我们希望将它们和其他相关的用例事件流结合起来，这样一个分组形成一个用例类。 用例类的实例是贯穿于用例的一个特定事