9-1面向对象开发模型及过程

1、 2008 BUPT TSEG面向对象开发模型及过程Unified ProcessXiao ding TSEG2 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心UP基本结构基本结构UP是一个软件开发过程软件开发过程是一个将用户需求转化为软件系统所需要的活动集合。UP不仅仅是一个简单的过程，而是一个通用的过程框架。UP使用UML来制定和描述软件系统的所有视图。UP的突出特点：用例驱动、以构架为中心、使用迭代和增量的开发模式3 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心UP生命周期生命周期uUPUP是在重复一系

2、列组成软件系统生命周期的循环。每次循是在重复一系列组成软件系统生命周期的循环。每次循环都以向用户提供一个产品版本作为终结。环都以向用户提供一个产品版本作为终结。u每次循环都包括四个阶段：每次循环都包括四个阶段：初始、细化、构造和移交初始、细化、构造和移交。每。每个阶段又进一步细分为多次迭代过程个阶段又进一步细分为多次迭代过程u每次循环都产生系统的一个新的每次循环都产生系统的一个新的版本版本(version)(version)，每个版本，每个版本都是一个可交付的产品它包括由能够编译和运行的构件所都是一个可交付的产品它包括由能够编译和运行的构件所体现的源代码、各种手册和相关的交付品体现的源代码、各

3、种手册和相关的交付品u所完成的产品包括所完成的产品包括一整套一整套需求、非功能性需求和测试用例需求、非功能性需求和测试用例等文档，还包括构架和可视化的模型等文档，还包括构架和可视化的模型4 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心UP 的迭代增量开发模式的迭代增量开发模式uUP的每个阶段可以进一步分为几个迭代过程。它是生成可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。u迭代和增量的三个关键点计划一小步计划一小步说明、设计和实现一小步说明、设计和实现一小步集成、测试和运行每

4、次迭代（一小步）集成、测试和运行每次迭代（一小步）5 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心UP的其它重要概念的其它重要概念u在早期迭代中解决高风险和高价值的问题u不断地让用户参与评估、反馈和需求确认u在早期迭代中确定系统的核心架构u不断地验证质量，尽早并经常性的实施测试u进行可视化建模（使用UML）u认真管理需求，实施变更管理和配置管理6 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心u每个阶段都以一个里程碑作为结束标志。每个阶段都以一个里程碑作为结束标志。通过获得一组可可用的制品用的制品来定义每个里

5、程碑。u在每个阶段结束时进行评估以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。良好的评估可使项目顺利进入下一阶段。UP里程碑里程碑7 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心迭代和增量模型的特点迭代和增量模型的特点u将项目分解成许多袖珍项目，每一个袖珍项目都作为一次迭代将项目分解成许多袖珍项目，每一个袖珍项目都作为一次迭代u每个这样的袖珍项目都像过去的瀑布模型，因为它处理的是瀑布模型每个这样的袖珍项目都像过去的瀑布模型，因为它处理的是瀑布模型的活动。我们可以将每次迭代标注为一个的活动。我们可以将每次迭代标注为一个“袖珍瀑布袖珍

6、瀑布”u迭代不是一个完全独立的实体，它是项目的一个阶段，它在很大程度迭代不是一个完全独立的实体，它是项目的一个阶段，它在很大程度上是作为项目的一部分而得到的上是作为项目的一部分而得到的u规划人员设法对迭代进行排序以得到一条有序的途径，使早期的迭代规划人员设法对迭代进行排序以得到一条有序的途径，使早期的迭代为后期的迭代提供认知基础为后期的迭代提供认知基础u项目的早期迭代增进了对需求、问题、风险和方案领域的了解，而后项目的早期迭代增进了对需求、问题、风险和方案领域的了解，而后期迭代产生的附加增量最终构成了外部版本，即客户产品期迭代产生的附加增量最终构成了外部版本，即客户产品u最终的成功是一个一直前

