關(guān)于鐵路售票系統(tǒng)架構(gòu)評審文檔

1、鐵路售票系統(tǒng)架構(gòu)評審文檔虛擬的一人多角色的評估小組，成員列表如下：表1：評估小組成員列表成員角色評估小組負(fù)責(zé)人、評估總結(jié)者、提問者、場景書記員、時間管理者評估負(fù)責(zé)人、提問者、架構(gòu)設(shè)計師、提問者、進(jìn)展書記員、數(shù)據(jù)收集人、提問者、領(lǐng)域?qū)＜摇①Y料員時間管理者、提問者、場景書記員、資料員目錄鐵路售票系統(tǒng)架構(gòu)評審文檔1引言3編寫目的：3背景：3定義：3三層架構(gòu)軟件設(shè)計3ATAM架構(gòu)評審模式3參考資料：4第0階段：合作關(guān)系及準(zhǔn)備工作4第1階段：評估階段5項目產(chǎn)品立項表述：5架構(gòu)方法分類：5架構(gòu)表述：6初步架構(gòu)類圖：7質(zhì)量屬性及采用的戰(zhàn)術(shù)：7生成質(zhì)量屬性效用樹：8初步分析架構(gòu)方法：9性能9可用性10安全性1

2、0戰(zhàn)術(shù)采用10第2階段：評估階段11集體討論并確定場景的優(yōu)先級：11再次分析架構(gòu)方法：12三層結(jié)構(gòu)選擇12LRU緩沖技術(shù)分析12MD5加密存儲分析12備份數(shù)據(jù)庫13改進(jìn)架構(gòu)類圖14結(jié)果表述14第3階段：后續(xù)階段14附錄15擬采用架構(gòu)評審方法中的ATAM方法15引言編寫目的：本文檔的編寫目的是對鐵路售票系統(tǒng)架構(gòu)設(shè)計進(jìn)行簡略的評審，為后繼的詳細(xì)項目設(shè)計等工作提供參考和依據(jù)，本文檔主要描述的內(nèi)容有：l 表述l 調(diào)查和分析l 測試l 形成報告本文檔的預(yù)期讀者為：系統(tǒng)設(shè)計人員、測試人員、用戶及其它有權(quán)限查閱本文檔的相關(guān)人員。背景：l 系統(tǒng)名稱：鐵路售票系統(tǒng)l 任務(wù)提出者：黃東鵬、張付俊、孫帥l 開發(fā)者（

3、承接單位）：開發(fā)小組l 用戶：網(wǎng)上訂購鐵路車票的人定義：三層架構(gòu)軟件設(shè)計所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個中間件層，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機(jī)器就是三層體系結(jié)構(gòu)，也不僅僅有B/S應(yīng)用才是三層體系結(jié)構(gòu)，三層是指邏輯上的三層，即使這三個層放置到一臺機(jī)器上。三層體系的應(yīng)用程序?qū)I(yè)務(wù)規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進(jìn)行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進(jìn)行交互，而是通過COM/DCOM通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進(jìn)行交換。ATAM架構(gòu)評審模式1.概述Architecture Tradeoff Analysis

4、Method(構(gòu)架權(quán)衡分析方法）。他是評價軟件構(gòu)架的一種綜合全面的方法。這種方法不僅可以揭示出構(gòu)架滿足特定質(zhì)量目標(biāo)的情況，而且（因為它認(rèn)識到了構(gòu)架決策會影響多個質(zhì)量屬性）可以使我們更清楚地認(rèn)識到質(zhì)量目標(biāo)之間的聯(lián)系即如何權(quán)衡諸多質(zhì)量目標(biāo)。ATAM評估方法的主要目的： 1) 提煉出軟件質(zhì)量屬性需求的精確描述； 2) 提煉出構(gòu)架設(shè)計決策的精確描述； 3) 評估這些構(gòu)架設(shè)計決策，并判定其是否令人滿意的實(shí)現(xiàn)了這些質(zhì)量需求。ATAM評估方法并非把每個可以量化的質(zhì)量屬性都進(jìn)行詳盡的分析，而是使眾多的風(fēng)險承擔(dān)者（包括經(jīng)理、開發(fā)人員、測試人員、用戶、客戶等等）都參與進(jìn)來，由此而達(dá)到上述目標(biāo)的。 ATAM是一種挖

