UML을 살펴보자

1. StarUml로 UML을 살펴보자

• 1. StarUml로 UML을 살펴보자
  • 1.1. UML (Unified Modeling Laguage)
  • 1.2. Diagram
    • 1.2.1. Class Diagram
  • 1.3. Class
  • 1.4. StarUML
    • 1.4.1. StarUML 클래스
    • 1.4.2. Steretype
    • 1.4.3. 접근제어
    • 1.4.4. Relation 표현
      • 1.4.4.1. Association (연관)과 Directed Association (직접 연관)
      • 1.4.4.2. Aggregation (집합)
      • 1.4.4.3. Composition (복합 연관)
      • 1.4.4.4. Dependency (의존)
      • 1.4.4.5. Generalization (일반화)
      • 1.4.4.6. Realization (실제화)와 Interface Realization (인터페이스 실체화)
      • 
        

1.1. UML (Unified Modeling Laguage)

개발자가 시스템 구조의 구조를 표준적이고 이해하기 쉬운 방법으로 시각화시켜 개발에 도움을 주고, 다른 사람과의 협업에 있어서 공유할 수 있는 메커니즘.

 

1.2. Diagram

Diagram은 시스템을 여러 가지 시각에서 볼 수 있는 뷰를 제공한다. 그리고 이런 뷰의 집합을 모델이라고 한다. 즉, 게임 서버를 만든다고 가정하자. 우리는 이 게임 서버를 다른 팀원들과 공유할 필요가 있을 것이다. 게임 서버의 구조를 클래스 간의 관계에서 볼 수도 있지만, 시간순서에 따른 흐름로도 볼 수 있다. 또는 객체들간의 통신로도 볼 수 있다. 이때 게임 서버의 구조를 모델, 각각의 관점을 뷰, 이 뷰를 표현하는 도구를 Diagram이라고 보면 될 것같다. 이런 관점(뷰)마다 표현할 수 있는 Diagram이 있다는 소리

1.2.1. Class Diagram

diagram은 그 종류가 다양한데, 그중 객체지향을 표현하는데 많이 쓰이는 것이 클래스 다이어그램(Class Diagram)이다.

1. 시스템의 논리적 구조를 표현
2. 객체지향 개발에서 많이 사용

1.3. Class

1. 객체의 속성(Attribute)와 행동(Operation)을 포함한다.
2. 모든 Class는 유일한 이름을 갖는다.
3. 단순명(Simple Name) : class 이름만 표현한다.

1.4. StarUML

StarUml...에 대해서는 딱히 아는게 없다. 그냥 Class Diagram의 대표적인 툴이라는 것이다. 나는 StarUML2까지는 무료였다는데, 몇년전부터 유료가 되어서 나는 평가판을 사용하겠다. 내 수준이 그렇게 높은 것도 아니고, 평가판이라도 기간은 무제한인 것같으니 딱 쓰기 좋은 것같다.

1.4.1. StarUML 클래스

아래의 그림은 Class Diagram의 기본적인 구조다.  

 

1은 클래스의 이름이다. 2는 멤버변수이다. 표현법은 아래와 같다.

(<>) 접근제어 이름 (: 타입) ([배열길이]) (= 기본값)

3번은 메서드다. 표현법은 다음과 같다.

(<>) 접근 제어 이름 (매개변수이름 : 타입) (:반환타입)

• 가상 함수의 경우, 글자가 기울어진다.

1.4.2. Steretype

표현법을 보면 Steretype라는 것이 있다. UML에서는 모델링 타임에 정의된 새로운 메타클래스라는데, 내가 봤을 떄에는 태그(꼬리표)같은 것이라고 보면 될 것같다. 굉장히 괜찮은 개념이라고 생각한다. Class Diagram으로 우리는 클래스들을 표현한다. 그러나, 클래스들을 분류하고 싶을 수가 있다. 이때에 클래스에 태그를 붙이는 것이 바로 Steretype이다.

1.4.3. 접근제어

의미	기호
public	+
private	-
protected	#
package	~

1.4.4. Relation 표현

 

 이 부분이 uml 포스팅을 써야겠다고 결심한 부분이다. 이걸 좀 정리해야할 필요성을 느꼈었다.

• Association (연관)
• Directed Association (직접 연관)
• Aggregation (집합 연관)
• Composition (복합 연관)
• Dependency (의존)
• Generalization (일반화)
• Realization (실체화)
• Interface Realization (인터페이스 실체화)

1.4.4.1. Association (연관)과 Directed Association (직접 연관)

클래스로 생성된 인스턴스들간의 관계를 말한다. 클래스에 메모리를 할당하여 참조하는 관계이다. (멤버변수로 가지지 않고 함수에 할당하거나...) 사진에서 볼 수 있듯이 직선으로 되어있는데, 이것은 A가 B를, B가 A를 참조할 수도 있다는 뜻이다.

1. A와 B는 서로 참조할 수 있다.
2. 수평적인 관계이다.

직접 연관은 멤버 변수로 가지는 관계를 말한다. 클래스가 다른 인스턴스에 명령을 내릴 수 있는 관계이다.

1. A와 B는 서로 참조할 수 있다.
2. 수직적인 관계다.

1.4.4.2. Aggregation (집합)

전체-부분을 표현한다.

1. has-a 관계를 표현하는데 쓰인다.
2. 서로 독립적인 관계이다.
3. 서로 생명주기가 다르다.(독립적이기에)
4. 부분 인스턴스는 다른 클래스와 공유될 수 있다.

1.4.4.3. Composition (복합 연관)

복합 연관관계는 집합과 같이 전체-부분을 나타내지만, 더 강한 관계를 나타낸다.

1. 집합은 서로 독립적이지만, 복합은 생명주기가 동일하다. 즉, 같이 생성되고 같이 소멸된다.
2. 부분은 공유되지 않는다. 전체가 사라질 때에 부분 또한 사라지기 때문이다. (독립적이지 않기 때문이다.)

1.4.4.4. Dependency (의존)

여기서부터 슬슬 머리가 아프더라....

1. 한 클랙스가 다른 클래스에 영향을 미친다.
2. 참조를 유지하지 않는다.
   • 멤버함수가 다른 클래스의 인스턴스를 인자로 받는다.
   • 한 클래스의 메소드 내에서 다른 클래스를 생성하고 생성된 클래스의 메소드를 사용한다.
   • 한 클래스가 다른 클래스를 반환

1.4.4.5. Generalization (일반화)

일반화는 Is-a 관계를 표현

1. Is-a관계를 표현한다.
2. 여러 클래스가 가진 공통적인 특징을 추출하여 공통적인 클래스로 일반화시키는 것을 의미한다.
3. 상속관계를 표현하는데 쓰인다.

1.4.4.6. Realization (실제화)와 Interface Realization (인터페이스 실체화)

인터페이스와 실제 구현된 클래스간의 관계.