3.10 Web應用系統的需求建模

Web開發過程必須使用敏捷方法，但需求分析常常是非常耗時的，然而，解決錯誤的問題甚至更花時間。在開發Web應用系統時，能否確保理解了問題的需求？如果答案是“是”，那么可以跳過需求建模，但如果是“否”，就應該實施需求建模。

Web應用需求建模的重視程度依據以下幾個因素。

●Web應用的規模和復雜度的增長。

●相關利益者的人數（所做的分析能幫助識別不同來源的需求沖突）。

●Web應用團隊的人數。

●Web應用團隊成員的經驗（所做的分析有助于達成對項目的共同理解）。

●組織成功的程度直接依賴于Web應用的成功。

與之相反的觀點是，當這個項目規模更小，干系人更少，開發團隊更有內聚力，應用系統并非十分重要，則采用更輕量級的分析方法是合理的。

雖然在開始設計前做問題分析是一個好主意，但并不見得所有的分析一定要在所有的設計之前進行。事實上，Web應用系統中僅有特定部分的設計會要求分析對其有影響的需求。例如SafeHome，對所有網站做符合要求的美學設計（版面布局、色彩框架等）不需要分析電子商務能力的功能需求。為了提高交付成果，軟件分析師只需要分析與遞增式交付相關的設計工作部分。

3.10.1 需求建模的輸入

當Web應用系統已經工程化時，可以采用常規軟件過程的敏捷版本。這個過程包含的溝通活動可以識別干系人和用戶類別、業務環境、界定信息和可用的目標、普通的Web應用系統需求和使用場景，這些都能成為需求建模輸入的信息。這些信息以自然語言的描述、概要大綱、草圖及其他非正式形式表達。

分析這類信息，并使用（所適用的）正規定義的表達模式構造它，接著生成更縝密的模型作為輸出。需求模型提供了揭示問題真實結構的詳細指導，并提供洞察其特性的解決方案。

雖然溝通活動提供了很好的理解基礎，但是需求分析通過提供額外的解釋會使理解更精確。當把問題的結構描述成需求模型的部分內容時，新問題又出現了。這就是彌補理解差距的問題，實際上這些問題也幫助人們在第一時間發現這些差距。

總之，在溝通活動中收集到的信息作為需求模型的輸入，即從非正規的電子郵件到包括綜合使用場景和產品規格說明書中詳細項目概述的任何內容。

3.10.2 需求建模的輸出

需求分析提供了嚴格規定的機制來描述和評估Web應用系統的內容和功能、用戶將遇到的交互模式，以及Web應用系統所處的環境和基礎設施。

每種特性都能表示成一套模型，這套模型允許以結構化方式分析Web應用系統的需求。當特定模型很大程度上依賴于Web應用系統的性質時，會有5種主要的模型類型。

●內容模型，給出由Web應用系統提供的全部系列內容。內容包括文本、圖表和圖像、視頻和音頻數據。

●交互模型，描述了用戶與Web應用系統采用了哪種交互方式。

●功能模型，定義了將用于Web應用系統內容并描述其他處理功能的操作，這些處理功能不依賴于內容卻是最終用戶所必需的。

●導航模型，為Web應用系統定義所有導航策略。

●配置模型，描述Web應用系統所在的環境和基礎設施。

分析師可以使用描述模式開發每一種模型，這種“語言”描述模式考慮到其意圖和結構，使Web工程團隊的成員和相關利益者之間更容易進行溝通和評估。結果是識別出關鍵問題列表（例如錯誤、遺漏、不一致性、供增強和更改的建議、澄清觀點）并照此行動。

3.10.3 Web應用系統內容建模

內容模型包含結構元素，它為Web應用系統的內容需求提供了一個重要的視圖。這些結構元素包含內容對象和所有分析類，在用戶與Web應用系統交互時生成并操作用戶可見的實體。

內容開發可能發生在Web應用系統的實現之前、構建之中，或者投入運行以后的很長一段時間里。在每種情況下，它都通過導航鏈接合并到Web應用系統的總體結構中。內容對象可能是產品的文本描述、描述新聞事件的一篇文章、在體育運動事件中拍攝的一張動作照片、在一次論壇討論中某個用戶的回答、公司徽標（logo）的一種生動演示、一個演講的簡短視頻，或者是一套演示幻燈片中的音頻插曲。這些對象內容可能存儲于分離的文件中，直接嵌入Web頁中，或從數據庫中動態獲得。換句話說，內容對象是呈現給最終用戶具有匯聚信息的所有條目。

通過檢查直接或間接引用內容的場景描述，可以根據用例直接確定出內容對象。內容模型必須具備描述內容對象構件的能力。在許多實例中，用一個簡單的內容對象列表，并給出每個對象的簡短描述就足以定義設計和實現所必需的內容需求。但是在某些情況下，內容模型可以從更豐富的分析中獲得好處，即在內容對象之間的關系和（或者）Web應用系統維護的內容層次中采用圖形化表示其關系。

例如，考慮圖3-22中為SafeHomeAssured.com構件建立的數據樹。該樹表述了常用于描述某個構件的一種信息層次。不帶陰影的長方形表示簡單或復合數據項（一個或多個數格值），帶陰影的長方形表示內容對象。在此圖中，描述說明（description）是由5個內容對象定義的。在某些情況下，隨著數據樹的擴展，其中的一個或多個對象將會得到進一步細化。

