상세정보
미리보기
적정 소프트웨어 아키텍처
- 저자
- 조지 페어뱅크스 저/이승범 역
- 출판사
- 한빛미디어
- 출판일
- 2022-05-30
- 등록일
- 2022-09-15
- 파일포맷
- PDF
- 파일크기
- 5MB
- 공급사
- YES24
- 지원기기
-
PC
PHONE
TABLET
웹뷰어
프로그램 수동설치
뷰어프로그램 설치 안내
책소개
소프트웨어 개발자를 위한 실용 가이드
이 책은 소프트웨어 개발을 시작할 때 필요한 실용 가이드북이다. 소프트웨어 아키텍처의 리스크는 무엇인지, 아키텍처 설계 원칙은 어떻게 적용하고 해결하는지, 유관 부서의 실무자를 어떻게 도울 수 있는지 등의 주제를 개발자가 흔히 겪는 경험을 기반으로 풀어냈다. 개발하면서 너무 많은 문서를 작성했거나, 코딩을 시작하기 전에 너무 적게 고민한 적도 있을 것이다. 어느 쪽이든 소프트웨어 개발이 왜 잘못되는지 알 수 있고, 이 책에서 제공하는 해결책이 많은 도움이 될 것이다.
저자소개
소프트웨어 시스템을 구축하는 방법을 배우려고 노력한 결과, 학계와 산업 소프트웨어 개발을 접목할 수 있었다. 저자는 컴퓨터 과학 학위 세트(학사, 석사, 박사)가 있으며 박사는 카네기 멜런 대학교의 소프트웨어 엔지니어링 분야에서 취득했다. 연구한 논문의 주제는 많은 개발자가 직면하는 문제인 ‘소프트웨어 프레임워크’였다. 프레임워크 사용 방법을 설명하려고 ‘design fragments’라는 새로운 사양을 개발했고, 올바르게 사용하는 중인지 확인할 수 있는 이클립스 기반 도구를 구축했다. 데이비드 갈란과 빌 셜리스의 지도를 받았고, 논문심사위원회에는 영광스럽게도 조너선 올드리치와 랄프 존슨이 참여했다.
학업 중에는 이론적인 내용을 배웠으며, 현업에서 실질적인 부분을 더 익힐 수 있었다. 노텔 DMS-100 중앙 사무실 전화 스위치(central office telephone switch), 운전 시뮬레이터(driving simulator)용 통계 분석, TW Telecom의 IT 애플리케이션, 이클립스 IDE용 플러그인, 그리고 웹 스타트업의 모든 코드를 포함한 프로젝트에 소프트웨어 개발자로 참여했다. 아마추어 시스템 관리자로서 리눅스 박스를 만지고, 컴퓨터 LED를 벽장의 미등처럼 사용했으며, 전원 공급 장치를 난방기처럼 사용했다. 그리고 초창기부터 애자일 기법을 지지해왔다. 1996년 몸담았던 부서의 6개월 개발 주기를 2주로 단축했고, 1998년 테스트 주도 개발을 시작했다. 현재 구글의 소프트웨어 엔지니어다. 구글 애드 익스체인지(AdX)를 포함한 다수의 프로젝트에서 테크니컬 리더로 활동 중이다.
목차
CHAPTER 1 개요
_1.1 분할, 지식, 추상화
_1.2 소프트웨어 아키텍처 세 가지 예시
_1.3 되돌아보기
_1.4 관점 이동
_1.5 아키텍처를 아키텍처링하는 아키텍트
_1.6 리스크 주도 소프트웨어 아키텍처
_1.7 애자일 개발자를 위한 아키텍처
_1.8 이 책에 대하여
PART I 리스크 주도 소프트웨어 아키텍처
CHAPTER 2 소프트웨어 아키텍처
_2.1 소프트웨어 아키텍처 개요
_2.2 소프트웨어 아키텍처가 중요한 이유
_2.3 아키텍처가 중요한 상황은?
_2.4 추정 아키텍처
_2.5 소프트웨어 아키텍처 사용법
_2.6 아키텍처 무관 설계
_2.7 아키텍처 집중 설계
_2.8 아키텍처 상향 설계
_2.9 대규모 조직에서의 아키텍처
_2.10 마치며
_2.11 참고 자료
CHAPTER 3 리스크 주도 모델
_3.1 리스크 주도 모델 개요
_3.2 리스크 주도성 자가 진단
_3.3 리스크
_3.4 기법
_3.5 기법 선택 가이드
_3.6 적정한 투자
_3.7 계획 설계와 진화적 설계
_3.8 소프트웨어 개발 프로세스
_3.9 프로세스 변동의 이해
_3.10 리스크 주도 모델과 소프트웨어 프로세스
_3.11 애자일 프로세스에 적용
_3.12 리스크와 아키텍처 리팩터링
_3.13 리스크 주도 모델의 대안
_3.14 마치며
_3.15 참고 자료
CHAPTER 4 예제: 홈 미디어 플레이어
_4.1 팀 커뮤니케이션
_4.2 상용 기성품 컴포넌트 통합
_4.3 메타데이터 일관성
_4.4 마치며
CHAPTER 5 모델링 관련 조언
_5.1 리스크에 집중하기
_5.2 아키텍처 이해
_5.3 아키텍처 기술 배포
_5.4 합리적인 아키텍처 선택
_5.5 지나친 선행 설계 미리 피하기
_5.6 하향식 설계 방지
_5.7 남은 과제
_5.8 기능과 리스크: 예시
PART II 아키텍처 모델링
CHAPTER 6 엔지니어가 사용하는 모델
_6.1 규모와 복잡성에 필요한 추상화
_6.2 통찰력과 지렛대 효과를 제공하는 추상화
_6.3 시스템 품질 추론
_6.4 세부 사항을 제거하는 모델
_6.5 추론을 증폭하는 모델
_6.6 질문이 먼저, 모델은 그다음
_6.7 마치며
_6.8 참고 자료
CHAPTER 7 소프트웨어 아키텍처의 개념 모델
_7.1 정준 모델 구조
_7.2 도메인 모델, 디자인 모델, 코드 모델
_7.3 지정 및 구체화 관계
_7.4 마스터 모델의 여러 가지 뷰
_7.5 모델을 구성하는 다른 방법
_7.6 비즈니스 모델링
_7.7 UML 사용
_7.8 마치며
_7.9 참고 자료
CHAPTER 8 도메인 모델
_8.1 도메인과 아키텍처의 관계
_8.2 정보 모델
_8.3 탐색 및 불변 사항
_8.4 스냅샷
_8.5 기능 시나리오
_8.6 마치며
_8.7 참고 자료
CHAPTER 9 디자인 모델
_9.1 디자인 모델
_9.2 경계 모델
_9.3 내부 모델
_9.4 품질 속성
_9.5 인저 시스템 설계 살펴보기
_9.6 뷰타입
_9.7 동적 아키텍처 모델
_9.8 아키텍처 기술 언어
_9.9 마치며
_9.10 참고 자료
CHAPTER 10 코드 모델
_10.1 모델 코드 격차
_10.2 일관성 관리
_10.3 구조적으로 명확한 코딩 스타일
_10.4 코드에서 설계 의도 표현
_10.5 코드 내 모델 원칙
_10.6 표현할 내용
_10.7 코드에서 설계 의도를 표현하는 패턴
_10.8 이메일 처리 시스템 둘러보기
_10.9 마치며
CHAPTER 11 캡슐화 및 파티셔닝
_11.1 여러 수준의 스토리
_11.2 계층 구조 및 분할
_11.3 분해 전략
_11.4 효과적인 캡슐화
_11.5 캡슐화된 인터페이스 구축
_11.6 마치며
_11.7 참고 자료
CHAPTER 12 모델 요소
_12.1 할당 요소
_12.2 컴포넌트
_12.3 컴포넌트 조립도
_12.4 커넥터
_12.5 설계 결정
_12.6 기능 시나리오
_12.7 불변 사항(제약 조건)
_12.8 모듈
_12.9 포트
_12.10 품질 속성
_12.11 품질 속성 시나리오
_12.12 책임
_12.13 트레이드오프
_12.14 마치며
CHAPTER 13 모델 관계
_13.1 투영(뷰) 관계
_13.2 분할 관계
_13.3 구성 관계
_13.4 분류 관계
_13.5 일반화 관계
_13.6 지정 관계
_13.7 구체화 관계
_13.8 바인딩 관계
_13.9 종속성 관계
_13.10 관계의 사용
_13.11 마치며
_13.12 참고 자료
CHAPTER 14 아키텍처 스타일
_14.1 장점
_14.2 개념 스타일 대 구현 스타일
_14.3 제약 조건 및 아키텍처 집중 설계
_14.4 패턴 대 스타일
_14.5 스타일 카탈로그
_14.6 계층 스타일
_14.7 큰 진흙 뭉치 스타일
_14.8 파이프와 필터 스타일
_14.9 일괄-순차 스타일
_14.10 모델 중심 스타일
_14.11 발행-구독 스타일
_14.12 클라이언트-서버 스타일 및 다중 계층
_14.13 P2P 스타일
_14.14 맵리듀스 스타일
_14.15 미러링, 랙, 팜 스타일
_14.16 마치며
_14.17 참고 자료
CHAPTER 15 아키텍처 모델 사용하기
_15.1 바람직한 모델 특성
_15.2 뷰를 이용한 작업
_15.3 뷰 품질 향상
_15.4 다이어그램 품질 개선
_15.5 테스트 및 증명
_15.6 아키텍처 모델 분석
_15.7 아키텍처 불일치
_15.8 추상화 수준 선택
_15.9 사용자 인터페이스 계획
_15.10 규범 모델 대 설명 모델
_15.11 기존 시스템 모델링
_15.12 마치며
_15.13 참고 자료
CHAPTER 16 결론
_16.1 당면 과제
_16.2 품질 속성에 집중
_16.3 모델링이 아니라 문제 해결
_16.4 제약 조건을 가이드 레일로 사용
_16.5 표준 아키텍처 추상화 사용
