《软件工程之用例模型总结》由会员分享，可在线阅读，更多相关《软件工程之用例模型总结（3页珍藏版）》请在金锄头文库上搜索。
1、软件工程之用例模型总结一、用例模型 1.用例概念用例：使用系统时发现的功能 性需求，不应过于复杂，简单的来说就是你希望系统能够有 什么功能，能够增加系统的价值。 用例模型包括用例描述和用例图，我们主要把中心放在用例 描述上。 用例模型包含参与者和场景，场景包括成功场景和失败场景。 因此用例模型中有多个场景；每个场景是一个用例。 用例必须注重为用户提供可观察的返回值，就是系统触发了 一个用例之后能够给用户带来什么。 一般用例都是黑盒用例，即不考虑如何实现。2.Use CaseDescription 每个用例都有一个描述。怎样确定用例？(1) 确定一个功能；(2) 写一个用例； (1)主要参与者：
2、调用系统服务完成目标的人。 (2)次要参与者：为系统提供服务的人。(3) 写出每个项目相关人员的理想需求，从中分析功能。(4) PreCondition: 执行到这个用例之前必须为真的情况， 比如 必须已成功登录或通过验证。(5) PostCondition: 成功执行完此用例后的情况，比如登录用例的后置条件是成功登录(不考虑其他失败情况) 。(6) main flow ：将最理想的步骤列出。一般 main flow 步骤如下：(1) 参与者发生动作。(2) 系统验证。(3)返回结果。(7) extension flow ：扩展步骤 ,通常格式为： (1) 系统检测到 * 有问题 ;在 mai
3、n flow 中的第一步扩展，则用 1a,1b,1c; 3.如何确保正确的用例EBP 原则 :一般用例都需要遵守这个规则， 即确定主要用例。 用例中的主要用例是一些重复做但是有意义的事，比如收银 员收钱，重复多次是有意义的，因为钱收得多了；但是像登 录系统，这种做 100 次却没有意义的用例，不能被称为主要 用例；(1)EBP (基本业务过程)原则的用例写入；如果要写编辑 A，删除A，添加A,可以合并成“管理A ;4.用例图 每个用例描述都是一个用例，左边是主要参与者(希望系统 为他提供服务)和次要参与者(提供给系统服务的人) ； 在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据
4、库的； 关系：(1)泛化关系，在参与者和用例中都能泛化。 (2)包含关系：表示A包含B ;比如A是管理数据，B可以是添加数据、 删除数据等；(3) 扩展关系：表示 D 被 C 扩展， D 包含新的功能，比如 D 是查询数据， C 可以是打印数据，即用户可以查询但不打印 数据，打印数据只是一个扩展功能。用例描述模板html view plain copy <p> 用例模型根据系统边界的确 定，描述了系统的输入和输出，确定了系统外部的参与者， 通过用例描述了系统的主要功能，描述了外部参与者与系统 的交互，将系统作为一个黑盒，从用户角度描绘出系统需要 提供的功能 ; </p> Use Case ：用例名称 Actor ： 参与者 Precondition ：前置条件，即执行这个用例一定 要满足的条件 Postcondition ：后置条件， 如果成功执行， 则一定会变成的状态 Main flow ：1. 用户开始一次会话2.用户输入信息3.系统验证并反馈4. 用户重复 2 ， 3 步 Extensions ：3a ：数据无效1.系统提示出错
