OCAF數據的分配-Distribution of Data Through OCAF Tree
Posted on 2012-11-24 13:52 eryar 閱讀(2488) 評論(0) 編輯 收藏 引用 所屬分類: 2.OpenCASCADEDistribution of Data Through OCAF Tree
OCAF數據的分配
一、作者注 Annotation
本文檔主要用于說明OCAF(Open CASCADE Application Framework)中數據模型的選擇問題。另外,以一個例子來說明OCAF的標準屬性的使用和創建OCAF新的屬性。
作者假設讀者已經熟悉OCAF的一些基礎知識。
二、簡介 Introduction
OCAF(Open CASCADE Application Framework)是為快速程序開發(Rapid Application Development)而提供的一些類。OCAF實現如下功能:撤銷、重做、復制、剪切、粘貼、保存文檔、打開文檔等等。
OCAF基于標簽-屬性(Label-Attribute)模型。標簽組成樹。在OCAF文檔中,屬性用于保存用戶的數據,且屬性綁定在標簽上。
本文檔描述了數據保存在OCAF文檔中應考慮的注意事項:
1. 是使用標準屬性還是創建自定義的新的屬性?
2. 如何優化數據的存儲來提高時間和空間上效率,和程序的運行速度?
三、概述Description
當開始設計基于OCAF的程序時,對于數據的存儲通常要面臨這樣的選擇:是使用標準屬性還是根據需要自己創建新的屬性?在給出這個問題的答案之前,先簡要回顧一下OCAF的標準屬性:
所有基本數據類型都在OCAF中表示為標準屬性:
u 整數Integer;
u 實數Double;
u 字符串String;
u 整數數組Array of integer values;
u 實數數組Array of double values;
u 字符串數組Array of string values;
u 拓樸形狀Topological shapes;
除了拓樸形狀屬性外,其它屬性都在Toolkit TKLCAF的Package TDataStd中:
u 整數屬性:TDataStd_Integer;
u 實數屬性:TDataStd_Real;
u 字符串屬性:TDataStd_AsciiString、TDataStd_Expression;
u 整數數組:TDataStd_IntegerArray;
u 實數數組:TDataStd_RealArray;
u 字符串數組:TDataStd_ExtStringArray;
細心的讀者可能發現沒有Boolean類型,因為通常用Integer來代替了。
所以使用OCAF的標準屬性可以用來定義任何模型。但是這樣定義對內存的使用、程序運行速度、及使用的方便性上來說是否合適?還是要根據特定的模型具體分析。
OCAF只有一個限制:每種屬性一個標簽只能包含一個。即只能給一個標簽定義一個整數屬性,一個實數屬性等。所以有必要考慮程序數據樹的設計。例如:一個標簽有幾個實數值,是把這幾個實數值分別存儲到子標簽中還是使用一個實數數組來存儲,都是需要事先考慮周全。
考慮同一個模型在OCAF中不同的存儲方法,并分析每種方法的優缺點。
四、不同方法的比較與分析Comparison and Analysis of Approaches
這里描述了定義模型的兩種方式:一種是基于OCAF標準屬性;另一種是創建新的屬性。
A load is distributed through the shape。量度由坐標(x, y, z)來定義。Load通過由每點的局部坐標系投影到X-、Y-和Z-軸上來表示。一個由局部坐標系轉換到世界坐標系的矩陣也可能需要,但這是可選的。
所以,每個點上有15個數值需要被存儲。若這樣的點有100000個,則在OCAF文檔中需要存儲1500000個數值。
第一種方式是使用OCAF的標準屬性。使用標準屬性也有幾種不同的方式:
1. 使用實數數組屬性來存儲這1500000個數,并將這個實數數組綁定到一個標簽;如下圖1所示。
2. 將每組15個值用一個實數數組屬性存儲,并將每個實數數組綁定到每個標簽上;如下圖2所示。
3. 使用實數數組屬性來存儲每個點的(X、Y、Z)3個坐標值,并將其綁定到標簽;局部坐標系到世界坐標系的投影軸的3個值也使用實數數組屬性來存儲,并將其綁定到子標簽上;同樣地,變換坐標系的9個值也用實數數組屬性存儲,并也將其綁定到子標簽上;如下圖3所示。
4. 當然,其它方法也是可行的。
圖1 使用一個數組屬性來存儲所有數據
第一種方法是把所有數據都用一個實數數組屬性來存儲。這種方法的優點是節省了初始內存,并且易于實現。但是數據的訪問很不方便,還需要為取得相應數據來定個專門的類來處理。如果程序需要對這些值進行編輯,這就意味著整個數組在每次編輯時都需要備份,這會導致內存的使用快速增加。所以,這種方式可能只能用于數據不需要編輯的程序。
圖2 為每個數據點使用一個數組屬性及一個標簽
考慮每個數據點作為一個標簽的第二種方式。這種情況需要創建100000個標簽,每個標簽上綁定了一個包含15個實數的實數數組屬性。如圖2所示。
現在數據的編輯要安全些,且內存的使用也在考慮之中。每個數據點的編輯(任意值:point coordinate, load, and so on)的備份也只是一個小的實數數組。但是這種結構需要更多的內存空間,因為使用很多的標簽和屬性。
另外,數據的訪問還是不方便,也需要一個類來處理數據的訪問。
圖3 存儲數據到不同的數組屬性中
第三種方式的數據存儲如圖3所示。在這種情況下引入了子標簽,數據的訪問變得容易了,不需要為此專門設計一個類來訪問所需要的數據了。
這種方式一方面為屬性分配更多的內存;另一方面,在數據編輯需要備份時節省了內存。所以,若程序中所有數據都可以修改,則這種方式會更好。
圖4 使用自定義屬性
在下結論之前,考慮使用自定義屬性來表示這個模型的方式。
例如,可以將每組15個值作為一個自定義屬性綁定到標簽上。與使用標準屬性的第三種方式相比,自定義屬性的方法使用更少的內存,因為只使用了一個屬性而不是三個屬性。
使用標準屬性的第二種方式還有些不足:當編輯數據時,每個點的所有數據都被備份,不管有些數據有沒有被修改。
當有些不可編輯的數據,最好將之與可編輯的數據分開存儲。數據編輯備份時將不會對不可編輯的數據進行備份,這樣在編輯時內存就會有所減少了。
五、結論Conclusion
當確定選擇使用哪種數據模型時,需要考慮程序響應時間、內存分配與內存在事務處理中的使用。大部分模型只使用OCAF的標準屬性已經足夠。其它需要特別處理的模型需要定義OCAF新屬性。