프레임워크 엔지니어링

본 내용은 월간 마소 2009년 02/03월호에 실린 내용을 정리한 것입니다.
불펌을 금지하며, 문제시 삭제하겠습니다.
원문 출처는 아래와 같습니다.

더글라스 슈미츠 (POSA2 저자)의 프레임워크 정의

  • 프레임워크는 도메인 기반의 지식으로 구성된 객체 구조와 기능을 가지고 있는 “반쯤 완성된 애플리케이션“이다.

고려할 6가지 사항

  • 조직 (가장 강력한 설계 툴)
  • 계획 (프레임워크를 올바르게 구축하기 위한 계획)
  • 아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들)
  • 설계 (품질을 보장하기 위해 고려할 사항들)
  • 개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들)
  • 그 외에 고려해야 되는 것들 (가독성, 문서화)

조직

  • 콘웨이의 법칙
    • 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 4단계의 컴파일러를 얻을것이다.
    • 팀 구조 ==> 소프트웨어 구조
    • 따라서 팀 구성전에 도메인 전문가 or 구성원 전체가 모여 프로세스 정제후에, 프로세스에 맞춰서 팀을 구성
  • 조직 구조에 따른 설계방법
    • 프레임워크 개발팀은 작고, 사용팀은 많다면 ==> 모든 요구사항 수렴 불가 ==> 80/20룰에 의거, 많이 쓰는 부분에 집중
    • 프레임워크 개발팀이 크다면 ==> 요구사항을 많이 들어줌 ==> 모듈간의 일관성 유지에 초점 ==> 프로토타입을 많이 만들고 피드백 받아야
  • 조직의 문화를 고려
  • 고객 중심의 회사 : End-2-End 시나리오 추출후, 시나리오 잘 지원하는 프레임워크 설계해야
  • 기술 중심의 회사 : 기술 변화를 쉽게 수용하도록 프레임워크 설계해야
  • 조직의 의사결정 매커니즘 고려
  • 개별적 맨 파워 중시하는 회사 : 빠른 의사 결정을 지원하도록 설계
  • 계층적인 조직구조의 회사 : 이질적인 의사 표현방법을 통합하고 상호 운용하는데 초점

계획

  • 땅콩버터
    • Bottom-Up
    • Feature들이 중심되어 S/W 만듬. 땅콩버터처럼 Feature들이 점진적으로 골고루 퍼지고 진화함
    • 새로운 소프트웨어 만들때, 하위 레벨의 프레임워크 만들때, 저수준의 라이브러리 개발시
    • 단점 : 고객요구 많고, 시나리오가 자주 새로워지면.. Feature별로 구성된 조직간 협업을 해야하고.. 시끄러워짐..
  • 마천루
    • 시나리오가 마천루처럼 높게 솟아 SW 기능 구현의 기준이 됨. 기준이 있다는 건 좋은거임..
    • Top-Down
    • 다양한 고객이 사용하는 상위레벨 애플리케이션 개발시
    • 단점 : 시나리오 기준이라 일괄적인 구조로 설계가 힘듬. 시나리오 수정시 속수무책.
  • 마일스톤 = 땅콩버터 + 마천루
    • 인프라 구축 초기에는 땅콩버터, 인프라 구축된 후 땅콩버터 유지하되 점진적으로 마천루 혼합
    • MS의 예 : 10개의 기능이 필요하면 2개 구현 –> 배포후 피드백 받음 –> 기존2개 수정, 새로운 2개 추가…..

