基於星形結構的通用業務模型的快速建模框架的製作方法

2024-03-24 06:40:05

基於星形結構的通用業務模型的快速建模框架的製作方法【專利摘要】本發明設計了基於星形結構的通用業務模型的快速建模框架。基本思路是：框架根據後臺業務模型和前臺視圖模型提供的信息，進行語義分析後，生成一系列資原始碼來實現面向用戶的增、刪、查、改、顯示基本應用功能的代碼和資源。這些代碼資源包括了：後臺對業務數據處理的代碼和資料庫持久層服務、資料庫表等等；前臺默認風格的列表視圖和編輯、查看視圖；生成前臺的控制類完成前臺後臺裝換的邏輯；以及相關的支持系統多語言的資源文件和自動化測試代碼。快速建模框架將傳統由人力編寫的代碼資源變成由框架生成，節約了人力成本，提高了開發效率。【專利說明】基於星形結構的通用業務模型的快速建模框架【
技術領域：
】:[0001]本發明設計了一種符合領域模型驅動設計原則的快速建模工具，其基本思路是:開發人員只需要手動定義後臺業務模型，框架對業務模型分析後，根據業務模型提供的信息，快速生成用戶能使用的，能完成增、刪、查、改、顯示、自動化測試等基本功能的代碼和資源，將原本需要消耗大量人力去編寫的基本功能的代碼資源，讓框架來自動生成，一方面降低了人力開發的成本，提高了建模的速度，同時使得開發人員能夠專注於特殊功能的開發。[0002]本框架基於的數據核心是一種基於星型結構的通用模型，我們稱為「服務實體(ServiceEntity)」。通過星型的數據結構來描述不同的業務邏輯，使得模型的結構實現了統一化，使得框架統一數據處理，自動化建模成為可能。我們基於該星形結構的業務模型，發明了這種自動化快速建模框架。一方面提供了公共接口，能夠處理不同業務模型的需求。二是基於模型本身提供的信息，能夠自動生成和模型結構相關的程序代碼，資源文件，自動化測試代碼和默認風格的用戶界面等等。相對於傳統的人工開發代碼的方式，開發效率進一步提聞。【
背景技術：
】:[0003]星形結構的通用業務模型簡介:領域驅動開發模式的提出，使得傳統的面向對象的軟體開發中引入了各個部門都能使用，能交流的統一領域模型，使得軟體開發更加面向實際業務需求。但是，在沒有統一的業務模型支持的框架下，實際的開發模型普遍是貧血的JAVA基本數據類(JAVAPOJO類)，開發模型和業務模型有不小的區別，需要花費大量精力實現兩種模型的轉換；另一方面，實際的業務模型結構是千差萬別的，在不同的業務場景，需要不同的方法來處理不同的業務模型，增加了開發和維護的難度。基於星形結構的通用業務模型，採用了通用的結構來描述不同場景的業務模型，一方面，使得開發模型和領域模型實現了合併，直接通過領域模型實現建模，體現而來領域驅動建模(DDD)的思想，同時，統一化的模型使得數據的處理和維護變得簡化，進一步使得統一框架來實現數據處理成為可能。[0004]本發明基於JAVA的平臺，基於星型結構的通用模型「服務實體」為核心。開發了一套自動化代碼和資源的生成工具，可以基於用戶定義的模型提供的信息，自動生成基於J2EE平臺軟體的代碼和相關資源，實現了軟體開發的生產線式生產，提高了軟體開發的效率。[0005]基於J2EE平臺的B/S軟體通常會有下面幾個部分組成:[0006]1.用戶視圖(UI):用戶通過IE瀏覽器能夠訪問到的頁面，通常為JSP頁面或者html頁面。在J2EE的軟體中，用戶通過視圖來展示和操作數據。視圖的特點是以某個或者某些數據模型為基礎，進行數據的展示或處理，這裡的數據模型，和我們前面提到的星形結構的業務數據模型不同，它是平坦結構，為視圖的顯示服務，稱為「視圖模型」。[0007]大部分的用戶視圖，可以分為兩種類型:列表視圖和編輯視圖。列表視圖的特點是數據源是視圖模型的集合，用來顯示滿足要求的一系列數據，用戶用列表視圖來搜索滿足要求的數據集合，並且可以選擇其中的某些數據，進行更詳細的編輯和查看工作。編輯視圖，數據源是某一個特定的視圖模型，編輯視圖對該模型進行編輯、查看，或者新建操作。[0008]2.表示控制層:支持用戶界面顯示的類，它實現了兩種模型的轉換，即複雜結構的業務模型和平坦的圖模型的相互轉換，以提供給視圖顯示，和後臺數據處理。另一方面，表示控制層對前臺請求進行分發，將前臺的請求，簡單處理後分發給後臺邏輯服務層進行進一步處理。[0009]3.邏輯服務層:用於核心的算法和業務處理控制。在服務實體的基本框架中，邏輯控制層的通過基本框架提供的方法，可以實現對服務實體模型數據的基本處理。[0010]4.資料庫持久層，指具體的關係資料庫中的資料庫表，用於持久化存放數據。在星形業務模型的框架下，模型每一個節點的數據，對應著一個關係資料庫表來存儲。[0011]5.數據訪問層，在應用軟體中，數據訪問層負責對資料庫進行操作，它對上面的應用層隔離了對資料庫的具體操作，提供了數據的增刪查改操作。在一些JAVA的ORM開源框架中，如hibernate和ibatis，資料庫訪問層還包括了資料庫和數據模型的映射配置文件。[0012]6.複雜結構的業務模型的建模，和平坦結構的視圖模型的建模。[0013]7.其它的資源，如視圖層中，控制視圖多語言顯示的資源文件，各個部分的自動化測試程序等等。[0014]【專利附圖】【附圖說明】中圖二描述了傳統的基於J2EE平臺，基於JAVA的POJO類為數據模型的軟體開發流程和工作量的情況。[0015]傳統的開發方式中，開發人員除了完成模型設計的工作外，上面描述的各個部分都需要手動編寫代碼，需要消耗大量的時間和精力。經過觀察和分析後，我們發現這樣的開發工作還存在著重複性:我們開發的軟體實現的功能，基本功能仍然是以數據模型為核心的的增、刪、查、改、數據顯示和數據間相互關係的操作，這些代碼的邏輯關係可以通過數據模型的結構和關係獲得。我們開發大部分代碼和資源文件的可以通過數據模型和視圖模型的結構和關係決定。根據這樣的原理，我們設計了一個圍繞著業務模型為核心的快速建模框架，通過模型得到的信息，自動化生成相關的代碼和資源文件。開發人員只需要將精力花在模型的設計上，同時也大大提高了建模的速度，一旦模型設計完成，就能直接生成用戶可以使用的應用。[0016]本快速建模框架的工作流程可以分為兩個階段:後臺資源生成和前臺資源生成。後臺資源生成中，用戶手動定義星形的業務模型，並且基於該模型，生成資源，如資料庫表的生成，資料庫表映射文件的生成，數據訪問層代碼的生成和邏輯服務層代碼的生成，同時為前臺生成默認的視圖模型。第二階段是前臺資源:用戶首先對自動生成的視圖模型進行手動調整，去掉不需要的欄位，調整欄位的命名。當視圖模型確定好之後，通過自動化建模工具，生成默認的JSP列表視圖和編輯、查看視圖，同時生成表示控制類，以實現視圖模型和後臺業務模型的裝換，同時，基於視圖模型生成視圖多語言控制的資源文件和各個部分的自動化測試代碼。【
發明內容】:[0017]星形結構的通用模型:服務實體(ServiceEntity)的介紹[0018]本發明設計的快速建模框架基礎是星型結構的通用模型，我們稱為「服務實體(ServiceEntity)」。通過統一的星型結構來描述不同的業務邏輯。在領域模型驅動開發的開發方式中，針對實際業務模型多變，維護結構各異的模型，需要消耗大量的人力、時間的問題，我們在領域驅動開發的模式下，提出了一種星形結構的通用模型，我們稱為「服務實體「，模型由唯一的根節點描述和模型基本信息，根節點下面可以接一對一，或者一對多的子節點，描述模型的附加信息。不同模型之間的相互引用關係，可以由引用型模型來實現。服務實體通用數據模型的提出，實現了模型結構的統一化，降低了建模的難度，也使得數據的統一處理成為可能。[0019]【專利附圖】【附圖說明】中，圖一，描述了一個簡單的基於服務實體結構的銷售訂單模型。和訂單本身密切相關的基本信息包括訂單號，訂單生成日期，經辦人，優先級別等等，定義為訂單的根節點信息。銷售訂單的附加信息，和訂單本身呈現I對多關係，比如參與方的信息，我們作為銷售訂單的子節點。常用的銷售訂單包含了兩個參與方，買方和買方，參與方的子節點包括的信息，應該有:參與方，主要聯繫人姓名。聯繫人電話，電子郵件，參與方角色(比如買方，賣方，供貨方，提貨方，付款方等等)。[0020]銷售訂單還包括了「銷售商品」的信息，和訂單呈現I對多的關係，也定義為子節點「銷售商品」。銷售商品中的商品自身信息應該是來自「商品」這個在銷售訂單外的獨立的模型，比如商品的名稱，商品的特點等等，「銷售商品」為引用型節點，引用自「商品」這個外部的服務實體模型，「銷售商品」自身包含的是和訂單中銷售活動相關的信息，比如用戶購買數量，購買單位等等。[0021]服務實體基本框架功能的介紹:[0022]圍繞服務實體的通用結構模型，我們提供了基礎的框架來支持建模和基本的數據處理。開發人員可以通過框架提供的基礎類，實現模型的定義，模型結構的描述。[0023]可以通過繼承框架提供的基礎類，通過少量的代碼，實現對資料庫不同類型數據訪問的功能，和數據處理的基本算法。[0024]【專利附圖】【附圖說明】中的圖三中可以看出，相對於傳統的面向對象的J2EE軟體開發，在引入了服務實體的基本框架後，建模開發的工作量得到了降低，由於模型結構的統一化，使得數據的處理也實現了統一化，開發人員針對每一個自定義的模型，在服務層，數據訪問層，只需要很少的代碼量描述模型的結構，數據的基本處理交給框架實現。然而在表示層，用戶視圖仍然需要開發不少的代碼實現用戶的需求。[0025]【專利附圖】【附圖說明】中，圖3描述了基於服務實體的數據模型和基本框架下的開發模式，和圖2中傳統J2EE的開發方式相比較，數據的統一化處理，使得數據訪問類和服務類的開發成本大大降低，基本的數據處理交給框架進行。但是表示層和視圖層的開發，仍然需要大量的人工編碼。[0026]基於服務實體的快速建模框架介紹:[0027]為了解決人工代碼開發效率低下，重複勞動的問題，我們發明了基於服務實體的快速建模框架，在服務實體基本框架能夠提供的基本功能，支持快速有效的建模和基本方法外。還增加了更多的快速建模工具，主要表現在:自動化代碼和相關資源的生成。快速建模工具，能夠根據用戶定義的服務實體模型，已經面向用戶界面(UI)的視圖模型，進行語義分析，生成一系列默認規則的代碼和相關資源，進一步提高快速建模的效率。自動化的代碼和資源生成分為兩個方面:1，是底層代碼的生成，即用戶模型結構描述代碼，數據訪問代碼，資料庫表和服務層代碼的生成。2是用戶界面代碼的生成，包括了JSP頁面，properties資源文件，和表示層控制器類的代碼生成。[0028]快速框架的基本工作原理和流程:[0029]快速建模框架的工作流程可以分成兩個階段:底層代碼資源生成，和表示層、視圖層代碼資源生成。[0030]底層代碼和資源的自動生成:[0031]首先開發人員根據業務需求，手動定義服務實體模型，包括模型由哪些節點構成，節點包含哪些欄位，節點間的關係，和外部節點的引用等等。[0032]自動建模框架首先通過JAVA的動態反射功能，將服務實體每個節點定義的所有欄位分別解析出來，節點會生成後臺資料庫表，一個節點，正好也是二維關係結構，映射成一個資料庫表，節點所有欄位，成為資料庫組成的欄位。框架根據這些信息，對每一個節點動態生成一個SQL「createtable」的建表命令，框架運行SQL建表指令，在目標資料庫中建立一系列關係資料庫表。【專利附圖】【附圖說明】中，圖4表示了框架根據模型中的每個節點動態生成資料庫表的對應關係。同時根據當前的ORM框架，生成資料庫表的映射配置文件:每一個服務實體，生成一個資料庫表的映射配置文件，包含了模型所有節點類和資料庫表的映射關係。[0033]同時，框架生成相應的數據模型配置類ConfigP1xy類，用來描述服務實體的結構:服務實體由哪些節點構成，節點間的相互關係。模型配置類提供的模型結構信息會在運行態時被其他類使用，以實現數據的處理。[0034]另一方面，框架生成和新定義的服務實體相對應的數據訪問類DAO類，載入模型配置類類作為自定義屬性，並且繼承基本框架提供的標準數據訪問DAO類。[0035]對服務層，生成新的服務類，並且載入DAO類和ConfigureProxy類作為自定義屬性，繼承基本框架提供的標準服務類。實現基本的數據算法。[0036]表示層、視圖層的代碼資源生成:[0037]相對於底層代碼，用戶界面的需求變化更大，代碼和資源的自動生成難度更大。一方面用戶對視圖界面的需求變化較大，形式多樣，另一方面，視圖基於的數據模型相對於底層來說，總類更豐富，比如很多視圖模型是由多個底層模型組合而成。[0038]通過長期觀察總結後，我們發現B/S軟體的用戶界面絕大部分可以分為兩個種類:I列表視圖，2編輯視圖。列表視圖特點是它基於的數據源是視圖模型的集合，以集合的方式展示滿足用戶搜索要求的一系列數據，用戶可以進行查詢，並且選中集合中的某些數據，進行進一步的編輯和查看。編輯視圖是基於某一個特定的視圖模型，進行編輯、查看、或者新建的操作。[0039]這兩個視圖可以相互嵌套，比如，一個編輯視圖中可以嵌套對於子節點的列表視圖。[0040]視圖的數據源是視圖模型，它和底層的複雜結構的業務模型不同，為了支持顯示，數據模型都是平坦的結構，但另一方面，視圖模型和業務模型有密切的關係:視圖模型都是通過對底層「服務實體」模型進行拆分和組合而成。當視圖模型包含多個底層模型的節點時，總是通過某種一比一的對應關係，將各個節點串接到一起。[0041]不同的業務場景中的列表視圖和編輯視圖是相互不同的，但實際上，視圖模型決定了它們的形式:列表視圖和編輯視圖的基本功能從根本上還是對視圖模型進行增刪查改。不管是列表視圖還是編輯實體，只要能夠確定它們的視圖模型，就能決定視圖的顯示形式。基於上述理論，我們可以通過開發人員簡單的定義工作，定義視圖模型的構成，基於這樣的信息，生成基於該視圖模型的默認顯示層、視圖層資源。而視圖模型是由業務模型的每個節點組合而成，基於這樣的原理，框架可以把一個服務實體的業務模型，節點進行「平坦化」組合，生成默認的視圖模型。[0042]表示層、視圖層代碼資源生成的流程和原理如下:[0043]1.「視圖模型」的生成。[0044]開發人員首先要定義視圖模型，並且確定和後臺業務模型的對應關係。[0045]由於視圖模型是由業務模型的節點組合而來，開發人員不需要完全手動定義視圖模型，框架可以根據業務模型，生成由所有節點「平坦化」組合而成的默認的視圖模型，並且自動建立和業務模型節點的對應關係。默認的視圖模型生成後，開發人員可以手動進行調整，刪除不需要的欄位，修改欄位的命名方式等等。[0046]表示層的控制器Controller的作用是支持視圖類的顯示，它的作用，一方面是對視圖提交的需求進行簡單處理後分發給後臺進行進一步處理，另一方面，控制器實現了視圖模型和業務模型的相互轉換。而視圖模型中包含了和業務模型的轉換關係，框架可以根據這些信息，自動生成默認的控制器代碼，完成視圖模型和業務模型轉換。和支持對視圖模型增刪查改的操作。[0047]在快速建模框架中，視圖模型和後臺業務模型的轉換關係包含這樣的信息:視圖模型包含了那些實體模型的節點，哪一個節點為「基礎節點(hostnode)」出發，如何通過某種一對一的關係，遍歷到下一個後臺節點。我們稱為「關係路線圖」。在框架生成的默認視圖模型中，開發人員可以提交「關係路線圖」給框架，框架從路線圖定義的「基礎節點」開始。將自定義屬性解析出來，作為視圖模型的屬性，並且通過框架提供的註解(annotat1n)，表明每一個節點屬性和後臺節點屬性的映射關係。同時，框架還會自動生成一個和視圖模型一對一的配置映射類(ConfigureMap)，來描述該視圖模型包含了那些後臺模型的節點和各個節點的對應關係，該類是用來輔助自動生成表示層視圖層代碼資源。框架生成的視圖模型為默認的視圖模型，開發人員還需要根據實際業務需要，對默認的實體模型進行調整，刪除掉不需要的欄位，調整命名等。[0048]2.表示層控制器和視圖等資源的生成。[0049]在視圖模型生成調整好後，開發人員調用快速框架，生成表示層、視圖層的各個代碼和資源，生成完畢後，默認的開發完畢，經過簡單的調式便可以使用。[0050]表示層的控制器(Controller)的代碼生成的核心和難點在於兩個部分:一是基於後臺「服務實體「，這個業務模型的後臺數據的抽取部分，即獲取後臺的原始數據源，二是後臺數據和視圖模型數據的轉換部分，即把元素業務數據轉換為視圖模型的數據。[0051]後臺數據抽取部分:需要確定當前的視圖數據，需要使用到的元素數據，怎麼從後臺取得，需要哪些「服務實體」的節點數據，各個節點的數據是怎麼樣串聯起來的。[0052]後臺數據的抽取部分的實現:[0053]根據前面所述，視圖模型在定義時，開發人員需要定義「關係路線圖」，根據關係路線圖定義的「基礎節點」出發，通過路線圖中描述的每個節點和下一個節點的轉換關係，逐步便利所有的節點，取得所有的元素數據。[0054]關係路線圖「基礎節點」出發，通過一對一的映射關係，不斷地連接到下一個節點，這種一對一的關係，在我們的快速框架中，有下面幾種形式，對應生成不同的轉換代碼:[0055]a.「T0_PARENT」:表示，從目標節點的角度看來，源節點到目標節點的映射關係為:源節點是父節點，目標節點是子節點。一般來說，父節點和子節點的關係可以是一對多的，但是因為視圖模型是平坦結構，這裡的對應關係也必須是一對一的，所以，「T0_PARENT」的對應關係，只能處理一對一的父子節點關係。系統在這種關係下生成的視圖轉換代碼:通過目標節點的屬性parentUUID等於源節點的屬性UUID，根據源節點的實例，獲得目標節點實例。[0056]下面給出一個生成的實例代碼:目標節點是VehicleHost(車主信息)，源節點:VhicleInfoRoot是車輛信息的根節點，也是VehicleHost的父節點，它們是一比一的父子對應關係。從VhicleInfoRoot節點到VehicleHost節點採用「T0_PARENT」，生成的代碼如下。[0057]VehicleHostvehiclehost=(VhicleHost)vehiclelnfoManager.getEntityByKey(vehiclelnfoRoot.getUuid,「parentUUID」，「VhicleHost」，null)；[0058]生成的代碼中，通過框架的註冊服務實體工具，取得了服務視圖VehicleInfo對應的服務類VehicleManager,通過調用它的方法getEntityByKey,將父節點vehiclelnfoRoot的uuid作為輸入參賽,獲得子節點的實例。[0059]另外，當父子節點屬性是一對多時，應該採用額外的限制條件來取得一比一的目標節點實例，需要開發人員手動編碼，則應採用後面提到的「OTHERS」對應關係。[0060]b.「T0_CHILD」:表示，從目標節點的角度看來，源節點到目標節點的映射關係，源節點是子節點，目標節點是父節點。這種關係在星型結構的服務實體中，一定是一對一的，生成的視圖轉換代碼:通過目標節點的屬性UUID等於源節點的屬性parentUUID，根據源節點的實例，獲得目標節點實例。[0061]基於上面的例子,如果是從VehicleHost連接到VehiclelnfoRoot則生成的實例代石馬:VehiclelnfoRootvehiclelnfoRoot=(VehiclelnfoRoot)vehiclelnfoManager.getEntityByKey(vehiclelnfoRoot.getParentUuid，「UUID」，「Root」,null)。[0062]c.「REF_T0_S0URCE」:這種映射關係表示了源節點到目標節點採用的是引用關係，需要調用服務層的方法通用方法getRefTarget，將源節點的實例變量作為輸入參數，獲得目標節點的實例變量。[0063]d.「OTHERS」:其它的轉換方式，需要開發人員手動設置限制條件，比如一對多的父子關係時，需要開發人員手動設置限制條件，利用源節點的實例變量，獲得一對一的目標節點實例變量。框架在這裡會生成註解，提示開發人員在註解下面添加自己的轉換代碼。[0064]後臺數據和視圖模型數據的轉換部分的實現:[0065]開發人員自定義的視圖模型類中，所有視圖模型屬性，通過注釋，描述了和後臺業務模型的關係，即屬性和業務模型哪個節點，哪個屬性相對應。在自動生成控制器代碼時，框架會動態搜索開發人員定義的視圖模型類，將所有的屬性遍歷，根據屬性設置的註解，找到對應的服務實體節點的屬性，實現前後臺代碼的轉換邏輯。【專利附圖】【附圖說明】中，圖5描述了框架基於開發人員定義的「關係路線圖」，生成視圖模型的流程圖。[0066]3.前臺視圖資源的生成。[0067]框架會對視圖模型進行分析，生成列表視圖和編輯視圖，視圖模型中的欄位，會反應到視圖中，對每個欄位進行顯示或者編輯，開發人員對對生成的視圖進行調整，刪除不需要的欄位等等。[0068]同時，框架基於視圖模型的各個屬性，生成properties的多語言資源文件，資源文件中的欄位，控制著的視圖模型的欄位在客戶端的顯示，目前默認能生成中，英文的資源文件，框架還會和已有的資源庫進行匹配，找出已有默認的欄位的多語言標籤，其他的欄位需要開發人員手動翻譯，並在資源文件中配置。[0069]當所有開發的代碼生成完畢後，開發人員開可以通過框架生成相關的自動化測試類，比如後臺的模塊，框架利用會讀取服務層和數據訪問層類的方法，並基於方法生成JUnit或者UnitilsJUnit4的自動測試類。另一方面，框架可以通過視圖模型，生成視圖類的對應測試代碼。[0070]【專利附圖】【附圖說明】中，圖4給出了基於服務實體星形結構的通用模型快速建模框架的工作流程圖。通過對比圖2，圖3，可以看出，在快速建模框架的下，所有需要大量人工編碼的工作都交給框架實現，開發人員只要建立數據模型，並給出配置信息，框架就可以生成代碼實現業務需求，大大提高了建模的效率。【專利附圖】【附圖說明】[0071]圖1描述了一個簡單的「銷售訂單」為實例的服務實體模型的星形結構。[0072]圖2描述了傳統J2EE軟體的開發流程和開發模式，以及工作量的情況。[0073]圖3描述了基於服務實體通用模型和基本框架的J2EE軟體的開發流程和開發模式，以及工作量的情況。[0074]圖4描述了快速建模框架，基於業務模型的各個節點，生成底層資料庫表、ORM映射文件等資源的原理圖。[0075]圖5描述了快速建模框架，根據服務實體模型和「關係路線圖」，建立出對應的視圖模型的原理圖。[0076]圖6描述了快速建模框架的整個工作流程和原理。【具體實施方式】[0077]1.系統準備:首先需要在JAVA工程中引入基本框架的工程包service,platform,jar,以支持建模和基本功能，在此基礎上，引入快速建模框架的工程包service,installat1n,jar。[0078]2.服務實體模型建模:設計服務實體的業務模型，設計人員需要通過需求分析，建立領域模型，即服務實體模型，確定服務實體由哪些節點組成，這些節點之間的相互關係，以及和外界節點的關係。然後對每一個節點建立服務實體類，繼承框架提供的基礎類:ServiceEntityNode.[0079]3.生成後臺代碼和相關資源:寫一段測試用例代碼，調用快速建模框架的方法ServiceEntityInstalIat1nComProxy.registerSE(ListselnsList)throwsServiceEntitylnstallat1nExcept1n[0080]下面給出一段示例代碼，用於調用這個快速建模方法:[0081]【權利要求】1.一種基於星型結構的通用業務模型為基礎的快速建模框架，用於J2EE平臺的B/S(瀏覽器/伺服器)軟體開發，自動化生成代碼資源。開發人員定義好星型結構的業務模型後，業務模型定義包括組成模型的各個節點、節點的所有欄位，以及節點間的相互關係。框架可以解析模型的信息，自動生成能滿足面向用戶對數據增、刪、查、改、顯示的基本應用，以及自動化測試的所有代碼資源，這些資源包括:關係資料庫表，資料庫映射文件，支持數據持久層操作的數據訪問類，提供增刪查改和日誌，權限控制基本功能的數據服務類，默認風格的視圖頁面和表示層控制類，支持視圖頁面多語言顯示的資源文件，及各部分的自動化測試代碼。2.根據權利要求1描述的星型結構的業務模型，框架可以自動解析模型的結構，包括業務模型的各個節點和節點的組成欄位，每一個節點生成一條創建資料庫表的SQL語句，用於關係資料庫中創建一張關係資料庫表，將節點中的每個欄位自動映射成資料庫表的列，並且生成模型-關係資料庫表映射文件。3.根據權利要求1描述的數據模型，包括星型結構的業務模型和平坦結構的視圖模型。其中，業務模型由開發人員手動定義，視圖模型是框架基於業務模型生成，再由開發人員進行手動調整，並且自動帶有用JAVA註解(annotat1n)描述的和業務模型的關係。框架基於兩種模型的關係，自動生成表示層控制類代碼，完成兩種模型的轉換和支持視圖顯示。4.根據權利要求1所描述的自動生成的默認風格的JSP視圖頁面，包括列表視圖和編輯視圖，列表視圖數據源基於視圖模型的集合，實現面向客戶的數據查詢，基本顯示功能，編輯視圖數據源基於特定選中的一個視圖模型，實現面向客戶的編輯，詳細查看和新建功能。視圖能夠顯示或編輯視圖模型的所有欄位，並且自動生成控制多語言顯示的資源文件，包含了所有欄位。【文檔編號】G06F9/44GK104049957SQ201310079249【公開日】2014年9月17日申請日期:2013年3月13日優先權日:2013年3月13日【發明者】張航申請人:成都泰聚泰科技有限公司