这是Howard Podeswa针对业务分析师创建的ABC系列：
A”代表活动图Activity Diagram
几年前，我为一家金融投资公司做过一些咨询。该项目的目标是改善业务流程工作流程，以跟踪客户关系管理（CRM）系统中的机会和建议。该公司一直在使用许多软件产品来处理该过程-一方面是CMS Open，另一方面是PeopleSoft。除其他事项外，他们对正在执行的重复输入次数不满意–在提议处于提议阶段时，在一个系统上输入客户信息，而在提议被接受后，在另一个系统上再次进行客户输入。
我使用的图表显示了该过程的步骤，并指出了由谁或什么系统负责每个步骤。这种类型的图有很多名称，包括：流程图（通常仅显示操作顺序，而不显示操作者），Swimlane工作流程图（显示每个操作的执行者）和（如果您使用的是UML标准）活动图（可能会显示执行者，也可能不会显示执行者），具体取决于绘制方式。
- 上下文
活动图在我描述的情况下非常有用：当您需要分析现有（按现状）或未来（将来）业务流程的工作流时。在UML中，当指定业务用例实现（用于执行业务流程的内部工作流的描述）时，将以这种方式使用（使用Rational Unified Process [RUP]术语）。在这种情况下，通过指示每个参与者的泳道（或“分区”）来画出他们的身份。
使用活动图的另一个上下文是描述系统用例。系统用例是用户任务，通常是计算机用户希望在与软件系统的单个会话中完成的任务。用户和系统之间交互的需求通常以文本形式描述，但是如果文本中的各个步骤以复杂的方式相互连接，则会添加一个活动图。
“B”代表 BPMN
BPMN是经常用于对业务流程进行建模的标准的名称。该标准涵盖的图称为业务流程图（BPD）。
由于活动图（以前的BA ABC博客的主题）涵盖了与BPMN BPD相同的基础，因此自然会产生一个问题：“哪个图更好”？实际上，在这个问题上争议很大，每种方法都支持和反对，因此值得探讨。UML（管理活动图的标准）吹捧的主要优势之一是，通过在整个生命周期中提供单一标准，可以避免翻译错误。通过这种推理，将活动图用于业务流程建模和对其进行自动化的软件流程的逻辑建模是有意义的。另一方面，出于对业务流程进行建模的特定目的，BPMN标准通常被视为更自然的候选者。
争论1：活动图是技术性的，而BPMN BPD是业务性的
- 因为UML标准来自开发世界，所以其活动图被认为是面向代码的。但这更多的是感知问题，而不是事实。实际上，UML是一个全光谱标准，支持真实世界和技术建模。虽然肯定有一些活动图的特征是面向技术的，但事实是，与业务涉众进行交流时，BA只能使用一小部分特征，并且该子集与通常理解的流程图符号紧密对应。（对于BPMN也可以说同样的话。）我强烈怀疑BPMN首字母缩略词中的“业务”一词对BPMN在业务使用中的优先地位的理解具有与其他任何事物一样大的影响。
争论2：总体而言，BPMN图对于业务相关者而言比活动图更容易理解
- 为了克服这些言论，让我们比较一下对于BA目的最有用的建模元素。图2和3显示了常用的BPMN符号及其对应的活动图。快速浏览一下就很难将两者区分开。当您并排看待这些元素时，您真的不得不怀疑所有这些大惊小怪。实际上，在一种情况下（从利益相关者的角度来看），与在BPMN BPD上相比，在活动图中以更清晰的方式表示：并行活动。图4比较了BPD和活动图符号，这些符号用于指示可能并行发生的两个活动（意味着它们可以以任何顺序发生）。我想大多数人都会同意BPD符号-带有“ +”号的钻石，
图3-BPD连接对象（与UML等效）
图4-BPD并行叉（与UML等效）
争论＃3：BPMN包含特殊的建模元素，使其比活动图更适合于业务目的
- 在这里，我确实相信赞成BPMN的观点有其优点。活动图无法很好处理的一种情况是“包含或”。这是用于对通用表达“和/或”进行建模的逻辑结构，例如：根据各种条件，对“ A”和/或“ B”和/或“ C”进行建模。图5说明了这两个标准中使用的方法。显然，BPMN BPD比活动图所需的混乱符号更可取。BPMN具有专用符号的另一种情况与事件的处理有关。图6说明了两种标准之间的区别。BPMN依靠循环事件符号的放置来向阅读器传达对事件响应的时间：活动上的事件符号表示该事件将其中断，而活动之后的事件表示该活动首先完成，然后记录并响应该事件。活动图对此具有一种简单的替代表示法-但对于读者来说，所传达的内容可能不那么容易理解。
图6-BPD事件（等效于UML）
争论＃4：BPMN比活动图更好地建模B2B交互
- 在“现实世界”中，企业与其他企业的互动方式有限，而单个企业中的组织单位的互动方式则更为复杂。在BPMN中，使用池和通道对此建模。将业务表示为池，将业务内的组织单位表示为通道。池之间的交互仅限于消息的传递–有效地反映了企业之间相互传递请求（消息）的方式，同时不了解彼此的内部流程。图7说明了这种方法。在活动图中没有形式主义专用于此概念，尽管通过规定企业通过发送和接收信号进行通信可以很容易地模拟这种情况。尽管如此，
C”用于类图
业务分析师使用类图来帮助他们发现“结构性”业务规则，并以可视化形式将其记录下来，开发人员易于理解。什么是结构规则？这是与业务的“名词”相关的任何规则-例如，只有一个销售人员被记为一笔销售的规则（这样就不会拆分销售佣金），或者根据佣金金额的规则进行销售。这些被认为是结构性业务规则，因为它们与类有关 （UML代表类型）业务中的事物，例如SalesPerson或Sale。
在我们提出的所有建议中，几乎总是会遇到阻力的建议是使用类图（或类似的图，实体关系图[ERD]）作为BA工具。必须意识到由BA绘制的类图和由开发人员创建的类图代表两种截然不同的观点。
BA的模型是对现实世界业务的抽象而开发人员的模型则代表软件解决方案（特别是软件类和数据库的设计模型）。简单的说，决定解决方案的设计是什么，它们仅说明解决方案必须满足的业务规则，无论解决方案是否经过设计的。但我的观察是，BA并未广泛采用绘制类图的实践。
有关类图结构建模的要点。
- BA绘制的类图与业务有关。它们不是技术规格。
- 创建类图的最佳时间是在需求会议期间，在此期间，它们可以帮助揭示缺失的规则，而不是稍后。
- 该模型不一定必须是正式的或完整的即可。在敏捷项目中，为了促进开发人员和利益相关者之间的会议，您可能只能创建上述草图。在这种情况下，它们仍然具有巨大的价值，因为它们可以帮助揭示缺失的业务规则。
类图的业务上下文
在某些情况下，我使用它的范围很广：
- eral仪馆：捕获企业存储死者个人信息所需的方式，并跟踪他们与产品（棺材）和墓地位置的关系。
- 军事：引出并记录有关军事装备及其相关维护工作的规则。
- 差旅：获取有关如何从土地，航空和酒店组成部分构造差旅套餐以及如何计费和出票的规则
- 制造：向开发人员说明如何在供应链中前后追溯有缺陷的组件。
- 司法系统：确定如何跟踪案件。
- 客户关系管理（CRM）：跟踪客户如何分组和分配给代理商。
作者： 霍华德·波德斯瓦（Howard Podeswa）是业务分析的领导者，为该行业的正规化做出了贡献，成为NITAS的SME，CompTIA的BA学徒计划，BABOK审核小组成员和作者。他是一位备受追捧的演讲者，在IT行业的许多方面都拥有30年的经验，最初是加拿大Atomic Energy，Ltd.的开发人员，然后继续担任系统分析师，业务分析师和课程设计师。他是《业务分析师手册》和《 IT业务分析师UML》的作者，该手册是BA的需求收集和文档的实用指南，目前已出版第2版，以3种语言出版。通过他的公司，霍华德（Howard）为医疗保健，国防，能源，政府，银行和金融等多个行业部门提供了BA咨询服务，其客户基础广泛，包括梅奥诊所，加拿大空军，南非社区和平计划（CPP），德勤，ISO，UST Global（美国和印度）和BMO /哈里斯银行。此外，霍华德还为众多机构设计了文学士培训课程，包括CDI（现为全球知识），波士顿大学，亨伯学院和新视野。
点击标题