일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- array
- heroku
- JAVA11
- 카데인 알고리즘
- hash table
- scanner
- R
- 자바 thread 실행 순서 제어
- 자바 스레드 실행 순서 제어
- Easy
- SpringBoot 2
- Kadane's Algorithm
- 사칙연산
- 수학
- input
- 자바입력
- Today
- Total
DeFacto-Standard IT
클래스, 관계, UML 본문
분류 |
Diagram 유형 |
목적 | |
구조 다이어그램 (Structure Diagram) - 정적 |
클래스 다이어그램 (Class Diagram) |
시스템을 구성하는 클래스들 사이의 관계를 표현 | |
객체 다이어그램 (Object Diagram) |
객체 정보를 보여줌 | ||
복합체 구조 다이어그램 (Composite Structure Diagram) |
복합구조의 클래스와 컴포넌트 내부 구조를 표현 | ||
배치 다이어그램 (Deployment Diagram) |
SW, HW, 네트워크를 포함한 실행 시스템의 물리 구조를 표현 | ||
컴포넌트 다이어그램 (Component Diagram) |
컴포넌트 구조 사이의 관계를 표현 | ||
패키지 다이어그램 (Package Diagram) |
Class나 UseCase 등을 포함한 여러 모델 요소들을 그룹화하여 패키지를 구성하고 패키지들 사이의 관계를 표현 | ||
행위 다이어그램 (Behavior Diagram) - 동적 |
활동 다이어그램 (Activity Diagram) |
업무 처리 과정이나 연산이 수행되는 과정을 표현 | |
상태머신 다이어그램 (State Machine Diagram) |
객체의 생명주기를 표현 | ||
유즈케이스 다이어그램 (UseCase Diagram) |
사용자 관점에서 시스템 행위를 표현 | ||
상호작용 다이어그램 (Interaction Diagram) |
순차 다이어그램 (Sequence Diagram) |
시간 흐름에 따른 객체 사이의 상호작용을 표현 | |
상호작용 개요 다이어그램 (Interaction Overview Diagram) |
여러 상호작용 다이어그램 사이의 제어흐름을 표현 | ||
통신 다이어그램 (Communication Diagram) |
객체 사이의 관계를 중심으로 상호작용을 표현 | ||
타이밍 다이어그램 (Timing Diagram) |
객체 상태 변화와 시간 제약을 명시적으로 표현 |
- 클래스 다이어그램
시간에 따라 변하지 않는 시스템의 정적인 면을 보여주는 대표적 UML 구조 다이어그램.
시스템을 구성하는 클래스와 그들 사이의 관계를 보여준다.
- 클래스
동일한 속성과 행위를 수행하는 객체의 집함.
클래스의 인스턴스는 '실체'를 의미.
클래스를 보는 또 하나의 관점은 객체를 생성하는 설계도로 간주하는 것.
UML에서는 세 부분으로 나누어진 박스로 클래스를 표현한다.
가장 윗 부분 - 클래스 이름
중간 부분 - 클래스의 특징을 나타내는 속성
마지막 부분 - 클래스가 수행하는 책임(연산)
경우에 따라 속성, 연산 부분은 생략할 수 있는데, 이런 경우 구획선을 그리지 않아도 된다.
또한 클래스의 속성과 연산을 기술할 때는 '-' 혹은 '+'와 같은 부호를 사용하는데, 이는 속성과 연산의 가시화를 정의한 것이다.
접근제어자 |
표시 |
설명 |
public |
+ |
어떤 클래스의 객체에서든 접근 가능 |
private |
- |
이 클래스에서 생성된 객체들만 접근 가능 |
protected |
# |
이 클래스와 동일패키지에 있거나 상속관계에 있는 하위클래스의 객체들만 접근가능 |
package |
~ |
동일패키지에 있는 클래스의 객체들만 접근 가능 |
속성과 연산에 가시화 정보를 항상 표시해야 하는 것은 아니다. 본래 클래스 다이어그램은 개념 분석 단계에서 구현에 이르기까지 광범위하게 사용되며, 속성 및 연산을 기술하는 상황에 따라 강조하는 것이 다를 수 있다.
분석 단계 - 속성의 구체적인 타입 정보나 가시화 정보보다 어떤 것을 속성으로 하는지가 더 중요
설계 단계 - 바로 코드 생성이 가능할 수 있는 정도로 구체적인 타입 정보와 가시화 정보를 기술하는것이 일반적
연산도 연산 이름을 제외한 인자의 목록이나 인자의 타입, 반환 타입 등과 같은 정보를 분석 단계에서는 생략 가능
다음에서 '[]'부분은 생략할 수 있는 항목이다.
|
표기방법 |
속성 |
[+|-|#|~]이름: 타입[다중성 정보][=초기값] |
연산 |
[+|-|#|~]이름(인자1: 타입1, ... , 인자n:타입n): 반환 타입 |
다음은 2가지 형태의 Course 클래스 다이어그램이다.
왼쪽의 Course 클래스는 속성과 연산 항목에 구체적인 타입 정보와 가시화 정보를 기술하지 않은 분석 단계의 클래스
오른쪽 Course 클래스는 바로 코드를 생성할 수 있게 하려고 구체적인 타입 정보와 가시화 정보를 기술한 설계 단계의 클래스에 해당.
*다이어그램 <-> 코드 의 변환이 자율적이어야 한다.
'Design Pattern > References' 카테고리의 다른 글
인터페이스, 실체화 관계 (0) | 2017.10.28 |
---|---|
의존관계 (0) | 2017.10.28 |
집합관계 (0) | 2017.10.28 |
일반화관계 (0) | 2017.10.28 |
연관관계 (2) | 2017.10.28 |