[펌] [안영회의 UML 강좌17] - Inheritance-1

##########0*0 상속(Inheritance)

2 .0 일반화(Generalization)와 전문화(Specialization)

3 .0 상속도(Inheritance Tree)

4 .0 상속(Inheritance)과 집합(Aggregation)

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

##########2*
이번 시간에는 상속(Inheritance)에 대해 알아보도록 하겠습니다. 객체 지향 모델링에서 상속은 클래스 사이에서 갖는 관계의 일종이죠. 지난 시간까지 클래스들의 주요 속성과 행위를 찾아낸 것이 개별 클래스 수준에서 묘사가 되었다면 상속은 이들을 다시 클래스 단위로 정리하는 것이라고 이해할 수 있습니다.


상속(Inheritance)

상속은 하나 이상의 클래스 사이에서 구조나 행위를 공유하는 관계를 말합니다. “is-a” 관계 혹은 “is-a-kind-of” 관계라고도 하죠. 객체지향 기술에서 기본적인 재사용 메커니즘 중에 하나입니다. 하위 클래스가 상위 클래스를 상속 받으면서 그 속성이나 오퍼레이션들을 모두 이어 받는 것이죠.

객체지향 언어를 잘 모르신다면 사실 상속을 제대로 이해하기도 어렵다는 생각이 드네요. 최근 CBD(Component-Based Development)라고 하는 컴포넌트를 기반으로 하는 재사용 바람이 거세게 불고 있습니다. 객체지향이라는 주류를 놓아 두고도 이러한 기술이 트렌드를 이루는 데는 다 그 나름의 이유가 있겠죠.

상속을 통한 재사용은 이론에서처럼 제대로 적용되지는 못했습니다. 그렇다고 근본적으로 상속을 대체하는 것이 컴포넌트라고 보기는 힘들 것 같습니다. 그저 좀더 좋은 해결책을 찾기 위한 노력이라고 보는 것이 옳겠죠. 아무튼 상속이 좋은 아이디어임에는 틀림없습니다. 상속의 UML 표기법은 그림 17-1과 같습니다.


##########3*
그림 17-1. 상속의 UML 표기법


UML에서 상속은 특수한 형태의 관계(Relationship)로 분류할 수 있습니다. 일반적인 관계와는 달리 관계의 이름을 붙이지 않고, 역할 이름이나 다중도(multiplicity)를 적용하지 않습니다. 이러한 속성들은 이미 ‘상속’이라는 의미 속에 녹아 들어가 있기 때문입니다.

상속 관계를 갖는 두 클래스의 관계를 많은 경우 부모와 자식 사이로 비유하는 표현을 사용합니다. 이에 따라 상위 클래스(super class)를 부모 클래스(parent class), 하위 클래스(subclass)를 자식 클래스(child class)라고도 하죠.

1 .0 상속(Inheritance)

##########4*0 일반화(Generalization)와 전문화(Specialization)

3 .0 상속도(Inheritance Tree)

4 .0 상속(Inheritance)과 집합(Aggregation)

##########5*

##########6*
일반화(Generalization)와 전문화(Specialization)

복잡한 시스템을 분석하고 설계할 때 상속 관계를 알아내는 일은 쉽지 않습니다. 특히 익숙하지 않은 분야의 일이라면 더욱 그러하겠죠. 상속 관계를 끌어내는 방법 중에 하나로 일반화(generalization)가 있습니다.

다수의 클래스 사이의 공통점을 발견하는 방법입니다. 공통점이 발견된 클래스들 사이에서 공통점은 상위 클래스로 정의하고, 이를 제외한 각각의 차이점만 모아서 개별적인 클래스들을 정의할 수가 있겠죠.

월드컵이 다가옴에 따라 우리나라 대표팀의 베스트11에 대한 관심과 예상들이 많습니다. 그러나, ‘상황에 따라 다른’ 전략을 보여줄 것이라는 것이 아직은 중론인 것 같습니다. 상황에 따라 다르다. 참 묘한 말입니다.

축구에서 정해진 포지션이라면 심판뿐이라고도 말할 수 있을 것입니다. 공격 성향의 축구를 하다 보니 종종 골키퍼가 최후방 수비수의 역할도 하니까요. 마찬가지로 모델링에서도 딱히 정답이 있는 경우는 극히 일부에 지나지 않습니다.

예를 들어, Student 클래스와 Professor 클래스가 있다고 해봅시다. 이들 사이에 공통점이 존재할까요? 절대적인 정답은 존재하지 않습니다. 상황에 따라, 구현할 시스템이 어떠한 영역(Domain)에서 사용되느냐에 따라서 모델은 달라질 것입니다.

도움이 될만한 기법이 있다면 ‘언어의 모호성’에 각별히 주의를 하셔야 한다는 점입니다. 가령, 의미는 같은데 다른 단어를 사용한 경우나 의미가 다른데 같은 단어를 사용하는 경우가 있습니다. 특히 팀으로 작업을 하는 경우 발생하기 쉬운 일이죠. 이런 경우 프로젝트 용어집 혹은 프로젝트 사전 등을 이용하여 쓰이는 말을 표준화할 필요가 있습니다.

