web介面類圖

❶ Web程序當中，介面有什麼作用怎麼實現介面

介面是個很抽象的東西，舉個例子吧，比如我生產電燈，你生產電燈的頭坐。我事先告訴你我的電燈是卡口的還是羅口的，那麼剩下來將電燈與電源連接起來我就不必關心，因為那是電燈頭坐的事情，他會實現這個介面，生產符合我的電燈的頭坐。

❷ WEB網和資料庫的主要介面方式有哪四種

不理解你所說的是什麼意思.我按照自己的意思理解一下，就是前台(Asp.net,php,jsp)等和後台資料庫(Sql server,oracle啥的)的連接
每種語言都有自己和後台資料庫的一組類庫，比如我是學.net的，連接資料庫有ado.net可以連接幾乎所有的主流資料庫，有一些比較偏的資料庫會自己提供類庫

而不同語言之間的訪問，比如我用asp.net想訪問java做的數據訪問層，現在比較通用的是通過web service,即一個與語言無關的中間層將其隔離

希望我的回答能有幫助~

❸ 基於web的坑窪跟蹤和修復系統類圖怎麼畫

1、確認網站架構圖中的關鍵要素（比如產品、技術、服務），梳理關鍵要素之間的關聯：包含、支撐、同級並列等。
2、打開億圖圖示，依次選擇「新建>軟體>程序架構圖」，新建一張空白畫布。
3、從左側符號庫選擇合適圖形拖放到畫布，億圖圖示支持圖形縮放、顏色歷握填充、線條調整等操作。
4、根據最開始的梳理，對關鍵要素（比如產品、技術、服務慶數）進行信息標譽爛首注、顏色填充等。

❹ webservice介面是什麼它有什麼作用

webService介面是一種常用的簡訊群發提交介面，使用時可以象調用一般函數一樣調用WebService的方法。

作用是：該介面主要用於客戶自身的軟體、網站或其他產品，需要將簡訊群發功能集成於軟體、網站內作為產品整體功能的一部分，在這種情況下可以使用WebService介面來提交簡訊。實現WebService介面的簡訊群發功能需要有一定的基本編程能力。如VC＋＋、Delphi、ASP等。

(4)web介面類圖擴展閱讀：

WebService介面技術支持

1、XML

可擴展的標記語言（標准通用標記語言下的一個子集）為Web Service平台中表示數據的基本格式。XML是由萬維網協會(W3C)創建，W3C制定的XML SchemaXSD定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。

2、SOAP

SOAP用於交換XML（標准通用標記語言下的一個子集）編碼信息的輕量級協議。它有三個主要方面：XML-envelope為描述信息內容和如何處理內容定義了框架，將程序對象編碼成為XML對象的規則，執行遠程過程調用(RPC)的約定。SOAP可以運行在任何其他傳輸協議上。

3、WSDL

Web Service描述語言WSDL，就用機器能閱讀的方式提供的一個正式描述文檔而基於XML（標准通用標記語言下的一個子集）的語言，用於描述Web Service及其函數、參數和返回值。

❺ web開發中所說的介面

對於新手來說，剛學習web項目開發的時候，經常容易混淆介面的具體意思，網上這方面的說明文獻也很少，正確的理解介面的意思，對於一個開發者來說很重要。介面到底是什麼。今天我來談一下我個人的感受,歡迎大家指正。
首先，我想換一個角度來理解一下，所謂介面其實就是獲取資源的一個途徑，通過這個介面也就是這個途徑可以獲得資源中的東西。對應於開發中，我們可以將實現某種功能的已經封裝好的類模塊或者函數模塊看做資源，那麼視圖函數的路徑url就可以看作介面，通過這個介面可以訪問對應的視冊彎圖函數，調用相應的功能。當然url中所包含的內容就是我們混淆概念的一個原因。
url即路由地址，也就可州讓悶以理解網址，具體包含的內容，無外乎：https協議，域名，再加上請求方式，以及拼接的具體內容。post,get等為請求方式。在開發中，分配的介面的任務，這里的介面可以理解為廣義滑啟的介面。這里的介麵包括我們常說的url，還有它所對應的視圖函數模塊，以及與前端交互的相應數據的傳遞。

