카네기멜론大와 소프트웨어공학 연구소 SEI 공식 교재
정보통신부와 한국소프트웨어진흥원이 선정한 아키텍트 교육과정 주교재

총론 ‘이론과 실제’에 두 가지 각론 ‘문서화’, ‘평가’를 합한 소프트웨어 아키텍처의 결정판


[ 세트 구성: 전3권 ]

1) 『소프트웨어 아키텍처: 이론과 실제』
2) 『소프트웨어 아키텍처 문서화』
3) 『소프트웨어 아키텍처 평가』


『소프트웨어 아키텍처: 이론과 실제』 소개
제9회 Jolt Awards 수상작인 이 책은 소프트웨어 엔지니어링의 패러다임을 바꾸고 있는 소프트웨어 아키텍처의 이론과 개념, 풍부한 베스트 프랙티스가 담겨 있다. 일명 "노란 책"으로 통하는 이 책은 카네기멜론大와 소프트웨어 공학 연구소 SEI가 채택한 교육 교재이며 정보통신부와 한국소프트웨어진흥원이 선정한 아키텍트 교육과정 주교재로 쓰인다. 다년간의 연구 내용과 현장 경험이 면밀히 녹아있는 소프트웨어 아키텍처의 필독서로 국내 전문 소프트웨어 아키텍트 양성에 큰 기여를 할 것으로 기대된다. 소프트웨어 아키텍트는 물론, 아키텍트를 꿈꾸는 개발자, 대학생도 꼭 읽어야 할 아키텍처 바이블이다.


『소프트웨어 아키텍처 문서화』 소개

이 책은 문서를 작성하는 책임을 진 아키텍트와 기술문서 작성자, 아키텍처 문서를 받아서 활용하는 개발자라면 꼭 읽어야 할 필독서로서 소프트웨어 아키텍처를 다루는 실무자들이 꼭 읽어야 할 책이다. 소프트웨어 아키텍트로서 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여준다.


『소프트웨어 아키텍처 평가』 소개

『소프트웨어 아키텍처: 이론과 실제』와 『소프트웨어 아키텍처 문서화』에 이어 SEI 시리즈 세 번째 책 『소프트웨어 아키텍처 평가』가 출간됐다. 소프트웨어 아키텍트의 필독서인 이 책에서는 올바른 아키텍처를 선택하거나 수립했는지를 평가하는 데 활용할 수 있는 ATAM 등 평가 기법을 소개하고 이를 기반으로 아키텍처 평가를 수행하는 데 실질적인 절차와 지침을 제공한다.

[ 저자 소개 ]

렌 베스
현재 미 SEI 연구소의 기술 분야 수석 연구원이다. 소프트웨어 공학과 관련된 책을 포함하여 6권의 책을 저술했고 수많은 논문을 발표했다. 또한 실제 프로젝트에서 아키텍처 설계를 담당하는 등 풍부한 실무 경험을 보유하고 있다.

폴 클레멘츠
현재 미 SEI 연구소에서 기술 분야의 수석 연구원으로서 소프트웨어 아키텍처와 프로덕트 라인 공학에 대해 연구하고 있다. 소프트웨어 아키텍처 분야에 대해 5권의 책을 저술했고 36편 이상의 논문을 발표했다.

릭 캐즈먼
미 SEI 연구소 기술 분야의 수석 연구원 겸 하와이 대학의 부교수이다. 편집자이기도 한 그는 3권의 저서가 있으며 소프트웨어 공학과 관련한 논문을 70편 이상 발표 해왔다.

마크 클라인
미 SEI 연구소 기술 분야의 수석 연구원이다. 마크는 카네기 멜론 대학의 소프트웨어 공학 석사과정의 교수이며 『A Practitioner’s Handbook for Real-Time Analysis(실무자를 위한 실시간 분석 가이드)』(슈프링거, 1993)의 공동저자다.


[ 역자 소개 ]

송재하
1992년 성균관대학교 컴퓨터 동아리에서 터보 파스칼을 배우면서 프로그래밍을 시작했다. 소프트웨어 설계와 분석에 많은 관심이 있고, 한국정보통신대학교 공학석사와 카네기멜론대 소프트웨어 공학 석사과정MSE을 졸업했다. 훌륭한 소프트웨어 아키텍트가 되고 싶어하고, 또 그 길을 가고 있다. 현재는 엔씨소프트의 오픈마루 스튜디오에서 검색 데이터 수집 팀을 이끌며 소프트웨어 공학과 아키텍처의 이론을 실제로 적용해 나가고 있다.

김정호
한양대학교 대학원에서 응용 수학을 전공하였고 카네기멜론대에서 소프트웨어공학 석사과정을 마쳤다. 현재 SKC&C의 대규모 프로젝트의 소프트웨어 아키텍트로 활동하고 있으며 소프트웨어 아키텍트 양성 교육강사를 겸임하고 있다. 이 시대 최고의 소프트웨어 아키텍트를 목표로 오늘도 열심히 달리고 있다.