일반화와 반대로 모호한 클래스를 명확하게 하기 위해 하위 클래스를 생성하는 경우가 있습니다. 이를 전문화(specialization)이라고 합니다. 일반화와 전문화 중에 어떤 방법이 더 좋다고 할 수는 없습니다. 자신에게 알맞은 방법을 적절히 쓰면서 상속 관계를 철저히 분석하는 것이 목표일 뿐이죠.

1 .0 상속(Inheritance)

2 .0 일반화(Generalization)와 전문화(Specialization)

##########7*0 상속도(Inheritance Tree)

4 .0 상속(Inheritance)과 집합(Aggregation)

##########8*

##########9*
상속도(Inheritance Tree)

##########10*
그림 17-2. 상속 관계 표현하기


그림 17-2처럼 클래스 다이어그램을 이용하여 상속 관계를 표현할 수 있습니다. 상속 관계를 표현하기 위한 새로운 다이어그램을 나타낼 수도 있고, 기존의 다이어그램에 상속 관계를 명시할 수도 있겠죠. 다이어그램 작성에 원칙은 없습니다. 다이어그램을 그리는 목적이 바로 우리가 구현하고자 하는 시스템을 설명해주는 모델을 바로 이해하기 위한 것이기 때문에 사람이 이해하는데 적합한 형태로 작성하면 좋은 다이어그램이라 할 수 있는 것이죠.

상속도를 표현하는 방법은 도구상자에서 Generalization 아이콘을 선택한 상태에서 하위 클래스에서 상위 클래스로 드래그 합니다. 화살표 방향이 혼돈을 가져오기 쉬운데 영문 어순을 생각하시면 쉽습니다. UML도 영어 문화권에서 개발된 언어니까요. 예를 들어 위의 그림에서, “Professor는 RegistrationUser(등록된 사용자)를 상속한다”와 같이 읽을 수 있겠죠.

상속관계를 표현할 때 만일 두 개의 하위 클래스와 모두 관계를 맺고 있는 클래스는 어떻게 표현해야 할까요?


##########11*
그림 17-3. 상속 관계도


그림 17-3을 보면 CourseOffering 클래스가 각각의 하위 클래스와 개별적으로 관계를 표현하고 있습니다. 이렇게 하지 않고, CourseOffering 클래스와 RegistrationUser 사이의 관계로 표시할 수도 있겠죠?

그렇습니다. 상황에 따라서 둘 중 하나가 효과적일 때가 있는 것이죠. 가령, 해당 클래스가 각각의 하위 클래스와의 관계가 같은 경우는 상위 클래스와의 관계로 표현하는 것이 더욱 이해하기에 좋을 것입니다. 그러나, 위의 경우처럼 다중도(multiplicity)가 다르거나, 관계가 틀린 경우에는 이들을 따로 표현하는 것이 더 효과적일 수도 있습니다.

1 .0 상속(Inheritance)

2 .0 일반화(Generalization)와 전문화(Specialization)

3 .0 상속도(Inheritance Tree)

##########12*0 상속(Inheritance)과 집합(Aggregation)

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

##########14*
상속(Inheritance)과 집합(Aggregation)

위임(Delegation)이라는 디자인 패턴이 있습니다. 특정한 경우에 상속을 대체하기 위한 개념입니다. 클래스간의 상속 관계가 문제가 되는 경우가 있습니다. 상속은 기본적으로 정적인 바인딩(Static Binding)을 합니다. 프로그램 실행 이전에 이미 클래스의 타입이 결정되는 것이죠. 따라서, 실행 중에 타입을 변환하는 일은 무척 어렵습니다.(상속 관계에 따라 위, 아래로 변하는 경우는 예외죠) 위임은 집합 관계로 표현이 됩니다.

수강신청 예제에서 다음과 같은 경우를 생각해보죠. 해당 학교의 교수진은 전임교수와 시간 강사가 있다고 합시다. 그런데 시간 강사던 사람을 학교측에서 전임교수로 임명했다고 합시다. 그러면 클래스를 바꿔줘야 하는데 이를 어떻게 할까요? 시스템이 지원하지 않으니까 시스템 상에는 시간 강사로 놓아둘까요? 아니면 시스템을 수정할까요? 좋습니다. 시스템을 수정해야 겠죠. 그런데 그 사람이 개인 사정으로 다시 시간 강사직을 맡겠다고 합니다. 이번에는 어떻게 할까요?

그렇습니다. 상속은 정적인 바인딩을 하는 탓에 유연성이 떨어집니다. 이런 경우에 시간 강사인지 전임교수인지를 구분해주는 역할(Role)을 다른 클래스에 위임(Delegation)해서 문제를 해결할 수 있습니다. 이렇게 하면 실행 중에 해당 강사의 역할에 따라 동적으로 바인딩이 가능하게 되는 것이죠. 이를 표현한 다이어그램이 그림 17-4입니다.

##########15*
그림 17-4. 상속과 집합