모델 기반 접근 방식인 MDA/MDD/MDSD를 사용하시나요?미래가 될까요?

https://stackoverflow.com/questions/21091

09-06-2019
|

문제

프로그래밍 언어는 역사상 몇 가지 (r)진화 단계를 거쳤습니다.어떤 사람들은 모델 중심 접근 방식이 차세대 혁신이 될 것이라고 주장합니다.openArchitectureWare, AndroMDA, Sculptor/Fornax Platform 등과 같은 도구가 있습니다.놀라운 생산성 향상을 약속합니다.하지만 처음에는 시작하기가 쉽지만 예상치 못한 일을 시도할 때 어느 시점에서 막히거나 프로젝트를 시작하는 방법을 알려주는 충분한 정보를 찾기가 매우 어렵다는 경험을 했습니다. 고려해야 할 사항이 많을 수 있습니다.

모델 기반 무언가에서 무엇인가를 얻는 중요한 통찰력은 모델이 반드시 멋진 그림이나 트리 모델 또는 UML의 집합은 아니지만 텍스트 설명일 수도 있다는 점을 이해하는 것입니다(예:상태 머신, 비즈니스 규칙 등).

당신은 어떻게 생각하며, 당신의 경험이 당신에게 무엇을 말해주는가?모델 중심 개발(또는 뭐라고 부르든)의 미래가 있습니까?

업데이트: 이 주제에는 별로 관심이 없는 것 같습니다.모델 기반 접근 방식에 대한 좋은 경험이 있거나 나쁜 경험이 있거나 그것이 전혀 흥미롭지 않다고 생각하는 이유가 있으면 알려 주시기 바랍니다.

해결책

도구가 더욱 정교해지고 더 많은 사람들이 MDD에 대한 경험을 쌓기까지는 시간이 걸릴 것이라고 생각합니다.현재 MDD에서 무언가를 얻으려면 상당한 투자를 해야 하므로 그 사용은 여전히 제한적입니다.

예를 들어 openArchitectureWare를 살펴보면 다음과 같습니다.매우 강력하고 기본적인 문서가 존재하지만 내부 작동에 대한 문서가 누락되어 있으며 문서화되지 않은 확장성에 여전히 문제가 있습니다. 아마도 Xtext 및 Xpand가 다시 작성되면 더 좋아질 것입니다.

그러나 이러한 제한을 무시하고 oAW를 사용하면 생성 자체가 매우 쉽습니다. Xtend 및 Xpand의 매력처럼 모델을 탐색할 수 있으며 여러 워크플로를 더 큰 워크플로로 결합하여 매우 복잡한 작업도 수행할 수 있습니다.필요한 경우 Java를 사용할 수 있으므로 모델을 사용하여 수행할 수 있는 작업에 매우 큰 유연성이 있습니다.oAW에서 Xtext를 사용하여 자신만의 DSL을 작성하는 것도 빠르게 완료되지만 기본적으로 메타 모델, 파서 및 매우 훌륭한 편집기를 무료로 얻을 수 있습니다.또한 기본적으로 어디에서나 모델을 얻을 수 있습니다.데이터베이스를 메타 모델로 변환할 수 있는 컴포넌트와 해당 모델을 큰 노력 없이 작성할 수 있습니다.

따라서 MDD에 대한 도구와 경험이 증가함에 따라 MDD는 여전히 구축되고 있다고 말하고 싶습니다.필요한 전문 지식이 있고 이를 회사 내에서 추진할 준비가 되어 있다면 이미 성공적으로 사용할 수 있습니다.결국, 많은 글루 코드(일명 복사 붙여넣기)가 생성될 수 있고 생성되어야 하기 때문에 이는 매우 좋은 일이라고 생각합니다.MDD를 사용하여 이를 수행하는 것은 재사용성을 촉진하는 매우 훌륭하고 구조화된 방법이라고 생각합니다.

다른 팁

