-
아키텍처 설계
- 소프트웨어 시스템이 어떻게 구성되어야 하는지?
- 시스템의 전체 구조 설계를 이해하는 것
- 시스템 내 주요 컴포넌트와 그 관계를 식별하는 중요한 연결
- 아키텍처 설계 프로세스를 통해 확인할 수 있는 것
- 시스템이 컴포넌트들 간의 집합으로 어떻게 구성되어 있는지 표현하는 모델
아키텍처 추상화
- 작은 단위의 아키텍처
- 개별 프로그램은 어떻게 구성되어있는지?
- 시스템이 컴포넌트들로 어떻게 구성되었는지?
- 큰 단위의 아키텍처
- 외부 시스템과 컴포넌트를 포함하는 시스템
- 이 시스템이 어떻게 분산되어 있는지?
아키텍처 명시화의 장점
- 이해관계자가 시스템을 이해하는 것에 도움이 된다.
- 비 기능적 요구사항에 대한 시스템 분석에 도움이 된다.
- 대규모 재사용을 통해 새로운 아키텍처 설계에 참고와 시간 단축이 가능하다.
아키텍처 표현
- 비정형적인 단순한 블록 다이어그램으로 엔터티와 관계를 보여주는 방법이 주로 쓰인다.
- 그러나 이는 엔터티 간 관계를 제대로 표현하지 못하고 아키텍처 내부의 속성도 표현할 수 없다.
- 매우 추상적인 다이어그램은 내부적인 자세한 관계에 의미를 두지 않는다.
- 전체적인 관계도를 추상화 한다.
- 이를 통해 비전문가와의 대화에 유용하게 사용할 수 있다.
아키텍처 모델 사용법
- 시스템 설계에 대한 논의 장려
- 상위 수준의 아키텍처 뷰를 통해 단순한 뷰를 구성하여 이해 당사자의 이해를 돕는다.
- 이를 통해 시스템 전체를 논의하고 세부적인 내용에 혼동되지 않는다.
- 설계한 아키텍처 문서화
- 컴포넌트와 인터페이스, 연결을 확인하여 완전한 시스템 모델을 작성할 수 있다.
아키텍처 설계 결정
- 아키텍처 설계는 어떤 시스템을 만드느냐에 따라 달라질 수 있다.
- 그러나 공통적인 결정사항이 존재하고 이는 비기능적 요구사항의 특성에 영향을 미친다.
- 성능 : 시스템의 성능을 보장하기 위해 분산을 최소화한다.
- 보안성 : 인증되지 않는 접근을 차단해야 한다. 따라서 가장 중요한 자산을 가장 안쪽에서 관리한다.
- 안전성 : 데이터의 무결성을 보장해야한다. 따라서 단일 또는 소수의 컴포넌트로 배치해야 한다.
- 가용성 : 시스템의 중단 없이 컴포넌트 교체가 가능해야 한다.
- 유지보수성 : 변경이 용이하도록 세분화 되고 독립적으로 설계되어야 한다.
아키텍처 재사용
- 유사한 도메인은 유사한 아키텍처를 가진다.
- 따라서 유사한 제품은 유사한 어플리케이션 프로덕트 라인에서 만든다.
- 특정 요구사항들에 따라 발생하는 변형들은 별도로 제작한다.
- 시스템 구조는 하나 이상의 아키텍처 패턴(또는 스타일)에 의해 설계 된다.
아키텍처 뷰
- 아키텍처 설계-문서화에 유용한 뷰는 무엇인지?
- 아키텍처 모델을 표현하기 위한 표기법은 무엇인지?
- 각 아키텍처 모델은 한가지의 뷰만을 보여준다.
- 4+1 뷰
- 논리 뷰
- 시스템의 핵심을 객체 또는 객체 클래스를 통해 표현한다.
- 정적 모델 : 클래스 다이어그램
- 동적 모델 : 순차, 상태, 액티비티
- 물리(배치) 뷰
- 시스템이 어떻게 분산되어 설치되고 어떻게 배치되어 동작하는지를 보여준다.
- 프로세스 뷰
- 시스템의 실행 중 프로세스 간 상호작용을 보여준다.
- 동적 모델 : 순차, 상태, 액티비티
- 개발 뷰
- 시스템 개발을 위해 소프트웨어가 어떻게 구성되어 있는지 보여준다.
- 동적 모델 : 순차, 상태, 액티비티
- 유즈케이스 뷰
- 시스템과 사용자의 상호작용을 기능으로써 보여준다.
- 아키텍처 뷰 표현
- UML을 통한 시스템 아키텍처의 설명과 문서화는 논쟁대상이다.
- 시스템 상위 레벨의 추상화에 대해 UML이 적합한지 관점이 다르다.
아키텍처 패턴
- 표현, 공유, 재사용에 관한 것이다.
- 여러 환경에서 테스트된 좋은 설계 사례에 대한 정형화된 설명이다.
- 어떤 상황에서 유용할지 또는 유용하지 않을지에 대한 정보를 포함한다.
- 표나 시각적 묘사로 표현한다.
- MVC 패턴
- 데이터, 표현, 상호작용을 분리한다.
- Model : 시스템 데이터와 데이터에 대한 오퍼레이션을 관리
- View : 사용자에게 데이터가 어떻게 보여지는지 정의
- Controller : 사용자의 상호작용을 뷰와 모델에 전달
- 사용
- 데이터에 대한 상호작용 방법이 여러가지 일 때
- 데이터 표현과 상호작용에 대한 요구사항을 예측할 수 없을 때
- 장점
- 데이터와 데이터 표현과 서로 무관하게 변경 가능하다.
- 단점
- 단순한 모델과 상호작용에서는 코드 복잡도가 문제가 될 수 있다.
- 계층적 아키텍처
- 시스템을 계층의 구성으로 만든다.
- 변경이 필요하다면 해당 계층과 계층에 접근할 인터페이스만 수정해주면 된다.
- 시스템의 점증적 개발을 지원한다.
- 사용
- 기존 시스템 위에 새로운 시스템을 만들 때, 개발팀을 나눌 수 있다.
- 다중 보안이 필요할 때
- 장점
- 인터페이스만 유지되면 전체 계층을 대체할 수 있다.
- 중복된 기능을 지원하여 신뢰도를 향상시킬 수 있다.
- 단점
- 계층의 명확한 구분이 어려울 수 있다.
- 계층 간의 직접적인 통신이 불가능하다.
- 여러 계층을 거치므로 성능 상의 문제가 발생할 수 있다.
- 저장소 아키텍처
- 서브 시스템 간의 데이터 공유는 중앙 데이터베이스를 통해 이루어진다.
- 중앙 저장소는 모든 시스템 컴포넌트에서 접근할 수 있다.
- 사용
- 장점
- 컴포넌트 들이 상호 독립적이다.
- 데이터가 일관성있게 관리된다.
- 단점
- 저장소에 문제가 생기면 전체 시스템에 문제가 발생한다.
- 저장소를 여러 기계로 분산시키는 것이 어려울 수 있다.
- 데이터 사본의 유지가 시스템에 추가 부담을 준다.
- 시스템의 런타임 구성을 보여주지 못한다.
- 클라이언트-서버 아키텍처
- 서버, 클라이언트, 클라이언트-서버 간 네트워크로 이루어진다.
- 사용
- 중앙 데이터베이스를 여러 곳에서 접근해야할 때
- 시스템 부하의 변동이 클 때
- 장점
- 단점
- 서비스 거부 공격에 민감하다.
- 성능이 네트워크 상태에 영향을 받는다.
- 서버의 소유자에 따라 관리 문제가 발생할 수 있다.
- 파이프 필터 아키텍처
- 순차적인 흐름의 아키텍처이다.
- 사용자 상호작용이 제한된 일괄처리 시스템이나 임베디드 시스템에 적합하다.
- 사용
- 장점
- 이해가 쉽고 변환의 재사용을 지원한다.
- 순차-병행 시스템으로 구현할 수 있다.
- 단점
- 데이터간 전송 형식이 일치해야한다.
- 시스템 부담을 증가시키는 데이터 구조를 재사용 할 수없다.
애플리케이션 아키텍처
- 특정 비즈니스나 조직의 요구사항을 만족시키기 위한 것
- 비즈니스 간 공통적인 특성이 존재하고 이 영역에는 공통 어플리케이션을 사용한다.
- 아키텍처 유형
- 데이터 처리 어플리케이션
- 트랜잭션 처리 어플리케이션
- 사용자의 요청과 정보 갱신을 데이터베이스의 트랜잭션에 기반하여 처리한다.
- 트랜잭션은 일관성있고 연속적인 동작이다.
- 사용자의 비동기적 요청이 발생하면 트랜잭션 매니저가 이를 처리한다.
- 사용자의 요청
- 어플리케이션 특화 논리로 요청 처리
- 트랜잭션 매니저에 의해 트랜잭션 생성
- 트랜잭션이 완료되면 어플리케이션 처리 신호를 보냄
- 이벤트 처리 시스템
- 언어 처리 시스템
- 사용자의 의도가 프로그래밍 언어와 같은 형식 언어로 표현된 시스템이다.
트랜잭션 시스템에 대한 예시 : 정보 시스템 아키텍처
- 트랜잭션 기반의 계층적 구조를 보인다.
- 사용자 인터페이스
- 사용자 상호작용
- 정보 조회
- 시스템 데이터베이스
- 웹 기반의 정보 시스템
- 정보와 자원 관리 시스템이 종종 웹 기반의 시스템에 의해 이루어진다.
- 이 시스템은 웹 브라우저를 통해 접근할 수 있도록 구현되어 있다.
- 쇼핑몰 시스템이 대표적인 인터넷 베이스의 자원 관리 시스템이다.
- 서버 구현
- 웹 서버가 사용자 인터페이스를 제공하고 서버와 상호작용 할 수 있도록 한다.
- 어플리케이션 서버가 어플리케이션 특화 논리를 통해 정보 저장소와 조회 요청 등을 처리한다.
- 데이터베이스 서버가 정보를 데이터베이스로 옮기고 트랜잭션 관리를 다룬다.