網(wǎng)購物系統(tǒng)uml的分析與設(shè)計(jì)(定稿)

PAGEPAGE21網(wǎng)絡(luò)購物系統(tǒng)的UML分析與設(shè)計(jì)摘要：論文簡單的描述了UML的基本概念和發(fā)展歷史，并且分析了目前運(yùn)用UML存在的一些問題，通過在實(shí)際的設(shè)計(jì)開發(fā)中，運(yùn)用UML對網(wǎng)絡(luò)購物系統(tǒng)的開發(fā)例子來闡述UML的一些實(shí)現(xiàn)原理。關(guān)鍵詞：UML系統(tǒng)分析面向?qū)ο笤O(shè)計(jì)1.UML簡介和背景：UML是有世界著名的面向?qū)ο蠹夹g(shù)專家G.BOOCH，J.RUMBAUGH，和I.JACOBSON發(fā)起，在BOOCH方法，OMT方法和OOSE方法的基礎(chǔ)上，汲取其他面向?qū)ο蠓椒ǖ膬?yōu)點(diǎn)，廣泛征求意見，幾經(jīng)修改而完成的。目前UML得到了諸多大公司的支持，已經(jīng)成為面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言。目前最新的UML規(guī)范說明是2003年3月發(fā)布的1.5版本。OMG在同時(shí)進(jìn)行兩個(gè)UML版本的工作，一個(gè)是對1.X版本的改進(jìn)工作，一個(gè)是有較大改動(dòng)的版本2.0的工作。OMG從2001年開始UML2.0的工作，由于UML2.0是一個(gè)比較大的升級工作，其發(fā)布時(shí)間也一再的推遲。經(jīng)過對2.0版本草案的多次征求意見和修改，2003年8月，OMG發(fā)布了最后的征求意見版本。正式的版本將很快發(fā)布。在UML建模語言成為標(biāo)準(zhǔn)之前，有很多的OO方法，每種方法都說自己是最好的，出現(xiàn)了所謂的方法學(xué)大戰(zhàn)。隨著UML被OMG采納為標(biāo)準(zhǔn)，面向?qū)ο箢I(lǐng)域的方法學(xué)大戰(zhàn)也隨之結(jié)束。UML在學(xué)術(shù)界和工業(yè)界越來越受到重視。2.目前運(yùn)用UML存在的一些問題：自從OMG提出UML以來,隨著它的不斷完善發(fā)展,UML逐漸被很多企業(yè)接受認(rèn)可,在很短的時(shí)間內(nèi)，UML已經(jīng)成為軟件工業(yè)中占支配地位的建模語言。但目前在國內(nèi)外UML的運(yùn)用情況卻不是很好。2002年6月底,BZ公司對226個(gè)個(gè)體進(jìn)行了調(diào)查,結(jié)果是有34%的開發(fā)人員運(yùn)用UML進(jìn)行系統(tǒng)開發(fā)的建模,62%的開發(fā)人員不用UML進(jìn)行開發(fā),4%的開發(fā)人員不太確定[1].究其原因是UML1.4還存在以下幾個(gè)方面的不足:1目前UML很多地方運(yùn)用難以解釋的字符來描述系統(tǒng)的功能、系統(tǒng)的行為和計(jì)算,不易于理解。并且沒有對數(shù)據(jù)操作進(jìn)行定義,很多對象之間的行為過程沒有加以說明，如：對象之間關(guān)系的操作（relationshipmanipulation），這些都迫切需要一個(gè)標(biāo)準(zhǔn)化的行為描述語言(ActionSpecificationLanguage)來對系統(tǒng)的行為進(jìn)行精確的描述。2UML雖然是一種面向?qū)ο蟮能浖到y(tǒng)設(shè)計(jì)的標(biāo)準(zhǔn)描述語言，但是在其狀態(tài)圖中用狀態(tài)和遷移表示對象行為關(guān)聯(lián)時(shí)用到了大量的不易于理解的注釋字符，因此，系統(tǒng)的UML模型既不是可以執(zhí)行的也是不和用編程語言開發(fā)的可執(zhí)行程序相協(xié)調(diào)。3在不同的技術(shù)實(shí)現(xiàn)平臺(tái)上（如：實(shí)現(xiàn)語言，軟件環(huán)境）對同樣需求的系統(tǒng)建模時(shí)細(xì)節(jié)差別很大，系統(tǒng)構(gòu)建模型的重用性就很低。這樣在計(jì)算機(jī)技術(shù)正在向各個(gè)方向快速發(fā)展的今天，老的遺留系統(tǒng)必須和新技術(shù)的實(shí)施平臺(tái)，開發(fā)技術(shù)相協(xié)調(diào)，使得新舊系統(tǒng)之間的集成或系統(tǒng)的演化面臨不同的實(shí)現(xiàn)技術(shù)，老的遺留系統(tǒng)在運(yùn)用新技術(shù)進(jìn)行重構(gòu)時(shí)，必然要浪費(fèi)很多財(cái)力，人力進(jìn)行系統(tǒng)模型的更新甚至完全重建系統(tǒng)。3.網(wǎng)絡(luò)購物系統(tǒng)的分析：3.1網(wǎng)絡(luò)購物系統(tǒng)的需求分析：1：普通用戶可以登陸系統(tǒng)，成為登陸后用戶。2：普通用戶只具有搜索產(chǎn)品、查看產(chǎn)品分類、查看產(chǎn)品項(xiàng)目、查看產(chǎn)品等幾個(gè)基本權(quán)限。3：除提供一般權(quán)限外，本系統(tǒng)還可為登陸后用戶提供編輯帳號(hào)、購物車、定單、結(jié)算的功能和服務(wù)。4：登陸后用戶可修改購物數(shù)量。3.2用例分析：確定參與者：1誰使用系統(tǒng)的主要功能？2誰需要從系統(tǒng)獲得對日常工作的支持和服務(wù)？3需要誰維護(hù)管理系統(tǒng)的日常運(yùn)行？4公司的哪個(gè)部門使用系統(tǒng)？5系統(tǒng)需要與其它哪些系統(tǒng)交互？6誰需要使用系統(tǒng)產(chǎn)生的結(jié)果？針對網(wǎng)上購物系統(tǒng)的前臺(tái)系統(tǒng)，通過回答以上問題，可以得到執(zhí)行者有三類，顧客，管理員和一般員工。確定用例:1系統(tǒng)需要哪些輸入/輸出？這些輸入/輸出從何而來？到哪里去？2執(zhí)行者是否需要對系統(tǒng)中的信息進(jìn)行讀、創(chuàng)建、修改、刪除或存儲(chǔ)？創(chuàng)建用例（1）訂單處理（2）訂單維護(hù)（3）訂單狀態(tài)查詢（4）個(gè)人信息維護(hù)（5）訂購（6）接收發(fā)貨（7）庫存查詢（8）缺貨拒絕（9）商品查詢（10）商品信息維護(hù)（11）銷售查詢（12）員工信息維護(hù)（13）報(bào)表維護(hù)（14）訂單增加（15）訂單刪除創(chuàng)建用例圖系統(tǒng)管理的用例圖如下圖1圖1系統(tǒng)管理用例圖系統(tǒng)用戶的用例圖如下圖2所示圖2系統(tǒng)用戶的用例圖3.3類圖分析：畫類圖和理解類圖時(shí)都應(yīng)采用三個(gè)層次的觀點(diǎn)。這些觀點(diǎn)也適用于其它模型。三個(gè)層次的觀點(diǎn)不是UML的組成部分，但對建造模型或評價(jià)模型都非常有用，且都可應(yīng)用于UML.（1）概念層描述應(yīng)用域中的概念，是對現(xiàn)實(shí)世界的直接描述，與實(shí)現(xiàn)它們的類有關(guān)但與實(shí)現(xiàn)方案和實(shí)現(xiàn)語言無關(guān)。（2）說明層描述軟件的接口，而不是軟件的實(shí)現(xiàn)。一個(gè)類型描述一個(gè)接口，但可能有多種實(shí)現(xiàn)。（3）實(shí)現(xiàn)層從實(shí)現(xiàn)的角度定義類及其實(shí)現(xiàn)，揭示了軟件實(shí)現(xiàn)體的構(gòu)成情況。針對當(dāng)前系統(tǒng)1產(chǎn)品類（Product）的主要操作：設(shè)置和獲取每個(gè)屬性值的方法。2產(chǎn)品類別類（Category）的主要操作：設(shè)置和獲取每個(gè)屬性值的方法。3產(chǎn)品項(xiàng)目類（Item）的主要操作：設(shè)置和獲取每個(gè)屬性值的方法4訂單類（Order）的主要操作：設(shè)置和獲取每個(gè)屬性值的方法、初始化訂單（initOrder）、增加產(chǎn)品項(xiàng)目（addLineItem）等。5購物車類（Cart）的主要操作：設(shè)置和獲取每個(gè)屬性值的方法、增加產(chǎn)品項(xiàng)目（addItem）、刪除產(chǎn)品項(xiàng)目（removeItemById）等。6購物車項(xiàng)目類(CartItem)的主要操作：設(shè)置和獲取每個(gè)屬性值的方法、統(tǒng)計(jì)金額（calculateTotal）等。下面是系統(tǒng)的類圖，見圖3圖3網(wǎng)上購物系統(tǒng)的類圖圖3網(wǎng)上購物系統(tǒng)的類圖3.4系統(tǒng)的時(shí)序圖分析：順序圖可描述幾個(gè)對象間的動(dòng)態(tài)協(xié)作關(guān)系，它非常直觀的展示了對象之間傳遞消息的時(shí)間順序。反映了系統(tǒng)執(zhí)行過程中某個(gè)特定時(shí)刻所發(fā)生的事情。在系統(tǒng)分析時(shí)，可對主要對象類繪制順序圖，以便分析系統(tǒng)的行為，驗(yàn)證和修改系統(tǒng)的靜態(tài)結(jié)構(gòu)，滿足用戶的需求，達(dá)到系統(tǒng)的目標(biāo)。 顧客訂購的時(shí)序圖如下圖4所示：顧客首先使用自己的帳號(hào)和密碼進(jìn)行登陸系統(tǒng)，登陸模塊會(huì)將客戶的ID保存在系統(tǒng)緩存中，并提交給商品查詢模塊。商品查詢模塊提示客戶輸入查詢條件，客戶輸入適當(dāng)?shù)牟樵儣l件后，查詢模塊將顯示商品列表。客戶得到商品列表后，提交自己想要購買的商品ID，訂購模塊得到商品ID。生成訂單并提交給數(shù)據(jù)庫模塊進(jìn)行保存，保存成功后，提示用戶訂購商品成功。圖4顧客訂購時(shí)序圖客戶刪除訂單的時(shí)序圖如圖5所示客戶在提交訂單后可以對訂單進(jìn)行維護(hù)（添加，刪除，修改）?？蛻羰紫容斎胱约旱膸ぬ?hào)和密碼登陸系統(tǒng)，登陸模塊會(huì)將客戶的ID保存在系統(tǒng)緩存中，并提交給訂單查詢模塊。訂單查詢模塊會(huì)顯示當(dāng)前所有的訂單，顧客得到該列表后，選擇要?jiǎng)h除商品的ID，訂單處理模塊把刪除信息提交給數(shù)據(jù)模塊，數(shù)據(jù)模塊保存信息。訂單處理提示用戶刪除成功。圖5客戶刪除訂單的時(shí)序圖管理員處理訂單的時(shí)序圖如圖6所示管理員使用其帳號(hào)和密碼登陸后，登陸模塊會(huì)將管理員的ID保存在系統(tǒng)緩存中并提交給訂單處理模塊。訂單處理模塊提交給管理員未處理的列表，管理員提交某商品的ID得到該商品的庫存情況，如果庫存充足則接收訂單，并把接收信息提交給數(shù)據(jù)模塊，數(shù)據(jù)模塊更新改客戶的訂單信息并返回成功信息給訂單處理模塊，訂單處理模塊提示改操作成功。圖6管理員處理訂單的時(shí)序圖3.5系統(tǒng)的協(xié)作圖分析：顧客訂購協(xié)作圖如圖7所示圖7顧客訂購協(xié)作圖顧客刪除訂單的協(xié)作圖如圖8所示圖8顧客刪除訂單的協(xié)作圖管理員處理訂單協(xié)作圖如圖9所示圖9管理員處理訂單協(xié)作圖3.6系統(tǒng)的活動(dòng)圖分析：購買商品的活動(dòng)圖如圖10所示圖10購買商品的活動(dòng)圖3.7系統(tǒng)的配置圖分析：配置圖可以顯示節(jié)點(diǎn)以及它們之間的必要連接，也可以顯示這些連接的類型，還可以顯示組件和組件之間的依賴關(guān)系，但是每個(gè)組件必須存在于某些節(jié)點(diǎn)上。配置圖用于對系統(tǒng)的實(shí)現(xiàn)視圖建模。繪制這些視圖主要是為了描述系統(tǒng)中各個(gè)物理組成部分的分布、提交和安裝過程。在實(shí)際應(yīng)用中，并不是每一個(gè)軟件開發(fā)項(xiàng)目都必須繪制配置圖的。如果項(xiàng)目開發(fā)組所開發(fā)的軟件系統(tǒng)只需要運(yùn)行于一臺(tái)計(jì)算機(jī)并且只需使用此計(jì)算機(jī)上已經(jīng)由操作系統(tǒng)管理的標(biāo)準(zhǔn)設(shè)備，這種情況下就沒有必要繪制配置圖了。另一方面，如果項(xiàng)目開發(fā)組所開發(fā)的軟件系統(tǒng)需要使用操作系統(tǒng)管理以外的設(shè)備（例如數(shù)碼相機(jī)、路由器等）、或者系統(tǒng)中的設(shè)備分布在多個(gè)處理器上，這時(shí)就有必要繪制配置圖，用其來幫助開發(fā)人員理解系統(tǒng)中軟件和硬件的映射關(guān)系。下面的本系統(tǒng)的配置圖，見圖11。圖11網(wǎng)絡(luò)購物系統(tǒng)的配置圖4.系統(tǒng)采取的設(shè)計(jì)模式分析4.1系統(tǒng)中的類，如下圖12所示：圖12系統(tǒng)的類圖關(guān)于圖11有幾點(diǎn)說明如下：1.Person類是所有類的父類，它的屬性包括用于標(biāo)示不同身份人的ID，姓名和地址。它的方法包括根據(jù)ID搜索，根據(jù)姓名搜索，設(shè)置某人的姓名，地址等。2.Customer繼承了父類的方法和屬性，并添加了自己的方法和屬性。Reg_date表示改用戶注冊的日子，password表示登陸密碼，Search_goods()用于搜索商品，maintain_order()用于維護(hù)客戶訂單。3.employee繼承了person，它的屬性dateHired表示雇傭日期，right表示使用權(quán)限，salary表示該員工的薪水，password表示登陸密碼。Handle_Order()用于搜處理訂單，這是所有員工共有的操作。系統(tǒng)管理員中還增加了查詢分析和報(bào)表打印的方法。4.2系統(tǒng)中的其他類，如下圖13所示：圖13系統(tǒng)中的其他類4.3模式的使用1簡單工廠模式：簡單工廠模式又稱靜態(tài)工廠方法模式，它就是由一個(gè)工廠對象決定創(chuàng)建出哪一產(chǎn)品類的實(shí)例。簡單工廠模式的策略圖如下14所示：圖14簡單工廠的策略模式圖簡單工廠模式是由一個(gè)工廠類根據(jù)傳入的參量決定創(chuàng)建哪一類產(chǎn)品的實(shí)例。由上圖可以看出它有三個(gè)角色：工廠類：擔(dān)任這個(gè)角色的是工廠方法模式的核心，含有與應(yīng)用緊密相關(guān)的商業(yè)邏輯。工廠類在客戶端的直接調(diào)用下創(chuàng)建產(chǎn)品的對象，它往往由一個(gè)具體的java類實(shí)現(xiàn)。抽象產(chǎn)品角色：擔(dān)任這個(gè)角色的類是由工廠方法模式所創(chuàng)建的類的父類，或者他們有共同的接口。抽象產(chǎn)品可以是一個(gè)java接口或者抽象類的實(shí)現(xiàn)。具體產(chǎn)品角色：工廠方法模式所創(chuàng)建的任何對象都是這個(gè)類的實(shí)例，由一個(gè)具體的java類來實(shí)現(xiàn)。在系統(tǒng)中，我們抽象出一個(gè)員工的類，它有連個(gè)子類：一般員工和系統(tǒng)管理員。有個(gè)一個(gè)工廠類factory負(fù)責(zé)具體實(shí)例的創(chuàng)建。具體的類圖如下圖15所示：圖15系統(tǒng)中使用的簡單工廠模式2策略模式：策略模式的用意：策略模式的用意是針對一組算法，將每一個(gè)算法封裝到具有共同接口的獨(dú)立的類里面去，從而使得它們可以相互替換。它是對算法的包裝，是把使用算法的責(zé)任和算法本身分割開，委派給不同的對象管理。策略模式的結(jié)構(gòu)：策略模式的結(jié)構(gòu)圖如下圖16所示：圖16策略模式的結(jié)構(gòu)圖在這個(gè)模式里面設(shè)計(jì)到三個(gè)角色：環(huán)境角色：它持有一個(gè)抽象策略的引用抽象策略角色：這是一個(gè)抽象角色，通常由一個(gè)接口或者抽象類實(shí)現(xiàn)。此角色給出所有的具體策略類所需要的接口。具體策略角色：包裝了相關(guān)的算法和行為在系統(tǒng)中設(shè)計(jì)到多種查詢，它們大都類似，我們可以采用策略模式提高程序的靈活性和適應(yīng)性。具體的策略模式的使用見下圖17所示：圖17策略模式在系統(tǒng)中的使用3享元模式：由于只使用到單享元模式，故在這里只給單享元模式給與介紹。在單純享元模式中，所有的享元對象都是可以共享的，如下圖17所示。它涉及到如下的四種角色：客戶端：它需要一個(gè)對所有享元對象的一個(gè)引用，同時(shí)它需要自行存儲(chǔ)所有享元的外蘊(yùn)狀態(tài)享元工廠：本角色負(fù)責(zé)創(chuàng)建和管理享元角色。它必須保證享元對象可以被系統(tǒng)適當(dāng)?shù)墓蚕?。?dāng)一個(gè)客戶端對象調(diào)用一個(gè)享元對象的時(shí)候，享元工廠會(huì)檢查系統(tǒng)中是否已近有一個(gè)已符合要求的享元對象，如果有的話，享元工廠就提供這個(gè)已有的享元對象；如果沒有的話，享元工廠就創(chuàng)建一個(gè)合適的享元對象。抽象享元角色：它是所有具體享元類的超類，為它們提供一個(gè)公共接口，當(dāng)需要外蘊(yùn)狀態(tài)的操作，可以提供參數(shù)傳入。具體享元：它實(shí)現(xiàn)了抽象享元所規(guī)定的接口。如果有內(nèi)蘊(yùn)狀態(tài)的話，它必須為內(nèi)蘊(yùn)狀態(tài)提供空間，使得享元對象在系統(tǒng)內(nèi)可以共享。圖18單純享元的模式結(jié)構(gòu)圖 在系統(tǒng)中所有的用戶擁有同樣的用戶類型，因此對他們我們只需保存一個(gè)，這樣可以很大程度上節(jié)省系統(tǒng)運(yùn)行的開銷以及提高運(yùn)行的效率。享元模式在系統(tǒng)中的使用如下圖19所示：圖19享元模式在系統(tǒng)中的使用5.結(jié)束語：UML在軟件工程中的運(yùn)用是與ＯＭＧ組織提出的ＭＤＡ是相一致的，隨著它的不斷發(fā)展和完善，并且隨著OMG使UML實(shí)現(xiàn)的標(biāo)準(zhǔn)化﹑統(tǒng)一化，最終基于UML的MDA軟件開發(fā)過程將變?yōu)橐粋€(gè)更加重用，更加快速，更加有效的軟件開發(fā)方法，使軟件開發(fā)方法向更高抽象層，更加可重用發(fā)展。6.參考文獻(xiàn)：[1]面向?qū)ο蟪绦蛟O(shè)計(jì)高級教程，陳奇，高等教育出版社，2001[2]標(biāo)準(zhǔn)建模語言UML極其支持環(huán)境，周伯生，張莉等，北京：計(jì)算機(jī)世界，1998[3]UML和模式應(yīng)用——面向?qū)ο蠓治龊驮O(shè)計(jì)導(dǎo)論，CraigLarman等，姚淑珍，李虎譯，機(jī)械工業(yè)出版社，2002[4]UMLASLReferenceGuideASLLanguageLevel2.5；IanWilkie,AdrianKing,MikeClarke,ChasWeaverandChrisRastrick；[5]StephenJ.Mellor,MarcJ.Balcer,ExecutableUML:AFoundationforModel-DrivenArchitecture,,2003,科學(xué)出版社目錄TOC\o"1-2"\h\z\u第一章總論 11.1項(xiàng)目概況 11.2可行性研究報(bào)告編制單位 41.3承辦單位簡介 41.4項(xiàng)目區(qū)概況 51.5可行性研究依據(jù) 91.6可行性研究的范圍 10第二章項(xiàng)目建設(shè)背景及必要性 112.1項(xiàng)目建設(shè)背景 112.2項(xiàng)目建設(shè)必要性 14第三章項(xiàng)目建設(shè)地址及條件 173.1項(xiàng)目建設(shè)地址 173.2項(xiàng)目建設(shè)條件 17第四章工程建設(shè)方案 224.1項(xiàng)目設(shè)計(jì)依據(jù)與原則 224.2工程規(guī)劃方案 234.3工程技術(shù)方案 254.4給排水工程 304.5供電工程 314.6采暖及通風(fēng) 354.7燃?xì)庠O(shè)計(jì) 37第五章環(huán)境保護(hù) 385.1環(huán)境保護(hù)標(biāo)準(zhǔn) 385.2環(huán)境影響初步分析 385.3施工期環(huán)境保護(hù)措施 395.4運(yùn)營期間環(huán)境保護(hù)措施 415.5綠化 425.6環(huán)境影響評價(jià) 43第六章節(jié)能 446.1依據(jù)標(biāo)準(zhǔn)、法律、法規(guī)和規(guī)范 446.2能耗狀況和能耗指標(biāo)分析 446.3節(jié)能措施 45第七章勞動(dòng)安全衛(wèi)生消防 487.1設(shè)計(jì)依據(jù) 487.2危害因素及危害程度分析 487.3安全設(shè)施及措施 487.4消防設(shè)施 50第八章抗震設(shè)防 528.1編制依據(jù) 528.2建設(shè)場地條件 528.3建筑結(jié)構(gòu)概況與抗震設(shè)計(jì) 54第九章組織機(jī)構(gòu)與項(xiàng)目管理 569.1組織機(jī)構(gòu) 569.2項(xiàng)目管理 56第十章項(xiàng)目建設(shè)實(shí)施進(jìn)度 5910.1項(xiàng)目建設(shè)期 5910.2項(xiàng)目建設(shè)實(shí)施規(guī)劃 59第十一章工程招標(biāo) 6011.1招標(biāo)依據(jù) 6011.2招標(biāo)投標(biāo)的基本原則 6011.3項(xiàng)目概況 6111.4項(xiàng)目提前招標(biāo)情況 6211.5項(xiàng)目招標(biāo)內(nèi)容 62第十二章投資估算與資金措籌 65HYPERLINK\l"