上下文图是一个简单的分析模型，显示了新的系统是如何适合其环境，它定义了所开发的系统和系统外部实体（如使用人员、硬件设备和其它信息系统）之间的边界和接口。”我感觉上下文图就是为了划定你要做的系统的边界，以及显示系统和其他系统或者人员、设备等等的交互情况，这是在一开始做需求时使用的。
首先，用例角色需要被清晰地定义，以便为我们理解系统交互提供帮助。
然后，在上下文关系图中摆放基础元素，并捕获它们之间的关系。使用最初的Booch标记法，系统和参与者都可以使用云图来表示。
在云之间的连线用来表示关系；而箭头标识参与者与系统之间的重要信息。正如，当客户请求系统提供信息以便签约，系统将返回确认信息，例如账号。当客户启动一个任务，系统则返回一个确认号。
同样的，销售人员和行政人员也可以与一个新客户签约，然后系统会提示所需的信息并返回一个新帐号。当老板需要相关使用报表时，系统应返回正确的报表。
在这张图中有大量的详细信息没有体现出来，但已经建立了参与者和系统之间的本质关系。最重要的是区分出什么是系统内的，显示出哪些参与者与系统交互。
注意我们捕获的信息是相同的，但UML标识法更容易区分对象（矩形）和参与者（小棒人）。不过放弃“云”形标记让我很伤心——用Rectangle to Code做书名就不够吸引人了——但其他方面我都认为新的标记符更好。只不过，矩形要更加容易绘制。一般情况下使用UML标识法，除非是那些应用Booch或OMT标识法更好的情况，这种情况我们可以同时用两种方式绘制。
以上是在网上复制的关于上下文图的介绍，而经过上午的课程，我意识到上下文图的优点：1、通俗易懂，我们在拿到一个上下文图的时候很容易就能看出这个系统需要什么，经过这个系统之后我们能得到什么；2、边界清晰，上下文图很好的说明了系统的边界，那些实体参与了系统，给系统提供什么东西，接受了系统反馈的什么信息一目了然。
所以上下文图在软件需求分析的作用非常之大，我觉得上下文图虽然功能很强大而且很容易理解，但是它在学习这一方面却是不算复杂的，所以学习好上下文图，真正理解了它的作用与含义，能灵活的将它用于以后的学习之中是非常关键的，我一定会努力学好上下文图。