这次我主要阅读了这本书的第九十章，通过看这章的知识了解了不少的知识开发某系统的重要前提是：这个系统有谁在用？这些人通过这个系统能做什么事？
一般搞清楚这件事，再画个业务流程图，就能条例清楚的表达系统的需求了。作为一个开发人员，不仅要懂得如何从用户那里获取有用的信息，还要懂得怎么清晰地描述自己的想法，给客户呈现出一个结构完整、功能全面的系统原型。那么，这些必备的画图技巧，就会帮上很大的忙。
用例图是用处非常广泛，使用频率最高的UML图，它用来描述什么角色通过某某系统能做什么事情，关注的是系统的外在表现、系统与人之间的交互、系统与其他系统之间的交互。
在一个实际项目中，可能会包含上百个用例，组织这些用例时可以使用高度概括的语言先画一个宏观的用例图，再将其分层次地分解为多个具体的用例图，必要时，还可以使用包图对众多用例图进行分类，帮助理解整个系统需求。
给用户描述系统原型时，在其能理解的基础上，可以使用精简的用例图。用客户能够听懂的语言（不应该处于开发人员的角度来描述），有侧重性地进行详述。当客户提出问题与需求时，我们需要立于客户的想法，又要高于客户的想法，不能盲目地从客户想法中导出用例，应该更多的从系统的目标、待解决的客户问题上寻找解决方案。
当然，用例图不是万能的，也不是表达需求的唯一方式。学会掌握用例图所承载的需求分析方法，能够灵活的运用才是关键。
上文提到的包图，就是一个容器，能够容纳各种UML图（包括包图自己），旨在将散乱的东西组织起来，由粗到细的解决问题，但如果已经是项目组的成员，并参加了整个需求调研过程，就没必要拐弯抹角，放弃包图了，减少不必要的阅读过程。
实际工作中，包图的使用频率比较低，但在软件设计、软件架构设计中会经常使用。
执行者的范围可以从系统的项目相关人员，用例的主执行者，被设计系统本身，用例的辅助执行者，内部执行者，在例子中公司没有注意系统的项目相关人员，导致系统没有提供完全的服务修改请求蜂拥而至。朱执行者是直接触发用例的执行者组织人或者是和该组织有关系的人，通过这些来描述用户主要场景，与我自己认知不同的是我认为用例必须用用例图来表示，不过语言文本的表示也是挺清晰的，一个编写良好的用例应该具有可读性，无论是业务人员还是软硬件开发人员还是设计人员都可以通过用例来描述需求，关接下来范围是指真正被讨论的系统是什么，主执行者谁有药实现的需求，层次指目标的高低，主成功场景一切都成功的情况下，在第一个一个人准备通过万维网购买股票的情况中这个用例应该是一次处理就能完成的目标处于用户级的目标而第二个则不能从一次中完成，需要多不的处理显然处于概要的目标。
