UML(Unified Modeling Language)

DAEILLIM·2023년 11월 15일

uml

소프트웨어공학

목록 보기

1/1

UML의 개요

1. UML

UML(Unified Modeling Language)은 시스템 개발 과정 중 상호 간의 원활한 의사소통을 위한 표준화된 객체지향 모델링 언어이다.
Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합한 모델링 언어이다.
OMG(Object Management Group)에서 표준으로 지정되었다.
시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램 작성할 수 있다.

1.1 UML 도입 효과

개발 기획과 산출물에 대한 확인
프로그램 개발이라는 행위에 대해 전문가와 비전문가가 서로 대화할 수 있는 도구

1.2 UML의 특징 (가구명문)

가시화 언어
- 개념 모델 작성 시 오류가 적고 의사소통이 용이
구축 언어
- 다양한 프로그래밍 언어로 실행 시스템의 예측 가능
- UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능
명세화 언어
- 정확한 모델 제시, 완전한 모델 작성 가능
문서화 언어
- 시스템에 대한 평가 및 의사소통의 문서

1.3 UML 구성요소

사물 Things
관계 Relationships
다이어그램 Diagrams

2. 사물

사물(Things)은 모델을 구성하는 가장 중요한 기본 요소이다.
다이어그램 안에 관계가 형상될 수 있는 대상들을 뜻한다.
구조사물, 행동사물, 그룹사물, 주해사물이 있다.

사물	내용
구조 사물(Structual Things)	시스템의 개념적, 물리적 요소를 표현 클래스(Class), 유즈 케이스(Use Case), 컴포넌트(Component), 노드(Node) 등
행동 사물(Behavioral Things)	시간과 공간에 따른 요소들의 행위를 표현 상호작용, 상태 머신(State Machine) 등
그룹 사물(Grouping Things)	요소들을 그룹으로 묶어서 표현 패키지(Package)
주해 사물(Annotion things)	부가적인 설명이나 제약조건 등을 표현 노트(Note)

3. 관계

사물과 사물 사이의 연관성을 표현하는 것이다.
연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있다.

4. 연관 관계

연관 관계(Association)는 2개 이상 사물이 서로 관련된 관계이다.
사물 사이를 실선으로 연결하고 방향성은 화살표로 표현한다.
양방향 관계의 경우에는 화살표를 생략하고 실선으로만 연결한다.
참여하는 객체의 개수를 의미하는 다중도(연관에 참여하는 객체의 개수)를 선 위에 표기한다.

다중도	의미
1	1개의 객체가 연관되어 있다.
n	n개의 객체가 연관되어 있다.
0..1	연관된 객체가 없거나 1개만 존재한다.
0.. 또는	연관된 객체가 없거나 다수일 수 있다.
1..*	연관된 객체가 적어도 1개 이상이다.
n..*	연관된 객체가 적어도 n개 이상이다.
n..m	연관된 객체가 최소 n개에서 최대 m개이다.

4.1 연관 관계 예제 1

사람이 집을 소유하는 관계이다. 사람은 소유하고 있는 집에 대해 알고있지만, 집은 누구에 의해 소유되고 있는지 모른다는 의미이다.

연관 관계 예제 1 해설

'사람' 쪽에 다중도가 '1'이므로 집은 한 사람에 의해서만 소유될 수 있다.
'집' 쪽에 다중도가 '1'이므로 사람은 집을 하나만 소유할 수 있다.

4.2 연관 관계 예제 2

선생님은 학생을 가르치고 학생은 선생님으로부터 가르침을 받는 것과 같이 서로 관계가 있다.

연관 관계 예제 2 해설

'선생님' 쪽에 다중도가 '1..*'이므로 학생은 한 명 이상의 선생님으로 부터 가르침을 받는다.
'학생' 쪽에 다중도가 '1..*'이므로 선생님은 한 명 이상의 학생을 가르친다.

5. 집합 관계

집합 관계(Aggregation Relationship)는 한 사물이 다른 사물에 포함된 관계이다.
포함하는 쪽(전체)과 포함되는 쪽(부분)은 서로 독립적이다.
포함되는 쪽(부분)에서 포함하는 쪽(집합)으로 빈 마름모를 연결해 표현.

5.1 집합 관계 예제 1

프린터가 컴퓨터에 연결하여 사용할 수 있으며 다른 컴퓨터에 연결해서 사용할 수 있다.