이석준
뉴사우스웨일스 대학원에서 정보공학을 전공했으며 삼성 SDS 아키텍처팀에서 소프트웨어 아키텍트로 활동하고 있다. SEI에서 소프트웨어 아키텍처 전문가 자격과 ATAM 평가자 자격을 수료했다. 참여한 다수 프로젝트에서 소프트웨어 아키텍처 수립 및 절차를 반영하는 데 많은 노력을 하고 있으며 이와 관련한 사내 과정의 집필과 강의를 맡고 있다.

박미율
덕성여자대학교에서 전산학을 전공하고 한국정보통신대학교 공학석사와 카네기멜론대학 소프트웨어공학 석사과정MSIT-SE을 졸업했다. 주 관심분야는 소프트웨어 아키텍처, 소프트웨어 개발방법론 등이며, 현재 국내 전자회사에서 임베디드 소프트웨어 관련 업무를 하고 있다.

방정욱
숭실대학교 컴퓨터학부를 졸업한 후, 한국정보통신대학교 공학석사, 카네기멜론대학교 소프트웨어공학 석사과정(MSIT-SE)을 졸업했다. 현재 안철수연구소에서 모바일 백신 개발을 하고 있다. 더 넓고 더 큰 세상으로 나아가기를 항상 간절히 소망하고 있다.

노구율
서강대학교 정보통신통신대학원, 카네기멜론대 소프트웨어공학 석사과정(MSE)을 졸업했다. 현재 삼성 SDS에서 IT 컨설팅을 수행하고 있다. PLM(Product Lifecycle Management)과 IT 프로젝트 관리에 관심이 많다.

송창선
한국항공대학교 항공기계공학과를 졸업한 후, 한국정보통신대학교 공학석사, 카네기멜론대 소프트웨어공학 석사과정을 졸업했다. 현재는 한국정보통신기술협회(TTA) SW시험인증센터에서 연구원으로 재직 중이다.

이진희
서울대학교 컴퓨터공학과를 졸업하고 카네기멜론대학 소프트웨어공학 석사를 졸업했다. 미국 오라클 본사에서 소프트웨어 엔지니어로 근무하다 현재 실리콘밸리에서 벤처기업을 창업해 CTO 겸 Vice President로 일하고 있다.

백창현
KAIST 전산학 석사출신으로 일찍이 전투기 파일럿을 꿈꾸다 항공 시뮬레이션에 빠져 소프트웨어 분야에 입문했다. 핸디소프트의 BPM/그룹웨어 개발과 벤처기업 이모션의 개발 경력을 거쳐 삼성 SDS IT 플랫폼 팀에서 차세대 시스템을 위한 엔터프라이즈 프레임워크 개발을 선도하고 있다. 제품/시스템 개발을 위한 최적화된 소프트웨어 설계가 주 관심 분야며, 소프트웨어 시스템 개발의 근간은 아키텍처라고 확신한다. 공저서로는 『1st 워크플로우』(시사컴퓨터, 2000), 역서로는 『소프트웨어로 승리하자』(학현사, 2004)가 있다.

박인수
숭실대에서 전산을 전공했으며 현재 삼성 SDS에서 소프트웨어 아키텍트로 활동하고 있다. 누구보다도 소프트웨어 아키텍처에 대한 애착이 있다고 자부하며, 실제 프로젝트에서 이상적인 소프트웨어 아키텍처를 적용하기 위해 노력한다. 훌륭한 아키텍처는 성공적인 시스템의 밑거름이 된다는 철학을 바탕으로, 설계에서 의도한 대로 시스템이 구현될 수 있을까에 대한 해답을 찾기 위한 연구에 매진 중이다. 개발자들이 희생을 강요당하지 않고 품질, 납기, 원가 모두를 만족하는 성공적인 소프트웨어 시스템을 구축할 수 있는 세상을 위해 늘 고민한다.

목차

• 『소프트웨어 아키텍처: 이론과 실제』
  
• 1부 아키텍처 개요 1
  
  • 1장 아키텍처 비즈니스 사이클 3
    • 1.1 아키텍처에 영향을 주는 요인 6
    • 1.2 소프트웨어 프로세스와 아키텍처 비즈니스 사이클 12
    • 1.3 좋은 아키텍처의 요건 15
    • 1.4 요약 17
    • 1.5 생각해볼 문제 17
      
  • 2장 소프트웨어 아키텍처 정의 19
    • 2.1 소프트웨어 아키텍처의 요건 19
    • 2.2 소프트웨어 아키텍처에 대한 기타 관점 23
    • 2.3 아키텍처 패턴, 참조 모델, 참조 아키텍처 24
    • 2.4 소프트웨어 아키텍처의 중요성 26
    • 2.5 아키텍처 구조와 뷰 35
    • 2.6 요약 42
    • 2.7 더 읽을거리 42
    • 2.8 생각해볼 문제 45
      
  • 3장 A-7E 항공 전자 시스템 47
    • 3.1 아키텍처 비즈니스 사이클과의 관계 48
    • 3.2 요구사항과 품질 48
    • 3.3 A-7E 항공 전자 시스템의 소프트웨어 아키텍처 53
    • 3.4 요약 66
    • 3.5 더 읽을거리 68
    • 3.6 생각해볼 문제 68
      
      
