실시간 UML 3판에서는 실시간 시스템의 중요 요점과 설계 및 개발에 있어서 계속 발전해가는 표준의 활용에 초점을 맞춰 UML을 소개한다. 이 책은 요구사항 분석, 객체의 구조 및 행동, 아키텍처 설계 및 메커니즘 설계와 좀더 구체적으로 데이터 구조, 오퍼레이션, 예외상황 등을 아우르는 상세 설계에 대해서 쉽게 기술하고 있다. 많은 그림들을 통해서 UML 설계 기법을 설명하고 있으며, 상세한 실전 예제들은 이런 기법들이 임베디드 시스템에 어떻게 적용되는지를 보여준다.


[ 책 소개 ]

임베디드 실시간 시스템들이 점점 복잡해져 감에 따라서 성공적인 구현으로 이끄는 좀더 정교하고 준비된 설계 방법이 요구된다. 객체기반의 UML(Unified Modeling Language)은 실시간 시스템에 매우 중요한 구조 측면과 행동 측면을 기술할 수 있어서 효과적인 설계를 위한 뛰어난 방법으로 자리매김하고 있다.

상당히 많은 부분이 개정된 3판은 좀더 분명하게 아키텍처를 지원하며 확장성도 향상된 새 UML 2.0 표준을 중점적으로 다룬다. 실시간 UML 3판은 또한 스케줄가능성(Schedulability), 성능(Performance), 시간(Time)을 위한 UML 프로파일(SPT 프로파일)을 소개한다. SPT 프로파일은 시스템의 스케줄 가능성 및 성능 제약 조건을 명세하는 표준화된 방법을 제공하며 분석 도구들은 이를 통해서 UML 모델들을 읽고 분석하게 된다.


[ 이 책에서 다루는 내용 ]

■ 임베디드 시스템용 쾌속 객체 지향 프로세스(ROPES)
■ 실시간 (SPT) UML 프로파일을 이용한 동시성 및 자원 모델링
■ 원활하게 실행가능한 동작 명세 만들기
■ 타이밍 다이어그램을 이용한 시나리오 모델링
■ 객체 식별을 위한 핵심 전략
■ 객체 상태 행동 정의하기
■ 스레드 표현과 식별
■ 메커니즘 설계 패턴
■ C4ISR(지휘, 통신, 통제, 컴퓨터, 정보, 감시, 정찰) 명세하기
■ UML로 아키텍처 모델링하기


[ 이 책의 대상 독자 ]

현업의 소프트웨어 개발자와 대학 2~3학년의 컴퓨터 과학 전공자를 대상으로 하는 책으로서 학부나 대학원 교재로도 쓸 수 있지만 초점은 이론 소개보다는 실제 개발에 있다. 이 책에 방정식은 거의 나오지 않지만 이론적 수학적 접근이 필요한 곳에는 참고 자료를 적어두었다. 이 책을 읽는 독자는 최소한 하나의 프로그래밍 언어에 어느 정도 능숙하고 최소한 피상적으로라도 객체 지향과 실시간 시스템이라는 개념을 접한 적이 있다고 가정했다.


[ 추천의 글 ]

브루스 더글라스의 책은 시간이 지날수록 장점이 더 늘어난다. 주요 변화는 물론 이제 새로운 버전인 UML 2.0에 대한 요구에 부응한다는 것이다. 1판과 마찬가지로 3판 역시 UML을 이용해서 시스템, 특히 반응적/실시간 시스템을 모델링하고 명세하고자 하는 엔지니어를 위한 가장 명쾌하고 값진 책이다. 따라서 브루스가 책을 갱신하고 그의 풍성한 펜대가 또 하나의 값진 산출물을 사람들에게 제공하는 것에 박수를 보낸다.

그럼에도 불구하고 필자도 UML 자체에 대해 특히 이전의 추천사에서 언급한 아래 두 가지 구절(하나는 예언이고 하나는 의견이다)과 관련해서 몇 마디 하고자 한다.

최근 UML의 인기는 래쇼날 사 저자가 쓴 공식 UML 책뿐만 아니라 UML을 설명하고 활용하고 정교화하거나 앞으로 하려는 책, 논문, 보고서, 세미나, 도구의 진정한 홍수를 불러올 것이다. 독자는 이 산만한 숲에서 정말로 가치 있는 나무를 찾기 위해 각별히 주의해야 할 것이다. 필자는 브루스의 책이 그 중 하나일 것이라 믿어 의심치 않는다.

그럼에도 불구하고 지금 당장은 UML이 너무 좀 크고 무겁다는 사실을 기억해야 한다. 우리는 그 일부만을 잘 이해한다. 다른 부분의 정의는 UML의 구조적인 핵심(클래스 다이어그램과 스테이트차트)과의 관계를 명확히 하기에 아직 충분히 깊게 이뤄지지 않았다.

첫 번째 구절에 대해서는 홍수를 예측하기란 너무나 어렵다. 홍수는 모든 기대를 넘어서 실체화되기 때문이다. 여기 간단한 통계가 있다. 이 글을 쓰는 지금, 아마존닷컴에서 “UML”을 제목으로 검색하면 213개 항목이 나오고, 같은 검색을 1998년과 그 이후로 제한하면 198개 항목이 나온다[역자주: 지금은 대략 400개가 넘는다]. 즉 이 책의 첫 판이 출간되었을 때는 UML 책이 15가지였고, 이제 200여 가지가 더 있다는 말이다! 그럼에도 불구하고 브루스의 책은 단연코 정말 몇 안 되는 값진 책 가운데 하나다.