❻ java開發webservice介面有幾種方式

Support for Standards
JSR Support

JAX-WS - Java API for XML-Based Web Services (JAX-WS) 2.0 - JSR-224
Web Services Metadata for the Java Platform - JSR-181
JAX-RS - The Java API for RESTful Web Services - JSR-311
SAAJ - SOAP with Attachments API for Java (SAAJ) - JSR-67

WS-* and related Specifications Support

Basic support: WS-I Basic Profile 1.1
Quality of Service: WS-Reliable Messaging
Metadata: WS-Policy, WSDL 1.1 - Web Service Definition Language
Communication Security: WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust (partial support)
Messaging Support: WS-Addressing, SOAP 1.1, SOAP 1.2, Message Transmission Optimization Mechanism (MTOM)

Multiple Transports, Protocol Bindings, Data Bindings, and Formats

Transports: HTTP, Servlet, JMS, In-VM and many others via the Camel transport for CXF such as SMTP/POP3, TCP and Jabber
Protocol Bindings: SOAP, REST/HTTP, pure XML
Data bindings: JAXB 2.x, Aegis, Apache XMLBeans, Service Data Objects (SDO), JiBX
Formats: XML Textual, JSON, FastInfoset
Extensibility API allows additional bindings for CXF, enabling additional message format support such as CORBA/IIOP

http://cxf.apache.org

❼ 使用PowerDesigner 9.5創建Web服務

Web服務允許您以標准格式提供現有的或新增的功能 並且允許用戶和應用程序從任何位置訪問它們

PowerDesigner 同時針對Microsoft NET和Java引入了完善的Web服務設計和生成機制 使用PowerDesigner 您可以專注於Web服務的設計 而將所有必需的生成 實現構造的任務交給PowerDesigner完成

一 Web服務概述 Web服務是一種介面 它描述了在網路上可通過SOAP消息進行訪問的操作集合

Web 服務的介面和部署位置(可選)由WSDL說明 WSDL是一種聲明數據類型 消息 埠類型和埠(可選)的XML文檔 通過WSDL 用戶可以知道應該發送哪種格式的SOAP消息來調用Web服務以及返回消息的格式為何

為了能使用戶查找到所需的Web服務 服務提供者可能會在UDDI注冊服務中發布WSDL文檔 這樣 用戶就可以使用UDDI注冊服務來搜索Web服務

若要調用Web服務 用戶可以向部署Web服務時所在的訪問點URL發送SOAP消息 或者使用可簡化此調用過程的代理類 SOAP消息也是XML文檔

