【導(dǎo)讀】{ "error_code": 17, "error_msg": "Open api daily request limit reached" }

　　

【正文】 3． 安全性：系統(tǒng)通過(guò)對(duì)用戶所具有的角色和權(quán)限進(jìn)行設(shè)置，來(lái)控制對(duì)系統(tǒng)的訪問(wèn)和操作權(quán)限。系統(tǒng)應(yīng)具有很強(qiáng)的安全性與容錯(cuò)機(jī)制，以保障系統(tǒng)的高可用性與不間斷正常運(yùn)行。 10 第四章 基于 UML 的系統(tǒng)分析與設(shè)計(jì) 本章討論了基于 UML 的訂單管理系統(tǒng)的分析與設(shè) 計(jì)。首先，從分析網(wǎng)站的的需求出發(fā)，描述用戶對(duì)系統(tǒng)的需求，并根據(jù)需求描述，確定系統(tǒng)的角色。然后，從不同角色的視角出發(fā)，分析并獲取他們的業(yè)務(wù)用例。接著，建立各業(yè)務(wù)用例的模型。最后，根據(jù)這些模型尋找業(yè)務(wù)對(duì)象及其屬性，從而進(jìn)行系統(tǒng)后臺(tái)數(shù)據(jù)庫(kù)的設(shè)計(jì)。在整個(gè)分析和設(shè)計(jì)過(guò)程中，都利用了 UML 的視圖進(jìn)行描述。 需求建模 用例被用來(lái)描繪一個(gè)系統(tǒng)外在可見(jiàn)的需求情況，常被用在項(xiàng)目的需求建模階段，對(duì)項(xiàng)目的測(cè)試計(jì)劃和用戶指南也有用處。他們被用來(lái)創(chuàng)建和驗(yàn)證被提議的設(shè)計(jì)，并確保該設(shè)計(jì)滿足所有的需求。 確定系統(tǒng)邊界 和系統(tǒng)范圍 確定系統(tǒng)邊界和系統(tǒng)范圍意味著找出系統(tǒng)中有什么 (你必須為創(chuàng)建它們投入大量的精力 )，系統(tǒng)外有什么（你不需要?jiǎng)?chuàng)建，但必須考慮與他們接口的事情）。訂單管理信息系統(tǒng)主要包含四個(gè)功能模塊，而訂單信息管理模塊是其中一個(gè)也是最重要的一個(gè)模塊。而諸如基本信息管理模塊、系統(tǒng)信息管理模塊等都是與訂單信息管理模塊交互的外部系統(tǒng)。這些外部系統(tǒng)的內(nèi)部功能結(jié)構(gòu)不屬于本課題系統(tǒng)分析和設(shè)計(jì)的范圍之內(nèi)。本課題主要是分析和設(shè)計(jì)訂單信息管理模塊的功能與外部系統(tǒng)的交互活動(dòng)。 系統(tǒng)角色分析 角色是系統(tǒng)的使用者和參與者，是與業(yè) 務(wù)系統(tǒng)有著交互的人或事物，他們用來(lái)確定系統(tǒng)業(yè)務(wù)的范圍，是獲得項(xiàng)目中幾種圖表的關(guān)鍵所在。系統(tǒng)的主角對(duì)項(xiàng)目來(lái)說(shuō)是必需的，而且非常重要，建立業(yè)務(wù)模型、查找業(yè)務(wù)用例都必須使用系統(tǒng)的角色。識(shí)別出角色之后，方能更好地理解項(xiàng)目必須支持的事件。 角色通常被認(rèn)為是人，但它們也可能是其他系統(tǒng)、定時(shí)器和時(shí)鐘，或硬件設(shè)備。角色在系統(tǒng)的運(yùn)作中其激勵(lì)作用，他們是事件的引發(fā)者，它們還可以接受系統(tǒng)的激勵(lì)，在這種情況下它們是被動(dòng)的。為找到系統(tǒng)角色，首先要分析系統(tǒng)的涉眾，即與系統(tǒng)相關(guān)的一切人和事。通過(guò)下面問(wèn)題，可以幫助建模者發(fā)現(xiàn)角色： ? 誰(shuí) /什 么會(huì)對(duì)這個(gè)系統(tǒng)產(chǎn)生的結(jié)果感興趣？ ? 誰(shuí) /什么會(huì)想要使用系統(tǒng)的主要功能、改變系統(tǒng)中的數(shù)據(jù)？ ? 誰(shuí) /什么需要與系統(tǒng)建立接口？ ? 誰(shuí) /什么需要從系統(tǒng)獲取信息？ ? 誰(shuí) /什么來(lái)維護(hù)、管理使系統(tǒng)正常工作？ ? 系統(tǒng)需要與哪些其他系統(tǒng)交互，包含其他計(jì)算機(jī)系統(tǒng)和其他應(yīng)用程序？ 通過(guò)回答以上問(wèn)題，可以確定訂單管理信息系統(tǒng)的涉眾主要是財(cái)務(wù)部人員、生產(chǎn)車間的工作人員以及系統(tǒng)的普通用戶和管理人員。根據(jù)這些涉眾及其關(guān)系可確定本網(wǎng)站的角色有以下幾種。 表 41 訂單系統(tǒng)中的角色 角色 定義 客戶 向企業(yè)訂購(gòu)產(chǎn)品 供應(yīng)商 向企業(yè)提供生產(chǎn)原材料 財(cái)務(wù)部人員 從財(cái)務(wù)的角度來(lái)審核訂單、協(xié)調(diào)銷售與采購(gòu) 生產(chǎn)車間人員 根據(jù)訂單數(shù)量和種類來(lái)安排生產(chǎn)工作 系統(tǒng)管理員 管理各類基本信息，維護(hù)系統(tǒng)信息 銷售人員 創(chuàng)建各類訂單 經(jīng)理 索取企業(yè)訂單狀況的各類報(bào)表 11 獲取用例 一旦獲取了系統(tǒng)角色就可以對(duì)每個(gè)角色提出問(wèn)題以獲取用例，典型的問(wèn)題有： ? 角色要求系統(tǒng)提供哪些功能（角色需要做什么）？ ? 角色需要讀、產(chǎn)生、刪除、修改或存儲(chǔ)的信息有哪些類型？ ? 必須提醒角色的系統(tǒng)事件有哪些？或者角色必須提醒系統(tǒng)的事件有哪些？怎樣把這些事件表示成用例中 的功能？ ? 角色的某些典型功能能否被系統(tǒng)自動(dòng)實(shí)現(xiàn)？ ? 系統(tǒng)需要何種輸入輸出？輸入從何處來(lái)？輸出到何處？當(dāng)前運(yùn)行系統(tǒng)的主要問(wèn)題？ 每一個(gè)用例圖都是一個(gè)活動(dòng)者與系統(tǒng)在交互中執(zhí)行的有關(guān)事務(wù)序列。應(yīng)當(dāng)根據(jù)系統(tǒng)需求，找出全部的用例，并從活動(dòng)者的角度給出事件流，當(dāng)用例執(zhí)行時(shí)系統(tǒng)應(yīng)提供給活動(dòng)者的服務(wù)。對(duì)一個(gè)用例應(yīng)說(shuō)明的基本內(nèi)容是：用例怎樣開(kāi)始和結(jié)束、正常的事件流、變通的事件流、意外情況的事件流等。根據(jù)以上問(wèn)題分析本系統(tǒng)的需求，可以初步確定這樣一些用例： 1) 銷售人員：創(chuàng)建訂單、向供貨商退貨、處理客戶退貨、訂單維護(hù)、訂單處理、訂單狀態(tài)查詢、個(gè)人信息維護(hù)、報(bào)表維護(hù) 2) 財(cái)務(wù)部人員：審核訂單、訂單狀態(tài)查詢、個(gè)人信息維護(hù) 3) 生產(chǎn)車間人員：庫(kù)存查詢、缺貨拒絕、原材料入庫(kù)、產(chǎn)品出庫(kù)、原材料退貨出庫(kù)、產(chǎn)品退貨入庫(kù) 4) 系統(tǒng)管理員：供應(yīng)商信息管理（添加、修改、刪除、查詢）、客戶信息管理（添加、刪除、修改、查詢）、產(chǎn)品信息管理、原材料信息管理、系統(tǒng)用戶管理、系統(tǒng)信息維護(hù) 在基本上找出系統(tǒng)中的用例后，接下來(lái)可以確定他們直接的關(guān)系，直觀的做法就是畫出系統(tǒng)的用例圖。下面是各角色的用例圖： 12 銷 售 人 員創(chuàng) 建 訂 單向 供 應(yīng) 商 退 貨處 理 客 戶 退 貨訂 單 維 護(hù)訂 單 處 理個(gè) 人 信 息 維 護(hù)報(bào) 表 維 護(hù)修 改刪 除訂 單 狀 態(tài) 查 詢庫(kù) 存 查 詢修 改 密 碼《extend》《extend》《include》《include》《extend》 圖 41 銷售人員 的用例圖 財(cái) 務(wù) 人 員審 核 訂 單個(gè) 人 信 息 維 護(hù)報(bào) 表 維 護(hù)訂 單 狀 態(tài) 查 詢修 改 密 碼《 e x t e n d 》 圖 42 財(cái)務(wù)人員用例圖 13 生 產(chǎn) 人 員產(chǎn) 品 出 庫(kù)個(gè) 人 信 息 維 護(hù)原 材 料 退貨 出 庫(kù)原 材 料 入 庫(kù)修 改 密 碼《 e x t e n d 》產(chǎn) 品 退 貨 入 庫(kù)庫(kù) 存 查 詢?nèi)?貨 拒 絕《include》《extend》《include》 圖 43 生產(chǎn)部門用例圖 系 統(tǒng) 管 理人 員客 戶 信息 管 理系 統(tǒng) 信 息 維 護(hù)系 統(tǒng) 用戶 管 理原 材 料 信息 管 理查 詢《extend》產(chǎn) 品 信息 管 理修 改添 加《extend》供 應(yīng) 商 信息 管 理刪 除《extend》《extend》《extend》《extend》《extend》《extend》添 加 用 戶刪 除 用 戶《include》《include》 圖 44 系統(tǒng)管理員的用例圖 14 用例文檔 在 UML 的文檔中，只給出了用例圖的表達(dá)方式，沒(méi)有給出一種標(biāo)準(zhǔn)的用例的描述方法。這也使得很多人混淆了用例和用例圖的概念，忽略了對(duì)用例的詳細(xì)描述。實(shí)際上，所謂的“用例驅(qū)動(dòng)”的基礎(chǔ)正是經(jīng)過(guò)詳細(xì)描述的用例，而不是用例圖。編寫用 例文檔以詳細(xì)描述用例，可以使用用例模板，包括以下幾個(gè)方面： ? 用例名稱 ? 目標(biāo)：簡(jiǎn)要描述該用例所要達(dá)到的目的 ? 范圍：用例的范圍 ? 前置條件：執(zhí)行該用例前必須滿足的條件 ? 后置條件：執(zhí)行完該用例后要滿足的條件 ? 主要參與者：執(zhí)行該用例的主要參與者 ? 觸發(fā)事件：引起該用例執(zhí)行的事件 ? 相關(guān)用例：與該用例相關(guān)的其他用例 下面僅以幾個(gè)主要和有代表性的用例文檔為例： 表 42 創(chuàng)建訂單的用例文檔 用例名稱： 創(chuàng)建訂單 目標(biāo)： 該用例根據(jù)與客戶簽訂的合同制定銷售訂單 范圍： 銷售部 參 與 者： 銷售人員 前置條件： 系統(tǒng)具有客戶信息、產(chǎn)品信息 后置條件： 產(chǎn)生銷售訂單，并將信息存入數(shù)據(jù)庫(kù)待財(cái)務(wù)部審核 觸發(fā)事件： 根據(jù)需要 相關(guān)用例： 訂單查詢、客戶信息管理 表 43 審核訂單的用例文檔 用例名稱： 審核訂單 目標(biāo)： 該用例是財(cái)務(wù)部門，根據(jù)與客戶簽訂的合同制定銷售訂單 范圍： 財(cái)務(wù)部 參 與 者： 財(cái)務(wù)人員 前置條件： 系統(tǒng)產(chǎn)生新訂單信息 后置條件： 審核通過(guò)的訂單信息發(fā)至生產(chǎn)部門，通知展開(kāi)生產(chǎn)；未通過(guò)的發(fā)回銷售 部銷毀或修改 觸發(fā)事件： 有新建的訂單發(fā)到財(cái)務(wù)部 相關(guān)用例： 訂單查詢、訂 單維護(hù) 15 表 44 訂單狀態(tài)查詢的用例文檔 用例名稱： 訂單狀態(tài)查詢 目標(biāo)： 該用例可由財(cái)務(wù)部門或銷售部執(zhí)行，根據(jù)需要查詢某訂單的當(dāng)前狀態(tài) 范圍： 財(cái)務(wù)部及銷售部 參 與 者： 財(cái)務(wù)人員、銷售人員 前置條件： 系統(tǒng)具有完整的訂單信息，并及時(shí)對(duì)訂單狀態(tài)進(jìn)行更新 后置條件： 用例成功，查詢者根據(jù)訂單狀態(tài)執(zhí)行后續(xù)工作 觸發(fā)事件： 根據(jù)需要 相關(guān)用例： 訂單查詢、訂單審核 表 44 產(chǎn)品出庫(kù)的用例文檔 用例名稱： 產(chǎn)品出庫(kù) 目標(biāo)： 該用例可生產(chǎn)部門執(zhí)行，根據(jù)客戶訂單上需求的 產(chǎn)品數(shù)量進(jìn)行生產(chǎn)后 將產(chǎn)品發(fā)出 范圍： 生產(chǎn)部門 參 與 者： 生產(chǎn)車間人員 前置條件： 訂單審核通過(guò)交付生產(chǎn)車間，系統(tǒng)具有產(chǎn)品信息 后置條件： 用例成功，生產(chǎn)車間將產(chǎn)品發(fā)往客戶處，并生成出庫(kù)單 觸發(fā)事件： 生產(chǎn)完成 相關(guān)用例： 訂單狀態(tài)查詢、訂單創(chuàng)建 表 45 個(gè)人信息維護(hù)的用例文檔 用例名稱： 個(gè)人信息維護(hù) 目標(biāo)： 訂單管理系統(tǒng)的所有用戶均可執(zhí)行該用例，已修改個(gè)人登錄信息 范圍： 與訂單管理有關(guān)的部門 參 與 者： 所有系統(tǒng)用戶 前置條件： 用戶已在系統(tǒng)中進(jìn)行注冊(cè) ，系統(tǒng)中存有其登錄信息 后置條件： 用例成功，該用戶的個(gè)人信息更新并存入數(shù)據(jù)庫(kù) 觸發(fā)事件： 根據(jù)需要 相關(guān)用例： 添加用戶、刪除用戶、修改密碼 靜態(tài)建模 進(jìn)一步分析系統(tǒng)需求，發(fā)現(xiàn)類以及類之間的關(guān)系，確定他們的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為是面向?qū)ο蠓治龅幕救蝿?wù)。系統(tǒng)的靜態(tài)結(jié)構(gòu)模型主要用類和對(duì)象圖描述。 定義對(duì)象和類 Booch 曾指出，區(qū)分對(duì)象和類是面向?qū)ο蠓椒ㄖ凶铍y的一步，而這一步又是面向?qū)ο蠓治龊驮O(shè)計(jì)的基礎(chǔ)。 16 對(duì)象是對(duì)現(xiàn)實(shí)世界中事物的抽象，要區(qū)分對(duì)象和類就要正確地運(yùn)用抽象的原則，首 先要舍棄那些與系統(tǒng)責(zé)任無(wú)關(guān)的事物，只注意與系統(tǒng)責(zé)任有關(guān)的事物。其次，對(duì)于與系統(tǒng)責(zé)任有關(guān)的事物，也不是要反應(yīng)出它的所有特征，應(yīng)舍棄那些與系統(tǒng)責(zé)任無(wú)關(guān)的特征。判斷事物是否與系統(tǒng)責(zé)任有關(guān)，一是事物是否為系統(tǒng)提供了一些有用的信息，或者它是否需要系統(tǒng)為它保存管理某些信息，二是它是否向系統(tǒng)提供了某些服務(wù)，或者說(shuō)，它是否需要系統(tǒng)描述它的某些行為。 發(fā)現(xiàn)對(duì)象和類一般有這樣幾種方法 : 1) 在 OOSE 中，將對(duì)象分為三種 ： 邊界類、實(shí)體類和控制類。其中，邊界類用于建立系統(tǒng)與其參與者之間交互的模型 ； 實(shí)體類用于對(duì)長(zhǎng)期持久的信息建模 ； 控制類 代表協(xié)調(diào)、排序、事物處理以及對(duì)其他對(duì)象的控制，還可用來(lái)表示復(fù)雜的派生與演算，如業(yè)務(wù)邏輯等。這為我們分析類和對(duì)象提供了一些啟發(fā)。 2) 在傳統(tǒng)的面向?qū)ο蠓椒?(如 Coad amp。 Yourdon 的 OOA)中給出了一些發(fā)現(xiàn)對(duì)象和類的基本策略和啟發(fā)性原則，這些方法是從實(shí)踐中總結(jié)出來(lái)的，有一定的普遍性，在基于 UML的面向?qū)ο蠼Ｖ腥钥梢圆捎?。主要策略有，從?wèn)題域 （ 人員、組織、物品、設(shè)備、事件、表格等 ） 、系統(tǒng)邊界 （ 人員、設(shè)備和外系統(tǒng) ） 和系統(tǒng)責(zé)任出發(fā)，考慮各種能啟發(fā)發(fā)現(xiàn)對(duì)象的因素，找出各種可能有用的候選對(duì)象。通過(guò)這種方法發(fā)現(xiàn)的類一 般是實(shí)體類。 3) 在 UML 中，由于我們采用用例來(lái)捕獲系統(tǒng)需求，分析用例，從用例中尋找對(duì)象和類也是一種很好的方法。而且，用例模型可以用來(lái)檢驗(yàn)領(lǐng)域模型，也就是對(duì)照用例模型，查找用例中的哪些功能尚沒(méi)有對(duì)象來(lái)實(shí)現(xiàn)，以此也可以發(fā)現(xiàn)對(duì)象。 通過(guò)以上方法分析訂單管理系統(tǒng)，可以發(fā)先以下實(shí)體類：產(chǎn)品、原材料、客戶、供應(yīng)商、庫(kù)存量、訂單、訂單狀態(tài)、入庫(kù)單、出庫(kù)單、向供應(yīng)商退貨單、客戶退貨單等。對(duì)于邊界類，分析階段不必深究用戶界面的每個(gè)窗口不見(jiàn)，只要說(shuō)明通過(guò)交互所實(shí)現(xiàn)的目標(biāo)就可以了，所以大致可以確定如下的邊界類：供貨商管理界面、客戶 管理界面、產(chǎn)品管理界面、原材料管理界面、訂單管理界面、系統(tǒng)用戶管理界面。對(duì)于控制類可以將復(fù)雜的業(yè)務(wù)邏輯抽象為控制類，如：發(fā)貨計(jì)劃、退貨計(jì)劃、訂單維護(hù)等。 為類分配屬性 抽象出系統(tǒng)中的類后，還需要確定這些對(duì)象的屬性和行為?？梢愿鶕?jù)前述的系統(tǒng)需求建模、用例圖、用例的事件流描述來(lái)確定并細(xì)化系統(tǒng)中的類、類的操作和類的屬性。 (1)類產(chǎn)品：描述了企業(yè)生產(chǎn)的產(chǎn)品的信息。 主要屬性：產(chǎn)品編號(hào)、產(chǎn)品名稱、單價(jià)、計(jì)量單位、規(guī)格 (2)類原材料：描述了供應(yīng)商提供的原材料的相關(guān)信息。 主要屬性：原材料編號(hào)、名稱、單價(jià)、計(jì) 量單位、供應(yīng)商 (3)類客戶：描述了