http://www-128.ibm.com/developerworks/library/j-aopwork9/index.html

AOP@Work: 새로운 AJDT릴리즈는 AOP개발을 쉽게 만든다.#

1.2 와 1.3버전은 AspectJ를 위한 향상된 개발 환경을 제공한다.

<div class="note"> 저자 정보 : Matt Chapman (mchapman@uk.ibm.com), AJDT project leader, IBM

2005년 8월 9일 </div> <div class="note" style="margin:10px; background-color: #fcc"> 이 글이 작성된 시점은 AJDT 1.3이 릴리즈되기 이전 시점이나 번역은 1.3이 릴리즈된 이후 시점이라 AJDT 1.3에 대한 언급은 릴리즈 이후이 상황에 맞춰서 임의로 변경될수 있음을 알립니다.

각각의 AOP 용어는 문맥상 다음과 같은 값으로 번역되어 있을수 있습니다.

  • join point - 결합점
  • pointcut - 교차점
  • Advice - 충고
  • Aspect - 애스펙트
  • weaver - 직조자
</div> <div class="note" style="margin:10px; background-color:white"> AJDT eclipse프로젝트 리더인 Matt Chapman는 eclipse 3.0과 3.1을 위한 AspectJ개발 툴의 가장 최신버전인 AJDT 1.2와 1.3을 통해 당신에게 다가간다. 이 릴리즈의 가장 중요한 핵심은 eclipse를 사용하여 AspectJ를 좀더 밀접하게 통합하고 AspectJ개발자들에게 eclipse를 사용하는 자바 개발자들에게 사용가능한 고급 툴 지원을 제공한다. </div>

eclipse를 위한 AspectJ 개발 툴(AJDT-AspectJ Development Tools for Eclipse)은 eclipse와의 좀더 완벽한 통합을 위해 최근 많은 부분이 변경되었다. 이 변경사항은 AspectJ개발자들에게 eclipse의 툴 지원에 대해 좀더 쉽게 접근하도록 만들었다. 이 글에서, 나는 6월에 릴리즈된 eclipse 3.0을 위한 AJDT 1.2와 9월에 릴리즈되는 eclipse 3.1을 위한 AJDT 1.3을 소개할것이다.

AJDT 1.1이후의 변경사항도 다루기 때문에 이 글은 AJDT를 처음 시작하는 개발자나 이전 버전과 친숙한 개발자 모두에게 흥미로울 것이다. 변경된 것이 무엇이며 어떻게 사용하는지에 대해 반복적으로 지적하는 것 대신에, 나는 현재 AJDT기능과 접근법에 대해 알수 있도록 이글을 사용할것이다.

이 글 전체에 AJDT기능을 알아보기 위한 공통적인 시나리오를 사용할것이다. 대부분의 시나리오는 일반적인 AspectJ개발자에 의해 다루어지는 활동(activities)를 반영한다. 예를 들어, 첫번째 시나리오는 스크래치(scratch)로 부터 간단한 AspectJ프로젝트를 생성하는 것을 포함한다. 좀더 하위 시나리오는 존재하는 자바 프로젝트에 aspect를 추가하는 것을 포함하고 다양한 다중 프로젝트 환경에서 작동한다. 나는 AspectJ 5의 새로운 기능을 위한 특정 지원과 AJDT 1.1에서의 이전(migration) 절차도 다룰것이다. 나는 AJDT개발 프로세스 자체를 간단히 되집어보는 것으로 이 글을 마칠것이다.

AJDT 1.2는 1.1.12버전을 대체하는 eclipse 3.0을 위한 가장 최신의 안정적인 릴리즈이다. AJDT 1.3은 eclipse 3.1을 위한 안정적인 릴리즈이다.

스크래치(scratch)로 부터 AJDT#

자바 프로그래머가 AspectJ를 시작하기 위해, 몇몇 간단한 AspectJ프로그램을 작성하는 것은 시작하기 좋은 방식이다. 당신은 AspectJ프로그래머 가이드나 많은 AspectJ책중 하나 또는 사용가능한 글들(웹이나 자료공유를 목적으로 공유되는 글들을 지칭한다)내 예제들을 사용하여 이것을 수행할수 있다. eclipse내에서 새로운 AspectJ프로젝트를 생성하는 과정은 자바 프로젝트를 생성하는 것(간단히 File > New > Project > AspectJ Project를 선택하거나 툴바의 New AspectJ Project단축키를 사용하는)과 몹시 유사하다. 마법사의 나머지 과정은 New Java Project마법사와 거의 일치한다.

사실, AspectJ프로젝트는 자바 프로젝트(eclipse개념에서, 이것은 자바 속성에 AspectJ속성이 추가된것이다.)이다. 그래서 자바 프로젝트에서 작동하는 어떠한 툴이나 플러그인들도 AspectJ프로젝트에서 작동할것이다. 핵심적인 차이점은 프로젝트를 컴파일하기 위해 사용되는 eclipse builder이다. AspectJ컴파일러는 JDT자바 컴파일러 대신에 사용된다. AspectJ컴파일러는 JDT컴파일러의 확장이다. 그러므로 자바코드를 컴파일하기 위한 모든 기능을 가진다.

다음 부분에서, 나는 간단한 개발 시나리오를 실행하는 AJDT의 기능중 몇가지를 당신에게 보여줄것이다.

새로운 Aspect 마법사#

AspectJ프로젝트와 자바 프로젝트의 유사성으로 인해, 나는 source폴더, 패키지 그리고 classes를 생성하는 방법이나 프로젝트의 classpath를 설정하는 방법을 설명할 필요가 없다고 생각한다. 게다가 클래스를 편집하는 것은 기존과 같다. 당신은 자바편집기를 사용할수 있고 당신은 content제안(-assist), quick fixe 그리고 import를 정리하는 것과 같은 시간을 절약하는 기능들을 찾을것이다.

다음 단계는 aspect를 생성하는 것이다. aspect는 AspectJ의 모듈 단위이고 자바언어의 클래스와 많은 공통점을 가진다. New Aspect마법사을 열기 위해 File > New > Other > AspectJ > Aspect나 툴바에서 New Type를 선택하자.

AspectJ 편집기#

