7-1 아키텍처 설계
- 아키텍처
- 건물의 뼈대 뿐 아니라 특성을 결정짓는 기본 구조
- 아키텍처는 모든 기술 분야에 적용할 수 있고 종류 다양
- 필요성
- 복잡하고 규모가 큰 소프트웨어를 개발
- 잘 정의된 구조의 품질 좋은 소프트웨어 개발
- 대형 프로젝트에서 복합성의 문제 해결하는 방법
- 개발할 소프트웨어의 전체 구조 생각
- 소프트웨어의 구조를 이루는 각 구성 요소를 찾음
- 아키텍처 설계 시 고려 사항
- 모든 이해관계자 사이의 의사소통 도구로 활용
- 구현에 대한 제약 사항(개발 비용, 기간)을 저으이
- 모든 이해관계자의 품질 요구사항 반영
- 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용하도록 설계
- 아키텍처의 특징과 기능
- 아키텍처의 기대 효과
- 소프트웨어의 기본 골격이 만들어져 개발에 참여하는 사람들의 이해의 폭이 넓어지며 구현상의 문제점을 도출
- 소프트웨어 아키텍처를 기반으로 분할 방법 찾고 구조화를 위한 구체적인 방안 생각
- 아키텍처의 기대 효과
- 아키텍처의 품질 속성
- 시스템 품질 속성
- 가용성
- 하드웨어는 가용성을 높이기 위해 이중화 설계
- 변경 용이성
- 변경이 자주 발생하는 SW는 아키텍처를 설계할 때 변경 용이성을 다른 품질 속성보다 우선으로 고려
- 성능
- 어떤 알고리즘을 선택하는지가 중요
- 보안성
- 승인되지 않은 사용을 차단하고 올바른 사용자에게 서비스가 제공될 수 있게 설계
- 사용성
- 시스템의 도움말 기능은 사용자에게 실제 도움을 줄 수 있어야 함
- 사용자 실수에도 오류의 영향을 최소화
- 테스트 용이성
- 테스트 비용을 줄이기 위해서는 아키텍처 설계부터 테스트 고려
- 가용성
- 비즈니스 품질 속성
- 시장 적시성
- 적정한 시기에 소프트웨어를 출시해 경쟁력을 높이는 것
- 비용과 이익
- 비용 절감에 초점을 두면 우선 개발 비용이 적게 드는 효과, 유지보수를 할 떄 비용 증가
- 예상 시스템 수명
- 확장성, 이식성과 같은 아키텍처 품질 속성을 고려
- 목표 시장
- 이식성 충분히 고려
- 시장 적시성
- 아키텍처 품질 속성
- 개념적 무결성
- 세부 구성 요소를 전체 시스템으로 통합하더라도 일관성 유지
- 정확성과 완전성
- 개발 용이성
- 개발 과정 중에도 쉽게 변경할 수 있는 능력
- 개념적 무결성
- 시스템 품질 속성
- 아키텍처 스타일
- 데이터 중심형 스타일
- 데이터가 리포지토리에서 중앙 관리
- 시스템에서 공동 활용 데이터는 리포지토리에서 보관
- 클라이언트-서버 스타일
- 분산 시스템 형태
- 서버, 서비스, 클라이언트로 구성되며 서브시스템이 서비스를 서로 요청하면서 상호작용
- 계층 스타일
- 기능을 몇 개의 계층으로 나누어 배치
- 각 계층의 응집도는 높고 계층 간 결합도는 낮아 재사용 및 유지보수 용이
- 역할 분담 명확
- MVC 스타일
- 모델, 뷰, 제어의 세 부분으로 이루어짐
- 뷰와 모델을 독립적으로 분리해 변경에 대한 영향이 적음
- 약한 결합으로 설계
7-2 클래스 설계원칙
- SOLID
- 단일 책임 원칙
- 클래스 변경해야 하는 이유는 한 개
- 개방 폐쇄의 원칙
- 확장에는 열려 있어야 하고 변경에는 닫혀야 함
- 리스코프 교체의 원칙
- 기반 클래스는 파생 클래스로 대체
- 인터페이스 분리의 원칙
- 구체적 여러 개의 인터페이스가 나음
- 의존 관계 역전의 분칙
- 클라이언트는 추상 클래스에 의존
- 단일 책임 원칙
7-3 디자인 패턴
- 디자인 패턴
- 장점
- 개발자 간의 원활한 의사소통
- 소프트웨어 구조 파악 용이
- 재사용을 통한 개발 시간 단축
- 단점
- 객체지향 설계/구현 위주
- 장점
- GoF의 디자인 패턴
- 쉽게 재사용할 수 있도록 객체지향 개념에 따른 설계만을 패턴으로 지정
- 생성 패턴
- 객체의 인스턴스 과정을 추상화하는 방법
- 프로그램에 유연성을 더해줌
- 추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤
- 구조 패턴
- 클래스나 객체를 조합해 더 큰 구조로 만들 수 있게 해주는 패턴
- 어댑터, 브리지, 컴포지트, 데코레이터, 퍼싸드, 플라이웨이트
- 행동 패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 어떤 태스크, 어던 알고리즘을 어떤 객체에 할당하는 것지 좋은지 정의 패턴
- 책임 연쇄, 커맨드, 인터프리터, 반복자
- 생성 패턴
- 쉽게 재사용할 수 있도록 객체지향 개념에 따른 설계만을 패턴으로 지정
- 아키텍처 패턴 vs 디자인 패턴
- 아키텍처는 디자인보다 상위일 떄 사용
- 아키텍처 : 전체 시스템의 구조를 설계하기 위한 참조 모델
- 디자인 ; 서브시스템에 속하는 컴포넌트들끼리의 관계를 설계하기 위한 참조 모델