왜 모두 모델 중심 개발을하지 않습니까? [닫은]

저는 Model Driven Development의 진정한 신자이며 생산성, 품질 및 예측 가능성을 높일 가능성이 있다고 생각합니다. 볼 때 MetaEdit의 결과는 놀랍습니다. 네덜란드의 Mendix 는 매우 빠르게 성장하고 있으며 훌륭한 결과를 얻었습니다.

나는 또한 많은 문제가 있다는 것을 안다

• 생성기, 템플릿 및 프레임 워크의 버전 관리
• 모델 중심 개발에 적합하지 않은 프로젝트 (충분히 반복되지 않음)
• 더 높은 위험 (첫 번째 프로젝트가 실패하면 기존 개발보다 더 적은 결과를 얻습니다)
• 기타

그러나 여전히 이러한 문제는 해결할 수있는 것으로 보이며 혜택은 필요한 노력보다 중요합니다.

질문 : 모델 중심 개발을 고려하지 않은 가장 큰 문제는 무엇이라고 생각하십니까?

이 답변을 본인의 이해를 위해서뿐만 아니라 내가 작성하려는 일련의 내부 기사의 가능한 출처로 사용하고 싶습니다.

황금 망치가 없습니다. 한 도메인에서 잘 작동하는 것은 다른 도메인에서는 꽤 쓸모가 없습니다. 소프트웨어 개발에는 몇 가지 고유 한 복잡성이 있으며 마법 도구로는 소프트웨어를 제거 할 수 없습니다.

또한 코드 생성은 언어 자체 (또는 프레임 워크)가 MDD를 비교적 무의미하게 만드는 강력한 추상화를 허용 할 정도로 수준이 높지 않은 경우에만 유용하다고 주장 할 수 있습니다.

재미있는 질문! 나는 팬이 아니라는 것을 인정하지만 방금 제기 한 문제 중 일부에 맞는 프로젝트에서 모델 중심 개발을 여러 번 사용하려고했습니다.

내 이유 목록은 다음과 같습니다.

• 학습 곡선-모델링 도구가 너무 빠르게 발전하여 도구를 깊이 이해하는 엔지니어를 찾기가 어려워졌습니다. 나는 여전히 당신이 모델링 도구만큼이나 좋다는 것을 알았습니다. 분명히, 아래의 많은 문제들이이 한 가지 문제를 추적 할 수 있습니다. 도구가 너무 제한적이라고 생각할 때마다 충분히 알지 못할 수도 있습니다.
• 너무 구조적-개인적으로, 모델링 툴이 내가 설명하는 데 필요한 모든 것을 설명 할 수 없을 정도로 구조화되어있는 상황에 처해있었습니다. 도구 외부에서 모델의 일부 조각을 그리는 것으로 전환하면 사람들이 정보를 찾기 위해 도구 외부로 표류하기 시작하면 상황이 빠르게 쇠퇴합니다.
• 도구 조정 비용-코드를 자동 생성하려고 시도 할 때마다 도구가 올바른 것으로 생각되면 코드를 수동으로 재 작업했습니다. 몇 번 돌아 다니면이 문제가 줄어 들지만 처음 몇 번의 라운드에서 살아남 아야합니다. 나는 일반적으로 우리가 두더지를 치고 있다고 느꼈습니다-모델 만들기-> 코드 생성-> 코드 수정-> 모델 업데이트-> 모델 수정, 헹굼 및 반복.
• 모델 구성 관리-모델은 프로젝트의 많은 부분을 설명하기 때문에 어느 정도 수준에서 모델 CM은 빌드 된 코드보다 더 교차 절단됩니다. 모델링 파일을 분류하는 것은 그 자체로 예술입니다. 잘못하면 개발자 교착 상태 또는 사람들이 포기하고 코드에 따라 오래된 모델이 종종 사라집니다.
• 시장 출시 시간-소프트웨어 작업이 절실한 상황에서 명확한 문제가 발생했습니다. 프로젝트와 팀이 충분히 작은 경우 코딩 및 테스트에 시간을 소비 할 수있을 때 모델링 도구에서 시간을 낭비 할 이유가 없습니다. 모든 프로젝트가 그러한 투자를 요구할만큼 큰 것은 아닙니다.
• 실패 비용-프로젝트가 모델링 도구에서 벗어나는 것을 보았을 때 높은 실패 비용으로 인해 도구를 사용하려면 모든 개발자가 참여해야합니다. 그것은 훈련에 대한 큰 투자와 학습에 대한 실습이며, 누군가가 모델을 잘못 설정하면 비용이 많이 드는 실수입니다. 내 경험에 따르면 모델을 올바르게 만들려면 2 ~ 3 개의 릴리스가 필요할 수 있습니다. 따라서 많은 프로젝트가 이점을 실현할만큼 오랫동안 모델링 실수를 극복하지 못합니다.

