UML之用例图（借助哲学家就餐问题来简单的实现建模流程）
声明：本用例图的构建采用哲学家就餐问题中的服务生方法，即哲学家欲想吃饭，需委托服务生为其代劳。
预先准备：正所谓：“工欲善其事必先利其器”
绘制UML的必备工具如下：（任选其一即可）
1，最简单的 在线绘制UML图 ProcessOn 网址：www.processon.com
2，Visio 非常全面，比较杂，支持各种图，我记得大一下学期的时候，交C语言大作业——一个简单的学生管理系统。当时的代课老师就是用的Visio让我们画图，挺好的老师，好像就是从那个时候和我前女友稍微认识的，啊，一晃都过去六七个月了，我都大二了。
3，Rational Rose 最开始便是为UML而生 后来加入对数据库的建模支持 和PowerDesign刚好相反。
4，PowerDesign 对数据库的支持比较好。
建议初学者（我就是其中一个）用第一个在线网站 比较方便 用着也很舒服，我觉得做产品也应该是这样，让人舒服的东西才叫好东西，不是简简单单的满足了我的需求，PonyMa之所以可以很成功的创建 腾讯，在很大程度上他是以产品经理的角度上去思考问题的：“Don’t make me think”,便是他的观念之一。
导言：
关于UML,我最近主要在看两本书，
一本是偏向实战《大象 Thinking in UML》，这本书是以实战的方式来讲述如何去在是实际业务中去充分利用UML。
另一本是UML发明者之一的Michael Blaha的《Object-Oriented Modeling and Design with UML》即《UML 面向对象建模与设
类建模及高级类建模，类模型表示系统静止的，结构化的“数据”层面，
类图，描述了系统内部对象及其关系的静态结构。
状态建模及高级状态建模，状态模型则是表示系统时序的，行为的控制层面，
状态图，描述对象随着时间发生变化的哪些方面
交互建模及高级交互建模，表示各个对象的协作，是系统的交流。
用例图，关注系统的功能，强调系统为用户做了什么事情。
顺序图，显示交互的对象以及发生交互的时间顺序。
活动图，描述重要的处理步骤。
仔细想想，其实就能看出来个端倪，以面向对象的角度来看的话，类模型就是创建一个类，表明我创造出来一个我准备用的东西
状态模型就是，在不同的时间顺序下，我的这个东西要去做些什么事，交互模型就是，我的这个东西去和别的东西去发生交流沟通，数据传输和控制。
我到现在觉得面向对象，实际上就是看待世界上的东西只有我本身和无数个不同的“你”打交道。只需要这三个模型便可以概述出几乎所有的事情。
大致介绍就到这里把，扯得有点多。
用例图 ——正式开始！
用例图是描述系统如何与外部参与者交互的图。他从用户角度描述系统的静态使用情况，用于建立需求模型。
通过上面的话，其实用例图的中心其实已经就凸显出来了，外部参与者+系统——>（交互) = 用例图
用例图的元素 参与者（Actor），用例（Use Case）, 关系（Relationship），边界（Boundary）。
第一弹：参与者
- 参与者可以是人或其他外界系统。参与者只是一个角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。只要你承担了参与者的人物，做到了参与者应该做的事情，那么不论是什么，都可以叫做参与者。
- 参与者是用例的启动者，参与者驱动用例进行，因为参与者的驱动，系统才会开始工作，系统因而才有了存在的意义，但参与者本身并不是系统的一部分。我记得小时候的拖拉机（大型卡丁车）的启动就是用一根大铁棍去启动的，拖拉机动起来是因为人想拖拉机了，但人不是拖拉机的一部分。
- 参与者可以参与多个用例，我们可以假想参与者是一个人，那么他不仅可以去银行存钱，也可以去超市买东西，对吧。
参与者长得就是这个样子，一个火柴人~
可是光知道笼统的概念是不够的，如何才能去发现我们所做项目的参与者呢？这个才是关键部分。
于是有引出了一个不在用例图元素之内却很关键的一个东西——涉众
涉众（Stakeholder）涉众是与要建设业务系统相关的一切人和事，参与者是涉众的代表，他代表着涉众对系统的利益需求，系统是以参与者的观点来建立的，因为参与者有这样的需求便有了这样的一个系统，比如哲学家就餐问题中的涉众，无非两个，哲学家，和服务生。我对此琢磨了好久究竟要选谁作为参与者比较合适，最终我选择了服务生，为什么呢？我一直在想这里的主角是哲学家还是服务生，
如果是服务生，那么明明是哲学家发出的请求，不应该是哲学家作为参与者吗？
如果是哲学家，可是服务生在该系统中承担着沟通交流的人物？
在不断的纠结之下，我选择了服务生作为参与者，因为就问题的最本质而言，无非是对系统发出资源的请求，如果采用逆向思维的画，我们会发现服务生在此刻是离系统最近的，其次才是哲学家，也就是说，一定是服务生与操作系统建立起资源请求的联系，然后服务生和操作系统构成的整体在作为一个系统和哲学家产生联系，这是一个嵌套的关系。对此我用一个用例描述就很清晰了。
第二弹——用例
用例是系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能。
参与者与系统的各种交互均可被量化成用例。其实用例就是由于参与者的存在而引发出来的事件，有多少事件就有多少用例。
椭圆里面便是用例事件。
第三弹——关系（该图片来自百度）
关联(Association)表示参与者与用例之间的通信，任何一方都可发送或接受消息。【箭头指向】：指向消息接收方
泛化(Inheritance)就是继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。
包含(Include)把一个较复杂用例所表示的功能分解成较小的步骤。
扩展(Extend)扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
对于关联关系是最基础的关系，用于通信，一般来说只要不涉及其他的关系，关联关系应用是最多的，
泛化关系的英语单词就是继承的意思，父类和子类的关系，比如喝东西这个用例 可以包括 喝水，喝咖啡，喝茶。由于我的观点所处理的哲学家就餐问题中没有体现到该关系，于是我用了喝东西这个事件来解释。
。
包含关系:是为了解决复杂化的问题，将一个复杂的用例弄得简单就是该关系存在的意义。比如上上图中的叉子检测问题，就比较复杂，它包含了两个小的用例，一个是叉子数目满足需求，另一个是叉子数目不满足需求。此时便要用到包含关系，来简单化该用例。
扩展关系在我看来是属于平级的关系，附加补充的他的职责，比如当服务生给与叉子或否时，接下来还要做些什么事情。
前面已经说了，这个问题在我看来有嵌套的成分，所以以上的系统应该叫做服务生管理系统，然后用该系统作为一个用例，和哲学家一起构造出哲学家就餐问题系统。其实这里就延伸出另外一个问题，当初纠结于谁作为参与者的时候其实就是因为边界的定位不够清晰，“界”在哪里，这是个极其抽象模糊的概念，最终我从问题的最里最本质的角度反向思考，就像圆一样，我不清楚我所在的位置，那我就去找圆心，通过圆心去找这个圆心有几个同心圆，谁离得最近，发现是服务生，然后是哲学家，如此一来，边界便一清二楚。整个问题也就简单了。
思考：其实这个问题并不难，我觉得学长的意思是想拿哲学家就餐问题来让我练练手，一边学习操作系统的知识，一边学习下架构的思想，一举两得，站在一定的高度上去看待问题对以后的成长之路还是很有帮助的。可能哲学家就餐问题确实不是一个比较好的uml问题，但是重点并不在这里，当我们对一个问题去思考的时候，便会把我们的所学所得和缺少遗漏的东西去补全，而且，世界上哪有十全十美，恰好合适的东西，以后用户提需求的时候，也不一定会完整的把需求列举出来，还是要自己去补充，思考，提升学习能力，这个也是我在看的另一本书（另一篇帖子《程序员的九堂课》）所理解到的，这个才是重点，就是这样啦~
以上便是我用模型观点来看待的哲学家就餐问题的思路，如有不同意见，欢迎讨论。国庆第二天，还没玩够，写个帖子没想到要花这么久，打会游戏，放松放松~
享受美好的假期生活。
思念我的女朋友，前女友。看她朋友圈发的旅游的动态，我很不舒服，想打人...
2018.10.02.17：48