Ⅰ 如何讀懂Web服務的系統架構圖
大數據數量龐大，格式多樣化。大量數據由家庭、製造工廠和辦公場所的各種設備、互聯網事務交易、社交網路的活動、自動化感測器、移動設備以及科研儀器等生成。它的爆炸式增長已超出了傳統IT基礎架構的處理能力，給企業和社會帶來嚴峻的數據管理問題。因此必須開發新的數據架構，圍繞「數據收集、數據管理、數據分析、知識形成、智慧行動」的全過程，開發使用這些數據，釋放出更多數據的隱藏價值。
一、大數據建設思路
1）數據的獲得
四、總結
基於分布式技術構建的大數據平台能夠有效降低數據存儲成本，提升數據分析處理效率，並具備海量數據、高並發場景的支撐能力，可大幅縮短數據查詢響應時間，滿足企業各上層應用的數據需求。
Ⅱ web 應用架構圖 用什麼軟體
Dreamweaver,俗稱DW網頁製作軟體
Ⅲ web在實際應用中主要包含哪幾個方面
1、鏈接測試
鏈接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以採用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行鏈接測試。
2、表單測試
當用戶給Web應用系統
管理
員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給伺服器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
3、Cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web伺服器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什麼影響等。
4、設計語言測試
Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
5、資料庫測試
在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的資料庫類型是關系型資料庫，可以使用SQL對信息進行處理。
在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網路速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
二、性能測試
1、連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鍾），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2、負載測試
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面的請求？
3、壓力測試
負載測試應該安排在Web系統發布以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
三、可用性測試
1、導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶介面控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜索引擎或其他的導航幫助？
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要盡可能地准確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2、圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮。
3、內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、准確性和相關性。
信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；信息的准確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟體來進行，例如使用Microsoft Word的」拼音與語法檢查」功能；信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂」相關文章列表」。
4、整體界面測試
整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？
對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。
對所有的可用性測試來說，都需要有外部人員（與Web應用系統開發沒有聯系或聯系很少的人員）的參與，最好是最終用戶的參與。
四、客戶端兼容性測試
1、平台測試
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。
2、瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。
測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
五、安全性測試
Web應用系統的安全性測試區域主要有：
（1）現在的Web應用系統基本採用先注冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（2）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鍾）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（3）為了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）伺服器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯腳本的問題。
Ⅳ Web應用框架的架構
基於請求的框架較早出現，它用以描述一個web應用程序結構的概念和傳統的靜態Internet站點一樣，是將其機制擴展到動態內容的延伸。對一個提供HTML和圖片等靜態內容的網站，網路另一端的瀏覽器發出以URI形式指定的資源的請求，Web伺服器解讀請求，檢查該資源是否存在於本地，如果是則返回該靜態內容，否則通知瀏覽器沒有找到。Web應用升級到動態內容領域後，這個模型只需要做一點修改。那就是web伺服器收到一個URL請求（相較於靜態情況下的資源，動態情況下更接近於對一種服務的請求和調用）後，判斷該請求的類型，如果是靜態資源，則照上面所述處理；如果是動態內容，則通過某種機制（CGI、調用常駐內存的模塊、遞送給另一個進程如Java容器）運行該動態內容對應的程序，最後由程序給出響應，返回瀏覽器。在這樣一個直接與web底層機制交流的模型中，伺服器端程序要收集客戶端籍get或post方式提交的數據，轉換，校驗，然後以這些數據作為輸入運行業務邏輯後生成動態的內容（包括HTML、JavaScript、CSS、圖片等）。
基於組件的框架採取了另一種思路，它把長久以來軟體開發應用的組件思想引入到web開發。伺服器返回的原本文檔形式的網頁被視為由一個個可獨立工作、重復使用的組件構成。每個組件都能接受用戶的輸入，負責自己的顯示。上面提到的伺服器端程序所做的數據收集、轉換、校驗的工作都被下放給各個組件。現代web框架基本上都採用了模型、視圖、控制器相分離的MVC架構，基於請求和基於組件兩種類型大都會有一個控制器將用戶的請求分派給負責業務邏輯的模型，運算的結果再以某個視圖表現出來，所以兩大分類框架的區別主要在視圖部分，基於請求的框架仍然把視圖也就是網頁看作是一個文檔整體，程序員要用HTML、Javascript和CSS這些底層的代碼來寫「文檔」，而基於組件的框架則把視圖看作由積木一樣的構件拼成，積木的顯示不用程序員操心（當然它們也是由另一些程序員開發出來的），只要設置好它綁定的數據和調整它的屬性，把他們大大從編寫HTML、Javascript和CSS這些界面的工作中解放出來。 基於請求的和基於組件的兩種框架各有優劣。雖然一眼看上去後者有很大的吸引力，普通的web開發人員只要使用專門的公司或開源組織提供的組件就可以輕松開發出好用漂亮的界面，但是有幾種因素綜合起來不利於這種理想中的方案。要編寫一個沒有潛在問題的、跨瀏覽器的、顯示美觀並且有足夠靈活性可以調整的伺服器端組件是需要高水平的技能、豐富的經驗和較多時間的，即使付出這些成本，也不能完全避免使用者失望的情況。
綜合來看，基於請求的框架要程序員自己動手的地方比較多，但也因此可以更精細地控制HTML、CSS和Javascript這些最終決定應用程序界面的代碼，特別是如果要在界面上有創新，嘗試新的視覺效果和用戶操作，必然選擇基於請求的框架。基於組件的框架可以提高開發界面的效率，前提是選用的組件質量優秀。
Ⅳ web應用包括什麼
常見的計數器、留言版、聊天室和論壇BBS等，都是Web應用程序，不過這些應用相對比較簡單，而Web應用程序的真正核心主要是對資料庫進行處理，管理信息系統（Management Information System,簡稱MIS）就是這種架構最典型的應用。
一個Web應用程序是由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序是由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。
(5)web應用結構圖擴展閱讀
web應用缺點
1、網路應用程序強調瀏覽器的適用性。如果瀏覽器方沒有提供特定的功能，或者棄用特定的平台或操作系統版本（導致不適用），就會影響大量用戶；
2、網路應用依靠互聯網遠程伺服器端的應用文件。因此，當連接出問題時，應用將不能正常使用。但是，如果使用HTML5 API，這些應用就可以被下載安裝而可離線使用。
3、許多網路應用程序不是開源的，只能依賴第三方提供的服務，因此不能針對用戶定製化、個性化，而且大多數情況下用戶不能離線使用，因而損失了很多靈活性；
4、它們完全依賴應用服務商的可及性。如果公司倒閉，伺服器停止使用，用戶也無法追索以前的資料。對比而看，即使軟體製造商倒閉了，傳統的安裝軟體也可以繼續運行，盡管不能再更新或有其他用戶服務。
Ⅵ 簡述web技術的結構
它是超級文本的簡稱。 二、超媒體（hypermedia） 超媒體是超文本（hypertext）和多媒體在信息瀏覽環境下的結合。它是超級媒體的簡稱。用戶不僅能從一個文本跳到另一個文本，而且可以激活一段聲音，顯示一個圖形，甚至可以播放一段動畫。 Internet採用超文本和超媒體的信息組織方式，將信息的鏈接擴展到整個Internet上。Web就是一種超文本信息系統，Web的一個主要的概念就是超文本連接，它使得文本不再象一本書一樣是固定的線性的。而是可以從一個位置跳到另外的位置。可以從中獲取更多的信息。可以轉到別的主題上。想要了解某一個主題的內容只要在這個主題上點一下，就可以跳轉到包含這一主題的文檔上。正是這種多連接性把它稱為Web。 三、超文本傳輸協議（HTTP） Hypertext Transfer Protocol超文本在互聯網上的傳輸協議。 當你想進入萬維網上一個網頁, 或者其他網路資源的時候，通常你要首先在你的瀏覽器上鍵入你想訪問網頁的統一資源定位符（UniformResourceLocator)，或者通過超鏈接方式鏈接到那個網頁或網路資源。這之後的工作首先是URL的伺服器名部分，被名為域名系統的分布於全球的網際網路資料庫解析，並根據解析結果決定進入哪一個IP地址(IP address)。 接下來的步驟是為所要訪問的網頁，向在那個IP地址工作的伺服器發送一個HTTP請求。在通常情況下，HTML文本、圖片和構成該網頁的一切其他文件很快會被逐一請求並發送回用戶。 網路瀏覽器接下來的工作是把HTML、CSS和其他接受到的文件所描述的內容，加上圖像、鏈接和其他必須的資源，顯示給用戶。這些就構成了你所看到的「網頁」。 大多數的網頁自身包含有超鏈接指向其他相關網頁，可能還有下載、源文獻、定義和其他網路資源。像這樣通過超鏈接，把有用的相關資源組織在一起的集合，就形成了一個所謂的信息的「網」。這個網在網際網路上被方便使用，就構成了最早在1990年代初蒂姆·伯納斯-李所說的萬維網。 傳統的Web資料庫系統體系結構 傳統的Web資料庫系統一般實現Web資料庫系統的連接和應用可採取兩種方法，一種是在Web伺服器端提供中間件來連接Web伺服器和資料庫伺服器，另一種是把應用程序下載到客戶端並在客戶端直接訪問資料庫。中間件負責管理Web伺服器和資料庫伺服器之間的通信並提供應用程序服務，它能夠直接調用外部程序或腳本代碼來訪問資料庫，因此可以提供與資料庫相關的動態HTML頁面，或執行用戶查詢，並將查詢結果格式化成HTML頁面。通過Web伺服器返回給Web瀏覽器。最基本的中間件技術有通過網關介面CGI和應用程序介面API兩種。 （一）、基於通用網關介面CGI CGI是WWW伺服器運行時外部程序的規范，按照CGI編寫的程序可以擴展伺服器的功能，完成伺服器本身不能完成的工作，外部程序執行時間可以生成HTML文檔，並將文檔返回WWW伺服器。CGI應用程序能夠與瀏覽器進行交互作用，還可以通過資料庫的API與資料庫伺服器等外部數據源進行通信，如一個CGI程序可以從資料庫伺服器中獲取數據，然後格式化為HTML文檔後發送給瀏覽器，也可以將從瀏覽器獲得的數據放到資料庫中。幾乎使用的伺服器軟體都支持CGI，開發人員可以使用任何一種WWW伺服器內置語言編寫CGI，其中包括流行的C、C、VB和Delphi等。 從體系結構上來看，用戶通過Web瀏覽器輸入查詢信息，瀏覽器通過HTTP協議向Web伺服器發出帶有查詢信息的請求，Web伺服器按照CGI協議激活外部CGI程序，由該程序向DBMS發出SQL請求並將結果轉化為HTML後返回給Web伺服器。再由Web伺服器返回給Web瀏覽器。這種結構體現了客戶/伺服器方式的三層模型，其中Web伺服器和CGI程序實際起到了HTML和SQL轉換的網關的作用。CGI的典型操作過程是：分析CGI數據；打開與DBMS的連接；發送SQL請求並得到結果；將結果轉化為HTML；關閉DBMS的連接；將HTML結果返回給Web伺服器。 基於Web的資料庫訪問利用已有的信息資源和伺服器。其訪問頻率大，尤其是熱點數據。但其主要的缺點是：①客戶端與後端資料庫伺服器通信必須通過Web伺服器，且Web伺服器要進行數據與HTML文檔的互相轉換，當多個用戶同時發出請求時，必然在Web伺服器形成信息和發布瓶頸。②CGI應用程序每次運行都需打開和關閉資料庫連接，效率低，操作費時；③CGI應用程序不能由多個客戶機請求共享，即使新請求到來時CGI程序正在運行，也會啟動另一個CGI應用程序，隨著並行請求的數量增加，伺服器上將生成越來越多的進程。為每個請求都生成進程既費時又需要大量內存，影響了資源的使用效率，導致性能降低並增加等待時間；④由於SQL與HTML差異很大，CGI程序中的轉換代碼編寫繁瑣，維護困難；⑤安全性差，缺少用戶訪問控制，對資料庫難以設置安全訪問許可權；⑥HTTP協議是無狀態且沒有常連接的協議，DBMS事務的提交與否無法得到驗證，不能構造Web上的OLTP應用。 （二）、基於伺服器擴展的API 為了克服CGI的局限性，出現的另一種中間件解決方案是基於伺服器擴展API的結構。與CGI相比，API應用程序與Web伺服器結合得更加緊密，佔用的系統資源也少得多，而運行效率卻大大提高，同時還提供更好的保護和安全性。 伺服器API一般作為一個DLL提供，是駐留在WWW伺服器中的程序代碼，其擴展WWW伺服器的功能與CGI相同。WWW開發人員不僅可以API解決CGI可以解決的一切問題，而且能夠進一步解決基於不同WWW應用程序的特殊請求。各種API與其相應的WWW伺服器緊密結合，其初始開發目標伺服器的運行性能進一步發掘、提高。用API開發的程序比用CGI開發的程序在性能上提高了很多，但開發API程序比開發CGI程序要復雜得多。API應用程序需要一些編程方面的專門知識，如多線程、進程同步、直接協議編程以及錯誤處理等。目前主要的WWWAPI有Microsoft公司的ISAPI、Netscape公司的NSAPI和OReily公司的WSAPI等。使用ISPAI開發的程序性能要優於用CGI開發的程序，這主要是因為ISAPI應用程序是一些與WWW伺服器軟體處於同一地址空間的DLL，因此所有的HTTP伺服器進程能夠直接利用各種資源這顯然比調用不在同一地址空間的CGI程序語句要佔用更少的系統時間。而NSAPI同ISAPI一樣，給WWW開發人員定製了NetscapeWWW伺服器基本服務的功能。開發人員利用NSAPI可以開發與WWW伺服器的介面，以及與資料庫伺服器等外部資源的介面。 雖然基於伺服器擴展API的結構可以方便、靈活地實現各種功能，連接所有支持32位ODBC的資料庫系統，但這種結構的缺陷也是明顯的：①各種API之間兼容性很差，缺乏統一的標准來管理這些介面；②開發API應用程序也要比開發CGI應用復雜得多； ③這些API只能工作在專用Web伺服器和操作系統上。 （三）、基於JDBC的Web資料庫技術 Java的推出，使WWW頁面有了活力和動感。Internet用戶可以從WWW伺服器上下載Java小程序到本地瀏覽器運行。這些下載的小程序就像本地程序一樣，可獨立地訪問本地和其他伺服器資源。而最初的Java語言並沒有資料庫訪問的功能，隨著應用的深入，要求Java提供資料庫訪問功能的呼聲越來越高。為了防止出現對Java在資料庫訪問方面各不相同的擴展，JavaSoft公司指定了JDBC，作為Java語言的資料庫訪問API。 採用JDBC技術，在JavaApplet中訪問資料庫的優點在於：直接訪問資料庫，不再需要Web資料庫的介入，從而避開了CGI方法的一些局限性；用戶訪問控制可以由資料庫伺服器本地的安全機制來解決，提高了安全性；JDBC是支持基本SQL功能的一個通用低層的應用程序介面，在不同的資料庫功能的層次上提供了一個統一的用戶界面，為跨平台跨資料庫系統進行直接的Web訪問提供了方案。從而克服了API方法一些缺陷；同時，可以方便地實現與用戶地交互，提供豐富的圖形功能和聲音、視頻等多媒體信息功能。 JDBC是用於執行SQL語句的Java應用程序介面API，由Java語言編寫的類和介面組成。Java是一種面向對象、多線程與平台無關的編程語言，具有極強的可移植性、安全性和強健性。JDBC是一種規范，能為開發者提供標準的資料庫訪問類和介面，能夠方便地向任何關系資料庫發送SQL語句，同時JDBC是一個支持基本SQL功能的低層應用程序介面，但實際上也支持高層的資料庫訪問工具及API。所有這些工作都建立在X/Open SQL CLI基礎上。JDBC的主要任務是定義一個自然的Java介面來與X/OpenCLI中定義的抽象層和概念連接。JDBC的兩種主要介面分別面向應用程序的開發人員的JDBC API和面向驅動程序低層的JDBC DriverAPI。JDBC完成的工作是：建立與資料庫的連接；發送SQL語句；返回數據結果給Web瀏覽器。
Ⅶ web應用的網路拓撲結構圖怎麼畫
用visio，再下思科設備visio圖標畫得快還非常漂亮。
注意可以下載visio 2013 但是必須是批量注冊版本，後面才好用工具激活。
不然就用2007版本 有綠色版本的。
Ⅷ 簡述WEB系統的架構原理
這個話題太大了。
一般來說，WEB系統，主要是指後端，前端就是各種瀏覽器了。
那麼簡單來講，只要是能與瀏覽器通過網路交互的系統，都可以算是WEB系統。最簡潔的就是用NODEJS寫一個echo,就是客戶端發什麼內容，就回什麼內容。
而在實際應用中，WEB系統的架構，一般有這么幾個部分：負載均衡、授權驗證（可選）、靜態內容服務、動態內容服務（業務邏輯）、資料庫、運維後台。
1）負載均衡是為了改善用戶體驗、充分利用伺服器資源，主要功能是將新的請求轉發到不那麼忙的伺服器進行處理。
2）授權驗證，是在對瀏覽器發起的請求進行授權校驗，如果不是合法的請求，就予以拒絕或者重定向至登錄頁面。
3）靜態內容服務，是指圖片、CSS等不會根據不同用戶而變化的靜態內容，將其直接返回給用戶。因為不需要進行邏輯判斷，性能主要取決於I/O讀寫，響應可以非常快。超大型網站，也會把一部分動態內容，例如對訪問量大的新聞頁，做靜態處理，以提升響應速度。靜態內容服務的典型是CDN。
4）動態內容服務，是根據用戶請求的不同，而進行響應的業務邏輯處理。比如對用戶數據的CRUD(增刪查改）。這是絕大多數WEB系統的核心所在，一般會調用資料庫和數據緩存。具體實現會根據業務需要而變化，也可以變得非常復雜。
5）資料庫，是數據所在，既有經典的關系型傳統資料庫系統，也有為了提升訪問性能、減輕的內存資料庫。
6）運維後台，是為了方便監控運行狀態、升級維護系統，不直接參與對外服務。
先寫這么多吧。有具體的問題了，可以再問。
Ⅸ Web開發需不需要UML，軟體工程
Web技術的發展，使得管理系統的開發更方便、功能更強大，在此系統的開發過程中，Web技術起了一個骨架式的支持作用；與此同時組件技術的發展為系統的開放性、集成性提供了便利，有效合理地引入組件技術是當前Web系統開發與發展的一個方向；通過對系統的開發進行建模，形象直觀的圖形化表示，可以顯示系統的流程與功能。選擇有效的建模方法，充分利用Web技術與組件技術，提高軟體的開發效率，提高的軟體的可靠性和可維護性，是每個軟體開發人員所關心的問題。
UML(Unified Modeling Language)是基於對象技術的標准建模語言，定義良好、易於表達、功能強大的特點使它在面向對象的分析與設計中更具優勢。在基於Web技術和組件技術的系統建模中，它完善的組件建模思想和可視化建模的優勢更利於系統開發人員理解程序流程和功能，進一步提高Web系統的開發效率以及Web組件的可重用性和可修復性。
本文將結合我們自主開發的活塞PDM系統中的項目審批流程的建模，介紹UML在基於WEB技術和組件技術的系統建模中的應用。
2、基於Web的應用系統結構
對於基於Web技術的應用系統，用戶直接面對的是客戶端瀏覽器，用戶在使用系統時，請求之後的事務邏輯處理和數據的邏輯運算由伺服器與資料庫系統共同完成，對用戶而言是完全透明的。運算後得到的結果再通過瀏覽器的方式返回給用戶。這個過程可分成一些子步驟，每一個子步驟的完成可理解為通過一個單獨的應用伺服器來處理，這些應用伺服器在最終得到用戶所需的結論之前，相互之間還會進行一定的數據交流和傳遞。圖1就是Web的應用結構簡圖。
隨著Web應用技術的發展，對Web數據流程的解釋上還會有相應的改進或補充。
3、Web應用系統的UML建模方法
頁面、腳本、表單和框架是Web應用系統的關鍵部分，數據流程的模型化表示關鍵就是用UML對上述Web元素應用及其關系建模，下面對這幾種元素的模型化表示作一個簡要介紹。
(1)頁面建模。用戶在使用Web應用系統時，是通過頁面進行系統的操作。在頁面建模中可用兩個類別模板《Client Page》和《Sever Page》分別表示客戶端頁面和伺服器端頁面。客戶端頁面的屬性是頁的作用域中定義的變數，方法是頁面腳本中的函數；伺服器頁面的屬性是頁面腳本中的變數，方法是腳本中定義的函數。在使用頁面信息傳遞時，還可能出現伺服器頁面的重定向，在UML建模中，用類別模板《redirect》來表示；對於客戶端頁面和伺服器頁面的構造關聯用類別模板《bulid》表示，這種關聯是一種單向關聯，由伺服器頁面指向客戶端頁面，具體表示如圖2所示。
在Web應用系統中，還會經常用到的就是超級鏈接，在UML建模中，用類別模板《link》表示超級鏈接，它的參數模擬為鏈接屬性。
(2)表單建模。用戶的要求一般通過表單與資料庫交互。在UML建模中，表單用類別模板《form》表示，屬性是表單中的域，表單沒有方法。表單在處理請求時，要與Web頁面交流數據，這個交流過程是用提交按鈕submit來完成，為了在建模中表示這種關系，用類別模板《submit》表示。
(3)組件建模。在使用組件技術的Web應用系統建模中，對組件的建模是個重要環節，在UML基本的圖形化建模元素中，設立了專門的組件圖。組件在使用過程中，同樣的分成了客戶端組件(如Java Applet,ActiveX控制項)和伺服器端組件。在系統的UML模型化表示中，用類別模板《Client Component》表示客戶端組件，用《Sever Component》表示伺服器端組件。
(4)框架建模。框架通過定義類別模板元素《frameset》來實現，frameset指定並命名各個框架，每個框架容納一個頁面；框架的使用還涉及到目標target，建模時用《target》來表示。
4、UML在活塞PDM系統建模中的運用
活塞PDM系統是在傳統PDM系統的基礎上，引入了組件技術和Web技術，對數據流程的處理更趨於簡易性和方便性。在對該系統的建模過程中，要體現整個系統前台與後台間數據交互的流程。在設計時，主要是考慮設計它的class diagram(類圖)和component diagram(組件圖),用這兩類模型圖來體現UML的用例驅動和系統組件結構的特性。由於在系統的開發中採用了模塊化的設計方法，因此在構劃模型圖時，採用了先整體後局部的思路，首先考慮整個系統的案例圖，再對子模塊進行分析和設計，在每個子模塊數據流的入口和出口設置模型圖間數據交互的介面。下面以活塞PDM系統中項目審批流程子模塊的建模為例說明UML在此系統建模中的應用。
4.1 項目審批流程
項目審批是項目管理流程的一部分，功能就是實現審批過程和數據傳遞的自動進行，取消了傳統審批流程中大量紙質文件的使用。下面以活塞新產品開發的項目審批為例來說明UML對項目審批流程的建模方法。
活塞新產品開發的項目審批過程有7個環節組成，分別是項目申請、組織評審、制定實施方案、技術委員會及專家委員會評審、技術副總審核、總經理審核和董事會審核。通過這七個環節來決定一個項目實施的可行性或者合理性。
審批過程自動化的實現方法，是在Web技術和組件技術的基礎上，對每一個環節設置了評審狀態tag。當tag=1時，表明項目已通過該環節評審，可進入下步評審；當tag=0時，表明項目還未經過評審，或者未通過評審，需要返回去修改項目運行的可行性研究，等待再一次的評審。同時在每個環節進行評審時，還要考慮該項目是否已進入了下一級評審，如若項目已進行了下一級的評審，這時該環節的操作人員都無權再對該環節所填寫的評審意見進行編輯。也就是在對每個環節進行維護時，還要考慮下一級的評審狀態。
在建模之前，首先看一下項目審批流程圖，如圖3所示。
除了這七個審批環節，為了讓用戶及時了解交叉投入生產的項目審批或進展情況，提供了項目瀏覽功能，用戶按照管理員所授予的許可權，在許可權范圍內並且利用項目瀏覽子模塊中提供的關鍵欄位、項目評審狀態或者進展狀態進行分類檢索。
在項目評審流程的每個環節，一般設置了兩部分功能需求，即填寫該環節評審的內容、編輯該環節評審的內容。
比如總經理評審環節，它的功能設置如圖4所示。
為了實現網上審批的自動化，在整個流程的環節功能設置時，遵照了如下的規則要求：在每個環節的查看已填評審內容時，列出的項目都是正在等待進入該環節評審的項目，而不屬於這種情形的項目在此環節中是顯示不出來的；同樣，對於在編輯此環節評審內容上，已經進行了下一級評審的項目也是不可能列出的，每個環節的負責人只可以對此環節以前的評審內容具有瀏覽功能，而不具備編輯功能。如果要查看整個項目的評審狀況，在管理員授予項目瀏覽功能的許可權下，通過項目瀏覽一項完成。
整個流程所包括的各個環節，在功能設置上是類似的，差異是評審環節在整個評審流程中所處的位置。在進行UML建模時採用了把這些環節分開的方法，先對每個環節建模，最後再把單個的環節模型圖整合成一個完整流程的模型圖。由於篇幅所限，下面以總經理評審的環節為例說明UML的建模方法。
4.2 總經理評審的類圖(Class Diagram)
在項目審批流程中，設計了總經理審核環節的Class Diagram，如圖（5）、圖（6）、圖(7)所示。圖(6)和圖(7)是圖(5)的延續。該類圖顯示了總經理審核環節中各個頁面之間的關系。為簡化，在此類圖中沒有列出各個類的屬性和方法。整個類圖實現了查看已填寫評審內容、填寫總經理評審內容和編輯評審內容。
4.3 總經理評審的組件圖(Component Diagram)
組件圖是分析該環節所涉及的功能是如何實現的，這部分與具體的編碼工作相關。總經理評審環節的模塊組件圖如圖（8）所示。
4.4 由模型圖到代碼的轉換
類圖和組件圖說明了在基於Web技術的信息交互流程，頁面的超級鏈接和頁間的重新導向在JSP代碼設計中，由模型圖就可以掌握它們之間交互的邏輯，這樣使程序編寫更富條理性和方便性。在實際工作中，可以設置為CRC卡，方便編程人員的使用。如若再比較詳細地設計出對象圖和順序圖，對於整個系統的類定義和方法設置，會提供更大的方便。
5、結束語
建模對系統的開發過程中起著很重要的作用，在系統的開發和維護中有必要建立系統的模型。UML是一種圖示化的面向對象建模語言，它形象直觀、應用廣泛，並對Web技術和組件技術在系統開發中的建模方法有了比較合理有效的定義。在UML提供的各種模型圖的基礎上，還可以依照所有開發技術的特點對它的表示進行擴展，在本文的建模中就是用了UML的類別模塊擴充機制，為某些模型元素添加新的語義，構造新的模型，來說明開發過程中的隱含特性。
通過利用UML建模，對基於Web的PDM系統中的項目審批流程進行了分析和設計，對整個流程的功能有了一個清晰的認識，利於開發人員對系統的開發與維護，同時可為系統的升級或者二次開發提供一個理論依據。