UML 다이어그램

Kiwoong Park·2022년 6월 15일
0

UML(Unified Modeling Language)은 객체지향설계방법론에 대한 연구를 수행해 오던 Grady Booch와 James Rumbaugh, Ivar Jacobson 각자가 제안한 방법론을 통합적으로 뒷받침 할 수 있는 객체지향 모델링 언어를 제안하였는데 이것이 UML이다.
즉, UML은 객체지향 관점에서 소프트웨어 설계를 어떻게 하는가에 대한 방법론이 아니라 오히려 이러한 방법론에 기초한 설계결과를 표현하는데 사용하는 언어
따라서 UML로 표기된 설계문서를 해석하는 사람은 기술 내용에 대한 동일한 이해를 가질 수 있고, UML의 각 다이어그램은 각 소프트웨어 설계 단계에 맞추어 작성하게 되어 어느 단계에서 어느 다이어그램이 적합할 것인가 쉽게 알 수 있다.

UML 다이어그램 종류

(1) UseCase Diagram

유스케이스 다이어그램은 시스템의 설계에서 가장 먼저 표현하는 다이어그램이다. 즉, 시스템이 사용자에 의해 어떻게 다루어 질 것인가를 설명하기 때문에 시스템의 가장 기본적인 요구사항을 분석할 수 있음

기본 요소

  • Use Case(쓰임새)
  • Actor(행위자)
  • event flow(사건 흐름)

그림은 영화 리뷰와 관련한 유스케이스 다이어그램이다. 고객은 행위자(Actor)가 되며 고객은 영화 리뷰라는 쓰임새를 사용하여 시스템에 처리를 요청하는 것을 표현

  • 도식적인 표현을 뒷받침하기 위해 설명(UseCase Description)을 부가할 수가 있으며, 이 설명에는 쓰임새의 개요와 제약조건, 성능요건, 보안 및 배치요구사항 등이 포함
  • 또한 한 장소에서의 쓰임새의 모든 사건흐름을 보여 주기 위하여 활동도(Activity Diagram)을 첨부할 수 있다
  • UseCase Diagram에서 박스는 시스템의 범위를 설정하기 위하여 사용하며 각각의 쓰임새는 이 박스 안에 표시되며, 행위자는 이 박스의 밖에 표시되어 시스템으로의 요청과 서비스를 표현한다.
  • 각 쓰임새는 하나의 쓰임새가 다른 쓰임새를 포함할 때 스테레오 타입 <<include>>를 사용해서 포함관계 표현
  • 하나의 쓰임새를 확장하고자 할 때는 스테레오 타입 <<extend>>를 사용해서 표현
  • 포함 관계나 확장 관계는 점선 - - - - 화살표를 사용
  • 쓰임새와 행위자의 상속관계는 빈 삼각형을 사용하여 표현

    영화 리뷰쓰기는 영화 검색과 영화 리뷰 저장의 쓰임새를 포함한다.
    영화 검색 쓰임새는 제목, 배우, 장르 검색에 상속된다.
    또한, 영화 리뷰쓰기는 타인의 리뷰를 조회 쓰임새와, 리뷰를 쓰기 위해 내 프로필 정보를 입력하는 쓰임새로 확장 시킬 수 있다.

(2) Class Diagram

클래스는 객체지향 시스템에서 가장 중요한 핵심 요소이다. 클래스는 속성(attribute)와 행위(method)를 가지며, 객체 간의 관계를 통하여 특정한 시스템을 모사한다. 즉, 어떤 시스템은 어떠한 클래스를 어떠한 관계 속에서 가지고 있느냐에 의해 정적인 구조가 묘사된다. 시스템이 갖는 정적인 정보들의 관계를 설명

기본 요소

  • 세 부분으로 나뉘며, 첫 번째는 클래스 이름, 두 번째는 속성, 마지막 칸에는 클래스의 메서드가 작성됨

