MDSE (Model Driven Software Engineering) 란 정확히 무엇입니까?

나는 오늘 infoq의 약어 MDSE 와 맞서게 되었다.

MDSE는 소프트웨어 엔지니어가 요구 사항, 아키텍처 및 디자인 정보가 최대로 정보의 "엔트로피"로 정렬되고 보존되는 추상화 수준에서 작업 할 수 있도록하는 것입니다. ( "디자인 작업 제품"이라고 부릅니다). 또한 MDSE는 엔지니어에게 주로 "디자인 작업 제품"이라는 용어를 사용하여 디자인을 검증하고 검증 할 수있는 수단을 제공해야합니다.

그리고 분명히, 모든 사람들이 그것을하고 있습니다 : (기사에서 다시)

우리는 MDSE 시대가 시작되었습니다. 향후 5 ~ 10 년 내에이 기간이 끝날 무렵 소프트웨어의 60 ~ 80 %가 모델 기반 기술을 사용하여 설계 될 것으로 예상되는 한도 내에서 MDSE 로의 상당한 변화가있을 것입니다.

MDSE가 무엇인지에 대한 구체적이고 전문적인 설명이 필요합니다. Rational Rose를 사용하여 90 년대와 마찬가지로 UML 상자를 작성하고 코드를 생성합니까?

(그 동안 누군가가 그러한 기술을 사용하여 생성 된 소프트웨어의 예를 가지고 있다면, 구체적인 예를보고 싶습니다).

"모델 기반 소프트웨어 엔지니어링 (MDSE)"은 소프트웨어 툴 제조업체에서 소프트웨어 모델의 상당 부분을 "곧"생성 할 수 있다는 마케팅 약속입니다.

의 인터뷰 파트너 당신이 다스 려하는 문서 , 로버트 하우 (참조 도구 제조 업체입니다 http://www.verum.com/을 세부 사항)

그러나 공구 제조업체의 약속에 따라 mdse는 아직 주류가되지 못했습니다.

hybris 인터넷 쇼핑 시스템은 "MDSE"의 작업 예이다 : 당신과 같은 XML-모델 파일을 유지 developper 소프트웨어 ( "* -items.xml")와 codegenerators / 통역 생성 DB-MODELL / 자바 코드에 대한 지속성 / GUI를 그것에서. 추가 속성이 필요한 경우 xml-model에 속성을 추가하고 생성기 / 인터프리터가 작업을 수행 한 후 속성을 사용하여 비즈니스 로직을 구현할 수 있습니다.

IMHO "모델 주도 "는 특히 "개발"대신 "디자인"또는 "소프트웨어 엔지니어링"과 같은 유행어와 함께 사용될 때 큰 과장입니다. "소프트웨어 디자인"이라는 오해를 가진 일부 사람들에 의해 발명 된 것은 아마도 건축가가 집의 청사진을 그리는 것과 같이 "그래픽"은 UML을 사용하여 주로 그래픽 모델을 그리는 것입니다. 청사진을 따라. (이것이 왜 틀렸는 지 여기에 설명하지 않아도되기를 바랍니다. 의견이 다른 경우 Jack Reeves의 "Code as Design"을 먼저 다운로드하기 전에 읽으십시오.)

이것은 5 년 동안 컴퓨터 공학을 공부했지만 실제 프로그래밍 경험은 최대 반년에 불과한 "건축가", "비즈니스 분석가", "디자이너", "소프트웨어 엔지니어"라고 부르는 사람들에게 훌륭한 정신 모델입니다. ), 코딩없이 "소프트웨어 디자인"을 포함하는 소프트웨어 산업에서 일자리를 찾고 있습니다. 이것이 바로이 "모델 중심"유행어가 그렇게 인기있는 이유라고 생각합니다.

실수하지 마십시오. 보일러 코드를 수동으로 작성 해야하는 필요성을 줄이기위한 모델 및 코드 생성기의 팬입니다. 예를 들어 데이터베이스와 같은 일부 제한된 영역에서 (데이터) 모델은 실제로 도메인 사용자와 통신하는 데 유용한 도구가 될 수 있습니다. 모델별로 구성 요소 간 데이터 흐름을 스케치하는 것은 소프트웨어 시스템에 구조를 가져 오는 데 가장 중요한 기술 중 하나입니다 (불행히도 UML 사람들 은 데이터 흐름 다이어그램을 표기에 포함하는 것을 잊어 버렸습니다 . 대신 중복되고 불필요한 항목을 추가했습니다) 아무도 실제로 사용하지 않습니다).

그러나이 모델을 "모델 중심의 소프트웨어 엔지니어링"이 아닌 "모델 지원 소프트웨어 개발" 이라고 부릅니다. 이는 모델링이 주요 활동 자체가 아니라 개발의 주요 활동 만 지원한다는 점을 분명히 밝힙니다.

이것은 많은 뚱뚱한 모델, 마른 컨트롤러 개념을 상기시킵니다 .
이 개념의 주된 아이디어는 가능한 한 많은 비즈니스 로직을 모델에 넣고 컨트롤러와보기를 매우 단순하게 유지하는 것입니다.
개인적으로, 나는 이것을 사용할 기회가 없었지만 매우 흥미로운 아이디어를 발견했습니다.
놀랍게도 Google 검색의 상위 10 개 링크 중 8 개가 이에 대해 말합니다.
그러나 모델을 단일 클래스가 아니라 여러 내부 클래스의 정면으로 생각하면 비즈니스 논리를 모델에 유지하는 것이 좋습니다.