實用文檔《軟件工程》實驗指導書計算機學院2017年2月實用文檔軟件工程實驗指導前 言軟件工程實驗是為計算機相關專業本科《軟件工程》課程配套設置的，是《軟件工程》課程講授中一個重要的、 不可或缺的實踐環節。其目的是使學生能夠針對具體軟件工程項目，全面掌握軟件工程管理、 軟件需求分析、 軟件初步設計、軟件詳細設計、軟件測試等階段的方法和技術，通過該課程設計使學生進一步理解和掌握軟件開發模型、 軟件生命周期、軟件過程等理論在軟件項目開發過程中的意義和作用， 培養學生按照軟件工程的原理、 方法、技術、標準和規范，進行軟件開發的能力， 培養學生的合作意識和團隊精神， 培養學生對技術文檔的編寫能力，從而使學生提高軟件工程的綜合能力，提高軟件項目的管理能力。按該課程的特點， 實驗內容包括軟件開發的兩大方法學的專題訓練， 即結構化（生命周期學）的方法學和面向對象的方法學， 通過對一個簡單項目， 要求學生利用結構化軟件開發技術或面向對象的軟件開發技術完成對該項目的開發。 因此設置五個實驗項目， 從項目發的準備工作，系統分析過程，系統設計過程，軟件測試到系統實施， 覆蓋軟件開發的整個過程，此外又引入我國國家《計算機開發規范》，以規范技術文檔的書寫標準， 提高實驗教學質量。通過實驗訓練，達到如下目的：使學生進一步了解和掌握軟件工程原理， 提高對實際項目的分析和設計能力， 通過實驗課程，熟悉和基本掌握軟件工程方法學、 軟件開發的過程，文檔資料的編寫格式及規范，全面領會和貫通所學習的理論知識， 從而培養學生綜合運用所學課程知識， 分析解決問題的能力，培養學生理論聯系實際作風，實事求是， 嚴肅認真的科學態度和良好的工作作風， 為今后從事科學研究工作打下基礎。實驗要求軟件工程實驗具體要求如下：每個項目小組必須按照 《軟件工程實驗指導書》 附錄中給定的文檔規范標準提供項目文檔；題目自定或采用附錄二中的題目；軟件開發的方法自定（結構化或面向對象的方法學） 。實用文檔實驗一 用Visio 進行功能分析和建模實驗目的掌握結構化分析的方法。掌握使用Visio2003 軟件繪制數據流圖、狀態轉換圖的一般方法和技巧。實驗環境軟件平臺:MicrosoftWindowsXP ，軟件工具： MicrisoftVisio2003 。實驗原理結構化分析方法以數據字典為核心，采用實體關系圖、數據流圖和狀態轉換圖等圖形來表達需求，直觀明了且易于理解和掌握。數據流圖作為功能建模的基礎，描述數據怎樣轉換以及轉換的功能，狀態轉換圖作為行為建模的基礎，表示系統的各種行為狀態以及狀態間的轉換方式。實驗內容與要求繪制學生成績管理系統（案例如下）的數據流圖及狀態轉換圖。撰寫實驗報告案例

1某校準備開發一個學生成績管理系統。 在該系統中，教務人員錄入學生信息、和成績信息，學生可以隨時查詢自己所選課程的成績。 由于學生成績屬于敏感信息，須提供必要的安全措施以防非法存取。用Visio 操作