5、掘潛在風(fēng)險，降低或者緩和現(xiàn)有風(fēng)險的軟件構(gòu)架評估方法。因此，以下三點(diǎn)是評估中要特別注重的：風(fēng)險、敏感點(diǎn)和權(quán)衡點(diǎn)。2構(gòu)架涉眾 普通用戶、用戶管理員、票務(wù)管理員、開發(fā)人員、測試人員參考資料：Software ArchitectureinPractical（第三版）第0階段：合作關(guān)系及準(zhǔn)備工作此次對項目的評估方法經(jīng)小組協(xié)商討論是采用ATAM架構(gòu)評估綜合方法。待評估的項目系統(tǒng)為鐵路售票系統(tǒng)。這是一個基于B/S的體系的常見應(yīng)用，基于網(wǎng)絡(luò)連接實(shí)現(xiàn)鐵路票務(wù)的相關(guān)業(yè)務(wù)。對其進(jìn)行架構(gòu)評估主要有如下幾個原因：1. 在架構(gòu)搭建的過程中一定會碰見許多一致或者未知的問題和困難，如果在核心功能模塊或者架構(gòu)本身的設(shè)計根本上出

6、現(xiàn)缺陷，盡早的發(fā)現(xiàn)對于晚發(fā)現(xiàn)，甚至完成項目后才發(fā)現(xiàn)的綜合成本要低得多；2. 由于該架構(gòu)面向多個用戶多平臺，因此要有足夠的健壯性，穩(wěn)定性，可拓展性以及可修改性；3.由于該系統(tǒng)借助了網(wǎng)絡(luò)的傳播性，可以隨時隨地的對系統(tǒng)進(jìn)行管理和維護(hù)，但是網(wǎng)絡(luò)的泛濫使得網(wǎng)絡(luò)環(huán)境總是充斥著有意無意的攻擊，為了避免系統(tǒng)所部屬的服務(wù)器淪為肉雞的下場，或者內(nèi)部數(shù)據(jù)被惡意破壞造成重大損失，所以系統(tǒng)應(yīng)保證相對的安全性，使得入侵者所花費(fèi)的入侵成本入侵系統(tǒng)的獲利成本或客戶損失。第1階段：評估階段項目產(chǎn)品立項表述：隨著現(xiàn)代交通的發(fā)展，在基于經(jīng)濟(jì)以及便利的考慮基礎(chǔ)上，鐵路出行成為廣大人民首選的性價比最高的交通方式。但隨著經(jīng)濟(jì)的發(fā)展，人工

7、售票逐漸不能滿足龐大人口數(shù)量的基本購票需求。隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡(luò)購票的普及解決了這個主要矛盾。根據(jù)上述目標(biāo)，質(zhì)量屬性可以劃分為兩類：1高優(yōu)先級質(zhì)量屬性：1) 性能2) 安全性3) 易用性4) 兼容性2重要但優(yōu)先級較低的屬性：1) 可擴(kuò)展性2) 可維護(hù)性3) 可靠性4) 可擴(kuò)充架構(gòu)方法分類：進(jìn)行了架構(gòu)表述后，評估小組列出他們曾聽到的架構(gòu)方法，以及那些在對文檔進(jìn)行評估前的評審中所了解到的方法：一、 分層架構(gòu)這種架構(gòu)將軟件分成若干個水平曾，每一層都有清晰的角色和分工，不需要知道其他層的細(xì)節(jié)，層與層之間通過接口通信。二、 事件驅(qū)動架構(gòu)事件是狀態(tài)發(fā)生變化時，軟件發(fā)出的通知。事件驅(qū)動架構(gòu)就是通過事件進(jìn)行

