软件工程个人学习笔记（第三章）

最新推荐文章于 2023-08-01 20:10:33 发布

H'xinHxin

最新推荐文章于 2023-08-01 20:10:33 发布

阅读量261

点赞数 1

文章标签：软件工程学习

本文链接：https://blog.csdn.net/qq_53676492/article/details/127205186

版权

软件需求管理——用例建模

1、用例建模概念

1.1用例在需求管理过程中的作用

描述系统的功能性需求

关联干系人需要以及软件需求
确认于系统交互的人或对象（参与者）
定义系统的边界
捕捉和传达系统的理想行为（用例）

1.2用例模型的表示

文本描述

用例图

1.3 用例图的主要元素

参与者：

与系统交互的人或外部系统
与系统交互的硬件组件
关注的重点是所承担的“角色”
参与者的名要明确定义其角色

用例：

定义一个参与者要用到的系统功能
通过此刻为参与者提供有价值且可观测的结果
描述系统为实现参与者价值所开展的行为序列
对参与者与系统之间的交互活动进行建模
从特定的用户角度出发，是完整的，实现特定用户的事件流

关联：

用例图中用例与参与者之间的交互关系
用一条直线表示交互——关联
有箭头的关联指出是谁发起的交互
没有箭头则表明双方都可以放弃交互

场景：

场景是用例的实例

2、用例建模过程

2.1 构建用例模型的步骤

找到所有的参与者和用例

识别出参与者并做简单的描述
识别出用例并做简单的介绍

编写用例

给用例事件流程划分重要等级
按照重要程度排序详细描述事件流程

2.2 参与者

寻找参与者

谁/什么使用系统？
谁/什么从系统中获取信息？
谁/什么向系统提供信息
公司的哪个部门会使用系统
谁/什么负责系统的维护
还有哪些其他的系统会使用系统

识别参与者——是谁与系统进行交互

参与者建模的检查项

是否找全所有的参与者？是否对系统环境中的所有的角色进行了描述和建模？
每个参与者是否至少与一个用例发生了交互？
是否可以为每一个角色找到至少两个实例？
不同参与者与系统的交互是否一致扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一个角色

2.3 用例

寻找用例

描述系统为参与者提供的服务/参与者如何与系统交互
基本策略：把自己当作actor，与设想中的系统进行交互。

每个参与者的目标是什么？
为什么参与者要使用这个系统？
参与者是否需要对系统中数据进行创建，存储，更改，删除或者读取的操作？为什么？
参与者是否需要将外部事件或发生的改变告知系统？
参与者是否需要找到系统内部发生的事件或改变？
系统是否能够应对业务中所有的正确行为与操作？

用例的命名

表面参与者的目标或者作用
使用主动语态：用动词起始
设计一系列操作流程（ to-do list）

用例建模过程中的检查项

用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作
应该识别出所有的用例，用来表达所有的需求
系统的任何一个特性都可以找到对应的用例
用例模型并不包括多余的行为；所有的用例可以追溯到系统的功能性需求作为验证
去掉所有的CRUD类的用例

2.4用例建模的过程

用例图——>用例提纲——>用例详细规约

2.5 总结：Use Case模型的建立步骤

找出系统外部的参与者和外部系统，确定系统的边界和范围；
确定每一个参与者所期望的系统行为；
把这些系统行为命名为Use Case；
使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；
编制每一个Use Case的脚本；
绘制Use Case图；
区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理；
细化Use Case图，解决Use Case间的重复与冲突问题。