Framework Design Guideline

Framework's Day

Mon, 01 Dec 2008 01:01:38 +0900

강의 자료

세션 1. Evolving_Framework.pptx

세션 2. Framework_Engineering.pptx

세션 3. BFnAS.pptx

세션 4. ASP.NET_MVC.pptx

세션 5. [SSM]ADO.NET_EntityFramework.ppt

세션 6. Session6_(iBatisNet_SpringNet).pptx

Evolving Frameworks

Sun, 21 Sep 2008 22:54:47 +0900

Design Pattern을 창시한 GoF의 한명이자, Framework 설계의 대가 Ralph Johnson.

소프트웨어 설계에 관심있는 분이라면, 한번쯤은 들어보셨을 겁니다.

Framework Design Guideline 번역을 위해, Framework 관련 Paper들을 계속해서 읽고 있습니다.

그러면 꼭 만나는 분이 Ralph Johnson입니다.

그는 Martin Fowler의 직,간접적인 스승이며, 그가 이 분야에 미치는 영향은 실로 대단합니다.

아래와 같이 Framework에 관련된 논문을 4개 쓰셨는데요.

Designing Reusable Classes

그 중 가장 마지막 자료인 Evolving Frameworks 논문을 다 읽고, 이 POST를 통해 여러분과 공유하는 시간을 가지고자 합니다.

이 논문은 9가지 패턴으로 구성되어 있는, 위 그림과 같이 시간이 지나면서 언제 해당 패턴을 적용해야 하는지, 연관된 패턴은 무엇인지를 설명하고 있습니다.

Three Example

특정 도메인을 위한 Framework를 개발할려고 할때, 여러분이 참고로 할만한 Framework Reference도 없고, 설계 경험도 없다면 어떻게 해야 할까요?

그럼 세개의 Application을 이용하여 Framework를 설계해야 합니다.

Whitebox Framework

Framework를 사용하는 두번째 Application을 만들때, 어떻게 해야 할까요? 첫번째 Application을 작성하기 위해 사용했던 Framework를 상속(Inheritance)을 이용해 확장해야 할가요?

다형성을 기반으로한 Composition(조합)을 써야 할까요? 물론 저의 생각은 예전 Posting에서 언급한 것과 같이 두가지를 적절히 조합해서 사용해야 된다는 것입니다.

모든 Pattern들이 그렇듯이 상속을 이용하여 계약 기반의 일원화된 Interface를 확립함으로써, 클라이언트는 필요에 따라 적절한 Concrete Class를 조합하여 이용함으로써, 확장성및 유연성을 가져올수 있습니다.

위 문장이 이해가 가지 않으시는 분은 제가 예전 블로그에 포스트한 "잘못 알려진 디자인 패턴의 두번째 원칙"을 읽어 보시면 좀더 명확해 지실 겁니다. 시간이 될때 추후 이 블로그로 옮겨 와야 겠네요 ^^

다시 돌아와 단지 재사용의 관점에서 상속을 이용하면 변하는 것과 변하지 않는 것을 쉽게 구분할수 있습니다. 여기서 변하는 부분들을 상속관계로 Subclass를 만들어 사용합니다.

상속을 통해 전체 Framework의 흐름을 일관성 있게 제어할 수 있습니다. (추후 변하지 않는 부분들은 추후 Blackbox Framework로 구성합니다.)

Component Library

Whitebox Framework 기반으로 두번째 Application을 순차적으로 개발할때, 어떻게 유사한 Object를 Framework에서 각각 Instacne화 하는 것을 피할수 있을까요?

정답은 공통화된 내용이나 흐름을 조절하는 추상 Class(대표적인 경우 Template Method Pattern) 들은 Framework에 두고, 실제 Concrete Class들을 Application내에 존재하게 하면 됩니다.

그리고 다양한 Application으로 부터 생성된 Concrete Class를 취합하여 Component Library를 구성함으로서, 재사용성을 높이는 것입니다.

Framework와 Library를 구분하는 방법은 여러가지가 있지만, 가장 큰 차이는 흐름을 제어하는 Flow Control의 차이입니다.

Framework는 Flow Control을 가지고 있어 내부적으로 어느정도 흐름을 제어할 수 있게 해주기 때문에, 개발자가 좀더 쉽게 사용할 수 있는 Semi-Application이 라고 불리웁니다.

