油田采油生产业务建模之业务用例实践（EA使用入门）

　　在设计工业企业生产物联网和管理信息化创新产品过程中，需要明确业务边界和掌握生产业务，并且设计出来的产品要符合工业生产规程，形成闭环管理，这样的产品才能被允许投入到企业生产中。

　　如何能快速的明确业务边界和掌握生产业务？业界通用方法是业务建模。

　　业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。

　　按业界规范，采用统一建模语言（UML）进行业务建模。

　　基于统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟通的效率和深度，有意无意遮掩的脓包也会强制露出。

　　业务执行者（Business Actor） ，这个小人就是被研究组织（本文为油田企业）内的人（例如采油工）、人群和机构（采油队），也是我们通常所说的组织角色、岗位。

　　业务用例（business use case），这个圆圈是指业务执行者希望通过和所研究组织交互获得的价值。以采油生产过程为例，“巡井踏查”业务活动就是采油工的一个业务用例。

　　使用建模工具EA，开始第一个业务模型——抽油机管家。

　　新建项目。

　　新建模型，通过“模型向导”开始第一个用例（Use Case）模型。

　　新建元素，用例模型元素包括业务执行者（Actor）、业务用例（Use Case），在本例中新建了业务执行者包括采油工、调度指挥等；业务用例包括巡井踏查、故障申报等。

　　画用例图，点击图标，打开用例模型图板（Use Case Model），拖拽元素到用例图中。（拖拽过程中将弹出对话框，“放在图上做为：”选择“连接”）

　　为角色、用例间，以及用例与用例间建立关联关系。

　　确定关联方向：“起始->目标”，箭头从角色指向用例。
　　

　　确定用例间的关系：

　　用例间关系包括Include、Extend：

　　《Include》: 表示一个用例包含另一个用例，即要完成包含用例就一定要执行被包含用例。主要体现的是“抽象”的思想，即当两个或多个用例存在相同的部分时，可以将相同部分抽离出来作为一个独立的子用例（共享服务），因为子用例被抽象出来了，因此它与基用例都不是一个完整的用例，只有他们结合起来时才是一个完整的用例。

　　《extend》:表示一个用例扩展到另一个用例，这里有一点需要注意：在执行一个被扩展用例时，不一定执行扩展用例。即扩展用例的执行是受条件限制的，是可选的。这一点，是区别两个用例之间的关系是《包含》还是《扩展》的依据。

　　在如用例图所示的内容中，故障申报用例是基于巡井踏查扩展出来的用例，同时维护抽油机用例也能扩展出故障申报用例，所以巡井踏查与故障申报用例间的关系是Extend。

　　生产任务管理是指任务消息的管理，与巡井踏查、维护抽油机等工作紧密相关，采油工按任务进行工作，所以生产任务管理独立存在是没有意义的，巡井踏查与生产任务管理用例间关系是是Include关系。

　　调度指挥角色、专家系统角色，通过生产任务管理用例，人工或系统智能的安排采油生产任务，以及任务跟踪管理。

　　至此，完成一幅抽油机生产管理的用例图，为设计人员描绘出采油生产参与者、业务活动，以及相互间简明关系。

参考：

[1]. 《软件方法》上册，业务建模和需求 潘加宇 清华大学出版社

[2].EA业务建模实践之业务用例图 CSDN博客 肖永威 2015.2

[3].谈谈需求分析规范化 CSDN博客 肖永威 2017.1