uml案例教學管理系統

第一篇：uml案例教學管理系統

網上教學系統的UML設計

《統一建模語言UML》

課程報告

題目：網上教學系統的UML設計

分數：

學期：

班級： 學號： 姓名： __ ___ 授課教師： __

一、需求分析

網上教學系統基本分為三個模塊：

1、教師模塊：教師在教學網站上通過登錄教學系統，進行輸入課程介紹、上傳課件、發布消息、修改和更新消息。

2、學生模塊：學生在教學網站上通過登錄教學系統，進行瀏覽信息、查找信息、下載文件。

3、管理員模塊：管理員通過登錄教學系統，對頁面維護、批準用戶的注冊申請。

二、用例模型

設計系統首先需要進行用例圖的建立，所以在此進行參與者確定。

1、在網上教學系統中，教師為參與者之一。教師作為教學直接實施者，需要在網上教學系統中進行進行輸入課程介紹、上傳課件、發布消息、修改和更新消息，如下圖教師用例圖所示。

圖1：教師用例圖

2、學生是網上教學系統的重要參與者。學生作為教學受益者，需要在網上教學系統中進行瀏覽信息、查找信息、下載文件。其用例圖如下圖所示。

圖2：學生用例圖

3、管理員也是網上教學系統的參與者之一，作為系統的維護人員，管理員需要在系統中進行頁面維護、批準用戶的注冊申請。下圖為管理員用例圖。

圖3：管理員用例圖

三、靜態模型

進行網上教學系統程序設計需要先繪制出類圖，以便程序的編寫。 用戶類操作為登錄;

學生類操作處了登錄、注冊外還有瀏覽、下載、查詢。 教師類操作有登錄、注冊、上傳、修改、發布。 管理員類操作為基本管理和系統維護。 下圖為網上教學系統的類圖。

圖4：用戶類圖

四、動態模型

4.1、順序圖

4.1.1、學生模塊下載課件順序圖

圖5：學生下載課件順序圖 4.1.2、學生模塊瀏覽頁面順序圖

圖6：學生瀏覽頁面順序圖

4.1.3、教師模塊上傳課件順序圖

圖7：教師上傳課件順序圖 4.1.4、教師模塊修改信息操作順序圖

教師在教學系統上的操作以及教學系統自身運作。

圖8：教師修改操作順序圖

4.1.5、管理員模塊順序圖

管理員與教學系統及教學系統與信息數據庫之間的交互。

圖9：管理員順序圖

4.2、協作圖

4.2.1、學生協作圖

圖10

圖11 4.2.2、教師協作圖

圖12

圖13 4.2.3、管理員協作圖

圖14

4.3、狀態圖

網上教學系統的基本流程為：用戶在首頁輸入網上教學系統的地址，在登錄界面輸入用戶名以及密碼，系統驗證，若成功則進入下一個狀態，若不成功則返回上一界面。驗證成功時分為三種情況，為管理員用戶則跳轉管理員模塊;為教師用戶則跳轉教師模塊;為學生用戶則跳轉學生模塊。其狀態圖如下：

圖15：系統狀態圖

4.4、活動圖

網上教學系統的總活動圖：

圖16：系統活動圖

五、總結

在進行網上教學系統的UML設計時，需要對Rose軟件有一定的了解，并會使用其進行各種圖的建立，明白不同圖的繪圖規則以及所需主要項。

網上教學系統的UML設計主要為對用例圖、類圖、順序圖、協作圖、活動圖、狀態圖的建立。分析出系統的對象以及功能，這需要對面向對象設計有一定的了解，明白系統中各個部分的內容和功能。

UML設計的完整性會影響網上教學系統進程，所以需要認真的進行UML設計。

第二篇：基于UML的開放式課堂教學管理系統建模

摘 要：隨著“互聯網+”在教育領域的應用，理實一體化課程在職業教育應用廣泛，構建相應的學習、教學空間成為當下流行趨勢，作者根據學習空間課堂教學管理實現的功能，應用UML分析設計B/S結構的系統模型，建立開放課堂教學管理系統，實現對象類的定義、對象類的動態建模及物理建模，有利于提高教學管理系統的開放性、穩定性、可重用性。

關鍵詞：開放課堂教學管理;UML;學習空間;動態建模

中圖分類號：G434 文獻標志碼：A 文章編號：1673-8454(2016)11-0062-03

一、引言

2016年地平線報告提出學習空間重構的重要性，這就要求各院校建立新的教與學空間。高等職業教育變革的主要體現之一是采用理實一體化的教學課程模式，利用現代教育技術，將理論與實踐，教與學，教室、工作室、實訓室，知識、技能等一體化。系統從學習空間教學角度出發，采用.NET框架和MVC模式開發開放課堂教學管理系統，既能夠實現學習空間動態、開放的教學，同時對職業院校學習空間的綜合管理具有重要作用。從學習空間教學的角度出發，使用UML對開放課堂教學管理系統建設內容進行分析建模。系統合理規劃，功能完善，方便師生共同使用，減少相關工作人員的工作量;實現學習空間上的資源共享，激發學習者的學習動機，學生完成社會性交互，促進學生主動參與，提升學習效果;學習空間管理方面，減輕管理員工作，采用信息系統的管理模式，學習空間主要實現項目課程的安排，師生通過訪問服務器可以方便地查詢、提交有關教學資源。

二、系統結構

系統根據教學需求把用戶分為四類，有教師用戶、學生用戶、系統管理員用戶、學習空間管理員用戶。針對具體的用戶，系統根據用戶數據庫提供的信息設置相應的權限和功能。學生使用這個系統可以運用個人密碼登錄，然后在線查看課程安排時間、地點，瀏覽工作項目信息，提交項目報告，修改個人信息，評定其他學生的工作項目，查看自己項目課程成績;教學一線的教師登錄這個系統主要是查詢本人授課的班級，所在的地點、時間，評定學生學習空間平時的課程成績，跟蹤學生的互動信息，記錄學生在開放課堂的表現，修改個人資料，申請使用學習空間并查看結果，申請設備，發布及管理項目報告資源;學習空間的管理人員登錄系統進行學習空間項目信息管理，管理耗材信息，管理設備信息，檢索并分配學習空間，審核學習空間申請，查看學習空間申請及學習空間安排;系統管理員登錄本系統設置學習空間、學生、教師基本信息，設置工作項目設備信息，維護公告信息、學習空間排課系統等。

