準則: 架構探索、分析及控制
本準則說明如何使用 RSA 建模環境,來執行專案的架構探索、分析及控制。
關係
相關元素
主要說明

簡介

我們在 RUP 的多項作業中,涵蓋了為何需要檢查新興的設計模型, 決定各種品質層面,以及必要的話,重構模型。 當系統開始實作後,維持系統的架構完整性是極為重要的事情, 如此才能確保不會違反架構與設計限制,並且系統在實作後, 仍會保留架構上的願景。在 RUP 中,這些項目都是審查架構review_the_design_gui_design 以及審查程式等作業中發生的主要檢查點。

在架構與設計整合期間發現的不同,但是聯結的問題:在架構分析(請參閱開發架構概觀調查可用的資產)以及納入現有的設計元素作業中,都建議「軟體架構師」盡可能在反轉工程之後, 找機會重複使用現有的設計與程式資產,將那些資產納入「設計模型」中。 除非重複使用的資產有隨附某種品質認證,否則「軟體架構師」 就要將其納入和新建立的設計與程式相同的檢查。

在這兩種情況下,「軟體架構師」對此靜態分析的後續需求都一樣:

  • 取出已撰寫的應用程式(或程式片段),探索其符號結構, 並在理想的情況下,將此符號結構回復為「設計模型」。 若能回復可瀏覽的文件成品,也可以在沒有文件存在,或文件已經過期時, 讓「軟體架構師」看出程式的實際建構方式
  • 若要分析任何「設計模型」,請先在構件:測量計畫中收集所需的品質衡量標準(例如術語定義:耦合性), 然後檢查是否符合構件:軟體架構文件設計準則
  • 獲知重要的架構或設計變更,以便在必要時,採取更正動作。 重要性是依據「軟體架構師」設定的準則判定。

理論上,這些需求透過檢查就可以滿足;但在實務上,對於較大且較複雜的系統, 就需要進行一些自動化輔助。以下幾節提供這些主題的部份詳細闡述以及工具支援範例。

探索及回復架構

背景

在初期開發 (greenfield development) 中,軟體架構是從需求以及領域環境和慣例(包括型樣和機制)產生;補充規格構件在決定架構時,具有重要的角色。 這個整理軟體架構的過程有時會稱為探索,因為在需求和架構之間, 鮮少有直接了當且機械式的對映存在。不過,在這裡我們要使用不同的探索意義, 來說明協助「軟體架構師」瞭解現有的應用程式或應用程式片段的程式型式之過程。 架構回復則是更有野心的動作:透過回復作業,「軟體架構師」不僅希望瞭解應用程式, 同時也要擷取該應用程式的模型,最理想的情況是取出和「設計模型」相容的抽象層次。 接下來就可以選擇將這些模型合併,並且透過名詞定義:轉換, 或許針對不同的名詞定義:平台,產生新的應用程式。

探索

架構分析(請參閱開發架構概觀調查可用的資產)以及納入現有的設計元素作業中,都建議「軟體架構師」盡可能找機會重複使用現有的設計與程式資產。 例如,組織的資產庫內可能有數個參照架構, 並且理想的情況是這些參照架構都具有最新的文件與模型。 不過,最常見的情況是只有程式碼而已,並且即使有架構文件的話,也不是最新的。

在許多情況下,「軟體架構師」都不能將這種程式碼視為黑盒子(即使其介面都有清楚定義亦然), 而需要瞭解其結構。這個過程可以由自動產生程式的可瀏覽說明功能協助。 如此軟體架構師就可以以視覺方式探索型樣以及程式碼中的反型樣。 此種輔助範例可以在 Rational Software Architect 工具找到, 此工具的架構探查功能會自動移入諸如 Java 應用程式的套件結構、類別內容、 繼承樹以及協同作業等主題圖。如需詳細資訊,請參閱 說明書籍圖示 Rational Software Architect 文件。

回復與轉換

若可重複使用的資產具有模型時,就可以將這些模型和專案特定的模型合併, 然後使用轉換技術,將合併後的模型轉成平台專用的實作方式。 在只有程式碼存在時,即使是使用轉換方式,整合由舊版程式碼轉換來的程式碼, 也還是可以重複使用舊程式碼。

軟體架構師可以透過架構回復,取得最多的能力和彈性:回復功能會產生語意豐富的應用程式模型, 這種模型不但可以用來產生程式碼,也可以用來瀏覽。在實務上,將程式碼反推回直接明確的視覺化呈現, 通常都可以追蹤;這種模型可以返溯回和名詞定義:平台獨立模型「設計模型」相同的抽象層次,這在一般而言,都很難自動設計到完整。

這是名詞定義:平台特定的模型轉換為名詞定義:平台獨立的模型(請參閱概念:Model-Driven Development (MDD) 與 Model Driven Architecture (MDA)); 回復的 PIM(片段)再使用模型合併轉換類型,和「設計模型」(它本身是 PIM)合併(請參閱 [OMG03])。

分析架構

可瀏覽的模型可讓軟體架構師透過檢驗,來驗證架構品質。不過,這項作業可能會極繁複和耗時, 同時這種方式的檢查標準和規則依循及收集測量極容易發生錯誤。 軟體架構師應該盡可能尋求將這個程序自動化,以便能空出較多時間來尋找和套用更正措施; 自動化程序可以讓軟體架構師進行實驗、提出「如果 ... 的話會怎麼樣」問題,並快速檢查結果。

什麼可以自動化?

自動化架構分析可以:

  • 找出架構中的型樣和反型樣(病狀結構)
  • 測量各種結構並報告測量值
  • 檢查是否依循軟體架構師規定的限制(請參閱「架構控制」)

