건축 기법

반복적이고 점진적인 접근

후보 솔루션을 생성하는 데 도움이되는 5 가지 주요 단계로 구성된 반복적이고 점진적인 접근 방식입니다. 이 후보 솔루션은 이러한 단계를 반복하여 더욱 세분화 할 수 있으며 마지막으로 애플리케이션에 가장 적합한 아키텍처 디자인을 만들 수 있습니다. 프로세스가 끝나면 아키텍처를 검토하고 모든 이해 당사자에게 전달할 수 있습니다.

가능한 한 가지 접근 방식입니다. 아키텍처를 정의, 검토 및 전달하는 더 많은 공식적인 접근 방식이 있습니다.

아키텍처 목표 확인

아키텍처 및 디자인 프로세스를 형성하는 아키텍처 목표를 식별합니다. 완벽하고 정의 된 목표는 아키텍처를 강조하고 설계의 올바른 문제를 해결하며 현재 단계가 완료되고 다음 단계로 이동할 준비가되었는지 결정하는 데 도움이됩니다.

이 단계에는 다음 활동이 포함됩니다.

처음에 아키텍처 목표를 식별하십시오.
우리 아키텍처의 소비자를 식별하십시오.
제약 사항을 식별하십시오.

아키텍처 활동의 예로는 웹 애플리케이션의 주문 처리 UI에 대한 피드백을 얻기위한 프로토 타입 빌드, 고객 주문 추적 애플리케이션 빌드, 인증 설계, 보안 검토를 수행하기위한 애플리케이션의 권한 부여 아키텍처 등이 있습니다.

주요 시나리오

이 단계에서는 가장 중요한 디자인에 중점을 둡니다. 시나리오는 시스템과 사용자의 상호 작용에 대한 광범위한 설명입니다.

주요 시나리오는 애플리케이션의 성공을 위해 가장 중요한 시나리오로 간주되는 시나리오입니다. 아키텍처에 대한 결정을 내리는 데 도움이됩니다. 목표는 사용자, 비즈니스 및 시스템 목표 간의 균형을 이루는 것입니다. 예를 들어, 사용자 인증은 품질 속성 (보안)과 중요한 기능 (사용자가 시스템에 로그인하는 방법)의 교차점이기 때문에 핵심 시나리오입니다.

응용 프로그램 개요

애플리케이션의 개요를 작성하여 아키텍처를보다 쉽게 만질 수있게 만들고 실제 제약 조건 및 결정에 연결합니다. 다음 활동으로 구성됩니다.

애플리케이션 유형 식별

모바일 애플리케이션, 리치 클라이언트, 리치 인터넷 애플리케이션, 서비스, 웹 애플리케이션 또는 이러한 유형의 일부 조합인지 여부에 관계없이 애플리케이션 유형을 식별하십시오.

배포 제한 사항 식별

적절한 배포 토폴로지를 선택하고 애플리케이션과 대상 인프라 간의 충돌을 해결합니다.

중요한 아키텍처 디자인 스타일 식별

클라이언트 / 서버, 계층, 메시지 버스, 도메인 중심 설계 등과 같은 중요한 아키텍처 설계 스타일을 식별하여 파티셔닝을 개선하고 자주 반복되는 문제에 대한 솔루션을 제공하여 설계 재사용을 촉진합니다. 응용 프로그램은 종종 스타일 조합을 사용합니다.

주요 문제 또는 주요 핫스팟

애플리케이션을 설계하는 동안 핫스팟은 실수가 가장 자주 발생하는 영역입니다. 품질 속성 및 교차 우려 사항을 기반으로 주요 문제를 식별합니다. 잠재적 인 문제에는 새로운 기술의 출현과 중요한 비즈니스 요구 사항이 포함됩니다.

품질 속성은 런타임 동작, 시스템 디자인 및 사용자 경험에 영향을 미치는 아키텍처의 전반적인 기능입니다. 크로스 커팅 문제는 모든 레이어, 구성 요소 및 계층에 적용될 수있는 디자인의 특징입니다.

이는 또한 영향력이 큰 설계 실수가 가장 자주 발생하는 영역이기도합니다. 교차 우려 사항의 예로는 인증 및 권한 부여, 통신, 구성 관리, 예외 관리 및 유효성 검사 등이 있습니다.

후보 솔루션

주요 핫스팟을 정의한 후 초기 기준 아키텍처 또는 첫 번째 상위 수준 디자인을 구축 한 다음 세부 정보를 입력하여 후보 아키텍처를 생성합니다.

후보 아키텍처에는 애플리케이션 유형, 배포 아키텍처, 아키텍처 스타일, 기술 선택, 품질 속성 및 교차 문제가 포함됩니다. 후보 아키텍처가 개선 된 경우 새로운 후보 아키텍처를 만들고 테스트 할 수있는 기준이 될 수 있습니다.

주기를 반복하고 설계를 개선하기 전에 이미 정의 된 주요 시나리오 및 요구 사항에 대해 후보 솔루션 설계를 검증합니다.

아키텍처 스파이크를 사용하여 설계의 특정 영역을 발견하거나 새로운 개념을 검증 할 수 있습니다. 아키텍처 스파이크는 특정 설계 경로의 실행 가능성을 결정하고 위험을 줄이며 다양한 접근 방식의 실행 가능성을 신속하게 결정하는 설계 프로토 타입입니다. 주요 시나리오 및 핫스팟에 대해 아키텍처 스파이크를 테스트합니다.