二 PowerDesigner的Web服務功能 PowerDesigner 允許您新建Web服務組件 通過對WSDL進行反向工程來創建Web服務組件 瀏覽UDDI 搜索WSDL 從Web服務組件的定義生成WSDL 生成 NET(C#和VB NET)的伺服器端代碼 生成 NET的客戶端代理 生成Java(JAX RPC和JAXM)的伺服器端代碼以及生成Java的客戶端代理

為了設計Web服務組件 PowerDesigner使用了UML類圖 組件圖和部署圖 Web服務由組件圖的組件表示 而已部署的Web服務則由部署圖的組件實例來表示

三 創建Web服務組件 創建Web服務組件有五個步驟 首先是要創建面向對象模型(OOM) 您可以選用以下語言中的任一種 C# Visual Basic NET或Java 在此模型上會自動附加用於WSDL的擴展模型定義(XEM) XEM定義了WSDL的生成模板和擴展屬性

第二步是創建類 最好是先創建一個程序組(Package) 然後再在此程序組下創建類

第三步是使用Web服務向導將創建的類轉換成Web服務組件 為此您可以右鍵單擊該類 然後選擇 創建Web服務組件 命令 或在選中該類後選擇 工具>創建Web服務組件 命令 圖 顯示了一個Web服務向導的示例 Web服務類型可以是介面或實現 如果選擇 介面 則表明您只希望定義此Web組件並生成相應的WSDL 對於 NET 此組件類型為 標准 其Web服務將通過 a *** x文件來實現 對於Java 此組件類型可能是 標准 服務程序 或 無狀態會話 Bean 這幾種Java組件類型的實現方法分別是 標准 類型使用JAX RPC 服務程序 類型使用JAXM 而 無狀態會話 Bean 類型將使用J EE(JSR )Web服務規范 當向導結束時會創建一個組件和類 圖 顯示了組件圖中的組件符號示例

圖 Web 服務向導

圖 組件符號

第四步是添加Web方法 您需要新建一個操作(Operation) 打開該操作的屬性頁 單擊 Web 方法 復選框 定義參數和返回類型以及編寫該操作的實現代碼 圖 顯示了Web方法GetStockQuote的實現示例

圖 Web方法GetStockQuote的實現示例

最後一步是對WSDL生成進行自定義 可以自定義參數和返回值的WSDL數據類型 操作的擴展屬性以及組件的屬性和擴展屬性 若要檢驗生成的WSDL 您可以打開組件屬性頁的WSDL選項卡 生成WSDL的任務可以交給PowerDesigner完成 也可以由您自行定義(用戶定義) 如果Web服務組件來源於對WSDL的反向工程 原始的WSDL將得到保留 圖 顯示了一個生成的WSDL的示例

圖 生成的WSDL的示例

您可以在類屬性頁的 預覽 選項卡中預覽生成的實現代碼 您可以使用部署圖 節點和組件實例來仿建已經部署的Web服務組件 此外 還可以在 節點 中定義伺服器的URL以及在 組件實例 中定義服務的URL

四 對WSDL進行反向工程 WSDL可以僅定義Web服務介面 也可以同時定義介面和訪問點的URL Web服務介面可能被多個服務提供者用來提供相同的服務 當然 這些服務會具有不同的實現和訪問點 如果擁有WSDL文檔的文件路徑或URL 您就可以通過對它進行反向工程來創建Web服務組件 之後可以定義自己的實現方法或將創建的Web服務組件保存在庫中供以後再次使用 您在查找感興趣的WSDL時 可以使用UDDI瀏覽器在UDDI注冊服務中進行搜索

為了對WSDL進行反向工程 需要用C# VB NET或Java中的任意一種語言創建OOM 然後選擇 語言>導入 WSDL 命令並輸入WSDL文件的路徑或URL 進行反向工程之後 會在組件圖中創建一個組件 同時在類圖中創建一個類 所創建的類將僅包含該Web服務的操作信號 若想實現該Web服務 還需要定義這些操作的實現代碼

在UDDI注冊服務中搜索WSDL 如果希望搜索在UDDI注冊服務中注冊的WSDL 請打開 導入WSDL 窗口 然後單擊 瀏覽UDDI 按鈕 通過 瀏覽 UDDI 窗口(見圖 ) 您可以選擇UDDI運營商 搜索條件和搜索類型 並可以按實體名稱 服務名稱或WSDL名稱進行搜索 此外 您還可以預覽找到的WSDL

圖 瀏覽UDDI 窗口

五 生成 NET類型的Web服務 對於 NET伺服器端代碼 PowerDesigner會生成一個 a *** x文件 這種Web服務的實現類可以在上述的 a *** x文件中生成 也可以在外部生成 此實現類所使用的語言可以是C#或者VB NET 在類屬性頁的 預覽 選項卡中 可以預覽 a *** x文件和相應的實現類代碼 圖 顯示了C#語言的 a *** x文件示例

圖 C#語言的 a *** x文件示例

PowerDesigner還可以生成客戶端代理類來簡化Web服務的調用 為生成客戶端代理類 PowerDesigner使用了Visual Studio NET附帶的wsdl exe程序

若要生成WSDL 伺服器端代碼和/或客戶端代理 請選擇 語言>生成C#代碼 或 語言>生成VB NET代碼 命令 如果要生成客戶端代理 可以在 任務 選項卡中選擇 生成Web服務客戶端代理 選項 圖 顯示了可用的生成任務 如果這個類不是在 a *** x文件內部生成的 您將可以對這些C#代碼或VB NET代碼進行編譯 不過 在編譯C#或VB NET文件時 您必須定義CSC或VBC變數來指示csc exe或vbc exe命令的位置

在部署Web服務時 只需要將IIS目錄下的 a *** x文件和相應的類文件進行復制 C:Inetpub oot<程序組名> 其中 <程序組名> 是程序組的名稱 要測試此Web服務 可以在瀏覽器中輸入以下URL //<主機名>/<程序組名>/<服務名> a *** x

圖 Web服務的生成任務

六 生成Java類型的Web服務 如果Web服務的實現類型為 標准 PowerDesigner將使用JAX RP 來實現 如果實現類型為 服務程序 PowerDesigner將使用JAXM來實現 如果實現類型為 無狀態會話Bean 則PowerDesigner將使用J EE(JSR )Web服務規范來實現 JSR 尚未正式頒布

JAX RPC定義了RPC類型的Web服務調用 雖然它易於開發和使用 但為了避免復雜的對象/XML映射 它只能局限於簡單的消息格式 而基於JAXM的Web服務組件顯然更具優越性 它允許您靈活地處理復雜的消息結構

若要使用JAX RPC或JAXM 您需要安裝Java Web Services Developer Pack(JWSDP) 此程序包可從Sun公司的網站下載 在部署JAX RPC或JAXM類型的Web服務組件時 需要有支持JAX RPC或JAXM的伺服器 支持JAX RPC或JAXM的Apache Tomcat附帶提供了JWSDP

至於基於JAX RPC的Web服務組件 您只需實現其Web方法的代碼 若要生成WSDL 伺服器端代碼和/或客戶端代理 可選擇 語言>生成Java代碼 然後選擇 使用XRPCC工具生成WSDL(伺服器端) 和/或 使用XRPCC工具生成Web服務的代理代碼 命令(見圖 ) XRPCC命令是JWSDP的一個工具 它可以生成JAX RPC類型的伺服器端代碼或客戶端代理 在部署生成的Web服務時 需要創建一個包含所有生成文件的 WAR文件 並將此 WAR文件部署在支持JAX RPC的伺服器上 比如說Apache Tomcat

圖 JAX RPC生成任務

對基於JAXM的Web服務組件而言 您需要實現其onMessage操作 onMessage操作將按照在WSDL中的指示 接收並處理輸入的SOAP消息並構建返回消息 以及將此消息返回 要生成WSDL和JAXM類型的Web服務 請選擇 語言>生成Java代碼 命令 然後選擇 構建Web組件 創建Web應用程序WAR 命令(見圖 ) 該命令會對JAXM服務程序代碼進行編譯並創建WAR文件 要部署此JAXM服務程序 您可以將上述WAR文件部署在支持JAXM的伺服器上 比如說Apache Tomcat

圖 JAXM生成任務

至於基於無狀態會話Bean的Web服務組件 由於JSR 規范尚未正式頒布 因此目前還不能使用

七 下一步要增強的功能 J EE(JSR )Web服務規范不久將面世 供人們使用 通過它 您可以將無狀態會話Bean用作Web服務實現的利器 它可以讓現有功能以Web服務的新面目出現 同時也可以新建Web服務 PowerDesigner 附帶提供了基於早期JSR 規范的版本 該版本尚待進一步的認證 等該規范正式頒布後 我們將提供維護版本以實現對它的完全支持

PowerDesigner的新版本還將支持Web服務的綜合標准

lishixin/Article/program/SQL/201311/16374

❽ 一個WEB項目有多少介面

一個WEB項目四個多少介面。
1、列印伺服器的Web介面，列印伺服器是Windows Server 2003伺服器中的一種。
2、終端伺服器的Web介面終端伺服器是一種可以讓有許可權的遠程網路用戶。
3、流媒體伺服器的Web介面。
4、遠程維護Web介面遠程維護功能是一項非常重要的功能。

❾ App 和 Web 的通用介面該怎麼設計

1、在介面定義中確定MVC的GET或者POST方式
由於我們整個Web API平台是基於MVC的基礎上進行的API開發，因此整個Web API的介面，在定義的時候，一般需要顯示來聲明介面是[HttpGet]或者[HttpPost]，雖然有些介面也可以不用聲明，但是避免出現類似下面的錯誤信息，顯式聲明還是有好處的。
請求的資源不支持 http 方法「POST

例如在基類定義的查找對象介面如下所示。

/// <summary>
/// 查詢資料庫,檢查是否存在指定ID的對象
/// </summary>
/// <param name="id">對象的ID值</param>
/// <returns>存在則返回指定的對象,否則返回Null</returns>
[HttpGet]
public virtual T FindByID(string id, string token)

如果是增刪改的介面，一般需要聲明為POST方式提交數據，而且基於安全性的考慮，需要攜帶更多的參數。

/// <summary>
/// 插入指定對象到資料庫中
/// </summary>
/// <param name="info">指定的對象</param>
/// <returns>執行操作是否成功。</returns>
[HttpPost]
public virtual CommonResult Insert(T info, string token, string signature, string timestamp, string nonce, string appid)

2、動態對象的介面定義
在一般的Web API介面裡面，我們可能都會碰到很多簡單類型的參數，但是又想讓它們以POST方式提交數據，那麼我們就可以有兩種方法來處理，一種是定義一個類來放置這些參數，一種是採用動態的JObject參數，前者有很多不方便的地方，因為我們不可能為每個介面參數定義多一個實體類，這樣可能會有很多難以管理的類定義。如下面是微信API的調用介面案例，我們也需要設置這樣的處理規則。
介面調用請求說明
http請求方式: POST（請使用https協議）
https://api.weixin.qq.com/cgi-bin/groups/update?access_token=ACCESS_TOKEN
POST數據格式：json
POST數據例子：{"group":{"id":108,"name":"test2_modify2"}}

那麼我們採用JObject是這么樣的呢，我們來看介面的定義和處理代碼。JObject是Newtonsoft.Json.Linq命名空間下的一個對象。

/// <summary>
/// 修改用戶密碼
/// </summary>
/// <param name="param">包含userName和userPassword的復合對象</param>
/// <param name="token">用戶訪問令牌</param>
/// <returns></returns>
[HttpPost]
public CommonResult ModifyPassword(JObject param, string token)
{
//令牌檢查,不通過則拋出異常
CheckResult checkResult = CheckToken(token);
dynamic obj = param;
if (obj != null)
{
string userName = obj.userName;
string userPassword = obj.userPassword;

bool success = BLLFactory<User>.Instance.ModifyPassword(userName, userPassword);
return new CommonResult(success);
}
else
{
throw new MyApiException("傳遞參數出現錯誤");
}
}

其中我們把JObject對象轉換為我們所需要的對象的時候，因為我們沒有定義具體的實體類，因此採用了dynamic語法，聲明這是一個動態對象，由運行時獲取對應的屬性。
dynamic obj = param;

這樣我們就可以在調用的時候，動態POST對應的JSON對象給Web API介面，而不需要預先定義各種介面參數的類了。

/// <summary>
/// 調用Web API介面，修改用戶密碼
/// </summary>
/// <param name="userName">用戶名稱</param>
/// <param name="userPassword">修改的密碼</param>
/// <returns>如果修改成功返回true，否則返回false</returns>
public bool ModifyPassword(string userName, string userPassword)
{
var action = "ModifyPassword";
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();

string url = GetTokenUrl(action);

CommonResult result = JsonHelper<CommonResult>.ConvertJson(url, postData);
return (result != null) ? result.Success : false;
}

其中GetTokenUrl是根據token和API的地址等參數，構建一個完整的提交地址。我們在上面代碼通過
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();

就可以動態創建一個對象，並生成它的JSON字元串，把數據POST提交到對應的API介面裡面即可，然後對結果進行對象的轉換就算完成了。

3、集合和分頁的處理
在很多介面裡面，我們都需要用到分頁的處理，Web API也不例外，這樣可以提交數據檢索效率，減少伺服器數據處理的壓力，同時也提交客戶端的數據顯示速度。
一般的集合介面定義如下所示（通用性基類介面）。

/// <summary>
/// 返回資料庫所有的對象集合
/// </summary>
/// <returns>指定對象的集合</returns>
[HttpGet]
public virtual List<T> GetAll(string token)
{
//檢查用戶是否有許可權，否則拋出MyDenyAccessException異常
base.CheckAuthorized(AuthorizeKey.ListKey, token);

List<T> list = baseBLL.GetAll();
return list;
}

但是這樣的返回記錄會比較多，一般情況下需要分頁，那麼分頁的處理介面定義如下所示。

/// <summary>
/// 根據條件查詢資料庫,並返回對象集合(用於分頁數據顯示)
/// </summary>
/// <returns>指定對象的集合</returns>
[HttpPost]
public virtual PagedList<T> FindWithPager(string condition, PagerInfo pagerInfo, string token)

分頁介面，在這里返回的結果裡面，用了一個PageList的泛型類，這個方便我們獲取當前的記錄及總數，它的定義如下所示。

/// <summary>
/// 分頁集合
/// </summary>
/// <typeparam name="T">對象</typeparam>
public class PagedList<T>
{
/// <summary>
/// 返回記錄的總數
/// </summary>
public int total_count { get; set; }

/// <summary>
/// 列表集合
/// </summary>
public List<T> list { get; set; }
}

最後整個分頁的處理Web API介面實現如下所示。

/// <summary>
/// 根據條件查詢資料庫,並返回對象集合(用於分頁數據顯示)
/// </summary>
/// <returns>指定對象的集合</returns>
[HttpPost]
public virtual PagedList<T> FindWithPager(string condition, PagerInfo pagerInfo, string token)
{
//檢查用戶是否有許可權，否則拋出MyDenyAccessException異常
base.CheckAuthorized(AuthorizeKey.ListKey, token);

List<T> list = baseBLL.FindWithPager(condition, pagerInfo);

//構造成Json的格式傳遞
var result = new PagedList<T>() { total_count = pagerInfo.RecordCount, list = list };
return result;
}

最後客戶端調用分頁的Web API代碼如下所示。

/// <summary>
/// 根據條件查詢資料庫,並返回對象集合(用於分頁數據顯示)
/// </summary>
/// <param name="condition">查詢的條件</param>
/// <param name="pagerInfo">分頁實體</param>
/// <returns>指定對象的集合</returns>
public virtual List<T> FindWithPager(string condition, ref PagerInfo pagerInfo)
{
var action = "FindWithPager";
string url = GetTokenUrl(action) + string.Format("&condition={0}", condition);
var postData = pagerInfo.ToJson();

List<T> result = new List<T>();
PagedList<T> list = JsonHelper<PagedList<T>>.ConvertJson(url, postData);
if (list != null)
{
pagerInfo.RecordCount = list.total_count;//修改總記錄數
result = list.list;
}
return result;
}

4、混合框架界面整合Web API介面
在整個Web API的平台構建以及在混合框架的整合過程中，我把各個模塊還是遵循相對獨立的方式進行開發和整合，它們實現了從直接訪問資料庫、以WCF服務獲取數據，以及通過WebAPI調用方式獲取數據幾種方式的統一，從而實現了整個混合框架的高度整合。

整個混合框架的核心是以相對獨立的方式，整合各個可重用的模塊，我們可以遵循一定的基礎上，快速構建統一的應用平台。

搭建完畢的整個WebAPI平台，其中包括了服務端內容，以API控制器的方式，發布了對應的Web API介面。

在每個混合框架的獨立模塊裡面，我們封裝了對應的Web API客戶端調用處理，從而實現了Web API的調用方式。

在Win10下，使用Web API模式運行混合框架，獲得的主體界面效果如下所示。

獨立模塊許可權管理系統界面如下所示。

系列文章如下所示：
Web API應用架構在Winform混合框架中的應用（1）
Web API應用架構在Winform混合框架中的應用（2）--自定義異常結果的處理
Web API介面設計經驗總結
Web API應用架構在Winform混合框架中的應用（3）--Winfrom界面調用WebAPI的過程分解
Web API應用架構在Winform混合框架中的應用（4）--利用代碼生成工具快速開發整套應用
Web API應用架構在Winform混合框架中的應用（5）--系統級別字典和公司級別字典並存的處理方式

❿ 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系統中的項目審批流程進行了分析和設計，對整個流程的功能有了一個清晰的認識，利於開發人員對系統的開發與維護，同時可為系統的升級或者二次開發提供一個理論依據。