가이드라인: 소프트웨어 아키텍처 문서
이 가이드라인은 소프트웨어 아키텍처 문서의 컨텐츠 개요를 제공합니다.
관계
기본 설명

참조

참조 섹션은 시스템의 아키텍처 이해에 중요한 배경 정보를 제공하는 외부 문서를 표시합니다. 많은 수의 참조가 있는 경우 섹션의 구조를 하위 섹션으로 나누십시오.

  1. 외부 문서
  2. 내부 문서
  3. 관리 문서
  4. 비관리 문서
  5. 기타

아키텍처 목적 및 제한조건

아키텍처는 다음을 고려하여 형성됩니다.

  • 유스 케이스 모델에서 캡처한 기능적 요구사항
  • 보충 스펙에서 캡처한 비기능적 요구사항

그러나 이들이 아키텍처를 형성하는 유일한 영향은 아닙니다. 소프트웨어가 작동해야 하는 환경, 기존 자산을 재사용할 필요성, 다양한 표준의 부과, 기존 시스템과의 호환성 필요 등에 의해 부과되는 제한조건이 있습니다. 개발 과정을 안내하며, 해당 프로젝트에 대해 면밀히 검토하고 확인해야 하는 기존의 아키텍처 원리 및 정책 세트도 있을 수 있습니다. 소프트웨어 아키텍처 문서의 이 섹션에서는 이러한 목적 및 제한조건, 그리고 여기서 생성되며 다른 부분에 준비된 홈(요구사항)이 없는 아키텍처 결정을 설명합니다.  

이 문서가 작성될 때 중요한 입력은 구현 환경의 스펙입니다. 지정해야 할 사항의 예제로는 대상 플랫폼(하드웨어, 운영 체제), 윈도우 시스템, 개발 도구(언어, GUI 빌더), 데이터베이스 관리 시스템 및 컴포넌트 라이브러리가 있습니다. 허용되는 사용자 인터페이스 기술과 그렇지 않은 기술을 지정하는 것도 가치가 있습니다. 여러 시스템은 더 많은 클라이언트 시스템이 응용프로그램을 사용할 수 있고 응용프로그램을 개발하기 수월하도록 특정 프리젠테이션 기술(JavaScript, Applets, Frames, XML 등)을 사용하지 않기로 선택합니다.  결정은 소프트웨어 아키텍처 문서에서 이 위치에 캡처되며 선택한 기술의 사용 및 적용 방법에 대한 세부사항은  중간 산출물: 프로젝트 가이드라인에 문서화되어 있습니다.

결정의 시행은 반복 평가의 일부로 사용될 아키텍처 평가 기준 세트를 작성하여 이루어집니다.

평가 기준은 다음에 대한 가능성 있는 미래 변경사항을 문서화하는 변경 사례에서도 파생됩니다.

  • 시스템의 기능 및 특성
  • 시스템의 사용 방식
  • 시스템의 작동 및 지원 환경

변경 케이스는 "간편한 확장", "간편한 포트", "간편한 유지보수", "변경에 대한 유연성" 및 "신속한 개발"과 같은 주제 문구를 통해 설명된 시스템의 특성을 분명히 합니다. 변경 케이스는 단지 가능한 내용보다는 중요하고 가능성이 있는 내용에 초점을 맞춥니다.

변경 케이스는 변경을 예측하려고 하지만 이러한 예측이 정확한 사실로 드러나는 경우는 드뭅니다.

시스템의 특성은 사용자, 후원자, 공급자, 개발자 및 기타 이해 당사자에 의해 결정됩니다. 변경은 다음과 같은 여러 소스로부터 발생할 수 있습니다.

  • 비즈니스 구동 요소: 새로 작성 및 수정한 비즈니스 프로세스 및 목적
  • 기술 구동 요소: 시스템의 새 플랫폼 적응, 새 컴포넌트와의 통합
  • 평균 사용자의 프로파일 변경사항
  • 다른 시스템과의 통합 필요성의 변경사항
  • 외부 시스템으로부터의 기능 이주에서 발생하는 범위 변경사항

유스 케이스 보기

