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