孟凡輝，王宏智，吳 旭

(中國電子科技集團公司第四十五研究所，北京 100176)

近年來，隨著工業(yè)激光器產(chǎn)業(yè)的發(fā)展和技術進步，激光加工應用技術在國內得到了迅猛發(fā)展。為提高加工數(shù)據(jù)導入效率，減少數(shù)據(jù)輸入人為誤差，目前大多數(shù)的激光加工設備主控軟件均包含了CAD數(shù)據(jù)圖形文件自動導入功能。數(shù)據(jù)圖形文件一般可分為矢量和位圖兩種格式。位圖加工一般常見于動態(tài)光路振鏡掃描系統(tǒng)的打標、雕刻等應用中，而矢量加工則更廣泛地應用于激光劃片、劃線、切割、鉆孔和結構化成型等靜、動態(tài)光路加工領域。

矢量文件格式中，以 PLT、HPGL、HPGL2、DWGTM和DXF等格式最為常見。受AutoCAD軟件龐大的用戶群影響，DWGTM、DXF已然成為二維CAD設計繪圖的事實標準，其中DWGTM格式是AutoCAD的專用內部文件格式。雖然Autodesk公司提供的ObjectARX二次開發(fā)包可以對DWG文件讀寫，但是開發(fā)出來的程序不能脫離宿主應用程序AutoCAD運行。ODA(Open Design Alliance)組織通過逆向工程技術獲取了DWG格式的大部分技術細節(jié)，并推出了TeighaTM(曾用名OpenDWG、DWGDirect)C++API類庫用于DWG數(shù)據(jù)讀寫，不過一般公司需要經(jīng)過嚴格的申請入會流程才能得到使用許可。因此，相對開放的DXF(繪圖交換格式)文件標準在各CAD/CAM軟件系統(tǒng)中更為流行。DXF文件分為ASCII和二進制兩種格式，本文僅討論應用更為廣泛的ASCII格式。

DXF數(shù)據(jù)解析通常被認為是一件繁瑣的任務，程序員需要深入理解業(yè)務領域模型——DXF文件詳細規(guī)范，同時設計解析器架構并精心編碼，另外還要考慮兼容性問題。實際應用開發(fā)中多是采用輕量級DXF數(shù)據(jù)解析開發(fā)包，比如開源社區(qū)知名的dxflib[1]類庫，結合具體應用執(zhí)行部分數(shù)據(jù)解析，僅解析出需要的數(shù)據(jù)并進行數(shù)據(jù)處理。本文提出了一種基于Boost Spirit解析器架構的新方法，程序員僅需要專注于特定領域建模，無需過多考慮代碼的架構及編碼，即可實現(xiàn)簡潔、高效的DXF文件解析器。

1 特定領域建模

特定領域建模 (Domain-specific modeling,DSM)，是近些年來軟件工程領域的一種新的模型驅動開發(fā)方法學，旨在大幅度的提高開發(fā)效率并簡化軟件開發(fā)。它試圖使用特定領域語言(DSL)描述系統(tǒng)，DSL傾向于支持比通用建模語言 (如UML)更高級別的抽象。DSM往往還包括自動代碼生成的想法：直接從DSM模型自動創(chuàng)建可執(zhí)行源代碼。擺脫手工創(chuàng)建和維護源代碼，意味著DSM可以顯著提高開發(fā)人員的工作效率。與手工編碼相比，自動生成的代碼比較可靠、生成的程序可減少缺陷從而提高代碼質量[2]。在近十年中，早期采用DSM的軟件人員已經(jīng)提高了5到10倍的生產(chǎn)率。微軟也自VS2005 SDK開始提供了DSL[3]。EBNF(Extended Backus-Naur Form,擴展巴科斯—諾爾范式)即為可應用于特定領域建模的一種元模型建模語言，而Boost Spirit類庫實現(xiàn)的內聯(lián)EBNF語法與語義API直接形成了創(chuàng)建解析器生成器的DSEL(特定領域嵌入式語言)。

1.1 Boost Spirit解析器框架

Boost Spirit是一個利用模板元編程技術實現(xiàn)的面向對象的遞歸下降解析器生成框架。借助于模板元編程技術的靜態(tài)多態(tài)特性、模塊化和可擴展性，表達式模板使編程人員能夠在C++代碼中使用近似于EBNF范式的文法，即內聯(lián)的EBNF語法規(guī)范可以自由地混合于其它C++代碼中，減少了傳統(tǒng)編譯器生成器(如YACC、Bison和ANTLR)中將EBNF文法轉換為C、C++代碼的額外步驟。[4]