6. 포함 관계

포함 관계(Composition Relationship)포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계이다.
집합 관계와 달리 서로 독립적이지 못한다.
포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채워진 마름모를 연결해 표현한다.

6.1 포함 관계 예제 1

문을 열 수 있는 키는 하나이며, 해당 키로 다른 문을 열 수 없다. 문이 없어지면 키도 더이상 필요하지 않다.

7. 일반화 관계

일반화 관계(Generalization Relationship)는 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계이다.
일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)이라고 한다.
하위에서 상위로 속이 빈 화살표를 연결하여 표현한다.

7.1 일반화 관계 예제 1

아메리카노와 에스프레소는 커피이다. 다시말하면, 커피에는 아메리카노와 에스프레소가 있다.

8. 의존 관계

의존 관계(Dependency Relationship)는 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계이다.
소유 관계는 아니지만, 변화가 있으면 다른 사물에도 영향을 미친다.
일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타난다.
영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다.

8.1 의존 관계 예제 1

등급이 높으면 할인율을 적용하고, 낮으면 적용하지 않음을 나타낸다.

9. 실체화 관계

실체화 관계(Realization Relationship)사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현한다.
사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다.

9.1 실체화 관계 예제 1

비행기는 날 수 있고 새도 날 수 있다. 그러므로 비행기와 새는 날 수 있다는 행위로 그룹화 할 수 있다.

10. 다이어그램

다이어그램 (Diagram)은 사물과 관계를 도형으로 표현한다.
가시화한 뷰를 제공함으로써 의사소통에 도움을 준다.
정적 모델링에서는 구조적 다이어그램을, 동적 모델링에서는 행위 다이어그램을 사용한다.

✅ 구조적 다이어그램 (Structural) - 정적 모델링

다이어그램	내용
클래스 다이어그램 Class Diagram	- 클래스와 클래스가 가지고 있는 속성, 클래스 사이의 관계를 표현함 - 시스템 구조를 파악하고 문제점 도출 가능
객체 다이어그램 Object Diagram	- 클래스에 속한 사물들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 - 럼바우 객체지향 분석 기법에서 객체 모델링에 활용 됨
컴포넌트 다이어그램 Component Diagram	- 실제 구현 모델인 컴포넌트 간의 관계, 인터페이스를 표현 - 구현 단계에서 사용
배치 다이어그램 Deployment Diagram	- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 - 노드와 의사소통(통신) 경로를 표현 - 구현 단계에서 사용
복합체 구조 다이어그램 Composite Structure Diagram	- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
패키지 다이어그램 Package Diagram	- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

✅ 행위 다이어그램 (Behavioral) - 동적 모델링

다이어그램	내용
유스케이스 다이어그램 Use Case Diagram	- 사용자의 요구 분석, 기능 모델링 작업에 사용 - 사용자와 사용 사례로 구성(여러 형태의 관계로 이루어짐)
순차 다이어그램 Sequence Diagram	- 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
커뮤니케이션 다이어그램 Communication Diagram	- 순차 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 뿐만 아니라 객체들 간의 연관까지 표현
상태 다이어그램 State Diagram	- 변화 혹은 상호작용에 따라 객체가 어떻게 변화하는지 표현 -럼바우 객체지향 분석 기법에서 동적 모델링에 활용
활동 다이어그램 Activity Diagram	- 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램 Interaction Overview Diagram	- 상호작용 다이어그램 간의 제어 흐름을 표현
타이밍 다이어그램 Timing Diagram	- 객체 상태 변화와 시간 제약을 명시적으로 표현

11. UML 확장 모델의 스테레오 타입

스트레오 타입(Stereotype)은 UML의 기본적 요소 이외에 새로운 요소를 만들어 내기 위한 확장 메커니즘이다.
형태는 기존의 UML의 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장한다.
UML의 스테레오 타입은 '<<>>'(길러멧; Guillemet) 기호를 사용하여 표현한다.

<<include>>
- 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
<<extend>>
- 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수도 있는 확장 단계
<<interface>>
- 모든 메소드가 추상 메소드이며, 바로 인스턴스를 만들 수 없는 클래스로 추상 메소드와 상수만으로 구성된 클래스
<<entity>>
- 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서
  기억 장치에 저장되어야 할 정보를 표현하는 클래스