이미 인용되었지만 No Silver Bullet 은 요점을 잘 설명합니다.

소프트웨어 엔터티의 본질은 데이터 세트, 데이터 항목 간의 관계, 알고리즘 및 함수 호출과 같은 연동 개념의 구성입니다. 이러한 본질은 이러한 개념적 구성이 많은 다른 표현 하에서 동일하다는 점에서 추상적이다. 그럼에도 불구하고 매우 정확하고 풍부합니다.

소프트웨어를 구축하는 데있어 어려운 부분은 소프트웨어를 표현하고 표현의 충실도를 테스트하는 것이 아니라이 개념적 구성의 사양, 디자인 및 테스트라고 생각합니다. 우리는 여전히 문법 오류를 만들고 있습니다. 그러나 그들은 대부분의 시스템에서 개념적 오류와 비교하여 모호합니다.

이것이 사실이라면, 소프트웨어 구축은 항상 어려울 것입니다. 본질적으로은 총알이 없습니다.

나중에 Brooks는 "자동 프로그래밍"개념에 대해 다음을 지적합니다.

거의 40 년 동안 사람들은 "자동 프로그래밍"또는 문제 사양 진술에서 문제를 해결하기위한 프로그램 생성에 대해 예상하고 글을 쓰고 있습니다. 오늘날 일부 사람들은이 기술이 다음 획기적인 기술을 제공 할 것으로 기대하는 것처럼 작성합니다.

파르 나스 용어는 주장이 아니라 의미 론적 내용에 대한 매력에 사용되는 것을 의미한다 "자동 프로그래밍은 항상있다, 즉 높은 수준의 언어로 프로그래밍을위한 완곡 어법 프로그래머에게 현재 사용할 수보다."

그는 본질적으로 대부분의 경우 문제가 아닌 솔루션 방법이며 사양을 제시해야한다고 주장합니다.

기본적으로 MDD는 이전에 사용했던 것보다 더 높은 수준의 언어로 프로그래밍하는 데있어 또 하나의 완곡 어라고 주장합니다.

그것은 더 높은 수준의 언어로 프로그래밍하는 것이 도움이 될 수 없다고 말하는 것은 아닙니다. 그러나 본질 문제는 동일하게 유지 : 훌륭한 도구 나 방법 훌륭한 언어가 하루의 끝에, 사용하는 방법에 상관없이 당신이 모든 문제를 통해 생각하고 문제를 해결해야합니다. Brooks가 말했듯이 " 이 개념 구성 의 사양 , 디자인 및 테스트 "와 같이 중요한 문제에 집중할 수 있도록 "퍼지"를 제거하는 것이 가장 좋은 도구 나 프로세스 입니다.

모든 프로그래밍이 객체 지향적이지는 않기 때문에 모든 MDD 도구가 기대하는 것 같습니다. UML 자체는 객체의 추정을 기반으로합니다. 물론 시퀀스 다이어그램을 사용하여 함수를 모델링 할 수 있지만 여러 번 서투른 것입니다.

나와 같은 프로그래머가 MDD보다 TDD로부터 더 많은 진보와 결과를 얻습니다.

Modeling! = Programming 때문입니다.

비용 / 이익은 비용 측면에서 너무 높았고 이익 측면에서는 충분하지 않기 때문입니다. 내가 MDD를 마지막으로 본 이후에 이것은 아마도 바뀌었을 것입니다. 그때 MDD를 어느 정도 능숙하게 할 수있는 도구에 대해 $ 6000 / seat (USD)를 지불해야합니다.

코드를 생성하는 함수를 충분히 설명하는 모델은 더 이상 모델로 유용하지 않기 때문입니다.

