二、 用例規約
1.註冊與登入
1.1 簡要說明
本用例用於向顧客提供註冊功能和註冊後的登陸以及前台客服的登陸。每位顧客必須註冊後才能登入系統內訂餐。註冊資訊包括使用本系統的賬號、密碼、聯絡位址和電子郵件等。
註冊完成後，可登入餐館管理系統，系統將會儲存這些資訊，以方便管理及聯絡使用者。
1.2 事件流
1.2.1 基本流
當顧客進行註冊時，開始執行以下基本流：
（1）系統要求顧客填寫個人資訊，包括使用本系統的賬號、密碼、聯絡位址、信用卡卡號、信用卡有效期和電子郵件等。
（2）顧客填寫個人資訊。
（3）系統驗證顧客所填寫的資訊的格式和內容。
（4）儲存該顧客資訊。
（5）顧客進入登陸介面進行登入。
1.2.2 備選流
1.2.2.1 顧客資訊驗證錯誤
如果系統檢測到顧客輸入的資訊格式或內容有錯，例如賬號中含有非法字元、輸入密碼和確認輸入密碼不一致，會給予錯誤提示，並清空填寫錯誤的文字框，要求顧客重新輸入。
1.2.2.2 顧客資訊儲存失敗
如果系統發現資料庫中已經儲存了同樣賬號的顧客記錄，會向顧客報告儲存失敗的錯誤資訊，並使頁面跳回註冊頁面，要求顧客修改註冊資訊。
1.3 特殊需求
無。1.4 前置條件
顧客必須首先訪問餐館管理系統的頁面，然後單擊註冊、登入。
1.5 後置條件
如果該用例成功，系統資料庫中將增加一條該顧客的資訊。否則，系統維持原狀。
1.6 擴充套件點
無。2.個人資訊管理
2.1 簡要說明
顧客註冊完成後登陸系統進行訂餐操作，同時前台客服也要登陸系統進行顧客資訊和點餐資訊的管理。顧客登入進入餐館個人資訊管理系統頁面後，通過檢視基本資訊以後，顧客可以進行資訊的一些補充。在預定結束時，顧客需要填寫一些相關資料以形成顧客訂單資訊儲存在該餐館管理系統的顧客資訊庫中。
2.2 事件流
2.2.1 基本流
當顧客登入到餐館管理系統後，開始執行以下基本流：
（1）顧客進入個人資訊頁面後，瀏覽個人資訊。
（2）顧客補填有關其個人資料的表單並將本次就餐人數與就餐時間填寫清楚。
（3）當顧客填寫完所有的資訊後，經確認後提交有其顧客訂單資訊的表單。
（4）系統經過驗證後，反饋給顧客驗證資訊，同時將顧客資訊連同顧客選定的飯菜資訊一併存入顧客資訊庫。
2.2.2 備選流
2.2.2.1 顧客賬號不存在
當顧客在預定結束時填寫個人資料後，系統經過驗證後，發現該顧客賬號不在該餐館管理系統的顧客資訊資料庫中，系統反饋乙個錯誤資訊給顧客，讓顧客重新填寫相關個人資料。
2.3 特殊需求
無。2.4 前置條件
顧客要想訂餐，必須先登入到該餐館管理系統中；若沒有顧客賬號，則該顧客還需要現在該系統中註冊乙個顧客賬號。
2.5 後置條件
該用例實現後，顧客資訊的情況就通過顧客訂單資訊被儲存在了系統的顧客資訊庫中，由系統對此進行統一的管理；反之，系統的顧客資訊庫中的資訊不發生任何的改變。
2.6 擴充套件點
無。3.食品管理
3.1 簡要說明
顧客登陸系統補充萬個人資訊後進行訂餐操作，同時前台客服也可登陸系統進行顧客點餐資訊的管理。顧客登入進入餐館食品管理系統頁面後，通過檢視選單資訊以後，顧客可以進行選擇要點的飯菜，並將選單資訊傳給產生報表系統和核准選單系統。
3.2 事件流
3.2.1 基本流
當傳送訂貨通知時，系統開始執行以下基本流：
（1）顧客進入選餐頁面後，瀏覽所有的選單資訊。
（2）顧客對選定的飯菜，下訂單。
（3）系統將點餐訂單交給核准選單系統和產生報表系統。
3.2.2 備選流
3.2.2.1 訂餐通知傳送失敗
由於網路或各種原因向採購部門傳送的訂貨通知傳送失敗，系統會提示失敗字元。
3.2.2.2 取消傳送訂餐通知
若取消傳送訂餐通知，則系統銷毀該訂單。
3.3 特殊需求
無。3.4 前置條件
顧客要想訂餐，必須先登入到該餐館管理系統中；當顧客補充資訊儲存後，該顧客才能進入食品管理系統進行點菜。
3.5 後置條件
該用例實現後，顧客預定飯菜的情況就通過該系統傳給核准選單系統和產生報表系統；反之，系統不向其他系統傳送任何的資訊。
3.6 擴充套件點
無。4.餐檯管理
4.1 簡要說明
本用例是用來確定顧客餐檯資訊之用。當顧客提交了顧客資訊單後，系統與餐檯資訊庫進行連線，通過檢測若有滿足的餐檯型別，則直接反饋給顧客他們的餐檯資訊（包括餐檯型別和餐檯號等）；若發現顧客所需的餐檯型別暫時沒有空台時，系統反饋資訊給顧客，讓顧客進行一些選擇（比如是調整就餐時間還是分開就坐等）。
4.2 事件流
4.2.1 基本流
當接收到顧客資訊單資訊時，開始執行以下基本流：
(1)根據顧客細資訊單資訊，連線餐檯資訊庫。
(2)根據就餐時間和就餐人數對比餐檯資料庫，確定餐檯號。
(3)向顧客傳送反饋資訊，給定餐檯號。
4.2.2 備選流
4.2.2.1 餐檯無空缺
若發現顧客所需的餐檯型別暫時沒有空台時，系統反饋資訊給顧客，讓顧客進行一些選擇（比如是調整就餐時間還是分開就坐等）。
4.3 特殊需求
無。4.4 前置條件
顧客個人資訊和就餐時間就餐人數必須已經填寫完成並提交，被儲存至顧客資訊庫。
4.5 後置條件
如果該用例成功，會生成通知顧客的反饋資訊。否則，系統維持原狀。
4.6 擴充套件點
無。5. 核准選單
5.1 簡要說明
本用例是用來確定顧客選單資訊之用。當顧客提交了點餐資訊單後，系統與食品庫存清單進行連線，通過檢測若全部能夠滿足，則直接列印出選單交給廚房工作人員，並將該選單資訊傳給產生報表系統；若發現有不能滿足的食品，則將核准後的選單交由廚房工作人員與產生報表系統。
5.2 事件流
5.2.1 基本流
當核准選單系統收到食品管理系統傳來的選單資訊以後，開始執行以下基本流：
（1）檢查選單資訊。
（2）連線食品庫存清單。
（3）進行對比，確定核准後選單。
（4）列印出核准後選單，交由廚房工作人員並將核准選單傳給產生報表系統。
5.2.2 備選流
無。5.3 特殊需求
無。5.4 前置條件
顧客必須提交了訂餐資訊。
5.5 後置條件
如果該用例成功，則列印出選單交給廚房工作人員，並將選單傳給產生報表系統。否則，系統維持原狀。
5.6 擴充套件點
無。6. 產生報表
6.1 簡要說明
對比原始選單和核准後的選單，確定是否需要食品採購，如若需要採購，則產生採購清單，並將採購清單交由採購員，同時將採購單資訊傳給採購消費資訊處理系統
6.2 事件流
6.2.1 基本流
當產生報表系統收到原始選單和核准後的選單時，開始執行以下基本流：
（1）系統對比原始選單和核准後的選單。
（2）如需採購，列印出採購清單給採購員，讓採購員去採購。
（3）將採購資訊傳給採購消費資訊處理系統。
6.2.2 備選流
6.2.2.1 列印失敗
由於網路或各種原因沒有出處資料導致列印失敗，系統會提示失敗字元，重新進行列印。
6.3 特殊需求
無。6.4 前置條件
原始選單和核准後的選單必須都已經傳入產生報表系統。
6.5 後置條件
如有需要，則列印出採購清單交給採購員並同時將採購資訊交給採購消費資訊處理系統。
6.6 擴充套件點
無。7. 採購消費資訊處理
7.1 簡要說明
採購資訊進入該系統，該系統連線食材**表，對採購花費進行統計，並將花費訊息進行統計存入財務資料庫。
7.2 事件流
7.2.1 基本流
當採購資訊進入該系統時，開始執行以下基本流：
（1）該系統連線食材**表。
（2）對比採購資訊和食材**表，統計出採購花費資訊。
（3）將採購花費資訊存入財務資料庫。
7.2.2 備選流
7.2.2.1 食材**表連線失敗
由於網路等原因，無法連線食材**表。進行再次連線或者稍後重試。
7.2.2.2 採購花費資訊存入失敗
由於網路或者線路問題，存入失敗，系統提示錯誤資訊，系統進行重傳。
7.3 特殊需求
無。7.4 前置條件
採購資訊必須進入該系統。
7.5 後置條件
該用例成功，則財務資料庫存入一條新的資訊，否則，系統資料庫維持現狀。
7.6 擴充套件點
無。8.消費統計
8.1 簡要說明
該系統連線食材**表，和核准後選單進行對比，計算出顧客消費情況，並將顧客消費情況傳給收銀員，同時將資訊存入財務資料庫。
8.2 事件流
8.2.1 基本流
當核准後選單進入該系統時，開始執行以下基本流：
（1） 該系統連線食材**表。
（2） 對比食材**表和核准選單，計算出顧客消費情況。
（3） 將顧客消費情況傳給收銀員。
（4） 將顧客消費情況存入財務資料庫。
8.2.2 備選流
8.2.2.1食材**表連線失敗
由於網路等原因，無法連線食材**表。進行再次連線或者稍後重試。
8.2.2.2 顧客消費資訊存入失敗
由於網路或者線路問題，存入失敗，系統提示錯誤資訊，系統進行重傳。
8.3 特殊需求
無。8.4 前置條件
核准選單必須進入該系統。
8.5 後置條件
該用例成功，則財務資料庫存入一條新的資訊，否則，系統資料庫維持現狀。
8.6 擴充套件點
無。三補充規約
1.目的
本補充規約列出了餐館管理系統的非功能性需求和部分全域性性需求。它和用例模型在一起，組成了完整的系統需求規格說明書。
2.範圍
本說明書除定義了許多用例中共有的功能性需求以外，還定義了系統的非功能性需求，如可靠性、可用性、系統效能和可支援性等。
3.參考
無4功能性
4.1滿足多個顧客的併發執行。
4.2當顧客預定飯菜時，系統必須判斷該食品是否還有剩餘，若該食品已無庫存，需提醒顧客，並通知採購部門進行採購。
5 可用性
顧客介面視窗與windows系統相容。
6. 可靠性
保證系統在配置完成以後24小時都可用，平均無故障時間應超過300小時。
7.效能
7.1 該系統應支援多達1000名顧客在任意特定時間使用**資料庫，並支援多達500名顧客在任何時候訪問本地伺服器。
7.2 系統要求對資料庫的訪問，訪問速度要快，特別是對食品目錄的訪問的反應時間要在8秒內
8. 可支援性
無。9. 安全性
系統要求有較高的安全性，由於在管理訂單時，顧客的資訊都在網路上傳輸，所以必須提供額外的安全性措施。
10 設計約束
無。四術語表
1.簡介
本文件用來對一些術語進行定義，同時對用例說明或其他文件中讀者不太熟悉的術語進行解釋性的描述。
2.名詞定義
這份術語表包含了餐館管理系統的重要概念。
2.1 顧客：指每個使用該餐館管理系統進行預定的人和每個到餐廳吃飯時登記的人。
2.2 前台客服：負責接待顧客和管理輸入顧客的個人資訊及點餐資訊。
2.3 廚房工作人員：餐館的工作人員，包括核准選單列印人員和廚師以及傳菜生。
2.4 收銀員：顧客就餐結束時的接待處理人員，負責顧客的結賬管理。
2.5 食品：餐館**的一切食物（包括主食、零食以及酒水等）。
2.6 個人資訊：使用者註冊時填寫的資訊。
圖書管理系統用例建模報告用例圖類圖時序圖
本實驗要求學生對學校的圖書館管理系統進行需求分析，對系統功能進行用例建模，畫出用例圖，類圖以及相應的時序圖。在使用uml對系統建模時，學會使用uml建模工具，熟悉工具中的功能。1 1 行為者 主要行為者 讀者。1 2 前置條件 讀者進入圖書管理系統。1 3 事件流 1.3.1 主要事件流 1.3.1...
倉庫管理系統用例規約
目錄1.簡介 3 1.1 目的 3 1.2 範圍 3 1.3 定義 首字母縮寫詞和縮略語 3 1.4 參考資料 3 1.5 概述 3 2.整體說明 3 3.具體需求 3 3.1 功能 3 3.1.1 使用者登入 3.1.2 產品入庫 3.1.3 產品出庫 3.1.4 入庫產品查詢 3.1.5 基礎資...
圖書管理系統uml用例圖
use case圖即用例圖，是從外部使用者的角度來描述系統功能的一種需求表達方式。乙個系統常常包含了眾多的用例，每個用例表達了使用者對系統的一項需求或描述了人們使用系統某項功能的途徑。使用系統的不同功能，其操作的場景不同。而使用相同的功能，其場景則相似。將同一用例的場景用文字描述出來就得到了系統用例...