소득공제
- 베스트
- IT 모바일 top100 9주
- 본 도서의 개정판이 출간되었습니다.
이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
에이콘 소프트웨어 아키텍처 시리즈
책소개
목차
|
서장: 소프트웨어 아키텍처와 문서화
P1: 아키텍처의 역할 용어 설명: 소프트웨어 아키텍처 견해 소개: 아키텍처는 설계와 어떻게 다른가? 용어 설명: 문서화, 설명, 표현, 명세 P2: 아키텍처 문서 활용방안 P3: 인터페이스 P4: 뷰 용어 설명: 아키텍처 뷰 P5: 뷰타입과 스타일 P.5.1 뷰타입 P.5.2 스타일 P.5.3 뷰타입, 스타일, 뷰에 대한 요약 용어 설명: 모듈과 컴포넌트 P6: 좋은 문서를 만드는 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: 목적에 맞게 작성됐는지 사후 검토한다 견해 소개: 화살표에 대한 고민 P7: 요약정리 P8: 토론 문제 P9: 더 읽을거리 1부: 소프트웨어 아키텍처 뷰타입과 스타일 1.1 뷰타입과 스타일 목록 I.1.1 모듈 뷰타입 I.1.2 컴포넌트와 커넥터 뷰타입 I.1.3 할당 뷰타입 1.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 피어 투 피어 스타일의 사례 2부 실전 소프트웨어 아키텍처 문서화 6장 고급 개념 6.1 정보 분할과 뷰 패킷, 정제, 설명적 완결성 6.1.1 뷰 패킷 6.1.2 정제 6.1.3 설명적 완결성 6.2 컨텍몽트 다이어그램 사용 6.2.1 최상위 수준 컨텍스트 다이어그램 6.2.2 컨텍스트 다이어그램의 내용 6.2.4 컨텍스트 다이어그램 표기법 6.2.5 컨텍스트 다이어그램에 대한 예제 6.3 결합 뷰 6.3.1 결합 뷰를 사용해야 하는 경우 6.3.2 대응의 유형 6.3.3 요소, 관계, 속성 6.3 결합 뷰 문서화 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 추적trace 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 왜 아키텍처가 현재의 모습을 하고 있는가: 배경, 근거, 설계 제약사항 견해 소개: 전역 분석Global Analysis 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.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.2 공통 산출물 11.6 ANSI/IEEE-1471-2000 11.7 데이터 흐름과 제어 흐름 11.7.1 데이터 흐름 뷰 11.7.2 제어 흐름 뷰 견해 소개: 그거 전부 다 추측이잖아요! 11.8 RM-ODP 371 11.9 아키텍처 문서화의 결말 11.9.1 아키텍처 설명 언어 11.9.2 상용 컴포넌트 11.9.3 하이퍼텍스트 문서 11.9.4 형상 관리 11.10 당부의 말 11.11 더 읽을거리 |
저자 소개
공저자 소개
폴 클레멘츠, 펠릭스 바흐만, 렌 베스, 데이비드 갈란, 제임스 이버스, 리드 리틀, 로버드 노드, 주디스 스태포드는 모두 소프트웨어 아키텍처 분야의 영향력 있는 인사들이다. 이들은 소프트웨어 공학 연구소(SEI) 내에서 팀을 이뤄 소프트웨어 아키텍처를 다루는 데 필요한 효과적인 방법이나 기법을 개발하고 서로 의견을 주고받는 작업을 했다. 저자들은 모두 시스템 아키텍처를 구축하는 데 삶을 바쳐온 사람들이고, 그 중에는 특히 소프트웨어 아키텍처를 주제로 많은 갈채를 받은 선도적인 책을 쓴 사람들도 있다.
역자 : 송재하
1992년 성균관대학교 컴퓨터 동아리에서 터보 파스칼을 배우면서 프로그래밍을 시작했다. 소프트웨어 설계와 분석에 많은 관심이 있고, 한국정보통신대학교 공학석사와 카네기멜론대 소프트웨어 공학 석사과정(MSE)을 졸업했다. 훌륭한 소프트웨어 아키텍트가 되고 싶어하고, 또 그 길을 가고 있다. 현재는 엔씨소프트의 오픈마루 스튜디오에서 검색 데이터 수집 팀을 이끌며 소프트웨어 공학과 아키텍처의 이론을 실제로 적용해 나가고 있다.
역자 : 박미율
덕성여자대학교에서 전산학을 전공하고 한국정보통신대학교 공학석사와 카네기멜론대학 소프트웨어공학 석사과정(MSIT-SE)을 졸업했다. 주 관심분야는 소프트웨어 아키텍처, 소프트웨어 개발방법론 등이며, 현재 국내 전자회사에서 임베디드 소프트웨어 관련 업무를 하고 있다.
역자 : 이진희
서울대학교 컴퓨터공학과를 졸업하고 카네기멜론대학 소프트웨어공학 석사를 졸업했다. 미국 오라클 본사에서 소프트웨어 엔지니어로 근무하다 현재 실리콘밸리에서 벤처기업을 창업해 CTO 및 Vice President로 일하고 있다.
역자 : 김정호
카네기멜론대학(CMU)에서 소프트웨어 공학석사를 졸업하고 한국정보통신대학(ICU)에서 소프트웨어 아키텍처 전공으로 박사과정을 수료했다. 현재 SKC&C에서 소프트웨어 아키텍트로서 활동하고 있으며 3차원 현실 환경을 복제해 서비스를 제공하는 메타버스 플랫폼의 소프트웨어 아키텍처를 수립하고 있다.
품목정보
- 발행일
- 2009년 02월 09일
- 쪽수, 무게, 크기
- 560쪽 | 1422g | 188*254*35mm
- ISBN13
- 9788960770737
책 속으로
|
매우 간단한 소프트웨어 시스템이 아닌 다음에야, 아키텍처에 세심한 주의를 기울이지 않은 상태로 개발에 성공하기란 쉽지가 않다. 여기서 아키텍처란 시스템을 서로 관련된 부분들로 나누는 방식과 그 부분들이 상호작용하는 방식을 일컫는다. 당면한 문제를 해결할 적당한 아키텍처가 없다면 프로젝트는 실패하고 말 것이다. 또한 매우 훌륭한 아키텍처가 있다 하더라도 이해하기 어렵거나 의미를 전달하기 어려울 때는, 다시 말해 문서화가 잘 안 돼 있을 때는 프로젝트가 혼란에 빠지게 된다.
최근 들어 소프트웨어 아키텍처가 뭇 사람들의 관심을 끌게 됐고, 이를 반영하듯 아키텍처를 다룬 책도 매달 새로이 등장하고 있다. 업계의 요구에 부응해 대학들도 소프트웨어 공학 과정에 소프트웨어 아키텍처 과목을 집어넣고 있다. 이제는 조직 내에 "소프트웨어 아키텍트"라는 구체적인 직책이 일반적으로 받아들여지는 경우가 많아졌고, 소프트웨어 아키텍트로 이루어진 전문적인 실무 그룹도 생겨나게 됐다. 소프트웨어 아키텍처는 주류 국제 학술대회와 워크샵의 주제로도 자리 잡고 있다. 통합 모델링 언어(UML)를 공급하는 회사들은 자신들의 제품을 "소프트웨어 아키텍처를 나타내는 표준 표기법"으로 내세우고 있다. 이런 것을 보면 아키텍처가 최소한 UML과 비슷한 정도로 자리 잡고 있음을 알 수 있다. 카네기 멜론 대학교(CMU)의 소프트웨어 공학 연구소(SEI)에서는 소프트웨어 아키텍처 관련해서 학술지나 학술대회 발표 자료를 1000여 개 가까이 모아 놓았다. 한 가지 안타까운 점은 언어나 표기법과 무관하게 아키텍처를 잡아낼 수 있는 실용적인 지침이 아직 부족하다는 것이다. 좀 더 명확히 말하자면 특정 언어(UML이라고 생각해 보자)를 사용하는 방법을 다루는 책들은 수없이 많다. 그러나 실제로 아키텍트가 요구하는 것은 아키텍처를 최우선 요소로 다루고 그와 관련된 언어는 그것을 지원하는 보조적인 역할로만 보는 지침서라고 봤을 때, 이를 다루는 책은 드물다. 일단 기본적인 배경지식을 살펴보자. 이 분야에서는 아직 소프트웨어 아키텍처에 대한 정의가 하나로 수렴되지 않고 여러 정의가 난립해 있기는 하지만, 이 책에서는 그중에서 하나를 골라 일관되게 사용할 것이다. 바로 베스, 클레멘츠, 캐즈먼(1998)에게서 가져온 정의이다. 비록 이 책에서 주로 다루는 내용이 요소와 관계의 의미에 대한 것이기는 하지만, 여기서 이 정의를 사용하는 이유는 아키텍처에는 매우 다양한 종류의 구조가 있음을 강조하기 위해서다. 구조에는 저마다 다양한 종류의 요소와 관계가 있고, 따라서 이런 구조를 통해 아키텍처의 특정 측면을 파악할 수 있는 시각을 얻을 수 있다. "외부에 드러나는 속성"이란 어떤 컴포넌트에 대해 다른 컴포넌트들이 두고 있는 가정을 말한다. 예를 들어 컴포넌트에서 제공하는 서비스나 품질속성의 특성, 공유자원에 대한 사용 등을 일컫는다. 아키텍처는 시스템과 그 시스템을 개발하는 프로젝트 양쪽 모두에 대해 청사진의 역할을 한다. 특히 개발 프로젝트에서는 설계나 구현팀에서 수행해야 할 작업할당 내용을 정의할 때 쓰인다. 아키텍처는 성능, 변경용이성, 보안 등과 같은 시스템의 품질을 보장하는 최선의 방법이다. 이런 품질들은 하나같이 통합적인 아키텍처적 시각 없이는 달성할 수 없는 것들이다. 아키텍처라는 산출물은 채택한 설계 안을 가지고 수용 가능한 시스템을 만들어 낼 수 있는지를 확인하는 데 필요한 초기 분석에도 쓸 수 있다. 아키텍처는 배포가 끝난 상황에서 시스템을 이해하고, 유지보수하며, 정보를 뽑아내야 하는 경우에도 핵심적인 역할을 한다. 간단히 말해서 아키텍처는 프로젝트 상의 모든 단계와 프로젝트와 관련된 모든 이해관계자들을 연결해 주는 개념적인 접착제라고 할 수 있다. 아키텍처 문서화 작업은 아키텍처를 수립하는 과정에서 화룡점정에 해당한다. 완벽한 아키텍처라 하더라도 그 내용을 제대로 전달할 수 없다면 아무 쓸모가 없다. 강력한 아키텍처를 만들어 내고자 한다면 모호함 없이 충분히 자세하게 기술해야 하고, 다른 사람들이 필요한 정보를 재빨리 찾을 수 있는 형태로 내용을 구성해야 한다. 그렇게 하지 않으면 그 아키텍처를 활용할 수 없어서 결국 헛수고가 되고 만다. 이 책을 읽을 독자들은 주로 아키텍처 문서를 생산하거나 소비하는데 관련된 사람들, 즉 소프트웨어 개발자들일 것이다. 이 책의 목표는 개발자들이 아키텍처에 대한 정보 중에서 어떤 것들을 찾아내서 기록해야 하는지 결정하는 데 도움을 주고, 또 그런 정보를 기록할 때 필요한 지침, 표기법, 예제 등을 제공하는 데 있다. 저자들은 이 책이 아키텍처를 구성하는 다양한 종류의 정보를 다루는 데 있어 실무자 중심의 지침궼가 될 수 있도록 했다. 또한 저자들은 사람들이 아키텍처 기반의 업무, 즉 구현, 분석, 복구 등의 업무를 수행할 때 아키텍처를 활용할 수 있게 정보를 기록하는 방법을 UML을 비롯한 다양한 표기법으로 만든 예제를 통해 보여주고자 했다. 이에 따라 이 책에는 다음과 같은 내용이 담기게 됐다. ● 소프트웨어 아키텍처 문서 활용: 문서를 어떻게 작성하느냐는 그 문서를 어떻게 활용하기를 원하는지에 달렸다. 이 책에서는 아키텍처 문서화에 서 실현 가능한 최종 목표들을 설정하고, 그렇게 설정한 개별 목표에 맞는 문서화 전략을 제공한다. ● 아키텍처 뷰: 소프트웨어 아키텍처 문서화는 기본적으로 관련 뷰들을 문서화한 다음, 이 정보에 뷰 이외의 관련 정보를 보강하는 작업이다. 이 책의 핵심은 가장 관련이 깊은 아키텍처 뷰들을 뷰타입이라 불리는 세 가지 주요 군으로 묶고, 이를 실제 문서로 옮길 수 있는 실질적인 지침을 넣은 데 있다. 또한 각 뷰타입마다 예제도 제시해 놓았다. ● 정보 패키지화: 뷰에 대해 이해하고 나면 남는 문제는 관련 뷰들을 선택하고, 개별 뷰에 들어가지 못한 정보를 찾아낸 다음, 그 모든 정보를 모아서 일관된 하나의 패키지로 만드는 일이다. 저자들은 이 모든 측면들에 대해 실질적인 조언을 제시하고자 한다. 우리 저자들은 시스템을 성공적으로 구축하려면 아키텍처가 매우 중요하다고 굳건히 믿고 있다. 그러나 효과적으로 의사소통할 수 없는 아키텍처로는 불가능하다. 또한 성공적인 의사소통의 핵심은 문서화에 있다. 모쪼록 이 책이 현장 실무자들에게 매우 쓸모 있는 안내서가 되기를 바라 마지 않는다. - 폴 클레멘츠, 텍사스 오스틴 - 펠릭스 바크만, 렌 베스, 데이비드 갈란, 제임스 이버스, 리드 리틀, 로버트 노드, 쥬디스 스태포드, 펜실베니아 피츠버그 --- '저자 서문' 중에서 |
|
소프트웨어 아키텍처를 다룬 정전들을 우리말로 옮겨서 펴내고자 마음 먹은 이래로 『소프트웨어 아키텍처: 이론과 실제』를 내고 이제 두 번째 책인 『소프트웨어 아키텍처 문서화』를 내게 됐습니다. 앞의 책이 소프트웨어 아키텍처에 대한 총론이라면, 이번 책은 소프트웨어 아키텍처 문서화에 집중한 각론에 해당합니다. 책의 구성으로 봐도 앞의 '이론과 실제' 책에서는 9장 한 장에서만 '소프트웨어 아키텍처 문서화'라는 제목으로 다뤘던 내용을 이번 책에서는 한 권 전체에 걸쳐 다루고 있습니다. 그만큼 아키텍처 문서화에 대해 필요한 거의 모든 내용을 다룬 전문서라 봐야 할 것입니다. 더불어 '이론과 실제' 11장에서 소개한, 'ATAM'을 필두로 한 소프트웨어 아키텍처 평가 방법들을 집중적으로 소개한 책도 조만간 나올 예정이라 하니, 우리 나라 업계에서도 소프트웨어 아키텍처 분야가 자리잡기 위한 구색이 점차 갖춰져 가는 느낌에 가슴이 뿌듯해 집니다.
한편, 이런 책들은 모두 원서가 2003년부터 2004년 즈음에 나온 것들로, 4~5년이나 지난 오늘에 와서 우리말로 번역돼 나온다는 사실이 안타깝기도 합니다. 어쨌든 이런 식으로 소프트웨어 아키텍처에 대한 총론서와, 세부 주제들을 집중적으로 다룬 각론서가 하나 둘씩 우리말로 소개되면서 소프트웨어 아키텍처라는 분야에 대한 지식이 대중화되고, 그로써 저희 역자들뿐 아니라 많은 독자들께서 동경하는 소프트웨어 아키텍트라는 역할이 좀 더 명확히 이해되고, 또 어떻게 하면 그 역할을 더 잘 할 수 있는지 지침이 제시되면서 업계에서 확고히 자리잡을 수 있지 않을까 기대합니다. 카네기 멜론 대학교의 소프트웨어 아키텍처 과목 교수이며, 저희 역자들에게 '저런 아키텍트가 되면 정말 멋지겠구나'라는 생각을 품게 해 준 역할 모델인 Anthony Lattanze 교수님이 했던 말이 기억납니다. "자네들 모두 소프트웨어 아키텍트가 되고 싶은 거 아네. 그런데 그거 아는가? 아키텍트가 하는 일 중에 98%는 모두 따분하고 재미없는 문서화 작업이라는 거. 나머지 한 2% 정도만 자네들이 신나고 재미있어 하는, 뭔가를 설계하고 결정하는 일이지. 힘 빠지는 얘기겠지만, 어쩌겠는가? 대부분의 전문분야가 다 이런 식으로 돌아가는걸. 약간의 매력적인 작업을 위해 하기 싫은 일을 견뎌내는 거지. 하지만 진짜 전문가는 하기 싫은 일을 효과적으로, 되도록 재미있게 하는 사람이야." 그렇지 못한 사람은 아마추어라는 말씀이시겠지요. 문서화 작업은 따분하고 재미없는 데서 그치지 않고, 하기 싫어서 미루다 보면 종국에는 고통스럽기까지 하더군요. 고통은 어디서 올까요? 부처님 말씀으로는, 무지에서 온다고 합니다. 그렇다면 혹시 제대로 알면 따분하고 재미없고 심지어 고통스럽기까지 한 문서화 작업이 재미있게 다가올까요? 전적으로 그런지는 모르겠지만, 알고 나면 흥미가 일고, 흥미가 일면 재미는 금방이지 않을까요? 이 책은 소프트웨어 문서화라는 게 무엇이고, 잘 하려면 어떤 원칙을 지켜야 하는지 설명하고, 소프트웨어 아키텍처 문서화에서 다뤄야 할 내용이 무엇인지 정리해 놨습니다. 따라서 아키텍처에는 관심이 있지만 문서화에는 관심이 없는 분들(언제까지고 그럴 수는 없겠지만!)도 아키텍처에서 다루는 내용이 어떤 것들인지 좀 더 심도 있게 살펴보거나, 아키텍처를 어떤 모습으로 구성해야 하는지 살펴보는 데 도움이 될 것입니다. 한 가지 양해를 구할 것은, 책 내용에 쉽지 않은 부분이 많아 독자들 눈에 거슬리는 부분이나 어색한 부분이 있지 않을까 하는 것입니다. 특히 90페이지 가까이 되는 소프트웨어 아키텍처 문서화 실전 예제 부록이 그런 부분이 아닐까 싶습니다. 원저자들이 '대규모 프로젝트 문서화 이렇게 한다!'를 사실적으로 보여주기 위해 전형적인 예제를 넣은 것인데, 안타깝게도 다루는 내용이 인공위성에서 데이터를 수집해 가공, 배포하는 쪽입니다. 분야가 워낙 독특하고 국내에서 접하기 힘든 내용들이라, 저희 역자들도 우리말 어휘나 표현으로 적절히 옮기기 어려운 점이 많았습니다. 간혹 틀린 데가 있더라도 독자들의 너그러운 양해 바랍니다. 끝으로 이 자리를 빌어 투박한 번역 원고를 검토해 여러 가지 고칠 곳을 지적해 주신 맹주원님과 정희종님, 엄태욱님께 감사 드립니다. 또한 원저자 중 한 분으로, 한국인 제자들이 자신이 쓴 책을 번역한다는 소식을 듣고 특별히 한국어판 추천의 글을 써 주신 카네기 멜론 대학교의 David Garlan 교수님께도 감사의 말씀을 전합니다. 2009년 1월 13일 역자 일동 --- '옮긴이의 말' 중에서 |
출판사 리뷰
|
소프트웨어 아키텍처를 다루는 실무자들이 꼭 읽어야 할 책. 소프트웨어 아키텍트로서 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여준다.
정말 간단한 것 외에 모든 소프트웨어 시스템은 아키텍처에 큰 관심을 기울여야 한다. 프로젝트에 관련된 많은 이해관계자 입장에서 프로젝트의 모든 단계를 연결해 주는 개념적 접착제 역할을 하는 바로 그 소프트웨어 아키텍처 말이다. 문제를 제대로 해결할 수 있는 아키텍처가 없으면 프로젝트가 휘청거리다가 결국 실패하고 말 것이다. 물론 뛰어난 아키텍처가 있다고 해도 그것을 사람들에게 제대로 이해시키거나 전달하지 못한다면, 다시 말해 제대로 문서화하지 못한다면, 프로젝트가 제대로 성공한다고 보기 어렵다. 요즘 들어서 아키텍처가 매우 중요한 요소로 널리 받들어지기는 하지만, 언어나 표기법에 얽매임 없이 제대로 포착해내는 방법이나 지침이 아직은 뚜렷이 없었다. 이 책 『소프트웨어 아키텍처 문서화』에서는 저자들의 폭넓은 경험을 바탕으로 어떤 정보를 문서에 기록해야 하는지 결정하고, 그런 다음에 필요한 지침들과 UML 등 다양한 표기법으로 작성한 예제들을 가지고 누구나 이해할 수 있는 형태로 아키텍처를 표현하는 방법을 보여주고 있다. 강력한 아키텍처를 만들어내려면 그 결과로 나올 아키텍처를 설명하는 일도 매우 상세하면서 깔끔하게 해낼 수 있어야 하고, 아키텍처의 구성도 잘해야 한다. 그래야 사람들이 필요한 정보를 빠르게 찾아낼 수 있다. ■ 좋은 문서를 만드는 일곱 가지 규칙 ■ 소프트웨어 아키텍처를 활용하는 용도, 목표, 전략 ■ 아키텍처 뷰와 스타일에 대한 일반적인 소개와 구체적인 예제 ■ 소프트웨어의 인터페이스와 행위에 대한 문서화하는 방법 ■ 정보를 수집해서 일관성을 갖춘 패키지로 만드는 데 도움이 되는 문서 양식 서장에서는 이 책을 읽는 데 꼭 필요한 개념과 용어에 대해 정리한다. 여기서는 소프트웨어 아키텍처 문서를 어떻게 사용할 것이고, 그것이 왜 중요한지를 살펴본다. 그리고 아키텍처 뷰타입과 스타일과 뷰라는, 이 책에서 채택한 문서화 접근법의 근간을 이루는 세 가지 개념을 정의한다. 또한 좋은 문서를 만드는 7가지 규칙에 대해서도 소개한다. 1부 소프트웨어 아키텍처 뷰타입과 스타일에서는 소프트웨어 아키텍처 문서화에 쓰이는 기본적인 도구인 뷰타입을 소개한다. 뷰타입이란 뷰에서 제공되는 정보의 종류를 명세해 놓은 것이다. 뷰타입에는 기본적으로 모듈, 컴포넌트와 커넥터, 할당이라는 세 가지가 있다. 개별 뷰타입 내에는 여러 가지의 아키텍처 스타일이 있다. 아키텍처 스타일은 뷰타입을 특화시켜 놓은 것으로 보면 된다. 1부 도입부에 1장부터 5장에 걸쳐 설명할 스타일들에 대한 간략한 목록을 넣어 놓았다. 2부 소프트웨어 아키텍처 문서화의 이론과 실제에서는 제대로 된 아키텍트라면 반드시 만들어 내야 하는 완전한 구성의 아키텍처 문서 패키지에 중점을 둔다. 다시 말해 2부에서는 1부에서 제시한 그림을 완성하는 과정을 설명한다. 이 책은 소프트웨어 프로젝트에서 아키텍처 문서를 작성하는 책임을 진 아키텍트와 기술문서 작성자들을 주 대상으로 해서 썼다. 물론 아키텍처 문서를 받아서 활용하는 입장에 있는 사람들도 함께 염두에 뒀다. 소프트웨어 아키텍트들은 이 책을 자신이 작성한 아키텍처 문서와 함께 제공하고 문서화 구성 원칙, 표기법, 개념, 관례 등을 설명한 해당 절을 적어놓는 방식을 활용하면 좋을 것이다. 이 책은 기본적으로 독자들이 소프트웨어 아키텍처 개념과 친숙한 상태에 있다고 가정하고 썼다. 물론 관련 배경지식을 어디서 얻을 수 있는지도 정보를 제공했다. 앞으로 여러 차례에 걸쳐, 독자들이 이미 친근할 만한 아키텍처 뷰, 아키텍처 스타일, 인터페이스 등과 같은 기본 개념들에 대해 좀 더 명확하게 다듬어서 설명할 것이다. |
