트윗 에서 William Cook 은 다음과 같이 썼습니다.
" UML은 MDD에있어 최악의 일이다. 다행히도 많은 사람들이 이것을 깨닫고있다. "
나는 그 주장에 대한 추론을 알고 싶습니다.
나는 많은 사람들이 UML을 좋아하지 않는다는 것을 알아 차렸다. 또한 UML이 효과적인 디자인과 모델링의 성배가되는 학계에 있다고 언급 할 가치가 있습니다.
답변:
글쎄, 나는 원래 트윗을 게시 한 학계입니다. 트윗은 학술 기사가 아닙니다. 그들은 광고이며, 나는 또한 논란의 여지가 있다고 생각합니다. 내 후속 트윗은 다음과 같습니다.
1) OO 설계를 모델링하기 위해 UML이 작성되었습니다. 시스템 동작이 아니라 시스템 코드를 모델링하는 데 영향을줍니다. UML의 레벨이 잘못되었습니다.
2) UML의 7 (또는 13) 다이어그램 형식이 모든 것을 포괄 할 수 있다는 생각은 미쳤다. GUI, 웹 와이어 프레임, 권한 부여 등은 어떻습니까? ???
3) UML은 모델이 그래픽이어야한다는 아이디어를 장려했다. 어리석은! 텍스트 및 그래픽 모델은 유용하고 종종 상호 교환 가능
4) UML은 한 번에 너무 크고 복잡하며 동시에 매우 제한적입니다. 스테레오 타입 및 프로파일은 사용 가능한 확장에 효과적이지 않습니다.
UML이 반드시 나쁜 것은 아닙니다. 나는 그것이 "모델 중심 개발"의 목표를 돕는 것이 아니라고 말하는 것입니다. 이것은 제가 관심있는 것입니다. "거룩한 성배"에 대한 의견을 이해하지 못합니다.
UML은 스크루 드라이버와 망치를 가져다가 함께 두드리고 "범용 고정 도구"라고 부르는 것과 같습니다. 이론적으로 그것은 하나의 도구라고 주장하는 제대로 통합되지 않은 수많은 도구를 실제로 표현하는 데 사용될 수 있습니다. 따라서 적절한 도구를 시작하는 것보다 하나의 작업을 수행하는 것이 훨씬 어렵습니다.
MDD가 UML에서 일어난 최악의 일이라고 생각하는 경우도 있다고 생각하지만 (우리가 가진 UML2를 가진 이유는 무엇입니까?)
MDD = 모델 중심 <디자인 | 개발>. 아이디어는 문제 영역에 적합한 추상화 수준에서 솔루션을 개발할 수 있도록하는 것입니다. 즉, 솔루션을 표현하기위한 가장 자연스러운 구문으로 문제에 대한 솔루션을 표현하려는 시도입니다. 문제 영역 자체는 운영 모델, 즉 컴퓨터에서 실행할 수있는 모델로 특징 지어집니다. 따라서 MDD는 두 가지 주요 요구 사항이 있지만 매우 매력적인 접근 방법이 될 수 있습니다.
UML2 노력이 포인트 1을 해결하기 위해 의도되었다는 것을 이해하고 있습니다. 아마도 UML에 대한 산업 경험이 포인트 2가 문제 영역의 일부 하위 집합에 대해 만족되었다고 생각했을 것입니다. 불행히도, 이것이 윌리엄 쿡이 얻은 것이라고 생각하는 UML은 생각 된 문제의 범위 근처에서 2 지점을 만족시키지 않습니다. 개인적인 경험으로는 말할 수 없지만 UMD와 함께 MDD를 사용하는 산업 경험에는 두 가지 공통적 인 결과가 있다고 생각합니다.
두 경우 모두 MDD의 약속은 이행되지 않습니다. UML은 MDD 도구 개발자가 실제로 작동 할 수있는 모델 (소규모의 소프트웨어 문제에도 불구하고)을 배제하기 위해 MDD 도구 개발자의 관심을 끌기 때문에 MDD에서 발생한 최악의 것으로 간주 될 수 있습니다.
UML은 모델링 언어 인 한 훌륭합니다. 그래픽 뷰를 얻기 위해 MDD를 UML에 연결하려고하면 쓸모가 없습니다. MDD가없는 UML뿐만 아니라 UML이없는 MDD도 좋습니다.
UML과 MDD가 더 이상 함께 살지 않기 위해 오늘 이혼했다고 가정 해 봅시다.