UML이 너무 크고 무겁다는 두 번째 의견에 대해서는 상황이 그다지 개선되지 않았다. 거의 출시가 임박한 버전 2.0은 의심할 여지없이 UML의 개발에 있어서 하나의 이정표지만 UML이 더 간결하고 가벼워졌는지 아니면 더 크고 산만해졌는지는 자문해봐야 한다. 다방면에 걸쳐 복잡하지만 표준으로 채택되어 세계적으로 널리 사용되고 있는 것이 새로운 버전이 나오면 사람들은 최신 버전이 무엇보다도 가장 중요한 측면에 집중하기를 기대한다. 개선하고 빈틈없이 없으며 잘 요약되어 있고, 비핵심적이거나 제대로 정의되지 않은 것들은 버리기를 기대했다. 그렇게 하면 더 배우기 쉽고 쓰기 쉽고 틀림없이 구현하기 쉬운 언어가 되었을 것이고, 따라서 효과가 훨씬 더 컸을 것이다. UML 2.0이 몇 가지 흥미로운 새로운 기능(특히 이 책과 관련 있는 분야(실시간/반응적 시스템)를 위한)을 포함하고 있지만 새로운 버전의 UML은 더 크고 더 복잡해졌다.

1997년의 추천사에서 언급한 대로 객체 지향은 지속될 것이고 UML도 대규모로 명맥을 이어나갈 것이다. 버전 3.0에서는 뭔가를 추가하기보다는 필요 없는 기능을 제거하고 통합하며 좀더 명확해져서 결속되어 나가기 바란다. 어쨌거나 언어에 대한 좋은 책은 언어 자체만큼이나 매우 중요하고, 그런 면에서 이 책은 진정으로 권하고 싶은 몇 안 되는 책 중 하나다.



[ 이전판 추천사 ]

임베디드 시스템은 꾸준히 지속될 것이다. 반응적/실시간 시스템도 마찬가지다. 이 책이 적절히 지적한 대로 임베디드 시스템은 도처에 있다. 일반적인 데스크탑이나 노트북보다 많은 컴퓨터가 물건의 뱃속에 감춰져 있다. 컴퓨터나 컴퓨터화 시스템이 있는 곳이라면 이를 구동하는 소프트웨어가 있어야 한다. 그리고 소프트웨어는 그냥 생기지 않는다. 사람들이 작성해야 하고, 사람들이 이해하고 분석해야 하며, 사람들이 사용해야 하고, 최신 버전을 얻기 위해 사람들이 유지보수하고 갱신해야 한다. 복잡한 시스템에 대한 보통의 프로그래밍 언어보다 더 높은 추상화 수준에서의 모델링을 요구하는 것은 프로그래밍의 인간적 측면이다. 이 때문에 모델링 프로세스 자체에 대해 소프트웨어 엔지니어와 프로그래머를 안내할 방법론도 필요하다.

고수준 모델링 접근 방법을 고안하려는 노력 가운데 하나는 좋은 도표라는 의견이 많다. 다른 것이 모두 같다면 그림이 일반적으로 텍스트나 기호보다 이해하기에 낫다. 그러나 복잡한 소프트웨어를 만드는 것이 전적으로 인간만의 활동은 아니기 때문에 그림이나 다이어그램에만 관심이 있는 것은 아니다. 우리는 다이어그램 언어에 관심이 있고 이들 언어는 검증과 분석에 컴퓨터화된 지원이 필요하다.

고급 언어가 에디터와 버전 제어 유틸리티뿐만 아니라(그리고 현저하게!) 컴파일러와 디버그 도구도 필요하듯이 모델링 언어 역시 예쁜 그림, 문서 작성 유틸리티, 프로젝트 관리 도구뿐만 아니라 실행 모델과 코드 생성을 요구한다. 이는 무엇이 허용되는지를 결정하는 문법을 갖춘 시각적 형식(visual formalism)과 허용된 것들이 무슨 뜻인지를 결정하는 의미(semantics)가 필요함을 뜻한다.

그런 형식은 다이어그램 요소 사이의 토폴로지상 관계를 주로 강조하면서 최대한 시각적이어야(분명히 어떤 것들은 자연스럽게 시각화되지 않을 것이다) 하고, 차선으로 기하학, 측량, 어쩌면 아이콘을 이용할 수 있을 것이다.
수년간 고수준 모델링에 대한 주요 접근 방법은 구조적 분석(SA, structured analysis)과 객체 지향(OO, object orientation)이었다. 이들 두 가지는 초기 착상과 발달이 대략 10년 차이가 난다. SA는 1970년대 후반에 드마르코(DeMarco), 요든(Yourdon) 등이 시작했고, 고전적인 절차적 프로그래밍 개념을 모델링 수준으로 “끌어올린” 것이다. 결과는 시스템 구조를 기능적 분해와 정보의 흐름으로 (계층적인) 데이터 흐름 다이어그램을 통해 그림으로 모델링하는 것이다.

시스템 행동에 대해서는 1980년대 초중반에 (Ward/Mellor, Hatley/Pirbhai, i-Logix의 STATEMATE 팀과 같은) 몇 개의 방법론 팀이 행동을 상태 다이어그램이나 더 풍부한 언어인 스테이트차트로 나타냄으로써 기본 SA 모델을 개선하는 구체적인 권고를 했다. 조심스럽게 정의한 행동 모델링은 특히 임베디드, 반응적, 실시간 시스템에 중요하다.