유스 케이스 보기는 시스템의 구조적으로 중요한 유스 케이스를 제시하는 중간 산출물: 유스 케이스 모델의 서브세트를 제공합니다. 이는 일부 중요 기능을 나타내는 유스 케이스 및/또는 시나리오 세트를 설명합니다. 실질적인 아키텍처 적용 범위가 있거나(여러 아키텍처 요소를 연습함), 아키텍처의 미묘한 특정 부분을 강조 또는 설명하는 유스 케이스 및/또는 시나리오 세트도 설명합니다.

모델이 더 큰 경우에는 일반적으로 패키지로 구성됩니다. 패키징한 경우 쉽게 이해할 수 있도록 유스 케이스 보기를 패키지별로 유사하게 구성해야 합니다. 중요한 유스 케이스에 각각에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

  1. 유스 케이스의 이름.
  2. 유스 케이스에 대한 간단한 설명.
  3. 유스 케이스의 이벤트 플로우에 대한 중요 설명. 이는 전체 이벤트 플로우 설명이거나 유스 케이스의 중요 플로우나 시나리오를 설명하는 하위 섹션일 수 있습니다.
  4. 포함 및 확장 관계나 커뮤니케이션 연관 관계와 같은 유스 케이스와 관련된 관계에 대한 중요 설명.
  5. 유스 케이스와 관련된 중요한 유스 케이스 다이어그램의 열거.
  6. 유스 케이스의 특별 요구사항에 대한 중요 설명. 이는 전체 특별 요구사항 설명이거나 중요 요구사항을 설명하는 하위 섹션일 수 있습니다.
  7. 유스 케이스를 명확히 하는 중요 사용자 인터페이스 그림.
  8. 이러한 유스 케이스는 논리 보기로 실현해야 합니다.

논리 보기

논리 보기는 구조적으로 중요한 디자인 요소를 제시하는 중간 산출물: 디자인 모델의 서브세트입니다. 이는 가장 중요한 클래스, 패키지와 서브시스템의 조직 및 이들 패키지와 서브시스템의 계층 조직을 설명합니다. 아키텍처의 동적 측면과 같이 가장 중요한 유스 케이스 실현도 설명합니다.

복잡한 시스템의 경우 논리 보기를 설명할 많은 섹션이 필요할 수 있습니다.

  1. 개요

    이 하위 섹션은 디자인 모델의 전반적인 분할을 패키지 계층 구조 및 계층의 측면에서 설명합니다. 시스템에 여러 패키지 레벨이 있으면 최상위 레벨에서 중요한 것들을 먼저 설명해야 합니다. 독립성과 계층 구조 뿐 아니라 중요한 최상위 레벨 패키지를 표시하는 다이어그램을 포함하십시오. 그런 다음 이들 내에서 중요한 패키지를 제시하는 식으로 계층 구조의 맨 아래까지 계속합니다.

  2. 구조적으로 중요 디자인 패키지

    각 중요 패키지에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

    1. 이름.
    2. 간단한 설명.
    3. 패키지 내에 포함된 모든 중요 클래스와 패키지가 있는 다이어그램. 보다 잘 이해하도록 하기 위해 이 다이어그램은 필요에 따라 다른 패키지의 일부 클래스를 표시할 수 있습니다.
    4. 패키지의 각 중요 클래스에 대해 이름, 간단한 설명 및 선택적으로 일부 주요 책임, 오퍼레이션 및 속성에 대한 설명을 포함하십시오. 포함된 다이어그램을 이해하려면 필요한 경우 중요 관계도 설명하십시오.
  3. 유스 케이스 실현

    이 섹션은 선택된 몇 가지 유스 케이스(또는 시나리오) 실현을 제공해서 소프트웨어가 작동하는 방식을 설명하고 다양한 디자인 모델 요소가 기능에 영향을 미치는 방법을 설명합니다. 여기에 제공된 실현은 최종 시스템의 일부 중요한 중심 기능을 나타내거나, 아키텍처 적용 범위(여러 아키텍처 요소를 연습함) 때문이거나, 아키텍처의 미묘한 특정 부분을 강조하거나 설명하기 때문에 선택된 것입니다. 실현의 해당 유스 케이스와 시나리오는 유스 케이스 보기에서 찾을 수 있습니다.

    각 중요한 유스 케이스 실현에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

    1. 실현된 유스 케이스의 이름.
    2. 실현된 유스 케이스에 대한 간단한 설명.
    3. 유스 케이스 실현의 이벤트 플로우 - 디자인에 대한 중요 설명. 이는 전체 이벤트 플로우 - 디자인 설명이거나 유스 케이스의 중요 플로우나 시나리오의 실현을 설명하는 하위 섹션일 수 있습니다.
    4. 유스 케이스 실현과 관련된 중요 상호작용 또는 클래스 다이어그램의 열거.
    5. 유스 케이스 실현의 파생된 요구사항에 대한 중요 설명. 이는 전체 파생된 요구사항 설명이거나 중요 요구사항을 설명하는 하위 섹션일 수 있습니다.