아키텍처

  • 프레임워크 구축하여 여러팀이 사용중에.. 아키텍쳐를 변경하는것은 매우 힘듬. 첨부터 잘 만들어야 함.
  • 타입들
    • Primitive : 기본 데이타 타입 (Int32, String…), 모든 데이타의 가장 하단부에 위치하므로 변경에 따른 영향이 큼
    • Library (Component) : 풍부한 행위와 정책을 가진 타입(EventLog, Debug…). 쉽게 확장 가능. Component 구축시 매개변수로 Library를 받지 마라 의존성 생긴다.
    • Abstraction (Interface) : 추상클래스로 프레임워크의 확장성과 유연성을 제공. 프레임워크가 반완성이라는 말은 Template Method 패턴과 같은 Abstraction을 많이 사용한다는 얘기.
  • 의존성 종류
    • API Depenency (Surface Depenency) : 컴포넌트 A와 B간에 파라미터나 리턴값 등으로 사용시 의존성
    • Implementation Depenency : 내부적으로 다른 컴포넌트 사용시. 다른 컴포넌트가 없으면 돌지도 않음.
    • Circular Depenency : A가 B를 의존하고, B가 A를 의존. 가장 나쁜 경우임.
  • 의존성과 악연

    • 컴포넌트는 재사용의 단위보다는 “같이 배포되고 같이 진화하는 타입들의 집합의 단위”.
    • 닷넷&자바 : 초기에 배포한 프레임워크에 라이브러리 기능 추가하지 않고, 베이스 클래스 라이브러리로 명명, 추후 별도의 라이브러리 추가
    • 의존성을 줄이려면 “계층화” 사용할것 ==> 연관된 컴포넌트는 하나의 레이어로 묶음 ==> 다른 레이어의 변화의 충격 완화됨
    • 참고 – Dependency를 관리하는 방법 : http://arload.wordpress.com/2008/12/07/dependency_managment/
  • Circular Depenency는 꼭 피하자
    • 상위레이어에서 하위레이어를 호출할 수는 있어도..
    • 하위 레이어가 상위레이어를 호출하면 안됨!!!! ==> 직/간접적으로 Circular Depenency 만들어진다.
    • ex) GUI –> 통신모듈 –> 오류시 try catch 문에서 MessageBox 표시 –> GUI 의존성..
    • 위의 경우 MessageBox로 보내지 말고.. Message Manager를 구성해서 의존성을 끊어라. 또는 Listener를 사용하여 IoC 구성하라
  • Dependency 깨는 IoC
  • Dependency 확인 도구 xDepend

    • JDepend의 닷넷버전. 상용 (초기버전은 무료)
    • 종속성을 그래프/다이어그램으로 보여줌. Circular Dependency 찾는 기능
    • CQL(Code Query Language)
    • http://www.ndepend.com
  • 추가사항 : Visual Studio 2010의 의존성 다이어그램
  • 호환성 (Compatibility)
    • .net 3.0에서 .net 2.0으로 구현한 애플리케이션 안돌아가면 큰 문제. 기존2.0은 BCL(Base Class
      Library)라고 하고, WPF/WCF/WF 등을 추가함.
    • 정책적 or 급변하는 IT환경에 따라 호환성을 버릴 수도 있다. 이때는 마이그레이션 패스를 제공하라.
    • 버전간 호환성 (Cross-Version ~) : 동일한 제품의 다른버전에서 만든 코드의 호환성
    • 하위 호환성 (Backward
      ~) & 상위 호환성 (Forward ~) : 보통 하위호환성을 지원함..
    • 타제품간 호환성 (Cross-Redist ~) :
      오라클 쿼리문을 MSSQL에서..
    • 바이너리 호환성 (Binary ~) : 예전 버전으로 만든 바이너리가 새버전에서도 컴파일 없이 잘
      작동..
    • 소스 호환성 (Source ~) : 서로다른 버전이지만 소스코드 그대로 사용
    • API 호환성 : 서로다른 버전의
      API간 호환성.

설계 (Design)

  • 현실적인 프레임워크 구축하기
    • 모든 요구사항을 수용할 수 없다. ex) 빠른전송과 높은보안수준을 함께하기 구현하기 힘듬
    • 사용자 피드백을 취합해 가장 많이 요구하는 기능들을 우선순위로 정할것
    • Three Example Application을 구축/리팩토링하면서 안정화된 프레임워크 만들것.
  • 품질을 측정
    • 품질기준 사이의 균형 조절이 필요 (ex: 빠른전송 vs 높은보안)
    • ATAM : Architecture Tradeoff Analysis Method
    • 사용자들 모아놓고 품질속성(기능성, 신뢰성, 사용성…) 등에 대한 투표를 진행하라
  • 동일함의 힘