새로운 aspect를 생성한 후에, 당신은 AspectJ편집기에서 이것을 보게될것이고 이 파일이 AspectJ내 aspect를 위해 디자인된 .aj확장자를 가지고 생성된것을 알게될것이다. 새로운 aspect내 몇가지 AspectJ코드를 입력해보자. 당신은 자바코드와 매우 유사한 편집기 기능을 보게 될것이다. 다음 기능들을 고려해보자.

  • outline view는 당신이 타이핑하는대로 할성화된다.
  • 문법에러는 빨간색으로 강조된다.
  • import를 정리하는 것은 당신이 import한 클래스의 순서대로 정렬된다.
  • 편집기는 폴딩을 지원한다.
  • 당신은 파일을 다시 특정 구조로 포맷팅할수 있다.
  • ctrl+space를 통한 content제안(-assist)은 많은 경우에 도움이 된다.

여기서 두가지를 빠져있다. aspect내 quick fixes를 포함해서 pointcut이름과 같은 것들에 대한 content제안은 AJDT의 차후 버전에 포함될것이다.

aspect를 저장하는 것은 당신의 프로젝트를 컴파일하도록 만든다(만약 당신이 build automatically를 비활성화시켰다면, 이 경우 자바 프로젝트와 같이 당신은 Build버튼을 누를 필요가 있다.) 만약 당신의 aspect가 당신의 프로젝트내 코드에 영향을 끼치는 advice를 포함한다면, 당신은 Cross References view에 나타나는 몇몇 항목과 편집기 왼쪽에 몇몇 표시된 사항을 보게 될것이다. 이것은 AJDT가 당신의 AspectJ프로젝트의 crosscutting속성을 당신에게 보여주는 두가지 방법이다.

Crosscutting views#

Cross References view 와 Outline view는 중요한 파트너가 될수 있다. Outline view가 현재 문서의 구조를 보여주는 반면에, Cross References view는 현재 요소를 위한 crosscutting관계를 보여준다. 유용한 레이아웃은 아래의 그림 1에서 보여지는 것처럼 Outline view아래 Cross References view에 위치한다. 만약 이 view가 보이지 않는다면, 당신은 Window > Show View > Other > AspectJ를 선택하여 이것을 열수 있거나 Outline view내 요소에서 마우스 오른쪽 클릭하여 컨텍스트 메뉴로 부터 Open Cross References를 선택할수 있다.

편집기에서 메소드를 클릭하는 것은 그림 1에서 보여주는 것처럼 그 메소드를 위해서 어느 crosscutting정보를 보여주기 위한 Cross References view를 야기한다.

그림 1. 클래스를 위한 Outline 과 Cross References view들

xref1.jpg

이 경우 당신은 메소드가 GetInfo aspect내 몇몇 around advice에 의해 충고되고(advised) 있는 것을 볼수 있다. 당신은 이것을 자세히 보기위해 advice를 클릭할수 있다. advice자체는 그림 2가 보여주듯이 당신이 다른 관점에서 관계를 볼수 있도록 해주는 Cross References view에서 보여진다.

그림 2. aspect를 위한 Outline 과 Cross References view들

xref2.jpg

당신은 편집기와 Cross References view를 연결하지 않기 위한 옵션을 가진다. 당신이 이 옵션을 선택하는 것에 따라, Cross References view는 편집기와 당신이 보여지는 crosscutting정보의 특정 목록을 유지하길 원할때 유용하게 사용될수 있는 Outline view에서 선택하는것에 대해 반응하지 않을것이다. 다른 옵션은 현재 요소대신에 현재 파일의 전체를 위한 crosscutting정보를 보여주는 것이다.

마지막으로, 몇몇 개발자는 화면 공간을 절약하기 위해 Outline view를 지속적으로 보지않도록 없애버린다. 대신 그들은 편집기를 보여주는 view의 대체용으로 Quick Outline(Navigate메뉴로 부터, 또는 ctrl+O를 물러서)을 사용한다. 같은 기능은 Cross References view를 위해 사용가능하다. ctrl+alt+X를 누르면(또는 당신은 AJDT설정을 통해 당신 스스로 키 바인딩을 설정할수 있다) 그림 3이 보여주는 것처럼 Quick Cross References view가 나타난다. Quick Outline view를 사용하여, 키 바인딩을 두번 누르는것은 상속된 멤버를 보여주기 위한 view를 야기한다. Quick Cross References view는 현재 요소를 위한 crosscutting정보를 보여주는 것과 전체 파일을 위한 crosscutting정보를 보여주는 것을 전환하기 위한 유사한 기법을 사용한다.

그림 3. Quick Cross References view

xref3.jpg

표시자와 이미지 장식자(Markers and image decorators)#

만약 당신이 충고되는(advised) 몇몇 소스코드를 위한 편집기를 찾는다면, 당신은 편집기의 왼쪽측면에서 표시자 아이콘을 보게 될것이다. 이것은 Outline과 Cross References view내에서 같은 아이콘을 사용하여 advice의 존재와 타입을 표시한다. 여기엔 before, after 그리고 around advice를 표시하기 위한 다른 아이콘이 있다. 각각의 아이콘은 작은 물음표를 가지거나 가지지 않는 두개의 변형된 형태를 가진다. 물음표는 cflow지시어가 pointcut에서 사용될때처럼 advice가 그 위치에서 적용할지를 결정하는 것을 실행시 테스트하는 것을 표시한다. 물음표 없는 변형은 컴파일시 결정될수 있는 지점에서 사용된다.

만약 당신이 표시자에서 오른쪽을 클릭한다면 당신은 컨텍스트 메뉴에서 충고되는(advised) 항목을 볼것이고 하위메뉴는 advice의 소스를 보여준다. 만약 당신이 여기서 특정 항목을 선택한다면, 편집기는 advice를 보여주기 위해 열릴것이다. 그림 4가 보여주는 것처럼 하위메뉴를 충고하는 advice로 부터 당신은 다른 방향으로 부터의 crosscutting관계를 보여주는 추가적인 표시자를 보게 될것이다. 이러한 균형된 표시자는 advice의 소스와 목표(target)간의 일관적인 탐색을 허용한다. 유사한 표시자와 하위메뉴는 타입간(inter-type) 선언처럼 다른 crosscutting정보를 표시하기 위해 사용된다.

그림 4. Advice 표시자와 컨텍스트 메뉴

markers.jpg

