1. 클래스 다이어그램


- 가장 중요한 다이어그램이며, 분석/설계 단계에서 모두 이용, 작성합니다. 이는 구현시 각 클래스로 표현됩니다. 초기 다이어그램은 객체와 클래스가 혼합되어 나타나지만 후반부로 가면서 구체화되어 시스템의 구현객체로 표현됩니다. 

- 클래스는 지식 도메인에 기반한 어휘와 용어로부터 만들어집니다. 시스템분석가는 의뢰인과 상담하여 그들이 가지고 있는 지식 도메인을 파악하여 정리하고, 그 도메인에서 발생되는 문제를 해결할 컴퓨터 시스템을 설계해 나가면서, UML에 사용할 용어를 선정하고 이것을 클래스로 모델링 하는 것입니다. 

- 의뢰인과 대화속에서 명사와 동사에 귀를 기울여햐 합니다. 명사는 클래스의 이름이 될 확률이 높기 때문이고 동사는 모델링한 클래스의 Operation이 될 가능성이 있습니다. 

- 클래스의 핵심이 되는 리스트(클래스 이름, 속성, 오퍼레이션)를 모두 정리한 다음에는 각각의 클래스가 의뢰인의 업무에서 어떤 역할을 할지에 대하여 묻도록 합니다. -> 이에 대한 대답은 클래스 책임 설명으로 적을 수 있습니다. 



명사 : 볼, 바스켓, 팀, 선수, 가드, 포워드, 센터, 슛, 슛시간, 3점 라인, 자유투, 파울, 자유투라인, 코트, 게임시간

동사 : 슛하다, 드리블 패스, 파울, 리바운드 (이 외에도 개인의 상식을 동원해서 클래스 모델링에 사용할 수 있습니다.)


다음은 이런 정보를 바탕으로 만든 Class 다이어그램입니다. 이렇게 만든 클래스 다이어그램은 나중에 다시 감독과 이야기할때 충분한 기본자료로 사용하여 더 많은 정보를 얻어내는데 도움을 줄 것입니다. 


연관 (Association)

클래스가 개념적으로 서로 연결되어 있음을 의미합니다.


- 각각의 클래스마다 역할을 표시할 수 있습니다. 

- 하나의 클래스가 여러클래스와 연관을 맺을 수 있습니다. 

- "->" 또는 <-" 화살표 표시를 사용하여 관계의 방향을 나타낼 수 있습니다. 



연관클래스


- 연관의 속성과 오퍼레이션을 모델링할때 사용합니다. 연관클래스는 연관선과 점선으로 연결되며, 다른클래스와의 연관을 가질수도 있습니다. 


객체가 클래스의 인스턴스인 것처럼, 연관도 자신의 인스턴스를 가질 수가 있습니다. 어떤 특정한 선수가 특정한 팀에 소속되어 있는 관계를 생각하면, 이때의 "운동하다" 연관관계를 링크(link)라고 부릅니다. 링크는 두 객체를 선으로 이어서 나타내며, 객체에 밑줄 긋듯이 링크에도 밑줄을 긋습니다. 



다중성(Multiplicity)


- 연관되어 있는 두 클래스 사이에서 한 클래스의 객체와 관계를 가질수 있는 다른 클래스의 객체 개수. 이것을 다이어그램에서 나타내면 해당 클래스 가까지에 객체의 수를 써줍니다. 예를 들면, 팀의 입장에서 보면 다섯명의 선수와 연관되어 있지만 선수의 입장에서 보면 한팀과 연관되어 있다는 것입니다. 


표기 

- UML은 "more"과 "many"를 표현하는 기호로써 '*' 를 사용합니다. 

예) 

- 1..* -> 1또는 그이상

- 2..7 -> 2이상 7까지

- 5,7 -> 5 또는 7


상속과 일반화(Generalization)