사용자 삽입 이미지

    • StyleCop
사용자 삽입 이미지

 

개발 (Development)

  • Feature 전담팀을 구성
    • 하나의 시스템 ==> 여러개의 Product Unit으로 나눔 ==> 각 PU에서 여러개의 기능(Feature)을 나눔\
    • 각 Feature가 완성시 기능/테스트까지 검증된 모듈을 얻음.
  • Quality Gate 구성 : Feature별 구현 완료의 기준이 필요함
    • 기능 스펙(Functional Specification)
    • 개발자 설계 스펙(Developer Design Specification)
    • 테스트 계획 (Test Plan))
    • 위협 모델 (Threat Model)
    • API Review
    • 아키텍쳐 리뷰 (Architectural Review)
    • 의존성 관리 (Dependency Management)
    • 정적 분석 (Static Analysis)
    • 코드 커버리지 (Code Coverage)
    • Testing (Unit and Integration Tests)
    • 0개의 Bug
    • 성능 (Performance)
  • 그외 고려사항
    • 네이밍룰
      • 파스칼 표기법 : PascalCasing – 첨에 대문자
      • 카멜 표기법 : camelCasing – 첨에 소문자
      • Uderscore 표기법 : SCREAMING_CAPS – 중간에 밑줄
      • 헝가리안 표기법 : sHungarian – 변수의 특성을 앞에
    • 약어 자제 : JLT(뭔 소리냐?), HTML(이건 다 아는거니까 봐줌)
    • 직관적 단어 : Count(일반적으로는 이거), NumberOfElement (XML에서는 이게 좋을것이다)
    • 상식에 맞게 : IFoo 는 당연히 인터페이스라고 누구나 생각한다.

프레임워크 매뉴얼 구축

  • 문서 로드맵(Documentation Roadmap) : 문서의 전체 구성 설명
  • 프레임워크 전체개요(Framework Overview) : 개요 및 도메인을 설명, 기능의 범위
  • 실례과 조리법들 (Cookbook & Recipes) : 특정 문제를 프레임워크로 해결하는 방안
  • 단계적인 예제들(Graded Example) : 어플리케이션 구축 방법 설명
  • 확장 포인트(Customizable Points) : 확장하는 위치 및 내부동작
  • 그밖에 : 문서에 소스코드를 제공하라. 에러발생시의 가이드라인 제시해라. 목차.

사용자 삽입 이미지

좋은 프레임워크란..

  • 쉽게 배워야
  • 문서 없이도 쉽게 사용해야
  • 실수하지 않도록 직관적이여야 (실패하기 힘들도록..)
  • 프레임워크 사용하면 코드가 읽기 쉬워야 (유지보수성도 좋아짐)
  • 확장이 쉬워야
  • 사용자를 고려해야..
요즘은 순규가 눈이 밟히는군하..
사용자 삽입 이미지

Notice

  • 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스
  • 저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.
  • 댓글에 대한 답변은 늦을 수도 있습니다.
  • 4 댓글

    1. arload 응답

      안녕하세요 손영수입니다.

      출처만 확실히 밝혀 주신다면, 전혀 문제가 없습니다. 저역시 .NET Framework 를 설게한 Brad Abrams와 Kryzstztof Cwalina 의 지식의 저의 조그만 지식을 보탠것 뿐입니다.

      kimstat님계서 더 풍성하게 만들어주시고, 나누어 주시길 부탁드리며, 다음에 기회가 되면 또 연락드리죠. 관심가져 주시고 나중에 베타리더를 뽑을때 지원 부탁드리겠습니다.

      감사합니다. 꾸벅!!

      • kimstar 응답

        좋은 글을 허락해 주셔서 감사드립니다.
        번역하고 계시는 책에도 관심이 많습니다.
        미천하여 도움이 될지는 모르겠지만 기회가 된다면 베타리더로 참여할 수 있다면 좋겠네요.. ^^

      • kimstar 응답

        프로프레임을 써본적이 없는데..
        뭔가 맺힌게 있으신가 보군요..
        근래의 티맥스 사건을 보면 씁쓸하긴 하더군요..

    댓글 남기기

    이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다