이미 소장하고 있다면 판매해 보세요.
|
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장 에필로그 |
|
★ 이 책에서 다루는 내용 ★
- 소프트웨어 아키텍처 컨텍스트: 기술적, 프로젝트, 비즈니스, 전문성 - 아키텍처 역량: 개인과 조직에게 아키텍처가 의미하는 것 - 비즈니스 목표의 근원과 이것이 아키텍처에 미치는 영향 - 아키텍처적으로 중요한 요구와 이들을 결정하는 방법 - 라이프사이클에서의 아키텍처: 설계 철학으로서 생성과 테스트, 구현 단계에서의 아키텍처 준수, 아키텍처와 테스팅, 아키텍처와 애자일 개발 - 아키텍처와 현재 기술: 클라우드, 소셜 네트워킹, 최종 사용자 디바이스 ★ 이 책의 대상 독자 ★ 소프트웨어 공학에 지식과 경험이 있는 소프트웨어 전문가나 학생을 대상으로 한다. - 아키텍처에 대한 기술적인 배경과 함께 거기에 작용하는 업무적, 조직적 상황과 요구사항, 영향력에 대해 이해하고자 하는 소프트웨어 공학 교육생 - 소프트웨어 아키텍처를 통해 시스템 구축 업무를 좀더 효과적으로 감독하고 조직을 개선시킬 수 있는 방법을 배우고자 하는 기술 관리자들 - 학부나 대학원의 소프트웨어 공학 과정에서 이 책을 학습 자료로 활용하고자 하는 전산과나 소프트웨어 공학과 학생 ★ 이 책의 구성 ★ 이 책은 5개 부로 구성된다. 1부는 아키텍처와 아키텍처를 들여다보는 다양한 컨텍스트적인 렌즈에 대해 개관한다. 이들 컨텍스트는 다음과 같다. - 기술적(technical): 시스템에서 소프트웨어 아키텍처의 기술적인 역할은 무엇인가? - 프로젝트 라이프사이클(project lifecycle): 소프트웨어 아키텍처는 소프트웨어 개발 라이프사이클의 어떤 단계와 관련을 갖는가? - 비즈니스(business): 소프트웨어 아키텍처가 조직의 비즈니스 환경에 어떤 영향을 미치는가? - 전문성(professional): 조직이나 개발 프로젝트에서 소프트웨어 아키텍트의 역할은 무엇인가? 2부에서는 기술적인 배경에 집중한다. 2부는 결정이 이루어지는 방법을 설명한다. 결정은 시스템의 바람직한 품질 속성을 기반으로 한다. 5장에서 11장까지는 7개의 품질 속성과 이들을 달성하는 데 사용되는 기법을 설명한다. 7개의 품질 속성은 가용성, 상호운영성, 변경용 이성, 성능, 보안, 테스트 용이성, 사용편의성이다. 12장은 7개 품질 속성에 다른 품질 속성을 추가하는 방법을 설명하며, 13장은 패턴과 전술을 논의하고, 14장은 가능한 다양한 유형의 모델링과 분석을 논의한다. 3부는 소프트웨어 아키텍처가 라이프사이클의 다른 부분과 관련된 사항을 다룬다. 특별히 애자일 프로젝트에서 아키텍처가 어떻게 사용되는지를 설명한다. 라이프사이클의 다른 관점 즉, 요구와 설계, 구현 및 테스팅, 재구성과 순응, 평가를 개별적으로 논의한다. 4부에서는 경제적인 관점과 조직적인 관점, 그리고 일련의 유사한 시스템을 구축하는 관점에서의 아키텍팅 작업을 다룬다. 5부에서는 몇 가지 뜨고 있는 기술과 이들 기술과 아키텍처의 관련성에 대해 논의한다. ★ 지은이의 말 ★ 이 책의 개정2판이 출간된 이후로 10년이 지났다. 이 시간 동안에 소프트웨어 아키텍처 분야는 기본적으로 내부적인 지향성(소프트웨어를 어떻게 설계하고 평가하며 문서화하는가?)뿐만 아니라 외부적인 영향(아키텍처에 대한 더 깊은 이해와 아키텍처가 라이프사이클, 조직, 관리에 미치는 영향의 대한 더 깊은 이해(?))을 포함하도록 초점이 확장되었다. 또한 과거 10년 동안 구축된 시스템의 유형이 극적으로 변화되었다. 대용량 데이터, 소셜 미디어, 클라우드는 10년 전에는 기껏해야 초보적이었지만, 지금은 성숙되었을 뿐만 아니라 커다란 영향력을 갖고 있다. 우리는 이전 판에서의 몇 가지 비판을 듣고 패턴에 대한 좀 더 많은 자료를 포함했으며, 품질 속성에 대한 자료를 재구성하고, 품질 속성의 상호운영성을 하나의 장에 할애했다. 또한 여러분이 선호하는 품질 속성에 대한 시나리오와 전술을 생성할 수 있는 방법에 대한 가이드도 제공한다. 새로운 많은 자료를 수용하기 위해 우리는 어려운 선택을 해야 했다. 특별히 이번 개정3판에서는 이전 판에서 있었던 확장된 사례 연구를 넣지 않았다. 또한 이러한 결정은 소프트웨어 아키텍처에서 선택할 수 있는 사례 연구가 과거 10년보다는 훨씬 더 많아졌다는 점에서, 그리고 소프트웨어 아키텍처의 중요성에 대해 이제는 그다지 강조하지 않아도 된다는 점에서 이 분야가 그만큼 성숙했음을 반영한다. 그러나 이전 두 판에 있었던 사례 연구는 이 책의 웹사이트(http://www.informit.com/store/software-architecture-inpractice-9780321815736)에서 찾을 수 있다. 이 웹 사이트에는 프리젠테이션 슬라이드도 포함되어 있다. 이번 개정3판에서 다룬 많은 주제들은 완전히 다시 작성되었다. 특별히 우리가 제시한 방법론(아키텍처 설계, 분석 및 문서화)이 특별한 목적을 달성하는 방법에 관한 하나의 버전이지만, 다른 것도 있다는 것을 인식했다. 따라서 우리는 이들의 기반이 되는 이론으로부터 세부적인 사항을 제시하는 방법론을 분리했다. 이제 우리는 이론의 가능한 실현을 예로 제공하는 구체적인 방법론으로 먼저 이론을 제시한다. 이번 개정판의 새로운 주제에는 아키텍처 중심적인 프로젝트 관리, 아키텍처 역량, 요구 모델링과 분석, 애자일 방법론, 구현과 테스팅, 클라우드, 엣지가 포함된다. 이전 판에서와 마찬가지로 주제들이 스터디 그룹이나 강의실에서 많이 논의된다고 강하게 믿고 있으므로, 각 장의 끝에 토론할 질문들을 포함시켰다. 이들 대부분의 토론 질문들은 개방적이기 때문에 절대적인 옳고 그른 답이 없다. 따라서 독자로서 여러분은 질문 그 자체에 대해 단순히 대답을 하기보다는 여러분의 대답의 정당성을 어떻게 주장할 것인가를 강조해야 한다. ★ 옮긴이의 말 ★ 나의 30년 가까운 소프트웨어 개발 경험 속에서 갖고 있는 하나의 신념은 ‘아키텍처가 튼튼한 시스템이 결국엔 성공한다’는 것이다. 아키텍처가 튼튼한 시스템은 결합성이 적고 응집력이 강한 시스템이다. 이처럼 튼튼하게 아키텍처가 설계된 시스템을 구현하는 것은 결코 실패하지 않으며, 적어도 문제를 최소화할 수 있다. 업무 로직이 변경되는 경우라도 쉽게 대응할 수 있어 생명력이 긴 소프트웨어 시스템을 만들어낼 수 있다. 이러한 신념은 이 책의 2판을 읽고 나서 더욱 커졌다. 그 이후로 내가 집필한 『CBD, What & How』(와우북스, 2008)와 『SOA, What & How』(와우북스, 2008)에서 각각 제시한 CBD와 SOA 방법론은 모두 튼튼한 아키텍처 설계를 강조하고 있다. 이 책은 2판에 비해 더 체계적인 내용을 담고 있다. 이 책의 핵심 개념인 품질 속성에 대해 좀 더 상세하고 체계적인 설명을 담고 있으며, 소프트웨어 개발 라이프사이클에서 아키텍처의 역할과 해야 할 일에 대해 체계적으로 설명한다. 특별히 애자일 접근 방법에서의 아키텍처의 역할을 설명한 장은 애자일 실천자들이 반드시 이해해야 할 좋은 내용을 담고 있다. 개발자들을 위해 이 책을 해설하는 가칭 『개발자를 위한 소프트웨어 아키텍처 해설』을 집필하고 있던 중에 출판사로부터 이 책의 번역을 의뢰받았다. 이 책의 번역본이 빨리 출간되었으면 하는 바람을 갖고 있던 터라 흔쾌히 수락하고 번역에 착수했다. 이 책의 번역이 어쩌면 내 인생에서 가장 힘들고 보람된 작업이 아니었나 싶다. 이미 이 책을 읽으면서 정리해둔 것이 있어서 가능한 일이었긴 하지만, 그래도 평균적으로 하루 20쪽 이상을 번역하는 작업이 그렇게 녹록한 일은 아니었다. 하지만 덕분에 꼼꼼히 이 책을 처음부터 끝까지 빠짐없이 읽을 수 있었기에 더할 나위 없이 보람된 작업이었다. 이미 여러 책을 집필하고 번역했기 때문에 책을 쓰고 번역하는 일이 낯설지 않았지만, 그래도 이 책을 번역하면서 어려움이 많았다. 사실 이 책이 소프트웨어 공학을 공부하는 사람들에게는 교과서와 같은 책이어서, 실무뿐만 아니라 학문적으로도 손색이 없도록 번역해야 한다는 부담감이 있었다. 그럼에도 불구하고 아무래도 이 책을 번역할 때 실무자를 향해 있음을 부인할 수는 없다. 이 책의 번역 용어는 가능한 한 실무를 반영해 선택했으며, 옮긴이 주석은 이 책을 읽는 데 이해하기 쉽도록 도움을 주는 정도로만 한정했다. 실무의 개발자들에게 좀 더 쉬운 해설을 제공하기 위해 향후 『개발자를 위한 소프트웨어 아키텍처 해설』 책을 집필할 계획이다. 이 책의 번역을 의뢰해주신 에이콘출판사에 감사드리며, 오타와 껄끄러운 문맥을 다듬느라 고생하신 편집부의 노고에 감사드린다. 이 번역본이 튼튼한 아키텍처를 갖춘 시스템을 구축하는 데 조금이라도 도움이 되었으면 한다. |