[펌] [안영회의 UML 강좌13] - Behavior and Structure(1)-1

##########0*

##########1*0 Behavior and Structure

2 .0 Behavior and Structure의 표현

3 .0 Class Refinement

##########2*

##########3*
지난 강좌에서는 iterative development에 대해 이야기 해 보았습니다. 이번에는 객체의 Behavior와 Structure를 찾아서 클래스의 속성과 operations를 뽑아 보도록 하죠. 이전까지 모델링 한 클래스가 뼈대라고 하면 거기에 살을 붙이는 것이라고 할 수 있습니다.

Behavior and Structure

클래스는 책임을 내포하고 있습니다. 시스템 개발 과정에서 대개 요구사항을 담고 있는 유즈케이스의 기능을 시스템을 구성하는 클래스에 나누어줘야 한다는 것이죠. 가령, 시스템을 전통적인 가정에 빗대어 본다면 ‘아버지’라는 클래스는 ‘가장의 역할’이라는 이름으로 뭉뚱그려진 어떤 책임들을 갖고 있죠. 중요한 결정을 한다던가 돈을 벌어 온다던가 하는 식이죠.

그리고, ‘어머니’라는 클래스는 ‘주부의 역할’이라는 이름으로, 아이들을 교육을 책임지거나 살림을 도맡게 되죠. 물론, 고리타분한 사고방식에서 나온 모습이니까 예제의 내용으로 너무 분개하지 마시고…^^;

클래스가 그런 책임을 내포하게 되고, 클래스가 실체와 되어서 객체가 되고, 이들 객체가 클래스에서 정의한 책임들을 잘 수행하게 된다면 시스템이 잘 돌아가겠죠. 우리나라의 가정(시스템)이 잘 돌아가려면 가족 구성원(객체)들이 각자 자기가 맡은 역할(클래스의 책임)을 다 해야 하는 것과 같은 이치죠. ‘수신제가 치국평천하’

한번에 필요한 모든 클래스를 찾아내고, 이들의 Behavior와 Structure를 다 추가 시킨다는 것은 힘든 일입니다. 자신이 뻔히 아는 일이라면 몰라도 모르는 분야에 대해서 시스템을 개발할 때는 더욱 그렇겠죠. 그래서 지난 강좌에 말씀 드린 것과 같이 반복적으로 이러한 작업을 해나갑니다.

클래스의 책임을 결국 operation들로 수행되게 되죠. 따라서, 클래스의 책임은 각각의 operation에 나눠지게 됩니다. 예를 들어, 강좌를 표현하는 CourseOffering 클래스를 생각해볼까요? CourseOffering은 기본적으로 학생을 추가하거나 제거해야 하는 책임을 갖고 있습니다. 이러한 책임은 궁극적으로 addStudent와 removeStudent와 같은 operation들로 수행이 되는 것이죠.

##########4*
그림 13-1. 클래스의 attributes와 operations

객체의 구조(structure)는 속성(attributes)로 표현됩니다. 각각의 속성들은 또한 클래스의 멤버 데이터로 정의가 되지요. 클래스가 객체로 인스턴스가 만들어지면 각각의 속성들은 고유한 값을 같게 됩니다. 여기서 고유하다는 것은 객체마다 하나의 값을 갖게 된다는 의미입니다. 동일한 클래스에 속한 객체들의 동일한 속성에 대한 값이 전부 달라야 한다는 말은 아닙니다. ^^;

 

1 .0 Behavior and Structure

##########5*0 Behavior and Structure의 표현

3 .0 Class Refinement

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

##########7*
Behavior and Structure의 표현

UML에서 Behavior and Structure의 이름은 기호나 코드가 아닌 자연어(일상적인 언어)를 사용하게 됩니다. 따라서, 모델링을 수행하는 사람마다 천차만별의 이름을 붙일 수 있습니다. 요즘처럼 개성이 강한 시대에는 정말 황당한 이름도 볼 수 있을 것 같네요.^^;

그러나, 대부분의 프로젝트 혹은 시스템 개발은 공동작업이기 때문에 이름을 정하는 일정한 규칙이 필요하게 됩니다. 스타일 가이드(style guide)라고도 하고, 더러는 네이밍 컨벤션(Naming Convention)이라는 말을 사용하기도 합니다.

특별하게 UML 자체에서 규정하는 규칙이 있다고 하기 보다는 특정 집단에서 정하게 되는 것이죠. 그러나 대부분 객체지향 언어에서 지켜져 왔던 네이밍 컨벤션을 따르는 것이 좋겠죠. 다들 아시겠지만 혹시 모르시는 분들을 위해 아래 정리를 좀 해놓죠.

