快速学习COSMIC方法之八：如何识别功能处理

在上一讲中我们讨论了对功能处理概念的理解，那是我们识别功能处理的基础。本节我们将继续讲解如何识别功能处理。在度量手册中，对识别功能处理给出了如下的规则：

a)   一个功能处理应该完全属于某层且仅属于某一层的一个软件块的度量范围。

b)   一个功能处理至少包含两个数据移动，一个输入加上一个输出或写。一个功能处理中数据移动的数量没有上限。

c)   一个执行中的功能处理，当其响应了触发输入并满足FUR时，则功能处理结束。由技术原因导致处理出现暂停时，不能认为功能处理结束了。

结合前面的功能处理的定义，我们来汇总一下识别功能处理的经验法则，我总结的5条，分别举例解释说明如下：

 

1 需求明确

1）功能处理一定在功能性用户需求中有描述的，如果需求中没有提到，则可以忽略之，不能杜撰一个功能处理出来。

2） 在功能性用户需求中要求明确区分的功能，虽然可能两个功能很相似，但是也是不同的功能处理。例如新增人员信息与修改人员信息，虽然识别出的数据移动可能是一样的，但是用户有不同的处理目的，应该识别为不同的功能处理。

 2 功能单一

功能不可以再细拆分为更小的可以独立存在的功能了，如单据维护的功能，里面其实包含了单据的增、删、改、查，四个更小的可以独立存在的功能，因此单据维护就不是一个单独的功能处理，而是应该识别为四个。

 3 执行独立

1）如果执行了功能处理A，则不一定非要执行B，则可以说A和B是不同的功能处理。

 例如读后修改的功能，先查询出某人的信息，然后用户再决定要不要修改此人的详细信息，查询人员信息与修改人员信息就是两个不同的功能处理。虽然必须先执行查询功能，但是执行了查询后，则未必一定执行修改，这是由用户做出的决策，不是系统自动做出的决策。

 2）如果执行了功能处理A，未必一定马上执行功能处理B，而是在A结束后，经过一段时间后再执行B，则可以说A和B就是不同的功能处理。

例如，录入采购订单后，可能经过1天，也可能1个月后才可以对订单进行付款，则录入订单与订单付款就是不同的功能处理，此时录入订单和订单付款可能是同一个功能用户（类型）。

3）如果执行了功能处理A之后，需要换另外一个角色执行功能处理B，则A和B就是不同的功能处理。

例如，新员工入职后，一个岗位负责先录入人员的基本信息，另外一个岗位再录入人员的工资信息，虽然他们都是录入人员的信息，但是应该是两个独立的功能处理。

 4 有始有终

1）始，指触发输入，一个功能处理的第1个数据移动一定是一个触发输入。

终，一个功能处理一定包含了一个写或输出，一个功能应该是以写或输出作为功能处理的结束。例如，识别出的一个功能处理中，如果只有输入和读，而没有输出和写，则这个功能处理中的数据移动一定是识别错了。

2）一个功能处理应该达成了其预期的目的后才能算完成了，即半途而废、没有达成目标是不能算一个单独的功能处理。例如，在人员信息的输入过程中，录入了部分人员信息，没有存盘，直接退出了，不能算一个单独的功能处理。

3）在一个功能处理中，根据输入数据组的不同，可能有多种处理路径，此时这些不同的处理路径，不能视为不同的功能处理。例如，录入人员的信息后，根据人员性别不同，设置的人员退休年龄不同，不能视为两个不同的功能处理。

 5 不能跨层

在COSMIC方法中，对层次有明确的定义，因为软件一般都是层次化结构存在的。我们的软件通常都分为：应用层，中间件层，数据库层，操作系统层，驱动程序层等。对于应用层，还可以再细分为：界面层，中间层，数据层。如果采用SOA模式的开发，中间层还可以再细分。是否需要细分，取决于度量目的。对软件分层是为了确定度量的范围。

度量范围是根据度量目的确定的。度量范围分为总体的度量范围与具体的度量范围，总体的度量范围即所有的在本次度量中要包括的软件；具体的度量范围指的是我们在度量总体范围中的某个功能、某个模块、某个子系统、某个软件时的度量对象。缺省情况下，我们提到的度量范围都是指具体的度量范围。这个具体的度量范围是不能跨层的，而我们说的功能处理，一定是存在于某个具体范围中，是不能跨层存在的。

 在识别功能处理时，我们需要先识别触发事件，通过触发事件来识别功能处理。如何识别触发事件，请参阅前面的《快速学习COSMIC方法之六：如何识别触发事件》。

 再次重申，本系列文章是对COSMIC度量方法的通俗解释，目的是帮助大家理解COSMIC中的概念、原则与规则，因此在行文中可能有不严谨的地方，敬请谅解。