7、进的迭代系列；即不必因为在后期的迭代中最终的成功是一个一直前进的迭代系列；即不必因为在后期的迭代中了解到的一些问题而回退了解到的一些问题而回退 2 3个迭代去修补模型个迭代去修补模型8 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心使用迭代和增量的理由使用迭代和增量的理由u为了尽早处理关键风险和重要风险为了尽早处理关键风险和重要风险u为了建立一个构架来指导软件开发为了建立一个构架来指导软件开发u能够处理不断变化的需求，并提供灵活变化的机制能够处理不断变化的需求，并提供灵活变化的机制u为了提供一个开发过程，使所有工作人员更高效地工作为了提供一个开发过程，

8、使所有工作人员更高效地工作9 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心合理规划迭代过程合理规划迭代过程u项目经理在当前迭代的目标未达到之前不应同意开项目经理在当前迭代的目标未达到之前不应同意开始下一次迭代。否则，就会导致必须改变计划来适始下一次迭代。否则，就会导致必须改变计划来适应新的情况应新的情况10 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心确定迭代次序确定迭代次序u用例设定了一个目标；而构架建立了一个模式。记用例设定了一个目标；而构架建立了一个模式。记住这个目标和模式，管理人员可以在人力资源充分

9、住这个目标和模式，管理人员可以在人力资源充分的情况下规划出进行产品开发的顺序的情况下规划出进行产品开发的顺序11 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心迭代和增量的优点迭代和增量的优点u允许变更需求允许变更需求：需求总是会变化，这是事实。u逐步集成元素逐步集成元素：集成并不只是简单的“一锤定音”。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。 u及早降低风险及早降低风险：因为风险一般只有在集成阶段才能发现

10、或得到处理。u有助于组织学习和提高有助于组织学习和提高：团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。u提高复用性提高复用性：早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。 u生成性能更强壮的产品生成性能更强壮的产品：性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。 u迭代流程自身可在进行过程中得到改进和精炼迭代流程自身可在进行过程中得到改进和精炼：一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待

11、改进之处，以便在下次迭代中更好地完成任务。 12 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心初始阶段初始阶段 Inceptionu主要目的是将一个好的想法发展为最终产品的一个构想。本质上，该阶段应回答下面三个问题：l系统向它的每个主要用户提供的基本功能是什么？系统向它的每个主要用户提供的基本功能是什么？l该系统的构架看起来是什么样子？该系统的构架看起来是什么样子？l开发该产品的计划如何？开销多大？开发该产品的计划如何？开销多大？u该阶段中最关键用例的最关键用例的简化用例模型简化用例模型可以回答第一个问题。u在这个阶段，构架是试验性的构架是试验性的，

12、通常只是一个包括主要子系统的大致轮廓。u在这个阶段，要确定最主要的风险及其优先次序，要对细化阶段进行详细规划，并对整个项目进行粗略估算。u注意，该阶段的目标不是定义所有的需求注意，该阶段的目标不是定义所有的需求13 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心初始阶段的目标和任务初始阶段的目标和任务u建立项目的建立项目的软件规模和边界条件软件规模和边界条件，包括运作前景、，包括运作前景、验收标准以及希望产品中包括和不包括的内容。验收标准以及希望产品中包括和不包括的内容。 u识别系统的识别系统的关键用例关键用例u对比一些主要场景，展示至少一个备选构架对

13、比一些主要场景，展示至少一个备选构架 u给出用户提出的非功能性要求描述给出用户提出的非功能性要求描述u评估整个项目的评估整个项目的总体成本和进度总体成本和进度u评估潜在的风险（源于各种不可预测因素）评估潜在的风险（源于各种不可预测因素）u准备项目的支持环境。准备项目的支持环境。u在阶段后期为细化阶段在阶段后期为细化阶段制定迭代计划制定迭代计划14 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心初始阶段的工件集初始阶段的工件集uVision：核心项目需求、关键特性、主要约束的总体构想核心项目需求、关键特性、主要约束的总体构想uBusiness Case：

14、业务用例业务用例uUse-case Model：初始的关键用例模型，占初始的关键用例模型，占10-20%10-20%的数量的数量uRisks ListuPlanProject-specific templates Software Development Plan Iteration PlanProduct Acceptance PlanuDevelopment CaseuToolsuGlossary15 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心电子收款机（电子收款机（POS）系统案例）系统案例uPOS机是一个计算机化应用的系统，用于记录销售信息

