UML从需求到实现—用例

Posted 2021-04-17 新梦想软件测试

关于用例图的概念相信不用我去说了 .能看到这篇文章的都是知道用例图概念的人。
　　

UML中最重要的是什么图呢 ?毫无疑问应该是用例图 ，用例是后期时序图和实际开发的重要依据。
　　

说明一下用例图是怎么产生的，了解他的产生对我们了解它本身有很大帮助，首先用例产生在需求分析阶段 ，这这个阶段系统分析人员对用户对系统要求的理解 ，也就是用户的愿望的描述，有时候我们习惯把用例说成系统的功能。
　　

用例一定是系统的功能，但是功能不一定是系统的用例。比如系统要求我在断电的时候要把数据保存起来。这个能写在用例里面吗?当然不能。这只不过是系统的一个限制，不能算是一个完整的愿望。
　　

接着说明一下用例的特点，然后根据特点来说明用例的建立过程。

用例特点:
一:用例是相对独立完整的，一个用例不需要其他用例来完成和它进行交互。也就是说，我在实现这个用例的过程中不能出现做完用例1，然后才能做用例2。

比如
我们去买菜

显然第一个不是一个用例，给钱只是买菜的一部分，不能单独成为一个用例。

二:用例的执行结果对于参与者来说是可见的，有意义的。这句话的意思就是说：一个用例必须有一个确定的结果，这个结果是有意思的，比如到银行取钱。

显然第一个不是一个用例，因为输入密码以后到底是什么结果，密码正确？还是错误，这些结果都是未知的。一个结果未知的过程，不能算做一个用例。

三:一个用例必须是由一个参与者发起，不存在没有角色的用例，用例也不该自动启动。
这个也是我们经常遇到的一个问题。
解决这个问题的时候，我们要首先确定用例边界，我们在那个范围之外去寻找用例，不同的范围会产生不同的用例。
　　

比如我们要以系统为边界去确定用例，那么角色就应该是系统之外的东西，不应该是系统。
　　

比如:

显然ATM不是一个角色，我们设计的用例也不应该包括ATM出钱这个用例，ATM是我们系统的一个部分，他最终出现在部署图上，就像是我们的一台PC 一样，不在边界之外。
　　

四:用例一定是动宾短语
比如:喝水 取钱 买菜 做饭等
因为这样才能构成一个完整的事件，角色是主语，动宾短语是动作和动作的受体。这样主、谓、宾都有了，才是一个完整的事件。

　　

五:一个用例是一个需求单元，分析单元，设计单元，开发单元，测试单元。
设计完一个用例，我们接下来的工作都要以单个用例为主线去开发、测试。这样就印证了开篇的那句话，用例对于开发来说是相当重要的。

那么用例是如何确定的呢?
一:确定系统的边界；
二:确定业务主角，这个是最重要的，也是常常困扰我们的地方，业务主角是与系统交互的人和事物。让我们常常困惑的是有些业务人员明明参加了业务，但是却是被动参加的，不好说明他有什么目的，又确实是在系统中做了事情。我们把这样的业务人员叫做业务工人 ，不是业务主角。
　　

区别的办法就是回答下面三个问题：
1:他是主动向系统发出请求的吗?
2:他是完整的业务目标吗?
3:系统为他服务吗?

三:参与者到角色的过度
参与者是一个具体的概念，角色是一个抽象的概念。从众多的参与者当中，抽象出相同的一部分.就形成一个角色。
　　

比如:教授，副教授都可以讲课 ，把它们抽象出来，做出老师讲课。

最后检查是否找到了所有的参与者
通过下面这些问题来做出测试：
1:是否对系统中的所有角色都进行了建模和说明
2:每个参与者是否至少涉及到一个用例
3:你是否列出至少两名可以作为特定参与者的人员
4:是否有两个参与者担任与用力相关的角色
5:参与者是否有直观的描述性名称

最后将参与者和他们的愿望结合起来，就形成了用例图，记得最后形成的一定是一个完整的事情，由参与者做主语，用例做谓语和宾语。
　　

PS:用例图只是一些符号，抽象程度较高，一百个人看了也不一定结果相同，所以用例要附加相关的用例文档加以说明。
　　

用例形成映射基本就是用户界面(UI)，这一点大家要清楚，不要做了用例再回头从新找界面。

主编QQ: 3339069958

主编微信:TVXQZYN

邮箱：[e-mail]

网址：http://www.876edu.com

如果您想了解软件测试行业，了解新梦想，欢迎咨询，我们将及时的为您服务！