现代软件工程技术.ppt

现代软件工程技术,基于UML、OMT和模式应用的系统分析、建模和迭代开发技术,林国璋,2006年10月,课程介绍,一、本课程的内容本课程的传统名称是系统分析与设计或系统分析与建模。是计算机专业和软件工程专业的核心课程。由于软件工程技术的不断发展，在讨论系统分析与建模时，必须跨越软件工程的多个技术领域，因此，把她称为现代软件工程技术也很确切。,本课程的核心内容是面向对象的分析与建模。围绕这一核心我们需要学习：*面向对象的思想OO*用例技术*对象建模技术OMT*统一建模语言UML*职责分配技术GRASP*设计模式应用ApplyingPatterns*统一过程UP,二、本课程的特点与学习方法本课程属工程技术类课程。相关技术均通过贯穿全课程的案例研究作深入浅出的阐述，并按照迭代开发过程进行迭代学习，解决了现实问题中令人生畏而又必须解决的分析与设计细节。本课程不涉及深奥的理论推导，但需要清晰的逻辑思维。只要一丝不苟，勤于思考，就不难学好。,三、本课程的教材与参考书1.教材：UML和模式应用（原书第三版）李洋等译原著:ApplyingUMLandPatternsAnIntroductiontoObject-OrientedAnaysisAndIterativeDevelopmentTHIRDEDITION作者:CraigLarman,2.参考书1)书名:Objict-OrientedModelingandDesign作者:JamesRumbaughMichaelBlahaWilliamPremerlaniFrederickEddyWilliamLorensen2)书名:Objict-OrientedModelingandDesignforDatabaseApplications作者:MichaelBlahaWilliamPremerlani,3)书名:DesignPaternsElementsofReusableObjict-Orientedsoftware作者:ErichGammaRichardHelmRalphJohnsonJohnVlissides4)书名:ApplyingUseCase(SecondEdition)作者:GeriSchneiderJasonP.Winters中译本:用例分析技术(原书第2版)译者:姚淑珍李巍,5)书名:TheRationalUnifiedProcessanIntroduction(SecondEdition)作者:PhilippeKruchten中译本:Rational统一过程引论(原书第2版)译者:周伯生吴超英王佳丽6)书名:TheUnifiedModelinglanguageReferenceManual作者:JamesRumbaugh,IvarJacobon,GradyBooch译者:姚淑珍唐发根,7)书名:UMLandC+:APracticalGuidetoObject-OrientedDevelopment(SecondEdition)作者:RichardC.LeeWilliamM.Tepfenhart中译本:C+面向对象开发(原书第2版)译者:麻志毅蒋严冰,第一部分绪论,第一章面向对象的分析与设计第二章开发过程导论第三章定义模型和制品,目标定义面向对象分析和设计阐述一个简单的OOA/OOD例子综述UML和可视化敏捷建模,第一章面向对象的分析与设计,1.1什么是分析和设计1.分析(analysis):分析强调的是对问题和需求的调查研究,而非解决方案。“分析”，主要指需求分析,即对需求的调查研究。分析可以有不同方法，如面向对象的分析方法或面向过程的分析方法等。2.设计(design):设计强调的是满足需求的概念上的解决方案(包括软件和硬件)而不是实现。“实现”，例如编码表达了真实和完整的设计。,1.2软件开发面临的问题软件危机一、问题的提出1.信息社会对软件技术的要求2.软件产业对软件技术的要求*开发周期问题*开发成本问题*可复用问题*可进化问题*可维护问题,3.软件本身的问题1）软件产品开发的高昂费用2）软件的复杂性问题3）软件与物理概念的的一致性问题4）软件对应的领域规则的可变性问题5）软件的不可见性问题6）软件的维护与服务问题,4.软件本身和软件工程方法的问题导致:1)软件项目的费用不断攀升2)软件开发周期越来越长3)软件错误越来越频繁,维护成本越来越高4)不成功的软件项目比例很大,造成巨大损失下面是曾经来自美国的权威组织的统计数据:,各开发阶段的软件项目费用比例,开发步骤%需求3设计8编程7测试15维护67本表来源于ButlerBloor。下面的饼图是从各种渠道得出的平均数：,软件生命周期各阶段的近似花费比例,软件开发阶段的错误率,开发阶段费用%引入错误%发现错误%纠错费用需求分析555181.0设计2530101.01.5代码及单元测试10集成测试5010501.05.0确认及编写文档10运行维护52210100此表来源于HughesDoDCompositeSoftwareErrorHistory,统计数据表明,软件开发方法导致系统维护的费用十分惊人。数据显示，85%的错误是在需求分析和设计的时候犯的。改善这两个阶段是提高软件质量的最有效途径。,费用超支比率,费用超支状况所占百分比400%4.4%数据来自Standish集团对MIS组织的研究报告,项目超时率,超时状况所占百分比400%1.1%数据来自Standish集团对MIS组织的研究报告,超支与超时的统计数据同样十分可悲。调查发现有三种基本的项目类型：*成功的：按时、按预算提交全部功能；*受到挑战的：能提交却不是全部功能，且超时、超支；*失败的：在开发中流产。综合结果是：只有16.2%的项目是成功的,52.7%是受到挑战的,31.1%在发布前就被取消了。估计1995年受到挑战的和失败的项目费用是1400亿美元。,调查还发现，许多项目从错误的目标开始,后来才发现错误，不得不从头开始。Standish发现，每100个启动的项目中，有94个要重新开始，一些项目多次重新开始。重新开始就意味着项目超时。综合统计表明，将近28%的项目，其费用要超支150200%。所有公司的平均项目超支费用是原先所估计的189%。小公司则倾向于更大超支，平均达214%，严重影响公司的生存能力。下表显示，大部分项目不能提交完整的功能。呜呼！现代公司面临灾难！,能提交的功能,提交功能所占百分比25%4.6%2549%27.2%5074%21.8%7599%39.1%100%7.3%数据来自Standish集团对MIS组织的研究报告,二、问题的原因造成软件危机的原因是什么呢？1）软件本身的特殊性2）真实世界的可变性3）软件工程方法的不适应性三、解决问题的办法改变软件工程的方法使之适应软件的复杂性和真实世界的可变性。,1.3软件工程方法1.结构化方法所谓结构化方法是一种使用功能作为其构造块的软件开发方法。这种被称为结构化分析与设计的方法以功能组织软件。20世纪70年代开始，这种方法成为主流。结构化方法非常适合科学计算，因为在大多数科学应用中，功能是十分稳定的，因为自然法则很少变化。,但是，在企业应用中，在范围十分广阔的信息管理应用中，功能是人定义的。不同时间、不同地点、不同的人都会有不同的定义。把结构化方法应用到这些领域中，便产生了不适应性。尤其是对大型软件，这种不适应性尤为突出。软件设计师按照预先约定的需求去开发软件，但是还没等到软件发布，需求已经发生了变化。而且软件只能定制，无法复用。,2.数据建模方法到20世纪80年代,PeterChen开发了实体关系图,EdCodd设计了关系数据库。他们向开发者提供了一种新的开发软件的方法基础。它基于称为实体的数据项的集合作为其构造块。理由是数据是企业中最稳定的部分。很多人都认为实体是稳定的，并且关系数据库有一个极好的数学基础。因此在80年代大多数人使用数据建模方法开发软件。,但是很快就发现，数据建模方法与结构化方法各占一半优点和缺点。结构化方法实际上帮助开发者处理数据（尽管它不适应功能变化），数据建模方法却不能帮助开发者管理功能（尽管它适应稳定的数据）。这两种方法的共同缺点是只使用一种系统的视觉组织系统。能否有一种支持系统所有视觉的范型的方法来组织系统呢？有,这就是面向对象的方法.,3.面向对象的方法软件开发急需一种能克服早期方法的弱点的方法。早期的方法只使用一种系统的视觉，不能容纳其它视觉。一些世界顶级的专家开始寻求新的软件工程方法，这就是现在主流的方法：面向对象的方法。这种方法提供支持系统的所有视觉的范型，并且以纵横的方式管理软件的复杂性。,1.4面向对象的分析与设计如前所述,面向对象的方法既不是单纯以功能为中心,也不是单纯以数据为中心来组织系统。在面向对象的分析过程中，强调的是在问题领域内发现和描述概念。在面向对象的设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。最后在实现设计中完成类的全部定义与编码。下面是面向对象强调对象的示例和面向对象范型与结构化范型的比较示例：,面向对象的范型与结构化范型的比较,帐目,帐目余额,取款,计算余额,存款,帐目余额,消息,消息,消息,存款,取款,计算余额,面向对象的范型,结构化范型,1.5简单示例本节以一个十分简单的示例“骰子游戏”展示面向对象的分析与设计的主要思想和过程。基本个过程是:,定义用例,定义领域模型,定义交互图,定义设计类图,定义用例1）用例的概念：用例是需求分析中的一种有效工具。用例描述应用的情节或场景。用例是需求制品。2）骰子游戏用例：游戏者请求掷骰子系统展示结果，如果总点数是，则游戏者赢，否则游戏者输。,2.定义领域模型1）领域模型的概念:领域模型描述领域中重要的概念、属性和关联。2）骰子游戏的部分领域模型：,该模型中有三个主要概念：Player、Die和DiceGame；Player有姓名属性，Die有面值属性；Player与Die有一个关联，表示每个游戏者可以滚动两个骰子，DiceGame与Player有一个关联，表示每个游戏者在玩一次游戏，DiceGame与Die有一个关联，表示每次游戏包括滚动两个骰子。注意领域模型并不是对软件对象的描述,它是真实世界中概念的可视化。因此领域模型也称概念模型。,3.分配对象职责并绘制交互图面向对象的设计关注软件对象的定义:分配对象的职责,建立各对象之间的协作关系。UML交互图用于描述这些定义，如图。注意:1)在真实世界中是是游戏者滚动骰子,但在软件设计中却是由DiceGame对象掷出骰子（即由DiceGame发送消息给Die对象）。2）把一个消息发送给一个对象，意味着该对象具有承担该任务的职责，换言之，设计将把该项职责分配给该对象。,骰子游戏的交互图（草图）,骰子游戏的交互图,4.定义设计类图UML使用交互图显示软件对象之间如何协作以完成任务,是一种动态视图。UML还使用一种静态视图即设计类图来定义软件中的类。例如在骰子游戏中，通过观察上述交互图，可以画出如下图所示的部分设计类图。注意到，由于第一个消息play是发送给DiceGame的，所以DiceGame对象应有play方法，同样Die对象应有roll方法和getFaceValue方法。,骰子游戏的局部设计类图,1.6UML语言1.什么是UML语言UML(UnifiedModelingLanguage)是统一建模语言,它是描述、构造和文档化系统制品的可视化语言。UML是个庞大的表示法体系。本课程不可能系统地讲授该体系，但会结合OOA/OOD简述如何使用UML的常用表示法。,2.UML的三种应用方式1）UML作为草图:非正式的不完整的图,通常在白板上手绘,用于讨论和敏捷建模。2）UML作为蓝图：相对详细的设计图，用于前向工程（代码生成）和逆向工程（由现有代码生成UML图，对代码可视化）。3）UML作为编程语言：用UML完成软件系统可执行的规格说明，以便可执行代码的自动生成。（仍处于研究和发展阶段）,3.应用UML的三种透视图同样的UML表示法可以用于不同的层面，表示不同的事物。应用UML可以表示三种透视图：1）概念透视图：用于领域模型，使真实世界的概念可视化。2）规格说明透视图：用图来描述软件的抽象物或具有规格说明和接口的构件，但不约定特定实现。3）实现透视图：用于设计模型，使软件系统中的类可视化，用图来描述特定技术中的软件实现。,UML的不同透视图,说明：由于同样的UML表示法可用于不同层面，其所表示的对象含义会各不相同。为清晰起见，关于“类”，明确如下：*概念类：现实世界中的概念或事物，领域模型中类。*软件类：软件系统中的类，设计模型中的类。*实现类：特定OO语言中的类。,第二章软件开发过程,目标软件开发过程的概念软件开发过程的比较UP过程,2.1软件开发过程一、什么是软件开发过程？软件开发过程(softwaredevelopmemtprocess)是生产软件的途径，它描述了构造、部署和维护软件的方式，软件过程一般都包括需求、分析、设计、测试、集成、提交、维护等阶段。软件开发过程概念与软件生命周期概念紧密相关。软件生命周期是指软件从开始开发到提交再到运行直至退役的一整个过程。软件开发过程主要研究软件开发的组织方法，它影响软件生命周期。,二、软件开发过程的比较不同的组织、不同的历史，存在不同的软件开发过程。详细追述这些过程并无必要。一些方法已经被抛弃。重要的是我们应该明白失败与成功的原因。典型的可以把软件开发过程分为两大类：一类是需求变化要服从开发过程，另一类是开发过程要服从需求变化。早期的开发过程大多属于前一种。典型的就是所谓“瀑布”过程。,瀑布过程本质上是基于需求和规格说明是可预知的和稳定的，并且能够在项目开始时就完全定义，同时具有低变更率。这种思想在一些领域中是正确的，如在科学计算领域中，软件要处理的是一些自然法则，而这些自然法则很少会变化。但是，在信息管理领域中，它却与事实背道而驰。因此，把瀑布过程用在十分广阔的信息领域中，就造成了“软件危机”。,反之，后一种方法提倡开发过程要服从需求变化，提倡变化驱动设计。这种开发过程基于变化是永恒的，设计要适应这种变化。设计要适应变化需要两个条件：一个是软件设计本身要可复用，便于推进，于是提出了OOA/OOD的分析与设计方法。另一个是软件开发过程要适应这种变化，于是提出了迭代式、增量式的开发过程方法。典型的就是UP过程(Unifiedprocess),即统一过程,特别是RUP(RationalUnifiedprocess)。,2.2迭代和进化式开发一、什么是迭代和进化式开发1.概念迭代开发(iterativedevelopment)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目,称为迭代。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。,迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此该方法也被称为迭代和增量式开发(iterativeandincrementaldevelopment)。因为反馈和调整使规格说明和设计不断进化，所以该方法也称为迭代和进化式开发(iterativeandevolutionarydevelopment)。,迭代和进化式开发的生命周期模型,统一过程模型,需求实现、测试、集成和进一步设计最终集成和系统测试,需求,设计,设计,实现、测试、集成和进一步设计,最终集成和系统测试,时间,系统增量式增长,一次迭代（如三周时间）,另一次迭代（如四周时间）,2.示例例如,在项目开始为期三周的一次迭代中,可以用周一上午一个小时的时间召开团队成员启动会议,明确本次迭代的任务和目标。其间由一人对上次迭代的代码进行逆向工程（使用CASE工具）制作UML图，并打印和显示其中重要部分。在周一剩下的时间里，团队成员可以在白板上以结对的工作方式进行敏捷建模，画出UML草图并使用数码相机记录，然后写出伪代码和设计纪要。,剩余的工作日对局部系统进行实现、测试、（单元测试、验收测试、可用性测试等）进一步的设计、集成和日常构造等工作。其他活动还包括与涉众进行演示和评估。示例告诉我们：一次迭代，周期很短；每次迭代的开始是处理上一次迭代的反馈，同时结合本次迭代任务进行设计与实现；每次迭代都产生可执行的但不完善的系统，直到多次（如1015次）迭代之后，系统才可能合格地用于产品部署。,注意：迭代的结果不是象早期原型法样，只是实验性的或将丢弃的原型，迭代开发也不是构造原型。与之相反，迭代的结果是最终系统产品的子集。三、在迭代中处理变更1.正确对待需求变更瀑布式过程是在实现之前企图全面地冻结需求和规格化说明，签署需求和设计协议。以此与软件开发中不可避免的变更进行抗争。与此相反，迭代和进化式开发报以接受变,更和改写的态度，并以此为本质的驱动力。这并不意味迭代开发和UP提倡不受控制的、不负责任的胡作非为。而是在涉众确实明确了其构想或在市场变化需要平衡需求时，一方面认同和稳定一组需求，另一方面接受需求不断变更的客观事实。2.接受与处理反馈每次迭代选择一小组需求,快速设计、实现和测试，并涉众调查，可以得到快速反馈，包括用户、开发人员和测试人员的反馈。,这种早期的反馈具有极高的价值。与“推测”完整、正确的需求或设计相反，团队可以从实际构造和测试的反馈中，挖掘出至关重要和实际的观点，从而修改和调整对需求或设计的理解。用户也有机会及早看到部分系统并提出：“不错，这是我所要求的；但我现在试过后，发现与我真正想要的有一些差异”。这种“不错但是”的过程并不是失败的标志，相反，早期频繁地在“不错但是”中循环，正是改进软件和发现什么对涉众有真正价值的途径。,除了处理需求变更之外，负载测试将验证局部设计和实现是否正确或合理，以确定是否需要在下一次迭代中改变核心架构。最好及早解决和验证具有风险的、关键的设计决策。迭代开发提供了完成这项工作的机制。因此，迭代工作是通过一系列有序的“构造-反馈调整”的循环向前进展的。可以肯定，早期迭代中偏离“正确轨道”的程度会大于后继迭代。随着迭代次数的增加，这种偏离将最终收敛，如图：,四、迭代开发的优点*减少项目失败的可能性，提高生产率，减低缺陷率。*在早期缓解高风险。*早期可见的进展。*早期反馈以及用户参与和调整，会产生更接近涉众真实需求的精化系统。*可控复杂性，团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。*一次迭代中的经验可以被系统地用于改进开发过程本身。,五、一次迭代的持续时间和时间定量大部分迭代方法建议迭代时间在26周之间。小步骤、快速反馈和调整是迭代开发的基本思想，迭代时间过长会背离迭代开发的基本思想，从而增加项目风险。时间太短如1周不足以获得有意义的产出和反馈，时间太长如大于6周，复杂性会变得不可控制，反馈将延迟。迭代的一个关键思想是时间定量，即时长固定。如果时间太紧，最好是从本次迭代中去掉一些任务而不是推迟迭代时间。,六、不要让瀑布思维侵蚀迭代或UP瀑布思维很顽固。这不仅是因为许多开发者过去受其影响而形成习惯，即便是新手，常常也会自然地喜欢一下子求全求完整。现在的研究最终表明，20世纪60年代到70年代所推崇的瀑布方法对于大多数软件项目是拙劣的实践而非良好的方法。80年代对瀑布方法作了一些改革，如原型法等，但没有从根本上解决问题。开发者应该牢牢记住，软件开发领域是属于,新产品开发领域，不是大规模制造领域，大规模制造领域是低变更领域，而新产品开发领域在开发过程中是必须要接受反馈，必然会有反复变更的。而且，在复杂的系统中，这种反馈和调整是成功的关键要素。,2.3进行迭代和进化式分析与设计示例这里给出一个示例,展示在训练有素的UP项目组中,迭代是如何被运用的。示例假定，在项目交付前，最终将有20次迭代。一、迭代前的准备工作1.需求工作会议在第一次迭代之前,召开第一个时间定量的需求工作会议。会期两天。出席人员：业务和开发人员、首席架构师。,会议内容及安排：1）第一天上午进行高层需求分析，仅确定高层用例包括名称和特性,不涉及详细细节,确定关键性的非功能性需求，形成任务列表。2）通过咨询首席架构师和业务人员，从高层用例列表中选择10%的用例，这些用例要具备以下三种性质：*具有重要的架构意义。*具有高业务价值即用户真正关心的特性。*在项目中最具风险性。,3）在剩下的一天半内，对这些用例的功能和非功能性需求进行详细的分析。注意：这个会议我们完成了10%的用例分析，另外90%的用例只是给出了名称和特性。2.召开迭代计划会议,在已经完成分析的那10%的用例中选择一个特性子集,要求在规定时间内(例如四周)完成设计、构造和测试。选择后将其分解为一系列更为详细的迭代任务，分配给团队的每一个人。3.在规定时间内完成第一次迭代，步骤为：,1）迭代开始的头两天，分组进行建模和设计。在首席架构师的指导下，在“公共作战室”的众多白板上画出UML的草图及其它模型。2）然后开始编程、测试和集成。注意这时的模型只是局部的，并且通常是不精确的。3）进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。4）在规定时间到的前一周，检查是否能够在规定时间内完成迭代任务，如果不能，减少迭代内容，把次要目标放回任务列表中。,5）在最后一周的星期二，冻结代码。此前必须完成第一版本的检入，并测试、集成所有代码（建立迭代的基线）。6）在星期三的上午，向外部涉众演示此局部系统，展示早期可视系统，同时要求反馈。4.在第一次迭代即将结束时，如最后一周的星期三下午和星期四，召开第二次需求工作会议，根据结果和反馈，对上一次需求会议的所有材料进行复查和修正。,需求修正后，再在任务列表中选择具有重要架构意义和高业务价值的另外10%15%的用例，用一到两天时间对其进行详细分析。至此我们完成了20%25%详细分析，同样也是不完美的，因为新完成的分析还未实现和检验。5.于最后一周的星期五上午，举行下一次迭代的迭代计划会议，在已选择的第一个10%的用例特性中再选择一个子集。6.以相同步骤进行第二次迭代。,7.反复进行四次迭代和五次需求工作会议,在第四次迭代结束时,我们已经详细分析了80%到90%的需求,但是只实现了系统的10%。在这一阶段中，我们主要在做需求分析，但是我们是在对大约10%的对系统具有重要架构意义和业务价值的不断设计和反馈的循环中推进需求分析。这大概要占整个开发过程20%。在UP术语中，这个阶段称为细化阶段(elaborationphase)。,8.估计后续任务情况:细化阶段结束时,我们可以估计这些经过精化的和相对确定的需求实现所需的工作量和时间。9.接下来是一系列为期三周的迭代。这期间一般不需要再开需求工作会议，需求已经稳定了。这期间的一系列为期三周的迭代就是陆续实现未实现的需求。这个阶段在UP术语中称为构造阶段。在构造阶段中每次迭代完成都产生一个新的版本，都有一次新的发布，系统都得到一个新的增量。,2.4风险驱动(risk-driven)和客户驱动(client-driven)UP以及大多数新方法都提倡风险驱动和客户驱动相结合的迭代计划。这意味着早期的迭代目标要致力于能够识别和降低最高风险,并且能够构造客户最关心的可视化特性。风险驱动迭代开发更为明确地包含了以架构为中心(architecture-centric)迭代开发的实践。这意味着早期的迭代目标要致力于核心架构的构造、稳定和测试。因为没有稳定,的架构就会带来高风险。本课程结合案例教学。由于学习是由浅入深、由易到难的过程，案例教学中第一次迭代不是以架构为中心的或风险驱动的。在实际项目开发中我们应该首先处理困难的和最具风险的工作。,2.5敏捷方法及其观点一、敏捷方法敏捷开发(agiledevelopmen)也是一种时间定量的迭代和进化式开发。敏捷开发提倡敏捷性即快速和灵活的响应变更，倡导反映简易、轻量、沟通、自组织团队等敏捷性的实践和原则。如Scrum敏捷方法的实践范例包括公共项目工作室和自组织团队，极限编程XP方法的实践范例包括结对编程和测试驱动开发(test-drivendevelopment)。,包括UP在内的任何迭代方法都可以施加敏捷精神。UP本身就是灵活的，因此可以施加敏捷方法中的实践。二、敏捷宣言和原则1.敏捷宣言个体和迭代,超越过程和工具工作的软件,超越完整的文档客户的协作,超越合同谈判对响应变更,超越履行计划,2.敏捷原则1）尽早并持续交付有价值的软件来满足客户。2）欢迎变更需求，即使在开发的后期提出。3）以两周到三周为迭代周期，时间定量。4）每一天开发人员都要和业务人员合作。5）由个体推动项目的建设，提供信任和支持。6）面对面交谈以高效传递信息。7）衡量进展的重要尺度是可运行的软件。8）提倡可持续开发。9）发起人、开发者和用户应该步调一致。,10）不断关注技术上优越的设计。11）简洁是最重要的，避免不必要的工作量。12）最佳的架构、需求和设计来自自组织的团队。13）团队要定期反省如何使工作更有效。提倡敏捷方法犹如提倡快速反应部队。2001年，敏捷联盟()创建并发表了敏捷宣言和原则。,三、敏捷建模敏捷方法认为，建模的目的主要是为理解，而非文档。这就提出了敏捷建模的思想：1）采用敏捷方法并不意味不进行任何建模，许多敏捷方法都包含重要的建模期。2）建模的目的主要用于理解和沟通，而不是用于构建文档。3）不要对所有或大多数软件设计建模或应用UML，只需对困难和棘手的问题建模。4）尽可能使用最简单的、大可视空间的工具。,例如在白板上草画UML，并使用数码相机。5）不是单独建模，而是结对或三人在白板上建模。小组要轮流进行，每人都参与其中。6）并行地创建模型。同时展示动态模型和静态模型。7）坚持使用简单、常用的UML元素。8）建模只是一种探索。测试过的代码才是最终的设计。9）开发者是为自己开发而建模，而不是创建模型后交给别人实现。,四、敏捷UPUP可以采纳和应用敏捷精神，实行敏捷UP：1）所有UP制品都是可选的，推荐使用UP活动和制品的简集。根据需要选择制品。2）应致力于早期的编程，而非构建文档。3）以敏捷建模实践应用UML。4）预先不要注重整个项目的详细计划，应该制定高层阶段计划，只对每次的迭代制定详细的计划。,2.6UP的核心思想与关键实践UP所倡导的核心思想是:短时间定量迭代、进化和可适应性开发。其他一些UP的最佳实践和关键概念包括：*在早期迭代中解决高风险和高价值的问题。*不断地让用户参加评估、反馈和确认需求。*在早期迭代中建立内聚的核心架构。*不断地验证质量；提早、经常和实际测试。*在适当的地方使用用例。*使用UML进行一些可视化建模。*认真管理需求。*实行变更请求和配置管理。,2.7UP的阶段UP项目将其工作和迭代组织为四个阶段:1)初始(Inception):大体上的构想,可行性评估阶段。2)细化(Elaboration):已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围并进行更为实际的评估。3)构造(Construction):对遗留的风险较低的和比较简单的元素进行迭代实现，准备部署。4)交付(Transition):进行beta测试和部署。,注意：1）不是在开始就定义全部需求，然后进行全部或大部分设计。2）初始阶段不是需求阶段，而是研究可行性阶段。3）细化阶段也不纯粹是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题。细化阶段结束时，需求基本稳定，但设计只完成大约10%。4）构造阶段迭代实现大部分设计任务。下图表示UP的不同阶段及相关术语：,UP阶段与相关术语,2.8UP科目科目(discipline)是指在一个主题域中的一组活动，例如业务建模、需求、设计、实现、测试、部署、配置和变更管理、项目管理和环境（设置工具和过程环境）等。制品(artifact)是指活动所产生的各种产品，重要的制品包括：在业务建模科目中的领域模型制品、在需求科目中的用例模型及其补充性规格说明制品、在设计科目中的设计模型制品等。,2.9科目和阶段、迭代之间的关系1.科目与迭代一次迭代的工作会遍历大部分或全部科目。2.科目与阶段不同阶段，各科目的工作量会随时间有所变化。下面两个示意图说明了这种关系：,科目与迭代的关系,科目与阶段的关系,2.10如何定制过程和UP开发案例一、定制过程在UP中,几乎所有的实践和制品都是可选的。开发团队应该选择一组能够解决其特定问题和需要的实践和制品，即定制过程。二、UP开发案例为项目选择实践和UP制品可以编写为简短文档，该简短文档称为开发案例。开发案例是环境科目中的制品。下表是本课程POS教学案例的开发案例：,三、UP实践（活动）和制品简单开发案例(s:开始,r:精化)科目实践制品初始细化构造移交迭代I1E1.EnC1.CnT1.Tn业务建模敏捷建模领域模型s需求讨论会需求需求讨论会用例模型sr设想包装练习设想sr计点投票表决补充性规格说明sr词汇表sr设计敏捷建模设计模型sr测试驱动开发软件架构文档s数据模型sr实现测试驱动开发结对编程持续集成编码标准项目管理敏捷项目管理每日例会,第三章案例研究,3.1引言3.2案例研究策略:迭带开发+迭代学习3.3案例1:销售点终端3.3案例2:Monopoly游戏系统,第二部分初始阶段,第四章初始不是需求阶段第五章进化式需求第六章用例第七章其他需求,第四章初始不是需求阶段,目标:1.定义初始阶段的步骤2.为本部分后续内容做铺垫4.1什么是初始阶段初始阶段是可行性研究阶段。4.2初始阶段会创建的制品,初始阶段制品的样例制品*注释设想和业务用例描述高阶目标与约束、业务案例并提供执行摘要用例模型描述功能需求,确定大部分用例名称,详细分析10%的用例补充性规格说明描述其他需求，主要是非功能性需求。词汇表关键领域术语和数据字典,风险列表及描述风险及解决办法风险管理计划原型和概念验证澄清设想并验证技术思想迭代计划描述第一个细化迭代的任务书阶段计划和软件对细化阶段的持续时间和工作开发计划量进行粗略估计开发案例就特定项目对UP步骤和制品进行定制注*本阶段只完成其中部分制品，后续迭代中对其精化,第五章迭代式需求,目标：强调需求进化式定义FURPS+模型定义UP需求制品5.1需求(requirement)和需求管理(managerequirement),一、需求(requirement)需求就是系统或项目必须提供的能力和必须遵守的条件。二、需求管理(managerequirement)需求管理是UP的最佳实践之一。UP需求管理不主张瀑布方法。在变更不可避免，涉众意愿不明朗的情况下，UP更提倡“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”。这种方法就是通过迭代的方法不断收集需求反馈，逐步达到需求的基本稳定。,三、进化式需求与瀑布式需求在UP的需求管理定义中，强调了需求不断变更的客观性，因而包容需求中的变更，并将其作为项目的基本驱动力。这是与瀑布式需求根本不同的地方。统计表明，软件项目的平均需求变更率为25%。因此试图在开始就固定所有需求是不符合客观实际的，而且最终将导致项目的失败。,四、寻找需求的方法UP提倡“寻找”需求。提倡使用一些有效的技巧以获得启示。例如，与客户一同编写用例、开发者与客户共同参加需求讨论会、请客户代理参加焦点小组以及向客户演示每次迭代的成果以求得反馈等等。,5.2需求的类型(FURPS+)1.功能性(Functional):特性、功能、安全性2.可用性(Usability)：人性化因素、帮助、文档3.可靠性(Reliability)：故障频率、可恢复性、可预测性4.性能(Performance)：响应时间、吞吐量、准确性、有效性、资源利用率5.可支持性(Supportability)：适应性、可维护性、国际化、可配置性,“FURPS+”中的+指一些辅助性和次要的因素，如：实现(Implementation):资源限制、语言、工具、硬件等接口(Interface):接口的要求操作(Operation):操作的要求包装(Packging):包装的要求授权(Legal)：授权的要求注意，需求类型也经常分为功能性需求和非功能性需求，有些需求也称为质量需求，如可用性、可靠性、性能、可支持性等。,5.3UP制品如何组织需求*用例模型：一种使用系统的典型场景，主要用于功能需求*补充性规格说明：主要用于非功能性需求*词汇表：术语表或数据字典*设想：系统的高阶（高层）需求描述*业务规则（领域规则）：领域或业务所要求的规则，通常指领域内应遵守的法规、政策等。,第六章用例和用例模型,目标确定和编写用例使用摘要、非正式和详述等用例形式将测试应用于适当的用例上将用例分析与迭代开发联系起来,6.1什么是用例用例是文本形式的情节描述，用于描述某参与者使用系统以实现某些目标的情节。例如下面的文本描述就是处理销售的摘要形式的用例：,处理销售的摘要形式,处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计总额并逐行显示细目。输入顾客支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后携商品离开。,6.2为什么使用用例用户的参与是软件成功的重要保证。用例是一种优秀的方法，使领域专家和用户能共同参与以提供正确的需求，用例强调了用户的目标和观点。用例能够根据需要对复杂程度和形式化程度进行增减调节。用例强调了功能性需求，即“FURPS+”中的“F”，也可用于其他需求，用例是发现和定义需求的核心机制。用例定义了系统行为的契约。,6.3用例和用例模型(Use-CaseModel).UP在需求科目中定义了用例模型用例建模主要是编写文本的工作，用例模型是文本文挡，它是所有书面用例的集合，也是系统功能性和环境的模型。用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。虽然用例不是面向对象的，也不进行OO分析，但是用例是经典的OOA/OOD的关键需求输入。,6.4参与者、场景和用例1.参与者参与者(actor)是某些具有行为的事物，可以是人、计算机系统或其它机构、相关的软件系统甚至是系统自身（当它调用其它系统的服务时）。有三种参与者：1）主要参与者，用例的发起者，具有用户目标。2）协助参与者，为系统提供服务的系统或机构。3）幕后参与者，在用例行为中具有影响或利益关系，如销售系统中要考虑到政府税收机构。,2.场景场景(scenario)是参与者和系统之间的一系列特定的活动和交互，场景也称为用例的实例(usecaseinstance),一个场景是使用系统的一个特定情节或用例的一条执行路径。因此，用例就是一组相关的成功和失败的场景集合。其中每一个场景都是系统执行的一系列活动，这些活动产生了对某个参与者可观察的返回值。场景分为主成功场景和非主成功场景。,6.5用例的三种常用形式用例可用三种不同形式化程度或格式进行编写：1.摘要形式：简洁的一段式概要。通常用于主成功场景。摘要形式用在早期需求分析中，为快速了解主题和范围，几分钟完成。2.非正式形式：非正式的段落格式。用几个段落覆盖不同场景。非正式形式也是用在早期需求分析中，但主要用于交替场景，而非主场景。,3.详述形式：详细编写所有步骤及各种情况，同时具有补充部分，如前置条件和成功保证（后置条件）。详述形式在以摘要形式编写了大量用例后使用，在多次迭代中逐步完善。在第一次需求讨论会中，通常只详细编写其中少量（如10%）的具有重要架构意义和高价值的用例。,6.6详述形式的用例的模板用例的组成部分注释用例名称以动词开始范围要设计的系统级别用户目标或子功能主要参与者调用系统使之交付服务涉众及其关注点关注该用例的人及其关心的需求前置条件值得提醒的开始前必为真的条件,成功保证值的提醒的成功必须满足的条件主成功场景典型的无条件的理想下的成功场景扩展成功或失败的替代场景特殊需求相关的非功能性需求技术或数据变元表不同的I/O方法和数据格式发生频率会影响对实现的调查、测试和时间安排杂项一些未决问题,6.7详述形式的用例例子（处理销售）及解释：1.范围：范围界定所要设计的系统。本例为:NextGenPOS应用2.级别：用户目标级别和子功能级别1）用户目标级别(user-gol-level)：通常使用的级别,实现主要的参与者目标的场景。大致相当于业务流程工程中的基本业务流程(ElementaryBusinessProcess,EBP).2)子功能级别(subfunction-level)：描述支持用户目标所须的可被共享的重复的公共子步骤。本例为用户目标,3.主要参与者：系统用例的发起者。本例为收银员。4.涉众及其关注点：用例是涉及系统和应用相关的行为契约。因此与该用例有关的人和事的关注点要首先并详细列出，以便确定详细的系统职责。本例的涉众及其关注点描述如下：-收银员：希望能够准确、快速地输入，正确地计算和记录支付。错误的支付将导致收银员被罚。,-售货员：希望自动更新销售提成。-顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。-公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能完成销售。希望能够自动、快速地更新账务和库存信息。,-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。-政府税收代理：希望能从每笔交易中抽取税金。可能存在多级税收代理，如国税、地税等。-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。,5.前置条件和成功保证（后置条件）1）前置条件前置条件(precondition)给出在用例中场景开始之前必须为真的条件。用例中不会检查前置条件。通常，前置条件隐含已经成功完成的其他用例场景，必须写出的前置条件是那些应该引起警惕的条件。本例中的前置条件是：收银员必须经过确认和认证。,2）成功保证（后置条件）后置条件给出用例成功结束后必须为真的事物，该保证应满足所有涉众的需求。本例中的后置条件为：存储销售信息；准确计算税金；更新账务和库存信息；记录提成；生成票据；记录支付授权的批准。,6.主成功场景和步骤（或基本流程）主成功场景也称“理想路径”场景，有时也称为“基本流程”或“典型流程”。它描述了满足涉众关注点的典型成功路径。通常不包括任何条件或分支。条件或分支延迟到扩展部分。场景记录以下三种步骤：1）参与者之间的交互。2）确认通常由系统来完成的过程3）系统完成的状态变更,本例中主成功场景如下：1.顾客携带所购商品或服务到收银台通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入商品条码。4.系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5.系统显示总额和所计算的税金。,6.收银员告知顾客总额，并请顾客付款。7.顾客付款，系统处理支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理9.系统打印票据。10.顾客携带商品和票据离开。,7.扩展（或替代流程）扩展部分描述了主成功场景之外的其他所有场景或分支，包括成功和失败路径。因此往往占有更大的篇幅。理想路径与扩展路经相结合应该满足“几乎”所有涉众所关心的问题。当然，有些问题可作为非功能性需求在补充规格说明中描述，以使用例文本更加清晰。编写扩展用例时应注意：1）扩展场景是对主成功场景的分支，因此能够以对应的步骤1N对其进行标识。,如本例中主成功场景第3步为收银员输入商品ID，这里有两个问题需要说明：一是当出现无效的商品ID时应该如何处理；一是当顾客购买多个同类产品时应该如何处理。于是扩展场景可标识并编写为:3a.无效商品ID:1.系统提示错误并拒绝输入该标识.2.收银员响应该错误.3b.当有多个商品属于同一类别时(如5个汉堡),不必记录每个商品的ID:1.收银员可以输入商品标识和商品数量.,2）扩展由两部分组成：条件和处理。应尽可能使用系统或参与者能够检测到的事物作为条件。对比下面两个条件:5a.系统检测到与外部税务计算系统服务的通信故障。5a.外部税务计算系统工作不正常。第一种风格更好,因为这时系统能检测到的条件。而第二种只是一种推断。,3）扩展处理可以针对一个步骤，也可以针对一系列步骤，当一组步骤中都出现相同条件时，可以简化描述。如本例中当操作在第3到第6步中间（即录入商品并显示累计金额）时顾客要求从购买的商品中去掉一项，此时的扩展可标识并描述为：3-6a.顾客要求收银员从所购商品中去掉一项：1.收银员输入商品ID并将其删除。2.系统删除该项目并显示更新后的累计额.,4）当扩展处理结束时，默认情况下将回到主成功场景，除非扩展指出了其他方式。5）当扩展点非常复杂时，例如本例中的信用卡支付扩展,可以使用单独的用例来表示扩展。6）扩展可以嵌套。例如前面提到的处理无效商品ID时：3a.无效商品ID（读商品ID时出错）:1.系统提示错误并拒绝输入该标识.2.收银员响应该错误：2a.商品ID可读（如数字型的UPC）（手工输入）2b.系统内不存在该商品，但该商品附有价签2c.,7）如果要描述在任何步骤或大多数步骤都可能发生的扩展，那么可以使用*a、*b这样的标识。例如本例中在主成功场景后:扩展(或替代流程):*a.经理在任意时刻要求进行超控操作：*b.系统在任意时刻失败:,8）执行其他用例场景：有时用例会产生分支去执行其他用例场景。如“寻找产品帮助”是一个单独的用例，该用例有时会在销售用例中执行（当无法识别商品ID时）。在用例描述中可以通过在用例名称下加下划线来标识被调用的用例。如：“收银员通过执行寻找产品帮助以获取正确的商品ID及其价格”,7.特殊需求：与用例有关的非功能需求、质量属性或约束也应该写入用例，如设备的要求、时间的约束等，当然也可以把它们归到补充规格说明中。8.技术和数据变元表：需求分析中有时会涉及到一些与设计有关的要求（如通常客户会对I/O设备提出要求，或对使用的标准代码提出要求）。一般来说，应该避免早期不成熟的设计决策，但有时这些决策免不了，就要写入用例。,6.8两栏式用例格式可以使用两栏式的对话格式编写用例.该格式展示参与者和系统之间的交互.主成功场