上下文圖是一個簡單的分析模型，顯示了新的系統是如何適合其環境，它定義了所開發的系統和系統外部實體（如使用人員、硬件設備和其它信息系統）之間的邊界和接口。”我感覺上下文圖就是為了划定你要做的系統的邊界，以及顯示系統和其他系統或者人員、設備等等的交互情況，這是在一開始做需求時使用的。
首先，用例角色需要被清晰地定義，以便為我們理解系統交互提供幫助。
然后，在上下文關系圖中擺放基礎元素，並捕獲它們之間的關系。使用最初的Booch標記法，系統和參與者都可以使用雲圖來表示。
在雲之間的連線用來表示關系；而箭頭標識參與者與系統之間的重要信息。正如，當客戶請求系統提供信息以便簽約，系統將返回確認信息，例如賬號。當客戶啟動一個任務，系統則返回一個確認號。
同樣的，銷售人員和行政人員也可以與一個新客戶簽約，然后系統會提示所需的信息並返回一個新帳號。當老板需要相關使用報表時，系統應返回正確的報表。
在這張圖中有大量的詳細信息沒有體現出來，但已經建立了參與者和系統之間的本質關系。最重要的是區分出什么是系統內的，顯示出哪些參與者與系統交互。
注意我們捕獲的信息是相同的，但UML標識法更容易區分對象（矩形）和參與者（小棒人）。不過放棄“雲”形標記讓我很傷心——用Rectangle to Code做書名就不夠吸引人了——但其他方面我都認為新的標記符更好。只不過，矩形要更加容易繪制。一般情況下使用UML標識法，除非是那些應用Booch或OMT標識法更好的情況，這種情況我們可以同時用兩種方式繪制。
以上是在網上復制的關於上下文圖的介紹，而經過上午的課程，我意識到上下文圖的優點：1、通俗易懂，我們在拿到一個上下文圖的時候很容易就能看出這個系統需要什么，經過這個系統之后我們能得到什么；2、邊界清晰，上下文圖很好的說明了系統的邊界，那些實體參與了系統，給系統提供什么東西，接受了系統反饋的什么信息一目了然。
所以上下文圖在軟件需求分析的作用非常之大，我覺得上下文圖雖然功能很強大而且很容易理解，但是它在學習這一方面卻是不算復雜的，所以學習好上下文圖，真正理解了它的作用與含義，能靈活的將它用於以后的學習之中是非常關鍵的，我一定會努力學好上下文圖。