소프트웨어 아키텍처 및 디자인 소개

시스템의 아키텍처는 주요 구성 요소, 관계 (구조) 및 서로 상호 작용하는 방식을 설명합니다. 소프트웨어 아키텍처 및 디자인에는 비즈니스 전략, 품질 속성, 인간 역학, 디자인 및 IT 환경과 같은 몇 가지 기여 요소가 포함됩니다.

소프트웨어 아키텍처와 디자인을 소프트웨어 아키텍처와 소프트웨어 디자인의 두 단계로 분리 할 수 있습니다. 에Architecture, 비 기능적 결정은 기능적 요구 사항에 따라 캐스팅되고 분리됩니다. 디자인에서는 기능적 요구 사항이 충족됩니다.

소프트웨어 아키텍처

아키텍처는 blueprint for a system. 시스템 복잡성을 관리하고 구성 요소 간의 통신 및 조정 메커니즘을 설정하기위한 추상화를 제공합니다.

그것은 structured solution 모든 기술 및 운영 요구 사항을 충족하는 동시에 성능 및 보안과 같은 공통 품질 속성을 최적화합니다.
또한 소프트웨어 개발과 관련된 조직에 대한 일련의 중요한 결정이 포함되며 이러한 각 결정은 최종 제품의 품질, 유지 관리 성, 성능 및 전반적인 성공에 상당한 영향을 미칠 수 있습니다. 이러한 결정은 다음으로 구성됩니다.
- 시스템을 구성하는 구조 요소 및 인터페이스 선택.
- 이러한 요소 간의 공동 작업에 지정된 동작입니다.
- 이러한 구조 및 행동 요소를 대형 하위 시스템으로 구성합니다.
- 아키텍처 결정은 비즈니스 목표와 일치합니다.
- 아키텍처 스타일은 조직을 안내합니다.

소프트웨어 디자인

소프트웨어 디자인은 design plan그것은 시스템의 요소, 그것들이 어떻게 맞고, 시스템의 요구 사항을 충족시키기 위해 함께 작동 하는지를 설명합니다. 설계 계획을 갖는 목적은 다음과 같습니다.

시스템 요구 사항을 협상하고 고객, 마케팅 및 관리 담당자와 기대치를 설정합니다.
개발 과정에서 청사진 역할을합니다.
세부 설계, 코딩, 통합 및 테스트를 포함한 구현 작업을 안내합니다.

세부 설계, 코딩, 통합 및 테스트 전과 도메인 분석, 요구 사항 분석 및 위험 분석 후에 발생합니다.

건축의 목표

아키텍처의 주요 목표는 애플리케이션의 구조에 영향을 미치는 요구 사항을 식별하는 것입니다. 잘 구성된 아키텍처는 기술 솔루션 구축과 관련된 비즈니스 위험을 줄이고 비즈니스와 기술 요구 사항을 연결합니다.

다른 목표 중 일부는 다음과 같습니다.

시스템 구조를 노출하되 구현 세부 정보를 숨 깁니다.
모든 사용 사례 및 시나리오를 실현하십시오.
다양한 이해 관계자의 요구 사항을 해결하십시오.
기능 및 품질 요구 사항을 모두 처리합니다.
소유권 목표를 줄이고 조직의 시장 지위를 개선합니다.
시스템에서 제공하는 품질과 기능을 개선합니다.
조직 또는 시스템에 대한 외부 신뢰를 향상시킵니다.

한계

소프트웨어 아키텍처는 여전히 소프트웨어 엔지니어링 분야에서 떠오르는 분야입니다. 다음과 같은 제한이 있습니다.

아키텍처를 나타내는 도구 및 표준화 된 방법이 부족합니다.
아키텍처가 요구 사항을 충족하는 구현으로 이어질지 예측할 수있는 분석 방법이 없습니다.
소프트웨어 개발에 대한 건축 설계의 중요성에 대한 인식 부족.
소프트웨어 설계자의 역할에 대한 이해 부족 및 이해 관계자 간의 의사 소통 부족.
디자인 프로세스, 디자인 경험 및 디자인 평가에 대한 이해 부족.

소프트웨어 아키텍트의 역할

소프트웨어 아키텍트는 기술 팀이 전체 애플리케이션을 만들고 설계 할 수있는 솔루션을 제공합니다. 소프트웨어 아키텍트는 다음 영역에 대한 전문 지식이 있어야합니다.

디자인 전문성

객체 지향 설계, 이벤트 중심 설계 등 다양한 방법과 접근 방식을 포함한 소프트웨어 설계 전문가
설계의 무결성을 위해 개발 팀을 이끌고 개발 노력을 조정합니다.
설계 제안을 검토하고 그들 사이의 균형을 맞출 수 있어야합니다.

도메인 전문성

개발중인 시스템에 대한 전문가 및 소프트웨어 발전 계획.
요구 사항 조사 프로세스를 지원하여 완전성과 일관성을 보장합니다.
개발중인 시스템의 도메인 모델 정의를 조정합니다.

기술 전문성

시스템 구현에 도움이되는 사용 가능한 기술에 대한 전문가.
프로그래밍 언어, 프레임 워크, 플랫폼, 데이터베이스 등의 선택을 조정합니다.

방법 론적 전문성

SDLC (Software Development Life Cycle) 동안 채택 할 수있는 소프트웨어 개발 방법론에 대한 전문가입니다.
전체 팀에 도움이되는 적절한 개발 접근 방식을 선택하십시오.

소프트웨어 아키텍트의 숨겨진 역할

