UML

이번 시간은 UML에 대해서 정리해보겠습니다.

 

UML이란?

Unified Modeling Language의 약어다. 소프트웨어의 전체를 판단할 수 있도록 12개의 다이어그램을 제시한다.

UML의 역할은 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트 간의 관계 등을 시각적으로 볼 수 있게 나타낸 도면이다.

UML의 12개 다이어그램은 아래와 같다.

12개 다이어그램에서도 유스케이스, 클래스, 순차. 통신, 활동, 상태, 컴포넌트, 배치 다이어그램에 대해 살펴보겠다.

UML의 12개 다이어그램

 

유스케이스 다이어그램

객체지향 방법에서는 UML의 유스케이스 다이어그램으로 사용자 요구 사항을 표현한다.

유스케이스 다이어그램은 시스템이 제공하는 기능을 나타내는 유스케이스와 이 기능을 사용하는 사용자인 액터, 그리고 이 둘의 관계로 나타낸다.

액터

액터와 유스케이스의 관게는 ->(화살표)로 표현하며 화살표 방향은 액터에서 유스케이스 방향이다.

액터 종류

• 사용자 액터 : 시스템을 사용하는 사람이다.
• 시스템 액터 : 해당 프로젝트의 개발 범위에는 속하지 않지만 데이터를 주고받는 등 서로 연동되는 또 다른 시스템이다.
• 주요 액터 : 시스템에게 작업의 실행을 요구하는 능동적 입장의 액터를 주요 액터라고 하며 대부분의 액터가 여기에 해당한다.
• 보조 액터 : 유스케이스로부터 요청을 받거나 메시지를 전달받아 수동적으로 작업을 하는 액터를 보조 액터라고 한다.
• 프록시 액터 : 액터와 시스템의 중간 위치에서 무언가를 대신 해주는 액터가 프록시 액터다.

액터 식별 방법

• 시스템을 사용하는 사람을 찾는다. 예를 들면 학사 관리 시스템을 사용하는 것은 학생, 교수, 조교 등
• 시스템에 자료를 CRUD 하는 사람을 찾는다. 예를 들어 성적을 수정, 삭제, 입력, 조회하는 교수
• 시스템에 연동된 또 다른 시스템을 찾는다.
• 시스템을 유지 및 관리하는 사람을 찾는다.
• 유스케이스 기능에 권한은 없지만 역할을 대신하는 사람을 찾는다.

액터 이름 규칙

• 이름만 봐도 액터의 의미를 알 수 있게 정한다.
• 역할을 나타내는 단어로 사용자 액터의 이름을 정한다.
• 시스템 액터는 시스템 이름을 사용해 이름을 정한다.

유스케이스

유스케이스는 사용자가 시스템을 통해 사용하고 싶은 기능이다.

유스케이스는 실제로 코딩할 수 있을 만큼 작은 기능이다. 따라서 여러 유스케이스가 모여 하나의 서브 시스템을 이루고 서브 시스템이 모여 개발 시스템이 된다. 이때 유스케이스로 도출되지 않은 것은 시스템의 개발 범위에 포함할 수 없고 유스케이스로 도출한 것은 개발 범위에서 빠뜨려서는 안 된다. 결국 전체 시스템은 유스케이스를 모아 놓은 것과 같아야 한다.

 

유스케이스 식별 방법

• 사용자인 액터가 시스템에 요구하는 기능을 후보 유스케이스로 선정할 수 있다. (학사 관리 시스템에서 교과목 개설, 휴학 신청, 수강 신청 등)
• 사용자의 업무에서 유스케이스를 도출할 수 있다. 예를 들어 사용자가 별도의 도구로 처리하던 업무 (엑셀, 수작업)
• DB에서 데이터를 CRUD 기능을 하나의 유스케이스로 선정할 수 있다. (성적 등록/조회/삭제/수정)

이와 같은 방법으로 찾은 후보 유스케이스는 여러 번의 정련 과정을 통해 최적화된 유스케이스로 결정된다. 유스케이스를 찾는 직업은 개발자가 하지만 사용자 관점에서 유스케이스를 정의해야 한다.