위 다이어그램의 클래스는 클래스명과 속성을 포함하며, 이러한 다이어그램은 초기 설계단계에서의 다이어그램으로 볼 수 있다. 이후 클래스의 메서드(행위)에 대한 분석이 완료되면, 메소드가 추가된 상세한 클래스 다이어그램을 그리게 된다.

  • 영화와 영화 카피본은 복사의 연관 관계를 가지며 여러 개의 물리적인 카피본을 갖는 것을 표현함.
  • 영화는 카피본이 없어도 존재하고(1) 영화 1개 당 1개 이상(1..*)의 카피본을 가질 수 있음
  • 영화 관람자는 영화 관람이 없어도 존재하고(1) 영화 관람을 안할 수도 혹은 여러 번 할 수도 있고(0..*), 이때 영화관의 경우 해당 좌석을 대여한다는 연관관계

(3) Object Diagram(객체 다이어그램)

객체 다이어그램은 클래스의 인스턴스를 모델링. 즉, 어느 한 시점에서의 객체 간의 관계를 보여줌.
객체 다이어그램은 시스템의 객체 구조를 완전하게 정의한다기보다는 임의의 한 시점에서 시나리오를 설정하고 시나리오에 참여하는 각 객체를 표현하며, 각 객체의 속성값과 상태를 표현

객체는 클래스의 인스턴스이기 때문에 클래스 명이나 변수 명과 대응되는 실제 값들이 각각 쌍으로 표현된다.

(4) Sequence Diagram(순차 다이어그램)

순차 다이어그램은 시간이 지남에 따라 객체간에 어떤 상호작용이 발생하는 지를 객체 간 교환하는 메시지를 중심으로 표시한다.

  • 이 다이어그램의 횡(가로)축은 상호작용에 참여하는 객체가 배열된다.
  • 통상 상호작용을 주도하는 객체는 좌측에 위치, 종속적인 객체는 우측에 위치한다.
  • 종(세로)축은 시간진행에 따른 메시지 순서에 초점을 맞춤

기본 요소

  • 각 객체로부터 아래로 그어진 선은 생명선(lifeline)
  • 이 생명선을 따라 객체의 실행(activation)이 표시된다.
  • 이 실행은 얇은 직사각형으로 객체의 오퍼레이션이 진행되는 시간에 따라 표시
  • 이 직사각형이 시작되는 지점에서 실행이 시작되고, 끝나는 지점에서 실행의 완료 시점 표시
  • 객체간 전달되는 메시지는 3가지 유형
    • 제어흐름(simple)
    • 메시지 답신을 요구하는 동기식 메시지(synchronous)
    • 일방적 메시지 전송인 비동기식 메시지(asynchronous)

(5) Collaboration Diagram(협력 다이어그램)

협력 다이어그램은 클래스간의 상호 협력활동을 표시한다. 상호작용에 참여하는 객체의 구조, 상호작용이 일어나는 객체와 그들 사이의 연결을 중심으로 상호작용을 표현하고 객체 역할간의 관계를 나타낸다.
이 다이어그램은 메시지를 주고 받으면서 상호작용 하는 객체의 구성을 강조하는 다이어그램으로 객체는 다이어그램 어디에도 위치가 가능하다.

기본 요소

  • 객체는 그래프의 노드로 표현되며, 객체 간의 관계인 링크는 선으로 표시된다.
  • 객체 간의 주고 받는 메시지는 링크 위에 별도의 화살표와 함께 표시된다.
  • 시간을 하나의 차원으로 보여 주지 않기 때문에 메시지 순서와 동시성의 제어는 순서번호를 사용하여 표현한다.

(6) Activity Diagram(활동 다이어그램)

활동 다이어그램은 시스템의 작업흐름을 표현하기 위한 다이어그램으로, 어떤 객체의 활동과 활동의 진행에 필요한 의사결정을 표시한다.
활동 다이어그램은 UseCase 다이어그램을 이용하여 작성하며, 각각의 쓰임새별로 작성하여 통합하거나 복잡한 경우 계층적인 활동 다이어그램을 작성할 수도 있음

기본 요소

  • 활동은 타원으로 표시하며 활동 간의 전이는 화살표로 표시
  • 활동의 시작은 검은 점으로 종료는 흰 원 안에 검은 점으로 표시
  • 어떠한 조건이 만족되는 가에 따라 분기하고 하는 경우를 위해 의사결정이 표시되어야 하는 위치를 마름모꼴로 표시
  • 병행적으로 진행되어야 하는 활동은 두 개의 평행선 안에 활동을 명시하여 표시
  • 활동 다이어그램은 시스템에서 어떤 작업이 수행되는가를 표현하지만 작업을 수행하는 주체는 표시하지 않음
  • 주체를 표시하고자 할 때는 객체 간을 구분해주는 스윔레인(swim lane | ... | ... |)을 표시하여 어떤 활동이 어떤 객체에 의해 수행되는가를 표시

