許多WebLogic項目的軟件架構師或項目負責人已經在重用的努力中備受挫折
而且死板的CASE工具套件用於開發可重用軟件時給許多開發人員留下了壞印象
因此
究竟是什麼改變了從而使得今天軟件重用得以可行？在這個關鍵時刻
三個關鍵因素使得人們覺得軟件重用計劃值得考慮或重新考慮
· 成熟
基於組件的開發環境
· Web服務和面向服務的體系結構
· 面向重用的軟件工程過程和工具
我將討論為什麼三個因素中的每一個對於有效軟件重用的目標都非常關鍵
並且許多情況下
在越來越多IT機構中
為什麼它們和商業因素結合在一起使軟件的重用計劃成為標准操作過程中的強制執行部分
成熟的基於組件的開發環境 當回顧過去
年的軟件開發時
無論在編程技巧的精巧方面
還是在供開發人員使用的特定於語言的服務方面
我們都可以看到一個穩健的過程
從早期C只有有限的標准庫
而且很多事情依靠智力來自己做
到結構化編程的提出
以及到面向對象編程迅速壯大的早期階段
到CORBA的分布式組件基礎結構和服務
到今天的現代J
EE和
NET組件架構
我們可以區分出一些使創建和使用可重用軟件可行的主要因素
結構化編程技術對模塊調用者使用的明確定義的功能協議概念有所貢獻
根據其前提條件
期望的輸入和輸出參數（包括那些參數的語義）
副作用以及調用所描述函數可能引起的任何違例條件等來定義一個協議
該定義對在調用者和被調用模塊之間傳遞明確的描述
面向對象編程引入了數據封裝和多態的概念
它們都對有效的軟件重用有所貢獻
數據封裝避免將底層數據結構暴露於對象的調用者
這些數據結構用於管理持久數據
並允許信息傳遞給與調用者目標更加准確的方法調用
多態在將調用代碼和實現分離的同時
使類的開發人員能夠提供含義豐富的抽象
這些抽象與根據特定算法需求調整的內部靈活的實現結合在一起
進一步討論一下分離的概念
分布組件技術為開發人員提供了定義和部署粗粒度組件接口的能力
其底層實現匯集了一組處理通用數據和功能目標的相關操作
盡管早期組件基礎結構提供的工具（如CORBA）有所限制
並且開發人員經常必須成為
火箭科學家
來使所有東西能夠正確地協同工作
但是如果做得正確
作為結果
部署後的組件情形將會提供一個有效的
靈活的
可重用的應用程序基礎結構
最後
隨著兩個主要的組件體系結構（J
EE 和
NET）的成熟
為開發人員提供了一個豐富而穩定的平台
在該平台上可以構建和部署它們的組件
這兩種體系結構提供的技術服務
例如事務完整性
消息傳遞和目錄服務
安全
異常處理
遠程訪問
以及許多其他許多服務
他們使開發人員能夠將注意力集中在組件功能上
而無需關注工作需要的所有底層技術基礎結構
Web服務和面向服務的體系結構 我相信您正在疑惑一些問題
難道Web服務與面向服務的體系結構不具有相同含義嗎？面向服務的體系結構是什麼樣的？它和Web服務有什麼區別？
簡單來說
面向服務的體系結構是一個這樣的體系結構
應用程序功能集中在一起
呈現一種獨立於其底層實現的松散耦合形式
這些松散耦合的服務典型地呈現粗粒度能力
這意味著它們通過某種形式的消息傳遞運行庫能夠匯集在一起
也可以說
許多（如果不是大多數的話）面向服務的體系結構利用了正被主要應用服務器廠商實現和促進的基於Internet的Web服務基礎結構
Web服務和面向服務體系結構的特性鼓勵重用
實際上從本質上來說它們也需要重用
因為服務的唯一目標是將一整套功能向多個消費者公開
如果這都不是重用
那什麼是呢？另外
因為服務意味著部署一次
就能在適當的位置訪問它
它們鼓勵跨越應用程序邊界的業務流程集合的概念
使一系列支持業務流程的服務交織在一起
業務流程可能通過圖形化的設計時用戶界面來描述
盡管支持這一概念的工具和底層機制還處於初期
但是一些計劃
如BPEL
WS（Business Process Execution Language For Web Services）
在啟用這種形式的應用程序開發時做出了很大的承諾
盡管期望圖形應用程序集合將會完全取代其他開發技術的想法不太現實
但是它確實在那些技術旁找到了自己的位置
並且在這個過程中
鼓勵底層服務的更有效的重用
服務和組件之間具有支持軟件重用的共生關系
組件通常是服務背後的底層機制
或者完全實現了服務所定義的功能
或者為使用一個或多個遺留系統連接到現代web服務基礎結構提供了必需的附帶代碼
軟件工程過程和工具 過去的十年已經朝著遵守規則和有效的軟件開發環境邁進了一大步
迭代方法
比如RUP（Rational Unified Process）鼓勵關鍵需求的早期發現
實施和提煉
在有規律和及時基礎上的增量改進與重量級的瀑布方法有巨大差別
瀑布方法經常導致軟件的晚交付
並且無法滿足用戶需求
這種情況不少
因為用戶需求經常會隨時間改變
RUP和其他軟件開發環境通過在開發過程中引入特定的Software Development Asset （SDA）搜索和重用回顧檢查點來鼓勵重用
這些搜索和回顧活動發生在開發生命周期的所有層次上
從最初的需求定義
到分析和設計
以及到實施
現代基於UML的建模技術也通過為分析師和開發人員提供一個明確定義功能需求的簡單圖形方式來鼓勵重用
這種形式的需求可以被其他開發工具使用
比如代碼生成器
映射引擎和資產元數據資料庫
基於UML的IDE工具不僅可以用於創建UML
而且也適用於可重用的知識SDA
例如設計模式到結果代碼
自動在源代碼和模型之間保持一致
重用的商業例子 有了這些工具和技術的幫助
並且經歷著不斷地消減IT預算的壓力
在任何規模的IT機構中都不難看到重用計劃的正當理由
Dr
Jeffrey Poulin是著名的軟件行業重用專家
曾經進行了很多研究
指明重用的回報發生在SDA的第一次重用時
他甚至考慮了建立重用資產所需的額外努力
Michael Blechar是Gartner Research的副總裁和研究總監
他指出
企業可以通過提交的軟件資產重用計劃充分提高應用程序開發效率和質量
比例可達
:
或更高
同時也減少了上市的時間
考慮到這一點
分析師和開發人員都必須具有查找和重用這些資產的能力
花些時間研究這些鼓勵重用的工具
（我將在以後編輯的文章中更詳細地討論這些過程和工具）
甚至那些看上去很簡單的事情
比如向開發團隊傳播體系結構方面的指導以及通過資產元數據資料庫分布的UML模型
通過使用行業和組織的最佳實踐來實現的代碼
從而獲得顯著的回報
這樣就會大大地減少重新編寫代碼和增加沉重的維護成本的機會
在您的組織中添加用於定義和分發結構良好的
粗粒度組件和服務的能力
可以加速開發效率
同樣重要地
可以大幅度提高應用程序的一致性
可能也會使您在這場交易中成為英雄！
From:http://tw.wingwit.com/Article/program/Java/Javascript/201311/25385.html