系統使用ASP.NET MVC模式來實現模型應用程序核心，實現在數據庫中存取數據的功能，視圖一方面將模型的數據接收并傳遞給用戶，另一方面將用戶的數據和請求傳遞給模型和控制器，控制器負責處理用戶之間的交互，MVC將模型、顯示和控制進行了分離，使一個模型可以具有多個顯示視圖，使應用更加方便。系統面向全體用戶具有信息發布功能，能夠完成項目提交、評定等功能，系統可以實現教師申請學習空間的請求，教師根據自己的教學計劃合理安排教學并作具體分配，避免學習空間安排沖突，開放課堂教學管理系統結構如圖1所示。

三、用例圖

系統采用UML 在需求分析階段的建模步驟，根據系統需求，從用戶的角度描述出系統的功能，作為用例圖執行時系統與操作者的一個交互過程，在捕獲用戶需求后，使用用例圖對系統靜態結構進行建模，定義系統的參與者，劃分用例，建立用例圖。

1.系統管理員用例圖

系統管理員的主要需求是保障系統的正確運行，同時進行系統運行過程中基礎數據的維護以及管理配置，具體包括基本信息配置，學習空間課程信息維護，系統用戶數據管理，學習空間排課系統維護、實現、信息的發布，系統登錄等。通過調查分析，學習空間課程信息維護包括項目課程信息導入，項目課程信息查詢，項目課程信息添加、修改、刪除等，參與查詢項目課程信息的用戶包括學生、教師、學習空間管理員等。將每個業務用例都繪制出相應的活動圖，活動圖用于研究實現一個工作過程、多個對象之間的合作，再將其中的各種“活動”整合，圖2為系統管理員用例圖：

2.學習空間課程教師用例圖

學習空間課程教師登錄系統，可以查詢學習空間的設備情況、學習空間課程的申請情況，預約申請學習空間、設備、耗材，上傳項目任務單，管理學生項目報告等，系統存儲師生在學習空間的教學資源，為學生在線主動學習提供了有力保障，圖3為學習空間課程教師用例圖：

3.學生用例圖

學生登錄系統，一方面提交項目報告，查看項目課程成績，進行自評互評，修改個人資料信息，查看課程安排，與系統管理員、課程教師、學生之間進行信息交流;另一方面系統及時記錄學生學習過程并及時反饋給教師，教師可以隨時隨地了解學生的學習情況，圖4為系統學生用例圖：

四、系統的類

系統在建模過程中，以用例模型為輸入，以MVC模式識別系統類、類的屬性和操作，對類進行劃分建立初步模型，之后確定類的屬性和操作以及類之間的聯系。Model部分包括后臺的邏輯操作，訪問數據庫中的類，在.NET中寫成獨立的類文件，最后建立開放課堂教學管理系統的類圖，系統的類分別是用戶類、系統管理員類、學生類、教師類、項目類、班級類、學習空間類、院系類、專業類、排課類，圖5為開放課堂教學管理系統的類圖，每類的功能介紹如下：

用戶類：用戶類是所有類的父類，包括的屬性有登錄名、密碼、用戶郵箱等，方法有getAccount()(獲取登錄賬號)以及changePass()(修改密碼)。

系統管理員類：主要負責系統運行過程中基礎數據的維護以及用戶的管理配置，除了繼承父類的屬性和方法，管理員有自己的屬性、電話號碼。還有自己的方法：cerftfyUpload()(文件的上傳認證)、updaPageInfor ()(更新頁面信息)、addUser()(添加用戶)和deleteUser()(刪除用戶)等。

學生類：主要負責參與學習空間項目課程學生的基本信息的事務管理，除了繼承父類的屬性和方法，還包括學號、姓名、性別、年級、專業、班級編號、系部編號、電話、學生類別、郵箱等。對學生信息事務管理的主要操作有updateStuInfo()(更新個人信息)等。

教師類：包括學習空間管理員與項目課程的教師，主要負責教師基本信息的事務管理，除了繼承父類的屬性和方法，還包括教師編號、教師姓名、性別、教授的課程、職稱、系部編號、類別、電話等，對教師信息事務管理的主要操作有updateCourInfo()(更新課程介紹)、updateTchIntro()(更新教師介紹信息)等。

項目類：主要負責教師學生項目基本信息的事務管理，工作項目基本信息事務管理的主要操作有issue()(項目發布)、delete()(項目刪除)和modify()(項目修改)等。對項目課程事務管理的主要操作有修改項目課程信息的方法modify()，主要屬性包括項目編號、課程編號、項目名稱、項目總課時數、項目要求、課程名稱、任務單號、專業編號、課程標準、考核類型、學習空間編號、用戶類別、學習者特征、分組人數、首開時間、教學目的等。

班級類：主要負責班級的事務管理，主要屬性包括班級編號、班級名稱、專業編號等，對班級事務管理的主要操作有修改班級信息的方法modify()等。

學習空間類：主要負責理實一體化學習空間基本信息的事務管理，主要屬性包括學習空間編號、學習空間名稱、負責教師編號、房間號、容納人數、電腦數、是否分配等，對學習空間事務管理的主要操作有修改學習空間信息的方法modify()。

院系類：主要負責系部信息管理，主要屬性包括院/系編號、院/系名稱等，對院/系事務管理的主要操作有修改院系信息的方法modify()等。

專業類：主要負責專業信息管理，主要屬性包括專業編號、專業名稱等，對專業事務管理的主要操作有修改專業信息的方法modify()等。

排課類：主要負責排課結束后的課表相關元素信息管理，主要屬性包括學習空間編號、項目編號、教師編號、教學周次、教學日次、教學節次、項目批次、容納上課人數等，對排課事務管理的主要操作有自動排課autoCourse()、手動排課manualCourse()、沖突檢測conflictDetection()、統計分析statisAnalysis()、報表輸出reportOut()等。

五、開放課堂教學管理系統中對象的動態建模