名詞定義:型樣是由專案和組織標準決定,並且其用法理論是記載在「軟體架構文件」 (如果具有架構意義的話)或「設計準則」中。透過自動化分析時,軟體架構師可以快速檢查型樣用法, 以驗證是否符合「軟體架構文件」和「設計準則」的本意。反型樣是指會使架構減弱的病狀架構與設計結構, 它會削弱架構、使其變複雜,或是更難以維護等。

需要進行的測量都會在「工作成果:測量計劃」中指出(準則:測量值中有提供一些建議的測量值)。「測量計劃」中也會說明測量值的使用方法, 例如,值較高或較低時比較好,或其趨勢才是重要事項,因此最好能在測量值分析中, 同時指出熱點,這是指在架構中的一些位置,若在這些位置做變更,將會對所收集的測量值產生顯著的改善。 毫無疑問的,這些位置通常會和結構中的病狀相關聯。如此軟體架構師就可以取得進行改善的客觀基準, 他們就可以進行變更,或是指派延續動作,並在動作完成時進行測試。

分析的目標是什麼?

分析的目標會隨著生命週期的演進而改變,並且視所選擇的開發方法而定。 當專案採用轉換(世代式)方法時,分析目標通常就是「設計模型」, 並且假設所產生的應用程式一定和設計同步。如果建立構件:實作模型且分開維護, 或重複使用程式碼時,請將重點集中在程式碼,以確保依據「軟體架構文件」和「設計準則」來測量時可以保持架構完整性。

這種分析類型(針對「實作模型」)實際可能不會從程式碼回復明確的「設計模型」作為分析之用; 不過這種分析會考量架構與設計議題(如其顯現在程式中),而不是程式碼撰寫標準。

這些概念與功能的範例

Rational Software Architect 工具除了可以透過架構探索,來回復 Java 應用程式的文件外, 也可以依據一組預定的型樣,來識別及報告可能是代表架構內的潛在問題點。 除了其他型樣外,這些型樣包括:

  • Butterfly
  • Breakable
  • Hub
  • Tangle
Butterfly

Butterfly 是一種元素,例如類別,它和其他相依元素具有多重關係, 如果 butterfly 變更時,這些關係就會受到影響。如果關係是直接的關係,這些元素就稱為 local butterfly。Rational Software Architect 也可以追蹤關係在應用程式內的階式排列結構, 並判定若變更某個元素時,除了會影響直接的相依項外,是否也會影響連續的相依項,進而影響整個應用程式。 這種具有許多間接相依關係的元素稱為 global butterfly。以下顯示 local butterfly 的圖例。 圖解中也顯示出關係也可能不是 UML 相依關係:例如,某個元素在被其他元素實現後, 會成為其他元素的相依項;因此若變更所指出的元素時,將會影響該元素的實現元素。

具有四個相依項的類別,其中兩個有使用相依關係、一個有一般化關係、另一個有實現化關係

Local Butterfly

Breakable

Breakable 是指具有多重相依關係的元素;亦即該元素的許多關係中,是相依於其他元素。 若變更其他元素中的任何一個,就會影響 Breakable 元素。和 Butterfly 元素一樣, 若關係是直接關係時,這些元素稱為 local breakable,而如果有多個會影響該元素的間接關係時, 就稱為 global breakable。Global breakable 極容易在應用程式的許多地方變更, 並且會指出應用程式缺乏模組能力。以下顯示 local breakable 的圖例。

具有四個相依項的類別,其中兩個有使用相依關係、一個有一般化關係、另一個有實現化關係。

Local Breakable

Hub

Hub 是指同時包含 Butterfly 與 Breakable 兩種性質的元素。 它也有 localglobal 兩種型號。出現 Global Hub 時, 是表示分割不良,會導致軟體對變更極為敏感,並且變更通常會呈漣漪狀,擴展至整個應用程式。

Tangle

Tangle 是一組很大的元素,它的關係由於過度迴旋纏繞,因此只要其中任意一個元素做變更, 就會影響所有其他元素。這種結構是主要不穩定的來源。

軟體架構師在使用 Rational Software Architect 工具時,可以快速找出這類熱點, 並和「設計師」共同加以更正。如需詳細資訊,請參閱 說明書籍圖示 Rational Software Architect 文件。

時機

這些分析結果對任何審查管制點都極為重要,因為它們是架構及設計品質的客觀及量化證明, 在有重大的架構變更時,也極為重要,如在更新設計模型的組織(在「作業:納入現有的設計元素」中)。

架構控制

軟體架構師的願景會記載在「軟體架構文件」中,並且「設計準則」中會有供設計師參考的實用指引。 即使所有參與人員都具有相同的願景,有時願景也會被專案的每日例行工作給遮蔽了。 有時為了拼期限,可能就會抄小路,同時軟體架構師通常也沒有辦法參與所有決定。 這就會形成控制問題:就像「專案經理」必須設定臨界值和限制,並加以監視(請參閱作業:監視專案狀態),「軟體架構師」對於漸漸浮現的軟體設計和實作,也有類似的責任。

架構控制讓軟體架構師可以建立一些規則,來進行架構限制。例如,軟體架構師可以定義一項規則, 來對特定介面的每項實現提出警告。若沒有工具的協助,這個規則的簡單做法是要經常進行審查,以找出違規者。 若使用自動化方法,就可以撰寫規則,以便在架構分析期間找出違反規則集者。 這種情況即使在進階的控制環境中,在設計和程式產生過程中加入規則,以防止違反規則的情況下, 也是會發生;但即使如此,仍然可以顯著改進人工審查程序。

Rational Software Architect 工具中有包含 Java 應用程式的這項功能: 軟體架構師可以設定一些規則,然後執行分析來確定是否符合規則。 如需詳細資訊,請參閱 說明書籍圖示 Rational Software Architect 文件。