8、通信的軟件架構(gòu)。分為：事件隊列、分發(fā)器、事件通道、事件處理器。三、 微核架構(gòu)又稱為“插件架構(gòu)”，指的是軟件的內(nèi)核相對較小，只要功能和業(yè)務(wù)邏輯都通過插件實(shí)現(xiàn)。內(nèi)核通常只包含系統(tǒng)運(yùn)行的最小功能。插件則是相互獨(dú)立的，插件之間的通信，應(yīng)該減少到最低，避免出現(xiàn)相互依賴的問題。四、 微服務(wù)架構(gòu)是服務(wù)導(dǎo)向的架構(gòu)的升級。每一個服務(wù)都是一個獨(dú)立的部署單元。這些單元都是分布式的，互相解耦，通過遠(yuǎn)程通信協(xié)議聯(lián)系。五、 云架構(gòu)云架構(gòu)主要解決擴(kuò)展性和并發(fā)問題，是最容易擴(kuò)展的架構(gòu)。它的高擴(kuò)展，主要原因是沒使用中央數(shù)據(jù)庫，而是把數(shù)據(jù)都復(fù)制到內(nèi)存中，變成可復(fù)制的內(nèi)存數(shù)據(jù)單元。然后，業(yè)務(wù)處理能力封裝成一個個單元。比如訪問量增加

9、，就新建單元處理；訪問量減少，就關(guān)閉但處理單元。由于沒有中央數(shù)據(jù)庫，所以擴(kuò)展性的最大瓶頸消失了。由于每個處理單元的數(shù)據(jù)都在內(nèi)存里，最好要進(jìn)行數(shù)據(jù)持久化。這個模式主要分成兩部分：處理單元和虛擬中間件。架構(gòu)表述：軟件架構(gòu)是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計。軟件架構(gòu)是一個系統(tǒng)的草圖。軟件體系結(jié)構(gòu)是構(gòu)建計算機(jī)軟件實(shí)踐的基礎(chǔ)?？紤]到票務(wù)系統(tǒng)的特點(diǎn)，將使用三層結(jié)構(gòu)進(jìn)行系統(tǒng)的架構(gòu)。初步架構(gòu)類圖：質(zhì)量屬性及采用的戰(zhàn)術(shù)：目標(biāo)實(shí)現(xiàn)方式所采用戰(zhàn)術(shù)性能用戶訪問系統(tǒng)能在規(guī)定時間內(nèi)做出響應(yīng)，如不能應(yīng)反饋相應(yīng)的提示。緩沖技術(shù)云服務(wù)器分流隊列等待安全性用戶信息不被泄露、支付安全信息加密易用性操作難度讓

10、系統(tǒng)能適應(yīng)大部分群眾界面簡潔兼容性能在多平臺運(yùn)行易移植編碼可維護(hù)性系統(tǒng)能在出現(xiàn)問題時得到及時修復(fù)，管理員能進(jìn)行信息更新分層架構(gòu)設(shè)計可擴(kuò)展性在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇預(yù)留接口可擴(kuò)充性在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇預(yù)留接口可靠性在程序的使用過程中出錯概率要盡量小，出錯了要能夠及時修復(fù)規(guī)范編碼生成質(zhì)量屬性效用樹：下表給出了在對鐵路售票系統(tǒng)評估期間生成的質(zhì)量屬性效用樹，有幾個質(zhì)量屬性求精沒有與之相關(guān)的場景。這種情況經(jīng)常出現(xiàn)，這并不是問題，對于某個質(zhì)量屬性，人們有時能夠想出一個合理的求精，但當(dāng)讓他們在自己的系統(tǒng)的上下文中對該質(zhì)量屬性的用例進(jìn)

11、行說明時，卻發(fā)現(xiàn)該求精實(shí)際上并不適用。表 2：對鐵路售票系統(tǒng)進(jìn)行ATAM評估的效用樹表格質(zhì)量屬性屬性求精場景性能最大負(fù)載響應(yīng)時間吞吐量當(dāng)開票時，用戶量劇增，能夠同時負(fù)載至少500的用戶同時訪問（H,H）用戶輸入數(shù)據(jù)后在網(wǎng)絡(luò)暢通的情況下應(yīng)能在s內(nèi)給出相關(guān)信息（H,M）日最高訂票量500萬張（按目前網(wǎng)絡(luò)訂票系統(tǒng)工作18小時算，每秒處理訂單量為78張）（H,H）安全性數(shù)據(jù)存儲注冊驗證登錄驗證密碼強(qiáng)度當(dāng)用戶注冊時，系統(tǒng)將用戶的信息加密后存入數(shù)據(jù)庫；當(dāng)用戶登錄時，系統(tǒng)將數(shù)據(jù)加密后再與數(shù)據(jù)庫的內(nèi)容進(jìn)行比較，防止傳輸過程被竊取泄露。（H,L）當(dāng)用戶注冊時,為確認(rèn)為真人操作，存在手機(jī)信息驗證碼驗證，并且60s

