RUP开发阶段及里程碑分析介绍教学.pptVIP

RUP概论@中国UML教育与资格认证中心 就是说在该生命周期内，完成的产品要到达哪些要求。 以ATM机为例 P36 设计模型中部分实现“取款”用例的类图，每个设计类参与并充当用例实现中的角色。 设计模型中部分实现“取款”用例的顺序图 我们将这个简单的ATM例子划分为三个子系统和一个服务子系统(“事务管理”子系统内部灰色的部分) 所有提供用户界面的类归入一个子系统， 所有与账户处理有关的类归入一个子系统， 用例的专用(特定)类归入一个子系统。 圆圈代表接口，从类到接口的实线表示由该类提供此接口，从类到接口的虚线表示该类使用此接口。 “转帐”接口定义了在账户之间转帐，从账户中取款以及向账户中存款的操作。 “取款”接口定义了从某个账户中请求取款的操作。 “分配”接口定义了由其他子系统(如“事务管理”子系统)使用的将货币分发给银行储户的操作。 设计模型中描述了如何用具体的制品来实现设计模型中的类。 “dispenser.c”文件构件包含3个类(“分配输送器”，“分配传感器”和“点钞机”)的源代码(因此是这三个类的具体实现)。 该文件通过编译并与”client.c”文件构件连接成为可执行的”client.exe”构件。 需求：确定系统范围，降低风险。 P265-266 初始阶段最缺少的就是项目相关信息。可以通过一些步骤来开始信息收集的工作： 1)将开发人员在项目开始之前收集的信息集中起来 2)将信息组织起来，并整理分类 3)召集知道如何使用这些信息的人员 4)研究需要进一步考察的项目内容 P267 P268 从图中可以看出，初始阶段的大部分工作流都是在需求工作流中完成的，一部分工作在分析和设计工作流中进行，在最后的实现和测试工作流中只有少量的工作。 矩形框的相应大小仅仅表示那些工作流在初始阶段需要更多注意，那些工作流则可较少关心。 具体的活动我们已经在第三部分中给出了详细的描述。我们只是结合不同阶段，讲解活动执行时的细微差别和侧重点。 P270 其中我们详细讲解在“用例捕获功能性需求”中几个重要的活动。 其中，需求一般需求工作流阶段的“构造用户界面原型”和“构造用例模型”，不是初始阶段需求工作流的重点。 P273 分析工作流中生成初始的分析模型(5%)，并用这个分析模型来精确定义用例和帮助生成候选构架。 分析工作流中的主要活动 P275 P274, 277 P276 评估准则是根据阶段目标(主要里程碑)来制定的。 初始阶段的结束也意味着项目通过了第一个主要里程碑，它标志着三项成就： 已经阐明了一个初始的构架(即候选构架)，也意味着我们知道如何为目标系统建立一个构架，该构架包含了系统中新颖的以及困难的部分。 已经识别出了最严重的风险(既关键风险)，并且通过对这些风险的研究，对建立系统的可行性充满信心。 已经建立了有足够描述信息的业务案例，取得了项目相关人员，尤其是投资方的同意。 就是说在该生命周期内，完成的产品要到达哪些要求。 P31 自动取款机ATM系统的用例模型， 参与者：“银行储户” 三个用例：1.从ATM机中取款 2.用ATM在不同账户间转帐 3.用ATM机存款 P27 分析模型是概念模型，贴近于被分析的领域。分析模型将用例模型中的用例精化为概念性的类元(与将要实现的设计类相对应)间的协作，以便更准确的理解这些用例。 边界类 一般负责建立系统与其参与者(即用户和外部系统)间的交互。 控制类 用于表示协调、排序、事务处理以及其他对象的控制。 实体类 一般用于建立长效且持久的信息模型。 参与“取款”用例实现的分析类，“分配”和“出纳接口”是边界类，“取款”是控制类，“账户”是实体类。 图中显示了每个用例(左图)如何实现为分析类结构(右图)。例如，“出纳接口”类、“取款”类、“账户”类和“分配”类全部参与了“取款”用例的实现。“出纳接口”和“账户”类参与并在全部三个用例中充当角色。其他的类只参与了一个用例的实现，即他们只充当一个角色。 分析模型中“取款”用例实现的协作图 设计模型中的设计类跟踪到分析模型中的分析类 P279 From ZhangXun 1.1 1.2主要是分析和设计模型 1.3开发一些关键构件的可执行原型，以消除构造阶段的风险。 1.4为项目计划中加入更详细的描述 P277 识别用例：仅仅画出用例模型图，包括参与者和用例。 描述用例：文字或形式化描述用例如何开始、结束以及如何与参与者进行交互，和用例的所有备选路径等内容。 分析用例：用分析模型来描述用例实现，小部分与关键风险相关的用例甚至被设计、实现和测试。 P277 表中的数据只是一个粗略的指示。最右边一列指示在各阶段末期的基线中有多少用例。 P 标书：对项目开发时间、进度、成本、质量的详细说明，用来竞标。 P281 从图中可