소프트웨어 아키텍처 문서화, 뷰 패킷, 정제, 설명적 완결성

  1. 뷰 패킷

    1. 대규모 소프트웨어 시스템에서 사용되는 뷰에는 수백, 수천 개의 요소가 들어간다. 이런 요소와 요소들의 관계를 하나의 문서에 다 포함할 수 없으므로, 이해관계자가 이해할 수 있는 부분들로 나눠서 조각을 나누어서 표현하는 것을 “뷰패킷” 이라고 한다.
    2. 같은 뷰에 속한 뷰 패킷

      1. 형제 뷰 패킷

        1. 동등한 레벨에서의 뷰 패킷, 사람의 , 머리, 가슴, 배 처럼 부분들로 나뉘어진 뷰 패킷
      2. 자식-부모 뷰 패킷

        1. 해당 뷰패킷의 내용을 더 상세화하면 자식 패킷
        2. 좀 더 추상적으로 보여주면 부모 패킷
    3. 다른 뷰에 속한 뷰 패킷

      1. 뷰들이 서로 겹치는 영역에 속한 뷰패킷
  2. 정제

    1. 분할 정제

      1. 실제 뷰 패킷을 기능 별로 자세히 설명하는 것

        1.  A는

          1. A1,A2,A3,A4로 나눠이지고 각각에 대해서 설명하면 분할정제
    2. 구현 정제

      1. 뷰 패킷의 기능을 구현에 가깝게 명확히 적시해 두는 것

        1. 구독, 발행 스타일에서 데이터 전송을 커넥터로 표현

          1. 구현정제 뷰 패킷에서는

            1. 커넥터는 토폴로지로 구현한다.

              1. 모든 구독자들이 서로 연결되어 있다.
            2. 커넥터는 분배기로 구현한다.

              1. 나의 분배 서버에서 각 해당 구독자들에게 알려준다.
              2.  즉, 구체적인 기술 구현 방법이 들어간다.
  3. 설명적 완결성

    1. 정제와 관련
    2. 적용은 선택적, 단 적용시에는 명확하게 표현해야함
    3. 뷰 패킷에 들어있는 요소들이 어떤식으로 연결되어 있는지 표현

      1. A->B, B<–>C 일 때

        1. A와 C는 관계가 있을 수도 있고 없을 수도 있다.
      2. 그러나 실제로 A<->C의 관계가 있을 수도 있으므로

        1. 추상적으로는 연결 안됨

          1. 모듈 뷰의 사용 개념(물리적으로 연결이지만, 논리적으로는 비 연결) 
        2. 실제로는 연결됨

 

소프트웨어 아키텍처 – 모듈 뷰 숙제하기

 

 물리적 구성(지누기꺼 복사)

1. 물리적 구성

 

시스템

             n개의 입구(Entrance)

             m개의 출구(Exit)

 

입구(Entrnace)

             1개의 문(gate)

             1개의 상태 디스플레이(State Display)

             1개의 티켓 머신(Ticket Machine)

                           1개의 요청 버튼(Request Button)

                           1개의 티켓 프린팅 유닛

                           1개의 카드 리더(Card Reader)

             1개의 induction loop

 

출구(Exit)

             1개의 문(gate)

             1개의 티켓 리더(카드 / Ticket 다 읽음)

             1개의 induction loop

 

모듈 분할 뷰

 

하드웨어 은닉모듈

장치 인터페이스 모듈

문 모듈

상태 디스플레이 모듈

버튼 모듈

프린팅 모듈

카드 리더 모듈

인덕션 루프 모듈

티켓 리더 모듈

 

행위 은닉 모듈

서비스 행위 모듈

함수 모듈

 

소프트웨어 결정 모듈

데이터 뱅커 모듈

티켓 유효성 검사 모듈

주차 공간 가능 체크 모듈

입장 제어 모듈

퇴장 제어 모듈

상태 변이 이벤트 모듈

 

 사용스타일 뷰

 범례 : UML

 

 

소프트웨어 아키텍처 5장 – 배포 스타일 뷰

배포 스타일 뷰

할당 스타일 뷰

 

 오늘 배운 것 중에 하나!!!

 단순히 배포 스타일 뷰는 소프트웨어 아키텍처에 들어가지 않는다.

 

 그리고 모듈 뷰를 그리면서 중요한 것.

 

  1. 모듈 사용 뷰

    1. 범례를 꼭 작성한다.

      1. 화살표등이 무슨 의미인지 설명하지 못하면 아무의미가 없다.
    2.  모듈 사용 뷰에서는 use 관계만이 나타나야 한다.

      1. 이것은 실제로 꼭 정해진 것은 아니라, 현재 책을 스터디 하므로, 이 부분을 따르는 것이 학습에 도움이 될것 같다라는 의미
      2. 결국 한번에 여러개를 표시할려고 하면, 힘들다는 것.
  2. 모듈 분할 뷰

    1.  분할의 기준을 설명하고, 개별 모듈별로 다음과 같은 내용을 밝히는 식으로 보강해야 한다.

      1. 모듈의 책임
      2. 부모 모듈 밖에서 보이는지를 나타내는 가시성
      3. 구현 정보 

컴포넌트와 커넥터 뷰타입 스타일(C&C)

 이번 주 스터디에서 C&C 뷰타입 스타일에 대해서 스터디를 했다. 문제는 이부분에 대해서 잘 모른다는 것!!!

그래도, 웬지 C&C 뷰타입 스타일은 패턴하고 비슷한 것들이 많아서 조금 이해하기 쉬웠다고 할까?

(이해했다라는 얘기가 아니다.)

 

 C&C  뷰타입 스타일에는 크게 다음 6가지가 있다.

  1. 파이프와  필터 스타일
  2. 공유 데이터 스타일(블랙보드 패턴)
  3. 발행 구독 스타일
  4. 클라이언트./서버 스타일
  5. 피어 투 피어 스타일
  6. 프로세스 간 통신 스타일

스터디 내용중에서 이해하기 힘들었던 부분들은

  • 공유 데이터 스타일(블랙보드 패턴)

    • 영구적인 데이터 저장소가 있다.
    • 데이터 저장소 부분을 빼면, 발행 구독 스타일과 비슷해 보인다.

      • 저장소에 쓴 데이터에 따라 구독을 원하는 Knowledge 가 있을 경우 알려줄 수 있기 때문에
  • 발행 구독 스타일

    • 어떻게 연결되어 있고 변화를 어떻게 알려주는가가 핵심
  • 클라이언트/서버 스타일

    • Request/Reply 가 비대칭적이다.

      • 즉 클라이언트에서 Request 를 하고 그 결과를 서버가 Reply 하는 형태이다.
      • 즉 A는 B를 알지만, B는 A를 모른다.
      • 결론, 레이어가 다르다는 것!!!
  • 피어 투 피어

    • Request/Reply 가 대칭적이다.

      • 즉 Peer A 가 Peer B는 서로 Request를 날릴 수 있다.
      • 같은 레이어다, 서로 상태를 안다.

소프트웨어 아키텍처 문서화 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. 계층 스타일

 

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