Visitor 패턴

Visitor 패턴은 AST(Abstract Syntax Tree)와 같은 자료구조를 순회하면서 필요한 작업을 정의하기에 용이하다. 이를 처음으로 접하게 된 것은 CEC(Comlumbia Esterel Compiler)의 소스코드를 분석할때였다. CEC는 Esterel 소스코드를 파싱하여 이를 XML 형태의 IR(Intermediate Representation)로 저장한다. CEC는 C++ 언어로 프로그램되어 있는데 XML 형태의 IR은 C++의 클래스 구조로 구성된 AST에 대응된다.

Esterel Source Code (Text) – AST (C++ Classes) – IR (XML)


배경은 이쯤에서 정리하고 본론으로 들어가보자. Esterel 언어는 하드웨어 언어인 Verilog로 컴파일되기도 하고 소프트웨어 언어인 C로 컴파일 되기도 하는 신기한(?)언어인데, Esterel 소스코드로 부터 C언어 코드가 나오기까지 IR을 XML 포맷으로 유지하며 여러단계의 독립적인 프로그램을 거치게 된다. 이때마다 XML 파일을 읽어 AST를 구축한 후 Visitor 패턴을 이용해 AST를 순회하며 필요한 작업을 수행한다. 물론 그러한 작업에 의해 AST가 수정되면 수정된 상태의 AST가 다시 XML형태로 저장된다.

Esterel Source Code – Parser – Expander – Dismantler – GRC synthesizer – C generator – C Source code


필자가 하고 있는 일은 동시설계 개발환경에서 Esterel 언어를 기반으로 임베디드 시스템을 정의하는 방법론을 제시하고 그 것으로 부터 임베디드 시스템 구현에 필요한 여러가지 인터페이스를 자동으로 생성하는 것이다. 임베디드 시스템을 XML 형태의 언어로 정의하도록 하고 이를 파싱하여 저장하는 나름의(?) AST를 자바 클래스로 구축하였다. 인터페이스 생성등 다양한 작업이 AST를 기반으로 이루어질 것 이며, 여기서는 AST에 저장되어 있는 정보를 다시 XML로 출력하는 프로그램을 예로 들어 Visitor 패턴을 설명하려고 한다.  

모든 AST의 클래스들은 다음과 같은 AbstractSpec 추상클래스를 상속한다. 여기에는 Visitor 패턴을 위한 메서드인 welcome 추상 메서드가 정의되어 있다.

package kr.ac.kaist.vicode.spec;
public abstract class AbstractSpec {
  public abstract void welcome(Visitor v);
}
그리고 당연히 모든 AST 노드에 해당하는 클래스들은 welcome 메서드를 정의해야 하는데 그 내용은 모두 다음과 같이 동일하다. 굳이 설명하자면 파라메터로 넘어온 visitor를 이용해서 자기 자신에 해당하는 visit 메서드를 호출하게 하는 것 이다.

public void welcome(Visitor v)
{
    v.visit(this);
}

다음으로 해야할 일은 Visitor 클래스를 생성하는 것이다. Visitor 패턴을 이용하는 클래스는 이 클래스를 상속받아서 visit 메서드를 구현하기만 하면 된다. 즉 파라메터로 입력받은 AST 노드에 해당하는 작업을 visit 메서드에 정의하면 된다.

package kr.ac.kaist.vicode.spec;

public abstract class Visitor {
  public abstract void visit(Spec n);
  public abstract void visit(Communication n);
  public abstract void visit(Api n);
  public abstract void visit(Rule n);
  public abstract void visit(DataFunc n);
  public abstract void visit(SignalFunc n);
  public abstract void visit(SignalDecl n);
  public abstract void visit(State n);
  public abstract void visit(Transition n);
  public abstract void visit(Set n);
}

Visitor 패턴을 사용하기 위한 준비작업은 모두 끝이 났다. 지금부터는 AST에 저장되어 있는 정보를 Visitor 패턴을 이용하여 AST를 순회하면서 XML형태로 출력하는 예제를 살펴본다. Spec2Xml 클래스는 Vistor 클래스를 상속하여 Visitor 패턴을 구현하고 있다. 각 visit 매서드에서 하는 일은 크게 두가지다. 하나는 해당 노드에 해당하는 작업을 수행하는 것이고, 나머지 하나는 자식 노드를 방문하게 하는 일인데 이과정을 위해서 단순히 각 AST 노드의 welcome 메서드를 호출하는 print 메서드를 정의하였다.

package kr.ac.kaist.vicode.spec.util;

import java.util.*;
import kr.ac.kaist.vicode.spec.*;

public class Spec2Xml extends Visitor {
  public void print(AbstractSpec n) {
       n.welcome(this);
  }