(7) Status Diagram(상태 다이어그램)

상태 다이어그램은 임의 시간동안 객체가 보유하는 상태와 상태가 전이하는 제어흐름을 표현.

기본 요소

  • 상태는 모서리가 둥근 사각형으로 표시하며 이 사각형을 세 부분으로 구분하여 맨 위에는 상태의 이름을, 두 번째에는 상태변수를, 그리고 제일 아래는 활동을 표시
  • 상태변수는 타이머나 카운터와 같이 상태의 진행에 도움을 주는 자료
  • 활동은 사건과 동작으로 이뤄짐
  • 상태와 상태 사이는 화살표로 연결하여 전이를 표시
  • 전이 조건은 화살표 위에 표시
  • 전이의 시작은 검은 원으로 마지막은 흰 원안에 검은 원으로 표시

(8) Component Diagram(컴포넌트 다이어그램)

컴포넌트는 하나 또는 그 이상의 클래스를 구현한 것이라고 간단히 설명할 수 있다. 컴포넌트 다이어그램은 시스템에 포함된 컴포넌트를 모델링하는 수단이다.

기본 요소

  • 컴포넌트는 큰 사각형과 왼쪽 경계상의 두 개의 작은 사각형으로 표시
  • 크게 컴포넌트와 인터페이스로 구성
    • 인터페이스는 어떤 클래스가 다른 클래스에게 자신이 가진 오퍼레이션을 수행시키도록 하게 하는 오퍼레이션의 집합
    • 인터페이스의 표현은 클래스와 마찬가지로 세 부분으로 나눠진 사각형으로 표시하여 인터페이스 명칭과 오퍼레이션을 작성, 명칭의 자리에는 <<interface>>라는 스테레오를 명시하여 클래스와 구분
    • 간단히 작은 원으로 인터페이스의 존재를 나타낼 수도 있음
    • 만약 두 개의 컴포넌트가 임의의 인터페이스를 통하여 연결될 때 이 인터페이스를 제공하는 측은 실체화(realization)을 표현하기 위해 점선과 삼각형의 화살표
    • 사용하는 측은 점선 화살표를 이용

화면에서 버튼을 눌렀을 때 이것을 사건으로 인식하여 처리할 수 있도록 하는 기능을 버튼이라는 컴포넌트와 윈도우 사건발생기라는 컴포넌트로 각각 모듈화
이 두 컴포넌트 사이의 사건을 전달하고 청취하기 위한 인터페이스

문서편집기라는 하나의 컴포넌트가 단어편집기와 단어의 오류를 검사하는 단어검사기, 그리고 문서에 포함된 어휘 수를 계산하는 어휘수 계산기 클래스로 구성

(9) Package Diagram(패키지 다이어그램)

시스템이 적은 경우는 클래스나 컴포넌트로 표현해도 무리가 없으나 대형 시스템의 경우는 작은 모듈로 시스템을 설명하는 것이 어려울 수 있음. 따라서 대형 시스템에서는 소프트웨어 구성요소를 더 큰 규모로 조직화하는 것이 필요한 데, 패키지는 클래스 뿐 아니라 클래스가 모아진 컴포넌트를 포함할 수 있는 논리적인 소프트웨어 모듈

기본 요소

  • 패키지는 크고 작은 두 개의 사각형으로 표시하며, 패키지 간의 의존관계를 표시하기 위하여 점선으로 된 화살표를 사용

(10) Deployment Diagram(배치 다이어그램)

배치 다이어그램은 실행에 필요한 처리능력을 갖는 노드의 구성과 그 노드에 존재하는 컴포넌트를 표시하는 다이어그램으로, 소프트웨어와 하드웨어 컴포넌트 사이에 물리적인 관계를 표시.
컴포넌트와 객체가 어떻게 분산환경에서 정보를 전달하는 가를 쉽게 가시화 시켜줌.

