| 000 | 00837namccc200301 k 4500 | |
| 001 | 000000827001 | |
| 005 | 20100806010520 | |
| 007 | ta | |
| 008 | 030320s2003 ulka 001c kor | |
| 020 | ▼a 895674078X ▼g 93000 : ▼c \18000 | |
| 035 | ▼a KRIC08602953 | |
| 040 | ▼a 246008 ▼d 211009 | |
| 041 | 1 | ▼a kor ▼h eng |
| 049 | 1 | ▼l 111248415 |
| 082 | 0 4 | ▼a 005.117 ▼2 21 |
| 090 | ▼a 005.117 ▼b 2003c | |
| 100 | 1 | ▼a Starr, Leon |
| 245 | 1 0 | ▼a UML 설계와 응용 : ▼b 클래스 모델 만들기 / ▼d 리안 스테어 著 ; ▼e 김인기 譯. |
| 246 | 1 9 | ▼a Executable UML |
| 260 | ▼a 서울 : ▼b 정보문화사 , ▼c 2003. | |
| 300 | ▼a 407 p. ; : ▼b 삽도 ; ▼c 25 cm. | |
| 500 | ▼a 색인수록 | |
| 650 | 0 | ▼a Application software ▼x Development. |
| 650 | 0 | ▼a UML (Computer science) |
| 700 | 1 | ▼a 김인기, ▼e 역 |
| 740 | 0 | ▼a 클래스 모델 만들기. |
| 900 | 1 1 | ▼a 스테어, 리안 |
소장정보
| No. | 소장처 | 청구기호 | 등록번호 | 도서상태 | 반납예정일 | 예약 | 서비스 |
|---|---|---|---|---|---|---|---|
| No. 1 | 소장처 중앙도서관/제2자료실(3층)/ | 청구기호 005.117 2003c | 등록번호 111248415 (4회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
컨텐츠정보
책소개
클래스 모델은 소프트웨어 스펙을 정확하게 표현할 수 있는 훌륭한 수단이다. 작성된 스펙은 테스트와 디버깅이 가능하고 여러 프로그래밍 언어와 플랫폼에서 실행되는 코드로 변환이 가능하다. 이 책은 Executable UML을 사용해서 어떻게 정확한 클래스 모델을 작성하는지에 대해 알려준다.
저자가 수행했던 리얼타임 분야의 프로젝트들로부터 다양하고 흥미로운 예를 도입해서 설명하고 있으며, 책에 사용된 모든 다이어그램들은 Executable UML의 표기법을 이용해서 작성되었다.
다음 내용들을 포함한다.
【 이 책의 특징 】 Executable UML로 클래스 모델을 작성하기 위한 실전 가이드리안 스테어(Leon Starr)는 이 책을 통해 Executable UML을 사용해서 어떻게 정확한 클래스 모델을 작성하는지에 대해 설명하고 있다. 클래스 모델은 소프트웨어 스펙을 엄밀하게 표현할 수 있는 훌륭한 수단이다. 이렇게 작성한 스펙은 테스트와 디버깅이 가능하고 여러 프로그래밍 언어와 플랫폼에서 실행되는 코드로 변환시킬 수 있다. Leon은 자신이 수행했던 리얼타임 분야의 프로젝트들로부터 다양하고 흥미로운 예들을 도입해서 설명하고 있다. 리얼타임 분야는 다른 어떤 분야보다 정교하고 분명한 소프트웨어 스펙을 필요로 하는 분야이다. 이전 도서 {How to Build Shlaer-Mellor Object Models}와 마찬가지로, 리안 스테어는 이 책에서도 Executable UML을 적극적으로 소개하고 있다. 이 책의 모든 다이어그램들은 Executable UML의 표기법을 이용하여 작성되었다. 여러분이 어떤 분야의 애플리케이션을 개발하더라도 여러분은 Executable UML을 이용하여 신뢰성 있는 소프트웨어를 개발할 수 있다. Executable UML은 어떤 하드웨어나 어떤 소프트웨어 플랫폼에서도 손쉽게 사용할 수 있다. 【 이 책의 내용 】- Executable UML로 클래스와 속성을 표현하는 방법 - 클래스 사이의 연관관계 - 양자간 연관관계의 특징과 연관관계 클래스 - 구체화(specialization) 관계와 일반화(generalization) 관계 - (연관관계) 루프와 루프의 제한 요소들 - 재귀 패턴, 네트웍 패턴, 선형 패턴, 트리 패턴 등을 이용한 효과적인 모델링 기법 저자 소개저자 리안 스테어(Leon Starr)1985년부터 Executable 모델을 이용해서 리얼타임 임베디드 소프트웨어를 개발해왔다. 그는 공장의 물류 시스템, 초음파 진단 기구, 심장병 보조 의료 기구, 가스 크로마토그래피를 이용한 반도체 웨어퍼 검사 장비, 동영상 편집 장비, 네트웍 전투 시뮬레이터 등 다양한 분야의 애플리케이션에 대한 모델을 작성해왔다. 그는 {How to Build Shlaer-Mellor Object Models}와 {Executable UML: A Case Study}의 저자이며, 현재 샌프란시스코에 위치한 Model Integration, LLC 사의 창립 멤버이자 선임 컨설턴트로 활동하고 있다. 역자 김인기한양대학교 대학원 전기공학과를 졸업하여 삼성중공업 중앙연구소와 성진씨앤씨를 거쳐 현재는 파수닷컴에서 DRM(Digital Rights Management) 시스템 개발에 관한 일을 하고 있다. 지금까지 리얼타임 임베디드 시스템과 윈도우즈 기반의 애플리케이션 개발에 관련된 일을 해왔으며, 또한 UML과 디자인 패턴을 이용한 시스템 설계에 많은 관심을 가지고 있다. 이 외의 관심 분야로는 COM/COM+ 등의 분산 컴포넌트 환경이며, 특히 요즘은 닷넷(.NET)에 몰두하고 있다. - 변역서 : "Understanding Active Directory Services", 정보문화사, 2000년
정보제공 :
저자소개
리안 스테어(지은이)
1985년부터 Executable 모델을 이용해서 리얼타임 임베디드 소프트웨어를 개발해왔다. 공장의 물류 시스템, 초음파 진단 기구, 심장병 보조 의료 기구, 가스 크로마토그래피를 이용한 반도체 웨어퍼 검사 장비, 동영상 편집 장비, 네트워크 전투 시뮬레이터등 다양한 분야의 애플리케이션에 대한 모델을 작성해왔다. 현재 샌프란시스코에 위치한 Model Integration, LLC 사의 창립 멤버이자 선임 컨설턴트로 활동하고 있다. 지은 책으로는 <How to Build Shlaer-Mellor Object Models>와 <Executable UML : A Case Study>가 있다.
김인기(옮긴이)
한양대학교 대학원에서 전력전자를 전공하고, C/C++ 프로그래머로서 20여 년간 리얼타임 임베디드 솔루션과 윈도우 기반 솔루션을 개발하고 있다. 그동안 군더더기 없이 간결한 시스템을 만들기 위해 노력했으며, 지금은 SK텔레콤에서 새로운 모바일 솔루션을 기획하고 있다. 새로운 것 배우기를 좋아하고, 어떻게 하면 세상을 편하게 할 제품을 만들 수 있을지와 어떻게 하면 그런 제품을 만드는 개발자를 편하게 만들 수 있을지를 고민한다.
목차
목차 서문 : Executable UML이란 무엇인가? = 25 왜 Executable UML을 이용하는가? = 26 스펙의 발전 과정 = 28 문장으로 서술한 스펙 = 28 기호로 표시한 스펙 = 29 Executable 스펙 = 33 스펙은 어떻게 구현되는가? = 37 모델 컴파일러의 이용 = 39 변환 기술 요소 = 40 왜 변환하는가? = 43 요약 = 46 제1부 기본적인 모델링 도구들 Chapter 1. 클래스 = 49 클래스란 무엇인가? = 50 클래스 기호 = 50 클래스와 인스턴스(instance)의 차이점 = 51 클래스 테이블에 대해... = 52 클래스 테이블 규칙 = 52 데이터의 최소 단위는 속성이다 = 53 인스턴스의 순서는 무시된다 = 54 속성의 순서는 무시된다 = 55 각 인스턴스는 고유하다 = 55 클래스의 종류 = 56 물질적인 클래스 = 57 소프트 클래스 = 58 발견된 클래스들 = 58 창조된 클래스들 = 58 실험된 클래스들 = 59 스펙 클래스들 = 59 사건에 관한 클래스들 = 64 관계에 관한 클래스들 = 65 역할 클래스들 = 67 클래스에 관한 잦은 질문들 = 69 속성이 하나뿐인 클래스를 만들어도 문제 없는가? = 69 클래스 인스턴스가 하나만 존재할 수 있는가? = 72 Chapter 2. 속성 = 73 속성이란 무엇인가? = 74 목적 = 75 설명 속성 = 75 이름 속성 = 75 이름 속성 또는 설명 속성? = 76 식별을 위한 역할 = 76 암묵적 식별자 = 77 단일 속성 식별자 = 78 복합 식별자 = 79 참조용 속성 = 80 여러 개의 식별자들 = 81 중복 식별자 = 82 다른 속성에 대한 의존관계 = 83 식별자에 대한 의존 = 83 식별자 전체에 대한 의존 = 86 값의 할당 = 87 식별자가 아닌 속성 값의 변경 = 88 식별자 속성 값의 변경 = 88 연산에 의한 의존관계 = 89 의미의 일반성 = 90 언제나 의미를 갖는 속성 = 90 (어떤 인스턴스들에게는) 아무 의미가 없는 속성 = 90 어떤 순간에 - 의미를 잃는 속성 = 92 늦게 값이 할당되는 속성 = 93 하나 이상의 의미를 갖는 속성 = 94 속성의 기원 = 97 네이티브 속성 = 98 참조 속성 = 98 속성의 기원과 식별자 = 98 속성의 특징에 대한 요약 = 100 속성에 관한 잦은 질문들 = 101 클래스는 얼마나 많은 속성을 가질 수 있는가? = 101 언제나 클래스의 고유함을 보장할 수 있는가? = 101 Chapter 3. 관계 = 105 연관관계란 무엇인가? = 106 연관관계를 추상화하기 = 108 연관관계의 기호 = 108 연관관계와 규칙들 = 108 관계는 애플리케이션 정책을 정의한다 = 109 관계의 중요성 = 113 관계의 종류 = 114 연관관계 종류에 따른 표기법 = 115 포테이토 다이어그램 = 115 양자간 비재귀적 관계 = 116 양자간 비재귀적 관계 : 클래스가 다른 두 인스턴스 사이의 관계 = 116 "양자간"이란 두 개의 참가자가 있음을 뜻한다 = 116 각 참가자 역할의 이름과 참여개수 = 117 양자간 재귀적 관계 = 117 하나의 클래스, 두 개의 참여자 = 118 참여자 역할의 대칭성, 비대칭성 = 118 사이클 = 119 연관관계와 링크 = 119 연관관계 클래스 = 119 연관관계 속성이 위치할 자리 = 120 연관관계가 어떤 행동양식을 가질 수도 있다 = 121 의존성 = 121 일반화관계 = 121 심지어 집합 속의 집합도 다음과 같이 모델링할 수 있다 = 123 Executable UML 관계에 대한 요약 = 124 Chapter 4. 양자간 연관관계 = 125 인스턴스(구체적인 사물, instance)와 추상적인 개념(abstraction)을 혼돈하지 말라 = 126 어떻게 정리해야 하는가? = 126 아이콘 = 127 작은 블록, 점, 연결선 = 127 테이블 = 128 양자간 비재귀적 관계 = 128 양자간 비재귀적 관계 : 클래스가 다른 두 인스턴스 사이의 관계 = 128 참여개수 = 129 일대일 = 129 일대다 = 131 다대다 = 132 조건부 관계 = 134 재귀적 관계 = 136 양자간 재귀적 관계 : 같은 클래스의 인스턴스들 사이의 관계 = 137 언제 재귀적 관계를 이용하는가? = 137 왜 순서를 일련번호로 관리하지 않았는가? = 139 좀더 많은 예제들 = 139 Chapter 5. 연관관계 클래스 = 141 양자간 링크 만들기 = 144 연관관계 클래스의 인스턴스 만들기 = 144 왜 연관관계 클래스를 만드는가? = 144 연관관계 클래스와 참여개수 = 146 한 개의 링크에 한 개의 연관관계 클래스 인스턴스 = 147 한 개의 링크에 여러 개의 연관관계 클래스 인스턴스 = 148 해결방법 1 = 149 해결방법 2 = 150 연관관계 클래스와 조건부 참여개수 = 152 한쪽이 조건부인 경우 = 152 양쪽이 모두 조건부인 경우 = 154 연관관계 클래스에 관한 잦은 질문들 = 156 하나의 연관관계 클래스에 세 개 이상의 클래스가 참여할 수 있는가? = 156 연관관계 클래스는 어떻게 이름 짓는가? = 157 Chapter 6. 연관관계 이름 짓기 = 159 연관관계를 모델링하는 잘못된 방법 = 161 규칙들을 찾아서 언급하라 = 163 Rule 1 = 164 Rule 2와 Rule 3 = 165 문제 확장하기 = 166 R5 - is compatible with = 169 R4 = 169 R1과 R2 = 170 루프와 제한조건 = 170 동사로 만든 이름 vs. 명사로 만든 이름 = 171 동사를 이용한 문장이 더 좋다 = 172 실용적인 팁들 = 175 포함관계에 대하여 = 176 부정확함 = 176 첫 번째 이유 : 분석보다 코딩을 염두에 두었기 때문이다 = 177 두 번째 이유 : 생각이 부족했기 때문이다 = 177 동사 구문만으로도 충분하다 = 178 요약 = 178 Chapter 7. 루프와 제한조건 = 179 루프란? = 180 첫 번째 실수 : 의미가 중복된 루프 = 181 접근 속도에 대한 고려 = 182 접근 속도를 빠르게 하기 위한 조치를 클래스 모델에 하지 마라 = 182 의미의 중복이 없는 루프 = 183 두 번째 실수 : 의미가 정확하지 못한 루프 = 184 제한조건이 없는 루프 = 184 제한조건이 있는 루프 = 185 제한조건의 적용 = 187 제한조건이 없는 루프가 필요한 경우도 있다 = 188 간단한 루프 = 188 구문(Step)과 구문의 연결에 적용되는 두 가지 제한조건 = 190 요약 = 191 Chapter 8. 일반화관계 : 기초 = 193 일반화관계와 계승관계는 다르다 = 194 분석단계의 목표 = 195 일반화관계를 이용한 분석 = 195 용어 = 196 일반화관계의 예 = 196 관련 인스턴스들 = 198 규칙을 분명하게 정하면, 생각을 분명히 할 수 있다 = 199 Executable UML 일반화관계의 규칙들 = 200 집합의 구분 = 201 집합의 멤버들 = 201 표기법 = 201 세부적인 연관관계와 광범위한 연관관계 = 202 세부적인 규칙과 광범위한 규칙 = 202 많은 규칙들이(지켜질 수밖에 없도록) 강제되었다 = 203 저장 공간을 효율적으로 사용할 수 있다 = 204 동적 모델(dynamic model)의 틀이 된다 = 204 비어있는 Off-Duty 클래스에 대하여 = 204 좀더 다양한 예제들 = 205 복잡한 모델을 단순화시키기 위해 일반화관계를 이용하는 경우 = 206 구체화를 사용할 때 = 210 일반화를 사용할 때 = 210 상호배타적인 관계를 표현하기 위해 일반화관계를 이용하는 경우 = 210 좀더 많은 내용들 = 212 일반화관계에 관한 잦은 질문들 = 213 클래스를 상태별로 구체화해야하는 때는 언제인가? = 213 Chapter 9. 일반화관계 : 고급 = 215 일반화 패턴 = 216 여러 방향 일반화 = 216 여러 방향 일반화가 올바른 방법인가? = 220 여러 방향 일반화가 항상 좋은 답이 될 수 없는 이유는 무엇인가? = 222 멀티레벨 일반화 = 223 정교한 표현이 가능하다 = 225 새로운 요구 사항을 쉽게 수용할 수 있다 = 225 시스템에 대해 깊게 생각할 수 있다 = 226 오버래핑 일반화(선택적인 일반화) = 226 겹쳐진 집합들 = 227 중복된 속성 없애기 = 229 일반화관계를 남용할 때의 문제점 = 230 사소한 문제로 시간을 낭비하지 말라 = 230 불필요한 노력을 줄이는 방법 = 230 일반화 레벨을 어떻게 나눌 것인가? = 231 하위클래스 사이의 이동 = 231 이동하는 하위클래스 = 231 고정적인 하위클래스 = 232 클래스를 상태에 따라 구체화할 때는? = 234 특정 상태에만 필요한 속성이나 연관관계가 있는지 파악하라 = 235 계층을 많이 두지 말라 = 235 잘못된 일반화의 예제 = 236 요약 = 238 제2부 유용한 모델을 만드는 방법 Chapter 10. 생각 없는 모델링을 피하는 방법 = 243 생각 없는 모델링의 결과 = 245 모델링과 분석의 차이점 = 246 분석에 집중하라 = 246 형식에 구애받지 말고 스케치하라 = 247 엄격한 모델과 자유로운 스케치 = 250 Chapter 11. 왜 모델 설명서를 쓰는가? = 255 좋은 설명서는 어떻게 쓰는가? = 257 모델 설명서를 작성하는 다섯 가지 이유 = 257 기술 문서와 모델 설명서는 작성 목적이 다르다 = 258 자만하지 말라 = 258 비디오 효과에 관한 애플리케이션 = 260 해결했던 문제가 다시 제기된다 - "I'll be back" = 261 결정이 내려졌다 = 262 어떻게 같은 문제가 다시 제기되었는가? = 263 시간 절약 = 264 다른 하위시스템의 개발 진도를 촉진시킨다 = 265 수준 높은 피드백을 얻을 수 있다 = 265 구현 작업의 방향을 안내할 수 있다 = 265 우선순위는 언제나 바뀐다 = 266 요약 = 267 Chapter 12. 클래스 설명서 작성법 = 269 의미를 설명하라 - 문법을 설명하지 말라 = 270 문장과 함께 그림을 이용하라 = 274 의사소통을 위해 그림을 이용하라 = 274 그림을 그려서 분석하라 = 275 물질적인 클래스를 그림으로 묘사하라 = 276 소프트 클래스를 그림으로 묘사하라 = 277 작업 도메인에 맞는 용어를 사용하라 = 279 같은 작업 도메인의 다른 모델 요소들을 참조하라 = 279 행동양식을 묘사하라 = 280 행동양식을 자세하게 서술하지 말라 = 282 우유부단하지 말라 = 282 클래스 설명서의 분량은 어느 정도여야 하는가? = 283 어느 정도 자세한 설명이 필요한가? = 284 요약 = 284 Chapter 13. 속성 설명서 작성법 = 287 속성의 의미와 목적 = 289 속성의 의미를 분명히 밝혀라 = 289 그림을 이용하라 = 289 상태 속성 = 290 공개된 상태 = 291 현재 상태와 라이프사이클 = 291 발견된 식별자 속성 = 292 도메인과 데이터 타입 = 293 속성 도메인과 역할 도메인 = 293 데이터 타입 = 294 기본 데이터 타입 = 294 사용자 정의 데이터 타입 = 294 구현 방식과 무관하다 = 295 도메인 설명서 = 295 모호한 표현을 쓰지 말라 = 295 측정 값에는 단위가 필요하다 = 296 센서 중앙에서 반사 물체 표면까지의 거리 = 297 양(量)을 나타내는 값에는 단위가 필요 없다 = 297 정밀도 = 297 구현 방법에 간섭하지 않는다 = 298 좌표계 = 298 좌표계를 명시한다 = 299 내부적인 제한들 = 300 Type 속성 = 300 열거형 도메인과 실수형 도메인 = 301 스펙 클래스를 통해 도메인을 제한한다 = 302 이름 문자열 = 303 요약 = 304 Chapter 14. 연관관계 설명서 작성법 = 305 왜 연관관계 설명서가 무시되는가? = 306 연관관계에 대해 무엇을 설명해야 하는가? = 306 모호한 부분을 찾아보자 = 307 모든 연관관계 설명서가 반드시 설명해야 하는 항목들 = 308 모든 일반화관계 설명서가 반드시 설명해야 하는 항목들 = 308 제목 = 309 의미 = 310 참여개수와 조건부 여부 = 310 연관관계 설명서를 마지막에 작성하지 말라! = 311 요약 = 312 제3부 모델 패턴(Model Patterns) Chapter 15. zero-one-many 참여개수만으로 충분한가? = 315 임의의 숫자를 쓰는 경우 어떤 문제가 있는가? = 316 zero-one-many 참여개수만으로는 충분하지 않은 경우 = 317 참여개수 2를 모델링하기 위한 시도 = 318 문제를 해결하는 방법은 위치에 관한 역할을 클래스로 모델링하는 것이다 = 320 그렇다면 DSP 문제는 어떻게 해결할 수 있는가? = 321 컴파일 단계에 참고할 수 있는 가정들 = 322 컬러링을 통한 문제해결 = 322 결론 = 323 Chapter 16. 재귀 패턴 = 325 재귀적 연관관계와 그래프 = 326 그래프 제한조건을 모델링하기 = 328 간단한 재귀 모델도 유용하다 = 328 재귀 모델이 복잡해질 수 있다 = 329 하지만 걱정하지 말자 = 329 분석 작업과 프로그래밍 작업에서의 재귀적 개념 = 329 재귀적 개념은 구현 작업에서만 사용되는 개념이 아닐까? = 330 애플리케이션의 정책과 구현 메커니즘 구별하기 = 331 간단한 그래프와 복잡한 그래프 = 333 Chapter 17. 네트웍 패턴 = 335 인접 지역 = 336 연결되지 않는 인스턴스가 존재할 수 없고, acyclic 특성을 갖는다 = 337 대칭 재귀형 연관관계 = 337 acyclic 연관관계 만들기 = 338 서로 통신하는 프로세스들 = 338 cycle, island, single connection = 339 cycle, island, multiple connection = 340 단방향, multiple = 341 그래프를 단방향으로 만들기 = 341 여러 개의 양방향 채널 = 344 여러 개의 단방향 채널 = 345 양방향 채널 = 346 채널과 데이터 전송 방향을 분리해서 생각하자 = 349 역할에 따른 구체화 = 349 요약 = 350 패턴 이용에 관한 중요한 충고들 = 350 Chapter 18. 선형 패턴 = 353 Example 1 : 비행 시뮬레이션 게임의 미션 편집기 = 354 목표점들을 연결하기 = 355 Waypoint를 따라 움직이는 전투 유닛 추가하기 = 356 Route 클래스의 도입 = 359 Waypoint가 끊길 수 있다 = 361 완전히 닫혀진 Route - 또 다른 시도의 잘못된 결과 = 362 다른 방식으로 생각하기 = 363 위치에 따른 구체화 = 364 참조되어지는 역할에 따른 구체화 = 365 양쪽 방향 모두를 구체화한다 = 365 잘못된 Route의 입력 막기 = 368 경계조건 - 가장 단순한 Route = 369 해결책 - Start Waypoint에 대한 구체화 작업을 추가한다 = 369 미션 편집기 요약 = 370 어떤 선형 패턴을 이용할 것인가? = 371 클래스 모델이 규칙을 적게 표현하면, 상태 모델이 복잡해진다 = 371 상세한 규칙들을 가능한 빨리 드러내자 = 372 Example 2 : 그림 그리기 프로그램의 Polyline 그리기 도구 = 372 결론 = 378 요약 = 378 Chapter 19. 트리 패턴 = 379 단순한 트리 = 381 부품들에 대한 단순한 트리 = 381 문제점 : 부품 보관 장소에 대한 표현 = 382 Root가 존재하는 트리 = 383 조립품만 보관한다 = 383 트리와 가지 = 385 외부업체가 공급하는 부품 = 385 선형 패턴을 이용한다 = 387 부품의 의미에 대한 재검토 = 388 경계조건 = 389 클래스의 의미를 희석시키는 것은 위험하다 = 390 클래스의 의미를 좀더 분명히 하자 = 391 언제 Part가 Assembly로 조립되는가? 그리고 언제 조립되지 않는가? = 392 창고가 보관하는 것은 무엇인가? = 392 최종 모델 = 393 결론 = 394 어느 수준까지 모델링해야 할까? = 395 결정을 내렸으면, 실행하라 그리고 실행을 통해 배워라 = 396 요약 = 396 더 많은 것을 배우려면 = 397 찾아보기 = 405