[Design Pattern] UML, 클래스, 관계

- 모델은 추상화에 바탕을 둠.

특정 관점에서 관련이 있는 점은 부각/관련이 없는 것은 무시

 

- 모델링 언어 = UML

UML은 요구 분석, 시스템 설계, 시스템 구현 등의 시스템 개발 과정에서 개발자 사이의 의사 소통이 원활하게 이루어지도록 표준화한 통합 모델링 언어

 

- 클래스 다이어그램

시간에 따라 변하지 않는 시스템의 정적인 면을 보여주는 대표적인 UML 구조 다이어그램.

(Q. 시간에 따라 변하지 않는다... 시스템의 정적인 구조를 표현한다....는 말이 정확히 어떤 말인지 감이 안 옴.)

시스템을 구성하는 클래스와 그들 사이의 관계를 보여준다.

 

- 클래스

동일한 속성과 행위를 수행하는 객체의 집합.

클래스의 인스턴스는 '실체'를 의미

클래스를 보는 또 하나의 관점은 객체를 생성하는 설계도로 간주하는 것.

 

Keypoint_ 클래스는 공통의 속성과 책임을 갖는 객체들의 집합이자 실제 객체를 생성하는 설계도다.

 

UML에서는 세 부분으로 나누어진 박스로 클래스를 표현한다.

=> 클래스명

 

=> Attr(멤버변수) 즉, 클래스속성

 

=> Oper(메서드)

 

가장 윗부분 - 클래스 이름중간 부분 - 클래스의 특징을 나타내는 속성마지막 부분 - 클래스가 수행하는 책임 (연산)경우에 따라 속성, 연산 부분은 생략할 수 있는데, 이런 경우 구획선을 그리지 않아도 된다.

 

또한 클래스의 속성과 연산을 기술할 때는 '-' 혹은 '+'와 같은 부호를 사용하는데, 이는 속성과 연산의 가시화를 정의한 것이다. 

속성과 연산에 가시화 정보를 항상 표시해야 하는 것은 아니다. 본래 클래스 다이어그램은 개념 분석 단계에서 구현에 이르기까지 광범위하게 사용되며, 속성 및 연산을 기술하는 상황에 따라 강조하는 것이 다를 수 있다. 

 

분석 단계 - 속성의 구체적인 타입 정보나 가시화 정보보다 어떤 것을 속성으로 하는 지가 더 중요

설계 단계 - 바로 코드 생성이 가능할 수 있는 정도로 구체적인 타입 정보와 가시화 정보를 기술하는 것이 일반적

 

연산도 연산 이름을 제외한 인자의 목록이나 인자의 타입, 반환 타입 등과 같은 정보를 분석 단계에서는 생략할 수 있다.

 

'[]'부분은 생략할 수 있는 항목이다. 

	표기방법
속성	[+|-|#|~]이름:타입[다중성 정보][=초기값]
연산	[+|-|#|~]이름(인자1:타입1, ...인자n:타입n):반환 타입

왼쪽의 Course 클래스는 속성과 연산 항목에 구체적인 타입 정보와 가시화 정보를 기술하지 않은 분석 단계의 클래스

오른쪽 Course 클래스는 바로 코드를 생성할 수 있게하려고 구체적인 타입 정보와 가시화정보를 기술한 설계 단계의 클래스

 

- 객체지향 시스템은 상호관계를 맺는 여러 클래스에서 생성된 객체들이 기능을 수행한다.

관계	설명
연관관계 (association)	클래스들이 개념상 서로 연결되었음을 나타낸다. 실선이나 화살표로 표시하며 보통을 한 클래스가 다른 클래스에서 제공하는 기능을 사용하는 상활일 때 표시한다.
일반화 관계 (generalization)	객체지향 개념에서는 상속 관계라고 한다. 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 이를 IS-A 관계라고 하며 UML에서는 일반화 관계로 모델링한다. 속이 빈 화살표를 사용해 표시한다.
집합관계 (composition, aggregation)	클래스들 사이의 전체 또는 부분 같은 관계를 나타낸다. 집약(aggregation)관계와 합성(composition)관계가 존재한다.
의존 관계 (dependency)	연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때를 나타낸다. 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같은, 매우 짧은 시간만 유지된다는 점이다. 점선 화살표를 사용해 표시한다.
실체화 관계 (realization)	책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계를 나타낸다. 상속과 유사하게 빈 삼각형을 사용하며 머리에 있는 실선 대신 점선을 사용해 표시한다.