Patterns for Successful Framework Development

1169962 Patterns for Successful Framework Development 1169958 2008-05-10T12:20:12Z http://fdg.springnote.com/pages/1169962 2008-05-09T16:08:35Z <h1>Patterns for Successful Framework Development</h1> <h5>Framework란 무엇인가? 그리고 왜 대두되어지고 기존의 라이브러리와의 차이점은 무엇인가?</h5>   Fraemwork에 대한 자세한 정보를 얻기 위해서는   GoF - Ralph Johnson 과 POSA2 - Douglas Schmidth 의 논문들을 찾아보길 권해드립니다. Framework = Semi Auto Application (반쯤 자동화된 Application을 의미한다 ) 그럼 Framework와 Library의 차이점은 무엇일가?  -> Control Flow를 가지고 있으면 Framework이다. 일반 라이브러리들은 단순히 모듈인 반면에, Framework는 내부적인 흐름을 가지고 좀더 응용, 적용하기 쉬운 구조를 가진다. 대두되는 사항 - Component가 재사용의 단위로 실패했기 때문에 요즘 Framework가 재사용의 단위로 각광박고 있다.   <h5>요약및 토론 내용</h5>   프레임워크는 어플리케이션 개발자들로 하여금 코드와 디자인을 재사용할 수 있도록 돕는다. 하지만 프레임워크를 개발하는 일은 결코 쉽지 않은 일이다. 우선, 프레임워크는 여러 어플리케이션이 이용할 수 있는 높은 추상화를 제공해야 하기 때문에 지나치게 일반화되는 경향이 있다. 이는 프레임워크를 필요 이상으로 복잡하게 하여 이해하기 어렵게 만든다. 더군다나 어플리케이션과 프레임워크의 개발을 동시에 진행하는 경우엔 문제가 더 복잡해진다.   이 논문에서는 성공적인 프레임워크 개발을 위한 각 단계별 패턴을  절차적으로 기술하고 있다.   <img alt="" /><img alt="" /><img title="overview.JPG" class="attachment" src="/pages/1169962/attachments/506860" height="514" alt="overview.JPG" width="590" />           <h6>1. Concrete Evidence for Reuse</h6> <div> <ul> <li>문제; 당신의 프로젝트에서 프레임워크가 필요하다는 것을 어떻게 확신할 수 있는가?</li> <li>적용; 프레임워크 개발전 feasibility를 파악할 때</li> </ul>   <ul> <li>프레임워크를 개발하는데 드는 비용은 일반 어플리케이션을 개발시보다 보통 3배 이상이 들어간다. 따라서 반드시 최소 3개 이상의 어플리케이션에서 이 프레임워크를 이용한다는 보장이 있을때에만 개발에 착수하라.</li> </ul>   <ul> <li>관련 패턴; 만약 어플리케이션이 프레임워크를 이용할지 불분명하다면 PILOT APPLICATIONS(4) 패턴을 적용하여 당위성을 파악할 수 있다.</li> </ul>   <ul> <li>참고; Don Roberts and Ralph Johnson의 논문에 THREE EXAMPLES에 대한 언급이 있다 - <a href="/pages/1169962/attachments/506864" title="evolving.pdf" class="attachment">evolving.pdf</a></li> </ul> </div>   <h6>2. The Beauty of Simplicity</h6> <div> <ul> <li>문제; 어떻게 프레임워크를 관리 가능한 규모로 유지할 것인가?</li> <li> 적용; 프레임워크의 설계전 규모와 기능의 범위를 결정할 때   </li> <li> 어플리케이션 개발팀의 다양한 요구 사항을 수렴하다보면 프레임워크의 복잡성도 그만큼 증대된다. 이런 복잡한 프레임워크는 만들기도 어려울 뿐더러 이해하고 사용하기도 쉽지 않다. 또한 개발 기간도 그만큼 길어지게 되어 프로젝트의 실패로 이어질 가능성이 커지게 된다. 세상의 모든 문제를 해결할 수 있는 프레임워크는 존재할 수 없다. 높은 추상화를 통해 제네릭한 알고리즘과 데이터 스트럭처를 제공하는 프레임워크는 그만큼 효율성의 손해를 가져온다. 따라서 적은 수의 핵심 기능에만 촛점을 맞추는 프레임워크를 설계하라.   </li> <li> 관련 패턴; Skilled Team(3)은 단순한 프레임워크를 설계하는데 있어 꼭 필요한 요소다.                프로젝트가 진행되는 중에도 요구사항은 계속 변경될 수 있다. 이에 대해선 Multiple Change Requests(8)를 참조하라.   </li> <li>참고; Wolfgang Pree, et al. 은 매우 작고 느슨하게 연결되어 어플리케이션의 부분 아키텍처를 제공하는 프레임워크를 Framelets 라 정의하고 있다. - <a href="/pages/1169962/attachments/506886" title="a6-pree.pdf" class="attachment">a6-pree.pdf</a></li> </ul> </div>   <h6>3. Skilled Team</h6> <div> <ul> <li>문제; 어떻게 프레임워크를 명확하고 일관된 방식으로 설계할 것인가?</li> <li> 적용; 프레임워크의 설계와 개발과 관련하여   </li> <li>프레임워크 개발은 대단히 숙련된 기술을 필요로 하는 작업이다. 프레임워크 개발 경험이 없거나 최소한 해당 어플리케이션 도메인에 대한 지식이 없는 팀은 대부분 실패할 수 밖에 없다. 따라서 반드시 프레임워크 개발에 숙련된 인원들로 팀을 조직하고, 이들중 최소 몇몇은 해당 어플리케이션 도메인에 대한 경험 또한 갖고 있는 것이 좋다. 또한 이들은 프레임워크 사용자와의 적절한 피드백을 위해 반드시 커뮤니케이션 기술을 갖추어야 한다.</li> </ul>   <ul> <li> 관련 패턴; 숙련된 팀일수록 The Beauty of Simplicity(2) 를 달성할 가능성이 높아진다. </li> </ul> </div>   <h6>4. Pilot Applications</h6> <div> <ul> <li>문제; 어떻게 프레임워크에 대한 구체적인 요구 사항을 파악할 것인가?</li> <li> 적용; 프레임워크를 개발하기로 결정하고, 제공 기능을 정의할 때   </li> <li> 프레임워크를 개발하기 위해서는 어플리케이션이 어떤 기능을 필요로 하는지 파악해야 한다. 그러나 어플리케이션 개발자는 자신들이 이용할 수 있는 프레임워크를 기다리고 있는 상황이다. 프로젝트를 진행하다보면 소위 이런 "계란과 달걀" 문제에 빠지기 쉽다. 이를 해결하기 위해 프레임워크를 이용할 파일럿 어플리케이션들을 미리 작성해 본 후 프레임워크가 제공해야 할 기능들을 파악하도록 한다. 이 때, 파일럿 어플리케이션의 수는 단순함을 위해 2개 정도가 적당하다.   </li> <li> 관련 패턴; 파일럿 유저들과 협력하는 것은 Framework User Involvement(7)의 일종이다.                파일럿 어플리케이션들은 요구 사항을 파악할 때 뿐 아니라 테스트를 위해서 활용될 수 있다. Pilot-Based-Tests(6)   </li> <li>참고; Customer와의 interaction을 강조하는 논문으로 Linda Rising의 "Customer Interaction Patterns"가 있다. - <a href="/pages/1169962/attachments/506906" title="CustomerInteraction.pdf" class="attachment">CustomerInteraction.pdf</a></li> </ul> </div>   <h6>5. Small Objects</h6> <div> <ul> <li>문제; 어떻게 하면 프레임워크의 복잡성을 낮게 유지하면서 유연성을 높일것인가?</li> <li> 적용; 프레임워크의 범위과 기능이 명확히 정의된 후, 전체 기능을 세부 조각들로 나눌 때   </li> <li> 프레임워크의 전체 기능을 분할할 때는 강력하고 광범위한 기능을 가지는 적은 수의 큰 오브젝트로 나누는 것보다, 덜 강력하지만 유연한 많은 수의 작은 오브젝트로 나누어라. 이럴 경우 비록 오브젝트의 수는 많아지지만 개개의 오브젝트들을 이해하는 것이 쉬워진다. 또한, 작은 오브젝트들은 여러 상황에서 보다 다양한 방식으로 조합될 수 있다.   </li> <li> 관련 패턴; 오브젝트들을 작은 크기로 유지하는 일 또한 The Beauty of Simplicity(2)를 돕는다.   </li> <li>참고; Concrete Evidence for Reuse에 언급된 논문(Ralph Johnson, et al.)에 Fine-Grained Objects에 관한 내용이 나온다.</li> </ul> </div>   <h6>6. Pilot-Based Tests</h6> <div> <ul> <li>문제; 어떻게 프레임워크를 충분하고 신뢰성있게 테스트 할 수 있는가?</li> <li> 적용; 프레임워크 코딩 중, 테스트를 할 때   </li> <li> 테스트는 QA에서 매우 중요한 요소이다. 하지만 프레임워크를 테스트 하는 일은 쉽지 않은 일이다. 프레임워크 자체는 단순히 추상적인 아키텍처일 뿐이지, 실행될 수 있는 무언가가 아니기 때문이다. 따라서 프레임워크를 사용하면서 기능들을 테스트해 볼 수 있는 샘플 어플리케이션이 필요하다. 이 때 사용될 수 있는게 파일럿 어플리케이션이다. 프레임워크의 다양한 기능들을 사용하는 파일럿 어플리케이션에 기반한 테스트를 수행하라.   </li> <li>관련 패턴; Pilot Applications(4) 패턴을 통해 도움을 받을 수 있다.                프레임워크 개발자는 사용자들에게 다양한 테스트 시나리오를 받을 수 있다. Framework User Involvement(7)</li> </ul> </div>   <h6>7. Framework User Involvement</h6> <div> <ul> <li>문제; 어떻게 하면 유저들로 하여금 프레임워크를 이용하도록 만들 것인가?</li> <li> 적용; 프레임워크의 첫번째 버전을 완성하고 난 후   </li> <li> 프레임워크를 쉽게 이용하도록 만들기 위해서는 사용자들에게 프레임워크의 실질적인 필요성을 각인시킬 필요가 있다. 이를 위해 사용자들을 지속적으로 참여시키는 방법이 필요하다. 이런 방법으로는 모두가 함께 참여하는 워크샵이 될 수도 있고, 프레임워크 사용을 돕는 툴을 제공하는 것도 생각할 수 있다. 하지만 이런 행위들이 비용과 시간을 상승시킨다는 점을 감안해서 적절히 조절할 필요가 있다.   </li> <li>관련 패턴; Pilot Applications(4)이 사용자들로부터 얻는 과정이라면, 이 패턴은 사용자들에게 전달하는데 촛점을 맞춘 과정이다.</li> </ul> </div>   <h6>8. Multiple Change Requests</h6> <div> <ul> <li>문제; 요구사항의 변경으로 인해 프레임워크가 복잡해지는 것을 막을수 있는 방법은 무엇인가?</li> <li> 적용; 어플리케이션들이 프레임워크를 이용하던 중, 추가적인 기능을 요구할 때   </li> <li> 개별적인 어플리케이션 요구사항들을 프레임워크에 모두 수용하다보면 프레임워크는 급격히 높은 복잡성을 갖게 된다. 따라서 몇몇 팀에서 사용할 추가 기능만 프레임워크에 포함시키도록 하라. 여기서 몇몇의 정의는 프레임워크를 이용하는 전체 팀의 수에 의해 결정된다. 만약 프레임워크를 4개의 팀이 이용하는 경우라면, 2개팀 정도가 적당하다. 많은 경우, 어플리케이션이 필요로 하는 추가적인 기능은 프레임워크에서 처리하는 것보다 직접 처리하는 것이 효율적이다.   </li> <li> 관련 패턴; Concrete Eveidence for Reuse(1)와 마찬가지로 추가적인 기능 요구사항도 그것을 다른 어플리케이션이 재사용한다는 보장이 있을때만 추가하라 </li> </ul> </div>     결론적으로, 성공적인 모든 프레임워크는 다음과 같은 특징들을 갖는다는 것을 알 수 있다.   <ul> <li>핵심적인 작업들에만 촛점을 맞춘다.</li> <li>재사용이 쉬운 영역을 다룬다.</li> <li>사용하기가 쉽다.</li> <li>프레임워크 개발자와 이용자들간에 긴밀하고 강력한 협력이 이루어진다.</li> </ul>   by-nc-nd http://only2u4u.myid.net/ http://only2u4u.myid.net/ 219