객체 지향 모델링은 1980년대 후반에 시작했는데, 어떤 면에서 그 역사가 SA의 역사와 매우 비슷하다. 시스템 구조에 대한 기본 생각은 객체 지향 프로그래밍에서 모델링 수준으로 개념을 “끌어 올리는” 것이었다. 따라서 부치(Booch)의 방법론, OMT와 ROOM 방법론, 기타 여러 방법론에서 객체에 대한 기본 구조 모델은 클래스와 인스턴스, 관계와 역할, 오퍼레이션과 이벤트, 집합 연관과 상속을 다룬다. 시각성은 이 모델의 기반으로 더욱 풍부해진 ER(entity-relationship) 다이어그램의 확장판을 사용함으로써 얻어졌다.

시스템 행동에 대해서는 대부분의 OO 모델링 접근 방법이 스테이트차트 언어를 채택했다(필자는 이 결정에 대해 기분 나쁘다고 할 수 없다. [역자주: 스테이트차트 언어를 만든 사람이 이 추천사를 쓰고 있는 데이빗 하렐 자신이다]). 스테이트차트는 각 클래스와 연관되고 그 역할은 인스턴스 객체의 행동을 기술하는 것이다.

구조와 행동(즉 객체 모델과 스테이트차트) 사이의 미묘하고 복잡한 관계를 객체 지향 방법론자들은 다양한 수준의 상세화(상당히 불충분한 정도에서 적당한 정도까지)로 처리했다. 관건은 물론 구조와 행동과 그들 사이의 연결을 위한 언어가 고수준 모델을 인터프리트(interpretation)와 컴파일(compilation)(모델의 실행과 코드의 생성) 할 수 있을 정도로 충분히 잘 정의돼있는지이다.

이는 몇 가지 경우에서만 가능했는데, (셀릭(Selic)과 굴렉슨(Gullekson), 워드(Ward)의 ROOM 방법에 기반을 둔) ObjecTime 도구와 (아이로직스의 게리(Gery)와 필자의 실행 가능 객체 모델링(Executable Object Modeling) 방법에 기반을 둔) 랩소디(Rhapsody) 도구에서만 가능했다.

시스템 모델링을 위한 SA와 객체 지향 패러다임 발전간 유사성으로부터 주목할 만한 이탈은 지난 2~3년간 객체 지향 방법론자들이 협력했다는 것이다. 객체 지향 방법론자들의 노트를 비교하고, 이슈를 토론하고, 다양한 객체 지향 모델링 접근 방법 가운데 최고를 모으려는 바람으로 마침내 일반적인 UML을 만드는 데 협력했다.

알골60(Algol60)과 에이다(Ada) 때의 팀웍을 연상시키는 이 광범위한 노력은 (부치 방법론의) G. 부치와 (OMT 방법론의 공동 개발자) J. 럼바(Rumbaugh), (유스케이스의 황제) I. 제이콥슨(Jacobson)이 앞장선 래쇼날 사의 원조 하에 이뤄졌다.

UML 0.8은 1996년에 발표되었고 딱히 정해진 답이 없고 모호하며 기대보다 잘 정의되지 않았다. 대략 1년 동안 UML 팀은 래쇼날 사 외부에 있는 방법론자와 언어 설계자들의 많은 도움을 받으며 (미천하나마 기여한 필자 또한) 열심히 일했고, 1997년 초에 발표된 버전 1.1은 훨씬 더 빈틈이 없고 견실하다.

UML은 아주 최근에 OMG 표준으로 채택되었고 조금 더 노력하면 그저 공인된 (조금 무미건조하게 문서화된다면) 표준일 뿐만 아니라 객체 지향 원칙에 따라 만들어지는 소프트웨어의 주요 모델링 메커니즘이 될 가능성이 높다. 그리고 이제 점점 더 많은 소프트웨어 엔지니어가 점점 더 많은 종류의 소프트웨어를 객체 지향 방식으로 가장 잘 만들 수 있다고 주장함에 따라 이는 사소한 일이 아니다.

시스템 구조를 나타내기 위해 UML은 실제로 클래스와 객체를 위해 ER 다이어그램 같은 다이어그램 언어를 채택했다. 초기 단계에서의 행동을 모델링하기 위해선 유스케이스를 권장하고, 가끔 MSC(message sequence chart)라고도 하는 시퀀스 다이어그램을 활용한다. 행동에 대한 전체 구성 명세를 위해서는 스테이트차트를 채택했다.

이 책에서 브루스 더글라스는 공학적 지혜를 복잡한 소프트웨어(특히 실시간, 임베디드, 반응적 소프트웨어)를 만들어야 하는 사람들에게 훌륭하게 전파했다. 게다가 이 책은 UML을 주된 수단으로 삼고 있다. 최근의 UML의 표준화와 빠른 전파를 고려할 때 이 책은 매일매일 그런 시스템의 신속하고 매끄러운 개발을 걱정하는 사람들에게 유용하다.

게다가 브루스의 책은 명쾌하고 매우 잘 쓰여져 저자가 담쟁이로 덮인 높다란 상아탑이나 전문 방법론자로서의 왜곡된 교조주의적 관점에서가 아닌 이 책에서 논하는 바로 그런 종류의 시스템에 대한 폭넓은 경험으로부터 썼다는 사실로 인해 독자들의 자신감이 높아진다.

