0 概述
這篇文章主要是針對一個對於知乎的數據進行爬取的爬蟲程序，將進行軟件系統的分析和設計，闡述使用的設計模式、軟件架構風格與策略，並采用視圖來描述軟件系統的模型。進行數據庫和核心數據結構的設計分析，最終形成軟件系統概念原型。
項目簡介：這是一個關於爬取知乎網數據的小程序，可以根據具體需求爬取當天的熱榜數據，每一個熱榜數據包括名稱、時間、熱度，每一個具體的回答包括用戶名、回答、時間、點贊數、評論等相關信息。主要目的是獲取數據。在獲取數據的過程中，經歷了數據清洗等過程。
1 項目的設計方案
首先先確定項目的架構風格和設計模式。
對於架構風格來說：典型的有管道-過濾器分割、批處理風格、黑板風格、資料庫風格、層架構風格、發布訂閱風格，以及現在流行的以網絡為中心的樣式風格等。
對於設計模式來說：典型的有工廠方法模式，單例模式，責任鏈模式，代理模式，外觀模式等等。
1.1 架構風格
我們需要確定軟件使用的架構風格，首先分析項目的需求，很簡單，獲取數據->數據清洗->存儲信息，每一步都是緊接着上一步進行。考慮到成熟的軟件架構風格：數據流風格：數據流樣式的特征是將系統視為對連續輸入數據的一系列轉換，因此，我們可以選擇管道-過濾器風格。
考慮到管道過濾器風格的優點：
- 易於添加和刪除組件（有助於擴展）
- 允許並發/並行執行（有助於性能）
這正是符合我們設計的軟件需要的風格
爬取到的數據必須先經過數據清洗驗證才能存儲起來，不能將數據直接跳過驗證步驟，只有當前一步處理完，后一步處理才能開始。數據傳輸在步與步之間作為一個整體。
1.2 設計模式
設計模式是軟件設計中常見問題的典型解決方案。 每個模式就像一張藍圖， 你可以通過對其進行定制來解決代碼中的特定設計問題。
我們的程序主要是注重於行為，我們查看設計模式里的行為模式，我們可以發現，責任鏈模式與我們的軟件具有深度的共同點，進一步的
責任鏈模式是一種行為設計模式， 允許你將請求沿着處理者鏈進行發送。 收到請求后， 每個處理者均可對請求進行處理， 或將其傳遞給鏈上的下個處理者。責任鏈會將特定行為轉換為被稱作處理者的獨立對象。 在上述示例中， 每個檢查步驟都可被抽取為僅有單個方法的類， 並執行檢查操作。 請求及其數據則會被作為參數傳遞給該方法。
我們給出大致的UML類圖
偽代碼如下：
// 基類接口
interface Handler
method setNext() //設置下一個調用的類
method handler() //具體的處理函數
class MyHandler implements Handler
field next //下一個處理的類
method setNext() //設置下一個調用的類
method handler() //具體的處理函數
class getData extends MyHandler
... //上面的next、setNext、field
method handler() //具體的爬取數據處理函數
class dataAuth extends MyHandler
... //上面的next、setNext、field
method handler() //具體的驗證清洗數據處理函數
class dataStore extends MyHandler
... //上面的next、setNext、field
method handler() //具體的存儲處理函數
main(){
g=new getData()
d=new dataAuth()
s=new dataStore()
g.setNext(d)
d.setNext(s)
g.handler()
}
此外，還可以采用外觀模式，為上述復雜的代碼提供一個簡單的接口，這里不再贅述
2 數據庫設計與核心數據結構
數據庫的設計采取文檔數據庫MongoDB，能夠存儲多樣化的數據信息
| 序號 | 說明 | 名稱 | 類型 | 長度 | 主鍵 |
|---|---|---|---|---|---|
| 1 | 編號 | _id | Int | 32 | Y |
| 2 | 作者名 | author_name | string | 不限 | N |
| 3 | 評論數 | comment_count | Int | 32 | N |
| 4 | 點贊數目 | veteup_count | Int | 32 | N |
| 5 | 內容 | content | string | 不限 | N |
| 6 | 摘要 | excerpt | string | 不限 | N |
| 7 | 問題id | question_id | string | 不限 | N |
| 8 | 創建時間 | Create_time | data | 不限 | N |
2.1 接口API
3 項目的目錄文件結構
項目文件的目錄結構如下：
4 項目視圖
4.1 分解視圖
分解是構建軟件架構模型的關鍵步驟，分解視圖也是描述軟件架構模型的關鍵視圖，一般分解視圖呈現為較為明晰的分解結構（breakdown structure）特點。分解視圖用軟件模塊勾划出系統結構，往往會通過不同抽象層級的軟件模塊形成層次化的結構。組件主要有類、軟件模塊、軟件單元、子系統等。
分解視圖如下：
4.2 依賴視圖
依賴視圖展現了軟件模塊之間的依賴關系。比如一個軟件模塊A調用了另一個軟件模塊B，那么我們說軟件模塊A直接依賴軟件模塊B。如果一個軟件模塊依賴另一個軟件模塊產生的數據，那么這兩個軟件模塊也具有一定的依賴關系。
4.3 泛化視圖
泛化視圖展現了軟件模塊之間的一般化或具體化的關系，典型的例子就是面向對象分析和設計方法中類之間的繼承關系。值得注意的是，采用對象組合替代繼承關系，並不會改變類之間的泛化特征。因此泛化是指軟件模塊之間的一般化或具體化的關系，不能局限於繼承概念的應用。
在用戶可以使用的UI類里，用戶可以進行爬取數據和查看數據,相應的子類再去調用具體的功能
4.4 執行視圖
執行視圖展示了系統運行時的時序結構特點，比如流程圖、時序圖等。執行視圖中的每一個執行實體，一般稱為組件（Component），都是不同於其他組件的執行實體。如果有相同或相似的執行實體那么就把它們合並成一個。
4.6 工作分配視圖
工作分配視圖將系統分解成可獨立完成的工作任務，以便分配給各項目團隊和成員。工作分配視圖有利於跟蹤不同項目團隊和成員的工作任務的進度，也有利於在個項目團隊和成員之間合理地分配和調整項目資源，甚至在項目計划階段工作分配視圖對於進度規划、項目評估和經費預算都能起到有益的作用。
此外還有一些其他視圖
4.7 開發視圖
開發視圖：着重於軟件開發環境中實際軟件模塊的組織。也稱模塊視圖，主要側重於軟件模塊的組織和管理。主要是在編程人員視角的視圖
對於開發人員來說，多加了一步在展示數據的時候從數據庫獲取數據
4.8進程視圖
側重於系統的運行特性，主要關注一些非功能性的需求，如性能和系統的可用性。強調並發性、分布性、系統集成性和容錯能力。
對於每一個獲取數據和數據驗證清洗的時候可以並行執行
4.9 部署視圖
主要考慮系統的非功能性需求，如系統可用性、可靠性（容錯）、性能（吞吐量）以及規模。
主要側重於硬件方面
4.10 用例圖
在開發體系結構時，用例圖可以幫助設計者找到體系結構的構件和它們之間的作用關系。可以用用例圖來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。
5 運行環境和技術選型
結合項目的分析，決定使用python語言作為項目的主要語言。基於Scrapy庫實現爬蟲的爬取，旨在快速、便捷的實現一個有一定並發量的爬取數據部分。在數據驗證清洗部分和數據存儲部分，則根據自己的實際尋求手動實現相關類的操作。另外，項目還開發了一個前端界面，結合HTML、CSS、JavaScript技術以及flask庫實現前端的開發。數據庫方面則使用MongoDB來存儲獲得到的數據。實現前后端的分離操作。
6 系統概念原型的核心工作機制
每個視圖都是從不同的角度對軟件架構進行描述和建模，比如從功能的角度、從代碼結構的角度、從運行時結構的角度、從目錄文件的角度，或者從項目團隊組織結構的角度。
軟件架構代表了軟件系統的整體設計結構，它應該是所有這些視圖的集合。但我們不會將不同角度的這些視圖整合起來，因為不便於閱讀和更新。不過我們會有意識地將不同角度的視圖之間的映射關系和重疊部分了然於胸，從而深刻理解軟件架構內在的一致性和完整性，這就是系統概念原型。
整個概念模型的工作過程為：
用戶這個用程序下達執行命令，系統開始根據知乎網的數據進行信息的爬取，在爬取過程中多開線程並行執行，在數據爬取到本地以后，將數據進行驗證清洗，剔除不合理和沒有高價值的數據。最后一步將驗證清洗后的數據存儲到數據庫中。
當用戶要查看數據的時候，打開一個網絡界面，從數據庫取數據，然后展示給用戶。
7 總結
這篇文章主要講述了一個 知乎爬蟲程序的設計方案，給出了架構選擇，設計模式的選擇，數據庫設計和核心數據結構的分析，給出了項目的視圖，因為才疏學淺，可能有不足之處。