Search Results for 'AOP'

3 POSTS

  1. 2006.10.13 Complexity of AOP
  2. 2006.10.11 AOP and DBC
  3. 2006.08.30 XDoclet

Complexity of AOP

Posted 2006.10.13 11:15
오늘 과제 연구 때문에 지도 교수님과 면담을 하고 왔는데, AOP(Aspect-Oriented Programming)의 복잡도에 대한 이야기를 나누었습니다.

AOSD(Aspect-Oriented Software Development)가 crosscutting concern을 캡슐화하는 아이디어는 좋지만, 코드를 읽을 때는 이해도(understandability)는 생각보다 떨어진다는 것이 AOP의 큰 단점입니다. 특히 사실상 정규식(regular expression)의 방식으로 포인트컷(pointcut)을 지정해서는, 복잡하고 큰 소프트웨어의 경우 어떻게 영향을 받는지 이해하기는 상당히 어렵습니다.

현재 AspectJ의 Eclipse 플러그인을 보면 이렇게 Aspect의 기존 컴포넌트 사이의 관계를 도식적으로 보여주고, aspect가 지정한 포인트컷을 표시해주는 기능이 있던데, 이런 도구에 대한 연구가 좀 더 필요한 것 같습니다.
신고

AOP and DBC

Posted 2006.10.11 22:59
최근에 AOP(Aspected Oriented Programming) 관련해서 과제 연구 주제를 찾고 있었는데, 흥미롭게도 AOP의 어플리케이션 중에 하나가 DBC(Design By Contract)의 구현이다. 사실 아직 AOP 초보인지라, 사용 사례를 로깅이나 보안 쪽 정도 밖에 생각 못하고 있었는데, DBC의 Pre/Post-Condition과 Invariant도 business logic과는 별개의 separate concern으로 생각할 수 있었다.

실제로 Developers@Work에 실린 Contract enforcement with AOP를 보면 AspectJ를 이용해 자바에서 DBC를 구현하는 간단한 예를 보여주고 있다. 간단하게 생각하면 Precondition는 메쏘드 실행 전에, Postcondition는 메쏘드 실행 후에 불러주고, Invariant는 실행 전후로 확인하면 되므로,

<Contract enforcement with AOP에서 발췌한 코드>
public abstract aspect AbstractContract
{
   /**
   * Define the pointcut to apply the contract checking
   * MUST CONTAIN A METHOD CALL
   */

   public abstract pointcut targetPointcut();

   /**
   * Define the ContractManager interface implementor to be used
   */

   public abstract ContractManager getContractManager();

   /**
   * Perform the logic necessary to perform contract checking
   */

   Object around(): targetPointcut()
   {
      ContractManager cManager = getContractManager();
      System.out.println("Checking contract using:" +
        cManager.getClass().getName());

      if (cManager!=null)
      {
         System.out.println("Performing initial invariants check");
         cManager.checkInvariants(thisJoinPoint.getTarget());
      }
      if (cManager!=null)
      {
         System.out.println("Performing pre-conditions check");
         cManager.checkPreConditions(thisJoinPoint.getTarget(), thisJoinPoint.getArgs());
      }

      Object obj = proceed();

      if (cManager!=null)
      {
         System.out.println("Performing post conditions check");
         cManager.checkPostConditions(thisJoinPoint.getTarget(),
           obj, thisJoinPoint.getArgs());
      }
      if (cManager!=null)
      {
         System.out.println("Performing final invariants check");
         cManager.checkInvariants(thisJoinPoint.getTarget());
      }
      return obj;
   }
}

위 코드의 예처럼 Template 메쏘드를 사용하면 일반적인 Contract enforcement가 구현 가능하다. 따라서 사용자는 targetPointcut을 override해서 어디에 삽입할 것인지를 정하고, ContractManager를 통해 실제 구현을 집어넣을 수 있다.

이 아이디어를 발전시켜서 실제로 DBC 구현에 Aspect를 사용한 예가 Contract4J이다. 해당 프로젝트 홈페이지에 나온 AOP와 DBC의 관계는 다음과 같다.

Design by Contract and Aspect-Oriented Programming

So what does DbC have to do with Aspect-Oriented Programming (AOP)? On the one hand, the component's contract is an essential part of the complete, logical component specification that clients must support. For example, an interface for a bank account may have a contract requirement that all methods that return a balance must always return a non-negative number (ignoring overdraft features). However, in practical terms, contracts often include implementation concerns that may have little relationship to the domain logic of the application. For example, the code implementing the bank account may prohibit passing null values as method parameters.

