개요
오늘은 소프트웨어의 모델링(Modeling)에 사용하는 통합 모델링 언어(UML, Unified Modeling Language)와 다양한 다이어그램(Diagram)에 대해서 알아보도록 하겠습니다.
소프트웨에서 모델(Model)이란 요구사항을 이해하기 쉽도록 현실의 상황을 단순화하여 개념적으로 표현한 것입니다.
모델(Model)은 문제가 발생하는 상황에 대하여 원인을 진단하고, 이해도를 높여주어 해결 방안을 모색할 수 있도록 도움을 줍니다.
따라서, 소프트웨어를 개발하기 위해 요구사항을 분석할 때에 핵심이라고 할 수 있습니다.
모델은 개발 대상의 종류, 범위, 역할 등에 따라 고유한 도메인(Domain)으로 분류할 수 있는데,
이렇게 특정한 목적을 위해 설계된 모델이 고유한 분야를 가지면서 다른 모델과 관계(Relationship) 및 종속성(Dependency)을 나타낼 때, 이는 곧 엔티티(Entity)라는 조금 더 상위의 개념으로 불리기도 합니다.
소프트웨어는 고객이 주문한 요구사항별로 관점이 달라지기 때문에 개념 모델도 다양하게 표현되어야 합니다.
따라서, 이를 효율적으로 표현하고 도식화하고 분석하기 위한 도구로 UML(Unified Modeling Language) 등을 사용합니다.
UML은 개발자가 소프트웨어라는 제품에서 야기된 다양한 문제 상황을 진단하고 해결하는 것에 도움을 줄 수 있습니다.
또한, 앞으로 개발될 시스템에 대하여 어떻게 개발 과정을 진행할 지 전체적인 일정과 이해를 필요로하는 다양한 개념에 대해서 공유하는 데 도움을 줄 수 있습니다.
이렇게 표현된 모델들을 생성해 나가는 일련의 과정을 개념 모델링(Conceptual Modeling)이라고 합니다.
그리고, 이와 비교되는 개념으로 절차적인 프로그램을 위한 자료 흐름도(Data Flow Model)는 프로세스 위주의 모델링도 있습니다.
즉 정리하자면 다양한 소프트웨어의 모델링을 보다 효율적으로 하기 위한 도구를 총칭하는 것이 UML
그리고 이러한 UML에 해당하는 다양한 도구들이 접미사 'Diagram'이라고 부릅니다.
*모델링에 사용되는 도구들
Use Case Diagram, Data Flow Model, State Model, Goal-Based Model, user Interactions, Object Model, Data Model 등
UML(통합 모델링 언어, Unified Modeling Language)이란?
통합 모델링 언어는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어입니다.
UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함합니다.
객체 지향 소프트웨어의 개발 과정에 시스템 분석, 설계, 구현 등의 산출물을 명세화, 시각화, 문서화할 때 사용하는 모델링 기술과 방법론을 통합하여 만든 범용 모델링 언어입니다.
럼바우(Rumbaugh)의 OMT 방법론과 Booch의 BOoch 방법론, Jacobson의 OOSE 방법론을 통합하여 만든 모델링
개념의 공통 집합으로, 객체 지향 분석 및 설계 방봅론의 표준 지정을 목표로 제안된 모델링 언어입니다.
OMG(Object Management Group)에서 표준화 공고 후 IBM, HP, Microsoft, Orcale 등이 참여하여 1997.1. 버전 1.0을 Release 하였습니다.
럼바우(Rumbaugh) 객체지향 분석 기법
- 소프트웨어 구성 요소를 그래픽으로 모형화하였다.
- 객체 모델링 기법이라고도 한다.
| 구분 | 설명 |
| 객체 모델링 | 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체 간의 관계를 규정하여 객체를 다이어그램으로 표시한다. |
| 동적 모델링 | 제어흐름, 상호작용, 동작순서 등의 상태를 시간 흐름에 따라 상ㅇ태 다이어 그램으로 표시한다. |
| 기능 모델링 | 여러 프로세스 간의 자료 흐름을 표시한다. 어떤 데이터를 입력하여 어떤 결과를 가져올 수 있을지 표현한다. |
UML의 특성
UML은 다음과 같은 특성을 가집니다.
| 특성 | 설명 |
| 시각화(Visualization) | - 소프트웨어 구성 요소 간의 관계 및 상호작용을 시각화 한 것이다. |
| 문서화(documentation) | - 소프트웨어 생명주기의 중요한 작업을 추적하고, 문서화할 수 있다. - 개발 프로세스 및 언어와 무관하게 개발자 간의 의사소통 도구를 제공한다. |
| 명세화(specification) | - 분석, 설계, 구현의 완벽한 모델을 제공한다. - 분석 단계-기능모델, 설계 단계-동작 수준 모델, 구현 단계-상호작용 모델 수준으로 명세화 할 수 있다. - 단순 표기법이 아닌 구현에 필요한 개발적 요소 및 기능에 대한 명세를 제공한다. |
| 구축(build) | - 객체지향 언어와 호환되는 프로그래밍 언어는 아니지만, 모델이 객체지향 언어로 맵핑될 수 있다. |
UML의 소프트웨어에 대한 관점
| 관점 | 설명 |
| 기능적 관점 | - 사용자 측면에서 본 소프트웨어의 기능을 나타낸다. - 사용 사례 모델링이라고도 한다. - 요구 분석 단계에서 사용한다. - UML에서는 Use Case Diagrame을 사용한다. |
| 정적 관점 | - 소프트웨어 내부의 구성 요소 사이의 구조적 관계를 나타낸다. - 객체, 속성, 연관 관계, 오퍼리에션의 시스템 구조를 나타내며 UML에서는 Class Diagram을 사용한다. - ex) 클래스 사이의 관계, 클래스 구성과 패키지 사이의 관계 |
| 동적 관점 | - 시스템의 내부 동작을 말하며, UML 에서는 Sequenece Digarm, State Diagram, Activity Diagram을 사용한다. |
UML의 기본 구성
| 구성 | 설명 |
| 사물(Things) | 객체 지향 모델을 구성하는 기본 요소이다. 객체 간의 관계 형성 대상이다. 추상적인 개념으로, 주제를 나타내는 요소 단어 관점에서 ‘명사’ 또는 ‘동사’를 의미 |
| 관계(Relationship) | 객체 간의 연관성을 표현하는 것이다. 연관, 집합, 포함, 일반화, 의존, 실체화 등이 있다. 사물과 사물을 연결하여 관계를 표현하는 요소 단어 관점에서 ‘형용사’ 또는 ‘부사’를 의미 |
| 다이어그램(Diagram) | 객체의 관계를 도식화한 것이다. 다양한 관점에서 의사소통할 수 있도록 VIew를 제공한다. 사물과 관계를 모아 그림으로 표현한 형태 형식과 목적에 따라 9가지로 정의 정적 모델 : 구조 다이어그램 동적 모델 : 행위 다이어그램 |
스테레오 타입
- UML에서 제공하는 기본 요소 외에 추가적인 확장 요소를 표현할 때 사용한다.
- UML 확장 모델에서 스트레오 타입 객체를 표현할 때 사용하는 길러멧(Guillemet <<>>)이며, 길러멧 안에 확장 요소를 적는다.
| 유형 | 설명 |
| <<include>> | - 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계 |
| <<extend>> | - 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지도 않을 수도 있는 확장 관계 |
| <<interface>> | - 모든 메서드가 추상 메서드이며 바로 인스턴스를 만들 수 없는 클래스로 추상 메서드와 상수만으로 구성된 클래스 |
| <<entity>> | - 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스 - 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 |
| <<boundary>> | - 시스템과 외부 액터와의 상호작용을 담당하는 클래스 |
| <<control>> | - 시스템이 제공하는 기능의 로직 제어를 담당하는 클래스 |
UML의 접근 제어자
| 접근 제어자 | 표기 | 설명 |
| public | + | 어떤 클래스의 객체에서든 접근 가능하다. |
| private | - | 해당 클래스로 생성된 객체만 접근 가능하다. |
| protected | # | 해당 클래스와 동일 패키지에 있거나, 상속 관계에 있는 하위 클래스의 객체들만 접근 가능하다. |
| package | ~ | 동일 패키지에 있는 클래스의 객체들만 접근 가능하다. |
연관 관계 다중성 표현
| 표기 | 의미 |
| 1 | 1개체 연결 |
| *또는 0..* | 0이거나 그 이상 객체 연결 |
| 1..* | 1이거나 1 이상 객체 연결 |
| 0..1 | 0이거나 1 객체 연결 |
| 1,3,6 | 1이거나 3이거나 6 객체 연결 |
| n | n개 객체 연결 |
| n..* | n이거나 n개 이상 객체 연결 |
UML 관계 표현
UML 연관 관계(Association Relation)
- 한 사물의 객체가 다른 사물의 객체와 연결된 것을 표현한다.
- 두 클래스가 서로 연관이 있다면 A, B 객체를 서로 참조할 수 있음을 표현
- 이름 : 관계의 의미를 표현하기 위해 이름을 가질 수 있다.
- 역할 : 수행하는 역할의 명시적 이름을 가질 수 있다.
UML 의존 관계(Dependency Realtion)
- 연관 관계와 같지만 메소드를 사용할 EO와 같이 매우 짧은 시간만 유지된다.
- 영향을 주는 객체(User)에서 영향을 받는 객체 바향으로 점선 화살표를 연결한다.
UML 일반화 관계(Generalization Relation)
- 객체지향에서 상속 관계(is a kind of)를 표현한다.
- 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 사용한다.
UML 집합 관계(Aggregation Relation)
- A 객체가 B 객체에 포함된 관계이다.
- ‘부분’을 나타내는 객체를 다른 객체와 공유할 수 있다.
- ‘전체’ 클래스 방향에 빈 마름모로 표시하고, or 관계에 놓이면 선 사이를 점선으로 잇고 {or}를 표시한다.
UML 포함 관계(Composition Relation)
- 부분 객체가 전체 객체에 속하는 강한 집합 연관의 관계를 표현하는 클래스이다.
- ‘부분’ 객체는 다른 객체와 공유 불가하고, ‘전체’ 객체 방향에 채워진 마름모로 표시한다.
UML 실체화 관계(Realization Relation)
- 인터페이스와 실제 구현된 일반 클래스 간의 관계로 존재하는 행동에 대한 구현을 표현한다.
- 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계이다.
UML다이어 그램의 종류
1. 구조적 다이어그램(Structured Diagram)
정적인 구조표현을 위한 다이어그램
| 다이어그램(Diagram) | 설명 |
| 클래스 (Class) | - 객체지향 모델링 시 클래스의 속성 및 연산과 클래스 간의 정적인 관계를 표현한 다이어그램 |
| 객체 (Object) | - 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현한 다이어그램 - 연관된 모든 인스턴스를 표현 |
| 컴포넌트 (Component) | - 컴포넌트 다이어그램은 시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타내는 다이어그램 |
| 배치 (Deployment) | - 컴포넌트 사이의 종속성을 표현하고, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하는 다이어그램 |
| 복합체 구조 (Composite Structure) | - 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현하는 다이어그램 |
| 패키지 (Package) | - 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한 다이어그램 |
클래스 다이어그램의 구성요소
| 구성요소 | 설명 |
| 클래스 (Class) | - 공통의 속성, 연산(메서드), 관계, 의미를 공유하는 객체들의 집합 |
| 속성 (Attribute) | - 클래스의 구조적 특성에 이름 붙인 것으로 특성에 해당하는 인스턴스가 보유할 수 있는 값의 범위를 기술 |
| 연산 (Operation), 메서드 (Method) | - 이름, 타입, 매개변수들과 연관된 행위를 호출하는 데 요구되는 제약사항들을 명시하는 클래스의 행위적 특징 - 객체에 요청하여 행동에 영향을 줄 수 있는 서비스 |
| 접근 제어자 (Access Modifier) | 클래스의 접근할 수 있는 정도를 표현하고 아래의 기호를 사용 - : 클래스 내부 접근만 허용 (private) + : 클래스 외부 접근을 허용 (public) # : 동일 패키지/파생 클래스에서 접근 가능 (protected) ~ : 동일 패키지 클래스에서 접근 가능 (default) |
패키지 다이어그램(Package Diagram)
- 폴더 모양의 패키지와 점선으로 표시된 의존 관계로서 <<import>>라는 스테레오 타입 표기를 통해 패키지 다이어 그램인지 아닌지 파악 가능
- 패키지 다이어그램은 시스템의 서로 다른 패키지들 사이의 의존 관계를 표현하기 위한 다이어그램
| 구성요소 | 설명 |
| 패키지 | - 요소들을 그룹으로 조직하기 위한 요소 |
| 의존 관계 | - 하나의 패키지가 다른 패키지를 사용하는 관계 - 의존성의 성질을 나타내기 위해 스테레오 타입을 붙일 수 있음 - 스테레오 타입에는 <>, <> 가 있음 |
2. 행위 다이어그램(Behavior Diagram)
동적이고 순차적인 표현을 위한 다이어그램이다.
| 다이어그램(Diagram) | 설명 |
| 유스케이스 다이어그램(Use Case Diagram) | 사용자 관점에서 시스템 행위를 표현한다. |
| 활동 다이어그램(Activity Diagram) | 업무 처리 과정이나 연산이 수행되는 과정을 표현한다. |
| 상태 머신 다이어그램(State Machine Diagram) | 객체의 생명주기를 표현한다. 동적 행위를 모델링하지만, 특정 객체만들 다룬다. ex) 실시간 임베디드 시스템, 게임, 프로토콜 설계 등 |
| 협력 다이어그램(Collaboration Diagram) | Sequence Diagram과 같으며, 모델링 공간에 제약이 없어 구조적인 면을 중시한다. |
유스 케이스 다이어그램(Use Case Diagram)
시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
유스 케이스 다이어그램(Use Case Diagram)의 구성 요소
| 구성 요소 | 설명 |
| 시스템 경계(System Boundary) | - 시스템이 제공해야 하는 사례(Use Case)들의 범위가 된다. - 큰 규모의 객체로 구현되는 존재이다. |
| 액터 (Actor) | - 서비스를 이용하는 외부 객체이다. - 시스템이 특정한 사례(Use Case)를 실행하도록 요구할 수 있는 존재이다 |
| 유스케이스 (Use Case) | - 시스템이 제공해야 하는 개별적인 서비스 기능이다. - 서비스는 특정 클래스의 멤버 함수로 모델링 된다. |
유스 케이스(Use Case)와 구성요소 간의 관계
- 액터와 유스케이스 사이의 의미 있는 관계를 나타낸다. 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)가 있으며 의존 관계는 포함(Include), 확장(Extend)으로 나누어진다.
| 구성 요소 | 설명 |
| 연관(Association) | - 유스케이스와 액터 간의 상호작용이 있음을 표현한다. |
| 포함(Include) | - 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다. |
| 확장(Extend) | - 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계이다. - 확장 대상 유스케이스를 수행할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용한다. |
| 일반화(Generalization) | - 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다. |
유스케이스 다이어그램Use Case Diagram)의 작성 단계
① 액터 식별
- 모든 사용자 역할과 상호작용하는 타 시스템을 식별한다.
- 정보를 주고받는 하드웨어 및 지능형 장치를 식별한다.
② Use Case 식별
- 액터가 요구하는 서비스와 정보를 식별한다.
- 액터가 시스템과 상호작용하는 행위를 식별한다.
③ 관계 정의
- 액터와 액터, 그리고 액터와 유스케이스의 관계 분석을 정의한다.
- 유스케이스와 유스케이스간의 관계 분석을 정의한다.
④ Use Case 구조화
- 두 개의 상위 Use Case에 존재하는 공통 서비스를 추출한다.
- 추출된 서비스로 Use Case를 정의한다.
- 추출된 서비스를 사용하는 Use Case 관계를 정의한다.
- 조건에 따른 서비스 수행 부분을 분석하여 구조화한다.
활동 다이어그램의 구성요소
시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서대로 표현한 다어어 그램
| 구성요소 | 설명 |
| 시작점 (Initial Node) | - 활동의 시작(액션이나 액티비티 시작)을 의미 - 하나의 다이어그램 안에는 하나의 시작점만 존재 - 검은색 동그라미로 표현 |
| 전이 (Transition) | - 실행의 흐름을 나타냄 - 화살표로 표현 |
| 액션(Action)/ 액티비티(Activity) | - 어떠한 일들의 처리와 실행을 의미 - 액션은 더 이상 분해할 수 없는 단일 작업 - 액티비티는 몇 개의 액션으로 분리될 수 있는 작업 - 모서리가 둥근 사각형으로 표현하고 둥근 사각형 안에 액션이나 액티비티 명을 기술 |
| 종료점 (Final Node) | - 처리의 종료를 의미 - 하나의 다이어그램 안에는 여러 개의 종료 노드가 있을 수 있음 - 검은색 동그라미를 포함한 원으로 표현 |
| 조건(판단)노드 (Decision Node) | - 조건에 따른 제어 흐름의 분리를 표현 - 마름모로 표현하고 들어오는 제어 흐름은 한 개이고 나가는 제어 흐름은 여러 개로 표현 |
| 병합 노드 (Merge Node) | - 여러 경로의 흐름이 하나로 합쳐진 것을 표현 - 마름모로 표현하고 들어오는 제어 흐름은 여러 개이고, 나가는 제어 흐름은 한 개로 표현 |
| 포크 노드 (Fork Node) | - 평행적으로 수행되는 흐름을 나누는 노드 - 굵은 가로선으로 표현하고, 들어오는 액티비티 흐름은 한 개이고 나가는 흐름은 여러 개 |
| 조인 노드 (Join Node) | - Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드 - 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개 |
| 구획면 (Swim Lane) | - 액티비티 수행을 담당하는 주체를 구분하는 면 - 가로 또는 세로 실선을 그어 구분 |
3. 상호작용 다이어그램 (Interaction Diagram)
| 다이어그램(Diagram) | 설명 |
| 시퀀스 다이어그램(Sequence Diagram) | 시스템의 동작을 정형화하고, 객체의 메시지 교환을 쉽게 표현하고 시간에 따른 메 세지 발생 순서를 강조한다. |
| 상호작용 개요 다이어그램 (Interaction Oveview Diagram) | 여러 상호작용 다이어그램 사이의 제어 흐름을 표현한다. |
| 통신 다이어그램(Communication Diagram) | 객체 사이의 관계를 중심으로 상호작용을 표현한다. |
| 타이밍 다이어그램(Timing Diagram) | 객체 상태 변화와 시간 제약을 명시적으로 표현한다. |
시퀀스 다이어그램 구성요소
| 구성요소 | 설명 |
| 객체 (Object) | - 객체는 위쪽에 표시되며 아래로 생명선을 가짐 - 객체는 사각형 안에 밑줄 친 이름으로 명시 |
| 생명선 (Lifeline) | - 객체로부터 뻗어 나가는 점선 - 실제 시간이 흐름에 따라 객체의 생명주기 동안 발생하는 이벤트를 명시 |
| 실행 (Activation) | - 직사각형은 오퍼레이션(함수)이 실행되는 시간을 의미 - 직사각형이 길어질수록 오퍼레이션 수행시간이 긴 것을 의미 |
| 메시지 (Message) | - 객체 간의 상호작용은 메시지 교환으로 이루어짐 - 한 객체에서 다른 객체로의 메시지를 전달하여 전달받은 객체의 오퍼레이션을 수행 |
참고자료
https://medium.com/@G_Kumar/features-of-uml-1d71dfef1cb1
Features of UML
The Unified Modeling Language (UML) is a standardized visual modeling language used in software engineering to represent, document, and…
medium.com
'CS BASIC > 소프트웨어 설계와 방법론' 카테고리의 다른 글
| [CS BASIC] 개발 일정 관리 모델(Development Managing Model)과 다양한 개발 도구(Development Kit)들 (1) | 2023.12.26 |
|---|---|
| [CS BASIC] COCOMO, 자료흐름도(DFD), 자료 사전(DD), 코드 설계(Code Design) (1) | 2023.12.25 |
| [CS BASIC] 소프트웨어의 디자인 패턴 (1) | 2023.12.23 |
| [CS BASIC] 모듈(Module)과 모듈 평가 기준, 소프트웨어 아키텍처 뷰와 프레임워크 (1) | 2023.12.21 |
| [CS BASIC] 소프트웨어 비즈니스 계획과 연속성 관리 (0) | 2023.12.20 |
