UML軟件建模網上話費充值系統(tǒng)

1、實驗報告課程名稱軟件建模技術實驗名稱軟件建模實驗姓名何虹江學號 201007040227 專業(yè)班級軟件1002 實驗日期 2012-11-30 成績指導教師衛(wèi)紅春(實驗目的實驗設備和環(huán)境實驗內容與步驟實驗結果與分析總結,問題及建議一、實驗目的通過Enterprise Architect 工具熟悉業(yè)務建模、需求建模、分析建模和設計建模的過程。二、實驗設備和環(huán)境三、實驗內容和步驟軟件模型設計(Page 2 Page 四、實驗結果與分析實驗結果與設計相符,說明實驗達到目的。五、總結,問題及建議我這次建立的是網上話費充值系統(tǒng)的模型。通過在EA對4種模型的建立,進一步了解了各圖表的功能,掌握了基本的設計

2、步驟。將理論結合實踐之后,對各項模型有了更加深刻的理解。但是實驗中也發(fā)現(xiàn)不少問題:1.圖表不熟悉,需要反復試驗各種圖表才能正確的繪圖;2.部分功能實現(xiàn)相對困難,對模型的理解不夠深刻導致一些參數沒有正確的運用。因此,在今后的UML建模中還需要多加鍛煉,還需要多次閱讀教材和相關書籍軟件模型設計目錄1業(yè)務建模 (31.1項目概述 (31.2企業(yè)使命 (31.3業(yè)務目標 (31.4企業(yè)的優(yōu)勢、挑戰(zhàn)及對策 (31.5企業(yè)的核心競爭力 (41.6充值系統(tǒng)的關鍵過程 (41.7涉眾模型 (41.8業(yè)務主線 (51.9業(yè)務過程模型 (51.10對象模型 (91.11業(yè)務規(guī)則模型 (92需求建模 (92.1參與

3、者 (92.2需求結構 (102.3非功能需求模型 (143設計建模 (153.1PIM類模型 (153.2用例分析模型 (154設計建模 (164.1架構模型 (164.2控制型PSM類模型 (174.3用例設計模型 (174.4數據庫設計模型 (184.5界面設計模型 (194.6部署模型 (201業(yè)務建模手機在線充值:提到手機在線充值,很多人都不禁搖頭,對此嗤之以鼻,其實并無需如此。手機在線充值本身是很方便的,有快充和慢充兩種,快充一般1-10分鐘就可以充值成功,慢充時間不等。新一輪在線充值業(yè)務的開展正在如火如荼的進行,您可以根據自己的情況,選擇信得過的在線充值鏈接進行充值。本系統(tǒng)將與通

4、信公司的充值平臺對接,實現(xiàn)最便捷的充值服務。充值平臺將作為核心模塊提供,支付平臺將使用網銀和第三方支付系統(tǒng),通過記錄流水號的方式進行跟蹤處理。通過對方便周到的服務和具有競爭力的速度優(yōu)勢,擴大互聯(lián)網充值體系。u c 業(yè)務愿景BO001:提供簡捷的網上話費充值服務BO002:與移動公司合作成為充值基本服務渠道B0003:在小區(qū)等居民聚集區(qū)的自助充值機上加載本系統(tǒng)1.4企業(yè)的優(yōu)勢、挑戰(zhàn)及對策使命:建立便捷的網上充值平臺,方便客戶隨時隨地充值優(yōu)勢:作,能實現(xiàn)充值系統(tǒng)的無縫接入能實現(xiàn)支付功能劣勢:2.涉及金融服務,需獲得監(jiān)管部門許可機遇:充值模式,成本低,實現(xiàn)簡單發(fā)策略:主要的推廣目標合作,提供流量支持

5、策略:2.加速申請流程,盡快獲得政府相關部門許可輕易地移植到手機和其他移動設備,實現(xiàn)全天24小時不間斷服務挑戰(zhàn):信企業(yè)合作2.支付流程過于復雜策略:1.加速開發(fā)過程,快速占領市場臺,利用快捷支付等手段簡化支付流程策略:付企業(yè)合作的方式推出產品系p kg 核心競爭力網絡的速度優(yōu)勢便捷的隨時隨地充值,支持多種設備通過網頁登陸與通信公司合作,專業(yè)正規(guī)p kg 關鍵過程輸入信息支付處理顯示充值結果c lass 涉眾建?？蛻艟W上充值系統(tǒng)處理系統(tǒng)網上話費充值系統(tǒng)的涉眾報告編號名稱描述期望SH001 客戶網上充值的客戶便捷的進行網上充值SH002 網上充值系統(tǒng)界面及運行系統(tǒng)負責提供充值信息和數據傳輸SH00

6、3 處理系統(tǒng)核心系統(tǒng)負責充值業(yè)務網上話費充值系統(tǒng)的業(yè)務主線共涉及輸入信息、支付、處理和顯示信息4個主要業(yè)務。a ct 業(yè)務主線客戶網上充值系統(tǒng)處理系統(tǒng)輸入信息支付處理顯示信息輸入信息輸入信息主要是確認充值信息是否合理,利用AJAX技術提前給予提示。a nalysis 輸入信息輸入信息Web網頁«目標»充值信息充值信息通過客戶輸入信息優(yōu)惠活動充值表單«supply»«output»«use»«achieve»«supply»«input»a ct 輸入信息充

7、值頁面客戶進入網站顯示充值功能選擇充值確認信息是否確認驗證信息是否正確提交請求是否是否支付支付功能主要是提供和網銀或第三方支付平臺的對接,提供多種支付手段。支付網上充值系統(tǒng)輸入信息«目標»支付信息支付平臺支付通過支付«input»«output»«supply»«achieve»«input»a ct 支付支付平臺支付系統(tǒng)獲取輸入信息獲取支付信息系統(tǒng)劃扣是否成功支付成功消息是否處理處理過程將直接與充值核心交換數據,為了保證數據安全和使用效率,將作為獨立模塊運行。處理處理系統(tǒng)支

8、付信息«目標»支付結果用戶數據庫處理結果處理«output»«supply»«achieve»«input»«input»a ct 處理寫入數據庫返回信息顯示信息對充值成功的客戶進行數據反饋,給予客戶確認。a nalysis 顯示信息顯示信息處理結果顯示信息Web網頁«目標»充值詳情充值結果«output»«achieve»«supply»«input»«input&

9、#187;通過對網上話費充值系統(tǒng)的業(yè)務進行分析,提取了客戶、充值網站、充值項目表、充值信息、支付信息和處理系統(tǒng)等業(yè)務實體。c lass 對象模型客戶充值網站支付系統(tǒng)處理系統(tǒng)充值項目表充值信息c lass 業(yè)務規(guī)則R001:只能對已有的賬號繳費R002:充值金額上限是1000元R003:提交信息必須使用加密方式傳輸(httpsR004:充值必須在30分鐘完成支付,否則將會被取消2需求建模uc 參與者客戶支付系統(tǒng)處理系統(tǒng)網上充值系統(tǒng)網頁平臺網上充值系統(tǒng):包括網頁平臺、支付系統(tǒng)和處理系統(tǒng)。 網頁平臺:提供WEB 服務、數據格式校驗等基礎服務。 支付系統(tǒng):對接網銀和第三方支付平臺、提供支付途徑及進行支

10、付校驗。 處理系統(tǒng):充值平臺的核心服務。 客戶:需要進行網上充值的客戶。 頂層需求結構頂層需求結構包括3個項目:信息驗證、支付驗證和充值信息反饋,其中充值信息反饋直接由系統(tǒng)生成。 信息驗證需求結構信息驗證需求結構包括基本信息和支付信息。 基本信息:提供充值的賬戶信息,作為充值依據。 支付信息:提供支付手段等信息,方便進一步與網銀或第三方支付平臺對接。 支付驗證需求結構支付驗證包括賬號驗證和付款驗證賬號驗證:賬號驗證的內容包括賬號信息是否存在、賬號是否被停用、充值信息是夠符合標準等。付款驗證:付款驗證主要將通過流水號傳遞的方式將付款信息反饋給支付系統(tǒng)。 充值系統(tǒng)反饋用例u c 充值信息反饋充值信

11、息反饋客戶充值信息網頁平臺充值信息反饋用例名:充值信息反饋參與者:網頁平臺、客戶事件流程:1.網頁整理充值反饋信息,并進行圖文排版。2.客戶接收充值信息。 基本信息用例u c 基本信息基本信息客戶輸入賬號信息選擇支付方式輸入充值金額網頁平臺優(yōu)惠推薦生成信息清單基本信息用例名:基本信息事件流程:1.客戶瀏覽網頁,選擇充值功能。2.客戶輸入充值信息,網頁平臺檢驗數據格式是否符合規(guī)范。3.調用賬戶驗證用例,系統(tǒng)判斷是否可用。4.保存信息并調用支付信息用例。«include»«include»«include» 支付信息用例u c 支付信息支

12、付信息客戶網銀選擇第三方支付選擇支付信息用例名:支付信息參與者:客戶事件流程:1.客戶瀏覽支付頁面,選擇相應的支付平臺。2.支付系統(tǒng)與相關平臺做連接,并獲得支付編號。3.等待用戶支付。賬號驗證用例u c 賬號驗證賬號驗證網頁平臺賬號驗證賬號驗證用例名:賬號驗證參與者:網頁平臺事件流程:1.網頁平臺將充值信息提交給服務器驗證。2.等待服務器給出驗證結果,并產生唯一訂單編號。付款驗證用例u c 付款驗證付款驗證支付系統(tǒng)付款金額驗證處理系統(tǒng)付款驗證用例名:付款驗證參與者:支付系統(tǒng)、處理系統(tǒng)事件流程:1.支付系統(tǒng)將付款信息驗證信息傳遞給處理系統(tǒng)。2.處理系統(tǒng)接收付款信息驗證,生成處理編號。非功能模型包

13、括:效率、可靠性、安全性、可用性和適應性5個方面。u c 非功能需求模型效率安全可用性可靠性適應性REQ101-訪問站點時延在2秒之內REQ102-界面信息反應速度在1秒內REQ103-同時允許1000人在線充值REQ201-平均在200小時內不發(fā)生故障REQ202-出現(xiàn)故障能夠快速恢復REQ203-出現(xiàn)故障不會引起系統(tǒng)災難REQ301-多次輸入錯誤將拒絕IPREQ302-能夠保證數據安全REQ401-具有方便的聯(lián)機幫助功能REQ402-方便好用REQ403-容易學習REQ501-系統(tǒng)適應訂餐業(yè)務的擴大REQ502-軟件功能可以隨版本增加3設計建模PIM類模型解釋了從用戶輸入信息開始數據在各系

14、統(tǒng)間的傳輸方式和系統(tǒng)的附加功能。其中的流水線包括兩條:信息校驗和支付校驗,最后將NO傳遞至處理系統(tǒng)完成處理。c lass PIM類模型充值信息- 訂單編號: int- 手機號: char- 充值金額: double- 支付方式: char- 是否選擇優(yōu)惠套餐: boolean賬戶信息- 訂單編號: int- 手機號: char- 充值金額: double- 是否選擇優(yōu)惠套餐: boolean支付信息- 訂單編號: int- 支付方式: char處理系統(tǒng)- 訂單編號: int- 處理編號: int充值反饋- 訂單編號: int- 手機號: char- 充值金額: double- 當前金額: do

15、uble賬戶信息校驗- 訂單編號: int- 校驗結果: boolean支付校驗- 訂單編號: int- 校驗結果: boolean優(yōu)惠政策- 編號: int- 組合列表: char- 截止時間: date留言- 留言編號: int- 留言內容: char11 11 11 0.110.1修改信息3.2用例分析模型 充值系統(tǒng)充值系統(tǒng)將完成充值前的相關信息校驗。s d 充值系統(tǒng)客戶網頁平臺信息校驗確認信息打開網頁(提交信息(創(chuàng)建訂單(«create»顯示信息(STR(支付系統(tǒng)支付系統(tǒng)將跟蹤支付過程,最后校驗是否支付成功,具體支付過程將由網銀或第三方支付平臺負責。s d 支付系統(tǒng)

16、支付系統(tǒng)賬戶信息支付信息充值過程充值信息賬戶信息確認:Boolean(確認編號:int(支付信息確認:Boolean(確認編號:int(充值完成(充值單號4設計建模用戶交互界面將使用B/S架構,服務器之間通信將采用傳統(tǒng)的數據傳輸。軟件分層架構為4層:顯示層、業(yè)務邏輯層、實體層和數據層。p kg 軟件架構模型數據層實體層業(yè)務邏輯層表示層4.2控制型PSM 類模型c lass 控制型PSM類模型表單數據控制器+充值服務可用: boolean + 數據格式驗證: boolean +賬戶信息驗證: boolean支付控制器+ 提交支付請求: boolean + 支付跳轉: boolean +接收支付結

17、果: char充值查詢控制器+ 注入充值數據庫: char + 準備充值信息: char +充值結果查詢: char安全控制器+加密傳輸會話控制器+ cookie添加: char +cession會話: char信息提交用例設計s d 用例設計«View頁面»IndexPage 客戶«控制類»CheckAction«實體類»Submit«實體類»ForwardlooppostForm(AddNO( :char«create»Add(«create»showFormData(A

18、ddCheck(«create»支付提交用例設計s d 支付提交«View頁面»IndexPage «控制類»Forward客戶«實體類»PayPage«View頁面»PayPageloop PostForm(:Forward«create»PostPay(«become»ToPay(«create»show( :char show( :charPostCheck( :boolean«create»DDL描述的數據庫邏輯結構 網站主要提供充值繳費功能,同時顯示的有優(yōu)惠推薦已指導客戶選擇最合理的充值方式和留言板以收集客戶的意見和建議。a nalysi