이미지 장식자는 crosscutting정보를 보여주기 위해 사용될수 있다. 만약 당신이 그림 1에서 보여주는 Outline view로 돌아가길 원한다면, 당신은 view내 3가지 메소드를 남기기 위한 작은 오렌지 화살표를 보게될것이다. 이 화살표는 자바요소를 위한 eclipse이미지 장식자이다. 이것은 주어진 요소가 advice에 의해 직접적으로 영향을 받는지를 표시하기 위해 사용된다. 또는 이것이 충고된(advised) join point를 포함한다. 이 유용한 시각적 힌트는 Outline view, Cross References view, 자바 브라우징 perspective내 Members view를 포함해서 자바 요소가 표시되는 어디서나 나타난다.


자바 프로젝트로 변환하기#

간단한 테스트 프로젝트를 통해 AspectJ와 AJDT에 대한 몇가지 경험을 얻은 뒤, 개발자를 위한 일반적인 다음 단계는 존재하는 자바 프로젝트를 가져와서 이것을 aspect를 사용하여 확장하는 것이다. 예를 들면, 당신은 강제로 System.out.println 나 Exception.printStackTrace와 같은 원치않는 호출을 체크것과 같은 aspect추가작업이나 퍼시스턴스를 구현하기 위한 aspect나 디자인 패턴의 aspect기반 구현물과 같은 aspect생성작업을 원할것이다. 자바 프로젝트를 AspectJ프로젝트로 변환하는 것은 일관적이다. 간단히 프로젝트에서 오른쪽 클릭하여 Convert to AspectJ Project를 선택한다. eclipse개념에서, 이것은 프로젝트에 AspectJ속성을 추가하고 AspectJ컴파일러를 사용하도록 전환한다. 만약 당신이 스크래치로 부터 AspectJ프로젝트를 생성한다면, 이 절차가 eclipse플러그인 프로젝트와 같은 좀더 높은 수준의 것들을 포함해서 자바속성을 가진 프로젝트에 적용될수 있다는 것이 아무런 가치도 없다. 이 절차는 AspectJ속성을 제거하기 위한 컨텍스트 메뉴를 사용하고 자바 컴파일러로 전환하여 취소할수 있다. 당신이 자바 프로젝트 대신에 AspectJ프로젝트를 가질때, 당신은 그것들과 차별화되는 것이 무엇인지 궁금할것이다. 일단 최소한의 대답은 "매우 적다" 이다. 당신은 표준적인 문서 outline view와 quick fixes, content제안, 그리고 빨간색 라인을 통해 미리 에러를 표시하는 것을 포함해서 당신이 의존하는 모든 기능를 사용하는 자바 편집기로 당신의 자바 클래스를 편집하는 것을 지속할것이다. 반면에, 클래스에 대한 변경을 저장하는 것은 프로젝트의 빠른 증가(incremental) 컴파일을 야기하고 프로젝트 프라퍼티 페이지로부터 컴파일러옵션을 모두 셋팅할수 있을것이다. 사실, AspectJ컴파일러는 eclipse자바 컴파일러의 확장이고 AJDT는 가능한한 일관적이고 투명하게 JDT툴을 확장한다. 이것은 우리가 균일한 통합에 대해 이야기 할때를 의미하는 것이다. 이것은 AJDT 1.2/1.3를 위한 중요한 핵심영역중 하나이고 우리는 멋진 진척사항(나는 이 글에서 남은 제한사항을 알려줄것이다.)을 이루었다. 균일한 통합의 목표는 가능한한 쉽게 AspectJ프로젝트로의 전환에 관련된 첫 단계를 만드는 것이다.


다중 프로젝트 관리하기#

AspectJ소스코드를 빌드하는 것은 두가지 단계를 요구한다. .class파일을 생성하기 위해 .java와 .aj파일내 소스를 컴파일한다. 그리고 생성된 .class파일에 aspect를 적용한다. weaving으로 알려진 두번째 단계는 AspectJ간의 핵심 차이점이고 생성된 .class파일로 aspect를 적용한다. 컨트롤러에 의한 분석을 위해 사용가능한 타입을 만드는 자바 컴파일 과정은 classpath셋팅에 의해 제어된다. 같은 classpath셋팅은 AspectJ컴파일 과정에 의해 사용되고 eclipse내에서 정확하게 같은 방법으로 설정된다. 어쨌든, 이 셋팅은 모든 상황에서 컴파일과 weaving단계를 모두 제어하기 위해 충분하지 않다. 이것은 AspectJ프로젝트를 위해 두가지의 추가적인 셋팅이 존재하는 이유이다.

첫번째, inpath셋팅이 있다. 여기서 명시되는 어떤것은 weaver를 위해 사용가능하도록 만들것이고 적용하는 aspect는 직조될것이다. 항목들은 프로젝트에서 마우스 오른쪽 클릭하고 Properties를 선택하여 AspectJ InPath부분으로 가서 프로젝트의 inpath에 추가될수 있다. 항목들은 JAR파일이나 다른 프로젝트의 bin디렉토리와 같은 디렉토리(class폴더)가 될수 있다. inpath에서 어떤것은 어쩌면 aspect로 직조된 후 프로젝트의 output으로 보내진다.

두번째 추가적인 셋팅은 aspectpath이다. inpath가 직조되는 것들의 목록을 제어하는 반면에, aspectpath는 이 목록으로 직조되는 것을 제어한다. 달리 말하면, 만약 그것들이 프로젝트로부터 소스를 보여준다면 aspectpath에 명시된 aspect는 직조과정에 사용가능하도록 만들어진다. 이 셋팅은 AspectJ Aspect Path프라퍼티 페이지로부터 제어되고 JAR파일이나 디렉토리를 포함할수 있다.

output JAR셋팅은 각각의 프로젝트의 프라퍼티 페이지의 AspectJ부분에 존재한다. 이 셋팅은 컴파일러가 프로젝트의 output폴더대신에 클래스 파일을 직접적으로 JAR파일로 출력하도록 만든다.

다른 프로젝트로부터 aspect를 사용하기#

