UML

1 정의

Unified Modeling Language의 약어.

수학적인 문법과 구성으로 이뤄진 프로그래밍 언어와는 달리 UML은 모델링 언어이다. 다시말해 설계도를 그리기 위한 언어라는것. 학교다닐때 실과나 기술시간에 간단한 건물 도면 기호에 대해 배운 기억이 있다면, 그런 건축 도면과 유사하게 정해진 기호로 구조를 설명할 수 있도록 하는 언어라고 보면 된다. [1]

기원은 Rational 사의 Grady Booch, James Rumbaugh에 의해 1994년 10월에 처음 개발에 착수되었다. 이후 1995년 10월에 Unified Method 0.8의 명칭으로 OOPSLA '95에서 발표되었으며, 이후 Ivar Jacobson이 UML 개발에 함께 협력하면서 1996년에 버전 0.9를 발표하였고, 1997년 11월에는 UML 1.1 이 OMG[2]에 의해 표준으로 채택되었다.

2005년에 UML 2.0이 발표되었으며 현재 2011년에 발표된 UML 2.4.1 이 최신 표준이다. 2012년 10월에 진행중인 상태의 UML 2.5가 발표되었으며 여전히 진행중 상태.

2 적용 분야

- 컴퓨터 비지니스 설계
- 자동차 개발 [3]
- 항공기 개발 [4]
- 원자력 발전소 [5] [6]

3 표준 문서

한국에 UML 관련 서적은 수십 종이 나왔으나, UML의 의미를 정확히 알고 설명하는 책은 없다. [7]
온전한 의미를 설명하는 책은 표준 문서와 기호학 서적[8]을 참조하시기 바란다.
표준 문서는 전부 1000~2000 페이지 분량이며, 현재도 계속 개량되고 있기 때문에 실용서가 아닌 해설서는 없다.[9]

- UML Infrastructure: 미칠 듯이 어렵다
- UML Superstructure: 어렵다

4 파생 표준 및 언어

- OMG SysML (System Modeling Language)
- OMG UML Testing Profile외 약 20여가지 모델링 언어
- AUTOSAR (AUTomotive Open Software ARchitecture)
- EAST-ADL (Architecture Modeling Language) 시리즈
- MATLAB / Simulink
- 각종 Visual based Languages

5 용도

개발 용이성이라고 하는데, 연구하는 사람이 봐도 용이함과는 거리가 멀다. 기본적으로 사람은 의사소통, 기계는 검증을 위해서 사용한다.

5.1 용도 1: 컴퓨터용 물건이 아니다

사실 UML은 단순한 모델링 언어라서, 이것을 소프트웨어 개발 방법론으로 보기는 힘들다. 단지 개발 방법론에서 고객과 개발자 또는 개발자와 개발자간의 의사소통 도구로 사용될 뿐이다. 그런데 UML이 대한민국에 처음 알려지기 시작한 시점에서는 UML 개발방법론따위의 단어가 대학교 정식 학부과정중에 있을 정도였다[10]. 어떻게 보면 대단히 부끄러운 이야기인데, 한국에서는 개발방법론이나 프로그램 아키텍처에 대해 사람들이 진지하게 파고들기 시작한 기간이 그렇게 길지 못하다. 그만큼 한국에는서 프로그래밍에 대한 인식은 "어떻게 하면 설계를 잘해서 좋은 결과물을 만들것인가"에 대한 고민이 없었다는것. UML은 컴퓨터 프로그래밍을 위해서 개발된 것은 아니다.

5.1.1 옳은 부분

미드 Numb3rs의 시즌3, 에피소드 17인 "One Hour"에서 이를 다루고 있다. 아이의 유괴범이 아이를 납치하였고, 이동을 계속해 FBI가 찾기를 힘들어하는데, UML 다이어그램을 이용해서 유괴범이 이동할 최종 목적지를 추측해낸다. [11]

5.1.2 반론

각 도메인의 개발 방법에 간섭하는 것은 한 두해로 끝날 수 있는 일이 절대 아니다. 아직 컴퓨터 분야의 DB 모델링 분야는 UML 통합을 시도도 못하고 있다. [12] 실질적으로 이것을 중요하게 써먹는 곳은 컴퓨터 프로그래밍 분야 밖에 없다. [13] 한국의 컴퓨터 분야의 문제가 아니라, 일을 어떻게 하고, 결과물을 어떻게 낼지 고민을 못하는 대학 교육의 문제이다.

5.2 용도 2: 하지만 컴퓨터 및 전자 분야에서 사용한다

