第一篇：02軟件設計說明書
文檔編號： LMS-02 版 本 號：
V1.0
文檔名稱： 項目名稱：
軟件設計說明書 學生考勤管理系統
編寫： 學號：10006410 姓名：李春林 校對： 學號：10006410 姓名：李春林 審核： 學號：10006410 姓名：李春林 日期： 院系： 專業：
2013年5月8日
通達學院 計算機科學與技術 1.引言 1.1 編寫目的
要求《學生考勤管理系統》對學校全體學生的資料和考勤情況進行管理，通過每日的打卡把出勤信息輸入到學校的考勤管理中心，保存學生每日的出勤情況，以便統計學生的出勤情況。同時方便班長查閱，即節省了人力，又省去了中間的很多容易出錯的步驟。讓學校學生的考勤管理更具有透明性，且方便管理。
明確所要開發的軟件應具有的功能、性能，是系統分析人員和軟件設計人員能清楚地了解用戶的需求，并在此基礎上進一步提出概要設計和完成后續設計與開發工作，為軟件開發范圍、業務處理規范提供依據。根據《需求規格說明書》，在仔細考慮討論之后，我們又進一步對《學生考勤管理系統》軟件的功能劃分、數據結構、軟件總體結構進行設計，從而完成概要設計，作為軟件詳細設計的基礎。
1.2 項目背景
項目委托單位：計算機學院軟件工程系。
開發單位：*************************************。
考勤作為一個基礎管理，是學校對學生進行管理的基本依據。實際管理和記錄工作非常需要快速獲知各個年級學生的每日出勤情況，以便于及時向班長反映學生出勤、缺勤情況（包括遲到、早退、病假、事假、曠課等情況）。因此此系統在操作系統的基礎上，結合Accese數據庫管理系統，運用VC++來實現運行。
1.3 定義
學生考勤管理系統
GUI：Graphic User Interface,圖形用戶界面。
1.4 參考資料
[1] 國剛 周峰 孫更新編著
《UML與Rational Rose 2003》 北京：電子工業出版社 2007
[2] 彭德中編著《軟件工程—理論與實踐》 高等教育出版社 2004 [3] 李佳若 《Accese2002數據庫應用》 人民郵電出版社 2006
[4] 《學生考勤管理系統》 曲阜師范大學計算機科學學院06級2班 第二小組 2.任務概述 2.1 目標
《學生考勤管理系統》相應的需求有：
1.具有輸入、查詢、刪除、修改記錄的任課老師，學院領導以及系統開發人員等系統管理員；
2.具有查詢記錄的學生作為普通用戶； 3.能夠對需要的統計結果提供打印輸出；
4.能夠提供一定的安全機制，提供數據信息授權訪問，防止隨意刪改，同時提供信息備份的服務。
a)運行環境
Intel486以上系列、AMD K6 以上系列等PC臺式機和便攜式電腦； 運行時占用內存：≤1MB； 所需硬盤空間：≤5MB；
軟件平臺：中文Windows2003/xp或更高版本；
b)條件與限制
由于時間比較短，使用計算機不方便以及對于網絡編程不熟悉，本圖書館管理系統并沒有提供數據的遠程訪問功能。對信息的保護手段僅限于設置用戶級別，以及提供數據文件的備份，比較簡單，安全性能有待進一步完善。5.總體設計 3.1 處理流程
1.主流程
1)建立與數據庫的連接 2)獲取系統設置
3)顯示主對話框（即主界面）
4)等待用戶輸入，如為學生：進入學生考勤流程（顯示學生對話框）。如為教師：進入教師工作流程（顯示教師對話框）。如為院系領導：進入院系領導流程（顯示院系領導對話框）。如為系統管理:進入系統管理流程（進行授權）。如為退出：檢查所有子窗口，關閉對話框，斷開與數據庫的連接
2.學生考勤流程
1)要求用戶輸入學號，姓名 2)學生身份檢驗
3)獲取相關的學生信息并顯示
4)等待用戶輸入，如為確認輸入操作：讀入操作，提交請求，更新信息顯示，把操作信息寫入考勤訪問記錄文件進行備份，顯示考勤操作結果。如為完成相應操作：結束學生流程。
3.教師工作流程
1)等待用戶輸入：如為確認輸入教師號：讀入教師號，提交教師請求，顯示教師操作的返還信息。如為查詢考勤狀態：顯示考勤信息，如為退出：結束教師工作流程。
4.院系領導流程
1)等待用戶輸入，如為確認輸入院系領導：讀入院系領導，顯示相應操作，顯示操作結果。如為退出狀態：結束該流程。
5． 系統管理流程
1)要求用戶輸入賬號及口令 2)用戶操作權限檢驗
3)根據操作權限級別顯示系統管理對話框
4)等待用戶輸入，如為請假操作：進入請假操作流程。如為學生考勤庫操作：進入學生考勤庫操作流程。如為數據統計：進入數據統計流程。如為更改口令：要求用戶輸入口令，檢驗正確后更新。如為返回：結束系統管理流程
6． 請假操作流程 1)顯示請假信息
2)等待用戶輸入，如為事假： 要求輸入原因、時間，提交申請，等待審批。如為病假： 要求輸入時間和相應證明的照片，確認為病假，等待審批。
7． 查詢操作流程 1)顯示學生考勤信息
2)等待用戶輸入，如為學生： 輸入學生號，查詢記錄，顯示數據。如院系領導：輸入口令，查看是否有學生請假或病假審批，要求及時返回審批結果，修改相應信息。刷新數據顯示。如為返回：更新當前記錄，結束學生考勤操作流程。
8． 數據統計流程
1)等待管理員輸入，如為開始統計： 讀入統計條件，生成統計結果并顯示。如為返回：結束統計流程。
3.2
3.2.1 總體結構
1)主模塊調用：
2)學生考勤模塊調用：學生身份檢驗模塊，考勤查詢模塊，請假申請模塊
數據庫操作模塊
3)教師工作模塊調用：訪問記錄模塊，確認考勤記錄模塊，考勤查詢模
塊，教師身份檢驗模塊
數據庫操作模塊
4)院系領導模塊調用： 訪問記錄模塊，審批請假模塊，考勤查詢模塊，院系領導身份檢驗模塊
學生考勤模塊，教師工作模塊，院系領導模塊，系統管理模塊。總體結構和模塊外部設計
數據庫操作模塊
5)管理員模塊調用： 管理員身份檢驗模塊，考勤操作模塊，數據顯示
模塊
5)考勤查詢模塊調用： 查詢命令生成模塊，數據庫查詢模塊
數據顯示模塊
6)系統管理模塊調用： 考勤操作模塊，各身份檢驗模塊
數據統計模塊，更改口令等設置模塊
7)身份檢驗模塊調用： 數據庫查詢模塊
8)考勤檢驗模塊調用：
9)考勤記錄模塊調用：
數據庫查詢模塊
10)考勤操作模塊調用： 考勤記錄集獲取模塊，當前記錄更新模塊
更新顯示模塊，數據庫查詢模塊
11)數據統計模塊調用： 查詢命令生成模塊，數據庫查詢模塊
數據顯示模塊
12)當前記錄更新模塊： 數據庫操作模塊
13)考勤記錄集獲取模塊： 數據庫查詢模塊
3.2.2 模塊外部描述
1)主模塊：從操作系統獲得程序運行所需資源，顯示主對話框，完成消息處理，調用相應的子模塊。
2)學生考勤信息模塊：檢驗輸入的學生學號，獲取相關的學生信息并根據操作結果予以刷新，讀入用戶輸入的學生學號，檢驗學號信息確定操作合法性，對合法學生考勤操作，登記入訪問記錄庫，數據庫查詢模塊
數據庫操作模塊 對非法的學生考勤操作，提出警告，并返回。
3)學生考勤信息模塊：檢驗輸入的學生學號，獲取相關的學生信息并根據操作結果予以刷新，讀入用戶輸入的學生學號，檢驗學號信息確定操作合法性，對合法學生考勤操作，登記入訪問記錄庫，對非法的學生考勤操作，提出警告，并返回。
4)教師工作模塊：檢驗輸入的教師號，獲取相關的教師信息并根據操作結果予以刷新，讀入用戶輸入的教師號，檢驗教師號信息確定操作合法性，對合法教師號操作，登記入訪問記錄庫，對非法教師號操作，提出警告，并返回。
5)院系領導模塊：檢驗輸入的口令，獲取相關的領導信息并根據操作結果予以刷新，讀入用戶輸入的口令，檢驗口令確定操作合法性，對合法領導操作，登記入訪問記錄庫，對非法領導操作，提出警告，并返回。
6)學生考勤信息查詢模塊：根據用戶界面的輸入生成數據庫查詢命令，向數據庫提交查詢請求，查詢并顯示查詢操作的結果。7)系統管理模塊：根據用戶輸入檢驗操作權限，根據用戶輸入選擇調用不同的子模塊，根據不同的操作權限，對數據進行保護。8)身份檢驗模塊：根據輸入的證號或口令生成查詢語句，查詢數據庫，返回查詢結果。
9)請假申請模塊：根據請假原因進行審批，返回請假成功/失敗結果。
10)訪問記錄檢驗模塊：根據學生學號生成查詢語句，調用數據庫查詢模塊查詢借書記錄，返回查詢結果。
11)系統操作權限查驗：檢驗是否正確的用戶與口令，返回相應的操作級別。
12)學生考勤信息庫操作模塊：顯示考勤信息的數據項，根據院系領導或管理員輸入修改，增加或刪除。
13)數據統計模塊：根據用戶輸入，生成查詢命令，根據要求進行查詢，將所得結果顯示給用戶。
14)數據庫操作模塊：根據輸入的數據庫操作命令，完成相應操作，將操作結果返回。
15)查詢命令生成模塊：將用戶界面的輸入轉換成為數據庫查詢命令 16)數據庫查詢模塊：根據輸入的數據庫查詢命令，進行查詢，將查詢生成的結果返回。
17)數據顯示模塊：將數據按照一定格式顯示(列表),根據用戶輸入,調整格式。功能分配
1瀏覽功能：學生考勤信息庫操作模塊
查詢功能：學生考勤信息庫操作模塊
插入功能：學生考勤信息庫操作模塊
修改功能： 學生考勤信息庫操作模塊
刪除功能：學生考勤信息庫操作模塊
授權功能： 系統操作權限檢驗模塊
數據統計模塊
管理員操作模塊 管理員操作模塊 管理員操作模塊
3.3
6.接口設計 4.1 用戶接口
使用基于對話框的GUI，用戶通過鼠標的點擊和鍵盤的輸入完成操作，編輯框用于用戶的輸入。
4.2 外部接口
1．用戶界面
使用Windows的標準對話框的形式，完全用對話框實現。應用工具：Visual C++。
1)主對話框：由六個功能按鈕構成
學生、教師、院系領導、管理員、幫助、退出
2)學生對話框：
學生學號編輯框： 用于輸入學生學號； 學生信息顯示區： 用于顯示學生信息(姓名)； 學生考勤信息顯示區：用于顯示學生考勤信息 學生請假顯示區：用于輸入學生請假申請； 請假申請提交按鈕：提交請假申請請求； 退出按鈕：退出學生對話框。
3)教師工作對話框：
教師號編輯框：用于輸入教師號；
教師信息顯示區：用于顯示教師信息(教師號、教師姓名，教授課程號)； 學生考勤信息顯示區：用于顯示學生考勤(正常、請假、曠課、遲到、早
退等)；
提交按鈕：用于提交確認學生考勤信息； 返回按鈕：用于退出教師對話框。
4)院系領導對話框：
院系領導口令編輯框：用于輸入領導口令
學生考勤信息顯示區：用于顯示學生考勤(正常、請假、曠課、遲到、早
退等)；
學生請假顯示區：用于輸入學生請假審批； 時間編輯框：用于編輯年與月； 退出按鈕：用于院系領導對話框；
5)管理員對話框：
管理員口令編輯框：用于輸入管理員口令；
學生考勤信息顯示區：用于顯示學生考勤(正常、請假、曠課、遲到、早
退等)；
學生考勤信息修改編輯框：用于修改某些特殊情況的學生信息； 學生考勤信息錄入編輯框：用于錄入學生考勤信息；
6)系統操作對話框：由六個功能按鈕構成
學生考勤信息庫操作、數據統計、數據備份、更改口令、返回。
7)學生考勤信息庫對話框：
學生學號編輯框：用于顯示學生學號； 學生姓名編輯框：用于顯示學生姓名； 課程號編輯框：用于顯示相應的課程號； 事假申請編輯框：用于顯示事假申請； 病假申請編輯框：用于顯示病假申請； 遲到編輯框：用于顯示遲到； 早退編輯框：用于顯示早退； 曠課編輯框：用于顯示曠課；
“前一個”按鈕：顯示和編輯前一個記錄； “后一個”按鈕：顯示和編輯后一個記錄；
“移動到”按鈕：顯示和編輯指定學生學號的考勤信息； “修改”按鈕：修改某些特殊情況考勤信息； “添加”按鈕：增加學生考勤信息； “刪除”按鈕：刪除當前的學生考勤信息； “退出”按鈕：退出學生考勤信息庫操作對話框。
8)數據統計對話框：
統計條件單選框：用于選擇統計條件類別(學生、教師、院系領導、管理
員情況)；
學生考勤統計條件復選框：用于指定統計條件包含的相關項(學生學號、學生姓名)；
教師統計條件復選框：用于指定統計條件包含的相關項(教師號、學生學
號、課程號)； 院系領導統計條件復選框：用于指定統計條件包含的相關性(領導口令、相關操作、審批日期)；
統計輸出設置單選框：用于選擇統計結果的輸出類別；
學生考勤統計輸出設置復選框：用于指定輸出項(學生學號、考勤狀態)； 教師統計輸出設置復選框：用于指定輸出項(教師號、課程號、查詢的考
勤狀況)；
院系領導輸出設置復選框：用于指定輸出項（領導口令、審批結果、審
批日期、查詢信息）
管理員輸出設置復選框：用于指定輸出項（管理員口令、考勤狀態）
“開始統計”按鈕：提交統計請求； “返回”按鈕：退出數據統計對話框。
9)更改口令對話框：
舊口令輸入框：輸入舊口令； 新口令輸入框：輸入新口令；
新口令確認輸入框：再輸入一次新口令； 確認按鈕：確認輸入的新口令，并提交。
2．軟件接口
使用Access數據庫的驅動程序，通過ODBC接口訪問。
4.3 內部接口 1.主模塊：
輸入：操作系統傳遞至的各種消息以及用戶的輸入數據 輸出：用戶界面顯示 上層模塊：無
下層模塊：學生考勤模塊、教師工作模塊、院系領導模塊、系統管
理模塊
2.學生考勤模塊：
輸入：學生學號、課程號 輸出：考勤信息 上層模塊：主模塊
下層模塊：學生考勤檢驗模塊、請假模塊、訪問記錄登記模塊、相
關信息獲取模塊。
3.教師工作模塊： 輸入：教師號、學生號 輸出：查詢信息、確認信息 上層模塊：主模塊
下層模塊：訪問記錄檢驗模塊、相關信息獲取模塊。
4.院系領導模塊：
輸入：領導口令
輸出：審批結果、查詢信息 上層模塊：主模塊
下層模塊：訪問記錄檢驗模塊、相關信息獲取模塊。
5.系統操作模塊：
輸入：與系統管理對話框有關的各種用戶及系統消息 輸出：
上層模塊：主模塊
下層模塊：系統操作權限檢驗模塊、考勤信息庫操作模塊、數據統
計模塊。
6.各身份檢驗模塊：
輸入： 身份驗證號 輸出：合法非法用戶標志 上層模塊：對應身份模塊 下層模塊：數據庫查詢模塊
7.相關信息獲取模塊：
輸入：身份驗證號
輸出：與身份驗證號匹配的記錄集 上層模塊：對應身份模塊 下層模塊：數據庫查詢模塊
8.訪問記錄登記模塊：
輸入：身份驗證號 輸出：操作結果信息 上層模塊：對應身份模塊 下層模塊：數據庫操作模塊
9.查詢命令生成模塊：
輸入：用戶界面的輸入
輸出：數據庫查詢命令(SQL命令)上層模塊：查詢模塊、數據統計模塊 下層模塊：無
10.數據顯示模塊：
輸入：數據庫操作的結果集 輸出：用戶界面的數據列表顯示 上層模塊：查詢模塊、數據統計模塊。下層模塊：無
11.系統操作權限檢驗模塊：
輸入：用戶名、用戶口令 輸出：合法/非法用戶標志 上層模塊：系統操作模塊 下層模塊：數據庫查詢模塊
12.顯示更新模塊
輸入：
輸出：用戶界面顯示
上層模塊：學生考勤信息庫操作模塊、、系統設置模塊。下層模塊：
13.更新當前記錄模塊
輸入：
輸出：操作結果信息
上層模塊：學生考勤信息庫操作模塊、系統設置模塊 下層模塊：數據庫操作模塊
14.數據統計模塊：
輸入：統計方式及其關鍵字 輸出：統計結果視圖顯示 上層模塊：系統操作模塊
下層模塊：查詢命令生成模塊、數據庫查詢模塊、數據顯示模塊
15.數據庫操作模塊：
輸入：數據操作命令 輸出：
上層模塊：學生考勤模塊 下層模塊：無
16.數據庫查詢模塊：
輸入：數據查詢命令 輸出：查詢結果集
上層模塊：各身份檢驗模塊、訪問記錄登記模塊、相關信息獲取模
塊、查詢模塊、系統操作權限查驗模塊、數據統計模塊、系統設置模塊。
下層模塊：無
4.4 功能分配
瀏覽功能：學生考勤信息庫操作模塊
查詢功能：學生考勤信息庫操作模塊
插入功能：學生考勤信息庫操作模塊
修改功能： 學生考勤信息庫操作模塊
刪除功能：學生考勤信息庫操作模塊
授權功能： 系統操作權限檢驗模塊
管理員操作模塊
管理員操作模塊
管理員操作模塊
數據統計模塊
7.數據結構設計 5.1 邏輯結構設計
學生考勤表：由多個學生考勤記錄構成
學生考勤記錄的數據結構如下： 學生學號
學生姓名
院系
年級
專業
性別
遲到
早退
曠課
請假
整數（唯一標識）
變長字符串 變長字符串 變長字符串 變長字符串 變長字符串 變長字符串
變長字符串
變長字符串 變長字符串
教師表：由多個教師記錄構成
教師記錄的數據結構如下：
教師號 課程號
整數（唯一標識）
變長字符串 變長字符串 教師姓名
院系領導表：由多個院系領導記錄構成
院系領導記錄的數據結構如下：
院系領導口令
院系領導姓名
整數（唯一標識）變長字符串
訪問記錄表：由若干個訪問記錄構成
請假記錄的數據結構如下： 請假學生學號(BookID)姓名(ReaderID)請假時間(BorrowDate)銷假學生學號(BookID)姓名(ReaderID)還書時間(ReturnDate)
整數（與學生考勤庫中的學生學號對應）(唯一標識)
變長字符串（與學生考勤庫中的姓名對應）
日期
整數（與學生考勤庫中的學生學號對應）(唯一標識)
變長字符串（與學生考勤庫中的姓名對應）日期 銷假記錄的數據結構如下：
系統操作員記錄表：由若干個系統操作員記錄構成 系統操作員記錄的數據結構如下：
記錄序號(id)整數(系統自動生成，唯一標示符)賬號(Administrater)口令(Password)
5.2 物理結構設計 數據的物理結構由使用的數據庫決定。
5.3 數據結構與程序的關系 主模塊：連接數據庫；
學生考勤模塊：指定學號，姓名，讀出考勤狀態，記錄考勤時期，對應課程號的相關信息，并把相關信息記錄到訪問記錄模塊中。
教師模塊：指定學號，教師號，讀出學生考勤狀態，對考勤狀態確認，記錄查詢日期，教師的相關信息，并把相關信息記錄到訪問記錄模塊中。
院系領導模塊：制定學號，院系領導號，讀出學生考勤狀態和請假申請相關信息，對請假申請進行審批，并把相關信息記錄到訪問記錄模塊中。
查詢模塊：指定查詢條件，提交給數據庫操作模塊。
系統操作模塊：對學生考勤信息庫操作，調用數據庫操作模塊對各個庫進行相應操作，對數據進行備份，在授權操作中檢驗用戶身份。
權限級別(Level)
變長字符串 變長字符串 整數 8.運行設計 6.1 運行模塊的組合
程序啟動后，進入主模塊，用戶的單擊對話框按鈕事件觸發主模塊調用各下層模塊，進入對應的子對話框，同樣由用戶的輸入觸發這些模塊調用其下層模塊，完成相應操作。
6.2 運行控制
本軟件控制流程：主程序運行，等待用戶的輸入，根據用戶的輸入調用各子模塊。
6.3 出錯處理及安全保密設計
1.提供豐富的出錯提示信息； 2.提供一定的保密手段。
6.4 維護設計
第二篇：軟件設計說明書
設計說明書 引言
水利方向一直是國家十分重視且投入巨大的方向，它關乎方方面面。百姓生命安全、水資源的利用、農業的灌溉等等，都與其息息相關，但是，正因為它的無處不在，導致如果使用傳統的手段，將需要消耗過多的人力，效率極其低下，甚至是不可完成的，所以，水利也需要更加現代化的手段去完成預期的目標，水利自動化就是為了這一目的而提出來的。水利自動化可以大大提高數據測量的準確度和控制的可靠性，提高效率，降低勞動強度，充分利用現有設備，從而對于當地水利單位和水利公司均能帶來可觀的經濟和社會收益。
1.1 編寫目的
a.編寫本說明書的目的在于闡明用戶的要求的，描述出系統的需求模型、功能和性能要求以及其他約定，為后期的軟件設計等工作提供依據。
b.本說明書的預期讀者為用戶、系統設計員及其他開發人員和相關審核檢測人員。
1.2 背景
本項目的任務提出者及開發者是北京恒宇偉業科技發展有限公司生產部開發小組：
項目負責人：
硬件設計工程師：
系統分析員：
系統設計員：
編碼員：
軟件測試員：
用戶為各地方招標業主單位，該軟件在WINDOW7系統下，在IAR FOR MSP430環境下完成開發，1.3 定義
RTU：遠程終端單元。
水文監測系統：是指用于對各類水文要素實施采集、傳輸、處理的總體。
1.4 參考資料
水文檢測數據通信規約(SL651-2014)2 設計總體
2.1 需求規定
本軟件系統的各種用戶是唯一的參與者，參與者通過使用事件與系統進行交互，所有的使用事件綜合起來即構成了用戶的功能需求。本系統通過用戶操作鍵盤操作及顯示屏顯示交互設定相關系統、通訊、傳感器參數，查看歷史數據和系統運行狀態。
2.2運行環境
本軟件屬于工業級產品設備運行系統，運行在基于MSP430F5438A CPU芯片的自助設計的電路板上。部分操作依托于外部傳感器設備。
2.3 基本設計概念和處理流程
2.4 結構
初始化函數流程圖
Main函數流程圖
數據發送流程圖
水位數據采集流程圖
雨量數據采集流程圖
數據處理模塊流程圖
輸入數據處理模塊
2.5 功能需求與程序的關系
主程序函數
main();系統滴答初始化
Init_CLK();
GPIO口相關映射初始化
Init_Port();
;UART口相關初始化
Init_RSUART()
;鍵盤相關初始化
Init_Keypad();菜單鏈表初始化
Init_Menu();系統時鐘讀取
RX8025_R();本地網絡修復模塊
NetFix();輸入數據處理模塊
IO_ReportDeal();菜單模塊
Menu_Ctrl();雨量數據處理模塊
Msg_RainDDeal();水位數據處理模塊
Msg_WaterDeal();報文拼組模塊
Msg_PostDeal();數據發送模塊
NT_SendMsg();系統參數變更存儲模塊
SysParSave();
2.6 人工處理過程
用戶通過鍵盤及顯示屏，依靠系統菜單，對相關內容進行設置，以達到按照具體需求運行程序獲得預期效果的結果。
2.7 尚未解決的問題
未能對攝像頭圖片數據進行采集及傳輸。接口設計
3.1 用戶接口
通過菜單項提供用戶接口,其操作簡單、功能直觀,故不再詳述,用戶接口如下： 主菜單：系統參數 通訊參數 傳感器參數 歷史數據 當前通訊狀態
系統參數：終端號 系統時鐘 密碼設置 次雨量清零 人工置數 修改密碼 恢復出廠設置 通訊參數：起始發送時間 當日發送次數 GPRS設置 GSM設置
傳感器參數：水位計類型 雨量計精度 水位預警值 水位變化閾值 水位基值 歷史數據：歷史數據查詢 歷史數據清空
當前通訊狀態：信號強度 網絡通訊狀態 實時時鐘
3.2 內部接口
按鍵中斷響應
#pragma vector=PORT1_VECTOR __interrupt void Port1(void)雨量中斷響應
#pragma vector=PORT2_VECTOR __interrupt void Port2(void)普通串口中斷響應
#pragma vector=USCI_A0_VECTOR __interrupt void USCI_A0_ISR(void)GPRS通訊串口中斷響應
#pragma vector=USCI_A1_VECTOR __interrupt void USCI_A1_ISR(void)485中斷響應
#pragma vector=USCI_A2_VECTOR __interrupt void USCI_A2_ISR(void)232中斷響應
#pragma vector=USCI_A3_VECTOR __interrupt void USCI_A3_ISR(void)
3.3 外部接口
硬件接口：
標準串口，485口，232口，格雷碼口，模擬量輸入口，12V供電輸出口，24V供電輸出接口 軟件接口：
關聯程序：編譯器等
運行設計
4.1 運行模塊組合
水位采集模塊→處理模塊→報文拼組模塊→數據發送模塊→歷史數據存儲模塊 雨量采集模塊→處理模塊→報文拼組模塊→數據發送模塊→歷史數據存儲模塊 按鍵響應模塊→菜單模塊→系統參數更新存儲模塊 輸入數據處理模塊→報文拼組模塊→數據發送模塊
4.2 運行控制
由用戶通過菜單選項進行控制。
4.3 運行時間
根據當前時間的采集任務及發送任務量決定 系統數據結構設計
5.1 邏輯結構設計要點
本系統各功能緊密結合，為盡量避免相互影響出現錯誤，系統嚴格按照時間順序運行，保證數據的絕對準確，各端口數據獨立接收，統一處理，保證數據不會混雜的前提下，保證更高的處理效率。系統出錯處理設計
6.1 出錯信息
當軟件進行硬件運行檢查，發生錯誤會重復啟動多次避免偶然情況導致硬件運行不正常，在多次檢驗無法通過時，會在顯示屏提示出錯原因，保住維護人員排查原因。
6.2 補救措施
故障出現后可能采取的變通措施，包括：
a.通過對系統參數進行分析，自主判斷問題原因，并采用預置的解決方案進行解決。
b.通過在程序各函數打印運行LOG并向串口發送，幫助排查人員了解當前運行情況，便于解決問題 c.恢復及再啟動技術說明將使用的恢復再啟動技術，使軟件從故障點恢復執行或使軟件從頭開始重新運行的方法。
6.3 系統維護設計
正確性維護：在運行過程中發現錯時，根據發生錯誤的功能項找到相應模塊，對出錯模塊單獨測試和修改。適應性維護：軟件的運行平臺限定特定硬件平臺上，限定住可能出現問題的范圍，便于排查。
完善性維護：為了應對用戶新提出的要求或改善性能，增加新的功能時，由于系統模塊間的獨立性，新功能通常可以單獨形成新的模塊，經測試后拼加到系統中，而對其他模塊影響不大；改善某模塊的性能（提高處理效率，改善程序結構等）時，只需對相應模塊進行改進，然后還原到系統中。
第三篇：庫存管理系統軟件設計說明書
引言........................................................................................2
1.1 編寫目的........................................................................2
1.2 背景及意義....................................................................3
1.3 國內外研究現狀............................................................4 2 系統總體設計分析...............................................................5
2.1 軟件功能及模塊設計....................................................5
2.1.1 軟件主要功能.........................................................6
2.1.2 軟件模塊組成.........................................................6
2.2 開發環境及性能優化....................................................7
2.2.1開發環境....................................................................7 3 各模塊軟件設計與實現.......................................................7
3.1系統管理模塊...................................................................7
3.2進貨管理模塊.................................................................14
3.3 出貨管理模塊.................................................................17
3.4報表統計模塊.................................................................17
3.5信息查詢模塊.................................................................18
引言 1.1 編寫目的
“公正、公平、合理”的企業管理理念和企業管理水平的提高，使社會對庫存管理系統有了更高的需求；同時由于個人電腦的普及，數據庫技術、客戶/服務器技術，特別是Internet/Intranet技術的發展，使的三代庫存管理系統的出現才成為必然。庫存管理系統的特點是從物品管理的角度出發，用集中的數據庫將幾乎所有與物品相關的數據統一管理起來，形成了集成的信息源。有好的用戶界面，強有力的報表生成工具、分析工具和信息的共享使得物品管理人員得以擺脫繁重的日常工作，集中精力從戰略的角度來考慮企業物品規劃和政策。
企業的庫存物資管理往往是很復雜、很繁瑣的。由于所掌握的物資種類眾多，訂貨、管理、發放的渠道各有差異，各個企業之間的管理體制不盡相同，各類統計報表繁多，因此倉庫的庫存管理必須編制一套庫存管理信息系統，實現計算機化操作，而且必須根據企業的具體情況制定相應的方案。
根據當前的企業管理體制，一般的庫存管理系統，總是根據所掌握的物資類別，相應分成幾個科室來進行物資的計劃，訂貨，核銷托收，驗收入庫，根據企業各個部門的需求來發送物資設備，并隨時按期進行庫存盤點，作臺帳，根據企業領導和自身管理的需要按月、季度、進行統計分析，產生相應報表。為了加強關鍵物資、設備的管理，要定期掌握其儲備，消耗情況，根據計劃定額和實際纖毫定額的比較，進行定額管理，使得資金使用合理，物資設備的儲備最佳。
一個完整的企業物資供應管理系統應包括采購計劃管理，合同收托管理、倉庫庫存管理、定額管理、統計管理、財務管理等模塊。其中倉庫的庫存管理是整個物資供應管理系統的核心。因此有必要開發一套獨立的庫存管理系統來提高企業工作效率, 而所使用的這套庫存管理系統是企業生產經營管理活動中的核心，此系統必須可以用來控制合理的庫存費用、適時適量的庫存數量，使企業生產活動效率最大化。
1.2背景及意義
進行庫存管理的意義就在于：它能確保物暢其流，促使企業經營
活動繁榮興旺。不論什么企業，都要儲備一些物資。以生產為主的企業，不儲備一定的物資，不能維持其連續生產；服務性行業，也要備置某些需用的設備和服務用具；就連一般的事業單位，也要備有某些辦公用品等。因此，各行各業都存在不同程度的庫存管理業務。
實行庫存管理有如下優點：
（一）有利于資金周轉
因為在某些特殊情況下，可以做到將庫存需要的投資額規定為零。為此可使經營活動更為靈活，把用于建立原材料、制成品、商品等常備庫存所需要占用的資金轉為經營其他項目，這就有可能使經營活動向更新、更高的階段發展。
（二）促使生產管理更為合理
這是因為庫存管理工作的目標之一就是必需的物資，即在需要時，按需要量供應。目前生產管理較為混亂的主要原因在于一些急需的物資不能及時供應，要從根本上杜絕此類現象，就要認真搞好庫存管理。
（三）有利于順利地進行運輸管理，也有助于有效地開展倉庫管理工作
通過庫存管理，可將原來零零散散放置的物料整理得井然有序，可使企業的生產環境整潔一新，實現文明生產。廢舊物料堆放整齊、報廢的設備及時運走，工廠的空地整潔干凈，這樣的環境，自然令人感到心情舒暢。此外。還可以把經常動用的物料以及危險性物料分片保管，以保證工廠的安全生產。
庫存管理工作的好壞，對改善企業生產環境將起著舉足輕重的作用。
1.3 國內外研究現狀
由于庫存管理在經濟管理中占重要地位，其計算機化在發達國家中也已經達到了相當高的水平。我國在全國范圍內推廣計算機在管理中的應用，是在70年代末開始的，雖然起步較晚，近幾年發展卻較快，特別是微型計算機的出現和普及為信息處理提供了物美價廉的手段，對于推動我國管理信息處理的現代化起了重要的作用。
庫存管理對企業來說是一項繁瑣復雜的工作，每天要處理大量的單據數據。為及時結清每筆業務，盤點庫存和貨物流動情況，保證企業生產用料以及貨物安全，庫管人員要花費大量人力物力和時間來做數據記錄統計工作。
在世界發達國家，庫存管理的計算機化水平已經很高了，盡管我國的生產企業在這方面也有了很強的意識和長足的進步，但仍存在這樣、那樣的一些問題。
有的企業單位的庫存管理部分目前仍為手工、半手工操作。從供應單位辦理入庫登記開始，到使用單位輸領料出庫手續為止，所有操作基本上都是由倉庫管理人員筆寫，手理，加上算盤、計算器來完成。這不僅煩瑣，效率低，而且缺乏庫存管理的一些基本手段，如庫存狀況統計，查詢經濟訂貨量計算等，這給企業在一定程度上造成了管理上的落后，及經濟利益上的損失。有的單位的庫存管理部已上了微機，但對微機的利用效率極低，有的在用它打游戲，有的僅把它當計算器或打字機來用。有的企業單位既有了微機同時也有了庫存管理軟件，但硬件上去了，軟件上不去。因為他們用的庫存管理軟件，大多為自己的工作人員及其他一些非專業人員所開發的簡單的管理程序，很難稱得上是“庫存管理信息系統軟件”這些程序的弱點多表現為：
1、系統開發時無科學的理論支持。
2、開發過程中調研不全面。
3、軟件編寫時模型不清晰完整。
4、所用開發工具落后（如Fox base）。
計算機在管理中的應用開始于1954年，當時美國首先用計算機處理工資單。40多年來，計算機在處理管理信息方面發展迅速。例如，60年代美國計算機在管理中應用項目不到300項，到了1975年達到2670項。而現在，美國在財務會計上90%的工作由計算機完成；物資管理中80—100%的信息處理由計算機完成；計劃管理中是80—90%。據計算機應用方面發展較快的國家統計，計算機用于經濟管理的約占80%；用于科技運算的占8%；用于生產過程控制的占12%。因此，經濟管理是計算機應用的主要領域。系統總體設計分析 2.1 軟件功能及模塊設計 2.1.1 軟件主要功能
庫存管理系統軟件能達到如下具體功能要求： 1）系統管理模塊 2）進貨管理模塊 3）出貨管理模塊 4）報表統計模塊 5）信息查詢模塊 2.1.2 軟件模塊組成
本軟件包括五個模塊：系統管理、進貨管理、出貨管理、報表統計、信息查詢。庫存管理系統總體設計框圖
圖2-1 系統總體設計框圖
2.2 開發環境及性能優化
2.2.1開發環境
數據庫：Microsoft SQL Server 2000 前端開發工具：Visual C#.NET 數據訪問對象：ADO 各模塊軟件設計與實現 3.1 系統管理模塊
系統管理模塊分為4種功能：身份驗證功能、注冊用戶功能、修改刪除用戶功能、修改密碼功能。身份驗證功能
在進入系統主界面之前，會出現一個身份驗證對話框，要驗證用戶的身份。本系統中用戶分為管理員、倉庫管理員和經理三種。不同用戶其權限也不同。
用戶通過庫存管理系統界面登錄進入系統。在其輸入用戶編號與密碼之后，單擊“確定”按鈕登錄數據庫（為了方便用戶，本系統允許用戶在輸入密碼之后直接按回車鍵登錄數據庫，而無須使用鼠標單擊“確定”按鈕）。此時觸發“確定”按鈕的Click事件相應函數。在這個事件響應函數中，需要首先判斷用戶，因為他們具有不同的權限。如果權限是0，則進入系統管理員界面；權限是1，則進入經理界面；權限是2，則進入倉庫管理員界面。
圖3-1 系統登錄界面
由于用戶權限的差異，他們所能進入的系統主界面也相應的不同。
圖3-2 系統主界面一（系統管理員身份進入）
圖3-3 系統主界面二（經理身份進入）
圖3-4 系統主界面三（倉庫管理員身份進入）
注冊用戶功能 以下為注冊用戶界面：
圖3-5 系統管理員注冊用戶界面
注冊用戶成功界面：
圖3-6 注冊用戶成功界面
修改刪除用戶功能 修改刪除用戶界面如下：
圖3-7 系統管理員修改刪除用戶界面
修改密碼功能
對一個完整的系統而言，用戶是應該可以修改自己的密碼的，因此系統中應該具有修改密碼的功能，提高數據的安全性，用戶可以在進入系統主界面后可以修改自己的密碼。當用戶輸入完成之后，按“確定”按鈕來關閉對話框，系統會自動檢查用戶兩次輸入的密碼是否一致，如果不一致，會出現出錯提示并建議用戶重新輸入。
圖3-8 修改密碼界面
用戶只能通過此界面修改自己的密碼，如果試圖修改別人的密碼，則提示如下圖：
圖3-9 修改密碼界面
修改密碼成功則顯示重新登錄界面，圖如下：
圖3-10重新登錄界面
3.2 進貨管理模塊
進貨管理模塊包括填寫貨品信息、入庫單、修改最低庫存三個子模塊。
圖3-11 倉庫管理員填寫入庫單界面
入庫單中涉及數據一致性，貨品編號為1開頭的庫別自動為飲料庫，貨品編號為2開頭的庫別自動為主倉庫，貨品編號為3開頭的庫別自動為酒庫。數量和進貨單價設置只能輸入數字類型。其中貨品編號如果在庫存信息表中不存在，那么提示先輸入貨品信息，點擊確定后界
面自動跳轉到如下圖：
圖3-12 倉庫管理員填寫入庫單界面
圖3-13 倉庫管理員填寫貨品信息界面
3.3 出貨管理模塊
出庫時如果出庫數量低于庫存信息表中的最低庫存時報警，提醒倉庫管理員及時通知采購員采購，如果不清楚此貨品的采購員是誰可以根據貨品編號查詢采購員信息，報警顯示如下圖：
圖3-14 填寫出庫單
3.4報表統計模塊
本系統的報表分為日報表和月報表，日報表在添加入庫單和出庫單時就已經自動添加進數據庫中的日報表了，所以在此只需再手動添加月
報表。
圖3-15 月報表統計
3.5信息查詢模塊
該模塊三種用戶都會用到，用戶根據不同的權限分別可以查詢不同的內容，如系統管理員為了修改倉庫信息表、采購員信息表、客戶信息表而查詢相關信息，倉庫管理員為了通知采購員及時采購而查詢采購員信息，經理查詢倉庫管理的各種信息等。
圖3-24 庫存信息查詢
第四篇：汽車租賃系統軟件設計說明書
汽車租賃系統 軟件設計說明書
目錄
1.介紹....................................................................................................................................1 1.1 目的..........................................................................................................................1 1.2 范圍..........................................................................................................................1 1.3 內容概覽..................................................................................................................1 2.體系結構表示方法............................................................................................................2 3.系統要達到的目標和限制................................................................................................2 4.用例視圖............................................................................................................................2 4.1 創建系統用例圖......................................................................................................2 4.2 創建系統靜態模型..................................................................................................4 4.3 創建活動圖..............................................................................................................4 4.4 創建狀態圖...........................................................................錯誤！未定義書簽。5.邏輯視圖............................................................................................................................7 5.1 參與者相關的類......................................................................................................8 5.2 系統中用到的其他類..............................................................................................9 5.3 各類之間的關系....................................................................................................10 6.過程視圖..........................................................................................................................10 6.1 客戶取車................................................................................................................10 6.2 客戶還車................................................................................................................12 6.3 客戶預訂車輛........................................................................................................13 6.4 出租汽車................................................................................................................15 6.5 增加汽車................................................................................................................15 6.6 刪除汽車................................................................................................................16 6.7 增加客戶................................................................................................................17 6.8 車輛信息管理........................................................................................................18 7.部署視圖..........................................................................................................................18 8.規模和性能......................................................................................................................20 9.質量..................................................................................................................................20
《軟件工程實踐》
2012-2013-02
軟件設計說明書
1.介紹
1.1 目的
汽車租賃系統是一套針對汽車租賃業務的實際特點而開發的應用與管理軟件，其功能覆蓋了汽車租賃業務的全部流程。主要包括車輛預定、租賃業務、車輛管理、客戶管理、車輛檢修、租金統計等功能。它包括了四個模塊：基本數據維護模塊、基本業務模塊、數據庫管理模塊和信息查詢模塊。其中，基本數據模塊提供了使用者錄入、修改并維護基本數據的途徑，主要包括了添加車輛信息、修改車輛信息、添加員工信息、修改員工數據幾大主要功能。基本業務模塊則提供，基本業務模塊中，客戶可以填寫汽車租賃申請表，工作人員負責處理這些表格；同時，技術人員可以提交每輛車的狀態，以便工作人員根據這些資料決定是否批準客戶的請求，它包含的功能有：用戶填寫預定申請、工作人員處理預定請求、技術人員填寫服務記錄和工作人員處理還車。數據庫模塊是對客戶、工作人員及車輛的信息都要進行統一管理，車輛的租賃情況也要進行詳細的登記，它的功能則是客戶信息管理、車輛信息管理、租賃信息管理和志愿信息管理。信息查詢模塊主要用于查詢數據庫中的相關信息，包括查詢客戶信息、查詢職員信息、查詢車輛信息和客戶記錄等。
這篇文檔提供了對在線汽車租賃系統的系統架構的總覽，從不同的視角描述了該系統。同時介紹了在線汽車租賃網站有關架構的想法，包含架構分析的關鍵決策，目的在于幫助開發人員理解汽車租賃系統的基本結構。
1.2 范圍
介紹了汽車租賃系統的客戶取車、客戶還車、客戶預訂車輛。
1.3 內容概覽
? 登錄系統
用戶如果要進行汽車租賃操作，需要輸入正確的用戶名和密碼，如果輸入錯誤，則停留在登錄頁； ? 注冊系統
客戶如果從來沒有在本網站租賃過汽車，需要注冊一個客戶賬號； ? 瀏覽汽車系統
進入汽車租賃系統后，客戶必須知道有關的汽車信息，可以得到汽車的名稱、價格、各種屬性信息，并能根據需要輸入相關信息進行搜索； ? 汽車系統
當客戶看中某輛汽車后，可以根據需要進行預定，操作后生成訂單，然后可以提交訂單。
《軟件工程實踐》
2012-2013-02 2.體系結構表示方法
這篇文檔使用一系列視圖反映系統架構的某個方面；
用例視圖：概括了架構上最為重要的用例和它們的非功能性需求； 邏輯視圖：展示了描述系統關鍵方面的重要用例實現場景(使用交互圖)；
部署視圖：展示構建在處理節點上的物理部署以及節點之間的網絡配置(使用部署圖)； 3.系統要達到的目標和限制 ? 目標
客戶可以正確登錄，在登錄頁面輸入信息時能夠在輸入錯誤的同時看到錯誤提示；正確登錄后可以看到汽車的列表，點擊其中一條信息后可以看到某輛汽車的詳細信息，看中后可以很方便的進行預定，在生成訂單之后客戶可以看到。
客戶在首頁可以很方便地進行注冊，輸入的注冊信息要進行驗證，驗證正確后將信息存入數據庫。
管理員正確登錄后可以修改用戶信息，汽車信息。? 限制
客戶和管理員的界面分開，客戶不能修改邏輯上不能修改的信息； 管理員不能修改用戶密碼，還有同級別的管理員的信息。4.用例視圖
4.1 創建系統用例圖
汽車租賃系統主要是對各種信息的管理，而在系統中，只有租賃管理人員才有權限使用本系統，才能對數據庫進行操作。
（1）管理人員對汽車信息的管理，包括汽車租出時將汽車狀態更改為已租出，而當汽車歸還時則將狀態置為可出租。再者就是當購進新車或者汽車報廢時更改可出租汽車的數量信息等。
（2）管理人員對于客戶信息的管理主要是對會員的管理，比如更改會員類型，增刪會員信息。
（3）而對于工作人員的管理主要是指增刪工作人員以及修改工作人員的信息，這有為重要，因為工作人員有權處理汽車的租賃流程。
系統用例圖如下：
《軟件工程實踐》
2012-2013-02 繳納罰金客戶<
圖4.1客戶用例圖
系統登錄查詢預訂記錄處理預定拒絕租車請求工作人員汽車交付介紹租車程序<
圖4.2工作人員用例圖
《軟件工程實踐》
2012-2013-02
增加汽車汽車信息管理更改汽車狀態客戶信息管理租賃系統管理者刪除汽車工作人員信息管理圖4.3租賃系統管理者用例圖
4.2 創建系統靜態模型
從前面的需求分析中，我們可以依據主要的七個類對象：汽車、客戶、職員、工作記錄、請求訂單、客戶記錄和服務記錄創建完整的類圖如圖4.3所示。
商品類別的活動圖如下：
圖4.3 系統類圖
4.3 創建活動圖
利用系統的活動圖來描述系統的參與者是如何協同工作的。汽車租賃系統中，根據客戶和職員的活動步驟我們可以創建活動圖如下圖4.4所示。
《軟件工程實踐》
2012-2013-02
圖4.4 客戶和職員的活動圖
圖4.5 系統管理員維護汽車信息的活動圖 5
《軟件工程實踐》
4.4 創建狀態圖
2012-2013-02 在汽車租賃系統中，從客戶開始發送租車請求道最后客戶歸還租借的車輛為止，整個系統的狀態圖如下圖4.5所示。
圖4.6 汽車租賃系統的活動圖
圖4.7 車的活動圖
《軟件工程實踐》
2012-2013-02
圖4.8 客戶的活動圖
5.邏輯視圖
邏輯視圖部分主要敘述了設計階段的工作。汽車租賃系統的數據類中共有8個：Person,Customer,Worker,Administrator,Car,RequestOrder,ServiceRecord,CustomerRecord.《軟件工程實踐》
5.1 參與者相關的類：
2012-2013-02
[類圖說明] ? Person類是所有類的父類，包含3個屬性：姓名（name），身份證號（ID）和電話號碼（PhoneNO）。它包含的方法都是用來設置和獲取這些屬性值。
? Customer類是包含客戶信息的類，除了繼承了父類的屬性和方法，還包括了車輛類型（CarType），性別（gender）和駕駛證號（licenseNo）等屬性。
? Worker類是包含員工信息的類，其中包含了員工的類型（type）和工作證號（WorkID）等屬性，方法中的calculate()用來進行結算，checkRequest用來查詢是否有沒處理的申請單，checkCar()是用來查詢汽車狀況的。
? Administrator類是系統管理員類，主要屬性有工作證號（WorkID），主要方法是update()。
《軟件工程實踐》
5.2 系統中用到的其他類：
2012-2013-02
[類圖說明] ? CustomerRecord類表示客戶記錄。customerID是客戶的身份證號碼，customerName是客戶名稱，RentDate是租車日期，CarType是所租車輛的類型，CarNumber是該車的車牌號碼。IsFinish代表該交易時否結束。check()用來得到該客戶的記錄，end()用來結束該交易。
? Car類代表汽車記錄。CarType是該車的車型，CarNumber是車牌號碼，status是指該車是否被預訂、正在使用中或空閑狀態，condition是指該車的狀態。InServiced()用來判斷該車是否空閑，updateStatus()用來修改車輛所處的狀態。
? RequestOrder類表示的是填寫客戶申請資料的表格。CarType表示客戶申請的車型，RentDate是租車時間，IsAllow表示該客戶的申請是否得到批準。Allow()用來接收客戶的請求，fillOrder()是指客戶填寫表格，check()用來檢查是否存在這個申請，isHandled()設置該申請已被處理。
? ServiceRecord類是服務記錄，屬性包括交易中涉及的員工、客戶、車輛、已經租賃信息。fillWorkRecord()用來填寫這份記錄，viewRecord()用來查看這份記錄，updateRecord()用來修改這份記錄。
《軟件工程實踐》
5.3 各類之間的關系：
2012-2013-02
[類圖說明] ? 從圖中可以看出，工作人員（Worker）可以查看所有客戶（Customer）的租賃歷史記錄（CustomerRecord），可以處理多個用戶的租賃申請（RequestOrder）。由于工作人員可以同時處理多個業務，所以他可以擁有多個服務記錄（ServiceRecord）。
6.過程視圖
過程視圖部分敘述幾個主要子系統的處理流程。主要包括客戶取車，客戶還車，客戶預訂車輛。
6.1 客戶取車 6.1.1 用例簡述
客戶取車：客戶出示取車的通知，職員查看通知無誤，客戶支付押金，職員填寫工作記錄，更新車輛的狀態，客戶取車。
6.1.2 基本事件流 客戶：客戶出示取車的通知； 2 職員：職員查看通知無誤； 3 客戶：客戶支付押金； 4 職員：職員填寫工作記錄；
《軟件工程實踐》
2012-2013-02 5 職員：更新車輛的狀態； 6 客戶：客戶取車 7 系統：用例結束。
6.1.3 客戶取車順序圖見圖6.1
圖6.1 客戶取車的系統順序圖
6.1.4 客戶取車的協作圖見圖6.2
圖6.2 客戶取車的協作圖
《軟件工程實踐》
2012-2013-02
6.2 客戶還車 6.2.1 用例簡述
客戶還車：客戶歸還車輛，職員檢查車輛的狀態并添加服務記錄，通知付款，客戶付清錢款，職員更新車輛狀態。
6.2.2 基本事件流 客戶：客戶歸還車輛； 職員：職員檢查車輛的狀態并添加服務記錄； 3 職員：通知付款； 4 客戶：客戶付清錢款； 5 職員：更新車輛的狀態； 6 系統：用例結束。
6.2.3 客戶還車的系統順序圖見圖6.3
圖6.3 客戶還車的系統順序圖
6.2.4 客戶還車的協作圖見圖6.4
《軟件工程實踐》
2012-2013-02
圖6.4 客戶還車的協作圖
6.3 客戶預定車輛 6.3.1 用例簡述
客戶預訂車輛：客戶填寫預訂單，職員檢查預訂單并檢查客戶記錄，辦理租車的手續，完成手續后，建立新的客戶手續，同意租車請求，通知客戶。
6.3.2 基本事件流 客戶：客戶填寫預訂單； 職員：職員檢查預訂單并檢查客戶記錄； 3 職員：辦理租車的手續； 職員：完成手續后，建立新的客戶手續； 5 職員：同意租車請求； 6 職員：通知客戶 7 系統：用例結束。
《軟件工程實踐》
6.3.3 客戶預訂車輛的系統順序圖見圖6.5
2012-2013-02
圖6.5 客戶預訂車輛的系統順序圖
6.3.4 客戶預訂車輛的協作圖見圖6.6
圖6.6 客戶預訂車輛的協作圖
《軟件工程實踐》
6.4 出租汽車 6.4.1 用例簡述
2012-2013-02 出租車輛：查詢汽車，驗證客戶身份，查詢可租汽車，查詢客戶信息，修改客戶租車信息，修改服務信息。
6.4.2 基本事件流 職員：查詢汽車； 2 職員：驗證客戶身份； 3 職員：查詢可租汽車； 4 職員：查詢客戶信息； 5 職員：修改客戶租車信息； 6 職員：修改服務信息； 7 系統：用例結束。
6.4.3 出租車輛的系統順序圖見圖6.7
圖6.7 出租車輛的時序圖
6.5 增加汽車 6.5.1 用例簡述
增加汽車：增加汽車，查詢汽車是否已存在，創建新車信息存入系統。
6.5.2 基本事件流 職員：增加汽車； 職員：查詢汽車是否已存在；
《軟件工程實踐》
2012-2013-02 3 職員：創建新車信息存入系統； 4 系統：用例結束。
6.5.3 增加車輛的系統順序圖見圖6.8
圖6.8 增加車輛的時序圖
6.6 刪除汽車 6.6.1 用例簡述
刪除汽車：刪除汽車，查詢汽車，刪除車輛信息。
6.6.2 基本事件流 職員：刪除汽車； 2 職員：查詢汽車； 3 職員：刪除車輛信息； 4 系統：用例結束。
6.6.3 刪除汽車的系統順序圖見圖6.9
《軟件工程實踐》
2012-2013-02
圖6.9 刪除汽車的時序圖
6.7 增加客戶 6.7.1 用例簡述
增加客戶：添加新的租車用戶信息。
6.7.2 基本事件流 職員：添加新的租車用戶信息； 2 系統：用例結束。
6.7.3 增加客戶的系統順序圖見圖6.10
圖6.10 增加客戶的時序圖
《軟件工程實踐》
6.8 車輛信息管理 6.8.1 用例簡述
2012-2013-02 汽車信息管理：查詢汽車狀態信息，更改汽車狀態信息，用例結束。
6.8.2 基本事件流 職員：查詢汽車狀態信息； 2 職員：更改汽車狀態信息； 3 系統：用例結束。
6.8.3 汽車信息管理的系統順序圖見圖6.8
圖6.11 汽車信息管理的時序圖
7.部署視圖
部署視圖描述了如何將具體軟件制品分配到計算節點(具有處理服務的某種事物)上，表示了軟件元素在物理架構上的部署，以及物理元素之間的通信。
在本系統中，我們可以對汽車類、職員類、服務記錄類、客戶類、工作記錄類、客戶記錄類和請求訂單類分別創建對應的構件進行映射。汽車租賃系統的構件圖如圖7.1所示。
《軟件工程實踐》
2012-2013-02
圖7.1系統構件圖
圖7.1 汽車租賃系統的構件圖
汽車租賃系統的部署圖描繪的是系統節點上運行資源的安排。包括三個節點，分別是：客戶端瀏覽器、Http服務器、數據庫服務器，創建后的汽車租賃系統部署圖如圖7.2所示。
圖7.2 汽車租賃系統的部署圖
? Generic PC 普通的個人計算機。? Web Browser 通用個人計算機上的網頁瀏覽器，如：IE6.0，Firefox等。? Apache Web服務器，可以運行在所有廣泛使用的計算機平臺上。? Struts 一個為開發基于模型-視圖-控制器模式的應用架構的開源框架，是利用Java Servlet和JSP構建Web應用的一項非常有用的技術。事件從客戶端(瀏覽器)由用戶操作出發的事件，Struts使用Action來接受瀏覽器表單提交的事件。? Tomcat 6.0 Tomcat 6.0提供Servlet容器。? Hibernate Hibernate提供對象關系映射框架，對JDBC進行了非常輕量級的對象封裝，使得可以使用對象編程思維來操縱數據庫，完成數據持久化。? MySQL MySQL是小型關系型數據庫管理系統，其體積小、速度快、總體擁有成本低，開放源碼數據庫。
《軟件工程實踐》
2012-2013-02 8.規模和性能 ? 滿足的規模
能夠滿足100人同時在線瀏覽網頁，20人同時進行有關數據庫的操作。? 滿足的性能
能夠滿足讓顧客可以認同的相應時間。9.質量
系統正式使用時，登錄、注冊、查看汽車信息、生產訂單的流程正常。
第五篇：酒店管理系統軟件設計說明書
酒店管理系統
需求規格說明書
目錄
1.引言……………………………………………………….3 1.1目的……………………………………………………..3 1.2 定義…………………………………………………….3 1.3 產品的范圍和產品特性……………………………….3 1.4 參考文獻……………………………………………….4 2.綜合描述………………………………………………….4 2.1 產品的前景…………………………………………...4 2.2 產品的描述…………………………………………...4 2.3 用戶類和用戶特性…………………………………...4 2.4 運行環境……………………………………………...5 2.5 設計和實現的約束條件……………………………...5 2.6 假設和依賴…………………………………………...5 3.外部接口需求…………………………………………….5 3.1 用戶接口……………………………………………...5 3.2 硬件接口……………………………………………...6 3.3 軟件借口……………………………………………...6 3.4 通信接口……………………………………………...6 4.系統特性………………………………………………….6 4.1前臺管理………………………………………………6
4.2 消費管理……………………………………………...8 4.3 收銀管理……………………………………………...9 4.4 客房服務……………………………………………...11 5.其他非功能需求…………………………………………13 5.1 性能需求……………………………………………..13 5.2 安全性需求…………………………………………..13 5.3 軟件質量需求………………………………………..13 6.附件………………………………………………………14
附錄 分析模型…………………………………………...14
1.引言 1．1目的
隨著旅游業的民展，酒店、餐飲娛樂行業日趨發達，引入全方位的電腦服務和電腦管理日益流行。同時，酒店和餐廳娛樂業引入電腦服務和管理也取得了優良的經濟效益和社會效益。酒店管理系統將先進的電腦技術和現代酒店服務管理管理完美地結合起來，實現了住宿，餐飲全新概念的服務和管理方式。
酒店管理的電腦化，不僅是體現酒店現代化形象的一個重要標志，而且對于提高員工的工作效率，加速資金周轉，降低各項成本及改善服務質量都有十分積極的作用。
1．2定義
1.客房預定系統:可以處理散客預定、團體預定、客房預定、預定未到處理、預售查詢等事務。
2.前臺接待系統：可以處理散客入住登記，合約入住，團體自動入住和手動入住，補填客單，修改客人信息、轉房、調房、設置房態、客人留言，預定客房查詢、可售客房查詢等事務。
3.前臺必銀系統：處理記賬、埋單、限制客人消費、退房、押金加入、查賬、轉賬、設置跑單、客用保險箱管理、團體埋單及退房業務。
4.賬務系統：除具有收銀的功能外，還具有糾錯、報表輸出等功能，能將損失降至最低。5.管家系統；可處理設置凈房、臟房、壞房及取消壞房，設置SKIP房、SLEEP房，查詢謅房表、臟房表、壞房表，房間狀態，新入住查詢等業務。
6.電話系統：具有自動計費、夜間稽核，客人信息查詢、動態房態查詢、房間明細賬查詢、收銀員報表、當日入住客人報表等功能。
7.客歷系統：能處理客人手工、自動輸入，客人資料查詢與修改，黑名單，入住客人自動查詢客歷、入住客人自動歸入客歷。
8.合約系統：可將酒店簽約的單位或個人的資料輸入電腦，并可隨時查詢和更新。
9.經理系統：可修改客房定價，增加、刪除、修改各級密碼，個性特別客單，設置系統參數，內部銀行系統，數據整理，自我診斷，數據備份。
10.總經理系統：具有客單查詢，查詢客房狀態，查詢可售情況，客房占用統計，賬務查詢，萬能查詢，報表輸出功能
11.密碼管理系統：可以管理客戶和酒店的各種密碼。
12.報表系統：主要是對處理一些非賬務表單。主要有客房占用表、轉房改租表、預定未到表、客房取消表、房租分析表、經營統計表、可售情況表、房間狀態表、壞房狀況表、日租統計表、合約銷售表。
13.賬務報表：主要是處理酒店的日常的賬務報表，有收入報表（前臺收入明細表、現付收入明細表）、消費報表、顧客賬務（住房賬務、離店客人賬務各跑單賬務）、交班報表、信用卡報表、街賬報表、應收報表、催賬報表、轉賬報表、借貸報表、聯網消費、酒店總表。
1．3產品的范圍和產品特性
“酒店管理系統”允許酒店工作人員對酒店的客房、員工以及入住酒店的顧客進行客房入住、酒店服務等一些管理。“酒店管理系統”實施后，能節約人力資源，提高服務質量，方便各項管理。賬務處理的時間明顯減少，數學計算上的錯誤也會消失。對客房狀態（如是否入住，入住顧客信息等）的查詢與統計也顯得非常方便，減少了顧客等待與員工分類統計的時間。詳細的項目描述請參見酒店管理系統前景和范圍文檔。文檔中這一部分的標題為“初始版本和后續版本的范圍”，列出了按照進度計劃在這一版本中實現的全部或部分特性。
1.4 參考文獻
1）《軟件需求》Karl E.Wiegers(美)著 清華大學出版社
2）前期所寫的《酒店管理系統的前景和范圍文檔》
3）《現代軟件工程》 孫涌等著 北京希望電子出版社
2.綜合描述
2.1 產品的前景
隨著計算機技術的飛速發展，信息時代的到來，信息改變了我們這個社會。各類行業在日常經營管理各個方面也在悄悄地走向規范化和網絡化。客房管理的信息化程度體現在將計算機及網絡與信息技術應用于經營與管理，以現代化工具代替傳統手工作業。無疑，使用網絡信息化管理使客房管理更先進、更高效、更科學，信息交流更迅速。
酒店客房管理系統是酒店經營管理中不可缺少的部分，它的內容對于經營的決策者和管理者來說都至關重要,所以客房管理系統、信息管理系統應該能夠為用戶提供充足的信息和快捷的查詢手段。但一直以來人們使用傳統人工的方式管理文件檔案，這種管理方式存在著許多弊端，如:效率低、保密性差，容易出現差錯等，且對于查詢空房間及已定房間等極為不方便。在當今時代，這些完全可以改用計算機來代替人的手工操作。
作為計算機及網絡應用的一部分，使用計算機對客房信息進行管理，具有手工管理所無法比擬的優點。例如:檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。這些優點能夠極大地提高客房經營管理的效率，也是企業的科學化、正規化管理，與世界接軌的重要條件。且辦事效率也是決定收入的一個關鍵因素。
“酒店管理系統”代表了酒店管理的信息化，不僅是體現酒店現代化形象的一個重要標志，而且對于提高員工工作效率，加速資金周轉、降低各項成本及改善服務質量都有十分積極的作用。
2.2 產品的描述
一個成熟的酒店管理系統不僅僅是記錄酒店客人的信息，提供查詢，報表打印等一 系列簡單的工作，它能讓工作人員從煩瑣的手工操作中解脫，并且酒店管理系統本身就 代表著一種管理方法。隨著它的深入，將帶動企業的運作，為管理和決策提供支持。本項目在經過對各酒店軟件進行分析和研究后，參考國際上的先進酒店軟
件管理思想，結合中國酒店的實際特點，認為可將整個酒店管理系統細分為五個子系統：（1）前臺管理系統（2）消費管理系統（3）收銀管理系統（4）客房服務系統（5）系統維護
2.3 用戶類和用戶特性
酒店前臺工作人員（優先考慮）：前臺服務員的主要職能是負責訂房和退房，以及查詢入住的客戶信息。所有該角色只可以使用部分功能，包括客房經營管理、客戶信息查詢、個人密碼修改以及注銷功能。前臺工作人員對客房信息進行管理，包括對客房的基本信息(如客房號、客房類型客房位置等)進行檢索、錄入和修改。工作人員根據酒店規定可 定義客房類型，并對其進行管理，包括對客房類型的基本信息(如類型名稱、面積、床位、價格等)進行檢索、錄入和修改系統。界面會自動顯示各種房類的訂房情況，以方便前臺接待控制房態。按客人姓名系統可自動調出回頭客信息 及歷次住店統計信息以確定房價優惠、優惠時段和客人具體的消費記錄等。
酒店管理人員：酒店管理員享有最高權限，可以使用酒店客房管理系統所提供的所有功能，包括員工信息維護、客房類型維護、客房信息維護、客戶信息查詢、經營狀況統計、個人密碼修改以及注銷功能。
顧客：顧客可以在酒店提供的網上酒店管理系統進行自助查詢酒店的一些相關信息，以及預定客房等。
財務管理部門：根據酒店客房的業務記錄，酒店財務管理部門的工作人員可選擇客房類別和日期的統計方式對營業額進行統計。他們需要接受培訓，學會如何讓使用計算機以及一些office應用。
酒店房務服務人員：酒店的房務服務人員利用系統可看到系統根據自家酒店的實際情況按順序房號列出客房，很直觀地顯示客房所屬的房間類型及用圖形及顏色表示不同的房態，有沒有顧客入住、退房等，客房需要什么樣的服務，是否需要打掃、服務。
2.4 運行環境
為了達到系統要求，必須依靠高起點的硬件環境和軟件開發工具來保證系統的穩定和正常運行。酒店電腦系統要求24小時連續運行，數據量大，可靠性要求高，因此整個電腦系統供電采用專線方式，加配lips（不間斷供電系統），并合理接地，以便保障整套系統的正常運行。
2.5 設計和約束條件
CO-1:部分子系統將使用酒店本來的業務流程。
CO-2:系統必須操作簡單、用戶手冊通俗易懂。
CO-3：該服務器實現要使用由公司批準的Red Hat Linux版本和Apache HTTP Server.2.6 假設和依賴
AS-1: 酒店擁有一臺打印機和傳真機，能方便打印報表，以及對預定客房的商務傳真進行處理。
AS-2: 酒店有鏈接外網的服務器或計算機，能提供網上預定功能，方便顧客預定。DE-1: 對于經常光顧或要求打折的顧客以及節假日或者店慶優惠活動，應具備折扣管理功能。
DE-2: 對于使用酒店管理軟件前的電話預定等，該管理軟件應該有專門的錄音功能。
3.外部接口需求
3.1 用戶接口（User Interfaces,UI）
UI-1:入住登記界面應包含：部門，可選設施圖標區，賓客登記信息區，選定設施列表。
UI-2：消費點單操作界面應包含：部門選擇，總賬單列表區，子賬單列表區，消費記錄區，消費品選擇區。
UI-3:外賣零單消費界面應包含：消費品選擇區，消費記錄區，支付方式選擇區。UI-4:在退房結賬界面應包含：部門選擇，總賬單列表區，子賬單列表區，消費明細表，結賬操作面板。
3.2 硬件接口（Hardware Interfaces,HI）
HI-1:采用基于超5類雙絞的綜合布線系統，同時支持語音和數字的傳輸。HI-2：對機器的指示是：CPU2400轉以上，顯示器支持800*600分辨率，基本內存512兆推薦2G，Windows兼容打印機。
3.3 軟件借口（Software Interfaces,SI）
“人事管理系統”。“人事管理系統”通過程序界面與“酒店管理系統”進行通信，完成下面這些工作：
1：提取人員業務完成情況，作為進行績效考核的依據。
2：根據酒店管理系統中各部門的項目消費情況，作為合理分配人員的依據。
3.4 通信接口（Communications Iterfaces,CI）
CI-1：“酒店管理系統”接收熟客的電子郵件預訂，由操作員將預訂信息輸入系統。
CI-2：“酒店管理系統”將向賓客發送電子郵件消息，以確認收到預訂或者預訂失敗信息。
4.系統特性
4.1 前臺管理
（1）描述和優先級
為住店客人提供預訂信息，并為顧客辦理登記入住手續，將登記信息錄入電腦。并可以為客人增加房間，更換房間，還能根據操作員的權限不同，對客人登記信息及房間價格加以修改，提高系統的靈活性，滿足不同客人的要求。
（2）刺激/響應序列
預定
刺激：選擇客人準備預約登記的部門，如客房…等，點擊“新增預訂”。響應：系統給出預定登記區。
刺激：在預訂登記區填入相關信息、選擇具體需預訂的設施項目及數量。填寫無
誤后按“保存”按鈕。
響應：系統記錄預定信息，并返回預定成功。刺激：反之選擇“取消”按鈕。響應：系統取消預定。
入住登記
刺激：進入“接待畫面”后，先選擇當前需接待登記的部門，如：客房、餐飲…．．
再選擇設施規格，默認狀態下是“標準”。
響應：建立客戶消費帳，為每位客人安排一個房間、床位、桌號、牌號、及其他相關登記類型索引記錄。
刺激：選擇和填寫完畢，按“確定”按鈕。響應：完成接待操作。
刺激：按“取消”按鈕。響應：取消所有操作。
顧客換房
刺激：進入“登記調整”界面，響應：系統調出所有已登記賓客和空余設施。
刺激：首先選擇需調整賓客當前所登記的“部門”，在界面“原登記”列表框內移動光標選擇需調整的賓客。在“設施列表”中選擇想調換的設施。按“調換”按鈕。
響應：完成調換。
刺激：按“取消”按鈕。響應：取消所有操作。
追加登記
刺激：進入“追加登記”界面，在客人列表框內直接移動光標選擇需追加登記的客人。
響應：系統調出該客人已登記的項目。
刺激：在“可供追加項目”列表框內雙擊鼠標添加新的項目到該賓客資料中，點擊“確定”。
響應：系統更新該客人的已登記記錄，并返回追加成功。刺激：選中追加項目，通過點擊“—”取消追加。響應：系統將新追加項目從該賓客資料中移除。刺激：按“取消”按鈕。響應：取消所有操作。
4.2 消費管理
（1）描述級和優先級
根據客人需求，為已登記在店客人提供店內能提供的消費服務，并自動建立消費檔案。每位顧客發生消費前必須進行登記，需要建立客戶帳，然后是顧客在酒店里進行了各種消費，例如：就餐點菜、會議室的租用、沐浴按摩、酒水消費等等，將這些消費信息錄入在客戶帳上，對這些消費進行管理滿足顧客不同的消費。
（2）刺激/響應序列
點單
刺激：進入“總帳單列表區”界面，通過移動上下鍵或直接用鼠標在此區域選擇需
要消費的客人，或者直接在“定位框”中輸入需要消費客人的編號或姓名直接進行定位選擇客人，選定客人，點擊客戶姓名。
響應：彈出選定顧客的消費總賬單，包含總帳單下的所有子帳單。子賬單也會并行
顯示在“子帳單列表區”。
刺激：根據客人的需求通過移動上下鍵或直接用鼠標在此區域選擇具體子帳單人，點擊進入。
響應：系統進入選定顧客的消費品選擇區，系統并行彈出消費品選擇區和消費記區界面。
刺激：先選擇消費品所在部門，然后根據該部門所提供的消費品列表雙擊某消費品 或按［添加］按鈕。
響應：系統添加該客人的本次消費品記錄，并返回添加成功。
刺激：所有消費品點單完成后，按“保存”按鈕。
響應：系統將本次操作所產生的消費額記錄在該客人的帳單數據表中，并生成消費
品記錄單反饋到消費服務部門，提示服務人員提供消費服務。
外賣
刺激：先選擇消費品所在部門，然后根據該部門所提供的消費品列表雙擊某消費或 按“添加”按鈕。
響應：系統添加該客人的本次消費品記錄，并返回添加成功。
刺激：所有消費品點單完成后，在顧客支付方式選擇區，根據客人的支付方式，如：
現金、支票、信用卡…等支付方式，進行選擇，按“保存”按鈕。
響應：系統即刻將消費記錄在消費記錄區等待顧客付費并彈出提示框，提示客人進 行付款。
刺激：點擊“付款”按鈕，輸入顧客已付款數額。響應：彈出應找零金額。
刺激：點擊“付款完成”按鈕。
響應：系統即刻生成客人消費記錄單反饋到服務部門，彈出提示框服務人員提供服務。
查單
刺激：進入“消費查詢（未結帳）”界面后，選擇需要查詢的部門，如選擇：進店 日期、消費部門這兩個項目，點擊“確定”按鈕。
響應：系統確定所查詢的范圍，彈出客人列表框。
刺激：在畫面左邊的客人列表框中移動光標，進一步確定某位客人的具體“消費明 細”和“收銀明細”情況。通過鼠標點擊“消費明細”和“收銀明細”頁框。
響應：系統顯示“消費明細”或“收銀明細”頁面。
刺激：可再進一步用鼠標點擊“只顯示電話費”明細。
響應：系統顯示電話費明細信息。
4.3 收銀管理
（1）描述和優先級
每一個客人從入住房間起，系統就需要自動產生該客人的帳號，住店的客人享受酒 店的短期貸款，可以在酒店絕大部分簽單，這將刺激客人的消費心理，增加酒店收入，酒店管理者還應可根據客人的情況鎖住其帳號，以限制其消費。
前臺收銀的埋單應允許客人一帳多單，分期埋單，分類別埋單，退房時能自動檢測：客人的帳務余額為零；客人帳號的帳項為空；否則不能退房。
系統還應具有合并、分拆帳戶的功能，既不但可以把幾個帳號的消費轉入另一帳號，也可把某一帳號特定時期特定幾類消費轉入另一帳號，便于滿足客人的多種結帳要求。
細分為如下四個需求：退房結帳、取消結帳、合并帳戶、訂金管理。（2）刺激/響應序列
退房結賬
刺激：客人提出退房結賬申請。響應：系統給出退房結賬界面。
刺激：在“總賬單列表區”選擇登記客人、在“子賬單列表區”選擇該客人賬目下項目。
響應：系統在“消費明細表”區域顯示“待結賬客人列表框”或“子客列表框”中光標焦點所指客人的記錄，在“結賬操作面板”中顯示結算金額、已收金額，計算出實際收款。
刺激：選擇付款方式、付款。
響應：系統更新數據庫，提示結賬成功。刺激：按“取消”按鈕。響應：取消所有操作。
取消結賬
刺激：客人登記后隨即提出“退單”。
響應：系統給出退房結賬界面。
刺激：在“退房處理”處打勾，點擊結賬按鈕。
響應：完成取消結賬操作，其所有消費不作營業額統計。刺激：按“取消”按鈕。響應：取消所有操作。
合并賬戶
刺激：選擇需要合并帳單的客人所在的部門。響應：系統調出所有已登記賓客的賬戶信息。刺激：在 “已登記在店客人”列表框內移動光標或直接用鼠標指定客人，也可在“已登記在店客人”文本框內輸入賓客姓名或房間編號迅速查找定位相關賓客。“已登記在店客人”列表框內按回車鍵或雙擊鼠標。
響應：將當前光標所指的客人記錄移動到“合并區”列表框。刺激：重復操作，選擇另一位需合并的客人。
響應：將當前光標所指的另一位客人記錄移動到“合并區”列表框。
刺激：在“合并區”移動光標，可確定合并后以哪個帳單號作為合并后的帳單 號。點擊“合并”按鈕。
響應：系統將合并的賬單存儲到合并后賬單號下，另一個賬號賬單清空，并提示合并成功。
刺激：按“取消”按鈕。響應：取消所有操作。定金管理
刺激：在“客人列表框”，通過直接用鼠標在此區域選擇欲繳款客人。也可 以在“定位框１”中輸入客人的編號或姓名直接進行定位選擇欲繳款客人。也可在 “子帳單列表區”直接接用鼠標在此區域選擇的欲繳款客人。響應：根據選擇的客人，其賬戶作為繳款賬號。
刺激：在“單據編號”文本框中輸入收款單據號（“單據編號”文本框為可選項，可通過“需要單據號”是否打勾確定）。
響應：根據單據號調出客人信息，作為繳款賬號。刺激：選擇“付款方式”，系統默認付款方式為“現金”。響應：等待輸入現金金額。
刺激：在“續繳金額’框中輸入具體金額。點擊“確定”
響應：系統將定金信息存儲到該客人的賬單號下，并提示繳納定金成功。刺激：按“取消”按鈕。響應：取消所有操作。
4.4 客房服務
（1）描述和優先級
酒店提出需要一個專門的子系統用于客房部檢查客房等項目設施狀態，根據多家酒店調研得出，通常將客房分為五種狀態：清潔、有客、清理中、待修理和有預約，在電腦系統中應以五種圖標代表。為增加靈活性，可以對其進行修改或調整。客房部根據電腦中的資料對臟房進行清潔，并能將清潔后的房態更改為清潔房。也可將部分房態改為待修理，使前臺不能出售此類房間。可顯示各部門的設施利用率，對已離店賓客的詳細情況進行查詢或打印。
（2）刺激/響應序列
房態管理
刺激：光標在“接待狀態表”主畫面上，直接用鼠標點擊圖標來選擇設施，如果該設
施狀態為：“有客”。
響應：系統在界面右下部會顯示使用該設施客人概況。
刺激：在房態標示為“有客”圖標上雙擊鼠標左鍵。
響應：系統彈出該客人的基本情況表。
刺激：點擊右鍵。
響應：系統彈出一菜單，供選擇改變當前指定設施的狀態。
刺激：如果改變了當前客房的房房態。
響應：被改變客房的房態圖標下面的文字變為紅色文字。
刺激：進行的更改完成，按“保存”按鈕完成保存操作。
響應：系統自動進行保存。
員工留言
刺激：系統界面設計有員工留言窗口，員工登錄留言。
響應：系統提示員工輸入登錄用戶名。
刺激：員工輸入用戶名點擊登錄。
響應：系統界面跳轉到員工留言窗口輸入框。
刺激：員工進行留言輸入，點擊完成發表。
響應：系統將員工的留言進行記錄在員工留言數據表中。
刺激：操作員登錄留言窗口進行查看時，如有“未接受”留言一提示，點擊查看。
響應：系統將“未接受”留言從數據表抽取出來顯示在界面上。
刺激：操作員查看完留言，進行回饋，點擊“完成”按鈕。
響應：系統將狀態為“未接受”留言改為“已接受”留言。將操作員的回復信息顯示在員工留言窗口。
設施利用統計
刺激：系統有一個查看酒店各部門的項目設施利用率，出租率情況的界面。酒店員工點擊查看。
響應：系統彈出輸入員工ID號的輸入框。
刺激：員工輸入自己的ID號，點擊“確定”按鈕。響應：系統判斷此員工是否有查看的權限。
刺激：如果有，系統彈出選擇框，選擇需查看的酒店部門，點擊“確定”按鈕。響應：系統彈出員工確認查詢的酒店部門項目設施利用率以及出租情況。
刺激：如果有部門項目設施利用率發生變化，員工要求更改記錄，點擊“修改”按鈕。響應：系統再次要求輸入員工身份認證密碼，彈出密碼輸入框。刺激：員工輸入密碼，點擊“確認”按鈕。響應：系統進行確認是否有修改權限。
刺激：如果有修改權限，進入設施記錄修改界面進行修改，修改完成，點擊“保存”按鈕。
響應：系統將新的記錄保存在酒店各部門的項目設施利用率，出租率報表中，進行更新。
客史資料查詢
刺激：系統有一個“登記人信息”界面，移動鼠標選擇要查詢客人的姓名，點擊“確定”。
響應：系統彈出輸入酒店工作人員ID號的輸入框。刺激：工作人員輸入自己的ID號，點擊“確定”按鈕。響應：系統判斷此員工是否有查看的權限。
刺激： 如果有，系統彈出進入指示，提示工作人員選擇進一步要查詢某位客人的信息
類別。
響應：系統根據員工的選擇彈出需查詢某位客人具體的登記情況。
刺激：在“其他人信息”區中移動光標，選擇進一步確定某位客人的查詢。
響應：系統根據員工的選擇彈出需進一步查詢某位客人的具體情況。
刺激：有一個“登記人信息”界面，點擊“查找按鈕”。
響應：系統彈出的“查找窗口”。
刺激：輸入“姓名”、“住址”和“證件號”，點擊查詢。
響應：彈出查詢客人信息。
5.其他非功能需求
5.1 性能需求
PE-1：當查詢空余項目時，系統的響應時間不能超過2秒。
PE-2：用戶向系統提交信息后，系統將在1秒鐘內向用戶顯示確認信息。
5.2 安全性需求
SE-1：用戶安全性需求：
（1）限制不必要的用戶。經常檢查系統的用戶，刪除已經不再使用的用戶。
（2）創建兩個管理員賬號。創建一個一般權限用戶用來處理一些日常事物，另一個有管理員權限的用戶只在需要的時候使用。
（3）開啟用戶策略，分別設置復位用戶鎖定計數器時間為20分鐘，用戶鎖定時間為20分鐘，用戶鎖定閾值為3次。
SE-2：密碼安性需求：
（1）使用安全密碼，注意密碼的復雜性，還要經常改密碼。（2）設置屏幕保護密碼。
（3）開啟密碼策略。設置密碼長度最小值為6位，設置強制密碼歷史為5次，時間為3天。
SE-3：系統安全性需求：
（1）安裝防毒軟件，經常進行系統掃描并升級病毒庫。（2）關閉默認共享。
SE-4：服務安全性需求：
（1）關閉不必要的端口。用端口掃描器掃描系統已開放的端口，確定系統開放的哪些服務可能引起黑客入侵。
（2）設置好安全記錄的訪問權限。安全記錄在默認情況下是沒有保護的，把它設置成只有管理員和系統賬戶才有權訪問。
（3）要把一些重要的用戶數據（文件、數據表、項目文件等）定時備份在另一個安全的服務器中。
5.3 軟件質量需求
Available（可用性）-1：“酒店管理系統”將具備每天24小時可用。
Robustness（健壯性）-1：如果在繳納定金或退房結賬時客戶機和服務器中斷，那么當時的操作全部視為無效，系統不記錄到數據庫。
6.附件
附錄 分析模型
圖1是酒店管理系統用例圖。用例視圖是表示整個系統需求。這個用例視圖反映了：參與者為系統管理員（總經理）和各部門經理，用例為各部門子系統，除了系統管理員（總經理）能與所有的用例進行通信外，每位部門經理只能與一個用例進行通信。
圖2為酒店管理系統的局部DFD圖。
圖8為酒店管理系統的狀態圖，它是描述客房狀態的狀態圖。
點擊咨詢 