현재 많은 회사에서 소프트웨어에 대한 전략적인 가치가 증가됨에 따라 산업계에서는 소프트웨어
생산의 자동화, 소프트웨어의 시간과 비용을 절감, 소프트웨어의 질을 향상시킬 수 있는 기술을
모색하고 있다. 이러한 기술들로 현재 부상하고 있는 것이 컴포넌트 기술, 시각적(Visual) 프로그
래밍, 패턴(Pattern)과 프레임워크(Framework) 등이 있다.
업무의 처리과정에서 그 업무의 범위와 규모가 커짐에 따른 시스템의 복잡성을 처리할 필요성을
느끼게 되었다. 특히 물리적인 시스템의 분산, 동시성(Cuncurrency), 반복성(Replication), 보안,
결점보완, 시스템들의 부하에 대한 균등화(Load balancy)와 같은 반복해서 발생하는
구조적 문제 대한 처리가 필요하게 되었다.
추가적으로 웹의 발전에 따라 시스템을 만들기는 쉬워졌으나 이러한 구조적 문제는 더욱 악화되었다.
UML은 이러한 모든 필요성에 의해 만들어졌다.
UML은 소프트웨어 시스템이나 업무 모델링(Business Modeling) 그리고
기타의 비 소프트웨어 시스템등을 나타내는 가공물(Artifact)을 구체화(Specifying)하고,
시각화(Visualizing)하고, 구축(Construction)하고, 문서화(Documenting)하기 위해 만들어진 언어이다.
UML은 복잡하고 거대한 시스템을 모델링함에 있어 성공적으로 증명된 공학적인 경험들을 포함하고 있다.
UML은 Rational Software와 그의 동료 회사에 의해 개발되었다.
UML은 OMT, Booch, OOSE/Jacobson에서 발견되는 모델링 언어의 장점을 계승하였다.
그리고 대부분의 회사들이 표준으로 제정된 UML을 가지고 그들의 개발 프로세스에 적용하고 있다.
이러한 개발 프로세스들은 업무의 모델링과 요구의 관리, 분석과 디자인, 프로그래밍과 테스트를
모두 포함하고 있다.
▶ 모델링의 중요성.
강력한 소프트웨어 시스템을 만들기 위해 구축(Construction)하고 개선(Renovation)하기에 앞서
모델을 만드는 것이 건물을 만들기 위한 청사진 만드는 것과 같이 핵심적인 요소이다.
잘 만들어진 모델은 프로젝트 팀간의 통신수단으로써 그리고
구조적인 문제를 해결하기 위한 수단으로써 핵심적인 것이다.
시스템의 복잡성이 증가함에 따라 좋은 모델링을 하기 위한 기술은 더욱 중요하게 되었다.
성공적인 프로젝트에서의 성공요소는 여러가지가 존재하지만 표준적이고 엄격한 모델링 언어를
가지는 것이 핵심적이다.
▶ 모델링 언어가 반드시 포함하여야 하는 것.
모델 요소(Model elelements) -> 기본적 모델링 개념과 의미
표기(Notation) -> 모델요소의 시각적인 그림
Guideline -> 관용적인 사용방법.
시스템의 복잡성이 증가함에 따라 시각화(Visualization), 모델화(modeling)가 핵심적인 사항이
되어가고 있다. UML은 이러한 필요성에 부응하기 위해 잘 정의되어져 있고 넓은 범위를 수용하도
록 되어있다. 결과적으로 객체지향 시스템과 컴포넌트 기반 시스템을 구축하기 위해 시각적 모델
링 언어를 선택하는 것도 필연적이다.
▶ UML의 목적
UML로 디자인함에 있어서 최우선 목표는 다음과 같다.
사용자에게 즉시 사용가능하고 표현력이 강한 시각적 모델링 언어를 제공함으로써 사용자는 의미
있는 모델들을 개발하고 서로 교환할 수 있다.
핵심적이 개념을 확장할 수 있는 확장성과 특수화 방법을 제공한다.
특정 개발 프로세스와 언어에 종속되지 않는다.
모델링 언어를 이해하기 위한 공식적인 기초를 제공한다.
객체 지향 툴 시장의 성장을 장려한다.
콜레버레이션(Collaboration), 프레임워크(Framework), 패턴(Pattern)과 Component와 같은 고수준
의 개발 개념을 제공한다.
▶ OMG-UML의 범위
UML은 소프트웨어가 중심이 되는 시스템을 나타내는 가공물(Artifact)을 구체화되고 시각화하고,
문서화하기 위한 언어이다. 이러한 특징을 가진 UML의 범위를 다음의 세가지로 요약할 수 있다.
첫째로 UML은 Booch, OMT, OOSE의 개념을 융화 시켜서 만들었기 때문에 그 결과는 사용자나 다른
어떤 방법론에도 일반적이고 유일하며, 넓게 사용될 수 있다.
둘째로 UML은 기존의 방법론들을 가지고 있는 어떠한 작업에도 적합한 방편을 제공한다.
예를 들면 UML 저자들은 동시에 발생하는(Concurrent), 분산된(Distributed) 시스템의 모델링을 UML의 목표로 삼았다.
셋째로 UML은 표준적인 방법론에 역점을 두지 않고 표준적인 모델링 언어에 역점을 두었다.
이와 같이 표준 방법론을 제시하지 않는 이유는 서로 다른 문제 영역에 대해 서로 다른 방법론을 요구하기 때문이다.
그래서 표준적 언어로의 UML은 첫째로 일반적인 메타모델(Metamodell)과 둘째로 일반적인 표기
(Notation)에 노력이 집중되었다. 하지만 UML에서도 사용사례유도(UseCase Driven)의, 구조중심
(Arcitecture-centric)의, 반복적인(Iterative), 점진적인(increment) 개념을 방법론에 적용하도
록 권장하고 있다.
▶ UML의 범위 외부
UML은 모든 것을 포함하는 언어가 아닌, 단순하고 표준화된 모델링의 제공을 목표로 하고 있다.
이러한 점이 산업계 전반에 걸쳐 존재하는 다양한 시스템의 디자인에 UML이 사용될 수 있는 유연
성을 제공한다.
▶ 프로그래밍(Programming) 언어
UML은 비주얼 모델링 언어이지 비주얼 프로그래밍 언어가 아니다. 하지만 UML은 어떤 의미에서는
비주얼 모델링 언어가 제공하는 모든 시각적이고 의미적인 모든 지원을 가지고 있다. UML은 소프
트웨어가 중심이 되는 시스템을 나타내는 가공물(Artifact)을 구체화되고 시각화하고, 문서화하
기 위한 언어이다. 하지만 UML은 실제 코드로의 지향을 위해 사용될 수 있다. 예를 드어 UML은 객
체 언어와 밀접하게 묶여 사용이 가능하고 이것은 최고의 결과를 낼 수 있다.
▶ 툴(Tools)
표준화 된 언어는 툴과 방법론을 위한 기본을 제공한다. OMG RFP(Request For Proposal) 의 목적
은 툴들 상호 운용성(Interoperability)에 목적을 둔다. 이러한 툴 들의 상호 운용성은 UML이 제
공하는 것과 같이 견고한 의미(Semantic)와 표기의 정의에 의존하고 있다. 즉 UML은 툴들의 상호
운용성을 위해 툴인터페이스, 저장방법(Storage), 실행시간 모델(run-time model)등과 같은 방법
을 제공하는 것이 아니라 의미적 메타모델(Metamodel)을 제공한다.
▶ 방법론(Process)
세계 많은 업체들이 그들의 프로젝트 산출물(Artifact)을 위한 일반적인 언어로 UML을 사용할 것
이다. 하지만 이들 업체들은 상이한 방법론에 동일한 UML 다이어그램을 사용하게 될 것이다. 즉
UML은 의도적으로 방법론에 독립적인 언어로 만들어졌고 또한 표준화된 방법론을 정의하는 것이
UML이나 OMG RFP의 목적이 아니다.
▶ UML의 기원과 어떻게 UML이 OMG의 표준이 되었는가
객체지향적 분석과 디자인에 대해 다양한 방면으로 실험적인 접근을 하던 방법론자들에 의해서
1970년 중반부터 1980년대까지 주목할 만하고 다양한 객체지향 모델링 언어가 나타나기 시작했
다. 1989년에서 1994년까지 확연한 모델링 언어가 적게는 10개미만에서 많게는 50개 이상으로 증
가하게 되었다. 객체 지향의 방법론을 사용하는 많은 사용자들이 하나의 모델링 언어에서 완벽하
게 만족을 찾기 위해 많은 논쟁이 있었다. 이를 방법론전쟁(Method War)이라 한다. 1990년대 중
반부터 이러한 방법론들이 새로운 모습으로 나타났고 이러한 방법론들이 서로 다른 방법론의 기술
들을 융합하게 되었다. 그 결과 몇 개의 특출한 방법론들이 드러나게 되었다.
UML의 개발은 1994년 후반에 Grady Booch와 Jim Rumbaugh에 의해 그들의 방법론인 Booch와 OMT의
통합으로 시작되었다. 1995년 가을 Ivar Jachobson이 소속된 회사 Objectory와 Rational과 병합되
면서 통합의 노력이 있었고 이에 Jacobson의 OOSE 방법론이 통합되었다.
Booth, OMT, OOSE의 주요 저자인 Grady Booch, Jim Rumbaugh, Ivar Jacobson는
다음의 세가지 이유로 통합된 모델링 언어를 만들게 되었다.
첫째, 각각의 방법론들이 이미 각자 독립적인 발전하고 있었다.
각자 방법론에서 사용자에게 혼란을 일으킬 불필요한 부분을 제거하여 같이 발전하는 것이 더 이치에 맞았다.
둘째로 완벽한 의미와 표기의 통일로써 안정된 객체지향 시장을 형성할 수 있다.
또한 프로젝트에 완벽한 모델링 언어를 제공하고 툴들에게 더 나은 특징을 제공하게 된다.
셋째로 각자의 방법론이 서로 보완하여 더 나은 발전을 이룰 수 있고 각자의 방법론이 해결
할 수 없는 문제를 해결할 수 있도록 도와준다.
이들 세사람이 통합을 하기 위해 먼저 그들은 다음의 4가지의 목표를 두고 노력을 기울였다.
객체지향 개념을 이용하여 소프트웨어 영역 뿐만 아니라 소프트웨어가 아닌 영역의 시스템도 모델
링 할 수 있게 한다.
실행 가능하거나 개념적인 산출물들을 명확하게 결합할 수 있게 만든다.
복잡하고 프로젝트 성공여부에 민감한 시스템들에 준하는 논점에 역점을 둔다.
인간이나 기계에 모두 유용한 모델링 언어를 만든다.
Booth, Rumbaugh, Jacobson은 1996년 6월에 UML 0.9를 내놓았고 10월에 0.91의 문서를 내놓았다.
1996년내에 UML저작자들은 여러가지 피드백을 받았고 이를 반영하게 되었다.
Rational은 UML을 표준 모델링 언어로의 확정을 위한 노력도 들였다.
1995년 초 Ivar Jacobson(Objectory의 기술담당 대표)과 Richard Soley(OMG의 기술 담당 대표)는
방법론의 시장에 표준으로 정하기 위한 어려운 노력을 시작하였다.
이러한 노력의 결과 1995년 6월에 쟁쟁한 방법론자들이 참석한 OMG의 주요 회의에서
OMG의 비호아래 방법론의 표준으로 제정되었다.
1996년 한 해동안 몇몇 기구에서 그들의 사업에 UML을 전략적인 도구로 보기 시작하였다.
OMG에 의해 제공된 RFP(Request For Proposall)가 몇몇 기구들에게 그들의 의견을 많이 반영시킬 수 있
도록 촉매제로서 제공되어졌다. 이에 Rational은 몇 개의 기구들과 함께 UML 파트너 협회를 만들
었고 강력한 UML1.0을 만들기 위한 다양한 정보를 제공하게 되었다.
이러한 모든 원조들의 UML1.0에 반영되었다. 이러한 협력업체로는 다음과 같다.
Digital Equipment Corp, HP, I-Logix, Intellicop, IBM, Icon Computing, MCI Systemhouse,
Microsoft, Oracle, Rational Software, TI, Unisys.
이러한 협력들이 잘 정의되었고 표현력이 강하고 강력하고, 일반적인 언어인 UML1.0를 만들게 되었다.
이것은 결국 1997년 1월에 OMG에 의해 RFP의 응답으로 받아들여지게 되었다.
1997년 1월에 IBM, Objectime, Platinum Technology, Ptech, Taslson, Reich Fechnologies and Softeam은
OMG에 개별적으로 RFP에 대한 응답을 제출했다.
이러한 회사들은 자신들의 의견을 반영하기 위해 UML협회에 참여하게 되었고, 결과적으로 UML은 1.1로 개선되었다.
UML1.1의 중점사항은 UML의 의미적인 무결성을 추구하고 새로이 참여한 회사들의 의견을 반영하는 것에 있었다.
결국 UML1.1은 1997년 가을에 OMG에 제출되었고 표준으로의 인정을 받았다.
▶ UML의 현재와 미래
UML은 한 회사에 독점적이지 않고 모두에게 개방되어 있다. 이것은 일반 사용자나 과학단체의 필
요성을 겨냥하여 나왔고 또한 기존의 주요한 방법론의 경험에 기초하여 만들어졌다.
많은 방법론자들과 협의체, 툴 업체들로 UML을 사용하기에 동의했다.
UML은 Booth, OMT, OOSE와 기타 주요한 방법론들과 유사한 의미론과 표기를 바탕을 만들어졌고
또한 여러 회사들의 폭 넓은 의견을 반영되었기 때문에 매우 직접적이다.
UML에서 목표로 하는 통합(Unified)의 의미로 다음의 두 가지 면을 가지고 있다.
기존의 방법론들의 다양한 모델링 언어들 사이의 사소한 차이를 끝내는 것이다.
여러 종류의 시스템(소프트웨어와 업무) 사이의 관점과 개발 단계(요구 분석, 디자인, 구현) 내부
적인 개념의 통합을 의미한다.
UML은 매우 상세한 언어로 정의 되어 있음에도 불구하고 미래의 모델링 개념으로 발전에 대한 벽
은 존재하지 않는다. 우리는 아주 많은 앞서가는 기술에 관심을 두고있다. 이러한 모든 기술이
UML의 차후 버전에 반영되기를 바랄 것이다. 앞서가는 많은 기술이 UML을 기초로 정의 될 수 있
고 또한 이러한 UML의 확장으로 UML의 핵심이 변화되는 일은 없을 것이다.
현재의 상황으로 보면 UML은 시각적 모델링을 위한, 시뮬레이션을 위한, 개발 환경으로써 많은 툴
들의 기본이 될것으로 기대되어진다. 통합개발 환경이 개발됨에 따라 UML을 기초로한 구현은 점
점 더 많이 늘어날 것이다.
▶ The Meta Object Facility
OMG MOF의 핵심 목적은 CORBA의 인터페이스 집합을 제공하는 것이다. MOF는 CORBA기반의 분산 개
발 환경구축에 있어서 핵심적인 단위이다.
MOF는 분산 객체의 환경에서의 객체 저장소, 객체 모델링 툴, 메타데이타 등의 영역에서 진행중
인 작업을 통합적으로 표현한 것이다. MOF의 스펙은 UML 표기를 이용한다. MOF의 인터페이스와
의미들은 실제 상업적인 객체 저장소, 모델링 툴들, 객체의 프레임워크 제품들에 의해 구현된 메
타데이터 관리의 앞서나가는 개념들을 포함하고 있다.
MOF의 스펙은 일반적으로 분산 객체의 환경에서, 특수하게 분산 개발 환경에서 메타데이타의 호환
성(Interoperability)과 메타데이타의 관리적인 측면을 강화하고 있다.
이러한 강화의 초기작업으로 객체분석과 디자인의 영역에서 메타데이타의 호환성을 강화하고 있고
이것은 앞으로 추가적인 영역을 제공하기에 충분할 것으로 기대되어진다.
OMG는 이러한 추가적인 영역을 담당할 수 있는 새로운 RFP를 기대한고 있다.
'소프트웨어공학 > UML이야기' 카테고리의 다른 글
| 3. B Usecase Discription (0) | 2009.05.26 |
|---|---|
| 5. Sequence Diagram (1) | 2009.02.06 |
| 4. Class Diagram (0) | 2008.10.26 |
| 3. A. Usecase Diagram (0) | 2008.06.23 |
| 2. UML의 구성 (0) | 2008.06.16 |