15、和处理支付过程，一般超市和零售商店都会用到。该系统的假设条件如下：系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统；系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统；它可能还需要与其他系统存在接口，比如信用卡支付系统、库存系它可能还需要与其他系统存在接口，比如信用卡支付系统、库存系统、记费系统等；统、记费系统等；该系统具有一定的容错性能，比如在与库存系统暂时终端连接时，该系统具有一定的容错性能，比如在与库存系统暂时终端连接时，仍能够进行物品的销售，不至于使系统瘫痪；仍能够进行物品的销售，不至于使系统瘫痪；多样化的终端接口：瘦客户多样化的终端接口：瘦客户WebWeb终端、终端、PCP

16、C、触摸屏、无线、触摸屏、无线PDAPDA能适应不同商店业务销售的功能要求，提供一种灵活性和定制能力能适应不同商店业务销售的功能要求，提供一种灵活性和定制能力的功能（作为系统开发的复用需求）的功能（作为系统开发的复用需求）16 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS案例案例-Step1u初始阶段应该考虑以下问题：项目的前景如何？业务背景和业务流程是什么？可行性如何？项目是否停止或继续进行？购买还是开发？粗略估计一下成本，估计收益。u主要目标：只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究

17、系统即可。（深入的研究是细化阶段的工作）u概括为：预见项目的范围、前景和业务案例；项目相关人员是否就项目的前景达成基本的一致，项目是否值得继续进行认真的研究。17 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step2u该阶段的主要工作成果集项目前景项目前景业务背景及业务流程业务背景及业务流程关键用例模型（关键用例模型（10-20%10-20%）补充性规格说明补充性规格说明词汇表词汇表.18 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step3u用例建模的基本过程：

18、1.选择系统边界 POS作为一个待构建的系统，包含软件、POS机、输入终端等，收银员、支付授权、税金计算等不包括在系统之内。任何系统之外的事物都在系统边界之外。2.识别主要角色 主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者。找出用户目标 次要角色：为系统提供服务的那些参与者。说明外部接口和协议 后台角色：对用例的行为感兴趣。保证找到并满足所有必要的兴趣。3.识别主要角色的目标 一般来讲：第2和第3步是同时进行的。19 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step4 寻找寻找ACtoru顾客：购买商品、退货

19、、支付费用希望得到快速的服务、能清楚地看到购买的商品和价格信息，得到收据以便退货u收银员：处理销售、处理退货、入款、出款希望能快速准确地输入，切无支付错误（出现错误时，将从其薪水中扣除）u经理：启动、关机、处理销售异常操作希望能快速地执行相应的操作，易于更正收银员出现的错误u系统管理员：添加用户、修改用户、删除用户、安全管理、系统表管理希望能方便地添加使用POS机的用户，并针对不同用户赋予不同的操作权限等u销售活动分析系统：分析销售数据和销售表现能够定期快速地获得必需的数据，制定相应的统计报表u库存系统、记费系统等20 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通

20、信软件工程中心主要参与者的确定主要参与者的确定u主要参与者是收银员还是顾客？答案：收银员。问题：为什么？为什么不是顾客？u主要原因取决于系统的边界，以及有关系统设计的主要对象。u如果将企业（超市）和销售服务视为一个整体，则主要参与者是“顾客”，顾客的主要目标是通过商店购买商品然后离开。u然而从POS系统建设的角度出发，认为使用系统的用户是收银员，他（她）的目标是使用POS机并通过该机处理销售交易21 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step5 确定用例确定用例u顾客：购买商品u收银员：处理销售、销售前准备、结束销售u经

21、理：开关机、处理销售异常u系统管理员：用户管理、权限安全管理uu由系统的主要参与者确定系统的关键用例销售用户管理权限安全管理22 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step6 用例图用例图u绘制初始用例图用户管理(from )安全管理(from )系统管理员(from Actors)收银员(from Actors)认证系统(from Actors)计费系统(from Actors)销售(from )23 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例-Step6

22、 关键用例描述关键用例描述u用例：销售u主要参与者：收银员u项目相关人员及其兴趣：（参见第19页）u前置条件：收银员必须已经被识别和授权u后置条件：存储销售信息、更新账目和库存信息、生成收据等u主要成功场景：1.顾客携带商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格、累加值。收银员重复34步，直到商品输入结束。5.系统显示总值并计算税金。6.收银员请顾客付款。7.顾客支付，系统处理支付。8.系统记录完整的销售信息，并将销售和付款信息发送到外部的帐务系统和库存系统。9.系统打印收据10.顾客带着商品和收据离开。u24 2007

