[图解]用例规约之补充约束01

1
00:00:01,520 --> 00:00:03,460
那么路径步骤写完之后

2
00:00:05,150 --> 00:00:07,140
接下来就是补充约束了

3
00:00:09,700 --> 00:00:10,800
补充约束的目的就是

4
00:00:12,690 --> 00:00:17,760
扫除路径步骤里面可能存在的模糊的表达

5
00:00:20,300 --> 00:00:26,840
比如说,路径步骤说,会员提交下单信息

6
00:00:28,380 --> 00:00:32,720
你得讲清楚,下单信息包括什么内容

7
00:00:34,130 --> 00:00:38,060
有哪些字段,由哪些内容组成

8
00:00:39,000 --> 00:00:42,370
然后你写,系统验证下单信息合法

9
00:00:44,020 --> 00:00:46,340
你得告诉我,什么叫合法

10
00:00:48,270 --> 00:00:49,460
这有个规则

11
00:00:50,160 --> 00:00:52,100
业务规则等等

12
00:00:54,880 --> 00:00:56,250
还有质量需求

13
00:00:58,010 --> 00:00:59,990
从提交到反馈

14
00:01:01,320 --> 00:01:02,110
要等多久

15
00:01:02,630 --> 00:01:04,330
1秒,5秒,10秒?

16
00:01:05,650 --> 00:01:09,810
质量需求,或者说允许多少人同时下单

17
00:01:10,790 --> 00:01:13,120
并发,质量需求

18
00:01:14,250 --> 00:01:16,220
还有设计约束,在实现的时候

19
00:01:17,050 --> 00:01:20,220
涉众有没有强制的约束

20
00:01:20,790 --> 00:01:21,980
必须要这样实现

21
00:01:23,870 --> 00:01:25,510
来自涉众的强制约束

22
00:01:28,120 --> 00:01:32,070
那么这些补充约束可以写在用例里面

23
00:01:33,360 --> 00:01:34,920
绑定到用例的步骤

24
00:01:34,930 --> 00:01:36,360
比如说,像字段列表

25
00:01:36,370 --> 00:01:40,050
业务规则这种,往往是绑定在那里的

26
00:01:42,930 --> 00:01:44,450
也可以单独到另外文档

27
00:01:45,170 --> 00:01:47,190
像一些这种质量需求

28
00:01:47,200 --> 00:01:50,120
它可能是针对整个系统的

29
00:01:50,980 --> 00:01:52,010
像什么稳定性

30
00:01:52,300 --> 00:01:53,490
可靠性等等

31
00:01:54,900 --> 00:01:56,660
包括使用的平台等等

32
00:01:58,460 --> 00:01:59,570
设计约束

33
00:02:00,150 --> 00:02:01,950
设计约束包括使用平台等等

34
00:02:01,960 --> 00:02:03,750
往往是针对整个系统的

35
00:02:04,250 --> 00:02:05,760
不是针对某个用例的

36
00:02:06,950 --> 00:02:09,950
那么可以单独写在一个地方

37
00:02:15,050 --> 00:02:17,730
我们来看这几个补充约束,字段列表

38
00:02:18,930 --> 00:02:26,370
这是描述路径步骤里面提到的各种概念

39
00:02:26,500 --> 00:02:28,690
包括输入输出

40
00:02:29,170 --> 00:02:30,990
会员提交订单信息

41
00:02:31,400 --> 00:02:32,840
输入一个订单信息

42
00:02:33,150 --> 00:02:34,460
输出,系统反馈

43
00:02:37,630 --> 00:02:41,470
订单的下单的情况之类的

44
00:02:42,020 --> 00:02:44,790
你反馈什么,输出什么

45
00:02:45,140 --> 00:02:51,410
还有你保存,系统保存什么信息

46
00:02:51,950 --> 00:02:52,500
保存什么

47
00:02:53,280 --> 00:02:55,490
会员提交一个什么订单

48
00:02:56,400 --> 00:02:59,570
系统保存这个信息

49
00:02:59,580 --> 00:03:02,170
系统很可能除了会员提交的信息之外

50
00:03:02,730 --> 00:03:04,290
可能还要保存一些别的

51
00:03:04,300 --> 00:03:07,180
比如说,保存当前的下单日期

52
00:03:07,530 --> 00:03:09,790
保存是哪个会员下的单

53
00:03:11,290 --> 00:03:13,280
就是说,提交的跟保存的

54
00:03:13,290 --> 00:03:17,400
很可能并不是同样的信息

55
00:03:18,540 --> 00:03:21,920
它们的字段不完全是一样的

56
00:03:22,830 --> 00:03:26,250
很可能保存的要比提交的要多

57
00:03:26,260 --> 00:03:28,980
也可能提交的比保存多,都有可能

58
00:03:28,990 --> 00:03:31,660
所以,我们不能够说

59
00:03:32,620 --> 00:03:33,140
把一个

60
00:03:34,180 --> 00:03:38,040
画一个数据库的一个模型

61
00:03:38,050 --> 00:03:40,400
然后说,这个就是我字段列表,不是的

62
00:03:40,710 --> 00:03:44,440
因为字段列表要绑定到每一步的

63
00:03:45,320 --> 00:03:47,650
这一步输入是哪几个字段

64
00:03:48,060 --> 00:03:49,220
输出是哪几个字段

