0장. UML이란?

UML이란?

Unified Modeling Language의 약자이다. 하나의 시스템을 표현하기 위한 표준적인 방법을 제공하기 위해서 만들어 졌다.

 

 

UML 개요

• OMG 표준기구로부터 인정받은 표준화된 그래픽언어이다.
• 개발자들의 의사소통을 원활하게 하며 기업간의 시스템 통합을 가능하게 한다.
• 개발 시스템과 관련된 사람에게 비전을 공유하고, 의견을 얻을 수 있도록 한다.
• 개발자, 운영자, 사용자, 엔지니어등와 시스템의 의도를 쉽게 전달할 수 있다.
• UML은 기호와 도식을 이용한다.
• 프로그램언어가 아닌 기호와 도식을 이용하여 표현하는 방법을 정의한다.

 

 

UML 작성 목적

객체 지향 시스템을 가시화, 명세화, 문서화한다.

 

 

 

UML의 요소

• Thing
• Structual Thing
• Behavioral Thing
• Grouping Thing
• Annotation Thing
• Relationships
• Dependency Relationship
• Generalization Relationship
• Association Relationship
• Aggregation Relationship
• Composition Relationship
• Realization Relationship
• Diagrams
• Class Diagram
• Object Diagram
• Use Case Diagram
• Sequence Diagram
• Collaboration Diagram
• State Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

 

Thing

정의

추상적인 개념으로 UML을 이용한 모델링의 기본요소

 

종류

Structural Thing(구조 사물)

  - UML 모델의 명사형(예. 클래스, 노드, 서버, 사용자...)

  - 모델의 정적인 부분이며 개념적이거나 물리적인 요소

Behavioral Thing(행동 사물)

  - UML 모델의 동사형

  - 모델의 동적인 부분이며 시간과 공간에 따른 행위 요소를 표현

Grouping Thing(그룹 사물)

  - 모델을 그룹화하여 요소 표현(패키지, 라이브러리, 네임스페이스..)

Annotation Thing(주석 사물)

  - UML 모델 요소를 설명하거나 메모하거나 명확히 하는 표현방법(주석, 메모..) 

 

 

Structural Thing 종류

 = Class(클래스)

  - 속성과 동작으로 구성된 객체를 표현(변수와 메소드, 객체지향 언어의 Class 와 동일)

 

왼쪽은 클래스명, 속성, 행동(메소드)를 표현한 것

오른쪽은 클래스명만으로 간략히 표현한것

 

 

= Interface(인터페이스)

  - 클래스 또는 컴포넌트의 행동(동작, 메소드)만을 명세화한 Operation의 집합이다.{자바의 인터페이스와 동일 개념 속성(인스턴스 변수) 없이 행동(메소드)선언만 존재하는 추상클래스라고 생각하면 쉽다. 행동의 구체적 명시없이 선언된 클래스}

 

 

왼쪽은 클래스 표현법의 클래스명에 <<Interface>> 란 단어를 붙여 Interface를 표현할 것이다.(행동을 명시하고 싶을때 사용한다.)

오른쪽은 Interface 명만 표현한 것이다.

 

 

= Use Case (쓰임새)

  - 시스템이 수행해야 하는 기능을 기술

 

 

 

= Component (컴포넌트)

  - 객체 지향에서의 모듈화 된 자원

    예) 문서, 소스 코드, 파일, 라이브러리 등

 

 

 

= Node (노드)

  - 실행시에 존재하는 실제 물리적 요소

    예) 서버, 프린터, 복사기, 키보드 등

 

 

 

 

 

 

Behavioral Thing 종류

 

= Interaction (상호작용)

  - 행위를 의미하여 특정 문백에 속한 객체들간의 Messages 들로 구성

 

 

 

= State Machine (상태 머신)

  - 객체의 시간에 따른 상태를 표현

 

 

 

                                              예)  

 

 

 

 

 

Grouping Thing 종류

 = Package 패키지

  - 요소를 그룹으로 묶는 방법(폴더 모양), 프레임워크, 서브시스템 표현

 

 

 

 

Annotation Thing 종류

 = Note (노트)

  - 주석(comment) 로 모델요소를 명확하게 설명하기 위한 방법

  - 주로 제약조건, 메모, 설명을 표현한다.

 

 

 

 

 

 

 

 

Relationships

정의

  - 구성 요소들간의 연관성을 표현

  - 주로 클래스들간의 관계 표현시 사용된다.

 

종류

  - Dependency Relationship(의존 관계)

  - Generalization Relationship(일반화 관계)

  - Association Relationship(연관 관계)

     - Aggregation Relationship(집합 관계)

     - Composition Relationship(구성 관계)

  - Realization Relationship(실체화, 실현 관계)

 

 

Dependeny Relationship

정의

 - 한 클래스가 다른 클래스를 사용하는 사용관계

 (프로그래밍에서는 인스턴스 변수없이 어떤 클래스의 정적 메소드를 사용할 경우나, 메소드내에서만 생성되었다 사라지거나 하는 경우. 예를 들어 Math 클래스 사용시 인스턴스를 생성하지 않고 Math 클래스의 정적 메소드(Math.sin()) 을 사용하는 경우이다. )

 

특징

 - 하나의 클래스의 변화가 다른 클래스에 영향을 주는 관계

 - UML 표기법은 점선으로 된 화살표로 표현

 - A 가 B를 의존할때

 

                                       

예) 세금 , 세금법

 

 

 

Generalization Relationship