이 맥락으로 볼때 Ralph Johnson 역시 Framework를 통해서 전체적인 흐름을 제어하고, Component Library를 통해서 재사용을 확보함으로써, 확장성(유연성), 재사용성을 확보하는 일거양득를 노렸다고 볼수가 있습니다.

Hot Spots

Component Library에 Component를 계속해서 추가할때, 계속해서 작성되어지는 유사한 코드(Hot Spot)가 발견된다면 이걸 어떻게 해결해야 할까요?

변하는 것과 변하지 않는 코드를 구분해서 변하는 코드들을 객체 형태로 캡슐화해야 합니다.

그리고 캡슐화한 변하는 부분을 한곳으로 취합함으로써, 좀더 쉽게 관리를 할수 있습니다.

이 논문에서는 변하는 부분들을 아래와 같은 디자인 패턴들을 적용하여 캡슐화하라고 권하고 있습니다.

Pluaggable Object

Component Library에 Component를 추가할때, 작성하는 SubClass(Concrete Class)들 대부분이 아주 조금씩 다르게 작성된다면 어떻게 해야 할까요?

Refactoring에서나 Composite Message Pattern에서 언급하듯이Parameter Object로 만들어야 합니다.

저같은 경우는 메세지의 변화가 전체 객체의 일부 Filed을 뽑아서 사용하는 경우라면 Enumeration(예를 들어 사람인 경우 사람.거주정보 , 사람.회사원정보)을 이용하고,

다양한 메세지 포멧을 지원하는 것이라면 파라메터들을 Protocol화여 종종 사용합니다.

Fine-Grained Object

Component Library를 좀더 재사용 가능하게 Refactoring하고 싶다면, 어떻게 해야 할까요?

Ralph Johnson 현재 BPMS와 같이 도메인 전문가가 자동으로 Composition해서 하나의 Application을 생성하는데 목적이 있습니다.

그래서 될수록 객체를 잘게 쪼개는 것을 권하고 있습니다. 여러개의 Behavior를 캡슐화한 클래스를 Component Library에서 찾은 후 각각의 Behavior를 캡슐화할 수 있는 개별적인 여러개의 클래스를 생성해야 합니다.

그후 여러개의 클래스를 조합해서 요구하는 Behavior를 생성할 수 있게 만들어야 합니다.

BlackBox Framework

Whitebox(Inheritance - 상속)로 Framework를 계층화하여 일원화된 흐름을 제공한 다음,

Blackbox(Composition-조합)을 통해 런타임시에 Application을 구성할수 있는 유연성과 코드의 중복을 감소하자는 것이 Blackbox의 핵심입니다.

Whitebox를 통해 만들어진 상속 관계로 구성된 여러 클래스에서 공적으로 사용되는 코드(변하지 않는 부분)들을 추출하여 이 부분을 Component(Blackbox)화 하여 사용하십시오.

그외의 Topic들 (Visual Builder와 Language Tools)은 AOM(Adaptive Object Model)을 통해 유연한 Application들 만드는 것(마치 BPMS로 하나의 Application을 구축하는 것)을 다루고 있으므로 생략하도록 하겠습니다.

이것으로 간단히 논문 내용의 정리를 마치고, 좀더 자세한 내용을 원하시는 분은 Evolving Frameworks 논문과 제가 올린 Mindmap을 보시길 권해드립니다. 클릭하시면 풀이미지를 얻으실 수 있습니다.

FreeMind File : evolving_framework.mm

Framework Engieering

Mon, 30 Jun 2008 23:13:13 +0900

Framework Design Guideline의 저자인 Krzysztof Cwalina의 TechED 2007 Framework Engineering 온라인 세션을 듣고 토론회를 가졌습니다.

편역을 하기전에 Framework 에 관해 배경지식을 쌓고, Paper Meeting 행사를 위한 가이드라인을 만들고 공유하기 위한 목적도 있었습니다.

Krzysztof Cwalina는 실제 .NET Framework를 설계한 분으로, 그의 경험을 책을 통해서 공유했을 뿐만 아니라, FxCop 이라는 툴을 이용해 VS.NET 내부 개발자들의 코드 품질을 검증하는 시스템을 외부로 공개하고 알린 분이기도 합니다.

