第一篇:UML 網(wǎng)吧管理系統(tǒng)
貴州師范大學職業(yè)技術(shù)學院
系統(tǒng)名稱:
姓 名:
班 級: 08 專 業(yè): —— UML基礎教程 ——
考 察 報 告
網(wǎng)吧管理系統(tǒng) 成豪 王建勇 何汶峰 彭健 楊茂科 楊勝文 楊興福 楊家權(quán) 計應 計算機應用技術(shù)
目
錄
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
UML實驗報告
第二篇:UML庫存管理系統(tǒng)
UML課程設計
報告 設計名稱: 庫存管理系統(tǒng)
專業(yè)班級: 姓 名: 學 號: 起止時間: 成 績 評 定
考核 設計 設計 綜合評 答辯 內(nèi)容 表現(xiàn) 報告 定成績 成 績 計算機科學與工程系
一、系統(tǒng)需求說明 20世紀90年代以來隨著科學技術(shù)和生產(chǎn)力的迅速發(fā)展以及經(jīng)濟全球環(huán)境的深刻變化,企業(yè)面臨著一個嶄新而又激烈的競爭環(huán)境,體現(xiàn)在全球化的信息網(wǎng)絡和全球化市場形成所帶來的信息爆炸技術(shù)變革的加速市場和勞務競爭的全球化,圍繞新產(chǎn)品的市場競爭日趨激烈,用戶的需求越來越苛刻,同時產(chǎn)品的生命周期不斷縮短,企業(yè)又面臨著縮短交貨期、提供產(chǎn)品質(zhì)量、降低成本和改進服務的壓力,在這種情況下全面提高和改善自身水平成為企業(yè)最關(guān)心的問題之一。企業(yè)實施信息化建設已成為企業(yè)的發(fā)展趨勢和提高企業(yè)的管理水平的有效手段。信息化建設不在是企業(yè)的效益工程而是企業(yè)的生存工程,20世紀90年代美國著名的IT分析公司Grant Group Inc,提出了ERP企業(yè)資源計劃的概念,迎合了信息時代企業(yè)管理的發(fā)展要求。隨著ERP相關(guān)理論,以及ERP系統(tǒng)開發(fā)的逐漸成熟,企業(yè)界掀起了實施ERP管理信息系統(tǒng)的浪潮。中國作為制造大國,在制造業(yè)迅速發(fā)展的今天,庫存國民投資額在整個國民生產(chǎn)總值占有相當大的比重達到了20%——30%,庫存管理的適當與否對企業(yè)經(jīng)營利潤有很大影響,因此新環(huán)境下非常值得人們對ERP環(huán)境下的庫存管理進行深入研究和探討。本文結(jié)合ERP環(huán)境下的庫存管理系統(tǒng),重點研究如何利用UML建模語言對庫存管理系統(tǒng)進行建模,給出了ERP環(huán)境下庫存管理系統(tǒng)的需求模型和對象模型,在建模過程中利用了用例圖、類圖、包圖、順序圖等圖形。最后,結(jié)合系統(tǒng)模型的研究,實現(xiàn)了庫存管理系統(tǒng)。
二、系統(tǒng)分析
(一)庫存管理業(yè)務流程分析 企業(yè)的庫存管理工作主要由企業(yè)物資部門或倉庫部門完成,其主要業(yè)務就是對企業(yè)物料收獲、存貨、發(fā)貨,以及分析提供庫存管理所需的各種數(shù)據(jù)報表等管理工作。庫存管理業(yè)務流程圖,如圖所示: 采購部門采購訂單 供應商發(fā)票 財務部門發(fā)貨 檢驗接受庫存盤點發(fā)銷售出入庫票貨款憑證求購處理入庫領料通知單生產(chǎn)發(fā)料發(fā)料 生產(chǎn)部門倉庫部門客戶入庫 庫存訂單工票產(chǎn)品入庫分析提貨單決策部門銷售部門 2
(二)Uml表示法 1.1 用例圖 根據(jù)業(yè)務流程圖確定系統(tǒng)邊界,確定用例(Use Case)。用例可從另一個方面對企業(yè)的業(yè)務流程建模,從中可以提取對我們開發(fā)系統(tǒng)有用的信息,可以確定系統(tǒng)功能。如圖2所示庫存管理系統(tǒng)的用例圖
inter manageout manageadministratorinventory manage
information search
該圖展示了一張倉庫管理系統(tǒng)的用例圖,從系統(tǒng)的外部執(zhí)行者的角度來看,普通倉庫管理員可以進行出庫管理、入庫管理、盤點管理和信息查詢等操作。(2)順序圖
: administrator1: load
2: back3: data name and position4: copy data5: copy success 3
(3)活動圖
produce inventory bills inventory on the spot inventory manage
三、系統(tǒng)設計報告(一)庫存管理系統(tǒng)需求模型的建立
1、用例圖 在庫存管理系統(tǒng)中,由于牽扯到大量的執(zhí)行者和用例,為了便于組織,按與系統(tǒng)交互的對象的不同將系統(tǒng)劃分為三個包,如圖所示:
用例模型包圖 其它系統(tǒng)與倉庫高層決策人員和系統(tǒng)倉庫管理員管理系統(tǒng)的交互 管理員與系統(tǒng)的交互 與交互系統(tǒng) 倉庫管理員與系統(tǒng)交互包主要描述倉庫管理員要使用系統(tǒng)的那些功能,向系統(tǒng)輸入哪些信息,從系統(tǒng)獲取哪些信息,以及需要系統(tǒng)提供哪些功能支持倉庫管理員的日常工作。高層決策人員及系統(tǒng)管理員與系統(tǒng)交互包描述高層決策人員需要從系統(tǒng)獲取什么信息,做出什么分析與決策支持系統(tǒng)更好的運轉(zhuǎn);系統(tǒng)管理員則需要維護,管理系統(tǒng),使其正常化工作。由于庫存管理系統(tǒng)并不是一個孤立系統(tǒng),他需要其他系統(tǒng)進行交互,其他系統(tǒng)與庫存管理系統(tǒng)的交互包則反映交互信息的流向。下面對每個系統(tǒng)包進行詳細的描述。4
(1)倉庫管理員與交互的用例模型
high-inventory alarm identity testexpand
useinventory place appointaccount updateinter manageuseexpandadministratorout
managelow-inventory alarminventory manageinformation searchform produce 在這個用例模型中有一個執(zhí)行者:庫存管理員。十一個用例:身份驗證,入庫管理員,最高庫存警報,出庫管理,最低庫存管理,指定庫位,更新賬目,庫存信息查詢,盤點管理及報表生成。當有物資需要進行出入庫時,倉庫管理員就要進行出入庫的管理:核實賬單,清點物資,錄入單據(jù),然后由系統(tǒng)自動為該批物資分配貨架,同時更新賬目。在入庫時,如果系統(tǒng)檢測該類物資庫存量超過限定的最高存量,也將發(fā)出警報。在入庫管理用例與最高庫存警報用例,出庫管理用例與最低庫存警報用例之間采用了擴展關(guān)系。入庫管理,出庫管理與指定庫位之間,指定庫位與更新賬目之間采用了使用關(guān)系。擴展時一種基本需求的特殊情況。而當在兩個或更多的用例中出現(xiàn)重復描述而又想避免這種重復時,采用使用。出入庫單據(jù)錄入后,倉庫管理員還需要定期對單據(jù)進行核對,即進行庫存信息的查詢,主要包括:賬目信息,出入庫信息,以及庫位信息,存量信息等。當所有信息核對完成后,倉庫管理員還需要定期打印出各種報表,以供其他系統(tǒng)做出一些決策。盤點也是庫管員一項很重要的工作,保持經(jīng)常有效的盤點,可以更加全面準確的掌握庫存信息。當庫管員進行盤點時,首先要鎖定盤點的庫位或物料信息,即盤點時刻不允許出入庫;盤點完畢后,要填寫盤點記錄,對于盤點數(shù)量與賬目數(shù)量不同的物料需求要給出原因。5
(2)高層決策人員與系統(tǒng)管理員的交互用例模型
inventory originallimits manage
inventory controlidentity testadministratorhigh-adminform produceanalyze reportdata copy and resume 在這個用例模型中共有兩個執(zhí)行者:高層決策人員,系統(tǒng)管理員。七個用例:基本信息維護、數(shù)據(jù)的備份與恢復、身份驗證、倉庫信息初始化、庫存控制、分析評價及庫存信息查詢。其中身份驗證和庫存信息查詢用例和庫管員和系統(tǒng)的交互的用例是同一用例。對于高層決策人員來講倉庫一些基本信息的初始化,主要是賬目和庫位信息初始化。當系統(tǒng)開始使用,高層決策人員還是要進行一些庫存控制,即為了滿足用戶及生產(chǎn)需求,確定最低庫存量,決定訂貨時間及訂貨量。當然為了及時動態(tài)了解庫存情況,還需要一些庫存信息進行分析評價,例如:資金占用情況,積壓失效情況,倉庫使用情況等。不論是做決定還是分析,都需要庫存基本信息支持。對于系統(tǒng)管理員來講,主要的工作室進行基本信息的維護,包括權(quán)限的管理和數(shù)據(jù)的備份與恢復。(3)其它系統(tǒng)與庫存系統(tǒng)的交互
out manageform produceproduce sys information searchsupply syscost manage project data syssell sysinter manage 由于庫存管理系統(tǒng)并不是一個獨立的系統(tǒng),他需要和其他系統(tǒng)進行信息的集成,以保證數(shù)據(jù)的完整和準確。再生產(chǎn)計劃出入庫時,需要根據(jù)計劃來限制出入庫的物資品種及數(shù)量。6
當然,計劃的制定還需要準確的庫存信息。采購供應管理系統(tǒng)需要根據(jù)庫存信息來制定采購計劃,外購物資則需要根據(jù)采購計劃進行入庫。庫存管理系統(tǒng)需要用工程數(shù)據(jù)管理系統(tǒng)中的一些基本信息,包括:物料信息,人員信息,以支持系統(tǒng)準確的進行。銷售和成本核算管理系統(tǒng)的梳理進行同樣需要庫存數(shù)據(jù)的支持。2.業(yè)務活動圖(1)物資入庫活動 inter form receive identity test inter manage inventory inventory inventory place checkcheckstate check alarm transmit inventory place appoint account update 物資的出入庫是庫存管理中主要的業(yè)務,合理的出入庫流程不僅能加快出入庫的效率,7
而且能夠?qū)齑嫘畔⒆龅叫闹杏袛?shù)。當一批物資需要進行出入庫時,首先庫管員需要核對入庫單,清點入庫物資,當入庫單據(jù)與入庫物資相符時,才能入庫。接著庫管員登錄系統(tǒng),通過身份驗證,進入入庫管理主界面。輸入要入庫物資的基本信息后,系統(tǒng)自動進行一些信息查詢:存量信息,庫位狀態(tài),盤點狀態(tài)。當該類物資存量超出最高庫存量,系統(tǒng)發(fā)出報警,此時可以退出系統(tǒng),即此類物資不在進行入庫,也可以強行入庫。在檢查庫位信息時,如果發(fā)現(xiàn)沒有空余庫位,同樣系統(tǒng)會發(fā)出警報,但允許入庫,只是需要人工指定庫位。完成上述步驟,系統(tǒng)會主動為物資安排庫位,更新賬目,到此時也就完成入庫過程。(2)主要業(yè)務活動圖 inventory inter out check account place checkcheckcheck
produce
inter and
inventory formoutmanage
analyze
and
inventory NewStatevaluatecontrole 8
庫存管理的業(yè)務都是以出入庫信息,賬目信息和庫位信息為依托進行的。所以首先需要將出入庫信息,賬目信息,庫位信息進行核對,只有這些信息準確無誤才可以進行下一步的工作。核對基本信息后,為了確定倉庫內(nèi)物資,可以進行盤點;為了進行分析評價,庫存控制,可以生成報表;對一些信息篩選后,可以進行數(shù)據(jù)的備份或恢復。
(二)庫存管理系統(tǒng)對象模型的建立 1. 類圖 基本信息中的類圖 入庫類別與出庫類別的屬性為出入庫別編碼及名稱,在進行出入庫時,以其為依據(jù)判別出入庫類型,例如確定一批貨物是一般收料還是委托加工等等。不論是倉庫管理員還是系統(tǒng)管理員還是高層決策人員在登錄時,都需要進行身份驗證,以確定其權(quán)限,如果是倉庫管理員則需要細化倉庫一級權(quán)限。下圖為主要類圖及沒類圖的具體屬性及操作,如圖所示: 9
2.順序圖與協(xié)作圖(1)物資入庫順序圖
inter windowaccountshelves state
inter shelves info1: ready to assign shelve 2: shelve not null3: shelve on inventory4: shelve available5: work normal and update6: back 物資入庫順序圖 在完成入庫單與入庫項的填寫后,進入胃物資指定庫位的操作中,首先系統(tǒng)要自動檢查庫位的狀態(tài),當沒有多余庫位或者庫位正在進行盤點時,則系統(tǒng)提示不能進入下一步的操作,如果有多余庫位則系統(tǒng)自動為物資安排庫位,進行物資的入庫,同時修改庫存信息,此時完成了物資的入庫的所有操作。(2)物資入庫協(xié)作圖 5: error4: error
6: change or check of goods incoming of 3: incoming of change the form(right)formitem2: incoming of form7: checkquit9: surpass of max reserve
window of
account of incomingreserve8: less than max resevelogon 1: incoming of administrgoodsator 11
物資入庫協(xié)作圖 上圖為物資入庫的合作圖。在一批物資要入庫時,首先倉庫管理員登陸系統(tǒng)進入入庫窗體,然后進行入庫單錄入,只有在入庫單填寫正確的情況下才能轉(zhuǎn)入入庫項填寫,如果入庫項填寫錯誤時,同樣不能進行下一步操作;并且如果在填寫入庫項時發(fā)現(xiàn)倉庫內(nèi)此類物資正在盤點,則此批貨物此時不能進行入庫的,需要退出或等待。當所有條件都符合時,系統(tǒng)自動檢查物資的庫存量,但超出倉庫最大庫存時,退出所有操作;反之進入為此貨物指定庫位的操作。(3)狀態(tài)圖
系統(tǒng)人機交互狀態(tài)圖
fail logonstartlogonlogon successoperateentry/ inputdo/ check
namefinishreturncancel password and logoncancelcancelfinishexit/ quit
entry/ prompt do/ checkexit/ quit or returnoutcome 人機系統(tǒng)交互狀態(tài)圖
四、系統(tǒng)的配置與實現(xiàn)
(一)系統(tǒng)的組件圖
<
The user
The
Server The rocessinterfacedatebase 系統(tǒng)組件圖 12
(二)系統(tǒng)配置圖
clientdatab...program 系統(tǒng)配置圖
五、設計心得體會 項目實訓開始的時候,要求每兩個人選擇一個題目,本以為這會很簡單,可坐下來之后才發(fā)現(xiàn),事實并非如此。從需求分析到最后的課題的終結(jié),中間實現(xiàn)的過程都需要應用很多的理論知識,而時間的推移讓自己發(fā)現(xiàn)所學知識的膚淺性,只是模糊的停留在知識的表面,沒有對其深刻的認識與掌握,同時,這也是對信心,和耐心的一次考驗。通過這次課程設計,小組成員分工合作,我們兩個都學到了很多東西。以前不熟悉的地方都得到了很好的解決。我們通過自我學習掌握一些基本應用,并通過項目來加強對其的理解,我們完成了這一系列的設計。過程是艱苦的,但是通過這次實訓我們學到了很多,結(jié)果是美好的。這次課程設計也讓我明白了,作為一個軟件技術(shù)的學習者,多動手顯得尤為重要,另外,多看看經(jīng)典的例題,多與同學之間交流,對于知識和能力的提高也有很大的幫助。由于我們能力有限,加上時間倉促,本系統(tǒng)難免會出現(xiàn)一些不足之處,對于出現(xiàn)的問題,在此深表歉意,如果還有其他問題希望老師批評指正。13
第三篇:門診管理系統(tǒng)UML
門診管理系統(tǒng)
第1章 需求分析
1.1系統(tǒng)建設的意義
隨著社會的發(fā)展,人們的生活節(jié)奏不斷加快,各種突發(fā)事故也頻繁發(fā)生。因此對于醫(yī)護人員來說提高單位時間內(nèi)的工作效率顯得原發(fā)重要。門診管理系統(tǒng)結(jié)合了各種新的技術(shù),還將醫(yī)務人員從繁瑣重復的病歷文書書寫工作中解脫出來,為醫(yī)務人員節(jié)省出大量的時間,更好的為門診和患者服務,集中精力關(guān)注病人的診療。
1.2系統(tǒng)需求描述
從系統(tǒng)功能描述可以劃分為以下幾方面:
掛號子系統(tǒng):該系統(tǒng)有人工掛號系統(tǒng)和自主掛號系統(tǒng)。掛號子系統(tǒng)主要描述了掛號過程中的各種活動,讓病人和醫(yī)護人員更加清楚這一過程中的環(huán)節(jié)。遵循這個規(guī)范則可以節(jié)省更多的時間,從而提高醫(yī)護人員的工作效率。
查詢子系統(tǒng):此查詢系統(tǒng)可為患者提供個人病例查詢,藥品的相關(guān)信息的查詢和就診醫(yī)生的相關(guān)的信息,病人需輸入相關(guān)的驗證信息;另外醫(yī)務人員還可以通過此查詢?yōu)椴∪四孟鄳乃幤贰?/p>
收費子系統(tǒng):該子系統(tǒng)的功能是主要醫(yī)院提供打印收費票據(jù)、醫(yī)療項目收費統(tǒng)計、收費匯總等功能。此外還可以為本院的忠實患者辦理醫(yī)療卡、進行醫(yī)療卡預存。醫(yī)療卡能方便患者進行掛號及自助掛號和繳付各種醫(yī)療費用。系統(tǒng)主要功能是面向醫(yī)院的工作人員。
辦理就診卡子系統(tǒng):對于初來患者需要錄入本人的相關(guān)信息并辦好就診卡,以后掛號就可以直接使用就診卡進行掛號,這樣既減輕了醫(yī)務人員的工作負擔,同時也縮短了患者的掛號時間,能夠更短時間的就診。
第2章 系統(tǒng)的UML基本模型
2.1系統(tǒng)整體的用例模型
圖2-1系統(tǒng)整體用例模型
用例模型描述:患者主要使用查詢病例信息用例和自主掛號用例。收銀員主要使用藥費和辦理醫(yī)療卡用例,其中用費用例又包含收取掛號費和檢查費用例。護士的主要使用掛號、配藥、辦理就診卡和登記患者信息用例;信息管理人員主要使用醫(yī)護人員管理、藥品管理和病人信息管理用例;醫(yī)生主要使用檢查和診斷用例,其中診斷用例有包含開檢查單、開藥方和開診斷結(jié)果用例。
2.2系統(tǒng)整體的用戶類圖
圖2-2系統(tǒng)整體用戶類圖
系統(tǒng)用戶類圖描述:系統(tǒng)用戶有病人、醫(yī)生、護士、收銀員、信息管理人員。其中病人輸入相關(guān)驗證信息可以查詢自己的病例和相關(guān)的藥品信息;醫(yī)生可以把病人的診斷結(jié)果以及真短信息寫入;護士可以給病人掛號和辦就診卡;收銀員收取診斷費和檢查費用;信息管理人員主要是針對醫(yī)務人員、患者和藥品的相關(guān)信息進行增加、刪除和修改。
2.3系統(tǒng)總體的順序圖
圖2-3門診信息系統(tǒng)主要的順序圖
系統(tǒng)總體順序圖描述:系統(tǒng)總體可以分為登陸窗口界面、系統(tǒng)界面、相應管理界面和信息界面。在登陸窗口界面,輸入正確的身份驗證信息之后,進入相應身份的系統(tǒng)界面,然后在系統(tǒng)界面點擊或者輸入相關(guān)的信息,在數(shù)據(jù)庫中提取信息并進入相應的信息界面。
2.4查詢
2.4.1查詢系統(tǒng)類圖
圖2-4查詢系統(tǒng)類圖 類圖說明:信息查詢器類處理所有的信息查詢操作。系統(tǒng)中所有用戶的查詢功能都是通過此類提供的各種查詢方法實現(xiàn)。信息查詢器根據(jù)用戶的不同級別控制其信息的訪問權(quán)限
2.4.2查詢系統(tǒng)活動圖
圖2-5查詢系統(tǒng)活動圖
2.4.3查詢病例順序圖
圖2-6查詢病例順序圖
2.5掛號
2.5.1掛號管理子系統(tǒng)類圖
圖2-7掛號管理子系統(tǒng)類圖
2.5.2掛號管理活動圖
圖2-8掛號管理活動圖
2.6自助掛號
2.6.1自助掛號活動圖
圖2-9自主掛號活動圖 2.6.2自助掛號順序圖
圖2-10自助掛號順序圖
2.7收費系統(tǒng)
2.7.1收費子系統(tǒng)類圖
圖2-11收費系統(tǒng)類圖
2.7.2收費系統(tǒng)順序圖
圖2-12收費系統(tǒng)順序圖
2.8辦理就診卡系統(tǒng)
2.8.1辦理就診卡類圖
圖2-13辦理就診卡類圖 2.8.2辦理就診卡順序圖
圖2-14辦理就診卡順序圖
第四篇:倉庫管理系統(tǒng)課程設計 UML
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
二、倉庫信息管理系統(tǒng)分析與設計
(一)《倉庫信息管理系統(tǒng)》的需求建模
1、需求分析
倉庫信息管理系統(tǒng)要能完成以下功能:
倉庫存放的貨物品種繁多,堆存方式以及處理方式也非常復雜,隨著業(yè)務量的增加,倉庫管理者需要處理的信息量會大幅上升,因此往往很難及時準確的掌握整個倉庫的運作狀態(tài)。針對這一情況,為了減輕倉庫管理員和操作員的工作負擔,此系統(tǒng)在滿足倉庫的基本管理功能基礎上發(fā)揮信息系統(tǒng)的智能化。
根據(jù)要求可將系統(tǒng)分為四個模塊(1)用戶登錄模塊
普通操作員和管理人員登錄此系統(tǒng),執(zhí)行倉庫管理的一些操作,但是普通操作員和管理人員所能執(zhí)行的功能不一樣。(2)倉庫管理模塊
管理員工作需要登陸系統(tǒng),才能夠進行操作,系統(tǒng)中的各項數(shù)據(jù)都不允許外人隨便查看和更改,所以設置登陸模塊是必須的??梢詧?zhí)行倉庫進貨,退貨,領料,退料;商品調(diào)撥,倉庫盤點等功能。(3)業(yè)務查詢模塊
在用戶登錄系統(tǒng)后,可以執(zhí)行庫存查詢,銷售查詢,倉庫歷史記錄查詢。
(4)系統(tǒng)設置模塊
顯示當前倉庫系統(tǒng)中的信息,在系統(tǒng)中可以執(zhí)行供應商設置,倉庫設置。
2、功能模塊分析(1)登錄模塊
? 普通操作員:顯示當天倉庫中的所有庫存的信息。? 管理員:修改倉庫中的庫存信息。
? 用戶注銷:在用戶執(zhí)行完倉庫功能時,注銷。? 用戶退出。(2)管理模塊
? 倉庫庫存的進貨與退貨;
? 倉庫中的庫存需要領料和退料功能;
? 倉庫也可以完成不同地區(qū)的商品在此倉庫的商品調(diào)撥任務; ? 用戶人員也可以在當天之后對倉庫中的庫存進行盤點。(3)查詢模塊
? 顯示當前倉庫商品信息,并執(zhí)行庫存查詢; ? 顯示倉庫信息,對商品的銷售量進行查詢; ? 此系統(tǒng)還可以對倉庫歷史記錄進行查詢。(4)設置模塊
? 供應商設置 ? 倉庫設置
3、工作內(nèi)容及要求
? 進一步細化需求分析的內(nèi)容,識別出系統(tǒng)的參與者,并完成用例圖; 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
將用例圖中的每個用例都寫成相應的事件流文檔;
進一步使用活動圖來描述每個用例,為后續(xù)的系統(tǒng)設計做好準備;
按照系統(tǒng)的功能分析,從用例的描述中提取出系統(tǒng)的對象類和界面類,建立類圖;
分析類圖中的實體類和實體類之間的關(guān)系,畫出數(shù)據(jù)庫的邏輯模型圖(只包含實體類,且注明角色和階元)。
? 對數(shù)據(jù)庫的邏輯模型進行優(yōu)化,取消多對多的聯(lián)系,完成最終的邏輯模型設計; ? 使用交互作用圖或狀態(tài)機圖完成系統(tǒng)動態(tài)行為的建模。(建議使用順序圖按功能分別描述)
4、創(chuàng)建SRS文檔:
? 引言
? 倉庫管理系統(tǒng)將24小時為用戶服務。? 用途
? SRS文檔將作為SDLC設計和編碼階段的輸入。? 作用域
? 管理員直接對系統(tǒng)進行管理。? 功能性需求
? 操作員需要取得管理員的認可才可以登錄此系統(tǒng)。? 操作員可以查詢庫存的信息。
? 系統(tǒng)管理員可以管理登錄系統(tǒng)以后對倉庫進行管理
? 因為不是每個人都可以隨便修改系統(tǒng)的,所以系統(tǒng)管理員可以登錄進系統(tǒng)以后對用戶的權(quán)限信息進行管理。
? 界面需求
? 界面應該清晰易懂。? 運行環(huán)境
? 此系統(tǒng)可以在網(wǎng)絡上進行運行。? ? ? ? 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
用例圖如下:
分析:操作員在進行驗證后登陸系統(tǒng),可以執(zhí)行商品的進退貨的記錄信息的查詢與管理等操作。
用戶登錄**倉庫領料倉庫進貨**退出系統(tǒng)****商品調(diào)撥**操作員****用戶注銷*倉庫退料*倉庫退貨c
圖1 操作員用例圖
分析:此用戶是管理員,可以對倉庫信息進行維護,倉庫商品進行盤點,業(yè)務分析,歷史記錄查詢,供應商信息維護和倉庫查詢操作。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
倉庫信息維護用戶登錄****用戶注銷******管理員***退出系統(tǒng)倉庫盤點*倉庫查詢**供應商信息維護*業(yè)務分析歷史記錄查詢*
圖2 管理員用例圖
分析:該用戶為供應商,可以對執(zhí)行倉庫進貨和退貨的查詢與管理操作。
倉庫進貨***商品供應商*倉庫退貨
圖3 供應商用例圖
(二)《倉庫管理系統(tǒng)》的靜態(tài)建模
靜態(tài)建模用于描述軟件的靜態(tài)成分,又叫結(jié)構(gòu)建模。它包含類關(guān)系圖和對象關(guān)系圖。用于描述軟件系統(tǒng)的成分之間的關(guān)系和依賴性。1)類的分析與設計
? 確定初始類圖 ? 提取類的屬性 ? 提取類的操作 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
? 類之間的關(guān)系
去除不必要的類和不正確的類:
1.冗余類:若兩個類表述同一信息,保留最具有描述能力的類; 2.不相干的類:去掉與問題沒有多少關(guān)系和根本不相關(guān)的類;
3.模糊類:類必須是確定的,有些臨時類邊界定義不對,或范圍太廣,應排除; 4.屬性:如果有些名詞是用來描述某個類的,那么它一定是這個類的屬性。5.操作:如果所描述的操作并不適用于對象并且被自身所操作,那么這一定不是類。這樣可以得到相關(guān)的三種類關(guān)系: ? 人員信息包類圖 ? 接口信息包類圖 ? 系統(tǒng)事務信息包類圖 2)確定類之間的關(guān)系
兩個類之間的相互依賴就是關(guān)聯(lián),關(guān)聯(lián)常用描述性動詞或動詞組來表示,其中有物理位置的表示、傳導的動作、通信、所有者關(guān)系及條件的滿足等等。通過以上方法可以確定類圖:
① 人員信息包類圖里包含:操作員類、管理員類、供應商類、商品進貨模塊類、商品退換模塊類、商品打印模塊類、庫存查詢模塊類、商品盤點模塊類、歷史信息查詢模塊類和商品調(diào)撥模塊類。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
**操作員-姓名-id號-權(quán)限+倉庫進貨()*+倉庫退貨()+倉庫領料()+倉庫退料()+商品調(diào)撥()*+用戶登錄()+用戶注銷()+退出系統(tǒng)()+盤點信息打印報表()+進貨商品打印報表()*+退換商品打印報表()+商品庫存信息()**商品進貨模塊+商品清單()+退貨清單()+查詢信息()庫存查詢模塊**商品打印模塊*
圖4 人員信息包類圖
供應商-供應商姓名-供應商id號-聯(lián)系方法+進貨()+退貨()*1管理員-姓名-id號-權(quán)限+供應商信息維護()+倉庫信息維護()+盤點信息()+倉庫查詢()+業(yè)務分析()+用戶注銷()+退出系統(tǒng)()+歷史記錄查詢()+用戶登錄()+查詢結(jié)果()*歷史信息查詢模塊*+查詢條件()+進貨記錄()+商品調(diào)撥記錄()+商品盤點信息()*********商品退換模塊*商品盤點模塊*+審核后盤點信息()+查詢信息()**商品調(diào)撥模塊+查詢信息()+查詢條件()*+盤點信息列表()8 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
② 接口信息包類圖里包含:用戶登錄類、倉庫管理類、系統(tǒng)管理類和業(yè)務查詢類。
倉庫管理+倉庫進貨()+倉庫退貨()+倉庫領料()+倉庫退料()+倉庫調(diào)撥()+倉庫盤點()用戶登錄+用戶登錄()+用戶注銷()+退出系統(tǒng)()系統(tǒng)設置-供應商設置-倉庫信息維護業(yè)務查詢+庫存查詢()+業(yè)務分析()+歷史記錄查詢()
圖5 接口信息包類圖
③系統(tǒng)事務信息包類圖包含:用戶登錄類、供應商管理類、業(yè)務分析類、查詢歷史信息類、倉庫信息維護類、領料類、退料類、退換類、盤點類、調(diào)撥類和倉庫查詢類。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
調(diào)撥供應商管理-該操作id號-日期-管理員id號+增加供應商()倉庫信息維護-該操作id號-日期退料用戶登錄-該操作id號-登錄日期-登錄人id-name+用戶登錄()+用戶注銷()+退出系統(tǒng)()退貨-交易id-日期-操作員-交易id-日期-退料人-操作員倉庫查詢-該操作id-日期領料-交易id-日期-領料員-操作員查詢歷史信息-該操作id-日期業(yè)務分析-操作id號-日期-管理員id+opname()盤點-交易id-日期-管理員id-倉庫id
圖6 系統(tǒng)事務信息包類圖
(三)《倉庫管理系統(tǒng)》的動態(tài)建模
在完成靜態(tài)建模后,需要對系統(tǒng)實現(xiàn)動態(tài)建模。需要創(chuàng)建
? 活動關(guān)系圖:表示系統(tǒng)的靜態(tài)成分為了完成過程需要執(zhí)行的活動的順序;
? 交互關(guān)系圖:表示軟件系統(tǒng)靜態(tài)成分之間的交互,常用序列關(guān)系圖和通信關(guān)系圖。(1)活動關(guān)系圖
活動關(guān)系圖是用來對特定過程的控制流進行建模。
分析:管理員在登錄系統(tǒng)后,查看銷售記錄和查看商品庫存情況,如果缺貨就通知操作員缺貨商品清單,操作員即可聯(lián)系供應商按缺貨清單提供貨物,然后管理員更新數(shù)據(jù)庫結(jié)束,如果不缺貨直接結(jié)束。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
通知操作員缺貨商品清單查看銷售記錄聯(lián)系供應商按缺貨清單提供貨物查看商品庫存情況[ 缺貨] 接受貨物更新庫存數(shù)據(jù)庫[ 不缺貨 ]
圖7 倉庫系統(tǒng)的活動圖
(2)交互關(guān)系圖:通信關(guān)系圖、序列關(guān)系圖
①通信關(guān)系圖以消息的形式表示對象之間的交互。通信圖集中在活動著的對象上,表現(xiàn)的是相互通信的對象之間的消息傳遞,不參照時間。通信圖通過在消息上加序號表示消息傳遞的次序。序列號放在消息之前作為消息的前綴。
注:通信關(guān)系圖不描繪對象的生命線。A.管理員盤點過程協(xié)助圖
分析:操作員把盤點信息發(fā)送給管理員,管理員審查后盤點信息,在倉庫商品盤點模塊中盤點信息列表,然后交由信息打印模塊打印盤點信息列表,給操作員。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
操作員盤點信息管理員盤點信息打印列表審查后盤點信息商品信息打印模塊盤點信息列表商品盤點模塊
圖8 管理員盤點過程協(xié)作圖
B.商品管理協(xié)作圖
分析:操作員通知供應商進貨,供應商打印出進貨清單,操作員也可以對進貨退貨進行管理,供應商打印出退貨清單。
商品進貨進貨商印品打報表進貨清單操作員退貨商品供應商表庫存查詢商品退換退貨清單庫存信息進貨商品打印報
圖9 商品管理協(xié)作圖 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
C.倉庫歷史記錄查詢協(xié)作圖
分析:管理員應該先登錄系統(tǒng)。當管理員登錄系統(tǒng)以后,可以查詢歷史信息,看到商品進貨、商品盤點、商品調(diào)撥的歷史記錄。
商品進貨管理員查詢條件歷史信息查詢進貨、退貨記錄查詢條件商品調(diào)撥商品盤點圖10 倉庫歷史記錄查詢協(xié)作圖
②序列關(guān)系圖
序列關(guān)系圖以按時間排序的消息形式來表示對象之間的交互。序列關(guān)系圖和通信關(guān)系圖的區(qū)別在于通信關(guān)系圖情調(diào)對象的組織結(jié)構(gòu),而序列關(guān)系圖則按時間順序顯示對象之間交互的消息。在序列關(guān)系圖中,可以沿x軸方向排列對象。將啟動交互的對象放在最左邊。消息序列中后來的對象則放在交互啟動對象的右邊。在交互中,對象發(fā)送和接收的消息按時間升序沿y軸防止。
注:和通信關(guān)系圖不同,序列關(guān)系圖描述對象生命線。
A.倉庫盤點過程序列圖 分析:操作員將盤點信息發(fā)送給管理員,管理員審查盤點信息,然后盤點信息列表交給商品打印模塊打印后發(fā)給操作員執(zhí)行相關(guān)商品操作。
商品盤點信息
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
操作員管理員商品盤點模塊商品打印模塊盤點信息盤點信息列表()審核后盤點信息盤點信息打印報表()
圖11 倉庫盤點過程序列圖
B.商品管理序列圖
分析:操作通知商品供應商進貨、退貨,商品供應商將商品清單和退貨商品清單發(fā)送給商品進貨模塊,商品進貨模塊將進貨商品打印報表給操作員,商品退貨模塊將商品退換報表打印發(fā)給操作員,操作員也可以查詢庫存,庫存庫存模塊將庫存查詢信息發(fā)送給操作員。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
操作員商品供應商商品進貨模塊商品退換模塊進貨()商品清單()進貨商品打印報表()退貨清單()退貨()退換商品打印報表()查詢條件()商品庫存信息
圖12 商品管理序列圖
C.倉庫歷史記錄序列圖
分析:管理員登錄系統(tǒng)查詢歷史信息模塊,歷史信息則查詢商品進貨退貨模塊、商品調(diào)撥模塊、商品盤點模塊,之后各模塊將查詢得到的信息發(fā)送給歷史信息模塊,最后由歷史信息模塊統(tǒng)一將信息發(fā)給管理員。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
管理員歷史信息查詢模塊商品進貨退貨模塊商品調(diào)撥模塊商品盤點模塊查詢信息()查詢條件()進貨記錄()查詢信息()商品調(diào)撥記錄()查詢信息()商品盤點信息()查詢結(jié)果()
圖13 倉庫歷史記錄序列圖 無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
(四)《倉庫管理系統(tǒng)》的架構(gòu)建模
架構(gòu)建模使您能夠了解組件在組織網(wǎng)絡中的物理分布。您需要對軟件系統(tǒng)的架構(gòu)進行建模以確定組件的設計是否符合軟件系統(tǒng)的需要。軟件架構(gòu)描述軟件按系統(tǒng)的所有組件以及這些組件之間的關(guān)系。要對系統(tǒng)軟件的架構(gòu)進行建模,您需要創(chuàng)建以下關(guān)系圖:
? 包關(guān)系圖:描述根據(jù)特定條件分組在一起的軟件系統(tǒng)構(gòu)成。? 組件關(guān)系圖:描述軟件系統(tǒng)的可執(zhí)行構(gòu)成。
? 部署關(guān)系圖:描述軟件系統(tǒng)組件的各種處理設備。
a)組件關(guān)系圖:組件可實現(xiàn)一組接口并構(gòu)成軟件系統(tǒng)的可執(zhí)行部分。
分析:該圖是系統(tǒng)的各個組件圖,由系統(tǒng)登錄、倉庫管理管理、信息查詢、系統(tǒng)設置。
倉庫管理信息查詢系統(tǒng)登錄系統(tǒng)設置
圖14 組件關(guān)系圖
b)部署關(guān)系圖:顯示需要在其中部署軟件組件的硬件。
分析:下圖表明系統(tǒng)采用數(shù)據(jù)庫系統(tǒng)作為后臺數(shù)據(jù)提供者,然后客戶登錄使用系統(tǒng),也可以對系統(tǒng)中的信息進行打印操作。
無錫職業(yè)技術(shù)學院實踐環(huán)節(jié)材料撰寫用紙
數(shù)據(jù)服務器客戶機1客戶機n打印機
圖15 部署關(guān)系圖
第五篇:電影院售票管理系統(tǒng)UML
1.前景和范圍文檔
1.1業(yè)務需求
1.背景、業(yè)務機會和客戶需要
隨著社會的發(fā)展,人們生活水平的提高,欣賞電影逐漸成為人們閑暇時的主要娛樂方式之一。傳統(tǒng)的電影售票都是人工服務,觀看作為都是人共安排,無法體現(xiàn)人性化選擇,加上現(xiàn)在人們的生活節(jié)奏越來越快,購票時間需要相應縮短以及方便定影院工作人員的管理,因此充分利用現(xiàn)代信息化、因特網(wǎng)的優(yōu)勢,設計電影院售票管系統(tǒng),對提高系統(tǒng)建設的工作效率,提高信息的及時性、減輕各級相關(guān)工作人員的勞動強度是非常有必要的。一個完善的電影院售票管理系統(tǒng),可以幫助電影院工作人員提升工作效率,輔助電影院工作人員進行相關(guān)數(shù)據(jù)的輸入、輸出、查找、管理等操作,讓電影院售票數(shù)據(jù)變得合理化、具體化、直觀化。2.業(yè)務目標(Business Objective,BO)和成功標準(Success Criteria,SC)BO-1:初始版本發(fā)布之后的6個月內(nèi),電影院的收入提高20%。
BO-2:初始版本發(fā)布之后的3個月內(nèi),每個員工每天的平均有效工作時間增加20分鐘。
SC-1:初始版本發(fā)布后的6個月內(nèi),電影院收入顯著提高。
3.業(yè)務風險(Risk)
RI-1:使用該系統(tǒng)的顧客太少,減少了對系統(tǒng)開發(fā)和維護過程的投資回報
1.2解決方案的前景
1.前景陳述
該系統(tǒng)的開發(fā),可以提升電影院工作人員的管理效率,使得售票、檢票不再那么繁瑣;也大大的節(jié)約了人們排隊購票的時間,同時也讓人們有了更多的選擇范圍。2.主要特性(Feature)
FE-1:根據(jù)電影院提供的當天的播放場次選擇訂票 FE-2:注冊訂票的付費方式
FE-3:創(chuàng)建、瀏覽、修改和刪除電影場次 FE-4:通過公司的內(nèi)聯(lián)網(wǎng)可以訪問系統(tǒng),或者授權(quán)的員工通過外部Internet訪問系統(tǒng) 3.假設(Assumption)和依賴(Dependency)
1.3范圍和局限性
1.初始版本和后續(xù)版本的范圍
目前僅實現(xiàn)1.0版本,實現(xiàn)上述的所有功能。2.局限性(Limitation)和排斥性
LI-1:“電影院售票管理系統(tǒng)”只能支持開通網(wǎng)銀的用戶在線使用,未開通的需到影院購買。
1.4業(yè)務上下文 1.涉眾概覽
涉眾
系統(tǒng)管理員 主要價值
引進新影片,更新數(shù)據(jù)庫
態(tài)度
主要興趣
使用該系統(tǒng)所節(jié)約的費用必須超過開發(fā)此系統(tǒng)的費用和使用此系統(tǒng)的費用
約束條件
無
員工 更高效率的利用了工作人員的整個工作時間;提高了客戶的滿意度
保住工作 培訓工作人員,掌
握
使
用
Internet所必須的技能
顧客 可以更好的選擇電影、座位、場
積極支持新系統(tǒng),但使用系統(tǒng)
使用要簡單,更節(jié)約時間
需要登錄該公司的內(nèi)聯(lián)網(wǎng)
次;節(jié)約了時間,的次數(shù)可能沒有更加方便
期望的高
2.項目優(yōu)先級
因素
進度 具體干活者
約束條件
自由度
計劃3/1/03前完成第一版,到5/1/03前完成第二版;在不包括責任人評審的情況下,最多可超過期限三星期
特性
安排1.0版本實現(xiàn)的特性必須完全可操作
質(zhì)量
必須通過95%的用戶驗收測試;必須通過全部的安全性測試;所有的安全事務都必須遵守公司的標準
工作人員 項目團隊包括一名半日工作的項目經(jīng)理,兩名開發(fā)人員,和一名測試人員
費用
在不包括責任人評審 的情況下,財政預算最多可超支15%
2.用例
各種用戶類確認的“電影院售票系統(tǒng)”的用例和主要參與者如下表示: 主要參與者
用例
顧客
1.訂票
2.變更訂單
3.取消訂單
4.查看訂單
5.登陸網(wǎng)站 員工
6.處理訂單
7.檢票
8.更新余票 系統(tǒng)管理員
9.引進新片
10.更新數(shù)據(jù)庫
11.添加、更改、刪除員工信息
12.添加、刪除、修改客戶賬戶
用例ID號
UC-1 用例名稱
訂票 參與者
顧客
主要參與者
用例
描述
顧客登錄網(wǎng)站訪問”電影院售票管理系統(tǒng)“,隨意查看某
一天的上映電影,選擇自己想看的電影,選定場次、座位,提交訂單并在付款界面支付
前置條件
1.顧客成功登錄,并訪問“電影院售票管理系統(tǒng)“
2.付款成功 后置條件
1.訂單在“電影院售票管理系統(tǒng)“中的存儲狀態(tài)是
“已接受“
2.根據(jù)這一訂單來更新余票
主干過程
1.0 訂一張票
分支過程
異常
1.顧客要求查看某一天的上映表 2.系統(tǒng)顯示當日上映電影、場次及余票 3.顧客選擇自己喜歡的電影場次 4.顧客表明訂票完成 5.系統(tǒng)顯示所訂票價格
6.顧客確認訂單或請求修改訂單(回到第3步)7.顧客付款 8.系統(tǒng)確認接受訂單
9.系統(tǒng)向顧客發(fā)送電子郵件,確認訂單細節(jié),價格10.系統(tǒng)將訂單存儲在數(shù)據(jù)庫中,并更新余票
1.1訂多張票(第4步之后分支出來)
1.顧客要求預定另一場次的電影 2.返回到第2步
1.2同樣的票訂多張(第3步之后分支出來)1.顧客請求預定指定數(shù)量的電影票
2.返回到第4步
1.0.E.1
訂單截止時間在當前時間之前(第1步)
1.系統(tǒng)通知顧客今天訂票已經(jīng)太晚了 2a.顧客取消訂單 2b.系統(tǒng)終止用例
3a.顧客請求選擇另一個日期 3b.系統(tǒng)重新啟動用例
1.0.E.2
票全部售完(第1步)
1.系統(tǒng)通知顧客今日已沒有余票 2a.顧客取消訂單
2b.系統(tǒng)終止用例
包含
優(yōu)先級
使用頻率
業(yè)務規(guī)則
特別需求
假設
注意和問題
用例ID號
用例名稱
參與者
描述
前置條件
1.0.E.3 不能完成同樣的票訂多張(第1步)1.系統(tǒng)通知顧客它所能提供的該票最大值 2.顧客變更訂單數(shù)量,或者取消訂單
無
高 無 無
1.顧客在確認訂單之前的任何時刻都可以取消訂單
無 1.如果客戶在今天的截止時間之前使用系統(tǒng),那么默認的日期是當前日期,否則,默認日期為下一個營業(yè)日 2.這一用例的峰值使用負載是當?shù)貢r間早十點到晚十點
UC-6
處理訂單 員工
員工根據(jù)用戶提交的訂單,查詢是否有余票及對應場次、座位,判斷是否接受訂單
1.用戶
3.軟件需求規(guī)格說明
3.1介紹
1.目標
軟件需求規(guī)格說明描述了“電影院售票管理系統(tǒng)”1.0版本的軟件功能性需求和非功能性需求。這一文檔計劃實現(xiàn)和驗證系統(tǒng)正確功能的項目團隊成員來使用。除非在其他地方另有說明,這里指定的所有需求都具有高優(yōu)先級,而且都要在版本1.0中加以實現(xiàn)。
2.項目范圍和產(chǎn)品特性 “電影院售票管理系統(tǒng)”允許顧客在線訂購電影票,并且可以修改取消訂單。詳細的項目描述請中參見電影院售票管理系統(tǒng)前景和范圍文檔。文檔中的這一部分標題為“初始版本和后續(xù)版本的范圍”,列出了按照進度計劃在這一版本中實現(xiàn)的全部或部分特性。
3.參考文獻
(1)Karl Wiegers所著的Cafeteria Ordering SystemVision and Scope Document,其網(wǎng)址是代碼遵照HTML4.0標準 CO-4:所有腳本都用Perl語言來編寫 5.用戶文檔(User Documentation,UD)
UD-1:系統(tǒng)將提供一個分層的和跨連接的HTML聯(lián)機幫助系統(tǒng),它描述并演示了所有系統(tǒng)功能
UD-2:如果是一個新用戶第一次使用該系統(tǒng),系統(tǒng)可以根據(jù)用戶的要求,提供一個聯(lián)機教程,咋這樣用戶可以使用靜態(tài)教程來具體實踐一下如何訂票。系統(tǒng)不會將采用這一模板的訂單存儲到數(shù)據(jù)庫中,也不會將這種訂單提交給系統(tǒng)。
6.假設(Assumption)和依賴(Dependency)
3.3系統(tǒng)特性
1.訂票
(1)描述和優(yōu)先級
顧客在其身份得到驗證后,就可以訂票,只要所訂票還沒有超過播放時間,顧客就可以取消或改變訂單。優(yōu)先級為高。(2)刺激/響應序列
刺激:顧客請求訂票,可以是一張或多張 響應:系統(tǒng)向顧客詢問訂票細節(jié)、付費方式 刺激:顧客請求改變訂單
響應:如果訂單狀態(tài)是“已接受”,則系統(tǒng)允許用戶編輯以前的訂單 刺激:顧客請求取消訂單
響應:如果訂單狀態(tài)是“已接受”,則系統(tǒng)取消訂單(3)功能性需求
? 登錄到“電影院售票管理系統(tǒng)”的顧客可以通過該系統(tǒng)訂票,訂一張或多張都可以
? 顧客可以瀏覽當天的上映電影 ? 顧客可以選擇電影場次及座位
? 如果顧客所訂票數(shù)超過了現(xiàn)在余票的最大值,系統(tǒng)將通知顧客他能訂購的最大值
? 顧客可以修改訂單,刪除訂單
? 當顧客訂購完成后,系統(tǒng)將提示顧客付款 ? 顧客可以瀏覽已訂票信息
? 訂購成功后,系統(tǒng)將發(fā)送電子郵件提示用戶訂購價格及細節(jié)
(4)非功能性需求 安全性:系統(tǒng)應保證客戶信息不被泄露
可維護性
及時性:用戶點擊最多不超過3秒,系統(tǒng)應給予相應的響應
3.4外部接口需求
1.用戶界面(User Interface,UI)
UI-1:“電影院售票管理系統(tǒng)”的屏幕畫面將遵照Process Impact Internet Application User Interface Standard版本2.0 UI-2:系統(tǒng)對所顯示的每個HTML網(wǎng)頁都提供幫助鏈接,解釋如何使用這些網(wǎng)頁
UI-3:Web頁面的全部導航和票目選擇,除了綜合使用鼠標和鍵盤共同完成外,還可以只通過鍵盤來單獨完成
2.硬件接口
硬件接口還沒確定
3.軟件接口(Software Interface,SI)還沒確定
4.通信接口(Communication Interface,CI)
CI-1:“電影院售票管理系統(tǒng)”將向顧客發(fā)送電子郵件消息,以確認收到訂單、價格。
CI-2:“電影院售票管理系統(tǒng)”獎項顧客發(fā)送電子郵件信息,以報告接受訂單后存在的問題。
系統(tǒng)管理員對賬戶操作的活動圖
登錄系統(tǒng)進行賬戶維護員工賬戶顧客賬戶添加賬戶修改賬戶刪除賬戶添加刪除修改退出系統(tǒng)
顧客登錄系統(tǒng)的時序圖 顧客登陸界面服務器數(shù)據(jù)庫輸入帳號密碼發(fā)送帳號密碼到服務器查詢驗證帳號密碼查詢驗證成功將信息發(fā)送到界面提示用戶登錄成功
顧客訂票的活動圖
查找登錄NO瀏覽預訂判斷是否登錄判斷是否有余票YESNO選擇場次、座位退出系統(tǒng)付款
員工處理退票的活動圖
登錄查詢客戶訂單判斷是否有退訂YESNO查詢電影場次時間超時拒絕退出系統(tǒng)接收退票申請退錢通知顧客進度更新余票
員工處理訂單的活動圖
員工客戶登錄系統(tǒng)查看客戶訂單返回刷新判斷是否有訂單YES查詢所購信息判斷是否有余票通知客戶修改訂單客戶修改訂單接收訂單通知客戶付款客戶付款成功處理訂退出系統(tǒng)單