Search Results for 'DBC'

3 POSTS

  1. 2006.10.20 Design by Contract의 문제점 (1)
  2. 2006.10.11 AOP and DBC
  3. 2006.10.11 Design By Contract(DBC) and Eiffel

Design by Contract의 문제점

Posted 2006.10.20 16:04
현재 DbC 도구나 언어는 계약 관계를 표현하는 방법이 쉽지만은 않다. 간단한 예제들은 이진 표현(예를 들어 a >= 0.0)으로 간단하게 필요한 조건을 표현할 수 있었지만, 실제 프로젝트를 적용해 보려고 하면 생각보다 다양한 상황을 표현할 수 있는 방법이 필요함을 알 수 있다. 예를 들어 배열로 넘어온 인자에서 모든 값이 0보다 커야 한다던지 하는 경우 지금의 DbC 도구들로 표현하기가 어려운 면이 있다.

사실 계약에 사용되는 언어는 또 다른 프로그래밍 언어인 셈이다. Contract4J의 경우도 @Pre, @Post, @Invar 등에 사용되는 언어는 자바와 유사하지만 자바와는 또 다른 계약을 표기하기 위한 언어이다. $return이나 $old 같이 특수한 값을 지정할 수도 있어야하고, 계약 언어 특유의 요구 사항에 따라 자바 언어와는 다른 여러 가지 기능을 지원할 수도 있어야할 것이다.

이런 계약 언어가 아직까지는 초기 단계이기 때문에 표현력이 많이 떨어지는 편이다. 현재 UML의 OCL(Object Constraint Language)를 계약 언어로 사용하기 위한 노력들이 있는데, 관련 도구들이 발전한다면 앞으로의 상황은 점점 나아질 것이다. 하지만 금으로서는 DbC 언어의 한계가 사용에 걸림돌이 되는 것만은 사실이다.
신고

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 구현에 좋다.
신고

Design By Contract(DBC) and Eiffel

Posted 2006.10.11 22:40
흔히 Object-Oriented 코드를 디자인할 때 "Design By Contract(DBC)"를 따르면, robust/reliable한 코드를 얻을 수 있다고 이야기를 합니다. DBC의 특징을 간략하게 요약하면 컴포넌트를 디자인할 때 Pre-Condition, Post-Condition, Class Invariants 등을 명확하게 정의하는 것을 말합니다. DBC의 창시자인 버트란드 마이어(Bertlant Meyer)가 만든 Eiffel 프로그래밍 언어는 이런 DBC를 프로그래밍 언어 속에 녹여 넣은 것으로 유명하고요.

DBC를 언급하면 항상 Eiffel이 따라 나오긴 하는데, 실제로 Eiffel로 뭔가 프로젝트를 진행하고 있는 사례가 궁금합니다. 특히 한국에서도 일부 블로그에 보면 DBC 이야기를 하시던데, 실제로 DBC, 더 나아가서 Eiffel을 프로젝트에 사용하고 있는 경우가 있는지요? 사례를 한 번 들어보면 좋을 것 같다는 생각이 듭니다.
신고

티스토리 툴바