정의

 - 일반화(generalization), 특수화(명세 specialization) 관계

 - 객체 지향에서의 상속 관계

  예) 인간, 원숭이의 일반화(Generalization)는 포유류이다. 포유류 중 특수화(specialization)는 인간이다.

- 실선에 화살표로 표현

 

화살표 방향이 일반화관계이고 반대가 특수화 관계이다.

 

 

 

 

 

Association Relationship (연관 관계)

정의

 - 클래스로부터 생성된 객체간의 일반적 협력관계

 - 연관 관계는 실선혹은 양방향화살선으로 표현한다.

 

한 반에는 여러 학생이 속한다. 한 학생은 하나의 반에만 속할 수 있다. * 은 0 혹은 그이상을 표현한다.

 

그냥 실선이나 양화살표가 있는 선이나 같은 표현이다.

 

 

세부 종류(Association 관계는 세부적으로 2가지로 나눈다.)

 - Aggregation Relationship(집합연관)

 - Composition Relationship(복합연관)

* association, aggregation 은 개념적차이지 실제 코드상의 차이는 거의없다. composition 은 실제 코드상에 차이가 있다.

 

 

= Aggregation Relationship(집합 관계)

정의

 - 두 클래스간의 전체-부분관계(Whole-part)

 - 각 클래스가 독립적인 생명 주기를 갖는다.

   예) 자동차의 경우 자동차가 사라진다고 바퀴, 엔진이 사라지는 것은 아니다. 자동차와 바퀴, 엔진의 생명주기는 다르다. 역으로 바퀴가 사라진다고 자동차도 사라지는 것은 아니다.

 - 하나의 클래스가 여러개의 컴포넌트 클래스로 구성

 

 

추가설명 : Aggregation Relationship 은 속이 빈 다이아몬드로 표현한다.

 

이렇게 이해하면 좋다. A가 B를 포함한다.

A ◇───> B 

= Composition Relationship

정의

 - 두 클래스간의 부분-전체관계(Part-Whole)

 - 부분의 생명주기가 전체의 영향을 받는다.

 - 하나의 클래스가 여러개의 컴포넌트 클래스로 구성

 - 다른 말로 강한 집합관계

추가적으로

 - part를 가진 whole 인스턴스가 part 인스턴스의 전체 수명을 책임진다.

 - part에 해당하는 인스턴트는 공유 될수 없다.

 - whole 인스턴스가 part 인스턴스를 생성

 - whole 인스턴스가 소멸되면 part 인스턴스도 함계 소멸

 - whole 인스턴스가 복사되면 part 인스턴스도 복사됨

구현시

 - Deep Copy 를 구현해야함 (공유되지 않기 위해서)

 - whole 클래스 생성시 part도 같이 생성되어야 함

 - 외부에서 part를 생성하지 못하게 해야하고 또한 part에 대한 Setter가 없어야 한다.

- whole ◆───> part

 - aggreagtion 과 다르게 ◇ 에 속이 채워져 있다.(채워져 있으니 없어져도 같이 없어진다고 생각하면 편할 듯)

 - A 는 B로 구성되어 있다. A◆───> B

- 손과 손가락으로 예를 들었다. 손이 생겨야 손가락도 생긴다. 손가락만 따로 생성되지 않는다. 또한 손이 사라지면 손가락도 사라진다. 물론 현실 세계에서 손만 사라지고 손가락은 남아서 남한테 붙일수 있지만 Aggregation 이나 Composition은 개념적으로 설계자가 어떻게 설계하느냐에 따라 달라지는거다. 설계자는 손과 손가락을 하나의 세트로 생각했으므로 Composition을 사용한것이고 손이 사라지면 손가락도 사라진다고 설계자는 설계했다.

= Realization Relationship

정의

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

 - generaization Relationship과 비슷하다 다르다. generalization은 존재하는 객체(속성,행동)에 대한 추가구현(오버라이딩)이고 Realization 은 존재하는 행동에 대한 구현이다.

 - 예를 들어 부모와 자식관계에서 부모는 키, 몸무게 등의 속성과 걸음, 달리기, 점프등의 행동이 이미 존재한다. 이것을 그대로 상속 받거나 변조 구현 한것이 자식이다. 이처럼 존재하는 것에서 더 추가/제거/변경을 통해 생성된 관계가 generalization 관계이다.

 - Realization은 행동만 정의 되어있는(구현되지 않았다. 행동 목록만 존재) 객체(interface)를 구현한 것이다. 예를 들어 '달리다', '점프하다', '눕다' 란 행동목록이 존재한다면 이것이 interface이다. 키, 몸무게 등의 속성은 없다. 행동 또한 어떻게 달릴지 어떻게 뛰지 구현되어 있지 않다. 다만 행동 목록만 나열되어 있다. 이것을 구현 할 때 Realization Relationship 이다. 

달리다, 점프하다, 눕다란 행동은 인간 뿐만 아니라 강아지, 사자, 호랑이로 구현 될 수 있다.

 - interface 는 행동만 정의(나열, 구현되지 않았다.)된 객체이다.

 - 다시 정리하면 generalization 은 객체(속성,행동)을 이어받아 속성/행동을 추가/제거/수정한 구현을 말하고 Realization은 행동(기능) 목록만을 나열된 interface의 행동(기능)을 구현한 것이다.

 - 자바나 c# 등 객체지향 언어의 일반 클래스와 추상클래스, interface에 대한 개념이 있다면 쉽게 이해할 수 있다.