나와 같은 프로그래머가 높은 수준의 모델 만 사용하고 코드로 세부 사항을 해결하는 프로그래머가 있기 때문입니다. 모델링 소프트웨어와는 다른 방식으로 코드를 볼 수 있습니다.

이것이 제가 개인적으로 MDD를하지 않는 이유 중 일부입니다. 나는 그것에 노출되었지만 아무것도 나를 개종시킬 수 없었습니다. 어쩌면 나는 너무 오래된 학교입니다. 어쩌면 나는 너무 새로운 학교입니다 (무엇이든). 그것은 내가 스스로 지불 할 수있는 도구가 아닙니다.

Microsoft / Apple / Google이 추진하지 않습니다. :)

어떤 종류의 개발이 대중화되는지는 도구, 후원자 및 전도와 관련이 있습니다. 큰 후원자없이 무언가를 돌파하는 것은 매우 어렵습니다 (Ruby on rails는 예외이지만 Java / C # / Python에 비해 여전히 작습니다)

CASE, UML 등의 모든 모델링 도구에 영향을 미치는 간단한 법 때문에

프로그래머와 코드 사이에 들어가는 것은 비용이 많이 듭니다.

그렇게하면 적절한 컴파일러 / 인터프리터를 빌드해야합니다. 코드 생성기는 프로그래머에게 끔찍한 워크 플로와 끔찍한 피드백 (오류 메시지 등)을 초래합니다.

Domain Driven Design의 큰 통찰력 중 하나는 모델이 코드 외부에있는 것이 아니라 코드에 있어야한다는 것입니다.

궁극적으로 문제는 : 모델이 코드에 적합하지 않은 이유는 무엇입니까? 임베디드 개발을하고 있고 C로 고착되어 있거나 다른 플랫폼에 대한 코드를 생성해야하는 경우 코드 생성 비용이들 수 있습니다. 다른 모든 사람들에게는 일반적으로 코드 이외의 코드를 디자인하는 것보다 강력한 프로그래밍 언어와 더 나은 코드 디자인이 더 좋습니다.

• 혜택이 거의없는 거대한 번거 로움.
• 나는 항상 엣지 케이스와 이상한 것들을 마시고있는 것처럼 보이지만 마술은 결코 제대로 작동하지 않는 것 같습니다.
• OO는 총알이 아닙니다. 소프트웨어 생성 방법론을 OO에 적용한다고해서 실버가되지는 않습니다.

그러나 나는 일반적으로 엔터프라이즈 솔루션을 좋아하지 않습니다.

토론을했고 MDA를하고 싶지만 가장 큰 단점은 현재 도구 지원입니다. 나는 "런타임 모델 평가"라고 부르는 MDA 파생을 사용하고 있지만 나중에 더 자세히 설명합니다.

내가 아는 것처럼 MDA의 단점은 다음과 같습니다.

• 누락 된 리팩토링 지원 : MDA (일반 사용 사례 번호 1)를 사용하여 데이터 모델의 엔터티를 모델링하려고합니다. 내 모델이 UML 다이어그램이라고 말하고 변경하면 코드가 변경되지 않고 (적어도 생성 된 클래스) 더 나은 이름의 속성을 가진 여전히 작동하는 앱 대신에 많은 오류를 수동으로 수정해야합니다.
• 디버깅 지원 누락 : 일반적으로 모델에서 코드로의 변환은 일부 변환 언어를 사용하여 수행됩니다. 이것은 일반적으로 문제가되지 않지만 디버깅 할 때 생성하는 코드에 대해 걱정할 필요가 없으며 디버거가 변환 모델로 들어가야합니다. 대신 생성 된 코드로 들어가서 생성 된 코드가 아니라 변환이보기 좋게 나타납니다. 좋아, 우리는 그것을 인쇄 할 수는 있지만 최적의 세계에서 생성 된 코드는 컴파일러 아티팩트이며 디버깅 세션을 위해 편집기에서 열면 안됩니다 (이와 함께 살 수 있으며이 이론은 약간 이론적입니다. 그러나 MDA에 대한 한 가지 이유입니다)
• 코딩 된 모델은 쉽습니다. 다른 예제에서 모델은 일부 도메인 측면을 모델링 한 다음 코드로 컴파일 할 수 있습니다. 예, MDA이지만 대부분의 MDA 모델은 복잡한 구성 파일 일 뿐이므로 런타임시 쉽게 처리 할 수 ​​있습니다.
• 변환은 테스트하기 어렵습니다. 특수 IDE에서 변환을 사용하는 경우 IDE "컴파일러"에서 수행됩니다. 그러나 변환은 응용 프로그램 코드의 일부로 보여야하며, 따라서 응용 프로그램의 테스트 및 코드 적용 요구 사항도 고려해야합니다.

내가 현재 선호하는 것은 "런타임 모델 평가"입니다 (누군가 허용 된 이름을 알고 있다면 저를 밝히십시오). 내 엔터티는 일반적인 Java 클래스에 저장되며 앱을 시작할 때 읽은 주석으로 "모델링"하는 데 필요한 모든 것이 만들어집니다. 변형이 필요하지 않았습니다. 메타 모델을 제대로 이해하기가 조금 어려웠습니다.

다른 모든 것은 속성 파일 또는 계층 적 데이터를위한 XML로 수행됩니다. 모델이있는 경우 항상 계층 적이므로 XML로 표현할 수없는 모델링 할 수있는 것은 없습니다. 또한 작성해야 할 특수 모델 편집기가 필요한 경우 앱 실행시에도 작동하고 모델링 할 수있는 모든 것보다 앱을 구성 할 수있는 편집기를 만들 수 있습니다.

나는 사람들이 왜 MDD를하지 않는지 설명하기 위해 Fred Brooks의 No Silver Bullet을 사용하는 대부분의 사람들이 Brooks의 요점을 놓치고 있다고 생각합니다. 물론 최종 결론은 소프트웨어 개발에있어 실질적이고 본질적인 복잡성이 사라지지 않을 것이므로 MDD는이를 해결하지 못할 것입니다.

그러나 Brooks가이 본질적인 복잡성을 논의하는 한 가지 이유는 우리가 해결하려는 문제의 본질적인 복잡성을 다루지 않는 언어, 라이브러리 및 도구와 일반적으로 싸우는 데 소요되는 많은 시간과 비교하는 것입니다. 바로 이것이 바로 MDD가 빛을 발하는 곳입니다. 모든 퍼지를 없애고 실제 언어의 복잡성을 처리 할 수있는 맞춤형 언어, 모델 또는 기타 형식을 만듭니다.

따라서 이러한 관점에서 No Silver Bullet은 MDD에 투자해야하는 훌륭한 이유입니다. 즉, MDD 채택을 방해한다고 생각되는 문제가 아닌 경우 : 해결하려는 문제의 본질적 복잡성에 완전히 집중할 수있는 모델 중심 환경의 실제 개발은 훨씬 어렵습니다. 범용 언어로 문제를 직접 해결하면됩니다. 대부분 기존 MDD 툴링이 매우 복잡하기 때문입니다.

이것을 다음과 같이 비교하십시오 : C 컴파일러를 작성하는 것보다 C로 프로그램을 작성하는 것이 훨씬 쉽습니다. 문제를 해결하고 일반 언어로 크 러프를 처리하는 대신 다른 개발자를위한 MDD 환경을 만들려면 기본적으로 문제 공간에서 가능한 모든 크래프트 관련 문제를 해결하는 프로그램을 작성해야합니다. 꽤 도전적입니다.

내 지식으로는 MDE와 MDA는 임베디드 컨트롤러 개발자의 요구를 충분히 충족시키지 못한다. 모델을 사용하여 시스템을 설명 할 수는 있지만 임베디드 개발자가 모델을 신뢰하여 최상의 소스 코드를 제공 할 수 있다고 생각하지 않습니다.

개발자가 모델을 사용하여 Java 코드를 작성 / 업데이트하거나 Java 코드를 사용하여 모델을 작성 / 업데이트 할 수있는 Eclipse 용 플러그인이 많이 있습니다. 이것은 편리한 도구처럼 보입니다. 불행히도, 모든 개발은 ANSI / ISO C로 이루어졌으며, 내가 알고있는 플러그인이 없어서 같은 작업을 수행 할 수 있습니다.

또한 개발자가 모델에 코드를 이벤트 기반 HSM 또는 다른 디자인 패턴으로 다른 디자인 패턴 (또는 안티 패턴)으로 구현하도록 지시 할 수있는 방법은 무엇입니까? 알 수없는 디자인 패턴을 사용하도록 코드를 수동으로 업데이트하는 경우 모델에서이를 정확하게 묘사 할 수 있습니까?

모델에 맞지 않는 함수를 어떻게 구현합니까?

짧은 대답… 모델 주도형은 종종 코드 생성과 관련이 있고 코드는 취약하기 때문입니다. 우리가 필요로하는 것은 코드 제거와 모델 중심입니다.

일부는 황금 망치가 없으며 소프트웨어 개발이 본질적으로 복잡하다는 주장을 일축했다.

나는 그들에게 황금 망치가 없다는 것에 전적으로 동의하지만, 모델 구동이 황금 망치 또는은 총알의 탐구라고 생각하지 않습니다!

더 복잡하게 가고 싶습니다. 두 가지 종류의 복잡성이 있습니다. 하나는 유기적 또는 자연적 복잡성입니다. 비즈니스와 그 프로세스에 내재 된 복잡성이지만 의식적인 복잡성도 있습니다.

매일 매일 지시에 따라 시스템 지시에 들어간 복잡성. 의식적 복잡성-불필요한 복잡성-본질적으로 비즈니스 지향 코드를 사용하여 제어되지 않은 기술 코드를 조작 할 때뿐만 아니라 시스템의 구조와 균일 성이 부족하기 때문에 발생합니다.

오늘날 정보 시스템의 개발을 방해하고 실패와 허리를 유발하는 전체 복잡성은 의식적인 복잡성입니다. 제거 할 수있는 복잡성.

의식상의 복잡성은 낭비, 코드로 인한 낭비, 가치 감소, 불리한 변화, 불변 코드; 엄격한 최소값으로 줄여야하는 코드입니다.

그렇게하는 방법? 처음에는 작성하지 말고 생성하지 마십시오!

불변의 기술 코드가 필요합니다. 읽기 / 쓰기, 표시, 통신에 사용되는 코드… 데이터의 논리적 구조를 설명함으로써 모델이 들어오는 곳-관계형 방식으로 추가-모델은 표준 읽기 / 쓰기, 표시 및 통신의 일반적인 처리를 가능하게합니다. 데이터.

그것은 운영 체제와 마찬가지로, 하나를 사용하는 모든 프로젝트에 대해 다시 작성하지는 않습니다. 따라서 모델에 따라 소프트웨어의 변하지 않는 측면을 처리하는 기술 엔진이 필요합니다. 나는 그것을 AaaS (Architecture as a Service) 엔진이라고 부릅니다.

불필요한 코드는 불필요한 코드이므로 작성하지 않은 채로 둘 수도 있습니다.

따라서 작성해야하는 비즈니스 중심의 코드, 설계해야하는 비즈니스 중심 데이터, 설계 및 상상해야하는 사용자 인터페이스 및 경험이 필요합니다.

취약한 코드를 제거함으로써 코드보다 모델링 및 디자인에 훨씬 더 기반을 둔 소프트웨어 개발을위한 새로운 패러다임을 Architecture as a Service로 채택 할 수 있습니다.

나는 여러 가지 이유가 있다고 생각하지만 MDD가 대학의 교과 과정에 있지 않다는 것이 확실합니다. 일반적으로 가장 가까운 것은 모델링을 가르치는 과정이며 모델은 스케치로 유지됩니다 (검사, 코드 생성, 모델 수준에서의 디버깅 없음). 이“모델링”과정은 종종 UML을 소개하며 학생들은 생성 된 모델의 가치가 낮을 때 왜 그렇게 크고 복잡한 표기법을 배우는지 의아해합니다.

이것을 임베디드 하드웨어 개발자 나 학생들이 다른 경험을 얻는 제어 엔지니어와 같은 다른 엔지니어링 분야와 대조하십시오. Simulink 또는 Labview와 같은 도구를 사용하여 학생들은 모델을 그린 다음 코드를 생성하거나 적어도 시뮬레이션에서 실행할 수 있습니다.

과거에는 대학에서 컴파일러와 파서를 가르쳤지만 이제는 발전기를 만들고 DSL을 구현하는 방법을 가르쳐야합니다.

Model Driven Development는 코드에 대한 하향식 모델이기 때문에 의미가 없습니다. 모델에서 전체 실행 응용 프로그램을 만드는 것은 불가능하므로 MDD는 쓸모가 없습니다!

내가하는 일은 응용 프로그램의 골격을 만들기 위해 더 높은 수준의 추상화에서만 UML을 사용하는 것입니다. 패키지, 클래스 등을 만든 다음 즉시 Java 언어로 코딩하기 시작합니다.

2004 년에 모델링을 처음 시작할 때 Togethersoft, Omondo와 같은 도구와의 실시간 동기화가 실제로 유용하다는 것을 알았습니다. 최근 Omondo는 Java, 모델 및 데이터베이스 ID 간의 일종의 매핑 인 새로운 단계가 도입되었습니다. 정말 강력하고 내 프로젝트에서 잘 작동합니다.

내 UML 다이어그램은 이제 프로젝트 속도를 높이고 더 이상 쓸모가 없습니다 :-)

