j2ee項目實訓uml及設計模式——第3章系統(tǒng)概要設計中的架構設計第2部分(參考版)
2024-11-21 16:14本頁面
【正文】 但在實際開發(fā)中經(jīng)常會出現(xiàn) 將 持久層 和 業(yè)務層 組合在一體的設計，也就是在 持久層 中承擔部分的 業(yè)務層 的 職責 。但 系統(tǒng)的架 構 師，也必須要明確應用不良的框架或者應用的不適當，不僅不能為系統(tǒng)帶來優(yōu)化的效果，反而會增加系統(tǒng)的負擔、并降低系統(tǒng)的性能！ 企業(yè)應用項目的成敗經(jīng)常是 “ 業(yè)務 ” 、“ 技術 ” 、 “ 管理 ” 三種因素共同作用的結果，而單純引入框架，只能解決部分 “ 技術 ”方面的 問題。軟件是有生命期的，在企業(yè)發(fā)展的過程中，一定會有新的業(yè)務功能的要求增加入或者需要對原有的業(yè)務功能需求進行改變和完善。 而 過分強調(diào)生產(chǎn)，匆忙做出判斷和設計，編碼人員過分賣力 地編程實現(xiàn) 不成熟的編碼，造成持續(xù)不斷 地對系統(tǒng)進行修 改。最后的結果將導致所開發(fā)出的軟件產(chǎn)品或者項目的通用性、擴充性將很差。 低能的 或不負責任的 架構師 在一些規(guī)模較小的項目開發(fā)中，由于受到在項目開發(fā)的時間、資金或人員的能力等方面因素的考慮，基本 上放棄了對軟件項目品質(zhì)的追求。 （ 4）過分強調(diào) 軟件系統(tǒng)本身的 功能，而不 充分考慮如何提高軟件 使用的方便性 和人性化操作 大家應該知道， 企業(yè) 花費大量的投資放在 信息化 方面，對于企業(yè)本身來說是為了能夠更好地 提升 企業(yè) 自 身 的核心競爭力 。 “大而全”的通用性工具軟件的開發(fā)背后，一定是高投資和長開發(fā)周期！ 合理的思維 應該 是在整個 企業(yè)發(fā)展的 戰(zhàn)略規(guī)劃下，從可行性研究出發(fā)，構造一系列的基本上是相互獨立的 并且滿足現(xiàn)有企業(yè)的規(guī)模和業(yè)務需要的 子系統(tǒng)，這些子系統(tǒng)之間預先定義 或者預留出一些 穩(wěn)定的接口 。 系統(tǒng)架構師 應該對企業(yè) 的 需求、市場狀況以及已經(jīng)存在的系統(tǒng)作為 目標 模型來 進行 調(diào)查 和分析 ，搞清 和理順客戶所在的 企業(yè)對 軟件 產(chǎn)品的 最終的 要求到底是什么？產(chǎn)品的設計應該來自于對企業(yè)需求的調(diào)研，而不是 開發(fā)者 自己對新技術的激情 和實驗 。因此，應該 是 軟件系統(tǒng)的 市場決定了產(chǎn)品的設計，而不是技術決定 軟件 產(chǎn)品 的 設計，這一點千萬不要本末倒置 ！ （ 2）把軟件 系統(tǒng) 當成自我 能力體現(xiàn) 的 “工藝 作品” 系統(tǒng)架構師 不應該將所設計和開發(fā)的軟件系統(tǒng) 當成自我 能力體現(xiàn) 的 “工藝作品” ，用于表達自己的智慧，以及表達自己對于技術的理解 和掌握的熟練程度的體現(xiàn) 。 （ 1）新穎的技術不應該成為 軟件系統(tǒng) 設計 的目標 系統(tǒng)架構師 不應該 迷戀于 對 新穎的技術 的應用 ， 或者 認為只要用了新的技術，就能夠開發(fā)出 最好的軟件產(chǎn)品， 企業(yè) 用戶也一定會喜歡 、一定會給企業(yè)帶來進步， 其實這是個誤區(qū) 。 這在作為實驗性的、原理性的教學項目中，是沒有什么問題的，而且也是值得鼓勵的！但如果在企業(yè)應用系統(tǒng)中，也如此 極端 地實施，將會 讓 項目陷入不可控制的地步。他們最喜歡 鼓吹本軟件系統(tǒng)如何達到松藕合 、 系統(tǒng)是如何實現(xiàn)具有 通用性 和 擴展性等等。 “完美主義”者的架構師 作為一個系 統(tǒng)架構師，很多人具有完美主義的傾向。 （ 1）過分追求完美，從而步入軟件架構設計和軟件工程理論方面的誤區(qū)。 軟件架構設計 時可能的 設計誤區(qū) 架構師 所可能 步入 的 軟件架構設計 方面 的誤區(qū) 楊教授工作室 精心創(chuàng)作的優(yōu)秀程序員 職業(yè)提升必讀系列資料 楊教授工作室，版權所有，盜版必究 ， 13/15 頁 架構師很容易走向極端，最常見的兩種極端情況是下面的兩種形式。在好的生命周期流程控制下，開發(fā)出的軟件系統(tǒng)能夠具有較好的適應變化性。 （ 2） 在軟件開發(fā)方法方面 采用很好的軟件生命周期流程能夠很好的控制變化。 在這種原則的指導下， 系統(tǒng)的開發(fā)者 所開發(fā)出的系統(tǒng)將會具有一定的通用性，這也是能夠使軟件系統(tǒng)具有更好的適應性的一個常用的手段。 （ 1） 在系統(tǒng)的架構設計和模塊設計方面 要有前瞻性 ? 在系統(tǒng)的架構設計中盡可能地充分利用各種成熟的框架（商業(yè)或者開源類型的） 因為在應用成熟的框架來進行系統(tǒng)開發(fā)時， 系統(tǒng)的開發(fā)者 可以不需要考慮具體實現(xiàn)的細節(jié)。 2) 其次，系統(tǒng)的開發(fā)者要借助自己和他人的經(jīng)驗對易發(fā)生 變化 的 內(nèi)容進行總結，探索規(guī)律，尋求解決之道；比如 用戶在使用中可以隨時進行改變，這可以用配置界面的形式提供給用戶； 或者另 一種變化是系統(tǒng)部署和發(fā)布時才確定的，則通過配置文件的形式提供給系統(tǒng)部署人員 。 楊教授工作室 精心創(chuàng)作的優(yōu)秀程序員 職業(yè)提升必讀系列資料 楊教授工作室，版權所有，盜版必究 ， 12/15 頁 （ 1）在系統(tǒng)主要的業(yè)務功能方面應該預測到可能會有那些變化 1) 首先，系統(tǒng)的開發(fā)者在開發(fā)系統(tǒng)時 應該站在行業(yè)的高度，從客戶的業(yè)務需求出發(fā)，預測行業(yè)未來的發(fā)展趨勢。 （ 4）第四方面的可能變化是技術實現(xiàn)和新技術的應用所帶來的技術實現(xiàn)的變化 針對領先 技術，系統(tǒng)設計人員認為如果功能上現(xiàn)行技術支持的話，就沒有必要去研究新技術，當進度時間不是很緊張的話，可以去考慮使用新技術，但也要充分考慮新技術可能有的潛在問題和負面影響。下面的 圖 為 模板方法模式 程序結構的 UML 的類圖 ，當系統(tǒng)的功能要求發(fā)生改變時，可以提供一個新的實現(xiàn)類來適應該變化。 （ 2）第二方面的可能變化是程序結構方面的變化 采用抽象的原則，將系統(tǒng)中的公共屬性提取出來，然后再由子類來定義具有自己的特有的屬性 ； 在代碼設計上，遵循“ GRASP 設計原則”，同時合理的運用“設計模式” 。這樣的設計方 案有助于代碼的替換和擴展，而不需要改變源代碼。 圖 松 藕合的系統(tǒng)架構設計的示例（ 優(yōu)化設計的結果） 系統(tǒng)架構設計師應該要 對系統(tǒng)功能 中 的擴展部分有可預見性，在設計方面應該預留好接口 并 隔離變化 ； 在需求管理方面，不應一味的聽取客戶的想法，也要有自己的主張并且用實際的理論或是例子來說服客戶向著自己的方向走 ， 同時還要以 商業(yè) 合同 規(guī)范 客戶 的合理要求 。由于數(shù)據(jù)訪問 服務層分離了兩個都可能會變化的部分，因此系統(tǒng)中的前端或者后端發(fā)生變化時，不會產(chǎn)生相互影響。 因此，必須要將應用系統(tǒng)中的經(jīng)常變化的部分進行隔離！這樣就不會出現(xiàn)相互影響的局面。 圖 緊密藕合的系統(tǒng)架構設計的示例 該系統(tǒng)的設計師采用如此的系統(tǒng)架構設計方案是基于系統(tǒng)中的業(yè)務處理功能實現(xiàn)非常簡單、但對系統(tǒng)的數(shù)據(jù)訪問功能要求卻非常高、數(shù)據(jù)訪問的性能也要求比較高，因此系統(tǒng)的 分層采用三層，控制層與系統(tǒng)中的持久層直接關聯(lián)。 為了不至于 拒絕需求的改變而令客戶的利益受損 或 屈從于需求的改變而導致項目失控 。 當然，為了能夠達到該目標，需要開發(fā)人員特別是系統(tǒng)架構師必須明確項目中“變化”的部分有哪些 ? 并對這些部分加以隔離。 明確軟件產(chǎn)品或者軟件項目中的“變化”的要素 好的軟件
研究報告相關推薦
鄂ICP備17016276號-1