12、內(nèi)不允許重復(fù)獲取驗證碼。（H,L）當(dāng)用戶登錄時，連續(xù)輸入兩次錯誤密碼后，再次登錄需要根據(jù)系統(tǒng)給出圖片驗證碼輸入正確的驗證碼才能完成登錄，圖片驗證內(nèi)容隨機(jī)生成，并且隨機(jī)生成條紋遮擋字符，防止機(jī)器驗證。（H,L）當(dāng)用戶注冊時系統(tǒng)根據(jù)用戶的密碼顯示相應(yīng)的密碼強(qiáng)度以提示用戶增強(qiáng)密碼強(qiáng)度。密碼強(qiáng)度根據(jù)密碼內(nèi)容字符類型以及長度確定。為了確?；镜陌踩砸约胺乐褂脩暨z忘密碼，用戶密碼長度范圍限制為6-16位。（H,L）易用性用戶通過輸入簡單的查詢信息就能夠得到對應(yīng)的相關(guān)數(shù)據(jù)并讓用戶輕易完成購買（H,M）兼容性多系統(tǒng)支持在相同平臺的不同系統(tǒng)上也能夠正常運(yùn)行（H,H）可維護(hù)性管理員功能維護(hù)管理系統(tǒng)自動報錯管理員

13、能夠在鐵路信息、用戶信息需要更新時進(jìn)行及時更新，并同步數(shù)據(jù)給用戶（H,M）當(dāng)出現(xiàn)了不可避免的錯誤時，可以及時進(jìn)行維護(hù)修復(fù)（H,M）可以定位出系統(tǒng)報錯內(nèi)容、報錯位置（M,L）可擴(kuò)展性添加新功能在出現(xiàn)新需求時能夠添加新功能，如支付渠道的增加支付渠道的選擇（M,L）可擴(kuò)充性功能業(yè)務(wù)的子模塊隨著發(fā)展和意見的收集，能夠根據(jù)情況添加新的業(yè)務(wù)功能，如外賣預(yù)定（M,M）可靠性不易出錯在程序的使用過程中出錯概率要盡量小，出錯了要能夠及時修復(fù)（H,H）表中的場景給出了決策者所分配的優(yōu)先級。在每一對有序的字母中，第一個代表能力的重要性，第二個代表設(shè)計師對實(shí)現(xiàn)該質(zhì)量屬性的難度的估計。我們需要注意到，一些場景已經(jīng)很完備

14、了，具備了刺激、環(huán)境和響應(yīng)三個部分；一些場景沒有刺激，還有一些場景沒有響應(yīng)。在這個階段，只要涉眾能夠理解場景的含義，不明確的場景說明是允許的。如果所選擇的場景用于進(jìn)行分析，那么該場景中的刺激和響應(yīng)必須得到足夠的明確。初步分析架構(gòu)方法：評估小組首先分析最重要而且最難實(shí)現(xiàn)的場景，每次分析一個最高優(yōu)先級的場景，同時我們的設(shè)計師詳細(xì)地解釋了構(gòu)架如何支持每個場景。小組成員探查設(shè)計師用來實(shí)現(xiàn)場景的架構(gòu)方法，把相關(guān)架構(gòu)決策編成文檔，一共確定了個8敏感點(diǎn)，4個風(fēng)險點(diǎn)，3個無風(fēng)險決策。性能場景系統(tǒng)訪問量達(dá)到高峰屬性性能環(huán)境系統(tǒng)處于高峰訪問時期刺激用戶請求訪問響應(yīng)良好響應(yīng)請求架構(gòu)決策敏感點(diǎn)權(quán)衡點(diǎn)有風(fēng)險決策無風(fēng)險決

