UML이란?

• UML은 시스템 구축자가 표준화된, 이해하기 쉬운 방식으로 그들의 비전을 포착할 수 있도록 하는 시각적 모델링 언어입니다.
• 다른 사람과 비전을 효과적으로 공유하고 소통할 수 있는 메커니즘을 제공합니다.
• 그래디 부치, 제임스 럼바우, 이바르 야콥슨에 의해 개발되었으며, OMG(Object Management Group)에 의해 모델링 표준으로 개발되었습니다.

UML 필요성

• 이전 모델링 방법론의 장점을 결합하고, 시스템 개발을 위한 통합된 표기법을 제공합니다.
• 개발자와 클라이언트 간의 소통을 용이하게 하며, 다양한 관점에서 시스템의 시각적 모델링을 제공합니다.

UML 구조

UML 구조는 시스템의 다양한 측면을 모델링하기 위해 다양한 뷰를 제공하는 아키텍처 프레임워크로 구성됩니다. 필리프 크루텐(Phillippe Kruchten)에 의해 제안된 이 구조는 다섯 가지 카테고리로 나뉩니다.

이러한 다양한 뷰는 시스템의 다양한 측면을 상세하게 분석하고 설계하는 데 도움을 줍니다. 각 뷰는 서로 다른 관점에서 시스템을 바라보며, 전체적인 시스템 설계와 구현을 위한 포괄적인 이해를 제공합니다.

1. 논리적 뷰(Logical View):
   • 시스템의 기능적 요구 사항을 충족하기 위한 주요 클래스와 패키지를 보여줍니다.
   • 시스템의 핵심 기능을 중심으로 구조화되며, 이 뷰는 시스템이 “무엇을 해야 하는가”에 초점을 맞춥니다.
2. 배치 뷰(Deployment View):
   • 시스템의 물리적 구성요소를 보여주며, 소프트웨어가 실행되는 하드웨어의 구성을 포함합니다.
   • 이 뷰는 시스템의 물리적 리소스와 네트워크 인프라 등의 관계를 설명합니다.
3. 구현 뷰(Implementation View):
   • 시스템의 소프트웨어 모듈과 그 관계를 나타냅니다.
   • 이 뷰는 시스템의 실제 구현을 다루며, 모듈과 컴포넌트의 구성을 중심으로 설계됩니다.
4. 프로세스 뷰(Process View):
   • 시스템의 동적인 측면을 보여주며, 프로세스, 스레드 및 기타 동적 요소를 포함합니다.
   • 시스템의 동작 흐름과 성능 문제, 동시성 및 동기화 요소 등을 다룹니다.
5. 사용 사례 뷰(Use Case View):
   • 시스템과 사용자(액터) 간의 상호작용을 중심으로 구성됩니다.
   • 사용자가 시스템을 통해 달성하고자 하는 목표를 중심으로 시나리오가 구성되며, 시스템의 외부 인터페이스를 설명합니다.

UML 다이어그램 종류

• 클래스 다이어그램: 클래스들 간의 관계와 각 클래스의 내부 구조를 보여줍니다.
• 객체 다이어그램: 클래스의 인스턴스와 이들 간의 관계를 구체적으로 표현합니다.
• 사용 사례 다이어그램: 시스템이 제공해야 할 기능과 사용자(액터)와의 상호작용을 설명합니다.
• 시퀀스 다이어그램: 객체 간의 상호 작용과 시간에 따른 이들의 행동을 순서대로 보여줍니다.
• 상태 다이어그램: 객체의 상태 변화와 그에 따른 행동을 보여줍니다.
• 활동 다이어그램: 프로세스나 작업 흐름의 동작을 순서대로 나열하여 표현합니다.
• 구성요소 다이어그램: 시스템을 구성하는 소프트웨어 컴포넌트와 그 관계를 보여줍니다.
• 배치 다이어그램: 소프트웨어 컴포넌트가 배치될 물리적 환경과 그 관계를 나타냅니다.

클래스 다이어그램

클래스 표시 (Visualizing a class)

UML에서 클래스의 구조와 행동을 명확하게 표현하기 위해 사용

1. UML 클래스 (UML Class):
   • 클래스는 속성(Attributes)과 연산(Operations)을 포함하는 기본적인 구성 요소입니다.
   • 클래스는 하나 이상의 객체를 생성하기 위한 템플릿으로 사용됩니다.
   • Pathname은 ::로 표시합니다.