23、 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心POS机案例机案例- step7 其他文档编写其他文档编写 用例模型只是描述了系统的功能性需求，其他需求放在下列工件中描述：前景（vision）：概述项目的远景。用简洁的语言表达项目总体想法，包括：项目为什么被提出？有哪些问题？有哪些项目相关人员？他们需要什么？以及提出了哪些解决方案等。补充规格说明：未在用例中描述的FURPS+需求。术语表：术语及其定义，还可以用作数据字典。25 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求：需求：FURPS+uFunction（功能

24、）：特性、能力、安全性uUsability（可用性）：人性化因素、帮助和文档；uReliability（可靠性）：故障周期、可恢复性、可预测性；uPerformance（性能）：响应时间、吞吐量、准确性、有效性；uSupportability（可支持性）：适应性、可维护性、国际化、可配置性。u：一些辅助性和次要的因素。Implementation（实现）：资源限制、语言和工具、硬件等；Interface（接口）：与外部系统接口所加的约束；Operations（操作）：系统操作环境中的管理Package（包装）Legal（授权）：许可证或其他方式。26 2007 BUPT TSEG 北京邮电大学

25、北京邮电大学 通信软件工程中心通信软件工程中心前景前景 Vision page1u修订历史u简介u定位商业机会问题综述产品定位综述替代方案和竞争对手u项目相关人员描述项目相关人员（非用户）概述用户概述项目相关人员主要的高级别目标和问题用户级别目标用户环境27 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心前景前景 Vision page2u产品纵览产品远景优点概述假设和依赖成本和定价授权和安装u系统特性概述系统特性是系统提供的一个外部可观测到的服务，这种服务能够直接满足项目相关人员的需要。特性是系统能做的事情。系统会做，比如记录销售记录、支付授权（信用

26、卡、借记卡、支票）u其他需求和约束28 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心补充性规格说明补充性规格说明page1u修订历史u简介u功能性（跨越许多用例的一般功能）日志和错误处理可插入的业务规则安全性u可用性人为因素，比如屏幕的分辨率要求u可靠性可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，以使交易能够完成。性能：交易的处理速度29 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心u可支持性适应性可配置性u实现约束：用户要求使用Java技术的解决方案u采购的组件u免费的开放源码的组件u接口值

27、得注意的硬件及其接口软件接口u领域（业务）规则：规定一个领域或者业务如何操作，如：退货、折扣等。u法律问题u有关感兴趣的业务规则：商品定价、信用卡支付需要签名、条形码产品等补充性规格说明补充性规格说明page230 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心术语表术语表 Glossaryu修订历史u定义术语定义和相关信息别名31 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段细化阶段 Elaborationu详细说明系统的绝大多数用例，详细说明系统的绝大多数用例，并根据关键用例的实现在并根据关键用例

28、的实现在第第1-2次迭代中设计出系统的构架次迭代中设计出系统的构架u最关键用例都要在这个阶段具体化。最关键用例都要在这个阶段具体化。该阶段的结果是构架该阶段的结果是构架基线基线u在细化阶段末期，要规划完成项目的活动，估算完成项目在细化阶段末期，要规划完成项目的活动，估算完成项目所需的资源。所需的资源。u该阶段的关键问题是：该阶段的关键问题是：用例、构架和计划是否足够稳定可用例、构架和计划是否足够稳定可靠，风险是否得到充分控制，以便能够按照合同的规定完靠，风险是否得到充分控制，以便能够按照合同的规定完成整个开发任务。成整个开发任务。32 2007 BUPT TSEG 北京邮电大学北京邮电大学 通

29、信软件工程中心通信软件工程中心细化阶段的目标和任务细化阶段的目标和任务u确保构架、需求和计划足够稳定，充分减少风险，从而能确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。够有预见性地确定完成开发所需的成本和进度。 u处理在构架方面具有重要意义的所有项目风险处理在构架方面具有重要意义的所有项目风险 u建立一个已确定基线的构架建立一个已确定基线的构架 u制作产品质量构件的演进式制作产品质量构件的演进式原型原型 u细化前景文档细化前景文档u在细化阶段后期为构造阶段制定详细的迭代计划在细化阶段后期为构造阶段制定详细的迭代计划u建立支持环境。这包括创建开发案例