위 셋팅을 보기 위해, 예제 작업공간(workspace)를 고려해보자. 두개의 프로젝트가 있다. 하나는 MyAspects라고 명명하고 다른 하나는 WeaveMe라고 명명한다. 둘다 AspectJ프로젝트이다. 두번째 프로젝트는 아마도 자체적인 aspect를 포함하지 않을것이다. MyAspects프로젝트는 WeaveMe프로젝트에서 요구되는 몇가지 aspect를 포함한다. 두개의 프로젝트를 연결하기 위해, WeaveMe프로젝트에서 간단히 마우스 오른쪽 클릭하자. 그리고 Properties를 선택한 뒤 AspectJ Aspect Path부분으로 이동하자. 그 다음 Libraries탭으로 부터, Add Class Folder를 누르고 MyAspects프로젝트의 bin디렉토리(또는 output디렉토리의 이름)를 선택하자.

새로운 셋팅으로 프로젝트를 빌드하기 위해 OK를 누르자. aspect내 pointcut이 WeaveMe소스코드내 위치와 일치한다고 가정하고 적절한 advice를 적용하자. 편집기 표시자와 Cross References view는 여전히 "에 의해 충고되는(advised by)" 관계를 보여주지만 지금 관계의 끝을 유래하는것은 바이너리 aspect로 언급될것이고 당신은 이것을 탐색할수 없을것이다. 이것은 대개 aspect가 외부 JAR파일과 같이 eclipse작업공간의 외부요소가 될수 있기 때문이다. 어쨌든 적어도 이 경우 소스는 다른 프로젝트의 작업공간내에 있어서 AJDT의 차후 버전은 이 연결을 만들수 있고 다른 프로젝트내 aspect에 대한 탐색을 허용할것이다.

aspectpath를 통해 제공되는 타입이 수행시 사용가능한 상태가 될 필요가 있다는 것을 아는게 중요하다. 다행이도 AJDT는 Run > Java Application를 선택하는 대신에 당신을 위해 이것을 쉽게 만들어준다. 당신은 새로운 실행(launch)설정인 Run > AspectJ/Java Application를 사용할수 있다. 이것은 수행 classpath에 aspectpath항목을 자동으로 추가하는 것을 제외하고 자바 실행(launch)설정과 같다. 두번째, 관계없는 차이점은 AspectJ/자바 실행 설정이 aspect내 포함되는 중요한 메소드를 할당할수 있다는 것이다.

자바 프로젝트 직조하기#

만약 당신이 자바코드를 포함한 프로젝트를 가진다면, 소스형태나 JAR파일중 aspect에 적용하길 원하는 것은 어떤것인가.? 만약 당신이 프로젝트로부터 분리된 aspect를 유지할 필요가 있다면 당신은 자바 프로젝트처럼 이것을 남겨둘수 있고 직조하기 위한 AspectJ프로젝트를 생성할수 있다. 이 경우, 당신은 Add JARs 나 Add Class Folder버튼을 사용하여 자바코드를 참조하기위해 AspectJ프로젝트내 "AspectJ InPath"셋팅을 간단히 추가할것이다.

이것처럼 바이너리 직조를 할때 당신은 advice가 어떤 영향을 끼치는 지점을 보여주기 위한 소스코드 표시자를 더이상 가지지 않는다.컴파일러 옵션은 여기서 유용하다. AspectJ프로젝트를 위한 AspectJ Compiler 셋팅의 다른 탭(또는 전역 preferences)으로 부터 Output weaving info messages to problems view(problems view를 위한 직조 정보 메시지 출력)옵션을 선택한다. 프로젝트가 Problems view로 빌드될때마다 그림 5가 보여주는것처럼 직조된 타입을 표시하기 위한 정보를 보여줄것이다.

그림 5. 직조 정보 메시지

weavemessages.jpg

입력이 JAR파일이었다면 당신은 원래 JAR파일의 직조된 버전을 직접적으로 생성하기 위해 이전에 언급된 Output JAR옵션을 사용하길 원할것이다.

Aspect 라이브러리 개발하기#

재사용가능한 aspect라이브러리의 개념은 매우 강력한 요소이다. 이것은 당신이 개발한 aspect를 다른 프로젝트에도 적용가능하다는 것을 말한다. 당신은 aspect를 이끌어낼수 있고 자신만의 프로젝트에 이것을 분류할수 있다. 대개 라이브러리내 aspect는 요구되는 특정 목적을 수행하는 행위를 적절하게 정의할것이다. 이것은 대부분 추상 pointcut을 가진 추상 aspect를 포함할것이다. aspect를 사용하는 프로젝트는 적용하기 위한 aspect를 위한 적절한 범위를 정의한 pointcut을 가지고 이것들을 확장할것이다.

만약 aspect를 사용하는 프로젝트가 요구되는 추상 aspect의 구체적인(concrete) 버전을 포함한다면, 당신은 Java Build Path프라퍼티 페이지에서 Projects탭에 라이브러리 프로젝트를 추가하여 간단히 두개의 프로젝트를 연결할수 있다. 구체적인 aspect가 프로젝트에 지역적인것처럼, 정규 클래스패스 룩업은 수퍼-aspect(super-aspect)를 분석하기 위해 충분할것이다.

편집기 표시자와 Cross References view가 advice의 소스를 추상 수퍼-aspect처럼 보여준다는 사실에 주목하라. 이것은 advice가 위치하는 것이기 때문에 정확하다. 어쨌든 이 위치에서 구체적인 aspect내 pointcut이 advice 애플리케이션을 제어하고 관여한다. AJDT의 차후 버전에서는, "uses pointcut" 관계가 이 연결을 촉진하도록 나타날것이다. 잠재적인 재사용가능한 aspect라이브러리가 주어진다면, 당신은 AJDT의 나중에 나올 릴리즈에서 이 영역을 증가시키는 일반적인 지원을 기대할수 있다.

플러그인 프로젝트와 작동하기#

eclipse의 증가하는 인기는 좀더 많은 개발자가 플러그인을 만든다는 것을 의미한다. 좋은 소식은 플러그인으로 작업하기 위해 AspectJ를 사용하는 것이 쉽다는 것이다. 간단히 플러그인 프로젝트를 가져와서 AspectJ프로젝트로 이것을 변환하기 위해 마우스 오른쪽 클릭하라. org.aspectj.runtime 플러그인의 의존성을 삽입하는 창을 보게될것이다. AspectJ프로그램은 aspectjrt.jar파일에 대해 수행시 의존성을 가지고 플러그인 프로젝트는 이 파일을 통해 org.aspectj.runtime 의존성이 만족된다. 당신의 프로젝트에 이 의존성을 추가한뒤, 당신은 플러그인 개발에 aspect를 사용할수 있다.