• 2부 아키텍처 수립 69
  
  • 4장 품질속성 이해 71
    • 4.1 기능성과 아키텍처 72
    • 4.2 품질속성과 아키텍처 72
    • 4.3 시스템 품질속성 74
    • 4.4 실전에서의 품질속성 시나리오 78
    • 4.5 기타 시스템 품질속성 94
    • 4.6 업무 품질 95
    • 4.7 아키텍처 자체의 품질 96
    • 4.8 요약 97
    • 4.9 더 읽을거리 97
    • 4.10 생각해볼 문제 98
      
  • 5장 품질 목표 달성 99
    • 5.1 설계전술 100
    • 5.2 가용성 설계전술 101
    • 5.3 변경용이성 설계전술 106
    • 5.4 성능 설계전술 112
    • 5.5 보안 설계전술 117
    • 5.6 시험용이성 설계전술 119
    • 5.7 사용편의성 설계전술 122
    • 5.8 설계전술과 아키텍처 패턴 관계 124
    • 5.9 아키텍처 패턴과 스타일 125
    • 5.10 요약 127
    • 5.11 생각해볼 문제 127
    • 5.12 더 읽을거리 127
  • 6장 항공관제 시스템 129
    • 6.1 아키텍처 비즈니스 사이클과의 관계 132
    • 6.2 요구사항과 품질 132
    • 6.3 아키텍처 관점에서의 해결방안 135
    • 6.4 요약 151
    • 6.5 더 읽을거리 152
    • 6.6 생각해볼 문제 152
      
  • 7장 아키텍처 설계 153
    • 7.1 생명주기상에서의 아키텍처 153
    • 7.2 아키텍처 설계 155
    • 7.3 팀 구조 형성과 아키텍처의 관계 167
    • 7.4 골격 시스템 구축 170
    • 7.5 요약 171
    • 7.6 더 읽을거리 173
    • 7.7 생각해볼 문제 173
      
  • 8장 비행 모의실험 175
    • 8.1 아키텍처 비즈니스 사이클과의 관계 176
    • 8.2 요구사항과 품질 177
    • 8.3 아키텍처 관점에서의 해결방안 182
    • 8.4 요약 197
    • 8.5 더 읽을거리 199
    • 8.6 생각해볼 문제 199
      
  • 9장 아키텍처 문서화 201
    • 9.1 아키텍처 문서의 용도 201
    • 9.2 뷰 204
    • 9.3 관련 뷰 선택 205
    • 9.4 뷰 문서화 207
    • 9.5 여러 뷰를 고려한 문서화 215
    • 9.6 UML 218
    • 9.7 요약 229
    • 9.8 더 읽을거리 230
    • 9.9 생각해볼 문제 230
  • 10장 아키텍처 재건 231
    • 10.1 개요 231
    • 10.2 정보 추출 234
    • 10.3 데이터베이스 구축 237
    • 10.4 뷰 융합 239
    • 10.5 재건 241
    • 10.6 사례 연구 248
    • 10.7 요약 257
    • 10.8 더 읽을거리 258
    • 10.9 생각해볼 문제 259
      
      
• 3부 아키텍처 분석 261
  
  • 11장 ATAM 271
    • 11.1 ATAM 참여자 272
    • 11.2 ATAM의 결과물 274
    • 11.3 ATAM의 과정 275
    • 11.4 나이팅게일 시스템: ATAM을 적용한 사례 연구 288
    • 11.5 요약 303
    • 11.6 더 읽을거리 304
    • 11.7 생각해볼 문제 305
      
  • 12장 CBAM 307
    • 12.1 의사결정의 배경 308
    • 12.2 CBAM의 기초 310
    • 12.3 CBAM의 구현 314
    • 12.4 사례 연구: 미국항공우주국 ECS 프로젝트 317
    • 12.5 CBAM 작업 결과 324
    • 12.6 요약 324
    • 12.7 더 읽을거리 325
    • 12.8 생각해볼 문제 325
  • 13장 월드와이드웹 327
    • 13.1 아키텍처 비즈니스 사이클과의 관계 328
    • 13.2 요구사항과 품질 329
    • 13.3 아키텍처 관점에서의 해결방안 334
    • 13.4 제2차 ABC 사이클: 웹 기반 전자상거래 아키텍처로의 진화 340
    • 13.5 품질 목표 달성 346
    • 13.6 오늘날의 웹 아키텍처 비즈니스 사이클 346
    • 13.7 요약 348
    • 13.8 더 읽을거리 349
    • 13.9 생각해볼 문제 349
      
      
