(개정3판) 소프트웨어 아키텍처 이론과 실제
- 원서명Software Architecture in Practice (3rd Edition) (ISBN 9780321815736)
- 지은이렌 베스(Len Bass), 폴 클레멘츠(Paul Clements), 릭 캐즈먼(Rick Kazman)
- 옮긴이전병선
- ISBN : 9788960777507
- 45,000원
- 2015년 08월 28일 펴냄
- 페이퍼백 | 648쪽 | 188*250mm
- 시리즈 : 소프트웨어 아키텍처
판매처
개정판책 소개
요약
소프트웨어 아키텍트가 되고자 하는 사람과 이미 소프트웨어 아키텍트로서 역할을 수행 중인 사람 모두가 읽어야 하는 소프트웨어 아키텍처 교과서다. 2판이 출간된 이후로 10여 년 동안 소프트웨어 분야의 발전을 반영하여 이번 3판은 전면 개정되었다. 소프트웨어 아키텍처의 이론적 기반을 좀 더 견고하게 설명하고 있으며, 실무 적용 사례는 좀 더 이해하기 쉽게 제시했다. 대규모 시스템의 소프트웨어 아키텍처 설계와 분석은 물론이고, 특별히 애자일 방식의 시스템을 개발할 때 소프트웨어 아키텍처의 역할과 적용에 대해서도 명확하게 설명한다.
이 책에서 다루는 내용
■ 소프트웨어 아키텍처 컨텍스트: 기술적, 프로젝트, 비즈니스, 전문성
■ 아키텍처 역량: 개인과 조직에게 아키텍처가 의미하는 것
■ 비즈니스 목표의 근원과 이것이 아키텍처에 미치는 영향
■ 아키텍처적으로 중요한 요구와 이들을 결정하는 방법
■ 라이프사이클에서의 아키텍처: 설계 철학으로서 생성과 테스트, 구현 단계에서의 아키텍처 준수, 아키텍처와 테스팅, 아키텍처와 애자일 개발
■ 아키텍처와 현재 기술: 클라우드, 소셜 네트워킹, 최종 사용자 디바이스
이 책의 대상 독자
소프트웨어 공학에 지식과 경험이 있는 소프트웨어 전문가나 학생을 대상으로 한다.
■ 아키텍처에 대한 기술적인 배경과 함께 거기에 작용하는 업무적, 조직적 상황과 요구사항, 영향력에 대해 이해하고자 하는 소프트웨어 공학 교육생
■ 소프트웨어 아키텍처를 통해 시스템 구축 업무를 좀더 효과적으로 감독하고 조직을 개선시킬 수 있는 방법을 배우고자 하는 기술 관리자들
■ 학부나 대학원의 소프트웨어 공학 과정에서 이 책을 학습 자료로 활용하고자 하는 전산과나 소프트웨어 공학과 학생
이 책의 구성
이 책은 5개 부로 구성된다.
1부는 아키텍처와 아키텍처를 들여다보는 다양한 컨텍스트적인 렌즈에 대해 개관한다. 이들 컨텍스트는 다음과 같다.
• 기술적(technical): 시스템에서 소프트웨어 아키텍처의 기술적인 역할은 무엇인가?
• 프로젝트 라이프사이클(project lifecycle): 소프트웨어 아키텍처는 소프트웨어 개발 라이프사이클의 어떤 단계와 관련을 갖는가?
• 비즈니스(business): 소프트웨어 아키텍처가 조직의 비즈니스 환경에 어떤 영향을 미치는가?
• 전문성(professional): 조직이나 개발 프로젝트에서 소프트웨어 아키텍트의 역할은 무엇인가?
2부에서는 기술적인 배경에 집중한다. 2부는 결정이 이루어지는 방법을 설명한다. 결정은 시스템의 바람직한 품질 속성을 기반으로 한다. 5장에서 11장까지는 7개의 품질 속성과 이들을 달성하는 데 사용되는 기법을 설명한다. 7개의 품질 속성은 가용성, 상호운영성, 변경용 이성, 성능, 보안, 테스트 용이성, 사용편의성이다. 12장은 7개 품질 속성에 다른 품질 속성을 추가하는 방법을 설명하며, 13장은 패턴과 전술을 논의하고, 14장은 가능한 다양한 유형의 모델링과 분석을 논의한다.
3부는 소프트웨어 아키텍처가 라이프사이클의 다른 부분과 관련된 사항을 다룬다. 특별히 애자일 프로젝트에서 아키텍처가 어떻게 사용되는지를 설명한다. 라이프사이클의 다른 관점 즉, 요구와 설계, 구현 및 테스팅, 재구성과 순응, 평가를 개별적으로 논의한다.
4부에서는 경제적인 관점과 조직적인 관점, 그리고 일련의 유사한 시스템을 구축하는 관점에서의 아키텍팅 작업을 다룬다.
5부에서는 몇 가지 뜨고 있는 기술과 이들 기술과 아키텍처의 관련성에 대해 논의한다.
목차
목차
- 1부 개요
- 1장. 소프트웨어 아키텍처의 의미
- 1.1 무엇이 소프트웨어 아키텍처이고, 무엇이 아닌가?
- 1.2 아키텍처 구조와 뷰
- 1.3 아키텍처 패턴
- 1.4 좋은 아키텍처를 만드는 법
- 1.5 정리
- 1.6 참고 문헌
- 1.7 생각해볼 문제
- 2장. 소프트웨어 아키텍처가 중요한 이유
- 2.1 시스템의 품질 속성 억제 또는 가능
- 2.2 변경 근거와 관리
- 2.3 시스템 품질 예측
- 2.4 이해당사자 의사소통 향상
- 2.5 초기 설계 결정 수용
- 2.6 구현 제약사항 정의
- 2.7 조직 구조 영향
- 2.8 발전적 프로토타이핑
- 2.9 비용과 일정 산정 향상
- 2.10 이전 가능한 재사용모델 공급
- 2.11 독립적으로 개발된 컴포넌트 통합 허용
- 2.12 설계 선택 대상 제한
- 2.13 훈련 기초 제공
- 2.14 정리
- 2.15 참고 문헌
- 2.16 생각해볼 문제
- 3장. 소프트웨어 아키텍처 컨텍스트
- 3.1 기술적 컨텍스트에서의 아키텍처
- 3.2 프로젝트 라이프사이클 컨텍스트에서의 아키텍처
- 3.3 비즈니스 컨텍스트에서의 아키텍처
- 3.4 전문성 컨텍스트에서의 아키텍처
- 3.5 이해당사자
- 3.6 아키텍처는 어떻게 영향을 받는가
- 3.7 아키텍처가 무엇에게 영향을 주는가
- 3.8 정리
- 3.9 참고 문헌
- 3.10 생각해볼 문제
- 2부 품질 속성
- 4장. 품질 속성의 이해
- 4.1 아키텍처와 요구
- 4.2 기능성
- 4.3 품질 속성 고려사항
- 4.4 품질 속성 요구 명세
- 4.5 전술을 통한 품질 속성 달성
- 4.6 품질 설계 결정 가이드
- 4.7 정리
- 4.8 참고 문헌
- 4.9 생각해볼 문제
- 5장. 가용성
- 5.1 가용성 일반 시나리오
- 5.2 가용성 전술
- 5.3 가용성 설계 체크리스트
- 5.4 정리
- 5.5 참고 문헌
- 5.6 생각해볼 문제
- 6장. 상호운영성
- 6.1 상호운영성 일반 시나리오
- 6.2 상호운영성 전술
- 6.3 상호운영성 설계 체크리스트
- 6.4 정리
- 6.5 참고 문헌
- 6.6 생각해볼 문제
- 7장. 변경용이성
- 7.1 변경용이성 일반 시나리오
- 7.2 변경용이성 전술
- 7.3 변경용이성 설계 체크리스트
- 7.4 정리
- 7.5 참고 문헌
- 7.6 생각해볼 문제
- 8장. 성능
- 8.1 성능 일반 시나리오
- 8.2 성능 전술
- 8.3 성능 설계 체크리스트
- 8.4 정리
- 8.5 참고 문헌
- 8.6 생각해볼 문제
- 9장. 보안
- 9.1 보안 일반 시나리오
- 9.2 보안 전술
- 9.3 보안 설계 체크리스트
- 9.4 정리
- 9.5 참고 문헌
- 9.6 생각해볼 문제
- 10장. 테스트 용이성
- 10.1 테스트 용이성 일반 시나리오
- 10.2 테스트 용이성 전술
- 10.3 테스트 용이성 설계 체크리스트
- 10.4 정리
- 10.5 참고 문헌
- 10.6 생각해볼 문제
- 11장. 사용편의성
- 11.1 사용편의성 일반 시나리오
- 11.2 사용편의성 전술
- 11.3 사용편의성 설계 체크리스트
- 11.4 정리
- 11.5 참고 문헌
- 11.6 생각해볼 문제
- 12장. 기타 품질 속성
- 12.1 기타 중요한 품질 속성
- 12.2 기타 품질 속성 카테고리
- 12.3 소프트웨어 품질 속성과 시스템 품질 속성
- 12.4 품질 속성 표준 목록 사용
- 12.5 ‘-성’ 다루기: 새로운 품질 속성 도입
- 12.6 참고 문헌
- 12.7 생각해볼 문제
- 13장. 아키텍처 전술과 패턴
- 13.1 아키텍처 패턴
- 13.2 패턴 목록 개요
- 13.3 전술과 패턴 사이의 관계
- 13.4 전술 종합 사용
- 13.5 정리
- 13.6 참고 문헌
- 13.7 생각해볼 문제
- 14장. 품질 속성 모델링과 분석
- 14.1 품질 속성 분석을 가능하게 하는 아키텍처 모델링
- 14.2 품질 속성 체크리스트
- 14.3 사고 실험과 대략 분석
- 14.4 실험, 시뮬레이션 및 프로토타입
- 14.5 라이프사이클 단계에서의 분석
- 14.6 정리
- 14.7 참고 문헌
- 14.8 생각해볼 문제
- 3부 라이프사이클에서의 아키텍처
- 15장 애자일 프로젝트에서의 아키텍처
- 15.1 어느 정도의 아키텍처일까?
- 15.2 애자일과 아키텍처 방법론
- 15.3 애자일 아키텍팅의 간단한 사례
- 15.4 애자일 아키텍트 가이드라인
- 15.5 정리
- 15.6 참고 문헌
- 15.7 생각해볼 문제
- 16장 아키텍처와 요구
- 16.1 요구 문서로부터 ASR 수집
- 16.2 이해당사자 인터뷰로 ASR 수집
- 16.3 비즈니스 목표 이해에 의한 ASR 수집
- 16.4 유틸리티 트리 ASR 수집
- 16.5 방법론 결합
- 16.6 정리
- 16.7 참고 문헌
- 16.8 생각해볼 문제
- 17장 아키텍처 설계
- 17.1 설계 전략
- 17.2 속성 주도 설계 방법론
- 17.3 ADD 단계
- 17.4 정리
- 17.5 참고 문헌
- 17.6 생각해볼 문제
- 18장 소프트웨어 아키텍처 문서화
- 18.1 아키텍처 문서 사용과 독자
- 18.2 아키텍처 문서 표기법
- 18.3 뷰
- 18.4 뷰 선택
- 18.5 뷰 결합
- 18.6 문서 패키지 구축
- 18.7 행위 문서화
- 18.8 아키텍처 문서와 품질 속성
- 18.9 문서화보다 빨리 변경되는 아키텍처의 문서화
- 18.10 애자일 개발 프로젝트에서 아키텍처 문서화
- 18.11 정리
- 18.12 참고 문헌
- 18.13 생각해볼 문제
- 19장 아키텍처, 구현과 테스팅
- 19.1 아키텍처와 구현
- 19.2 아키텍처와 테스팅
- 19.3 정리
- 19.4 참고 문헌
- 19.5 생각해볼 문제
- 20장 아키텍처 재구성과 순응
- 20.1 아키텍처 재구성 프로세스
- 20.2 원시 뷰 추출
- 20.3 데이터베이스 구축
- 20.4 뷰 융합
- 20.5 아키텍처 분석: 위반 사항 찾기
- 20.6 가이드라인
- 20.7 정리
- 20.8 참고 문헌
- 20.9 생각해볼 문제
- 21장 아키텍처 평가
- 21.1 평가 요인
- 21.2 아키텍처 트레이드오프 분석 방법론
- 21.3 경량 아키텍처 평가
- 21.4 정리
- 21.5 참고 문헌
- 21.6 생각해볼 문제
- 22장 관리와 거버넌스
- 22.1 계획
- 22.2 조직
- 22.3 구현
- 22.4 측정
- 22.5 거버넌스
- 22.6 정리
- 22.7 참고 문헌
- 22.8 생각해볼 문제
- 4부 아키텍처와 비즈니스
- 23장 아키텍처 경제적 분석
- 23.1 의사 결정 배경
- 23.2 경제적 분석 기초
- 23.3 이론에서 실제로: CBAM
- 23.4 사례 연구
- 23.5 정리
- 23.6 참고 문헌
- 23.7 생각해볼 문제
- 24장 아키텍처 역량
- 24.1 개인 역량: 아키텍트의 의무, 기능, 지식
- 24.2 소프트웨어 아키텍처 조직 역량
- 24.3 정리
- 24.4 참고 문헌
- 24.5 생각해볼 문제
- 25장 아키텍처와 소프트웨어 제품 라인
- 25.1 제품 라인 가변성 사례
- 25.2 소프트웨어 제품 라인 작동 원리
- 25.3 제품 라인 범위
- 25.4 가변성 품질 속성
- 25.5 제품 라인 아키텍처의 역할
- 25.6 가변 메커니즘
- 25.7 제품 라인 아키텍처 평가
- 25.8 주요 소프트웨어 제품 라인 이슈
- 25.9 정리
- 25.10 참고 문헌
- 25.11 생각해볼 문제
- 5부 멋진 신세계
- 26장 클라우드 아키텍처
- 26.1 기본적인 클라우드 정의
- 26.2 서비스 모델과 배포 선택
- 26.3 경제적 타당성
- 26.4 기반 메커니즘
- 26.5 기술의 예
- 26.6 클라우드 환경에서의 아키텍팅
- 26.7 정리
- 26.8 참고 문헌
- 26.9 생각해볼 문제
- 27장 엣지 아키텍처
- 27.1 엣지 지배적 시스템의 생태계
- 27.2 소프트웨어 개발 라이프사이클 변화
- 27.3 아키텍처 의미
- 27.4 메트로폴리스 모델 의미
- 27.5 정리
- 27.6 참고 문헌
- 27.7 생각해볼 문제
- 28장 에필로그
도서 오류 신고
정오표
정오표
[p.41: 아래에서 5행]
사용 구조(uses sttructure)
->
사용 구조(uses structure)
[p.45: 12행]
2개의 컴포넌트
->
2개의 모듈
[p.50: 2행]
아키텍처와 개발팀
->
아키텍트와 개발팀
[p.60: 아래에서 9행]
분산 호나경
->
분산 환경
[p. 117: 1행]
MTBF(Mean Time Between Faiure)
->
MTBF(Mean Time Between Failures)
[p. 117: 주석 1번]
결함이 발견된고
->
결함이 발견되고
[p.121: 3행]
짧은 회가
->
짧은 회로가
[p.123: 표 2행 2열의 4행]
작절한 실체
->
적절한 실체
[p.123: 2행]
hearbeat monitor
->
heartbeat monitor
[p.315: 표 14.3]
->
[p.429 : 1행]
발경하고
->
발견하고
[p.432 : 3행]
아키텍터
->
아키텍처
[p.434 :아래에서 9행]
바램
->
바람