<<boundary>>
- 시스템과 외부 액터와의 상호작용을 담당하는 클래스
<<control>>
- 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스
<<exception>>
- 예외를 정의하는 경우
<<constructor>>
- 생성자 역할을 수행하는 경우

12. 주요 UML 다이어그램

주요 UML 다이어그램으로 유스케이스 다이어그램, 클래스 다이어그램, 순차 다이어그램이 있다.

12.1 유스케이스 다이어그램

유스케이스 다이어그램(Use Case Diagram)은 개발된 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것이다.
유스케이스 다이어그램을 통해 시스템의 범위를 파악할 수 있다.

12.2 유스케이스 다이어그램의 구성요소

유스케이스 다이어그램의 구성요소는 시스템(System), 액터(Actor), 유스케이스(Usecase), 관계(Relation)로 구성되어 있다.

시스템(System) / 시스템 범위(System Scope)

시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템 범위를 표현한다.
사각형 안쪽 상단에 시스템 명칭을 기술한다.

액터(Actor)

시스템과 상호작용을 하는 모든 외부요소로, 사람이나 외부시스템을 의미한다.
외부요소 이므로 시스템 밖에 표현한다.
액터는 주액터와 부액터가 있다

주액터(Primary Actor)

시스템을 사용함으로써 이득을 얻는 대상으로 주로 사람이 해당하며 주로 왼쪽에 배치한다.

부액터(Secondary Actor)

주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로 조직이나 기관등이 될수 있다.
주로 오른쪽에 표기하며 시스템명을 사각형으로 묶은 후 상단에 <<Actor>>라고 표기한다.
부액터는 시스템 밖에 표시한다.

유스케이스(Use Case)

사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것이다.
타원으로 표현하며 타원 안쪽이나 아래쪽에 유스케이스 이름을 기술한다.
액터에 의해 수행되며, 액터가 관찰할 수 있는 결과를 산출한다.
부분적 수행은 허용되지 않으며 유스케이스는 분석, 설계, 테스트 등 개발 전 과정에서 이용될수 있다.

13. 관계(스트레오 타입)

유스케이스 다이어그램에서의 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있으며, 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있으며 의존관계는 포함(Include), 확장(Extend)로 나눠진다.

💡 포함 관계
두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우,
새롭게 분리된 유스케이스와 관계를 포함 관계라고 한다.
💡 확장 관계
유스케이스가 특정 조건에 부합되 기능이 확장 될 때 그 관계를 확장 관계라고 한다.

13.1 연관 관계

연관 관계(Association)는 유스케이스와 액터간의 상호작용이 있음을 표현한다. 유스케이스와 액터를 실선으로 연결한다.

위 그림은 "사용자"(액터)가 "글을 등록한다"(유스케이스)는 기능과 상호작용이 있다는 것을 나타낸다.

13.2 포함 관계

포함 관계(Include)는 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다.
포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용한다.
포함하는 유스케이스에서 포함되는 유스케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기한다.

위 그림은 "글을 등록한다" 기능을 동작하기 위해서 "로그인 한다" 기능이 반드시 동작되어야 한다는 것을 나타낸다.

13.3 확장 관계

확장 관계(Extend)는 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.
확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용한다.
확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기한다.

위 그림은 "글을 등록한다" 기능을 수행 할 때 "파일을 첨부한다" 기능을 선택적으로 수행 할 수 있다는 것을 나타낸다.

13.4 일반화 관계

일반화 관계(Generalization)는 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다.

구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다.

위 그림은 "글을 검색한다"를 "글쓴이로 검색한다"와 "날짜로 검색한다"로 좀더 구체화 한 것을 나타낸다.

14. 유스케이스 작성 순서

유스케이스 작성 순서로는 1. 액터 식별 2. 유스케이스 식별 3. 관계 정의 이다.

14.1 액터 식별

액터는 시스템에 관련이 있는 사용자의 역할과 외부 시스템으로 식별 할 수 있다.

액터를 식별하기 위한 질문?

누가 정보를 제공하고, 사용하고, 삭제하는가?
누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가?
누가 요구사항에 대해 관심을 가지고, 시스템이 만들어낸 결과에 관심이 있는가?
누가 시스템이 잘 운영될 수 있도록 유지보수 및 관리를 하는가?
개발될 시스템과 상호작용하는 하드웨어나 소프트웨어 시스템은 무엇인가?

14.2 유스케이스 식별