• 4부 아키텍처 확산 351
  
  • 14장 소프트웨어 프로덕트 라인 353
    • 14.1 개요 353
    • 14.2 소프트웨어 프로덕트 라인의 작동원리 355
    • 14.3 범위 설정 357
    • 14.4 프로덕트 라인 아키텍처 360
    • 14.5 프로덕트 라인의 방해 요소 364
    • 14.6 요약 367
    • 14.7 더 읽을거리 368
    • 14.8 생각해볼 문제 368
      
  • 15장 셀시우스테크 369
    • 15.1 아키텍처 비즈니스 사이클과의 관계 370
    • 15.2 요구사항과 품질 388
    • 15.3 아키텍처 관점에서의 해결방안 390
    • 15.4 요약 399
    • 15.5 더 읽을거리 400
    • 15.6 생각해볼 문제 400
      
  • 16장 J2EE/EJB 401
    • 16.1 아키텍처 비즈니스 사이클과의 관계 402
    • 16.2 요구사항과 품질 403
    • 16.3 아키텍처 관점에서의 해결방안 406
    • 16.4 시스템 배치 의사결정 420
    • 16.5 요약 425
    • 16.6 더 읽을거리 426
    • 16.7 생각해볼 문제 426
      
  • 17장 루더 아키텍처 427
    • 17.1 아키텍처 비즈니스 사이클과의 관계 428
    • 17.2 요구사항과 품질 431
    • 17.3 아키텍처 관점에서의 해결방안 434
    • 17.4 품질 목표 달성 451
    • 17.5 요약 452
    • 17.6 더 읽을거리 452
    • 17.7 생각해볼 문제 452
      
  • 18장 기성 컴포넌트를 활용한 시스템 구축 453
    • 18.1 컴포넌트가 아키텍처에 미치는 영향 455
    • 18.2 아키텍처 불일치 456
    • 18.3 검색을 통한 컴포넌트 기반 설계 462
    • 18.4 ASEILM 사례 466
    • 18.5 요약 476
    • 18.6 더 읽을거리 476
      
  • 19장 소프트웨어 아키텍처의 미래 477
    • 19.1 다시 살펴보는 아키텍처 비즈니스 사이클 479
    • 19.2 아키텍처 수립 479
    • 19.3 생명주기 내에서의 아키텍처 481
    • 19.4 상용 컴포넌트의 영향 482
    • 19.5 요약 484
      
      
• 『소프트웨어 아키텍처 문서화』
  
• 서장: 소프트웨어 아키텍처와 문서화
  • P.1 아키텍처의 역할
    • [용어 설명] 소프트웨어 아키텍처
    • [견해 소개] 아키텍처는 설계와 어떻게 다른가?
    • [용어 설명] 문서화, 설명, 표현, 명세
  • P.2 아키텍처 문서 활용방안
  • P.3 인터페이스
  • P.4 뷰
    • [용어 설명] 아키텍처 뷰
  • P.5 뷰타입과 스타일
    • P.5.1 뷰타입
    • P.5.2 스타일
    • P.5.3 뷰타입, 스타일, 뷰에 대한 요약
    • [용어 설명] 모듈과 컴포넌트
  • P.6 좋은 문서를 만드는 7가지 규칙
    • P.6.1 규칙 1: 읽는 사람의 관점에서 문서를 작성한다
    • P.6.2 규칙 2: 불필요한 반복을 피한다
    • P.6.3 규칙 3: 모호함을 피한다
    • P.6.4 규칙 4: 표준 체계를 따른다
    • P.6.5 규칙 5: 근거를 남겨둔다
    • P.6.6 규칙 6: 문서는 항상 최신 내용을 담되 너무 앞서나가지 않는다
    • P.6.7 규칙 7: 목적에 맞게 작성됐는지 사후 검토한다
    • [견해 소개] 화살표에 대한 고민
  • P.7 정리
  • P.8 생각해볼 문제
  • P.9 더 읽을거리
    
• I부 소프트웨어 아키텍처 뷰타입과 스타일
  • I.1 뷰타입과 스타일 목록
    • I.1.1 모듈 뷰타입
    • I.1.2 컴포넌트와 커넥터 뷰타입
    • I.1.3 할당 뷰타입
  • I.2 스타일 지침: 스타일 문서화를 위한 표준 문서체계
    
• 1장 모듈 뷰타입
  • 1.1 개요
  • 1.2 모듈 뷰타입의 요소, 관계, 속성
    • 1.2.1 요소
    • 1.2.2 관계
    • 1.2.3 속성
    • [용어 설명] 교체가능성
  • 1.3 모듈 뷰타입이 적합한 상황
  • 1.4 모듈 뷰타입 표기법
    • 1.4.1 비공식 표기법
    • 1.4.2 UML
  • 1.5 다른 뷰타입과의 관계
  • 1.6 정리
  • 1.7 생각해볼 문제
  • 1.8 더 읽을거리
    