구조적으로 중요 디자인 요소

구조적으로 중요한 사항을 결정하는 데 도움을 주기 위해 한정 요소와 특성의 일부 예제가 제시됩니다.

  • 문제점 도메인의 핵심 추상을 캡슐화하는 모델 요소. 예를 들어 다음과 같습니다.
    • 항공 수송 제어 시스템의 비행 계획.
    • 급여 시스템의 직원.
    • 전화 시스템의 가입자.

이들의 하위 유형을 반드시 포함할 필요는 없습니다. 예를 들어, ICAO 표준 비행 계획US 국내 비행 계획과 구별하는 것은 중요하지 않습니다. 이 둘은 모두 비행 계획으로 속성과 오퍼레이션을 상당 부분 공유합니다.

데이터 회선 또는 전화선의 가입자를 구별하는 것도 통화 처리가 대개 동일한 방식으로 진행되는 한 문제가 되지 않습니다.

  • 여러 다른 모델 요소에 사용되는 모델 요소.
  • 시스템의 주요 메커니즘(서비스)을 캡슐화하는 모델 요소.
  • 디자인 메커니즘.
    • 지속성 메커니즘(저장소, 데이터베이스, 메모리 관리).
    • 통신 메커니즘(RPC, 브로드캐스트, 브로커 서비스).
    • 오류 처리 또는 복구 메커니즘.
    • 표시 메커니즘 및 기타 공통 인터페이스(윈도윙, 데이터 캡처, 신호 조정 등).
    • 매개변수화 메커니즘.

일반적으로 임의의 메커니즘이 여러 다른 패키지에 사용될 수 있으므로(완전히 패키지 내부적인 것과 반대됨) 시스템 전반에서 단일 공통 구현 또는 적어도 여러 대체 구현을 숨기는 단일 인터페이스를 이용하는 것이 좋습니다.

  • 시스템의 주요 인터페이스에 참여하는 모델 요소. 예를 들어 다음과 같습니다.
    • 운영 체제
    • 기존 제품(윈도윙 시스템, RDBMS, 지리 정보 시스템)
    • 아키텍처 패턴(예: 모델-보기-제어기 패턴을 포함한 모델 요소의 연계를 제거하는 패턴 또는 브로커 패턴)을 구현하거나 지원하는 클래스
  • 로컬로 볼 수 있지만 시스템의 전체 성능에 일부 큰 영향을 줄 수 있는 모델 요소. 예를 들어 다음과 같습니다.
    • 매우 높은 비율로 센서를 스캔하는 폴링 메커니즘
    • 문제점 해결 추적 메커니즘
    • 고가용성 시스템에 대한 체크포인트 메커니즘(체크포인트 및 다시 시작)
    • 시작 시퀀스
    • 코드의 온라인 갱신
    • 새롭고 기술적으로 위험한 알고리즘 또는 안전이나 보안상 중요한 일부 알고리즘을 캡슐화하는 클래스(예: 방사선 레벨 계산, 혼잡한 영공에서의 충돌 방지 기준, 암호 암호화).

구조적으로 중요한 것에 대한 기준은 프로젝트의 초기 반복에서 전개되는데, 이는 이 시기에 기술적 어려움을 발견하고 시스템을 더 잘 이해하기 시작하기 때문입니다. 그러나 대체로 모델 요소의 최대 10%에 구조적으로 중요하다는 표시를 해야 합니다. 그렇지 않으면 아키텍처의 개념이 희박해질 위험성이 있고 "모든 것이 아키텍처"가 될 수 있습니다.