系統的動態建模的主要作用是描述個對象間消息的實時變換和相互作用等，開放課程教學管理系統，系統中內部對象間的通信采用UML建模方式進行描述，系統從用戶的主要用例間的交互出發，在用例圖的基礎上建立時序圖。具體的動態建模的流程是：系統管理員進行驗證后登錄系統，對學生、教師、課程的信息進行管理;學習空間管理員進行驗證后登錄系統，可查看課程、課程項目信息，審批預約申請，查詢學習空間設備;學生進行驗證后登錄系統，可以對項目課程信息和考核成績進行查詢，就學生個人信息進行個性化設置等;教師進行驗證后登錄系統，可以查看項目課程、學生信息，同時也可對教師的個人信息進行個性化設置和實時觀察學生的學習過程等。

六、結束語

開放課堂教學管理系統以高職院校理實一體化課程的學習空間為基礎，結合學習空間教學管理的工作流程，開發Web應用系統，采用統一建模語言UML在系統中的應用，提出系統的靜態和動態結構，系統經過反復調試使用，目前運行穩定，各基本條件設置較為滿足，達到合理分配學習空間資源的效果，滿足院校學習空間教學管理系統的優化與實現。

參考文獻：

[1]李雄杰.職業教育理實一體化課程研究[M].北京：北京師范大學出版社，2011.8.

[2]柏依彤.基于校園網的高校畢業設計選題系統的建模與設計[D].成都：電子科技大學，2011.

[3]劉冰，劉銳.軟件體系結構原理、方法與實踐[M].北京：清華大學出版社，2014.1：128-153.

[4]李志河.基于Web的高校教師績效考評系統的研究[J].電化教育研究，2011(11).

[5]陳艷艷，施?B.構建網絡化教學質量監控系統的探索與實踐[J].中國教育信息化，2010(13)：54-55.

[6]王振，陳軍.基于UML對高校教務管理系統的分析與建模研究[J].延邊教育學院學報，2015(1)：55-58.

[7]毛睿.基于UML的教學質量監控系統設計[J].電腦知識與技術，2014(31)：7377-7381.

(編輯：王天鵬)

第三篇：UML 網吧管理系統

貴州師范大學職業技術學院

系統名稱:

姓 名：

班 級: 08 專 業: —— UML基礎教程 ——

考 察 報 告

網吧管理系統 成豪 王建勇 何汶峰 彭健 楊茂科 楊勝文 楊興福 楊家權 計應 計算機應用技術

目

錄

第一章 用例圖 .............................................................................................................

一、管理員用例圖.................................................................................................

二、用戶用例圖 ........................................................................................................ 2 第二章 活動圖 ................................................................................................................. 3

一、用戶活動圖 ........................................................................................................ 3

二、管理員活動圖..................................................................................................... 4 第三章 時序圖 ................................................................................................................. 6

一、管理員在維護窗口進行添加、刪除、掛失用戶的時序圖...................................... 7

二、用戶和管理員在維護窗口進行密碼修改、換機、查看余額的時序圖 .................... 8

三、管理員在充值窗口對用戶進行充值的時序圖 ....................................................... 9

四、用戶在管理窗口進行掛機和注銷的時序圖........................................................... 9 第四章 類圖 .................................................................................................................. 10

一、系統中主要的類 ............................................................................................... 10

二、各類之間的關系 ................................................................................................11 第五章 狀態圖 ............................................................................................................... 12 第六章 方式圖 ............................................................................................................... 13

一、系統的組件圖................................................................................................... 13

二、系統的部署圖................................................................................................... 14

UML實驗報告

第一章 用例圖

第一章 用例圖

用例圖(Use Case Diagram)在需求分析階段有很重要的作用，它描述人們希望如何使用一個系統，作為參與者的外部用戶所能觀察到的系統功能的模型圖。開發的全過程都是圍繞需求階段的用例圖進行的。我們所開發的網吧管理系統的用戶包括需要上網的用戶和管理員。

一、管理員用例圖

管理員的用例包括1)用戶注冊、2)系統登錄、3)充值、4)下機、5)查詢余額、6)修改密碼、7)換機、8)掛機、9)掛失、10)用戶的刪除。如圖1-1所示

圖1-1 管理員用例圖

第頁 共 14頁

UML實驗報告

第一章 用例圖

二、用戶用例圖

用戶的用例包括1)系統登錄2)下機、3)查詢余額、4)修改密碼、5)換機、6)掛機。如圖1-2所示

圖1-2 用戶用例圖

第 2 頁 共 14頁

UML實驗報告

第二章 活動圖

第二章 活動圖

活動圖是基于對象的狀態變遷所繪制的視圖。它的主線是狀態的變化，而不是時間，而時序圖則是對象在不同時間段內的表現。為了滿足這個活動圖，類的一些基本必要方法就可以初步確定。再加上邏輯視圖中類關系的分析，可以套用一些設計模式，又可以進一步再確定一些類的方法和屬性。這一切的圖，就是為了讓你從需求情景描述-設計用例-邏輯視圖-詳細類分析抽象出你的類設計?？傊?，讓面向對象的設計過程，思路連續，可推導。系統不可能完成所有的事情，必然有一部分功能是由人來完成的，所以活動圖，從手工的角度描述了一個業務的流程，其中有些是手工作業，有些是系統的功能，活動圖描述出了整個流程?；顒舆@個術語的解釋依賴于作圖的目的和抽象層次。在描述概念層視圖中，活動表示需要完成的一些任務;在說明層視圖和實現層視圖中，活動表示類中的方法。一個活動可以順序地跟在另一個活動后執行，這是簡單地順序關系。如果觸發事件連接到一個用加黑地粗線段表示地同步條上，且同步條引出幾個帶箭頭地觸發事件，那么這幾個觸發事件是并行的，也就是說這幾個活動的執行次序可以是隨意的。我們做的系統包括用戶活動圖和管理員活動圖。

一、用戶活動圖

用戶以普通使用者的身份登錄系統，可進行如下操作：如圖2-1所示 1. 查詢消費信息：查看當前卡上余額及歷史消費信息;

2. 掛機：如果當前有應用程序正在進行，但臨時有事，需離開計算機一小段時間，希望不中斷當前的任務，即進行此操作用(<1>此操作需設置掛機密碼;<2>掛機狀態，計算機仍處于計費狀態);

3. 修改用戶密碼：如覺得自己的密碼不夠安全，想更換新的密碼，可以進行此操作; 4. 換機：正處于登錄狀態，如覺得當前的計算機的性能不能滿足自己的要求，可進行換機操作，登錄到另一臺計算機;

