本文重点是业务建模实践，以及建模工具EA初级使用过程日志。
先前写了些文档，从不同角度描述了业务建模，但是条理性和规范性仍无法让人一目了然。春节期间当我再次读了《软件方法》前几章，产生了共鸣：误解随处都在，通过UML规范沟通环境，是辛勤汗水的教训。
按书中观点及回答问题如下：
业务建模：描述组织内部各系统（人肉系统、机械系统、电脑系统......）如何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个零件。组织引进一个软件系统，和招聘一名新员工没有本质区别。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。
需求：聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的表现─功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众（Stakeholder）在意的、不能改变的契约，哪些不是，严防“做”污染“卖”。需求工作流的结果─需求规约是“卖”和“做”的衔接点。
组织要解决什么问题。
为组织提供流程管理、流程再造服务，为组织办公流程能力、执行力、工作效率提供管理支撑服务。
为了解决组织的问题，待开发系统应该提供什么功能和性能。
提供本地化、个性化BPM服务，提供快速开发流程支持（5个工作日以内）服务，通过流程（流程定义与流程实例）全面生命周期为组织提供管理创新支持服务。
本次实践的研究对象是办公管理的业务流程。
业务用例模型是说明业务预期功能的模型。作为一个核心输入模型，业务用例模型用于确定组织的各个角色和可交付工件。
图1
按办公管理的业务流程为研究对象，涉众利益者有办公管理人员、流程管理人员（是办公管理人员中的子集，是其中专业管理流程的人员）、流程开发者（运维人员）、系统建设者等，其中业务用例所关注的主要涉众是办公管理人员、流程管理人员、流程开发者，也就是业务执行者。
有箭头从执行者指向用例，也有箭头从用例指向执行者。前一种执行者称为用例的主执行者，后一种执行者称为用例的辅助执行者。
如图1所示，以及《易扩展的办公流程化管理核心模型（第1版）》所述，此图中的用例是组织业务建模用例，解答组织真实核心需求，并不是人们日常所见到的资费审批流程、人力请假流程...，而是能支撑快速开发流程及支持管理创新的流程管理能力平台。
需求及功能敬请见下篇文章。
Enterprise Architect 是基于UML 标准的，将高效建模和可视化，及设计融为一体的平台。它具有从思维导图，到业务需求，软件设计，直至部署的完全跟踪能力。
1.创建项目
通过模型向导，选择“Use Case”，其它根据实际情况选择。
图2
2.分包管理
在用例模型下，创建业务分组包（package）
图3
图4
结果如下：
图5
3.创建用例图（Use Case Diagram）
图6
图形类型选择用例“Use Case”。
1）首先确定研究用例对象的边界
图7
拖拽“Boundary”到用例图中，并进行定义，名字为“流程管理”。
图8
生成的边界如下图所示。
图9
2）添加业务执行者“Business Actor”
拖拽上图中的“Actor”到用例图中，命名为“办公人员”，并按下图设置为“Business Actor”。
图10
结果如下：
图11
3）添加用例
拖拽上图中的“Use Case”到用例图中。弹出如下图所示的用例定义窗口，输入用例名称为“申请”。
图12
生成如下所示图形。
图13
4）添加关联线
选择工具盒中的“Use Case Relationships”->“Associate”线，点击“办公人员”Actor并按住鼠标拖拽到“申请”用例中（出现关联虚影）再松开鼠标按键，
图14
图15
鼠标双击下图中关联线（实线），弹出关联线定义窗口。
图16
在弹出窗口中，通过选择定义关联线类型“Stereotype”来定义业务执行者与用例关联关系，此案例中选择了“Source->Destination”。
图17
图18
最终如图1所示的用例图。
参考及摘自：
《软件方法》UMLChina 潘加宇 2012.11
易扩展的办公流程化管理核心模型（第1版）肖永威 2015.1
原文地址：http://blog.csdn.net/xiaoyw71/article/details/43938505