구조적으로 중요한 모델 요소를 논리 보기에 정의하고 포함할 때에는 다음 측면도 고려해야 합니다.

  • 공통성 및 재사용에 대한 잠재성을 식별하십시오. 어느 클래스가 공통 클래스의 서브클래스이거나 매개변수화된 동일한 클래스의 인스턴스일 수 있습니까?
  • 매개변수화에 대한 잠재성을 식별하십시오. 정적 및 런타임 매개변수를 사용하여 디자인의 어느 부분을 보다 재사용가능하거나 탄력적으로 할 수 있습니까(예: 테이블 기반 동작 또는 시작 시 로드된 자원 데이터)?
  • 기존 제품 사용에 대한 잠재성을 식별하십시오.

프로세스 보기

프로세스 보기는 시스템의 프로세스 구조를 설명합니다. 프로세스 구조는 아키텍처에 큰 영향을 미치므로 모든 프로세스를 제시해야 합니다. 프로세스 내에서는 구조적으로 중요하고 간단한 스레드만을 표시하면 됩니다. 프로세스 보기는 시스템의 실행과 관련된 타스크(프로세스 및 스레드), 상호작용과 구성 및 오브젝트와 클래스를 타스크에 할당하는 것에 대해 설명합니다.

프로세스의 각 네트워크에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

  1. 이름.
  2. 관련된 프로세스.
  3. 커뮤니케이션 다이어그램 형태의 프로세스 간 상호작용, 여기서는 오브젝트가 자체 제어 스레드를 포함하는 실제 프로세스입니다. 각 프로세스에 대해 동작, 수명 및 커뮤니케이션 특성을 간단히 설명하십시오.

배치 보기

이 섹션은 소프트웨어가 배치되어 실행되는 하나 이상의 실제 네트워크(하드웨어) 구성을 설명합니다. 실제 노드에 타스크를 할당(프로세스 보기에서)하는 것에 대해서도 설명합니다. 각 실제 네트워크 구성에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

  1. 이름.
  2. 구성을 설명하는 배치 다이어그램 및 각 프로세서로의 프로세스 맵핑.
  3. 가능한 실제 구성이 많이 있으면 일반적인 구성만 설명한 다음 다른 구성을 정의할 때 준수해야 할 일반 맵핑 규칙을 설명하십시오. 대부분의 경우 소프트웨어 테스트 및 시뮬레이션을 수행하기 위한 네트워크 구성 설명도 포함해야 합니다.

이 보기는 중간 산출물: 배치 모델에서 생성됩니다.

구현 보기

이 섹션은 소프트웨어를 계층으로 분할하는 것과 구현 모델의 구현 서브시스템을 설명합니다. 구현으로의 디자인 요소 할당(논리 보기에서)에 대한 개요도 제공합니다. 다음 두 가지 하위 섹션을 포함합니다.

  1. 개요

    이 하위 섹션은 다양한 계층과 컨텐츠, 제공된 계층에 대한 포함을 지배하는 규칙 및 계층 간의 경계를 정의하고 이름을 지정합니다. 계층 간의 관계를 표시하는 컴포넌트 다이어그램을 포함하십시오.

  2. 계층

    각 계층에 대해 다음 정보가 있는 하위 섹션을 포함하십시오.

    1. 이름.
    2. 구현 서브시스템 및 가져오기 종속성을 표시하는 컴포넌트 다이어그램
    3. 해당되는 경우, 논리 또는 프로세스 보기의 요소에 대한 계층 관계의 아웃라인.
    4. 계층에 있는 구현 서브시스템의 열거. 각 구현 서브시스템에 대해 다음을 수행하십시오.
      • 이름, 약어나 닉네임, 간단한 설명 및 존재에 대한 근거를 제공하십시오.
      • 해당되는 경우, 논리 또는 프로세스 보기의 요소에 대한 구현 서브시스템의 관계를 표시하십시오. 많은 경우에 구현 서브시스템은 논리 보기에서 하나 이상의 디자인 서브시스템을 구현합니다.
      • 구현 서브시스템이 구조적으로 중요한 구현 서브시스템 및/또는
        디렉토리를 포함하는 경우 하위 섹션 계층 구조에 이를 반영하는 것을 고려하십시오.
      • 구현 서브시스템이 구현 디렉토리와 일 대 일로 맵핑되지 않으면 구현 디렉토리 및/또는 파일을 통해 구현 서브시스템이 정의되는 방법에 대한 설명을 포함하십시오.

