【文章內(nèi)容簡(jiǎn)介】 行中重新定義或調(diào)整模型，從而達(dá)到使開(kāi)發(fā)的信息系統(tǒng)完全貼近不斷變化的業(yè)務(wù)。 LiveBOS由 LiveBOS Server 和 LiveBOS Studio以及 LiveBOS Manager 三大部分組成， LiveBOS Server 就是 LiveBOS 業(yè)務(wù)平臺(tái)的業(yè)務(wù)中間件，是整個(gè) LiveBOS 平臺(tái)的運(yùn)行支撐環(huán)境，它將部署在它上面的 LiveBOS 業(yè)務(wù)模型直接解析為可以直接供最終用戶使用的應(yīng)用系統(tǒng)軟件。 LiveBOS Studio 是面向 LiveBOS 應(yīng)用開(kāi)發(fā)者提供的集成開(kāi)發(fā)環(huán)境，它基于 Eclipse 平臺(tái)。提供了包括業(yè)務(wù)對(duì)象設(shè)計(jì)，業(yè)務(wù)流程設(shè)計(jì)，報(bào)表設(shè)計(jì)，參數(shù)設(shè)計(jì)，選項(xiàng)設(shè)計(jì)等設(shè)計(jì)功能，所有對(duì)象通過(guò) LiveBOS Studio 建立之后以 XML 作為源浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 14 代碼的方式存放。 LiveBOS Manager 面向 IT 管理人員，提供系統(tǒng)級(jí)的管理監(jiān)控和性能優(yōu)化。三者具體的聯(lián)系如圖 ： 圖 LiveBOS 產(chǎn)品的構(gòu)成 從圖 可以比較清晰地看出三者的聯(lián)系，即：開(kāi)發(fā)者在LiveBOS Studio 中完成 LiveBOS 業(yè)務(wù)對(duì)象、流程、報(bào)表等設(shè)計(jì)工作，生成相應(yīng)的 XML 格式模型描述文件，通過(guò) LiveBOS Server提供的應(yīng)用部署服務(wù)，實(shí)現(xiàn)模型在運(yùn)行支持平臺(tái)的部署，運(yùn)行支持平臺(tái)執(zhí)行業(yè)務(wù)模型，就實(shí)現(xiàn)了設(shè)計(jì)預(yù)期的軟件應(yīng)用。 LiveBOS Manager 面向 IT管理人員，提供系統(tǒng)級(jí)的管理監(jiān)控，性能優(yōu)化等。 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 15 LiveBOS業(yè)務(wù)中間件 概括地說(shuō) LiveBOS Server 由一個(gè)基礎(chǔ)服務(wù)層，四個(gè)核心引擎和一個(gè)應(yīng)用架構(gòu)層構(gòu)成，具體如圖 ： 圖 LiveBOS Server架構(gòu)圖 基礎(chǔ)服務(wù)層： LiveBOS 提供的底層框架服務(wù)，包括 Cache 機(jī)制、安全控制、定時(shí)服務(wù)、性能管理，日志服務(wù)，消息協(xié)同等一系列基礎(chǔ)功能。 引擎層：引擎層是 LiveBOS Server 的核心層次，提供了業(yè)務(wù)應(yīng)用系統(tǒng)的運(yùn)行環(huán)境，包括對(duì)象模型引擎、工作流引擎、報(bào)表浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 16 引擎、門(mén)戶引擎。 引擎層 的功能特性包括： 象模型，并按模型文件的描述生成最終的應(yīng)用軟件，它是整個(gè)LiveBOS平臺(tái)的核心。 設(shè)定的流程執(zhí)行，符合 WFMC 標(biāo)準(zhǔn)，并加入了很多符合中國(guó)管理特色的特殊需求，簡(jiǎn)單易用。 ，按照?qǐng)?bào)表定義模型的解釋執(zhí)行生成各類報(bào)表。 ，讓用戶可以按照自己使用的要求，靈活部署自己的工作桌面。門(mén)戶還支持開(kāi)發(fā)人員創(chuàng)建虛擬的門(mén)戶頁(yè)面，按業(yè)務(wù)或角色組織應(yīng)用頁(yè)面。 應(yīng)用框架層：提供管理應(yīng)用軟件所必須的用戶與角色管理，組織架構(gòu)管理，軟件的菜單自定義，界面布局配置，虛擬門(mén)戶頁(yè)面設(shè)置等功能。應(yīng)用架構(gòu)層也可以認(rèn)為是是 LiveBOS 應(yīng)用軟件的一個(gè)組成部分，它是面向 LiveBOS應(yīng)用管理員的基礎(chǔ)功能。 LiveBOS對(duì)象引擎 LiveBOS Server 業(yè)務(wù)對(duì)象模型引擎是整個(gè) LiveBOS 的核心與靈魂所在。業(yè)務(wù)對(duì)象模型提供了基本的信息表達(dá)，包括信息之間的關(guān)系、內(nèi)部的邏輯關(guān)系以及所有可能的操作定義，同時(shí)也定義了信息的展現(xiàn)模式等。具體如圖 所示： 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 17 圖 LiveBOS對(duì)象引擎 LiveBOS 中的對(duì)象主要有實(shí)體對(duì)象（包括層次對(duì)象，流程對(duì)象，子對(duì)象，從屬對(duì)象），虛擬對(duì)象，對(duì) 象視圖等。通過(guò)不同對(duì)象之間不同模式的引用，建立對(duì)象與對(duì)象之間不同的關(guān)系模式。LiveBOS 中業(yè)務(wù)對(duì)象的信息描述，不同于一般軟件開(kāi)發(fā)中以技術(shù)底層的數(shù)據(jù)類型描述，它可以以高層次的類型來(lái)定義，比如，一個(gè)對(duì)象的屬性，可以是另外一個(gè)對(duì)象或一個(gè)選項(xiàng)，一個(gè)文檔等等。 同時(shí)被引用的對(duì)象，它在引用其對(duì)象展現(xiàn)中的顯示模式和輸入的方式，也完全由其自身預(yù)先定義的展現(xiàn)屬性所決定。 LiveBOS 的虛擬對(duì)象技術(shù)支持將各種查詢結(jié)果集（可以是 SQL 查詢結(jié)果，也可以是 WebService 返回的結(jié)果集）映射為虛擬對(duì)象，它具有對(duì)象的許多共同特征。 LiveBOS 的子對(duì)象技術(shù)可以描述現(xiàn)實(shí)中同一類別的多樣化信息，這樣便于權(quán)限管理與便捷使用。 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 18 ETL技術(shù) ETL的概念 ETL 是數(shù)據(jù)抽取（ Extract）、轉(zhuǎn)換（ Transform）、清洗（ Cleansing）、裝載（ Load）的過(guò)程。是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)的重要一環(huán)，用戶從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，經(jīng)過(guò)數(shù)據(jù)清洗 ,最終按照預(yù)先定義好的數(shù)據(jù)倉(cāng)庫(kù)模型，將數(shù)據(jù)加載到數(shù)據(jù)倉(cāng)庫(kù)中去。如圖： 圖 ETL概念示意圖 ETL作為 BI/DW（ Business Intelligence/Data Warehouse）的核心和靈魂，能夠按照統(tǒng)一的規(guī)則集成并提高數(shù)據(jù)的價(jià)值，是負(fù)責(zé)完成數(shù)據(jù)從數(shù)據(jù)源向目標(biāo)數(shù)據(jù)倉(cāng)庫(kù)轉(zhuǎn)化的過(guò)程，是實(shí)施數(shù)據(jù)倉(cāng)庫(kù)的重要步驟 。 [13]如果說(shuō)數(shù)據(jù)倉(cāng)庫(kù)的模型設(shè)計(jì)是一座大廈的設(shè)計(jì)藍(lán)圖，數(shù)據(jù)是磚瓦的話，那么 ETL 就是建設(shè)大廈的過(guò)程。 [14]在浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 19 整個(gè)項(xiàng)目中最難部分是用戶需求分析和模型設(shè)計(jì)，而 ETL規(guī)則設(shè)計(jì)和實(shí)施則是工作量最大的，約占整個(gè)項(xiàng)目的 60%～ 80%，這是國(guó)內(nèi)外從眾多實(shí)踐中得到的普遍共識(shí)。 [12] ETL 負(fù)責(zé)將分布的、異構(gòu)數(shù)據(jù)源中的數(shù)據(jù)如關(guān)系數(shù)據(jù)、平面數(shù)據(jù)文件等抽取到臨時(shí)中間層后進(jìn)行清洗、轉(zhuǎn)換、集成，最后加載到數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)集市中，成為聯(lián)機(jī)分析處理、數(shù)據(jù)挖掘的基礎(chǔ)。 ETL 是本系統(tǒng)數(shù)據(jù)中心中的非常重要的一環(huán)。它是承前啟后的必要的一步 。所以從工程應(yīng)用的角度來(lái)考慮，按著物理數(shù)據(jù)模型的要求加載數(shù)據(jù)并對(duì)數(shù)據(jù)進(jìn)行一些系列處理，處理過(guò)程與經(jīng)驗(yàn)直接相關(guān)，同時(shí)這部分的工作直接關(guān)系數(shù)據(jù)中心中數(shù)據(jù)的質(zhì)量，從而影響到聯(lián)機(jī)分析處理和數(shù)據(jù)挖掘的結(jié)果的質(zhì)量。 實(shí)現(xiàn) ETL，首先要實(shí)現(xiàn) 數(shù)據(jù)清洗 轉(zhuǎn)換的過(guò)程。 [15]它可以集中地體現(xiàn)為以下幾個(gè)方面 ： ：可捕獲字段空值，進(jìn)行加載或替換為其他含義數(shù)據(jù)，并可根據(jù)字段空值實(shí)現(xiàn)分流加載到不同目標(biāo)庫(kù)。 ：可實(shí)現(xiàn)字段格式約束定義，對(duì)于數(shù)據(jù)源中時(shí)間、數(shù)值、字符等數(shù)據(jù)，可自定義加載格式。 ：依據(jù)業(yè) 務(wù)需求對(duì)字段可進(jìn)行分解。 。 ：對(duì)于因業(yè)務(wù)因素，可實(shí)現(xiàn)無(wú)效數(shù)據(jù)、缺失數(shù)據(jù)浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 20 的替換。 ETL 過(guò)程的主外鍵約束：對(duì)無(wú)依賴性的非法數(shù)據(jù)，可替換或?qū)С龅藉e(cuò)誤數(shù)據(jù)文件中，保證主鍵惟一記錄的加載。 ETL產(chǎn)品體系結(jié)構(gòu) ETL 過(guò)程在很大程度上受企業(yè)對(duì)源數(shù)據(jù)的理解程度的影響，也就是說(shuō)從業(yè)務(wù)的角度看數(shù)據(jù)集成非常重要。一個(gè)優(yōu)秀的 ETL設(shè)計(jì)應(yīng)該具有如下功能： [16] 管理簡(jiǎn)單；采用元數(shù)據(jù)方法，集中進(jìn)行管理；接口、數(shù)據(jù)格式、傳輸有嚴(yán)格的規(guī)范；盡量不在外部數(shù)據(jù)源安裝軟件；數(shù)據(jù)抽取系統(tǒng)流程自動(dòng)化，并 有自動(dòng)調(diào)度功能；抽取的數(shù)據(jù)及時(shí)、準(zhǔn)確、完整；可以提供同各種數(shù)據(jù)系統(tǒng)的接口，系統(tǒng)適應(yīng)性強(qiáng)；提供軟件框架系統(tǒng)，系統(tǒng)功能改變時(shí)，應(yīng)用程序很少改變便可適應(yīng)變化；可擴(kuò)展性強(qiáng)。 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 21 下圖為 ETL產(chǎn)品體系結(jié)構(gòu)，它體現(xiàn)了主流 ETL 產(chǎn)品框架的主要組成部分： 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 22 圖 ETL體系結(jié)構(gòu)圖 Design manager 提供一個(gè)圖形化的映射環(huán)境，讓開(kāi)發(fā)者定義從源到 目標(biāo)的映射關(guān)系、轉(zhuǎn)換、處理流程。設(shè)計(jì)過(guò)程的各對(duì)象的邏輯定義存儲(chǔ)在一個(gè)元數(shù)據(jù)資料庫(kù)中。 Meta data repository 提供一個(gè)關(guān)于 ETL 設(shè)計(jì)和運(yùn)行處理等相關(guān)定義、管理信息的元數(shù)據(jù)資料庫(kù)。 ETL 引擎在運(yùn)行時(shí)和其它應(yīng)用都可參考此資料庫(kù)中的元數(shù)據(jù)。 Extract 通過(guò)接口提取源數(shù)據(jù)，例如 ODBC、專用數(shù)據(jù)庫(kù)接口和平面文件提取器，并參照元數(shù)據(jù)來(lái)決定數(shù)據(jù)的提取及其提取方式。 Transform 開(kāi)發(fā)者將提取的數(shù)據(jù)，按照業(yè)務(wù)需要轉(zhuǎn)換為目標(biāo)Load Transform Extract Source adapters Runtime meta data services Meta data repository Target adapters Databaseamp。files Legencyamp。 applicationsperations Administationamp。operations services Transport services Databaseamp。files Design manager Meta data export/import 浙江大學(xué)碩士學(xué)位論文 第 2 章 設(shè)計(jì)和實(shí)現(xiàn)中應(yīng)用的技術(shù) 23 數(shù)據(jù)結(jié)構(gòu)，并實(shí)現(xiàn)匯總。 Load 加載經(jīng)轉(zhuǎn)換和匯總的數(shù)據(jù)到目標(biāo)數(shù)據(jù)倉(cāng)庫(kù) 中，可實(shí)現(xiàn)SQL或批量加載。 Transport services 利用網(wǎng)絡(luò)協(xié)議或文件協(xié)議，在源和目標(biāo)系統(tǒng)之間移動(dòng)數(shù)據(jù)，利用內(nèi)存在 ETL處理的各組件中移動(dòng)數(shù)據(jù)。 Administration and operation 可讓管理員基于事件和時(shí)間進(jìn)行調(diào)度、運(yùn)行、監(jiān)測(cè) ETL 作業(yè)、管理錯(cuò)誤信息、從失敗中恢復(fù)和調(diào)節(jié)從源系統(tǒng)的輸出。 合理的業(yè)務(wù)模型設(shè)計(jì)對(duì) ETL 至關(guān)重要。數(shù)據(jù)倉(cāng)庫(kù)是企業(yè)惟一、真實(shí)、可靠的綜合數(shù)據(jù)平臺(tái)。數(shù)據(jù)倉(cāng)庫(kù)的設(shè)計(jì)建模一般都依照三范式、星型模型、雪花模型，無(wú)論哪種設(shè)計(jì)思想，都應(yīng)該最大化地涵蓋關(guān)鍵業(yè)務(wù)數(shù)據(jù) ，把運(yùn)營(yíng)環(huán)境中雜亂無(wú)序的數(shù)據(jù)結(jié)構(gòu)統(tǒng)一成為合理的、關(guān)聯(lián)的、分析型的新結(jié)構(gòu)，而 ETL 則會(huì)依照模型的定義去提取數(shù)據(jù)源，進(jìn)行轉(zhuǎn)換、清洗，并最終加載到目標(biāo)數(shù)據(jù)倉(cāng)庫(kù)中。 [17] 模型的重要之處在于對(duì)數(shù)據(jù)做標(biāo)準(zhǔn)化定義，實(shí)現(xiàn)統(tǒng)一的編碼、統(tǒng)一的分類和組織。 [17]標(biāo)準(zhǔn)化定義的內(nèi)容包括：標(biāo)準(zhǔn)代碼統(tǒng)一、業(yè)務(wù)術(shù)語(yǔ)統(tǒng)一。 ETL 依照模型進(jìn)行初始加載、增量加載、緩慢增長(zhǎng)維、慢速變化維、事實(shí)表加載等數(shù)據(jù)集成，并根據(jù)業(yè)務(wù)需求制定相應(yīng)的加載策略、刷新策略、匯總策略、維護(hù)策略。 [18] 浙江大學(xué)碩士學(xué)位論文 第 3 章 客戶服務(wù)系統(tǒng)需求分析 24 第 3章 客戶服務(wù)系統(tǒng)需求分析 需求分析方法 在客戶服務(wù)系統(tǒng)項(xiàng)目 中，項(xiàng)目組面臨的第一個(gè)也是最大的挑戰(zhàn)是如何把握客戶的需求。貼近需求，持續(xù)改進(jìn)是 LiveBOS 平臺(tái)的開(kāi)發(fā)特點(diǎn)。 “ 模型即軟件 ,建模即開(kāi)發(fā) ” 是 LiveBOS 最重要的特征。它可以從技術(shù)角度解決開(kāi)發(fā)過(guò)程中的 “ 需求困境 ” ， LiveBOS 支持敏捷開(kāi)發(fā)模式 ,它允許在開(kāi)發(fā)過(guò)程的任何階段提出需求改進(jìn)。通過(guò)快速循環(huán)改進(jìn)模式 ,提升軟件功能?？蛻舴?wù)系統(tǒng)中每個(gè)功能模塊一般看作一個(gè)子系統(tǒng)，從總體上說(shuō)，每個(gè)子系統(tǒng)的需求分析一般經(jīng)歷了以下過(guò)程： ，包括了解該組織的部門(mén)組成情況，各部門(mén)的職能等，為分析信息流程做準(zhǔn)備 。 ，包括了解各個(gè)部門(mén)輸入和使用什么數(shù)據(jù)，如何加工處理這些數(shù)據(jù)，輸出什么信息，輸出到什么部門(mén)，輸出結(jié)果的格式是什么。 ，包括信息要求、處理要求、完全性與完整性要求。 ，確定哪些功能由計(jì)算機(jī)完成或?qū)?lái)準(zhǔn)備讓計(jì)算機(jī)完成，哪些活動(dòng)由人工完成。由計(jì)算機(jī)完成的功能就是新系統(tǒng)應(yīng)該實(shí)現(xiàn)的功能。 浙江大學(xué)碩士學(xué)位論文 第 3 章 客戶服務(wù)系統(tǒng)需求分析 25 實(shí)際的經(jīng)驗(yàn)中，如果根據(jù)傳統(tǒng)的大型項(xiàng)目方法，通過(guò)大量前期的需求調(diào)研，形成文檔化的客戶需求報(bào)告往往與客戶的真正需求相距甚遠(yuǎn)。實(shí)際上，這 里存在兩個(gè)層次的問(wèn)題： 1. 客戶是否完全清楚其對(duì)未來(lái)才能上線軟件的真正要求； 2. 文檔化的需求是否已經(jīng)完全表達(dá)了客戶所表述的需求。在實(shí)際項(xiàng)目過(guò)程中，選擇敏捷開(kāi)發(fā)的方法論以及符合敏捷需求模式的中間件技術(shù)，正是為了解決傳統(tǒng)開(kāi)發(fā)模式中需求分析存在的問(wèn)題。敏捷思想的核心是人與交流。需求問(wèn)題實(shí)際上是一個(gè)交流問(wèn)題。 Kent Beck 在 XP過(guò)程中提到了現(xiàn)場(chǎng)客戶 [17]， 在客戶服務(wù)系統(tǒng)項(xiàng)目中作為敏捷團(tuán)隊(duì)具備現(xiàn)場(chǎng)客戶這一要素 ， 雖然客戶由于自身工作原因不能全職投入項(xiàng)目開(kāi)發(fā)進(jìn)程，但依然屬于理想 的 情況，因?yàn)榕c客戶可以隨時(shí)進(jìn)行當(dāng)面交 流，客戶、開(kāi)發(fā)人員對(duì)需求有統(tǒng)一的認(rèn)識(shí)。 敏捷過(guò)程并不是沒(méi)有需求分析，而是把需求分析過(guò)程分散到整個(gè)開(kāi)發(fā)的過(guò)程中，讓開(kāi)發(fā)和需求分析并行進(jìn)行。 敏捷方法希望快速交付可用的軟件。實(shí)現(xiàn)軟件的快速交付是通過(guò)迭代來(lái)完成。在迭代開(kāi)始前，由 項(xiàng)目經(jīng)理 大致評(píng)估一下 用戶需求 ，標(biāo)記出不同的難度和風(fēng)險(xiǎn)，并提出問(wèn)題。然后 提出優(yōu)先級(jí)、具有較大商業(yè)價(jià)值的需求供用戶選擇 ，客戶可以選擇 先進(jìn)行這些模塊的開(kāi)發(fā) ，或者指出從他的視角看到的優(yōu)先級(jí)更高的 功能需求 。這些將成為下一個(gè)迭代的內(nèi)容。 在需求分析的實(shí)際工作進(jìn)行中，項(xiàng)目組首先確定了各成員的浙江大學(xué)碩士學(xué)位論文 第 3 章 客戶服務(wù)系統(tǒng)需求分析 26 分工情況和大致 的時(shí)間進(jìn)度，