一、UML活动图和用例图
——我一直不太信任自己的记忆力，所以我把它们都写下来
在小公司里各种因素的限制，导致工程师根本无法在工作中接触到科学的软件设计方式。每次新项目开工的时候都是老板把大家召集在一起告诉大家这个项目是给谁做的，干啥的，大小如何；再说一些大体的业务。然后孩子们在模棱两可中根据项目的大小选择个框架然后开工，码代的过程中遇到问题就去问老板，有时候老板突然一拍脑门告诉我们有一些东西忘记了，大家改改。。fuck。。。有时候做到一半的时候发现里面存在很多问题，导致跟下游的业务完全无法对接……真的是受够这种工作方式了，效率低就不说了，主要是太打击程序猿的信心了。
刚毕业那会儿就听过UML（统一建模语言），知道这个东东是软件开发初期设计用的，然后就没有下文了，疯狂的投入到码代事业中。但是今年尤其是最近又有新项目，还是跟以前一样的拍脑门绝对软件怎么弄的时候我实在是受够了，决定必须找到一套行之有效的方法，让大家能完整的了解软件项目的需求。其实不管什么活动图、用例图、时序图、类图……都是为了让软件人员能完整的全方位的了解项目的需求，做出客户期望的软件产品，并且有利于后期维护。
上面红字部分才是我们学习UML的目的，就像软件设计师用例驱动一样，在项目开始之前我们就应该明确我们的目的。下面先看 活动图 和 用例图。UML工具软件常用的visio、Rose等，MAC用Omnigraffle。下面的实例都是在Omnigraffle中设计的。
活动图：阐明了业务用例实现的工作流程（强烈建议活动图用泳道方式分隔开，每个泳道可以是用户或者部门）
下面是医药企业进货业务的活动图，左边是普通的活动图，右边加了泳道。我想是否使用泳道表示的原因一目了然
活动图在上面时候使用呢？
1）项目开始阶段，确定业务需求时通过活动图与客户设计业务流程。
2）企业管理成也可以根据活动图修改现有的流程。
3）集成测试阶段根据活动图明确测试的结果。
活动图要点？
活动图关注的业务的流程完整性，而不是业务的具体实现。
活动图制作过程中不要关注数据。
用例图：用例图也是在项目需求前期确定阶段常用的分析方式，它是站在用户的角度，研究的是用户的目的，必须立足于用户的“期望”，而不是以我们自己单纯的意愿决定用户的操作。
同样还是上面的业务，用例图表现如下
用例图和活动图都是在需求确定阶段研究业务流程和业务关系的，所以也有很多相似的地方。