데이터 보기

이 보기는 데이터베이스 지원 지속성을 포함하는 시스템에만 관련이 있습니다. 이는 데이터 모델에서 구조적으로 중요한 지속성 요소를 설명합니다. 시스템에 지속성을 제공하는 데 사용되는 스토어드 프로시저, 트리거, 색인, 뷰 및 테이블을 통해 데이터 모델과 조직의 개요를 설명합니다. 데이터베이스의 데이터 구조에 대한 지속성 클래스의 맵핑(논리 보기로부터)도 설명합니다.

일반적으로 다음을 포함합니다.

  • 키 지속성 디자인 클래스로부터의 맵핑, 특히 이 맵핑은 중요합니다.
  • 데이터베이스에서 스토어드 프로시저 및 트리거의 형태로 구현된 시스템의 구조적으로 중요 파트.
  • 데이터 내포가 있는 다른 보기의 중요 결정(예: 트랜잭션 전략 선택, 분배, 동시성 및 결함 허용). 예를 들어, 데이터베이스 기반 트랜잭션 관리를 사용하기로 선택하면(트랜잭션의 확약 또는 중단을 데이터베이스에 의존함) 아키텍처에 사용된 오류 처리 메커니즘이 응용프로그램의 메모리에서 캐시된 지속성 오브젝트의 상태를 새로 고쳐서 실패한 트랜잭션을 복구하는 전략을 포함해야 합니다.

구조적으로 중요한 데이터 모델 요소를 제시하고, 이들 요소의 책임과 몇 가지 매우 중요한 관계 및 동작(트리거, 스토어드 프로시저 등)을 설명해야 합니다.

크기 및 성능

이 섹션은 시스템의 구조적으로 정의하는 볼륨 및 반응 특성을 설명합니다. 제시된 정보는 다음을 포함할 수 있습니다.

  • 시스템이 처리해야 할 핵심 요소의 수(항공사 제어 시스템의 동시 비행 수, 통신사 스위치의 동시 통화 수, 항공사 예약 시스템의 동시 온라인 사용자 수 등).
  • 시스템의 핵심 성능 척도(예: 중요 이벤트의 평균 응답 시간, 평균, 최대 및 최소 처리량 비율 등).
  • 실행 가능 프로그램의 풋프린트(디스크 및 메모리에 대한) - 시스템이 극도로 한정된 제한조건 내에 있어야 하는 임베디드 시스템인 경우에 필수적입니다.

이들 대부분의 품질은 요구사항으로 캡처됩니다. 이들은 아키텍처를 의미있는 방식으로 형성하고 특별한 초점을 보장하기 때문에 여기에 제시됩니다. 각 요구사항에 대해 아키텍처가 이 요구사항을 지원하는 방식을 논의하십시오.

품질

이 섹션에서 아키텍처를 형성하는 시스템의 중요 품질 차원을 나열하십시오. 제시된 정보는 다음을 포함할 수 있습니다.

  • 운영 성능 요구사항(예: 평균 실패 시간 간격(MTBF)).
  • 품질 목표(예: "계획되지 않은 정지 시간 없음")
  • 확장성 목표(예: "시스템이 실행 중인 동안 소프트웨어 업그레이드 가능").
  • 이식성 목표(예: 하드웨어 플랫폼, 운영 체제, 언어).

각 차원에 대해 아키텍처가 이 요구사항을 지원하는 방식을 논의하십시오. 다른 보기(논리, 구현 등) 또는 품질별로 섹션을 구성할 수 있습니다. 안전, 보안 또는 개인정보와 같이 시스템에서 특별한 특성이 중요한 경우 이 섹션에서 이들에 대한 아키텍처 지원을 주의깊게 기술해야 합니다.