本帖最后由 xdwangxf 于 2014-8-28 20:14 编辑
【上期简单回顾】
上期对建模和建模过程做了简要的分析和描述，是启动建模前的铺垫。
【本期重点】本期重点内容是实现从“现实世界-->业务模型”的过程。 【本期内容】 从现实世界到业务模型，就是根据产品的业务目标，建立业务模型。主要包括以下的工作： 1. 发现业务主角、定义系统边界； 2. 获取业务用例； 3. 业务建模、领域建模、提炼业务规则； 4. 获取整理非功能性需求。
【正文】 在发现业务主角和定义边界之前，大家有以下三个方面需要先交代一下。 （1） 现在属于系统分析和设计的初期，关注业务主角，更有利于发现最主要和最关键的用例。 （2） 其次，一部分设计人员（包括我自己在内），受模块化设计的影响，容易犯的一个错误就是首先划分模块或者是子系统，然后以划分的模块或者子系统为边界，来确定用例和用户。这样的划分不是说没有道理，但是这样的设计方式，子系统可以这样划分、也可以那样划分子系统，而且没有明显的区别。 （3） 再次，在连载四的如何建模中讲到的面向对象设计方法和面向过程的设计方法的结合。在大颗粒度的设计中，主要采用面向对象的设计和分析方法。在细颗粒度的设计中，以面向过程的设计方法为主。
这里，首先给出一个简单的例子，用以说明涉众、参与者、用户和业务主角，以及划分边界的基本思路。然后 再具体到大家协议栈的设计上。
电视机作为20世纪最伟大的发明之一，可以说对人们的生活影响深远。那么，试想抛开大家现在对电视机的所有感性的认识， 大家需要发明设计一个“怎样设计一个新颖的收音机、使它能够把移动的画面与声音一起传送”，就像当年14岁的法恩斯-沃斯 面临的难题一样。
就像图1-1的描述，大家对“电视机”还没有一个感性的认识，需要大家从头开始定义和设计“电视机”，那么你 知道“电视机”的边界和相关的涉众吗？这个问题留给大家来思考。
涉众：是和要设计的系统相关的一切人和事物； 参与者：参与者是涉众的子集，位于系统边界之外，对系统有明确的目标诉求并且主动发出动作的人和事物，系统 为参与者服务。参与者是UML建模的核心； 用户：是参与者的一个子集，和系统交互，但是不一定局限于业务交互。 业务主角：是参与者的子集，特别用于定义业务的参与者。业务主角对系统有明确的业务需求。
对于以上的分析，可能对用户和业务主角，不容易分的清楚。比如以“看影片”为例，观众毫无疑问属于业务主角，放映员（针对人工放映），属于业务工人，也是用户。 好，让大家回到终端App协议栈上来，来分析这个系统的业务主角和边界。
需要回过头来参考连载三的 表1.2 业务目标整理结果。分析结果见表1-1。 表1.1 业务主角和重要业务分析
对表1.1的补充说明： （1） 首先要说明，经过现在分析，能够发现前面的业务目标的挖掘和整理存在不合理的地方的。可以在这里给予修正。 （2） 移动终端上面有各种各样丰富的应用APP，提供各种便利的业务，用户的很多操作是通过这些应用APP（这些应用APP是相关业务的业务工人）来启动的。针对App协议栈，属于数据业务。所以涵盖在序号8和9的业务中。 （3） 从这个表的分析来看，是不是比较简洁。真实的手机中还有其他的业务类型，比如WIFI、蓝牙控制相关的，大家没有列出来，因为LTE的App协议栈不涉及到这些。而且这里列的是重点的业务。 大家发现的业务主角如图1-3。
根据表1.1的分析，大家容易确定边界如图1-4。
2. 获取业务用例 (1) 用例的概况 “ Use Case（用例）是一个 UML中非常重要的概念，在使用 UML的整个App开发过程中， UseCase处于一个中心地位。用例是对一组动作序列的抽象描述，系统实行这些动作序列，产生相应的结果。这些结果要么反馈给参与者，要么作为其他用例的参数。” “用例（ 英语： use case），或译使用案例、用况，是 App工程或 系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。” “用例定义了一组用例实例，其中每个实例都是系统所实行的一系列操作，这些操作生成特定的主角可以观测的值。” 《大象-Thinking in UML》 一个完整的用例，包括参与者、前置条件、场景和后置条件。后置条件可以理解为用例实行的结果。 这里提出一个问题：为什么说用例如此重要？这个大家从《统一App开发过程》中可以找到答案。 统一过程的特点是用况驱动、以构架为中心、迭代和增量的过程。图1-5很好的说明了为什么用例在App开发过程中，处于很重要的地位。
这个图，希翼大家用心揣摩，并能够在工作中实践，再揣摩、再实践。
（2）用例描述 在不同的阶段，用例有不同的颗粒度。在业务分析和业务建模阶段，用例的粒度以能够描述一个完整的业务流程；在概念建模阶段（用例分析阶段），用例描述一个完整的业务流程中的一个步骤；而在系统建模阶段（也就是设计模型阶段），因为要关联到如何实现，需要和嵌入式系统、硬件单板、计算机以及邻接子系统等关联，因此用例的粒度描述和邻接子系统的一个完整的交互。当然，粒度的划分方法没有一个统一的标准。 大家得到的用例如图1-6和图1-7。
下面这段话写的很好，在这里摘录下来，和大家分享： “要建立一个高质量的App系统，也要从建立准确、清晰、高效和强壮的业务模型开始。“法治”强于“人治”，依据模型进行App系统的建设，无论如何都要比凭经验拍脑袋强”。摘自《大象-Thinking in UML》
本来想在这个讲解中，将业务建模、领域建模、提炼业务规则和获取非功能性需求也讲解完，不过篇幅会有些过长。
争取在下一个连载中，将业务建模的后续内容讲解完，然后做一个小结。
这个连载写的时间有点长，一方面因为工作和私人的事情，最近比较多，另一个方面，因为自己也是在不断的反思和整理。
如果有好的意见和建议，请大家积极回复，相信在大家的帮助下，这个连载能够写的更好。沟通和互动很重要。
谢谢！
| 
发表于 2014-8-28 19:53:56