처음에는 가능하다고 생각되는 것을 모두 도출해 놓고 하나씩 면밀히 살펴보는 과정을 거쳐 불필요한 것은 삭제하고, 필요시 합치거나 분리해 최종 유스케이스를 선정한다.

 

유스케이스 검증 과정

• 시스템이 아니라 수작업으로 이루어지는 것은 유스케이스 포함하면 안된다.
• 액터가 원하는 최종 결과만 나타내는 유스케이스인지 확인한다.
• 액터가 수행하는 유스케이스인지 확인한다.
• 유스케이스 내의 이벤트 흐름 전체를 액터가 사용하는지 확인한다.

유스케이스 이름 규칙

• 사용자 관점에서 이해할 수 있는 이름을 사용한다.
• 명사보다는 어떤 기능을 하는지 알 수 있는 동사형 명사를 사용한다.
• 사용자가 시스템을 통해 얻으려는 최종 목적이 나타나는 이름을 사용한다.

관계

액터 -> 유스케이스 관계

• 액터와 유스케이스는 연관 관계로 방향성을 갖는 실선으로 표현한다.
• 이때 화살표 방향은 데이터가 흘러가는 방향이 아니라 제어의 흐름을 표현한다.
• 제어하는 주체에서 출발해 제어받는 대상으로 연관 방향이 결정된다.

아래는 단순한 액터와 유스케이스 관계다.

학생 액터와 성적 조회 유스케이스 연관 관계

아래는 액터와 시스템 액터와 유스케이스의 연관 관계를 나타낸다.

학생 액터 증명서 자동 발급기 시스템 액터 증명서 출력 유스케이스 연관 관계

유스케이스 -> 액터 관계

• 유스케이스의 수행 결과를 액터에게 알려줄 때는 유스케이스에서 액터로 방향성을 갖는 실선으로 표현한다.
• 유스케이스 -> 액터 관계에서 주의할 사항은 통보 기능이 시스템 내에서 이루어져야 한다.
• 유스케이스 다이어그램에서 화살표로 나타냈다면 그 기능을 개발에 포함해야 한다.

조교가 학사관리 시스템으로 업무 승인 요청 -> 학사 담당직원이 승인 요청을 봄 -> 이후 승인 -> 승인 결과가 조교에게 감.

아래 이미지는 위 예시다. 유스케이스 수행 결과를 액터에게 알려주는 것을 통보 기능이라고 한다.

유스케이스와 액터의 관계

액터의 일반화 관계

• 개별적인 것에서 공통적인 특징을 뽑아 이름을 붙인 것이 일반화다.
• 일반화될수록 추상화가 되고, 반대로는 구체화가 된다. 구체화되는 것을 특수화라고 한다.
• 간결하게 일반화해 복잡합을 줄이면 이해하기가 쉽고 새로운 액터도 간단하게 추가할 수 있다.

아래 왼쪽 이미지는 일반화가 안된 예시고 오른쪽은 일반화가 된 예시다.

일반화를 한 예시가 더욱 직관적으로 바로 알 수 있다.

일반화를 적용했을 때 차이

 

포함 관계

• 포함 관계는 한 유스케이스의 일부 기능(이벤트 흐름)이 다른 유스케이스에서도 공통으로 필요하다면 이를 별도 유스케이스로 만든 뒤 호출해 사용하는 것을 말한다.
• 피포함 유스케이스 : 공통으로 사용하기 위해 별도 유스케이스로 만들어 놓은 것
• 기본 유스케이스 : 피포함 유스케이스를 호출하는 유스케이스
• 포함 관계는 화살표 방향이 기본 유스케이스에서 피포함 유스케이스로 향한다.
• 점선을 사용하고 스테레오 타입으로 <<include>>라고 표기한다.
• 포함 관계는 화살표 방향이 기본 유스케이스에서 피포함 유스케이스로 향한다.
• 선행 조건과 포함관계를 혼동하면 안된다.

