Advanced C# 2. 인터페이스

Advanced C# 2. 인터페이스
등록: 한빛미디어(주) (2003-02-04 22:35:56)
저자: 한동훈(traxacun at unitel.co.kr) UML에서 추상 클래스는 이탤릭체로 표기한다. 다음은 추상클래스와 이를 상속한 구상 클래스를 나타낸 클래스 다이어그램이다. [그림 1] 인터페이스 Abstract 클래스를 보면 메소드도 이탤릭체로 표기된 것을 볼 수 있다. 또한 여기서 메소드는 추상 메소드를 뜻한다. 클래스에 어떠한 구현도 없는 추상 클래스는 인터페이스의 역할을 하기 때문에 일반화(Generalization)를 뜻하는 선 대신 실현(Realization)을 뜻하는 선을 그어준다. 따라서 위 그림은 인터페이스를 표현한 것이다. [그림 2] 실현(Realization) Abstract 클래스가 인터페이스라는 것을 명확하게 하기 위해 스테레오 타입 '<<interface>>'를 사용하기도 한다. 다음은 스테레오 타입을 사용한 다이어그램이다. [그림 3] <<interface>> 스테레오 타입 모델링 도구를 사용하여 코드를 자동으로 생성하는 경우에 스테레오 타입을 이용한 다이어그램은 추상 클래스(abstract class) 또는 인터페이스(interface) 두 가지로 정의될 수 있다. 이것은 생성하는 코드의 종류가 C++이거나 C#, Java와 같은 언어인가에 따라 다르다. UML에서 인터페이스를 나타내기 위해 다음과 같은 도형을 사용할 수 있다. [그림 4] 인터페이스 IChat 인터페이스를 정의하고 Concrete1 클래스에서 인터페이스를 구현하는 클래스 다이어그램은 다음과 같다. [그림 5] IChat 인터페이스 위 다이어그램을 구현한 소스 코드는 다음과 같다. [그림 6] Abstract 클래스 [그림 7] Concrete1 클래스 집합(Aggregation) 연관 [그림 8] 집합 연관 집합 연관은 전체(whole) 클래스와 그 구성품(part)의 관계를 나타내기 위해 사용한다. 컴퓨터를 나타내는 Computer 클래스가 있다면 이 Computer는 각 구성품을 나타내는 다양한 클래스들로 구성되어 있다. VGA, RAM, HDD, FDD, MotherBoard 등이 이러한 구성품을 나타내는 클래스로 표현될 것이다. 이와 같이 각 클래스간의 관계가 "is kind of" 관계를 만족하는 것은 아니지만 있어야만 하는 관계는 모두 집합 연관으로 나타낼 수 있다. [그림 9] 집합 연관 다이어그램 위 다이어그램에서 VGA와 Disk에 표시되어 있는 '1'과 '*'의 의미는 관계를 나타낸다. Computer 클래스와 VGA 클래스는 일대일 관계라는 것을 나타내며 Disk 클래스와는 일대다 관계를 나타낸다.(사실, 컴퓨터에는 1개 이상의 VGA를 장착할 수 있지만 여기서는 예를 나타낸 것이다) 관계를 나타내는 방법은 경우에 따라서 0..4와 같이 0에서 4까지라는 의미로 나타낼 수도 있으며 0..*, 1..*, *..* 과 같이 경우에 따라 표현할 수 있다. 탁자(Table)과 다리(Leg)의 관계는 하나의 탁자에 반드시 4개의 다리가 있으므로 1.4와 같이 표현될 것이며 구성품(Leg)이 전체(Table)에 보다 종속적인 관계를 나타내기 때문에 집합 연관 보다 강한 복합 연관으로 표현될 것이다. 위 클래스의 소스 코드는 다음과 같다. Computer 클래스 Disk, HardDisk, FloppyDisk 클래스 VGA 클래스 복합(Composite) 연관 복합 연관은 집합 연관과 비슷하지만 하나의 전체(Whole) 클래스에만 속할 수 있는 관계를 나타내기 위해 사용하며 선의 끝에 채워진 마름모를 사용하여 표기한다. [그림 10] 복합 연관 Conceptual Subclass(개념 모델) Conceptual Subclass는 "상위 클래스의 정의가 그대로 하위 클래스에 적용되어야 한다(100% Rule)"와 "하위 클래스는 상위 클래스의 한 종류이어야 한다(is kind of Rule)"을 만족하는 경우에 Conceptual Subclass라 한다. 이러한 Subclass를 모델링 과정에서 필요에 따라 다시 하위 클래스로 분류하게 되는 경우가 있는데 이를 분할(Partition)이라 한다. 하위 클래스에서 필요로 하는 특별한 속성이나 오퍼레이션이 있는 경우에 하위 클래스로 분할하게 된다. 전자결재 시스템에서 지불방법(Payment)을 모델링한 경우에 신용카드 결재인가에 따라서 추가적인 속성이나 오퍼레이션을 갖게되기 때문에 이러한 경우에는 신용카드 결재(CreditPayment)와 현금 결재(CashPayment)와 같이 분할하게 된다. 반대로 분할이 무의미한 경우에는 이들을 다시 하나로 결합하기도 한다. 예를 들어 남성 고객(Male Customer)와 여성 고객(Female Customer)을 모델링한 경우에 두 클래스간에 차이점이나 특별한 속성, 오퍼레이션을 갖지 않는 경우 이들을 다시 하나로 합치는 것이 바람직하다. 여러 클래스들에서 비슷한 작업을 하는 공통적인 요소(속성이나 오퍼레이션)들을 발견할 수 있는 경우에는 이들을 상위 클래스로 일반화(Generalization)하는 것이 바람직하다. 주석(Notation) UML에 있는 다이어그램으로 모든 것을 설명할 수는 없기 때문에 스테레오 타입과 함께 주석을 사용할 수 있다. 주석은 다음과 같이 표현된다. [그림 11] 주석관 마치며 UML에서 자주 쓰이는 클래스 다이어그램에 대해서 간략하게 설명하였다. UML에 대해서 그리 많은 지식을 갖고 있지 않기 때문에 매우 빈약한 설명이 되었다. UML에 대해서 관심이 있다면 UML과 함께 방법론에 대해서 학습할 것을 권한다. Conceptual Subclass에 대한 이야기는 실현(Realization)에서 설명했어야 하지만 미처 하지 못했기 때문에 여기서 간략하게 소개하였다. 참고 도서에는 가장 잘 알려진 3권의 도서를 넣었다. UML에 대해서 잘 모른다면 『The Unified Modeling Language Users Guide』로 시작하는 것이 가장 좋으며 그 다음으로 『UML Distilled』를 읽어보고, 프로젝트에서 전체적인 흐름을 알아보고자 하는 분들에게는 『Applying UML and Patterns』를 참고하기 바란다. 불행히도 이 책만 국내에 번역서가 없다. 그외에 『UML In a Nutshell』 (오라일리)와 『The Instant UML』 (Wrox)는 가장 많은 개발자들이 서가에 꽂아놓고 참고하는 책이다. 개인적으로 비교적 작은 크기이면서 찾아보기 편한 『UML In a Nutshell』을 좋아한다. 책상앞에 두고 참고하고 싶은 레퍼런스를 원한다면 이 두 권 중에 하나를 고려해보기 바란다. (이 글이 한빛사이트에 등록되는 것과 나의 추천은 전혀 별개의 문제이며 인터넷을 통해 여러분은 쉽게 진실을 가려낼 수 있다. 3일이면 들통날 거짓말은 하지 않는게 필자의 지론이다.) 참고자료 『Applying UML and Patterns, 2nd ed』, Larman, Prentice Hall OOAD에 대해서 설명하고 있는 책으로 책 전체가 하나의 케이스 스터디로 구성되어 있기 때문에 전체 소프트웨어 개발 과정에서 어떻게 UML과 패턴을 적용하고 있는지 보여주고 있다. 『UML Distilled 2nd ed』, Kendall Scott, Martin Fowler 리팩토링으로 잘 알려진 마틴 파울러와 ICONIX Process로 잘 알려진 Kendall Scott이 공동 집필한 서적으로 UML에 대해서 잘 설명하고 있는 책이다. 국내에 원서와 번역서 모두 소개되어 있으며 영어가 어려운 분들은 번역서를 참고하기 바란다. 『The Unified Modeling Language Users Guide』, Grady Booch, Ivar Jacobson, James Rumbaugh 3인방(Three Amigos)으로 알려진 3명의 저자가 집필한 책이며 다른 UML 관련 서적을 위한 출발점으로 삼아도 될만한 책이다. OOAD에서 분석과 디자인을 위해 어떻게 UML을 적용할 것인가를 잘 설명한 책이다. 이 책과 함께 『UML In a Nutshell』을 레퍼런스로 시작하면 좋을 것이다.