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