포함 관계를 나타내는 유스케이스 다어그램과 벤 다이어그램

확장 관계

• 특정 조건이 발생(메일 도착)하면 확장 유스케이스를 수행(메일 확인)하고 다시 기준 유스케이스(검색)를 수행
• 확잔 관게는 점선 화살표로 표기하고 방향은 기준 유스케이스 쪽으로 향한다.
• <<extend>>라는 스테레오 타입을 사용한다.

확장 관계

 

클래스 다이어그램

• 소프트웨어의 기본 구성 단위인 시스템에서 클래스를 정의
• 클래스들이 서로 어떻게 연결되어 있고 어떤 역할을 하는지 다이어 그램으로 표현

클래스 다이어그램 요소

• 클래스 이름 : 클래스는 다른 클래스와 구별되는 유일한 이름을 짓는다.
• 속성 : 클래스가 가지는 정적인 특성.
• 메서드 : 클래스가 외부의 다른 객체에게 제공할 서비스와 기능이다. 외부 클래스는 메서드를 통해 해당 클래스에 접근한다. 외부에서 이 기능을 요구하는지에 따라 메서드로 도출할지 판단한다.
• 가시성 : 속성과 메서드의 접근 권한을 지정하는 방식. public, private, protected 방식이 있다.

클래스 다이어그램

순차 다이어그램

• 실행 시점에 객체들이 어떻게 상호 동작하는지를 메시지 순서에 초점을 맞춰 나타낸 것
• 어떠한 작업이 객체 간에 발생하는지를 시간 순서에 따라 쉽게 파악할 수 있다.

순차 다이어그램 구성 요소

• 객체 : 순차 다이어그램에서 객체는 메시지를 보내고 받는 것
• 객체 생명선 : 객체의 생존 기간을 나타내며 X 표시는 객체가 소멸하는 시점이다. 위에서 아래로 내려가는 점선으로 나타낸다.
  생명선을 따라 나타나는 직사각형은 활성 구간으로 객체의 메서드가 실행되고 있음을 나타낸다. 구간의 길이는 메서드의 실행 시간 활성 구간은 반드시 존재하는 것은 아니며 생략 가능하다.
• 메시지 : 객체와 객체의 상호작용을 표현하는 것으로 화살표를 이용한다. 화살표 위에는 수신 객체의 함수명을 적는다.
• 동기 메시지 : 송신 객체가 수신 객체에 서비스를 요청(메서드 호출)하면 메서드 실행이 완료될 때까지 기다린다. 실선과 속이 채워진 삼각형으로 나타낸다.
• 비동기 메시지 : 송신 객체가 수신 객체에 서비스를 요청할 때 메서드의 실행과 상관없이 다음 작업을 수행하며 수신 객체로부터의 반환도 기다리지 않는다. 일반 화살표 모양으로 나타낸다.
• 재귀 메시지 : 수신 객체가 자신의 메서드를 호출할 때 사용한다.
• 답신 메시지 : 호출 메서드의 결과를 반환할 때 사용한다. 점선과 속이 채워진 삼각형으로 나타낸다.
• 시나리오 정의 : 시나리오를 명확히 정의한 후에 그것을 토대로 순차 다이어그램을 작성한다.
• 다이어그램과 시나리오의 1 : 1 대응 : 하나의 이벤트에 여러 개의 시나리오가 나올 경우 시나리오마다 각각의 다이어그램으로 표현
• 시나리오 분할 : 하나의 이벤트가 너무 길면 시나리오를 여러 개로 나누어 작성하는 것이 좋다.

순차 다이어그램

통신 다이어그램

• 객체 간 상호작용 관계에 주목
• 화살표 위에 적힌 번호로 순서를 알 수 있다.

링크

• 객체 간에 메시지를 주고받는 관계
• 통신 다이어그램에서는 링크를 사용해 객체 간의 관계를 표현한다.

통신 다이어그램

