아키텍처 설계
- 소프트웨어 설계 프로세스의 첫 단계
- 시스템의 전체 설계를 이해하는 것
- 주요 구조 컴포넌트들과 그들 간의 관계 식별
- 설계와 요구공학 사이의 중요한 연결
- 결과물 → 아키텍처 모델
- 시스템이 상호작용하는 컴포넌트들의 집합으로 어떻게 구성되었는지 설명
- 시스템이 상호작용하는 컴포넌트들의 집합으로 어떻게 구성되었는지 설명
애자일 프로세스 아키텍처 설계
- 초기 단계에서 전체 시스템 아키텍처 설계에 초점 맞춤
- 아키텍처의 점진적 개발은 보통 성공적이지 않음
- 변화에 대응하여 컴포넌트를 리팩토리항 하는 것이 상대적으로 쉬움
- 시스템 아키텍처를 리팩터링 하는 것은 비용이 많이 듦
- 아키텍처 변화에 따라 시스템 컴포넌트들은 수정해야 함
아키텍처 설계의 현실적 측면
- 주요 아키텍처 컴포넌트들이 시스템의 상위 수준 특징 반영
→ 컴포넌트 식별 필요 - 이상적으로는 시스템 명세에는 설계 정보가 포함되지 않아야 함
→ 실제론 요구공학 프로세스랑 아키텍처 설계 사이가 많이 중첩 - 시스템 요구사항과 디테일을 이해당사자와 논의하기 위해 사용
소프트웨어 아키텍처
- 두 수준의 추상화
- 작은 수준의 아키텍처
- 개별 프로그램의 아키텍처와 연관
- 개별 프로그램을 컴포넌트들로 분해하는 방법과 관련
- 큰 수준의 아키텍처
- 복잡한 기업 시스템과 연관
- 다른 시스템들과 프로그램 컴포넌트 포함
- 작은 수준의 아키텍처
- 소프트웨어 아키텍처 중요성과 장점
- 중요성 : 시스템의 성능, 견고성, 분산성, 유지보수성에 영향
- 비기능적 시스템 특성에 지배적인 영향, 그 반대도 마찬가지
- 비기능적 시스템 특성에 지배적인 영향, 그 반대도 마찬가지
- 장점 : 소프트웨어 아키텍처를 명시적으로 설계 및 문서화 가능
이해당사자 간의 의사소통- 상위 수준의 시스템 표현으로 다양한 범위의 이해당사자들 간 논의로 사용 가능
- 상위 수준의 시스템 표현으로 다양한 범위의 이해당사자들 간 논의로 사용 가능
시스템 분석- 초기단계에서 설계를 위해선 분석이 필요
- 아키텍처 설계 요구사항을 만족시킬 수 있는지에 큰 영향
대규모 재사용- 시스템 구성과 컴포넌트 간의 상호작용에 대한 간결하고 다루기 쉬운 설명
- 비슷한 요구사항을 가진 시스템들 간의 시스템 아키텍처는 종종 동일
- 중요성 : 시스템의 성능, 견고성, 분산성, 유지보수성에 영향
블록 다이어그램을 통한 시스템 아키텍처 표현
- 시스템 구조를 쉽게 이해할 수 있는 상위 수준의 그림
- 소프트웨어 설계 프로세스에 관여하는 사람들 사이의 의사소통 지원
→ 많은 프로젝트에서 아키텍처 기술에 사용하고 있음 - 비정형적인 표현 → 아키텍처 표현으로 적절치 않다는 의견
- 시스템 컴포넌트 간 관계의 유형을 보여주지 못함
- 컴포넌트가 외부로 보여주는 속성 표현 못함
아키텍처 모델이 사용되는 방법
- 시스템 설계에 대한 논의를 장려하기 위한 방법
- 결과물 : 시스템의 상위 수준 아키텍처 뷰
- 이해당사자 측면에서의 장점
- 아키텍처 관점으로 이해 및 시스템에 대한 추상적인 뷰 이해 가능
- 세부사항 혼동 x, 시스템 전체로써 논의 가능
- 개발할 주요 컴포넌트들 식별 가능 → 시스템 개발을 위한 인력 배치 시작 가능
- 설계한 아키텍처를 문서화하는 방법
- 결과물 : 완전한 시스템 모델
- 시스템의 서로 다른 컴포넌트들과 그들의 인터페이스와 그들의 연결을 완전하게 보여줌
- 시스템의 서로 다른 컴포넌트들과 그들의 인터페이스와 그들의 연결을 완전하게 보여줌
- 시스템의 이해 및 발전을 쉽게 함
- 결과물 : 완전한 시스템 모델
아키텍처 설계 결정
- 아키텍처 설계
- 시스템 구조를 설계하는 창의적인 프로세스
- 일련의 활동이 아닌 연속적인 결정
- 목적 : 시스템의 기능적, 비기능적 요구사항 만족
- 영향을 주는 사항
- 개발되는 시스템의 유형
- 시스템 아키텍트가 배경지식과 경험
- 시스템 특유의 요구사항
- 설계 시 고려해야 하는 부분
- 설계 중인 시스템의 템플릿으로 사용할 수 있는 범용 애플리케이션 아키텍처가 있는가?
- 시스템이 하드에어 코어나 프로세서 상에 어떻게 분산되는가?
- 어떤 아키텍처 패턴이나 스타일이 사용되는가?
- 시스템 컴포넌트들의 동작을 제어하기 위해 사용되는 전략은 무엇인가?
- 시스템의 아키텍처가 어떻게 문서화되어야 하는가?
- 시스템의 비기능적 요구사항을 만족시키기에 최적인 아키텍처 구성은 무엇인가?
- 시스템의 구조를 이루는 컴포넌트들이 서브 컴포넌트로 어떻게 나뉘는가?
- 시스템을 구조화하기 위하여 사용되는 기본적인 접근법은 무엇인가?
시스템 아키텍처 설계 및 결정
- 아키텍처 결정은 시스템의 성능과 신뢰성에 영향을 주는 핵심 결정
- 동일한 응용 도메인의 시스템들은 종종 도메인의 근본적인 개념을 반영하는 유사한 아키텍처를 가짐
- 시스템 아키텍처를 설계할 때 고려해야 할 점
- 광범위한 애플리케이션 클래스와 시스템의 공통점이 무엇인지 결정
- 애플리케이션 아키텍처에서 재사용할 수 있는 지식이 얼마나 되는지 결정
소프트웨어 시스템의 아키텍처
- 특정 아키텍처 패턴 또는 스타일에 기반
아키텍처 패턴- 시스템 구조를 기술한 것(예 : 클라이언트-서버 구조, 계층 아키텍처)
- 다양한 소프트웨어 시스템에서 사용되어 온 아키텍처의 핵심을 담고 있음
- 아키텍처 패턴 필요 사항
- 컴포넌트를 서브 컴포넌트로 나누는 전략이 필요(구조적 시스템 단위로 분해)
- 제어 모델링 프로세스에서 시스템의 다양한 부분들 간의 일반적 제어관계 모델 개발
비기능적 특성과 소프트웨어 아키텍처
- 아키텍처 스타일과 구조 선택은 시스템 비기능적 요구사항과 밀접한 관계
성능이 중요한 경우- 같은 컴퓨터에 배치된 소수의 컴포넌트 안에 중요한 작업이 모이도록 설계
- 상대적으로 몇 개의 큰 컴포넌트 사용 → 컴포넌트 간의 통신 횟수가 줄어듦
- 연관된 시스템 기능 사이의 상호 작용의 대부분이 컴포넌트 내부에서 일어남
- 연관된 시스템 기능 사이의 상호 작용의 대부분이 컴포넌트 내부에서 일어남
- 시스템 중복 혹은 서로 다른 프로세서에서 실행되는 것을 허용하는 런타임 시스템 구성을 고려
보안성이 중요한 경우- 아키텍처에 계층 구조 사용
- 가장 중요 자산 → 가장 안쪽 계층에서 보호 → 높은 수준의 보안 검증이 적용
- 가장 중요 자산 → 가장 안쪽 계층에서 보호 → 높은 수준의 보안 검증이 적용
- 아키텍처에 계층 구조 사용
안전성이 중요한 경우- 안전 관련 작업이 단일 컴포넌트나 소수의 컴포넌트에 같이 배치되도록 설계
- 안전 검증 비용과 문제 감소
- 장애 발생 시 시스템을 종료시킬 수 있는 보호 시스템을 제공
- 안전 관련 작업이 단일 컴포넌트나 소수의 컴포넌트에 같이 배치되도록 설계
가용성이 중요한 경우- 중복 컴포넌트를 포함하여 시스템의 중단 없이 컴포넌트를 교체하고 갱신하는 것이 가능하게 설계
- 중복 컴포넌트를 포함하여 시스템의 중단 없이 컴포넌트를 교체하고 갱신하는 것이 가능하게 설계
유지보수성이 중요한 경우- 변경이 용이한 세분화되고 독립적인 컴포넌트를 사용하도록 설계
- 데이터 생산자와 소비자는 분리, 데이터 구조를 공유하는 것은 피해야 함
- 데이터 생산자와 소비자는 분리, 데이터 구조를 공유하는 것은 피해야 함
- 변경이 용이한 세분화되고 독립적인 컴포넌트를 사용하도록 설계
- 어떤 아키텍처들 사이에는 잠재적인 충돌
- 서로 다른 아키텍처 패턴이나 스타일을 사용하여 타협점 찾음
- 서로 다른 아키텍처 패턴이나 스타일을 사용하여 타협점 찾음
- 아키텍처 설계 평가 기준 : 시스템이 사용될 때 얼마나 기능적, 비기능적 요구사항을 만족시키는지
아키텍처 뷰
여러 아키텍처 뷰의 필요성
- 그래픽 모델
- 시스템의 한 가지 뷰나 관점만 보여줌
→ 시스템 아키텍처와 관련된 정보를 하나의 다이어그램에 표현하는 것은 불가능
- 시스템의 한 가지 뷰나 관점만 보여줌
네 가지 기본 아키텍처 뷰
논리적 뷰- 객체 또는 객체 클래스로 시스템의 핵심 추상화를 보여줌
- 객체 또는 객체 클래스로 시스템의 핵심 추상화를 보여줌
프로세스 뷰- 런타임에 시스템이 어떻게 상호 작용하는 프로세스들로 구성되는지 보여줌
- 성능이나 가용성과 같은 비기능적 시스템 특성들을 판단하는데 유용함
개발 뷰- 소프트웨어가 개발을 위해 어떻게 분해되는지 보여줌
- 소프트웨어 관리자나 프로그래머에게 유용
물리적 뷰- 시스템 하드웨어와 소프트웨어 컴포넌트들이 시스템의 프로세스에 어떻게 분산되는지 보여줌
- 시스템 배치를 계획하는 시스템 엔지니어에게 유용
개념적 뷰
- 4가지 기본적인 아키텍처 뷰 외에 제안한 뷰
- 시스템의 추상적 뷰
- 상위 수준 요구사항을 더 자세한 명세로 분해하기 위한 기초
- 재사용 컴포넌트에 대한 결정 도움, 제품라인 표현(예 : 포장 로봇의 아키텍처)
- 시스템 아키텍처의 개념적 뷰
- 실제 설계 프로세스 중에 거의 항상 개발됨
- 시스템 아키텍처를 이해당사자들에게 설명하고, 의사결정을 알림
아키텍처 기술
- 기술 및 문서화 시 UML이 비정형적인 방법으로 사용
- 왜 비정형적 방법? → 빠르게 작성 가능하기 때문
- UML : 아키텍처를 상세히 문서화하거나 모델 주도 개발을 사용할 때 유용
- 설계 프로세스 자체 과정에서는 UML이 적합하지 않음
- 설계 프로세스 자체 과정에서는 UML이 적합하지 않음
- 더 특수한 아키텍처 기술 언어(ADL)의 사용 제안
- 기본요소 : 컴포넌트 + 커넥터, 아키텍처를 위한 규칙과 가이드라인 포함
- 전문가 언어이기 때문에 주류 소프트웨어 공학 실무가 되진 않음
- 네 가지 관점에 따른 상세 아키텍처 기술 작성은 중대한 시스템을 제외하곤 가치 X