一個工程實踐專案的完整軟體系統設計方案

吾心似秋月666發表於2020-12-20

1 前言

  本文主要是針對一個留學生資訊管理與分析系統的分析與總結,主要闡述專案的完整設計方案和一些軟體結構特點,並採用不同的檢視來描述專案的軟體系統概念原型。

  工程實踐專案介紹:工程實踐是一個關於留學生資訊管理與分析的平臺。該系統是為使用者提供有關留學服務資訊的雙邊平臺,管理人員定期維護系統,學生可以通過該系統搜尋學校相關資訊,並根據所提供的自身資訊獲得相應的留學建議。留學資訊管理與分析系統可以針對不同使用者,通過多種因素的綜合分析,給出科學的建議,給使用者合適的擇校建議,讓使用者更好的選擇心儀的海外高校。主要是為海外留學的人提供一些指導和推薦作用。

2 軟體設計方案總述

  一個良好的軟體必然是經過好的軟體設計,並不斷重構、迭代的,以具有好的效能和可用性。那麼,怎樣才是一個好的軟體設計呢?

  軟體設計從大的方面來說,有軟體架構風格與策略的不同,從具體實現方面來說,有設計模式的不同,從底層來說,資料的存取以及語言的實現也不一樣。只有採取最適合專案的軟體設計方案,綜合效能、成本、開發效益、可用性,才能獲得最好的軟體設計效果。

  軟體架構風格有很多,如分層架構、典型的MVC架構和MVVM架構、管道-過濾器、客戶端-服務、P2P(如區域鏈)、釋出訂閱風格、CRUD、層次化架構等;典型的設計模式有工廠模式、單例模式、裝飾模式、代理模式、外觀模式、享元模式等;典型的軟體架構的描述方法檢視,比如分解檢視、依賴檢視、泛化檢視、執行檢視、實現檢視、部署檢視等。

  這些軟體架構風格和設計模式並沒有優劣之分,只有適不適合之說。因此,我們要採取最適合本專案的架構風格和設計模式,以達到收益的最大化。

3 軟體架構風格

  本專案是一個多使用者的系統,分為普通使用者和超級管理員,為了軟體設計的合理性、主流性、易用性、維護性考慮,此專案採取B/S架構,即browser/server架構,此架構最適合此專案的開發。

  B/S(Browser/Server)架構,即瀏覽器/伺服器架構,是在C/S(Client/Service,客戶機/伺服器)模式的基礎上發展起來的一種體系結構,在開發Web應用時有明顯的技術優勢。因為在C/S模式下,使用者使用應用時需要下載並安裝客戶端程式,其中同時包含了業務邏輯的實現和介面顯示,由伺服器端提供對資料訪問的處理功能。而在B/S模式下,應用程式的業務邏輯實現和資料處理全部由伺服器端提供,使用者只需依靠瀏覽器作為介面顯示便可使用,非常輕量快捷。

 

 

設計模式

  採用設計模式的目的就是為了軟體的重用,因此採用關注點分離的思想,區分軟體中變化的部分和不變的部分,在不變的部分使用設計模式,以提高軟體的重用性和可維護性。

  此專案採用物件導向的思想,因此不可避免的採用多型的技術,因此也不可避免的採用模板方法模式和策略模式。為了安全的考慮,我們在許可權控制模組採取代理模式,進行使用者審計,防止使用者進行越權訪問;採用外觀模式,進一步簡化瀏覽器的業務邏輯;採用介面卡模式,來適應普通使用者和管理者介面的不適配。