30、、创建模板和指南、建立支持环境。这包括创建开发案例、创建模板和指南、安装工具安装工具 33 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段的工件集细化阶段的工件集uVision uPrototypesUse-case Model ：至少80%的用例要完成，所有用例均被识别，大多数用例描述被开发Domain Model： 结合用例模型完成相应的领域模型构建Analysis Model： 可选，主要用于帮助系统结构的确定Design Model： 结合用例给出系统的静态和动态结构Data Model： 结合用例模型和领域模型给出相应的数据模型Imp

31、lementation Model：将部分用例转化为代码uRisk ListuToolsuSoftware Architecture DocumentuSoftware Development PlanuIteration Plan34 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1POS机案例机案例 确定迭代次数确定迭代次数u进入到细化阶段的首要工作就是确定阶段的迭代次数u根据细化阶段的主要目标：构建架构基线，来确定具体的迭代次数u一般情况下，通过实现2-3个用例来证明架构的稳定性u本案例计划使用两次迭代35 2007 BUPT TS

32、EG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 构建领域模型构建领域模型 Domain Modelu领域模型是OO分析中最重要的和经典的模型，它阐述了领域中的重要业务概念u领域模型是UP过程的可选制品，但领域模型很大程度上会影响用例模型分析和构建，甚至是设计模型中的软件对象。u领域模型的构建限定于当前迭代所分析的用例，它能够不断地演进用以展示相关的重要概念。u定义：是对领域内的概念类或现实世界中对象的可视化表示，而非软件对象。也称之为概念模型、分析对象模型、领域对象模型。36 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程

33、中心细化阶段：迭代1 领域模型领域模型 Domain Modelu应用UML表示法，领域模型被描述为一组没有定义操作的类图，提供了概念透视图，用以展示：领域对象或概念类概念类之间的关联概念类的属性u概念类的定义：是思想、事物或对象，可以从其符号、内涵和外延来考虑符号：表示概念类的词语或图形内涵：概念类的定义外延：概念类所适用的一组实例表示表示“销售销售”交易的事件、具有时间和日期交易的事件、具有时间和日期销售销售1 1、销售、销售22销售销售n n37 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 领域模型不是软件组件模型领域模型不是

34、软件组件模型u领域模型所关注的仅仅是客观世界中的事物并将其可视化，而非诸如Java或C#类的软件对象。u以下元素不适用于领域模型软件制品，例如窗口、界面、数据库软件模型中具有职责或方法的对象领域模型领域模型软件制品，不属于领域模型销售数据库软件类制品软件类制品38 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1降低与降低与OO建模之间的表示差异建模之间的表示差异uOO的关键思想：领域层软件类的名称要源于领域模型的信息和职责u这样可以减小人们的思维与软件模型之间的表示差异启发了软件启发了软件对象及其名称对象及其名称39 2007 BUPT

35、 TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 创建领域模型的原则创建领域模型的原则u以当前迭代所关注的需求为界寻找概念类将其绘制为UML类图中的类添加关联和属性u寻找概念类的三条策略重用和修改现有的概念模型根据经验使用分类列表根据用例说明确定名词短语40 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 使用分类列表寻找概念类使用分类列表寻找概念类概念类分类示例概念类分类示例物理或具体对象RegisterAirplane抽象名词的概念HungerAcrophobia事物的设计、描述和规范Produ

36、ctSpecificationFlightDescription组织SalesDepartmentObjectAirline位置StoreAirport事件Sale, Payment, MeetingFlight, Crash, Landing交易Sale, PaymentReservation过程SellingAProductBookingASeat交易项目SalesLineItem规则和政策RefundPolicyCancellationPolicy人的角色CashierPilot分类ProductCatalogPartsCatalog其他事物的容器Store, BinAirplane有关