課程信息系統必實驗步驟及相關詳細講解：第0層DFD圖教務人員維護學生信息和課程信息，并登錄學生的選課成績；學生查詢自己的成績單。實用文檔*第1層DFD圖對第0層DFD圖中的一個加工 "學生成績管理"進行展開。雙箭頭：直線——右鍵格式——線條，線端的起點終點實用文檔直線用動態連接線*第2層DFD圖對第1層DFD圖中的一個加工 "查詢學生成績"進行展開。實用文檔繪制第0層DFD的時候，將整個系統看成一個加工，然后找出作用于該加工的外部實體，以及相應的數據輸入和輸出。對于"學生成績管理系統"而言，整個系統就是一個加工"學生成績管理"。從用戶的需求描述可知，"教務人員"是數據的源點，"學生"是數據的終點。另外，教務人員需要錄入學生信息、課程信息和成績，說明"學生信息"、"課程信息"和"成績"是數據流；同樣，"查詢請求"和"查詢結果"也是數據流。根據上述分析，得到如圖所示的第 0層DFD。繪制下一層數據流圖時， 細化第0層的加工"學生成績管理"，從而描述系統的主要功能。 從第0層DFD得知，"學生信息"是教務人員需要錄入的一個信息，因此加入一個加 ?quot;錄入學生信息"，同樣得到"錄入課程信息"、"登記成績"兩個加工。另外，數據流"查詢請求"和"查詢結果"應該由加工"查詢成績"來完成。這樣，我們用"錄入學生信息"、"錄入課程信息"、"登記學生成績"和"查詢學生成績"四個加工代替第0層的"學生成績管理"，同時增加這些數據流對應的數據存儲，即"學生"、"課程"和"成績"，最后得到如圖所示的第1層DFD。為了繼續進行分解，我們分析第1層DFD中的加工"查詢學生成績"。學生查詢成績時需要提供合法性檢查，因此，"查詢學生成績"可以分解為"合法性檢查"和"查詢成績"兩個處理步驟，從而形成如圖所示的第2層DFD。根據以上實例和經驗，繪制數據流圖應當遵循以下原則：1）分層時，子圖的輸入、輸出數據流必須和父圖中相應加工的輸入、輸出數據流一致；2）加工的編號應該唯一且具有層次性；3）加工不應該只有輸入或只有輸出，通常既有輸入又有輸出；4）數據流圖不應反映處理的順序；5）加工之間應通過數據存儲進行通信，避免從一個加工直接流到另一個加工；6）數據應通過加工進行流動，避免從一個數據存儲直接流到另一個數據存儲；7）數據流圖中所有元素的命名應當對客戶有意義，且與業務相關；8）不要在一個圖中繪制7個以上的加工，否則難于繪制和理解。通常來說，行為建模用于實時系統。實時系統中可能存在許多腳本，很多實體需要進行狀態劃分和描述狀態轉換圖，有時為了描述系統的并發行為，還需要使用其他一些工具進行描述，如Petri網。在事務系統中，系統行為相對簡單，只有某些行為較復雜的實體才需要建立其狀態轉換圖。1）分析外部事件，所謂外部事件是指外部實體與系統的一次交互。2）分析事件的響應者，該響應者為了響應該事件要進行怎樣的活動，這種活動又會激發哪些事件等，這樣構成了系統行為的腳本。3）根據事件和活動劃分實體的狀態，也可根據其他知識劃分實體狀態，考慮發生怎樣的事件使該實體進入這個狀態，怎樣的事件使該實體從這個狀態轉換到另一狀態等。舉例分析：實用文檔（在數據流程圖中）或 UML圖中在"學生成績管理"系統中，學生成績信息需要采取安全措施，我們可以采取登錄方法避免非法使用系統。這樣，該系統存在 "登錄"、"正常"和"出錯"等狀態的轉換。學生啟動系統之后，系統處于 "登錄"狀態。在這種狀態下，學生可以進行登錄或取消登錄。如果取消登錄，系統直接退出；如果登錄失敗，系統進入"出錯處理"狀態，在顯示錯誤信息后，又重新回到"登錄"狀態；如果登錄成功，系統進入"正常"狀態，即顯示操作界面，等待學生查詢，學生可以多次查詢不同課程的成績，直到學生選擇退出為止。實用文檔實驗二用例模型設計1.實驗目的學會IBMRationalRoseEnterpriseEdition的基本操作。掌握使用Rose進行用例建模。2.實驗環境軟件平臺:Microsoft WindowsXP，軟件工具：IBMRational RoseEnterprise Edition 。實驗原理使用用例方法來描述系統功能需求的過程，就是用例建模，它是實現"功能模型"建模的主要手段之一。用例模型主要包括以下兩部分內容。⑴用例圖(UseCaseDiagram)確定系統中所包含的參與者、用例和兩者之間或其自身的關系，用例圖是基于系統要實現的功能的一個可視化描述。①參與者(Actor)②用例(UseCase)用例是用來描述參與者使用系統，以達到某個目標時所涉及到的一系列的場景的集合。一個用例的核心并不是上述的圖標， 而是一個規格化的敘述型文檔， 它描述了參與者要實現某項功能的事件流程，展示和體現了其所描述的過程中的需求情況。用例名稱一般以“做什么”即“動賓詞組”形式來命名。③用例和參與者及自身的關系泛化關系(generalization)包含關系(include)擴展關系(extend)⑵用例規約(UseCaseSpecification)所謂規約，就是業務規則的規格說明。針對每一個用例，都應該有一個用例規約文檔與之相對應，以描述該用戶的細節內容。每一個用例的用例規約，都應該包含以下內容：①用例名稱(UseCaseName)：用例的名稱一般由 "動詞+名詞"構成，簡單說明"做什么"。②簡要說明(BriefDescription) ：簡要介紹該用例的作用和目的。③前置條件(PreviousCondition) ：系統在執行該用例前必須處在的狀態。④事件流(FlowofEvent)⑤用例場景(UseCaseScenario) ：包括成功場景和失敗場景，場景主要由基本流和備選流組合而成。⑥特殊需求(SpecialRequirement) ：描述與該用例相關的非功能性需求 (性能、可靠性、可用性和可擴展性等 )以及涉及約束(所使用的操作系統、開發工具等 )。⑦后置條件(PostCondition) ：系統在執行完該用例之后應該處在的狀態 。實驗步驟1）找出系統邊界以外的角色（actor），角色是與系統進行交互的外部實體，可以是與系統交互的人員、與系統相連并交換信息的設備和其他系統；（2）從這些角色如何與系統進行交互的角度，使用用例（ usecase）來描述角色怎樣使用系統以及系統向角色提供什么功能，用例所表示的是從外部用戶角度觀察的系統功能；3）繪制用例圖，并編寫詳細的用例描述。用例圖只能宏觀地描述系統的功能，但卻不能提供用例模型所必需的所有信息，每個功能的含義和具體實現步驟則以文本方式描述。實驗內容與要求繪制用例圖，詳見教材 P95(4.7)。實用文檔撰寫實驗報告實用文檔實驗三 用例規約及活動圖一、實驗目的熟悉活動圖的基本功能和使用方法。掌握用例規約的撰寫。掌握如何使用建模工具繪制活動圖方法。二、實驗器材計算機一臺。2.RationalRose 工具軟件。三、實驗原理1. 用例規約描述用例單純使用用例圖不能提供用例所具有的全部信息， 因此，需要使用文字描述那些不能反映在圖形上的信息。用例描述實際上是關于角色與系統如何交互的規格說明， 要求清晰明確，沒有二義性。描述用例時，應該只注重外部能力，不涉及內部細節。每一個用例的用例規約，都應該包含以下內容：①用例名稱：用例的名稱一般由 "動詞+名詞"構成，簡單說明 "做什么"。②簡要說明：簡要介紹該用例的作用和目的。③前置條件：系統在執行該用例前必須處在的狀態。④事件流：基本流和備選流。⑤特殊需求(Special Requirement)：描述與該用例相關的非功能性需求 (性能、可靠性、可用性和可擴展性等 )以及涉及約束 (所使用的操作系統、開發工具等 )。⑥后置條件(PostCondition) ：系統在執行完該用例之后應該處在的狀態 。活動圖描述用例在UML中，活動圖類似于流程圖，它描述了執行某個功能的活動。使用活動圖來描述用例，比用例規約更直觀。組成活動圖的元素：①活動的起點－實心圓②活動的終點－半實心圓③狀態－帶圓端的方框④轉移－帶箭頭的直線⑤分支－菱形⑥泳道－將活動圖的活動狀態分組四、實驗內容圖書管理系統的用例圖如下：實用文檔注冊用戶登錄 管理讀者查詢瀏覽管理圖書資料圖書管理員預訂圖書登記借書普通讀者取消預訂 登記還書圖書管理系統用例圖根據分析設計情況， 可進一步添加或細化。 其中圖書管理員的用例可細化如下 （部分）：刪除讀者<<include>>增加讀者<<include>>修改讀者信息<<include>><<include>>管理讀者<<depend>> 查詢讀者信息登錄圖書管理員圖書管理員用例圖（部分）其中刪除讀者信息一般按照以下步驟進行：管理員在錄入界面，輸入待刪除的讀者的信息；實用文檔“業務邏輯”組件在“數據庫”中查找待刪除的讀者信息；(3)如果不存在，則顯示出錯信息，返回步驟(1)，如果存在則繼續；(4)“業務邏輯”組件判斷“待刪除的讀者”是否可以刪除（如借了書則不能刪）；(5)如果不可以，則顯示出錯信息，返回步驟(8)，如果可以則繼續；在“數據庫”中刪除相關信息；顯示刪除成功信息；結束。編寫“刪除讀者”用例的規約。繪制“刪除讀者”用例的活動圖。五、繪圖步驟在用例圖中，找到“刪除讀者”用例，在該用例上單擊右鍵，在彈出的快捷菜單中選“New”，Rose工具會彈出一個菜單，選“ActivityDiagram”，選中后單擊，便可以新建好一個活動圖，命名為“刪除讀者”。新建好活動圖后，雙擊“刪除讀者”活動圖，然后把在左邊的工具欄內點擊“Swinlane”，在右邊的圖中添加一個泳道，并命名為“圖書管理員接口”。按照此步驟，再添加兩個泳道，并分別命名為“業務邏輯接口”、“數據庫接口”。接著在左邊的工具上選取開始點，并在“圖書管理員接口”的泳道上添加；添加完開始結點后，再來為此活動圖添加活動。參考圖如下：使用工具Swinlane 最后一個圖標實用文檔圖書管理員 接口 業務邏輯接 口 數據庫接口輸入待刪除的讀者的信息確認輸入放棄輸入顯示出錯信息不能刪顯示刪除結果