부인 성명:저는 비즈니스 애플리케이션 개발자입니다.다음 견해는 확실히 엔터프라이즈 IT 분야에서의 나의 경험에 의해 형성되었습니다.나는 소프트웨어 개발에 다른 영역이 있다는 것을 알고 있습니다.특히 산업 및/또는 임베디드 시스템 개발에서는 세상이 다르게 보일 수 있습니다.

MDSD는 여전히 코드 생성에 너무 많이 묶여 있다고 생각합니다.

코드 생성은 코드에 노이즈가 많거나 매우 반복적인 경우에만 유용합니다.즉, 코드가 본질적인 복잡성에 주로 집중할 수 없고 우발적인 복잡성으로 오염된 경우입니다.

내 생각에는 현재 플랫폼과 프레임워크의 추세는 우발적인 복잡성을 제거하고 애플리케이션 코드가 본질적인 복잡성에 집중하도록 하는 것입니다.

따라서 이러한 새로운 플랫폼/프레임워크는 MDSD 운동의 돛에서 많은 바람을 불러일으킵니다.

DSL(텍스트)은 본질적인 복잡성에만 초점을 맞추려는 또 다른 추세입니다.DSL은 코드 생성을 위한 소스로 사용될 수 있지만 주로 코드 생성과 연결되지는 않습니다.DSL(특히 내부 DSL)은 기본적으로 런타임에 해석/실행되도록 열어줍니다.[런타임 코드 생성은 그 사이 어딘가에 있습니다].

그래서 DSL은 MDSD와 함께 자주 언급되기도 하지만 실제로는 MDSD의 대안이라고 생각합니다.그리고 현재의 과대광고를 고려하면 그들은 MDSD 운동의 추진력도 빼앗습니다.

코드에서 우발적인 복잡성을 궁극적으로 제거하려는 목표에 도달했다면(이것이 허구라는 것을 알고 있습니다) 비즈니스 문제의 텍스트 모델에 도달한 것입니다.이것은 더 이상 단순화될 수 없습니다!

멋진 상자와 다이어그램은 추상화 수준을 또 다른 단순화나 향상을 제공하지 않습니다!시각화에는 좋을 수도 있지만 그것조차 의심스럽습니다.그림이 항상 복잡성을 파악하는 데 가장 좋은 표현은 아닙니다!

더욱이, MDSD와 관련된 도구의 현재 상태는 또 다른 수준의 우발적 복잡성을 추가합니다(생각해 보세요:동기화, 비교/병합, 리팩토링 ...) 이는 기본적으로 단순화라는 궁극적인 목표를 무효화합니다!

내 이론을 설명하기 위해 다음 ActiveRecord 모델을 살펴보십시오.

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

나는 이것이 더 이상 단순화될 수 없다고 생각한다.또한 상자와 선을 사용한 그래픽 표현은 단순화되지 않으며 더 이상 편리함도 제공하지 않습니다(레이아웃, 리팩토링, 검색, 비교 등을 생각해 보세요).

모델 기반 개발은 아주 오랫동안 진행되어 왔습니다.

초기 시도 중 가장 성공한 것은 제임스 마틴(James Martin)의 통합 엔지니어링 시설(Integrated Engineering Facility)이었습니다. 이 시설은 여전히 CA에서 심각하게 냉소적인 "Coolgen" 브랜드 이름으로 판매하고 있습니다.

그렇다면 그것이 그렇게 좋았다면 왜 세상을 장악하지 못했을까요?

이 도구는 간단한 일을 더 쉽게 만드는 데는 좋지만, 어려운 일을 더 쉽게 만드는 것은 아니며 많은 경우 어려운 일을 더 어렵게 만듭니다!

Java/C/SQL 등에서 올바른 코드를 코딩하는 것이 사소한 일이라는 것을 알면 그래픽 4GL 모델링 언어가 "올바른 일을 수행"하도록 설득하는 데 몇 시간을 보낼 수 있습니다.

아마도 확실한 답은 없을 것 같습니다. 따라서 이 질문에 대한 "관심"이 부족합니다.

