모델 지향 아키텍처

모델 중심 아키텍처(MDA)는 소프트웨어 시스템 개발을 위한 소프트웨어 설계 접근법입니다.모델로서 표현되는 사양의 구조에 관한 일련의 가이드라인을 제공합니다.모델 중심 아키텍처는 도메인 엔지니어링의 일종으로 소프트웨어 시스템의 모델 중심 엔지니어링을 지원합니다.그것은 ^[1]2001년에 OMG에 의해 시작되었다.

개요

Model Driven Architecture®(MDA®)는 물리, 조직 및 I의 전체 라이프 사이클을 지원하기 위해 모델과 아키텍처에서 가치를 창출하는 접근방식을 제공합니다.T. systems" 를 참조해 주세요.모델은 시스템의 추상화이다.MDA®는 개념 뷰에서 최소 구현 세부 사항까지 다양한 추상화 수준에서 모델을 제작하여 가치를 제공합니다.OMG 문헌에서는 이러한 추상화, 즉 아키텍처의 관점에서 계산 독립 모델(CIM), 플랫폼 독립 모델(PIM) 및 플랫폼 고유 모델(PSM)의 세 가지 수준에 대해 설명합니다.CIM은 시스템을 개념적으로 기술하고 PIM은 시스템의 계산 측면을 기술하며, PSM은 시스템의 구현에 필요한 기술적 세부사항을 제공합니다.그러나 OMG 가이드에서는 이 세 가지 아키텍처 관점은 유용하지만 가능한 많은 관점 ^[2]중 세 가지에 불과하다고 언급하고 있습니다.

OMG 조직은 구현이 아닌 사양을 제공하며, 종종 제안 요청(RFP)에 대한 답변으로 제공됩니다.구현은 민간 기업 또는 오픈 소스 그룹에서 이루어집니다.

관련 기준

MDA 모델은 Unified Modeling Language(UML), Meta-Object Facility(MOF), XML 메타데이터 교환(XMI), 엔터프라이즈 분산 객체 컴퓨팅(EDOC), 소프트웨어 프로세스 엔지니어링 메타모델(SEM), 공통 웨어하우스(Common Warehouse) 등 여러 표준과 관련되어 있습니다.아키텍처는 모델링되는 시스템의 아키텍처가 아니라 MDA의 ^{[citation needed]}기술 기반 역할을 하는 다양한 표준 및 모델 형식의 아키텍처를 의미합니다.

실행 가능한 UML은 MDA가 태어났을 때 사용된 UML 프로파일입니다.이제, OMG는 대신에 fUML을 홍보하고 있다.(fUML의 액션 언어는 ALF입니다).

상표

Object Management Group은 모델 기반 아키텍처 및 그 약어 MDA에 대한 등록 상표와 모델 기반 애플리케이션 개발, 모델 기반 애플리케이션 개발, 모델 기반 프로그래밍, 모델 기반 시스템 ^[3]등과 같은 용어의 상표를 보유하고 있습니다.

모델 중심 아키텍처 토픽

MDA 어프로치

OMG는 Model Driven Architecture®를 미래 엔지니어링, 즉 추상적이고 인간이 변형한 모델링 다이어그램(예: 클래스 다이어그램)^{[citation needed]}에서 코드를 생성하는 데 초점을 맞춥니다.OMG의 ADTF(Analysis and Design Task Force) 그룹이 이를 주도하고 있다.이 그룹은 유머를 가지고 ADM(MDA 역방향)을 선택하여 리버스 엔지니어링 연구의 이름을 붙였습니다.ADM은 아키텍처 중심 모던라이제이션으로 해독됩니다.ADM의 목적은 레거시 ^[4]시스템의 모델 기반 리버스 엔지니어링 표준을 작성하는 것입니다.KDM(Knowledge Discovery Metamodel)은 이러한 노력을 가장 많이 수반하며 다양한 자산(프로그램, 사양, 데이터, 테스트 파일, 데이터베이스 스키마 등)으로 정보 시스템을 기술합니다.

