초보자를 위한 UML 객체지향 설계 제3판 - ipg.kripg.kr/ebook/pdf/5674-217.pdf · 시작하면서 25 PART 3에서는UML을디자인패턴과임베디드시스템(embedded

세상을살아가는데있어서비전(vision)만큼중요한것은없다. 컴퓨팅산업은더욱그러하다.

지금까지의 훌륭한 시스템들 역시 어떻게 기술들을 개선하고 발전시킬 수 있을까 에 대한

비전을 가진 사람들에 의해서 이루어져 왔다. 개발자라면 반드시 이런 생각을 충분히 이해하

여야 하고, 자신이 가진 비전을 구체화시킬 수 있는 시스템을 개발하면서 꼭 염두에 두어야

한다.

시스템 개발 프로젝트는 비전을 쫓는 사람과 개발자의 사이에 다리를 놓아줄 때 성공적이라

고말할 수 있다. UML(Unified Modeling Language)은 바로이 다리를 놓는데사용되는 도구

이다. UML은 개발할 시스템에 대한 비전을가지도록 하며, 이시스템에 관여하고 있는 다른

사람에게자신의비전을 알리고의견을얻을 수있도록돕는데 목표를두고있다. UML은 정

해진 기호(symbol)와 다이어그램(diagram)을 사용하여 이러한 목적을 이루어내고 있다.

이책의목적은 여러분들이 UML을 탄탄하게공부할수 있도록돕는것이다. 이를위하여 각

장에서는여러분의이해를도와줄예제와새롭게알게된지식을적용할수있는연습문제를

준비해 두었다.

이번판에서 달라진 부분은?필자는제3판을준비하면서 앞의 1판과 2판을 자세히 살펴보고, 필요한 곳에 추가 및 업데이

트를 하며 강화시켜 나갔다. 추가되어야 할 부분이 필요한 이유는 새롭게 채택된 UML 2.0

때문이다. 또한, 시간의 흐름과 기술의 진보도 한 몫 했다.

시작하면서

24 초보자를 위한 UML 객체지향 설계 제3판

1판과 2판에서처럼 14장 패키지와 UML의 구조를 확실히 익혀둡시다 는 UML의 근본구조인 이

론적인개념을나타낸다. 이번 3판에서는UML 2.0의새로운개념을수용하기위해대폭확장

시켰다.

게다가 모델과다이어그램에 대한 생각을 일부 개량했고, 퀴즈 질문과 연습문제를추가했다.

이번 3판에서개량된곳은 모든교류다이어그램에클래스의오퍼레이션을보여주기 위해클

래스다이어그램을 먼저그렸다는 부분이다. 교류다이어그램에서 보여지는메시지를 뚜렷하

게 좀 더 직관적으로 만들려는 게 목적이다. 만약 UML을 조금이라도 안다면 필자의 이야기

가무슨말인지이해할수있을것이다. UML을처음보는것이라면....흠...그렇다면...(잠시먼

산...) 이해하기 힘들겠지만, 이 책의 후반부로 가면 확실히 이해할 수 있게 될 것이다.

누가 이책을 읽어야 할까?이 책은 시스템 분석가, 관리자, 디자이너, UML의 기초를 빠르게 정복해야 하는 개발자들을

겨냥하고있다. 만약UML로바로작업을시작해야하거나, 다른사람의 UML 작업을충분히

이해해야만 한다면 바로 이 책이 적격이다.

이책의 구성

필자는이책을세개의부로나누었다. PART 1에서는UML의전체적인개요와더불어, 객체

(object)와 클래스(class)를 도식화하기 위한 기반을 이루는 객체지향 개념에 대해 가르쳐 줄

것이다. 또한, 유스 케이스(use case), 즉 시스템을 사용자에게 보이는데 필요한 구조에 대해

여러분들이 알아보고, 이것을 도식화하는 방법도 동시에 공부하도록 한다. 필자는 여분의 시

간을객체지향과유스 케이스의개념에투자했다. UML의기초를형성하는데다가, 가장많은

시간동안사용되기때문이다. UML 다이어그램을그리는데 필요한나머지사항도 PART 1에

서 함께 다루어 보도록 한다.

PART 2에서는 가상의 사례 연구를 통해 시스템 개발에 필요한 방법론을 단순화시켜 다루어

간다. 여기서 UML이 어떻게프로젝트개발에 맞아떨어지는지를보여주도록 하겠다. 여러분

은 UML의 각 요소가 어떻게 시스템 모델과 연동되는 지를 확인할 수 있을 것이다.

시작하면서 25

PART 3에서는 UML을 디자인패턴과임베디드시스템(embedded system)에 적용해본다음,

다른 분야에 대한 적용 가능성도 아울러 점쳐 본다.

현재몇몇 업체들이 UML 다이어그램을작성하여 모델화시킬 수있도록 하는 패키지를내놓

고있다. 부록 B UML 모델링 도구를 사용하여 작업하기 에서는해당도구에대한 감각을키워주

기 위해 Microsoft 비지오 프로페셔널 에디션(Visio Professional Edition)으로 세 개의 UML

다이어그램을그림으로써 그 사용감각을 익힐 수있도록 하였다. 또한, 다른 모델링 도구세

가지도 짧게 요약해 놓았다.

하지만이책을가지고공부할때여러분에게필요한것은단지UML 다이어그램을그리는데

필요한 종이와 연필, 그리고 시스템 설계 기술이 현재 어느 정도까지 와있는 지에 대한 상당

한 호기심뿐이다.

이 책에 쓰인 규칙

이 책으로 공부를 하다보면 다음과 같은 것들을 보게 된다.

▣각 장은 이장의 학습내용의리스트로시작한다.

▣ 새로운 단어는 특별한 폰트를 사용했다. 예를 들어, 각 객체로부터 밑으로 늘어져 있는 점선을 객체

의 생명선이라고 부른다.

▣ 책을 읽다 보면 특별한 부연 설명이 나타나기도 한다. 주요 흐름과 상관없는 유용한 정보를 나타낼

때사용된다.

객체의 중요성

2장 객체지향을 이해합시다 , 3장 객체지향 개념을 적용해 봅시다 , 4장 관계를 지어 봅시다 에서객체지

향의개념을 다루고있다. 이개념은책전체에걸쳐서 매우중요한역할을 맡고있다.

자, 이제 모델링의 세계로 떠나보자.

26 초보자를 위한 UML 객체지향 설계 제3판

강의 지원

효과적인강의를돕기위한자료를다음의홈페이지에서서비스하고있으니참고하기바란다.

ht t p : / / www. i nf o pub . co . kr

Microsoft Powe rpoint로 작성된 슬라이드 — 강사 분들이나 교수 분들을 위해 본 서적의 강의를

도와줄 수 있는 교육용 자료(교안)를 제공받을 수 있다. 단, 도서 문의 게시판을 통해 교육용 자

료를 요청한교수, 강사 분들께만제공되는점을 유의해주기바란다.

연습 문제의 해답에 대해서

연습 문제 해답

이책에나오는 연습 문제에 대한 해답을 알려줄 수 없다는 것에 유념해 주기 바란다. 그런 종류의 일은

학생들을 가르치는 교수, 강사의 몫이며, 필자의 재량권 밖의 일이기 때문이다. 책의 필자(역자)라고 하

더라도, 교수나 강사의 고유 권한을 침범할 수는 없다. 그러나 이 책은 도움이 필요한 학생들을 위해 퀴

즈나 Q&A에대한상세한해답과 자세한설명을포함하고있다.

Cha pte r 1 UML을 소 개 합 니 다

Cha pte r 2 객 체 지 향 을 이 해 합 시 다

Cha pte r 3 객 체 지 향 개 념 을 적 용 해 봅 시 다

Cha pte r 4 관 계 를 지 어 봅 시 다

Cha pte r 5 집 합 연 관 , 복 합 연 관 , 인 터 페 이 스 그 리 고 실 체 화

Cha pte r 6 유 스 케 이 스 와 의 만 남 은 우 연 이 아 니 다

Cha pte r 7 유 스 케 이 스 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 8 상 태 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 9 시 퀀 스 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 10 통 신 다 이 어 그 램 을 그 려 봅 시 다

UML 입문

36 PART 1 UML 입문

Cha pte r 11 활 동 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 12 컴 포 넌 트 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 13 배 포 다 이 어 그 램 을 그 려 봅 시 다

Cha pte r 14 패 키 지 와 UML의 구 조 를 확 실 히 익 혀 둡 시 다

Cha pte r 15 시 스 템 개 발 과 정 에 UML을 적 용 하 기 위 한 도 움 닫 기

이 장 의 학 습 내용

▣왜 UML이필요할까?

▣UML이 어떻게 생겼을까?

▣UML 다이어그램에 대하여

▣왜 굳이 여러가지의 다이어그램을 사용해야 할까?

UML을 소개합니다1


UML(Unified Modeling Language)은오늘날의객체지향시스템개발분야에서가장각광받는

도구중 하나이다. 왜그럴까? UML은 시스템개발자가 자신의비전(vision)을 구축하고반영

하는데있어서표준적이고이해하기쉬운방법으로할수있도록도와주며, 자신의설계결과

물을 다른 사람과 효과적으로 주고받으며 공유할 수 있는 메커니즘을 제공하기 때문이다.

비전을 나눈다는 것은 요즘 시대에서 없어서는 안될 중요한 것이다. UML이 있기 전의 시스

템개발은 때려 맞추어서운좋으면 성공하고, 틀리면망한다는 명제였다. 시스템분석가는

의뢰인의 요구를 받아들여 적당히 조정하고, 분석가들이 이해할 수 있는 일정한 표기법을 사

용하여 요구사항을 명세화하며(하지만 고객은 알 길이 없다), 분석 결과를 프로그래머 혹은

개발팀에게 넘긴 다음 최종 제품이 제발 의뢰인이 원하는 것으로 만들어지기를 기도하기 일

쑤였다.

몇 가지 용어

이책에서이야기하는 시스템 (system)이라는용어는비즈니스 문제에 대한솔루션을 제공하는 소프트웨

어와 하드웨어가 합쳐진 개념이다. 시스템 개발 (Syste m deve lopment)은 고객이 필요로 하는 시스템을

만드는(create) 것이며, 고객(client)이란, 솔루션을 필요로 하는 사람이다. 분석가 (a na lyst)는 고객의

문제를 문서화하여 개발자에게 전달하며, 개발자 (develope r)는 문제를 해결할 수 있는 소프트웨어를 만

들고, 그것을컴퓨터 하드웨어에 설치하는 프로그래머에게전달한다.

시스템 개발은 인간 생활과 똑같기 때문에, 어느 단계에서든지 오류가 발생할 가능성은 다분

히존재한다. 분석가는의뢰인의 요구를 잘못이해할 수 있으며, 의뢰인이이해할 수 없는문

서를 만들어낼 수도 있다. 프로그래머가 분석 결과를 명쾌하게 이해하지 못하고 사용하기 어

려운 프로그램을 만들어 냄으로써, 의뢰인의 문제를 제대로 해결해 주지 못할 수도 있다.

오늘날사용되고 있는장수 프로그램의대다수가 거추장스럽고까다로우며, 사용하기에도 어

렵다는 사실에 대해 궁금하지 않은가?

복잡한 세상 바로 잡기

컴퓨팅 시스템의 초창기에는 프로그래머들이 대개 면밀한 문제 분석에 의존하지 않은 것이

보통이었다. 문제 분석이 있었다고 해도 거의 잊어버리거나 귓등으로 흘려 보내기 일수였다.

그들은 프로그램을 밑바닥부터 만들어 올렸으며, 필요한 코드를 스스로 만들었다. 그 당시에

Chapter 1 UML을 소개합니다 39

야이러한것들이추억담이나무용담이될수있었겠지만, 오늘날과같이위험도높은업계에

서는 적당하지 못하다.

오늘날에는 치밀한 사고와 기획만이 살아 남는다. 의뢰인은 개발팀이 무엇을 할 지 이해해야

하고, 개발팀이 의뢰인의 요구를 제대로 이해하지 못했을 경우에는(혹은 의뢰인이 마음을 바

꾸었을경우) 변경점을 지적해 주어야한다. 또한, 시스템 개발은 팀 지향적인활동이기 때문

에, 개발팀의 각 멤버는 자신이 개발 작업의 어느 분야에 적합한 지를 파악해야 한다.

점점복잡해지는세상에컴퓨터기반시스템역시덩달아복잡해지고있다. 여러대의하드웨

어와 소프트웨어는 기본이고, 하드웨어를 연결하기 위한 네트워크 시스템과 데이터베이스도

필요해졌다. 다음 세기로 여러분을 이끌 시스템을 개발하고자 한다면 어디부터 손을 대어야

할까?

열쇠는 단 한 가지이다. 시스템 개발에 참여하는 분석가, 의뢰인, 프로그래머, 그 외의 모든

이들이 이해하고 동의할 수 있는 방법으로 설계 과정을 조직화하는 것이다. UML은 바로 이

조직화 수단을 제공하기 위해 준비된 것이다.

먼저, 자세한청사진을 세우지 않으면사무실 빌딩 같은복잡한 구조물을 만들수 없듯이, 상

세한 계획을 세우지 않으면 이 사무실 빌딩에 들여놓을 복잡한 시스템을 구축할 수 없다. 이

계획은건물주에게 건축가가설계도를 보여주듯이, 소프트웨어를 사용할고객에게 보여주는

설계도와 똑같다. 이 디자인 계획은 고객의 요구를 상세하게 분석한 결과로써 주어진다.

요즈음의 시스템 개발 추세는 전체 개발 기간을 짧은 시간 간격(timeframe)으로 나누는데 있

다. 각각의시간 간격끝에 작업기한(데드라인)이 놓여지면이제 완전한설계가 뒤를따르게

될 수밖에 없다.

또 하나는 현대의 생활 패턴이 완벽한 설계를 요구하고 있다. 즉, 업무 인수 인계(corporate

takeover)이다. 한 회사가 다른 회사를 받아들였을 때 새 조직이 진행중인 개발 프로젝트의

중요한부분을바꿀지도모르는일이다(구현도구, 코딩 언어 등). 이때집행부의집중사격

을막을 수있는 완전한설계 계획이 문서로구비되어 있으면 업무변경이 부드럽게 이루어

진다.


탄탄한 설계에 대한 필요성은 바로 디자인 표기(design notation)에 대한 필요성을 낳았다. 전

자 회로를 체계적으로 그려 둔 도면을 엔지니어가 읽을 수 있듯이 분석가, 개발자, 의뢰인이

표준으로 받아들일 수 있는 디자인 표기이다. UML은 바로 그 표기이다.

UML의 탄생 배경

UML은그래디부치(Grady Booch), 제임스럼버(James Rumbaugh), 이바야콥슨(Ivar Jacobson)의

머리에서 태어났다. 최근 쓰리 아미고(Three Amigos 3인방) 라고 불리는 이 세 신사들은

원래 80년대 전반과 90년대 초반까지 객체지향 분석 설계 분야에서 각자의 영역에서 방법론

을 연구해 왔었다. 그들이 발표한 방법론은 동일한 분야의 다른 경쟁자들보다 항상 탁월한

위치에 있었으며, 세 사람은 90년대 중반에 이르러 각자의 아이디어를 교환하기 시작하였고,

결국 각자의 방법을 하나로 모아 합치기에 이른다.

객체지향s

객체지향 개념에 대해서는 2장 객체지향을 이해합시다 와 3장 객체지향 개념을 적용해 봅시다 그리고 4

장 관계를 지어 봅시다 에서 공부하게 된다. 사실, 이 책에서 객체지향 개념을 빼면 아무 것도 남는 것

이없다.

1994년, 럼버는 부치가 이미 세운 래쇼날 소프트웨어(Rational Software Corporation)에 영입

되었고, 야콥슨은 그로부터 1년 후에 래쇼날 사에 들어가게 된다.

나머지는그들이말하듯이, 역사(history)라고말할수있다. UML의초안(draft) 버전은소프트

웨어 업계를 뒤흔들기 시작하였고, 그 결과로 돌아온 피드백은 바로 변경점에 반영되었다.

UML은우리들의전략에딱맞는다 라고인식해가는회사가늘어남에따라그결과로UML

컨소시엄도발족하게되었다. UML 컨소시엄의멤버로는 디지털(DEC), 휴렛-팩커드(Hewlett-

Packard), 인텔리캅(Intellicorp), Microsoft, Oracle, 텍사스 인스트루먼트(Texas Instruments),

래쇼날 사 등이 있었다. 1997년 UML 컨소시엄은 UML 버전 1.0을 만들어내고, 오브젝트 매

니지먼트그룹(OMG : Object Management Group)이표준모델링언어의제안서를내라는요

구에 맞추어 이것을 제출하였다.

UML 컨소시엄은계속 발전하였으며, OMG에 다시상정된 UML 1.1은 1997년 말에 표준모

델링 언어로 채택되었다. OMG는 UML의 관리 기법을 받아들여 1998년에 새로운 수정안을


발표하였다. UML은 소프트웨어 업계의 명실 상부한 표준이 되었으며, 계속 수정 보완되고

있다. 버전 1.3과 1.4 그리고 1.5가나와있고, 최근에는버전 2.0이 OMG에의해승인된상태

이다. 이전버전들, 즉버전 1.X는현존하는대부분의모델및 UML 모델링책의기본이되어

왔다. 자, 이제 이 책을 통해 이전 버전과 새로운 버전의 차이점에 대해 알아보도록 하자.

UML의 구성요소

UML의여러가지그래픽요소는하나의큰그림, 즉다이어그램을그리는데사용된다. UML

은언어이기때문에, 이들그래픽요소들을서로맞추는데에는규칙이필요하다. 각각의그림

조각과요소에대해서시시콜콜히이야기하기보다는다이어그램을먼저이해시키는것이필

자나 여러분 입장에서 더 나을 것이다. 왜냐하면, 우리는 시스템 분석이 목표이기 때문이다.

해보면서 배운다

해보면서 배운다라는 필자의 방법은 외국어 학습과도 비슷하다. 문법을 배우고 어휘를 끼워 맞추는 것

보다 일단 읽고, 쓰고, 말해 보고 하는 것이 더 써먹기 좋기 때문이다. 이런 식으로 외국어를 사용하는

시간이많아지면문법이나 동사변형을이해하기도훨씬쉬워진다.

다이어그램의 목적은 시스템을 여러 가지 시각에서 볼 수 있는 뷰(View)를 제공하는 것이며,

이러한 뷰의 집합을 모델(Model)이라고 한다. 시스템의 UML 모델은 건물을 짓는 건축가의

스케일모델과도비슷하다. 꼭알아두어야할점이있다면, UML 모델은시스템자체의 목적

행동 을 설명하는 언어라는 것이다. UML 모델은 시스템의 구현 방법을 설명하는 수단 이

아니다.

이제 UML에서 가장 흔히 사용되는 다이어그램과 각각의 개념을 간략하게 알아보기로 하자.

여기서 간략하게 알아볼 각각의 개념은 PART 1의 후반부에서 하나씩 자세히 다루도록 하겠

다. 이다이어그램들은얼마든지다른형태로조합할수있으며, UML은다이어그램을조직화

하고 확장시킬 수 있는 수단을 제공한다는 것을 잊지 말아달라는 부탁도 곁들인다.


모델

모델은이학 및공학 분야에서상당히유용하게쓰이는 개념이다. 가장일반적인의미로 이야기하면, 모

델을 만든다는 것은 여러분이 잘 모르고 있는 어떤 것을 이해하는데 도움이 될 것으로 추측되는 어떤

것을 사용한다는 뜻이다. 어떤 분야에서는 이 모델의 일련의 수식(방정식)의 집합으로 정의되기도 하며,

다른분야에서는컴퓨터 시뮬레이션을모델로 삼기도한다. 이렇듯 모델은가지각색이다.

여러분들은 시스템의 이해와 개발에 필요한 UML 다이어그램(직접 조사해 보고, 평가해 보고, 수정해

볼수있는)을모델로 삼도록하자.

클래스 다이어그램

객체지향 기술은 여러분의 주변 상황과 가끔 흡사하다. 대부분의 사물은 자기만의 속성

(attribute)과일정한 행동(behavior) 수단을 가지고있다. 이러한행동을 오퍼레이션(operation)

의 집합으로 생각할 수 있을 것이다.

택시는 탈 것, 의자는 가구 범주에 넣을 수 있듯이, 사실 우리 주변에서 발견할 수 있는 대부

분의 것들은 어떠한 범주(category)에 넣을 수 있다. 이러한 범주를 클래스라고 한다. 클래스

(class)란, 비슷한 속성과 공통적인 행동 수단을 지닌 것들의 범주 혹은 그룹을 일컫는다. 세

탁기(washing machine)의클래스가있다고가정하고예를들어보자. 이클래스의속성은브랜

드 이름, 모델, 일련 번호, 용량 등이고, 이 클래스의 행동은 옷을 넣는다(accept clothes) ,

세제를 뿌린다(accept detergent) , 켜다(turn on) , 끄다(turn off) 등일 것이다.

[그림 1.1]은방금이야기한세탁기의속성과행동을 UML로그린예로써, 사각형은클래스를

나타내는 UML 아이콘이다. 이 사각형은 세 부분으로쪼개져 있다. 가장윗 영역에는 클래스

의 이름을 넣고, 둘째 영역은 속성을 넣는 공간 그리고 가장 마지막 영역은 오퍼레이션을 넣

는 공간이다.

그림에서클래스와속성그리고행동의이름을각각눈여겨보도록하자. UML에서는두단어

이상으로 이루어진 클래스 이름은 단어 사이의 공백을 없애고, 각 단어의 처음 문자를 모두

대문자로한다(예 : Wa s hi ngMa c h i ne). 속성과행동의 이름 또한마찬가지이지만, 가장 앞

단어의 처음 문자는 소문자로 한다(예 : a c c e pt Cl ot he s ( ) ). 행동을 나타내는 이름 뒤에

소괄호(( ))가 붙는 이유는 3장에서 다루도록 하겠다.


[그림 1 .1] UML 클래스 아이콘

4장에서는클래스다이어그램이여러선들에 의해다른사각형아이콘들과연결된모습을 볼

수 있을 것이다. 클래스가 다른 클래스와 어떻게 관계를 맺고 있는지 보여주는 모습이다.

UML과친해지려면우선주변사물을속성과행동으로생각하는버릇을들여보자. 복잡한업

무를 순조롭게 진행시키기 위하여 대부분의 최신 시스템은 실세계를 그대로 흉내낸 형태로

만들어진다. 이것은 수십년 간의 경험에서 나온 결과로써, 실세계의 작업을 수행하는 클래스

를 소프트웨어로 나타낼 때 이렇게 하는 것이 소프트웨어를 개발하기에 가장 쉽다. 클래스

다이어그램을 그리는 일은 이 작업의 시초라고 할 수 있다.

이뿐만이아니다. 클래스다이어그램은시스템분석에도도움을준다. 이클래스다이어그램

이 있기 때문에, 분석가는 의뢰인(Client)과 상담할 때 의뢰인의 용어 로 이야기할 수 있고,

의뢰인 자신이 원하는 솔루션에 대하여 자세히 털어놓을 수 있도록 자극할 수 있다.

객체 다이어그램

객체(Object)란, 클래스의 인스턴스 즉, 값이 매겨진 속성과 행동을 가지고 있는 개별적인 개

체를일컫는다. 세탁기를예로들면 정보전자 라는브랜드명과 발빨래세탁기 라는모델명,

그리고 GL57774 라는일련번호와 16파운드 라는용량을가진하나의세탁기가객체가될

수 있다.

[그림 1.2]는객체를 UML로나타낸그림이다. 아이콘자체는클래스와똑같이사각형이지만,

이름에밑줄이그어져있다. 인스턴스의이름은콜론(:)의왼편에쓰며, 클래스의이름은콜론

의오른편에쓴다. 인스턴스의이름은 소문자로시작하고, [그림 1.2]의 오른쪽아이콘처럼 익

명의 객체도 가능하다. 객체가 속해 있는 클래스를 보여주는 것에만 중점을 둠으로써, 특정

이름을 지정해 주지 않은 것이다.


[그림 1 .2] 2개의 UML 객체 아이콘 - 왼쪽의 아이콘은 이름이 있는 객체, 오른쪽 아이콘은 익명의 객체를

나타낸다.

유스케이스 다이어그램

유스케이스(use case)는사용자의입장에서본시스템의행동을일컫는다. 시스템개발자에게

이 유스 케이스라는 것은 무척 값진 도구가 된다. 왜냐하면, 사용자가 원하는 시스템 사항을

얻어내는데유용하게쓰이기때문이다. 목표가사람들(단지컴쟁이뿐만아니라)이사용할수

있는 시스템을 만드는 것이라면 더욱 중요하다.

유스케이스에대해서는 6장 유스 케이스(Use Case)와의 만남은 우연이 아니다? , 7장 유스 케이

스 다이어그램을 그려봅시다 , 18장 시스템 요구사항의 수집 , 19장 유스 케이스 만들기 에서좀더

자세히이야기할기회가있을것이다. 일단, 지금은예제만눈요기하도록하자. 현재여러분이

세탁기를사용하는이유는옷을빨기(wash clothes) 위해서인데, [그림 1.3]에서이것을UML 유스

케이스 다이어그램으로 그려보았다.

[그림 1 .3] UML 유스 케이스 다이어그램

세탁기사용자를 나타내는 막대인간 그림을 행위자(actor)라고 한다. 타원은유스 케이스(use

case)를 나타낸다. 행위자(유스 케이스와 대화를 시작하는 개체)-사람 혹은 다른 시스템이 될

수 있다. 또한, 유스 케이스가 시스템을 의미하는 사각형 내에 있고, 행위자는 사각형 바깥에

있음을 유의하여 보기 바란다.


발음에 관한 팁

보통 use case 라고하면 유즈케이스로 발음하기 쉬우나여기서는 유스케이스로발음하기바란다.

상태 다이어그램

객체는시간에따라각기다른상태에있을수있다. 인간도마찬가지이다. 갓난아기로태어나

영/유아가 되고, 어린이가 되고, 10대가 되고, 성인으로 자란다. 엘리베이터는 올라갔다가, 섰

다가, 내려갈수 있다. 세탁기는물을 담고(soak), 세탁하고(wash), 헹구고(rinse), 돌리고(spin),

정지될 수 있다.

UML 상태(state) 다이어그램은 [그림 1.4]에서보듯이, 현실상황이조금많이반영되어있다.

세탁기의 상태가 단계별로 변해감을 알 수 있다.

[그림 1 .4] UML 상태 다이어그램

이 그림의 상단에 있는 기호는 시작 상태(start state)를, 하단에 있는 기호는 종료 상태(end

state)를 나타낸다.


전이

상태에서 상태로의 전이가 항상 일직선으로 이루어지는 것은 아니다. 이에 관해서는 8장 상태 다이어그

램을 그려봅시다 에서 다시이야기하도록하겠다.

시퀀스 다이어그램

클래스 다이어그램과 객체 다이어그램은 정적인 정보를 나타낸다. 하지만, 특정한 행동을 수

행하는 시스템에서는 여러 개의 객체들이 서로 메시지를 주고받으며 작업을 진행하는 것이

보통이다. UML 시퀀스(sequence) 다이어그램은 객체들끼리 주고받는 메시지의 순서를 시간

의 흐름에 따라 보여주는 그림이다.

역시 세탁기 예제를 가지고 계속 이야기하자. 세탁기는 타이머, 입수관(맑은 물을 넣기 위한

관) 그리고 드럼(빨래를 담는 통) 등으로 구성되어있다. 물론, 이것들은모두 객체이다(곧이

해하겠지만, 객체는 다른 여러 개의 객체들로 구성될 수 있다).

이제, Wash clothes 유스케이스를 작동시켰을 때 어떤 일이 일어날까? 옷을 넣는다 , 세제

를 뿌린다 , 그리고 켠다 오퍼레이션은 이미 마쳤다고 가정하면, 이 유스 케이스에서는 다

음의 행동이 단계별로 이루어질 것이다.

1. 입수 단계(Soaking)의 시작으로써 물이 입수관(water pipe)을 통해 드럼(drum)으로 들

어간다.

2. 드럼은 5분 동안 정지된 상태를 유지한다.

3. 입수 단계(Soaking)의 끝으로써 물이 들어가다 멈춘다.

4. 세탁 단계(Washing)의 시작으로써 드럼이 앞 뒤로 15분간 회전한다.

5. 세탁 단계(Washing)의 끝으로써 세제와 때가 섞인 물이 배수관을 통해 나온다.

6. 드럼의 회전이 멈춘다.

7. 헹굼 단계(Rinsing)의 시작으로써 물이 다시 들어간다.

8. 드럼은 다시 앞뒤로 회전한다.

9. 15분 후에 물이 들어가다 멈춘다.


10. 헹굼 단계(Rinsing)의 끝으로써 물(rinse water)이 배수관을 통해 나온다.

11. 드럼의 회전이 멈춘다.

12. 탈수 단계(Spinning)의 시작으로 드럼이 시계 방향으로 회전하기 시작하면서 5분 동안

가속한다.

13. 탈수 단계(Spinning)의 끝으로써 드럼의 회전이 멈춘다.

14. 세탁이 종료된다.

타이머, 입수관, 드럼을 각각 객체라고 해보자. 각 객체는 하나 이상의 행동을 하면서 서로에

게메시지를보내며상호적으로작동하게된다. 메시지는 보내는객체 로부터 받는객체 로

전달되는 하나의 요청이라 볼 수 있다. 받는 객체 가 할 수 있는 행동 중에서 어느 하나를

수행해달라는 의미로 부탁(?)되는 것이다.

그 행동들을 따져보자면, 우선 타이머는

▣입수의시간을 잰다.

▣세탁의시간을 잰다.

▣헹굼의시간을 잰다.

▣탈수의시간을 잰다.

를 할 수 있고,

입수관은

▣물을흘려보낸다.

▣물을막는다.

를 행동할 수 있다.

또한, 드럼은

▣물을저장한다.

▣앞 뒤로회전한다.

▣시계방향으로 회전한다.


▣ 회전을멈춘다.

▣ 물을빼낸다.

가 가능하다.

[그림 1.5]는시간의흐름에따른입수관, 드럼, 배수관(그림상단에익명의객체로되어있다)

사이의 상호 대화를 나타낸 시퀀스 다이어그램이다. 화살표는 하나의 객체에서 다른 객체로

전달되는메시지를의미한다. 이다이어그램에서시간은위에서아래로 흐른다. 첫번째 메시

지는 타이머가 자신에게 보내는 t i me Soa k ( ) 이고, 두 번째는 타이머가 입수관(WaterPipe)

으로 보내는 s e ndWa t e r ( ) 메시지이다. 마지막 메시지는 s t opRot a t i ng ( ) 으로써 타이

머에서 드럼으로 전달된다.

객체가 메시지를 보낼 때 자기 자신에게도 보낼 수 있음(타이머 객체)을 알길 바란다. 또한

화살표의끝모양이모두같지않음을알수있는데, 여기에관해서는 9장 시퀀스 다이어그램을

그려봅시다 에서 자세히 다루어보도록 하겠다.

( 익명의 객체 가 무엇을 의미하는지 기억이 나지 않는다면 [그림 1.2]를 다시 확인해 보자.)

활동 다이어그램

유스케이스내부혹은객체의동작중에발생하는활동(activity)은대개시퀀스내에서발견할

수 있다. 바로 앞에서 배운 전체 14단계가 활동에 해당되며, [그림 1.6]은 4단계부터 6단계까

지를 활동 다이어그램으로 그려보았다.

전이 II

이미 앞에서 상태에서 상태로의 전이가 항상 일직선으로 이루어지는 것이 아니다라고 언급한 적이 있

는데활동다이어그램에서도 마찬가지이다. 11장 활동 다이어그램을 그려봅시다 에서 자세하게이야기하

도록하겠다.


[그림 1 .5] UML 시퀀스 다이어그램


[그림 1 .6] UML 활동 다이어그램

통신 다이어그램

하나의 시스템을 구성하는 요소들은 다른 요소들과 손발을 맞추면서 시스템 전체의 목적을

이루어나가는 것이 보통이기때문에, 모델링언어는 이것을 표현할수 있어야 한다. 앞서말

한 시퀀스 다이어그램이 그것이고, UML 통신(communication) 다이어그램 또한 이러한 목적

을 위하여 디자인된 것으로, [그림 1.7]에 그 예를 보여준다. 하지만, 시퀀스 다이어그램과는

어느정도다른점이있다. [그림 1.7]의통신다이어그램은 [그림 1.5]의시퀀스다이어그램에

서 타이머와 입수관, 드럼 사이에 오가는 메시지 중에 초반의 것들만을 뽑아내어 보여주고

있는데, 보다시피위에서아래, 즉수직으로시간경과를보여주는것이아니고, 메시지에숫자

를 붙임으로써 그 순서를 보여주고 있다.

시퀀스 다이어그램과 협력 다이어그램은 객체 사이의 상호관계를 나타내는 다이어그램이기

때문에 UML에서는 이 둘을 통합적으로 교류(interaction) 다이어그램이라고 부른다.

이름의 변화

통신 다이어그램의이름은버전 2.0에서 처음 생겨난것이다. 버전 1.X에서는 협력 (collaboration) 다이

어그램이라고 불렀다. 버전 2.0에서 정착되었기 때문에 두 단어가 서로 사용된다 하더라도 생소해 하질

않길바란다.


[그림 1 .7] UML 통신 다이어그램

컴포넌트 다이어그램

이다이어그램과다음다이어그램에서는세탁기이야기를그만하도록하겠다. 컴포넌트다이

어그램과 배포 다이어그램은 컴퓨터 시스템을 명확하게 나타낼 수 있도록 준비된 것이기 때

문이다.

현대의소프트웨어개발추세는컴포넌트중심으로되어가고있다. 팀단위로수행하는프로

젝트라면 특히 중요한 것이 컴포넌트이다. 하여간 여기서는 오래 이야기하지 않고 그림으로

대신하고자한다. [그림 1.8]은소프트웨어컴포넌트를버전 1.X에서 UML로나타낸것이다.

[그림 1 .8] 버전 1. x에서의 UML 컴포넌트 다이어그램

실제 현업 종사자들에게서 위 기호가 어색하다는 반응이 많아, UML 2.0에서는 새로운 기호

로 바뀌었다. [그림 1.9]를 봐주기 바란다.


[그림 1 .9] 버전 2. 0에서의 UML 컴포넌트 다이어그램

거듭 인용표(«»)는 무엇일까?

[그림 1.9]의 component 양옆에 있는 «»는 무엇을 의미할까? UML에서 이 기호는 매우 특별한 기

호이다. 한두장뒤에서보게 될 키워드와스테레오타입 부분에서 다루어보도록하겠다.

배포 다이어그램

UML 배포(deployment) 다이어그램은 컴퓨터를 기반으로 하는 시스템의 물리적 구조를 나타

낸그림이다. 이다이어그램은컴퓨터와부가장치, 그리고각각의연결관계뿐만아니라, 각각

의 기계에 설치된 소프트웨어까지 표시한다. 컴퓨터는 큐브로 나타내며, 컴퓨터 사이의 연결

관계는 큐브와 큐브 사이를 선으로 이어줌으로써 나타낸다. [그림 1.10]의 예를 살펴보자.

[그림 1 .10] UML 배포 다이어그램


이외의 것들

앞서 이야기했듯이, UML은 다이어그램을 조직화하고 확장할 수 있는 장치를 가지고 있다.

이번에는 그것들에 대하여 소개할 순서이다.

노트

다이어그램을 그리다 보면 왜 이것이 필요한지 혹은 어떻게 작동하는지 에 대한 명확한

설명을하고있지않은부분이생길수있다. 이경우, UML 노트(note)를사용하면된다. 노트

는 붙였다 떼었다 할 수 있는 노란 메모지를 생각하면 바로 맞아떨어진다. 노트의 아이콘은

한쪽귀가 접힌 사각형이며, 안에는부가 설명을 쓸수 있다. [그림 1.11]에 노트의 사용예를

보여주고 있는데, 노트를 다이어그램 요소에 붙이려면 점선을 사용한다.

[그림 1 .11] 어떠한 다이어그램 요소에도 노트를 붙여서 부가 설명을 달 수 있다.

키워드와 스테레오타입

UML에 준비된 것들은 그 자체로 매우 유용하지만, 시스템 설계자들이 생각할 수 있는 모든

것을제공하는것은아니다. 앞으로새로운개념과새로운기호를필요로하는모델을생성해

야 할 일이 생길지도 모른다. 이런 경우 사용하는 것이 스테레오타입이다. 스테레오타입

(stereotypes)은 기존의 UML 요소를 기본으로 하여 다른 요소를 새로 만들 수 있게 하는 장

치이다. 양복점에서옷을산다음, 여러분의기장이나품에맞게다시손보는것과마찬가지로

(어차피 처음부터 옷을 만드는 일은 쉽지 않을테니까), 일종의 변형이라고 생각하면 쉽다. 스

테레오타입은 원하는 이름을 거듭인용표(«»)로 감싸는 것으로 간단히 마무리 되며, 이렇게 된

이름을원하는곳에사용하면된다. 그리고거듭인용표에감싸여진이름을 키워드(keyword)라

고 부른다.


간혹 UML에서는새로운 기호 자체를생성하여 사용하는 대신이미 존재하는 개체에키워드

를 부가하여 사용하는 경우가 있다. 키워드는 개체가 원래 존재하는 의미로서가 아닌 어떤

다른목적으로사용되었음을나타낸다. 인터페이스의개념을가지고설명하는것이가장좋을

것 같아서 여기에 예를 든다. 인터페이스(interface)는 오퍼레이션만 가지고 있으며 속성은 가

지지않는클래스이다. 즉, 여러분의모델에맞추어계속사용할수있는오퍼레이션의집합(5

장에좀더명확히설명되어있다)이란뜻이다. UML에서는인터페이스를나타내기위해새로

운 요소를 만들지 않고, 클래스 아이콘에 « I nt e r f a c e »를 덧붙여(클래스 이름 위에 쓴다)

사용할 수 있다. [그림 1.12]를 보도록 하자.

[그림 1 .12] 스테레오타입은 기존의 UML 요소에 거듭인용표와 키워드를 포함시킨 것이다. 키워드는 UML 요소가

원래 의미가 아닌 새로운 다른 의미로 사용되었음을 나타낸다.

스테레오타입은 UML 모델링 도구(program)를사용할때특히유용하다. 모델링도구의기능

중 사전(Dictionary) 기능이라는 것이 있는데, 여러분의 모델에서 생성된 요소들(클래스, 유스

케이스, 컴포넌트등)을저장해놓는기능이다. 여러모델링 도구마다사전기능이라는 이름이

다를 수도 있다. 사전 기능은 또한 기존의 UML 요소뿐만 아니라, 스테레오타입으로 변형된

요소들도저장해놓을수가있다. 즉, 새로운어떤요소를만들고그것을사전에 저장함으로써

좀더조직적으로수월하게관리될수있을뿐만아니라, 여러분이만든새로운요소를재사용

하는 데에도 매우 유용할 것이다.

14장 패키지와 UML의 구조를 확실히 익혀둡시다 에서 UML의 속을 들여다보고, 스테레오타입

등의근본적인개념들을다루어볼것이기때문에지금은단지 UML 아이콘에키워드가추가

된스테레오타입모양만을새겨두길바란다. 또한, UML 모델링작업을할때(특히 UML 모델

링도구를이용하여) 본래만들어진스테레오타입과이미정의된키워드(예로 «compone nt »

나 « i nt e r f a ce»)를 찾아볼 수 있게 될 것이다.


뒷걸음?

필자는 세 페이지 전의 컴포넌트 다이어그램 절에서 처음 거듭인용표에 대해 알려주었다. [그림 1.8]

의 UML 1.X 버전의 소프트웨어 컴포넌트가 [그림 1.9]의 UML 2.0 표기법으로 바뀌었음을 언급한

부분이다. 지금까지는 존재하지 않는 기호를 사용하고자 할 때 스테레오타입을 이용하여 새로운 기호를

가리킬 수있다고 말해왔는데, 컴포넌트 아이콘의 경우에는 1.X에서 2.0으로 바뀔 때 그와 반대로 이루

어진경우라고 볼수있겠다. 이미존재하고 있는기호를키워드와 클래스아이콘으로대체하고있다.

UML 2.0의 새로운 다이어그램

UML 2.0에는 소프트웨어 컴포넌트처럼 UML 1.X의 다이어그램이 새롭게 변화된 것이 있는

가 하면, 새로운 아이디어가 여러 방면으로 추가된 다이어그램도 존재한다.

복합체 구조 다이어그램

여러분이클래스 모델을만들 때클래스의 내부구조가 어떤것으로 이루어져있는지 살펴보

는것이매우유용할때가있다. 클래스가컴포넌트클래스들로구성되어있다면더욱그렇다.

예를 들어, 사람(person)이 마음(mind)과 몸(body)로 구성되어 있다고 가정해 보자. 5장에서

이런 모델링 방법의 예를 많이도 접해보게 될 것이다. Pe r s on 클래스에 속해 있는 Mi nd

클래스와 Body 클래스라는 기호, 그리고 직선들로 구성해볼 수 있다.

UML 2.0의 복합체 구조 다이어그램(composite structure diagram)에는 각 컴포넌트 클래스를

전체클래스안에위치시킴으로써넓이의개념을포함한다. 클래스로만국한되던시야를전체

구조로 넓혀보도록 하자. [그림 1.13]에서 필자가 말하고자 하는 예를 보여준다.

버전 1.X에서는 일반적인 클래스 다이어그램에서 이러한 표기법이 가능하였지만, 버전 2.0에

서는 명백한 종류의 다이어그램으로 나누어졌다.


[그림 1 .13] 복합체 구조 다이어그램은 클래스의 내부 구조를 모델링한다.

선의 철학

객체지향에 대해 좀 더 자세히 공부하게 되면 알게 되겠지만, 두 개의 클래스(예 : Mi nd 클래스와

Body 클래스)를 연결하는 직선은 대개 자신의 이름을 갖게 된다. 그렇다면 [그림 1.13]의 Mi nd와

Body 사이의 직선에는 어떤 이름을 붙여줄 수가 있을까? 철학자들은 이 문제와 관련하여 한 세대 동

안 골머리를 앓아왔다. 그리고 그들은 과연 몸과 마음을 연결해 주는 선이 존재하는지, 아니면 Mi nd

컴포넌트라는 개념이존재할수있는지등을 이야기해오고 있다.

교류 개요 다이어그램

[그림 1.6]의 활동 다이어그램을 다시 한 번 살펴보자. 하나의 단계가 하나의 활동 이 된다.

각 활동마다 객체 사이에 시간의 흐름을 갖는 메시지가 존재한다고 가정해 보겠다. 그렇다면

몇몇 활동 부분은 시퀀스 다이어그램이나 통신 다이어그램(혹은 두 다이어그램의 조합)으로

바뀌어야할것이다. 이것이UML 2.0에서새로생긴교류개요다이어그램(interaction overview

diagram)이다.

다음에 예를 들어보겠다. 여러분들은 지금 도서관에 있다.

1. 도서관 데이터베이스에서 책을 검색한다.

2. 책을 빌리기 위해 계산대로 가져온다.

3. 책을 가지고 도서관을 나가기 전에 계산한 책이란 것을 확인 받는다.

[그림 1.14]는 위의 세 단계를 간단하게 활동 다이어그램으로 구성한 것이다.


[그림 1 .14 ] 도서관에서의 3개의 활동

이제, 각 활동을분석해보자. 처음 단계에서여러분은도서관 데이터베이스(LibraryDatabase)

에원하는책의위치를물어볼것이고, 데이터베이스는책의위치를알려줄것이다. 두번째로

도서관원(Librarian)에게 책을 빌리겠다고 말하고, 계산이 끝난 후, 도서관원은 책을 가져가도

좋다고말할것이다. 마지막으로책이계산된것이라는것을감시인(Guard)에게확인받은후

도서관을 떠나게 된다.

[그림 1.15]에서 이러한 시퀀스 다이어그램이 시간에 따라 어떻게 구성되는지를 보여준다.

타이밍 다이어그램

이전에 예로 들었던 세탁기를 떠올려보자. 필자는 이 존경할만한 기계를 클래스 다이어그램,

상태 다이어그램, 시퀀스 다이어그램, 통신 다이어그램에 사용하였다. 시퀀스 다이어그램 부

분에서는각상태의시간에관해이야기한적있다(5분동안입수, 15분동안세탁, 15분동안

헹굼, 5분 동안 탈수).

[그림 1.5]의 시퀀스 다이어그램을 주의 깊게 살펴봤다면 알다시피 시간에 관해서는 전혀 언

급하지않았다. UML 2.0의타이밍다이어그램에서이러한시간을다룰수가있다. 한상태에

서 객체가 얼마나 오랜 시간을 지체하는지를 명시하는데 [그림 1.16]에서 타이밍 다이어그램

의 한 형태를 보여주고 있다.


[그림 1 .15] [그림 1. 14]의 활동 다이어그램을 자세하게 나타낸 교류 개요 다이어그램


[그림 1 .16] UML 타이밍 다이어그램

어떻게 보면새롭고, 어떻게 보면 익숙한 패키지 다이어그램

버전 1.X에서도 다이어그램의 요소를 조직화하는 기능이 존재한다. 패키지(package)라고 부

르는 것이며, [그림 1.17]처럼 탭이 달린 폴더로 나타낸다. 이 탭이 달린 폴더 안에 요소들을

집어넣음으로써 표현 가능하다. 예를 들어, 클래스 혹은 컴포넌트가 특정한 서브시스템을 구

성하는 요소로 다수 존재한다면 패키지 안에 그려 넣어주면 된다.

[그림 1 .17] UML 패키지 아이콘

패키지다이어그램을살펴보면, 버전 2.0에서더욱업그레이드되었기때문에더이상다이어

그램의 요소들을조직화하기위해골머리를앓지않아도된다. 패키지 다이어그램이면충분

하다.

왜 이렇게 다이어그램이 많을까?UML은시스템을 여러가지 시점(view)에서점검하고 관찰할수 있도록하는 도구이다. 모든

다이어그램이 모든 UML 모델에 등장하는 것은 아니라는 점에 주목해 주기 바란다(사실, 대

부분의 UML 모델은 필자가 앞서 이야기한 다이어그램으로 구성되긴 하지만 말이다).


왜 여러 가지 시점에서 시스템을 설계하고 점검해야 할까? 대개 다른 많은 참여자(stake-

holder)들이 하나의 시스템을 지켜본다. 많은 사람들이 각자의 관심에 맞추어 시스템을 바라

본다는뜻이다. 세탁기만해도그렇다. 여러분이모터설계자라면모터설계자의시점에서 세

탁기시스템을바라본다. 세탁기조작명령어를프로그래밍하는엔지니어는또다른시점에서

세탁기 시스템을 바라보고 있을 것이다. 세탁기의 외관을 디자인하는 사람은 그 세탁기가 옷

을 어떻게 빨든 간에 세탁기의 성능과 전혀 관계없는 관점을 가지고 있을 것이다.

제대로 설계된 시스템 설계라면 가능한 시점의 모든 다이어그램이 포함되어 있어야 하고, 각

각의UML 다이어그램은자신이나타내고있는시점을하나로합칠수있는수단을제공한다.

모든 참여자를 만족시키기 위해서이다.

단지 그림 몇 개 묶어 놓은 것 아닌가?몇몇 사람들은 UML 모델링이 별로 중요하지 않다고 말할지도 모르겠다. 프로젝트에서 가장

중요한 부분은 결국 프로그래밍일까? 개발자들이 진짜 작업을 하는 것이고, 모델을 만드는

사람은 단지 그림만 그리는 것뿐일까?

정확한 모델을 그리는 것이 얼마나 중요한지는 메사추세츠, 보스톤의 유명한 장기 건설 프로

젝트를 생각해보 면 알 수 있다. 정식적인 명칭은 Central Artery/Tunnel 이지만, 일반적으로

The Big Dig 이라고 더알려져 있다. 이프로젝트의 목적은보스톤의 심각한교통사고를 줄

이고자함에 있다. 도시의 한 가운데를지나는 터널 및다리를 건설함으로써, 낡고 좁은고가

도로들을 몽땅 대체한다. 이러한 교통 문제를 해결한다면 The Big Dig 은 경제적으로나 환

경적으로 막대한 이득을 안겨다 줄 것이다.

하지만, 프로젝트가 10억 달러를 넘는 투자비용을 과도하게들이고 있기 때문에 커다란 이득

을 가져올 것이라고 말하기가 애매모호해졌다. Boston Globe 의 기록에 따르면, 그 이유 중

하나가 굴착과 건설에 관련된 도면(즉, 모델)이 부정확하고 미완성되었기 때문이라고 한다.

예로, FleetCenter(보스톤의 스포츠와 엔터테인먼트를 위한 시설)의 도면 하나를 잘못 그림으

로써일으킨 불편을들어보자. 눈부신 도면의활약(?)으로건설자가 착각을일으켜 도시의특

정 부분에 중요한 선을 놓음으로써 이용할 수 없는 통로가 되어 버렸다. 또 다른 도면에선

존재하지도 않았던 맨홀(전기선 같은 것 때문에 설치) 따위가 그려져 있는가 하면, 터널 중


어느 것은 터널의 입구와 출구가 4피트나 차이가 났다고 한다. 작업자들은 이 차이를 터널을

연결하고 나서야 알아챘다고 한다.

그 결과, 잘못된 것을 다시 고침으로써 뜻하지 않은 막대한 비용이 들어감과 동시에 완료 예

정일을 훌쩍 넘어버리게 되었다.

섬뜩하지 않은가?

모델링, 배움 그리고 지식

필자가보건 데, 배움에는세단계를거치게 된다.

1. 여러분이모르고있다는 것을 모른다. 좀더 쉽게이야기하면 특정분야에전혀 익숙하지 않는다는

것을이야기한다.

2. 여러분이 모르고 있다는 것을 안다. 다른 말로 하면 어떤 분야에 대해 모두 접해보았고, 여러분이

가지고있는지식과 얼마만큼의 차이가있는지알아챈다.

3. 그차이를채워 나간다.

UML(즉, 모델링)은 여러분을 굉장히 빠른 속도로 두 번째 단계까지 안내해 주는 최고의 방법이다. 자

신이 무엇을 모르는지 빨리 깨달을 수 있을 것이고, 관련된 정보를 찾는 데에 도움을 받을 수 있을 것

이다.

요약

시스템개발은인간이하는것이기때문에, 이해하기쉬운표기방식이없으면(대형프로젝트

의 경우에 더욱) 에러를 일으킬 가능성이 매우 높다.

UML은시스템개발세계에서표준으로인정받은표기시스템으로서그래디부치, 제임스럼

버, 이바 야콥슨이 공동으로 만들었다. UML은 시스템 분석가에게 의뢰인, 프로그래머, 그리

고시스템개발과정에참여한모든사람들이각자의시점에서이해할수있는다방면의설계

도를 그릴 수 있는 표준을 제공하며, 제안하는 그래픽 요소를 조합하여 다이어그램을 그릴

수 있도록 되어 있다.

UML 모델은 시스템이 무엇을 의도하고 있는지를 말해줄 뿐, 어떻게 동작하는지를 말해

주지는 않는다.


Q&AQ. UML을영어로쓸때 UML 이라고해야합니까? 아니면정관사를붙여서 the UML 이라고

해야 합니까?

A. 이 언어를 만든 분들이 the UML을 더 선호하는 것 같아요. 되도록 그렇게 하세요.

Q. 객체지향개념이이책에서매우중요한역할을한다고말씀하셨습니다. 그렇다면객체지향

을 이해하고사용하기 위해서 자바나 C++ 같은 언어의 개발자가 되어야 할까요?

A. 그렇진 않습니다. 객체지향의 개념은 단지 프로그래머에 국한되는 것이 아닙니다. 시스템

작동과 관련된 지식을 이해하고 모델을 만들기 원하는, 즉 시스템 분석가에게 있어서도 매

우 유용합니다.

Q. 필자분은 UML이시스템분석가에게없어서는안될도구라고강조하셨습니다. 하지만, 배포

다이어그램을보면시스템개발의분석단계에서유용할것같지는않습니다. 이다이어그램

은 나중 단계에 더적절하지 않나요?

A. 사실, 배포(deployment)라는 것에 대해 그렇게 생각해도 그리 성급한 것은 아닐 것입니다

(대개, 개발 과정에서 나중의 일로 다루어지니까요). 시스템 분석가가 의뢰인과 사용자에

대해 가장 많이 신경 쓰는 것이 사실이지만, 개발 과정 초기에는 반드시 시스템 하드웨어

를 구성할 컴퓨터와 구성요소에 대해 생각하고 있어야 합니다.

의뢰인이 이 부분에 대하여 어떻게 해달라고 부탁할 경우도 왕왕 있습니다. 개발팀이 추천

해 주길 원하는 의뢰인도 있지요. 이럴 경우 시스템 개발자(architect)는 배포 다이어그램이

매우 유용하다는 사실을 느끼게 될 것입니다.

Q. 다이어그램을복합적으로만들수있다고도하셨는데요. UML, 에구죄송합니다. the UML

은 다이어그램을 구성하는 요소에 대한제한을 두고 있습니까?

A. 천만에요. the UML은 어떠한 제한도 두고 있지 않습니다. 다만, 다이어그램이 한 종류의

요소를 포함하는 것은 경우에 따라서입니다. 배포 다이어그램에 클래스 아이콘을 넣을 수

있지만, 그렇게 해봐야 별 쓸모가 없지요.

Q. [그림1.3]에 옷을세탁한다"라는유스케이스다이어그램이나옵니다. 이유스케이스가말

하고자하는바는, 세탁기사용자는옷을세탁하기원한다이죠. 꼭이렇게말할필요가있

나요? 단지 간단하게 한문장으로 나타낼순 없나요?

A. 그렇게 말한다면 맞습니다. 단, 한 문장으로도 표현이 가능합니다. 하지만, 개발 프로젝트에

있어서 유스 케이스는 오리지날 스타트렉 시리즈 (에피소드 42)의 Tribbles 와 같습니다.

작게 시작하면 작은 정보만을 얻는 것이죠.


실습해 보기

독자 여러분은 UML의 거친 세상에 뛰어든 후 몇 페이지를 거침없이 지나왔다. 여기서는 몇

개의 퀴즈와 연습 문제를 통하여 여러분이 공부한 것을 다지는 기회를 가져 보도록 하겠다.

답은 부록 A 퀴즈 풀이 에 실어 두었다.

퀴즈1. 시스템 모델링에 있어서 다이어그램을 다양하게 그려야 하는 이유는 무엇인가?

2. 시스템의 정적인 뷰를 제공하는 다이어그램에는 무엇이 있을까?

3. 시스템의 동적인 뷰를 제공하는(즉, 시간에 따른 변경 상황을 보이는) 다이어그램에는

어떤 것이 있을까?

4. [그림 1.5]에 있는 객체들의 종류는 무엇인가?

연습 문제1. 사용자와 체스 게임을 두는 컴퓨터 기반의 시스템을 구축하고 있다고 가정하자. 이 시

스템에 적합한 UML 다이어그램은 무엇일까? 또, 그 이유는?

2. 방금 답한 시스템에 대하여, 미래의 사용자(의뢰인)에게 물어볼 질문을 떠올리고, 각각

의 이유를 생각해 보자.

3. [그림 1.7]의 통신 다이어그램을 살펴보자. [그림 1.5]의 시퀀스 다이어그램과 마찬가지

로 완전한 모습으로 완성해 보도록 하자. 어떤 문제가 발생할까?

4. [그림 1.5]에서 객체들의 행동들을 살펴보도록 하자. 각 객체가 한 클래스의 인스턴스

가 된다고 가정해 보고, 이 클래스들과 행동들을 포함하는 클래스 다이어그램을 그려

보도록 하자. 각각의 클래스에 추가할 만한 행동들을 생각해 볼 수 있을까?

5. 연습 문제 4의 클래스들을 세탁기의 복합연관 구조 다이어그램으로 구현해 보자. 또

한, 추가할 만한 컴포넌트 클래스에 대해서도 생각해 보도록 하자.


6. 상태 다이어그램 절에서 엘리베이터가 움직이거나 멈추거나 할 수 있다고 말한 적이

있다. 비록 아직 상태 다이어그램에 대해 잘 모르겠지만, 가능하다면 엘리베이터의 각

상태를 어떻게 표현할지 생각해 보자. 그리고 각 상태에 이름을 붙여 보도록 하자. 상

태 다이어그램을 그릴 때 어떤 정보들이 있을까? (힌트 : 엘리베이터 문을 생각해 보

자. 언제 열리고, 언제 닫히는지...)

7. [그림 1.5]의 시퀀스 다이어그램을 [그림 1.15]의 교류 개요 다이어그램으로 구성해 보

자. 한 객체에서 다른 객체로 전달되는 메시지에 초점을 맞추어 어느 메시지가 어느

위치에 와야 할지 잘 생각해 보도록 하자.

연습 문제 해답

책 앞부분에 있는 시작하면서 에서도 설명하였듯이, 이 책에 나오는 연습 문제에 대한 해답을 알려줄

수 없다는 것에 유념해 주기 바란다. 그런 종류의 일은 학생들을 가르치는 교수, 강사의 몫이며, 필자의

재량권 밖의 일이기 때문이다. 책의 필자(역자)라고 하더라도, 교수나 강사의 고유 권한을 침범할 수는

없다. 이 책은 도움이 필요한 학생들을 위해 퀴즈나 Q&A에 대한 상세한 해답과 자세한 설명을 포함하

고있다.

Documents

초보자를 위한 UML 객체지향 설계 제3판 - ipg.kripg.kr/ebook/pdf/5674-217.pdf · 시작하면서 25 PART 3에서는UML을디자인패턴과임베디드시스템(embedded