정의:
외부에서 인식할 수 있는 특성이 담김 소프트웨어의 기본구조
필요 요소:
1. 구성요소(모듈, 컴포넌트, 서비스, 객체 등)
2. 구성요소들 사이의 관계
3. 구성 요소들이 외부에 드러내는 속성
4. 구성 요소들과 주변 환경 사이의 관계
5. 구성 요소들이 제공하는 인터페이스
6. 구성 요서들의 협력 및 조립 방법
특징:
1. 개발할 소프트웨어에 대한 전체적인 구조를 다룬다
2. 소프트웨어를 이루고 있는 여러 구성요소(컴포넌트, 서브시스템)를 다룬다
3. 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지를 정의해야 한다.
4. 세부 내용보다는 중요한 부분만을 다룬다
5. 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 한다.
설계시 고려사항
1. 의사소통 도구로 활용할 수 있어야 한다.
2. 구현에 대한 제약 사항을 정의해야 한다.
3. 품질 속성을 결정해야 한다.
4. 재사용할 수 있게 설계해야 한다.
설계시 기술 방법
1. 이해하기 쉽게 작성
2. 명확하게 기술
3. 표준화된 형식 사용
4. 문서 버전 명시
소프트웨어 아키텍처의 품질 속성
1. 비기능적 특성과 소프트웨어 아키텍처는 밀접한 관계가 있다. 따라서 아키텍쳐 스타일과 구조의 선택은 비기능적 요구사항에 의해 좌 우된다
2. 이해 관계자들의 품질 요구 사항을 반영해 품질 속성을 결정
시스템 품질 속성
1. 가용성: 하드웨어 이중화 처럼 여분의 구성 요소를 포함하도록 설계해야 가용성이 높아진다.
2. 변경 용이성: 빈번하게 변경할 가능성이 높은 소프트웨어는 변경 용이성을 고려해 아키텍처를 결정
3. 성능: 공유 자원을 어떻게 사용하는지, 어떤 알고리즘을 사용해 구현하는지 등의 요소와 밀접
4. 보안성: 계층 구조를 사용해 가장 중요한 자산을 가장 안쪽 계층에서 보호
비즈니스 품질 속성
1. 시장 적시성: 정해진 날짜레 소프트웨어를 출시해 경쟁력을 높일 수 있는 정도
2. 비용과 이익: 비용을 더 많이 들여 유연한 설계를 할 것인지, 비용을 절감하는데 초점을 맞출것인지 판단해야 한다.
3. 예상 시스템 수명: 수명이 중요한 경우면 용이성, 확장선성, 이식성을 더 중요하게 고려
4. 목표시장: 시능성 및 다양한 플랫폼에도 잘 작동되야 하므로 이식성을 충분히 고려
5. 신규 발매 일정 또는 공개 일정:
현재 버전에서는 기본 기능만 제공하고, 추후에 배초할 차기 버전에서 기능을 추가하여 완성도를 높일 예정이면 유연성과 확장성을 고려 한 설계가 필요
6. 기존 시스템과의 통합: 아키텍처 설계시 기존 시스템과의 통합 방법을 충분히 고려한 설계 필요
아키텍처 품질 속성
1. 개념적 무결성: 전체 시스템과 시스템 구성 요소가 일관되도록 아키텍처를 결정
2. 정확성과 완전성: 사용자가 요구하는 기능을 충족시키는 정도 -> 요구 분석 명세서와 일치하는 정도
3. 개발 용이성:
전체 시스템을 적절한 모듈로 분할한 후 개발 팀에 알맞게 분배해 개발함으로써 정해진 기간 내에 완성하고, 개발 과정 중에도 쉽게 변경할 수 있는 능력
아키텍처 구축 절차
1. 요구사항 분석
-품질 속성과 같은 비기능적인 요구 사항에 더 많은 관심을 둔다.
2. 아키텍처 분석
- 품질 속성 식별 -> 우선순위 결정 -> 반영 방법 개발
3. 아키텍처 설계
-관점 정의: 이해 관계자 파악, 이해 관계자별 관점 정의
- 아키텍처 스타일 선택: pipe-filter, MVC 등의 스타일 혼용 적용 가능
- 후보 아키텍처 도출: 배경도 및 각 관점별 다이어그램 작성, 아키텍처 명세서 기술
4. 검증, 승인
- 아키텍처 평가: 아키텍처 요구사항 만족도, 적합성, 품질 속성간 절출관계 등 평가
- 아키텍처 상세화(반복): 설계 방법 도출, 설계 패턴 고려
- 아키텍처 승인: 이해 관계자들이 최종 승인
아키텍처의 관점(4+1관점):
1. 논리적 관점(분석가/ 설계자): 클래스나 컴포넌트의 종류와 관계
-클래스나 컴포넌트의 종류와 이들의 관계에 초점
정적표현: 클래스 다이어그램, 객체 다이어그램
동적표현: 상태, 순차, 통신, 활동 다이어그램
2. 구현 관점(프로그래머): 서브시스템의 모듈구조와 관계
- 서브시스템의 모듈이 어떻게 되있는에 관심
정적: 컴포넌트 다이어그램
동적: 상태, 순차, 통신, 활동 다이어그램
3. 프로세스관점(시스템 통합자): 시스템의 성능, 확장성 효율
- 실제 구동 환경을 실펴서 논리적 관점과 같이 시스템 내부의 구조에 초점
- 시스템의 동시성과 동기화에 관심
시스템 구성 표현: 컴포넌트, 배치 다이어그램
동적 표현: 상태, 순차, 협동, 활동 다이어그램
4. 배치관점(시스템 엔지니어): 시스템 통합자
- 시스템을 구성하는 장치 간의 물리적인 배치에 초점
- 서브 시스템들이 물리적인 환경에서 어떻게 연관되어 실행되는 지를 나타냄
- 시스템의 분산 구조와 실행할 때 컴포넌트 들의 배치 상태를 나타낸다
정적 표현: 배치 다이어그램
동적 표현: 상태, 순차, 통신, 활동 다이어그램
5. 유스케이스 관점: 사용자 기능.
* 1, 2, 3, 4는 모두 유스케이스의 관점을 기준으로 한다
- 시스템 사용자에세 제공하는 기능에 관심
- 다른 네가지 관점에 사용되는 다이어그램의 근간이 된다
정적 표현: 유스케이스
동적 표현: 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램
아키텍처 스타일
1. 아키텍처 스타일에 따라 구조, 규칫, 요소, 기법 등이 결정된다
2. 소프트웨어 특성, 전체 구조, 개발 방법을 알 수 있다
아키텍처 스타일을 사용한 설계의 장점
1. 개발 시간 단축, 고품질의 소프트웨어 생산
2. 수월한 의사소통
3. 용이한 유지보수
4. 검증된 아키텍처
5. 구축 전 시스템 특성에 대한 시뮬레이션 가능
6. 기존 시스템에 대한 빠른 이해
아키텍처 스타일의 기능
1. 소프트웨어 시스템의 구조를 체계적으로 구성하기 위해 기본 스키마를 제시
2. 미리 정의된 서브시스템 제공
3. 각 아키텍처 패턴 간의 책임 명시
4. 패턴 간의 관계를 조직화하는 규칙, 가이드라인 제시
5. 문제를 소프트웨어 모듈 단위로 분해하는 방법 제시
6. 분해한 소프트웨어 모듈 단위가 상호작용하는 방법 제시
데이터 중심형 모델(저장소 모델):
1. 주요 데이터가 저장소에서 중앙 관리
2. 구성:
-저장소: 공동으로 활용하는 데이터 보관
-서브시스템: 저장소에 접근하여 정보를 저장, 검색, 변경하는 역할
3. 유용한 경우
-장기간 저장되야 하는 대량의 정보를 생성하는 시스템을 가지고 있을 때
-저장소에 데이터가 추가되면 어떤 행동이나 도구의 동작이 필요한 시스템 등에 적용된다.
4. 장점
-데이터가 한군데에 모여 있기 때문에 데이터를 모순되지 않고 일관성 있게 관리 가능
-새로운 서브시스템의 추가 용이
5. 단점
-저장소의 병목 현상 발생 가능
-서브시스템과 저장소 사이의 강한 결합 -> 저장소 변경 시 서브시스템에 영향을 줌
Client-server 모델
1. 네트워크를 이용하는 분산 시스템 형태
2. 유용한 경우
-데이터와 처리 기능을 클라이언트와 서버에 분할해 사용
-공유 데이터를 여러 지역에서 접근해야 할때
3. 장점
-서버가 네트워크 상에 분산될 수 있음
-분리와 독립
4. 단점
-각 서비스가 단일 장애점. 서비스 거부 공격(Dos)에 민감
-시스템 뿐 아니라 네트워크에 의해 성능이 영향 받음
-서버를 서로 다른 기관에서 소유한다면 관리 문제 발생 가능
계층모델
1. 기능을 몇개의 계층으로 나누어 배치. 각 계층은 관련된 기능 수행
2. 각 계층은 상위 계층에 서비스 제공. 가장 아래 계층은 시스템 전체에 사용되는 핵심 서비스
3. 프로토콜을 통해 계층간 통신
4. 유용한 경우
-새로운 기능을 기존 시스템 위에 구축할떄
-각 팀이 기능 계층에 대한 책임이 있을 때
-다중 수준 보안이 필요할 때
5. 장점
- 인터페이스가 유지 된다면 전체 계층을 대체하는 것이 가능
6. 단점
-현실적으로 계층을 명확히 분리하는 것이 어려울 수 있다
-상위 수준 계층이 바로 아래 계층을 통하지 않고 하위 수준 계층과 직접 상호작용 해야할 수 있다.
MVC 모델
1. 중앙 데이터 구종
2. 같은 모델의 서브시스템에 대해 여러 뷰 서브시스템을 필요로 하는 시스템에 적합하다
3. 세 개의 서브시스템으로 분리하는 이유:
변경에 대한 영향을 덜 미치도록 하기 위해. 즉 ,UI부분이 자주 변해도 모델 서브시스템에는 영향을 주지 않기 위해
4. 구조
4.1 Model 서브시스템
-뷰/제어 서브시스템과 독립되어 모든 데이터 상태와 로직을 처리
-특정 입, 출력 방식에 영향을 받지 않고, 무언가의 호출에 응답만 함
4.2 View 서브시스템
-사용자와 직접 대화가 이루어지는 부분으로 데이터를 사용자에세 보여주는 역할
4.3 Controller 서브시스템
-뷰를 통한 사용자의 요청을 적절한 모델 쪽으로 넘겨주고, 모델로 부터 받은 응답을 다시 뷰를 통해 사용자에세 돌려주는 역할
5. 장점
-관심의 분리
-데이터를 화면에 표현하는 디자인과 로직을 분리함 으로써 느슨한 결합 가능
-구조 변경 요청 시 수정 용이
6. 단점
-기본 기능 설계로 인한 클래스 수의 증가로 복잡도 증가
-속도가 중요한 프로젝트에 부적합
데이터 흐름 모델
1. Pipe and filter 구조
-Filter: data stream을 한 개 이상 입력받아 처리한 후 data stream 하나를 출력
-pipe: filter를 거쳐 생성된 data stream하나는 다른 filter의 입력에 연결
2. 유용한 경우
-사용자의 개입없이 데이터의 흐름이 전환되는 경우
-사용자의 상호작용이 제한된 일관처리 시스템, 임베디드 시스템에 적합
3. 장점
-이해하기 쉽고 재사용 지원
-변환을 추가하여 기능을 변경하는 것이 명료
-순차적 또는 병행 시스템으로 구현 가능
4. 단점
-데이터를 주고 받는 각 변환이 시스템 부담을 증가시킬 수 있음
아키텍처 문서의 내용
1. 목적
-문서가 기술하는 대상 시스템이 무엇인지 기술
-설계가 다루고 있는 요구 사항에 대한 참고문헌을 소개
2. 우선순위
-설계 작업 과정을 설명할 우선순위를 기술
3. 설계의 아웃라인
-개괄적인 소개를 하기 위해 최상위로 추상화된 설계를 제시
4. 주요 설계 이슈
-해결되어야 할 중요한 이슈
-고려해야 할 다른 대안이나 최종 결정, 결정 이유 등을 기술
5. 설계 상세 사항
-아직 언급되지 않은 것 중 독자가 꼭 알아야 할 사항 기술
-통신 프로토콜, 자료 구조와 알고리즘, API사용법 등