객체지향언어로 개발되는 경우, 프레임워크라는 이름으로 개발에 기반이 되는 라이브러리들을 거의 다 제공하고 있습니다. 심지어 특정 문제를 해결할 수 있는 이름 그대로 프레임워크를 제공하기도 합니다. 우리는 데이터베이스 액세스를 위해서나 소트를 위해서 별도의 개발을 하지 않습니다. 물론 이것은 저수준 언어를 사용하거나 다양한 라이브러리를 제공받지 못하는 환경에서의 개발은 제외하고 말하는 것입니다.

어떤 기능을 어떤 품질특성을 갖고 제공해야 하는가?를 알고, 이를 프레임워크에서 제공하는 컴포넌트나 클래스로 매핑할 수 있으면 개발이 된다는 것입니다. 이는 메커니즘이나 패턴이라는 이름으로 시도되고 있습니다. 그러나 이러한 시도들은 단편적이고 요구사항에서 구현 프레임워크와 라이브러리까지 연결이 원활치 못합니다.

use case driven, architecture centric은 기능, 비기능(품질특성)요구를 중심으로 개발할 수 있는 방법을 제시하고는 있지만 하향적 접근방식으로 구현 프레임워크나 라이브러리들에 와서 충돌이 발생하곤 합니다.

우리는 요구사항으로 부터 구현 프레임워크와 라이브러리까지의 요구사항에 대한 서로 다른 추상수준들 사이의 매핑을 통해 개발을 완료하는 방법이 있기를 원합니다.

그리고 이런 방법을 ‘목적이 이끄는 개발(goal driven development)’ 방식이라 부릅니다.

이를 위해서는 먼저 구현 프레임워크나 라이브러리들로 부터 요구사항으로의 상향식 매핑이 요구됩니다. 대부분 구현 프레임워크나 라이브러리 개발자들은 특정 문제해결을 염두에 두고 이것들을 개발했을 것입니다.

이때 라이브러리의 클래스들은 문제 해결의 일부를 담당하기 위해 개발되었기 때문에 문제 중심으로 이들을 조합해서 패턴화 할 필요가 있습니다. 물론 이들의 사용은 다양하기 때문에 쉽지 않습니다. 쉽지 않다고 가능하지 않은 것은 아닙니다. 아주 특수한 부분에 대해서는 못하겠지만 어느 정도 일반화된 부분에 대해서는 가능합니다. 이러한 일반화된 방식을 제시하는 것들이 책입니다.

구현 프레임워크와 라이브러리의 상향식 접근방식과 RUP의 분석메커니즘으로 부터 설계메커니즘 구현메커니즘으로의 진행과 같은 메커니즘 방식과 아키텍처 패턴에서 설계 패턴으로의 연결과 같은 패턴지향 방식과, use case driven, architecture centric 방식을 결합하면 어느정도 결과가 나올 것 같습니다.

목적이 이끄는 개발에서는 기능/비기능 요구들을 획득한 이후, 이들에 대해 연속적으로 좀 더 낮은 추상수준으로 매핑을 통해 개발을 완료합니다. 가장 낮은 추상수준은 구현 프레임워크와 문제중심으로 결합된 라이브러리 클래스들의 조합입니다.

개발자가 할 일은 상위추상수준의 표현에 대한 하위추상수준의 표현을 선택하는 것 뿐입니다. 이런 방식은 MDA와도 접근법이 유사합니다. MDA의 현실적인 적용이라 할 수 있습니다.

항상 커튼 뒤에서는 우리가 보지 못하는 더 많은 일들이 일어납니다. 목적이 이끄는 개발방식을 위해서는 상위추상과 하위추상의 표현들과 이들의 매핑을 지속적으로 갱신해주는 사람들이 있어야 합니다. 구현 라이브러리를 문제해결 중심으로 지속적으로 패턴화해서 제공해주는 사람들이 있어야 합니다. 도구를 만드는 사람과 같이 더 많은 사람들이 더 많은 일들을 위해 필요할 수 있습니다. 이러한 방식은 한 개발자에 의해 가능한 것이 아니라, open source와 같은 방식을 따라 진행되어야 합니다. open source는 source에 대한 공유 였습니다. 개발지식에 대한 다양한 공유방식이 있지만 실제 source의 공유는 아니었습니다.