  public void visit(Spec n) {
       output(“<spec>”);
       print(n.getCommunication());
       print(n.getApi());
       print(n.getRule());
       output(“</spec>”);
  }

Vistor 패턴의 시작은 간단하다. AST의 최상위 노드에 대해서 print 메서드를 호출하면 자신의 자식노드에 대해서 visit 메서드를 호출하게 되고 이러한 일련의 과정을 통해 경우에 따라서 모든 노드를 방문하며 특정 작업을 수행할 수 있다. 위의 예제에서 Spec은 AST의 최상위 노드에 해당하며 이는 3가지 자식노드 (communication, api, rule)을 가지고 있으며 각각에 대해서 visit 메서드가 호출되도록 한다.  

지금까지 살펴본 것 처럼 Visitor 패턴은 AST와 유사한 자료구조를 빠짐없이 탐색하며 특정작업을 수행하기에 적합한 방법론을 제공한다. 특히 컴파일러나 인터프리터와 같이 AST를 사용하는 프로그램에서 잘 활용하면 유지보수가 용이하고 코드가 깔끔한 코드를 작성하는데 큰 도움이 될 것 같다.

Draw2D

UML Diagram using Draw2D

Draw2D는 GEF에 내장되어 있기도 하지만 standalone으로 사용될 수 있는 그래픽 라이브러리다. GEF에서 그림을 그릴 때 내부적으로 이 라이브러리를 사용한다. Display a UML Diagram using Draw2D 문서를 읽고 금방 그 사용법을 익힐 수 있을 정도로 잘 구성되어 있다. 여러 Figure를 조합해서 하나의 component를 구성하고 그 component 사이에 connection을 정의할 수 있도록 되어있다. 물론 그림 처럼 connection에 해당하는 외관을 변경한다던지 레이블을 추가하는 등의 작업이 가능하다. Eclipse 혹은 SWT 기반의 어플리케이션에서 유용하게 사용할 수 있을 것 같다.  

Graphical Editing Framework (GEF)

The Graphical Editing Framework (GEF) allows developers to create a rich graphical editor from an existing application model. GEF consists of 2 plug-ins. The org.eclipse.draw2d plug-in provides a layout and rendering toolkit for displaying graphics. The developer can then take advantage of the many common operations provided in GEF and/or extend them for the specific domain. GEF employs an MVC (model-view-controller) architecture which enables simple changes to be applied to the model from the view.

GEF는 이름 그대로, Graphical Editor의 구현을 도와주는 프레임워크라고 할 수 있다. 무에서 Graphical Editor를 구현한다고 상상해본다면 어떨까? 유사한 경험을 가지고 있지 않다면 대체 어디서 어떻게 시작해야할지 도무지 감을 잡을 수 없을 것이다.

항상 어떤 프레임워크나 플랫폼을 활용할 때는 딜레마를 느끼게 된다. 잘 짜여진 프레임워크를 활용하면 내가 한 일에 비해서 보기좋은(?) 아웃풋을 얻을 수 있다는 장점이 있는 반면에 얼마나 자유도를 가지고 시스템을 개발할 수 있는지에 대해서 의구심을 떨쳐버릴 수가 없고 충분히 활용하기까지 공부를 많이 해야한다는 단점이 있다.

분명한건 이런 프레임워크나 플랫폼은 나보다 똑똑한 여러명이 심사숙고해서 만들어 놓은 뼈대이며, 자유도를 고려한 디자인을 가지고 있다보니 본의 아니게(?) 복잡해질 수 밖에 없다. 따라서 이를 활용하기 위해서 적잖이 공부해야한다.

연구실에서 개발하는 Verification Integrated CODesign Environemnt (VICODE)에서 임베디드 시스템을 설계 할때 전체 시스템의 논리적인 디자인을 다이어그램 에디터에서 이루어지게 하려고 한다. 분명 xml 코드를 직접 쓰는 것보다는 훨씬 낫겠다는 기대와 함께 …

구현을 돕기 위해 공부해야할 것에는 다음과 같은 것 들이 있다.

EMF (Eclipse Modeling Framework)
GEF (Graphical Editing Framework)
GMF (Graphical Modeling Framework)


이들은 모두 MVC (Model-View-Controller) Architecture를 기반으로 한다. EMF는 Eclipse에서 사용할 Model의 클래스 구조를 자동생성해주는 녀석 쯤으로 보이고 GEF는 특정 Model을 편집할 수 있는 그래픽 편집기를 생성하는 프레임워크라고 볼 수 있다. 여기서 EMF로 생성된 Model이 GEF의 Model의 조건을 만족하기 때문에 EMF+GEF 조합의 솔루션이 소개되었다. 그리고 이를 돕기 위해 GMF 프로젝트가 전개되고 있다.

나는 GEF만을 사용하여 다이어그램 에디터를 구현하고자 한다. 여전히 복잡하고 어려워보이지만 “복잡한 문제는 단순한 문제의 합” 이라고 믿고 그냥 가보는거다! GEF를 공부하고 그 틀대로 구현을 하게 되면 아래와 같이 보기 좋은 그래픽 에디터가 생성된다.