Search Results for '분류 전체보기'

244 POSTS

  1. 2006.08.30 XDoclet
  2. 2006.08.30 소프트웨어 프로젝트 완료 조건
  3. 2006.08.30 JSR-170 Java Content Repository API
  4. 2006.08.30 테스트 주도 개발

XDoclet

Posted 2006. 8. 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은 대안이 될 것이다.

소프트웨어 프로젝트 완료 조건

Posted 2006. 8. 30. 20:06
소프트웨어 작성 계약을 맺을 때는 프로젝트 종료 시점을 분명히하고 완료 테스트를 명확히 지정해야한다고 배웠습니다. 하지만 실제로 프로젝트를 하면 이런 조언을 지키기가 쉽지가 않네요. 방학 때 용돈이나 벌어볼 목적으로 매트록스 라인 카메라를 이용한 홀(hole) 검출 프로그램을 작성하였는데, 이게 예상과는 달리 끝이날 조짐이 안 보이네요. 공장에 가서 테스트를 해야 마무리 지을텐데, 어떻게 된 사정인지 회사에서는 테스트를 계속 연기하고 있습니다.

계약서에 종료 시점이나 종료 조건을 명확하게 표시하지 않았던 점이 조금 후회스럽군요. 특정 시점을 넘길 때까지 상대방의 협조 부족으로 프로젝트가 진행되지 못하면 어떻게 하겠다는 식의 조항을 넣었어야 하는데 말이죠. 지금에서야 이런 생각을 하지만, 그 당시에는 그저 잘 풀리겠지하고 막연히 생각했던게 화근인 것 같습니다. 어쨌거나 잘 마무리해서 남은 돈을 받아야할텐데, 왠지 걱정이 되는군요.

JSR-170 Java Content Repository API

Posted 2006. 8. 30. 19:58
IBM developers@work에서 [Introducing the Java Content Repository API]를 읽어봤다.

JSR-170은 Content Repository API를 의미하는데, 각종 컨텐트를 보관, 검색, 버저닝(versioning)하는 방법을 표준화하려는 시도이다. 현재 오픈 소스 구현으로는 Apache Jackrabbit이 있다. JSR-170은 하부 구현에 대해서는 언급이 없기 때문에 파일 시스템, WebDAV, DB 등 다양한 방식이 사용될 수 있다.

요즘 작성되는 대부분의 웹 어플리케이션(위키, 블로그, 게시판) 등이 사실은 컨텐트를 잘 저장하고 다시 꺼내오는 것에 지나지 않음을 생각하면 이런 프레임워크가 표준화되었을 경우 많은 득이 있을 것 같다.

테스트 주도 개발

Posted 2006. 8. 30. 19:11
The case for static types라는 IBM developers@work의 기사를 읽다가 괜찮은 아이디어를 얻었다.

Extreme Programming에서는 코드 작성 이전에 테스트 케이스를 만드는 게 좋다고 권고하는데, 자바처럼 StaticType Check하는 언어의 경우 테스트를 먼저 만들어도 컴파일해 볼 수 없다는 문제가 있다. 최소한 메쏘드의 인자와 리턴타입을 알 수 있는 스텁(stub) 클래스는 존재해야만 컴파일해 볼 수 있다.

하지만 스텁 클래스를 만드는 것 자체가 상당한 디자인을 요한다. 특히 자바 같은 경우 클래스 인터페이스를 만드는 게 코딩의50% 이상이라고 말해도 과언이 아니다. 테스트 케이스 작성을 먼저하는 이유는 인터페이스를 고정하기 전에 클래스의 유스케이스를먼저 보겠다는 뜻인데, 이에 맞춰서 스텁을 제공하는 것은 고역인 셈이다.

이에 대한 대안으로 필자의 제안처럼 테스트 도구가 자동으로 인터페이스(스텁)를 만들어주는 방법이 있다. NextGen에 스텁 생성(Stub-generating) 모드라는 걸 작업하고 있다는데, 이런 종류의 프로젝트를 시작해 보는 것도 괜찮을듯 싶다.
« PREV : 1 : ··· : 10 : 11 : 12 : 13 : NEXT »