zoukankan      html  css  js  c++  java
  • 需求用例分析之四:业务规则

    作者:张克强

    作者微博:张克强-敏捷307

    在雅各布森用例分析方法和科伯恩用例分析方法中用例本身事实上都没有“业务规则”的属性。可是业界使用中经常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢?

    从时间和传播上非常easy判断,业务规则的来源是传统的需求规格说明书。

    在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是当中核心的分析产物。受到传统需求规格说明书的深远影响。不少人认为这种业务规则是值得写的用例规约中的。

    业务规则有哪些?

    在《用例规约的编写--业务规则和实体描写叙述一文(下文称为c文)中,将业务规则分为三类:

    1.一种是全局规则一般与全部用例都相关而不是与特定用例相关

    2.另外一种是交互规则产生于用例场景其中

    3.第三种是内禀规则是指业务实体本身具备的规则而且不由于外部的交互而变化的规则比如。每张定单至少要有一件商品,同一类商品数量不能大于5件等。

    在这篇文章的后面提出“将这些单独列出来并给予关注和管理是非常有必要的”。

    显然的,将全局规则列出的话。肯定不会在用例规约中。由于它与特定用例无关。那么在用例规约中要单独列出来的是交互规则和内禀规则。

    用例规约与交互规则

    先来看交互规则的情况,相同在上述那篇文章中 “交互规则是在用例场景其中产生的,它们规定了满足什么条件后业务将怎样反应。通常,这部分规则是最复杂,也最不稳定,最easy变化的。

    大家所说的需求常常变更相信绝大部分就来自于此”,那么假设是先写了用例场景(指事件流),再将这复杂不稳定交易的规则提炼出来后,就将产生信息冗余一致性的问题。在以后处理变化时,须要改动2处。假设是提炼到用例以外,那么上下文关联问题和冗余不一致问题就更加突出。假设是提炼在用例之内。即是有专门的“业务规则”属性字段,事件流的表现力是足够表现不论什么复杂规则的。把相同信息在同一个地方写两次是没有必要的。所以这种提炼是多余的。

    而假设是在业务规则中先写了交互规则,再来写用例事件流。也可大致分为两种情况。一是按传统SRS写法已经书写了较完整的交互规则。这样的情况下,用例事件流的书写就显得多余,往往在24行字中说明參见业务规则。然后事件流就结束了,这样的写法相当于穿着用例外衣的传统SRS,我想这或许就是两位大师都没有加上“业务规则”属性的原因。二是先很概要的记录了业务规则,然后书写事件流来体现业务规则,这样的情况下事件流的书写就显得有价值。那么在这样的情况下这概要的业务规则就不必要独占一个专门的属性字段,全然能够写到用例的简要说明中。

    用例规约与内禀规则

    再来看内禀规则的情况。首先交互规则与内禀规则的差异是极为模糊的。比方诸如“同一类商品数量不能大于5”在交互中须要校验。是能够属于交互规则的。其次这本身属于需求的范畴。这是业务层面的规则,c文也是说“这类规则是业务实体的内在规则”,可是c文紧接着说“因此应该写到领域模型文档中”。

    显然的此类规则应当反映在用例中,由于假设不在用例中反映,那么需求就是不完整的。其次在用例中怎样反映?这与交互规则的情况是全然一样,概要能够写到简要说明,详细规则的详细应用在事件流中反映,假设规则的篇幅长并且又是比較细节。须要引用到其他文件,但前提是一定在事件流里明白说明并引用。

    其实c文在后面说到“同一时候这部分规则(指交互规则)通常在系统中以Control类去实现,MVC模式如此,SOA架构中的BPEL也是如此”“这类规则(指内禀规则)应该实现到你的实体类中去,不论你的业务实体是EntityBean,JavaBean,POJO还是COM+,依据面向对象的封装原则,内禀的逻辑一定不要让它暴露到外部去”。这就让需求分析去考虑了兴许分析设计的任务,需求分析已经是天下难事,再兼顾分析设计,那么用例承担了过重的任务。

    当然在RUP其中,用例确实承担了如此重的任务。在“拥抱敏捷的用例分析方法”一文中说明了用例分析不必承担过多的职责,不必考虑识别详细实现的类,专注于需求表达。

    专注于表达需求的用例对兴许的面向对象分析与设计相同是高效并且准确的传递信息。

    小结

    经过以上分析,能够看到“业务规则”确实不是用例规约的必需字段,能够通过用例简要说明和事件流覆盖用例级别全部的业务规则。

    假设非要有业务规则。有一个简单的规则来帮助推断是否体现了用例分析的优势:事件流的描写叙述文字是否明显比业务规则长?假设非常长的业务规则配与非常短的事件流,那么这是穿着用例外衣的传统SRS写法。

    另外,有些规则篇幅可能比較长,也比較细节,比方说明地址信息的有效性校验,在《编写有效用例》中建议在用例中引用。另外地方书写,比方数据字典。这也是不错的办法。

    參考文献

    OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描写叙述。coffeewoo  http://blog.csdn.net/coffeewoo/article/details/4073551 

    拥抱敏捷的用例分析方法,张克强。http://blog.csdn.net/zhangmike/article/details/6790919


  • 相关阅读:
    AtCoder Beginner Contest 205
    Codeforces Round #725 (Div. 3)
    Educational Codeforces Round 110 (Rated for Div. 2)【A
    Codeforces Round #722 (Div. 2)
    AtCoder Beginner Contest 203(Sponsored by Panasonic)
    AISing Programming Contest 2021(AtCoder Beginner Contest 202)
    PTA 520 钻石争霸赛 2021
    Educational Codeforces Round 109 (Rated for Div. 2)【ABCD】
    AtCoder Beginner Contest 200 E
    Educational Codeforces Round 108 (Rated for Div. 2)【ABCD】
  • 原文地址:https://www.cnblogs.com/slgkaifa/p/7363651.html
Copyright © 2011-2022 走看看