2. 속성 (Attributes):
   • 클래스의 특성을 나타내며, 클래스에 속한 객체들이 가질 수 있는 데이터 필드를 정의합니다.
   • 각 객체는 특정 속성에 대해 구체적인 값을 가집니다.
   • 속성의 유형(Type), 초기 값(Initial Value) 등 추가 정보를 포함할 수 있습니다.
   • + 속성이름: 타입 = 초기 값
3. 연산 (Operations):
   • 클래스가 수행할 수 있는 행동 또는 기능을 정의합니다.
   • 연산은 클래스 외부의 요소(또는 다른 클래스)가 클래스에 요청할 수 있는 동작입니다.
   • 연산의 시그니처(Signature)는 연산에 대한 입력 파라미터와 반환 값의 타입 정보를 포함합니다.
4. 제약 조건 (Constraints):
   • 클래스가 따라야 할 규칙이나 조건을 명시합니다.
   • 제약 조건은 중괄호({}) 안에 자유 형식 텍스트로 표현되며, 클래스의 동작을 제한할 수 있습니다.
5. 노트 (Attached Notes):
   • 클래스 다이어그램에 추가적인 정보를 제공할 수 있는 요소입니다.
   • 클래스의 속성, 연산, 책임, 제약 조건 외에 추가적인 설명을 포함할 수 있습니다.

관계 (Relations)

시스템 내 객체들이 어떻게 서로 연관되어 있는지를 설명하는 중요한 부분입니다.

1. 연관 (Associations):
   • 두 클래스 간에 의미 있는 연결을 나타냅니다.
   • 연관은 일반적으로 클래스 다이어그램에서 두 객체 사이를 연결하는 선으로 표현됩니다.
   • 연관에는 방향성이 있을 수 있으며, 양방향이나 단방향일 수 있습니다.
   • UML에서 연관 관계의 제약조건은 연관된 클래스 사이의 상호 작용을 정의하고 제한하는 규칙이나 조건을 명시합니다.
     • {readOnly}, {readOnly} 등
2. 다중성 (Multiplicity):
   • 연관된 관계에서 한 클래스의 인스턴스가 다른 클래스의 몇 개의 인스턴스와 관계를 가지고 있는지를 나타냅니다.
   • 예를 들어, 한 교수는 여러 학생을 가르칠 수 있으며, 한 학생은 여러 과목을 수강할 수 있습니다.
3. 상속과 일반화 (Inheritance and Generalization):
   • 한 클래스가 다른 클래스로부터 속성과 연산을 상속받는 관계입니다.
   • 일반적으로 화살표가 하위 클래스(자식)에서 상위 클래스(부모)로 향하는 선으로 표현됩니다.
   • 상속은 객체 지향 프로그래밍의 핵심 원리 중 하나로, 코드 재사용성과 유지 보수성을 향상시킵니다.
   • 삼각형 화살표로 표현되어, 화살표의 끝(기점)이 하위 클래스를 가리키고, 화살표의 넓은 부분(머리)이 상위 클래스를 가리킵니다.
   • 추상 클래스는 인스턴스화될 수 없는 클래스로 정의
4. 의존성 (Dependencies):
   • 한 클래스가 다른 클래스의 메서드나 객체에 의존하는 관계를 나타냅니다.
   • 의존성은 일반적으로 점선 화살표로 표현되며, 한 클래스의 변경이 다른 클래스에 영향을 줄 수 있음을 의미합니다.

집합 (Aggregations)

UML에서 집합은 클래스 간의 특별한 관계 유형으로, 하나의 클래스(전체, whole)가 다른 클래스들(부분, part)을 포함하는 구조를 나타냅니다. 이 관계는 전체와 부분 간에 구조적인 관계를 표현하며, 부분 클래스의 객체들이 전체 클래스의 객체 없이도 독립적으로 존재할 수 있음을 나타냅니다. 집합 관계는 일반적으로 빈 다이아몬드로 전체 클래스의 측면에 표시되는 선으로 시각화됩니다.

집합 관계는 전체 객체가 생명 주기 동안 부분 객체를 관리하지만, 부분 객체가 전체 객체 없이도 존재할 수 있다는 점에서 합성(강한 집합 관계)과 구별됩니다. 예를 들어, 대학과 학과 간의 관계에서 대학(전체)은 여러 학과(부분)를 포함하지만, 학과는 대학 없이도 개념적으로 존재할 수 있습니다.