Spirit類庫涉及了幾個基本概念，包括Rule(規(guī)則)、Scanner(掃描器)、Parser(解析器)、Match(匹配)、Semantic Action(語義動作)等，如圖 1 所示，它們相互關聯(lián)，功能交織構成了整個框架?？蚣艿暮诵氖墙馕銎?，它真正完成從頭到尾識別由掃描器讀入的線性數(shù)據(jù)流的工作。解析器嘗試以一系列完整定義的規(guī)范來匹配輸入，這些規(guī)范被稱為語法規(guī)則。解析器通過匹配對象來通知客戶程序分析的成功與否。成功匹配時，將執(zhí)行客戶程序提供的語義動作。最后，語義動作從解析器中獲取結構化的信息，這些信息依賴于解析器傳遞的數(shù)據(jù)和解析器所處的語境層次[4]。

2.2 DXF文件結構[5]

DXF文件本質上由代碼及其關聯(lián)值對組成。代碼(通常稱為Group Code,組碼)表明其后的值的類型。使用這些組碼和值對，可以將DXF文件組織到由記錄組成的區(qū)域中，這些記錄由組碼和數(shù)據(jù)值組成。在DXF文件中，每個組碼和值都各占一行。每段都以一個后跟字符串SECTION的組碼0開始，其后是組碼2和表示該段名稱的字符串(如HEADER)。每段都由定義其元素的組碼和值組成。每段都以一個后跟字符串ENDSEC的組碼0結束。DXF文件完整結構如表1所示。

圖1 Spirit框架基本概念

表1 DXF文件結構組成

2.3 DXF文法模型

實際上，DXF文本文件模型可以EBNF文法精確地表示，例如頂層非終結符dxffile的產(chǎn)生式規(guī)則可以定義如下：

限于篇幅，以上省略了除header_section以外其它幾個段、實數(shù)、整數(shù)和字符串等非終結符的產(chǎn)生式規(guī)則。關于EBNF文法的更多細節(jié)，請參考ISO/IEC 14977 標準[6]。

以上文法在Spirit程序中對應編碼如下所示：

HEADER=str_p("HEADER")>>eol_p;

可以看到，Spirit重載了C++語法中的>>、*、+、!和|等操作符來表示EBNF語法規(guī)則，其中eol_p、char_p、str_p、print_p 等內建原語(Primitives)作為基本構建塊以形成更加復雜的產(chǎn)生式規(guī)則。

3 應用實踐

本部分將舉例闡釋本文所描述的Spirit類庫為基礎的DXF文件解析方法。為敘述方便并突出重點，此處DXF文件中僅包含線段和圓兩種幾何實體類型。實際應用中，可能還需要考慮圓弧、多義線和BLOCK塊等幾何實體類型。

3.1 基本數(shù)據(jù)結構

圖層和幾何實體均有圖層名稱、線型、顏色和線寬等屬性，其UML類圖如圖2所示。

圖2 幾何實體及圖層相關類圖

其中，定義了以下圖層和實體指針兩個容器類型以方便數(shù)據(jù)存儲及后續(xù)處理。

3.2 語義動作

語義動作通常具有如下形式：expr[action]，即表達式后跟著符號[]，方括號內為語義動作。語義動作可以是符合一定接口的自定義回調函數(shù)或仿函數(shù)(functor)，同時Spirit框架內部也包含幾個最為常用的預定義仿函數(shù)。在下面的circle規(guī)則編碼中，預定義仿函數(shù)assign()用于將解析器傳遞過來的圓的各種屬性值(所屬圖層、線寬、顏色、線型、圓心坐標和半徑等)賦給actions類中的相應成員變量。

其中，!表示對其后的表達式匹配0次或1次，這是為應對DXF文法的多變性所必需的，以提高代碼的健壯性。如下定義AddCircle仿函數(shù)，以表示匹配circle解析器時的語義動作。

可以參考AddCircle仿函數(shù)的成員操作符()簽名，定義更多的仿函數(shù)，例如以下代碼所示的

