프레임워크 엔지니어링

PP/Framework
posted by 방랑군 2012. 1. 4. 13:34
본 내용은 월간 마소 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/ ··· gment%2F
  • 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)

  • 메인시나리오 작성 ==> 시나리오에 부합되는 코드샘플 작성 ==> 개발자들에게 피드백하여 정제 ==> 객체 모델 정의
  • 프레임워크 디자인 스튜디오
    • 소개 : http://arload.wordpress.com/2008/10/11/introduceframework-design-studio/
    • Home : http://code.msdn.microsoft.com/fds
    • 사용법 : Add Assembly 사용하여 dll 또는 exe 추가 ==> Add Comment를 사용하여 사용자로부터 의견받음 ==> 수정 ==> Select Assembles to Compare를 사용하여 이전 버전과 비교 (빨:제거, 녹:추가, 회:상속)

  • 현실적인 프레임워크 구축하기
    • 모든 요구사항을 수용할 수 없다. 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) : 확장하는 위치 및 내부동작
  • 그밖에 : 문서에 소스코드를 제공하라. 에러발생시의 가이드라인 제시해라. 목차.

사용자 삽입 이미지


좋은 프레임워크란..

  • 쉽게 배워야
  • 문서 없이도 쉽게 사용해야
  • 실수하지 않도록 직관적이여야 (실패하기 힘들도록..)
  • 프레임워크 사용하면 코드가 읽기 쉬워야 (유지보수성도 좋아짐)
  • 확장이 쉬워야
  • 사용자를 고려해야..
저작자표시

'PP > Framework' 카테고리의 다른 글

프레임워크 구축과 발전  (0) 2012.01.04
애플리케이션과 프레임워크 동시 개발  (0) 2012.01.04
C#용 Open Source 조사  (0) 2012.01.04
프레임워크 개발 정리  (0) 2012.01.04
Spring.NET 프레임워크 활용 가이드  (0) 2012.01.04

티스토리툴바