Fraemwork에 대한 자세한 정보를 얻기 위해서는 GoF - Ralph Johnson 과 POSA2 - Douglas Schmidth 의 논문들을 찾아보길 권해드립니다.
Framework = Semi Auto Application (반쯤 자동화된 Application을 의미한다 )
그럼 Framework와 Library의 차이점은 무엇일가? -> Control Flow를 가지고 있으면 Framework이다.
일반 라이브러리들은 단순히 모듈인 반면에, Framework는 내부적인 흐름을 가지고 좀더 응용, 적용하기 쉬운 구조를 가진다.
대두되는 사항 - Component가 재사용의 단위로 실패했기 때문에 요즘 Framework가 재사용의 단위로 각광박고 있다.
프레임워크는 어플리케이션 개발자들로 하여금 코드와 디자인을 재사용할 수 있도록 돕는다.
하지만 프레임워크를 개발하는 일은 결코 쉽지 않은 일이다. 우선, 프레임워크는 여러 어플리케이션이 이용할 수 있는 높은 추상화를
제공해야 하기 때문에 지나치게 일반화되는 경향이 있다. 이는 프레임워크를 필요 이상으로 복잡하게 하여 이해하기 어렵게 만든다.
더군다나 어플리케이션과 프레임워크의 개발을 동시에 진행하는 경우엔 문제가 더 복잡해진다.
이 논문에서는 성공적인 프레임워크 개발을 위한 각 단계별 패턴을 절차적으로 기술하고 있다.
적용; 프레임워크의 설계전 규모와 기능의 범위를 결정할 때
어플리케이션 개발팀의 다양한 요구 사항을 수렴하다보면 프레임워크의 복잡성도 그만큼 증대된다. 이런 복잡한 프레임워크는 만들기도 어려울 뿐더러
이해하고 사용하기도 쉽지 않다. 또한 개발 기간도 그만큼 길어지게 되어 프로젝트의 실패로 이어질 가능성이 커지게 된다.
세상의 모든 문제를 해결할 수 있는 프레임워크는 존재할 수 없다. 높은 추상화를 통해 제네릭한 알고리즘과 데이터 스트럭처를 제공하는 프레임워크는
그만큼 효율성의 손해를 가져온다. 따라서 적은 수의 핵심 기능에만 촛점을 맞추는 프레임워크를 설계하라.
관련 패턴; Skilled Team(3)은 단순한 프레임워크를 설계하는데 있어 꼭 필요한 요소다.
프로젝트가 진행되는 중에도 요구사항은 계속 변경될 수 있다. 이에 대해선 Multiple Change Requests(8)를 참조하라.
적용; 프레임워크의 설계와 개발과 관련하여
관련 패턴; 숙련된 팀일수록 The Beauty of Simplicity(2) 를 달성할 가능성이 높아진다.
적용; 프레임워크를 개발하기로 결정하고, 제공 기능을 정의할 때
프레임워크를 개발하기 위해서는 어플리케이션이 어떤 기능을 필요로 하는지 파악해야 한다. 그러나 어플리케이션 개발자는 자신들이 이용할 수
있는 프레임워크를 기다리고 있는 상황이다. 프로젝트를 진행하다보면 소위 이런 "계란과 달걀" 문제에 빠지기 쉽다. 이를 해결하기 위해
프레임워크를 이용할 파일럿 어플리케이션들을 미리 작성해 본 후 프레임워크가 제공해야 할 기능들을 파악하도록 한다. 이 때, 파일럿 어플리케이션의
수는 단순함을 위해 2개 정도가 적당하다.
관련 패턴; 파일럿 유저들과 협력하는 것은 Framework User Involvement(7)의 일종이다.
파일럿 어플리케이션들은 요구 사항을 파악할 때 뿐 아니라 테스트를 위해서 활용될 수 있다. Pilot-Based-Tests(6)
적용; 프레임워크의 범위과 기능이 명확히 정의된 후, 전체 기능을 세부 조각들로 나눌 때
프레임워크의 전체 기능을 분할할 때는 강력하고 광범위한 기능을 가지는 적은 수의 큰 오브젝트로 나누는 것보다, 덜 강력하지만 유연한 많은 수의
작은 오브젝트로 나누어라. 이럴 경우 비록 오브젝트의 수는 많아지지만 개개의 오브젝트들을 이해하는 것이 쉬워진다. 또한, 작은 오브젝트들은 여러
상황에서 보다 다양한 방식으로 조합될 수 있다.
관련 패턴; 오브젝트들을 작은 크기로 유지하는 일 또한 The Beauty of Simplicity(2)를 돕는다.
적용; 프레임워크 코딩 중, 테스트를 할 때
테스트는 QA에서 매우 중요한 요소이다. 하지만 프레임워크를 테스트 하는 일은 쉽지 않은 일이다. 프레임워크 자체는 단순히 추상적인
아키텍처일 뿐이지, 실행될 수 있는 무언가가 아니기 때문이다. 따라서 프레임워크를 사용하면서 기능들을 테스트해 볼 수 있는 샘플 어플리케이션이 필요하다.
이 때 사용될 수 있는게 파일럿 어플리케이션이다. 프레임워크의 다양한 기능들을 사용하는 파일럿 어플리케이션에 기반한 테스트를 수행하라.
적용; 프레임워크의 첫번째 버전을 완성하고 난 후
프레임워크를 쉽게 이용하도록 만들기 위해서는 사용자들에게 프레임워크의 실질적인 필요성을 각인시킬 필요가 있다. 이를 위해 사용자들을
지속적으로 참여시키는 방법이 필요하다. 이런 방법으로는 모두가 함께 참여하는 워크샵이 될 수도 있고, 프레임워크 사용을 돕는 툴을 제공하는
것도 생각할 수 있다. 하지만 이런 행위들이 비용과 시간을 상승시킨다는 점을 감안해서 적절히 조절할 필요가 있다.
적용; 어플리케이션들이 프레임워크를 이용하던 중, 추가적인 기능을 요구할 때
개별적인 어플리케이션 요구사항들을 프레임워크에 모두 수용하다보면 프레임워크는 급격히 높은 복잡성을 갖게 된다. 따라서 몇몇 팀에서 사용할
추가 기능만 프레임워크에 포함시키도록 하라. 여기서 몇몇의 정의는 프레임워크를 이용하는 전체 팀의 수에 의해 결정된다. 만약 프레임워크를 4개의
팀이 이용하는 경우라면, 2개팀 정도가 적당하다.
많은 경우, 어플리케이션이 필요로 하는 추가적인 기능은 프레임워크에서 처리하는 것보다 직접 처리하는 것이 효율적이다.
관련 패턴; Concrete Eveidence for Reuse(1)와 마찬가지로 추가적인 기능 요구사항도 그것을 다른 어플리케이션이 재사용한다는 보장이 있을때만 추가하라
결론적으로, 성공적인 모든 프레임워크는 다음과 같은 특징들을 갖는다는 것을 알 수 있다.