최근 UML의 인기는 래쇼날 사의 저자가 쓴 공식 UML 책뿐만 아니라 UML을 설명하고, 활용하고, 정교화하거나 하려고 하는 책, 논문, 보고서, 세미나, 도구의 진정한 홍수를 불러올 것이다. 독자는 이 산만한 숲에서 정말로 가치 있는 나무를 찾기 위해 각별히 주의해야 할 것이다. 필자는 브루스의 책이 그 가운데 하나일 것이라고 믿어 의심치 않는다.
그럼에도 불구하고 지금 당장 UML이 약간은 너무 크고 무겁다는 것을 기억해야 한다. 우리는 단지 그 일부만을 잘 이해한다. 다른 부분의 정의는 UML의 구조적인 핵심(클래스 다이어그램과 스테이트차트)과의 관계를 명확히 하기에 아직 충분히 깊게 이뤄지지 않았다.
예를 들어 유스케이스와 관련 시퀀스/협력 다이어그램은 시스템의 필요 행동을 시나리오로 풀어나가려는 사용자와 요구 사항 엔지니어에게 매우 귀중하다.

유스케이스는 모든 관련 객체에 대한 하나의 시나리오(또는 밀접히 관련된 일군의 시나리오)-객체간 행동(interobject behavior)이라고 한다 - 를 기술한다. 반면에 스테이트차트는 단일 객체의 모든 행동(객체 내 행동(intraobject behavior))을 기술한다. 필자는 이 현저한 차이를 시스템 행동의 대(大) 이중성(grand duality of system behavior)라고 하고자 한다. 이 이중성을 이해하는 좋은 알고리즘은 없다. 아직 하나의 뷰에서 다른 뷰를 도출하는 방법이나 이들 둘에 표시된 명세가 서로 일관됐는지를 효과적으로 테스트하는 방법을 모른다.

다른 심각한 도전도 여전해서 단지 표면만 긁었을 뿐이다. 예를 들어 UML이 제공하는 고수준 방법을 이용한 객체 지향 소프트웨어의 진정한 정형적 확인(formal verification), 자동적으로 보기 편하고 구조가 잘 들어나게 하는 UML 다이어그램 레이아웃, 이산 값과 연속 값을 아우르는 하이브리드 시스템을 다루는 만족스런 방법 등 여러 가지 도전이 존재한다.

복잡한 소프트웨어를 다루는 일반적인 방법으로서 객체 지향은 지속될 것이고, 따라서 UML도 그러할 것이다. 객체 지향은 시스템에 대해 생각하고 시스템을 프로그램하는 강력하고 현명한 방법이고, 오랜 동안 자존심 있는 소프트웨어 엔지니어에게 필요한 지식의 일부일 것이다. 이 책은 그 점에서 큰 도움이 될 것이다.
한편 객체 지향은 모든 문제를 풀지는 못할 것이고 따라서 UML도 그러할 것이다. 여전히 알아야 할 것들이 아직도 많다. 사실 이 분야에서 우리가 모르고 아직 이룰 수 없는 것이 우리가 알고 있고 할 수 있는 것보다 훨씬 더 많다고 해도 큰 과장이 아닐 것이다. 그럼에도 불구하고 우리가 지금 갖고 있는 것은 5년 전에 바랐던 것보다 훨씬 더 많고, 이에 대해 감사하고 겸손해야 한다.

[ 저자 소개 ]

브루스 파월 더글라스
브루스 파월 더글라스는 선도적 실시간 시스템 개발 도구 제작사인 아이로직스(I-Logix)의 수석 전도사이다. 브루스는 OMG(Object Management Group)의 실시간 분석과 설계 워킹 그룹(Real-Time Analysis and Design Working Group)의 공동의장으로서 UML의 초기 명세와 UML 2.0의 작성에 공헌했다. 현재 브루스는 미항공우주국(NASA)과 같이 대규모 실시간 세이프티 크리티컬 시스템을 만드는 여러 회사와 조직에 컨설팅을 제공하고 있다. 그는 『Real-Time Design Patterns』(Addison-Wesley, 2003)과 『Doing Hard Time』(Addison-Wesley, 1999)을 포함하여 7권의 책을 집필했다.


[ 3판 저자 서문 ]

UML은 진화하는 표준이다. 여기에는 물론 장점도 있고 단점도 있다. 단점 가운데 하나는 계속 바뀐다는 것이다. 그러나 필자는 가장 큰 장점(표준이 계속 진보한다는)이 이를 상쇄하고도 남을 것이라고 믿는다. 『실시간 UML』 2판 이래로 UML에 중요한 변화 몇 가지가 생겼다.

이 가운데 가장 중요한 것이 UML 2.0이다. 이 글을 쓸 때(2003년 여름) UML 2.0 명세가 “투표를 통해 채택되었다”. 이는 OMG(Object Management Group)가 UML 2.0을 승인했고, 보류 중인 몇 가지 투표가 표준으로 발표되기 위한 최종 절차를 시작할 준비가 되었다는 것을 뜻한다. 최종 절차는 1년 이상(혹은 바라건대 조금 적게) 걸릴 수도 있다.

UML 2.0은 UML 1.x 표준에 대한 점진적 개선으로 아키텍처를 나타낼 때의 명확성과 확장성을 개선했다. UML 2.0은 아직 결함을 제거하고 일관성을 높이기 위한 최종 절차를 거쳐야 하기 때문에 발표될 표준은 이 책에 기술된 것과는 조금 다를 수도 있다. 하지만 필자는 그 차이가 작고 비교적 중요하지 않으리라고 믿는다.

그 밖에 실시간 공동체를 위한 개선점으로는 적어도 스케줄 가능성과 성능, 시간을 위한 UML 프로파일(UML Profile for Schedulability, Performance, and Time. 일명 실시간 프로파일[RTP])의 채택을 들 수 있다. 이 프로파일은 UML 1.x의 표준 경량 확장 메커니즘을 이용해서 시스템의 스케줄성과 성능 제약 사항을 나타내는 표준 태그들을 제공한다.

