쿠킷 기술블로그

일반화와 상속의 차이

starUML을 사용하다보니 다음과 같은 의문이 들었다.

" 상속(Inheritance) 기호를 왜 일반화 기호로 표기했을까? "

Generalization이라 표기되어있는 상속기호

고민을 하다보니, 문득 예전에 객체지향프로그래밍 과목(C++) 시간에배운 is-a / has-a 관계가 생각났다.

따라서, 이번 글에서는 일반화와 상속의 차이에 대해 정리하고, is-a / has-a 관계에 대해 리뷰해보는 시간을 가져보자.

1. is-a

사람과 학생 클래스가 있다. 이들의 관계를 표현해보자

is-a 관계가 성립할 때 이를 상속으로 표현할 수 있다.

1) Person is a student. : 사람은 학생이다.  -> 논리적으로 옳지 않다. 모든 사람은 학생이 아니기 때문이다.

 2) Student is a person. : 학생은 사람이다.  -> 논리적으로 옳다. 모든 학생은 사람이라는 속성을 가진다.

따라서 is-a 관계에 의해 우리는 위의 다이어그램과 같이 person클래스를 상속받는 학생 클래스를 만들 수 있다. 

2 has-a

학생증이라는 클래스를 추가해보자. 이들의 관계를 표현해보자.

학생 has a 학생증.

is a 관계라 가정하면, 다음과 같이 표현할 수 있다.

1) Student is a student card. : 사람은 학생증이다. -> 논리적으로 옳지 않다

2) Student card is a student. : 학생증은 사람이다. -> 논리적으로 옳지 않다

매우 어색하다. 우리는 이를 표현하기 위해 has - a 관계라는 것을 정의함으로써 다음과 같이 올바르게 표현할 수 있다.  

 3) Student has a student card. : 

즉, 우리는 이와 같은 관계를 가질 때 이를 has-a 관계라고 부르며, 포함(Aggregation) 관계라 부르기도 한다. (일반적으로 필드가 객체를 포함하는 상황에서 has-a 관계를 가진다)

이때 한가지 더 첨언하자면, 학생 클래스 객체가 생성되면 학생 객체가 학생증 클래스의 생성자를 호출해 학생증 객체를 만든다. <-- 개념 다시 정리

이제 본격적으로, 일반화와 상속의 차이에 대해 이해해보자.

1. 일반화 (Generalization)

Bottom-up Process로 비슷한 클래스끼리의 공통 유사 속성을 묶은 것이다. 일반적으로 is-a 관계로 표현될 수 있으며,

Specialization Class is a Generalization Class. 로 나타내어진다.

( 구체화 클래스 is a 일반화 클래스 )

사진 출처 : http://www.universalteacherpublications.com/univ/free-asgn/2008/mcs32/page1.htm

위의 예시를 보면 shape 의 한 종류로 사각형, 원, 삼각형이 있는 것을 알 수 있다. 도형이라는 속성으로 일반화가 되었다고 볼 수있다. (반대로 구체화과정을 거치면 shape를 구체화하면 사각형, 원, 삼각형이 될 수 있다는 걸 알 수있다.)

2. 상속

(정의 보강 예정)

부모클래스로부터 자식클래스가 물려받을 때, 우리는 이를 상속이라고 부른다. 일반화관계일 때 보통 상속구조를 가질 수 있다.

예를 들어 학생이 사람을 상속받는다면, 사람의 속성을 학생이 다 가질 수 있기 때문이다.

따라서 관점의 차이에서 만들어낸 용어의 차이로,  일반화와 상속은 같은 뜻을 가진 용어라고 봐도 무방하다.

UML 클래스 다이어그램

UML은 Unified Modeling Language의 약어로,클래스들의 구조도를 표현한 다이어그램이라 볼 수있다. 

객체간의 관계를 표현함에 있어 최적의 표현 방법이다. 시스템 시각화나 사양 및 설계를 문서화할 때 주로 사용되며 소프트웨어공학 시간에 UML 클래스 다이어그램을 배우게 된다.  UML을 쉽게 그릴 수 있도록 지원하는 소프트웨어들이 있는데, 나의 경우 무료인 Star UML이나 마이크로소프트에서 나온 유료 소프트웨어인 Visio를 쓴다.

이번 글에서는 자바 클래스/인터페이스를 기준으로 어떻게 UML 다이어그램을 그리는지 알아보자.

클래스 또는 인터페이스를 표현하는 방법은 다음과 같다.

1. 세칸으로 나눈 네모박스를 그린다.

 UML 프로그램에서는 이를 클래스 선택시 간편하게 그려주고 자동으로 조절해준다.

2. 클래스 이름을 적는다. 인터페이스의 경우 <<interface>>라고 타입을 표기해주는 것이 좋다.

 ex)   <<interface>> 

        인터페이스 이름

  또한, 추상클래나 인터페이스의 경우 이탤릭체, 즉 약간 기울인 글꼴을 통해 추상이라는 속성을 가졌음을 표기해준다.

3. 필드값을 적는다. 

  스태틱의 경우, 필드값 아래 밑줄을 친다.

  만약 필드 값이 없다면 공란으로 비워둔다.

4. Method를 적는다.

  스태틱의 경우, 필드값 아래 밑줄을 친다. 

만약 메소드가 없다면 공란으로 비워둔다.

다음 예제를 살펴보자.

Ex) Executable 인터페이스를 UML 다이어그램으로 표현하기

interface Executable{

abstract void execute();

}

- 정답

- 그리는 순서

 1. 클래스 다이어그램을 그린다.

 2. 인터페이스 Executable임을 표기한다. 

 3. execute를 그린다.

와 같은 절차로 완성되었다.

이번엔 추상클래스를 그리는 예제를 살펴보자.

abstract class ParentClass {

int _field1;

static int FIEELD2;

abstract viod method1();

void method2(){

... 

}

static void method3(){

     ...

}

}

- 정답 : 

( method1은 추상메소드이므로 속성에서 isAbstract를 클릭해주면 된다)

- 그리는 순서

 1. 클래스다이어그램을 그린다.

 2. ParentClass는 추상클래스임을 표기해준다. 

 3. 필드값들을 입력하고, FIELD2는 static임을 표기한다.

 4. method들을 이력하고 method1은 static임을 표기하고, method3은 static임을 표기한다.

와 같은 절차로 완성되었다.

starUML을 통해 클래스 다이어그램을 그리는 것을 알아보았다.

다시 한번 정리하자면,

이탤릭체로 표기해야 하는 것은 추상클래스명/인터페이스명/추상메소드이며

밑줄은 static의 속성을 가질 때 그어주면 된다는 것이다.

다음 글에서는 클래스간의 관계 표기에 대해 알아보겠다.

예제 출처 : 자바로 배우는 리팩토링 입문