MDD는 또 다른 단계를 개발 프로세스에 추가하는데, 이는 좋은 모델이없고 시장에 대한 예측할 수 없거나 거의 부분적인 부분 솔루션이 가장 많은 상을받을 수있는 상황에서 단점입니다.

실행 가능한 비즈니스 프로세스 모델을 갖는 것은 성배입니다. 이론적으로는 프로그래머가 전혀 필요하지 않습니다. 실습에 따르면 MDE를 사용하면 실제 모델을 작동시키는 것이 코드 작성만큼 복잡하다는 것을 알 수 있습니다.

숙련 된 개발자에게는 ExecutableUML과 같이 귀찮게하는 것보다 UML에서 생성 된 클래스를 채우는 것이 훨씬 쉽다고 말하고 싶습니다. 반면, ExecutableUML의 경우 상당한 양의 컴퓨터 과학 지식이 필요하므로 비즈니스 관리자가이를 스스로 만들 수는 없습니다. 이론적으로 그는 단지 준비된 블록 (클래스)을 결합 할 것이지만 실제로 "접착제"가 문제의 원인입니다.

또한 MDE의 유용성은 구성 요소 재사용이 많은 시스템으로 제한됩니다.

MBSE-모델 기반 소프트웨어 엔지니어링이 더 적절한 용어입니다.

