Top

(개정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부에서는 몇 가지 뜨고 있는 기술과 이들 기술과 아키텍처의 관련성에 대해 논의한다.

저자/역자 소개

지은이의 말

이 책의 개정2판이 출간된 이후로 10년이 지났다. 이 시간 동안에 소프트웨어 아키텍처 분야는 기본적으로 내부적인 지향성(소프트웨어를 어떻게 설계하고 평가하며 문서화하는가?)뿐만 아니라 외부적인 영향(아키텍처에 대한 더 깊은 이해와 아키텍처가 라이프사이클, 조직, 관리에 미치는 영향의 대한 더 깊은 이해(?))을 포함하도록 초점이 확장되었다.
또한 과거 10년 동안 구축된 시스템의 유형이 극적으로 변화되었다. 대용량 데이터, 소셜 미디어, 클라우드는 10년 전에는 기껏해야 초보적이었지만, 지금은 성숙되었을 뿐만 아니라 커다란 영향력을 갖고 있다.
우리는 이전 판에서의 몇 가지 비판을 듣고 패턴에 대한 좀 더 많은 자료를 포함했으며, 품질 속성에 대한 자료를 재구성하고, 품질 속성의 상호운영성을 하나의 장에 할애했다. 또한 여러분이 선호하는 품질 속성에 대한 시나리오와 전술을 생성할 수 있는 방법에 대한 가이드도 제공한다.
새로운 많은 자료를 수용하기 위해 우리는 어려운 선택을 해야 했다. 특별히 이번 개정3판에서는 이전 판에서 있었던 확장된 사례 연구를 넣지 않았다. 또한 이러한 결정은 소프트웨어 아키텍처에서 선택할 수 있는 사례 연구가 과거 10년보다는 훨씬 더 많아졌다는 점에서, 그리고 소프트웨어 아키텍처의 중요성에 대해 이제는 그다지 강조하지 않아도 된다는 점에서 이 분야가 그만큼 성숙했음을 반영한다. 그러나 이전 두 판에 있었던 사례 연구는 이 책의 웹 사이트(http://www.informit.com/store/software-architecture-inpractice-9780321815736)에서 찾을 수 있다. 이 웹 사이트에는 프리젠테이션 슬라이드도 포함되어 있다.
이번 개정3판에서 다룬 많은 주제들은 완전히 다시 작성되었다. 특별히 우리가 제시한 방법론(아키텍처 설계, 분석 및 문서화)이 특별한 목적을 달성하는 방법에 관한 하나의 버전이지만, 다른 것도 있다는 것을 인식했다. 따라서 우리는 이들의 기반이 되는 이론으로부터 세부적인 사항을 제시하는 방법론을 분리했다. 이제 우리는 이론의 가능한 실현을 예로 제공하는 구체적인 방법론으로 먼저 이론을 제시한다. 이번 개정판의 새로운 주제에는 아키텍처 중심적인 프로젝트 관리, 아키텍처 역량, 요구 모델링과 분석, 애자일 방법론, 구현과 테스팅, 클라우드, 엣지가 포함된다.
이전 판에서와 마찬가지로 주제들이 스터디 그룹이나 강의실에서 많이 논의된다고 강하게 믿고 있으므로, 각 장의 끝에 토론할 질문들을 포함시켰다. 이들 대부분의 토론 질문들은 개방적이기 때문에 절대적인 옳고 그른 답이 없다. 따라서 독자로서 여러분은 질문 그 자체에 대해 단순히 대답을 하기보다는 여러분의 대답의 정당성을 어떻게 주장할 것인가를 강조해야 한다.

지은이 소개

렌 베스(Len Bass)

NICTA(National ICT Australia Ltd) 사의 수석 연구원이다. 2011년에 NICTA에 입사하기 전에 카네기 멜론(Carnegie Mellon) 대학의 SEI(Software Engineering Institute)에서 25년간 재직했다. 『Software Architecture: Views and Beyond, Second edition』(Addison-Wesley, 2011)을 포함하여 2권의 수상 경력을 보유한 책의 공동 저자이며, 컴퓨터 과학과 소프트웨어 공학에 관련된 다양한 주제에 관한 여러 권의 책과 다수의 논문이 있다. 과학 분석 시스템, 임베드 시스템과 정보 시스템과 같은 여러 도메인에서 소프트웨어 개발과 연구를 50년간 해왔다.

폴 클레멘츠(Paul Clements)

빅레버 소프트웨어(BigLever Software) 사의 Customer Success 부사장으로, 시스템과 소프트웨어 제품 라인 엔지니어링의 채택을 확산시키는 일을 하고 있다. 이전에는 SEI에서 기술 분야의 수석 연구원으로서 17년 동안 소프트웨어 제품 라인과 소프트웨어 아키텍처 문서화와 분석 분야의 프로젝트를 이끌었다. 『Software Architecture: Views and Beyond, Second edition』(Addison-Wesley, 2011)의 공동 저자이며, 『Evaluating Software Architectures: Methods and Case Studies』(Addion-Wesley, 2002)(번역서: 『소프트웨어 아키텍처 평가』(에이콘, 2009)), 『Software Product Lines: Practices and Patterns』(Addison-Wesley, 2002) 등을 집필했다. 이와 함께 소프트웨어 시스템의 설계와 명세에 대한 오래된 관심사를 반영하는 수십 편의 소프트웨어 엔지니어링 논문을 출판했다.

릭 캐즈먼(Rick Kazman)

하와이(Hawaii) 대학의 교수이며, SEI 외래 연구원(그리고 전 기술 분야 수석 연구원)이다. 『Evaluating Software Architectures: Methods and Case Studies』(Addion-Wesley, 2002)의 공동 저자이며, 100편이 넘는 기술 논문의 저자다. 주요 연구 분야는 소프트웨어 아키텍처 설계와 분석, 소프트웨어 시각화 및 소프트웨어 엔지니어링 경제학이다. SAAM(Software Architecture Analysis Method), ATAM(Architecture Tradeoff Analysis Method), CBAM(Cost-Benefit Analysis Method), 그리고 Dali 아키텍처 역공학 도구를 포함하는 여러 영향력이 높은 아키텍처 분석 방법론과 도구를 만들었다.

옮긴이의 말

나의 30년 가까운 소프트웨어 개발 경험 속에서 갖고 있는 하나의 신념은 ‘아키텍처가 튼튼한 시스템이 결국엔 성공한다’는 것이다. 아키텍처가 튼튼한 시스템은 결합성이 적고 응집력이 강한 시스템이다. 이처럼 튼튼하게 아키텍처가 설계된 시스템을 구현하는 것은 결코 실패하지 않으며, 적어도 문제를 최소화할 수 있다. 업무 로직이 변경되는 경우라도 쉽게 대응할 수 있어 생명력이 긴 소프트웨어 시스템을 만들어낼 수 있다. 이러한 신념은 이 책의 2판을 읽고 나서 더욱 커졌다. 그 이후로 내가 집필한 『CBD, What & How』(와우북스, 2008)와 『SOA, What & How』(와우북스, 2008)에서 각각 제시한 CBD와 SOA 방법론은 모두 튼튼한 아키텍처 설계를 강조하고 있다.
이 책은 2판에 비해 더 체계적인 내용을 담고 있다. 이 책의 핵심 개념인 품질 속성에 대해 좀 더 상세하고 체계적인 설명을 담고 있으며, 소프트웨어 개발 라이프사이클에서 아키텍처의 역할과 해야 할 일에 대해 체계적으로 설명한다. 특별히 애자일 접근 방법에서의 아키텍처의 역할을 설명한 장은 애자일 실천자들이 반드시 이해해야 할 좋은 내용을 담고 있다.
개발자들을 위해 이 책을 해설하는 가칭 『개발자를 위한 소프트웨어 아키텍처 해설』을 집필하고 있던 중에 출판사로부터 이 책의 번역을 의뢰받았다. 이 책의 번역본이 빨리 출간되었으면 하는 바람을 갖고 있던 터라 흔쾌히 수락하고 번역에 착수했다. 이 책의 번역이 어쩌면 내 인생에서 가장 힘들고 보람된 작업이 아니었나 싶다. 이미 이 책을 읽으면서 정리해둔 것이 있어서 가능한 일이었긴 하지만, 그래도 평균적으로 하루 20쪽 이상을 번역하는 작업이 그렇게 녹록한 일은 아니었다. 하지만 덕분에 꼼꼼히 이 책을 처음부터 끝까지 빠짐없이 읽을 수 있었기에 더할 나위 없이 보람된 작업이었다.
이미 여러 책을 집필하고 번역했기 때문에 책을 쓰고 번역하는 일이 낯설지 않았지만, 그래도 이 책을 번역하면서 어려움이 많았다. 사실 이 책이 소프트웨어 공학을 공부하는 사람들에게는 교과서와 같은 책이어서, 실무뿐만 아니라 학문적으로도 손색이 없도록 번역해야 한다는 부담감이 있었다. 그럼에도 불구하고 아무래도 이 책을 번역할 때 실무자를 향해 있음을 부인할 수는 없다. 이 책의 번역 용어는 가능한 한 실무를 반영해 선택했으며, 옮긴이 주석은 이 책을 읽는 데 이해하기 쉽도록 도움을 주는 정도로만 한정했다. 실무의 개발자들에게 좀 더 쉬운 해설을 제공하기 위해 향후 『개발자를 위한 소프트웨어 아키텍처 해설』 책을 집필할 계획이다.
이 책의 번역을 의뢰해주신 에이콘출판사에 감사드리며, 오타와 껄끄러운 문맥을 다듬느라 고생하신 편집부의 노고에 감사드린다. 이 번역본이 튼튼한 아키텍처를 갖춘 시스템을 구축하는 데 조금이라도 도움이 되었으면 한다.

옮긴이 소개

전병선(IT 아키텍트/컨설턴트)

20년 이상의 실무 개발 경험을 바탕으로 CBD, SOA, BPM 분야의 아키텍처 설계와 컨설팅을 수행하고 있으며, 20권 이상의 많은 저서를 출간한 베스트 셀러 저자다. 최근에는 다시 개발자로서 직접 실무 개발에 참여하고 있으며 .NET과 자바 개발 기술을 리딩하고 있다.
IT 기술 분야의 저자로서 1993년부터 C, C++, Visual C++, 객체지향, UML, CBD, SOA 분야의 20권 이상의 많은 베스트 셀러 TI 서적을 저술했으며 폭넓은 독자층을 갖고 있다.
94년 이후 전문 IT 기술 강사로서 정보기술연구소, 다우데이터시스템, 소프트뱅크코리아, 데브피아, 웹타임, 삼성SDS멀티캠퍼스에서 강의했으며, 96, 97년에는 마이크로소프트의 초대 리저널 디렉터로서 DevDays, TechEd, PDC 등의 여러 컨퍼런스에서 강연했다.
금융, 제조, 조선, 통신, 정부 연구기관 등 다양한 도메인 분야에서 아키텍트이자 PM으로 참여했다. 삼성전자 홈네트워크 솔루션 아키텍처 구축, STX조선 생산계획 시스템, 대우조선 DIPS시스템, 삼성생명 비전속영업관리 시스템 등 CBD 또는 Real-Time & Embedded를 기반으로 하는 다양한 프로젝트를 컨설팅했다.
또한 SOA 전문가로서 거번먼트 2.0, KRNet 2010 등 각종 SOA 세미나와 강연회를 가졌으며, 조달청 차세대 통합 국가전자조달시스템 구축 사업 서비스 모델링과 KT N-STEP SOA 진단 컨설팅했고, KT의 NeOSS 시스템 구축, 암웨이의 AUS 시스템, 대우조선의 SOA기반 종합 계획 EA 프로젝트 등의 SOA 관련 프로젝트들을 수행했다.

목차

목차
  • 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.100 아래에서 3행 : '몇일'동안 -> 며칠동안

정오표

정오표

[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행]
바램
->
바람