eclipse플러그인 개발 환경(PDE-Eclipse Plug-in Development Environment)은 당신의 플러그인 프로젝트를 위한 Ant빌드 파일(build.xml)을 생성하는 것을 가능하게 해준다. AJDT는 AspectJ가 가능한 플러그인 프로젝트를 위한 작은 옵션을 제공한다. plugin.xml파일에서 마우스 오른쪽 클릭하여 PDE Tools > Create Ant Build File with AspectJ Support를 선택한다. 생성된 build.xml파일은 소스코드를 컴파일하기 위해 javac Ant task를 사용하는 것 대신에 AspectJ에 의해 제공되는 iajc task를 사용하는 것을 제외하고 자바 플러그인 프로젝트를 위해 생성된 파일과 유사할것이다.

<div class="note" style="background-color:white"> 통합의 제한점

다양한 영역에서, eclipse의 나머지와 AJDT를 통합하는 것은 플러그인의 예제처럼 완벽하게 되지는 않는다. AspectJ 지원 옵션을 가지고 Ant빌드 파일을 생성하는 것은 존재하는 Ant빌드 파일 생성하는 옵션과 함께 추가되었다. eclipse플러그인은 이것을 대체하는 것보다 새로운 기능을 추가하는데 기여할것이다. 하지만 이 경우, 존재하는 기능이 AspectJ프로젝트와 작업하기 위해 확장된다면 좀더 멋질것이다. 사용자는 자바와 AspectJ프로젝트를 위해 Ant빌드 파일 생성하기 옵션을 볼 것이고 두 경우 모두 "잘 작동"할것이다. </div>


큰 프로젝트들 관리하기#

당신은 eclipse에서 AJDT를 사용하여 간단한 프로젝트를 생성하는 방법(자바 프로젝트에서 AJDT로 변환하는 방법)과 AJDT를 사용하여 다중 프로젝트와 프로젝트 타입간의 유지와 작업을 하는 방법이 쉽다는 것을 알게되었다. 다음에 나는 많은 수의 소스파일을 가진 프로젝트에 적합한 몇몇 AJDT기능을 당신에게 보여줄것이다.

프로젝트 레벨의 시각화#

당신이 이전에 본것처럼, AspectJ편집기와 Cross References view내 표시자는 파일별로 crosscutting속성을 보여준다. 이러한 기능으로 부터 당신이 얻지 못하는 것은 전체 프로젝트나 패키지 단위에서 관여된 넓은 범위의 멋진 개요이다. 이러한 타입의 관점을 위해서, 당신은 Visualiser를 사용할것이다.

Visualiser를 가져오기 위한 가장 쉬운 방법은 소스파일내 라인수에 비례한 높이를 가진 각각의 소스파일을 위한 칼럼을 구성하는 선택된 프로젝트의 시각적 표현을 담당하는 Aspect Visualization perspective로 전환하는 것이다. 줄무늬는 advice가 영향을 끼치는(추가적인 수행테스트시 잠재적으로 영향을 끼치는) 소스위치를 표시하기 위한 적절한 지점에 칼럼을 칠한다. 각각의 줄무늬의 색은 advice를 포함하는 aspect에 일치한다. 당신은 그림 6에서 스크린샷으로 이것을 볼수 있다.

그림 6. Visualiser

vis.jpg

당신이 볼수 있는것처럼, 중요 Visualiser view와 표시될 aspect를 목록화하는 두번째 Visualiser Menu view가 있다. 당신은 시각화로부터 그것들을 제거하기 위해 이 목록으로부터 aspect의 선택을 해제할수 있다. 예를 들면, 당신은 다른 aspect를 숨겨버리는 침투적인 로깅 aspect를 제거하길 원할지도 모른다. 당신은 view에 내용물의 크기를 맞추도록 view를 크게 보거나 작게 보이도록 하거나 advice에 의해 영향을 받는 칼럼만 보여주고 클래스레벨에서 패키지 레벨로 그룹화레벨을 전환하기 위해 Visualiser view의 툴바를 제어할수 있다. 마지막으로 당신은 화면 표시를 사용자 정의할수 있는 preference페이지와 같이 다른 옵션들에 접근하기 위한 드랍다운 메뉴를 사용할수 있다. advice의 영향을 보여주는것에 추가적으로, 시각화는 "declare error" 과 "declare warning"구문의 대응(matching) 위치를 포함한다. Visualiser 메뉴툴바에서 토글될수 있다. 다른 aspect를 표시하기 위해 사용된 색상들은 목록으로 부터 변경될수 있고 선택된 색상은 기억될것이다.

Visualiser는 비록 굉장히 많은 처리가 모든 클래스의 크기를 판단하고 시각화를 표현하기 위해 요구되더라도 큰 프로젝트를 다루기 위해 디자인되었다. 사용가능한 그래픽 메모리는 일반적인 메모리보다 좀더 제한된다. 표현처리는 그래픽 메모리의 사용을 최소한으로 유지하기 위해 최적화된다. 칼럼들은 요구되는것만큼 표시된다. 그래서 처음 view를 스크롤하는 거은 나중에 하는 것만큼 부드럽지가 않다. 일반적인 메모리는 이미지 데이터를 잡기 위해 사용된다. 이미지 데이터가 매번 다시 활성화되는 경우에 이것은 좀더 큰 프로젝트가 보여지긴 하지만 제한된 메모리를 가지고는 스크롤이 원할하지 않다.

Visualiser는 키보드나 마우스를 통해 칼럼, 클래스 또는 줄무늬를 선택하기 위한 선택(selection) 기법을 지원한다. 선택을 활성화하는것(마우스로 더블클릭하거나 스페이스바를 눌러서)은 편집기에서 열릴 관련항목을 야기한다. Visualiser는 eclipse표시자에서 구글검색결과까지 어떤것을 시각화하기 위해 만들어질수 있는 완전히 일반적인 목적의 컴포넌트이다. Visualiser에 사용자정의 데이터를 제공하는 만큼, 당신은 칼럼의 그려지는 스타일과 줄무늬를 위한 색상을 사용자정의 할수 있다.

변경사항 관리하기#