37、工作、契约、财务和法律事物的记录Receipt, Ledger, EmploymentContractMaintenanceLog容器包含的元素ItemPassenger财务设施及服务LineOfCreditStock在该系统之外的系统CreditPaymentAuthorizationSystemAirTrafficControl手册、文档、引用论文、书籍DailyPriceChangeListRepairManual41 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 通过识别名词短语寻找概念类通过识别名词短语寻找概念类u用例是通过

38、名词短语识别领域概念的丰富源泉，因此应该详述用例。u名词可以是概念类，也可能是概念类的属性。属性一般是可以赋值的，比如数字或者文本。该名词可以这样赋值吗？如果不行的话，那么就有可能是一个概念类。如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。需要注意的是：不存在名词到类的映射机制，因为自然语言具有二义性u这种方法的弱点是自然语言的不精确性42 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS机案例机案例- Step1寻找概念类寻找概念类u主要成功场景：1.顾客携带商品到达POS机收费口2.收银员开始一次新的销

39、售3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格、累加值。收银员重复34步，直到商品输入结束。5.系统显示总值。6.收银员请顾客付款。7.顾客支付，系统处理支付。8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统和库存系统。9.系统打印收据10.顾客带着商品和收据离开。u43 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS机案例机案例-寻找到的初始概念类寻找到的初始概念类u顾客：商品销售的主体和驱动者u商品：顾客所需购买的物品uPOS机：商店进行商品销售的设备u收银员：商店执行商品销售并使用

40、销售设备的人员u销售：一次或多次商品交易事件u商品标识：是销售设备能唯一标识物品的IDu商品条目：销售设备记录每一个商品销售的具体信息，销售小票中的多条商品信息u商品总价：一次销售所有商品的总价u付款：顾客支付该次销售交易的金额u帐务系统：销售设备将一次销售交易的金额等信息传递给记账系统u库存系统：一次销售将对库存的商品信息和数量进行修改u商品描述：每一个销售商品的具体信息44 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 添加关联添加关联u关联通常意味着我们必须知道这个关系的存在，并且这个关系需要保存一段时间，时间的长短取决于关联所

41、处的语境。u添加关联的两种方式：需要将概念之间的关系信息保持一段时间的关联需要知道（need-to-know）型关联只需理解型关联反映了理解概念类所需的本质信息45 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 添加关联添加关联-使用常见的关联列表使用常见的关联列表分类示例分类示例A在物理上是在物理上是B的一的一部分部分Drawer RegisterWing AirplaneA是是B的一个组织子的一个组织子单元单元Department StoreMaintenance AirlineA在逻辑上是在逻辑上是B的一的一部分部分SalesL

42、ineItem SaleFlightLegFlightRouteA使用或管理使用或管理BCashier RegisterPilot AirplaneA在物理上包含在在物理上包含在B中或者依赖于中或者依赖于BRegister Store, Item ShelfPassenger AirplaneA与与B通信通信Customer CashierReservation Agent PassengerA在逻辑上包含在在逻辑上包含在B中中ItemDescription CatalogFlight FlightScheduleA与一个交易与一个交易B有关有关Customer PaymentPassenge

43、r TicketA是对是对B的描述的描述ItemDescription ItemFlightDescription FlightA是一个与另一个交是一个与另一个交易易B有关的事务有关的事务Payment SaleReservation CancellationA是交易或者报表是交易或者报表B中的一项中的一项SalesLineItem SaleMaintenance Job Maintenance LogA与与B相邻相邻SalesLineItem SalesLineItemCity CityA为为B所知所知/为为B所记录所记录/录入录入B中中/为为B所捕获所捕获Sale RegisterRese

44、rvation FlightManifestA为为B所拥有所拥有Register StorePlane AirlineA是是B的一个成员的一个成员Cashier StorePilot AirlineA是一个与是一个与B有关的有关的事件事件Sale Customer, Sale StoreDeparture Flight46 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 关联与概念类关联与概念类u识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。u根据“需要知道型”原则获取最小集合的关联，然后利用“只需理解型”

45、关联增强对领域中关键概念的理解。u太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。u避免显示冗余或导出关联。47 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS机案例机案例- Step2 添加关联添加关联uPOS机案例中领域模型的核心概念类应该是销售销售与POS机之间存在“使用”或者“扫描”的关系一个销售“包括”多个销售条目一次销售必然要有顾客“支付”相应的金额销售条目“记录”的是销售的商品信息POS机“位于”库存系统中商店的商品“存储”于库存系统48 2007 BUPT TSEG 北京邮电大学北京邮电大学 通

