UML-usecase(new)概要.ppt

-*- 用例阐述 Use Case：购买商品 ID UC1 参与者 Cashier，Customer 交叉引用 … 描述 顾客带着所要购买的商品来到付款处，出纳员记录下商品信息并接受付款，付款完成后，顾客带着所购买的商品离开 前置条件 客户购买了若干件商品 基本事件流： 用例起始于顾客带着所要购买的商品到达一个销售点终端 出纳员录入每个商品的商品号，如果出现多个商品，则还需要录入数量 系统确定商品信息输入到正在运行的POST系统，显示当前商品信息和价格 输入完商品信息后，出纳员向POST发出提示，提示商品信息录入完毕 计算和显示顾客的商品价格总额 出纳员将商品价值总额报告给顾客 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据 出纳员收管好现金并取出要找还给顾客的现金，并支付给顾客打印付款收据 系统记录本次交易 顾客带着所购的商品离开 备选事件流： 第2步：如果输入的商品号码无效，系统显示出错信息 第7步：顾客没有足够的现金，则取消本次交易 后置条件 示例2：用例建模 1. 问题描述 当需求分析人员对用户和客户进行访谈后，就要记录下用户和客户对业务系统的描述。开发人员必须把客户对业务系统的陈述转化为完整的，清晰的、可用于开发系统的描述，这种描述业务系统的格式，必须是客户能理解的、认可的标准格式。当然，“完整”和“清晰”实际上是做不到的。第一次是不可能非常接近这些目标的。但是，最终应有一个文档描述了系统应完成的所有工作（和系统不应完成的工作），而且没有误解。 例如，下面就是汽车租赁系统的业务陈述(Nowhere Cars任务陈述)： * 示例2：用例建模 商店将汽车的跟踪自动化了——使用条形码、柜台终端和激光阅读器，这有许多优点：租凭助手的效率提高了20%，汽车很少失踪，客户群很快变大（根据市场调查，其部分原因至少是专业化和效率的显著提高）。 管理层认为，Internet会提供进一步提高效率、降低成本的机会。例如，现在不是打印可用汽车的目录，而可以让每个Internet冲浪人员在线浏览这些目录。对于有特权的客户，可以提供额外的服务，例如通过鼠标点击进行预约。这个领域的目标是每个商店的运营成本降低15%。 在两年内，使用电子商务的所有功能，通过Web浏览器提供所有的服务，在客户中完成汽车的交付和收回，以达到虚拟租凭公司的最终目标，将未预约业务的运营成本降到最低。 * 示例2：用例建模 上面有三个段落的任务陈述包含了许多信息：公司的自动化历史；客户的满意度；在线目录和预约；有特权和无特权的客户；节约成本的历史和目标；公司的最终目标（“虚拟租凭公司”）。当然，管理层的一些想法实现起来还有很长的路要走（客户适应虚拟租凭商店的时间可能会超过两年）。 上述任务陈述是下面案例分析的基础。虚拟公司的新系统称为Coot，客户可使用的Internet功能集合称为iCoot. * 示例2：用例建模 开发Nowhere Cars系统的优点是：在延长的期限内爱好者出租专用汽车。由于不可能出租所有型号的汽车，客户在要租汽车时，必须找到一家租凭货店。汽车的租凭方式是先到先得到服务，客户可以在当前可用的汽车中选择。另外，如果客户要租用的某型号汽车目前没有，还可以预约，当有匹配的型号汽车时，助手就会与客户直接签约；客户必须在两天内取车（或交抵押金，先于其他客户取车）。会员必须注册，才能电话预约。 * 示例2：用例建模 2. 定义术语表 每个业务领域都具有它本身独一无二的词汇，需求分析的目的就是理解和定义这些词汇。词汇应该被项目相关人所理解。术语表必须解决同音异义和同义异音问题。 一般来说，我们从问题描述中提取术语表。 下面是汽车租赁系统的术语表： Car（业务对象） 由商店保存的、用于出租的CarModel的实例 CarModel（业务对象） 目录中的一个模型，可用于预约 Customer（业务参与者，业务对象） 为获得一个标准服务而付费的人 Member（业务对象） 其身份和信用状况已得到验证的顾客，因此，可以访问特定的服务（例如电话预约或通过Internet预约） * 示例2：用例建模 3. 标识参与者 首先，需要标识业务参与者。参与者是在业务中扮演某个角色的人、部门或者独立的软件系统。一般来说，参与者使用系统或给系统提供服务。 与现实生活一样，参与者可以在不同的时刻，扮演不同的业务角色。例如，小刘在Nowhere Cars商店上班时，他是一个助手；如果他在回家之前要租用一辆汽车，就成为一个顾客。 * 示例2：用例建模 我们一般是从业务陈述中获取参与者。 下面是汽车租赁系