프로젝트는 코드에 생성되는 변경사항만큼 더 많은 시간을 개발한다. 코드가 리팩토링되거나 버그가 고쳐지고 새로운 기능이 구현되는것처럼 클래스와 메소드는 추가되거나 삭제되고 재명명될것같다. 좀더 큰 프로젝트에서 이러한 변경사항을 관리하는 것은 특히 많은 crosscutting기능을 다룰때 시도될수 있다. aspect를 가지고 이 기능을 획득하는 것은 코드기반으로 산개된것 대신에 적절한 코드를 모으는 상황을 향상시킨다. pointcut은 aspect내 advice가 적용하는 지점의 join point에 의해 정의되어 사용된다.

이것을 분석하기 위한 첫번째 접근법은 시작부터 견고한 pointcut를 개발하는 것이다. 제대로 빌드된 pointcut은 변경사항이 코드에 생긴이후 필요한 위치를 일치시키는것을 다소 덜 멈추게 할것같다. 에를 들어, 당신이 첫번째 파라미터로 정수를 가지는 update메소드에 대한 호출에 관심이 있다면, 당신은 call(* update(int))과 같은 pointcut를 사용해야만 한다. 이것은 하나의 정수 파라미터를 가지는 update메소드를 호출한다. 하지만 만약 누군가가 나중에 이 메소드에 추가적인 파라미터를 만든다면, pointcut은 더이상 일치하지 않는다. 만약 당신이 첫번째 정수 파라미터에만 관심을 가진다면 더 나은 pointcut은 call(* update(int,..))가 될것이다. 이것은 추가적인 파라미터가 만들어지거나 삭제되더라고 여전히 일치되기 때문이다.

이런 주의조차도, 변경사항의 몇몇 타입은 가장 견고한 pointcut에서도 문제를 발생시킨다. 예를 들면, 위 경우에서 메소드의 첫번째 파라미터가 더 이상 정수가 아닌것으로 변경될수 있다. 변경사항의 다른 타입은 요구되는 것보다 더 많은 상황에서 일치되기 위한 pointcut을 발생시켜야만 한다. 예를 들면, 만약 당신이 setter메소드에 관심을 가진다면, 당신은 pointcut에 set* 형태를 적용해야만 할것이다. 하지만 코드에 셋업을 호출하는 setter가 아닌 메소드의 이후 추가는 pointcut에 의해 비교적 탐탁치 않은 추가적인 일치라는 결과를 만들게 될것이다.

AJDT 1.2.1과 1.3릴리즈를 위해 추가된 새로운 Crosscutting비교 기능은 당신이 코드에 이러한 변경사항의 다양한 타입들을 다루는 것을 도와주기 위해 꼼꼼히 개발되었다. Crosscutting비교는 프로젝트의 crosscutting관계의 스냅샷을 가지도록 허용하고 프로젝트의 차후 버전에 존재하는 관계로 스냅샷을 비교한다. 스냅샷을 생성하기 위해, 프로젝트에서 마우스 오른쪽을 클릭하고 AspectJ Tools > Save Crosscutting Map를 선택한다. 당신은 관계 맵을 저장하기 위해 파일명을 입력받기 위한 창을 보게 될것이다. 이러한 파일은 .ajmap확장자를 가지고 당신의 프로젝트에 직접적으로 저장된다. 예를 들어, 당신은 프로젝트의 특정버전을 릴리즈할때, 다른 릴리즈를 개발할때 참조하기 위한 시점으로 그것들을 사용하기 위해 당신은 그 릴리즈를 위한 crosscutting관계를 저장해야만 한다.

프로젝트에 하나 이상의 crosscutting맵 파일을 가질때, 당신은 비교를 수행할수 있다. 당신은 서로 각각의 파일을 비교할수 있거나 최근 빌드하는 관계에 대해 하나의 파일로 관계를 비교할수도 있다. 이러한 두가지 비교 옵션은 패키지 탐색기에서 하나나 두개의 맵파일을 선택하고 마우스 오른쪽 클릭하여 컨텍스트 메뉴로부터 적절한 옵션을 선택하여 사용가능하다. 비교의 결과는 그림 7에서 보여주는 것처럼 새로운 view에 표시할것이다.

그림 7. Crosscutting Comparison view

comparison.jpg

이 view는 첫번째 맵 파일이 기록된 이후 삭제된 것 뿐 아니라 추가된 crosscutting관계를 보여준다. 그것들은 두번째 맵 파일(또는 현재 빌드)에는 존재하지 않는다. 당신은 편집기에서 그것들을 열기 위해 source나 target요소를 더블클릭할수 있다. 보여지는 관계를 제한하기 위해 툴바에서 filter버튼이 있다. 디폴트는 "advised by" 대신에 "advises"와 같은 하나의 방향으로 관계를 보여준다. 당신은 칼럼에 따른 결과를 정렬하기 위해 칼럼헤더를 클릭할수 있다. 마지막으로, 만약 당신이 현재 빌드로 맵 파일을 비교하기 위해 선택했다면, 비교는 빌드가 발생할때마다 다시 수행할것이다. 이것은 당신에게 프로젝트에 코드가 리팩토링될때 매우 유용하게 사용될수 있는 맵 파일이 생성된 후 변경되는 것이 무엇인지 지속적으로 보여준다.

메모리 사용#

대개 AspectJ 프로젝트의 메모리 사용은 두가지 중요한 영역에서 자바 프로젝트보다 좀더 높다. 첫번째, 컴파일러에서 더 높다. aspect지향 컴파일러는 직조처리단계가 있기 때문에 객체지향 컴파일러보다 더 많은 작업을 수행한다. 두번째, 추가 작업은 애플리케이션의 crosscutting구조를 명확히 만드는 개발환경에서 필요하다. 이러한 오버헤드를 완변하게 제거할수 없는한 AJDT와 AspectJ컴파일러의 차후버전은 이것을 줄이는데 집중할것이다.