5. 注銷登錄：如果用戶不想繼續上網，可進行結帳下機、注銷登錄系統(注：如用戶余額不足以支付本次上網，將進行強行注銷登錄系統操作)。

第 3 頁 共 14頁

UML實驗報告

第二章 活動圖

圖2-1 用戶活動圖

二、管理員活動圖

管理員以管理者的身份登錄系統后，可進行如下操作：如圖2-2所示

1. 注冊帳號：如有新用戶前來注冊帳號，在其提供其有效身份證件及用戶密碼后，可進行新用戶的注冊;

2. 用戶充值：用戶前來充值，在確認金額和用戶帳號后，可對其進行充值操作; 3. 帳戶管理：如用戶帳戶保持0余額時間超過一年，即對其帳號進行注銷處理; 4. 查詢用戶消費信息：如用戶想申請查看其自己的消費信息，在其提供其帳號后，可為其查詢消費信息情況;

5. 換機：如用戶覺得當前使用的計算機的性能不能滿足其需要，在其提出申請后，可為其更換到另一臺計算機;

6. 掛失：如用戶帳號遺失，在其提供有效的身份證件后，可對其帳號作掛失處理;

注銷登錄：操作完畢，注銷登錄狀態，退出系統。

第 4 頁 共 14頁

UML實驗報告

第二章 活動圖

圖2-2 管理員活動圖

第 5 頁 共 14頁

UML實驗報告

第三章 時序圖

第三章 時序圖

時序圖(Sequence Diagram)主要用于按照交互發生的一系列順序，顯示對象之間的這些交互。順序圖的主要用途之一，是把用例表達的需求，轉化為進一步、更加正式層次的精細表達。用例常常被細化為一個或者更多的序列圖。順序圖除了在設計新系統方面的用途外，它們還能用來記錄一個存在系統的對象現在如何交互。當把這個系統移交給另一個人或組織時，這個文檔很有用。網吧管理系統的時序圖主要有：

(1)管理員在維護窗口進行添加、刪除、掛失用戶的時序圖。如圖3-1所示

(2)用戶和管理員在維護窗口進行密碼修改、換機、查看余額的時序圖。如圖3-2所示

(3)、管理員在充值窗口對用戶進行充值的時序圖。如圖3-3所示

(4)、用戶在管理窗口進行掛機和注銷的時序圖。如圖3-4所示

第 6 頁 共 14頁

UML實驗報告

第三章 時序圖

一、管理員在維護窗口進行添加、刪除、掛失用戶的時序圖

圖3-1管理員在維護窗口進行添加、刪除、掛失用戶的時序圖

解析：① 管理員登陸到維護窗口之后有三個選擇：添加用戶、刪除用戶、掛失用戶。

② 當進行添加用戶的時候，首先要查詢該用戶是否存在。如果返回的結果表明用戶不存在，則為該新用戶分配一個會員等級。用戶添加成功。

③ 當查詢用戶的信息發現某用戶有一年未登陸并且該用戶的卡上沒有余額的時候，就將該用戶刪除。

④ 當為用戶進行掛失的時候，用戶必須要提供正確的身份證明才給予辦理。

第 7 頁 共 14頁

UML實驗報告

第三章 時序圖

二、用戶和管理員在維護窗口進行密碼修改、換機、查看余額的時序圖

圖3-2用戶和管理員在維護窗口進行密碼修改、換機、查看余額的時序圖

解析：①管理員和用戶登陸維護窗口之后有三個選擇：修改密碼、換機、查看余額。

②當修改密碼時，需要輸入舊密碼進行驗證。當返回的驗證結果表明密碼正確之后，就可以輸入新的密碼以完成密碼的修改。

③當換機的時候，需要輸入目的主機號進行檢查。當返回的檢查結果表明目的主機是空閑的話，就可以將本機換到目的主機。 ④查詢余額的時候比較簡單。當用戶執行查詢余額的功能的時候，系統返回一個查詢結果給用戶即可。

第 8 頁 共 14頁

UML實驗報告

第三章 時序圖

三、管理員在充值窗口對用戶進行充值的時序圖

圖3-2管理員在充值窗口對用戶進行充值的時序圖

解析：管理員登陸充值窗口進行充值，首先輸入要充值的金額。此時系統就會對金額大小進行判斷，如果金額的大小在優惠的范圍內時就會進行相應的優惠，完成充值。

四、用戶在管理窗口進行掛機和注銷的時序圖

圖3-4用戶在管理窗口進行掛機和注銷的時序圖

解析：①用戶登陸管理窗口后有兩個選擇：掛機、注銷登陸。

②如果用戶想暫時離開電腦而又不想結賬下機，也不想讓別人碰自己的這臺電腦時，用戶可以選擇掛機的功能。當執行該功能的時候，系統要求用戶輸入一個密碼來鎖定電腦，當用戶再次用到該電腦的時候，需要輸入此密碼進行解鎖。輸入掛機密碼后，完成掛機操作。

③當用戶想結賬下機是，執行注銷登陸功能。當執行該功能時，用戶就會處于離線狀態，系統停止對該用戶的計費。

第 9 頁 共 14頁

UML實驗報告

第四章 類圖

第四章 類圖

類圖是對象結構建模的一部份，類圖描述系統中類的靜態結構。盡管其他模型可以幫助建模者發現被模擬對象的重要信息，但是它們不能揭示的信息則必須求助于類圖。類圖模擬保證系統正常工作的所有必要資源。其它所有模型如果想獲取這些資源(例如屬性值、狀態和對行為的約束)的信息，最終都必須訪問類圖。類圖是代碼生成(將模型轉化為代碼)的來源，也是逆向工程(將代碼轉化為模型)的目標設生成物。我們所開發的網吧管理系統中主要的類有3個。如圖4-1所示

一、系統中主要的類

(1) 用戶類： 它的屬性有用戶名(Name)、密碼(Password)、上網的卡號(Cardnumber)、用戶身份證號碼(ID)。操作包括修改密碼(Changpassword)、換機(Huanji)、掛機(Guaji)、下機(Xiaji)、余額查詢(Chaxun)、登錄(Denglu)。

(2) 電腦類： 它的屬性有電腦號(Computernumber)、機器地址(Mac)。本身的操作沒有，但有被用戶和管理員換機、掛機、登錄、下機的操作。

(3) 管理員類： 它的屬性有用戶名(name)、密碼(password)，操作包括注冊用戶(Registeredusers)、充值(Chongzhi)、刪除用戶(Deleteusers)、查詢用戶信息(Chaxun)、登錄(Denglu)、換機(Huanji)、掛機(Guaji)、下機(Xiaji)、掛失(Guashi)。

第 10 頁 共 14頁

UML實驗報告

第四章 類圖

圖4-1 系統中主要的類

二、各類之間的關系

一個用戶可以選擇多臺電腦登錄，而一臺電腦可能有被多個用戶登錄，一個管理員管理多個用戶和電腦。如圖4-2所示

圖4-2 各類之間的關系

第 11 頁 共 14頁

UML實驗報告

第五章 狀態圖

第五章 狀態圖

狀態圖用來建模對象是如何改變其狀態的，狀態定義為對象行為在某一時刻的快照或轉折點。狀態圖由狀態、事件、轉移組成。在我們做的網吧管理系統中，管理員通過密碼和用戶名、用戶則通過管理員提供的刷卡機激活自己的網卡登錄系統。用戶可以直接進入操作窗口，管理員會有一個主界面，在主界面上有兩個窗口(維護窗口和操作窗口)，管理員進入維護窗口對用戶的注冊和刪除，從而對數據庫的更新。而另一個操作窗口對于用戶和管理員都是可用的，只是用戶在保證自己網卡上有余額的前提下才能有操作窗口的出現。兩者都有掛機、充值、換機、查詢余額、修改密碼等狀態，最后退出系統。如圖5-1所示

圖5-1 系統狀態圖

第 12 頁 共 14頁

UML實驗報告

第六章 方式圖

第六章 方式圖

實現方式圖包括兩種類型：組件圖和部署圖，組件圖用來演示軟件的各個組件之間的關系，而部署圖用來演示硬件的各個組件之間的關系。它可以讓讀者了解系統中的各個組件的位置及其相互之間的作用關系，幫助設計系統整個架構。

一、系統的組件圖

組件圖用來建模系統的各個組(包括源代碼文件、二進制文件、腳本、可執行文件之間的關系，它們是通過功能或者位置(文件)組織在一起的。)使用組件圖可以幫助讀者了解某個功能位于軟件的哪一位置，以及各個版本的軟件包各包含哪些功能。 下面是網吧管理系統的組件圖：

網吧管理系統中主要有兩個組件圖：管理員組件圖和用戶組件圖。 A. 管理員組件圖

系統建立在一個含有登錄信息、管理界面信息，管理員使用界面依賴于登陸界面。管理員組件如圖6-1所示：

圖6-1管理員組件圖

B.用戶界面組件圖 除了業務對象以外，系統與用戶交互的組件也能創建一個組件圖管理員使用界面依賴于登陸界面。用戶界面組件圖6-2所示

第 13 頁 共 14頁

UML實驗報告

第六章 方式圖

圖6-2 用戶組件圖

二、系統的部署圖

部署圖描述了一個運行時的硬件結點，以及在這些結點上運行的軟件組件的靜態視圖。 部署圖顯示了系統的硬件，安裝在硬件上的軟件，以及用于連接異構的機器之間的中間件。

網吧管理系統由4個節點構成，服務器主要負責整個系統的總體協調工作;數據庫負責數據的管理;管理員用機模塊用于管理員進行查詢、設置信息、如添加新用戶;用戶用機模塊用于用戶上機、信息反饋，節點之間是通過局域網進行通信。

圖6-3系統的部署圖

第 14 頁 共 14頁

第四篇：倉庫管理系統課程設計 UML

無錫職業技術學院實踐環節材料撰寫用紙

二、倉庫信息管理系統分析與設計

(一)《倉庫信息管理系統》的需求建模

1、需求分析

倉庫信息管理系統要能完成以下功能：

倉庫存放的貨物品種繁多，堆存方式以及處理方式也非常復雜，隨著業務量的增加，倉庫管理者需要處理的信息量會大幅上升，因此往往很難及時準確的掌握整個倉庫的運作狀態。針對這一情況，為了減輕倉庫管理員和操作員的工作負擔，此系統在滿足倉庫的基本管理功能基礎上發揮信息系統的智能化。

根據要求可將系統分為四個模塊 (1)用戶登錄模塊

普通操作員和管理人員登錄此系統，執行倉庫管理的一些操作，但是普通操作員和管理人員所能執行的功能不一樣。 (2)倉庫管理模塊

管理員工作需要登陸系統，才能夠進行操作，系統中的各項數據都不允許外人隨便查看和更改，所以設置登陸模塊是必須的?？梢詧绦袀}庫進貨，退貨，領料，退料;商品調撥，倉庫盤點等功能。 (3)業務查詢模塊

在用戶登錄系統后，可以執行庫存查詢，銷售查詢，倉庫歷史記錄查詢。

(4)系統設置模塊

顯示當前倉庫系統中的信息,在系統中可以執行供應商設置，倉庫設置。

2、功能模塊分析 (1)登錄模塊

普通操作員：顯示當天倉庫中的所有庫存的信息。 管理員：修改倉庫中的庫存信息。

用戶注銷：在用戶執行完倉庫功能時，注銷。 用戶退出。 (2)管理模塊

倉庫庫存的進貨與退貨;

倉庫中的庫存需要領料和退料功能;

倉庫也可以完成不同地區的商品在此倉庫的商品調撥任務; 用戶人員也可以在當天之后對倉庫中的庫存進行盤點。 (3)查詢模塊

顯示當前倉庫商品信息，并執行庫存查詢; 顯示倉庫信息，對商品的銷售量進行查詢; 此系統還可以對倉庫歷史記錄進行查詢。 (4)設置模塊

供應商設置 倉庫設置

3、工作內容及要求

進一步細化需求分析的內容，識別出系統的參與者，并完成用例圖;

3 無錫職業技術學院實踐環節材料撰寫用紙

將用例圖中的每個用例都寫成相應的事件流文檔;

進一步使用活動圖來描述每個用例，為后續的系統設計做好準備;

按照系統的功能分析，從用例的描述中提取出系統的對象類和界面類，建立類圖;

分析類圖中的實體類和實體類之間的關系，畫出數據庫的邏輯模型圖(只包含實體類，且注明角色和階元)。

對數據庫的邏輯模型進行優化，取消多對多的聯系，完成最終的邏輯模型設計; 使用交互作用圖或狀態機圖完成系統動態行為的建模。(建議使用順序圖按功能分別描述)

4、創建SRS文檔：

? 引言

倉庫管理系統將24小時為用戶服務。 ? 用途

SRS文檔將作為SDLC設計和編碼階段的輸入。 ? 作用域

管理員直接對系統進行管理。 ? 功能性需求

操作員需要取得管理員的認可才可以登錄此系統。 操作員可以查詢庫存的信息。

系統管理員可以管理登錄系統以后對倉庫進行管理

因為不是每個人都可以隨便修改系統的，所以系統管理員可以登錄進系統以后對用戶的權限信息進行管理。

? 界面需求

界面應該清晰易懂。 ? 運行環境

此系統可以在網絡上進行運行。

4 無錫職業技術學院實踐環節材料撰寫用紙

用例圖如下：

分析：操作員在進行驗證后登陸系統，可以執行商品的進退貨的記錄信息的查詢與管理等操作。

用戶登錄**倉庫領料倉庫進貨**退出系統****商品調撥**操作員****用戶注銷*倉庫退料*倉庫退貨c

圖1 操作員用例圖

分析：此用戶是管理員，可以對倉庫信息進行維護，倉庫商品進行盤點，業務分析，歷史記錄查詢，供應商信息維護和倉庫查詢操作。

5 無錫職業技術學院實踐環節材料撰寫用紙

倉庫信息維護用戶登錄****用戶注銷******管理員***退出系統倉庫盤點*倉庫查詢**供應商信息維護*業務分析歷史記錄查詢*

圖2 管理員用例圖

分析：該用戶為供應商，可以對執行倉庫進貨和退貨的查詢與管理操作。

倉庫進貨***商品供應商*倉庫退貨

圖3 供應商用例圖

(二)《倉庫管理系統》的靜態建模

靜態建模用于描述軟件的靜態成分，又叫結構建模。它包含類關系圖和對象關系圖。用于描述軟件系統的成分之間的關系和依賴性。 1)類的分析與設計

? 確定初始類圖 ? 提取類的屬性 ? 提取類的操作

6 無錫職業技術學院實踐環節材料撰寫用紙

? 類之間的關系

去除不必要的類和不正確的類：

1. 冗余類：若兩個類表述同一信息，保留最具有描述能力的類; 2. 不相干的類：去掉與問題沒有多少關系和根本不相關的類;

3. 模糊類：類必須是確定的，有些臨時類邊界定義不對，或范圍太廣，應排除; 4. 屬性：如果有些名詞是用來描述某個類的，那么它一定是這個類的屬性。 5. 操作：如果所描述的操作并不適用于對象并且被自身所操作，那么這一定不是類。 這樣可以得到相關的三種類關系： ? 人員信息包類圖 ? 接口信息包類圖 ? 系統事務信息包類圖 2)確定類之間的關系

兩個類之間的相互依賴就是關聯，關聯常用描述性動詞或動詞組來表示，其中有物理位置的表示、傳導的動作、通信、所有者關系及條件的滿足等等。 通過以上方法可以確定類圖：

① 人員信息包類圖里包含：操作員類、管理員類、供應商類、商品進貨模塊類、商品退換模塊類、商品打印模塊類、庫存查詢模塊類、商品盤點模塊類、歷史信息查詢模塊類和商品調撥模塊類。

7 無錫職業技術學院實踐環節材料撰寫用紙

**操作員-姓名-id號-權限+倉庫進貨()*+倉庫退貨()+倉庫領料()+倉庫退料()+商品調撥()*+用戶登錄()+用戶注銷()+退出系統()+盤點信息打印報表()+進貨商品打印報表()*+退換商品打印報表()+商品庫存信息()**商品進貨模塊+商品清單()+退貨清單()+查詢信息()庫存查詢模塊**商品打印模塊*

圖4 人員信息包類圖

供應商-供應商姓名-供應商id號-聯系方法+進貨()+退貨()*1管理員-姓名-id號-權限+供應商信息維護()+倉庫信息維護()+盤點信息()+倉庫查詢()+業務分析()+用戶注銷()+退出系統()+歷史記錄查詢()+用戶登錄()+查詢結果()*歷史信息查詢模塊*+查詢條件()+進貨記錄()+商品調撥記錄()+商品盤點信息()*********商品退換模塊*商品盤點模塊*+審核后盤點信息()+查詢信息()**商品調撥模塊+查詢信息()+查詢條件()*+盤點信息列表() 8 無錫職業技術學院實踐環節材料撰寫用紙

② 接口信息包類圖里包含：用戶登錄類、倉庫管理類、系統管理類和業務查詢類。

倉庫管理+倉庫進貨()+倉庫退貨()+倉庫領料()+倉庫退料()+倉庫調撥()+倉庫盤點()用戶登錄+用戶登錄()+用戶注銷()+退出系統()系統設置-供應商設置-倉庫信息維護業務查詢+庫存查詢()+業務分析()+歷史記錄查詢()

圖5 接口信息包類圖

③系統事務信息包類圖包含：用戶登錄類、供應商管理類、業務分析類、查詢歷史信息類、倉庫信息維護類、領料類、退料類、退換類、盤點類、調撥類和倉庫查詢類。

9 無錫職業技術學院實踐環節材料撰寫用紙

調撥供應商管理-該操作id號-日期-管理員id號+增加供應商()倉庫信息維護-該操作id號-日期退料用戶登錄-該操作id號-登錄日期-登錄人id-name+用戶登錄()+用戶注銷()+退出系統()退貨-交易id-日期-操作員-交易id-日期-退料人-操作員倉庫查詢-該操作id-日期領料-交易id-日期-領料員-操作員查詢歷史信息-該操作id-日期業務分析-操作id號-日期-管理員id+opname()盤點-交易id-日期-管理員id-倉庫id

圖6 系統事務信息包類圖

(三)《倉庫管理系統》的動態建模

在完成靜態建模后，需要對系統實現動態建模。需要創建

? 活動關系圖：表示系統的靜態成分為了完成過程需要執行的活動的順序;

? 交互關系圖：表示軟件系統靜態成分之間的交互，常用序列關系圖和通信關系圖。 (1)活動關系圖

活動關系圖是用來對特定過程的控制流進行建模。

分析：管理員在登錄系統后，查看銷售記錄和查看商品庫存情況，如果缺貨就通知操作員缺貨商品清單，操作員即可聯系供應商按缺貨清單提供貨物，然后管理員更新數據庫結束，如果不缺貨直接結束。

10 無錫職業技術學院實踐環節材料撰寫用紙

通知操作員缺貨商品清單查看銷售記錄聯系供應商按缺貨清單提供貨物查看商品庫存情況[ 缺貨] 接受貨物更新庫存數據庫[ 不缺貨 ]

圖7 倉庫系統的活動圖

(2)交互關系圖：通信關系圖、序列關系圖

①通信關系圖以消息的形式表示對象之間的交互。通信圖集中在活動著的對象上，表現的是相互通信的對象之間的消息傳遞，不參照時間。通信圖通過在消息上加序號表示消息傳遞的次序。序列號放在消息之前作為消息的前綴。

注：通信關系圖不描繪對象的生命線。 A.管理員盤點過程協助圖

分析：操作員把盤點信息發送給管理員，管理員審查后盤點信息，在倉庫商品盤點模塊中盤點信息列表，然后交由信息打印模塊打印盤點信息列表，給操作員。

11 無錫職業技術學院實踐環節材料撰寫用紙

操作員盤點信息管理員盤點信息打印列表審查后盤點信息商品信息打印模塊盤點信息列表商品盤點模塊

圖8 管理員盤點過程協作圖

B.商品管理協作圖

分析：操作員通知供應商進貨，供應商打印出進貨清單，操作員也可以對進貨退貨進行管理，供應商打印出退貨清單。

商品進貨進貨商印品打報表進貨清單操作員退貨商品供應商表庫存查詢商品退換退貨清單庫存信息進貨商品打印報

圖9 商品管理協作圖

12 無錫職業技術學院實踐環節材料撰寫用紙

C.倉庫歷史記錄查詢協作圖

分析：管理員應該先登錄系統。當管理員登錄系統以后，可以查詢歷史信息，看到商品進貨、商品盤點、商品調撥的歷史記錄。

商品進貨管理員查詢條件歷史信息查詢進貨、退貨記錄查詢條件商品調撥商品盤點圖10 倉庫歷史記錄查詢協作圖

②序列關系圖

序列關系圖以按時間排序的消息形式來表示對象之間的交互。序列關系圖和通信關系圖的區別在于通信關系圖情調對象的組織結構，而序列關系圖則按時間順序顯示對象之間交互的消息。在序列關系圖中，可以沿x軸方向排列對象。將啟動交互的對象放在最左邊。消息序列中后來的對象則放在交互啟動對象的右邊。在交互中，對象發送和接收的消息按時間升序沿y軸防止。

注：和通信關系圖不同，序列關系圖描述對象生命線。

A.倉庫盤點過程序列圖 分析：操作員將盤點信息發送給管理員，管理員審查盤點信息，然后盤點信息列表交給商品打印模塊打印后發給操作員執行相關商品操作。

商品盤點信息

13 無錫職業技術學院實踐環節材料撰寫用紙

操作員管理員商品盤點模塊商品打印模塊盤點信息盤點信息列表()審核后盤點信息盤點信息打印報表()

圖11 倉庫盤點過程序列圖

B.商品管理序列圖

分析：操作通知商品供應商進貨、退貨，商品供應商將商品清單和退貨商品清單發送給商品進貨模塊，商品進貨模塊將進貨商品打印報表給操作員，商品退貨模塊將商品退換報表打印發給操作員，操作員也可以查詢庫存，庫存庫存模塊將庫存查詢信息發送給操作員。

14 無錫職業技術學院實踐環節材料撰寫用紙

操作員商品供應商商品進貨模塊商品退換模塊進貨()商品清單()進貨商品打印報表()退貨清單()退貨()退換商品打印報表()查詢條件()商品庫存信息

圖12 商品管理序列圖

C.倉庫歷史記錄序列圖

分析：管理員登錄系統查詢歷史信息模塊，歷史信息則查詢商品進貨退貨模塊、商品調撥模塊、商品盤點模塊，之后各模塊將查詢得到的信息發送給歷史信息模塊，最后由歷史信息模塊統一將信息發給管理員。

15 無錫職業技術學院實踐環節材料撰寫用紙

管理員歷史信息查詢模塊商品進貨退貨模塊商品調撥模塊商品盤點模塊查詢信息()查詢條件()進貨記錄()查詢信息()商品調撥記錄()查詢信息()商品盤點信息()查詢結果()

圖13 倉庫歷史記錄序列圖

16 無錫職業技術學院實踐環節材料撰寫用紙

(四)《倉庫管理系統》的架構建模

架構建模使您能夠了解組件在組織網絡中的物理分布。您需要對軟件系統的架構進行建模以確定組件的設計是否符合軟件系統的需要。軟件架構描述軟件按系統的所有組件以及這些組件之間的關系。要對系統軟件的架構進行建模，您需要創建以下關系圖：

? 包關系圖：描述根據特定條件分組在一起的軟件系統構成。 ? 組件關系圖：描述軟件系統的可執行構成。

? 部署關系圖：描述軟件系統組件的各種處理設備。

a)組件關系圖：組件可實現一組接口并構成軟件系統的可執行部分。

分析：該圖是系統的各個組件圖，由系統登錄、倉庫管理管理、信息查詢、系統設置。

倉庫管理信息查詢系統登錄系統設置

圖14 組件關系圖

b)部署關系圖：顯示需要在其中部署軟件組件的硬件。

分析：下圖表明系統采用數據庫系統作為后臺數據提供者，然后客戶登錄使用系統，也可以對系統中的信息進行打印操作。

17 無錫職業技術學院實踐環節材料撰寫用紙

數據服務器客戶機1客戶機n打印機

圖15 部署關系圖

第五篇：某大學教務管理系統UML模型

隨著高校校園網的建設和Internet技術的引進，基于校園網和Internet的應用系統的開發正在蓬勃發展。教務管理師高校教學管理的一向重要工作，現代化的高校教務管理需要現代化的信息管理系統支持。新世紀背景下，高校教育體制進行了大規模的改革，招生人數逐年增加，教學計劃不斷更新。在高校日常管理中，教務管理無疑是核心工作，重中之重。其管理模式的科學化與規范化，管理手段的信息化與自動化對于學校的總體發展產生深遠的影響，由于管理內容過多，繁瑣，處理的過程也非常復雜，并且隨著學校人員的增加，教務管理系統的信息量大幅上升，因此往往很難及時準確地掌握教務信息的運作狀態這使得高校教務管理的工作量大幅度增加，另外，隨著教育改革的不斷深化，教學管理模式也在發生變化，例如實施學分制、學生自主選課等。這一切都有賴于計算機網絡技術和數據庫技術的支持，在這樣的形勢下建立和完善一個集成化的教務管理系統勢在必行。

目前，國內高校都開發了自己基于校園網的教務管理系統。由于其教務管理模式不盡相同，不同學校的實際教務管理情況各有自己的特點，因而各高校需要針對自己的教務管理模式和特點建立自己的教務管理系統。本設計是基于某高校的教務管理模式開發的基于校園網的教務管理系統。這樣一個系統不僅可以降低工作量、提高辦公效率，而且使分散的教務信息得到集中處理，對減輕教務工作負擔、提高教務管理水平、實現教務管理的現代化具有重要意義。

1.建立系統用例模型

1.1確定系統模型的參與者

仔細分析教務管理系統問題描述。在UML中，角色代表位于系統之外和系統進行交互的一類對象，本系統中創建主要的角色有以下三類：

(1)教務員：教務員在教學管理系統中對全體學生進行用戶登錄、學籍管理、選課管理、教學管理和成績管理，并且對教師進行登錄管理、教學管理和成績管理。教務處工作人員處理日常的系統維護，例如維護和及時更新學生，教師信息以及安排選課等。

(2)教師：教師根據教務系統的選課安排進行教學，將學生的考試成績錄入此系統。 (3)學生：學生能夠在教務管理系統更改學籍信息、進行選課、查詢已選課程和考試成績。

1.2識別用例

用例是系統外部參與者與系統在交互過程中需要完成的任務，識別用例最好的方法就是從分析系統的參與者開始，考慮每一類參與者需要使用系統的哪些功能，如何使用系統，根據教務管理系統的運行流程個提取的參與者信息，確定系統分為以下幾個用例： (1)學生參與者用例：

用戶登錄 學籍管理 選課管理 (2)教師參與者用例：

用戶登錄 成績管理 教學管理

(3)教務員參與者用例：

用戶登錄 學籍管理 排課管理 成績管理 選課管理 教學管理 系統維護

1.3建立如下四個用例圖模型

(1)頂層用例圖如圖1-1所示

圖1-1頂層用例圖

從用例圖1-1可以看出學生、教師和教務員都使用了“用戶登錄”用例，表示學生必須先進行用戶登錄后才可以進行學籍管理和選課管理。同理，教師也必須登錄后才能進行成績管理和教學管理。教務員登錄后進行系統設置、學籍管理、排課管理和教學管理等操作。

(2)學生角色用例圖 如圖1-2所示

圖1-2學生角色用例圖

從用例圖1-2可以看出學生登錄后才能進行所有的操作，這樣可以提高系統的安全性。 (3)教師角色用例圖如圖1-3所示

圖1-3教師角色用例圖 從用例圖1-3可以看出教師所有的用例都是建立在“用戶登錄”基礎上，表示教師必須先登錄后才可以執行相應的功能，這樣可以提高系統的安全性，以免有人故意提供虛假信息。 (4)教務員角色用例圖如圖1-4所示

圖1-4教務員角色用例圖

從用例圖1-4可以看出教務員的用例相對較多，但是教務員的所有的用例都必須在“用戶登錄”的基礎上，表示教務員必須先登錄才可以執行相關的功能，這樣同樣可以提高系統的安全性，避免有人故意更改信息。

2 建立系統動態模型 2.1活動圖

經過活動圖的建?？梢员容^清楚地了解整個進程過程的操作過程，本系統中主要的活動圖有如下幾個：學生成績查詢活動圖、教務員修改學生資料活動圖、學生選課活動圖以及教師成績錄入活動圖

(1)學生成績查詢圖如圖2-1所示

圖2-1 學生成績查詢活動圖

從圖2-1可以看出，活動圖分為多個不同的泳道，每個泳道表示學生在查詢成績活動中不同參與者的工作流。每個泳道中的活動是參與者要執行的操作。通過不通泳道之間的活動過渡，可以了解參與者之間的通信。這些信息可以幫助我們更好地理解系統的業務過程。

在學生成績查詢活動圖中可以知道，學生、教師和教務員之間存在著相互聯系。學生登錄以后可以查詢已選科目和成績單，如果發現自己的成績單有錯誤后可以通知教務員成績有誤，教務員聯系教師后，教師修改成績，然后教務員更新數據庫。成績無誤后，查詢結束。

(2)教務員學生資料修改活動圖如圖2-2所示; (3)學生選課活動圖如圖2-3所示;

圖2-2教務員學生資料修改活動圖圖2-3學生選課活動圖

從圖2-2可以看出，教務員登錄教務系統，系統驗證用戶名和密碼，若有錯誤重新輸入，無誤后進行選擇修改項目，確定修改，

圖2-3學生選課活動圖圖2-4 教師成績錄入活動圖

2.2順序圖

主要包括如下幾個順序圖 ①教務學籍管理順序圖 ②學生注冊順序圖 ③學生選課順序圖 ④教師成績錄入順序圖

圖2-5教務學籍管理順序圖

圖2-6學生注冊順序圖

圖2-7教師成績錄入順序圖

3系統類模型 3.1系統包圖

將整個教務管理系統劃分為人員信息、接口和事務3個包，分別控制不同的應用。

3.2類圖

根據系統劃分的三類包圖，分別討論人員信息包，接口包和事務包中的類圖分別為： (1)人員信息包內的類圖 (2)接口包內的類圖 (3)事務包內的類圖

圖3-1 人員信息包內的類圖

圖3-2接口信息包內的類圖

圖3-3系統事務信息包內的類圖