UML (Unified Modeling Language, 통합 모델링 언어)

Development/UML 2012. 3. 6. 22:31

객체 지향 분석/설계용의 모델링 언어. 기존의 객체 지향 방법론과 함께 제안되어 모델링 언어 표기법의 표준화를 목적으로 한 것이다. 주로 미국의 래셔널 소프트웨어(Rational Software)사에서 방법론의 통일과 표준화 작업에 전념한 결과 1997년 11월에 UML 1.1이 객체 관리 그룹(OMG)에 의해 표준으로 채택되었다. UML은 방법론이 아닌 소프트웨어 개발에 사용되는 다이어그램을 정의하는 것으로, 소프트웨어 개발 시 산출물들을 비주얼하게 제공함으로써 개발자와 고객 또는 개발자 상호 간의 의사 소통을 원활하게 할 수 있으며, 산업계 표준으로 채택되었기 때문에 UML을 적용한 시스템은 신뢰성이 있다 



UML (Unified Modeling Language, 통합 모델링 언어) 는 시스템을 시각화하거나 시스템의 사양이나 설계를 문서화하기 위한 표현방법입니다. UML은 주로 객체 지향 프로그램의 구조를 나타내는데 사용되며, 클래스 다이어그램 (Class Diagram), 시퀀스 다이어그램 (Sequence Diagram) 등이 존재합니다.

1. 클래스 다이어그램

클래스 다이어그램은 클래스나 인스턴스, 인터페이스 등의 정적인 관계를 표현합니다.  

<클래스 다이어그램의 예>

 
각각의 클래스는 위 그림과 같이 표현할 수 있으며, 표현하는데 필요한 몇 가지 기호들이 존재합니다.

<클래스의 표현>


 클래스는 직사각형으로 표현합니다. 직사각형은 수평선으로 세개의 칸으로 분할됩니다. 첫번째 칸에는 클래스의 이름을 두번째 칸에는 필드의 이름을 쓰고 마지막 세번째 칸에는 메소드의 이름을 적습니다.

각각의 칸에는 이름 뿐 아니라 부가적인 정보를 적기도 합니다.

추상 클래스와 추상 메소드의 경우에는 이탤릭체를 사용합니다. static 필드와 static 메소드의 경우에는 밑줄을 사용합니다.

<상속 표현>


클래스간의 상속은 실선 화살표를 이용해 표시합니다. 화살표의 방향은 자식 클래스에서 부모 클래스로 향합니다.

<인터페이스, 집약의 표현>

 
점선 화살표는 인터페이스의 구현을 의미합니다. 화살표의 방향은 구현 클래스에서 인터페이스 방향으로 향합니다. 인터페이스를 표현하는 경우 <<interface>>와 같이 표현합니다.

마름모가 붙은 선은 집약 (aggregation) 을 의미합니다. 인스턴스를 갖고 있는 경우에는 두 클래스간의 관계는 집약입니다.

클래스 다이어그램에서 엑세스를 표현할 수도 있습니다.
  • +가 붙은 경우 : public
  • -가 붙은 경우 : private
  • #이 붙은 경우 : protect
  • ~이 붙은 경우 : 동일한 패키지 내에서만 사용할 수 있습니다.

2. 시퀀스 다이어그램

<시퀀스 다이어그램>


시퀀스 다이어그램은 프로그램이 작동될 때 어떤 순서로 실행되는지를 나타냅니다.

시퀀스 다이어그램의 가장 위에 있는 직사각형 안에는 인스턴스의 이름이 들어갑니다. 콜론 (:) 뒤에는 클래스의 이름을 표기하고 그 앞에는 인스턴스의 이름을 표기합니다. 만약 인스턴스의 이름을 따로 표기할 필요가 없을 경우에는 표기하지 않아도 상관없습니다.

인스턴스에서 아래로 뻗어있는 점선은 라이프 라인 (Life Line) 입니다. 시퀀스 다이어그램에서 시간은 위에서 아래 방향으로 흐릅니다. 라이프 라인 중간의 직사각형은 객체가 활동중임을 의미합니다.