Framework Engineering은 TechED2007 Europe 에서 발표한 세션으로 원래 일반인에게는 비공개이나, 고맙게도 자신의 블로그를 통해 공유해 주시고 계십니다.

관심있는 분은 다운받으시길 권해드립니다. 물론 영어로 된 강좌이나 대학원 후배들이 열심히 자막을 만들었고, 조만간 배포가 될 것 같습니다.

자막이 완성되면, 추후 포스팅으로 후배님들의 소개와 같이 알려드리도록 하겠습니다. 역시 믿음직스러운 후배를 둔 것 같습니다. :)

그럼 Framework Engineering 내용을 간략히 요약하도록 하겠습니다.

Organization

조직의 특성을 파악해라.
Conway's Law
Cost,Time은 한정적인 자원 => Process를 개선의 중요성

Planning

Architecture

의존성관리
Type간의 계층 (Taxonomy)
호환성 (Compatibility)
언제 API를 변경해야 할까?
중복과 중첩을 피해라.

Design

API를 설게하기 전에 해야할 것
KISS (Keep It Simple!! Stupid! 가능한 Feature를 심플하게 만들어라)
측정, 측정, 측정

Deployment

완성되지 않은 Feature들 통합하지 말것
빛을 지지 마라

세부적인 애기들은 제가 정리한 마인드 맵을 통해 공유하도록 하겠습니다.

Thumbnail (Depth - 3 단계인 간략 버젼)

PDF 풀 버젼 (Depth - 6단계)

이미지 풀 버젼 (Depth - 6단계)

Framework_Engineering.mm

Patterns for Successful Framework Development

Sat, 10 May 2008 21:20:12 +0900

Patterns for Successful Framework Development

Framework란 무엇인가? 그리고 왜 대두되어지고 기존의 라이브러리와의 차이점은 무엇인가?

Fraemwork에 대한 자세한 정보를 얻기 위해서는 GoF - Ralph Johnson 과 POSA2 - Douglas Schmidth 의 논문들을 찾아보길 권해드립니다.

Framework = Semi Auto Application (반쯤 자동화된 Application을 의미한다 )

그럼 Framework와 Library의 차이점은 무엇일가? -> Control Flow를 가지고 있으면 Framework이다.

일반 라이브러리들은 단순히 모듈인 반면에, Framework는 내부적인 흐름을 가지고 좀더 응용, 적용하기 쉬운 구조를 가진다.

대두되는 사항 - Component가 재사용의 단위로 실패했기 때문에 요즘 Framework가 재사용의 단위로 각광박고 있다.

요약및 토론 내용

프레임워크는 어플리케이션 개발자들로 하여금 코드와 디자인을 재사용할 수 있도록 돕는다.

하지만 프레임워크를 개발하는 일은 결코 쉽지 않은 일이다. 우선, 프레임워크는 여러 어플리케이션이 이용할 수 있는 높은 추상화를

제공해야 하기 때문에 지나치게 일반화되는 경향이 있다. 이는 프레임워크를 필요 이상으로 복잡하게 하여 이해하기 어렵게 만든다.

더군다나 어플리케이션과 프레임워크의 개발을 동시에 진행하는 경우엔 문제가 더 복잡해진다.

이 논문에서는 성공적인 프레임워크 개발을 위한 각 단계별 패턴을 절차적으로 기술하고 있다.

1. Concrete Evidence for Reuse

문제; 당신의 프로젝트에서 프레임워크가 필요하다는 것을 어떻게 확신할 수 있는가?
적용; 프레임워크 개발전 feasibility를 파악할 때

프레임워크를 개발하는데 드는 비용은 일반 어플리케이션을 개발시보다 보통 3배 이상이 들어간다. 따라서 반드시 최소 3개 이상의 어플리케이션에서
이 프레임워크를 이용한다는 보장이 있을때에만 개발에 착수하라.

관련 패턴; 만약 어플리케이션이 프레임워크를 이용할지 불분명하다면 PILOT APPLICATIONS(4) 패턴을 적용하여 당위성을 파악할 수 있다.

