【導讀】{ "error_code": 17, "error_msg": "Open api daily request limit reached" }

　　

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