• 클래스 이름은 대문자로 시작한다.
  
• 속성(attribute)이나 operation의 이름은 소문자로 시작한다.
  
• 단어가 이어질 때는 뒤 따라오는 단어의 첫번째 알파벳을 대문자로 한다.
  
• 클래스와 속성은 명사 표현을 사용한다.
  
• Operation은 동사 표현을 사용한다.

이렇게 스타일 가이드를 만들어 두고 이를 따르게 되면 어떤 장점이 있을까요? 다음의 세 가지 장점을 열거해 볼 수 있습니다.

• 모델과 코드의 일관성(consistency)을 유지할 수 있다.
  
• 모델과 코드의 가독성(readability)을 높인다.
  
• 모델과 코드의 유지보수가 용이(maintainability)하다.

이런 장점들이 궁극적으로는 프로젝트 혹은 개발과정의 생산성(productivity)을 높여 줍니다. 시간과 비용을 줄일 수 있다는 것이죠. 개발 경험이 있으신 분들은 쉽게 알 수 있으시리라 생각이 드네요. 제가 아는 분이 프로젝트 경력이 8년이라는데 표준화가 제일 중요하더란 말을 하시더군요.

요즘 자바 관련 사이트에 보면 개발 프레임워크에 대한 이야기들이 심심치 않게 오르고 있더군요. RUP도 하나의 개발 프레임워크라고 볼 수 있죠. 요즘 미국에서 선풍적인 인기를 구가한다는 XP도 그렇구요. 얼마 전에 ‘자바 메가트렌드’에 갔었는데 L사의 선임연구원이라는 분이 자사의 방법론 구체화 과정에 대해 설명하는 세션을 들었습니다.

##########8*
그림 13-2. XP 관련 서적

개발 경험이 별로 없던 저였지만 모델 주도의 개발을 해보려다가 쓰디쓴 경험을 해서 그런지 뼈에 사무치는 경험담을 해주시더군요. L사는 모델 주도로 개발을 해보다가 자사에 맞지 않는다는 것을 깨닫고는 XP를 도입해 자사에 맞게 정제해 나가고 있었습니다.

종종 개발 방법론이나 프로세스에 대해 질문을 하시는 분들이 계셔서 이참에 좀 더 얘기를 드리면 RUP에 대한 환상부터 버리시길 바랍니다. RUP는 거대한 프로젝트에 적합한 방법론이고, 웹에서 쉽게 가르쳐 줄 수 있는 부분이 아닌 것 같습니다. 학부 때도 소프트웨어공학을 배우고, 현재도 또 소프트웨어공학을 객체지향 관점에서 다시 공부하고 있는 제 입장에서 느껴지는 것은 좋은 이론은 배우되 반드시 소화를 해야 하겠다는 생각이 들더군요.

RUP나 XP가 좋은 모델이 될 수는 있지만 이를 그대로 활용하려면 일단 사고방식부터 미국인들처럼 바꿔야 하겠죠? 이론을 답습은 하되 “자기화”하는 과정 혹은 “창조적인 재해석”이 필요하다 하겠습니다.

##########9*
그림 13-3. RUP Builder 화면

 

 

1 .0 Behavior and Structure

2 .0 Behavior and Structure의 표현

##########10*0 Class Refinement

##########11*

##########12*
Class Refinement

객체의 Behavior and Structure를 뽑아내고 이를 통해 적절하게 클래스를 정의하다 보면 이전의 뽑아낸 클래스가 문제가 있음을 발견하기도 합니다. 하나의 클래스로 정의해야 할 것을 특정 클래스의 속성들로 섞어 두기도 하고, 반대로 속성에 지나지 않을 것을 클래스로 뽑아놓은 것들도 있죠.

이런 문제점들은 클래스를 찾는 과정에서 보다 객체의 Behavior and Structure를 뽑아내는 과정에서 더 잘 드러나기 마련입니다. 이러한 점이 지난 강좌에 언급한 반복적인 개발의 장점이라고 할 수 있습니다. 속성과 operations이 없이 개념적인 수준에서만 찾아낸 클래스(Conceptual Class)들에 살을 붙여 나가는 과정에서 이들이 더욱 더 정제되는 것이죠.

이러한 정제 과정 역시 한번으로 끝나는 것이 아니라, 계속적으로 반복되면서 진화하게 되는 것이죠. 이런 이유로 개발 과정에서 나타나는 클래스들은 ‘Candidate Class’나 ‘Class Draft’라고 부르기도 합니다.