장군이는 홍군

지난 번에 올린 UML의 개요를 통해서 UML이란 것이 대략 어떤 형태를 가지고 있는지 "눈팅"정도만 해 보았다.

내가 작성을 하면서도, 각 다이어그램들이 명확히 구분되거나 용도가 정확하게 파악되지는 않았다.

그리고 다이어그램이 UML에서 갖는 중요도가 어느 정도인지도 모르는 것은 당연하고...

이제부터는 UML의 공식 문서를 가지고 공부를 시작하겠다.

앞서 관련 링크 부분에서 언급했듯이 OMG에서 공식 문서를 받을 수 있다.

OMG UML 사이트

그런데 들어가 보니 문서가 하나가 아니다.

UML에도 Infrastructure/Superstructure 두가지가 있고,

Metamodel이니 XMI, Diagram Interchange 등등 관련된 것들도 많다.

일단은 Infrastructure/Superstructure 두가지 문서만 받아보자.

"두가지만"이라고 했지만 각각이 1.6MB, 6MB에 달하는 방대한 양이다.

머 200 페이지, 700 페이지 짜리이니 웬만한 소설책보다 두껍다.

그리고 소설책보다 재미 없다.

게다가 대충 대충 읽어서는 않되는 것 아니냐...

엥기니어들 책 안 읽는다고, 무식하다고 깔보지 말자.

맨날 보는게 저런 스펙들이다.

책이란거에 이가 갈리는 사람이다...

각설하고,

일단 이런 방대한 문서를 볼 때 한숨부터 나오지만, 안 볼 수는 없다.

그러면...

1. 좀 더 안락한 생활(?)을 위해 필요한 최소한의 투자라고 생각하자.

2. 천재가 아닌 이상, 그냥 읽어댄다고 다 이해가 가능하지도 않고 외우는 것은 더더욱 불가능하다.

   좀 더 효율적으로 공부를 하자.

- 일단은 문서가 두개인데, 왜 두개일까? 무엇부터 봐야 할까?

   스펙을 다운받은 곳에 친절하게도 이런 안내가 있다.

Beginning with UML 2.0, the UML Specification was split into two complimentary specifications: Infrastructure and Superstructure. The UML infrastructure specification defines the foundational language constructs required for UML 2.1.2. It is complemented by UML Superstructure, which defines the user level constructs required for UML 2.1.2. The two complementary specifications constitute a complete specification for the UML 2 modeling language.

   User Level Construct라는게 뭔지는 아직 잘 모르겠지만, Infrastructure를 먼저 읽어야한다는 소리인지는 알겠다. (다행히 200 페이지짜리 ㅎㅎ)

- 우선 Infrastructure의 목차를 보면서 상상의 나래를 펼쳐보자~~

1. Scope

2. Conformance

3. Normative References

4. Terms and Definitions

5. Symbols

6. Additional Information

7. Language Architecture

8. Language Formalism

9. Core::Abstractions

10. Core::Basic

11. Core::Constructs

12. Core::PrimitiveTypes

13. Core::Profiles

1~6까지는 대부분의 문서 서두에 나오는 부분이다. 문서를 이해하는데 도움이 될 수 있도록 설명하거나 약속해 두는 것들이니 한번 읽어보면 된다. 아는 부분은 가볍게 넘어가 주고 모르는 부분은 한번 자세히 읽어봐주면 되는...

이름으로는 7~8에 기본적인 사항이 들어가 있겠다.

9~13까지는 Core::으로 공통된 부분이 있는 것으로 보아 개별적으로 자세한 설명이 되어 있을 듯하다. 그런데 왜 Core일까? 그리고 거기에 Abstractions/Basic/Constructs/PrimitiveTypes/Profiles의 5가지가 있군....흠흠...이런 의문을 가지고 읽어 나가면 될 듯.

참고로 내가 보고 있는 문서의 버전은 v2.1.2임.

[출처] [UML.5] 체계적으로 UML 공부하기|작성자 dimalion

앞서 언급한 링크에서 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.

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의 참조문은 이것으로 마치고 이 다음부터는 제대로 된 공부를 시작해 보자.

S/W를  개발할 때마다 느끼게 되는 어려움은,

어떻게 하면 생각을 효율적으로 정리할 수 있을까 라는 것이다.

효율적이라함은,

표현하기가 쉬워야 하고,

이해하기 쉬워야 하고,

구현하기 쉬워야 한다는 뜻이다.

하지만 막상 실천을 하려고 보면, 매우 어렵다는 것을 느끼게 되는데,

그 이유는 위의 3가지 원칙이 서로 상충하는 부분이 많기 때문이다.

비록, "쉽다"는 공통된 형용사를 썼지만, 속뜻은 서로 다르기 때문이다.

첫번째의 "표현하기 쉬워야 한다"의 "쉽다"는 말 그대로 쉽다는 의미이다.

생각을 표현하는데 제약이 적고, 수정하기 쉽고, 많은 노력/시간이 필요하지 않고, 심지어는 이 과정을 통해 생각을 정리하고 보완할 수 있다면 더욱 좋을 것이다.

두번째의 "이해하기 쉬워야 한다"의 "쉽다"는 체계적이어야하는 의미이다.

아무리 복잡한 생각이라도 핵심은 간단하게 표현이 되어 있어야 하며, 세부사항은 자세하게 설명이 되어야 한다. 읽기에 거부감이 없어야 하고, 핵심을 빠르게 파악하며, 원하는 사항에 빠르게 접근할 수 있어야 한다.

세번째의 "구현하기 쉬워야 한다"의 "쉽다"는 명확하다는 의미이다.

실제 구현을 하다보면 이런저런 예외 사항이 나타나게 마련이다. 생각의 큰 개념에서는 아주 미미하지만 구현하는 입장에서는 명시되지 않았다면 매우 난처한 상황이다.

그리고 이런 부분이 명시되지 않은 상황에서 임의로 구현이 되고, 임의로 구현된 것들이 점점 많아지면, 애초에 정리된 생각과 구현된 것과는 전혀 딴판의 결과를 가져 올 수 있다.

즉, 빠짐 없이 명확하게 기술하되, 간단하게 기술하면서도 체계적이어야 하므로 어렵지 않을 수 없는 것이다.

이러한 고민으로 인해, S/W개발과 관련해서 많은 이론, 방법론, 도구들이 만들어졌다.

이제 알아볼 UML은 이러한 고민을 해결하기 위해 고민하다 찾아낸 한줄기 빛이다.

아직은 모르지만 과연 이 빛이 나의 고민을 해결해 줄 수 있을지 알아보도록 하자.

[출처] [UML.1] UML의 시작|작성자 dimalion