本节书摘来自异步社区《软件工程（第4版?修订版）》一书中的第2章2.4节实际的过程建模，作者【美】Shari Lawrence Pfleeger , 【加】Joanne M.Atlee，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.4 实际的过程建模
软件工程（第4版•修订版）
很长时间以来，过程建模一直是软件工程研究的焦点。但是，它的实用性如何呢？一些研究人员称，正确地使用过程建模，为理解过程和揭示过程中的不一致性带来了诸多益处。例如，Barghouti、Rosenblum、Belanger和Alliegro进行了两个案例研究，以确定在大型组织中使用过程模型的可行性、效用和限制（Barghouti, Rosenblum, Belanger and Alliegro 1995）。在这一节，我们将讨论他们所做的工作以及他们的研究结果。
2.4.1 MarveI的案例研究
在这两个案例研究中，研究人员都使用MSL（即Marvel规格说明语言）来定义过程，然后，为其生成一个Marvel过程制订环境（Kaiser, Feiler and Popovich 1988；Barghouti and Kaiser 1991）。MSL使用3种主要的结构（类、规则和工具信封（tool envelope））来产生一个3部分的过程描述。
(1) 基于规则的过程行为规格说明。
(2) 模型的信息过程的面向对象定义。
(3) 用作执行该过程的外部软件工具和Marvel之间的接口的一组信封。
第一个案例研究的是美国电话电报公司的呼叫处理网络。该网络处理电话呼叫，还包含一个单独的信令网，它负责为这些呼叫安排路由并平衡网络负载。Marvel用于描述信令故障解析过程，该过程负责检测、维修以及解决信令网络的问题。工作中心1监控该网络、检测故障并把故障提交给其他两个工作中心中的一个进行处理；工作中心2处理需要详细分析的软件故障或人为故障；工作中心3处理硬件故障。图2-15描述了这个过程。双虚线表示哪一个活动使用了工具或数据库，工具或数据库用椭圆表示，矩形框表示任务或活动，菱形框表示判定，箭头指明控制流。该图给出的是概要，并没有提供足够的细节以表示基本的过程要素。
因而，用MSL对每一个实体和工作中心建模。图2-16解释了建模是如何进行的。图的上半部分定义了一个凭单类，这里凭单（ticket）表示当一个失效出现时就记下的一个故障单（fault ticket）（或问题报告）。正像我们将在有关测试的章节中看到的那样，故障单用于跟踪一个问题（从问题的出现到它的解决）。整个网络表示为22个这样的MSL类，一个过程的创建或需要的所有信息都包含在其中。
接着，该模型强调了信令故障解析过程的行为方面的信息。图2-16的下半部分是一个MSL规则，它大致对应于图2-15中标有“诊断”的方框。因而，MSL描述了诊断未决问题的规则，它由每一个打开的凭单激发。当过程模型完成时，需要21个MSL规则来描述这个系统。
第二个案例是研究美国电话电报公司的5ESS交换机软件的部分维护过程。与第一个案例研究不同（第一个案例研究的目标是过程改进），第二个案例研究的目的只是用MSL获取过程步骤和交互从而把它们文档化。该模型包含有25个类和26个规则。
对每一个模型，用MSL过程描述生成“过程制订环境”，它产生一个含有信息模型类实例的数据库。接着，研究人员模拟若干场景以验证模型是否像期望的那样执行。在模拟的过程中，他们收集计时和资源使用情况的数据，为分析合适的过程执行提供基础。通过改变这些规则并重复执行一个场景，对计时进行比较和对照，从而不用在资源方面进行大的投资就得到显著的过程改进。
建模和模拟执行对早期识别问题和解决问题是非常有用的。例如，软件维护过程定义揭示了现有过程文档中的3种类型的问题：缺少任务输入和输出、含义模糊的输入输出标准以及低效率的过程定义。信令故障模型的模拟揭示了各工作中心单独描述造成的低效率。
Barghouti和他的同事指出，把过程建模问题划分成建模信息和建模行为是非常重要的。通过将这两方面分离开，产生的模型清晰且简洁。他们还指出，计算机密集的活动比人员密集的活动更容易建模，Curtis和他的同事也指出了这一经验。
2.4.2 过程建模工具和技术应该具有的特性
有很多过程建模的工具和技术，而且研究人员不断地努力，以确定在给定情况下哪些工具和技术是最合适的。但是，有一些特性对任何一种技术都是有益的。Curtis、Kellner和Over标识了以下5类良好的特性（Curtis, Kellner and Over 1992）。
(1) 促进人们的理解和交流。该技术应该使用一种大多数客户和开发人员能理解的方式来表示过程，鼓励关于过程的交流并对其形式和改进达成一致。该技术应该包含足够的信息，以便能够实际执行该过程，并且模型或工具应当成为培训的基础。
(2) 支持过程改进。该技术应当标识开发或维护过程的基本构件。它应当允许在后面的项目中复用过程或子过程，并能比较不同的可选方案，而且在过程实际投入使用之前估算变化造成的影响。同样，该技术应该有助于为过程选择工具和技术，有助于有组织的学习，支持持续的过程演化。
(3) 支持过程管理。该技术应该允许过程是针对特定项目的。这样，开发人员和客户应该能够推测软件创建或演化的属性。该技术还应该支持计划和预测、监控和管理过程以及测量关键的过程特性。
(4) 在执行过程时提供自动化的指导。该技术应该定义所有的或部分的软件开发环境，提供指导和建议，并保留可复用的过程表示供以后使用。
(5) 支持自动化的过程执行。该技术应该让全部的或部分过程自动化，支持协同工作，获取相关的测度数据，以及强制规则以保证过程的完整性。
当为开发项目选择过程建模技术时，这些特性可以作为有用的指导。如果你的组织机构试图将其过程标准化，那么第4个特性特别重要。工具能够提示开发人员下一步做什么，并且提供入口和检查点，以确保在下一步之前，制品满足了某些标准。例如，工具可以检查一组代码构件，评估它的规模和结构。如果规模或结构超出了预先定义的限制，那么，可以在测试开始之前通知开发人员，而某些构件可能被重新检查，也可能要重新设计。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
