시스템 아키텍처를 공식화 할 때 아키텍처가 테이블에 가져 오는 것의 가치를 이해해야 할뿐만 아니라 그 구조가 무엇인지 이해하고 이해하는 것이 중요합니다.

소프트웨어 또는 기술 아키텍처의 기본 목표 는 시스템 아키텍처를 주도 할 품질 속성에 의해 실현되는 기능 외 요구 사항 을 식별 하는 것 입니다.

비 기능 요구 사항 :

비 기능적 요구 사항은 특정 동작이 아닌 시스템 작동을 판단하는 데 사용할 수있는 기준을 지정하는 요구 사항입니다. 특정 동작이나 기능을 정의하는 기능 요구 사항과 대조됩니다. 기능 요구 사항 구현 계획은 시스템 설계에 자세히 설명되어 있습니다. 비 기능적 요구 사항을 구현하기위한 계획은 시스템 아키텍처에 자세히 설명되어 있습니다.

기능 요구 사항은 일반적으로 시스템의 기능을 정의하고 비 기능 요구 사항은 시스템의 동작 방식을 정의합니다. 비 기능적 요구 사항은 종종 시스템의 “품질 속성”이라고합니다. 기능 외 요구 사항에 대한 다른 용어는 “품질”, “품질 목표”, “서비스 품질 요구 사항”, “제약 사항”및 “비 동작 요구 사항”입니다.

물론 그린 필드 프로젝트에서는 건축 적으로 중요한 요구 사항을 식별하는 것이 합리적이지만 기존 소프트웨어로 작업 할 때는 가능한 한 훈련을받는 것이 가장 좋습니다. 소프트웨어 아키텍처가 기존 시스템의 영향을받지 않기를 바랍니다.

권위있는 소프트웨어 아키텍처는 실제로 3 가지가 필요합니다.

선언적

이것은 당신이 무엇을 선언하지 않는지 문서의 일부이지만 어떻게해야 하는지를 알려줍니다. 우리는 시스템의 다양한 아키텍처 뷰를 사용하여이를 수행합니다. 구성 요소와 구성 요소의 상호 작용 방식을 정의한 다음 선택적으로 시스템을 설계해야하는 방식을 나타내는보다 세부적인보기를 위해 각 구성 요소를 드릴 다운합니다.

이것은 중요한 차이점입니다. 시스템 설계는 시스템 아키텍처에 의해 제약을 받아야하며, 실제로는 별개이지만 관련이 있습니다.

이론적 해석

소프트웨어 아키텍처의 이론적 근거는 아키텍처 결정에 대한 합법성과 권한을 제공하는 것입니다. 배치 작업을 트리거하기 위해 MQ를 통해 Pub / Sub 이벤트 리스너를 사용하기로 결정한 후 다이어그램을 작성 했습니까?

이 결정이 내려진 이유는 무엇입니까? 이론적 근거 섹션에서 이유를 설명하고 기능 요구 사항, 품질 속성 목표 또는 구조적으로 중요한 요구 사항에 대한 설명을 다시 연결합니다. (예 : 작업은 비동기식이고 반복 가능해야합니다. 품질 속성으로서 유지 보수성은 배치 작업 실패시 작업이 MQ 메시지를 통해 다시 시작될 수 있도록하고, 시스템은 비동기 통신으로 메시지 손실이 없어야합니다. ..)

위험

이제 이론을 근거로 아키텍처를 구현하고 증명하는 방법을 선언 했으므로 이제 시스템의 현재 상태에서이를 준수하지 않는 위험을 식별 할 수 있습니다.

(예 : 서버 측 유효성 검사는 클라이언트 측 Javascript 코드에서 복제되고 있습니다. 이는 DRY 원칙을 위반하는 것으로 유지 관리의 품질 속성과 상반됩니다.이 영역의 성능과 관련하여 정의 된 비 기능적 요구 사항이 없으므로 현재 시스템 동작에 대한 근거가 없음)

리스크는 현재 상태가 현재 아키텍처에서 벗어난 위치를 다이어그램으로 표시 할 수도 있습니다. 이러한 위험은 프로젝트 계획을 통해 또는 백 로그에 추가하여 개발 팀이 해결할 수 있습니다.

답변