UML 개요 및 다이어그램 종류

원문 : http://blog.naver.com/dimalion?Redirect=Log&logNo=130032330667


사용케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 등... 다이어그램에 대한 내용.
다이어그램에 이런 종류가 있고, 상황에 맞는 적당한 다이어그램을 세부적으로 찾아보시기 바랍니다.

---

앞서 언급한 링크에서 IBM의 한글 문서를 요약한 것임.
http://www.ibm.com/developerworks/kr/library/769.html


먼저 배경 지식의 일부분을 옮기면 다음과 같다.

==============================================================================

배경 지식

...

UML이 표준 모델링 언어가 된 한 가지 이유는 이것이 프로그래밍 언어에 독립적이라는데 있다. (IBM Rational의 UML 모델링 툴은 .NET 뿐만 아니라 J2EE에서도 사용된다.) 또한 UML 표기법 세트는 언어이지 방법론이 아니다. 언어인 것이 중요한 이유는 방법론과는 반대로 언어는 기업이 비즈니스를 수행하는 방식에 잘 맞는다.

UML은 방법론이 아니기 때문에 (IBM Rational Unified Process® lingo의 "객체(artifacts)" 같은) 어떤 형식적인 작업 생성물들이 필요 없다. 하지만 정해진 방법론 안에서 쓰이면, 애플리케이션을 개발할 때 애플리케이션을 쉽게 이해할 수 있도록 도와주는 여러 가지 유형의 다이어그램을 제공한다.

...

==============================================================================

아무리 읽어도 잘 이해가 되질 않는다.
"UML 표기법 세트는 언어이지 방법론이 아니다."라는 부분....
도대체 방법론이란 무엇을 말하는 것일까? 방법론이 무엇이길래 "UML은 방법론이 아니기 때문에 어떤 형식적인 작업 생성물들이 필요없다."라고 말하는걸까?

