读《UML大战需求分析》有感04
开发某系统的重要前提是：
这个系统有谁在用？
这些人通过这个系统能做什么事？
一般搞清楚这件事，再画个业务流程图，就能条例清楚的表达系统的需求了。作为一个开发人员，不仅要懂得如何从用户那里获取有用的信息，还要懂得怎么清晰地描述自己的想法，给客户呈现出一个结构完整、功能全面的系统原型。那么，这些必备的画图技巧，就会帮上很大的忙。
用例图是用处非常广泛，使用频率最高的UML图，它用来描述什么角色通过某某系统能做什么事情，关注的是系统的外在表现、系统与人之间的交互、系统与其他系统之间的交互。
在一个实际项目中，可能会包含上百个用例，组织这些用例时可以使用高度概括的语言先画一个宏观的用例图，再将其分层次地分解为多个具体的用例图，必要时，还可以使用包图对众多用例图进行分类，帮助理解整个系统需求。
给用户描述系统原型时，在其能理解的基础上，可以使用精简的用例图。用客户能够听懂的语言（不应该处于开发人员的角度来描述），有侧重性地进行详述。当客户提出问题与需求时，我们需要立于客户的想法，又要高于客户的想法，不能盲目地从客户想法中导出用例，应该更多的从系统的目标、待解决的客户问题上寻找解决方案。
当然，用例图不是万能的，也不是表达需求的唯一方式。学会掌握用例图所承载的需求分析方法，能够灵活的运用才是关键。
上文提到的包图，就是一个容器，能够容纳各种UML图（包括包图自己），旨在将散乱的东西组织起来，由粗到细的解决问题，但如果已经是项目组的成员，并参加了整个需求调研过程，就没必要拐弯抹角，放弃包图了，减少不必要的阅读过程。
实际工作中，包图的使用频率比较低，但在软件设计、软件架构设计中会经常使用。