아키텍처 검토

아키텍처 검토는 실수 비용을 줄이고 가능한 한 빨리 아키텍처 문제를 찾아 수정하기위한 가장 중요한 작업입니다. 이는 프로젝트 비용과 프로젝트 실패 가능성을 줄이는 잘 확립되고 비용 효율적인 방법입니다.

주요 프로젝트 이정표에서 그리고 기타 중요한 아키텍처 변경에 대한 응답으로 아키텍처를 자주 검토합니다.
아키텍처 검토의 주요 목표는 아키텍처를 올바르게 검증하는 기준 및 후보 아키텍처의 실행 가능성을 결정하는 것입니다.
기능 요구 사항 및 품질 속성을 제안 된 기술 솔루션과 연결합니다. 또한 문제를 식별하고 개선 할 영역을 인식하는 데 도움이됩니다.

시나리오 기반 평가는 비즈니스 관점에서 가장 중요하고 아키텍처에 가장 큰 영향을 미치는 시나리오에 초점을 맞춘 아키텍처 설계를 검토하는 지배적 인 방법입니다. 다음은 일반적인 검토 방법입니다.

소프트웨어 아키텍처 분석 방법 (SAAM)

원래 수정 가능성을 평가하기 위해 설계되었지만 나중에 품질 속성과 관련하여 아키텍처를 검토하기 위해 확장되었습니다.

아키텍처 트레이드 오프 분석 방법 (ATAM)

품질 속성 요구 사항과 관련하여 아키텍처 결정을 검토하고 특정 품질 목표를 얼마나 잘 충족하는지 검토하는 세련되고 개선 된 SAAM 버전입니다.

ADR (Active Design Review)

일반적인 검토를 수행하는 대신 한 번에 일련의 문제 또는 아키텍처의 개별 섹션에 더 집중하는 불완전하거나 진행중인 아키텍처에 가장 적합합니다.

중간 디자인 (ARID)에 대한 적극적인 검토

진행중인 아키텍처 검토의 ADR 측면과 일련의 문제에 초점을 맞추고, 품질 속성에 초점을 맞춘 시나리오 기반 검토의 ATAM 및 SAAM 접근 방식을 결합합니다.

비용 편익 분석 방법 (CBAM)

아키텍처 결정의 비용, 이점 및 일정에 미치는 영향을 분석하는 데 중점을 둡니다.

아키텍처 레벨 수정 가능성 분석 (ALMA)

비즈니스 정보 시스템 (BIS)에 대한 아키텍처 수정 가능성을 추정합니다.

가족 아키텍처 평가 방법 (FAAM)

상호 운용성과 확장 성을 위해 정보 시스템 제품군 아키텍처를 추정합니다.

아키텍처 디자인 전달

아키텍처 설계를 완료 한 후에는 개발 팀, 시스템 관리자, 운영자, 비즈니스 소유자 및 기타 이해 관계자를 포함한 다른 이해 관계자들에게 설계를 전달해야합니다.

다른 사람에게 아키텍처를 설명하는 다음과 같은 잘 알려진 방법이 있습니다. −

4 + 1 모델

이 접근 방식은 전체 아키텍처에 대한 다섯 가지보기를 사용합니다. 그중 네 가지 견해 (logical view, 그만큼 process view, 그만큼 physical view, 그리고 development view) 다양한 접근 방식의 아키텍처를 설명합니다. 다섯 번째보기는 소프트웨어의 시나리오 및 사용 사례를 보여줍니다. 이해 관계자는 특히 관심이있는 아키텍처의 기능을 볼 수 있습니다.

아키텍처 설명 언어 (ADL)

이 접근 방식은 시스템 구현 전에 소프트웨어 아키텍처를 설명하는 데 사용됩니다. 동작, 프로토콜 및 커넥터와 같은 문제를 해결합니다.

ADL의 가장 큰 장점은 설계를 공식적으로 사용하기 전에 아키텍처의 완전성, 일관성, 모호성 및 성능을 분석 할 수 있다는 것입니다.

애자일 모델링

이 접근 방식은 "표현보다 콘텐츠가 더 중요하다"는 개념을 따릅니다. 생성 된 모델이 간단하고 이해하기 쉬우 며 충분히 정확하고 상세하며 일관성이 있는지 확인합니다.

애자일 모델 문서는 특정 고객을 대상으로하고 해당 고객의 작업 노력을 수행합니다. 문서의 단순성은 아티팩트 모델링에 이해 관계자의 적극적인 참여를 보장합니다.

IEEE 1471

IEEE 1471은 ANSI / IEEE 1471-2000,“소프트웨어 집약적 시스템의 아키텍처 설명에 대한 권장 사례”로 알려진 표준의 축약 이름입니다. IEEE 1471은 아키텍처 설명의 내용을 향상시켜 특히 컨텍스트,보기 및 관점에 특정 의미를 부여합니다.

통합 모델링 언어 (UML)

이 접근 방식은 시스템 모델의 세 가지보기를 나타냅니다. 그만큼functional requirements view (사용 사례를 포함하여 사용자 관점에서 본 시스템의 기능적 요구 사항) the static structural view(클래스 다이어그램을 포함한 객체, 속성, 관계 및 작업); 그리고dynamic behavior view (오브젝트 간의 협업 및 시퀀스, 활동 및 상태 다이어그램을 포함한 오브젝트의 내부 상태 변경).