序言
- 論軟件設計模式及其應用
- 論可靠性與設計與應用
- 基於DSSA的軟件架構和應用
- 論微服務架構及其應用
- 分佈式系統設計
馬上就要考試了，這個還是自己寫完的第一篇論文。初步打算會寫五篇。就是上面所寫的。講真的寫這個東西還是一點思路都沒有，這一篇的改動對非常大，暫時做個記錄。也當是自己的勉勵，加油。
論文
摘要：
2018年上半年,我在XX電子責任有限公司,作爲氣候組組長參與了陝西氣象監測業務系統的開發。主要負責和客戶的需求對接、關鍵模塊的分析、系統的架構設計、開發人員的組織安排以及對開發和測試人員氣候方面知識的培訓。陝西橫跨三個氣候帶，南北氣候差異較大,氣候事件種類繁多，共開發了暴雨、高溫、沙塵、霜凍、華西秋雨、春季透雨、初夏汛雨等18類氣候事件的監測評估模塊。所以需求繁雜、變化性大、對業務系統要求高。基於項目的可擴展性和可維護性，我決定使用設計模式進行軟件設計。
項目中主要使用工廠模式解決類的創建問題，利用策略模式解決不同氣候事件統計算法之間的替換，利用模板方法模式提高代碼的可複用性等。設計模式使我們簡化軟件設計、提高開發人員的溝通、降低技術風險和提高軟件質量。爲項目的成功奠定基礎。
正文：
2018年上半年,我所在的公司開發了陝西氣候監測業務系統。該項目共有12名成員。爲了分工明確,主要分爲前端組,後端組和測試組。其中美工組和GIS組在需要的時候配合工作。本人在項目中擔任開發組長,主要進行和客戶的需求分析和系統的架構、關鍵模塊的設計、人員的組織和調配、對整體項目進度的把控。該項目建設的目的是應用於政府及大衆的決策服務。幫助氣象局建設氣象信息現代化的平臺，對各類氣候事件的極端性、等級、歷史排位等作出準確、及時的監測評估。
系統主要採用C/S和B/S的混合架構,其中C/S部分實現了各氣候事件的基礎數據查詢
xx公司是一個很有實力的企業,公司90%的業務是關於氣象的。而氣象業務中氣候又是公司最爲重要的一塊。目前氣候業務已經覆蓋了甘肅、寧夏和新疆三個省。再加上現在陝西的系統。四省的項目同時維護和開發，代價和成本都太高。所以迫切的需要我們能夠基於各省的氣象業務相同點和氣候差一點。開發出一套統一的監測業務系統平臺。通過對業務原型和以往經驗分析,監測業務系統主要三大模塊。一：氣候事件的統計分析，陝西有18種，如高溫、低溫、霜凍、華西秋雨等。然後根據各省的特點不同高溫模塊又有高溫日數、高溫站數和站次、高溫初終日、高溫區域過程、？？二：產品模塊的自動生成，因爲每個科室都需要在月季年末的時候做大量的報表統計。爲了解決解決重複他們的手動統計指標和效率低下提供模板的自動生成和在線編譯。三：各種極端事件的大屏實時展示,主要的精確尺度爲小時。
設計模式是一套被反覆使用的、多數人知曉的、經過分類編目的代碼設計經驗的總結。常見的設計模式主要分爲三大類，創建型模式、結構型模式、行爲式模式。
創建型模式主要用於創建對象，爲設計類的實例化提供指南。所包括的模式有Abstract Factory(抽象工廠)、Factory Method(抽象方法)、Singleton(單例模式)、Builder(建造者)、Prototype(原型)。
結構型模式主要用於處理類和對象的組合,對類如何設計以形成更大的結構提供指南。常見的模式有Composite(組合模式)、Facade(外觀模式)、Proxy(代理模式)、Adapter(適配器模式)、Bridge(橋接模式)、Dectorator(裝飾者模式)、Flyweight(享元)
行爲型模式主要用於類或對象的交互以及職責的分配責任的方式提供指南。常見的模式有：Strategy(策略)、Memento(備忘錄)、Visitor(訪問者)、State(狀態)、Chain of Responsibility(責任鏈)、Template Method(模板)、Observer(觀察者)、Iterator(迭代器)、Commond(命令)、Interpreter(解釋器)。
這裏我主要介紹我們在數據處理和產品管理兩個模塊如何使用設計模式簡化開發。
數據查詢統計模塊。需要統計日候旬月季年的歷史數據。他們都要統計最高溫、最低溫、平均氣溫、降水距平百分率、降水量等。但是他們的統計算法有一定的差異。經過分析我們決定採用簡單工廠模式來創建不同時間類型的對象。簡單工廠模式是定義一個創建對象的接口,並讓子類自己決定實例化哪一個類,將對象的實例化延遲到了子類。首先定義了一個TimePeriod(時間段)的總接口。然後分別由日候旬月季年去實現該接口。這樣當添加一種新的時間段如上旬、春季等我們只要去修改工廠方法，而不用去修改業務邏輯代碼。
上述模塊中,不同對象中統計相同字段的算法統計相同。但是不同字段的統計方法各異。氣溫統計最大值和最小值,降水和日照統計累計值。都需要統計平均值。根據算法的差異,而儘可能的做到對象之間的解耦。我們決定採用策略模式。衆所周知策略模式定義了一組算法集,讓他們直接可以互換。我們首先定義了一個天氣現象算法和時間段的彙總策略接口。在接口中定義了通用方法。接着在不同的子類中實現不同字段處理的算法。最後根據不同的輸入條件和不同的時間段。實例化氣候事件的實例類。然後彙總到彙總控制總類。彙總控制總類只和接口進行關聯，不依賴於具體的子類。彙總控制種類負責執行具體的策略，並把數據放到相應的時間維度上。
一開始我們並沒有採用策略模式。而是採取傳統的方式。每種字段對應一個類來處理。隨着項目的跟進，因爲氣候統計在中國仍然是一門在摸索的學科，後期客戶的需求改動幅度很大。原本只要統計常見的氣溫、降水、日照。後面添加了霜凍、降雪等的統計。導致項目的臃腫和耦合度不斷的提高。程序的可維護性越來越差而且工作量也越來越大。經過分析我們使用了策略模式，不但解決了後期添加的不同字段的統計方式，而且大大降低了後續的開發工作量。
在項目中我們還採用了模板方法模式,解決不同產品模板中多個子類共有的的方法且邏輯相同，提高代碼的複用。使用中介模式解決多個業務邏輯類之間的項目耦合。設計模式使我們簡化並加快設計、方便開發人員之間的溝通、同時降低開發降低風險。
設計模式簡化並提高開發速度，提升軟件質量，爲項目成功奠定了堅實的基礎。項目與2019年5月，被陝西氣象局驗收。各項功能指標都滿足招標要求，得到客戶的一直好評。但是由於項目時間和資源的限制，仍然有一些地方做的不足。因爲我們我們的系統主要給科長和科員日常工作統計彙報所用，所以對數據的準確性和易操作性。爲了快速幫助客戶解決問題和提高代碼的質量，所以對其他的質量屬性。如性能達不到最佳水平。我們需要在設計模式和反設計模式之間找到平衡點，滿足項目實際要求。同時加強技術專業水平，同時總結在項目中的教訓和經驗。爲未來氣候類軟件貢獻一份自己的水平。