UML에서 집합 관계에 대한 제약조건은 집합 관계의 성격을 추가로 명시하는 규칙이나 조건을 뜻합니다. 예를 들어, 어떤 집합 관계에서 “or” 관계를 사용하여 가능한 부분 클래스 중 하나만 선택되어야 함을 명시할 수 있습니다.

복합체 (Composites)

UML에서 복합체는 집합 관계의 한 형태로, 전체와 부분의 관계가 더욱 강하게 연결되어 있는 구조를 나타냅니다. 복합체에서는 부분 객체가 전체 객체에 소속되며, 전체 객체의 생명 주기에 종속됩니다. 즉, 전체 객체가 소멸하면 그 구성 요소인 부분 객체들도 함께 소멸합니다.

복합체 관계는 UML 다이어그램에서 검은색 다이아몬드로 표시되는 선으로 시각화됩니다. 이 검은 다이아몬드는 전체 클래스 쪽에 위치하며, 부분 클래스들은 이 다이아몬드에 연결된 선을 통해 표현됩니다.

예를 들어, 커피 테이블이 전체 객체일 때, 그 구성 요소로서 테이블 상판과 다리들은 복합체 관계를 형성합니다. 테이블이 파괴되면 상판과 다리도 함께 파괴될 것입니다. 이는 각 구성 요소가 전체 객체에 완전히 의존적임을 나타내며, 복합체 관계의 특징을 잘 보여줍니다.

인터페이스와 실현 (Interfaces and Realizations)

UML에서 인터페이스는 클래스가 외부로 제공하는 메소드의 집합을 정의합니다.

실현 (Realization) 은 클래스가 하나 이상의 인터페이스를 구현하는 관계를 나타냅니다. 이 관계는 클래스가 인터페이스에서 정의된 모든 메소드를 구현해야 함을 의미하며, UML 다이어그램에서 점선 화살표로 표현됩니다.

포트는 인터페이스와 클래스 간의 연결점으로서, 클래스가 외부 환경과 상호작용하는 지점을 나타냅니다. 예를 들어, 컴퓨터에 있는 마우스 포트는 마우스 인터페이스와의 연결 지점으로 작용합니다.

Visibility

가시성은 클래스의 속성이나 연산이 다른 클래스에서 어떻게 접근 가능한지를 정의합니다. 가시성은 클래스의 멤버가 다른 클래스와 어떻게 상호작용할 수 있는지를 명시하며, 정보 은닉과 캡슐화의 원칙을 지원합니다.

1. Public (+):
   • 공개 가시성은 클래스 외부의 모든 클래스가 해당 멤버에 접근할 수 있음을 의미합니다.
   • 이는 가장 덜 제한적인 가시성으로, 일반적으로 API와 같은 인터페이스에서 사용됩니다.