그러나 저는 개인적으로 MDA에 대해 혼합된 경험을 했습니다.유일하게 좋은 경험이었던 때는 훌륭한 도구를 사용했을 때였습니다. 저는 TogetherSoft를 사용하곤 했습니다(어떻게든 볼랜드에 가게 된 것 같아요). 그들은 "코드 생성"이 아닌 실제로 코드를 편집하는 편집을 최초로 도입한 사람 중 하나였습니다. 모델을 직접적으로 편집할 수 있습니다(코드나 모델을 편집하는 것이 모두 중요했습니다).그들은 또한 리팩토링을 했습니다(스몰토크 환경 이후 처음으로 기억합니다).

그 이후로 나는 적어도 주류에서는 MDA의 인기가 더 이상 커지는 것을 보지 못했기 때문에 인기 측면에서 볼 때 미래가 아닌 것 같습니다(그래서 그런 대답이 됩니다).

물론 인기가 전부는 아니며 다시 돌아오는 경향이 있지만, 당분간은 많은 사람들이 MDA+도구를 "마법사 기반 코드 생성" 도구로 보는 것 같아서(실제로 그것이 무엇인지에 관계없이) 실제로 성공하려면 시간이 좀 걸리거나 결코 없을 것이라고 생각하십시오.

MDD의 문제점 중 하나는 더 높은 추상화 수준에서 작동하기 때문에 더 높은 추상화 수준으로 올라갈 수 있는 개발자도 필요하다는 것입니다.이는 그러한 방법론을 이해하고 사용할 수 있는 개발자의 세계를 크게 감소시킵니다.

모델 기반 접근 방식에 대한 좋은 경험이 있거나 나쁜 경험이 있거나 그것이 전혀 흥미롭지 않다고 생각하는 이유가 있으면 알려 주시기 바랍니다.

나는 여기의 기여자들이 "No Silver Bullet" 진영의 일부라고 생각합니다(저는 확실히 그렇습니다).MDA가 효과가 있었다면("엄청난 비용 절감"과 동일) 우리는 이를 알 수 있을 것입니다.질문은 ~이야:시스템을 관리 가능하게 유지하면서 "메타"를 얼마나 멀리까지 갈 수 있습니까?이는 UML 2.0이 보다 공식적인 메타-메타 모델을 도입한 전환점이었습니다.지금까지 나는 UML 2.0의 모델링 기능을 실제로 사용하는 것을 본 적이 없습니다(그러나 내 세계는 다소 제한적입니다).게다가 모델 기반 접근 방식에는 두 가지 선택 사항만 있습니다.코드를 생성하거나 모델을 활용하는 런타임을 가집니다.제약이 없는 궁극적인 코드 생성기는 "인간"이라고 불리는 반면, 궁극적인 런타임은 4GL에서 발견됩니다(요즘 현재 숫자는 얼마입니까?).아마도 그것은 열정이 부족하다는 것을 설명할 것입니다.

itemis(www.itemis.com)에서는 모델 기반 소프트웨어 개발을 많이 사용합니다.지금까지 우리는 정말 좋은 경험을 했습니다.Shure는 만능은 아니지만 소프트웨어 품질을 향상시켜 고객이 더 많이 사용할 수 있도록 도와줍니다.

모델 중심 개발은 사용하는 모델이 생성하려는 코드를 작성하는 것만큼 유연할 수 있는 경우에만 미래가 될 것입니다.지금 당장 그렇게 잘 되지 않는 이유는 텍스트 기반 프로그래밍 언어가 수십 년 동안 해왔던 것과 같은 "왕복"을 수행하기가 어렵기 때문이라고 생각합니다.

텍스트 기반 프로그래밍 언어를 사용하면 모델 변경은 코드 몇 줄만 변경하는 것만큼 간단합니다.그래픽 프로그래밍 언어(UML과 같은 MDD 다이어그램이라고도 함)를 사용하면 해당 모델을 텍스트 기반의 해당 언어(처음부터 이미 표현적으로 효율적임)로 다시 변환하는 방법을 찾아야 합니다. 아주 아주 지저분해지세요.