이 프로파일이 UML에 새로운 기능을 추가하지는 않지만 서비스의 적시성(timeliness)을 나타내는 표준 방식을 제공해서 도구들이 모델을 교환하고 교환 시 적시성 제약 사항을 이해할 수 있게 한다. 이는 스케줄성과 성능 분석 도구가 UML 모델을 읽고 (프로파일에 부합하는) 수학적 분석을 할 수 있다는 것을 뜻한다.

UML은 실시간 임베디드 시스템 특히 복잡한 시스템 영역에서 계속해서 추진력을 얻고 있다. 이런 이유로 필자는 이 책의 끝에 UML을 이용해서 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, 지휘, 통제, 통신, 컴퓨터, 정보, 감시, 정찰) 아키텍처를 나타내는 방법을 다룬 특별한 주제의 장을 넣었다. C4ISR 시스템은 세상에서 가장 복잡한 시스템 가운데 하나지만 C4ISR 표준이 오리지널 UML 표준과 비슷한 시기에 발표돼 아직까지 함께 논의된 적이 없다.

2판의 목적은 여전히 3판의 목적이기도 하다. 이 책은 여전히 UML과 UML의 표기와 의미를 실시간 임베디드 시스템에 적용하는 방법에 대한 읽기 쉬운 입문서로 기획되었다. 이 글을 쓰고 있는 지금 이 책은 UML과 실시간 시스템에 대한 몇 안 되는 책 가운데 하나다.

필자는 『Doing Hard Time: Developing Real-Time Systems using UML, Objects, Frameworks, and Patterns(Addison-Wesley, 1999)』와 『Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems(Addison-Wesley, 2002)』를 집필하기도 했다.

『Doing Hard Time』은 객체 스케줄 가능성 분석과 스테이트차트 모델 작성에서의 행동 패턴 사용, 효과적인 실시간 프레임워크 사용법을 중심으로 실시간 시스템의 기초와 특이한 점을 좀 더 깊이 살펴본다. 『Doing Hard Time』은 이들 개념을 나타내기 위해 어쩌다 UML을 이용하게 된 실시간 시스템에 대한 좀 더 깊은 탐험을 제공하고 있다.

필자의 다른 책 『Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems』는 아키텍처와 ROPES 프로세스에 정의된 아키텍처의 5가지 뷰(서브시스템과 컴포넌트 뷰, 병행성과 자원 뷰, 분배 뷰, 안전과 신뢰성 뷰, 배치 뷰)를 이용한 아키텍처 개발을 위한 디자인 패턴의 응용에 대한 책이다. 이 책은 『Doing Hard Time』보다 더 전문적인 책으로, 거의 전적으로 소프트웨어와 시스템 아키텍처에 초점을 두고 있다. 대조적으로 『Real-Time UML』은 주로 UML과 실시간 시스템의 요구 사항과 구조, 행동을 나타내기 위한 UML의 사용법에 대한 소개를 다룬다.

이런 1판과 2판의 본래 목표에 덧붙여 3판에는 두 가지 목표가 추가되었다. (1) 책의 내용을 최근의 UML 표준 변경에 맞춰 수정하고(특히 곧 발표될 UML 2.0과 스케줄 가능성, 성능, 시간을 위한 UML 프로파일), (2) 첫 두 판에 대한 피드백에 근거해 책을 개선하는 것이다.