For both types of contract details, AOP allows us to specify the details with sufficient "proximity" to the interface so that clients can see the constraints and AOP gives us an elegant way of testing the constraints at runtime without cluttering the code with logic to run the tests and handle failures.

More generally, AOP is a new approach to modularizing "concerns" that need to be handled by a component, but which tend to obscure the main logic of the component, often compromising clarity, maintainability, reusability, etc. For example, modern web and enterprise applications typically must support secure access, transactional behavior, persistence of data, and mundane support issues like logging. Without AOP, the code for these "concerns" gets mixed in with the domain logic, thereby cluttering the code and diminishing the "ilities" we all strive for. AOP keeps these concerns in separate modules and provides powerful facilities for "injecting" the concern behavior in the specific execution points where needed. Contract4J5 uses AOP techniques to find the contract specifications and test them at runtime at the appropriate execution points.

AOP is a good approach to supporting DbC because it permits DbC concerns to be managed in a modular and minimally-intrusive way, without cluttering application logic, while still allowing the contracts to be integrated into the runtime environment for development and testing. Contract4J5 uses the best-known AOP language, AspectJ, to support DbC for Java.

For more information on AOP, see the references below.

요약하면 application logic에서 DBC를 분리해 @pre ( ), @post ( ) 같은 방식으로 써준다. 이렇게 하면 DBC 관련 코드와 application code가 뒤섞여서 생기는 문제를 해결할 수 있다. 하지만 실제 실행 시에 해당 코드를 메쏘드 앞 뒤로 자연스럽게 껴 넣을 수 있기 때문에 AOP가 DBC 구현에 좋다.
신고

XDoclet

Posted 2006.08.30 21:27
XDoclet은 오픈 소스 코드 생성 엔진으로, 자바에서 관점 지향 프로그래밍 (Attributed-Oriented Programming)을 가능하게 해준다. 쉽게 말해서 자바 소스 코드에 메타 데이터를 더해서, 코드만으로 표현하지 못했던 여러 가지 정보를 추가한 후에 관련된 코드 및 데이터 생성을 자동화하는 것이다. 이런 메타 정보는 기존 JavaDoc에 특수한 태그를 추가해서 지정할 수 있다.

예를 들어 어플리케이션을 JAR 파일로 묶을 때는 디스크립토 파일을 만들어서 더해주어야 한다. 개발 과정에서 이 작업이 반복되면 무척 귀찮은데, 디스크립토에 들어갈 정보를 XDoclet을 이용해 소스 코드에 직접 기술해주면 XDoclet 프로그램이 이 정보를 추출해 자동으로 JAR 디스크립토를 만들어준다. 특히 복잡한 컴포넌트의 경우 여러 개의 파일을 별도로 관리할 필요 없이 자바 파일 하나만 업데이트 하면 되기 때문에 유지보수성(maintainability)가 좋아진다.

특히 EJB의 경우 보통 7개 이상의 보조 파일을 필요로 하는데, 이런 메타 데이터와 자바 소스 코드의 싱크를 맞추려면 상당한 노력이 든다. 소스 코드만 업데이트하고, 메타 데이터는 업데이트하지 않을 경우 이상한 문제에 부딪힐 수도 있다. XDoclet을 이용하면 자바 소스 파일에 기술된 특수 태그를 통해 EJB가 필요한 각종 메타 데이터를 생성해 낼 수 있다. XDoclet의 통계에 따르면, EJB 프로그램에서 필요한 코드의 85%를 XDoclet이 자동으로 생성해 준다고 한다.

XDoclet은 처음에 EJB 개발을 돕기 위해 출발했지만, 지금은 범용적인 어트리뷰트 지향 프로그래밍을 표방하고 있다. 스텁(stub)과 스켈레톤(skeleton) 클래스를 생성해 주어야 했던 과거 자바 RMI 경우도 XDoclet을 사용했다면, 보조 클래스 생성을 자동화시킬 수 있었을 것이다.

XDoclet은 Java 5의 어노테이션(annotation)의 필요성을 인식시키는데 많은 영향을 미쳤다. 현재 XDoclet의 기능 중 상당수는 자바 어노테이션을 이용해서 가능하지만, XDoclet은 여러 프로젝트에 적용해온 노하우가 있으므로, 이와 같은 기능을 필요로 한다면 XDoclet은 대안이 될 것이다.
신고

티스토리 툴바