[펌] [안영회의 UML 강좌7] - 클래스 다이어그램

##########0*0 객체와 클래스

2 .0 객체의 특성과 표기법

3 .0 클래스와 그 표기법

4 .0 Rose에서 클래스 만들기

5 .0 클래스 뽑아내기

##########1*

##########2*
##########3*클래스 다이어그램을 배우기에 앞서 객체와 클래스에 대한 개념을 짚고 넘어가겠습니다. 제 경우는 C++과 자바 같은 객체지향 언어를 공부하고 UML을 접한 터라 이들 개념을 이해하는데 큰 무리가 없었습니다.

분석 및 설계를 공부하시는 분들 중에는 구현(프로그래밍)을 단순 작업 정도로 치부하는 분들이 있습니다. 그러나, 구현이 없는 설계는 공허한 것입니다. 같은 맥락에서 어떻게 구현되는지 모르면서 이상적인 설계만을 고집한다면 많은 문제를 낳을 것입니다.

적어도 배우는 과정에서는 개발과정 전체를 아우르는 이해가 어느 정도는 필요하다 점입니다. UML을 공부하시는 분들께서도 틈틈이 객체지향언어에 대한 이해도 갖추어야 할 것입니다. 향후 강좌 진행에 있어서 간간이 자바를 통해 여러분들을 조금이나마 도울 수 있도록 노력하겠습니다.

##########4*
그림 7-1. 붕어빵과 붕어빵 틀

그림 7-1은 붕어빵과 붕어빵을 만드는 틀의 그림입니다. 객체를 설명할 때 가장 흔하게 쓰는 비유입니다. 붕어빵이라는 객체를 만들기 위해서는 붕어빵을 찍어 낼 틀(Template)이 필요합니다. 이것이 클래스라고 할 수 있죠.

비록 초보적인 수준에서 사용되는 비유이긴 하지만 나름대로 꼼꼼히 바라보면 많은 것을 얻을 수 있습니다. 같이 한번 살펴보죠. 100개의 붕어빵을 만들기 위해서 100개의 붕어빵 틀이 필요한 것은 아니죠? 단 하나의 붕어빵 틀로도 수없이 많은 붕어빵을 만들어 낼 수 있습니다. 마찬가지로 하나의 클래스로 수많은 객체를 만들어낼 수 있는 것이죠.

그러나 하나의 붕어빵 틀로는 한가지 모양의 붕어빵밖에는 얻을 수 없습니다. 만일 다른 모양의 붕어빵을 얻고자 한다면 모양이 다른 붕어빵 틀이 필요하겠죠. 붕어빵을 만드는 사람 입장에서 붕어빵 틀을 또 만들거나 구입하는 것은 돈이 드는 일입니다. 그렇지만, 새로운 형태의 붕어빵을 만든다면 히트를 쳐서 더 많은 수입을 올릴 수도 있는 일이죠.

마찬가지로 객체들을 만들어내기 위한 클래스를 어떻게 정의하느냐는 명확한 정답이 없는 문제입니다. 경험과 직관을 요하는 일이죠.

붕어빵과 붕어빵 틀의 관계를 잘 이해하셨다면 어느 정도는 객체와 클래스의 관계를 이해하실 수 있었을 것입니다. 다음과 같은 수식으로도 양자의 관계를 설명할 수도 있습니다.

객체:클래스 = 인스턴스:템플릿

인스턴스(Instance)라는 말은 하나의 예가 될 수 있는 일, 상황이나 사람을 의미합니다. 템플릿(Template)은 지침이 되는 틀을 칭하는 것입니다. 따라서, 템플릿(클래스)는 인스턴스(객체)의 공통점을 뽑아낸 것이죠. 같은 붕어빵 틀로 찍어낸 붕어빵들도 모양이나 맛이 조금씩 틀린 것처럼 하나의 템플릿에 의해 만들어진 인스턴스라 할지라도 고유한 면을 갖게 됩니다.

 

1 .0 객체와 클래스

##########5*0 객체의 특성과 표기법

3 .0 클래스와 그 표기법

4 .0 Rose에서 클래스 만들기

5 .0 클래스 뽑아내기

##########6*

##########7*
앞에서 다소 장황하게 설명했지만, 객체(Object)는 눈에 보이는 것이든 개념적인 것이든 어떠한 개체(Entity)들을 표현한 것입니다. 붕어빵들도 객체이지만, 내 컴퓨터도 객체이고, 여러분의 예금계좌도 객체입니다.

객체는 일반적으로 세 가지 특징을 갖고 있습니다. 상태, 행위와 아이덴터티입니다.

• 상태(State)는 객체가 존재하는 상태에 대한 정보를 말하는 것입니다. 상태는 속성(attribute 혹은 property)값으로 표현합니다.
  
• 행위(Behavior)는 객체가 다른 객체의 요청에 대해서 어떠한 반응을 보이는지, 무엇을 할 수 있는지를 정의한 것입니다. 행위는 객체의 오퍼레이션(Operation)들로 구현됩니다.
  
• 아이덴터티(Identity)는 각각의 객체들은 고유하다는 것을 의미합니다. 겉으로 보아서 붕어빵이 동일하게 보여도 이 둘은 서로 다른 붕어빵이죠. 마찬가지로 상태와 행위가 동일하다고 해도 두 객체는 고유한 아이덴터티를 지닙니다. 구현 단계에서는 이를 위해 키(Key) 등으로 불리는 속성을 두어 아이덴터티를 나타냅니다. (아이덴터티를 고유성, 유일성 등으로 번역하면 오해의 소지가 있을 것 같아 앞으로도 용어의 번역이 모호한 경우에는 가능한 원어의 한글발음을 사용하는 것을 원칙으로 하겠습니다.)

