[軟工頂級理解組] 技術規格說明書

項目	內容
班級：2020春季計算機學院軟件工程(羅傑 任健)	博客園班級博客
做業：技術規格說明書	功能規格說明書

目錄

• 1、技術棧介紹
  • 前端
  • 後端
  • 數據庫
  • 爬蟲
  • 雲環境
• 2、先後端接口設計
• 3、設計原則

1、技術棧介紹

前端

咱們所製做的產品是一款Android APP，一切開發基於Google的Android SDK進行製做。咱們使用Android Studio進行開發，開發語言爲Java。

Android Studio基於IntelliJ IDEA，是Google爲開發者提供的安卓開發工具，也是現在市面上使用最普遍的安卓開發IDE。在該軟件的框架下開發，咱們能使用強大且方便的佈局編輯器，拖拉UI控件而且進行效果預覽。

雖然咱們的目標用戶是全部北航學生，也考慮到了很多北航同窗使用iOS系統，但因爲人數和時間的限制，咱們暫無iOS前端的開發計劃，力求儘快在安卓平臺交付成品。若是Alpha版本的設計獲得好評，咱們會考慮開發iOS前端。

後端

後端使用Django做爲框架，MySQL做爲數據庫，基於Python語言實現。

Django自己是一款先後端能夠兼顧的框架，也可以作全棧開發，不過咱們只使用其後端的相關功能。Django具備基礎的MVC設計模式，提供了大量的基礎功能，可以知足咱們先後端交互的需求。咱們可能會考慮使用Django REST Framework做爲後端的實現框架，體現RESTful開發。

數據庫

數據庫使用MySQL。MySQL數據庫是咱們最熟悉也是使用人數較多的一款數據庫，較爲穩定，且相關技術較爲成熟，和Django的相性也很好。

Django自帶的SQLite數據庫較爲輕便，能夠做爲本地調試使用，但不適合部署在服務器上供應較多的人使用，性能可能會受限。

爬蟲

目前因爲安全緣由，學校並無向學生直接開放數據庫的讀取接口，咱們也沒法用常規方式獲取教務網站上的數據。可是咱們依然想要製做這樣一款軟件，因此不得已選取了爬蟲來獲取數據

因爲北航教務的session驗證較爲複雜，且教務系統中有iframe之類的較爲複雜的結構，使用通常的爬蟲框架較爲困難，因此咱們選擇簡單易用的無頭瀏覽器Selenium做爲從學校獲取數據的工具。

咱們會控制爬取的頻率和數據，也會保證不會進行越界操做，極大程度上保護用戶的安全。

同時，數據庫中的靜態數據採用加密存儲方式，解密密鑰由用戶生成，掌握在用戶手中，使得開發人員沒法經過簡單的查詢數據庫的方式來獲取到你們的統一認證帳戶。

雲環境

咱們暫定使用課程組提供的華爲雲資源，爲1核1G的服務器。

考慮到實際狀況，1核1G太少，未必可以知足咱們的需求，在爬蟲進行較高頻率的爬取時，可能會致使內存不足，以及服務器最重要的帶寬多多少少會影響到咱們的響應速度。若是在實踐過程當中發現不足，可能會考慮自費更換更高配置的服務器。

2、先後端接口設計

先後端的對接使用HTTPS請求來完成。同時，咱們的設計思路遵循RESTful原則，前端只須要調用接口便可得到數據，不須要思考內部細節。架構設計如圖：

下面是暫定的接口規則，有待進一步細化。

#	請求方法	請求路徑	用途
1	POST	/api/users/verify	用戶驗證
2	GET	/api/users/timetable	獲取課表
3	GET	/api/users/score	獲取成績
4	GET	/api/users/todolist	獲取課程中心ddl
5	GET	/api/users/empty_rooms	獲取空教室
6	GET	/api/users/tests	獲取考試時間表

3、設計原則

• 抽象

  • 行爲抽象

    行爲的抽象主要體如今前端與後端、後端與爬蟲的交互上。咱們對實現特定功能的接口均進行了明確的定義，其中具體的操做不須要調用者去操心。

  • 數據抽象

    咱們將全部數據存在數據庫中，數據庫設計在models.py中，將每一個表封裝成了對象，方便增刪讀寫的操做。同時將結構的變更維護爲遷移記錄，方便往後的開發維護。

• 內聚/耦合/模塊化

  主要體如今後端的設計上。後端使用的Django框架自己支持較爲方便的MVC模式，每一個不一樣的功能能夠設計進不一樣的djangoapp，每一個djangoapp都有獨立的方法進行管理，它們之間不會在數據和功能上相互影響。

  前端APP也分爲不一樣的頁面，其每一個頁面有本身獨立的功能，它們之間不會相互影響，每一個頁面各司其職，完成它們本身的功能，這也是分工開發的必然。

• 信息隱藏和封裝、界面和實現的分離

  信息的隱藏封裝，也是先後端分離架構的一大原則。咱們沒有把全部的查詢功能放在用戶程序中去實現，而是經歷用戶-服務器-教務的過程，之間用盡量少的信息來進行交互隱藏，僅僅經過API交流，互相不暴露內部細節。

  而用戶手中的前端Android APP，自己就具備較好的封裝性，解包和非法讀取數據有必定的難度，也對信息的隱藏封裝、界面和實現的分離有較好的幫助。

• 如何處理錯誤狀況

  做爲一款Android APP，前端留給用戶犯錯的機會十分有限，若出現輸入非法之類的簡單錯誤，則會在前端檢出，不會將請求發送給後端。

  大多數錯誤會在後端被檢出。一旦檢出錯誤，或者後端內部的爬蟲出現爬取錯誤，則會返回相應的HTTP Status Code，來判斷髮生了什麼樣的錯誤。前端將Code轉譯爲文字，告訴用戶具體發生的錯誤是什麼，給予用戶詳細的操做指導。

• 程序模板對於運行環境、相關模板、輸入輸出參數有什麼假設？這些假設和相關的人員驗證過麼？

  前端的運行環境和模板基於Android平臺，其上自己具備大量應用可供參考，且咱們的產品並無性能和網絡需求，因此不會有太大的問題。

  後端可能對於高併發爬蟲處理存在着一些問題，主要是服務器資源佔用過大，致使性能跟不上，若是後續實踐中出現相關問題，咱們會當即更換雲端環境。

  先後端交互依賴HTTPS請求，其輸入輸出參數自己就有很嚴格的標準限制，且咱們有充分的錯誤處理設計，在交互上不會出現很大的問題。

• 應對變化的靈活性

  靈活性創建在模塊化和低耦合之上。咱們對先後端儘量的分離、後端儘量的模塊化也是基於這一點。若是出現新的需求，或者教務網站出現意外狀況，咱們能在修改儘量少的代碼的狀況下，完成咱們的工做，可以體現出高度的靈活性。

• 對大量數據的處理能力

  後端對於大量來源於前端的請求處理能力，創建在Django框架的合理性和服務器自己的性能之上，這二者都已經在其餘大型項目中獲得過驗證。而在接口設計方面，咱們已經儘量將API和數據傳輸內容進行簡化，不會由於接口問題而致使處理出現難度。

  爬蟲對於來自於後端的大量命令處理多是一個難點。服務器自己的帶寬和資源不支持多開chrome進行高併發查詢，因此咱們的解決辦法是儘可能減小爬取次數。可以經過緩存機制解決，可以肯定短期內不會變化的數據，咱們不會進行重複爬取，儘量減少服務器壓力。