語義動作仿函數(shù)通常較多，為此可以抽象出一個語義動作管理器類Actions，即將各仿函數(shù)作為管理器類的成員變量，由其集中統(tǒng)一管理，其UML類圖如圖3所示。

圖3 Actions類圖

3.3 語法規(guī)則

Spirit用戶可以基于其框架設計定制符合應用需求的完備的語法規(guī)則。以下代碼創(chuàng)建一個從預定義grammar類繼承的派生類DXFgrammar。grammar類是一個模板類，其被派生類DXFgrammar參數(shù)化。而為了便于繁多語義動作的管理，DXFgrammar作為模板類又被語義動作管理器類Actions參數(shù)化。

其中，DXFgrammar類包含一個嵌套的類型名為ScannerT的模板結構體definition，語法規(guī)則在其構造函數(shù)中定義，實際的語法self作為引用參數(shù)傳遞至構造函數(shù)內部。Definition必須提供成員函數(shù)start()，以表示規(guī)則入口點。此處，dxffile為Start規(guī)則，規(guī)則展開具體代碼可參考2.3節(jié)。

至此，dxf文件解析函數(shù)可以實現(xiàn)如下。其中，數(shù)據(jù)結構parse_info可以用來診斷解析過程中的錯誤，其hit字段表示解析是否成功，而length字段表示匹配長度。

3.4 編譯運行情況說明

本實例源代碼在Windows XP操作系統(tǒng)和VC6 SP6開發(fā)工具下編譯通過。使用的Boost Spirit類庫為1.6.4版本，這是支持VC6的最后一個版本。因為VC6自帶的標準模板庫Plauger STL對模板元編程技術的支持不夠完善，建議使用STLport STL。

利用AutoCAD軟件幾個不同版本和第三方CAD工具導出大量DXF測試文件，對程序執(zhí)行測試，均能正常運行且解析結果無誤，文件解析兼容性也得到了部分驗證。

4 結束語

在面對諸如本文所述的DXF文件解析之類的軟件設計問題時，大多數(shù)程序員面臨的挑戰(zhàn)是，難于精確捕捉、識別問題域模型。DXF相對復雜的文法規(guī)則，使得傳統(tǒng)純手工編碼時，問題域相關代碼常散布于多處源代碼之中，最終導致了脆弱與僵化的軟件設計。而面向特定領域建模的軟件設計，使得程序員能夠在設計階段居于更高的層次來關注、審視問題域，避免過早迷失于詳細編碼之中。

利用Spirit，可以方便地將DXF EBNF文法規(guī)則完全建模于Spirit語法派生類之中，從而降低了問題域核心模型代碼與其余代碼的耦合，極大地方便了程序編寫、調試、測試和后期代碼維護。得益于部分代碼自動生成，對于一個輕量級DXF數(shù)據(jù)解析應用，基于Spirit的解決方案其源代碼僅需千余行，這通常為傳統(tǒng)純手工編碼方案所需源代碼行數(shù)的1/10～1/30，因而也顯著提高了程序員的生產(chǎn)效率。目前，Spirit類庫已更新到2.5版本，包含了對二進制數(shù)據(jù)流的匹配解析功能，因而實際上，本文所展示的技術可以推廣應用于適于EBNF文法規(guī)則精確表述的多種文本或二進制CAD/CAM數(shù)據(jù)格式(如 RS-274X、HPGL2、Excellon2、Sieb&Meyer、ODB++和IPC-2581等)文件的解析處理。

[1] dxflib library doc[DB/OL]，http://www.ribbonsoft.com/en/dxflib-documentation，2012.

[2] Wikipedia，Domain-specific modeling[DB/OL]，http://en.wikipedia.org/wiki/Domain-specific_modeling，2011-10-17.

[3] Kelly，S.and Tolvanen，J.-P.，Domain-Specific Modeling:Enabling Full Code Generation，John Wiley&Sons，New Jersey.2008.

[4] Joelde Guzman，Spiritframework documentation[DB/OL]，http://boost-spirit.com/distrib/spirit_1_6_4/libs/spirit/index.html，Sep.2002.

[5] Autodesk公司，DXF 參考手冊[DB/OL]，http://docs.autodesk.com/ACD/2011/CHS/landing.html，2011.

[6] ISO/IEC 14977，Information technology-Syntactic metalanguage-Extended BNF，International Organization for Standardization[S]，1996.