46、信软件工程中心通信软件工程中心细化阶段：迭代1 案例案例- Step3 构建初始领域模型类图构建初始领域模型类图商店商店49 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 Step 4 添加属性添加属性u领域模型中包含的属性：是需求（用例）建议或者暗示我们需要记忆的那些信息。u有效属性类型原则：概念模型中的属性应当被优先定义为简单属性或数据类型。如：boolean、date、number、string、text、time，其他常见的简单数据类型如：address、color、zip等。用关联而不是用属性来联系概念类，避免用属性表达一个

47、复杂的领域概念。50 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS机案例机案例- Step5 完善领域模型类图完善领域模型类图付款 顾客(from Actors)销售1111Payed-by1111is for收银员(from Act.POS机10.110.1Captured on1111works on帐务系统1n1nLogs-completed销售条目1.n11.n1Contained-in商品10.110.1Records-sale-of商店11.n11.nHouses1111records-accounts-forn1

48、n1stocks产品目录1n1nUsed-by产品描述1n1ndescribes11.n11.ncontains51 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 Step 6 领域模型是否正确领域模型是否正确u没有所谓唯一正确的领域模型u所有的模型都是用于理解领域的特点u领域模型主要是在特定群体中用于理解和沟通的工具领域的概念术语概念之间的关系52 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 构建用例模型构建用例模型 Use-Case Modelu用例模型的组成用例图用例

49、说明SSD系统顺序图操作契约53 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS案例案例-Step1-用例模型之用例模型之SSDu系统顺序图（SSD）：用于说明与系统相关的输入和输出事件，它是操作契约和对象设计的输入。u用例图表达了角色使用系统的目标，那么角色是如何激活系统操作满足其目标的呢？面向对象思想中，通过事件激活。系统事件有哪些？系统顺序图（SSD）u用例描述角色是如何与系统进行交互的。在交互中，角色对系统发起系统事件，系统中的某些系统操作对这些事件加以处理。例如，当收银员使用扫描仪输入商品ID时，收银员请求POS机记录

50、对该商品的销售（EnterItem事件），该事件引发了系统的操作。用例说明暗示了EnterItem事件，而SSD将其变得具体和明确。54 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 系统顺序图系统顺序图 SSDu系统顺序图：为每个用例的主要成功场景以及频繁或复杂的替代场景进行设计；描述外部角色与系统（作为一个黑箱）之间交互的事件；l本次迭代主要考虑主要角色产生的事件；l也可以描述次要角色接收系统产生的事件。描述事件的顺序。u此时所描述的系统行为只需要确定系统“做什么”，而无需解释如何做。55 2007 BUPT TSEG 北京邮电大

51、学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 系统顺序图系统顺序图 SSD目的目的u软件设计中需要明确的问题是：系统中会发生什么事情？为什么？u原因是我们必须为这些处理和事件（来自于鼠标、键盘）来设计软件来自于参与者（人或计算机）的外部事件时间事件错误或异常（通常源于外部）u因此需要准确地知道什么是外部输入的事件，即系统事件56 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 SSD与用例图之间的关系与用例图之间的关系简化的现金支付的处理销售场景简化的现金支付的处理销售场景u顾客携带所需商品到POS机进行付款u收银员

52、开始一次新的销售交易u收银员输入商品项目标识u系统逐条记录出售的商品项目，并显示该商品的基本描述、数量、价格和累计金额u系统显示总价u收银员告知顾客总价并提请付款u顾客支付u系统处理支付。 : 收银员 : 系统1:makeNewSale2*more items:enterItem(itemID,quantity)description,total3:endSaletotal4:makepayment(amount)change due, receipt57 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS案例案例-Step2- 整

53、理整理SSD的信息的信息u在SSD中所展示的元素：操作名称、参数、返回的数据等u需要对这些在图中很简洁的数据加以适当的解释，以便为设计时能明确输入了什么和输出了什么。u词汇表是详细描述这些元素的最佳选择例如，实例中的一条返回信息“change due,receipt”change due,receipt”。就可以在词汇表中加入票据条目，显示票据样本（数码图片）、详细内容和布局58 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 POS案例案例-Step3-用例模型之用例模型之操作契约操作契约u用例的操作契约可以作为用例模型中一个补充环节

54、，它对用例指出的系统操作的作用提供了更详细的分析。u操作契约的主要输入是SSD中确定的系统操作、领域模型或者领域专家的见解。u操作契约也可以作为对象设计的输入u定义操作执行的结果（对象状态的改变），而非过程59 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 操作契约的组成操作契约的组成操作：操作以及参数的名称交叉引用： （可选择）可能发生此操作的用例前置条件： 在操作执行前，领域模型中系统或对象状态的假设，它们在此操作的逻辑内不会得到测试，而被假设为真，同时，它们并非无关紧要而应让读者了解此假设的存在。后置条件： 操作完成后领域模型中

55、对象的状态。（最重要的部分）操作：enterItem(itemID:ItemID,quantity:integer)交叉引用：用例：Sale前置条件：有一个Sale正在进行后置条件：1.创建一个SalesLineItem实例sli（实例创建）2.sli和当前的Sale形成关联（关联形成）3.sli.quantity变成quantity（属性修改）4.在itemID匹配的基础上，sli和ProductSpecification形成关联（关联形成）60 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 操作契约的后置条件操作契约的后置条件u后

56、置条件描述了领域模型内对象的变化，后置条件可以分为三种类型：创建或删除实例属性值的变化形成或消除关联（UML的链接）u后置条件是声明性的，而且是面向状态变化而不是面向行为的。正是基于此，后置条件能够在不描述系统操作如何实现的前提下描述系统操作引起系统状态的变化，给出了分析的细节。因此，分析阶段可以集中精力于系统发生了什么而非是如何发生的。u在需求分析时，要为系统操作产生一个完整、详细的后置条件集是不可能甚至是不需要的。（初始契约不完整）。61 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 示例：示例：enterItem后置条件后置条件

57、u创建和删除实例输入itemID和商品条目的quantity后，会创建哪些新对象？答：创建了SalesLineItem的实例Sli。u属性修改在收银员输入商品条目标识和对应的商品数量后，修改了哪些新对象或现有对象的属性？答：SalesLineItem的quantity被赋值为quantity参数，即修改属性 Sli.quantity = quantityu关联形成和消除在收银员输入商品的itemID和quantity后，形成或清除了哪些新的或已有的对象之间的关联？答：Sli与当前的Sale关联答：基于itemID的匹配，Sli与ProductDescription关联62 2007 BUPT

58、TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 示例：销售用例中的系统操作契约示例：销售用例中的系统操作契约 page1 操作：makeNewSale( ) 交叉引用：用例：Sale 前置条件：无 后置条件：1.创建了Sales的实例s（实例创建）2.S被关联到Register（关联形成）3.S的属性被初始化（属性修改） 操作：enterItem(itemID:ItemID,quantity:integer) 交叉引用：用例：Sale 前置条件：有一个Sale正在进行 后置条件：1.创建一个SalesLineItem实例sli（实例创建）2.sli和当前的

59、Sale形成关联（关联形成）3.sli.quantity变成quantity（属性修改）4.在itemID匹配的基础上，sli和ProductSpecification形成关联（关联形成）63 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心细化阶段：迭代1 示例：销售用例中的系统操作契约示例：销售用例中的系统操作契约 page2 操作：endSale( ) 交叉引用：用例：Sale 前置条件：正在进行中的销售 后置条件：1.Sale.iscomplete被置为真（修改属性） 操作：makePayment(amount:Money ) 交叉引用：用例：S

60、ale 前置条件：正在进行中的销售 后置条件：1.创建了Payment的实例p（实例创建）2.p.amountTendered被赋值为amount（修改属性）3.P被关联到当前的Sale（形成关联）4.当前的Sale被关联到Store（形成关联），将其加入到完成销售的历史日志中64 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心用例模型、领域模型与设计模型的关系用例模型、领域模型与设计模型的关系65 2007 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心总结总结初始阶段、细化阶段的初次迭代初始阶段、细化阶段的初次迭代u