提交讀者 在數據庫中查找待信息 刪除的讀者信息比較讀者信息顯示出錯信息讀者不存在讀者存在分析是否可以刪除可以刪 刪除相關信息分析刪除結果六、實驗報告要求整理實驗結果。小結實驗心得體會。實用文檔實驗四 類圖一、實驗目的理解類及類間關系的基本概念。掌握如何從需求分析中抽象出類的方法。掌握描繪類間關系的方法。掌握在RationalRose中繪制類及類關系的操作方法。二、實驗器材計算機一臺。2.RationalRose 工具軟件。三、實驗原理類圖是描述類、接口以及它們之間關系的圖，它顯示了系統中各個類的靜態結構，用于對系統的靜態視圖（它用于描述系統的功能需求）建模。發現和定義對象類應以問題域和系統責任為出發點，正確地運用抽象原則，盡可能全面地發現對象的因素，并對其進行檢查和整理，最終得到系統的對象類。我們可以在用例模型的基礎上，通過識別實體類、邊界類和控制類，從而發現和定義系統中的對象類。在這里，實體類表示系統存儲和管理的永久信息，邊界類表示角色與系統之間的交互，控制類表示由系統支持和用戶執行的任務，我們使用UML中的構造型<<entity>>、<<boundary>>和<<control>>分別表示實體類、邊界類和控制類。在找到系統的對象類之后，我們需要分析和認識各類對象之間的關系，從而使對象類構成一個整體的、有機的系統模型。對象與外部的關系有以下幾種：1）對象之間的分類關系，即泛化關系；2）對象之間的組成關系，即聚合關系；3）對象之間的靜態關系，即關聯關系；4）對象之間的動態關系，即依賴關系。四、實驗內容通過前面對圖書館管理系統的需求的初步分析，得出系統的用例圖和相應的活動態圖，初步了解系統的業務處理流程。現在需要對系統進行靜態建模，這就需要利用系統的用例圖，活動圖來尋找和發現類，并分析它們之間的關系。尋找和抽象出書圖書館管理系統中的實體類。對實體類的關系建模。五、實驗步驟分析：通過分析和理解問題域，可以識別出系統的實體類，如讀者基本信息、借書記錄、預訂信息、圖書基本信息、書目等。繪制類的步驟:打開前面初步構建的UML模型文件；(2)打開Rose中的邏輯視圖(LogicalView)，用鼠標右擊“LogicalView”，在彈出來的菜單中選擇“New→Classdiagram”項，創建類圖。雙擊新建的類圖，并點右邊控件集中選中的類的圖標，并用鼠標在圖中分別拖出一個類圖，并命名，如“Title”。接下來的一步為設置類的屬性，在新的類中雙擊該類，在打開屬性面板中，可以看到在實用文檔此可以設置類的屬性和方法等其他的信息。點擊“ Attributes ”這個欄目，此欄目為設置類的屬性的選項。在圖中間的單擊右鍵，可以看到有一個“ Insert ”的選項，選中這個選項。后在出現的對話框中輸入相關信息， 如書本的 ISBN號，在Type這個方框內輸入此屬性的類型值，同時可以看到一欄可以設置此屬性的訪問權限， 一般這些屬性都設置 Private 這個權限。這個類的其他屬性也可以按照以上的做法設置。(5) 設置好類的屬性，現在來設置類的方法 (也是操作 )。雙擊類后在彈出的菜單上選“operations ”這個選項，在圖中的空白地方單擊右鍵，在彈出的菜單中選“ insert ”這個選項，也就只有這個選項可用。 接著輸入方法名， 同時可以設置該方法的返回類型，也可以在“Documentations”的方框內填寫一些相關的方法說明，設置好該方法的訪問權限，類的其他方法也可以按上面來設置好。至此，類的方法和屬性都設置好了。(6)依此繪制其它類。(7)接下來就可以為各個類添加關系了。(8)可右擊工具箱空白處，點“Customize”，添加其它模型元素。類接口依賴單向關聯泛化實現類和關聯的關系雙向關聯六、實驗報告要求整理實驗結果。小結實驗心得體會。實用文檔實驗五交互圖一、實驗目的1.理解順序圖的基本概念。2.理解協作圖的基本概念。3.掌握在RationalRose 中繪制交互圖的操作方法。二、實驗器材1.計算機一臺。2.RationalRose 工具軟件。三、實驗原理時序圖又叫順序圖， 它是強調消息時間順序的交互圖， 描述類與類間相互交換以完成期望行為的消息。時序圖向 UML用戶提供事件流隨時間推移的、 清晰的和可視化的軌跡。 時序圖一般包括如下元素：類角色、生命線、激活期和消息。⑴類角色。代表時序圖中的對象在交互中所扮演的角色，一般代表實際對象。⑵生命線。代表時序圖中的對象在一段時期內的存在。 每個對象底部中心都有一條垂直的虛線，這就是對象的生命線，對象間的消息存在于兩條虛線之間。⑶激活期（控制焦點）。代表時序圖中的對象執行一項操作的時期。每條生命線上窄的矩形代表活動期。⑷消息。消息用于實體間傳遞信息，類角色通過發送和接收消息進行通信。時序圖的組成四、實驗內容通過對圖書管理系統的需求分析， 并從業務對象中抽象出了類， 現在需要對前面所給出的用例進行實現，而用例的實現主要由交互圖來指定和描述系統的動態特性。對“登記借書”用例進行動態建模。五、實驗步驟在Rose軟件的左邊欄目上的LogiclView單擊右鍵，新建一個時序圖。接下來的是添加類，添加方法。在上面做好的類找到可以直接拖拉來圖中。課本165頁實用文檔添加屬性添加方法選擇構造型添加消息，開始是必須是外面的實體向系統發送消，如管理員登錄時向系統發送的消息。先添加對象消息（→），雙擊對象消息（即→），打開如圖對話框，添加或選擇消息（方法）。實用文檔可以按上一步的方法來完成其他的方法。完成了時序圖后，可以按F5鍵便得到“登記借書”的協作圖。六、實驗報告要求整理實驗結果。小結實驗心得體會。課本165頁按F5后實用文檔小人12實用文檔3在輸入librarian 時點擊確定會出錯， 所以把librarian 最后的n改成另一個字母（隨便一個）點擊確定回到上一級窗口如圖確定小人出來了因為名字不一樣，刪除 上面一個小人雙擊下面一個小人改成 librarian小人畫完實用文檔附錄一：實驗題目題目一：教務管理系統之子系統——學院課程安排1．系統簡介每個學期的期中，學校教務處向各個學院發出下各學期的教學計劃，包括課程名稱、課程代碼、課時、班級類別（本科、專科、成人教育、研究生） 、班號等；學院教學主管人員根據教學任務和要求給出各個課程的相關限制（如：任課教師的職稱、上課的班數、最高和最低周學時數等）；任課教師自報本人授課計劃，經所在教研室協調任可，將教學計劃上交學院主管教學計劃的人員，批準后上報學校教務處，最終由教務處給出下個學期全學院教師的教學任務書。假設上述排課過程全部由人工操作，現要求為上述過程實現計算機自動處理過程。2．限定條件1）每位教師的主講課程門數不超過2門/學期：講師以下職稱的教師不能承擔學院定主課的主講任務。（2）學院中層干部的主講課時不能超過 4學時/周。3本學期出現嚴重教學事故的教師不能承擔下各學期的主講任務。4）本系統的輸入項至少包括：教務處布置的教學計劃，學院教師自報的授課計劃和學院定的有關授課限制條件。5）本系統的輸出項至少包括：教務處最終下達全院教師的教學任務書和學院各個班級下各學期的課程表（可以不含上課地點）。題目二：學校教材定購系統1．系統簡介本系統可以細化為兩個子系統：銷售系統和采購系統銷售系統的主要工作過程為：首先由教師或學生提交購書單，經教材發行人員審核是有效購書單后，開發票、登記并返給教師或學生領書單，教師或學生可以到書庫領書。采購系統的主要工作過程為：若是教材脫銷，則登記缺書，發缺書單給書庫采購人員；一旦新書入庫后，即發進書通知給教材發行人員。以上功能要求在計算機上實現。2．技術要求和限制條件1）當書庫中的各種書籍數量發生變化（包括進書和出書）時，都應修改相關的書庫記錄，如庫存表或進/出庫表。2）在實現上述銷售和采購的工作過程時，需考慮有關的合法性驗證。3）系統的外部項至少包括：教師、學生和教材工作人員。4）系統的相關數據存儲至少包括：購書表、庫存表、缺書登記表、待購教材表、進庫表和出庫表。實用文檔題目三：機票預定系統1．系統簡介航空公司為給旅客乘機提供方便，需要開發一個機票預定系統。各個旅行社把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼（護照號碼）、旅行時間、旅行始發地和目的地，航班艙位要求等）輸入到系統中，系統