高端网站建设服务商,做网站一定要公司备案吗,网站加载页模板,赚钱软件的套路1.说明 关于用例图#xff0c;这篇文章我将直接照搬罗伯特.C.马丁老爷子在《敏捷开发》一书种的第17章#xff0c;并配上自己的理解#xff0c;因为这一章写的实在是太精彩了#xff0c;希望能够分享给大家#xff0c;共勉。以下是老爷子的原文中文翻译以及豆芽的个人解读…1.说明 关于用例图这篇文章我将直接照搬罗伯特.C.马丁老爷子在《敏捷开发》一书种的第17章并配上自己的理解因为这一章写的实在是太精彩了希望能够分享给大家共勉。以下是老爷子的原文中文翻译以及豆芽的个人解读。
2.怎么看待用例 用例的思路非常好却被过度复杂化了。我总是看到一些开发团队围坐在一起讨论用例该如何写。一般来说这种团队更多的是在关注形式而非内容。他们在前置条件、后置条件、主参与者、辅助参与者以及一堆根本不重要的事情上争论不休。豆芽解读看到没有老爷子一直是一个非常注重实践任何复杂而无用的理论都应该丢到垃圾桶。 使用用例真正的窍门就是保持用例简单。不要担心用例的格式简单把它们写在空白纸、字处理器的空白页或空白的索引卡片上就行了。不要担心所有的细节。细节只有到了很后期才有用。不必为记录所有的用例而烦恼因为那是一项不可能完成的任务。关于用例有一点要牢记明天它们将会变化。不管你多么努力地记录它们不管你在记录细节方面多么地一丝不苟不管你考虑地多么全面不管你在研究和分析需求上投入了多少精力明天它们都要变化。如果有些东西明天会变化那么就不必在今天就记录下它的细节。事实上你要做的就是把细节的记录推迟到最后一刻。可以请把用例看作是即时需求。(豆芽解读敏捷开发面对的是变化也就是需求的变化用例同样无法固化所以不要妄图用任何形式固化它。)
3.怎么写用例 请注意本节的标题。我们是要写用例而不是要画它们。用例不是图示。用例是从一个特定视角进行编写的关于行为需求的文本描述。 “等等”你喊道“我知道UML中有用例图我见过。” 不错UML中确实有用例图。不过从这些图中你根本看不出任何有关用例的内容。它们根本不包含任何关于行为需求的信息而这正是用例该记录的内容。UML中的用例图记录的完全是其他一些东西。(豆芽解读老爷子的这段话我个人感觉比较极端虽然说用例图没有比文本描述要强上多少但是老爷子说用例图完全没有用我觉得还是过于极端了。主要他想表达的是用例图确实无法表示用例的实现细节对测试和编码来说确实用处不大但是对需求分析和系统设计而言还是具备一定的指导意义的。)
4.用例图有什么用 我们下面来看看老爷子所说的用例图是不是那么没用。用例图至少有以下四个应用场景即需求分析、 系统设计、 测试、 文档编写。我们先看下一个用例通过用例图和文本描述分别是什么样的。例如下面是销售终端系统的一个典型用例卖出商品的用例。
文本表示
收银员在扫描仪上划过商品扫描仪读取UPC码。商品的价格、描述以及当前价格总数出现在朝向顾客的显示器上。价格和描述也出现在收银员的屏幕上。价格和描述打印在收银条上。系统发出可以听到的“确认”声以通知收银员UPC码正确读取。
用例图表示 额这确如老爷子所说我竟然不知道如果绘制以上文本描述的用例图。因为如果我用更详细的图示表示的话会发现文字还是更加直观且完整。 用文本表示用例已经完成表示了用例的基本流程。不需要任何更复杂的东西。事实上如果用例不是一会儿就要实现那么即使是上面这几个简单的步骤可能也过于详细了。如果用例不需要在几天或者一周内就要实现我们是不希望记录这种细节的。如果不记录下用例的细节如何对它进行估算呢你可以去问利益相关者有关细节的内容不必把它记录下来。这会为你提供进行粗略估算所需要的信息。既然要去询问利益相关者一些细节方面的内容为什么不把它们记录下来呢因为明天细节将会变化。难道变化不会影响到估算吗会影响不过对大量的用例来说这些影响会相互抵消。过早记录下细节是完全不划算的。如果我们现在不记录用例的细节那要记录什么呢如果不写下一些东西我们又如何得知存用例呢记下用例的名称即可。在电子表格或者文档中保持用例名字的代码清单。更好的做法是把用例的名称写在索引卡片上保存在一起等临近实现时再填入细节。
5.怎么画用例图 虽然以上的大量篇幅看起来都在劝退各位不要使用用例图但是我们还是需要教会大家怎么画用例图因为当你评价一个事物前首先要了解它我说的。 用例图中包括四种元素参与者、用例、它们之间的关系、系统边界。关于参与者与用例的解析详见下表 系统边界主要描述需要系统实现的功能集合一般使用矩形框将系统边界标注出来。
各元素之前的关系如下 6.总结
你对用例的态度一定要保持这种简洁性。如果陷入用例复杂性的黑暗面就会被它牢牢控制。运用原力保持用例的简单化。
引用
《敏捷开发》——罗伯特.C.马丁
如何画用例图UML (baidu.com)
