클래스 다이어그램
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
클래스 다이어그램은 소프트웨어 시스템의 클래스, 속성, 메서드 및 클래스 간의 관계를 시각적으로 표현하는 데 사용되는 UML(Unified Modeling Language) 다이어그램의 한 유형이다. 클래스는 사각형으로 표현되며, 클래스명, 속성, 메서드를 포함할 수 있다. 속성과 메서드는 가시성, 범위, 다중성과 같은 추가 정보를 가질 수 있으며, 연관, 집합, 합성, 의존, 일반화/상속, 실현과 같은 다양한 유형의 관계를 나타낼 수 있다. 이러한 관계는 시스템의 구조와 동작을 이해하는 데 중요한 역할을 한다.
더 읽어볼만한 페이지
클래스 다이어그램 | |
---|---|
클래스 다이어그램 개요 | |
유형 | 구조적 다이어그램 |
UML 관계 | 연관 관계 집합 관계 합성 관계 일반화 관계 구체화 관계 의존 관계 |
사용 분야 | 정보 시스템 모델링 데이터베이스 모델링 소프트웨어 개발 |
클래스 다이어그램 상세 정보 | |
목적 | 시스템의 정적 구조를 시각적으로 표현 |
표현 요소 | 클래스 속성 메서드 관계 |
장점 | 시스템 구조의 이해 용이 개발 과정에서의 의사 소통 원활화 설계 오류의 조기 발견 가능 |
단점 | 복잡한 시스템의 경우 다이어그램이 복잡해질 수 있음 다이어그램 작성에 시간과 노력이 필요함 |
2. 클래스
소프트웨어 시스템에서 클래스는 클래스명이 기입된 사각형으로 표현한다. 클래스는 소프트웨어 요소뿐만 아니라 자동차 타이어, 화학 물질 종류, 요리 재료와 같이 도메인 등 다른 요소도 표현할 수 있다.
클래스명 아래에는 속성(프로퍼티)을 나타내는 구획을 둘 수 있다. 각 속성에는 최소한 이름을 기입해야 하며, 선택적으로 타입, 초기값, 기타 특성을 추가할 수 있다. 그 아래에는 클래스의 메서드를 나타내는 구획을 둘 수 있으며, 각 메서드에는 최소한 이름을 기입하고 선택적으로 인수나 반환값을 추가할 수 있다. 이 외에도 보존할 의무, 필요 조건, 제한 등 다른 구획을 정의할 수도 있다.
2. 1. 가시성 (Visibility)
클래스 멤버(속성 또는 메서드)의 가시성을 지정하려면 멤버 이름 앞에 다음 표기법을 사용해야 한다.[5]표기법 | 의미 |
---|---|
+ | Public (공개) |
- | Private (비공개) |
# | Protected (보호) |
~ | Package (패키지) |
속성이나 조작에 대한 가시성은 다음과 같다.
- "+" : '''public''' (공개)
- "#" : '''protected''' (보호)
- "-" : '''private''' (비공개)
- "~" : '''package''' (패키지 내에서 가시)
2. 2. 범위 (Scope)
UML은 멤버의 범위에 대해 '인스턴스'와 '클래스' 두 가지 유형을 지정한다. 클래스 이름은 인스턴스 이름(있는 경우), 콜론(':'), 실제 클래스 이름을 밑줄로 연결하여 표시한다.[1]- '''인스턴스 멤버'''는 특정 인스턴스에 적용되는 범위를 갖는다.
- 속성 값은 인스턴스 간에 다를 수 있다.
- 메서드 호출은 인스턴스의 상태에 영향을 미칠 수 있다(즉, 인스턴스의 속성을 변경).
- '''클래스 멤버'''는 많은 프로그래밍 언어에서 "정적"으로 일반적으로 인식된다. 범위의 끝은 클래스 자체이다.
- 속성 값은 모든 인스턴스에 대해 동일하다.
- 메서드 호출은 분류자의 상태에 영향을 미치지 않는다.
멤버에 대한 분류자 범위를 나타내려면 해당 이름을 밑줄로 표시해야 한다. 그렇지 않으면 기본적으로 인스턴스 범위가 가정된다.
3. 관계
관계는 클래스 다이어그램과 객체 다이어그램에서 발견되는 특정 유형의 논리적 연결을 포괄하는 일반적인 용어이다. UML은 다양한 관계를 정의한다.
3. 1. 인스턴스 수준 관계
객체 다이어그램에서 객체는 프로그래밍 언어의 객체뿐만 아니라 다양한 대상을 포함하며, 이들 간의 기본적인 관계는 '''링크'''로 표현된다. 링크는 객체를 나타내는 직사각형을 실선으로 연결하여 나타낸다.두 개 이상의 클래스에서 각 인스턴스 사이에 링크가 존재할 수 있는 경우, 이들 클래스 간에는 '''연관 관계'''가 있다고 한다. 연관 관계는 클래스를 나타내는 직사각형을 실선으로 연결하여 표현한다. 연관 관계를 나타내는 선의 끝에는 롤명을 표기하여 연관 대상의 역할을 나타낼 수 있다.
유도 가능성은 연관 관계의 선을 화살표(열린 화살표)로 표시하여 나타낼 수 있다.
3. 1. 1. 연관 관계 (Association)
300px'''연관 관계'''는 구조적 연결의 집합을 나타낸다. 이진 연관 관계는 두 클래스 간의 실선으로 표현된다. 자기 반사 연관 관계는 클래스와 자기 자신 사이의 이진 연관 관계이다. 셋 이상의 클래스 간의 연관 관계는 각 연관된 클래스에 실선으로 연결된 다이아몬드로 표현된다. 세 클래스 간의 연관 관계는 삼항 연관 관계이다. 더 많은 클래스 간의 연관 관계는 n-ary 연관 관계라고 한다.[8]
연관 관계는 이름을 가질 수 있으며, 연관 관계의 끝은 역할 이름, 집합 표시기, 다중성, 가시성, 탐색 가능성 및 기타 속성으로 장식될 수 있다. 예를 들어 점 표기법을 사용하면 연관 관계의 한쪽에 작은 점을 사용하여 연관 관계 끝이 반대쪽에 속함을 나타낼 수 있다.[8]
연관 관계에는 단순 연관 관계, 공유 집합, 복합 집합(구성)의 세 가지 유형이 있다. 연관 관계는 하나 이상의 방향으로 탐색 가능할 수 있다. 탐색 가능성은 명시적으로 지정할 필요가 없다. 클래스 측면에 열린 머리 화살표는 런타임에 반대쪽에서 해당 클래스에 효율적으로 도달할 수 있음을 문서화한다. 단방향 탐색은 도달할 수 없는 클래스 측면의 연관 관계 선에 작은 십자가로 표시된다. 예를 들어, 항공편 클래스는 쌍방향으로 비행기 클래스와 연관된다.
''링크''는 기본적인 객체 간의 관계이다. 객체 다이어그램에서는, 객체를 나타내는 직사각형을 실선으로 연결하여 링크를 나타낸다. 여기서 말하는 객체는 프로그래밍 언어에서의 객체에 한정되지 않는다.
두 개(이상)의 클래스의 각각의 인스턴스 사이에 링크가 있을 수 있는 경우, 이 클래스에 ''연관'' (association)이 있다고 한다. 두 클래스에 연관이 있다는 것은, 클래스를 나타내는 직사각형을 실선으로 연결함으로써 나타낸다. 세 개 이상의 연관을 나타내는 표기법도 있다. 연관을 나타내는 선의 끝에, 롤명이라고 불리는, 연관 대상의 역할을 나타내는 이름을 표기할 수 있다.
연관의 선을 화살표(열린 화살표)로 함으로써, 유도 가능성 (navigability)을 표현할 수 있다.
3. 1. 2. 집합 관계 (Aggregation)
'''집합'''(Aggregation)은 "소유" 연관 관계의 변형이며, 집합은 연관 관계보다 더 구체적이다. 이는 부분-전체 또는 부분 관계를 나타내는 연관 관계이다. 그림과 같이 교수는 가르칠 '수업'을 '갖고' 있다. 연관 관계의 한 유형인 집합은 이름을 지정할 수 있으며 연관 관계와 동일한 장식을 가질 수 있다. 그러나 집합은 두 개 이상의 클래스를 포함할 수 없으며, 이진 연관 관계여야 한다. 또한 구현 과정에서 집합과 연관 관계 사이에는 거의 차이가 없으며, 다이어그램은 집합 관계를 완전히 생략할 수도 있다.[9]
집합은 한 클래스가 다른 클래스의 컬렉션 또는 컨테이너일 때 발생할 수 있지만, 포함된 클래스가 컨테이너에 대한 강력한 ''수명 주기 종속성''을 갖지 않는 경우를 말한다. 즉, 컨테이너가 파괴되어도 컨테이너의 내용은 여전히 존재한다.
UML에서 이는 포함하는 클래스에 ''비어 있는'' 마름모꼴 도형으로 표시되며, 이를 포함된 클래스에 연결하는 단일 선이 있다. 집합은 많은 연산에서 단위로 취급되는 확장된 객체이지만, 물리적으로는 여러 작은 객체로 구성된다.
집합은 "has-a" 관계를 나타낸다. 인스턴스 간의 링크로는, "부분"에 해당하는 객체와 "전체"에 해당하는 객체의 결합이다. "부분" 측 인스턴스가 여러 "전체" 인스턴스에 공유되는 경우, 후술할 합성에는 해당하지 않으며, "집합"으로 분류된다. UML 규격서에서는 shared aggregation이라고도 표기된다.
"전체" 인스턴스가 파기되어도, "부분" 인스턴스가 파기될 필요는 없다. 그림에서는 클래스를 잇는 관련의 선을 그리고, "전체" 측 단에 속이 빈 마름모를 붙이는 것으로 표현한다. 전체-부분 관계의 예시로, "차와 엔진"의 관계를 들 수 있다. 이것은 집합 또는 합성으로 모델링될 수 있다.
3. 1. 3. 합성 관계 (Composition)
합성 집합 관계(통상적으로 합성이라고 함)는 집합체가 집합하는 요소의 수명 주기를 제어하는 더 강력한 형태의 집합이다.[1] 그래픽 표현은 포함된 클래스를 포함하는 클래스(들)에 연결하는 선의 포함하는 클래스 끝에 있는 ''채워진'' 다이아몬드 모양이다.[1]
''컴포지션''은 집약과 마찬가지로 관계의 일종이며, "has-a" 관계를 나타내지만, 집약보다 결합이 더 강하다.[1] 컴포지션은 "집약"보다 제약이 강하며, "부분" 측 인스턴스가 공유되지 않는다.[1] 즉, "부분" 인스턴스에 연결된 "전체" 인스턴스는 동시에 많아도 1개이다.[1] 두 인스턴스의 라이프 사이클에 강한 관계가 있으며, "전체" 인스턴스가 파기될 때 "부분" 인스턴스도 모두 파기되는 것이 보통이다(필수는 아님).[1]
표기는 "집약"과 유사하지만, "전체" 측 끝에 붙는 마름모를 검은색으로 칠한다.[1] 컴포지션에서는, 앞서 언급한 제약(공유 불가)에 의해, 전체 측 인스턴스의 다중성은 0..1 또는 1이 된다.[1]
3. 1. 4. 의존 관계 (Dependency)
의존 관계는 한 요소(서버 또는 대상)의 정의가 변경될 경우 다른 요소(클라이언트 또는 소스)에도 변경을 일으킬 수 있는, 종속 모델 요소와 독립 모델 요소 사이의 의미적 연결 관계이다.[7] 이 연관 관계는 단방향이다. 의존 관계는 클라이언트에서 공급자로 향하는 열린 화살표가 있는 점선으로 표시된다.의존 관계는 한 클래스가 다른 클래스를 특정 시점에 사용하기 때문에 다른 클래스에 의존한다는 것을 나타내는 약한 형태의 결합일 수 있다. 독립적인 클래스가 의존적인 클래스의 메서드의 매개변수나 지역 변수인 경우 한 클래스는 다른 클래스에 의존한다. 때때로 두 클래스 간의 관계는 매우 약하며, 멤버 변수로 전혀 구현되지 않고, 멤버 함수 인수로 구현될 수 있다.
모델 요소 간에 한쪽을 변경하면 다른 쪽에 변경이 발생하는 의존 관계가 존재한다. "의존 관계"에는 몇 가지 명명된 종류가 있으며, 인스턴스 간, 클래스 간, 인스턴스-클래스 사이에 있을 수 있다.
다이어그램에서는 의존하는 쪽에서 의존되는 쪽으로 향하는 점선 화살표로 표현한다. 점선 위에 스테레오타입이라고 불리는 텍스트를 겹따옴표 (« »)로 묶어 의존 관계의 종류를 표기할 수 있다.
3. 2. 클래스 수준 관계
클래스 간의 관계는 다음과 같다.- 일반화/상속 (Generalization/Inheritance): 한 클래스(하위 클래스)가 다른 클래스(상위 클래스)의 특수한 형태임을 나타낸다. (상속 또는 ''"~이다"'' 관계라고도 한다.)
- 실현/구현 (Realization/Implementation): 한 모델 요소(클라이언트)가 다른 모델 요소(공급자)의 동작을 실현(구현 또는 실행)하는 관계이다.
3. 2. 1. 일반화/상속 (Generalization/Inheritance)
일반화 관계는 흔히 상속 또는 ''"~이다"'' 관계라고도 하며, 한 클래스(하위 클래스)가 다른 클래스(상위 클래스, ''상위 형식'', ''기본 클래스'')의 특수한 형태라는 개념을 담고 있다. 이 관계가 성립하는 경우, 상위 클래스는 하위 클래스의 일반화로 간주된다. 이러한 형태의 일반화 트리 예시는 생물 분류에서 찾을 수 있는데, 예를 들어 인간은 유인원의 하위 클래스이며, 유인원은 포유류의 하위 클래스 등이다. 이 관계는 "A는 B이다"라는 구절로 가장 쉽게 이해할 수 있다(인간은 포유류이고, 포유류는 동물이다).
일반화의 UML 그래픽 표현은 하나 이상의 하위 유형과 연결되는 선(또는 선 트리)의 상위 클래스 끝에 있는 빈 삼각형 모양이다.
실현의 기호 (하위 클래스) _______▻ (상위 클래스)
일반화의 쌍대는 ''특수화'' 관계이다. 일반적인 상위 클래스의 (특수화된) 하위 클래스에 대한 다른 용어로는 ''하위 유형'', ''파생 클래스'', ''파생 형식'', ''상속 클래스'', ''상속 형식'', ''자식'', ''자식 클래스''가 있다.
''범화(汎化)''는 한 쪽 클래스(''슈퍼클래스'')가 다른 쪽(''서브클래스'')에 비해 더 일반적이라고 여겨지는 것을 나타낸다. 이는 서브클래스의 인스턴스가 슈퍼클래스의 인스턴스이기도 함을 의미한다.[1] ''특화(特化)''는 범화의 반대이다. 즉, 서브타입은 슈퍼타입을 특화시킨 것이다.[1]
UML에서는 슈퍼클래스 쪽에 속이 빈 삼각형을 표기하여 표현한다.[1]
범화/특화 관계는 "''is-a''" 관계라고도 알려져 있다.[1]
상속은 특화와 관련이 있지만 동일하지는 않다.[1]
범화/특화 관계에서 슈퍼타입은 "''부모''", "''슈퍼클래스''", "''기저 클래스''", "''기저 타입''", "기본형"으로도 알려져 있다.[1] 서브타입은 "''자식''", "''서브클래스''", "''파생 클래스''", "''파생 타입''", "''파생형''"으로도 알려져 있다.[1]
범화/특화 관계의 예시로, "화물차는 자동차의 일종이다"라는 관계를 들 수 있다. 화물차는 자동차로부터 특화되었고, 자동차는 화물차로부터 범화되었다고 할 수 있다.[1]
3. 2. 2. 실현/구현 (Realization/Implementation)
UML 모델링에서 실현 관계는 한 모델 요소(클라이언트)가 다른 모델 요소(공급자)가 지정하는 동작을 실현(구현 또는 실행)하는, 두 모델 요소 간의 관계이다.실현은 클래스 또는 컴포넌트 다이어그램에서만 표시할 수 있다. 실현은 클라이언트 요소를 공급자 요소에 연결하는 클래스, 인터페이스, 컴포넌트 및 패키지 간의 관계이다. 클래스/컴포넌트와 인터페이스 간의 실현 관계는 클래스/컴포넌트가 인터페이스에서 제공하는 연산을 실현함을 보여준다.
구현은 한 클래스가 다른 클래스(인터페이스 또는 명세)의 구현임을 나타낸다. 예를 들어, 인터페이스와 그 구현 클래스의 관계가 있다.
UML에서는 인터페이스 쪽에 속이 빈 삼각형을, 구현 클래스 쪽에 점선을 사용하여 표현한다.
4. 다중성 (Multiplicity)
연관 관계는 (최소한) 두 개의 관련 클래스 중 하나가 다른 클래스를 참조한다는 것을 나타낸다. 이 관계는 일반적으로 "A는 B를 가진다"와 같이 설명된다 (어미 고양이는 새끼 고양이를 가지고, 새끼 고양이는 어미 고양이를 가진다).[1]
UML에서 연관 관계는 두 개의 연관된 클래스를 연결하는 선으로 표현된다. 선의 각 끝에는 선택적 표기법이 있다. 예를 들어, 화살표 머리를 사용하여 뾰족한 끝이 화살표 꼬리에서 보인다는 것을 나타낼 수 있다. 공의 배치를 통해 소유권을 나타낼 수 있고, 해당 끝 요소가 수행하는 역할을 역할의 이름을 제공하여 나타낼 수 있으며, 해당 엔티티의 인스턴스 ''다중성''(다른 쪽 끝의 관점에서 연관 관계에 참여하는 객체의 수 범위)를 나타낼 수 있다.[1]
표기 | 인스턴스 수 |
---|---|
0 | 인스턴스 없음 (드묾) |
0..1 | 인스턴스 없음 또는 하나의 인스턴스 |
1 | 정확히 하나의 인스턴스 |
1..1 | 정확히 하나의 인스턴스 |
0..* | 0개 이상의 인스턴스 |
* | 0개 이상의 인스턴스 |
1..* | 1개 이상의 인스턴스 |
UML에서는 해당 인스턴스에 대한 ''다중성''을 클래스 간의 양쪽에 기술할 수 있다. 다중성은 관련 관계에 참여하는 객체의 수를 나타낸다.[1]
참조
[1]
서적
Unified Modeling Language 2.5.1
https://www.omg.org/[...]
"[[Object Management Group]] Standards Development Organization (OMG SDO)"
2017-12
[2]
웹사이트
Database Modeling in UML
http://www.methodsan[...]
2011-09-08
[3]
간행물
Phase I: Mapping Legal Concepts to Technical Objects
https://link.springe[...]
Springer International Publishing
2023-01-07
[4]
문서
UML 2 Class Diagrams
http://www.agilemode[...]
2009
[5]
간행물
UML Reference Card, Version 2.1.2
http://www.holub.com[...]
Holub Associates
2011-03-12
[6]
웹사이트
UML derived property is property which value is produced or computed from other information, for example, by using other properties.
https://www.uml-diag[...]
2019-01-24
[7]
문서
UML Distilled: A Brief Guide to the Standard Object Modeling Language
2003
[8]
웹사이트
Getting it right on the dot
https://www.omg.org/[...]
"[[Object Management Group]]"
2023-11-26
[9]
웹사이트
UML Tutorial part 1: class diagrams
http://www.objectmen[...]
2015-07-18
[10]
웹사이트
Modelling and Simulation, p. 26
http://www2.warwick.[...]
2015-11-28
[11]
웹인용
Database Modeling in UML
http://www.methodsan[...]
2011-09-08
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com