설계를 실현하는 데 사용되는 개념과 테크놀로지, 아키텍처를 실현하는 데 사용되는 개념과 테크놀로지가 각자의 페이스에 따라 변화하고 있기 때문에 이들을 분리함으로써 시스템 개발자는 두 영역에서 가장 적합하고 최적인 것을 선택할 수 있습니다.설계에서는 기능(유스케이스) 요건에 대응하고 아키텍처에서는 확장성, 신뢰성, 퍼포먼스 등의 비기능 요건을 실현하기 위한 인프라스트럭처를 제공합니다.MDA는 기능 요건을 실현하는 개념적 설계를 나타내는 플랫폼 독립 모델(PIM)이 실현 기술 및 소프트웨어 아키텍처의 변화에도 살아남을 것으로 예상하고 있습니다.

모델 중심 아키텍처에서 특히 중요한 것은 모델 변환의 개념입니다.모델 변환을 위한 특정 표준 언어는 QVT라고 불리는 OMG에 의해 정의되었습니다.

MDA 도구

OMG 조직은 구현이 아닌 대략적인 사양을 제공하며, 종종 제안 요청(RFP)에 대한 답변으로 제공됩니다.OMG는 전체 프로세스를 MDA 가이드라고 하는 문서에 기록합니다.

기본적으로 MDA 도구는 모델 또는 메타모델을 ^[5]개발, 해석, 비교, 정렬, 측정, 검증, 변환하는 데 사용되는 도구입니다.다음 섹션에서 "모델"은 모든 종류의 모델(예: UML 모델) 또는 메타모델(예: CWM 메타모델)을 의미하는 것으로 해석됩니다.모든 MDA 접근 방식에는 기본적으로 두 가지 모델이 있습니다. 초기 모델은 인간 에이전트에 의해 수동으로 생성되고 파생 모델은 프로그램에 의해 자동으로 생성됩니다.예를 들어, 분석가는 느슨한 비즈니스 상황을 관찰하여 UML 초기 모델을 생성하는 반면 Java 모델은 모델 변환 작업을 통해 이 UML 모델에서 자동으로 파생될 수 있습니다.

MDA 도구는 모델의 완전성, 불일치 또는 오류 및 경고 상태를 확인하는 데 사용되는 도구일 수 있습니다.모델의 ^[6]메트릭을 계산하는 데도 사용됩니다.

일부 도구는 위에 나열된 여러 기능을 수행합니다.예를 들어, 일부 생성 도구에는 변환 및 테스트 기능이 있을 수 있습니다.그 밖에도 창작, 그래픽 프레젠테이션, 변환 등을 목적으로 하는 툴이 있습니다.

OMG 규격의 실장은 민간 기업 또는 오픈 소스 그룹에서 이루어집니다.OMG 사양 구현의 중요한 원천 중 하나는 Eclipse Foundation(EF)입니다.OMG 모델링 표준의 많은 구현은 EMF(Eclipse Modeling Framework) 또는 GMF(Graphical Modeling Framework)에서 확인할 수 있습니다. Eclipse 재단은 GMT로서 다양한 프로파일의 다른 도구도 개발하고 있습니다. Eclipse의 OMG 규격 준수 여부는 종종 엄격하지 않습니다.이는 예를 들어 EMF가 에코어 구현과 근사한 OMG의 EMOF 표준에 해당된다.QVT 표준을 구현하는 M2M 프로젝트 또는 MOF2Text 표준을 구현하는 M2T 프로젝트에서 더 많은 예를 찾을 수 있습니다.

MDA 도구 목록과 UML 도구 목록을 혼동하지 않도록 주의해야 한다.이 구분은 '변수 메타모델 도구'와 '고정 메타모델 도구'를 구분하여 보다 일반화할 수 있다.UML CASE 도구는 특정 버전의 UML 메타모델(예: UML 2.1)에서만 작동하도록 유선 연결되었기 때문에 일반적으로 '고정 메타모델 툴'입니다.반대로, 다른 도구들은 임의의 메타모델이나 특정 종류의 메타모델에 적응할 수 있는 내부 범용 기능을 가지고 있다.

일반적으로 MDA 툴은 기본적인 아키텍처 사양에 초점을 맞춥니다.단, 아키텍처에 의존하지 않는(또는 플랫폼에 의존하지 않는) 툴도 있습니다.

아키텍처 사양의 간단한 예는 다음과 같습니다.

• Java EE 또는 Microsoft 등 지원되는 참조 아키텍처 중 하나를 선택합니다.네트워크,
• 프레젠테이션 레이어 테크놀로지, 비즈니스 로직 레이어 테크놀로지, 지속성 테크놀로지 및 지속성 맵핑 테크놀로지(오브젝트 관계형 맵퍼 등)의 선택지를 포함한 보다 상세한 레벨의 아키텍처 지정.
• 메타데이터: 데이터에 대한 정보.