IMHO는 MDD가 처음부터 텍스트 기반만큼 표현력이 풍부하고 유연하도록 구축된 경우 MDD가 유용할 수 있는 유일한 방법입니다.계층화된 추상화(예: 프로그래밍 언어)를 사용하여 본질적으로 상향식으로 구축된 도구에 기존 하향식 그래픽 디자인 언어(예: UML)를 사용하려고 하면 엄청난 임피던스 불일치가 발생합니다.손가락질할 수는 없지만 MDD에는 사람들이 주장하는 것만큼 유용하게 만들 수 있는 뭔가가 아직 빠져 있습니다...

매우 늦은 답변입니다만, 현재 아쉽게도 Rhapsody로 대체되고 있는 Rose RT를 대체할 MDD 도구를 찾고 있습니다.우리는 실시간, 임베디드 및 분산 C++ 공간에 있으며 MDD에서 많은 것을 얻습니다.우리는 더 나은 도구로 전환하고 대규모 회사에서 도구를 더 널리 사용하려고 노력하고 있습니다.여기에 언급된 몇 가지 훌륭한 이유 때문에 이는 힘든 싸움입니다.

컴파일러가 어셈블리 위에 있는 것처럼 MDD도 컴파일러보다 한 단계 위인 것으로 생각합니다.나는 아키텍트로서 애플리케이션 프레임워크를 개발하고 코드 생성(스크립트)을 광범위하게 편집하여 해당 프레임워크와 메시지 전달에 사용하는 모든 미들웨어를 사용할 수 있는 도구를 원합니다.나는 개발자가 애플리케이션 및/또는 라이브러리를 생성하는 데 필요한 모든 코드를 포함하는 완전한 UML 클래스와 상태 다이어그램을 만들기를 원합니다.

코드로 무엇이든 할 수 있다는 것은 사실이지만 MDD의 이점을 대략적으로 요약하면 다음과 같습니다.

소수의 사람들은 애플리케이션 프레임워크, 미들웨어 어댑터를 만들고 이를 MDD 도구에 붙입니다.그들은 "집"을 짓는다.
다른 사람들은 완전한 클래스, 다이어그램 및 상태 머신 전환 코드를 만듭니다.이를 통해 "집" 대신 응용 프로그램에 집중할 수 있습니다.
다이어그램이 코드이기 때문에 사람들이 이상한 디자인을 가지고 있을 때 쉽게 알 수 있습니다.전문 개발자가 다 있는 건 아니고 후배들을 이렇게 키우는 게 좋은 것 같아요.
대부분 모바일 로봇 프로젝트와 같은 곳에서 발생할 수 있는 불쾌한 상태 기계 코드입니다.나는 사람들이 내가 이해하고, 비판하고, 함께 작업할 수 있는 상태 다이어그램을 만들기를 원합니다.
작업 및 속성을 상속 체인이나 다른 클래스로 드래그하는 등 멋진 리팩토링을 수행할 수도 있습니다.파일을 파헤치는 것보다 그게 더 좋아요.

이 글을 입력하는 동안에도 코드로 모든 것을 할 수 있다는 것을 깨달았습니다.나는 코드 위에 통일성을 강화하고 디자인을 문서화하며 좀 더 쉽게 리팩토링할 수 있는 얇은 도구인 jsut를 좋아합니다.

제가 직면한 가장 큰 문제는 그러한 모델에 대한 표준 기능 세트와 파일 형식이 없다는 것입니다.사람들은 벤더가 사라지고 막히는 것에 대해 걱정합니다.(기본적으로 Rose RT에서는 그런 일이 발생했습니다.) 소스 코드에는 그런 일이 없습니다.그러나 최신 버전의 도구와 마지막으로 생성한 강좌 코드가 있을 것입니다. :).나는 위험보다 이익이 더 크다고 확신합니다.

나는 아직 이와 같은 도구를 찾지 못했지만 몇몇 공급업체가 내 말을 듣고 이 일이 가능하도록 돈을 받을 수 있도록 노력하고 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow