|
當軟體系統的規模、複雜性低的時候，其品質直接經由程式可以掌控。當規模、複雜性增加時，整個系統結構的設計及規格之議題較計算之演算法與資料結構設計就更顯重要。系統結構的議題包含系統之組織；整體控制結構；通訊協定，同步，及資料存取；功能分配至各設計元件；實體佈置；延展能力及效能；設計方案之選擇。這些都是軟體架構層的設計。
[1]
基本上軟體架構是一種抽象機制，抽離在這階段不相干的資訊，用以澄清設計意圖，提供設計之分析基礎，改善可維護性，提供決策、減少風險所需的充分資訊。其主要在處理系統層次的性質，諸如，效能、延展性、可靠性、可遷移性、可維護性等系統品質屬性，
換言之在滿足非功能性的需求。
近年來以元件或物件為基礎軟體發展方式的流行，以組合的方式(Compositional
approach)取代一切自己造的方式(Build from scratch)來建構系統。架構設計在其中扮演的角色益形重要，Design
Pattern的風行便是明證之一，MDA (Model Driven
Architecture)的待勢而起即明證之二，著名的Carnegie Mellon Software Engineering
Institute開出一系列軟體架構設計的課程為明證之三。
那麼軟體架構提供什麼樣的價值呢？依據Len Bass等人[2]及採集各家之言綜合整理如下：
|
˙ |
相關利害人間相互溝通之高階抽象工具 |
|
|
軟體架構係將軟體構成之最佳實務經驗結構成可以清楚辨認的抽象實體，作為共同的語言。於此可以表達不同的關切，及交涉，並且作為各種形式之軟體再用的工具。 |
|
˙ |
代表早期設計決策 |
|
|
軟體架構定義建置上所加諸的限制。意味者建置必須按照架構設計的元件區分及相互關係建構。其用以抓住早期且重要的設計決策，例如，系統賴以組成之結構元件及其介面的選擇，元件間互相合作的行為規範，結構及行為元件的組合方式，導引整個組織的架構風格，系統需求與元件間的對映關係。而且軟體架構設計者與元件設計者可以各司其職，各有所專(Separation
of concerns)。
軟體架構強烈的影響品質屬性，其設計是將系統功能對映至軟體結構，決定對軟體品質在架構方面的支持。例如反映系統封裝(Encapsulation)策略的模組化影響可修改性(Modifiability)，元件間耦合性強弱影響可再用性(Reusability)，元件間溝通協調的複雜度影響效能(Performance)。因此評估軟體架構可預測其品質。 |
|
˙ |
系統之可轉換至其他系統的抽象表示 |
|
|
軟體架構是可以重複使用的模型。以架構為基礎的發展方式，重點放在組合各元件，元件分別發展並可更換。軟體系統的設計可以限縮於數種有用的Architectural
Styles及Design Patterns，減少設計複雜度。 |
|
˙ |
軟體架構與品質屬性的關係？ |
|
|
品質屬性可以說是非功能性需求(non-functional requirements)，其與功能性需求(Functional
requirements)應於設計時一併考量。經由檢查軟體架構中的設計概念，達成滿足品質屬性。 |
|
˙ |
其他像提供面對變動市場的彈性及適應性，架構模式及元件可以再使用或組合更大的系統，以及縮短學習時間。 |
資策會數位教育研究所了解到台灣的軟體產業發展要能興盛，軟體品質是項關鍵。因此陸續推出一系列相關的Classroom + ELearning課程，各位有興趣的讀者若想了解架構設計的進一步詳情，請密切注意開課時程。
參考資料：
1. Mary Shaw, David Garlan, Software Architecture: Perspectives
on an emerging discipline, Prentice Hall, 1996.
2. Len Bass, Paul Clements, Rick Kazman, Software Architecture in
Practice, Addisdon-Wesley, 1998.
3. IEEE SWEBOK trial version 1.00 – May 2001
|