MDA에 관한 문제

MDA 접근방식을 뒷받침하는 주요 개념(2001년 시작)은 1980년대 후반 Shlaer-Mellor 방법에 의해 처음 설명되었다.실제로 MDA 접근법의 핵심 기술 표준(실행 가능 UML의 액션 언어 구문)은 원래의 Shlaer-Mellor 액션 언어(UML용으로 ^{[citation needed]}수정됨)를 채택함으로써 일부 벤더에 의해 브리징되고 있습니다.그러나 이 기간 동안 MDA 접근방식은 주류업계에서 받아들여지지 않았습니다.Gartner Group은 2006년 "Hype Cycle"^[7]에서 MDA를 "상승 중" 테크놀로지로 인식하고 있으며 Forrester Research는 2006년 ^[8]MDA를 "D.O.A"로 선언했습니다.OMG MDA 접근방식으로 제기된 잠재적 우려 사항은 다음과 같다.

• 불완전한 표준:MDA 접근방식은 다양한 기술 표준으로 뒷받침되며, 그 중 일부는 아직 명시되지 않았거나(예: xtUML의 액션 시멘틱 언어), 표준 방식으로 아직 구현되지 않았다(예: QVT 변환 엔진 또는 가상 실행 환경이 ^[9][10]있는 PIM).
• 벤더 록인:MDA는 (기술적인) 플랫폼의 독립성을 달성하기 위한 접근법으로 생각되었지만, 현재 MDA 벤더는 상호 운용성을 위해 MDA 툴셋을 엔지니어링하는 것을 꺼려 왔습니다.이러한 결과는 MDA ^{[citation needed]}접근방식을 추구하는 사람들에게 벤더를 구속하는 결과를 초래할 수 있습니다.
• 이상적: MDA는 액션 언어 프로그래밍을 통합한 모델을 완전 자동화 또는 부분적으로 자동화된 "세대" 단계를 통해 한 방향으로 구현 아티팩트(실행 가능 코드, 데이터베이스 스키마 등)로 변환하는 미래 엔지니어링 접근법으로 간주됩니다.이는 MDA가 UML(및 관련 표준)에서 문제 영역의 전체 복잡성을 모델링하고 이후 완전한(^[11]실행 가능한) 애플리케이션으로 전환할 수 있도록 해야 한다는 OMG의 비전과 일치한다.단, 이 접근방식은 구현 아티팩트에 대한 변경(데이터베이스 스키마 조정 등)은 지원되지 않음을 의미합니다.이는 구현 아티팩트의 변환 후 '적용'이 필요하다고 생각되는 상황에서 문제가 된다.완전한 MDA 접근방식이 일부 실제 배치에 너무 이상적일 수 있다는 증거는 이른바 "프라그마틱 MDA"^[12]의 상승에서 확인되었습니다.실용적인 MDA는 OMG의 MDA의 문자 그대로의 표준을 구현 아티팩트의 적응을 지원하는 왕복 엔지니어링과 같은 보다 전통적인 모델 중심 메커니즘과 혼합합니다.
• 전문 스킬 세트: MDA 기반 소프트웨어 엔지니어링 실무자는 (다른 툴 세트와 마찬가지로) 자신의 분야에서 높은 수준의 전문 지식을 보유해야 합니다.현재의 전문 ^[13]MDA 실무자(종종 Modeller/Architects라고 불림)는 기존 개발자의 가용성에 비해 거의 없습니다.
• OMG 실적:또한 MDA 접근방식을 후원하는 OMG 컨소시엄(및 MDA 상표권 소유)은 CORBA 표준을 도입하고 후원하였으나, CORBA 표준은 널리 사용되는 ^[14]표준으로 구현되지 못했다.
• 불확실한 가치제안(UVP): 앞서 설명한 바와 같이 MDA의 비전은 특정 컴퓨팅 플랫폼(예를 들어 .NET)의 구체적인 구현(프로그램)으로서 실현될 수 있는 추상적 모델로서의 시스템 사양을 가능하게 합니다.따라서 순수 MDA 접근 방식을 통해 성공적으로 개발된 애플리케이션은 이론적으로 새로운 릴리스로 이식될 수 있습니다.NET 플랫폼(또는 Java 플랫폼)은 결정론적인 방식입니다.다만, 번역중의 실제의 실용성(사용자 인터페이스의 실장등)에 대해서는, 큰 의문이 남습니다.이러한 역량이 중요한 가치 제안을 나타내는지는 특정 채택기업에게 여전히 의문으로 남아 있습니다.그럼에도 불구하고, "프로그래밍의 대안"을 통해 가치를 추구하는 MDA의 채택자는 이 접근방식을 평가할 때 매우 주의해야 한다.주어진 문제 영역의 복잡성은 항상 유지되며, 비즈니스 로직의 프로그래밍은 다른 접근 방식과 마찬가지로 MDA에서 수행되어야 합니다.MDA와의 차이점은 사용되는 프로그래밍 언어(예: xtUML)가 Java 또는 C#보다 추상적이고 기존의 UML 아티팩트(예: 클래스 다이어그램)와 함께 존재한다는 것입니다.주류 3GL 언어보다 추상적인 언어로 프로그래밍을 하면 시스템의 품질이 향상될지, 비용이 절감될지, 또는 전송 속도가 빨라질지는 아직 제대로 답변되지 않은 문제입니다.
• MDA는 독립적으로 개발된 다양한 표준화 솔루션을 하나로 묶을 수 있는 가능한 방법으로 인식되었습니다.시뮬레이션 커뮤니티에서는 또 다른 미국 국방성 의무 표준에 ^[15]대한 비즈니스 및 산업 기반 대안으로 권장되었습니다.