팀 구성원 간의 기술 작업을 촉진하고 팀의 신뢰 관계를 강화합니다.
지식을 공유하고 풍부한 경험을 가진 정보 전문가.
팀원을 산만하게하고 프로젝트의 가치를 낮추는 외부 요인으로부터 팀원을 보호합니다.

건축가의 결과물

명확하고 완전하며 일관되며 달성 가능한 일련의 기능적 목표
최소한 두 개의 분해 계층이있는 시스템의 기능적 설명
시스템 개념
적어도 두 개의 분해 레이어가있는 시스템 형태의 디자인
타이밍, 운영자 속성, 구현 및 운영 계획에 대한 개념
기능적 분해를 보장하는 문서 또는 프로세스를 따르고 인터페이스의 형태를 제어합니다.

품질 속성

품질은 우수성의 척도 또는 결함이나 결함이없는 상태입니다. 품질 속성은 시스템의 기능과는 별 개인 시스템 속성입니다.

품질 속성을 구현하면 좋은 시스템과 나쁜 시스템을 쉽게 구별 할 수 있습니다. 속성은 런타임 동작, 시스템 설계 및 사용자 경험에 영향을 미치는 전반적인 요소입니다.

그들은 다음과 같이 분류 될 수 있습니다-

정적 품질 속성

아키텍처, 디자인 및 소스 코드와 직접 관련된 시스템 및 조직의 구조를 반영합니다. 최종 사용자에게는 보이지 않지만 개발 및 유지 관리 비용에 영향을 미칩니다 (예 : 모듈성, 테스트 가능성, 유지 관리 가능성 등).

동적 품질 속성

실행 중 시스템의 동작을 반영합니다. 이들은 시스템의 아키텍처, 디자인, 소스 코드, 구성, 배포 매개 변수, 환경 및 플랫폼과 직접 관련됩니다.

최종 사용자가 볼 수 있고 런타임에 존재합니다 (예 : 처리량, 견고성, 확장 성 등).

품질 시나리오

품질 시나리오는 결함이 실패하지 않도록 방지하는 방법을 지정합니다. 속성 사양에 따라 여섯 부분으로 나눌 수 있습니다.

Source − 자극을 생성하는 사람, 하드웨어, 소프트웨어 또는 물리적 인프라와 같은 내부 또는 외부 개체.
Stimulus − 시스템에 도착했을 때 고려해야 할 조건.
Environment − 특정 조건 내에서 자극이 발생합니다.
Artifact − 전체 시스템 또는 프로세서, 통신 채널, 영구 저장소, 프로세스 등과 같은 일부
Response − 오류 감지, 오류 복구, 이벤트 소스 비활성화 등과 같은 자극 도착 후 수행되는 활동.
Response measure − 요구 사항을 테스트 할 수 있도록 발생한 응답을 측정해야합니다.

일반적인 품질 속성

다음 표는 소프트웨어 아키텍처가 가져야하는 일반적인 품질 속성을 나열합니다.

범주	품질 속성	기술
디자인 품질	개념적 무결성	전체 디자인의 일관성과 일관성을 정의합니다. 여기에는 구성 요소 또는 모듈이 설계되는 방식이 포함됩니다.
	유지 보수성	시스템이 어느 정도 쉽게 변경 될 수있는 능력.
	재사용 성	다른 애플리케이션에서 사용하기에 적합한 구성 요소 및 하위 시스템의 기능을 정의합니다.
런타임 품질	상호 운용성	외부 당사자가 작성하고 실행하는 다른 외부 시스템과 통신하고 정보를 교환하여 시스템 또는 다른 시스템이 성공적으로 작동 할 수있는 능력.
	관리 용이성	시스템 관리자가 애플리케이션을 얼마나 쉽게 관리 할 수 있는지 정의합니다.
	신뢰할 수 있음	시간이 지나도 계속 작동 할 수있는 시스템의 능력.
	확장 성	시스템 성능에 영향을주지 않고로드 증가를 처리 할 수있는 시스템의 능력 또는 쉽게 확장 할 수있는 능력.
	보안	설계된 용도를 벗어난 악의적이거나 우발적 인 행동을 방지하는 시스템의 기능.
	공연	주어진 시간 간격 내에서 작업을 실행하는 시스템의 응답 성을 나타냅니다.
	유효성	시스템이 작동하고 작동하는 시간의 비율을 정의합니다. 사전 정의 된 기간 동안 전체 시스템 다운 타임의 백분율로 측정 할 수 있습니다.
시스템 품질	지원 가능성	올바르게 작동하지 않을 때 문제를 식별하고 해결하는 데 도움이되는 정보를 제공하는 시스템의 능력.
시스템 품질	테스트 가능성	시스템 및 구성 요소에 대한 테스트 기준을 만드는 것이 얼마나 쉬운 지 측정합니다.
사용자 자질	유용성	응용 프로그램이 직관적으로 사용자와 소비자의 요구 사항을 얼마나 잘 충족하는지 정의합니다.
아키텍처 품질	단정	시스템의 모든 요구 사항을 충족하기위한 책임.
비 런타임 품질	휴대 성	다른 컴퓨팅 환경에서 실행되는 시스템의 능력.
	완전	시스템의 개별적으로 개발 된 구성 요소가 함께 올바르게 작동하도록하는 기능.
	수정 가능성	각 소프트웨어 시스템이 소프트웨어 변경 사항을 쉽게 수용 할 수 있습니다.
비즈니스 품질 속성	비용 및 일정	시장 출시 시간, 예상 프로젝트 수명 및 레거시 활용과 관련된 시스템 비용.
비즈니스 품질 속성	시장성	시장 경쟁과 관련하여 시스템 사용.