객체에 대한 UML 표기법은 이름에 밑줄을 그은 직사각형입니다. 만일 코리아인터넷닷컴의 UML 포럼을 객체로 표현할 경우 다음과 같이 표기할 수 있습니다.

UML 포럼

그림 7-2. 객체에 대한 UML 표기법

 

1 .0 객체와 클래스

2 .0 객체의 특성과 표기법

##########8*0 클래스와 그 표기법

4 .0 Rose에서 클래스 만들기

5 .0 클래스 뽑아내기

##########9*

##########10*
앞에 설명한 것과 같이 클래스는 객체의 공통점을 뽑아낸 것입니다. 보다 명확하게 말하자면 객체의 공통적인 속성과 행위를 기술해 놓은 것입니다. 일반적으로 하나의 클래스에 속하는 모든 객체는 동일한 속성과 행위를 갖고 있습니다. 그러나, 각각은 고유한 속성값들을 갖게 됩니다. 고유하다는 말은 다른 것을 의미하지는 않습니다. 실제 구현단계에서는 메모리 영역이 다른 것을 의미하게 되는 것이죠.

클래스의 UML 표기법은 구획면으로 나눠진 직사각형을 사용합니다. 상단에는 클래스 이름이 나오고, 가운데는 상태를 나타내는 속성들이, 마지막 하단에는 행위를 표현하는 오퍼레이션들이 기술됩니다.

코리아인터넷닷컴에는 ‘UML 포럼’ 이외에도 ‘HTML 포럼’, ‘디자인 포럼’, ‘비즈니스 포럼’ 등 많은 수의 포럼이 존재합니다. 이들 각각의 포럼을 객체라고 하면 ‘포럼’이라는 클래스를 정의할 수 있을 것입니다. 클래스 이름은 ‘포럼’이라고 할 수 있죠? 속성들은 포럼 이름, URL, 작성자 등을 생각해 볼 수 있고, 오퍼레이션으로는 글을 추가하는 것과 삭제하는 것들을 생각해 볼 수 있습니다. 오퍼레이션은 궁극적으로 메소드로 구현되기 때문에 작명에 있어서도 일반적인 메소드 작명법(Naming Convention)을 따르는 것이 좋습니다. ‘글을 추가하기’와 ‘글을 삭제하기’를 각각 addArticle(), deleteArticle()이라고 이름 지어보죠.

자 그럼, 앞에서 만든 포럼 클래스를 UML을 이용하여 표기해 봅시다.

포럼

포럼이름 URL 작성자

addArticle() deleteArticle()

그림 7-3. 클래스의 UML 표기법

 

1 .0 객체와 클래스

2 .0 객체의 특성과 표기법

3 .0 클래스와 그 표기법

##########11*0 Rose에서 클래스 만들기

5 .0 클래스 뽑아내기

##########12*

##########13*

##########14*
그림 7-4. 클래스 만들기

그림 7-4 와 같이 브라우저의 Logical View를 선택하고 오른쪽 마우스를 클릭하여 팝업 메뉴를 나타나게 한다. [New]-[Class] 순으로 선택하면 클래스가 만들어지면서 NewClass라는 이름이 반전상태가 되는데 이때 클래스 이름을 입력한다.

1 .0 객체와 클래스

2 .0 객체의 특성과 표기법

3 .0 클래스와 그 표기법

4 .0 Rose에서 클래스 만들기

##########15*0 클래스 뽑아내기

##########16*

##########17*
클래스를 뽑아내는 것은 그야말로 ‘Art’의 영역이라고 할 만큼 어려운 일이다. 정답도 없고, 공식도 없는 문제를 푸는 일이다. RUP에서는 엔터티 클래스(Entity Classes), 바운더리 클래스(Boundary Classes)와 컨트롤 클래스(Control Classes)를 찾아내는 방법을 제시하고 있다. 이것은 MVC(Model-View-Controller) 패턴의 관점에 따른 것으로 완전한 해결책은 아니지만 실제로 클래스를 찾아내는 작업을 상당히 수월하게 해준다. 이들 주요 클래스에 대해 알아보자.

• 엔터티 클래스(Entity Classes): 실세계의 개체(Entity)를 반영하는 것으로서 시스템 내부의 일을 수행한다. 대체로 긴 수명을 지니는 정보나 행위를 정의한다. 시스템이 속한 업무 영역에 관계된 클래스가 일반적이어서 도메인 클래스(Domain Classes)라고 불리기도 한다. 대개 시스템의 ‘무엇을 해야 하는지’를 명확히 하는 과정에서 발견된다. 가령, 수강신청 시스템은 학생의 강좌 정보를 유지해야 하기 때문에 ‘학생’, ‘강좌’ 등의 엔터티 클래스를 찾아낼 수 있다.
  
• 바운더리 클래스(Boundary Classes): 시스템과 환경과의 의사소통 인터페이스 역할을 하는 클래스이다. 유즈케이스 다이어그램을 그리고 나면 액터별 시나리오가 나타나기 마련이다. 이때 액터와 시스템이 접하는 부분에서 각 액터에 맞는 바운더리 클래스를 정의할 수 있다. 가령, 학생은 일정한 폼(화면)을 통해서 수강신청 시스템과 상호작용 할 수 있는데 이러한 폼이 바운더리 클래스이다.
  
• 컨트롤 클래스(Control Classes): 시스템에서 발생되는 일의 흐름을 제어하는 역할을 하는 클래스이다. 일(Event)의 순서를 결정하고 조정하게 된다. 일반적으로 액터별 시나리오마다 흐름을 제어하기 위한 컨트롤 클래스를 추가된다.