15、策超出限制訪問量的請求放在等待S1R1緩存S2R2N1云服務(wù)器分流S3數(shù)據(jù)庫連接池S4N2推理1、 由于在系統(tǒng)部署的時候用的是單應(yīng)用服務(wù)器，而一臺應(yīng)用服務(wù)器可同時支持的并發(fā)用戶數(shù)量是很少的，在幾千甚至上萬的用戶訪問系統(tǒng)時，由于限制最大訪問量，不能保證每個用戶都能隨時登錄，降低用戶的滿意度。2、 單服務(wù)器提供的緩存數(shù)有限3、 避免了非法用戶的惡意攻擊，但有可能降低系統(tǒng)的可用性4、 減輕數(shù)據(jù)庫的負(fù)擔(dān)，提高系統(tǒng)的性能可用性場景系統(tǒng)備份與恢復(fù)屬性可用性環(huán)境系統(tǒng)發(fā)生錯誤刺激用戶進(jìn)行恢復(fù)響應(yīng)盡快恢復(fù)并未用戶提供有意義的反饋信息架構(gòu)決策敏感點(diǎn)權(quán)衡點(diǎn)有風(fēng)險決策無風(fēng)險決策系統(tǒng)備份S5R3故障恢復(fù)S6R4數(shù)據(jù)庫備

16、份S7推理1、 系統(tǒng)備份是進(jìn)行故障恢復(fù)的前提，但頻繁的備份會影響正常的業(yè)務(wù)處理，存在一定的風(fēng)險2、 如果因為系統(tǒng)掉電或其他操作，利用備份數(shù)據(jù)可以很快恢復(fù)。但由于使用的是但服務(wù)器機(jī)制，一旦這臺服務(wù)器出現(xiàn)故障或者崩潰，硬件發(fā)生故障，系統(tǒng)的回復(fù)時間會很長，存在風(fēng)險。安全性場景用戶信息傳輸屬性安全性環(huán)境信息泄露響應(yīng)信息加密架構(gòu)決策敏感點(diǎn)權(quán)衡點(diǎn)有風(fēng)險決策無風(fēng)險決策信息加密S8N3推理1、 信息可能在傳輸過程中被截獲2、 信息加密傳輸，并且以加密格式在數(shù)據(jù)庫中校對可以防止惡意獲取信息3、 信息加密不影響性能，還能提高信息的安全傳輸和數(shù)據(jù)庫安全戰(zhàn)術(shù)采用采用戰(zhàn)術(shù)敏感點(diǎn)（S）有風(fēng)險決策（R）訪問量激增使用LRU

17、緩沖提高了系統(tǒng)的工作效率單服務(wù)器提供的緩存數(shù)目有限，并發(fā)用戶多的情況下，系統(tǒng)處理緩慢超出限制訪問量的請求放在等待隊列中提高了系統(tǒng)的穩(wěn)定性和可用性，減少了崩潰的可能會降低最大并發(fā)數(shù)目，使得用戶等待時間過場，可能造成用戶不滿云服務(wù)器分流分流訪問量，提高效率鎖機(jī)制解決多管理用戶同時訪問修改同一數(shù)據(jù)可能產(chǎn)生管理用戶長期占用資源，降低資源使用率備份數(shù)據(jù)庫防止數(shù)據(jù)庫物理性破壞數(shù)據(jù)庫連接池數(shù)據(jù)庫連接池允許應(yīng)用程序重復(fù)使用一個現(xiàn)有的數(shù)據(jù)庫連接，而不再是重新建立一個，提高應(yīng)用系統(tǒng)的性能系統(tǒng)備份與恢復(fù)增強(qiáng)系統(tǒng)的容錯能力操作系統(tǒng)和數(shù)據(jù)庫軟件發(fā)生崩潰時，回復(fù)時間較長MD5加密防止用戶信息泄露第2階段：評估階段集體討論

18、并確定場景的優(yōu)先級：下表給出了在本步驟中提出的某些部分感興趣場景進(jìn)行重點(diǎn)分析。按重點(diǎn)次序羅列，由于篇幅有限，有些細(xì)微場景沒有列出，只列出了認(rèn)為重要場景。表1：集體討論確定的場景場景號場景1為了防止軟件搶票，應(yīng)在對一個相同的用戶的多次請求進(jìn)行分析。如：驗證碼兩次輸入錯誤之間的之間間隔。當(dāng)判定不是軟件搶票時，應(yīng)當(dāng)隨著驗證錯誤次數(shù)的增加降低驗證難度2用戶賬戶與付款的綁定、多種支付方式、以及安全性的要求。在保證安全性的前提下應(yīng)該能夠讓用戶通過最簡潔的流程選擇自己合適的支付流程。3信息密傳輸4突然激增的流量導(dǎo)致服務(wù)器處理緩慢，甚至崩潰異常，要求對有害信息進(jìn)行過濾，使用LRU緩沖計數(shù)減少服務(wù)器負(fù)擔(dān)，增加服