기본 요소

  • 물리적 장치는 육면체 노드로 표현, 내부에는 컴포넌트를 표시
  • 컴포넌트는 하나 이상의 인터페이스를 가질 수 있으며, 다이어그램을 이용하여 노드의 내부에서의 인터페이스를 표시할 수 있음

UML을 이용한 시스템 모델링의 분류

UML을 이용한 시스템의 모델링은 크게 기능적 관점, 구조적 관점, 동적 관점으로 구성된다.

1. 기능적 관점

사용자 측면에서 소프트웨어의 기능을 나타내고 주로 요구 분석 단계에서 사용하는 UseCase Diagram으로 표현한다.

2. 구조적 관점

구조적 관점을 이해하기 위해 정적과 동적 모델의 차이를 이해할 필요가 있다.
말 그대로 정적과 동적은 시간의 개념이 포함되어 있느냐의 차이로 시간의 개념이 포함되지 않은 정적 모델은 주로 시스템의 구조적인 측면을 나타낸다.
예를 들어 클래스나 객체들의 관계, 또는 클래스의 그룹이 어떤 의존, 연관관계에 있는지를 나타내는 다이어그램이다.
클래스의 관계를 나타내는 Class Diagram, 패키지로 선언한 모듈의 구조를 나타내는 Package Diagram, 소프트웨어의 하드웨어 배치를 나타내는 Deployment Diagram이 있다.

컴포넌트와 모듈
컴포넌트 : 명백한 역할을 가지고 있으며 독립적으로 존재할 수 있는 시스템의 부분. 같은 기능을 가진 다른 컴포넌트로 대체 할 수 있다. (Ex. 원시코드 파일, 실행 파일(.exe), 동적 링크 라이브러리(DLLs), 데이터베이스 등)
모듈 : 모듈이란 프로그래밍 언어의 문법 구조에서 정의된 컴포넌트를 의미 (Ex. 메서드, 클래스, 패키지는 Java 프로그램의 모듈. 파일과 함수는 C언어의 모듈

3. 동적 관점

시간의 개념이 있는 동적 모델은 어느 특정한 시각에 시스템의 동작을 스냅샷 찍어놓은 것을 나타낸다. 어떤 기능을 실행하고 있는 시스템의 상태나 기능을 실행하는 순간 협력하는 객체들을 표현한 것을 동적 모델이라 한다.
Sequence, State, Activity Diagram 등으로 표현하며, 시퀀스 다이어그램은 객체들 사이의 메시지 교환을 나타내는 반면, 상태 다이어그램은 하나의 객체가 가질 수 있는 상태와 상태의 변화에 의하여 동작을 나타낸다. 액티비티 다이어그램은 순차 또는 병렬로 수행하는 작업의 제어흐름을 나타낸다.

UML 다이어그램과 설계절차

객체지향개발 프로세스는 소프트웨어 개발시스템에 대한 계획을 수립하고 요구하상을 분석하고, 설계, 구현, 시험절차를 거쳐 최종적으로 개발 완료된 시스템을 제공하는 것. UML 다이어그램은 분석과 설계과정에서 각 다이어그램의 용도에 맞게 사용하는 것이 중요함.
어떤 특정한 다이어그램을 작성하기 위한 순서가 정해져 있는 것은 아니지만 기본적으로

  1. 쓰임새를 분석하는 과정에서 시작하는 UseCase 다이어그램을 그려 모든 개발과정에서 참조하게 될 요구사항을 요약적으로 표시한다.
  2. 쓰임새 다이어그램에서 Booch, Rumbough, Jacobson의 기법을 이용하여 클래스를 찾고 이들 간의 관계를 발견함으로써 1차적인 클래스 다이어그램을 작성한다.
  3. 정적인 클래스 다이어그램은 순차 다이어그램, 상태 다이어그램, 활동 다이어그램을 작성해 나가는 과정에서 동적인 특성이 추가됨으로써 구체화 된다.
  4. 설계 과정은 이러한 동적인 요소들을 클래스의 메서드로 변환함으로써 상세한 클래스 다이어그램을 작성하게 되고 클래스를 모아 컴포넌트로 구성하고 물리적인 컴퓨터 시스템과 통신망을 통한 분산환경에 배치하게 됨으로써 설계 과정을 종료한다.
profile
You matter, never give up

0개의 댓글

관련 채용 정보