다시 wikipedia의 힘을 빌었다.(http://en.wikipedia.org/wiki/Unified_Modeling_Language)
==============================================================================

Methods

UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (for example OMT), and new methods have been created based on UML. The best known is Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.

==============================================================================

방법론이란 method를 번역한 것이고, 일상적으로 얘기하는 방법론과 UML에서 의미하는 방법론이 조금 다른 것으로 보인다. 가령 Abstraction Method, Dynamic System Development Methd이라고 언급된 것으로 미루어 아주 한정된 좁은 의미인 듯...
그런데 이부분을 번역하면, "UML은 방법론 그 자체는 아니다..."가 된다. 즉, 방법론이 포함되었다는 의미아닌가?

그래서 다시 internet 검색... 텀즈에서 찾은 부분에 비슷한 부분이 있다.(http://www.terms.co.kr/UML.htm)
==============================================================================
...

UML은 모델링 언어일뿐 메쏘드(또는 방법론)는 아니다. 메쏘드는 프로세스에 대한 정의와 각각의 업무들에 대한 지침과, 업무들 간의 순서들을 명시해야 하는 반면, 모델링 언어는 표기법(또는 다이어그램)들만을 제시하는 것이다. 따라서 UML은 소프트웨어 개발에 사용하기 위한 여러 다이어그램들을 정의하고 있으며, 또 다이어그램들의 의미들에 대해 정의하고 있다.

...
==============================================================================
아항~~ 방법론이란 바로 메쏘드를 지칭하는 것이구나!!

Object Oriented Programming(OOP)에서는 개체를 속성(attribute)과 메쏘드(method)로 나누어 정의한다. 속성은 쉽게 얘기하자면 변수, 상수와 같은 값을 의미하고, 메쏘드는 특정한 기능을 수행하는 함수를 의미한다.
텀즈에서 언급한 "메쏘드는 프로세스에 대한 정의와 각각의 업무들에 대한 지침과, 업무들 간의 순서들을 명시해야 하는 반면..."이 이를 확인시켜주는 것이다.



UML은 다이어그램을 이용해 대상 시스템을 모델링한다.
가장 유용한 표준 UML 다이어그램은 사용 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 스테이트 차트 다이어그램, 액티비티 다이어그램, 컴포넌트 다이어그램, 전개 다이어그램 등이 있다.
(UML 2.0에는 3개의 카테고리에 13가지의 다이어그램이 있다. 자세한 사항은 다음에...)

1. 사용케이스 다이어그램

사용 케이스는 시스템에서 제공한 기능 단위를 설명한다. 사용 케이스 다이어그램의 주요 목적은, 다른 사용 케이스들 간 관계 뿐만 아니라 주요 프로세스에 대한 "액터(actors)" (시스템과 인터랙팅하는 사람)들과의 관계를 포함하여, 개발 팀들이 시스템의 기능적 요구 사항들을 시각화 하는 데 있다.
사용 케이스 다이어그램에 대한 사용 케이스를 보여주려면 다이어그램 중간에 타원을 그려서, 타원의 중앙 또는 아래에 사용 케이스 이름을 적어놓는다. 사용 케이스 다이어그램에 액터(시스템 사용자)를 그리려면 다이어그램의 왼쪽이나 오른쪽에 사람 모양을 그려 넣는다.

2. 클래스 다이어그램

클래스 다이어그램은 다른 엔터티들이 서로 어떻게 관계를 맺고 있는지를 보여준다. 다시 말해서, 이것은 시스템의 정적 구조라고 할 수 있다. 클래스 다이어그램은 주로 프로그래머들이 다루는 구현 클래스들을 보여주는데 쓰인다.
다음 그림에서는 세 개의 섹션으로 클래스 다이어그램을 설명하고 있다. 위 섹션은 클래스의 이름을, 중간 섹션은 클래스의 애트리뷰트를, 가장 아래 섹션은 클래스의 연산("메소드")을 보여주고 있다.

3. 시퀀스 다이어그램

시퀀스 다이어그램은 특정 사용 케이스에 대한 상세한 흐름이나 심지어는 특정 사용 케이스의 일부분 까지도 보여준다. 대부분이 설명을 포함하고 있다. 시퀀스에서 다른 객체들 간의 호출관계를 보여주고 있고, 다른 객체들로의 다른 호출까지 상세하게 보여줄 수 있다.
시퀀스 다이어그램은 2차원으로 그려진다. 수직 차원은 발생 시간 순서로 메시지/호출 시퀀스를 보여주고 있다. 수평 차원은 메시지가 전송되는 객체 인스턴스를 나타내고 있다.

4. 스테이트 챠트 다이어그램

스테이트 차트 다이어그램은 클래스가 개입된 다양한 상태(state)를 모델링 하고 그 클래스가 상태간 어떻게 이동하는지를 모델링 한다. 모든 클래스는 상태를 갖고 있지만 각각의 클래스가 스테이트 차트 다이어그램을 가질 수 없다. "중요한" 상태, 말하자면 시스템 작동 중 세 개 이상의 잠재적 상태가 있는 클래스일 경우만 모델링 되어야 한다.

다음 그림에서 보듯, 스테이트챠트 다이어그램에는 다섯 개의 기본 엘리먼트들이 사용된다. 시작점(짙은 원), 스테이트 간 이동(화살표), 스테이트(모서리가 둥근 직사각형), 결정 포인트(속이 비어있는 원), 한 개 이상의 종료점(원 내부에 짙은 원이 그려져 있음)이 바로 그것이다. 스테이트챠트 다이어그램을 그리려면 시작점과 클래스의 초기 상태를 향하는 화살표로 시작한다. 다이어그램 어디에나 이 스테이트를 그릴 수 있고 스테이트 이동 라인을 사용하여 연결한다

5. 액티비티 다이어그램

액티비티 다이어그램은 액티비티를 처리하는 동안 두 개 이상의 클래스 객체들 간 제어 흐름을 보여준다. 액티비티 다이어그램은 비즈니스 단위 레벨에서 상위 레벨의 비즈니스 프로세스를 모델링 하거나 저수준 내부 클래스 액션을 모델링 하는데 사용된다. 내가 경험한 바로는 액티비티 다이어그램은 기업이 현재 어떻게 비즈니스를 수행하는지, 또는 어떤 것이 비즈니스에 어떤 작용을 하는지 등의 고차원 프로세스를 모델링 할 때 가장 적합하다. 액티비티 다이어그램은 언뜻 보기에 시퀀스 다이어그램 보다는 덜 기술적이기 때문에 비즈니스 마인드를 가진 사람들이 빠르게 이해할 수 있다.

액티비티 다이어그램의 표기법은 스테이트 차트 다이어그램과 비슷하다. 스테이트 차트 다이어그램과 마찬가지로 액티비티 다이어그램은 초기 액티비티에 연결된 실선으로 된 원에서 시작한다. 이 액티비티는 모서리가 둥근 직사각형을 그려 그 안에 액티비티 이름을 적어 넣으면서 모델링 된다. 액티비티들은 이동 라인을 통해 다른 액티비티들에 연결되거나 결정 포인트의 조건에 제약을 받는 다른 액티비티들에 연결하는 결정 포인트로 연결될 수 있다. 모델링 된 프로세스를 종료하는 액티비티는 (스테이트 차트 다이어그램에서처럼) 종료 포인트에 연결된다. 이 액티비티들은 수영 레인으로 그룹핑 될 수 있다. 이것은 실제로 액티비티를 수행하는 객체를 나타내는데 사용된다.

6. 컴포넌트 다이어그램

컴포넌트 다이어그램은 시스템을 물리적으로 볼 수 있도록 한다. 이것의 목적은 소프트웨어가 시스템의 다른 소프트웨어 컴포넌트들(예를 들어, 소프트웨어 라이브러리)에 대해 소프트웨어가 갖고 있는 종속 관계를 보여주는 것이다. 이 다이어그램은 매우 고급 레벨에서 볼 수 있거나 컴포넌트 패키지 레벨에서 볼 수 있다.

컴포넌트 다이어그램의 모델링은 이 예제에 잘 설명되어 있다. 다음 그림은 네 개의 컴포넌트인 Reporting Tool, Billboard Service, Servlet 2.2 API, JDBC API를 보여주고 있다. Reporting Tool에서 출발하여 Billboard Service, Servlet 2.2 API, JDBC API로 가는 화살표는 Reporting Tool이 이들 세 개의 컴포넌트에 종속되어 있음을 나타낸다.

7. 전개 다이어그램

전개 다이어그램은 하드웨어 환경에 시스템이 물리적으로 어떻게 전개되는지를 보여준다. 목적은 시스템의 다양한 컴포넌트들이 어디에서 실행되고 서로 어떻게 통신하는지를 보여주는 것이다. 다이어그램이 물리적 런타임을 모델링 하기 때문에 시스템 사용자는 이 다이어그램을 신중하게 사용해야 한다.

전개 다이어그램의 표기법에는 컴포넌트 다이어그램에서 사용되던 표기법 요소들이 포함된다. 이외에 노드 개념을 포함하여 두 가지 정도 추가되었다. 노드는 물리적 머신 또는 가상 머신 노드(메인프레임 노드)를 표현한다. 노드를 모델링 하려면 3차원 큐브를 그려 큐브 상단에 노드 이름을 적는다.

원저자 : Donald Bell : IT 전문가, IBM Global Services.