흥미 있는 독자는 아이로직스 웹사이트를 살펴보면 UML 명세와 도구 설명, 관련 사이트로의 링크뿐만 아니라 관련 주제에 대해 필자와 다른 이들이 쓴 여러 글들을 볼 수 있다.
필자는 UML과 실시간 임베디드 시스템에 대한 UML의 응용 관련 논의와 글을 위한 야후 그룹(http://groups.yahoo.com/group/RT-UML/)의 의장이기도 하다.



[ 역자 소개 ]

김기주
포항공과대학교 컴퓨터 공학과와 동 대학원을 졸업한 뒤 지금은 임베디드 소프트웨어를 개발하고 있다. “월간 마이크로소프트웨어” 등에 디지털 TV와 프로그래밍 방법 관련 기사를 기고하기도 했으며, “자바원”과 “한국 자바 개발자 컨퍼런스”, “썬 테크 데이” 등에서 디지털 TV와 JavaME에 대해 소개하기도 했다. 역서로는 『임베디드 프로그래밍 입문: C와 어셈블리로 확실히 배우는(에이콘출판사, 2006)』이 있다.

채원석
포항공과대학교 컴퓨터공학과를 졸업하고 동 대학원에서 소프트웨어공학을 전공했다. 루슨트코리아에서 무선교환기 시스템을 개발했으며, 한국 소프트웨어 프로세스 예비심사원으로 활동했다. 현재 시카고에 위치한 토요타 대학원에서 프로그래밍 언어와 컴파일러를 공부하고 있다.

최현식
포항공과대학교 컴퓨터공학과를 졸업하고 동 대학원 소프트웨어공학 연구실에서 석사과정을 마쳤다. LG전자 디지털TV연구소에서 7년간 근무하며 다양한 TV 제품의 소프트웨어 개발에 참여하였다. 현재는 모교로 돌아와 소프트웨어공학 연구실에서 박사과정으로 소프트웨어 제품 라인의 재사용 방법론을 연구하고 있다.


[ 역자 서문 ]

아마존닷컴에서 “UML”을 제목으로 검색하면 현재 400여 가지 책이 나오지만 “real time UML”을 제목으로 검색하면 현재 11가지 책이 나온다. 하지만 우리나라에서 가장 큰 인터넷 서점에서 “real time UML”이나 “실시간 UML”을 제목으로 검색하면 한 권도 나오지 않는다. 임베디드 시스템 용어와 UML 용어를 번역하는 과정에서 많은 어려움이 있었지만 국내의 실시간 임베디드 소프트웨어 개발자를 위한 책이 한 권도 없는 이 시점에서 이 책을 소개하게 돼 매우 기쁘다.

원저자도 서문에서 말하고 있지만 실시간 임베디드 소프트웨어 분야에서는 잘 정의된 표기법을 이용해서 설계를 하고 완성된 설계를 바탕으로 구현하기보다는 이전 제품의 코드에 추가된 기능을 개발자가 생각나는 대로 코딩하는 것이 일반적인 거라 여겨진다. 하지만 PC 소프트웨어와 달리 사용자의 안전에 영향을 줄 수 있다는 면에서 임베디드 소프트웨어의 철저한 설계와 그 검증은 매우 중요하다고 생각한다.

이 책이 임베디드 소프트웨어 개발자들에게 UML과 UML을 임베디드 소프트웨어에 적용하는 방법에 대한 안내서가 되길 바라고, 더불어 소프트웨어 개발 시 요구 사항 분석과 설계에 대해서도 생각할 수 있는 기회가 되길 바란다.

참고로 UML을 쓰려면 시중에 나와 있는 여러 가지 도구의 도움을 받을 수 있겠으나 무료로 쓸 수 있는 통합 개발 환경인 넷빈스(NetBeans. 자세한 내용은 http://www.netbeans.org/ 참조)에 UML 플러그인을 설치(메뉴 Tools → Plugins 선택 → Available Plugins 탭에서 UML 선택)해서 쓰는 것도 한 가지 방법이다.

UML 관련 용어는 주로 『Teach Yourself UML in 24 Hours, 3판(SAMS,2004)』을 번역한 『초보자를 위한 UML 객체 지향 설계, 3판(정보문화사, 2006)』를 따랐고, 임베디드 시스템 용어는 『Embedded Systems Dictionary(CMP Books, 2003)』을 번역한 『임베디드 시스템 대사전(에이콘출판사, 2005)』을 따랐으며, 디자인 패턴 관련 용어는 『Design Patterns: Elements of Reusable Object-Oriented Software(Addison Wesley, 1995)』를 번역한 『GoF의 디자인 패턴: 재사용성을 지닌 객체 지향 소프트웨어의 핵심 요소, 개정판(피어슨에듀케이션코리아, 2007)』을 따랐다. 때에 따라 인터넷 검색 결과도 참고했다.

목차

• 1장 실시간 임베디드 시스템 세계의 개요 1
  • 1.1 실시간 시스템의 특징 2
  • 1.2 시간, 성능, QoS 7
    • 1.2.1 동작과 동시성 모델링 8
    • 1.2.2 자원 모델링 14
    • 1.2.3 시간 모델링 15
    • 1.2.4 스케줄 가능성 모델링 17
    • 1.2.5 성능 모델링 27
  • 1.3 시스템 공학과 소프트웨어 공학 27
  • 1.4 아키텍처란 28
  • 1.5 ROPES 프로세스 30
    • 1.5.1 MDD(Model-Driven Development) 33
    • 1.5.2 ROPES 나선 34
  • 1.6 MDA와 플랫폼 독립적 모델 41
  • 1.7 모델 기반 프로젝트 스케줄하기 44
    • 1.7.1 스케줄의 이유 45
    • 1.7.2 예측 46
    • 1.7.3 BERT와 ERNIE 47
    • 1.7.4 스케줄 49
  • 1.8 모델 조직 원칙 53
    • 1.8.1 모델 조직의 이유- 53
    • 1.8.2 특정 모델 조직 패턴들 58
  • 1.9 모델 기반 프로젝트 작업 64
  • 1.10 앞으로 72
  • 1.11 연습문제 73
  • 1.12 참고 자료 74
    
• 2장 UML 2.0과 함께 하는 객체 지향 - 구조 측면 77
  • 2.1 UML을 이용한 객체 지향 78
  • 2.2 작은 것들: 객체, 클래스, 인터페이스 80
    • 2.2.1 객체 80
    • 2.2.2 클래스 83
    • 2.2.3 표기법 87
    • 2.2.4 인터페이스 89
    • 2.2.5 메시징 92
  • 2.3 관계 95
    • 2.3.1 연관 95
    • 2.3.2 집합 연관 98
    • 2.3.3 복합 연관 100
    • 2.3.4 일반화 103
    • 2.3.5 의존 106
    • 2.3.6 구조 다이어그램 109
    • 2.3.7 객체를 코드에 대응시키기 111
  • 2.4 큰 것들: 패키지, 컴포넌트, 서브시스템 114
    • 2.4.1 모델의 조직화: 패키지 115
    • 2.4.2 구조화 클래스: 복합체, 부속, 포트, 커넥터 117
    • 2.4.3 컴포넌트 122
    • 2.4.4 서브시스템 124
    • 2.4.5 배치: 노드 127
    • 2.4.6 노드냐 클래스냐 128
    • 2.4.7 아키텍처 계층 구조 130
  • 2.5 고급: 고급 모델 작성자를 위한 구조 요소의 UML메타 모델 130
  • 2.6 추가적인 표기법과 의미 134
  • 2.7 앞으로 136
  • 2.8 연습문제 137
  • 2.9 참고 자료 138
    
• 3장 UML 2.0과 함께 하는 객체 지향 - 동적 측면 139
  • 3.1 행동과 UML 140
  • 3.2 행동의 유형 141
    • 3.2.1 단순 행동 141
    • 3.2.2 상태 행동 142
    • 3.2.3 연속 행동 143
  • 3.3 행동의 기본 단위: 동작과 활동 145
  • 3.4 행동과 단일 객체 148
    • 3.4.1 스테이트차트의 기본 요소 149
    • 3.4.2 동시 상태 157
    • 3.4.3 의사 상태 159
    • 3.4.4 상속 상태 모델 169
    • 3.4.5 부적격 스테이트차트 171
    • 3.4.6 심장 박동 조절기 예제 173
    • 3.4.7 프로토콜 상태 기계 183
    • 3.4.8 활동 다이어그램 185
  • 3.5 상호작용 190
    • 3.5.1 시퀀스 다이어그램 190
    • 3.5.2 타이밍 다이어그램 206
  • 3.6 요약 212
  • 3.7 연습문제 212
  • 3.8 참고 자료 214
    
• 4장 스케줄 가능성과 성능, 시간을 위한 UML 프로파일 215
  • 4.1 UML 프로파일 216
    • 4.1.1 스테레오타입 217
    • 4.1.2 꼬리표 값 219
    • 4.1.3 프로파일 222
  • 4.2 “RT UML” 프로파일 222
    • 4.2.1 일반 자원 모델 서브프로파일 228
    • 4.2.2 시간 모델링 서브프로파일 233
    • 4.2.3 동시성 모델링 서브프로파일 240
    • 4.2.4 스케줄 가능성 모델링 서브프로파일 242
    • 4.2.5 성능 모델링 서브프로파일 256
    • 4.2.6 실시간 CORBA 서브프로파일 268
  • 4.3 앞으로 273
  • 4.4 연습문제 274
  • 4.5 참고 자료 276
    
• 5장 실시간 시스템의 요구 사항 분석 277
  • 5.1 요구 사항 278
  • 5.2 유스케이스 280
    • 5.2.1 행위자 282
    • 5.2.2 유스케이스와 텍스트 297
    • 5.2.3 유스케이스 관계 299
    • 5.2.4 유스케이스 사용 301
    • 5.2.5 유스케이스 찾아내기 302
  • 5.3 유스케이스 상세화 305
    • 5.3.1 유스케이스에 대한 시나리오 307
    • 5.3.2 스테이트차트 318
    • 5.3.3 활동 다이어그램 324
    • 5.3.4 타이밍 다이어그램 326
  • 5.4 앞으로 328
  • 5.5 연습문제 329
  • 5.6 참고 자료 330
    
• 6장 분석: 객체 도메인 분석 331
  • 6.1 객체 발견 프로세스 332
  • 6.2 객체 모델과 유스케이스 모델의 연결 334
  • 6.3 객체를 찾아내는 핵심 전략 339
    • 6.3.1 명사에 밑줄 긋기 전략 341
    • 6.3.2 원인 객체 찾기 344
    • 6.3.3 서비스(수동적 기여자) 찾기 345
    • 6.3.4 메시지와 정보 흐름 찾기 346
    • 6.3.5 실세계 항목 찾기 346
    • 6.3.6 물리적 장치 찾기 348
    • 6.3.7 핵심 개념 찾기 349
    • 6.3.8 트랜잭션 찾기 349
    • 6.3.9 지속적 정보 찾기 351
    • 6.3.10 시각 요소 찾기 352
    • 6.3.11 제어 요소 찾기 355
    • 6.3.12 시나리오 적용 356
  • 6.4 객체 연관 찾기 358
  • 6.5 객체 속성 362
  • 6.6 후보 클래스 발견 364
  • 6.7 클래스 다이어그램 365
    • 6.7.1 연관 클래스 367
    • 6.7.2 일반화 관계 370
  • 6.8 앞으로 396
  • 6.9 연습문제 396
  • 6.10 참고 자료 398
    
• 7장 분석: 객체 행동 정의 399
  • 7.1 객체 행동 400
    • 7.1.1 단순 행동 400
    • 7.1.2 상태 행동 402
    • 7.1.3 연속 행동 403
  • 7.2 객체 상태 행동 정의 404
    • 7.2.1 심장박동 조절기 예 408
    • 7.2.2 계산기 예 423
    • 7.2.3 이벤트 계층 구조 441
  • 7.3 상호작용 443
    • 7.3.1 시퀀스 다이어그램 443
  • 7.4 오퍼레이션의 정의 463
    • 7.4.1 오퍼레이션의 종류 465
    • 7.4.2 오퍼레이션 정의 전략 468
  • 7.5 앞으로 471
  • 7.6 연습문제 472
  • 7.7 참고 자료 472
    
• 8장 아키텍처 설계 473
  • 8.1 설계의 의미 474
  • 8.2 아키텍처 설계 477
    • 8.2.1 논리적 아키텍처 478
    • 8.2.2 물리적 아키텍처 482
    • 8.2.3 서브시스템과 컴포넌트 뷰 486
    • 8.2.4 동시성과 자원 뷰 489
    • 8.2.5 분산 뷰 493
    • 8.2.6 안전성과 신뢰성 뷰 498
    • 8.2.7 배치 뷰 500
    • 8.2.8 물리적 아키텍처 이슈 501
    • 8.2.9 소프트웨어 아키텍처 이슈 503
  • 8.3 소프트웨어가 하드웨어를 만나다: UML의 배치 아키텍처 509
  • 8.4 동시성과 자원 설계 513
    • 8.4.1 스레드 표현 513
    • 8.4.2 시스템 태스크 다이어그램 514
    • 8.4.3 동시 상태 다이어그램 516
    • 8.4.4 스레드 정의 518
    • 8.4.5 스레드 식별 519
    • 8.4.6 객체를 스레드에 할당 521
    • 8.4.7 스레드 랑데부 정의 521
    • 8.4.8 자원 공유 523
    • 8.4.9 우선순위 할당 523
  • 8.5 앞으로 524
  • 8.6 연습문제 525
  • 8.7 참고 자료 526
    
• 9장 메커니즘 설계 527
  • 9.1 메커니즘 설계란 528
  • 9.2 메커니즘 설계 패턴 530
  • 9.3 감시자 패턴 533
    • 9.3.1 요약 533
    • 9.3.2 문제 533
    • 9.3.3 패턴 구조 534
    • 9.3.4 협력 역할 535
    • 9.3.5 결과 536
    • 9.3.6 구현 방법 536
    • 9.3.7 예제 모델 537
  • 9.4 프록시 패턴 539
    • 9.4.1 요약 539
    • 9.4.2 문제 539
    • 9.4.3 패턴 구조 540
    • 9.4.4 협력 역할 540
    • 9.4.5 결과 543
    • 9.4.6 구현 방법 543
    • 9.4.7 예제 모델 544
  • 9.5 신뢰성 트랜잭션 패턴 547
    • 9.5.1 요약 548
    • 9.5.2 문제 548
    • 9.5.3 패턴 구조 548
    • 9.5.4 협력 역할 551
    • 9.5.5 결과 552
    • 9.5.6 구현 방법 553
    • 9.5.7 예제 모델 553
  • 9.6 스마트 포인터 패턴 554
    • 9.6.1 요약 555
    • 9.6.2 문제 555
    • 9.6.3 패턴 구조 556
    • 9.6.4 협력 역할 557
    • 9.6.5 결과 558
    • 9.6.6 구현 방법 560
    • 9.6.7 관련 패턴 560
    • 9.6.8 예제 모델 560
  • 9.7 가드 호출 패턴 562
    • 9.7.1 요약 562
    • 9.7.2 문제 562
    • 9.7.3 패턴 구조 562
    • 9.7.4 협력 역할 563
    • 9.7.5 결과 564
    • 9.7.6 구현 방법 564
    • 9.7.7 예제 모델 565
  • 9.8 컨테이너 패턴 567
    • 9.8.1 요약 568
    • 9.8.2 문제 568
    • 9.8.3 패턴 구조 569
    • 9.8.4 협력 역할 570
    • 9.8.5 결과 570
    • 9.8.6 구현 방법 570
    • 9.8.7 예제 모델 570
  • 9.9 랑데부 패턴 580
    • 9.9.1 요약 581
    • 9.9.2 문제 581
    • 9.9.3 패턴 구조 581
    • 9.9.4 협력 역할 582
    • 9.9.5 결과 583
    • 9.9.6 구현 방법 583
    • 9.9.7 관련 패턴 584
    • 9.9.8 예제 모델 584
  • 9.10 앞으로 586
  • 9.11 연습문제 586
  • 9.12 참고 자료 587
    
• 10장 상세 설계 589
  • 10.1 상세 설계 590
  • 10.2 데이터 구조 591
  • 10.3 연관 598
  • 10.4 오퍼레이션 601
  • 10.5 가시성 603
  • 10.6 알고리즘 604
  • 10.7 예외 611
  • 10.8 요약 615
  • 10.9 연습문제 616
  • 10.10 참고 자료 616
    
• 11장 특별 주제: C4ISR 아키텍처와 UML 617
  • 11.1 소개 618
  • 11.2 C4ISR 618
  • 11.3 C4ISR의 필수 산출물 625
    • 11.3.1 AV-1 개요와 요약 정보 625
    • 11.3.2 AV-2 통합 사전 625
    • 11.3.3 OV-1 상위 수준 운영 개념 그래픽 629
    • 11.3.4 OV-2 운영 노드 연결 기술 629
    • 11.3.5 OV-3 운영 정보 교환 매트릭스 631
    • 11.3.6 SV-1 시스템 인터페이스 기술 633
    • 11.3.7 TV-1 기술 아키텍처 프로파일 634
  • 11.4 지원 산출물 634
    • 11.4.1 OV-4 지휘 관계 차트 635
    • 11.4.2 OV-5 운영 활동 모델 636
    • 11.4.3 OV-6a 운영 규칙 모델, SV-10a 시스템 규칙 모델 638
    • 11.4.4 OV-6b 운영 상태 전이 기술, SV-10b 시스템 상태 전이 기술 640
    • 11.4.5 OV-6c 운영 이벤트-추적 기술, SV-10c 시스템 이벤트-추적 기술 643
    • 11.4.6 OV-7 논리적 데이터 모델 643
    • 11.4.7 SV-3 시스템-시스템 매트릭스 643
    • 11.4.8 SV-4 시스템 기능 기술 644
    • 11.4.9 SV-5 운영 활동-시스템 기능 추적 매트릭스 645
    • 11.4.10 SV-6 시스템 데이터 교환 매트릭스 646
    • 11.4.11 SV-7 시스템 성능 매개 변수 매트릭스 647
    • 11.4.12 SV-8 시스템 발전 기술 649
    • 11.4.13 SV-9 시스템 기술 예측 649
    • 11.4.14 SV-11 물리적 스키마 650
  • 11.5 요약 651
  • 11.6 감사의 글 652
  • 11.7 참고 자료 652