액터가 요구하는 서비스, 정보를 유스케이스로 식별 할 수 있고 액터가 시스템과 상호작용하는 행위를 유스케이스로도 나타낼 수 있다.

유스케이스를 식별하기 위한 질문?

액터가 원하는 시스템 제공 기능은 무엇인가?
액터는 시스템에 어떤 정보를 생성, 수정, 조회, 삭제하고 싶어 하는가?
모든 기능 요구사항들을 만족할 수 있도록 유스케이스가 모두 식별 되었는가?

14.3 관계 정의

액터간, 유스케이스간의 일반화, 연관관계를 정의하고 유스케이스간의 포함, 확장관계를 정의한다.

관계를 식별하기 위한 질문?

연관 관계: 액터와 유스케이스 간에 상호 작용이 존재하는가?
포함 관계: 유스케이스를 실행하기 위하여 반드시 실행되어야 하는 유스케이스가 존재하는가?
확장 관계: 유스케이스를 실행함으로써 선택적으로 실행되는 유스케이스가 존재하는가?
일반화 관계: 액터 또는 유스케이스가 구체화 된 다른 액터 또는 유스케이스를 가지고 있는가?

15. 클래스 다이어그램

클래스 다이어그램(Class Diagram)은 구조 다이어그램으로 클래스 내부 구성요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 및 전체를 구조화 합니다. 개발 하기 전, 클래스 다이어그램을 그리게 되면 시스템 내 클래스 간의 의존성 파악과 팀원들 간 의사소통이 편리합니다.

구조적 다이어그램
시스템 구성 요소를 문서화하는 데 사용
시스템 모델링 시 자주 사용

클래스 다이어그램 구성요소

1. 클래스(Class)

각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현함
일반적으로 3개의 구획(Compartment)으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기함
속성: 클래스의 상태나 정보 표현
오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수라고도 함

2. 제약조건

속성에 입력될 값에 대한 제약 조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음

3. 관계(Relationship)

클래스와 클래스 사이의 연관성을 표현
클래스 다이어그램을 표현하는 관계에는 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계가 있음

💡 접근제어자

public ➜ +

private ➜ -

protected ➜ #

package ➜ ~

16. 순차 다이어그램

순차(Sequence) 다이어그램은 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상화 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것이다.

시스템이나 객체들이 상호 작용 과정에서 주고받는 메시지를 표현한다.
각 동작에 참여하는 시스템이나 객체들의 수행기간을 확인하는 데 사용된다.
클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현한다.
주로 기능 모델링에서 작성한 유스케이스 명세서를 하나의 표현 범위로 하지만 하나의 클래스에 포함된 오퍼레이션을 하나의 범위로 표현하기도 한다.

순차 다이어그램 구성요소
1. 액터(Actor)
시스템으로부터 서비스를 요청하는 외부 요소(사람, 외부 시스템)

2. 객체(Object)
메시지를 주고받는 주체

3. 생명선(Lifeline)
객체 메모리에 존재하는 기간, 객체 아래쪽에 점선을 그어 표현

4. 실행 상자(Active Box)
객체가 메시지를 주고받으며 구동되고 있음을 표현

5. 메시지(Message)
객체가 상호 작용을 위해 주고받는 메시지

기호	의미	기능
실선 + 꽉찬 삼각형 ( ▶ )	동기	메시지를 보낸 후 결과가 반환될 때까지 기다린다.
실선 + 비어있는 삼각형( > )	비동기	메시지를 보낸 후 결과가 반환될 때까지 기다리지 않고 다른 작업을 수행한다.
점선 + 비어있는 삼각형( > )	생성	메시지를 받는 새로운 객체를 생성한다.
점선 + 꽉찬 삼각형 ( ▶ )	응답	동기 메시지에 대한 수행 결과이다.

6. 객체 소멸
라이프라인 상에서 객체 소멸 표시를 만나면 해당 객체는 더 이상 메모리에 존재 하지 않음을 의미한다. 객체 라이프라인 마지막에 X로 표현한다.

7. 프레임(Frame)
다이어그램의 전체 또는 일부를 묶어 표현한다. 전체, 복합적인 부분, 반복구조, 선택구조 등이 프레임안에 표현된다. 프레임의 왼쪽 위에 다이어그램의 종류와 제목을 표기한다.

DAEILLIM

필기하고, 타이핑하고, 말하면서 읽고, 코딩하고, 눈으로 읽고 오감으로 공부하기