만약 당신이 좀더 큰 프로젝트에서 작업을 한다면, 첫번째 단계는 언제나 자바가 eclipse구동을 처리하기 위해 사용가능한 메모리를 증가시키는 것이다. 당신은 ecliipse를 위해 -vmargs -Xmx512m과 같은 인자를 설정해서 이것을 수행할수 있다. 만약 한번에 모든 프로젝트가 열려있을 필요가 없을때는 당신은 작업공간에서 몇몇 프로젝트를 닫을수 있다. 만약 여전히 스스로가 메모리 부족을 겪는다면, 몇몇 코드가 바이너리 직조나 로드시 직조되는 aspect와 함께 자바 컴파일러에 의해 컴파일되는 것처럼 당신의 프로젝트를 조정할수 있다. 다른 선택사항은 AspectJ컴파일러 셋팅의 "Other"탭을 사용하여 crosscutting구조 모델의 생성을 비 활성화하는 것이다. 이것을 하는 것은 메모리를 절약하지만 나중에 재정렬되어야만 한다. 당신이 advice표시자를 더이상 볼수 없고 Cross References 와 Visualiser views는 어떤 crosscutting정보도 보여주지 않을것이다.


AspectJ 5 의 새로운 사항#

내가 먼저 언급했던 AspectJ 5에 특정적인 기능들은 오직 ecliipse 3.1에서만 사용가능하다. 왜냐하면 이것은 eclipse 3.0에서는 존재하지 않는 java 5지원을 요구하기 때문이다. 그러므로 다르게 언급하지 않는한, 이 부분의 모든 것은 오직 AJDT 1.3에만 적용한다. 지난달 AOP@Work에서, "Introducing AspectJ 5"는 AspectJ 5의 새로운 기능을 다룬다. 어쨌든 AspectJ프로젝트에서 Java 5 모드를 사용하기 위해 필요한 단계는 자바 프로젝트와 같다. Java > Compiler를 선택하고 컴파일러 레벨을 5.0으로 셋팅한다. 당신은 프로젝트이 빌드 경로에 JRE시스템 라이브러리가 Java 5이고 1.4.2이거나 그 이전 버전이 아님을 확인할 필요가 있다.

AspectJ 5에서의 몇몇 변경사항은 문법적인 변경이나 추가적인 API클래스와 같은 AJDT의 어떤 변경사항도 요구하지 않는다. 새로운 pertypewithin aspect초기화 모델과 같은 몇몇 변경사항은 오직 편집기에서 문법적인 강조와 이 경우 새로운 Aspect마법사의 추가적인 체크박스만을 요구한다. 다른 변경사항은 당신이 볼수 있듯이 좀더 많은 작업을 요구한다. 그리고 많은 경우 AJDT개발팀이 처음에 좀더 풍부한 기능을 나중에 추가하기 위한 범위를 가진 최소한의 지원레벨을 구현했다는 것에 주목하라.

Java 5와 AspectJ 5에 대한 추가적인 annotation은 광법위하게 알려졌다. 왜냐하면 AJDT는 eclipse의 JDT를 확장하기 때문이다. 이것은 자동적으로 그것들에게 추가된 annotation지원으로부터 자동적으로 이득을 얻게 된다. AspectJ 5는 annotation의 존재에 기반하여 일치하기 위한 @this와 같은 새로운 pointcut디자이너를 추가한다. 이것들은 편집기에서 문법적인 강조를 요구한다. 타입, 메소드, 생성자 그리고 필드에 대한 annotation을 선언하기 위한 새로운 종류의 declare구문이 추가되었다. 새로운 declare구문은 "advises" 와 "advised by."와 같이 Cross References view와 표시자를 위한 컨텍스트 메뉴에서 보여지는 두개의 새로운 crosscutting관계인 "annotates" 와 "annotated by,"를 추가하여 AJDT에서 지원된다.

당신은 그림 8에서 새로운 declare구문의 간단한 예제를 볼수 있다. aspect는 declare @method구문과 내부타입 선언을 포함한다. aspect는 선택되어서 Cross References view는 aspect내 모든것을 위한 crosscutting정보를 보여준다. declare @method구문은 세개의 메소드에 주석을 단다. 하나는 내부타입 선언이고 다른 두개는 Account클래스에 직접한다. 내부타입 선언은 Account클래스가 "declared on"되고 @method선언이 "annotated by" 되기 위해 보여진다. 편집기 표시자는 crosscutting관계의 source와 target처럼 @method선언에 대조(against)되고 두방향 화살표는 내부타입 선언에 대조된다.

그림 8. AspectJ 5에서 annotations선언하기

declareanno.jpg

AspectJ 5의 다른 새로운 기능은 "@AspectJ" 스타일이라고 알려진 aspect선언의 annotation기반 스타일을 위한 지원이다. 이것은 AspectJ애플리케이션이 정규 Java 5컴파일러에 의해 컴파일되고 나중에 AspectJ직조자에 의해 직조되는 것을 허용한다. 예제에서처럼, 정규 코드스타일문법으로부터 pointcut키워드를 사용하는 대신에, 당신은 일반적인 자바 메소드를 정의하고 pointcut을 정의하는 메소드를 위해 Java 5 annotation을 덧붙인다. 이것의 예제는 그림 9에서 보여준다. 당신이 보는것처럼 AJDT는 여전히 당신에게 사용되는 개발 스타일에도 불구하고 애플리케이션의 crosscutting구조를 보여준다.

그림 9. @AspectJ 개발 스타일

ataspectj.jpg


AJDT 1.1로부터 이전하기(migration)#

AJDT 1.2와 1.3내 주어진 변경사항의 확장에대가 많은 내부적인 구조의 재구성으로 인해, AJDT 1.1에서 사용되는 eclipse작업공간을 형식적으로 업그레이드하는 것이 명백히 복잡한 처리라는것은 놀라운 일이 아니다. 어쨌든 AJDT개발팀은 그림 10이 보여주는 이전 마법사를 소개하여 가능한한 무리없이 이것을 처리하도록 하고 있다. 마법사는 AJDT이 버전을 업그레이드한 후에 eclipse를 처음 실행하는 시점에 나타날것이다. 업그레이드를 시도하기 전에 당신은 이전 처리에 포함될 프로젝트를 열어두어야 하고 AspectJ편집기가 변경될것이기 때문에 AspectJ편집기의 인스턴스를 닫아두어야만 한다. (만약 당신이 편집기의 인스턴스를 닫지 않느다면, 당신은 "cannot restore editor"에러를 보게될것이다. )

그림 10. 이전 마법사