참고; Don Roberts and Ralph Johnson의 논문에 THREE EXAMPLES에 대한 언급이 있다 - evolving.pdf

2. The Beauty of Simplicity

문제; 어떻게 프레임워크를 관리 가능한 규모로 유지할 것인가?
적용; 프레임워크의 설계전 규모와 기능의 범위를 결정할 때
어플리케이션 개발팀의 다양한 요구 사항을 수렴하다보면 프레임워크의 복잡성도 그만큼 증대된다. 이런 복잡한 프레임워크는 만들기도 어려울 뿐더러
이해하고 사용하기도 쉽지 않다. 또한 개발 기간도 그만큼 길어지게 되어 프로젝트의 실패로 이어질 가능성이 커지게 된다.
세상의 모든 문제를 해결할 수 있는 프레임워크는 존재할 수 없다. 높은 추상화를 통해 제네릭한 알고리즘과 데이터 스트럭처를 제공하는 프레임워크는
그만큼 효율성의 손해를 가져온다. 따라서 적은 수의 핵심 기능에만 촛점을 맞추는 프레임워크를 설계하라.
관련 패턴; Skilled Team(3)은 단순한 프레임워크를 설계하는데 있어 꼭 필요한 요소다.
프로젝트가 진행되는 중에도 요구사항은 계속 변경될 수 있다. 이에 대해선 Multiple Change Requests(8)를 참조하라.
참고; Wolfgang Pree, et al. 은 매우 작고 느슨하게 연결되어 어플리케이션의 부분 아키텍처를 제공하는 프레임워크를 Framelets 라 정의하고 있다. - a6-pree.pdf

3. Skilled Team

문제; 어떻게 프레임워크를 명확하고 일관된 방식으로 설계할 것인가?
적용; 프레임워크의 설계와 개발과 관련하여
프레임워크 개발은 대단히 숙련된 기술을 필요로 하는 작업이다. 프레임워크 개발 경험이 없거나 최소한 해당 어플리케이션 도메인에 대한
지식이 없는 팀은 대부분 실패할 수 밖에 없다. 따라서 반드시 프레임워크 개발에 숙련된 인원들로 팀을 조직하고, 이들중 최소 몇몇은 해당 어플리케이션
도메인에 대한 경험 또한 갖고 있는 것이 좋다. 또한 이들은 프레임워크 사용자와의 적절한 피드백을 위해 반드시 커뮤니케이션 기술을 갖추어야 한다.

관련 패턴; 숙련된 팀일수록 The Beauty of Simplicity(2) 를 달성할 가능성이 높아진다.

4. Pilot Applications

문제; 어떻게 프레임워크에 대한 구체적인 요구 사항을 파악할 것인가?
적용; 프레임워크를 개발하기로 결정하고, 제공 기능을 정의할 때
프레임워크를 개발하기 위해서는 어플리케이션이 어떤 기능을 필요로 하는지 파악해야 한다. 그러나 어플리케이션 개발자는 자신들이 이용할 수
있는 프레임워크를 기다리고 있는 상황이다. 프로젝트를 진행하다보면 소위 이런 "계란과 달걀" 문제에 빠지기 쉽다. 이를 해결하기 위해
프레임워크를 이용할 파일럿 어플리케이션들을 미리 작성해 본 후 프레임워크가 제공해야 할 기능들을 파악하도록 한다. 이 때, 파일럿 어플리케이션의
수는 단순함을 위해 2개 정도가 적당하다.
관련 패턴; 파일럿 유저들과 협력하는 것은 Framework User Involvement(7)의 일종이다.
파일럿 어플리케이션들은 요구 사항을 파악할 때 뿐 아니라 테스트를 위해서 활용될 수 있다. Pilot-Based-Tests(6)
참고; Customer와의 interaction을 강조하는 논문으로 Linda Rising의 "Customer Interaction Patterns"가 있다. - CustomerInteraction.pdf

5. Small Objects