• 2장 모듈 뷰타입 스타일
  • 2.1 분할 스타일
    • 2.1.1 개요
    • 2.1.2 요소, 관계, 속성
    • 2.1.3 용도
    • 2.1.4 표기법
    • 2.1.5 다른 스타일과의 관계
    • 2.1.6 사례
    • [용어 설명] 하위시스템
  • 2.2 사용 스타일
    • 2.2.1 개요
    • 2.2.2 요소, 관계, 속성
    • 2.2.3 용도
    • 2.2.4 표기법
    • 2.2.5 다른 스타일과의 관계
    • 2.2.6 사례
    • [용어 설명] 사용
  • 2.3 일반화 스타일
    • 2.3.1 개요
    • 2.3.2 요소, 관계, 속성
    • 2.3.3 용도
    • 2.3.4 표기법
    • 2.3.5 다른 스타일과의 관계
    • [용어 설명] 일반화
    • 2.3.6 사례
  • 2.4 계층 스타일
    • 2.4.1 개요
    • 2.4.2 요소, 관계, 속성
    • 2.4.3 용도
    • 2.4.4 표기법
    • 2.4.5 다른 스타일과의 관계
    • 2.4.6 사례
    • [용어 설명] 가상기계
    • [견해 소개] 거슬러 올라가는 소프트웨어
    • [견해 소개] ‘수준’ 때문에 생기는 혼란
    • [견해 소개] UML 클래스 다이어그램 남용금지!
  • 2.5 정리
  • 2.6 생각해볼 문제
  • 2.7 더 읽을거리
    
• 3장 컴포넌트와 커넥터 뷰타입
  • 3.1 개요
  • 3.2 C&C 뷰타입의 요소, 관계, 속성
    • 3.2.1 요소
    • 3.2.2 관계
    • 3.2.3 속성
    • [견해 소개] 커넥터는 정말 필요한가?
    • [견해 소개] 커넥터 추상화
  • 3.3 C&C 뷰타입의 용도
    • [견해 소개] 데이터 흐름과 제어 흐름 투영
  • 3.4 C&C 뷰타입 표기법
  • 3.5 다른 뷰타입과의 관계
  • 3.6 정리
  • 3.7 생각해볼 문제
  • 3.8 더 읽을거리
    
• 4장 컴포넌트와 커넥터 뷰타입 스타일
  • 4.1 파이프와 필터 스타일
    • 4.1.1 개요
    • 4.1.2 요소, 관계, 속성
    • 4.1.3 용도
    • 4.1.4 다른 스타일과의 관계
    • 4.1.5 사례
  • 4.2 공유 데이터 스타일
    • 4.2.1 개요
    • 4.2.2 요소, 관계, 속성
    • 4.2.3 용도
    • 4.2.4 다른 스타일과의 관계
    • 4.2.5 사례
  • 4.3 발행 구독 스타일
    • 4.3.1 개요
    • 4.3.2 요소, 관계, 속성
    • 4.3.3 용도
    • 4.3.4 다른 스타일과의 관계
    • 4.3.5 사례
  • 4.4 클라이언트/서버 스타일
    • 4.4.1 개요
    • 4.4.2 요소, 관계, 속성
    • 4.4.3 용도
    • 4.4.4 다른 스타일과의 관계
    • 4.4.5 사례
  • 4.5 피어 투 피어 스타일
    • 4.5.1 개요
    • 4.5.2 요소, 관계, 속성
    • 4.5.3 용도
    • 4.5.4 다른 스타일과의 관계
    • 4.5.5 사례
  • 4.6 프로세스 간 통신 스타일
    • 4.6.1 개요
    • 4.6.2 요소, 관계, 속성
    • 4.6.3 용도
    • 4.6.4 다른 스타일과의 관계
    • 4.6.5 사례
  • 4.7 C&C 스타일 표기법
    • 4.7.1 비공식적 표기법
    • 4.7.2 정형적 표기법
    • [견해 소개] 클래스로 컴포넌트 타입과 인스턴스 표현하기
    • [용어 설명] 컴포넌트와 UML 컴포넌트의 비교
  • 4.8 정리
  • 4.9 생각해볼 문제
  • 4.10 더 읽을거리
    
• 5장 할당 뷰타입과 스타일
  • 5.1 개요
  • 5.2 요소, 관계, 속성
  • 5.3 배치 스타일
    • 5.3.1 개요
    • 5.3.2 요소, 관계, 속성
    • 5.3.3 용도
    • 5.3.4 표기법
    • 5.3.5 다른 스타일과의 관계
    • 5.3.6 사례
  • 5.4 구현 스타일
    • 5.4.1 개요
    • 5.4.2 요소, 관계, 속성
    • 5.4.3 용도
    • 5.4.4 표기법
    • 5.4.5 다른 스타일과의 관계
    • 5.4.6 사례
  • 5.5 작업할당 스타일
    • 5.5.1 요소, 관계, 속성
    • 5.5.2 용도
    • 5.5.3 표기법
    • 5.5.4 다른 스타일과의 관계
    • 5.5.5 사례
  • 5.6 정리
  • 5.7 생각해볼 문제
  • 5.8 더 읽을거리
    
• II부 실전 소프트웨어 아키텍처 문서화
  
• 6장 고급 개념
  • 6.1 정보 분할과 뷰 패킷, 정제, 설명적 완결성
    • 6.1.1 뷰 패킷
    • 6.1.2 정제
    • 6.1.3 설명적 완결성
  • 6.2 컨텍스트 다이어그램
    • 6.2.1 최상위 수준 컨텍스트 다이어그램
    • 6.2.2 내용
    • 6.2.3 그 밖의 보조 문서
    • 6.2.4 표기법
    • 6.2.5 사례
  • 6.3 결합 뷰
    • 6.3.1 결합 뷰를 사용해야 하는 경우
    • 6.3.2 대응의 유형
    • 6.3.3 요소, 관계, 속성
    • 6.3.4 결합 뷰 문서화
    • 6.3.5 결합 뷰 예제
    • 6.3.6 그 밖의 예제
  • 6.4 가변성과 역동성 문서화
    • 6.4.1 가변성
    • 6.4.2 역동성
    • 6.4.3 정보 기록
    • 6.4.4 표기법
    • [견해 소개] 시점이란 무엇인가?
  • 6.5 새로운 스타일 작성과 문서화
    • [용어 설명] 스타일과 패턴
  • 6.6 정리
  • 6.7 생각해볼 문제
  • 6.8 더 읽을거리
    
• 7장 소프트웨어 인터페이스 문서화
  • 7.1 개요
  • 7.2 인터페이스 명세
  • 7.3 인터페이스 문서 표준 체계
    • [용어 설명] 예외와 오류 처리
  • 7.4 인터페이스 문서와 관련된 이해관계자
  • 7.5 인터페이스 문서 표기법
    • 7.5.1 인터페이스의 존재 제시
    • 7.5.2 형태정보 전달
    • 7.5.3 의미정보 전달
    • 7.5.4 요약
    • [견해 소개] 다중 인터페이스
    • [용어 설명] 호출규약, 인터페이스, API
  • 7.6 인터페이스 문서화 예제
    • 7.6.1 SCR 스타일의 인터페이스
    • 7.6.2 IDL
    • 7.6.3 맞춤형 표기법
    • 7.6.4 XML
  • 7.7 정리
  • 7.8 생각해볼 문제
  • 7.9 더 읽을거리
    
• 8장 행위 문서화
  • 8.1 구조를 넘어서
  • 8.2 행위 문서화 위치
  • 8.3 행위 문서화 필요성
    • 8.3.1 시스템 분석
    • 8.3.2 개발 작업 추진
  • 8.4 문서화 내용
    • 8.4.1 통신 방식
    • 8.4.2 순서 제약사항
    • 8.4.3 시간에 따라 발생하는 자극
  • 8.5 행위 문서화에 쓰이는 언어와 표기법
    • 8.5.1 추적
    • 8.5.2 정적 모델
  • 8.6 정리
  • 8.7 생각해볼 문제
  • 8.8 더 읽을거리
    
• 9장 뷰 선택
  • 9.1 이해관계자들에게 필요한 문서
    • [견해 소개] 아키텍처 트레이드오프 분석 방법
  • 9.2 선택하기
  • 9.3 두 가지 예제
    • 9.3.1 소규모 프로젝트 A-7E
    • 9.3.2 대규모 프로젝트 ECS
  • 9.4 정리
  • 9.5 생각해볼 문제
  • 9.6 더 읽을거리
    
• 10장 문서 패키지 작성
  • 10.1 문서를 하나로? 여러 개로?
    • [견해 소개] ‘is’의 의미
  • 10.2 뷰 문서화
    • [견해 소개] 표현 방법도 중요하다!
  • 10.3 뷰 개괄 문서
    • 10.3.1 어떻게 문서가 구성됐는가: 구성 정보
    • 10.3.2 무엇을 아키텍처로 봤는가: 구성 내용
    • 10.3.3 왜 아키텍처가 현재의 모습을 하고 있는가: 배경, 근거, 설계 제약사항
  • [견해 소개] 전역 분석
• 10.4 소프트웨어 아키텍처 문서의 검증
  • [견해 소개] 용어집을 만들면 좋았을 텐데
• 10.5 정리
• 10.6 생각해볼 문제
• 10.7 더 읽을거리
  

11장 그 밖의 문서화 기법

• 11.1 개요
• 11.2 래셔널 통합 프로세스(RUP)/크루첸 4+1
• 11.3 UML
  • 11.3.1 클래스 다이어그램과 객체 다이어그램
  • 11.3.2 컴포넌트 다이어그램
  • 11.3.3 배치 다이어그램
  • 11.3.4 행위 다이어그램
• 11.4 지멘스 4뷰
  • 11.4.1 전역 분석
  • 11.4.2 개념적 아키텍처 뷰
  • 11.4.3 모듈 아키텍처 뷰
  • 11.4.4 실행 아키텍처 뷰
  • 11.4.5 코드 아키텍처 뷰
  • 11.4.6 요약
• 11.5 C4ISR 아키텍처 프레임워크
  • 11.5.1 C4ISR 프레임워크의 공통 아키텍처 뷰
  • 11.5.2 공통 산출물
• 11.6 ANSI/IEEE-1471-2000
• 11.7 데이터 흐름과 제어 흐름
  • 11.7.1 데이터 흐름 뷰
  • 11.7.2 제어 흐름 뷰
• [견해 소개] 그거 전부 다 추측이잖아요!

11.8 RM-ODP

11.9 아키텍처 문서화의 정리

• 11.9.1 아키텍처 설명 언어
• 11.9.2 상용 컴포넌트
• 11.9.3 하이퍼텍스트 문서
• 11.9.4 형상관리

11.10 당부의 말

11.11 더 읽을거리