5 檢視及目錄結構

  5.1 分解檢視

  分解是構建軟體架構模型的關鍵步驟,分解檢視也是描述軟體架構模型的關鍵檢視,一般分解檢視呈現為較為明晰的分解結構(breakdown structure)特點。分解檢視用軟體模組勾畫出系統結構,往往會通過不同抽象層級的軟體模組形成層次化的結構。元件主要有類、軟體模組、軟體單元、子系統等。

  根據對留學生資訊管理系統的分析,此係統可以分解成五大功能模組,畫出分解檢視如下:

  

  5.2 依賴檢視

  依賴檢視展現了軟體模組之間的依賴關係。比如一個軟體模組A呼叫了另一個軟體模組B,那麼我們說軟體模組A直接依賴軟體模組B。如果一個軟體模組依賴另一個軟體模組產生的資料,那麼這兩個軟體模組也具有一定的依賴關係。依賴檢視在專案計劃中有比較典型的應用。比如它能幫助我們找到沒有依賴關係的軟體模組或子系統,以便獨立開發和測試,同時進一步根據依賴關係確定開發和測試軟體模組的先後次序。依賴檢視在專案的變更和維護中也很有價值,比如它能有效幫助我們理清一個軟體模組的變更對其他軟體模組帶來影響範圍。

  依賴是一種使用的關係,即一個類的實現需要另一個類的協助,所以要儘量不使用雙向的互相依賴。在程式碼上主要表現為區域性變數、方法的引數或者對靜態方法的呼叫。

  根據分解檢視的五大模組,我們可以把握其中模組之間的關係,通過UML類圖,我們可以畫出相應的依賴檢視:

  5.3 泛化檢視

  首先我們要明確一點就是,泛化不同於繼承,應該大於繼承。不要一提起泛化就想到繼承,這是不準確的。繼承關係只是物件導向分析和設計方法中類之間的典型例子。值得注意的是,採用物件組合替代繼承關係,並不會改變類之間的泛化特徵,因此泛化是指軟體模組之間的一般化或具體化的關係,不能侷限於繼承概念的 應用。

  泛化檢視展現了軟體模組之間的一般化或具體化的關係,有助於描述軟體的抽象層次,從而便於軟體的擴充套件和維護。比如通過物件組合或繼承很容易形成新的軟體模組與原有的軟體架構相容。

  基於以上理解,我們可以簡單重構一下,同樣通過UML類圖,畫出此專案的泛化檢視:

  5.4 執行檢視

  執行檢視展示了系統執行時的時序結構特點,比如流程圖、時序圖等。執行檢視中的每一個執行實體,一般稱為元件,都是不同於其他元件的執行實體。如果有相同或相似的執行實體那麼就把他們合併成一個。

  執行實體可以最終分解到軟體的基本元素和軟體的基本結構,因而與軟體程式碼具有比較直接的對映關係。在設計與實現過程中,我們一般將執行檢視轉換為虛擬碼之後,再進一步轉換為實現程式碼。

  因此,執行檢視其實表現的是系統中間比較動態的那一部分。鑑於此,我們可以通過UML的流程圖來表示此專案的執行檢視:

  

  5.5 實現檢視

  實現檢視是描述軟體架構和原始檔之間的對映關係。比如軟體架構的靜態結構以包圖或設計類圖的方式來描述,但是這些包和類都是在哪些目錄的哪些原始檔中具體實現的呢?一般我們通過目錄和原始檔的命名來對應軟體架構中的包、類等靜態結構單元,這樣典型的實現檢視可以由軟體專案的原始檔目錄樹來呈現。實現檢視有助於碼農在海量原始碼檔案中找到具體的某個軟體單元的實現。實現檢視與軟體架構的靜態結構之間對映關係越是對應的一致性高,越是有利於軟體的維護,因此實現檢視是一種非常關鍵的架構檢視。

  根據此專案的開發,我們可以給出原始碼的目錄檔案結構,即此專案的實現檢視:

 

 

 

 

 

 

   5.6 部署檢視

  部署檢視是將執行實體和計算機資源建立對映關係。這裡的執行實體的粒度要與所部署的計算機資源相匹配,比如以程式作為執行實體,那麼對應的計算機資源就是主機,這時應該描述程式對應主機所組成的網路拓撲結構,這樣可以清晰地呈現程式間的網路通訊和部署環境的網路結構特點。當然也可以用細粒度的執行實體對應處理器、儲存器等。部署檢視有助於設計人員分析一個設計的質量屬性,比如軟體處理網路高併發的能力、軟體對處理器的計算需求等。

  對應於此專案,我們可以採取UML的部署圖來描述其部署檢視:

  

  5.7 工作分配檢視

  工作分配檢視將系統分解成可獨立完成的工作任務,以便分配給各專案團隊和成員。工作分配檢視有利於跟蹤不同專案團隊和成員的工作任務的進度,也有利於在專案團隊和成員之間合理地分配和調整專案資源,甚至在專案計劃階段,工作分配檢視對於進度規劃、專案評估和經費預算都能起到有益的作用。

  在這裡,我們給出此專案的大致工作分配檢視:

  

 

6 資料庫設計

  資料庫採用當下流行的MySQL資料庫,使用Redis進行資料快取,提高可用性。

  根據之前對專案進行的資料建模和分析,大致的可以得出此係統的五個類,對應五張表,我們可以新建一個analysis資料庫,在資料庫裡新建五張表,這裡把相應的表結構的設計列出來:

A)使用者資訊表

  使用者資訊表存放所有使用者的賬號和密碼等重要資訊,用於使用者的註冊和登入。其他資訊則與論壇或其他個人資訊關聯,包括性別、頭像、成績、意向學校或收藏等,可為空,後續進行詳細設計。使用攔截器,未登入不能訪問論壇與院校詳情。

Id

賬號

密碼

暱稱

註冊時間

其他……

 

 

 

 

 

 

 

B)管理員資訊表

  後臺管理人員的資訊。

Id

賬號

密碼

登入時間

登入ip

 

 

 

 

 

 

C)學校資訊表

  學校資訊表主要記錄學校的一些關鍵資訊如名稱、專業設定等。其他例如錄取率、申請材料等在其他資訊中進行詳細設計。

Id

中英校名

國家地區

QS排名

學校介紹

專業設定

其他……

 

 

 

 

 

 

 

 

D)專業資訊表

  專業資訊表包括全球主流專業的詳細資訊。後續進行詳細設計以增強資訊檢索能力。

Id

名稱

學校排名

詳細資訊……

 

 

 

 

 

E)文章資訊表

  論壇的首要的功能是實現文章的釋出與留言,文章資訊表中的熱度包括瀏覽量、點贊數和轉發數,留言列表將採用單獨的表進行對映。

Id

作者

釋出時間

熱度

關鍵詞

文章內容

留言列表

 

 

 

 

 

 

 

 

F)中間結果表

  主要是起到快取的作用,引入中間關聯表。

Id

學校ID

專業ID

詳細資訊……

 

 

 

 

 

 

  資料結構方面的設計我們採取Redis快取和rabbitHQ佇列,具體的資料結構已經通過springboot技術進行封裝,我們這裡不再敘述。

7 軟體系統執行環境和技術選型

  本專案採用JavaWeb應用開發技術,基於Vue+Spring Boot實現一個留學資訊管理與分析系統,旨在為使用者提供完善的資訊檢索功能和建議與分析的推薦功能。前端部分採用HTML、CSS、JavaScript等技術實現使用者介面的開發,並採用Vue+Vue-resource+Vue-cookie。後臺伺服器端基於Java語言進行開發,核心部分採用SpringBoot技術棧,ORM則選擇myBatis框架。資料庫管理方面使用輕量級MySQL資料庫和Redis快取技術,最終採用ECS雲伺服器實現系統的釋出。使用RESTFul進行介面設計、使用前後端分離開發。後續則實現資訊挖掘和視覺化,以實現更強大的分析功能,可能使用Scrapy框架等。

  前端開發平臺:Visual Studio Code

       後臺開發平臺:Intellij IDEA

       資料庫:MySQL & Redis

       伺服器:雲伺服器(ECS)

8 概念模型的核心工作機制 

  概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論,概念原型是一種虛擬化的、理想化的軟體產品形式。也就是說,概念原型 = 用例 + 資料模型。

  軟體架構代表了軟體系統的整體設計結構,它應該是所有這些檢視的集合。但我們不會將不同角度的這些檢視整合起來,因為不便於閱讀和更新。不過我們會有意識地將不同角度的檢視之間的對映關係和重疊部分了然於胸,從而深刻理解軟體架構內在的一致性和完整性,這就是系統概念原型。

  因此基於以上分析和建模,我們就可以總結出此專案的概念原型,同時對此概念模型的工作過程進行分析。

 

  整個概念模型的工作過程為:

  使用者這個用例向系統輸入條件和資料,系統進行分析和篩選為專業、學校和文章幾種資訊,系統獲取到使用者的資訊,進行演算法的分析和提取,並根據每一個獨立的使用者進行個性化推薦,把最適合使用者的學校和專業推薦給使用者。使用者如果對結果不滿意,還可以檢視學校和專業的論壇,通過檢視別人的帖子進行篩選,重新進行資訊檢索,直到獲取到滿意的結果。這就是一次普通使用者的業務過程。比如我是張三,我今年軟體工程專業畢業,我想去美國留學,我輸入自己的論文、科研成果以及GPA,系統會自動推薦適合我的學校,比如哈佛大學,但是我可能並不太想去哈佛,於是去搜一下對應的論壇,發現麻省理工更適合我,於是把簡歷發給了麻省理工,留學分析這個過程完畢。
  管理員登入之後,進入屬於自己的介面,管理員進行增刪改查等操作之後,系統進行處理這些資料,進行更新學校、專業、文章等表結構,並把操作之後的結果返回給管理員,完成了一次業務過程。比如管理員登入系統之後,可以進行學校資訊的更新,專業的更新,對不符合的論壇或者使用者進行刪除操作等。如果某個專業或者學校大家都說好,那麼我可以設定一下推薦權級,讓使用者搜尋的時候,優先看到此學校或者專業,節省使用者的時間。管理員介面主要是個後臺監管介面,可以對系統進行一定的干預,以獲得更好的使用者體驗。

9 總結

  本篇部落格主要給出了留學分析與管理系統的完整設計方案,給出了其蘊涵的軟體結構特點和概念原型(各種檢視),並提供了執行環境和技術選型,最後結合例項給出了該系統概念原型的核心工作機制。希望在進行軟體設計階段予以讀者一定的啟發作用,更好的運用軟體工程的原理進行軟體開發。

10 參考資料

  1 Software Engineering:Theory and Practice(Fourth Edition),ShariLawrence Pfleeger,Joanne M.Atlee

  2 https://www.cnblogs.com/chy666/p/14049077.html

  3 https://www.cnblogs.com/jiangds/p/6596595.html

  4 https://refactoringguru.cn/design-patterns/

 

相關文章