1、现代软件工程技术,基于UML、OMT和模式应用的系统分析、建模和迭代开发技术,林国璋,2006年10月,课程介绍,一、本课程的内容 本课程的传统名称是系统分析与设计或系统分析与建模。是计算机专业和软件工程专业的核心课程。由于软件工程技术的不断发展，在讨论系统分析与建模时，必须跨越软件工程的多个技术领域，因此，把她称为现代软件工程技术也很确切。,本课程的核心内容是面向对象的分析与建模。围绕这一核心我们需要学习： *面向对象的思想OO *用例技术 *对象建模技术OMT *统一建模语言UML *职责分配技术GRASP *设计模式应用Applying Patterns *统一过程UP,二、本课程的特点
2、与学习方法 本课程属工程技术类课程。 相关技术均通过贯穿全课程的案例研究作深入浅出的阐述，并按照迭代开发过程进行迭代学习，解决了现实问题中令人生畏而又必须解决的分析与设计细节。 本课程不涉及深奥的理论推导，但需要清晰的逻辑思维。只要一丝不苟，勤于思考，就不难学好。,三、本课程的教材与参考书1. 教材：UML和模式应用（原书第三版）李洋 等译原著: Applying UML and Patterns An Introduction to Object-Oriented Anaysis And Iterative Development THIRD EDITION作者: Craig Larman,
3、2. 参考书1) 书名: Objict-Oriented Modeling and Design 作者: James Rumbaugh Michael Blaha William Premerlani Frederick Eddy William Lorensen2) 书名: Objict-Oriented Modeling and Design for Database Applications 作者: Michael Blaha William Premerlani,3)书名: Design Paterns Elements of Reusable Objict-Oriented soft
4、ware 作者: Erich Gamma Richard Helm Ralph Johnson John Vlissides4)书名: Applying Use Case (Second Edition) 作者:Geri Schneider Jason P.Winters 中译本:用例分析技术(原书第2版) 译者:姚淑珍 李巍,5)书名:The Rational Unified Process an Introduction(Second Edition) 作者: Philippe Kruchten 中译本: Rational统一过程引论(原书第2版) 译者:周伯生 吴超英 王佳丽6)书名:T
5、he Unified Modeling language Reference Manual 作者:James Rumbaugh, Ivar Jacobon, Grady Booch 译者:姚淑珍 唐发根,7)书名:UML and C+: A Practical Guide to Object-Oriented Development (Second Edition) 作者:Richard C.Lee William M.Tepfenhart 中译本:C+面向对象开发(原书第2版) 译者:麻志毅 蒋严冰,第一部分 绪论,第一章 面向对象的分析与设计第二章 开发过程导论第三章 定义模型和制品,目标
6、定义面向对象分析和设计阐述一个简单的OOA/OOD例子综述UML和可视化敏捷建模,第一章 面向对象的分析与设计,1.1 什么是分析和设计 1. 分析(analysis) :分析强调的是对问题和需求的调查研究,而非解决方案。 “分析”，主要指需求分析,即对需求的调查研究。分析可以有不同方法，如面向对象的分析方法或面向过程的分析方法等。 2. 设计(design):设计强调的是满足需求的概念上的解决方案(包括软件和硬件)而不是实现。“实现”，例如编码表达了真实和完整的设计。,1.2 软件开发面临的问题软件危机 一、问题的提出 1. 信息社会对软件技术的要求 2. 软件产业对软件技术的要求 *开发周
7、期问题 *开发成本问题 *可复用问题 *可进化问题 *可维护问题,3. 软件本身的问题 1）软件产品开发的高昂费用 2）软件的复杂性问题 3）软件与物理概念的的一致性问题 4）软件对应的领域规则的可变性问题 5）软件的不可见性问题 6）软件的维护与服务问题,4. 软件本身和软件工程方法的问题导致: 1) 软件项目的费用不断攀升 2) 软件开发周期越来越长 3) 软件错误越来越频繁,维护成本越来越高 4) 不成功的软件项目比例很大,造成巨大损失 下面是曾经来自美国的权威组织的统计数据:,各开发阶段的软件项目费用比例,开发步骤 % 需求 3 设计 8 编程 7 测试 15 维护 67本表来源于Bu
8、tler Bloor。下面的饼图是从各种渠道得出的平均数：,软件生命周期各阶段的近似花费比例,软件开发阶段的错误率,开发阶段 费用% 引入错误% 发现错误% 纠错费用需求分析 5 55 18 1.0设计 25 30 10 1.01.5代码及单 元测试 10集成测试 50 10 50 1.05.0确认及编 写文档 10运行维护 5 22 10100此表来源于Hughes DoD Composite Software Error History,统计数据表明,软件开发方法导致系统维护的费用十分惊人。 数据显示，85%的错误是在需求分析和设计的时候犯的。改善这两个阶段是提高软件质量的最有效途径。,费
9、用超支比率,费用超支状况 所占百分比 400% 4.4% 数据来自Standish集团对MIS组织的研究报告,项目超时率,超时状况 所占百分比 400% 1.1% 数据来自Standish集团对MIS组织的研究报告,超支与超时的统计数据同样十分可悲。调查发现有三种基本的项目类型： *成功的： 按时、按预算提交全部功能； *受到挑战的：能提交却不是全部功能，且 超时、超支； *失败的： 在开发中流产。 综合结果是：只有16.2%的项目是成功的,52.7%是受到挑战的,31.1%在发布前就被取消了。估计1995年受到挑战的和失败的项目费用是1400亿美元。,调查还发现，许多项目从错误的目标开始,后
10、来才发现错误，不得不从头开始。 Standish发现，每100个启动的项目中，有94个要重新开始，一些项目多次重新开始。重新开始就意味着项目超时。 综合统计表明，将近28%的项目，其费用要超支150200%。所有公司的平均项目超支费用是原先所估计的189%。小公司则倾向于更大超支，平均达214%，严重影响公司的生存能力。 下表显示，大部分项目不能提交完整的功能。 呜呼！现代公司面临灾难！,能提交的功能,提交功能 所占百分比 25% 4.6% 2549% 27.2% 5074% 21.8% 7599% 39.1% 100% 7.3% 数据来自Standish集团对MIS组织的研究报告,二、问题的
11、原因 造成软件危机的原因是什么呢？ 1）软件本身的特殊性 2）真实世界的可变性 3）软件工程方法的不适应性三、解决问题的办法 改变软件工程的方法使之适应软件的复杂性和真实世界的可变性。,1.3 软件工程方法 1. 结构化方法 所谓结构化方法是一种使用功能作为其构造块的软件开发方法。这种被称为结构化分析与设计的方法以功能组织软件。20世纪70年代开始，这种方法成为主流。 结构化方法非常适合科学计算，因为在大多数科学应用中，功能是十分稳定的，因为自然法则很少变化。,但是，在企业应用中，在范围十分广阔的信息管理应用中，功能是人定义的。不同时间、不同地点、不同的人都会有不同的定义。 把结构化方法应用到
12、这些领域中，便产生了不适应性。尤其是对大型软件，这种不适应性尤为突出。软件设计师按照预先约定的需求去开发软件，但是还没等到软件发布，需求已经发生了变化。而且软件只能定制，无法复用。,2. 数据建模方法 到20世纪80年代,Peter Chen开发了实体关系图,Ed Codd设计了关系数据库。他们向开发者提供了一种新的开发软件的方法基础。它基于称为实体的数据项的集合作为其构造块。理由是数据是企业中最稳定的部分。 很多人都认为实体是稳定的，并且关系数据库有一个极好的数学基础。因此在80年代大多数人使用数据建模方法开发软件。,但是很快就发现，数据建模方法与结构化方法各占一半优点和缺点。结构化方法实际
13、上帮助开发者处理数据（尽管它不适应功能变化），数据建模方法却不能帮助开发者管理功能（尽管它适应稳定的数据）。 这两种方法的共同缺点是只使用一种系统的视觉组织系统。 能否有一种支持系统所有视觉的范型的方法来组织系统呢？有,这就是面向对象的方法.,3. 面向对象的方法 软件开发急需一种能克服早期方法的弱点的方法。早期的方法只使用一种系统的视觉，不能容纳其它视觉。 一些世界顶级的专家开始寻求新的软件工程方法，这就是现在主流的方法：面向对象的方法。这种方法提供支持系统的所有视觉的范型，并且以纵横的方式管理软件的复杂性。,1.4 面向对象的分析与设计 如前所述,面向对象的方法既不是单纯以功能为中心,也不
14、是单纯以数据为中心来组织系统。 在面向对象的分析过程中，强调的是在问题领域内发现和描述概念。 在面向对象的设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。 最后在实现设计中完成类的全部定义与编码。 下面是面向对象强调对象的示例和面向对象范型与结构化范型的比较示例：,面向对象的范型与结构化范型的比较,帐目,帐目余额,取款,计算余额,存款,帐目余额,消息,消息,消息,存款,取款,计算余额,面向对象的范型,结构化范型,1.5 简单示例 本节以一个十分简单的示例“ 骰子游戏”展示面向对象的分析与设计的主要思想和过程。 基本个过程是:,定义用例,定义领域模型,定义交互图,定义设计类图,定义用
15、例 1）用例的概念：用例是需求分析中的一种有效工具。用例描述应用的情节或场景。用例是需求制品。 2）骰子游戏用例：游戏者请求掷骰子系统展示结果，如果总点数是，则游戏者赢，否则游戏者输。,2. 定义领域模型 1）领域模型的概念:领域模型描述领域中重要的概念、属性和关联。 2）骰子游戏的部分领域模型：,该模型中有三个主要概念：Player、Die和DiceGame； Player有姓名属性， Die有面值属性； Player与Die有一个关联，表示每个游戏者可以滚动两个骰子， DiceGame与Player有一个关联，表示每个游戏者在玩一次游戏， DiceGame与Die有一个关联，表示每次游戏包
16、括滚动两个骰子。 注意领域模型并不是对软件对象的描述,它是真实世界中概念的可视化。因此领域模型也称概念模型。,3. 分配对象职责并绘制交互图 面向对象的设计关注软件对象的定义:分配对象的职责,建立各对象之间的协作关系。UML交互图用于描述这些定义，如图。注意: 1)在真实世界中是是游戏者滚动骰子,但在软件设计中却是由DiceGame对象掷出骰子（即由DiceGame发送消息给Die 对象）。2）把一个消息发送给一个对象，意味着该对象具有承担该任务的职责，换言之，设计将把该项职责分配给该对象。,骰子游戏的交互图（草图）,骰子游戏的交互图,4. 定义设计类图 UML使用交互图显示软件对象之间如何协
17、作以完成任务,是一种动态视图。 UML还使用一种静态视图即设计类图来定义软件中的类。例如在骰子游戏中，通过观察上述交互图，可以画出如下图所示的部分设计类图。注意到，由于第一个消息play是发送给DiceGame的，所以DiceGame对象应有play方法，同样Die 对象应有roll方法和getFaceValue方法。,骰子游戏的局部设计类图,1.6 UML语言 1. 什么是UML语言 UML(Unified Modeling Language)是统一建模语言,它是描述、构造和文档化系统制品的可视化语言。 UML是个庞大的表示法体系。本课程不可能系统地讲授该体系，但会结合OOA/OOD简述如何
18、使用UML的常用表示法。,2. UML的三种应用方式 1） UML作为草图: 非正式的不完整的图,通常在白板上手绘,用于讨论和敏捷建模。 2）UML作为蓝图：相对详细的设计图，用于前向工程（代码生成）和逆向工程（由现有代码生成UML图，对代码可视化）。 3）UML作为编程语言：用UML完成软件系统可执行的规格说明，以便可执行代码的自动生成。（仍处于研究和发展阶段）,3. 应用UML的三种透视图 同样的UML表示法可以用于不同的层面，表示不同的事物。应用UML可以表示三种透视图： 1）概念透视图：用于领域模型，使真实世界的概念可视化。 2）规格说明透视图：用图来描述软件的抽象物或具有规格说明和接
19、口的构件，但不约定特定实现。 3）实现透视图：用于设计模型，使软件系统中的类可视化，用图来描述特定技术中的软件实现。,UML的不同透视图,说明：由于同样的UML表示法可用于不同层面，其所表示的对象含义会各不相同。为清晰起见，关于“类”，明确如下： * 概念类：现实世界中的概念或事物，领域模型中类。 * 软件类：软件系统中的类，设计模型中的类。 * 实现类：特定OO语言中的类。,第二章 软件开发过程,目标软件开发过程的概念软件开发过程的比较UP过程,2.1 软件开发过程一、什么是软件开发过程？ 软件开发过程(software developmemt process )是生产软件的途径，它描述了构
20、造、部署和维护软件的方式，软件过程一般都包括需求、分析、设计、测试、集成、提交、维护等阶段。 软件开发过程概念与软件生命周期概念紧密相关。软件生命周期是指软件从开始开发到提交再到运行直至退役的一整个过程。 软件开发过程主要研究软件开发的组织方法，它影响软件生命周期。,二、软件开发过程的比较 不同的组织、不同的历史，存在不同的软件开发过程。详细追述这些过程并无必要。一些方法已经被抛弃。重要的是我们应该明白失败与成功的原因。 典型的可以把软件开发过程分为两大类： 一类是需求变化要服从开发过程，另一类是开发过程要服从需求变化。 早期的开发过程大多属于前一种。典型的就是所谓“瀑布”过程。,瀑布过程本质
21、上是基于需求和规格说明是可预知的和稳定的，并且能够在项目开始时就完全定义，同时具有低变更率。这种思想在一些领域中是正确的，如在科学计算领域中，软件要处理的是一些自然法则，而这些自然法则很少会变化。但是，在信息管理领域中，它却与事实背道而驰。因此，把瀑布过程用在十分广阔的信息领域中，就造成了“软件危机”。,反之，后一种方法提倡开发过程要服从需求变化，提倡变化驱动设计。这种开发过程基于变化是永恒的，设计要适应这种变化。 设计要适应变化需要两个条件： 一个是软件设计本身要可复用，便于推进，于是提出了OOA/OOD的分析与设计方法。 另一个是软件开发过程要适应这种变化，于是提出了迭代式、增量式的开发过
22、程方法。 典型的就是UP过程(Unified process),即统一过程,特别是RUP(Rational Unified process)。,2.2 迭代和进化式开发 一、什么是迭代和进化式开发 1. 概念 迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目,称为迭代。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。,迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。
23、 随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此该方法也被称为迭代和增量式开发(iterative and incrementaldevelopment)。 因为反馈和调整使规格说明和设计不断进化，所以该方法也称为迭代和进化式开发(iterative and evolutionary development)。,迭代和进化式开发的生命周期模型,统一过程模型,需求 实现、测试、集 成和进一步设计 最终集成和 系统测试,需求,设计,设计,实现、测试、集 成和进一步设计,最终集成和系统测试,时间,系统增量式增长,一次迭代（如三周时间）,另一次迭代（如四周时间）,2. 示例 例如,在项目开
24、始为期三周的一次迭代中,可以用周一上午一个小时的时间召开团队成员启动会议,明确本次迭代的任务和目标。其间由一人对上次迭代的代码进行逆向工程（使用CASE 工具）制作UML图，并打印和显示其中重要部分。在周一剩下的时间里，团队成员可以在白板上以结对的工作方式进行敏捷建模，画出UML草图并使用数码相机记录，然后写出伪代码和设计纪要。,剩余的工作日对局部系统进行实现、测试、（单元测试、验收测试、可用性测试等）进一步的设计、集成和日常构造等工作。其他活动还包括与涉众进行演示和评估。 示例告诉我们：一次迭代，周期很短；每次迭代的开始是处理上一次迭代的反馈，同时结合本次迭代任务进行设计与实现；每次迭代都产
25、生可执行的但不完善的系统，直到多次（如1015次）迭代之后，系统才可能合格地用于产品部署。,注意：迭代的结果不是象早期原型法样，只是实验性的或将丢弃的原型，迭代开发也不是构造原型。与之相反，迭代的结果是最终系统产品的子集。三、在迭代中处理变更 1. 正确对待需求变更 瀑布式过程是在实现之前企图全面地冻结需求和规格化说明，签署需求和设计协议。以此与软件开发中不可避免的变更进行抗争。 与此相反，迭代和进化式开发报以接受变,更和改写的态度，并以此为本质的驱动力。这并不意味迭代开发和UP提倡不受控制的、不负责任的胡作非为。而是在涉众确实明确了其构想或在市场变化需要平衡需求时，一方面认同和稳定一组需求，
26、另一方面接受需求不断变更的客观事实。 2. 接受与处理反馈 每次迭代选择一小组需求, 快速设计、实现和测试，并涉众调查，可以得到快速反馈，包括用户、开发人员和测试人员的反馈。,这种早期的反馈具有极高的价值。与“推测”完整、正确的需求或设计相反，团队可以从实际构造和测试的反馈中，挖掘出至关重要和实际的观点，从而修改和调整对需求或设计的理解。用户也有机会及早看到部分系统并提出：“不错，这是我所要求的；但我现在试过后，发现与我真正想要的有一些差异”。这种“不错但是”的过程并不是失败的标志，相反，早期频繁地在“不错但是”中循环，正是改进软件和发现什么对涉众有真正价值的途径。,除了处理需求变更之外，负载
27、测试将验证局部设计和实现是否正确或合理，以确定是否需要在下一次迭代中改变核心架构。最好及早解决和验证具有风险的、关键的设计决策。迭代开发提供了完成这项工作的机制。 因此，迭代工作是通过一系列有序的“构造-反馈调整”的循环向前进展的。可以肯定，早期迭代中偏离“正确轨道”的程度会大于后继迭代。随着迭代次数的增加，这种偏离将最终收敛，如图：,四、迭代开发的优点 *减少项目失败的可能性，提高生产率，减低缺陷率。 *在早期缓解高风险。 *早期可见的进展。 *早期反馈以及用户参与和调整，会产生更接近涉众真实需求的精化系统。 *可控复杂性，团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。 *一次迭代中的经验
28、可以被系统地用于改进开发过程本身。,五、一次迭代的持续时间和时间定量 大部分迭代方法建议迭代时间在26周之间。小步骤、快速反馈和调整是迭代开发的基本思想，迭代时间过长会背离迭代开发的基本思想，从而增加项目风险。时间太短如1周不足以获得有意义的产出和反馈，时间太长如大于6周，复杂性会变得不可控制，反馈将延迟。 迭代的一个关键思想是时间定量，即时长固定。如果时间太紧，最好是从本次迭代中去掉一些任务而不是推迟迭代时间。,六、不要让瀑布思维侵蚀迭代或UP 瀑布思维很顽固。这不仅是因为许多开发者过去受其影响而形成习惯，即便是新手，常常也会自然地喜欢一下子求全求完整。 现在的研究最终表明，20世纪60年代
29、到70年代所推崇的瀑布方法对于大多数软件项目是拙劣的实践而非良好的方法。80年代对瀑布方法作了一些改革，如原型法等，但没有从根本上解决问题。 开发者应该牢牢记住，软件开发领域是属于,新产品开发领域，不是大规模制造领域，大规模制造领域是低变更领域，而新产品开发领域在开发过程中是必须要接受反馈，必然会有反复变更的。而且，在复杂的系统中，这种反馈和调整是成功的关键要素。,2.3 进行迭代和进化式分析与设计示例 这里给出一个示例,展示在训练有素的UP项目组中,迭代是如何被运用的。示例假定，在项目交付前，最终将有20次迭代。 一、迭代前的准备工作 1. 需求工作会议 在第一次迭代之前,召开第一个时间定量
30、的需求工作会议。 会期两天。 出席人员：业务和开发人员、首席架构师。,会议内容及安排： 1）第一天上午进行高层需求分析，仅确定高层用例包括名称和特性,不涉及详细细节,确定关键性的非功能性需求，形成任务列表。 2）通过咨询首席架构师和业务人员，从高层用例列表中选择10%的用例，这些用例要具备以下三种性质： *具有重要的架构意义。 *具有高业务价值即用户真正关心的特性。 *在项目中最具风险性。,3）在剩下的一天半内，对这些用例的功能和非功能性需求进行详细的分析。 注意：这个会议我们完成了10%的用例分析 ，另外90%的用例只是给出了名称和特性。 2. 召开迭代计划会议,在已经完成分析的那10%的用
31、例中选择一个特性子集,要求在规定时间内(例如四周)完成设计、构造和测试。选择后将其分解为一系列更为详细的迭代任务，分配给团队的每一个人。 3. 在规定时间内完成第一次迭代，步骤为：,1）迭代开始的头两天，分组进行建模和设计。在首席架构师的指导下，在“公共作战室”的众多白板上画出UML的草图及其它模型。 2）然后开始编程、测试和集成。注意这时的模型只是局部的，并且通常是不精确的。 3）进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。 4）在规定时间到的前一周，检查是否能够在规定时间内完成迭代任务，如果不能，减少迭代内容，把次要目标放回任务列表中。,5）在最后一周的星期二，冻结代码
32、。此前必须完成第一版本的检入，并测试、集成所有代码（建立迭代的基线）。 6）在星期三的上午，向外部涉众演示此局部系统，展示早期可视系统，同时要求反馈。 4. 在第一次迭代即将结束时，如最后一周的星期三下午和星期四，召开第二次需求工作会议，根据结果和反馈，对上一次需求会议的所有材料进行复查和修正。,需求修正后，再在任务列表中选择具有重要架构意义和高业务价值的另外10%15%的用例，用一到两天时间对其进行详细分析。至此我们完成了20%25%详细分析，同样也是不完美的，因为新完成的分析还未实现和检验。 5. 于最后一周的星期五上午，举行下一次迭代的迭代计划会议，在已选择的第一个10%的用例特性中再选
33、择一个子集。 6. 以相同步骤进行第二次迭代。,7. 反复进行四次迭代和五次需求工作会议,在第四次迭代结束时,我们已经详细分析了80%到90%的需求,但是只实现了系统的10%。 在这一阶段中，我们主要在做需求分析，但是我们是在对大约10%的对系统具有重要架构意义和业务价值的不断设计和反馈的循环中推进需求分析。这大概要占整个开发过程20%。在UP术语中，这个阶段称为细化阶段(elaboration phase)。,8. 估计后续任务情况: 细化阶段结束时,我们可以估计这些经过精化的和相对确定的需求实现所需的工作量和时间。 9. 接下来是一系列为期三周的迭代。这期间一般不需要再开需求工作会议，需求
34、已经稳定了。这期间的一系列为期三周的迭代就是陆续实现未实现的需求。这个阶段在UP术语中称为构造阶段。在构造阶段中每次迭代完成都产生一个新的版本，都有一次新的发布，系统都得到一个新的增量。,2.4 风险驱动(risk-driven)和 客户驱动(client-driven) UP以及大多数新方法都提倡风险驱动和客户驱动相结合的迭代计划。这意味着早期的迭代目标要致力于能够识别和降低最高风险,并且能够构造客户最关心的可视化特性。 风险驱动迭代开发更为明确地包含了以架构为中心(architecture-centric)迭代开发的实践。这意味着早期的迭代目标要致力于核心架构的构造、稳定和测试。因为没有稳
35、定,的架构就会带来高风险。 本课程结合案例教学。由于学习是由浅入深、由易到难的过程，案例教学中第一次迭代不是以架构为中心的或风险驱动的。在实际项目开发中我们应该首先处理困难的和最具风险的工作。,2.5 敏捷方法及其观点 一、敏捷方法 敏捷开发(agile developmen)也是一种时间定量的迭代和进化式开发。敏捷开发提倡敏捷性即快速和灵活的响应变更，倡导反映简易、轻量、沟通、自组织团队等敏捷性的实践和原则。如Scrum敏捷方法的实践范例包括公共项目工作室和自组织团队，极限编程XP方法的实践范例包括结对编程和测试驱动开发(test-driven development)。,包括UP在内的任何
36、迭代方法都可以施加敏捷精神。UP本身就是灵活的，因此可以施加敏捷方法中的实践。 二、敏捷宣言和原则 1. 敏捷宣言 个体和迭代,超越过程和工具 工作的软件,超越完整的文档 客户的协作,超越合同谈判 对响应变更,超越履行计划,2. 敏捷原则 1）尽早并持续交付有价值的软件来满足客户。 2）欢迎变更需求，即使在开发的后期提出。 3）以两周到三周为迭代周期，时间定量。 4）每一天开发人员都要和业务人员合作。 5）由个体推动项目的建设，提供信任和支持。 6）面对面交谈以高效传递信息。 7）衡量进展的重要尺度是可运行的软件。 8）提倡可持续开发。 9）发起人、开发者和用户应该步调一致。,10）不断关注技
37、术上优越的设计。 11）简洁是最重要的，避免不必要的工作量。 12）最佳的架构、需求和设计来自自组织的团队。 13）团队要定期反省如何使工作更有效。 提倡敏捷方法犹如提倡快速反应部队。2001年，敏捷联盟 ()创建并发表了敏捷宣言和原则。,三、敏捷建模 敏捷方法认为，建模的目的主要是为理解，而非文档。这就提出了敏捷建模的思想： 1）采用敏捷方法并不意味不进行任何建模，许多敏捷方法都包含重要的建模期。 2）建模的目的主要用于理解和沟通，而不是用于构建文档。 3）不要对所有或大多数软件设计建模或应用UML，只需对困难和棘手的问题建模。 4）尽可能使用最简单的、大可视空间的工具。,例如在白板上草画U
38、ML，并使用数码相机。 5）不是单独建模，而是结对或三人在白板上建模。小组要轮流进行，每人都参与其中。 6）并行地创建模型。同时展示动态模型和静态模型。 7）坚持使用简单、常用的UML元素。 8）建模只是一种探索。测试过的代码才是最终的设计。 9）开发者是为自己开发而建模，而不是创建模型后交给别人实现。,四、敏捷UP UP可以采纳和应用敏捷精神，实行敏捷UP： 1）所有UP制品都是可选的，推荐使用UP活动和制品的简集。根据需要选择制品。 2）应致力于早期的编程，而非构建文档。 3）以敏捷建模实践应用UML。 4）预先不要注重整个项目的详细计划，应该制定高层阶段计划，只对每次的迭代制定详细的计划
39、。,2.6 UP的核心思想与关键实践 UP所倡导的核心思想是:短时间定量迭代、进化和可适应性开发。其他一些UP的最佳实践和关键概念包括： *在早期迭代中解决高风险和高价值的问题。 *不断地让用户参加评估、反馈和确认需求。 *在早期迭代中建立内聚的核心架构。 *不断地验证质量；提早、经常和实际测试。 *在适当的地方使用用例。 *使用UML进行一些可视化建模。 *认真管理需求。 *实行变更请求和配置管理。,2.7 UP的阶段 UP项目将其工作和迭代组织为四个阶段: 1) 初始(Inception):大体上的构想,可行性评估阶段。 2) 细化(Elaboration):已精化的构想、核心架构的迭代实
40、现、高风险的解决、确定大多数需求和范围并进行更为实际的评估。 3) 构造(Construction):对遗留的风险较低的和比较简单的元素进行迭代实现，准备部署。 4) 交付(Transition):进行beta测试和部署。,注意： 1）不是在开始就定义全部需求，然后进行全部或大部分设计。 2）初始阶段不是需求阶段，而是研究可行性阶段。 3）细化阶段也不纯粹是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题。细化阶段结束时，需求基本稳定，但设计只完成大约10%。 4）构造阶段迭代实现大部分设计任务。 下图表示UP的不同阶段及相关术语：,UP阶段与相关术语,2.8 UP科目 科目(disci
41、pline)是指在一个主题域中的一组活动，例如业务建模、需求、设计、实现、测试、部署、配置和变更管理、项目管理和环境（设置工具和过程环境）等。 制品(artifact)是指活动所产生的各种产品，重要的制品包括：在业务建模科目中的领域模型制品、在需求科目中的用例模型及其补充性规格说明制品、在设计科目中的设计模型制品等。,2.9 科目和阶段、迭代之间的关系 1.科目与迭代 一次迭代的工作会遍历大部分或全部科目。 2.科目与阶段 不同阶段，各科目的工作量会随时间有所变化。 下面两个示意图说明了这种关系：,科目与迭代的关系,科目与阶段的关系,2.10 如何定制过程和UP开发案例 一、定制过程 在UP中
42、,几乎所有的实践和制品都是可选的。开发团队应该选择一组能够解决其特定问题和需要的实践和制品，即定制过程。 二、UP开发案例 为项目选择实践和UP制品可以编写为简短文档，该简短文档称为开发案例。开发案例是环境科目中的制品。 下表是本课程POS教学案例的开发案例：,三、UP实践（活动）和制品 简单开发案例(s:开始,r:精化) 科目 实践 制品 初始 细化 构造 移交 迭代 I1 E1.En C1.Cn T1.Tn 业务建模 敏捷建模 领域模型 s 需求讨论会 需求 需求讨论会 用例模型 s r 设想包装练习 设想 s r 计点投票表决 补充性规格说明 s r 词汇表 s r 设计 敏捷建模 设计模型 s r 测试驱动开发 软件架构文档 s 数据模型 s r 实现 测试驱动开发 结对编程 持续集成 编码标准 项目管理 敏捷项目管理 每日例会 ,
