标签：商品   下单   输入   简单介绍   循环   性能   网站   计时   类型   

我的工程实践选题是开发一个电商平台网站，在这里我简单介绍一下用例建模的流程并结合我的工程实践来加以说明。

用例建模

需求建模

需求分析

确定功能性需求和非功能性需求

需求规约

形成需求规约文档使需求分析师和客户达成共识

用例

参与者

与系统交互的外部用户

主要和次要参与者

• 主要参与者：启动用例，系统必须响应主要参与者
• 次要参与者：除主要参与者

不同类型参与者

• 主要参与者：启动用例，系统必须响应主要参与者
• 次要参与者：除主要参与者
• 不同类型参与者
• 人类参与者

• 外部系统参与者

• 输入/输出设备参与者
• 计时器参与者

• 用例模型中文档化的用例

• 用例名称: 名称
  概述: 用例描述
  依赖: 是否依赖其他用例，即是否包含或扩展另一个用例
  参与者: 主要和次要参与者
  前置条件: 从用例角度开始时必须要的条件
  主序列描述: 参与者和系统之间的交互序列，描述形式是参与者的输入和系统的响应
  可替换序列描述: 主序列的可替换分支的叙述性描述，例如性能和安全性需求
  后置条件: 用例终点处为真的条件。如客户资金已取出
  未解决问题: 尚未解决问题

　　示例

　　　　用例名称: 下单请求
　　　　概述: 客户下单从在线购物系统中购买商品，需要验证信用卡可用
　　　　参与者: 客户
　　　　前置条件: 客户已选择一个或多个商品
　　　　主序列描述:
  　　　　1.客户提出订单请求和客户账号ID来为购买付款
  　　　　2.系统检索账户和信用卡信息
  　　　　3.系统检查信用卡并创建授权号码
  　　　　4.系统创建发货单
  　　　　5.系统确认批准购买并向客户显示订单信息
　　　　可替换序列描述:
  　　　　第2步：如果客户没有账号，则系统为其创建一个账号
  　　　　第3步：如果信用卡被拒绝，则提示输入其他信用卡或取消订单
　　　　后置条件: 系统为客户创建了发货单

用例关系

包含关系

• 包含用例：一个共同交互序列可以从多个原始的用例中抽取出来，形成一个新的用例即包含用例，通常不能单独执行，需要作为一个具体用例的一部分执行
• 基用例：被抽取走公共用例部分后的就用例被称为基用例或者具体用例

包含关系也可以用来组织一个冗长的用例。基用例提供参与者和系统之间高层次的交互序列

扩展关系

• 扩展用例：用来进行扩展的用例
• 基用例：被扩展的用例
• 扩展点：用来规定用例中能被增加扩展的精确位置
• 扩展条件：符合条件才进入扩展用例

用例包

将相关用例分组到一起

活动图

描述控制流和活动中序列的UML图，用来表示用例的执行顺序，包括所有主序列和可替换序列

• 活动序列
• 决策节点
• 循环
• 并发活动

用例建模Use Case Modeling

标签：商品   下单   输入   简单介绍   循环   性能   网站   计时   类型   

原文地址：https://www.cnblogs.com/ttt-kkk/p/11784869.html