第五章协同过程模型实例课件.ppt

上传人(卖家):三亚风情 文档编号:3002878 上传时间:2022-06-21 格式:PPT 页数:161 大小:788KB
下载 相关 举报
第五章协同过程模型实例课件.ppt_第1页
第1页 / 共161页
第五章协同过程模型实例课件.ppt_第2页
第2页 / 共161页
第五章协同过程模型实例课件.ppt_第3页
第3页 / 共161页
第五章协同过程模型实例课件.ppt_第4页
第4页 / 共161页
第五章协同过程模型实例课件.ppt_第5页
第5页 / 共161页
点击查看更多>>
资源描述

1、第五章第五章 协同过程模型协同过程模型=Synergy过程模型过程模型=初始阶段初始阶段=细化阶段细化阶段=构造阶段构造阶段=移交阶段移交阶段1. 协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/ /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始初始细化细化构造构造移交移交l它是对它是对RUP过程的剪裁,是基于风险的增量和过程的剪裁,是基于风险的增量和迭代的开发迭代的开发l这一过程是经过实践检验的适

2、合这一过程是经过实践检验的适合C/S、B/S结构结构的软件开发模型的软件开发模型l它分为四个阶段,每个阶段至少通过它分为四个阶段,每个阶段至少通过3次迭代过次迭代过程完成阶段目标程完成阶段目标l每个迭代有明确的目标和评估标准每个迭代有明确的目标和评估标准l整个项目划分为整个项目划分为3次目标明确的增量开发,每次次目标明确的增量开发,每次增量作为一个可执行版本,提交用户使用增量作为一个可执行版本,提交用户使用2. 初始阶段初始阶段总体目标:生成具有必要内容的业务案例,总体目标:生成具有必要内容的业务案例,以证明启动项目是正确的以证明启动项目是正确的l确定系统范围确定系统范围l扩展系统构想扩展系统

3、构想l制定项目规划制定项目规划l设立评价准则设立评价准则主要工作:主要工作:制定项目规划时,须考虑下面的五种关键制定项目规划时,须考虑下面的五种关键性的输入信息:性的输入信息:l待开发系统必须支持的特征待开发系统必须支持的特征 l投资或关注系统用途的涉众投资或关注系统用途的涉众 l使用系统的用户使用系统的用户 l系统必须响应的事件系统必须响应的事件 l项目中存在的限制与风险项目中存在的限制与风险 2. 初始阶段初始阶段协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/

4、 /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始初始细化细化构造构造移交移交2. 初始阶段初始阶段(续续) 通过三次迭代完成生命周期目标里程碑:通过三次迭代完成生命周期目标里程碑:迭代一:确定事件与参与者迭代一:确定事件与参与者迭代二:用例分析与初步建模迭代二:用例分析与初步建模迭代三:细化用例路径和准备系统初始构架迭代三:细化用例路径和准备系统初始构架l 确定参与者确定参与者l 提取事件提取事件l 建立事件表建立事件表l 评估首次迭代评估首次迭代 迭代一:确定参与者和事件迭代一:确定参与者和事件事件:事件:可以描述的、值得

5、记录的在某一特定时间和地点发可以描述的、值得记录的在某一特定时间和地点发生的事情生的事情( (动作动作) ) 参与者:参与者:在系统之外与系统交互的某人或某事物在系统之外与系统交互的某人或某事物 迭代一:确定参与者和事件迭代一:确定参与者和事件(续)(续)提取事件提取事件-需要注意的问题需要注意的问题l在集体讨论时不要对系统边界做出不成在集体讨论时不要对系统边界做出不成熟的假定熟的假定 l在初次集体讨论中,不要拒绝接纳超出在初次集体讨论中,不要拒绝接纳超出系统范围的事件系统范围的事件 l在初始阶段,提取事件的目的是确定系在初始阶段,提取事件的目的是确定系统范围,故事件的层次较高统范围,故事件的

6、层次较高 建立事件表建立事件表-需要注意的问题需要注意的问题l填写事件表填写事件表主语主语动词动词宾语宾语频度频度触发方式触发方式响应响应客户客户 下下订单订单1000/天天随机随机编辑订单并保存到系统中编辑订单并保存到系统中 l初次开会集中讨论事件初次开会集中讨论事件l第二次开会第二次开会集中精力添加附加信息并集中精力添加附加信息并填写事件表填写事件表在项目规划中,团队成员必须对模板中在项目规划中,团队成员必须对模板中包括的基本组成部分(特性、评价成功因包括的基本组成部分(特性、评价成功因素)、参与者和事件达成一致意见。填写项素)、参与者和事件达成一致意见。填写项目规划文档中的相应部分内容目