문제; 어떻게 하면 프레임워크의 복잡성을 낮게 유지하면서 유연성을 높일것인가?
적용; 프레임워크의 범위과 기능이 명확히 정의된 후, 전체 기능을 세부 조각들로 나눌 때
프레임워크의 전체 기능을 분할할 때는 강력하고 광범위한 기능을 가지는 적은 수의 큰 오브젝트로 나누는 것보다, 덜 강력하지만 유연한 많은 수의
작은 오브젝트로 나누어라. 이럴 경우 비록 오브젝트의 수는 많아지지만 개개의 오브젝트들을 이해하는 것이 쉬워진다. 또한, 작은 오브젝트들은 여러
상황에서 보다 다양한 방식으로 조합될 수 있다.
관련 패턴; 오브젝트들을 작은 크기로 유지하는 일 또한 The Beauty of Simplicity(2)를 돕는다.
참고; Concrete Evidence for Reuse에 언급된 논문(Ralph Johnson, et al.)에 Fine-Grained Objects에 관한 내용이 나온다.

6. Pilot-Based Tests

문제; 어떻게 프레임워크를 충분하고 신뢰성있게 테스트 할 수 있는가?
적용; 프레임워크 코딩 중, 테스트를 할 때
테스트는 QA에서 매우 중요한 요소이다. 하지만 프레임워크를 테스트 하는 일은 쉽지 않은 일이다. 프레임워크 자체는 단순히 추상적인
아키텍처일 뿐이지, 실행될 수 있는 무언가가 아니기 때문이다. 따라서 프레임워크를 사용하면서 기능들을 테스트해 볼 수 있는 샘플 어플리케이션이 필요하다.
이 때 사용될 수 있는게 파일럿 어플리케이션이다. 프레임워크의 다양한 기능들을 사용하는 파일럿 어플리케이션에 기반한 테스트를 수행하라.
관련 패턴; Pilot Applications(4) 패턴을 통해 도움을 받을 수 있다.
프레임워크 개발자는 사용자들에게 다양한 테스트 시나리오를 받을 수 있다. Framework User Involvement(7)

7. Framework User Involvement

문제; 어떻게 하면 유저들로 하여금 프레임워크를 이용하도록 만들 것인가?
적용; 프레임워크의 첫번째 버전을 완성하고 난 후
프레임워크를 쉽게 이용하도록 만들기 위해서는 사용자들에게 프레임워크의 실질적인 필요성을 각인시킬 필요가 있다. 이를 위해 사용자들을
지속적으로 참여시키는 방법이 필요하다. 이런 방법으로는 모두가 함께 참여하는 워크샵이 될 수도 있고, 프레임워크 사용을 돕는 툴을 제공하는
것도 생각할 수 있다. 하지만 이런 행위들이 비용과 시간을 상승시킨다는 점을 감안해서 적절히 조절할 필요가 있다.
관련 패턴; Pilot Applications(4)이 사용자들로부터 얻는 과정이라면, 이 패턴은 사용자들에게 전달하는데 촛점을 맞춘 과정이다.

8. Multiple Change Requests

문제; 요구사항의 변경으로 인해 프레임워크가 복잡해지는 것을 막을수 있는 방법은 무엇인가?
적용; 어플리케이션들이 프레임워크를 이용하던 중, 추가적인 기능을 요구할 때
개별적인 어플리케이션 요구사항들을 프레임워크에 모두 수용하다보면 프레임워크는 급격히 높은 복잡성을 갖게 된다. 따라서 몇몇 팀에서 사용할
추가 기능만 프레임워크에 포함시키도록 하라. 여기서 몇몇의 정의는 프레임워크를 이용하는 전체 팀의 수에 의해 결정된다. 만약 프레임워크를 4개의
팀이 이용하는 경우라면, 2개팀 정도가 적당하다.
많은 경우, 어플리케이션이 필요로 하는 추가적인 기능은 프레임워크에서 처리하는 것보다 직접 처리하는 것이 효율적이다.
관련 패턴; Concrete Eveidence for Reuse(1)와 마찬가지로 추가적인 기능 요구사항도 그것을 다른 어플리케이션이 재사용한다는 보장이 있을때만 추가하라

결론적으로, 성공적인 모든 프레임워크는 다음과 같은 특징들을 갖는다는 것을 알 수 있다.

핵심적인 작업들에만 촛점을 맞춘다.
재사용이 쉬운 영역을 다룬다.
사용하기가 쉽다.
프레임워크 개발자와 이용자들간에 긴밀하고 강력한 협력이 이루어진다.