각 객체 사이의 실선 화살표는 메소드의 호출을 점선 화살표는 메소드에서 리턴되었음을 의미합니다.


출처 - http://mutablearray.tistory.com/222

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

통합 모델링 언어(UML, 영어: Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어이다. 이 표준은 UML을 고안한 객체 관리 그룹에서 관리하고 있다.

UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다.

목차

  [숨기기] 

[편집]개요

통합 모델링 언어는 객체 지향 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다.[1] UML은 아래와 같은 사항을 포함하여 시스템의 구조적 청사진을 시각화 하는 표준안을 제공한다:

UML은 데이터 모델링(개체-관계 다이어그램)과 비즈니스 모델링(업무 흐름), 객체 모델링, 부품 모델링의 최선의 기술을 조합한다. UML은소프트웨어 개발 공정뿐만 아니라 다른 구현 기술의 모든 공정에서 사용될 수 있다. UML은 Booch 방법론의 객체 모델링 기법(OMT)와 객체 지향 소프트웨어 공학(OOSE)을 광범위하게 사용할 수 있는 단일한 공통 모델링 언어로 통합한다. UML의 목표는 동시적 분산 시스템을 모델링 하는 표준 언어다. UML은 산업의 실질적 표준으로서, 객체 관리 그룹(OMG)에 의해 개선되고 있다. 초기에 OMG가 엄격한 소프트웨어 모델링 언어를 만들기 위해 객체 지향 방법론적인 통지를 요청했고, 많은 산업 선구자가 UML 표준 제작을 돕기위해 진지하게 응답하였다.[1]

UML 모델은 객체 관리 그룹이 지원하는 QVT와 같은 변환 언어 등을 이용해 다른 표현(예를 들면 자바)으로 자동적으로 변환된다. UML은 확장할 수 있으며 커스터마이제이션을 위한 메커니즘인 프로파일 (UML), 스테레오타입 (UML)을 제공한다. 프로파일을 이용한 확장의 의미는 UML 2.0에서 개선되었다.

[편집]역사

UML은 그래디 부치(Grady Booch), 제임스 럼버(James Rumbaugh), 이바 야콥슨(Ivar Jacobson)의 머리에서 태어났다. 최근 “쓰리 아미고(Three Amigos-3인방)”이라고 불리는 이 세 사람은 80년대 전반 부터 90년대 초반까지 객체지향 분석 설계 분야에서 각자의 영역에서 방법론을 연구해 왔었다. 그들이 발표한 방법론은 동일한 분야의 다른 경쟁자들보다 항상 탁월한 위치에 있었으며, 세 사람은 90년대 중반에 이르러 각자의 아이디어를 교환하기 시작하였고, 결국 각자의 방법을 하나로 모아 합치기에 이른다.

1994년, 럼버는 부치가 세운 래셔널 소프트웨어(Rational Software Corporation)에 영입 되었고, 야콥슨은 그로부터 1년 후에 래셔널 사에 들어가게 된다.

나머지는 그들이 말하듯이, 역사(History)라고 말할 수 있다. UML의 초안(draft) 버전은 소프트웨어 업계를 뒤흔들기 시작했고, 그 결과로 돌아온 피드백은 바로 변경점에 반영되었다. “UML은 우리들의 전략에 딱 맞는다”라고 인식해 가는 회사가 늘어남에 따라 그 결과로 UML 컨소시엄도 발족하게 되었다. UML 컨소시엄의 멤버로는 디지털(DEC), 휴렛-팩커드(Hewlett-Packard), 인텔리캅(Intellicorp), 마이크로소프트(Microsoft), 오라클(Oracle), 텍사스 인스트루먼트(Texas Instruments), 래셔널 소프트웨어 등이 있었다. 1997년 UML 컨소시엄은 UML 버전 1.0을 만들어 내었고, 오브젝트 매니지먼트 그룹(OMG:Object Management Group)이 표준 모델링 언어의 제안서를 내라는 요구에 맞추어 이것을 제출 하였다.

UML 컨소시엄은 계속 발전하였으며, OMG에 다시 상정된 UML 1.1d은 1997년 말에 표준 모델링 언어로 채택되었다. OMG는 UML의 관리 기법을 받아들여 1998년에 새로운 수정안을 발표하였다. UML은 소프트 웨어의 업계 명실 상부한 표준이 되었으며, 계속 수정 보안되고 있다. 버전 1.3과 1.4 그리고 1.5가 나와 있고, 최근에는 버전 2.0이 OMG에 의해 승인된 상태이다. 이전 버전들, 즉 버전 1.X는 현존하는 대부분의 모델 및 UML 모델링 책의 기본이 되어 왔다.[3]

[편집]UML 구성요소

[편집]소프트웨어 개발 방법론

UML 그 자체는 개발 방법이 아니지만[4] 그 당시 주도적이었던 객체 지향 소프트웨어 개발 방법론(예를 들면 Booch 방법론, 객체 모델링 기법, Objectory)과 잘 어울리도록 설계되었다. UML 발전해 감에 따라서 UML의 장점을 취하기 위해 몇몇 다른 방법론(예를 들면 객체 모델링 기법)이 개선되었다. 또 UML을 기반으로 한 새 방법론이 만들어지기도 했는데 IBM 래셔널 통합 프로세스(RUP)가 가장 유명하다. 이 외에도 추상 방법론(Abstraction Method), 동적 시스템 개발 방법론 등 더 특수한 해결책이나 다른 목적을 달성하기 위해 설계된 UML 기반의 방법론이 많이 있다.

[편집]모델

모델은 이학 및 공학 분야에서 상당히 유용하게 쓰이는 개념으로서 가장 일반적인 의미로 말하면, "모델은 만들다"는 것은 잘 모르고 있는 것을 이해하는데 도움이 될 것으로 추측되는 어떤 것을 사용한다는 뜻이다. 어떤 분야에서는 이 모델의 일련의 수식(방정식)의 집합으로 정의되기도 하며, 다른 분야에서는 컴퓨터 시뮬레이션을 모델로 삼기도 한다.

UML의 여러가지 그래픽 요소는 하나의 큰 그림, 즉 다이어그램을 그리는데 사용된다. UML은 언어이기 때문에, 이들 그래픽 요소들을 맞추는 데에는 규칙이 필요하다. 다이어그램의 목적은 시스템을 여러가지 시각에서 볼 수 있는 뷰(View)를 제공하는 것이며, 이러한 뷰의 집합을 모델(Model)이라고 한다. 시스템의 UML 모델은 건물을 짓는 건축가의 스케일 모델과도 비슷하다고 말할 수 있다. UML 모델은 시스템 자체의 “목적 행동”을 설명하는 언어이다. UML 모델은 시스템의 “구현 방법을 설명하는 수단”이 아니다.

[편집]클래스 다이어그램

대부분의 사물은 자기만의 속성과 일정한 행동 수단을 지니고 있다. 이러한 행동을 오퍼레이션(Operation)의 집합으로 생각할 수 있다. UML에서는 두단어 이상으로 이루어진 클래스 이름은 단어 사이의 공백을 없애고, 각 단어의 처음 문자를 모두 대문자로 한다(예:Wikipedia). 속성과 행동의 이름 또한 마찬가지이지만, 가장 앞 단어의 처음 문자는 소문자로 한다(예:edit()).

[편집]비판

Wiki letter w cropped.svg 이 부분은 토막글입니다. 서로 지식을 모아 알차게 문서를 완성해 갑시다.

[편집]같이 보기

Umbrello UML Modeller 스크린샷.

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

통합 모델링 언어 (통합 모델링 언어 UML , 영어 : Unified Modeling Language)은 소프트웨어 공학 의 객체 모델링 을 위해 표준화 했다 명세 언어 이며, 그래픽 기술로 추상화 하여 시스템 의 모델 (UML 모델) 생성하는 일반 모델링 언어 이다.

최초 기의 버전은 합리적 에서 그라 디 · 부찌 , 이바노 야콥손 , 제임스 람보 3 명이 책정했다. 이 3 명은 쓰리 아미고스 라고있다. 현재 OMG(Object Management Group)가 관리하고있다. 소프트웨어 개발에서 소프트웨어를 이용하는 범용 모델링 언어로서 현재 가장 많이 보급되어있다. 2008 년 현재 최신 버전은 UML 2.1.1이며, ISO / IEC 19501:2005으로 UML 1.4을 표준화하고있다.

UML 2.0 이상에서는 13 종류의 그림 (다이어그램)을 필요에 따라書き分ける. 자주 사용하는 그림으로, 상태 다이어그램 시퀀스 다이어그램이있다. 특정 언어로 개발이 결정된 시점에서 클래스 다이어그램 과 유스 케이스 다이어그램 을 사용하는 경우가있다.

UML 2.0 다이어그램 체계 ( 클래스 다이어그램 으로 표현)

목차

  [ 숨기기 ] 

개요 [ 편집 ]

UML의 공식적인 정의는 Object Management Group (OMG)이 Meta-Object Facility (MOF)의 메타 모델을 사용하고있다. 다른 MOF 기반의 사양뿐만 아니라 UML 메타 모델과 UML 모델은 XMI 로 직렬화있다. UML은 소프트웨어 를 중심으로하는 시스템의 사양을 작성하고, 구상하고, 구축하고 문서화하기 위해 설계되었다.

UML은 소프트웨어 모델링뿐만 이용하는 것은 아니다. 비즈니스 프로세스 모델링 및 시스템 공학 모델링에 사용되고, 조직의 구조도를 표현하는데도 사용할 수있다. Systems Modeling Language (SysML)은 UML 2.0 프로파일로 정의된 시스템 공학을위한 도메인 특정 모델링 언어이다.

UML은 모델 기반 설계 (MDE) 및 모델 기반 아키텍처 (MDA) 같은 모델 기반의 기술이 발전하는 계기가되었다. 클래스, 구성 요소 일반화 집계 같은 개념의 시각적 표기법에 대해 업계의 합의를 얻게 된 것으로, 소프트웨어 개발자는 설계 및 구조 (아키텍처)에 집중할 수있게되었다.

UML 모델은 OMG 가 해당 QVT 같은 변환 언어를 사용하여 다른 표현 ( Java )에 자동으로 변환할 수있는 경우가있다.

UML은 확장성이 있고 프로파일과 스테레오 타입과 같은기구로 지정있다. 프로토 타입의 확장 의미론 은 UML 2.0에서 개선하고있다.

역사 [ 편집 ]

1994 년 합리 은 제너럴 일렉트릭 에서 제임스 람보 를 고용했다. 그 회사는 오늘 두 객체 지향 모델링 기법을 창출하게되었다. 그것은 랭보의 객체 모델링 기법 ( 객체 지향 분석 (OOA)의 일종)와 그라 디 · 부찌 의 Booch 법 ( 객체 지향 설계 (OOD)의 일종)이다. 랭보와 부찌 공동으로 그들의 기술을 통합하는 작업을 시작했다.

곧 이바노 야콥손 이 더해졌다. 객체 지향 소프트웨어 공학 (OOSE)의 개발자이다. 야콥손는 1995 년 자신의 회사인 Objectory AB 가 인수함으로써 합리에 합류했다. 이 3 명의 방법 주의자를 쓰리 아미고스 라고 부른다.

1996 년 합리적인 너무 다양한 모델링 언어가 존재하고 있다고 객체 기술의 채용이 지연될 것으로 판단하고 그들의 통합 작업을 개방형 통합 모델링 언어 개발에 방향 전환했다. OOPSLA '96에서 객체 기술 설계 경쟁 업체가 모여 이에 관한 토론이 진행되며 람보 OMT 표기법으로 사용되고 있던 사각형 클래스를 나타내는 기법이 부찌 구름 클래스를 나타내는 기법을 이겼다. 이 승리를 기념하여 람보가 조니 미첼 의 "Clouds"를 아카펠라 로 불렀다는 [ 필요 출처 ] .

쓰리 아미고스 기술 지도력하에 UML Partners는 국제 컨소시엄이 1996 년에 결성되어 통합 모델링 언어 (Unified Modeling Language, UML) 사양이 완성되고, OMG RFP에 대한 응답으로 제안되었다. UML Partners의 UML 1.0 스펙 초안이 OMG에 제시된 것은 1997 년 1 월이었다.같은 달 UML Partners는 Semantics Task Force를 결성 사양의 의미 론적 측면의 마무리와 다른 표준화 작업과의 정합 작업을했다. 그 결과는 UML 1.1로 OMG 1997 년 8 월에 제출되어 1997 년 11 월 채택되었다 [1] .

모델링 기법으로는 OMT 기법이 거의 답습되었다 (예를 들어, 클래스와 객체를 구형으로 나타내는 등). 부찌의 "구름"문법은 제외되었지만, 부찌 법에 특유한 저수준 설계 세부 정보를 설명하는 기능이 채용되고있다. 야콥손의 Objectory 에서 유스 케이스 다이어그램 이 채용되어 부찌의 구성 요소 그림 도 채용되었다. 하지만 의미 론적 통합이라는 관점에서 UML 1.1은 약하고, 그 점이 크게 개선된 것은 UML 2.0였다.

다른 객체 지향 기술의 개념을 UML 완만하게 통합하여 거의 모든 객체 지향 기법에 대응하는 것으로되어있다. 예를 들어, CRC 카드 (1989 년경, 켄트 벡 과 워드 커닝햄 이 고안) 및 Object Oriented Role Analysis Method (OORam)이 고려되고있다. 이외에도 당시의 다양한 객체 지향 기법이 기여하고있다. Tony Wasserman과 Peter Pircher의 "Object-Oriented Structured Design (OOSD)"기법, Ray Buhr의 "Systems Design with Ada"Archie Bowen 사례 및 타이밍 분석, Paul Ward 데이터 분석, David Harel의 "Statecharts"등 이다. 이 때, 그들은 실시간 시스템 영역을 커버하기 위하여려고하고 있었다. 결과적으로 UML은 단일 프로세스 응용 프로그램에서 분산 시스템에 이르기까지 다양한 공학적인 문제에 사용할 수있는 도구가 거대한 사양을 안게되었다.

통합 모델링 언어는 국제 표준 규격 이다. ISO / IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2로 규격화하고있다.

UML은 UML 1.1 이후에도 계속 진화하고있다. 몇 가지 사소한 버전 (UML 1.3, 1.4, 1.5) 버그 및 문제점을 수정한 것이지만, UML 2.0에서 크게 진화했다. 이것이 현재의 OMG 표준이다.

UML 2.0의 첫 번째 부분은 새 다이어그램 및 모델링 요소를 설명했다 고차 구조 (슈퍼 구조)이며, 2004 년 10 월 OMG가 채택했다. 다른 부분은 인프라라고, Object Constraint Language (OCL)와 그림의 관계를 나타낸 것이며, 순차적으로 채용되어 2005 년 11 월에 완성했다.UML 2.0 specification 최종 버전이 사용 가능하다고 선언, OMG의 형식 사양 라이브러리에 추가되고있다. UML 사양의 다른 부분으로UML 2.0 infrastructure , UML 2.0 Diagram Interchange , UML 2.0 OCL 을 채용하고있다.

2007 년 8 월 현재 버전은 2.1.1, UML 2.1 버전의 XMI 2.1 버전의 형태로 사용 가능하다. 그 XMI 2.1 파일은 OMG에서 구할 수있다. 2.2 버전은 현재 개발 중.

잘 알려진 UML 도구의 대부분은 UML 2.0의 대부분을 지원하고있다. 일부 그다지 사용되지 않는 기능을 구현하지 않을 수있다.

방법론 [ 편집 ]

UML 자체는 방법 (방법론) 대신 당시 주류였던 객체 지향 소프트웨어 개발 방법론 군 ( OMT , Booch 법 , OOSE / Objectory )와 호환되도록 설계하고있다. 다음 UML이 보급됨에 따라 그 기술을 새로운 그림을 이용하도록 변경하고있다. 또한 UML 기반의 새로운 수법도 등장하고있다. 잘 알려진 예로는 합리적인 통합 프로세스 (RUP)가있다. 이외에도 Abstraction Method, DSDM 등이 있으며, 각각 다른 목적을 전문하는 경향이있다.

UML 다이어그램 [ 편집 ]

UML 다이어그램은 시스템의 정적인 구조를 나타내는 구조도 및 시스템 동작을 나타내는 동작 ​​그림 으로 분류된다. 동작 다이어그램에서 개체 간의 메시지 교환에 주목한 것을 특히 상호 작용 다이어그램 이라고 부른다.

구조도 [ 편집 ]

KP-UML-Generalization-20060325.svg

KP-UML-Aggregation-20060325.svg

클래스 다이어그램 에 따르면일반화 관계 및 one to many 연관 (복합성)의 표현

구조 다이어그램은 시스템의 정적 구조를 모델로 표현한다.

클래스 다이어그램
시스템을 구성하는 클래스 (개념)과 그들 사이에 존재하는 관련 구조를 표현한다. 사용자 관점에서 시스템을 구성하는 물건이나 개념을 나타낸다.
복합 구조 다이어그램
컴포넌트 다이어그램
물리적 구성 요소 ( 파일 , 헤더, 라이브러리 , 모듈 실행 파일이나 패키지 등) 시스템의 구조를 표현한다.
배치도
하드웨어와 응용 프로그램의 관계를 나타낸 것.
객체 다이어그램
클래스를 구체화하여 생성된 개체 간의 관계를 표현한다.
패키지 다이어그램
패키지 간의 의존 관계를 그리는 방식으로 논리적 그룹핑을위한 다이어그램에서 클래스 다이어그램의 일부이다. 패키지는 관례적으로 디렉터리 구조과 같이 나타낼 수있다. 패키지 그림은 시스템을 논리적인 계층 구조로 분해하는 데 도움이된다.

동작 그림 [ 편집 ]

유스 케이스 다이어그램 예제
상태 차트 예제

동작 그림은 시스템의 동작을 모델로 표현한다.

활동 다이어그램
시스템과 같은 흐름을 기술하는 표기법 순서도의 일종이다. UML에서는 표기 흐름은 확인되지 않으며 사용자 측에 가까운 업무 흐름이나 완성에 가까운 함수의 흐름을 보여줄 수있다.
유스 케이스 다이어그램
시스템에 요구되는 기능을 사용자의 관점에서 보여줍니다. 유스 케이스 다이어그램을 활용하여 시스템의 전체 상을 개발자와 사용자가 함께 평가되기 쉽다. 이것은 완성된 시스템이 사용자의 요구에 맞지 않는다는 문제를 완화할 수있다.
상태 차트 ( 상태 다이어그램 , 스테이트 머신 다이어그램, 상태 기계 그림)
한 객체의 상태 (상태)에 착안하여 그 변화를 표현한 것.

상호 작용 다이어그램 [ 편집 ]

시퀀스 다이어그램 예제

상호 작용 다이어그램은 동작 그림의 일종이며, 객체 사이의 데이터 (메시지)를 전달 모델.

시퀀스 다이어그램
객체 간의 메시지 흐름을 시계열 로 나타낸다. 그림 속에 시간의 흐름이 존재하기 때문에 이벤트 발생 순서와 개체 사이의 생존 시간을 기술할 수있다.
통신 다이어그램 ( 공동 작업 그림 )
객체 간의 메시지 교환을 보여준다. 시퀀스 다이어그램은 달리 개체를 중심으로 기술한다.
UML2.x에서 일부 표기 변경과 함께 협업 다이어그램 에서 통신 다이어그램 로 명칭이 변경되었다.
상호 작용 개요도
타이밍 다이어그램

비판 [ 편집 ]

UML은 모델링 표준으로 널리 알려져 사용되고 있지만, 다음과 같은 문제점을 잘 지적된다.

  • 언어 비대 . UML은 불필요하게 커질 복잡 해지고 있다고 비판하는 경우가 많다 [2] . 많은 그림과 구성 요소로 이루어져있어 일부는 거의 사용되지 않고, 게다가 중복이다. 특히 UML 2.0이되고 나서위원회적인 해결책이 많아진 것으로, 이러한 비판이 늘고있다.
  • 학습 및 채용에 관한 문제 . 에 대한 비판도 관계하지만, UML 학습과 채용은 어려워지고있다 [3] .
  • 코드와 동기화 문제 . UML 모델링 자체의 아름다움보다 실제로 실행하는 시스템의 모델이 아니면한다. Jack Reeves 이것을 간결하게 "코드는 디자인이다"라고 나타내고있다 [4] . 이 개념을 추진, 소프트웨어 작성의 개선이 필요로하는 것이다. UML은 거기에서 소스 코드 및 실행 코드를 생성하는 도구도있다. 하지만 UML 2.0의 Action Semantics가 튜링 완전 여부는 분명하지 않기 때문에 충분하다고는 말할 수 없다.
  • 임피던스 부정합 . UML 다른 표기법과 비교해도 간결하고 효율적으로 시스템을 표현할 수있다. 따라서 개발자는 UML과 프로그래밍 언어 모두로 기술 가능한 솔루션을 중시하는 경향이 생긴다. 그러나 언어가 정통 객체 지향 언어가 아닌 경우, UML과 언어 사이에 공통점이 적기 때문에이 문제가 특히 커진다.
  • 외형의 일관성 느낌 . 임기응변으로 다양한 그림이 통합되어 있기 때문에 일관성이 없다는 비판도있다.
  • 팔방 미인 . UML은 범용 모델링 언어이며 다양한 구현 언어와 호환성을 달성하려고하고있다. 개별 프로젝트는 목표 달성을위한 설계 팀이 UML 사용 가능한 기능을 구별할 필요가있다. 한층 더 말하면, UML의 범위를 특정 영역으로 제한하는 방법은 완전히 공식화되지 않고, 그것도 비판의 대상이되고있다.

버트런드 메이어 와 에드워드 요돈 가 American Programmer 잡지에 쓴 'UML : The Positive Spin'라는 기사는 UML을 패러디 형식 (UML을 테마로 그 장점을 써야하지 않는 학생들이 쓴 논문이라는 모양)에서 엄격하게 비판이다. Eiffel Software 아카이브 사이트의 [2] .

관련 항목 [ 편집 ]

위키 미디어 공용은 통합 모델링 언어 와 관련된 범주가 있습니다.

각주 [ 편집 ]

[ 도움말 ]
  1. ^ UML Specification v 1.1 (OMG document ad/97-08-11)
  2. ^ A b Bertrand Meyer : UML : The Positive Spin , in American Programmer , 1997.
  3. ^ ACM 기사 "Death by UML Fever" 는 이러한 종류의 문제를 논하고있다.
  4. ^ The Code is The Design Slashdot Code as Design : Three Essays by Jack W. Reeves

참고 문헌 [ 편집 ]

외부 링크 [ 편집 ]

UML 도구 [ 편집 ]




 


'Development > UML' 카테고리의 다른 글

이클립스 UML 종류  (0) 2012.03.12
UML의 기초  (0) 2012.03.12
UML은 무엇을 위해 있는 것일까?  (0) 2012.03.07
StarUML 소개2  (1) 2010.12.07
StarUML 소개1  (0) 2010.12.07
Posted by linuxism
,

티스토리툴바