65
00:03:49,230 --> 00:03:50,270


66
00:03:51,830 --> 00:03:55,400
每一个步骤它涉及到的字段不一样

67
00:03:55,410 --> 00:03:58,230
不能说给你一个数据库的表,你自己看去

68
00:03:58,360 --> 00:03:59,030
不是这样的

69
00:04:01,930 --> 00:04:03,850
第二个,你数据库表哪里来的

70
00:04:04,790 --> 00:04:05,550
你没有需求

71
00:04:05,560 --> 00:04:08,900
你所谓的数据库模型都是假的

72
00:04:13,920 --> 00:04:20,150
字段列表,不能拿数据库模型

73
00:04:20,160 --> 00:04:22,220
类模型来充当

74
00:04:22,890 --> 00:04:25,250
必须要每一个地方单独写出来

75
00:04:27,390 --> 00:04:29,230
实际上,这一步也是让我们思考什么

76
00:04:29,240 --> 00:04:32,040
最简化的

77
00:04:32,050 --> 00:04:35,520
我们的输入输出的一个思考了

78
00:04:35,890 --> 00:04:37,560
我必须要告诉系统什么

79
00:04:38,270 --> 00:04:39,750
系统必须要告诉我什么

80
00:04:39,760 --> 00:04:42,430
把这个思考出来

81
00:04:43,070 --> 00:04:44,300
使得我们的答案

82
00:04:44,310 --> 00:04:47,270
得到的答案,是最简化,最小化的

1
00:00:01,020 --> 00:00:04,760
下一个补充约束就是业务规则

2
00:00:04,770 --> 00:00:07,430
业务规则是做某些事情的规则

3
00:00:10,700 --> 00:00:12,490
怎么表达这个业务规则

4
00:00:12,500 --> 00:00:15,330
你可以用文字说明

5
00:00:17,220 --> 00:00:19,610
比如说,什么叫合法的订单

6
00:00:20,750 --> 00:00:22,020
必须什么什么

7
00:00:22,150 --> 00:00:22,780
这样说

8
00:00:24,170 --> 00:00:27,620
还有很多了,比如说,决策表

9
00:00:29,850 --> 00:00:33,230
要表达房价的规则

10
00:00:35,750 --> 00:00:38,160
或者行业上适用的任何方式

11
00:00:38,900 --> 00:00:41,080
也就是说,这个地方不一定要用UML

12
00:00:41,090 --> 00:00:43,190
也不一定要用文本

13
00:00:43,200 --> 00:00:46,070
比如说,你做一个物理的软件

14
00:00:48,080 --> 00:00:51,730
那么很可能业务规则就是一个物理公式

15
00:00:52,790 --> 00:00:56,190
那么这个物理公式本身

16
00:00:56,530 --> 00:00:58,280
它就是一个业务规则的

17
00:00:58,930 --> 00:01:00,560
合适的表达形式

18
00:01:00,570 --> 00:01:03,390
不能说这个不是文本

19
00:01:03,670 --> 00:01:05,500
不是UML,不行,不是这样的

20
00:01:05,510 --> 00:01:06,910
因为这个物理公式

21
00:01:06,920 --> 00:01:10,710
对于物理专业的涉众来说

22
00:01:11,920 --> 00:01:13,160
它就是人话

23
00:01:13,820 --> 00:01:14,910
它不是鸟语

24
00:01:16,140 --> 00:01:17,770
它就是核心域的概念

25
00:01:20,270 --> 00:01:21,310
各种方式都可以

26
00:01:21,600 --> 00:01:26,110
但是必须是涉众的角度来描述的

27
00:01:27,370 --> 00:01:30,890
不能说,经常我们说业务规则

28
00:01:30,900 --> 00:01:33,490
很多人经常喜欢说什么,算法

29
00:01:34,390 --> 00:01:37,530
比如说,你这个订单怎么分配的

30
00:01:38,130 --> 00:01:39,380
他说我有算法

31
00:01:40,580 --> 00:01:41,530
不是废话吗

32
00:01:43,610 --> 00:01:45,910
所有的计算机最后都是算法

33
00:01:46,150 --> 00:01:51,120
问题是我们说的业务规则是从什么

34
00:01:51,130 --> 00:01:53,280
即使计算机这个不存在

35
00:01:53,290 --> 00:01:55,360
即使你这个系统不做了

36
00:01:56,260 --> 00:01:58,380
这个规则依然存在的

37
00:02:00,030 --> 00:02:02,510
要表达出这样的一个东西来

38
00:02:02,910 --> 00:02:04,220
而不是什么算法算法

39
00:02:04,510 --> 00:02:06,600
因为很多人他不了解什么叫算法

40
00:02:07,720 --> 00:02:10,770
他觉得算法这两个字很高大上

41
00:02:10,780 --> 00:02:11,730
他到处乱用

42
00:02:12,920 --> 00:02:16,030
算法算法,不是这样的,业务规则

43
00:02:18,390 --> 00:02:20,980
即使没有计算机,计算机不存在

44
00:02:21,350 --> 00:02:25,340
这些规则依然可以表达,它依然成立

45
00:02:25,350 --> 00:02:31,730
依然可以表达的,业务规则是核心域的规则

46
00:02:33,220 --> 00:02:34,970
不要说什么某算法这样

  • 8
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值