활동 다이어그램

• 흐름도와 비슷하나 객체의 행위를 나타낸다는 점에서 다르다.
• 상위 수준에서는 업무의 흐름을 표현하고 분석 단계에서는 유스케이스의 구체적인 흐름(이벤트 흐름)을 나타낸다.
• 설계 단계에선느 클래스 내부 동작에 대한 알고리즘이나 구체적인 로직을 표현한다.

활동 다이어그램의 구성 요소

시작/종료 상태, 활동

• 시작점 : 활동의 시작을 나타내며 속이 채워진 원으로 표기
• 종료점 : 활동의 종료를 나타내며 이중 원으로 표기
• 활동 : 일의 처리와실행을 나타내며 모서리가 둥근 사각형으로 표기
• 전이 : 활동 간의 이동을 나타내며 화살표로 표기

분기와 병합

• 분기 : 조건에 의해 두 가지 경로로 나뉘는 위치이며 마름모를 사용한다. 조건문은 마름모 옆에 <<>> 기호로 작성한다.
• 병합 : 분기되어 각 활동을 수행하다가 합쳐지는 위치를 나타내며 분기와 같이 마름모를 사용한다. 병합은 생략이 가능하다.

동기화 막대

• 여러 활동을 병행할 때 사용하는 것으로 동시 처리의 시작과 끝을 나타낸다.

신호

• 활동 사이의 거래는 제어 신호를 보내는 방식으로 이루어진다. 여기서 사용되는 신호는 아래와 같다.

신호의 종류

상태 다이어그램

이벤트 발생이나 시간의 흐름에 따라 바뀌는 객체의 상태를 나타낸다.

상태 다이어그램의 구성 요소

• 상태 : 객체가 존재할 수 있는 조건. 객체의 존재 가능한 모든 상태가 파악되어야 한다. 상태는 모서리가 둥근 사각형으로 표현.
• 전이 : 객체의 상태가 바뀌는 것을 나타내며 화살표로 표현한다.
• 이벤트 : 객체의 상태를 바뀌게 하는 자극. 화살표로 나타낸 전이 위에 <<>>기호를 사용해 작성한다.

상태 다이어그램

컴포넌트 다이어그램

• 구현 관점에서 정적 모델링을 할 때 사용하는 것
• 어떤 실행 모듈이 존재하고 이들이 서로 어떤 연관성이 있는지의 종속 관계를 나타낸다.
• 사용자에게 논리적 또는 물리적 시스템의 구조를 볼 수 있게 해준다.

컴포넌트 다이어그램의 구성 요소

컴포넌트

• 컴포넌트는 시스템을 구성하는 물리적인 요소로 프로그램 코드를 조정
• <<executable>> : 실행 파일
• <<library>> : DLL 같은 정적 또는 동적 객체 라이브러리
• <<table>> : 데이터베이스 테이블
• <<file>> : 원시 코드를 포함하는 파일

인터페이스

• 클래스 모양으로 나타내거나 아이콘을 사용해 간략하게 표현할 수 있다.

의존 관계

• 서로 영향을 주는 의존 관계를 말한다. 컴포넌트 간 연결은 점선 화살표로 나타내며 의존하는 쪽으로 화살표가 연결된다.

컴포넌트 다이어그램의 작성 과정

1. 컴포넌트 대상 정의
2. 컴포넌트 찾기
3. 컴포넌트 배치
4. 의존 관계 정의

배치 다이어그램

• 하드웨어 자원을 명시적으로 정의해 시스템의 물리적인 요소를 모델링하고 노드 간의 관계를 나타낸다.
• 노드 : 시스템을 구성하는 처리 장치로 실행 파일 수준의 컴포넌트가 탑재된 하드웨어를 말한다.
• 노드를 연결하는 관계는 다양한 통신 방식을 의미한다.

 

 

참고자료

쉽게 배우는 소프트웨어 공학 2판 (2단원 UML)

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429 

쉽게 배우는 소프트웨어 공학 - 교보문고