7、规划文档中的相应部分内容l 确定参与者确定参与者l 提取事件提取事件l 建立事件表建立事件表l 评估首次迭代评估首次迭代 迭代一:确定参与者和事件迭代一:确定参与者和事件初始阶段首次迭代检查点初始阶段首次迭代检查点l项目规划文档中所涉及的内容是否已经确定项目规划文档中所涉及的内容是否已经确定l依据应用领域的相关信息确定角色及其职责依据应用领域的相关信息确定角色及其职责l事件是系统必须支持的功能,它是系统需求的事件是系统必须支持的功能,它是系统需求的核心,接下来将通过定义用例满足要求核心,接下来将通过定义用例满足要求 2. 初始阶段初始阶段(续续) 通过三次迭代完成生命周期目标里程碑:通过三次迭

8、代完成生命周期目标里程碑:迭代一:确定事件与参与者迭代一:确定事件与参与者迭代二:用例分析与初步建模迭代二:用例分析与初步建模迭代三:细化用例路径确定系统初始构架迭代三:细化用例路径确定系统初始构架l建立用例模型建立用例模型l勾画用例路径勾画用例路径l评估迭代二评估迭代二迭代二:用例分析与初步建模迭代二:用例分析与初步建模迭代二:迭代二:用例分析与初步建模用例分析与初步建模(续(续)l用例是一个参与者履行的用例是一个参与者履行的与其行为相关与其行为相关的相互作的相互作用序列,它要为这个参与者提供用序列,它要为这个参与者提供一定的价值一定的价值表明一组交互双方,在交互过程中应含有自制的结束单表明

9、一组交互双方,在交互过程中应含有自制的结束单元,业务不能对其强加干涉,进行时间延迟元,业务不能对其强加干涉,进行时间延迟用例必须由一个参与者发起,并有一个参与者看到结束用例必须由一个参与者发起,并有一个参与者看到结束表明用例应该达到某些业务目标表明用例应该达到某些业务目标用例一定要使系统保持在一个稳定状态下,它不应该只用例一定要使系统保持在一个稳定状态下,它不应该只是部分完成是部分完成l用例面向目标用例面向目标l用例模型是系统既定功能及系统环境的模型,用例模型是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约并作为客户和开发人员之间的契约确定系统用例的两个切入点确定系统用例的两个切

10、入点l 使用事件表使用事件表 特征特征事件清单事件清单事件表事件表 用例用例l确定使用系统的参与者确定使用系统的参与者确定确定Use CaseUse Case时需要注意的问题时需要注意的问题l封闭原则封闭原则l合并原则合并原则l避免编程避免编程l用例层次用例层次l检查用例与事件的对应关系检查用例与事件的对应关系l范围蠕变问题范围蠕变问题 所有的需求都源于要满足的事件及用来满足它们的用例。所有的需求都源于要满足的事件及用来满足它们的用例。如果它没有被定义为一个事件,并且没有通过一个用例来满足,如果它没有被定义为一个事件,并且没有通过一个用例来满足,那么它就是一个变更要求,需要一定形式的改变控制动

11、作那么它就是一个变更要求,需要一定形式的改变控制动作 用例图是从项目发起者的视角看的最用例图是从项目发起者的视角看的最重要的图,它表示了应用的问题域,并从重要的图,它表示了应用的问题域,并从一个较高层次的视角界定了项目的范围,一个较高层次的视角界定了项目的范围,它是划分项目成为多个增量的依据。它是划分项目成为多个增量的依据。 l建立用例模型建立用例模型l勾画用例路径勾画用例路径l评估迭代二评估迭代二迭代二:用例分析与初步建模迭代二:用例分析与初步建模勾画用例路径勾画用例路径l用例路径用例路径 描述用例内部包含的为了回应事描述用例内部包含的为了回应事件所采取的步骤件所采取的步骤前置条件前置条件结

12、束状态结束状态基本路径基本路径备选路径备选路径用例路径分类用例路径分类用例路径分类用例路径分类l基本路径基本路径 是指用例在最通常情况下发生的路径是指用例在最通常情况下发生的路径l备选路径备选路径 是一个合法路径是一个合法路径, ,只是发生的频率低只是发生的频率低 一些而已一些而已l异常处理路径异常处理路径 不经常发生的路径,应用程序必不经常发生的路径,应用程序必 须要来捕获的错误情况须要来捕获的错误情况 并不是每个用例都必须有异常处理路径。并不是每个用例都必须有异常处理路径。用例路径描述的视角用例路径描述的视角l用户用户插入插入ATMATM卡卡l系统系统要求输入合法的密码要求输入合法的密码l

13、用户用户输入正确密码输入正确密码, , 如果用户输入如果用户输入的密码有误的密码有误, ,转至备选事件流转至备选事件流A1.A1.l系统系统提示用户选择提示用户选择“存款存款”或者或者“取款取款” ” l用户用户选择选择“取款取款”l系统系统提示用户输入取款金额提示用户输入取款金额l用户用户输入输入( (合理合理) )取款金额并确认取款金额并确认, , 如果取款金额不合理如果取款金额不合理, ,转至备选事转至备选事件序列件序列A2A2l系统系统从帐户中扣除取款金额从帐户中扣除取款金额, , 提示提示用户用户“打印收据打印收据”或者或者“不打印收不打印收据据”l用户用户要求不打印收据要求不打印收

14、据, ,如果要求打如果要求打印收据印收据, , 转至备选事件序列转至备选事件序列A3A3l系统系统显示显示“交易结束交易结束”l系统系统要求用户输入合法的密码要求用户输入合法的密码l系统系统提供提供“存款存款”和和“取款取款”两种两种选项选项l系统系统能够接受用户录入取款金额能够接受用户录入取款金额l系统系统能够从帐户中扣除取款金额能够从帐户中扣除取款金额l系统系统允许选择允许选择“打印收据打印收据”或者或者“不打印收据不打印收据”l系统系统能够显示交易结束信息能够显示交易结束信息立足开发者视角立足用户视角哪一个更利于用户作出哪一个更利于用户作出判断,从而形成判断,从而形成 “ “共同共同的理

15、解的理解”?w 用户用户插入插入ATMATM卡卡w 系统系统要求输入合法的密码要求输入合法的密码w 用户用户输入正确密码输入正确密码, , 如果用户输入的密如果用户输入的密码有误码有误, ,转至备选事件流转至备选事件流A1.A1.w 系统系统提示用户选择提示用户选择“存款存款”或者或者“取款取款” ” w 用户用户选择选择“取款取款”w 系统系统提示用户输入取款金额提示用户输入取款金额w 用户用户输入输入( (合理合理) )取款金额并确认取款金额并确认, , 如果如果取款金额不合理取款金额不合理, ,转至备选事件序列转至备选事件序列A2A2w 系统系统从帐户中扣除取款金额从帐户中扣除取款金额,

16、 , 提示用户提示用户“打印收据打印收据”或者或者“不打印收据不打印收据”w 用户用户要求不打印收据要求不打印收据, ,如果要求打印收据如果要求打印收据, , 转至备选事件序列转至备选事件序列A3A3w 系统系统显示显示“交易结束交易结束”基本路径基本路径备选路径备选路径w A1. .A1. .w A2. .A2. .w .用例路径描用例路径描述的视角述的视角勾画用例路径勾画用例路径l用例路径描述用例路径描述一旦角色和用例已经确定,下一步就一旦角色和用例已经确定,下一步就要开发一个活动流作为确定不同场景的起要开发一个活动流作为确定不同场景的起始点。始点。当开发了不同的活动流后,所有通用当开发了

17、不同的活动流后,所有通用的内部用例就可以确定出来,并且可以分的内部用例就可以确定出来,并且可以分成不同的通用用例。成不同的通用用例。 评估迭代二评估迭代二l用例在技术实现上是中立的,可应用于团队开发用例在技术实现上是中立的,可应用于团队开发使用的任何过程和方法使用的任何过程和方法l用例定义了一组用例实例,其中每个实例都是系用例定义了一组用例实例,其中每个实例都是系统所执行的一系列操作,这些操作生成特定视角统所执行的一系列操作,这些操作生成特定视角可以观测的值,并对系统有意义可以观测的值,并对系统有意义l主要路径或者事件的基本路径,被认为是一个用主要路径或者事件的基本路径,被认为是一个用例的最普

18、通的路径例的最普通的路径l备选路径也是有效路径,但它并不经常被访问备选路径也是有效路径,但它并不经常被访问l描述路径必须满足原始事件的要求描述路径必须满足原始事件的要求2. 初始阶段初始阶段(续续) 通过三次迭代完成生命周期目标里程碑:通过三次迭代完成生命周期目标里程碑:迭代一:确定事件与参与者迭代一:确定事件与参与者迭代二:用例分析与初步建模迭代二:用例分析与初步建模迭代三:细化用例路径和准备系统初始构架迭代三:细化用例路径和准备系统初始构架l细化用例基本路径细化用例基本路径l准备系统初始架构准备系统初始架构l成本估算成本估算l增量计划增量计划l项目计划项目计划l评估迭代三评估迭代三迭代三:

19、细化基本路径和准备系统初始构架迭代三:细化基本路径和准备系统初始构架细化用例基本路径细化用例基本路径l在初始阶段还需从做什么的角度,通过勾画在初始阶段还需从做什么的角度,通过勾画完成功能的必要步骤,细化用例的路径,特完成功能的必要步骤,细化用例的路径,特别是基本路径。目的有二:别是基本路径。目的有二:更好地理解实现某个用例可能带来的复杂度。更好地理解实现某个用例可能带来的复杂度。为了估算增量的发布策略即相应的时间为了估算增量的发布策略即相应的时间/ /费用费用评估迭代三评估迭代三l细化的用例基本路径是否准确反映了用户的要求细化的用例基本路径是否准确反映了用户的要求l确定的初步构架是否可行确定的

20、初步构架是否可行l增量计划是否合理增量计划是否合理l项目进度计划,特别是细化阶段的实施计划是否项目进度计划,特别是细化阶段的实施计划是否可行可行2. 初始阶段初始阶段(续续) 通过三次迭代完成生命周期目标里程碑:通过三次迭代完成生命周期目标里程碑:迭代一:确定事件与参与者迭代一:确定事件与参与者迭代二:用例分析与初步建模迭代二:用例分析与初步建模迭代三:细化用例路径确定系统初始构架迭代三:细化用例路径确定系统初始构架=Synergy过程模型过程模型=初始阶段初始阶段=细化阶段细化阶段=构造阶段构造阶段=移交阶段移交阶段3. 细化阶段细化阶段l以实际所能达到的最快速度定义、确认构架以实际所能达到

21、的最快速度定义、确认构架并将其基线化并将其基线化l设置构想的基线设置构想的基线l为构造阶段的高可信度计划设定基线为构造阶段的高可信度计划设定基线l演示说明基线构架可以在适当的时间以合理演示说明基线构架可以在适当的时间以合理的费用支持这个构想的费用支持这个构想总体目标:总体目标:4. 细化阶段细化阶段(续)(续)l细化构想,建立对大多数关键用例的确定理解,细化构想,建立对大多数关键用例的确定理解,这些关键用例将驱动做出最终构架和计划决定这些关键用例将驱动做出最终构架和计划决定l细化过程、基础设施、开发环境,且过程、工具细化过程、基础设施、开发环境,且过程、工具和自动化支持各就各位和自动化支持各就

22、各位l细化构架并选择组件。细化构架并选择组件。评价潜在组件,很好地理解制作评价潜在组件,很好地理解制作/ /买进买进/ /重用决定,对重用决定,对构造阶段的成本和进度安排作出决定。构造阶段的成本和进度安排作出决定。基本活动:基本活动:3. 细化阶段细化阶段(续)(续)l构想是否稳定?构想是否稳定?l构架是否稳定?构架是否稳定?l可执行的演示是否表明主要的风险要素已被处理并被可可执行的演示是否表明主要的风险要素已被处理并被可靠地解决?靠地解决?l构造阶段的计划是否足够准确?是否得到一个可靠的基构造阶段的计划是否足够准确?是否得到一个可靠的基本估计的支持?本估计的支持?l如果在现有构架的语境中执行

23、当前计划来开发完整的系如果在现有构架的语境中执行当前计划来开发完整的系统,所有项目相关人员是否都赞成当前的构想?统,所有项目相关人员是否都赞成当前的构想?l实际的资源开支相对于计划的开支是否可接受?实际的资源开支相对于计划的开支是否可接受?主要评价标准:主要评价标准:协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/ /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始初始细化细化构造构造移交移交4. 细

24、化阶段细化阶段(续)(续)通过三次迭代完成生命周期构架里程碑:通过三次迭代完成生命周期构架里程碑:迭代一:建立静态模型迭代一:建立静态模型迭代二:开发用户界面原型迭代二:开发用户界面原型迭代三:建立动态模型和最终构架迭代三:建立动态模型和最终构架协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/ /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始初始细化细化构造构造移交移交迭代一:建立静态模型迭代一:建

25、立静态模型l细化路径细化路径l识别和分类业务规则识别和分类业务规则l挖掘类挖掘类l关系关系l创建类图创建类图l识别类的属性和操作识别类的属性和操作l对象图对象图l评估迭代一评估迭代一挖掘类挖掘类尽管开始时类图可能有些简单且缺乏实际的尽管开始时类图可能有些简单且缺乏实际的重要价值,但随着我们对应用程序静态和动态特重要价值,但随着我们对应用程序静态和动态特性的深入了解,它将成为一个中心图,所有其他性的深入了解,它将成为一个中心图,所有其他内容都从这个图中派生出来。即便是内容都从这个图中派生出来。即便是UMLUML组件和组件和部署图也是用来描述类是怎么封装的,并最终以部署图也是用来描述类是怎么封装的

26、,并最终以类的运行形式提交。类的运行形式提交。类的类型类的类型实体类,用于对长效且持久的信息建模实体类,用于对长效且持久的信息建模接口类,用于建立系统与其参与者之间接口类,用于建立系统与其参与者之间 交互的模型交互的模型将类分成三种类型可以使应用程序更能适应改变将类分成三种类型可以使应用程序更能适应改变控制类,代表协调、排序、事务处理以及对其他对象控制类,代表协调、排序、事务处理以及对其他对象 的控制,经常用于封装与某个具体用例有关的控制,经常用于封装与某个具体用例有关 的控制,它对系统中的动态特征建模的控制,它对系统中的动态特征建模挖掘类挖掘类(续)(续)客户客户订单订单库存库存处理订单界面

27、处理订单界面维护订单界面维护订单界面维护库存界面维护库存界面处理订单控制程序处理订单控制程序 维护订单控制程序维护订单控制程序 维护库存制程序维护库存制程序 LOcaleSheetMusicSuppliesGuitarADdressPaymentProduct0.*+1ShipmentCUstomer+0.*+1.*Invoice+0.*+1OrderHeaderOrderLine+0.*+1+0.*+1.*OrderSummaryOrder+0.*+1+1.*+1+1+1+1.*+1+1+1创建类图创建类图对象图对象图orderId : Integer = 123356orderStatus

28、 : String = Complete123356:Order orderDate : Date = 01/01/1999orderId : Integer = 123700orderStatus : String = Open123700:OrderorderDate : Date = 03/15/1999firstName : String = R.MichaellastName : String = Richardsonstatus : String = preferredR.Michael Richardson : Customer用用 例例路路 径径1.*1基本路径基本路径备选路径

29、备选路径异常处理异常处理顺序图顺序图协作图协作图交互图交互图类类1.*1.*1.*1.*1.*1.* 类最开始在用例中出现,最终作为对类最开始在用例中出现,最终作为对象在交互图中使用。象在交互图中使用。分析模型分析模型包括:包括:l用例模型用例模型l用例描述用例描述l类类l类图类图l对象图对象图评估迭代一评估迭代一l细化阶段的第一步就是要详细描述将在第一个增量开发细化阶段的第一步就是要详细描述将在第一个增量开发过程中涉及的用例的备选路径和异常处理过程中涉及的用例的备选路径和异常处理l业务规则的划分,尽管不是业务规则的划分,尽管不是UMLUML中的制品,但它是项目中的制品,但它是项目成功和可跟踪

30、性的关键。业务规则诉诸于能够强力地表成功和可跟踪性的关键。业务规则诉诸于能够强力地表现它们的用例来体现现它们的用例来体现l通过简单地从用例中抽取出名词和对各种类进行筛选,通过简单地从用例中抽取出名词和对各种类进行筛选,能够得到初步的候选类的清单能够得到初步的候选类的清单l类可以划分为三类构造型:实体类,控制类和边界类。类可以划分为三类构造型:实体类,控制类和边界类。实体类对于项目发起者来说意义重大。不过,三者对于实体类对于项目发起者来说意义重大。不过,三者对于在项目进行过程中把握应用的灵活性都至关重要。有时在项目进行过程中把握应用的灵活性都至关重要。有时实体类也叫领域类实体类也叫领域类 评估迭

31、代一评估迭代一l关联有五种形式:聚合,组合,连接,反身和限定。在前关联有五种形式:聚合,组合,连接,反身和限定。在前面的示例说明中,它们为用例提供了消息流的链接面的示例说明中,它们为用例提供了消息流的链接l一个类图包括三部分:类名、属性和操作。在项目的当前一个类图包括三部分:类名、属性和操作。在项目的当前阶段,有关属性和操作的细节不需要都完成,但在编码之阶段,有关属性和操作的细节不需要都完成,但在编码之前,这些工作都要做完前,这些工作都要做完lRLRL的分析模型既包含了所有用例关键路径的详细内容,又的分析模型既包含了所有用例关键路径的详细内容,又包含了类的识别过程、怎样建立关联以及多重性的细节

32、包含了类的识别过程、怎样建立关联以及多重性的细节 3. 细化阶段细化阶段(续)(续)通过三次迭代完成生命周期构架里程碑:通过三次迭代完成生命周期构架里程碑:迭代一:建立静态模型迭代一:建立静态模型迭代二:开发用户界面原型迭代二:开发用户界面原型迭代三:建立动态模型和最终构架迭代三:建立动态模型和最终构架协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/ /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始

33、初始细化细化构造构造移交移交迭代二:开发用户界面原型迭代二:开发用户界面原型l确定用户接口原型开发目标确定用户接口原型开发目标l收集用户接口需求收集用户接口需求l构造构造UIUI原型原型l评价评价UIUI原型原型l根据创建原型过程中发现的新信息,根据创建原型过程中发现的新信息,更新用例图和类图更新用例图和类图l评估迭代二评估迭代二用户接口原型开发的目标用户接口原型开发的目标l评估应用程序中主要路径上指定的用户接口需求评估应用程序中主要路径上指定的用户接口需求l向投资者提供可视化形式的反馈,表明在用例中向投资者提供可视化形式的反馈,表明在用例中找到的需求都已被理解,并且是可以实现的找到的需求都已

34、被理解,并且是可以实现的l开始项目用户接口的早期开发开始项目用户接口的早期开发l开始创建在构造阶段使用的屏幕模板开始创建在构造阶段使用的屏幕模板需要注意的问题需要注意的问题l用户界面高度的不确定性和改变的可能性用户界面高度的不确定性和改变的可能性是用户是用户界面设计为什么要采用实验和自适应方式,以及界面设计为什么要采用实验和自适应方式,以及为什么要把用户接口原型作为一个重要问题来考为什么要把用户接口原型作为一个重要问题来考虑的主要原因虑的主要原因l我们必须预先告诉项目投资者,原型后面的实现我们必须预先告诉项目投资者,原型后面的实现现在还是非常现在还是非常“模糊的模糊的”;大多数关于原型的逻;大

35、多数关于原型的逻辑和数据方面的内容还很粗糙。辑和数据方面的内容还很粗糙。它所能代表的只它所能代表的只是我们期待的流程和总体风格是我们期待的流程和总体风格 收集用户接口需求收集用户接口需求l 确定参与者和用例边界确定参与者和用例边界l 提取用户接口需求提取用户接口需求l 分析用例耦合分析用例耦合用户接口原型首先关注的参与者是用户接口原型首先关注的参与者是: : 在哪一点开始执行用例在哪一点开始执行用例用户接口并不一定都是图形化的!用户接口并不一定都是图形化的! 确定参与者和用例边界确定参与者和用例边界订单办事员订单办事员处理订单处理订单 确定参与者和用例边界确定参与者和用例边界要创建原型的主要路

36、径是用来处理订单入口,它是要创建原型的主要路径是用来处理订单入口,它是覆盖了应用程序中的大部分流程。覆盖了应用程序中的大部分流程。一个好的开始创建原型过程的方法,是通过问几个一个好的开始创建原型过程的方法,是通过问几个问题来发现参与者对用例的接口要求。不同的回答会对问题来发现参与者对用例的接口要求。不同的回答会对原型的最终效果产生不同的影响。原型的最终效果产生不同的影响。提取用户接口需求提取用户接口需求提取的用户接口需求将作为用例演示以及提取的用户接口需求将作为用例演示以及接下来创建实际屏幕内容时每一步的输入。接下来创建实际屏幕内容时每一步的输入。它们只描述概念和轮廓,非常它们只描述概念和轮廓

37、,非常“模糊模糊”。 分析用例耦合分析用例耦合用例耦合是从工作流的角度看,一个给定的用例是否用例耦合是从工作流的角度看,一个给定的用例是否和其他的用例有非常紧密的联系。它提供了某种程度上的和其他的用例有非常紧密的联系。它提供了某种程度上的耦合信息,对于用户接口流程非常有用。耦合信息,对于用户接口流程非常有用。使用一个使用一个用例矩阵用例矩阵并且描述它们之间的联系,可以估并且描述它们之间的联系,可以估算出用例之间的关联程度。算出用例之间的关联程度。l用例间这些事件的发生是随时的,它反映了在给定时间商务运作的本性用例间这些事件的发生是随时的,它反映了在给定时间商务运作的本性l用例间的关联不是用例间

38、的关联不是“包含包含”或者或者“扩展扩展”关系,它们只与工作流和导向有关系,它们只与工作流和导向有关关l用例耦合矩阵可帮助我们决定如何遍历用户接口,同时展示从一个关联用用例耦合矩阵可帮助我们决定如何遍历用户接口,同时展示从一个关联用例路径中访问另外的用例是多么的容易例路径中访问另外的用例是多么的容易构造构造UI原型原型 调查人员发现,一个应用程序的可用性:调查人员发现,一个应用程序的可用性:有有60%60%决定于用户接口和用户的心理模式决定于用户接口和用户的心理模式/ /潜在模式的符潜在模式的符合程度合程度但开发人员往往最先考虑对应用程序可用性作用最小的部分但开发人员往往最先考虑对应用程序可用

39、性作用最小的部分因此构造原型应先确定主要的窗口组和总体风格,而将美学上因此构造原型应先确定主要的窗口组和总体风格,而将美学上的讨论留到最后的讨论留到最后交互占到了交互占到了30%30%表示只占了表示只占了10%10%从原型中获取信息从原型中获取信息反馈信息至少应该覆盖下面内容:反馈信息至少应该覆盖下面内容:l 要执行的逻辑功能要执行的逻辑功能l 如何实现如何实现l 行为的结果是什么行为的结果是什么注意:这里只关心屏幕的显示,通过创建屏幕对话框表单来获取这些信息,可使用屏注意:这里只关心屏幕的显示,通过创建屏幕对话框表单来获取这些信息,可使用屏幕快照创建屏幕对话框。捕获任何特殊处理信息的同时捕获

40、任何特殊的编辑信息。幕快照创建屏幕对话框。捕获任何特殊处理信息的同时捕获任何特殊的编辑信息。评价评价UI原型原型项目开发者和用户一起考察原型,关于改进项目开发者和用户一起考察原型,关于改进用户接口以及功能的建议,通常在这个步骤中用户接口以及功能的建议,通常在这个步骤中形成。形成。评价评价UI原型原型(续)(续)l能够快速地把合理的建议结合到原型中是非能够快速地把合理的建议结合到原型中是非常重要的常重要的l必须注意区分用户接口项目和需求上的功能必须注意区分用户接口项目和需求上的功能范围的内容,并且保证这种改变要符合改变范围的内容,并且保证这种改变要符合改变控制的程序控制的程序l获取的所有内容最终

41、都必须在用例中反映出获取的所有内容最终都必须在用例中反映出来,否则应该遵循变更需求程序来,否则应该遵循变更需求程序评价评价UI原型原型(续)(续)原型开发过程中,通常有一系列的评价期。原型开发过程中,通常有一系列的评价期。每个评价期过后,原型都要从它的使用中获得经每个评价期过后,原型都要从它的使用中获得经验,进行修改,然后接受进一步的评价。这个过验,进行修改,然后接受进一步的评价。这个过程迭代进行,直到原型达到目标为止。迭代之间程迭代进行,直到原型达到目标为止。迭代之间所需要的时间极其重要,必须悉心安排。所需要的时间极其重要,必须悉心安排。我们从原型中获取了什么?我们从原型中获取了什么?l屏幕

42、结构图在一个较高的层次描述了逻辑流程屏幕结构图在一个较高的层次描述了逻辑流程l原型自身给出了应用程序的风格原型自身给出了应用程序的风格l屏幕对话框可以让用户在逻辑动作、如何执行它们以屏幕对话框可以让用户在逻辑动作、如何执行它们以及它们返回什么样的结果方面提供信息反馈及它们返回什么样的结果方面提供信息反馈下一步,把目前为止生成的下一步,把目前为止生成的UMLUML制品关联起来,当参与者以某种最初事件的形式和制品关联起来,当参与者以某种最初事件的形式和用例发生作用的时候,交互就开始了。如,客户下订单,这是通过一个用例来满足的用例发生作用的时候,交互就开始了。如,客户下订单,这是通过一个用例来满足的

43、(从用户角度看)。而且最终要通过某种满足该用例的人(从用户角度看)。而且最终要通过某种满足该用例的人/ /机交互方式来实现。作为增机交互方式来实现。作为增量重复项目开发的一部分,这种类型的反馈机制强化了最终生成品,并且增强了项目小量重复项目开发的一部分,这种类型的反馈机制强化了最终生成品,并且增强了项目小组成员工作下去的信心。组成员工作下去的信心。 评估迭代二评估迭代二l原型的基本目标是确认参与者和用例边界的关系,原型的基本目标是确认参与者和用例边界的关系,并且揭示功能需求和可用性需求。并且揭示功能需求和可用性需求。l为用例创建用户接口产品部分可以更好地定义参与为用例创建用户接口产品部分可以更

44、好地定义参与者和用例之间的交互细节。者和用例之间的交互细节。l项目小组经常浪费了宝贵的时间创建一个可视化的项目小组经常浪费了宝贵的时间创建一个可视化的产品作为原型的第一个步骤。屏幕结构图是一个技产品作为原型的第一个步骤。屏幕结构图是一个技术含量很低的用来描述应用程序流程的实现方法。术含量很低的用来描述应用程序流程的实现方法。l屏幕对话框是另一个低技术含量的尝试。它捕捉用屏幕对话框是另一个低技术含量的尝试。它捕捉用户对用户接口和期望结果的直觉。户对用户接口和期望结果的直觉。评估迭代二评估迭代二(续)(续)l对原型的改变应该尽快的进行,以加快相应用户的提议。对原型的改变应该尽快的进行,以加快相应用

45、户的提议。l任何由于改变原型导致的用例的变化,都必须按照变更管任何由于改变原型导致的用例的变化,都必须按照变更管理的程序进行。理的程序进行。 l通过迭代增量式地开发应用程序,我们可以控制范围溢出通过迭代增量式地开发应用程序,我们可以控制范围溢出的同时,加入相应的改变。并将改变不断地合并到用例中,的同时,加入相应的改变。并将改变不断地合并到用例中,以保证项目以及接下来对项目范围的改变,不会影响项目以保证项目以及接下来对项目范围的改变,不会影响项目的可跟踪性。的可跟踪性。 3. 细化阶段细化阶段(续)(续)通过四次迭代完成生命周期构架里程碑:通过四次迭代完成生命周期构架里程碑:迭代一:建立静态模型

46、迭代一:建立静态模型迭代二:开发用户界面原型迭代二:开发用户界面原型迭代三:建立动态模型迭代三:建立动态模型迭代四:确定系统最终构架迭代四:确定系统最终构架协同过程模型协同过程模型发布发布周期周期项目项目范围范围初始初始构架构架初初 步步模模 型型静态静态模型模型UIUI原型原型动态动态模型模型最终最终构架构架数据库设数据库设计计/ /创建创建组件设组件设计计/ /创建创建网络设网络设计计/ /创建创建发布发布/ /培训培训用用 例例分分 析析初始初始细化细化构造构造移交移交在项目当前阶段,动态建模的作用在项目当前阶段,动态建模的作用 l首次将类和用例路径结合在一起来演示为完成首次将类和用例路

47、径结合在一起来演示为完成它们所必需的通信建模的能力它们所必需的通信建模的能力l将在动态建模过程中了解到的信息通过类图中将在动态建模过程中了解到的信息通过类图中的操作、属性和关联表达出来的操作、属性和关联表达出来l结合在用例和类图中反映出来的信息,通过创结合在用例和类图中反映出来的信息,通过创建使用矩阵为应用程序的组装和加载特性建模建使用矩阵为应用程序的组装和加载特性建模动态建模的依据动态建模的依据 l在确定项目范围时标识出来的在确定项目范围时标识出来的事件事件,为系统必须,为系统必须响应的内部和外部激励提供了一个清晰的画面响应的内部和外部激励提供了一个清晰的画面 l在用例模板中标识出来的在用例

48、模板中标识出来的路径路径,动态描述了实现,动态描述了实现用例目标所必需的逻辑步骤用例目标所必需的逻辑步骤 l业务规则业务规则捕获了应用程序中的元素必须用到的参捕获了应用程序中的元素必须用到的参数和语义数和语义 Use Case PathwaysClass1 Class 2 Class3 Class 4 Object1Object2Object3Object4迭代三:建立动态模型迭代三:建立动态模型lUMLUML四种动态模型四种动态模型l应用矩阵应用矩阵l评估迭代三评估迭代三l顺序图和基本路径顺序图和基本路径l备选路径的顺序图备选路径的顺序图l将获取知识反映到类图中将获取知识反映到类图中l浏览顺

49、序图,验证应用程序的正确性和浏览顺序图,验证应用程序的正确性和完整性完整性UMLUML四种动态模型四种动态模型-顺序图顺序图处理订单用例描述处理订单用例描述 处理订单用例基本路径描述处理订单用例基本路径描述 RlRl系统用例图系统用例图 顺序图顺序图(续)(续)LOcaleSheetMusicSuppliesGuitarADdressPaymentProduct0.*+1ShipmentCUstomer+0.*+1.*Invoice+0.*+1OrderHeaderOrderLine+0.*+1+0.*+1.*OrderSummaryOrder+0.*+1+1.*+1+1+1+1.*+1+1+

50、1类类 图图: O r d e r : O r d e r ClerkClerk:Customer:Customer:Order:Order:Invoice:Invoice: :OrderSummaryOrderSummary: :OrderLinOrderLine e: :OrderHeaderOrderHeader:Product:Product:Payment:Payment1:validate()1:validate()2:create()2:create()5:addProduct()5:addProduct()9:addToTotal()9:addToTotal()10:calcT

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公、行业 > 各类PPT课件(模板)
版权提示 | 免责声明

1,本文(第五章协同过程模型实例课件.ppt)为本站会员(三亚风情)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!


侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|