특집기사:EMF 리소스 로케이터와 구체적 타입 모델링

위클립스
이동: 둘러보기, 찾기
Article.png 특집기사 정보
Ed-merk.jpg
원문 보기
저자 Ed Merks
역자 이지율
Recipe.gif 이 문서는 번역된 문서입니다. 원문 읽기

이 글은 Ed Merks이 최근 개발한 새로운 EMF 기능 중 일부를 자신의 블로그를 통해 소개한 글을 번역한 것이다. ResourceLocator및 지너릭 타입 모델링에 대한 향상된 코드 생성 기능을 소개한다.

이글의 제목은 EMF가 뭘 할 수 있지?(EMF Can do What?)이 었으나, 내용에 맞추어 제목을 변경하였음을 알린다.

목차

[편집] 개요

지난 몇 달간 새롭고 멋진 것들을 구현하느라 너무도 바빴다. 물론 그런 내용들을 잘 알리려는 의도는 갖고 있지만, 일단 문제를 해결하고 나면, 더 흥미로운 다른 멋진 주제에 집중하게 된다. 물론 이러한 새로운 기능들을 커뮤니티에 알리는 것이 실질적으로 더 가치 있는 일이기는 하지만, 나는 여전히 개발하는 것에 더 초점을 두고 있다.

좋은 의도로 포장한 도로가 보통 어디에서 끝나는지[1]를 모르는 것은 아니다.

Road-to-hell.jpg

[편집] ResourceLocator

예를 들어, 내가 EMF 2.8에추가한 ResourceSetImpl안의 ResourceLocator를 알고 활용하는 사람이 없다는데 내기를 걸 수도 있다. 왜냐하면 그런게 있는 줄도 모르기 때문이다. 유닛 테스트 코드를 살펴보면 이들이 어떻게 사용되는지 확인 할 수 있다.

이것이 하는 일은 ResourceSet.getResource가 전체 리소스 세트를 뒤져 보지 않고 리소스를 찾을 수 있도록 한다. 이전 구현을 자세히 살펴보면, 비교적 비싼 선형 탐색이 사용되는 것을 알 수 있는데, 이 과정에서 URI를 적절히 비교하기 위해 각 리소스의 URI를 평준화 하는 작업이 포함되어, 더욱 비용이 비싸짐을 알 수 있다.

ResourceLocator를 추가함으로써, 리소스 세트의 크기와 독립적으로 빠른 매핑 탐색을 통해 성능 향상을 볼 수 있다. 중요한 점은, 이 맵은 항상 올바른 상태로 관리되므로, URIConverter 들의 URI 매핑 정보등을 포함하여 어떠한 변경이 일어나더라도, 항상 올바른 리소스를 얻을 수 있다는 점이다.

[편집] Reified Type

새로운 멋진 기능 중 가장 최근의 예는 구체화된 타입(Reified Types)의 지원이다. 지너릭 타입을 널리 사용하면서, 모델 코드를 이리저리 재생성 해 본다면, 이 기능을 눈치 챌 수 있을 것이다. 그 과정에 개입하지는 않겠다, 그 편이 더 빨리 눈치 챌 수 있을 것이다. 아래의 모델을 가정 하자:

package org.example.element
 
class Element{
   container Container<Element> parent opposite children
}
 
class Container<T extends Element> extends Element
{
   contains T[] children opposite parent
   refers T selectedElement
}
 
class MenuElement extends Element
{
}
 
class Menu extends Container<MenuElement>
{
}
역자주 ecore 파일만 다뤄본 사람은 다소 난감할 수도 있는데, ecore를 DSL로 정의하는 Xcore의 문법이다. 주의 깊게 살펴보면 언어 자체가 단순함으로 쉽게 이해 가능하다

Menu를 살펴보면, MenuContainer를 상속 받았으므로, childrenselectedElement를 가지며 타입은 MenuElement이어야 함을 알 수 있다. 최근 배포된 EMF의 코드 생성기도 그 사실을 인지하며 다음과 같이 Menu의 구현 소스를 생성한다.

@Override
public EList<MenuElement> getChildren()
{
   if (children == null)
   {
      children =
         new EObjectContainmentWithInverseEList<MenuElement>
            (MenuElement.class, this, ElementPackage.MENU__CHILDREN, ElementPackage.ELEMENT__PARENT);
   }
   return children;
}
 
@Override
public void setSelectedElement(MenuElement newSelectedElement)
{
   super.setSelectedElement(newSelectedElement);
}

다시 말해 코드 생성기가 fail-fasttype-safe를 보증한다는 것이다. 뿐만 아니라 편집 지원 역시 향상되었다.

Container에는 모든 타입을 자식으로 붙일 수 있지만:

ElementModelContainerChildCreation.png


Menu의 인스턴스에는 MenuElement만 만들 수 있다:

ElementModelMenuChildCreation.png


유사하게, Container에서는 아무 타입이나 selectedElement를 지정할 수 있지만:

ElementModelContainerSelection.png


Menu에서는 그렇지 않다:

ElementModelMenuSelection.png


[편집] 맺음

얼마나 멋진가! 어쩌면 누가 이렇게 모델링을 해? 라고 생각할 수도 있다. 자세히 보면, 아주 가까운 곳에서 예를 찾을 수 있다.

이런 멋진 기능이 가능하다는 것을 모르는 사람들에게 알리기 위한 좋은 의도를 가지고 이 글을 송고한다.

[편집] 참조

  1. 좋은 의도로 포장된 도로는 지옥으로 연결된다: 의도보다는 실천적인 접근의 중요성을 강조한다.[1]

이 기사에 대한 의견은 토론 페이지를 통해 나눌 수 있습니다.

개인 도구
이름공간
변수
행위
포탈
탐색
도움
도구모음