MBSE는 효과 점 솔루션 인 다양한 도구 문제를 해결하기 위해 다른 프로젝트 워크 플로가 필요합니다. DSML (도메인 특정 모델링 언어)은 이해 관계자와 검토하기위한 요구 사항을 효과적으로 전달하는 데 필요한 추상화 수준에 있어야합니다. 그런 다음 점점 더 세분화 된 수준의 정제를 통해 모델을 변환하여 결국 코드를 ​​생성해야합니다.

DSML 및 변환 / 생성 프로세스가 완전하고 올바르게 구현되면 아티팩트 생성 비용이 매우 낮아집니다. 그러나 디버깅 된 툴링 단계에 도달 할 때까지는 매우 고통 스럽습니다.

MDD의 성공 사례 대부분은 기존 툴링을 사용하여 유사한 제품이 연속적으로 생성되는 PLE (Product Line Engineering) 영역에 있습니다. 물론 많은 Java 코드 생성기는 MDD의 단순화 된 버전입니다. 일부 XML 입력 및 생성 된 코드 출력

당신은 썼습니다 :

나는 또한 많은 문제가 있다는 것을 알고 있습니다 ... 모델 중심 개발에 적합하지 않은 프로젝트 (충분히 반복되지 않음)

코드가 반복적이라면, 프로그래밍 언어를 잘못 선택했거나 잘못 사용하고 있습니다. 더 나은 언어를 사용하면 반복 할 필요가 없습니다. Ruby Active Record 라이브러리를 고려하십시오. 데이터베이스 테이블은 마이그레이션을 작성하여 작성됩니다. 다른 곳에서는 스키마 정의를 반복 할 필요가 없습니다. 테이블 열에 해당하는 데이터 멤버가있는 클래스를 정의 할 필요가 없습니다. 한 줄의 코드는 클래스를 테이블에 연결합니다.

나는 모델 중심 개발을 약한 프로그래밍 언어에 대한 복잡하고 비효율적 인 해결책으로 본다.