부록 A: 소프트웨어 아키텍처 문서 패키지 사례

• 1권 ECS 소프트웨어 아키텍처 뷰 개괄 문서
• 2권 ECS 소프트웨어 아키텍처 뷰
  
  

『소프트웨어 아키텍처 평가』

1장 소프트웨어 아키텍처

• 1.1 이해관계자 간 의사소통 수단으로서의 아키텍처
  • 1.1.1 | 아키텍처와 이해관계자에게 미치는 영향
  • 1.1.2 | 아키텍처 뷰
  • 1.1.3 | 아키텍처 설명 언어
• 1.2 초기 설계 의사결정에 대한 방향선언으로서의 아키텍처
  • 1.2.1 | 아키텍처 스타일
• 1.3 재사용가능하고 이전할 수 있는, 시스템 추상화로서의 아키텍처
• 1.4 정리
• 1.5 더 읽을거리
• 1.6 생각해볼 문제
  

2장 소프트웨어 아키텍처 평가

• 2.1 아키텍처 평가 이유
• 2.2 아키텍처 평가 시점
• 2.3 아키텍처 평가 참여자
• 2.4 아키텍처 평가의 예상 결과
• 2.5 아키텍처 평가대상 품질속성
• 2.6 품질속성 분석의 모호성
• 2.7 아키텍처 평가의 결과물
  • 2.7.1 | ATAM, SAAM, ARID의 결과물
  • 2.7.2 | ATAM만의 결과물
• 2.8 아키텍처 평가 수행의 이점과 비용
• 2.9 더 읽을거리
• 2.10 생각해볼 문제
  

3장 ATAM - 아키텍처 평가방법

• 3.1 ATAM 스텝의 요약
• 3.2 ATAM 스텝 상세 설명
  • 3.2.1 | 스텝 1: ATAM 프리젠테이션
  • 3.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션
  • 3.2.3 | 스텝 3: 아키텍처 프리젠테이션
  • 3.2.4 | 스텝 4: 아키텍처 접근방법 식별
  • 3.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성
  • 3.2.6 | 스텝 6: 아키텍처 접근방법 분석
  • 3.2.7 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
  • 3.2.8 | 스텝 8: 아키텍처 접근방법 분석
  • 3.2.9 | 스텝 9: 결과 프리젠테이션
• 3.3 ATAM의 단계
  • 3.3.1 | 0단계 활동
  • 3.3.2 | 1단계 활동
  • 3.3.3 | 2단계 활동
  • 3.3.4 | 3단계 활동
• 3.4 더 읽을거리
• 3.5 생각해볼 문제
  

4장 전장통제 시스템 - ATAM을 적용한 첫 사례연구

• 4.1 준비
• 4.2 1단계
  • 4.2.1 | 스텝 1: ATAM 프리젠테이션
  • 4.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션
  • 4.2.3 | 스텝 3: 아키텍처 프리젠테이션
  • 4.2.4 | 스텝 4: 아키텍처 접근방법 식별
  • 4.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성
  • 4.2.6 | 스텝 6: 아키텍처 접근방법 분석
• 4.3 2단계
  • 4.3.1 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
  • 4.3.2 | 스텝 8: 아키텍처 접근방법 분석
  • 4.3.3 | 스텝 9: 결과 프리젠테이션
• 4.4 BCS 평가의 결과
  • 4.4.1 | 문서화
  • 4.4.2 | 요구사항
  • 4.4.3 | 민감점과 절충점
  • 4.4.4 | 아키텍처 위험요소
• 4.5 정리
• 4.6 생각해볼 문제
  

5장 품질속성 이해

• 5.1 품질속성 특징화
  • 5.1.1 | 성능
  • 5.1.2 | 가용성
  • 5.1.3 | 변경용이성
  • 5.1.4 | 품질속성 특징화 질문
• 5.2 ATAM에서의 품질속성 특징화 사용
• 5.3 속성 기반 아키텍처 스타일
• 5.4 정리
• 5.5 더 읽을거리
• 5.6 생각해볼 문제
  

6장 ATAM 적용 사례연구

• 6.1 배경 6.2 0단계: 제휴와 준비
  • 6.2.1 | 0단계, 스텝 1: ATAM 프리젠테이션
  • 6.2.2 | 0단계, 스텝 2: 후보 시스템 설명
  • 6.2.3 | 0단계, 스텝 3: ATAM의 진행 여부 결정
  • 6.2.4 | 0단계, 스텝 4: 업무내용 협의
  • 6.2.5 | 0단계, 스텝 5: 핵심 평가팀 구성
  • 6.2.6 | 0단계, 스텝 6: 평가팀 착수회의 개최
  • 6.2.7 | 0단계, 스텝 7: 1단계 준비
  • 6.2.8 | 0단계, 스텝 8: 아키텍처 검토
• 6.3 1단계: 초기평가
  • 6.3.1 | 1단계, 스텝 1: ATAM 프리젠테이션
  • 6.3.2 | 1단계, 스텝 2: 비즈니스 동인 프리젠테이션
  • 6.3.3 | 1단계, 스텝 3: 아키텍처 프리젠테이션
  • 6.3.4 | 1단계, 스텝 4: 아키텍처 접근방법 식별
  • 6.3.5 | 1단계, 스텝 5: 품질속성 유틸리티 트리 작성
  • 6.3.6 | 1단계, 스텝 6: 아키텍처 접근방법 분석