2. Protected (#):
   • 보호된 가시성은 멤버 클래스와 그 서브클래스에서만 접근할 수 있음을 나타냅니다.
   • 이는 상속받은 클래스가 부모 클래스의 멤버에 접근할 수 있도록 하면서, 다른 외부 클래스의 접근은 제한합니다.
3. Private (-):
   • 비공개 가시성은 해당 멤버가 선언된 클래스 내부에서만 접근 가능함을 의미합니다.
   • 이는 정보 은닉의 가장 강력한 형태로, 클래스의 내부 구현을 외부로부터 완벽하게 숨기고자 할 때 사용됩니다.
4. Package:
   • 패키지 가시성(때로는 default 가시성이라고도 함)은 같은 패키지 내의 클래스들 사이에서만 멤버에 접근할 수 있게 합니다.
   • 이는 패키지 내부의 클래스들이 서로 긴밀하게 작동하도록 하면서, 패키지 외부의 클래스들은 접근을 제한합니다.
5. 인스턴스 범위 (Instance Scope):
   • 인스턴스 범위에서는 속성이나 연산이 각 객체 인스턴스에 개별적으로 존재합니다.
   • 이는 각 객체가 해당 속성이나 연산의 자체 복사본을 가지고 있음을 의미하며, 객체 간에 데이터가 공유되지 않습니다.
   • 예를 들어, 각 사람 객체는 고유의 이름과 나이 속성 값을 가질 수 있습니다.
6. 분류자 범위 (Classifier Scope):
   • 분류자 범위에서는 속성이나 연산이 클래스 자체와 관련되어 있으며, 모든 인스턴스에서 공유됩니다.
   • 이는 주로 정적 속성이나 메서드를 정의할 때 사용되며, 모든 객체 인스턴스에 걸쳐 단 하나의 값을 공유합니다.
   • 예를 들어, 학생 클래스의 학생 수 속성은 모든 학생 객체에 걸쳐 공유되며, 모든 학생이 접근할 수 있습니다.

퀴즈

다음 예제 중 어떤 것이 연관 관계이고 어떤 것이 집합 관계인가?

1. 거리의 집들 (연관 관계)
2. 책의 페이지들 (집합 관계)
3. 교향곡의 음표들 (집합 관계)
4. 홈 엔터테인먼트 시스템의 구성 요소들 (집합 관계 또는 연관 관계)

다음 용어 중 다른 객체로 구성된 객체를 가장 잘 설명하는 것은 무엇인가? 하나만 선택하시오.

• a. 일반화 (Generalization)
• b. 상속 (Inheritance)
• c. 연관 (Association)
• d. 집합 (Aggregation)
• e. 특수화 (Specialization)

사용 사례 다이어그램 (Use Case Diagram)

사용 사례 다이어그램은 시스템의 기능과 시스템 외부의 액터(사용자 또는 외부 시스템)와의 상호 작용을 나타내는 데 사용됩니다. 이 다이어그램은 시스템이 제공해야 하는 서비스, 기능, 또는 행동을 시각적으로 표현하며, 주로 시스템의 요구 사항 수집 및 분석 단계에서 사용됩니다.

목적

• 시스템의 기능적 요구 사항 정의: 시스템이 사용자에게 제공해야 하는 서비스나 기능을 명확히 정의합니다.
• 사용자 관점에서의 시스템 이해 촉진: 비기술적인 이해 관계자들도 시스템의 기능을 쉽게 이해할 수 있게 돕습니다.
• 개발 과정에서의 커뮤니케이션 도구로 활용: 개발자와 비개발자 간의 소통을 원활하게 하며, 프로젝트 요구 사항에 대한 공통의 이해를 구축합니다.

구성요소

1. 액터 (Actor):
   • 시스템과 상호 작용하는 개체를 나타냅니다. 액터는 사람, 다른 시스템, 하드웨어 장치 등일 수 있습니다.
   • 액터는 사용 사례 다이어그램에서 보통 스틱맨 아이콘으로 표현됩니다.
2. 사용 사례 (Use Case):
   • 시스템이 수행해야 하는 개별적인 기능이나 목표를 나타냅니다.
   • 사용 사례는 타원으로 표현되며, 내부에 해당 기능을 설명하는 짧은 문장이나 구문이 포함됩니다.
3. 관계 (Relationships):
   • 연관 관계 (Association): 액터가 사용 사례에 참여하는 것을 나타냅니다.
   • 포함 관계 (Include): 하나의 사용 사례가 다른 사용 사례를 필수적으로 포함할 때 사용합니다.
   • 확장 관계 (Extend): 하나의 사용 사례가 조건에 따라 다른 사용 사례를 확장할 수 있을 때 사용합니다.
   • 일반화 관계 (Generalization): 하나의 액터 또는 사용 사례가 다른 액터 또는 사용 사례의 일반적인 형태를 상속받을 때 사용합니다.

State Diagram

State Diagram이란?

• 상태 다이어그램은 시스템 내 객체의 상태 변화와 해당 상태 간의 전환을 시각적으로 나타냅니다.
• 객체가 가질 수 있는 상태와 그 상태를 변경하는 시작점 및 종료점을 보여줍니다.
• 이러한 다이어그램은 분석가, 디자이너, 개발자가 시스템 내 객체의 행동을 이해하는 데 도움을 줍니다.
• 클래스 다이어그램과 객체 다이어그램은 시스템의 정적인 측면만을 보여주는 반면, 상태 다이어그램은 객체가 수행해야 할 동작을 명확히 할 수 있도록 합니다.

이벤트, 행동, 가드 조건

• 각 상태에는 ‘진입(Entry)’, ‘퇴장(Exit)’, ‘수행(Do)’ 등의 활동 카테고리가 있습니다.
• 진입은 상태에 들어갈 때 발생하는 일, 퇴장은 상태를 떠날 때 발생하는 일, 수행은 상태에 있을 동안 발생하는 일을 의미합니다.
• 이벤트(Event)
  • 정의: 이벤트는 상태 변화를 유발하는 외부 또는 내부의 사건입니다. 이벤트는 시스템이나 사용자의 행동에 의해 발생할 수 있으며, 특정 상태에서 다음 상태로의 전환을 촉발합니다.
• 행동(Action)
  • 정의: 행동은 상태 전환 시 또는 상태에 들어가거나 나올 때 실행되는 동작이나 작업입니다. 이는 상태 변화와 함께 자동으로 수행되어야 하는 기능적 요소를 포함합니다.
• 가드 조건(Guard Condition)
  • 정의: 가드 조건은 특정 상태 전환을 조건부로 실행하기 위한 논리적 조건입니다. 이 조건이 참(True)일 때만 해당 상태 전환을 허용합니다.

하위 상태, 히스토리 상태 및 연결 지점 모델링 방법

1. 하위 상태(Substates)
   • 하위 상태는 더 큰 상태 내부에 존재하는 작은 상태들입니다. 이것은 상태를 더 세부적으로 분할하여 각각의 부분에 대해 더 구체적인 동작을 정의할 수 있게 해줍니다.
   • Sequential Substates:
     • awaiting user input, registering user input, visualizing user input
     • Concurrent Substates
     • Watching system clock, updating display
   • 예시: 온라인 쇼핑 상태를 모델링할 때, “주문 처리 중”이라는 큰 상태 안에 “주문 확인”, “결제 처리”, “발송 준비”와 같은 하위 상태들을 둘 수 있습니다. 이렇게 하면 각 단계에서 필요한 동작과 전환을 보다 명확하게 할 수 있습니다.
2. 히스토리 상태(History States)
   • 히스토리 상태는 객체가 복합 상태(여러 하위 상태를 포함하는 상태)를 떠났다가 다시 돌아올 때, 이전에 활성화되었던 하위 상태를 기억하게 해줍니다. 이 기능은 사용자가 예전 상태로 돌아갈 수 있도록 하여, 사용자 경험을 개선하는 데 유용합니다.
   • Deep history states
     • When a history state remembers substates at all levels of nesting
     • Shallow history states
     • When a history state remembers only the highest nested substate
   • 예시: 문서 편집기에서 “편집 모드” 상태가 “문자 입력”, “이미지 삽입”, “포맷 변경” 등의 하위 상태를 가질 때, 사용자가 다른 모드로 전환했다가 다시 편집 모드로 돌아올 경우, 마지막으로 사용했던 하위 상태(예: “이미지 삽입”)로 자동으로 돌아갑니다.
3. 연결 지점(Connection Points)
   • 연결 지점은 상태들 간의 전환을 보다 유연하게 연결해주는 역할을 합니다. 특히 복합 상태의 내부와 외부를 연결할 때 사용됩니다.
   • 예시: “주문 처리 중” 상태가 외부의 “주문 취소” 상태와 내부의 “결제 처리” 상태 사이에 연결 지점을 두어, 어느 단계에서든 주문을 취소할 수 있는 경로를 제공합니다.

Sequence Diagram

시스템 내에서 객체들 간의 상호작용과 이들이 주고받는 메시지의 순서를 시각적으로 표현한 다이어그램입니다.

구성요소

1. 객체(Object):
   • 시퀀스 다이어그램의 가장 기본적인 요소로, 상호작용하는 각 객체를 나타냅니다.
   • 객체는 다이어그램 상단에 사각형으로 표시되며, 객체의 이름이 밑줄과 함께 표시됩니다.
2. 생명선(Lifeline):
   • 각 객체의 존재를 나타내는 세로선으로, 객체가 상호작용을 시작하고 끝내는 전체 시간을 나타냅니다.
   • 생명선은 객체 아래로 길게 그어지며, 시간이 지남에 따라 아래로 내려갑니다.
3. 메시지(Message):
   • 객체들 간에 주고받는 정보를 표현합니다.
   • 메시지는 화살표로 나타내며, 보통 호출(Call)과 반환(Return) 메시지로 구분됩니다.
   • 동기 메시지(Synchronous Message)는 발신자가 수신자의 응답을 기다릴 때 사용하고, 비동기 메시지(Asynchronous Message)는 발신자가 응답을 기다리지 않을 때 사용합니다.
4. 프레임(Frame):
   • 다이어그램을 더 큰 부분으로 나누거나 특정 시나리오를 그룹화하는 데 사용됩니다.
5. Alt (Alternative Fragment)
   • “alt”는 Alternative Fragment의 약자로, 조건부 로직을 표현하는 데 사용됩니다. 이 프레임은 여러 분기 중 하나만 선택적으로 실행되는 시나리오를 나타낼 때 쓰입니다.
   • “alt” 프레임은 하나의 조건이 참일 때 실행되는 경로와 그렇지 않을 때 실행되는 경로를 구분 짓는 데 유용합니다.
6. Par (Parallel Fragment)
   • “par”는 Parallel Fragment의 약자로, 병렬로 실행되어야 하는 여러 상호작용을 나타내는 데 사용됩니다. 이는 동시에 발생해야 하는 작업들을 표현할 때 유용하며, 서로 간의 직접적인 시퀀스 의존성 없이 동시에 발생하는 상호작용들을 나타냅니다.

Activity Diagram

Activity Diagram이란?

소프트웨어나 시스템의 행동 또는 비즈니스 프로세스의 흐름을 시각적으로 표현합니다. 이 다이어그램은 프로세스나 시스템의 흐름을 단계별로 보여주어, 각 단계에서 수행되는 활동들과 그 순서를 명확하게 이해할 수 있게 도와줍니다.

구성요소

1. 초기점과 종결점(Start and End Points):
   • 프로세스의 시작과 끝을 나타내는 특수한 기호입니다.
   • 초기점은 작은 검은 원으로, 종결점은 더 큰 원 안에 작은 원으로 표시됩니다.
2. 활동(Activities):
   • 시스템 또는 프로세스에서 수행되는 작업을 나타냅니다.
   • 활동은 보통 둥근 모서리의 직사각형으로 표시되며, 각 활동은 프로세스의 한 단계를 대표합니다.
3. 전이(Transitions):
   • 활동과 활동 사이를 연결하는 화살표로, 흐름의 방향을 나타냅니다.
   • 이 화살표는 프로세스가 다음 단계로 어떻게 진행되는지 보여줍니다.
4. 분기(Decision Points):
   • 조건에 따라 흐름이 갈라지는 지점을 나타내며, 보통 다이아몬드 모양으로 표시됩니다.
   • 각 분기점에서는 조건부 로직에 따라 다른 활동으로 흐름이 이동합니다.
5. 병렬 처리 (Concurrent Paths) (Fork and Join):
   • 프로세스가 동시에 여러 경로로 분기되거나 병렬 경로가 다시 하나로 합쳐지는 지점을 나타냅니다.
   • 포크는 흐름을 여러 병렬 경로로 나누고, 조인은 그 경로들을 다시 합칩니다.
6. 신호(Signals):
   • 프로세스 실행 중 발생하는 이벤트를 특정 활동이나 전이를 트리거하는 데 사용됩니다.
   • 신호는 주로 프로세스의 한 부분에서 다른 부분으로 정보를 전달하는 역할을 하며, 받는 신호를 통해 새로운 행동이 시작될 수 있습니다.
   • 신호는 일반적으로 화살표나 특수 기호로 표현되어, 특정 조건이 만족될 때 다음 행동으로 진행하도록 합니다.
7. 수영장(Swimlanes):
   • 프로세스를 다루는 서로 다른 역할이나 책임을 가진 단위를 구분하기 위해 사용됩니다.
   • 각 수영장은 특정 역할이나 개체가 수행하는 활동들을 그룹화하여 표현합니다.

Components Diagram

Component Diagram이란?

컴포넌트 다이어그램(Component Diagram)은 UML에서 사용하는 구조 다이어그램 중 하나로, 소프트웨어 시스템 내의 컴포넌트들의 구성과 그들 간의 관계를 시각적으로 표현합니다.

컴포넌트는 시스템의 물리적인 부분 또는 실행 가능한 부분으로, 재사용 가능하며, 다양한 시스템에서 독립적으로 기능할 수 있습니다. 이 다이어그램은 시스템을 구성하는 각 컴포넌트의 역할과 서로간의 인터페이스 연결을 명확하게 나타내어 시스템의 구조적 이해를 돕습니다.

구성요소

1. 컴포넌트(Component):
   • 소프트웨어의 물리적인 부품을 나타냅니다. 각 컴포넌트는 재사용 가능한 모듈로서 특정 기능을 수행하며, 하나 이상의 인터페이스를 통해 다른 컴포넌트와 통신할 수 있습니다.
   • 컴포넌트는 직사각형으로 표시되며, 내부에 이름과 선택적으로 기능을 설명하는 텍스트가 포함될 수 있습니다.
2. 인터페이스(Interface):
   • 컴포넌트가 외부에 제공하는 서비스나 외부 컴포넌트로부터 받는 서비스의 명세를 나타냅니다.
   • 제공 인터페이스(Provided Interface)와 요구 인터페이스(Required Interface)로 구분되며, 각각 컴포넌트가 제공하는 기능과 필요로 하는 기능을 나타냅니다.
3. 종속성(Dependency):
   • 한 컴포넌트가 다른 컴포넌트의 서비스를 사용하는 관계를 나타냅니다. 이는 컴포넌트 간의 의존성을 보여주며, 시스템의 연결 구조를 이해하는 데 중요합니다.
4. 연결(Ports):
   • 컴포넌트와 외부 세계 사이의 상호 작용 점을 나타냅니다. 포트는 인터페이스를 통해 컴포넌트가 서로 연결되는 지점을 말하며, 실제 통신이 이루어지는 경로입니다.
5. 연관 관계(Association):
   • 두 컴포넌트가 서로 어떻게 연결되어 있는지를 나타내는 관계입니다. 이는 일반적으로 두 컴포넌트 사이의 데이터 흐름이나 제어 흐름을 설명합니다.

Deployment Diagram

Deployment Diagram이란?

배포 다이어그램(Deployment Diagram)은 UML에서 사용하는 구조 다이어그램의 한 형태로, 소프트웨어 시스템의 물리적인 구성요소(하드웨어)와 그 요소들 위에 배치되는 소프트웨어 아티팩트(실행 파일, 데이터베이스, 라이브러리 등)의 배치를 시각적으로 나타냅니다. 이 다이어그램은 소프트웨어의 물리적 배치와 시스템의 스케일링, 성능, 신뢰성과 같은 속성을 이해하는 데 도움을 줍니다.

구성요소

1. 노드(Node):
   • 물리적인 시스템 구성 요소를 나타내며, 서버, 컴퓨터, 또는 기타 장치 등이 이에 해당합니다.
   • 노드는 주로 큐브 모양의 아이콘으로 표시되며, 각 노드는 하나 이상의 소프트웨어 컴포넌트를 호스팅할 수 있습니다.
2. 디바이스(Device):
   • 노드의 한 유형으로, 아티팩트를 실행하는 하드웨어 장치를 특정합니다.
   • 디바이스는 물리적 또는 가상의 하드웨어 구성 요소로, 서버나 라우터, 스위치 등과 같은 네트워크 장비를 포함할 수 있습니다.
3. 아티팩트(Artifact):
   • 실행 가능한 소프트웨어나 데이터를 나타내며, 실행 파일, 라이브러리, 데이터베이스 파일, 구성 파일 등이 포함됩니다.
   • 아티팩트는 특정 노드 위에 배치되어 해당 소프트웨어가 어떤 물리적 자원에서 실행되는지를 보여줍니다.
4. 배포 사양(Deployment Specification):
   • 아티팩트가 다른 아티팩트에 대해 제공하는 매개변수나 설정을 정의하는 아티팩트입니다.
   • 이는 예를 들어, 소프트웨어 구성을 위한 파일, 환경 변수 설정 등이 될 수 있으며, 소프트웨어가 어떻게 실행되어야 하는지에 대한 세부 정보를 제공합니다.
5. 통신 경로(Communication Path):
   • 노드 간의 데이터 전송 경로를 나타내며, 노드가 서로 어떻게 연결되어 있는지를 보여줍니다.
6. 종속성(Dependency):
   • 아티팩트 간 또는 아티팩트와 노드 간의 의존 관계를 나타내며, 특정 소프트웨어 컴포넌트가 다른 컴포넌트의 기능이나 데이터에 의존하는 관계를 설명합니다.