RationalRose用例图及其应用资料.pptVIP

分组： 在一些用例中，用例的数目可能非常多，这个就需要组织这些用例。这种情况在一个系统包含很多个子系统时就会出现。 还可以把相关的用例放在一个包中 * 在建模参与者过程中，注意： 1、参与者对于系统而言总是外部的，因此它们在你的控制之外。 2、参与者直接同系统交互，这可以帮助定义系统边界 3、参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。 4、一个人或者事物在与系统发生交互的时候，可以同时或者不同时扮演多个角色。 5、每一个参与者需要有一个具有业务一样的名字。 6、每个参与者必须有简短的描述，从业务角度描述参与者是什么。 7、像类一样，参与者可以具有分栏，表示参与者属性和他可以接受的事件。 * 识别用例 识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。使用这种策略的过程中可能会找出一个新的参与者，这对完善整个系统建模很有帮助。 在识别用例的过程中，通过以下的几个问题可以帮助识别用例： （1）特定参与者希望系统提供什么功能？ （2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发? （3）当系统改变状态时，通知参与者吗？ （4）存在影响系统的外部事件吗？ （5）是哪个参与者通知系统这些事件？ * 用例与事件流 用例分析是处于系统的需求分析阶段，这个阶段应该尽量的避免去考虑系统实现的细节问题。也就是说，用例描述的是一个系统做什么，而不是怎么做。 可以通过一个清晰的，易被用户理解的事件流来说明一个用例的行为。这个事件流包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。 * 四、用例图建模技术 对语境建模 对系统语境建模可以参考如下方法。 （1）得出需要从系统中得到帮助的组；执行系统功能必须的组；与外界进行交互的组；执某些辅助功能的组，并由此来识别系统外部的参与者。 （2）将类似的参与者组织成泛化的关系中。 （3）如需加深理解，可以为参与者提供构造型。 （4）说明用例图中参与者和用例间的通信路径。 * 对需求建模 软件需求就是根据用户对产品的功能的期望，提出产品外部功能的描述。需求分析师的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。 对系统功能建模可以参考如下方法： （1）识别系统外部的参与者，从而建立系统的语境。 （2）考虑每一个参与者期望的行为或需要系统提供的行为。 （3）把公共行为命名为用例。 （4）确定供其他用例使用的用例和扩展其他用例的用例。 （5）在用例图中对这些用例、参与者和它们间的关系建模。 （6）用描述非功能需求的注释修饰用例图。 * * 3.1 参与者规范 Rose在实现中对参与者和类使用相同的规范窗口，包括如下一些标签： General Detail Operations Attributes Relations Components Nested Files 3 参与者规范及应用 * 3 参与者规范及应用 3.1 参与者规范 General标签 Name Stereotype Documentation * 3 参与者规范及应用 3.1 参与者规范 Detail标签 Multiplicity （参与者基数） Abstract（抽象参与者） 基数 含义 0..0 0 0..1 0或者1 0..n 0或者多 1..1 1 1..n 1或者多 n 许多 * 3 参与者规范及应用 3.1 参与者规范 Relations标签 列出了参与者参与的所有关系。包括参与者与用例、参与者与其他参与者的一切关系 * 3.2 参与者的操作 1）增加参与者 2）删除参与者 3 参与者规范及应用 * 4.1 用例规范 General标签 Diagrams标签 Relations标签 Files标签 4 用例规范及应用 * 4 用例规范及应用 4.1 用例规范 General标签 Name Package Stereotype Rank Abstract Documentation * 4.1 用例规范 Diagrams标签 用例所拥有的模型图的信息，其中第一列（没有标题）显示模型图的图标，第二列（Title）显示图的名称 4 用例规范及应用 * 4 用例规范及应用 4.1 用例规范 Relations标签 用例与其他用例或参与者之间存在的所有关联关系 * 4 用例规范及应用 4.1 用例规范 Files标签 * 4.2 用例的操作 增加用例 将新的用例加入用例图 将现有的用例加入用例图 删除用例 仅仅从一个用例图中删除一个用例 从整个模型中删除用例 添加文件和链接URL 4