UML을 두루 사용하는 쪽은 주로 SI 업체에 근무하던 사람들이다. 정확히는 비지니스 프로세스 개발 분야에 특화되어 사용, 발전되었으며, 개발 요구 사항은 이들에 맞춰져 구성되었다. 이론적으로는 모든 것을 표현가능하나, 기본적으로 배우기 어렵다는 문제 때문에 [14] [15] 아직 널리 퍼지지 못하고 있다.

5.2.1 컴퓨터 분야에서의 효용성에 대해

일단 UML을 도입하면 이런 효과를 기대해 볼수 있다.

  • 개발 기획과 산출물에 대한 확실한 증거. UML이 소프트웨어의 설계도를 그리기 위한 물건이다보니 UML을 그렸으면 그린대로 만들고 그린대로 동작하면 일단 그 설계는 성공한 것으로 본다. 하지만 실제 설계된 대로 돌아가고 설계된 대로 돌아가게끔 하는것은 쉽지가 않기에 이런 부분은 전문적인 아키텍터가 붙어서 해결한다. SI업체의 경우 업체별로 각자 업무흐름이 있으니 다 똑같지는 않지만, 한번 UML을 그리면 관련된 모든 사람들에게 설계문서를 돌려 도장을 찍고 그대로 만들겠다는 계약서를 쓴다 카더라.그래도 나중에 변경사항 나오는건 어쩔수가 없다.
  • 프로그램 개발이라는 행위에 대해 전문가와 비전문가가 서로 대화할수 있는 도구. 일반적인 프로그램 언어와는 달리 도형으로 표현이 가능하기 때문에 프로그램에 대한 지식이 없는 사람도 프로그램이 제공해야할 기능과 구조를 표현하는게 가능하다. 물론, 비전문가가 설계하는 컨셉을 그대로 프로그램 언어로 옮길수는 없기에 일반적으로 개발을 요청한 쪽과는 UseCase정도만 사용해서 일을 하고 그 UseCase마다 구현을 위한 내용을 설계한다.

하지만 UML을 도입하면 이런 피곤한 일들이 생긴다.

  • 제대로 배운 사람이 없다: 기본적으로 모델링 분야는 컴퓨터 기반의 학문이 아닌 기호학에서 기반이 된 분야이다. 인터넷을 개발한 사람이 물리학자이고, MIT MediaLab 설립자가 건축학자이듯이 컴퓨터는 제대로 전공을 배운 사람이 없다. [16] 그리고 그리는 표준에 관련된 방법론을 책이 아닌, 제대로 익힌 사람은 더더욱 드물다...
  • 다양한 학문의 접점이라, 그리기는 쉬워도 적용하기는 어렵다: 모델은 기호학, 모델 변환 도구는 수학과 철학의 논리학 , 언어학 등이 결합된 부분이어서, 전문 개발 회사 이외에는 손대기... 매우 어렵다. [17]
  • 설계한 내용대로 구현이 불가능할때. 이럴때는 당연히 구현이 최선이기 때문에 설계를 무시하고 프로그램을 만들게 된다. 문제는 이렇게 설계외 구현을 하게되면 이 부분은 처음 설계문서에 반영이 되어야 하는데...개발일정에 쫓기다보면 그렇게 하기가 힘들다. 다행히도 요즘은 개발툴들[18] [19]이 많이 발전되어 소스코드와 UML을 상호 연관시켜 자동으로 갱신될수 있도록 해준다. [20]
  • 서류의 산. UML 설계문서는 정말 작정하고 그리기 시작하면 시스템 규모에 따라 틀리지만 그 양이 엄청나다. 그래서 이런 부분을 전문적으로 관리해주는 사람이 있다면 모를까 그렇지 않으면 개발자가 서류에 깔려죽는다.

그러한 이유로 요즘은 제대로 조직이 갖춰진 회사가 아니고서야 소규모 개발회사의 경우 단위기능별로 밑그림이 필요할때 정도만 사용한다.본격 개발자의 실용주의

대표적인 UML 파생 제품은 National Instrument사의 LabView를 이용해서 개발된 미군 무인전투기 프레더터가 있다. UML과 모델 기반 개발 방법의 채용을 통해 개발 비용 및 검증 비용을 절감하였다. [21] UML을 피상적으로 이해하고 사용하였던 F-35[22]는 개발자 부족으로 인해 개발언어를 Ada[23]에서 C++로 교체하다가... 세계 최고가의 비행기가 되어버렸다.

