uml輔助網(wǎng)站規(guī)劃與設計指導書-預覽頁
【正文】 。上圖也顯示出無線用戶能夠訪問網(wǎng)站中其他用戶不能訪問的某些區(qū)域。一般地，你應該為這些Use Case加上簡單的說明。用戶是否確實需要那么多的界面？某個頁面是否過于復雜？網(wǎng)站的導航設施是否簡單易用，即從主頁訪問常用服務是否很方便？在勾畫界面草圖、制作網(wǎng)站原型之前，你應該先在Use Case圖中解決這些問題。 / 網(wǎng)站的根 /weather/ 天氣報表該圖還顯示了在頁面之間傳遞的參數(shù)。用戶界面布局圖能夠幫助你避免網(wǎng)站混亂，它對于規(guī)劃網(wǎng)站是很有用的。當前最流行的組合是Apache + PHP + MySQL，有許多低價位的Web托管服務支持并主要集中在這種工具組合上。圖4：網(wǎng)站體系結構圖 討論軟件的整個生命周期已經(jīng)超出了本文的范圍，但應該指出的是，建立應用原型和界面模型應該在這個時候就開始。一旦對自己所要構造的系統(tǒng)有了較多的認識，你就應該開始擬定設計思路。雖然這也能夠完成任務，但它使得管理復雜工程和在工作組之內分配任務變得非常困難。然而，如果代碼只是匆匆忙忙堆砌而成，從現(xiàn)有代碼長期獲益的機會就減少了。 Renderer類是一個抽象類（用斜體字顯示）。 WeatherReport類創(chuàng)建并擁有Region對象，這通過代表聚合關系（Aggregate Relationship）的黑色菱形顯示出來，它表示一個對象擁有并創(chuàng)建其他對象。 類圖中的每一個類應該注明：所有的方法（以及所有的變量，如有的話），方法的訪問屬性（public，private或者protected），方法的返回值類型，方法的參數(shù)，變量的類型。雖然此時類圖不再顯示繼承、構成/聚合等面向對象系統(tǒng)特有的關系，但它可以用依賴關系描述出文件之間的調用關系。對于Web網(wǎng)站設計來說，情節(jié)圖（Scenario Diagram）特別有用。協(xié)作圖和序列圖分別舉例如下。一些人喜歡以“1，2，3，……”形式對執(zhí)行步驟編號，但一般而言，用“1，2，……”的形式顯示出調用棧的深度是一種更好的選擇，這種編號方式能夠更清楚地顯示出程序的控制轉換過程。事實上，許多UML建模工具能夠從協(xié)作圖生成次序圖，或者相反。 如果要顯示代碼中與時間或線程密切相關的問題，選擇次序圖。 如果要顯示幾個或者大量對象之間的交互過程，選擇次序圖。盡管如此，部署圖（Deployment Diagram）在兩個方面仍舊很有用：網(wǎng)站結構，文件組織。如果使用得法，UML能夠幫助我們輕松地構造出更好的網(wǎng)站。它意味著你不應該把構造UI的代碼和實現(xiàn)數(shù)學算法的代碼混合到一起，你應該盡力把所有與用戶緊密相關的信息封裝到UserAccount類。它不僅使得整個設計容易理解，而且也方便了代碼的維護。更重要的是，修改任意一個類時受影響的類數(shù)量都減到了最少（例如，修改D類只直接影響B(tài)類）。只有在實踐中不斷鍛煉才能避免出現(xiàn)過于復雜的設計，但注意以下幾點有助于達到這一目標： 采用直觀、有意義的名字。 不要害怕改寫代碼。代碼膨脹是類缺乏內聚力的一種征兆。其他人可能有新的想法，或者為你指出你以為顯而易見但別人卻不能明白的問題。注意這并不是建議把性能問題拋到腦后，而是建議把細節(jié)優(yōu)化問題留到工程后期考慮。如果你使用2000以前的版本，你可以在這里找到Visio Stencil and Template for UML。 五、附錄：常用UML符號和參考資源 下面這個表格簡要介紹了常用的UML符號和關系。Actor參與者。一般地，Use Case記錄對某個系統(tǒng)功能的需求，而這個功能由對動作或者事件的應答示范。extend Relationship擴充關系。這意味著一個事物了解另一個事物，并需要另外一個事物才能發(fā)揮功能。構件一般代表一個軟件單元，它可能是一個DLL、一個執(zhí)行文件，或者是一個數(shù)據(jù)庫。UML中的類與面向對象編程中的類一樣，即它定義并封裝了一組行為和屬性。例如，“MyClass myObj = new MyClass。Interface接口。Abstract Class抽象類。你可以為兩個類之間的這種關系提供更具體的信息。聚合關系表示某個對象屬于其他對象所有。 Object Oriented FAQ：一個面向對象術語和概念的介紹
黨政相關相關推薦
鄂ICP備17016276號-1