19、務(wù)器工作效率。5用戶訪問的相關(guān)車次查詢、買票、下訂單、付款、改簽、退款的流程應(yīng)直觀、簡潔。6支持新車次添加、舊車次刪除、用戶信息修改操作等。7如果存在多個管理員時怎么并發(fā)管理系統(tǒng)，如果多個管理員對同一數(shù)據(jù)進(jìn)行修改時應(yīng)如何保護(hù)數(shù)據(jù)不被多次修改。這里考慮到參考鎖機(jī)制。再次分析架構(gòu)方法：三層結(jié)構(gòu)選擇由于票務(wù)數(shù)據(jù)以及用戶數(shù)據(jù)量龐大，而三層結(jié)構(gòu)的特點(diǎn)將數(shù)據(jù)層、邏輯層以及表現(xiàn)層分隔開，在開發(fā)上降低了復(fù)雜度。并且考慮到系統(tǒng)的開發(fā)效率，三層結(jié)構(gòu)使項目結(jié)構(gòu)更清楚，分工更明確?？紤]到用戶數(shù)量多，并且票務(wù)信息隨時都有可能發(fā)生變化，使用三層結(jié)構(gòu)有利于后期的維護(hù)、更新和升級。并且數(shù)據(jù)的差異性大，將三層架構(gòu)中的控制層進(jìn)行

20、了細(xì)分，實(shí)現(xiàn)低耦合、并行開發(fā)。為解決訪問流量大的問題，服務(wù)器考慮使用LRU緩沖計數(shù)以提高服務(wù)器工作效率和改善用戶體驗。并且出于對大量用戶信息安全的角度考慮，數(shù)據(jù)的傳輸和校驗采用MD5加密方式。在集中的討論中，我們重點(diǎn)討論了上述問題的解決方案，考慮到時間和空間的限制，我們就第一二個詳細(xì)展開說明，以及分析和權(quán)衡。LRU緩沖技術(shù)分析比如說一些系統(tǒng)登錄的操作，不可能每次你訪問系統(tǒng)都去調(diào)用數(shù)據(jù)庫的東西，如果能劃出一些空間來，比如說500M，用來緩存這些東西，這樣用戶訪問的時候先在緩存里找，找不到，再去訪問數(shù)據(jù)庫，同時把被訪問的內(nèi)容放到緩存里面（我們可以假設(shè)這些東西還會經(jīng)常被訪問）。然而，我們分配用來做緩

21、存（Cache）的空間肯定是有限的，總不可能從數(shù)據(jù)庫讀的東西全部放到緩存里，所以，當(dāng)緩存里的內(nèi)容達(dá)到上限值的時候，我們就要把最少使用的東西寫回數(shù)據(jù)庫，再將新的訪問內(nèi)容從數(shù)據(jù)庫暫存到緩存里面。以此保證服務(wù)端的效率和使用度。MD5加密存儲分析MD5將任意長度的“字節(jié)串”變換成一個128bit的大整數(shù)，并且它是一個不可逆的字符串變換算法，換句話說就是，即使你看到源程序和算法描述，也無法將一個MD5的值變換回原始的字符串，從數(shù)學(xué)原理上說，是因為原始的字符串有無窮多個，這有點(diǎn)象不存在反函數(shù)的數(shù)學(xué)函數(shù)。將客戶端的內(nèi)容數(shù)據(jù)進(jìn)行加密后傳輸?shù)綌?shù)據(jù)庫進(jìn)行校驗，這樣可以防止在傳輸過程中數(shù)據(jù)被盜取的安全性問題。備份數(shù)

