가이드라인: SAD(Software Architecture Document)
주제
이 참조 섹션에서는 시스템 구조를 이해하는 데 중요한 배경 정보를 제공하는 외부 문서를
설명합니다. 한 섹션에 참조할 내용이 많으면 서브 섹션으로 분할하여 구성됩니다.
- 외부 문서
- 내부 문서
- 정부 문서
- 비정부 문서
- 기타 문서
구조는 다음 요구사항을 고려하여 이루어집니다.
- 유스 케이스 모델에서 캡처된 기능적 요구사항
- 추가 스펙에서 캡처된 비기능적 요구사항
그러나 이러한 요구사항만이 구조를 형성하는 데 영향을 주지는 않으며, 기존 자산에 대한 재활용 요구,
다양한 표준 적용, 기존 시스템과 호환성 요구 등에 따라 소프트웨어가 작동해야 하는 환경에서 부과하는
제한조건이 있습니다. 또한 이전부터 존재하는 일련의 구조 원칙 및 정책도 있을 수 있는데,
이는 개발을 안내하고 프로젝트를 위해 구현 및 구체화되어야 합니다. SAD에서
이 섹션은 해당 목표와 제한조건, 그리고 다른 곳에서 시작점(요구사항으로서)을 찾지 않는 목표와
제한조건으로부터 구조 결정 진행 과정를 설명합니다.
이 문서를 작성할 경우 중요한 입력은 구현 환경의 스펙입니다. 지정되어야 하는 요소의 예는
대상 플랫폼(하드웨어, 운영 체제), 창 시스템, 개발 툴(언어, GUI 빌더), 데이터베이스 관리 시스템 및
컴포넌트 라이브러리입니다. 또한 허용되는 사용자 인터페이스 기술 및 허용되지 않는 사용자 인터페이스
기술을 지정하는 것도 중요합니다. 더 많은 클라이언트 시스템에서 해당 어플리케이션을 사용할 수
있도록 하거나 이 어플리케이션을 쉽게 개발하도록 다수의 시스템에서 특정 프리젠테이션 기술(JavaScript,
애플릿, 프레임, XML 등)을 사용하지 않도록 선택합니다. 결정은
이 SAD에서
반복 평가의 일부분으로서 사용될 일련의 구조 평가 기준을 프레임으로 구성하면 이러한 결정을
적용할 수 있습니다.
또한 평가 기준도 해당 문서가 향후에 다음과 같이 변경될 수 있는 변경 케이스에서 도출됩니다.
- 시스템의 성능 및 등록 정보
- 시스템 사용 방법
- 시스템의 작동 및 지원 환경
변경 케이스는 "확장 용이", "포트 연결 용이", "유지보수 용이", "변경에
대한 탄력적 대응" 및 "신속 개발"과 같은 주관적 문구로 설명되는 시스템의 등록 정보를 명확히
합니다. 변경 케이스는 중요하고 단지 가능성만 있는 것이 아닌 구체적인 것에 초점을 맞춥니다.
변경 케이스는 변경을 예측하려고 시도하지만 이러한 예측은 좀처럼 정확하게 일치하지는
않습니다.
사용자, 스폰서, 공급자, 개발자 및 기타 스테이크홀더(Stakeholder)가 시스템의 등록 정보를 결정합니다. 변경은
다수의 소스에서 발생할 수 있는데, 예를 들면 다음과 같습니다.
- 비즈니스 동인: 새롭거나 수정된 비즈니스 프로세스 및 목표
- 기술 동인: 새 플랫폼에 시스템 적응, 새 컴포넌트와 통합
- 일반 사용자의 프로파일에서 변경
- 다른 시스템과 통합 요구에서 변경
- 외부 시스템으로부터 기능 이주에서 발생하는 범위 변경
유스 케이스 보기는 구조적으로 중요한 시스템의 유스 케이스를 보여주는
결과물: 유스 케이스 모델의 서브세트를 나타냅니다. 이 보기는
일부 중요한 핵심 기능을 나타내는 일련의 시나리오 및/또는 유스 케이스를 설명합니다. 또한 다수의 구조적
요소를 사용하는 실질적인 구조적 커버리지가 있거나 구조의 정교한 특정 지점을 강조하거나 설명하는
일련의 시나리오 및/또는 유스 케이스도 설명합니다.
모델이 커지면 일반적으로 패키지로 구성됩니다. 패키지로 구성한 경우 유스 케이스 보기도 쉽게
이해할 수 있도록 이와 유사하게 패키지로 구성되어야 합니다. 각각의 중요한 유스 케이스에 대해
다음 정보가 있는 서브 섹션을 포함시키십시오.
- 유스 케이스 이름.
- 유스 케이스에 대한 간략한 설명.
- 유스 케이스의 이벤트 플로우에 대한 중요한 설명. 전체 이벤트 플로우 설명
또는 유스 케이스의 중요한 플로우나 시나리오를 설명하는 이벤트 플로우의 서브 섹션일 수 있습니다.
- 유스 케이스를 수반하는 중요한 관계 설명(예: 포함 및 확장 관계 또는 의사소통 연관).
- 유스 케이스와 관련되는 중요한 유스 케이스 다이어그램의 나열.
- 유스 케이스의 특수 요구사항에 대한 중요한 설명. 전체 특수 요구사항 설명
또는 중요한 요구사항을 설명하는 특수 요구사항의 서브 섹션일 수 있습니다.
- 유스 케이스를 명확하게 설명하는 중요한 사용자 인터페이스 그림.
- 논리 보기에서 이러한 유스 케이스를 실현해야 합니다.
논리 보기는 구조적으로 중요한 설계 요소를 보여주는 결과물: 설계 모델의
서브세트입니다. 이 보기는 가장 중요한 클래스, 패키지와 서브시스템으로 이루어진 구성, 그리고 이 패키지와
서브시스템의 구성을 계층화시켜 설명합니다.
또한 가장 중요한 유스 케이스 실현(예: 구조의 동적 특성)도 설명합니다.
복잡한 시스템에는 논리 보기를 설명하기 위해 다음과 같은 다수의 섹션이 필요할 수 있습니다.
- 개요
이 서브 섹션에서는 패키지 계층 구조 및 계층에 관하여 설계 모델을 전체적으로 분해하여
설명합니다. 시스템에 여러 레벨의 패키지가 있으면 중요한 최상위 레벨의 패키지를 먼저 설명해야
합니다. 상호 종속성 및 계층화뿐만 아니라 중요한 최상위 레벨 패키지를 보여주는 다이어그램을
포함시키십시오. 그런 다음 이 안에 포함된 중요한 패키지에서 최하위 계층의 중요한 패키지까지
하향식으로 계속하여 나타냅니다.
- 구조적으로 중요한 설계 패키지
각각의 중요한 패키지에 대해 다음 정보가 있는 서브 섹션을 포함시키십시오.
- 패키지 이름.
- 간략한 설명.
- 패키지 안에 있는 중요한 모든 클래스 및 패키지를 포함하고 있는 다이어그램. 이 다이어그램을
더 잘 이해하기 위해서는 필요한 경우 다른 패키지의 클래스를 일부 보여줄 수 있습니다.
- 패키지에 있는 각각의 중요한 클래스에 대해 이름, 간략한 설명을 포함시키고 일부의 주요 책임,
조작 및 속성의 설명은 선택사항으로 포함시키십시오. 또한 포함된 다이어그램을 이해하는 데 필요한 경우
중요한 관계도 설명하십시오.
- 유스 케이스 실현
이 섹션에서는 선택된 약간의 유스 케이스(또는 시나리오) 실현을 제공하여 소프트웨어 작동 방법을 설명하며
다양한 설계 요소가 해당 기능을 어떻게 지원하는지 설명합니다. 여기서 제공되는 실현은 최종 시스템에서 일부 중요한
핵심 기능을 나타내거나, 구조적 커버리지에 대해 다수의 구조 요소를 사용하거나, 구조의 정교한 특정 지점을 강조 또는
설명하기 때문에 선택된 것입니다. 이러한 실현에 해당하는 유스 케이스 및 시나리오는 유스 케이스 보기에 있어야 합니다.
각각의 중요한 유스 케이스에 대해 다음과 같은 정보가 있는 서브 섹션을 포함시키십시오.
- 실현된 유스 케이스 이름.
- 실현된 유스 케이스에 대한 간략한 설명.
- 유스 케이스 실현의 이벤트 플로우 - 설계에 대한 중요한 설명. 전체 이벤트 플로우 - 설계
설명 또는 유스 케이스의 중요한 플로우나 시나리오의 실현을 설명하는 이벤트 플로우 - 설계의 서브 섹션일 수 있습니다.
- 유스 케이스 실현과 관련되는 중요한 상호 작용 또는 클래스 다이어그램의 나열.
- 유스 케이스 실현의 도출된 요구사항에 대한 중요한 설명. 전체 도출된 요구사항 설명 또는 중요한 요구사항을 설명하는 도출된 요구사항의 서브 섹션일 수 있습니다.
구조적으로 중요한 설계 요소
구조적으로 중요한 요소의 결정을 돕기 위해 요소와 해당 특성을 규정하는 몇 가지 예가 있습니다.
- 다음과 같이 문제점 도메인의 주요 추상성을 캡슐화하는 모델 요소
- 항공 교통 제어 시스템의 비행 계획
- 급여 시스템의 직원
- 전화 시스템의 가입자
이러한 요소의 서브유형이 반드시 포함되어야 하는 것은 아닙니다. 예를 들어, 모두 비행 계획이고
실제로 상당한 양의 속성과 조작을 공유하기 때문에 ICAO 표준 비행 계획과 US 국내 비행 계획을
구별하는 것은 중요하지 않습니다.
호출 처리가 거의 동일한 방식으로 계속되는 한 데이터 회선 또는 음성 회선을 사용하는 가입자를
구별하는 것은 중요하지 않습니다.
- 기타 수많은 모델 요소에서 사용하는 모델 요소
- 시스템의 주요 메커니즘(서비스)을 캡슐화하는 모델 요소
- 설계 메커니즘
- 지속성 메커니즘(저장소, 데이터베이스, 메모리 관리)
- 의사소통 메커니즘(RPC, 브로드캐스트, 중개자 서비스)
- 오류 처리 또는 복구 메커니즘
- 표시 메커니즘 및 기타 공통 인터페이스(창 지정, 데이터 캡처, 신호 조정 등)
- 매개변수화 메커니즘
일반적으로 메커니즘은 다양한 패키지에서 사용될 수 있으며(패키지에 완전히 내장되는 것과 대조적)
이를 위해 시스템 전반에 걸쳐 하나의 공통 구현을 수행하거나 여러 개의 대체 구현을 숨기고 있는 최소 하나
이상의 공통 인터페이스를 배치하는 것이 좋습니다.
- 시스템의 주요 인터페이스에 참여하는 모델 요소는 예를 들면 다음과 같습니다.
- 운영 체제
- 재고품(창 지정 시스템, RDBMS, 지리 정보 시스템(GIS))
- 구조 패턴(예: MVC(Model-View-Controller) 패턴을 포함한 분리 모델 요소 패턴 또는
중개자 패턴)을 구현하거나 지원하는 클래스
- 지역화된 가시성을 보유하나 시스템의 전체 성능에 크게 영향을 미칠 수 있는 모델 요소는
예를 들면 다음과 같습니다.
- 초고속으로 센서를 스캔하기 위한 폴링 메커니즘
- 문제점 해결을 위한 추적 메커니즘
- 높은 사용 가능성 시스템을 위한 체크포인트 메커니즘(체크포인트 및 재시작)
- 시작 순서
- 온라인 코드 갱신
- 새롭고 기술적 위험이 높은 알고리즘이나 안전 또는 보안이 중요한 일부 알고리즘을
캡슐화하는 클래스(예: 방사선 조사 레벨 계산, 혼잡한 영공에서 항공기 충돌 방지 기준, 암호화)
기술적 장애를 발견하고 시스템을 더 잘 이해하기 시작함에 따라 구조적으로 중요한 요소에 관한 기준은
프로젝트의 초기 반복에서 전개합니다. 그러나 일반적으로 10% 정도의 모델 요소를
"구조적으로 중요한" 요소로 레이블을 지정해야 합니다. 그렇지 않으면
"구조가 중요하다."라는 구조 개념을 약화시키는 위험을 감수해야 합니다.
논리 보기에서 구조적으로 중요한 모델 요소를 정의하여 포함시키는 경우 다음 특성도 고려해야 합니다.
- 공유성 및 재사용에 대한 잠재적 요소를 식별하십시오. 어떤 클래스가 공통 클래스의 서브클래스 또는
매개변수화된 동일한 클래스의 인스턴스일 수 있습니까?
- 매개변수화에 대한 잠재적 요소를 식별하십시오. 정적 및 런타임 매개변수를 사용하면
설계의 어느 파트(예: 테이블 기반 작동 또는 시작시 로드되는 자원 데이터)가 더 많이
재사용될 수 있거나 유연하게 될 수있습니까?
- 재고품 사용에 대한 잠재 요소를 식별하십시오.
프로세스 보기는 시스템의 프로세스 구조를 설명합니다. 프로세스 구조는 상당히 큰 구조적 영향을 주기 때문에
모든 프로세스가 나타나야 합니다. 프로세스 안에는 구조적으로 중요한 경량 스레드만 나타나야 합니다. 프로세스
보기는 타스크에 객체 및 클래스를 할당할 뿐만 아니라 시스템의 실행, 상호 작용 및 형상과도 관련된 타스크(프로세스
및 스레드)를 설명합니다.
프로세스의 각 네트워크에 대해 다음 정보가 있는 서브 섹션을 포함시키십시오.
- 네트워크 이름.
- 관련된 프로세스.
- 의사소통 다이어그램 형식의 프로세스 간 상호 작용(객체는 고유의 제어 스레드를
보유하는 실제 프로세스임). 각 프로세스의 작동, 지속 기간 및 의사소통 특성을 간략하게 설명합니다.
이 섹션에서는 소프트웨어를 전개하여 실행하는 하나 이상의 실제 네트워크(하드웨어) 형상을 설명합니다. 또한
실제 노드에 타스크(프로세스 보기)를 할당하는 것도 설명합니다. 각각의 실제 네트워크 형상에
대해 다음 정보가 있는 서브 섹션을 포함시키십시오.
- 네트워크 형상 이름.
- 형상을 설명하는 전개 다이어그램으로 각 프로세서에 프로세스를 맵핑하는 작업이 수반됩니다.
- 다수의 실제 형상이 있을 가능성이 있으면 일반적인 형상 하나를 설명한 다음 다른 형상을 정의할 때
준수할 일반 맵핑 규칙을 설명하십시오. 또한 대부분의 경우 소프트웨어 테스트 및 시뮬레이션을 수행하기
위한 네트워크 형상의 설명도 포함시켜야 합니다.
이 보기는 결과물: 전개 모델에서 생성됩니다.
이 섹션에서는 소프트웨어를 계층으로 분해하고 구현 모델에서 구현 서브시스템을
설명합니다. 또한 구현에 설계 요소(논리 보기)를 할당하는 방법에 대해서도 개요를
제공합니다. 포함되는 두 개의 서브 섹션은 다음과 같습니다.
- 개요
이 서브 섹션에서는 다양한 계층과 해당 컨텐츠, 지정된 계층에 포함시킬 사항을 제어하는 규칙 및 계층 간
경계를 명명하고 정의합니다. 계층 간 관계를 보여주는 컴포넌트 다이어그램을 포함시키십시오.
- 계층
각 계층에 대해 다음 정보가 있는 서브 섹션을 포함시키십시오.
- 계층 이름.
- 구현 서브시스템 및 가져오기 종속성을 보여주는 컴포넌트 다이어그램.
- 해당되는 경우, 논리 또는 프로세스 보기에 있는 요소와 계층 사이의 관계 개요.
- 계층에 있는 구현 서브시스템의 나열. 각 구현 서브시스템에 대해 다음을 수행하십시오.
- 이름, 약어 또는 별명, 간략한 설명 및 존재에 대한 합리성을 제공하십시오.
- 해당되는 경우, 논리 또는 프로세스 보기에 있는 요소와 구현 서브시스템 사이의
관계를 나타내십시오. 다수의 경우에서 구현 서브시스템은 논리 보기로부터 하나 이상의 설계 서브시스템을 구현합니다.
- 구현 서브시스템에 구조적으로 중요한 구현 서브시스템 및/또는
디렉토리가 있으면 서브 섹션 계층 구조에 이 경우를 반영하도록 고려하십시오.
- 구현 서브시스템이 구현 디렉토리와 일대일로 맵핑되지 않으면 구현 디렉토리 및/또는 파일에
관하여 구현 서브시스템 정의 방법의 설명을 포함시키십시오.
이 데이터 보기는 데이터 모델에서 구조적으로 중요한 지속적 요소를 설명합니다. 시스템에 지속성을
제공하는 데 사용되는 테이블, 보기, 색인, 트리거 및 저장 프로시저에 관하여 데이터 모델 및 해당 구성의
개요를 제공합니다. 또한 데이터베이스의 데이터 구조에 지속적 클래스(논리 보기)를
맵핑하는 방법도 설명합니다.
일반적으로 다음 항목이 포함됩니다.
- 특히 맵핑이 중대한 핵심 지속적 설계 클래스로부터 맵핑.
- 저장 프로시저 및 트리거 형식으로 데이터베이스에 구현되어 있는 시스템의 구조적으로 중요한 파트.
- 트랜잭션 전략, 분배, 동시성, 결함 허용의 선택과 같이 데이터 암시성이 있는 기타 보기에서 중요한 결정.
예를 들어, 트랜잭션을 확약하거나 중단할 데이터베이스에 따라 데이터베이스 기반 트랜잭션 관리를 사용하도록
선택할 경우에는 해당 구조에서 사용되는 오류 처리 메커니즘에 어플리케이션의 메모리에 캐시된 지속성 객체의 상태를
새로 고쳐 실패한 트랜잭션으로부터 복구하는 전략이 포함되어야 합니다.
구조적으로 중요한 데이터 모델 요소를 제시하고 약간의 매우 중요한 관계와 작동(트리거, 저장 프로시저 등)뿐만
아니라 책임도 설명해야 합니다.
이 섹션에서는 시스템에 대한 구조적 정의의 볼륨 측정 및 응답 특성을 설명합니다. 제시되는 정보에는
다음 항목이 포함될 수 있습니다.
- 시스템에서 처리해야 할 핵심 요소의 수(예: 항공 교통 제어 시스템의 동시 비행 수, 전기 통신 교환의
동시 통화 수, 항공사 예약 시스템의 온라인 동시 사용자 수 등).
- 시스템의 핵심 성능 측정값(예: 핵심 이벤트의 평균 응답 시간, 평균, 최대 및 최소 처리율 등).
- 디스크 및 메모리에 관하여 실행 파일의 실행 기록 - 극히 한정적인 제한조건 내에서 지속되어야 하는 임베디드
시스템인 경우 필수적입니다.
이러한 품질 특성은 대부분 요구사항으로서 캡처되며, 구조를 중요한 방법으로 구체화하고 특수한 목표를
보증하기 때문에 여기서 제시되는 것입니다. 각 요구사항에 대해 구조에서 이 요구사항을 지원하는 방법을 검토하십시오.
이 섹션에서는 구조를 구체화하는 시스템의 핵심 품질 차원을 나열합니다. 제시되는 정보에는
다음 항목이 포함될 수 있습니다.
- 작동 성능 요구사항(예: MTBF(Mean Time Between Failure)).
- 품질 목표(예: "예정되지 않은 작동 중단 시간이 없음").
- 확장 가능성 목표(예: "시스템이 실행되는 동안 소프트웨어 업그레이드 가능성").
- 이식성 목표(예: 하드웨어 플랫폼, 운영 체제, 언어).
각 차원에 대해 구조에서 이 요구사항을 지원하는 방법을 검토하십시오. 다양한 보기(논리, 구현 등)
또는 품질로 섹션을 구성할 수 있습니다. 시스템에서 특정 특성(예: 안전, 보안 또는 개인 정보 보호)이
중요한 경우 이러한 특성에 대한 구조적 지원은 이 섹션에서 신중하게 설명되어야 합니다.
| |
|