OO分析-用况图解析.ppt

3．2 参与者 简言之，参与者是在系统之外的与系统进行交互的任何事物。 3．2．1 概念与表示法 一个参与者定义了用况的使用者在与这些用况交互时所扮演的一组功能高内聚的角色。 参与者是与系统交互的任何事务。 3．4 用况图 用况图展示了用况之间以及同用况与参与者之间是怎样相互联系的。用况图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。 用况图呈现了一些参与者和一些用况，以及它们之间的关系。 在图形上，用况图是一幅由一组参与者、一组用况以及这些元素之间的关系组成的图。这些关系是参与者和用况之间的关联、参与者之间的泛化，以及用况之间的泛化、扩展和包含。 可以选择把一些用况用一个矩形围起来，用来表示系统、子系统或“类”的边界。 用况图可以包含注解和约束。 use case a use case b use case c 用况图 参与者 s 参与者 g 被包含的use case 该用况应优先开发 运输公司 职员 订购货物 获取订单状态 获取目录 取消订单 客户 退货 客户代表 运送货物 发送货物 计算运费 供货商 ？ 对系统的需求建模，要遵循如下策略： 通过识别系统周围的参与者来建立系统的语境。 对于每个参与者，考虑它期望的或需要系统提供的行为。 把上述的行为命名为用况。 分解公共行为，放入新的用况中，以供其他的用况使用；分解异常行为，放入新的用况中，以延伸较为主要的控制流。 在用况图中对这些用况、参与者以及它们的关系进行建模。 用陈述非功能需求的注解或约束来修饰这些用况，可能还要把其中的一些附加到整个系统。 注：有人把不与系统进行内外交互的情况也作为一个用况，如在一个信用卡验证的系统中，把系统内的对信用卡的欺诈检查也作为一个用况*。 3.5 审查 参与者 ■????????? 确定系统环境中的所有角色，并都归入了相应的参与者。 ■????????? 每个参与者都至少和一个用况关联； ■?????? 若一个参与者是另一个参与者的一部分，或扮演了类似的角色，考虑在它们之间使用泛化关系； 用况 ■?????? 每个用况都至少和一个参与者相关； ■???????? 若两个用况有相同或相似的序列，可能需要合并它们，或抽取出一个新用况，在它们之间使用包含、扩展或泛化关系。 ■???????? 若用况过于复杂，为了易于理解，考虑进行分解；若一个用况中有完全不同的事件流，最好把它分解成不同的用况 例题 很多软件系统在一开始都需要登录，若用户登录成功，则可进入系统。 如下以一个研究生学籍管理系统为例，描述四种登录方法。 为了简化起见，假设此处仅描述登录、选课和查看学分这3项功能。 方案一： 由于选课和查看学分都需要登录，故专门设立一个“登录”用况。若登录成功，则可以进行选课，也可以进行查看学分。 登录 查看学分 选课 《include》 《include》 研究生 该方法的缺点是，必须要了解系统的所有其它模块，才能描述清楚“登录”用况。向系统增加新用况时，也要修改登录用况。此外，从维护的角度看，有时会忘记对“登录”用况进行修改。 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课 系统执行用况“选课”； 若通过，若该生选择查看学分 系统执行用况“查看学分”； ? 如下为对用况“登录”的描述： 方案二： 让所有的相关用况都包含登录用况。 登录 查看学分 选课 《include》 《include》 研究生 如下为对用况“选课”的描述： 研究生启动系统，调用用况“登录” 若通过，系统执行用况“选课”的其余部分； 这个方法中的“登录”用况仅描述有关登录的信息，研究生执行系统的每项功能都要先登录。其缺点为，对研究生要进行多次验证。 研究生启动系统，调用用况“登录” 若通过，系统执行用况“查看学分”的其余部分； 如下为对用况“查看学分”的描述： 方案三： 使用扩展，设计系统登录。 登录 扩展点： 选课：选择选课 查看学分：选择查看学分 查看学分 选课 《extend》 《extend》 研究生 如下为对用况“登录”的描述 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课