소프트웨어 아키텍처 문서화 1,2장

  현재 아꿈사(http://cafe.naver.com/architect1) 소프트웨어 아키텍처 문서화(DSA) 라는 책을 스터디 하고 있습니다. 이 책 흐흐흐, 아직 잘 이해가 안가네요.

 

 1,2장 내용을 살포시 정리해 보면 -_-, 양이 많아서 핵심만,

 

  1. 소프트웨어 아키텍처

    1. 큰 문제를 작은 부분으로 나눠서 해결( Divide & Conquer )
    2. 위에서 Divide & Conquer 한 문제를 재구성 <– 이 부분이 특히 중요

      1. 이렇게 해결하고 다시 재구성 하므로, 전체적으로 이해하기 쉽고 영역별로 나눌 수 있다.
    3. 아키텍처

      1. 위에서 나뉜 조각들이 서로 조화를 이뤄서 하나의 시스템으로 성공적으로 동작하게 만드는 존재
  2. 아키텍처 문서화

    1. 결국 1번의 내용을 각각의 이해관계자들이 이해하고 수행할 수 있도록 알려주는 작업

      1. 이해관계자란?

        1. 해당 아키텍처에 직, 간접적으로 연관되는 사람들

          1. 아키텍트 및 모듈 설계자
          2. 실제 구현 개발자
          3. 테스트 담당자 통합 담당자(부분별로 나뉜걸 통합해서 하나로 만드는 사람)
          4. 유지보수인력
          5. 연동 시스템의 설계자
          6. 관리자
          7. 프로덕트 라인 관리자
          8. 품질보증팀(QA)
          9. 이것 뿐만이 아니라 고객, 경영진 등도 전부 이해관계자가 될 수 있다.
    2. 아키텍처 마다 지켜야 할 품질 속성이나  설계 목표가 있다.

      1. 성능, 신뢰성, 보안, 변경 용이성

        1. 위의 특징을 가질려면 어떻게 시스템을 구성하고 개발해야 하는가를 문서화에서 충분히 설명해야 한다.
    3. 아키텍처 문서의 용도

      1. 교육용
      2. 이해관계자들 사이의 기본적인 의사소통 도구
      3. 시스템 분석의 대상
    1.  아키텍처 문서화란 아키텍처 관련 뷰들을 하나씩 문서로 작성한 다음, 여러 뷰와 관련된 아키텍처적 내용을 문서로 만들어 추가하는 작업이다.
    2. 뷰가 필요한 이유

      1. 위의 아키텍처의 용도나, 가져야 하는 특성들을 하나의 관점으로 서술 할 수 있을까?

        1. 못한다.
        2. 그래서 뷰는 여러 개가 나와야 한다.

          1. 품질 속성을 지키기 위한 측면에서 바라보는 뷰
          2. 용도(교육용,분석대상, 의사소통 대상) 에 맞게 바라보는 뷰
          3. 각각의 이해관계자들에게 보여주기 위한 뷰
    3. 즉 뷰는 각각의 측면에서 아키텍처를 바라보는 모양이라고 할 수 있다.
  3. 뷰타입과 스타일

    1. 아키텍트가 소프트웨어 아키텍처에 대해 고려할 점

      1. 구현 단위들이 어떤 식으로 구조화됐는가?
      2. 실행시간 행위나 상호작용을 하는 요소들이 어떤 식으로 구조화됐는가?
      3. 주변 환경에 존재하는 비소프트웨어 구조와는 어떤 식으로 연결돼있는가?
    2. 세 가지 뷰타입 <– 위의 질문들에 따른 뷰타입

      1. 모듈 뷰타입

        1. 기본적인 시스템 구현 단위를 문서화
      2. 컴포넌트와 커넥터 뷰타입

        1. 시스템의 실행 단위를 문서화
      3. 할당 뷰타입

        1. 시스템의 소프트웨어와 그것을 둘러싼 개발 및 실행 환경 사이의 관계를 문서화
    3. 스타일

      1. 각각의 뷰타입 중에서 일반적으로 자주 나타나고 사용되는 형태

        1. 즉, 이것 역시 패턴이다.(디자인 패턴을 기억하자)
  4. 모듈 뷰타입

    1. 모듈

      1. 책임을 구현하는 코드 단위
    2. 모듈 뷰타입 스타일

      1. 분할 스타일

        1. 시스템을 하향식 관점에서 쳐다보는 형태
        2. 커다란 디렉토리 형태로 중복되지 않게 모듈들이 구성되어있다고 생각하자
      2. 사용 스타일

        1. Uses 관계, 특히 depends-on 관계에 특화된 형태

          1. 모듈 A가 모듈 B를 사용한다면, 이것은 모듈 A 가 모듈 B에 Depend 한다고 볼 수 있다.
          2. 실제로, 어떤 모듈이 다른 모듈을 무엇을 사용하는 지 표현한다.
          3. 서큘러(순환, A->B->C->A 형태로 연결되는 것)가 있으면 안좋다. -_-

            1. 당연하지!!!
          4. 실제로 물리적으로 호출은 하지만, A->B로 함수 콜등을 하지만, B의 결과가 A에 영향을 미치지 않는다면, A는 B에 의존하지 않는다.
          5. 실제로 물리적인 호출은 없지만, B가 만든 전역데이터를 A가 사용해야 한다면 A는 B에 의존한다.
      3. 일반화 스타일

        1. 코드 들이 실제로 어떻게 관계를 맺고 있는지 보여준다.(클래스 상속 구조등)
      4. 계층 스타일

 

 소프트웨어 아키텍처 문서화를 보면서, 실제로 문서화의 기본은 좋은 아키텍처를 만드는 것이라고 할 수 있다. 하지만, 좋은 아키텍처가 좋은 문서화를 보장해 주지는 않는다. 모두의 생각이 동일할 수 는 없기 때문이다. 살아있는 문서를 만드는 것… 그것이 핵심이다.