장군이는 홍군

앞서 언급한 링크에서 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. 사용케이스 다이어그램

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.

UML의 시초는 1994년 Rational Software社의 James Rumbaugh, Grady Booch, Ivar Jacobson이라고 한다.
Rational Software는 Object Oriented의 일가를 이루었던 회사인데, 현재는 IBM에 합병되어 있다.
1996년에 이 세사람의 주도하에 UML partners라는 국제 조합이 결성되었고 1997년 1월에 OMG에 UML 1.0 규격을 제출했다고 한다.

UML에 대한 공식적인 자료는 아래 링크에서 찾아 볼 수 있다.
http://www.uml.org

검색엔진에서 UML로 검색한 결과에 IBM에서 작성해 놓은 한글 페이지가 있다.
처음 읽을 때 좋을 듯 하다.
http://www.ibm.com/developerworks/kr/library/769.html

OMG에서도 유용한 자료는 많이 찾을 수 있다.
http://www.omg.org

UML은 Unified/Universal Modeling Language의 약자로, wikipedia에는 다음과 같이 설명되어 있다.

소프트웨어 엔지니어링 분야에서 UML은 개체(Object)를 표현하기 위한 표준화된 시각적 규격 언어이다. UML은 범용의 모델링 언어로써, 그림 기호를 사용해서 대상이 되는 시스템의 추상화된 모델(이를 UML모델이라 한다)을 만든다.

(In the field of software engineering, the Unified/Universal Modeling Language (UML) is a standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.)

개요(General Description)

UML은 공식적으로 OMG(Object Management Group)의 UML metamodel에서 Meta-Object Facility metamodel(MOF)로 정의되었다. 다른 MOF기반의 규격처럼, UML은 소프트웨어 개발자들이 좀 더 개념과 구조에 집중하도록 만들어졌다. UML로 표현된 모델은 변환기를 이용해서 다른 형태(자바 등)로 자동 변환이 가능하며, 여기에는 OMG에서 제공하는 QVT와 같은 변환 언어가 있다.

UML은 프로파일과 스테레오타입을 이용해서 변형/확장이 가능하다.

프로파일을 이용한 확장의 의미가 UML 2.0의 주요한 개정 사항이다.

(UML is officially defined at the Object Management Group (OMG) by the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, UML has allowed software developers to concentrate more on design and architecture^{[citation needed]}.

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG.

UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 2.0 major revision.)

P.S. 역시나 번역은 어렵다는 생각을 다시 하게 만든다.

      하지만 번역이 어려운 첫번째 이유는 UML에 대해서 잘 모르기 때문이다.

      Wikipedia의 참조문은 이것으로 마치고 이 다음부터는 제대로 된 공부를 시작해 보자.