22、據(jù)庫 由于存儲的數(shù)據(jù)信息內(nèi)容數(shù)量龐大，一旦服務(wù)器出現(xiàn)問題，數(shù)據(jù)丟失將會導(dǎo)致巨大的損失。所以在之前的部署上添加了備份數(shù)據(jù)庫，防止數(shù)據(jù)丟失。改進(jìn)架構(gòu)類圖結(jié)果表述(1) 由于開發(fā)人員對架構(gòu)缺乏一定的熟練度，我們決定邊學(xué)邊做，碰見一些解決不了的問題采用在文檔中總結(jié)報告，記錄下來，優(yōu)先完成功能模塊的實(shí)現(xiàn)環(huán)節(jié)；(2) 平臺開發(fā)入門檻較低，產(chǎn)品容易被模仿，需要及時更新設(shè)計以擺脫競爭對手，所以應(yīng)該預(yù)留系統(tǒng)API接口，為不管是以后管理方設(shè)計更改界面還是可以由用戶自定義開發(fā)界面都能起到良好的促進(jìn)作用。第3階段：后續(xù)階段ATAM評估的一個具體結(jié)果就是生成了最終報告，該報告包括一個有風(fēng)險決策、誤風(fēng)險決策、敏感點(diǎn)和權(quán)衡

23、點(diǎn)的列表。還包括一個涉及如下內(nèi)容的目錄：所使用的架構(gòu)方法、效用樹、經(jīng)過集體討論確定的場景以及所選擇的每個場景的分析記錄。最后，最終報告還包括由該評估小組所確定的風(fēng)險主題的集合，并指出了每個風(fēng)險主題所危及的商業(yè)動機(jī)。附錄擬采用架構(gòu)評審方法中的ATAM方法對ATAM模型方法的簡略描述：軟件構(gòu)架的評估方法：SAAM和ATAM。這里只詳細(xì)說明ATAM方法。ATAM一種進(jìn)行構(gòu)架評估的綜合方法，ATAM是評估軟件構(gòu)架的一個健壯的方法。在該方法中，項目決策者和涉眾要清晰地闡述一個準(zhǔn)確的質(zhì)量屬性需求列表（以場景的方式），并說明與實(shí)現(xiàn)每個高優(yōu)先場景相關(guān)的構(gòu)架決策。然后，把這些決策確定為有風(fēng)險決策或無風(fēng)險決策，以

24、找到構(gòu)架中任何存在問題的地方。ATAM不是需求評估。ATAM不是代碼評估。ATAM不包括實(shí)際的系統(tǒng)測試。ATAM不是一個準(zhǔn)確的手段，但它識別了構(gòu)架中可能存在風(fēng)險的區(qū)域。這些風(fēng)險包含在敏感點(diǎn)和權(quán)衡中。ATAM活動的4個階段：在第0階段（合作關(guān)系和準(zhǔn)備）確定細(xì)節(jié)：人員名單，時間，地點(diǎn)；評估小組獲取資料并進(jìn)行初步了解分析。第1階段，評估階段，決策者參與，小組開始信息收集與分析；耗時約1周。12周中斷期，評估小組進(jìn)一步以非正式方式了解構(gòu)架。第2階段，評估階段，涉眾參與，分析繼續(xù)；約2天。第3階段，后續(xù)階段，生成最終報告，進(jìn)行評估活動總結(jié)；1周。評估階段的步驟：第1步：ATAM方法的表述。評估負(fù)責(zé)人向決策者表述ATAM方法，使大家理解其過程，了解角色布局。第2步：商業(yè)動機(jī)的表述。決策者介紹系統(tǒng)商業(yè)動機(jī)、重要功能、各種限制（任何相關(guān)的技術(shù)、管理、經(jīng)濟(jì)和政治限制）、商業(yè)目標(biāo)和上下文、主要的涉眾、驅(qū)動因素等。第3步：構(gòu)架的表述。首席設(shè)計師或架構(gòu)小組介紹構(gòu)架，技術(shù)限制、所用模式等。第4步：對構(gòu)架方法進(jìn)行分類。評估小組利用所有已知信息對構(gòu)架方法進(jìn)行分類。第5步：生成質(zhì)量屬性效用樹。生成質(zhì)量屬性效用樹，捕獲詳細(xì)的需求信息，為每個場景分配一個級別，如（高，中），前者為重要度，后者為實(shí)現(xiàn)難易度，重點(diǎn)放在（高，高）的場