软件架构要分层、分模块

图仅仅是描述了系统具有的功能，但是并没有描述每一个用例的行为，也就是执行过程。

在上一篇文章中说到，我们不需要对每一个用例进行分析，而是需要在这些用例中，找出那些关键用例，然后对这些关键用例写出用例描述，因为关键用例才是系统架构的决定因素。

那么又出现一个问题了：如果把所有的用例，按照重要程度进行优先级排序，那么从上到下应该选取多少个、或者说百分之多少的关键用例呢?这个就要看整个系统的复杂度了，30%不嫌少，50%不嫌多，根据你的时间自由把握。

以上图网关中的用例图来说，我认为：添加设备、删除设备、控制设备、规则配置、规则触发这几个用例比较关键，因此，我就针对这几个用例写用例描述。有 2 点注意的地方：

在事件流中，我们是把网关作为一个黑盒进行描述的，因为我们是在进行需求分析，而不是在进行设计，因此，不需要考虑网关内部的执行流程;

红色部分都是一个执行主体，这个主体可以是一个人、一个界面、一个设备、一个系统等等;

事件流可以用文字来描述(就像图中这样)，也可以画一个序列图来展现这个过程，就像下面这样(这里没有详细描述出更细的执行过程，主要以示意性为主):

 

我们现在需要通过鲁棒图这个工具，去拆解用例描述中的事件流，把系统内部的、为了完成这个用例所需要的参与元素，全部都找出来，并标注它们之间的关系。

1. 对每个关键用例的用例描述，画出鲁棒图

先说一下容易混淆的概念：鲁棒性，也称作健壮性，是指程序在运行过程中，即使出现了一些错误的状况，也已让能够顺利的执行下去。它描述的是程序的容错性。

鲁棒图是指：用图形建模的方式，来描述一个用例描述是否正确、是否完善。

主要通过 3 种元素：边界对象，控制对象和实体对象，来画出一个用例描述中，待设计的系统内部各功能模块之间的交互关系。

边界对象：在系统内部，需要与外界进行交互的元素。它负责接收外部的输入、向外部输出内部的处理结果;

控制对象：描述动态的控制行为，强调从一个执行环节进入另一个执行环

（编辑：阜新站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!