응용단 설계
Class Diagram 편.
by
Jan 03. 2017
시스템 설계 관련해서 포스팅을 했다가 지웠는데 100 이상 공유는 쉽지 않다는 것을 뒤늦게 깨닫고 후회하고 있습니다. 저처럼 몰라서 잘못을 저지르는 사람들이 세상에 많습니다. 극단적인 예를 하나 들어 보겠습니다.
현실 세계를 클래스로 만들기는 매우 쉽습니다. 위 기사에 대해서 어느 누구도 반론을 제기하지 못할 UML 클래스 다이어그램의 클래스들은 다음과 같습니다.(너무 단순화 하긴 했습니다. ^^)
여기서 "관계를 맺는 것"을 UML 다이어그램에서는 "선을 긋는다"로 표현할 수 있습니다. associations, relationships, aggregation 어떤 말을 써도 좋습니다. 이해하기 쉽게, OLPP 패러다임 설명에서 쓰던 용어로 통일해 보면 link가 가장 맞는 표현이라고 봅니다. UML은 OMG가 라이센스를 가지고 있어서 이렇게 마음대로 용어를 정의하고 설명하니, 야매(걍 이해를 돕기 위한 가짜?)라고 보시면 됩니다.
이 모두는 어떠한 모습이던 관계가 있게 됩니다. 아빠가 생각한 관계는 다음과 같습니다.
클래스의
수명을 함께하는 관계를 나타낸 선(다이아포함)을 composition 라고 합니다. 다이아몬드 부분의 클래스가 사라지면, 함께
사라지는 것입니다. 사람 클래스에 각각 얼굴, 몸, 팔, 다리 클래스가 붙었을 때도 위와 같이 컴포지션 디렉션을 지정할 수
있습니다.
그러나 실제로는 다음과 같습니다.
아빠와 엄마를 둘러싼 것을 패키지, 딸1/2를 둘러싼 것도 패키지이며 두 패키지는 <<package import>>, 또는 <<element import>> 인 가져오기 관계일 뿐입니다. <<가져오기>> 를 삭제하면 종속(부모의 도움을 받으며 의존적인)관계로 가져오기 보다는 조금 더 친밀하게 됩니다. 물론, 컴포지션이 가장 친밀한 관계입니다. 죽고 못사는 경우죠.
아빠가 생각한 것은 두 딸은 컴포지션 관계로 자신으로부터 상속(삼각형 모양)받았다고 생각합니다.
(붙이고 보니 딸1, 딸2 의 아빠, 엄마 상속 relationshop이 하나씩 빠졌네요 ^^)
상속은 둘의 relationshop이 끊어져도 각 객체는 유지됩니다.
단지 상속 관계일 뿐이지,
컴포지션 관계가 아니라는 것입니다.
Whatever... 상속이던 종속이던 집합 관계던 컴포지션은 아닙니다.
다이어가 칠해져 있지 않으면 aggregation association(집계, 집합체 관계)입니다. 구성원이라는 것이죠.
설명을 위해 간단히 사회라는 클래스를 만들었다고 했을 때 위와 같은 모습이 됩니다. 딸1의 자식이 있었다면, 아마 컴포지션 관계일 것입니다. 세월호에 탔던 학생들의 부모님들의 심정을 UML로 헤아려보면 말이죠.
댓글 없음:
댓글 쓰기
국정원의 댓글 공작을 지탄합니다.