3. 业务建模
业务建模是在业务用例分析的基础之上，使用UML工具，从不同的角度对用例流程、参与者、规则、约束进行描述，用于指导后续的需求分析和系统设计。
描述的角度主要有如下三类：
（1） 根据参与者在当前业务中的职责和行为；
（2） 根据参与者在业务流程的各自行为执行的先后顺序；
（3） 根据参与者在业务流程中的协作和交互过程。
这里，提示大家想一想，如果有过负责或者参与产品的系统设计的经历的，在系统设计完成后，是否后期设计中，往往会发现系统设计中有些业务是被遗漏掉而需要补充的。当然，即便是增加了业务建模，也可能会导业务流程的遗漏。但是经过这样扎实的交流、分析和设计，至少关键、重要的业务流程一般不会被遗漏掉。
要对业务进行建模，除了业务用例视图（连载五中已经描述）外，还需要分析和描述清楚业务用例的场景、业务用例规则（其中最重要的就是前置条件和后置条件）。
我们以连载五中图1.6“发起数据业务”为例，来说明如何针对业务用例进行业务建模。
一般的，在业务建模阶段，首先要分析清楚参与者在业务流程中的职责和行为，采用UML中的活动图来描述；
其次，如果针对某个业务流程，参与者的协作和交互非常重要，那么也需要采用UML中的协作图，对参与者的协作和交互做重点描述；再次，针对关键的参与者的行为的执行先后顺序，可以采用UML的序列图进行描述。
这里，我们以软件协议栈为边界，而不是终端系统为边界，对“发起数据业务”这个业务用例进行业务建模。
根据图3.1，我们对单次发起数据业务的用例场景有了基本的了解。这里我们不用去探究软件协议栈内部的处理。但是根据图3.1，第一点，能够看到在软件协议栈的“状态”不同的情况下，单次发起数据业务的流程是不同的。我们希望对“非连接状态”下的控制和业务处理的先后顺序有更为清晰的认识，自然我们想到用序列图进行建模；第二点，是否在软件协议栈的不同“状态”下，业务应用子系统和软件协议栈子系统之间的交互，会有不同呢？这个描述可以用协作图来解决。
针对图3.2，有如下三点解释：
（1）“状态”：图3.1和图3.2中都提到了状态。状态是软件协议栈维护的和基站系统之间的状态，是一个比较复杂的参量，现阶段读者只要知道这个参量是用来描述终端和基站之间是否具备直接发送业务的条件；
（2）图3.2仅仅描述了在“非连接状态”下，在终端发起业务时，终端和基站成功建立连接的一种序列图。针对“连接状态”下的终端发起业务、以及终端和基站之间业务建立失败的序列图，这里就不再描述了。但是在做业务建模时，分析人员这点是要清楚的。
（3）图3.2中省略了基带子系统和射频子系统，是因为二者都受软件协议栈的调度和控制，在不影响业务分析的情况下，可以省略，简化工作量。
针对单次发起数据业务的用例场景，进行业务传输，首先需要和对端建立业务连接。比如针对TCP连接，TCP的三次握手连接是有时间限制的。针对非TCP的其他连接类型，那连接的时间限制可能和TCP业务有所不同。
针对终端的软件协议栈，在不同的“非连接状态”下，和基站之间建立连接所花费的时间也有不同，同时根据信道的好坏情况，同样的连接建立，花费的时间也有所不同。那么，在这种情况下，为了提高连接建立的概率和业务体验，很有可能需要在业务子系统和软件协议栈之间，针对不同的情况，建立协作机制。
图3.3重点描述了业务子系统和软件协议栈之间的一种请求-反馈机制。业务子系统可以根据软件协议协议栈的反馈，来控制业务连接时间和控制，提升用户体验。按照分层的设置，我们不期望高层业务和底层的业务之间存在这种时间上的耦合关系，但是因为承载于LTE协议栈之上的业务协议可能有多种，针对可能承载在之上的业务协议，都需要做进一步的分析。
4. 领域建模
如果对于“领域”有不了解的，请参考连载系列之三的“领域模型和业务模型”。
针对领域建模，首先我们需要找到关键的“领域”。领域问题见仁见智，可能不同的分析人员分析的结果不尽相同。这里，请各位首先思考一下，你认为的领域问题是什么？
通过上述业务建模的分析，这里认为终端和基站之间的连接状态，是一个需要进一步重点分析的状态量。因为以下两点原因：
（1） 终端和基站之间的连接状态有多种情况，比较复杂；
（2） 在不同的连接状态下，针对“发起数据业务”用例，业务子系统等待的时间以及处理的流程是不同的。
好，下面就针对这个问题进行分析。
当软件协议栈接收到数据包发送请求时，终端和基站之间的连接状态有哪些可能的情况。
（1） 终端未找到驻留小区，分为找不到驻留小区和终端正处于开机驻留过程之中；
（2） 终端处于飞行模式；
（3） 终端处于下行失步状态；
（4） 终端处于DRX周期；
（5） 终端处于上行失步状态；
（6） 终端和基站之间的RRC连接被释放；
（7） 终端和基站之间的RRC连接存在；
（8） 终端正处于切换过程中；
（9） 终端正处于Tracking Area Update过程中；
（10） 。。。。。。
以上通过头脑风暴分析到了多种可能的状态和原因，下面表4-1对这可能的状态进行分析和整理。
通过表4-1，我们可以知道，在不同的状态和原因下，软件协议栈需要给业务子系统反馈的状态。同时，如果熟悉LTE，可以针对不同的可能影响和系统的硬件方案，能够估算出恢复终端和基站之间连接所需要的时间。这样，就能够提前评估出是否符合不同的业务连接的需要。
针对TCP的连接的建立，根据TCP/IP详解 卷一中的描述，客户发送的第二个SYN和第一个间隔6s，第三个SYN和第二个SYN间隔24s，这么长的时间周期内，底层的连接建立结果是能够确定的。
可以将表4-1的描述，反代入到图3.1、图3.2和图3.3的业务用例场景中，看看有无风险点？这个处理大家可以尝试一下。
【小结】
本连载六和上一期的连载五，以软件协议栈为边界，对业务用例、用例场景（以发起数据业务用例为例）、用例的规则和用例的关键领域做了分析和建模，尽量描述清楚“发起数据业务”这一用例。
同时在用例场景中，从不同的测量，分别用活动图、序列图和协作图，对“发起数据”用例做了描述。
不知道大家对于业务用例分析、业务用例建模和领域分析是否有了一定的了解呢？
现在我们将重点放在纯业务的分析上面。从下一期开始，我们将针对“发起业务”业务，进行需求分析和需求建模。才会逐步关注针对业务的功能需求和非功能性需求。
发表于 2014-9-7 23:58:48
