建站
咨詢
售后
建站咨詢
新聞中心
自從5月8號寫完架構設計三部曲的***部如何寫架構設計說明書，到現(xiàn)在快20多天了，這段時間主要準備了下系統(tǒng)分析師的考試，當然還有各種工作上的雜事，于是也就拖到現(xiàn)在寫第二部如何評審架構設計說明書。當然這個是從評審的角度來看的，其實從編制架構設計說明書的角度來看，也可以闡述具體如何編寫架構設計說明書，就像高考作文一樣，評審總是有些采分點的嘛，那么對于編制架構設計說明書來說，哪些是我們應該準備的采分點呢？我們在編制的過程中需要重點注意哪些章節(jié)的哪些內(nèi)容呢？這就是我接下來想和大家分享的。
創(chuàng)新互聯(lián)建站是專業(yè)的紫金網(wǎng)站建設公司，紫金接單;提供網(wǎng)站設計、成都網(wǎng)站制作,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行紫金網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
根據(jù)***部文章我們知道一篇架構設計說明書大致章節(jié)應該是這樣的：
- 文檔概述：包含項目背景、項目目標、文檔版本信息、目標讀者、參考文檔、名詞解釋之類的一般文檔都會有的章節(jié)；
- 整體架構：主要從整個IT層描述系統(tǒng)所處的位置，與周邊關聯(lián)系統(tǒng)之間的調(diào)用關系；
- 邏輯架構：系統(tǒng)內(nèi)部功能模塊的劃分以及各模塊功能介紹、相互之間的關系表述；
- 接口設計：包括系統(tǒng)間的接口設計以及內(nèi)部功能模塊之間的接口設計；
- 數(shù)據(jù)架構：本系統(tǒng)與上下游系統(tǒng)間的數(shù)據(jù)流關系，以及本系統(tǒng)關鍵數(shù)據(jù)表設計、數(shù)據(jù)管理策略等；
- 技術架構：實施此架構需要用到哪些技術能力，有哪些復用能力及風險；
- 部署架構：系統(tǒng)如何部署，網(wǎng)絡拓撲上有何要求，對硬件服務器有何要求，需要幾臺，是否需要優(yōu)化服務器參數(shù)；
- 非功能性設計：性能、高可用、可擴展性、可維護、安全性、可移植性等。
- 其他說明：如特別約束條件、風險考慮、進度要求、政策限制、環(huán)境影響等；
那么我們依次來看，每個章節(jié)在評審過程中需要關注哪些問題，編寫架構設計說明書的人員有針對性的需要提供哪些內(nèi)容：
（一）文檔概述
對本架構設計說明書本身進行解釋，需要說明清楚本文檔背景，即為什么有這個文檔，文檔的內(nèi)容范圍，預期的讀者，包括了哪些需要同步參考的文檔，有哪些需要說明術語等，可以分二級標題來寫，內(nèi)容形式如：本文檔是對XX系統(tǒng)第XX期項目架構設計/升級/變更進行闡述，主要從整體架構、邏輯架構、接口設計。。。等等各方面詳細說明了本系統(tǒng)各架構維度的內(nèi)容，期望讀者為項目管理人員、架構管理人員、運維人員等，在編制過程中參考了XX需求書、XX架構設計規(guī)范等；評審一般會關注：
文檔目的及內(nèi)容范圍是否是從架構角度來說明的；
參考文檔否則提到了《用戶需求規(guī)格說明書》、業(yè)務知識文檔等；
說明術語是否對非通用和非IT縮寫進行了解釋；
整章是否交代清楚了文檔整體上的介紹，使讀者對全篇有了大致的了解。
（二）整體架構
描寫系統(tǒng)在架構設計時總體的思路及方針，比如采取了分層架構、B/S架構、服務化、數(shù)據(jù)分離等，同時在設計過程中的一些約束條件，如網(wǎng)絡訪問約束、開發(fā)規(guī)范約束、開源產(chǎn)品協(xié)議類型等，更重要的是，作為整體架構，一定要將本系統(tǒng)作為一個內(nèi)部不透明的整體，闡述清楚與之有交互的外部系統(tǒng)都有哪些，與具體外部系統(tǒng)的交互實現(xiàn)的需求是什么？如通過消息總線獲取客戶信息，通過企業(yè)內(nèi)容管理存取非結構化數(shù)據(jù)，通過CRM獲取客戶信息等，并以本系統(tǒng)為中心描繪整個交互關系圖，也就是整體架構圖。評審一般會關注：
設計方案表述是否清晰并與實際設計內(nèi)容一致；
相應的約束是否真實具體，有可檢查性；
從整體架構圖是否能看清這個系統(tǒng)需要和哪些系統(tǒng)交互，交互的目的是什么；
對于系統(tǒng)間的交互是否正確，外部系統(tǒng)是否能滿足交互，如通過CRM獲取客戶信息可以，獲取機構信息可行嗎。
（三）邏輯架構
邏輯架構關心的是如何將系統(tǒng)分為不同部分以及各部分之間如何交互，其規(guī)定了軟件系統(tǒng)由哪些邏輯元素組成以及這些邏輯元素之間的關系（層、子系統(tǒng)、模塊等的劃分決定+交互接口和交互機制[方法調(diào)用、RMI、消息]），因此邏輯架構圖需要說清楚本系統(tǒng)包含了哪幾項功能模塊，模塊之間如何交互，交互的目的是實現(xiàn)哪些業(yè)務需要。同時，對于具體的功能模塊，需要詳細說明清楚功能模塊的業(yè)務意義。評審一般會關注：
邏輯架構圖是否列出了功能模塊，及其模塊間的交互關系；
是否對圖中列出的模塊進行了詳細說明，使得讀者完全了解為什么會有此功能模塊，它包括了哪些業(yè)務需求。
（四）接口設計
架構設計中對接口的設計包括兩方面的內(nèi)容，一方面是指本系統(tǒng)與外部系統(tǒng)之間的外部接口關系，需要全部例舉所有與外部系統(tǒng)的接口，詳細解釋每一個外部接口的名稱（如XX數(shù)據(jù)推送接口）、所交互的系統(tǒng)名稱（如ODS）、交互方式（如Webservice）、交互類別（如后臺異步）、接口描述（如本系統(tǒng)通過此接口從ODS中獲取XX業(yè)務數(shù)據(jù)）；另一方面是指本系統(tǒng)內(nèi)部功能模塊之間的內(nèi)部調(diào)用關系，嚴格意義說來說這部分屬于邏輯架構的一部分，同樣需要根據(jù)各功能模塊的調(diào)用實際全部例舉，依次解釋每個內(nèi)部接口的名稱（如報表服務接口）、主調(diào)模塊（即主動發(fā)起內(nèi)部調(diào)用的功能模塊如展示模塊）、服務模塊（即提供服務的模塊，如報表模塊）、接口描述（如展示模塊通過此接口從報表模塊獲取報表數(shù)據(jù)從而實現(xiàn)模塊間的解耦），一般來說內(nèi)部接口調(diào)用屬于代碼級，如果對于需要獨立部署的模塊而使用遠程調(diào)用方式的，需要做特別說明。接口是系統(tǒng)復雜度的一種體現(xiàn)，是體現(xiàn)高內(nèi)聚、低耦合設計原則一個很重要的方面，評審一般會關注：
外、內(nèi)部接口是否全部例舉，是否按照上述對接口各維度的要素進行了解釋說明；
對于服務方，是否確實能按照接口所描述的提供相應的服務。
（五）數(shù)據(jù)架構
數(shù)據(jù)處理是系統(tǒng)的***目標，系統(tǒng)在處理過程中有可能需要外部數(shù)據(jù)的協(xié)助，同時系統(tǒng)處理完數(shù)據(jù)后也可能需要提供給其他系統(tǒng)使用，因此對于數(shù)據(jù)架構最重要的是講清楚本系統(tǒng)處理的數(shù)據(jù)在整個業(yè)務數(shù)據(jù)流鏈條上的位置，上游有哪些系統(tǒng)為本系統(tǒng)供數(shù)，下游哪些系統(tǒng)需要使用本系統(tǒng)的數(shù)據(jù)。另外，針對系統(tǒng)對數(shù)據(jù)的處理，需要解釋系統(tǒng)設計了哪些關鍵表，數(shù)據(jù)初始化采用何種方式、數(shù)據(jù)冗余如何做，備份如何做等，評審一般會關注：
是否從業(yè)務數(shù)據(jù)流向角度描述清楚了本系統(tǒng)數(shù)據(jù)與上下游系統(tǒng)數(shù)據(jù)之間的關系；
針對本系統(tǒng)承載的業(yè)務處理，設計了哪些關鍵實體數(shù)據(jù)表及其對應，是否能全面覆蓋；
有無本系統(tǒng)產(chǎn)生的數(shù)據(jù)體量估算、數(shù)據(jù)初始化、數(shù)據(jù)歸檔方式、備份策略等。
（六）技術架構
從技術的角度描述本系統(tǒng)在實現(xiàn)過程中用到的關鍵技術能力，核心的技術組件，包括成熟商業(yè)套件以及開源的技術產(chǎn)品。如果是商業(yè)套件需要說明使用限制，升級支持等，如果是開源技術需要說明開源協(xié)議要求等。可以按分層架構的模式，比如展現(xiàn)層用到了JQuery、Flex之類的，邏輯控制層用到了spring、json等，這個一定是從技術上來說的，對于具體用到的組件，一定要說明組件的版本、功能、適用場景呢。當然，可復用性是技術架構的關鍵，無論是使用之前的組件還是開源產(chǎn)品，都是通過可復用性來減少資源重復投入，因此在技術組件中需要強調(diào)對可復用性的重視，評審一般會關注：
是否對關鍵技術進行了說明，且能明確表述此技術的成熟度與適用性；
對某些技術的使用是否與企業(yè)通用的同類技術有沖突，比如企業(yè)內(nèi)其他系統(tǒng)多使用redis，而本系統(tǒng)確使用memcached；
（七）部署架構
講清楚系統(tǒng)分為了幾個物理部分，每部分需要幾臺服務器，服務器之間是共同提供服務的集群模式還是一臺提供服務一臺備用的Master-Slave模式，或者是一臺負責寫多臺多臺負責讀的讀寫分離模式，從網(wǎng)絡層面來看，系統(tǒng)處于整個企業(yè)網(wǎng)絡環(huán)境的哪個位置如外聯(lián)區(qū)或DMZ區(qū)或內(nèi)網(wǎng)區(qū)等。對于需要的服務器，需要說明服務器的軟硬件配置信息，如硬件方面幾核多大內(nèi)存、硬盤大小、網(wǎng)絡端口數(shù)及網(wǎng)絡帶寬要求，軟件方面對操作系統(tǒng)的要求，版本要求，系統(tǒng)及軟件參數(shù)的調(diào)優(yōu)設置等；是否需要預安裝第三方軟件，所需軟件的版本、部署說明等。評審一般會關注：
是否能從部署架構圖看明白系統(tǒng)分幾部分進行物理部署;
各部署部分之間的服務器的協(xié)作關系；
對硬件服務器的型號、配置、數(shù)量等是否明確；
整體部署的網(wǎng)絡區(qū)域是否明確；
是否需要對相關參數(shù)的調(diào)優(yōu)及特殊部署要求進行了說明。
（八）非功能性說明
系統(tǒng)的非功能性包括性能、高可用、可擴展性、可維護、安全性、可移植性，一般來說，對于性能或安全性有較高要求的系統(tǒng)，可以將其獨立成一個一級章節(jié)來寫，比如實時分析類系統(tǒng)要求性能，交易類要求安全，可以將性能和安全作為獨立的章節(jié)來描述，其他非功能性也可以類似處理。在編寫過程中，可以有主次的分別進行闡述，但一定要從系統(tǒng)的實現(xiàn)性來說，即需要描述清楚系統(tǒng)做了何種設計或優(yōu)化以滿足性能，設計了何種校驗機制來保障安全，如何通過集群或熱備部署來保證可用性，如何講過去狀態(tài)化實現(xiàn)可擴展等，這些設計是如何落實在系統(tǒng)里的。即要從系統(tǒng)如何做來滿足非功能性的角度，而不是解釋具體的非功能性要求是什么。評審一般會關注：
對非功能性的描述是從系統(tǒng)如何實現(xiàn)而不是對系統(tǒng)的要求角度來說的；
每類非功能性都能從需求里面找到對應的需求點，且與業(yè)務實際相匹配；
系統(tǒng)對非功能性的實現(xiàn)與系統(tǒng)本身的架構不矛盾，架構可以通過合理的調(diào)整來滿足；
非功能性的評審需要根據(jù)不同系統(tǒng)的業(yè)務特點來評審，總體的編制原則是說實現(xiàn)不說需求，畢竟架構設計是要指導后續(xù)系統(tǒng)建設實施的。
（九）其他說明
此章節(jié)主要對一些輔助的約束或環(huán)境進行說明，如約束條件、風險考慮、進度要求、政策限制、環(huán)境影響等，根據(jù)實際可預見的情況編寫即可。如高層對系統(tǒng)總體的要求、開發(fā)資源的限制、業(yè)務環(huán)境的影響、人員知識結構等。評審過程一般不關注具體事項，除非系統(tǒng)有特別要求。
以上就是整個架構設計說明書的評審內(nèi)容，也是各章節(jié)編制的指導思路，本人根據(jù)在實際工作中的一些體會粗略總結，不一定全面，但是對整個編制會有一些幫助，和大家一起討論學習。
分享標題：架構設計之如何評審架構設計說明書
URL標題：http://www.dlmjj.cn/article/djecpih.html