由多項內容對象和數據項組成的任何內容都可以生成數據樹。開發數據樹盡量在內容對象中定義層級關系，并提供一種審核內容的方法，以便在開始設計前發現遺漏和不一致的內容。此外，數據樹可以作為內容設計的基礎。

圖3-22 SafeHomeAssured.com構件的數據樹

3.10.4 Web應用系統的交互模型

絕大多數Web應用系統都能使最終用戶與應用系統的功能、內容及行為之間進行“會話”。可以使用交互模型描述會話，這種交互模型由一種或多種元素組成：用例、順序圖、狀態圖；和（或）用戶界面原型。

在許多實例中，一套用例足以描述在分析階段的所有交互活動（在設計階段引入更細化的細節）。然而當遇到復雜的交互順序并包含多個分析類或多任務時，有時更值得采用嚴格的圖解方式去描述它們。

用戶界面的布局、介紹的內容、實現的交互機制，以及用戶與Web應用系統連接上的總體審美觀，都與用戶的滿意度和Web應用系統的整體成功密切相關。雖然創建用戶界面原型是一種設計活動，但在創建分析模型期間就開始創建用戶界面原型仍是一個好辦法，對用戶界面的物理表示評估得越早，就越有可能滿足最終用戶的需求。

Web應用系統的構造工具種類繁多且功能強大，可以用于創建界面原型。原型應該實現主要的導航鏈接，并采用同樣的構造方式表現總體的屏幕布局。例如，如果為用戶提供5種主要系統功能，當用戶看到這些原型第一次使用Web應用系統時，這些原型就表示了這些系統功能，至于圖形鏈接、導航菜單和顯示信息等，可以由原型來回答以上類似的問題。

3.10.5 Web應用系統的功能模型

許多Web應用系統提供大量的計算和操作功能，這些功能與內容直接相關（既能使用又能生成內容）。這些功能常常以用戶Web應用系統的交互活動為主要目標。正因如此，必須分析功能需求，并且當需要時也可以用于建模過程。

功能模型描述Web應用系統的兩個處理元素，每個處理元素代表抽象過程的不同層次：①用戶可觀察到的功能是由Web應用系統傳遞給最終用戶的；②分析類中的操作實現與類相關的行為。

用戶可觀察到的功能包括直接由用戶啟動的任何處理功能。例如一個金融Web應用系統可以執行多種財務功能（例如計算器）。這些功能實際上可能使用分析類中的操作完成，但是從最終用戶的角度看，這些功能是可以看見的結果。

在抽象過程的更低層次，分析模型描述了由分析類操作執行的處理。這些操作可以操縱類的屬性，并參與類之間的協作來完成所需要的行為。

不管抽象過程的層次如何，UML的活動圖可用來表示處理細節。在分析階段，僅在功能相對復雜的地方才會使用活動圖。許多Web應用系統的復雜性不是出現在提供的功能中，而是與可訪問信息的性質及操作的方式相關。

3.10.6 Web應用系統的配置模型

在某些情況下，配置模型只不過是服務器端和客戶端的屬性列表。但是，對更復雜的Web應用系統來說，多種配置的復雜性（例如，多服務器之間的負載分配、高速緩存的體系結構、遠程數據庫、同一網頁上服務于不同對象的多個服務器）可能對分析和設計產生影響。在必須考慮復雜配置體系結構的情況下，可以使用UML部署圖。

3.10.7 導航建模

導航建模考慮了每一類用戶如何從一個Web應用系統元素（如內容對象）導航到另一個元素。把導航機制定義為設計的一部分。在這個階段，分析人員應該關注總體的導航需求，應該考慮以下問題。

●某些元素比其他元素更容易得到嗎（即需要更少的導航步驟）？表示的優先級別是什么？

●為了促使用戶以他們自己的方向導航，應該強調某些元素嗎？

●應該怎樣處理導航錯誤？

●導航到相關元素組的優先權應該高于某個特定元素的優先權嗎？

●應該通過鏈接方式、基于搜索的訪問方式還是其他方式來實現導航？

●根據前面的導航行為，某些確定的元素應該展現給用戶嗎？

●應該為用戶維護導航日志嗎？

●在用戶交互的每一點處，（與單個“返回”鏈接或有方向的指針相比）一個完整的導航地圖或菜單都可用嗎？

●導航設計應該由大多數普遍期望的用戶行為來驅動，還是由已定義的Web應用系統元素可感知的重要性來驅動？

●為了促進將來使用快捷，一個用戶能否“存儲”他以前對Web應用系統的導航？

●應該為哪類用戶設計最佳導航？

●應該如何處理Web應用系統外部的鏈接？應該覆蓋現有的瀏覽器窗口嗎？該導航能否作為一個新的瀏覽器窗口，還是作為一個單獨的框架？

軟件工程師和其他干系人必須決定導航的總體需求。例如，提供的“站點圖”能讓用戶全面縱覽整個Web應用系統的結構嗎？“導游”將突出顯示可以使用的最重要的元素（包括內容對象和功能）嗎？用戶能夠訪問內容對象或者由其元素屬性所決定的功能嗎（例如，用戶可能想要訪問一個特定建筑的所有圖片）？