이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
책소개
목차
|
Part 1 시스템 분석 . 설계의 요소
CHAPTER 1-01 UML과 모델링 모델링 기존의 설계서의 문제 UML 액티비티(Activity) 다이어그램 액티비티 다이어그램의 주요 요소 유스케이스 다이어그램(UseCase Diagram) 유스케이스 다이어그램(UseCase Diagram)의 주요 요소 클래스 다이어그램 클래스 다이어그램의 주요 요소 시퀀스 다이어그램 시퀀스 다이어그램의 주요 요소 스테이트 머신 다이어그램 스테이트 머신 다이어그램의 주요 요소 배치 다이어그램 배치 다이어그램의 주요 요소 CHAPTER 1-02 컴포넌트 기반의 개발(CBD: Component Based Development) 컴포넌트 기반의 개발이란 컴포넌트 기반 개발과 SOA SOA를 구축하기 위한 기반 제품 CHAPTER 1-03 모델 드리븐 아키텍처(MDA : Model Driven Architecture) MDA란 MDA의 장점 Part 2 개발 프로세스 CHAPTER 2-01 개발 프로세스 스타일 UML과 개발 프로세스 워터폴 개발 프로세서 이터레이티브 개발 프로세스 CHAPTER 2-02 개발 프로세스의 개요 업무 분석 요구 분석 시스템 분석 아키텍처 설계 시스템 설계 구현 Part 3 시스템을 도입하기에 앞서(업무 분석) CHAPTER 3-01 컴포넌트 기반 모델링 Part 3에서 설명하는 공정 컴포넌트 기반 개발에 관해서 컴포넌트 기반 모델링이란 컴포넌트 정의 CHAPTER 3-02 대상 업무 정리하기 기업에 있어서의 업무 분석 대상 업무의 정리 대상 업무의 분석 액티비티 다이어그램이란 액티비티 다이어그램 작성 포인트 현장의 업무의 흐름을 정리한다(AS-IS) 업무 청취 결과를 액티비티 다이어그램으로 표현한다 현장의 업무 전체를 나타내는 액티비티 다이어그램(AS-lS) CHAPTER 3-03 시스템 도입 후의 모습 표현하기 실무의 문제점 분석과 해결책 검토 시스템 도입 후의 흐름을 정리한다(TO-BE) 개선 후의 업무를 구조화 한다 Part 4 시스템의 도입을 향해(요구 분석) CHAPTER 4-01 시스템화 대상의 결정과 기능요건의 검토 Part 4에서 해설하는 공정 시스템화 대상을 나타낸다 요구 분석이란 유스케이스 다이어그램이란 유스케이스 다이어그램 작성의 포인트 액티비티 다이어그램을 바탕으로 유스케이스 다이어그램 작성 컴포넌트 구성 사양도의 작성 CHAPTER 4-02 소프트웨어 컴포넌트의 기능과 정보 분석 기능요건의 상세화 유스케이스 시나리오란 유스케이스 시나리오 작성의 포인트 유스케이스 시나리오의 기술 방법 유스케이스 시나리오에 의한 유스케이스의 상세 분석 배부를 의뢰한다(대체 시나리오) 배부를 의뢰한다(예외 시나리오) 집하를 지시한다(주 시나리오) 유스케이스 다이어그램에의 반영 시나리오의 대체로서의 액티비티 다이어그램 화면 설계와의 관계 비기능요건의 발견 CHAPTER 4-03 컴포넌트를 추출한다 유스케이스 시나리오로부터 컴포넌트 추출 시스템기능 컴포넌트를 추출한다 유스케이스 시나리오를 분할한다 컴포넌트 구성 사양도에의 반영 컴포넌트의 분할 Part 5 구조와 행동의 정의(시스템 분석) CHAPTER 5-01 오브젝트 다이어그램의 작성 Part 5에서 설명하는 공정 오브젝트 다이어그램 오브젝트 다이어그램의 작성 방법 유스케이스 시나리오에서 오브젝트를 선별하여 쓴다 오브젝트 간의 링크를 정의한다 CHAPTER 5-03 구조를 기술한 분석클래스 다이어그램의 작성 분석클래스 다이어그램이란 구조를 기술한 분석클래스 다이어그램의 작성 방법 클래스, 관련의 종류, 다중도(multiplicity)를 정의한다 클래스와 속성을 재점검하다 유스케이스 다이어그램, 시나리오 유스케이스에 반영 CHAPTER 5-03 스테이트 머신 다이어그램과 화면전이 다이어그램의 작성 스테이트 머신 다이어그램이란 스테이트 머신 다이어그램 작성 방법 화면전이 다이어그램을 작성한다 CHAPTER 5-04 분석 모델을 기술하는 아키텍처의 결정 파울러의 아키텍처 CHAPTER 5-05 상호작용개요 다이어그램과 분석시퀀스 다이어그램의 작성 상호작용개요 다이어그램과 시퀀스 다이어그램 상호작용개요 다이어그램 작성의 포인트 분석시퀀스 다이어그램이란 분석시퀀스 다이어그램 작성의 포인트 “ 배부처를 결정한다”의 분석시퀀스 다이어그램 “ 판매증가 자료를 결정한다”의 분석시퀀스 다이어그램 “ 배부의뢰를 작성한다”의 분석시퀀스 다이어그램 CHAPTER 5-06 분석클래스 다이어그램에 행동 추가 및 패키지 나누기 구조와 오퍼레이션의 정의 오퍼레이션을 추가한 분석클래스 다이어그램의 작성 분석클래스 다이어그램의 작성 패키지 나누기 패키지 나누기의 방법 규칙에 따라 패키지를 나눈다 Part 6 시스템화를 향해서 CHAPTER 6-01 시스템 아키텍처의 선정 Part 6에서 설명하는 공정 아키텍처를 결정하기 위한 정보 아키텍트의 직책 시스템 아키텍처의 선정 CHAPTER 6-02 프레임워크의 선정 어플리케이션 아키텍처에서 필요한 요소 CHAPTER 6-03 패턴의 정의 패턴 적용의 장점 코러블레이션에 의한 패턴의 표기방법 프레임워크 적용 형태의 패턴화 파사드 패턴 DAO/DTO 패턴 Struts 패턴 JSF 패턴 ORM(Hibernate) 패턴 DAO/DTO-ORM(Hibernate) 패턴 DI(Spring) 패턴 Spring-JSF 패턴 Spring-Hibernate 패턴 DAO/DTO-Spring-Hibernate 패턴 패턴의 최적화 Part 7 논리모델의 도출과 패턴의 적용/전개 CHAPTER 7-01 논리클래스 다이어그램의 작성 Part 7에서 설명하는 공정 논리클래스 다이어그램 및 시퀀스 다이어그램 작성 방법 고려할 점 1 (배부의뢰 오브젝트 구조의 명확화) 고려할 점 2 (각 엔티티의 라이프 사이클 명확화) 고려할 점 3 (재고배당 처리의 명확화) 고려할 점 4 CHAPTER 7-02 패턴의 적용 및 코드 작성 정의한 패턴을 적용한다 서비스의 그루핑(grouping) Struts 패턴과 DAO/DTO 패턴의 적용 “ 배부처를 조회한다” “배부처를 선택한다”의 패턴 적용 결과 적용 후의 소스코드 Spring-JSF 패턴과 DAO/DTO-Spring-Hibernate 패턴의 적용 Part 8 MDA툴 최신 동향 CHAPTER 8-01 MDA툴의 이해 MDA툴의 목적 CHAPTER 8-02 uCosminexus Developer에 의한 변환 예 uCosminexus Developer의 모델 환경툴의 이해 적용 패턴과 변환 예(구조 모델 → 구현 모델) 모델의 변환(분석 모델 → 구조 모델) 모델의 변환(구조 모델 → 구현 모델) CHAPTER 8-03 medini Componenet Modeler에 의한 변환 예 medini Component Modeler의 이해 모델의 기술 사례 Appendix 부록 A. 전체 시스템 구축 공정과 아웃풋 도큐먼트 B. 패턴위버의 활용 |
품목정보
- 발행일
- 2008년 05월 30일
- 쪽수, 무게, 크기
- 375쪽 | 972g | 188*254*30mm
- ISBN13
- 9788958971269
책 속으로
|
가끔 “컴포넌트 개발은 잘 된 적이 없다”, “컴포넌트화는 영원한 과제다”라는 말을 듣는다.
“그것은 절대 그렇지 않습니다.” 그렇게 말하는 사람들의 개발 과정을 살펴보면 그 원인을 찾아볼 수 있다. 즉, 컴포넌트를 보여주는 개발 프로세스에 따라서 만들지 않았거나 컴포넌트를 사용하는 구조나 체제로 운용을 하지 않았기 때문이다. 아니면 처음부터 컴포넌트화를 포기했기 때문이다. 이것이 컴포넌트 개발이 어렵다고 여겨지는 원인이다. 나는 메인프레임이 주류를 이루고 있을 때, OS와 DBMS 등의 소프트웨어 제품을 개발한 적이 있었다. 당시는 「컴포넌트」라고 하지 않고, 「모듈」이라고 불렀는데, 기능 단위로 정확히 모듈화되어, 자신이 개발하는 모듈은 다른 모듈로부터 호출되거나 다른 모듈을 호출하여 처리하는 구조로 프로그램 개발이 이루어지고 있었다. 게다가 대부분의 OS나 DBMS 개발부서 등의 모든 부서에서 공통으로 사용할 수 있는 공통 로직(매크로)은, 사내의 어떤 팀이 개발해서 제공하는 장치로 만들어지고 있었다. 당시엔 이것이 당연한 개발 형태라고 여겨졌다. 또, 한때 나는 업무 어플리케이션 개발에도 종사한 적이 있었다. 어느 날, 메인 프레임의 프로그램을 신규로 오픈화 시스템으로 새로 바꿀 기회가 있어서 지금까지 만들어왔던 프로그램 내의 처리를 분석했다. 그 결과 곳곳에 중복 로직이 섞여 있어서, 아연실색하며 스스로 크게 반성을 한 적이 있다. 중복 로직의 원인의 첫 번째는 업무 어플리케이션이라면 처음부터 끝까지 스스로 만들어 버리는 편이 빠르다는 생각이었고, 두 번째는 개발기법에 있어서 공통화 프로세스를 갖지 않았기 때문이었다. 당연히 공통화 프로세스의 운용 장치가 없었고, 제품 개발과 같이 확실한 개발 시스템을 갖추고 있지 않았다. 그 후, Java 개발에서 「컴포넌트화」를 의식하며 추진해 왔지만, 오브젝트 지향 개발의 일반적인 기법을 채용한 탓에 상세 설계 공정에서 「컴포넌트화」를 실시하려고 하여 매번 실패했다. 상세 설계 공정에서는 컴포넌트를 꺼내는 것이 보기 힘들다는 점과 공정이 빠듯하여 프로젝트 전체가 「컴포넌트화」할 입장이 되지 않은 것이 실패의 원인이었다. 많은 시행착오를 겪으며 내가 내린 결론은「컴포넌트화」는 역시, 상위 단계의 개발 프로세스에서 설계해야 한다는 것이다. 또한 업무 분석 단계에서 의식적으로 「컴포넌트화」부분을 도출해 설계?개발과 묶어, 그것들을 잘 운용하는 장치와 체제를 만드는 것, 그것이 「컴포넌트화」성공의 비결이라는 것이다. 그리고 지금까지 그 방법을 수많은 정보 시스템의 개발 현장에서 적용하며 실천해 왔다. 최근, SOA에 의한 정보 시스템이 주목받고 있다. SOA의 「서비스」를 구성하는 요소가 「컴포넌트」라고 생각한다. 따라서, SOA의 성공 비결 중의 하나로 「컴포넌트화」를 정확히 설계할 수 있는가 하는 점을 들 수 있다. 이 책에서는, 업무 분석 단계부터 「컴포넌트화」를 의식해서 분석, 설계, 개발로 묶여있는 현장의 사례를 모델로 설명하였다. 이 책이 「컴포넌트화」에 대해서 개운치 않게 여기고 있는 분, 또는 포기하고 있는 분, 이제부터 「컴포넌트화」를 진행하려고 하고 있는 분들에게 일조할 수 있다면 좋겠다. --- 본문 중에서 |
출판사 리뷰
|
UML을 가장 폭넓게 이용할 수 있게 한 실천서가 출간되었다.
UML을 어플리케이션 설계용으로만 사용하던 시대는 지났다. 이제는 업무 분석부터 시스템 개발에 이르기까지 UML을 얼마나 활용하느냐 하는 것이 중요해졌다. 이것은「UML=오브젝트 지향 기술」을 말하는 것이 아니라 업무의 정리나 시스템화 또는 SOA를 이용한 서비스 구축 등의 광범위한 이용을 말한다. 그리고 이를 위해서는, 오브젝트 지향보다는「컴포넌트」나 「서비스」라는 생각으로 UML을 사용해야 한다. 이 책은 UML 방법론을 설명한 이론서가 아니다. 본격적인 실천서이다. 그래서 대규모 시스템 개발에 실제로 사용되고 있는 방법을 채택하여 실었다. 현재 UML을 습득하여 어플리케이션을 설계하는데 사용하고 있지만, 더욱 본격적으로 사용하고 싶은 독자들에게 안성맞춤이다. 꼭, 이 책을 보다 차원 높은 시스템 개발에 활용하기를 바란다. |