migration.jpg 이전 마법사의 첫번째 페이지는 소스파일의 파일확장자를 .aj파일로 변환하는 것이다. 당신이 원한다면 이 과정에서 프로젝트를 제외할수 있다. 파일 확장자의 차후 변환을 위해 AJDT내 변환 마법사가 있다. 프로젝트나 소스파일을 개별적으로 마우스 오른쪽 클릭하여 사용가능하다. 이전 마법사의 다음 페이지는 AJDT를 위한 eclipse빌더를 위한 내부 변경사항을 다룬다. 당신이 여기서 디폴트로 받아들이길 원하지 않는 경우는 프로젝트가 AJDT 1.1에서 사용될수 있는 프로젝트의 호환모드를 사용하는것이다. 세번째 페이지는 큰 org.aspectj.ajde플러그인에 실행시 의존성을 가지는 대신에 AspectJ가능한 플러그인 프로젝트만을 위한것이다. 의존성은 지금 새롭고, 매우 작은 org.aspectj.runtime플러그인이다. 다음 페이지는 AJDT 1.1에 의해 만들어지는 전역 작업공간 셋팅으로 되돌리고 마지막 페이지는 새로운 Cross References view를 소개한다.


AJDT 개발 노트#

최근 AJDT프로젝트 팀의 우리는 AJDT자체를 개발하기 위해 AspectJ와 AJDT를 사용한다. AJDT는 AspectJ가 가능한 계속 증가중인 플러그인에 의해 구현되었다. 많은 개발자가 200,000라인이 코드정도의 좀더 큰 프로젝트에 AJDT를 사용하는동안, AJDT는 적절한 테스트케이스(우리의 수많은 JUnit테스트와 수동 테스트 시나리오)를 만들고 당신이 그것들에 부닥치기 전에 많은 문제를 찾고 고치는것을 의미한다.

eclipse를 사용하여 AJDT를 개발하고 통합하기 위해 AOP를 사용하는 것은 대부분 필요한 버그수정과 향상된 사항에 집중하도록 도화준다. 우리의 첫번째 생산성은 전환에 의해 낮아지지만 경험은 AJDT와 AspectJ사용으로 인한 향상에 감사하게 된다.

전환은 이러한 이유를 위해 가치가 있다. 하지만 우리는 같은 시각에 AOP로부터 몇가지 이득을 기대했다. 시작하는 분들을 위해 우리는 수동으로 예외처리하는것에 비해 예외를 잡고 eclipse에러 로그에 적절한 항목을 추가하기 위해 aspect를 사용하여 문제를 분석하는 능력을 향상시킬수 있다. 우리는 Visualiser로 다양한 성능및 자원사용 측정을 보여주기 위한 view를 활성화한다. Aspects는 강제로 코딩표준을 따르고 다중 프라퍼티 페이지에 변경사하을 추적하고 eclipse의 ISafeRunnable인터페이스를 사용하여 호출을 포장하기 위해 AJDT에서 사용된다.


AJDT의 미래#

만약 당신이 AJDT의 이전 버전에 친숙하다면 당시은 AJDT 1.2와 1.3내 변경사항에 대해새 지금 알았을것이다. AJDT 1.1로 돌아가서 AspectJ편집기는 다소 기능이 떨어지고 클래스와 aspect를 모두 편집하는데 사용된다. 그리고 사용자정의 outline view는 표준적인 자바 outline view보다 기능이 떨어진다. 반대로 새로운 AspectJ편집기는 aspect를 편집하기 위해 풍부한 기능을 제공하고 표준적인 자바 편집기는 클래스를 편집하기 위해 사용되고 표준적인 outline view는 aspect를 위한 지원으로 향상되었다. 이것은 또한 작업공간 셋팅을 위해 전역적인 변경사항을 적용하기 위한 preferences마법사가 더이상 필요하지 않다는 것을 의미한다.

ajdoc의 생성과 설정을 빌드하기 위한 지원에 관련된 기능은 크게 변경되지 않았지만, 대부분 다른 영역은 향상되고 확장되었다. 당신 프로그램의 crosscutting구조를 보여주고 탐색하는 새로운 방법, JAR파일에 보내기 위한 새로운 지원, 파일 확장자 변환하기, 그리고 빌드 파일 생성하기에다가 증가(incremental) 컴파일을 위한 명백하게 향상된 지원 그리고 좀더 큰 프로젝트를 다룰수 있는 좀더 유연한 Visualiser가 있다.

이 모든 진척사항에도 불구하고 아직도 해야할 것들이 많다. 첫번째, eclipse와의 통합에 관련한 이슈가 있다. 긴 개념에서 견고하고 완벽하게 통합된 AJDT는 최근의 상황보다 더 확장가능하도록 eclipse내에서 자바 툴을 요구하고 우리는 많은 영역에서 기여할수 있도록 AJDT를 개발하는데 많은 경험으로 인한 피드백이 있길 바란다. 두번째, AspectJ를 위한 툴을 향상시킬수 있는 좀더 많은 기능이다. 여기엔 aspect지향 리팩토링과 개발을 위한 증가된 지원과 aspect라이브러리의 사용, 게다가 프로젝트내 AspectJ의 도입이 증가할때 압도적으로 많은 crosscutting표시자를 로드할수도 있음을 나타내는 "information overload"를 다루는 개발 방법들을 포함한다. AJDT는 사용자의 요구에 의해 지속된다. 그래서 당신이 필요하고 대부분의 문제를 야기하는 버그가 있으면 우리에게 알려달라.


자원#

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
jpg
ataspectj.jpg 66.3 kB 1 07-Jan-2006 11:16 이동국
jpg
comparison.jpg 42.0 kB 1 07-Jan-2006 11:16 이동국
jpg
declareanno.jpg 42.2 kB 1 07-Jan-2006 11:16 이동국
jpg
markers.jpg 51.8 kB 1 07-Jan-2006 11:16 이동국
jpg
migration.jpg 47.8 kB 2 07-Jan-2006 11:16 이동국
jpg
vis.jpg 41.2 kB 1 07-Jan-2006 11:16 이동국
jpg
weavemessages.jpg 22.2 kB 1 07-Jan-2006 11:16 이동국
jpg
xref1.jpg 20.0 kB 1 07-Jan-2006 11:16 이동국
jpg
xref2.jpg 30.7 kB 1 07-Jan-2006 11:16 이동국
jpg
xref3.jpg 35.8 kB 1 07-Jan-2006 11:16 이동국
« This page (revision-17) was last changed on 06-Apr-2006 09:45 by 이동국  
G’day (anonymous guest) My Prefs

Referenced by
AspectOrientedProgra...

JSPWiki v2.8.4