问题描述
解决方案
解决方案二：
我觉得这三张图的含义一目了然楼主你要我怎么给你解释？
解决方案三：
第一个叫做用例图，它基本上跟你见过的“功能菜单”差不多，是功能列表。标题党就是从这里出去的。第二个，它自己标题说是状态图。活动图的典型特种就是没有循环，它的重点在于状态的迁移。你看两次“进水”动作，实际上分别出现在两个不同的状态下，因此就不是循环操作。实际上状态图应该表示出来系统关键的状态，例如第一次进水时，洗衣粉还没有用过、衣服是脏的；第二次进水时，衣服是半干净的，洗衣粉已经用了80%了......可见不同的“进水”动作时，状态不同。第三个，是活动图。因此它就有循环，它的重点在于活动的迁移。传统的流程图其实不适合描写复杂的业务，因此用“活动图+状态图”这个维度，立体地刻画流程图的细节。但是这里的状态图其实不是很正确。状态图是说明了“事件-->状态-->事件-->状态”这样的链条。而这里把它弄得很简单、很俗，跟活动图很类似了。比如说“漂洗”的前提状态是“衣物已经半干净了，并且洗衣机里的水是清水”，据此才能推论出“漂洗”是最快也得放到第二次“上水”之后的操作。那么这个图就只有活动，而没有把状态表达清楚。状态图是大多数人的“软肋”。一般初学者只会画第一个“用例图”，因为这个跟标题党如出一辙。稍微用点心的人，可以画出“活动图”，因为这跟市场调查比较接近。而“状态图”是最难画好的，因为这体现着设计人员的逻辑推理能力。在这些动态图之前，实际上设计者还应该画出“类型关联图”，其中对于接口、继承、多态等概念都有运用，以便说明一个系统在不断地“抽象、一般化、扩展”中是一个什么扩展走势。这些动态图还不够，实际上设计者还应该给出一些算法描述。最后，软件设计既不是自底向上地堆砌，也不是自顶向下地功能分解。在早期（30年前）结构化编程方式强调的是功能分解、概念分解的思路。现在有一些工作了10几年、20年的老程序员，还是只会这一招，而不会现代的软件设计方法。
解决方案四：
活动图的典型特种就是没有循环-->状态图的典型特种就是没有循环状态图其实跟基于规则自我推理的人工智能规划系统差不多，是最复杂最完备的。
解决方案五：
在表示一些通讯相关的简单“应用接入系统”服务设计时，基本上都使用“时序图”。在一些大企业中表示类似的跨部门的业务流程，用其变种——“泳道图”。基本上，有那么7、8套不同角度、不同目的的设计图，每一种中使用UML规定符号中五分之一不到的基本符号，就可以把设计说清楚了。