二、規劃階段
不論你是從頭開始構造**、移植**還是增加某個重要的功能，為了確保設計決策的最優化，進行一些先期規劃是必要的。如果你和其他人協作完成一項工程，就工作總量及其分配達成明確的共識具有不可估量的作用。在規劃期間，你應該努力對系統的以下方面形成正確的認識：
2.1 使用者
了解使用系統的使用者是很重要的。不僅系統分析要求你接觸一些使用者（通過問卷調查、email，或者面對面交談），而且你經常還要讓系統能夠控制不同的使用者角色和許可權。通過對使用者進行分類並了解他們的需求，你就可以找出線索來確定資料庫的安全機制、功能限制方法、使用者介面分組、培訓和幫助需求、對具體內容的需求，甚至還可以從側面了解到潛在廣告客戶的分布。
圖1：參與者/角色 層次圖
上圖顯示了幾組不同的**使用者（在uml中稱為actor，即參與者）。在這裡，最普通的使用者型別（「site user」）位於圖的頂端，實線箭頭表示generalization關係（「泛化」關係，參見本文附錄說明，下同），它表示site user又可以具體分成兩類使用者：guest，registered user。這兩類使用者共有的特徵在「site user」參與者中說明，而guest和registered user各自私有的特徵則在對應的參與者中說明。通常，你可以直接為參與者加上說明文件，無需單獨編寫說明使用者的文件，但具體與你所用的uml工具有關。在本例中，registered user又可以細分為wireless user和administrator兩種型別，系統對這些使用者的處理方式應有所不同。
2.2 定義需求
在正式開始編寫**之前，你應該對準備構造乙個怎樣的系統有乙個清晰的認識。雖然在編寫**的同時也可以逐步完成這一工作，而且這種做法也很有吸引力，但借助圖形和文字資料事先集體進行討論效率要高得多。為**編寫詳細的需求說明往往不那麼合算，但你應該有時間畫出幾個草圖、寫下幾段註解去說明**準備提供的服務。這就要用到use case圖（用例圖）。use case可以看成一組功能——它可能對應**上的乙個頁面、乙個必須編寫的程式，或者**上可能發生的乙個動作（比如，驗證使用者登入，改變使用者的配置檔案，清除過期的帳號，等等）。下面就是乙個能夠幫助你規劃**的use case圖。注意，該圖並沒有顯示出**的所有use case，通常我們需要多個use case圖才能描述完整的**功能。
圖2：use case圖
即使是在這樣乙個簡單的use case圖中，我們也能夠輕鬆地表達出大量的資訊。例如，include關係說明兩個use case包含同樣的身份驗證功能；extend關係說明天氣頁面可能以wml或者html格式顯示；generalization關係說明各個具體的表現過程將遵從「render html page」或者「render wml page」所描述的基本行為規則以達到維持統一的風格效果和統一巨集觀行為模式的目的。
上圖也顯示出無線使用者能夠訪問**中其他使用者不能訪問的某些區域。在這個use case圖中，只有無線使用者能夠訪問交通流量報表。這是因為我們已經得知只有在旅途中的移動使用者才需要交通流量報表，而且不想再花時間把交通流量報表製作成其他標記語言形式。由此，「get traffic report」use case不需要分成wml和html兩種顯示形式，它可以直接包含「render wml traffic report」這個use case。
一般地，你應該為這些use case加上簡單的說明。具體地說，你應該描述每乙個use case裡將要發生什麼，誰可以使用它，它如何啟動、如何停止，以及某些時候可能發生的特殊事件（稱為variation，即變化）。
2.3 使用者介面組織
在製作use case的過程中，你會得到一些指示**需要哪些使用者介面的線索。也許你早就有了設計某些頁面的絕妙主意，但use case幫助我們從另外乙個角度來看問題。使用者是否確實需要那麼多的介面？某個頁面是否過於複雜？**的導航設施是否簡單易用，即從主頁訪問常用服務是否很方便？在勾畫介面草圖、製作**原型之前，你應該先在use case圖中解決這些問題。
當use case逐漸清晰時，我們就可以開始勾畫出**的大致結構。有些人會強調說頁面和檔案應該用相應的構件圖（component diagram）建模，其實類圖（class diagram）工具也很方便。請參見下圖：
該圖還顯示了在頁面之間傳遞的引數。regionid是乙個很重要的引數，它代表著使用者感興趣的地區（可能是乙個國家、城市或者省份）。regionid在頁面之間傳遞地區資訊，使得使用者能夠從指定地區的天氣報表跳轉到交通流量資訊。至於**的common區域，你可以看到指標指向的是整個包（package）而不是區域中的單個檔案，這是一種減少混亂的簡化方法，因為所有其它的包都要用到大部分（如果不是全部的話）/common/區域中的檔案。
使用者介面布局圖能夠幫助你避免**混亂，它對於規劃**是很有用的。而且，一旦確定了一種有效的**結構組織方式，它還可以作為乙個固定的模式在多個**上應用。
2.4 工具選擇
對於小型**，選擇工具和技術相當簡單。特別是由於投資的原因，只有少數幾種工具組合才具有現實意義——apache，mysql或者postgresql，php、perl或jsp/servlet。當前最流行的組合是apache + php + mysql，有許多低價位的web託管服務支援並主要集中在這種工具組合上。而對於規模較大的**，在投資應用軟體之前，它必須對各種工具進行更嚴格的評估和測試。下面是乙個構件圖的例子，它可以用來說明**的體系結構。這個圖形雖然簡單，但它已經描述出了當前大多數**的體系結構，對於你的**，重新製作該圖可能也沒有必要，因為再也沒有什麼與眾不同的內容值得加入這個圖形了。
圖4：**體系結構圖
討論軟體的整個生命週期已經超出了本文的範圍，但應該指出的是，建立應用原型和介面模型應該在這個時候就開始。務必記下有關**結構和頁面布局的一些想法，因為最終你會想要為布局（選單，導航條，頁面整體布局等）編寫一些公用的**。另外，如果你正在轉到新的工具和技術，建立原型的工作能夠讓你確保設計的可行性，確信已經就新工具的使用對開發組成員進行了足夠的培訓。
設計階段應該與分析階段交迭。一旦對自己所要構造的系統有了較多的認識，你就應該開始擬定設計思路。先100％地分析系統再進入設計階段是沒有意義的。需求總是不斷地發展，而設計本身有時也會推動需求的發展（反之亦然）。所有的開發者都在進行某種型別的設計——只不過有些開發者直接以程式設計**的形式進行設計。雖然這也能夠完成任務，但它使得管理複雜工程和在工作組之內分配任務變得非常困難。先花一點時間通過設計圖構造系統模型，以後你將獲得巨大的回報。
3.1 為未來而設計
許多開發者花費在**除錯和改寫上的時間超過了編寫**的時間，如果從乙個以上**的建設來看這個問題，情況就尤其嚴重了。好的**設計能夠以結構、組織方式和**重用的形式應用到多個**上。然而，如果**只是匆匆忙忙堆砌而成，從現有**長期獲益的機會就減少了。要對**進行設計規劃，一種很有效的方法是畫出類圖（class diagram）。下圖顯示了類圖通常要用到的許多重要關係。
圖5：類圖
說明如下：
即使你所構造的不是乙個物件導向的系統，你仍就可以用類圖建立系統的模型。類能夠方便地描述出各種包含關係和你所編寫的函式檔案。雖然此時類圖不再顯示繼承、構成/聚合等物件導向系統特有的關係，但它可以用依賴關係描述出檔案之間的呼叫關係。
mysql uml建模 UML 建模
建模公式 這種精華的東西，一定是值得研讀和實踐的！myself 人，事，物，規則。人，業務主角 業務工人 參與者。如果應用到教務系統中，就是管理員，主任，老師的關係。事，業務用例，系統用例。物，業務實體。有些東西，一次兩次理解不了。要多理解幾次就好了。有些東西，先留個印象，相信隨著不斷思考，一定會逐...
UML 資料建模
一 資料庫模簡介 二 資料建模元素 1 表 table 2 表索引 table index 3 表觸發器 table trigger 4 表約束 table constraint 5 檢視 view 6 儲存過程 stored procedure 三 資料建模例項 四 總結 資料建模不僅可以物件的屬...
UML實現建模
uml中類圖例項 介面 空心圓 直線 唐老鴨類實現了 講人話 依賴 虛線 箭頭 動物和空氣的關係 關聯 實線 箭頭 企鵝需要知道氣候才遷移 聚合 空心四邊形 實線 箭頭 雁群和大雁的關係 合成 組合 實心四邊形 實線 箭頭 鳥和翅膀的關係 泛化 繼承 空心三角形 實線 動物和鳥的繼承關係 實現 空心...