• 6.4 1단계와 2단계 사이의 공백기간
• 6.5 2단계: 평가 완성
  • 6.5.1 | 2단계, 스텝 0: 2단계 준비
  • 6.5.2 | 2단계, 스텝 1~6
  • 6.5.3 | 2단계, 스텝 7: 시나리오 브레인스토밍과 우선순위 결정
  • 6.5.4 | 2단계, 스텝 8: 아키텍처 접근방법 분석
  • 6.5.5 | 2단계, 스텝 9: 결과 프리젠테이션
• 6.6 3단계: 후속조치
  • 6.6.1 | 3단계, 스텝 1: 최종보고서 작성
  • 6.6.2 | 3단계, 스텝 2: 사후 개선회의 개최
  • 6.6.3 | 3단계, 스텝 3: 포트폴리오 구축과 산출물 저장소 갱신
• 6.7 더 읽을거리
• 6.8 생각해볼 문제
  

7장 SAAM을 이용한 예제 아키텍처 평가

• 7.1 SAAM 개요
  • 7.1.1 | SAAM 평가를 위한 입력물
  • 7.1.2 | SAAM 평가의 결과물
• 7.2 SAAM 평가의 스텝
  • 7.2.1 | 스텝 1: 시나리오 개발
  • 7.2.2 | 스텝 2: 아키텍처 설명
  • 7.2.3 | 스텝 3: 시나리오 분류와 우선순위 결정
  • 7.2.4 | 스텝 4: 간접 시나리오의 개별적인 평가
  • 7.2.5 | 스텝 5: 시나리오 상호작용 평가 7.2.6 | 스텝 6: 평가 총괄 정리
• 7.3 SAAM 의제 예시
• 7.4 SAAM 사례연구
  • 7.4.1 | ATAT 시스템 개요
  • 7.4.2 | 스텝 1: 시나리오 개발, 첫 번째 반복
  • 7.4.3 | 스텝 2: 아키텍처 설명, 첫 번째 반복
  • 7.4.4 | 스텝 1: 시나리오 개발, 두 번째 반복
  • 7.4.5 | 스텝 2: 아키텍처 설명, 두 번째 반복
  • 7.4.6 | 스텝 3: 시나리오 분류와 우선순위 결정
  • 7.4.7 | 스텝 4: 간접 시나리오의 개별적인 평가
  • 7.4.8 | 스텝 5: 시나리오 상호작용 확인
  • 7.4.9 | 스텝 6: 평가 총괄 정리 - 결과와 권고사항
• 7.5 정리
• 7.6 더 읽을거리 7.7 생각해볼 문제
  

8장 ARID - 부분적 아키텍처 평가방법

• 8.1 능동적 설계검토
• 8.2 ARID: ARD/ATAM 하이브리드
• 8.3 ARID의 스텝
  • 8.3.1 | 1단계: 예행연습
  • 8.3.2 | 2단계: 검토
• 8.4 ARID를 적용한 사례연구
  • 8.4.1 | 스텝의 수행
  • 8.4.2 | 활동 결과
• 8.5 정리
• 8.6 더 읽을거리
• 8.7 생각해볼 문제
  

9장 소프트웨어 아키텍처 평가방법 비교

• 9.1 질의기법
  • 9.1.1 | 설문지와 체크리스트
  • 9.1.2 | 시나리오와 시나리오 기반 방법
• 9.2 측정기법
  • 9.2.1 | 측정지표
  • 9.2.2 | 시뮬레이션, 프로토타입, 실험
  • 9.2.3 | 비율단조 분석
  • 9.2.4 | 자동화 도구와 아키텍처 설명 언어
• 9.3 하이브리드 기법
  • 9.3.1 | 소프트웨어 성능 엔지니어링
  • 9.3.2 | ATAM
• 9.4 정리
• 9.5 더 읽을거리
• 9.6 생각해볼 문제
  

10장 조직 차원에서 아키텍처 평가역량의 증대

• 10.1 조직적인 합의 구축
• 10.2 평가자 후보군의 확대
• 10.3 조직 차원 기억 수립
  • 10.3.1 | 비용과 이득 데이터
  • 10.3.2 | 평가방법 지침
  • 10.3.3 | 재사용 산출물
• 10.4 정리
• 10.5 생각해볼 문제
  

11장 결론

• 11.1 이제 준비완료!
• 11.2 앞서 살펴본 방법 11.3 아키텍처를 평가해야 하는 이유
• 11.4 ATAM의 효과
• 11.5 마치면서
  

부록 A 속성 기반 아키텍처 스타일의 사례

• A.1 문제 서술
• A.2 자극/응답
• A.3 아키텍처 스타일
• A.4 분석
  • A.4.1 | 추론
  • A.4.2 | 우선순위 지정
  • A.4.3 | 우선순위 반전
  • A.4.4 | 중단시간