UML은 실제로 프로그램을 제작하는데 직접 사용되는 것이 아닌, 프로파일을 이용한 모델 기반 개발 (Model-based development)에 사용된다. UML은 모델 기반 개발 및 요구조건-개발-검증 단계를 명시한 V 프로세스의 핵심 부분이며, 전자 장비의 기능성과 안정성을 규정해 높은 IEC 61508, IEC 61508에서 파생된 자동차 세부 표준인 ISO 26262 및 기타 7가지 세부 개발 방법론, 자동차 개발 및 소프트웨어 구현 표준인 AUTOSAR 표준에서는 기본으로 사용한다.[24]
  1. ↑ 최초의 적용 분야가 프로그래밍이었던 것 뿐이다. 프로그래밍만을 위한 것이었으면 Programming Modeling Language가 더욱 적합한 표현이다. 의미상으로는 프로그래밍만을 위한 것이 아니다.
  2. ↑ CORBA 아키텍처를 만든 그곳
  3. ↑ 개발 프로세스 표준도 2011년에야 만들었다... 모델 기반 개발로의 전환은 2015년 이후에나 가능
  4. ↑ MATLAB/Simulink, LabView 등 사용
  5. ↑ 1차로 상태 모델 개발하고, 2차로 UML 등의 모델을 이용한 설계하고, 3차로 구현하고, 4차로 코드별로 까서 검증한다...
  6. ↑ 후쿠시마 발전소 폭발 사고에서도 프로그램은 정해진 설계대로의 성능을 발휘했다. 수소 기체를 안정화하기 위한 기기의 외부 전원을 연결하기 위한 콘센트 길이가 짧을 줄 누가 알았나. 물론 전선을 만들기만 하고 30년 동안 꼽는 시늉도 안했던 일본 정부 및 도쿄전력의 잘못이다.
  7. ↑ 번역의 질은 더더욱 기대하면 곤란하다.
  8. ↑ 솔직히 전문가는 컴퓨터 전공자가 아니라 수학자들이나 신부님들. 안 보이는 거 설명하느라 (21세기 수학은 다차원이라 그래프 못 그리고, 신학은 뭐...) 무진장 전문가라고 한다...
  9. ↑ 제대로 파고들 목적이라면 안되겠지만, 프로그램 개발 현업에서 쓸목적이라면 실용서 정도로도 적당하다.
  10. ↑ 실례를 하나 들어보면, 전통적인 정보공학방법론을 적용한 프로젝트에서 사용자 요구사항을 기술하기 위한 도구로서 UML을 채용했더니 정보시스템 감리가 UML을 사용하면 무조건 CBD방법론이니 CBD 방법론에 기반한 산출물을 추가로 작성하라고 강제한 사례가 있다.
  11. ↑ UML은 자세한 구조를 전부 표현하기 보다는 의사소통에 사용하는 것이 더 효율적이다.
  12. ↑ 관련 전문가들이 기존의 ER 다이어그램을 쓰지 UML을 쓰지 않는다
  13. ↑ 만들면 뭐하나. 쓰는 사람이 없는데...
  14. ↑ 정말로 어렵다. 이 쪽에서는 has / is도 엄격하게 구분해서 사용하는 단어이다.
  15. ↑ 그러나 두 객체의 관계를 구현하기 위해서는 결국 has인지 is인지를 어느 단계에서인가는 결정해야만 한다. 따라서 이는 has/is의 문제는 설계상의 어려움이지, UML표현의 어려움은 아니다. 물론 하위 개념들 중에는 구분하기 힘든 경우가 많기는 하다.
  16. ↑ 기간이 짧아서...
  17. ↑ 그리고 컴파일러 만들어서 큰 돈 벌은 회사는 없다. MS나 Oracle은 Lock-in 전략을 위해서 사용하지, 직접적인 매출을 위해서 개발하지 않는다. MS 홈페이지 들어가면 Visual Studio Community 버전 공짜로 받을 수 있다.
  18. ↑ 무진장 비싸다. 분야에 따라서는 정가가 아닌 제품에서 % 단위로 떼어간다
  19. ↑ 공개를 해버린 MS Robotics Development Studio는 순식간에 로봇 관련 중소기업들의 de facto 표준이 되었다
  20. ↑ 이론적으로는 모델 기반 개발은 최적화 작업을 죄악시한다. 후임 개발자가 손 댈 수 없으니까...
  21. ↑ 이론적으로는 개발 언어가 변경되더라도 언어 변환 어댑터만 교체하면 된다.
  22. ↑ 모델 기반 개발 분야의 재앙이라고 불린다. 재앙이라는 말은 구매처 소속인 미국 장군이 한 말이니 태클 지양 바람
  23. ↑ 미국방성 무기 표준 개발 언어
  24. ↑ 이들 모델은 UML을 직접적으로 사용하지 않고, 나름대로 변형된 모델을 사용하지만, UML 모르고서는 읽을 수도 없다. 물론 OMG에서 이들 표준 및 단체에 사용료 받는다.