【導(dǎo)讀】在目前國(guó)內(nèi)供應(yīng)鏈管理系統(tǒng)應(yīng)用環(huán)境不成熟的條件下，如何提供優(yōu)質(zhì)。及對(duì)傳統(tǒng)軟件工程的改進(jìn)方法，最后得出了一套適應(yīng)現(xiàn)階段SCM應(yīng)用的原型軟件,面向制造業(yè)的SCM系統(tǒng)的本質(zhì)特點(diǎn)是優(yōu)化整個(gè)供應(yīng)鏈上的企業(yè)的資源配置,段SCM的開發(fā)應(yīng)用。進(jìn)一步的研究需要跟蹤SCM理論及其實(shí)現(xiàn)技術(shù)的發(fā)展動(dòng)態(tài)，結(jié)合實(shí)踐過程，不斷改進(jìn)開發(fā)方法。§課題的主要任務(wù)和實(shí)現(xiàn)方法.........

　　

【正文】 系統(tǒng)負(fù)載過重：需要根據(jù)實(shí)際情況，調(diào)節(jié)系統(tǒng)軟硬件環(huán)境配置，必要時(shí)采用多服務(wù)器分布運(yùn)算，增加分布點(diǎn)，并由 Web服務(wù)器保證負(fù)載均衡。 ? 商務(wù)信息傳輸（ B/S）和商務(wù)信息處理（ C/S）系統(tǒng)數(shù)據(jù)接口沖突：要求協(xié)同設(shè)計(jì)，避免交叉訪問數(shù)據(jù)，防止數(shù)據(jù)并發(fā)訪問造成數(shù)據(jù)失真。 ? 內(nèi)部的誤操作 導(dǎo)致系統(tǒng)不穩(wěn)定，數(shù)據(jù)非法等，靠程序設(shè)計(jì)自我保護(hù)。 ? 網(wǎng)絡(luò)的中斷，這根本上需要網(wǎng)絡(luò)大環(huán)境的改善加以解決。 對(duì)于系統(tǒng)的故障解決原則是盡量采取預(yù)防措施降低系統(tǒng)的故障率，對(duì)于已經(jīng)發(fā)生的故障，要求花費(fèi)最少的代價(jià)和最短的時(shí)間修復(fù)，對(duì)于實(shí)在無法修復(fù)的故障，作為這個(gè)版本的一個(gè)缺陷記載下來，在下一個(gè)版本中改進(jìn)。 9) 對(duì)可使用性的分析： 軟件的可使用性是指在某個(gè)給定時(shí)間點(diǎn)上程序能夠按需求執(zhí)行的概率，用公式 度量系統(tǒng)的可用性： 可用性＝ MTTF/(MTTF+MTTR) 100% ……………………………………… .() MTTF:平均失敗時(shí)間； MTTR:平均修復(fù)時(shí)間。 本系統(tǒng)為低發(fā)布成本方案，是基于應(yīng)用的，性能由開發(fā)者保證，設(shè)計(jì)中按同時(shí)容納50 個(gè)用戶同時(shí)在線為前提，系統(tǒng)注冊(cè)客戶數(shù)量限制在 2020人以內(nèi)，服務(wù)器暫時(shí)不提供集群和分布服務(wù)，主要在 Win2020 Advanced Server 操作系統(tǒng)上運(yùn)行，服務(wù)器配置滿足硬件要求，用戶的網(wǎng)絡(luò)接入速度不低于 56kbps 時(shí) ,在滿足以上的條件的前提下，系統(tǒng)的可用性要求不小于 %。 10) 對(duì)可維護(hù)性的分析： 系統(tǒng)需要定期的維護(hù)，目前系統(tǒng)的自維護(hù)能力并不強(qiáng)，需要人工定期參與維護(hù) ，外 ２０ 部的數(shù)據(jù)需要定期的收集到企業(yè)內(nèi)部處理，企業(yè)內(nèi)部的數(shù)據(jù)也定期的發(fā)布出去 ,重要的數(shù)據(jù)要定期的備份，在發(fā)生災(zāi)難時(shí)要及時(shí)的恢復(fù)，系統(tǒng)軟件可以根據(jù)需要升級(jí)，系統(tǒng)資源緊張時(shí)需要采取措施緩解壓力。 11) 對(duì)可移植性的分析： 本系統(tǒng)的移植主要有兩種情況：一種是操作系統(tǒng)的變更，要求程序的運(yùn)行基本已經(jīng)和操作系統(tǒng)之間互相獨(dú)立 ,在不同的操作系統(tǒng)間移植比較容易 ,只需要對(duì)新的運(yùn)行環(huán)境做一定的配置即可。另外一種是 Web 服務(wù)器的變更，要求系統(tǒng)可以適應(yīng)目前市場(chǎng)上流行的各種 Web 服務(wù)器，包括： Jaguar CTS of Sybase、 WebSphere of IBM 等。 12) 對(duì)系統(tǒng)穩(wěn)定性的分析： 系統(tǒng)的穩(wěn)定性需要一定的保障，至少要求系統(tǒng)能夠在滿足用戶需求的情況下連續(xù)穩(wěn)定運(yùn)行時(shí)間不小于 48 小時(shí)，本系統(tǒng)是基于 Java 組件的產(chǎn)品，系統(tǒng)穩(wěn)定性依靠組件本身以及服務(wù)器來保證。 13) 對(duì)安全性的分析： 由于系統(tǒng)直接與 Inter 相連，安全性要求比較高，沒有發(fā)布的企業(yè)內(nèi)部數(shù)據(jù)無論在什么情況下，都不能被外部攻擊、篡改或偷聽，對(duì)通過 Inter 傳入的數(shù)據(jù)需要采用一定的校驗(yàn)措施保證其合法性， EDB 上的數(shù)據(jù)相對(duì) CDB上的數(shù)據(jù)享有更高的安 全等級(jí)，需要保證絕對(duì)的安全性。 167。 對(duì)系統(tǒng)分析建模方法的探討 [30] 167。 原則上說，用戶提出需求時(shí)，是不用顧及整個(gè)系統(tǒng)的，需求獲取后，需要從開發(fā)者的角度對(duì)需求進(jìn)行分析，判斷用戶的需求是否合理？需求實(shí)現(xiàn)是否有困難？各個(gè)需求之間是否有沖突？如何對(duì)需求進(jìn)行優(yōu)化？這些問題需要在系統(tǒng)建模分析階段得出結(jié)論。 系統(tǒng)建模方法有兩類：傳統(tǒng)的結(jié)構(gòu)化建模方法和面向?qū)ο蟮慕７椒ā? 傳統(tǒng)軟件工程建模方法是結(jié)構(gòu)化的，結(jié)構(gòu)化分析模型必須要達(dá)到三個(gè)主要目標(biāo)： 描述客戶的需要； 1) 建立傳統(tǒng)軟件設(shè)計(jì) 的基礎(chǔ)； 2) 定義在軟件完成后可以被確認(rèn)的一組需求。 ２１ 3) 為了達(dá)到這些目標(biāo)，在結(jié)構(gòu)化分析中導(dǎo)出了以下的分析模型： 以“數(shù)據(jù)字典”為核心（數(shù)據(jù)字典包含了軟件使用或生產(chǎn)的所有數(shù)據(jù)對(duì)象描述的中心庫(kù)），建立系統(tǒng)的數(shù)據(jù)模型，功能模型和行為模型。圍繞數(shù)據(jù)字典，借助三種圖來描述模型： “實(shí)體 —— 關(guān)系圖”（ ERD），描述數(shù)據(jù)對(duì)象間的關(guān)系， ERD是用來進(jìn)行數(shù)據(jù)建?；顒?dòng)的記號(hào)； “數(shù)據(jù)流圖” (DFD)，服務(wù)于兩個(gè)目的：（ 1）指明數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換；（ 2）描述對(duì)數(shù)據(jù)流進(jìn)行變換的功能（和子功能）。數(shù)據(jù)流圖是進(jìn)行功能建模建?；顒?dòng)的主要工具。 “狀態(tài)變遷圖”（ STD） ,指明作為外部事件的結(jié)果，系統(tǒng)將如何動(dòng)作，為此， STD表示了系統(tǒng)的各種行為模式以及在狀態(tài)間進(jìn)行變遷的方式， STD是行為建模的基礎(chǔ)。 而面向?qū)ο蟮慕７椒ǖ囊鈭D是定義所有問題相關(guān)的類（以及和類關(guān)聯(lián)的關(guān)系和行為），為了達(dá)到這個(gè)目標(biāo)，必須完成以下的任務(wù)顯示： 1) 必須在客戶和軟件工程師之間溝通了解基本的用戶需求； 2) 必須標(biāo)識(shí)類（即類的屬性和方法）； 3) 必須刻化類的層次； 4) 表示對(duì)象 對(duì)象的關(guān)系； 5) 必須建模對(duì)象行為； 6) 任務(wù) 15遞進(jìn)地反復(fù)使用，直到完成建模。 面向?qū)ο蟮姆治龇椒ê蛡鹘y(tǒng)的軟件 分析方法一樣，試圖建造一個(gè)多部分的分析模型來描述客戶的需求。面向?qū)ο蟮姆治龇椒ê蛡鹘y(tǒng)的軟件分析方法是否確實(shí)存在不同呢？對(duì)于這個(gè)問題，作者認(rèn)為：傳統(tǒng)的軟件分析方法采用獨(dú)特的“輸入－加工－輸出”視角，數(shù)據(jù)被脫離數(shù)據(jù)的變換過程而單獨(dú)考慮，系統(tǒng)的行為雖然重要，但被作為第二位考慮，這種分析方法著重于功能分解的使用，而面向?qū)ο蟮姆治龇椒ù砹讼鄬?duì)于傳統(tǒng)的軟件分析方法的改進(jìn)，面向?qū)ο蟮娜齻€(gè)基本原則（封裝，對(duì)象分類和繼承）的分析模型是相正交的。 本系統(tǒng)中將采用很多的面向?qū)ο蟮募夹g(shù)，各種運(yùn)算都以類的形式封裝和調(diào)用，但系統(tǒng)的面 向?qū)ο蟮奶攸c(diǎn)并不突出，對(duì)象的封裝、分類以及繼承等并不是重點(diǎn)，相反，由于系統(tǒng)的邏輯處理比較復(fù)雜，更關(guān)心的是系統(tǒng)在邏輯上是如何實(shí)現(xiàn)的，系統(tǒng)的功能如何的被分解，因此系統(tǒng)準(zhǔn)備采用傳統(tǒng)的軟件分析方法進(jìn)行分析。 ２２ 167。 供應(yīng)鏈管理系統(tǒng)數(shù)據(jù)建模 作為商務(wù)信息處理外圍，商務(wù)信息處理部分的數(shù)據(jù)建模工作應(yīng)該和商務(wù)信息處理的數(shù)據(jù)建模工作一起進(jìn)行，數(shù)據(jù)建模采用傳統(tǒng)的實(shí)體－關(guān)系圖就可以表示清楚，本文不做詳細(xì)的描述。 167。 供應(yīng)鏈管理系統(tǒng)功能建模 功能建模需要建立的加工模型通過 DFD圖描述，在設(shè)計(jì)商務(wù)傳輸子系統(tǒng)時(shí)，針 對(duì)本系統(tǒng)的特點(diǎn)，統(tǒng)一對(duì) DFD 圖的四個(gè)元素做統(tǒng)一的規(guī)定，并要求設(shè)計(jì)人員在繪制 DFD 圖時(shí)遵循這種規(guī)定： 外部實(shí)體：在 DFD圖中用矩形框表示，系統(tǒng)的外部實(shí)體只有用戶，但是為了系統(tǒng)大規(guī)模協(xié)同開發(fā)的需要，將用戶和頁面（不包括生成頁面的對(duì)象）看作外部實(shí)體，它們可以作為數(shù)據(jù)源點(diǎn)和終點(diǎn)，因?yàn)閷?duì)于系統(tǒng)的頁面設(shè)計(jì)和實(shí)現(xiàn)部分被分離出來給一個(gè)橫向的頁面組去實(shí)現(xiàn)，對(duì)于 SCM 設(shè)計(jì)人員來說，頁面組的工作都應(yīng)該是系統(tǒng)邊界以外的事情，他們處理的對(duì)象就是外部實(shí)體（不是系統(tǒng)的外部實(shí)體）。 處理：在 DFD圖中用圓圈表示，一個(gè)處理代表了一個(gè)功能，設(shè) 計(jì)中要求處理精化到每個(gè)圓圈可以用一個(gè)方法實(shí)現(xiàn)，對(duì)一個(gè)功能的描述反應(yīng)在對(duì)應(yīng)圓圈的加工規(guī)約中，除很復(fù)雜的加工過程外，一般的圓圈不要求描述加工規(guī)約，在這里，規(guī)定一個(gè)類對(duì)應(yīng)一個(gè)方法，那么實(shí)際上一個(gè)處理對(duì)應(yīng)的就是一個(gè)傳統(tǒng)的函數(shù)。 數(shù)據(jù)對(duì)象：在 DFD圖中用帶描述的箭頭表述，箭頭的方向表示數(shù)據(jù)的流動(dòng)方向，箭頭的描述表示對(duì)應(yīng)在數(shù)據(jù)字典中的數(shù)據(jù)名。 數(shù)據(jù)存儲(chǔ)：在 DFD圖中用兩條平行線表示，包括可能的數(shù)據(jù)庫(kù)對(duì)象（這時(shí)數(shù)據(jù)庫(kù)還沒有建立）、數(shù)據(jù)臨時(shí)保存對(duì)象（如服務(wù)器端的 session 對(duì)象）等。 由于本系統(tǒng)采用了是面向?qū)ο蟮募夹g(shù)，傳 統(tǒng)的第 0層的語境級(jí)模型對(duì)于本系統(tǒng)的設(shè)計(jì)沒有多大的實(shí)際意義，因此在設(shè)計(jì)中，直接從第 1層 DFD 圖開始設(shè)計(jì)，逐級(jí)精化，如圖 35是銷售部分的訂單錄入的第一層 DFD 圖 ,在圖中共有 6個(gè)處理過程，其中處理 填寫銷售訂單不能在一個(gè)函數(shù)內(nèi)實(shí)現(xiàn)，需要進(jìn)一步的精化，圖 36是對(duì) 的精化。 ２３ DFD[HAT87] 編輯時(shí)間: 2 0 0 0 1 1 6銷售D F D L e v e l 1 －訂單錄入版本: 0EC組第 頁項(xiàng)目: S C M圖號(hào): 1 _ 2銷售訂單編輯界面生成訂單訂單錄入信息訂單顯示33查銷售員I D當(dāng)前銷售員ID內(nèi)部用戶文件當(dāng)前用戶文件用戶I D用戶名銷售訂單文件寫入訂單外部訂單信息外部訂單信息產(chǎn)品文件( 內(nèi))產(chǎn)品基本信息填寫銷售訂單外部訂單信息產(chǎn)品清單顯示申請(qǐng)單顯示選中的產(chǎn)品選中的產(chǎn)品30提取產(chǎn)品產(chǎn)品基本信息產(chǎn)品代碼 生成反饋頁面外部訂單信息反饋頁面出錯(cuò)信息反饋信息反饋信息PSPEC1 , 接受外部訂單信息，并傳送到2 . 3 寫入訂單處理；2 ，根據(jù)寫入訂單處理的返回結(jié)果，生成反饋頁面。 圖 訂單錄入第一層 DFD 圖 DFD[HAT87] 編輯時(shí)間: 2 0 0 0 1 1 6銷售D F D L e v e 2 －填寫銷售訂單版本: 0EC組第 頁項(xiàng)目: S C M圖號(hào): 1 _ 2 _ 1產(chǎn)品清單顯示申請(qǐng)單顯示生成訂單填寫頁面選中的產(chǎn)品選中的產(chǎn)品訂單填寫頁面錄入訂單回顯信息存已填信息選中產(chǎn)品臨時(shí)文件已填信息已填信息已填信息已填信息銷售訂單文件( 外)外部訂單信息選中的產(chǎn)品 訂單錄入信息生成反饋頁面反饋信息外部訂單信息反饋信息 圖 訂單錄入第二層 DFD 圖 系統(tǒng)所有的 DFD圖請(qǐng)參見本文的附件，這些 DFD圖 基本上表示出了系統(tǒng)的功能，也 ２４ 表示了系統(tǒng)對(duì)頁面請(qǐng)求的相應(yīng)動(dòng)作。 167。 供應(yīng)鏈管理行為建模 行為建模的目的是指明作為外部事件的結(jié)果，系統(tǒng)將如何的動(dòng)作，當(dāng)用戶從遠(yuǎn)程發(fā)送一個(gè)請(qǐng)求觸發(fā)一個(gè)事件時(shí)，系統(tǒng)就會(huì)產(chǎn)生一系列的動(dòng)作：頁面變遷、請(qǐng)求接收、邏輯運(yùn)算、事務(wù)處理、結(jié)果回傳等，在類似本系統(tǒng)的 B/S 應(yīng)用中，用戶能夠直接感覺到的最明顯的系統(tǒng)動(dòng)作就是頁面變遷，這是在行為建模階段的重點(diǎn)，本系統(tǒng)的狀態(tài)變遷圖實(shí)際上以頁面變遷圖表示（在附錄六中給出了系統(tǒng)的頁面變遷圖），而系統(tǒng)的其它動(dòng)作在 DFD圖中已經(jīng)表示清楚。 167。 數(shù)據(jù)字典 分析模型中包含對(duì)數(shù)據(jù)對(duì)象、功能和控制的表示。在每種表示中，數(shù)據(jù)對(duì)象和控制項(xiàng)都扮演一定的角色，因此，有必要提供一種有組織的方式來表示每個(gè)數(shù)據(jù)對(duì)象和控制項(xiàng)的特性，這是由數(shù)據(jù)字典來實(shí)現(xiàn)的。 數(shù)據(jù)字典是對(duì)所有與系統(tǒng)相關(guān)的數(shù)據(jù)元素的一個(gè)有組織的列表，以及精確的、嚴(yán)格的定義，使得用戶和系統(tǒng)分析員對(duì)于輸入、輸出、存儲(chǔ)成分和中間計(jì)算有共同的理解，它是數(shù)據(jù)建模、功能建模和行為建模的核心。 在 DFD圖中已經(jīng)表示出的各種數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)對(duì)象，是數(shù)據(jù)字典需要詳細(xì)描述的信息集合，為了統(tǒng)一思想，對(duì)數(shù)據(jù)字典的格式做了以下的 規(guī)定： 標(biāo)記 意義 ＋ 和 [ | ] 或 ,枚舉值用 |分開 { } 重復(fù) ( ) 可選 ＝ 由 …… 構(gòu)成 表 數(shù)據(jù)字典表述符號(hào) 例如對(duì)于圖 ：訂單錄入信息，系統(tǒng)的數(shù)據(jù)字典中這樣描述的： ２５ 數(shù)據(jù)字典關(guān)于訂單錄入信息包括以下的信息：臨時(shí)銷售訂單頭和臨時(shí)銷售訂單項(xiàng)，而臨時(shí)銷售訂單頭和臨時(shí)銷售訂單項(xiàng)是一對(duì)多的關(guān)系，臨時(shí)銷售訂單頭由客戶代碼、發(fā)貨日期、發(fā)貨地點(diǎn)、制訂日期、備注等數(shù)據(jù)項(xiàng)，而臨時(shí)銷售訂單項(xiàng)包含了數(shù)據(jù)項(xiàng)物資代碼、數(shù)量、單價(jià)、稅率等數(shù)據(jù)項(xiàng)。 167。 法 [18] [29] 到此為止，系統(tǒng)的需求就初步確定下來了，為了確保需求的正確性，需要從幾方面對(duì)需求進(jìn)行驗(yàn)證 : 1) 驗(yàn)證需求的一致性： 所有需求必須是一致的，任何一個(gè)需求不能和其它需求互相矛盾，目前只能依靠對(duì)系統(tǒng)模型的人工技術(shù)審查驗(yàn)證這點(diǎn)。 2) 驗(yàn)證需求的現(xiàn)實(shí)性： 需求應(yīng)該是用現(xiàn)有的軟、硬件技術(shù)是可以實(shí)現(xiàn)的。在開發(fā)這套系統(tǒng)前曾經(jīng)做過一段時(shí)間的技術(shù)預(yù)研工作，利用以前的研究成果，結(jié)合軟件需求規(guī)格說明書，基本上可以驗(yàn)證需求的現(xiàn)實(shí)性。 3) 驗(yàn)證需求的完整性和有效性： 一般來說，這步工作需要用戶的密切配合才能完 成，但在開發(fā)過程中，發(fā)現(xiàn)用戶大多數(shù)的時(shí)候并不能清楚的認(rèn)識(shí)到他們的需要，因?yàn)楸鞠到y(tǒng)是第一個(gè)版本，沒有可以參照的模型，因此決定先開發(fā)一套可供需求評(píng)估的原型，依靠原型來驗(yàn)證系統(tǒng)需求的完整性和有效性。 訂單錄入信息＝臨時(shí)銷售訂單頭＋ {臨時(shí)銷售訂單項(xiàng) } 臨時(shí)銷售訂單頭＝客戶代碼＋發(fā)貨日期＋發(fā)貨地點(diǎn)＋制訂日期＋備注 臨時(shí)銷售訂單項(xiàng)＝物資代碼＋數(shù)量＋單價(jià)＋稅率 ２６ 第四章 對(duì)供應(yīng)鏈管理系統(tǒng)設(shè)計(jì)過程的研究 167。 設(shè)想中的幾種系統(tǒng)結(jié)構(gòu) [19] [21] [28] 為了適應(yīng) SCM市場(chǎng)的各個(gè)發(fā)展階段，根據(jù)企業(yè)和開發(fā)商的實(shí)際情況的變化 ,設(shè)想了三種系統(tǒng)結(jié)構(gòu) ,這三種系統(tǒng)結(jié)構(gòu)的共同特征是試圖將企業(yè)內(nèi)部的信息系統(tǒng)通過 Inter向外延伸，但實(shí)現(xiàn)方式上有所差異。 167。 模式 A 目前國(guó)內(nèi)很多的企業(yè)已經(jīng)擁有了完整的內(nèi)部信息系統(tǒng)，特別是 MIS/ERP 系統(tǒng)，并且應(yīng)用已經(jīng)很成熟 ,在 SCM應(yīng)用處于初級(jí)實(shí)施階段，一般企業(yè)不敢輕率的將原有的系統(tǒng)升級(jí)到 SCM，而希望有一個(gè)過渡期，因此在這個(gè)階段，存在這樣一類特殊的需求： 企業(yè)實(shí)施 SCM的準(zhǔn)備工作沒有到位，特別是內(nèi)部的 SCM業(yè)務(wù)人員培訓(xùn)沒有到位，在實(shí)施 SCM 時(shí)，希望有一個(gè)過渡期，對(duì)原有的信息系統(tǒng)不作或少作改動(dòng)，以保持企業(yè)內(nèi)部業(yè)務(wù)流程基本不變； 在 SCM應(yīng)用環(huán)境不完善的情況下，企業(yè)要求優(yōu)