코드 생성 논란

코드 생성이란 사용자가 추상적으로 솔루션을 모델링하고 일부 모델 데이터가 포함된 후 자동화된 툴이 소프트웨어 시스템의 모델 부분 또는 소스 코드 모두에서 파생되는 것을 의미합니다.일부 툴에서 사용자는 프로그램 소스 코드의 골격을 소스 코드 템플릿의 형태로 제공할 수 있으며, 여기서 코드 생성 프로세스 중에 미리 정의된 토큰이 프로그램 소스 코드 부분으로 대체된다.

자주 인용되는 비판은 UML 다이어그램이 프로그램 소스에서 다루는 것과 동일한 정보를 포함하는데 필요한 세부 정보가 부족하다는 것입니다.일부 개발자들은 심지어 "강령은 디자인이다"^[16][17]라고 주장하기도 합니다.

「 」를 참조해 주세요.

레퍼런스

추가 정보

• 케빈 라노."UML 및 Java를 사용한 모델 중심 소프트웨어 개발"CENGAGE 학습, ISBN 978-1-84480-952-3
• 데이비드 S. 프랑켈모델 중심 아키텍처: 엔터프라이즈 컴퓨팅에 MDA 적용John Wiley & Sons, ISBN 0-471-31920-1
• Megan Kiffer MDA 저널: 마스터가 직접 제공하는 모델 지향 아키텍처.ISBN 0-929652-25-8
• Anneke Kleppe (2003).MDA 설명, 모델 중심 아키텍처: 실천과 약속.애디슨 웨슬리.ISBN 0-321-19442-X
• Stephen J. Mellor (2004).모델 기반 아키텍처의 원리 MDA 증류.애디슨-웨슬리 프로페셔널입니다ISBN 0-201-78891-8
• 크리스 레이스트릭입니다실행 가능한 UML을 갖춘 모델 중심 아키텍처. Cambridge University Press, ISBN 0-521-53771-1
• Marco Brambilla, Jordi Cabot, Manuel Wimmer, Model Driven Software Engineering in Practice, Richard Soley(OMG 회장), Morgan & Claypool, 2012, 소프트웨어 엔지니어링에 관한 합성 강의 #1.182 페이지ISBN 9781608458820(페이퍼백), ISBN 9781608458837(전자책).http://www.mdse-book.com
• 스탠리 J. 시월MDA에 대한 이그제큐티브의 정당성
• 소일루 A, 데 카우메커 패트릭Proc 24th Intl Computer and Information Sciences(컴퓨터 및 정보 과학) 심포지엄에서 모델 중심과 온톨로지 중심 시스템 개발을 통합하는 것은 광범위한 컴퓨팅의 관점에서 접근합니다.2009, 페이지 730-735.

외부 링크

• OMG의 MDA 웹사이트
• 모델 주도형 소프트웨어 개발 코스 B빌켄트 대학교 테키네르도간