第一篇：uml管理系統課程設計
倉庫管理系統課程設計 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課程設計報告+網絡教學系統的分析和設
統一建模語言UML 課程設計報告
指導老師: 姓名: 學號: 班級:
【設計名稱】 網絡教學系統-使用UML進行系統的分析和設計 【設計目的】1.掌握UML建模的基礎知識和其應用;
2.熟悉Rational Rose環境及功能,能夠設計出完整系統。
【設計要求】1.對系統功能進行必要的描述;
2.繪制系統的主要模型圖;
3.模型圖要有說明性文字解釋。 【設計內容】1.網絡教學系統的需求分析;
2.網絡教學系統UML建模。
【設計步驟】
一: 網絡教學系統的需求分析
1、系統功能需求
(1)學生可以登陸網站瀏覽和查找各種信息以及下載文件。
(2)教師可以登陸網站給出課程見解、發布、修改和更新消息以及上傳課件。 (3)系統管理員可以對頁面進行維護和批準用戶的注冊申請。 滿足上述需求的系統主要包括下面幾個模塊
(1)數據庫管理模塊：提供使用者錄入、修改并維護數據的途徑。
(2)基本業務模塊：教師可以上傳文件、發布消息、修改和更新消息;學生可以下載文件;管理員可以維護頁面，批準注冊等。
(3)信息瀏覽、查詢模塊：主要用于對網站的信息進行瀏覽、搜索查詢。
圖 1.1系統功能需求
2、數據庫管理模塊
圖 1.2數據庫管理模塊
(1)教師信息管理：負責教師信息的管理。
(2)課程簡介信息管理：負責課程簡介信息的管理。 (3)文件上傳信息管理：負責文件上傳信息的管理。
3、基本業務模塊
圖 1.3基本業務模塊
(1)文件上傳：教師可以使用此模塊將課程的數據上傳到網站服務器。 (2)文件下載：學生可以使用此模塊從網站上下載課件及其他資料。
(3)消息發布：教師可以通過此模塊發布學習方法、課程重點等和教學相關的文章，以及和課程相關的通知等。
(4)消息修改和更新：教師可以通過此模塊對自己發布的信息進行修改和更新。 (5)頁面維護：網站管理員可以使用此模塊對網站的頁面進行維護。 (6)用戶注冊批準：網站管理員可以使用此模塊批準用戶注冊。
4、信息瀏覽、查詢模塊
圖 1.4信息查詢模塊功能
(1)網頁信息瀏覽：用戶瀏覽網站信息。
(2)文章信息搜索：用戶根據關鍵字搜索文章。
二: 系統的UML建模
1、系統的用例圖
創建用例圖之前首先需要確定參與者。 ① 在網絡教學系統中，需要學生和教師的參與。學生可以瀏覽課程簡介，教學計劃，學習方法等教師發布的文章，并可以根據關鍵字查詢文章。此外，學生可以從網站上下載課件。教師作為教學的主導者，使用此網站可以發布學習方法，課程重點等和教學相關的文章，以及和課程相關的通知等，還可以將某一門課程的課件上傳。 ② 網站需要一個專門的管理者進行日常維護與管理，所以需要有系統管理員的參與。 (1)系統用戶參與的總的用例圖
教師和學生都可以從“網站用戶”這個參與者泛化而來，網站用戶是指網站的注冊用戶，注冊用戶可以登錄系統完成相應的操作。
系統用戶參與的總的用例圖如圖所示。從圖中可以清楚地看到泛化關系與各個參與者所參與的用例。
圖 2.1系統用戶參與的總的用例圖
抽象參與者注冊用戶的用例只有登錄系統(System Login)一個，學生和老師用戶除了包含這個用例以外，還各自有相對應的用例。 (2)學生參與者的用例圖
學生參與者的用例圖如下圖所示。
圖 2.2學生參與的用例圖
① 文章瀏覽用例:學生可以瀏覽諸如課程簡介，教學計劃，學習方法等教師發布的文章。 ② 文章搜索用例:學生可以使用搜索功能根據關鍵字查詢相應的文章。
③ 文章下載用例:學生可以使用下載功能將網站上的課件以及資料信息下載到本地機器上?！加美龍D說明〗
① Download:文件下載用例。 ② Look through info:文章瀏覽用例。 ③ Article search:文章搜索用例。
④ Identify:權限認證用例。此用例用來認證文件下載是否具有下載文件的權限。
(3)教師參與者的用例圖
教師參與者的用例圖如下所示。
圖 2.3教師參與的用例圖
3 ① 添加課程簡介用例：教師可以為自己所教授的課程添加課程簡介。 ② 上傳課件用例：教師可以將課程的課件上傳到網站上供學生下載。 ③ 文章或消息發布用例：教師可以發布介紹學習方法，課程重點等和教學相關的文章，以及和課程相關的通知等。 ④ 文章或消息修改用例：教師可以修改自己發布的文章和通知。 〖用例圖說明〗
① Course Intro:添加課程簡介用例。 ② Upload CAI:上傳課件用例。 ③ Message Issue:文章或消息發布用例。 ④ Message Update:文章或消息修改用例。
(4)系統管理員參與者的用例圖
系統管理員的用例圖如下所示。
圖 2.4系統管理員參與的用例圖
① 頁面維護。系統管理員可以對網站進行日常維護與管理。 ② 處理注冊申請。系統管理員可以處理學生或教師用戶的注冊申請。 〖用例圖說明〗
① Page Maintenance:頁面維護。
② CAI Process:教師上傳的課件經過系統管理員的審批和處理。
③ Information Update:頁面更新。系統管理員負責網站的頁面更新，除了文章，消息，圖片等的更新，還包括頁面的美化和板塊的調整。
④ Process Registration:處理注冊申請。
2、系統的時序圖
網絡教學系統中的用例很多，所能畫出的時序圖也很多，在此不一一介紹。 (1)系統管理人員管理網站的時序圖
圖 3.1 系統管理人員管理網站的時序圖
4 〖時序圖說明〗
① Login:登錄系統的函數。
② Add_or_delete_Article:添加或刪除的文章。 ③ UpdateCAI():更新CAI課件的函數。 ④ Add_or_delete_User:添加或刪除用戶。 ⑤ Show():刷新頁面的函數。 ⑥ Notify():通知用戶的函數。
系統管理人員通過與管理窗口的交互可以添加或刪除文章，更新CAI課件，添加或刪除用戶。具體的操作由管理窗口與數據庫交互完成，管理員操作后的結果會在頁面上顯示。 (2)用戶登錄系統的時序圖
圖 3.2 用戶登錄系統的時序圖
〖時序圖說明〗
① Input(String,String):輸入用戶名和密碼的函數。
② Send(String,String):將用戶名和密碼發送給服務器的函數。
③ Query_and_Validate():查詢數據庫并驗證用戶名和密碼正確性的函數。
④ feedBack():發送反饋消息的函數，如果驗證通過，發送OK;如果驗證出錯，發送Error. ⑤ ShowInformation():將反饋信息顯示給用戶的函數。
用戶要登錄系統，首先要和登錄窗口交互，輸入用戶名和密碼。登錄窗口負責和服務器交互，將用戶輸入的用戶名和密碼發送到服務器，服務器再與數據庫交互，以驗證用戶名和密碼的有效性，如果驗證成功，則返回OK，驗證失敗返回Error。服務器將通過登錄窗口將信息顯示給用戶。
(3)學生下載文件時序圖
圖 3.3 學生下載文件的時序圖
〖時序圖說明〗
5 ①Request:學生發送下載請求。
②Send(String,String):傳遞下載參數的函數。 ③Identity():驗證用戶權限的函。 ④authorize:返回認證信息的函數。
學生要下載文件，首先要向下載窗口發送請求，然后下載窗口的參數傳遞個服務器，服務器與數據庫交互以獲得用戶的權限認證，認證信息再通過服務器及下載窗口傳遞給學生。
3、系統的協作圖：
1 、用戶登錄系統的協作圖
圖 4.1 用戶登錄系統的協作圖
〖協作圖說明〗
①Input(String,String):輸入用戶名和密碼的函數。
②Send(String,String):將用戶名和密碼發送給服務器的函數。
③Query_and_Validate():查詢數據庫并驗證用戶名和密碼正確性的函數。
④feedback():發送反饋消息的函數，如果驗證通過，發送OK，否則，發送Error。 ⑤ShowInformation():將反饋信息顯示給用戶的函數。
2、學生下載文件的協作圖
圖 4.2 學生下載文件的協作圖
〖協作圖說明〗
①Request:學生發送下載請求。
②Request(String,String):傳遞下載參數的函數。 ③Identity():驗證用戶權限的函數。
④showStatus():返回下載狀態的函數。如果認證成功，開始下載，不成功則報錯。
4、系統的狀態圖：
圖 5.1 系統的狀態圖
〖狀態圖說明〗
① HomePage:處于網站主頁。 ② Certify:登錄驗證狀態。 ③ SuccessPage:登錄成功頁面。 ④ UploadApplyPage:文件上傳頁面。 ⑤ Storing File:文件存儲狀態。 ⑥ OldPage: 頁面未更新狀態。 ⑦ NewPage:頁面更新狀態。
教師要上傳文件，首先要登錄網站，通過網站認證后轉入文件上傳頁面，上傳文件后處于文件存儲狀態。文件存儲后，要經過管理員的認證才可以在頁面上顯示，如果通過認證，則刷新頁面，如果未通過，頁面維持不變。
5、系統的活動圖：
(1)用戶登錄系統的活動圖
圖 6.1 用戶登錄系統的活動圖
〖活動圖說明〗
7 ①InputURL:輸入網站的URL。 ②Show HomePage:顯示網站主頁。 ③Input Login Information:輸入登錄信息。 ④Press ”OK” Button:單擊 “OK”按鈕。
⑤Certify UserInfo:用戶信息認證。 ⑥Show Success Page:顯示登錄成功界面。
用戶登錄系統時，首先要輸入登錄網站的URL，然后從首頁的登錄窗口中輸入信息登錄信息，如用戶名和密碼，點擊頁面上的登錄按鈕。用戶輸入的信息會與數據庫中的信息對比驗證，如果驗證成功返回登錄成功頁面，如果失敗，返回登錄失敗頁面。 (2)教師上傳課件的活動圖
圖 6.2 教師上傳課件的活動圖
〖活動圖說明〗
①Apply File Upload:申請文件上傳。
②Certify Size And Other Aspact:驗證文件的大小和其他信息。 ③Store:文件存儲。
④Administrator Authorize:系統管理員認證。 ⑤Update Page:更新頁面。 ⑥Delete File:刪除文件。
教師要上傳文件，先要進入文件上傳頁面，然后驗證上傳文件的大小和其他信息是否符合要求。驗證成功后將文件存儲，當系統管理員認證通過，更新頁面;認證不通過刪除文件。 (3)系統管理員維護網站的活動圖
圖 6.3 系統管理員維護網站的活動圖
〖活動圖說明〗
①Login:登錄系統。
②Process CAI:處理上傳的課件。 ③Update Information:更新頁面信息。 ④Modify Page:修改頁面。
6、系統中的類
(1)參與者相關的類
系統中和參與者相關的類的類圖如下：
圖 7.1 參與者相關的類
〖類圖說明〗
9 ①User類是所有類的父類，包括屬性有Account(登錄名)、Password(密碼)、email(用戶郵箱)等。方法有getEmail(獲取郵箱)、getAccount(獲取登錄賬戶名)以及changePass(修改密碼)。
②Student類是學生類， 除了繼承父類的屬性和方法，還包括number(學號)、name(姓名)、sex(性別)、age(年齡)、class(班級)、和grade(年級)等屬性。
③Teacher類是教師類，除了繼承父類的屬性和方法，還包括name(姓名)、sex(性別)、Identity Card(身份證號)、course(教授的課程)、以及TelephoneNum(電話號碼)。
④Adminstrator是管理類，管理員有自己的屬性，TelephoneNum(電話號碼)。還有自己的方法：CertifyUpload(文件的上傳認證)、UpdatePageInformation(更新頁面信息)、AddUser(添加用戶)和DeleteUser(刪除用戶)等。
(2)各類之間的關系
類不是單獨一個模塊，各個類之間是存在聯系。網絡教學系統各個類之間的聯系如下圖：
圖 7.2 各類之間的關系
〖類圖說明〗
①CourseIntro類表示課程介紹類。此類的屬性有：courseName(課程名)、college(開課院校)、teacher(授課教師)、scorePoint(課程學分)、time(開課時間)、Place(上課地點)和teachingPlan(教學計劃)等，它有一個修改課程信息的方法Modify()。
②Article類表示發表的文章類，包括articleNum(文章序號)、articleTitle(文章標題)、teacherToIssue(發布教師)、create Time(創建時間)以及文章內容。方法有Issue(文章發布)、Delete(文章刪除)和Modify(修改)。 ③FileUploadOrDownload類表示上傳的文件信息類，屬性包括fileName(文件名)、fileType(文件類型)、fileSize(文件大小)、shortIntro(文件的簡短介紹)、fileURL(文件地址)、create(文件的創建者)以及createTime(文件的創建時間)等。操作包括checkSize(檢查文件大小)、Modify(修改文件信息)、Store(文件存儲)以及Cancle(取消上傳)等。
教師可以教授幾門課程，所以有幾門課程的課程簡介;教師可以發布多條信息，也可以不發布;教師可以不上傳文件，也可以上傳多個文件。一個學生可以下載一個文件，也可以不下載文件。
7、系統的組件圖
網絡教學系統的組件圖如下圖，組成Web應用程序的頁面包括：維護頁面(Maintenance Page)、文件下載頁面(File Download Page)、文件上傳頁面(FileUpload Page)、信息發布頁面(Message Issue
10 Page)和登錄頁面(Login Page)。
圖 8.1 系統的組件圖
8、系統的配置圖
配置圖主要是用來說明如何配置系統的軟件和硬件。網絡教學系統的應用服務器負責保存整個Web應用程序，數據庫是負責數據庫管理。此外還有很多終端可以作為系統的客戶端。由于客戶端很多，在此只畫出3個客戶端，系統配置圖如下圖：
圖 9.1 系統的配置圖
【小結】
在建模過程中，遇到一些問題，諸如某些操作界面無法看到，一些修改影響了其他模圖的建立，通過詢問輔導老師和上網查找資料，得到了比較滿意的解決;在這次實驗中，關于UML的概念以前比較模糊的地方，我在實際操作中，變得更加清楚了，對Rational Rose的UML功能運用的更加系統，更加熟練;但是更讓我明白，UML的知識是十分豐富的，我現在的認識還不夠，我將會在以后的學習中，不斷提高自己的UML知識。
第三篇：軟件工程課程設計——基于UML醫院患者監護系統的分析與設計
軟件工程
課程設計報告
基于UML醫院患者監護系統的分析與設計
姓名： 班級： 學號： 指導教師：
實驗題目
基于UML醫院患者監護系統的分析與設計
實驗目的
軟件工程課程設計是軟件工程專業一個綜合性的實踐教學環節，其目的在于促進學生復習和鞏固計算機軟件設計知識，加深對軟件設計方法、軟件設計技術和設計思想的理解，并能運用所學軟件設計知識和面向對象技術進行綜合軟件設計，提高學生的綜合應用能力。通過這次課程設計，要掌握UML(統一建模語言)，并能運用UML在Rational Rose中建模。
實驗要求
1. 一人一組。
2. 熟悉Rose開發環境。
3. 掌握UML的基本模型元素(如角色、用例、類等)。 4. 熟悉UML，主要了解UML中的9大圖：Use case diagram(用例圖)、Class diagram(類圖)、Sequence diagram(序列圖)、Collaboration diagram(協作圖)、Statechart diagram(狀態圖)、Activity diagram(活動圖)、Component diagram(組件圖)、Deployment diagram(配置圖)、datamodel diagram(數據模型圖)。
5. 進行系統需求分析與系統功能模塊設計，繪出系統詳細的業務流程圖和數據流程圖，建立完整的系統數據庫的邏輯模型。 6. 完成對系統的建模實現。 7. 進行檢查，并提交設計報告。
實驗內容
一、 問題描述
在醫院的病房里，將病癥監視器安置在每個病床，對病人進行監護。監視器將病人的病癥信號(組合)實時地傳送到中央監護系統進行分析處理。在中心值班室里，值班護士使用中央監護系統對病員的情況進行監控，監護系統實時地將病人的病癥信號與標準的病診信號進行比較分析，當病癥出現異常時，系統會立即自動報警，并打印病情報告和更新病歷。系統根據醫生的要求隨時打印病人的病情報告，系統還定期自動更新病歷。
二、 需求分析
根據分析系統主要實現以下功能：
1、要求病癥監視器隨時接收每個病人的生理信號(脈搏、體溫、血壓、心電圖等)，定時記錄病人情況以形成病情報告。
2、病癥監視器可以將采集到的病癥信號(組合)，格式化后實時的傳送到中央監護系統。
3、中央監護系統將病人的病癥信號與標準的病癥信號庫里的病癥信號的正常值進行比較，當病癥出現異常時系統自動報警。
4、當病癥信號異常時，系統自動更新病歷并打印病情報告。
5、值班護士可以查看病情報告并進行打印。
6、醫生可以查看病情報告，要求打印病情報告，也可以查看或要求打印病歷。
7、系統定期自動更新病歷。
三、 用UML的靜態建模機制定義描述系統的靜態結構
(一) 建立系統的用例圖
通過分析可以識別出本系統的四個角色：值班護士，醫生，病人，標準病癥信號庫。其描述面板如下：
角色：病人 角色職責： 提供病癥信號
角色職責識別：
負責生成、實時提供 各種病癥信號。
角色：醫生 角色職責：
對病人負責，負責處理病情的變化
角色職責識別：
(1)需要系統支持以完成其日常工作
(2)對系統運行結果感興趣
角色：值班護士 角色職責：
負責監視病人的病情變化
角色職責識別：
(1)使用系統主要功能 (2)對系統運行結果感興趣 角色：標準病癥信號庫 角色職責：
負責向系統提供病癥信號的正常值
角色職責識別：
(1) 負責保持系統正常運行 (2) 與系統交互
通過分析可以初步識別出系統的用例為：中央監護，病癥監護，提供標準病癥信號，病歷管理，病情報告管理。頂層用例圖如下：
(二)識別系統的類
通過名詞識別法和系統實體識別法等方法可以識別出系統的十二個類。類圖(含數據模型)如下：
(三)用配置圖描述系統的體系結構
用配置圖可以進一步描述系統的網絡結構。配置圖如下：
四、 用UML的動態建模機制定義描述系統結構元素的動態特性及行為
(一)用狀態圖描述系統結構元素的動態特性及行為 狀態圖如下：
(二)用序列圖和協作圖描述病人病情異常時系統的情況 序列圖如下：
生成協作圖如下：
(三)用活動圖描述系統在監護病人時的狀態變化 活動圖如下：
五、 作出系統的詳細業務流圖及數據流圖 業務流圖如下：
數據流圖如下：
源程序和文檔
見附件。
心得體會
通過本次課程設計，我對于UML有了更深刻的了解，能更熟練的使用UML在Rational Rose中進行建模，同時也對軟件工程及面向對象等方面的知識有了一個溫習和鞏固，對今后的學習起著積極的作用。在實驗中碰到的幾個困惑，或請教老師同學，或自己查閱資料都得到了解決，許多以前不甚理解的地方也豁然開朗，收獲很大。
第四篇：《面向對象技術與UML課程設計》實驗指導書
實驗一 系統的用例模型
實驗名稱：系統的用例模型
實驗類型: 設計性實驗 學
時：一天
一、實驗目的
1.熟悉用例圖的基本功能和使用方法。
2.鍛煉結合給定題目，進行有效需求分析的能力。 3.掌握如何使用建模工具繪制用例圖的方法。
二、實驗器材
1.計算機一臺。
2.Rational Rose 工具軟件。
三、實驗內容
在理解用例圖的基本功能和使用方法的基礎上，結合具體問題，完成對系統的需求建模，得到用例模型后，應針對每個用例進行業務分析，說明其具體的業務流程。用Rational Rose工具軟件繪制系統的用例圖。
四、實驗步驟
1.結合實際給定題目，完成系統的需求建模。
2.針對每個用例進行業務分析。以圖書管理系統中“刪除讀者信息”用例為例來說明實驗具體步驟。
(1)分析：在圖書管理系統中,管理員首先登錄系統,系統驗證通過后,管理方可向系統查詢數據,在查詢后,系統會給出提示,有沒有找到相關的數據,管理員根據系統查詢的返回結果,進行下一步的操作,就是刪除讀者,在刪除的過程中,系統會對查詢得到的結果判斷該記錄是否可以刪除,若可以刪除,則給刪除提示,若不能刪除,也給相關的提示信息。
(2)根據分析結果，書寫業務流程，一般包含以下信息：
①管理員在錄入界面，輸入待刪除的讀者名;
②“業務邏輯”組件在數據庫中，查找待刪除的讀者名; ③如果不存在，則顯示出錯信息，返回步驟①，如果存在則繼續; ④“業務邏輯”組件判斷“待刪除的讀者”是否可以刪除; ⑤如果不可以，則顯示出錯信息，返回步驟⑧，如果可以則繼續; ⑥在數據庫中，刪除相關信息; ⑦顯示刪除成功信息; ⑧結束。
3.根據分析結果，繪制用例圖。以圖書管理系統中“刪除讀者信息”用例為例說明具體繪圖步驟: (1)在用例圖上雙擊main,出現如圖1.1所示,為繪制用例圖做好準備。
圖1.1 (2)在圖中的工具欄選取Actor圖標，在右邊的圖中添加一個Actor，并輸入名稱:administrator,如圖1.2所示。
(3)在左邊的工具欄中，選取用例的圖標，在右邊的圖中畫出一個用例，并輸入用例的名稱：login 。
圖1.2 (4)按照步驟(3)，繪制出如圖1.4和圖1.5的兩個用例。
圖1.3
圖1.4
圖1.5 (5)在繪出了用例后，接下來的是繪制參與者與用例實現，如圖1.6所示。
圖1.6
(6)根據步驟(5)，同時完成如圖1.7和圖1.8。此時，刪除讀者用例圖就到此完成。其系統查詢讀者信息等其他的功能會在時序圖和活動圖中描繪。
(7)根據分析情況，進一步添加或細化用例圖。
圖1.7
圖1.8
五、實驗報告要求
1. 說明系統的需求建模結果，對主要用例整理用例圖。 2. 小結實驗心得體會。
實驗二 系統的類模型
實驗名稱：系統的類模型
實驗類型: 設計性實驗 學
時：一天
一、實驗目的
1.理解類的基本概念。
2.掌握如何從需求分析中抽象出類的方法。 3.掌握在Rational Rose中繪制類的操作方法。
二、實驗器材
1.計算機一臺。
2.Rational Rose 工具軟件。
三、實驗內容
完成實驗一后，對給定題目的系統的需求的初步分析，得出系統的用例圖，通過對用例的業務流程的分析，我們可以初步了解系統的業務處理流程。本實驗需要對系統進行靜態建模，這就需要從系統的用例圖去尋找和發現類。用Rational Rose工具軟件繪制系統的類圖。
四、實驗步驟
1.分析：由前面試驗對需求的分析抽象出類。 2.繪制類圖的步驟：
(1)打開前面初步構建的UML模型文件; (2)打開Rose中的邏輯視圖(Logical View)，選擇分析模型(analysis model)目錄。并在其下創建一個子目錄并命名為：“圖書館業務功能”。
(3)用鼠標右擊“圖書館業務功能”在彈出來的菜單中選擇“New→Class diagram”項，創建類圖，如圖2.1所示。
(4)雙擊新建的類圖，并點右邊控件集中選中的類的圖標，并用鼠標在圖中分別拖出一個類圖，并命名為Book，如圖2.2所示。
圖2.1
圖2.2 (5)接下來的一步為設置類的屬性，在新的類中雙擊該類，在打開屬性面板中，可以看到在此可以設置類的屬性和方法等其他的信息，圖2.3所示;后撞擊Attributes這個欄目，此欄目為設置類的屬性的選項，在圖中間的單擊右鍵，可以看到有一個“Insert”的選項，選中這個選項，圖2.4所示，后在出現的對話框中輸入相關信息如圖2.5所示;如書本的ISBN號，在Type這個方框內輸入此屬性的類型值，同時可以看到一欄可以設置此屬性的訪問權限，一般這些屬性都設置Private這個權限，如圖2.6所示。這個類的其他屬性也可以按照以上的做法設置，最后得到的結果是圖2.7所示。
圖2.3 圖2.4
圖2.5 圖2.6 (6)設置好類的屬性，現在來設置類的方法(也是操作)，雙擊類后在彈出的菜單上選operations這個選項，可以看到圖2.8所示，在圖中的空白地方，單擊右鍵，在彈出的菜單中選insert這個選項，也就只有這個選項可用，見圖2.9，接著輸入方法名，同時可以設置該方法的返回類型，也可以在Documentations的方框內填寫一些相關的方法說明，如圖2.12所示，設置好該方法的訪問權限，見圖2.13。類的其他方法也可以按上面來設置好，最后，得到該類的其他方法見類2.14。
圖2.7 圖2.8
圖2.9
圖2.11
圖2.10
圖2.12
圖2.13 圖2.14 (7)至此，類的方法和屬性都設置好了，如圖2.15所示。
圖2.15 (8)按照上面的步驟設置好所有類的屬性和方法。
(9)為各個類添加關系，由關聯、泛化、依賴等關系來靜態描述業務。
五、實驗報告要求
1.整理實驗結果。 2.小結實驗心得體會。
實驗三 系統的狀態建模
實驗名稱：系統的狀態建模
實驗類型: 設計性實驗 學
時：一天
一、實驗目的
1.熟悉狀態圖的基本功能和使用方法。 2.掌握如何使用建模工具繪制狀態圖方法。
二、實驗器材
1.計算機一臺。
2.Rational Rose 工具軟件。
三、實驗內容
完成實驗一后，對給定題目的系統的需求的初步分析，得出系統的用例圖，通過對用例的業務流程的分析，我們可以初步了解系統的業務處理流程，但對業務處理過程的處理狀態間轉換了解仍不夠，這不利于設計人員對系統業務的進一步理解，而狀態圖能從對象的動態行為的角度去描述系統的業務活動。因此，在本實驗主要完成用例的狀態圖。
四、實驗步驟
1.業務分析：由前面實驗對用例的描述和分析得到業務動態行為的狀態分析。以用例“還書”為例，還書業務的動態行為是由：空閑(idle)、圖書查找(finding)、還書(reversion)、失敗(Failure)、歸還成功(Success)5種狀態及激活相互轉換的事件。
2.繪制狀態圖。
還書的狀態圖，還書的主要業務都是由管理員來完成，首先管理員必須先登錄系統，并通過驗證后，便可以進行下一步的操作，查找該書的相關信息，如存在，則進行還書操作，如不存在該信息，則給出提示信息;
繪圖步驟：
(1)在用例圖中的還書(revesion)用例，單擊右鍵，如圖3.1所示，新建一個狀態圖，命名為revesion狀態圖，圖3.2所示。
圖3.1
圖3.2 (2)雙擊“receivesion”狀態圖，展開后，在左邊的工具欄上選取一個實心圓點，此結點為開始結點，圖3.3所示;當還書的時候，操作者先要詢問系統的狀態，如果系統忙，操作者則必需等待，因此，得到系統的兩種狀態，如圖3.5所示。
圖3.3
圖3.4
圖3.5 (3)操作者在詢問系統和狀態后，得到的圖3.6所示兩種狀態，如果系統忙，操作者必需要等待、結束，如圖3.7和圖3.8所示，重返步驟(1)。
圖3.6
圖3.7
圖3.8 (4)如系統空閑，則進行對還書的信息進行查詢操作，圖3.9所示;查詢也有兩種結果，一是查詢得到該書的相關信息，二查詢不到該書的相關信息;則此時有兩種狀態，需要建立兩種狀態，如圖3.10所示。
圖3.9
圖3.10 (5)最后，操作者進行了操作后，系統會給出操作的結果給操作者;操作成功或失敗，都會有提示信息給出。整個的還書的過程便完成;圖3.11所示。
(7)根據分析設計情況，進一步添加或細化狀態圖。
圖3.11
五、實驗報告要求
1.整理實驗結果。 2.小結實驗心得體會。
實驗四 活動圖
實驗名稱：活動圖
實驗類型: 設計性實驗 學
時：一天
一、實驗目的
1.熟悉活動圖的基本功能和使用方法。 2.掌握如何使用建模工具繪制活動圖方法。
二、實驗器材
1.計算機一臺。
2.Rational Rose 工具軟件。
三、實驗內容
完成實驗一后，對給定題目的系統的需求的初步分析，得出系統的用例圖，通過對用例的業務流程的分析，我們可以初步了解系統的業務處理流程。本實驗在前面基礎上繪制活動圖，說明用例具體的業務流程。
四、實驗步驟
(1)通過對用例的分析，得到用例執行的具體步驟。以用例“刪除讀者信息”為例，經過分析，一般按照以下步驟進行：
①管理員在錄入界面，輸入待刪除的讀者名;
②“業務邏輯”組件在數據庫中，查找待刪除的讀者名;
③如果不存在，則顯示出錯信息，返回步驟(1)，如果存在則繼續; ④“業務邏輯”組件判斷“待刪除的讀者”是否可以刪除; ⑤如果不可以，則顯示出錯信息，返回步驟(8)，如果可以則繼續; ⑥在數據庫中，刪除相關信息; ⑦顯示刪除成功信息; ⑧結束。
(2)繪制活動圖，以用例“刪除讀者信息為例”繪圖步驟如下：
①在用例圖中，找到刪除的用例，如圖4.1所示，在刪除用例上單擊右鍵，在彈出的快捷菜單中選“New”，Rose工具也會彈出一個菜單，選”Activity Diagram”，選中后單擊，便可以新建好一個活動圖。如圖4.2所示。
圖 4.1
圖4.2 ②新建好活動圖后，雙擊刪除的活動圖，得到如圖4.3所示，然后把在左邊的工具欄內點擊“Swinlane“，在右邊的圖添加一個泳道，如圖4.4所示，并命名為administrator.按照此步驟，再添加另一個泳道，并命名為SystemTool，得到圖4.5。
圖4.3 ③接著在左邊的工具上選取開始點，并在administrator的泳道上添加，如圖4.6所示;添加完開始結點后，再來為此活動圖添加活動，圖4.7所示，在左邊的工具欄上選中Activity這個圖標，在administrator這邊的泳道上添加一個活動，命名為登錄(login)，再在開始結點和活動登錄(login)之間添加活動關系，如圖4.8所示。
圖4.4
圖4.5
圖4.6
圖4.7
圖4.8
④完成步驟②后，登錄輸入需要對輸入的信息進行驗證，則在圖中添加一個驗證框，如圖4.9所示：添加驗證框后，驗證的內容，如果通過，則允許管理員進行查詢操作，如圖4.10所示;如不能通過，則結束，如圖4.11所示。
圖4.9
圖4.10
圖4.11
⑤驗證后，下一步的操作是查詢需要刪除的記錄，添加一個活動，命名為delete，如圖4.12和圖4.13所示。
圖4.12
圖4.13 ⑥最后，在刪除后，系統會返回操作結果給操作者，圖4.14所示;刪除成功或刪除失敗系統都會有信息返回給操作者。
五、實驗報告要求
1. 整理實驗結果。 2. 小結實驗心得體會。
實驗五 順序圖
實驗名稱：順序圖
實驗類型: 設計性實驗 學
時：一天
一、實驗目的
1.理解順序圖的基本概念。
2.掌握在Rational Rose中繪制交互圖的操作方法。
二、實驗器材
1.計算機一臺。
2.Rational Rose 工具軟件。
三、實驗內容
通過對教學內容的學習，我們完成了系統的需求分析，并從業務對象中抽象出了類?，F在需要對前面所給出的用例進行實現，而用例的實現主要由順序圖來指定和描述系統的動態特性。本實驗主要在前面實驗基礎上對用例進行動態建模。
四、實驗步驟
1.通過前面實驗，分析系統中存在的主要交互操作。
2.為每一個交互操作繪制順序圖。以“增加圖書”為例說明繪圖步驟：
(1)在Rose軟件的左邊欄目上的Logicl View單擊右鍵，新建一個時序圖，順序圖可以用時序來表示，如圖5.1;圖中的直線箭頭是發送消息;虛線箭頭是返回消息;曲折線是對象自己給自己發送消息并調用。
(2)接下來的是添加類，系統中的類是其他的方法的邊界，在上面做好的類找到可以直接拖拉來圖中，見圖5.2 和圖5.3所示。
圖5.1
圖5.2
圖5.3 (3)添加類后，便可以添加方法了，開始是必需是外面的實體向系統發送消息，如圖5.4所示，是管理員登錄時向系統發送的消息;
圖5.4 (5)可以按上一步的方法來完成其他的方法，如viladate(驗證),返回驗證結果，當用戶收到結果后，可以正常登錄后便能進行增加圖書見圖5.5到圖5.9。最后得到的時序圖如圖5.10所示。
圖5.5 : administrator1: login : ActionFormSystem2: login3: validate
圖5.6 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result
圖5.7 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add
圖5.8 : administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook
圖5.9
: administrator1: login : ActionFormSystem2: login3: validate4: result5: result6: add7: add8: addbook9: addruselt10: addresult
圖5.10
五、實驗報告要求
1.整理實驗結果。 2.小結實驗心得體會。
第五篇：UML網上售樓系統設計論文
[摘要] 本文設計和實現了一個B/S架構的網上售樓系統。本系統采用UML建模，Web服務器軟件是IIS5.5，開發工具是ASp，后臺數據庫系統是SQL Server 2000，網頁設計軟件是Macromedia Dreamweaver。
[關鍵詞] 網上售樓 UML ASp
網上售樓系統是一個B2C的電子商務流程，售樓本身業務繁多，涉及金額數量大，根據售樓的實際特點，網上售樓系統在售樓業務完成以后，可以為用戶提供支付信息，將會員所要支付的款項收錄在支付信息中，為后續服務提供依據。
一、系統分析與設計
1.系統用例分析與設計。用例是獲取系統功能需求的一種技術，是從參與者的角度來描述系統行為。一個用例就是參與者與系統的一次交互，它表達了系統的功能和所提供的服務。因此，在識別出參與者的基礎上，可確定在網上售樓系統中，有訪客、會員、管理員三個參與者，訪客可以瀏覽樓盤信息、注冊成為會員。會員可以登錄系統、管理個人信息、訂購房屋、退訂房屋、查詢訂單、查詢退單、查詢支付信息、在留言板上留言。管理員可以管理管理員專欄、管理樓盤房屋信息、管理公告信息、管理會員信息、處理訂單、處理退單、管理支付信息、管理留言板。
在分析階段我們分析了訪客用例、會員用例和管理員用例，而在設計階段，所描述的會員和管理員的用例圖是編寫程序代碼、實現系統功能的依據。下面僅以角色權限最大的管理員為例說明(如圖1)。
圖1 管理員用例圖
說明：管理員登錄系統后臺，主要實現幾個大的功能模塊，包括管理會員信息、管理管理員信息、管理留言板、管理公告、管理訂、退、支付單等 。在每個大模塊中，又包含具體的基本功能，主要是增、刪、改、查的操作。
2.系統類圖分析設計與數據庫邏輯設計。類圖描述系統所包含的類、類的內部結構及類之間的關系，表示的是系統中各個對象及其間各種靜態關系。這種靜態關系主要有兩種：關聯和子類型。
類圖分為分析階段的類圖和設計階段的類圖，本系統需要九個類：“會員”、“管理員”、“訂單”、“退單”、“留言”、“公告”、“支付清單”、“樓盤信息”、“房屋信息”(如圖2)。
說明：在對象模型向關系模型的轉化中需將業務邏輯類進行轉化,即將每個業務邏輯類映射為一個數據實體,在數據庫中用一個或多個數據表表示;類屬性映射為數據表的字段。本系統涉及的數據庫表有:“會員表”、“管理員表”、“訂單表”、“退單表”、“留言表”、“公告表”、“支付清單表”、“樓盤信息表”、“房屋信息表”?！?.系統順序圖分析與設計。順序圖顯示了對象之間的動態合作關系，強調對象之間消息發送的時間順序，同時顯示對象之間的交互，順序圖分為分析階段的順序圖和設計階段的順序圖。
設計階段的順序圖是對分析階段在內容上的補充和完善，在系統分析和設計中描述了管理員基本信息管理順序圖、留言順序圖、訪客注冊成為會員順序圖、管理員處理退單順序圖、會員提交訂單順序圖。無法一一描述，僅以訪客注冊會員為例。訪客注冊會員順序圖描述為：兩個參與者，即訪客和管理員。訪客進入售樓系統后可以注冊成為會員。訪客要先填寫并提交注冊信息，當還有必填內容沒有填時，則會出現注冊失敗，系統會自動提示所要填的信息，此時，訪客修改補充并提交，系統將顯示注冊成功。之后，管理員將審核會員信息，如果符合標準，則改變會員狀態，由“未審核”轉變為“已審核”，只有在已審核狀態下的會員才能登錄系統(如圖3)。
二、系統實現
1.系統體系結構。本系統采用B/S架構，B /S模式把處理功能全部移植到了服務器端,用戶的請求通過瀏覽器發出,無論是使用和數據庫維護上都比傳統模式更加經濟方便. 而且使維護任務層次化:管理員負責服務器硬件日常管理和維護,系統維護人員負責后臺數據庫數據更新維護。
2.系統開發工具。本系統采用采用ASp開發WEB應用程序。ASp (Active server pages動態服務器主頁的簡稱) 內含于Internet Information Server(IIS)中,是一套微軟開發的服務器端腳本環境。通過ASp ,可以結合HTML網頁、ASp 指令和ActiveX 元件,建立動態、交互且高效的WEB 服務器應用程序，所有的程序都將在服務器端執行，包括所有嵌在普通HTML中的腳本程序。當程序執行完畢后,服務器僅將執行的結果返回給客戶瀏覽器,這樣也就減輕了客戶端瀏覽器的負擔,大大提高了交互的速度。后臺數據庫系統是SQL Server 2000，網頁設計軟件是Macromedia Dreamweaver。
3.主要界面的實現。本系統分為前臺和后臺兩個部分。前臺主要的界面有：前臺首頁、樓盤信息頁、房屋信息明細頁、公告首頁、公告內容頁、注冊頁、留言頁、會員修改個人信息頁、提交訂單頁、查看訂單頁、提交退單頁、查看退單頁、支付信息明細頁等;后臺主要的界面有：審核會員頁、發布公告頁、公告保存頁、管理留言板頁、查看會員信息頁、刪除會員信息頁、修改會員信息頁、查看訂單并受理頁、訂單生成支付信息頁、訂單生成支付信息明細頁、管理員查看支付信息明細頁等(如圖4)。
三、總結
本文結合使用了UML 和ASp, 設計并實現了網上售樓系統。采用UML 建模語言進行分析,具有靈活、高效的特點,為進行可視化系統的開發提供了極大的方便。
參考文獻:
[1]鄺孔武王曉敏:信息系統分析與設計[M].清華大學出版社.2006
[2]陳剛李建義:數據庫系統原理及應用[M].中國水利水電出版社. 2003