本篇文章是下面两篇文章的后续：《UML建模方法论（上）：建模初期准备》《UML建模方法论（中）：业务建模》阅读本篇文章前建议先阅读上面两篇文章。
五、系统建模
系统建模这里如果按照书中的方法同样需要做很多的工作，包括：
概念用例
系统用例视图
系统用例规约
补充规约
业务规则
系统用例实现
分析对象
在这里我们还是和上面一样，只用分析系统用例视图模型和系统用例场景即可
5.1 系统用例视图建模
什么是系统用例模型：
实际上，系统建模就是我们通常所说的需求获取。
一般来说，系统二字可以省略， 所谓的系统用例就是我们熟悉的用例，系统用例模型也就是我们熟悉的用例模型。
所以这里也将省略系统二字， 直接使用用例模型这一叫法。
制作用例模型的作用：
1）系统的功能性需求完全由用例模型来表达。作为客户方和开发方的契约，用例模型必须得到客户的认可。
2）用例模型从作用上讲完全等同于＂需求规格说明书”，它将作为合同附件来约定系统的开发范围。
需求范围不等于系统范围，不是所有的需求都要在系统中实现，例如那些不适合在计算机系统里运行的手工任务：也不是所有的系统功能都是从需求当中来的，例如那些系统管理类的功能。
3）另一方面，用例模型也是客户理解系统的最重要途径。如果客户认可用例模型， 开发方就可以认为系统正是客户所需要的。
如何获取系统用例：
要找到系统用例，首先要分析业务用例场景，从业务用例场景当中抽出那些可以在计算机当中实现的单元来。
所以这里也说明了一个问题，产品经理懂技术的重要性，懂技术的话，在这一个环节你可以清楚的知道哪些地方是可以由计算机来实现的，哪些可以转化为系统用例；如果你不懂技术的话，就有可能漏掉一些可能的系统用例，不过好在一般情况下即使你不太懂技术，大部分系统用例也很容易判断出来。
业务用例场景通常被描述为某某做什么，然后某某又做什么……某某做什么就是系统用例的来源。
继续分析我们的案例：
之前我们已经绘制出了系统用例场景图，接下来我们只需要从系统用例场景图中找出系统用例即可。
简单点说就是分析业务用例场景图中的哪些步骤能通过计算机来代替：
上图中红色边框的步骤都是可以转换为系统用例的，也就是说这些步骤都可以在计算机上完成，由此我们得到系统用例图：
说明：至此我们已经推导出了我们需要做哪些功能，这里的每一个用例就是我们在系统需要去实现的功能，但是还没结束，接下来是系统用例场景建模。
和业务用例场景建模的区别：
与业务用例场景建模不同的是， 我们的视角和建模目的已经从原来的描述业务、理解业务变成了理解系统、描述系统。这两者的差别在于引入了计算机。
之前的描述是原来的业务是什么样子，工作人员怎样完成业务，而现在的描述应该变成计算机怎样做， 工作人员怎样操作计算机。
我们选取上面的“DEMO课排课”，“记录跟进信息”，“邀约家长试听DEMO课”作为例子，来讲解如何描述系统用例。
话不多说直接上图：
邀约家长试听DEMO课用例场景：
到了这一步我们的系统建模也就基本完成了，接下来只需要拿着这些系统用例场景图开始画原型就可以了
这里要注意：
业务用例场景图就是我们经常在说的业务流程图，系统用例场景图就是我们说的功能/任务流程图，业务用例场景图是用来描述业务的，系统用例场景图是用来描述这个功能如何满足用户需求的，所以业务流程图一定是不会包含计算机这个泳道的，而系统用例场景图一定要包含计算机这个泳道。
六、结尾
到这里我们的整个建模方法论也就讲完了，不知道大家现在对下面这些问题是否有一个比较清晰的答案了
为什么说做B端产品对于业务的理解非常重要？
B端产品的功能是如何从业务出发一步一步推导出来的？
业务流程图，任务/功能流程图到底有什么区别？
再问大家一个问题：
产品经理和交互设计师的工作界限在哪里，哪些工作是产品经理做的，哪些工作是交互设计师做的？
说下我的理解哈，其实产品经理只要把系统用例场景或者说/功能任务流程图做出来，再把每个页面必须要包含的信息给出来，接下来至于长什么样就可以交给交互设计师发挥了。
如果有在深圳工作的产品小伙伴或者平时喜欢看书，学习和交流的小伙伴们可以加我微信哦~