- 한 클래스는 다른 클래스로부터 속성과 오퍼레이션을 물려 받을 수 있습니다. 이것을 객체지향 개념에서는 "상속"이라 하고, UML 에서는 "일반화"라고 합니다. 상속관계에서 상속을 받는 쪽을 Child Class 또는 Sub Class라고 하고, 상속을 해주는 쪽을 Parent Class 또는 Super Class라고 합니다. Sub Class에서 Super Class 쪽으로 속이 빈 화살표를 연결합니다. 이러한 타입의 연결관계를 "...의 일종(is a kind of) 라고 부릅니다.


- 상속관계를 모델링 할 때에는, 반드시 서브 클래스가 수퍼 클래스에 대해 "is a kind of" 관계를 가지도록 만들어야 합니다. 

- 만약 두 클래스가 이 관계로 맺어지지 않는다면, 차라리 다른 타입의 관계를 맺어주는 것이 더 낫습니다. 


Root Class : Super Class를 가지지 않는 클래스

Leaf Class : Sub Class를 가지지 않는 클래스  



★ 어떤 Sub Class의 Super Class가 있을때, 만약 이 Super Class의 구체적인 인스턴스를 만들 필요가 없을때에는 "추상 클래스"로 만들자. 즉, 클래스의 객체를 생성하지 않는 클래스를 "추상 클래스"로 만듭니다. 

표기: 클래스명을 이탤릭체로 씁니다. 

의존관계(Dependency)

- 한 클래스가 다른 클래스를 사용하는 관계를 말합니다. 예를 들자면 "시스템"클래스와 "폼" 클래스가 있는데, "시스템"클래스는 '폼_출력(form:폼)' 이라는 Operation을 가지고 있을때, 이 "시스템"이 화면에 표시해주는 서식은 전적으로 "폼" 클래스에 따라 달라집니다. 이 상황을 UML로 표기하려면 "의존대상" 이 되는 클래스를 향해 점선으로 긋고 화살표 머리를 붙여주면 됩니다. 

집합연관(Aggregation)


 하나의 클래스가 여러개의 컴포넌트 클래스로 구성되어 있는 경우가 있습니다. 즉, 컴포넌트 클래스와 전체 클래스가 "부분-전체"연관 관계를 가질때 집합 연관이 됩니다. 

표기 : 컴포넌트 클래스와 전체 클래스를 선으로 잇고, 빈 마름모꼴을 전체 클래스 쪽에 붙여서 나타냅니다.

복합연관(Composition)


강한 집합연관으로써 각 컴포넌트 클래스가 오직 하나의 전체 클래스에서만 의미를 가질때, 복합연관으로 표현 합니다. 

표기 : 각각의 컴포넌트는 전체 클래스 쪽으로 향하여 안이 채워진 마름모 꼴의 화살표로 연결합니다. 


인터페이스와 실체화


- 어떤 클래스들이 동일한 Super Class와 관계를 가지지 않았는데, 같은 시그니처를 가진 Operation이 존재한다면 이것은 Operation의 재사용으로 간주 됩니다. 이런 재사용을 위한 Operation 의 집합을 인터페이스라고 합니다.


- 인터페이스는 클래스의 일정한 행동을 나타내는 Operation의 집합으로, 다른 클래스에서 사용될 수 있습니다. 자바에서 인터페이스는 method의 prototype 만 선언되어 있고, 인터페이스를 구현(Implementation)한 클래스에서 method를 정의합니다. 이것을 UML에서는 실체화(realization) 라고 합니다. 


가시성(Visibility)

-> 해당 클래스(혹은 인터페이스)의 속성과 오퍼레이션을 들여다 볼 수 있는 범위를 말합니다. 


표기 : 자바기준 

"+"  public : 모든 클래스에서 접근가능

"#"  protected : Package member Class와 Sub Class만 접근가능

"-"  private : member Operation만 접근가능

none : Package member Class만 접근가능 



* 위 자료는 백석대학교 이승형 교수님의 "소프트웨어 공학" 자료를 참고하였습니다.