모델 구동형 아키텍처

3. 배경

모델 구동형 아키텍처는 상호운영성 결여, 소프트웨어 개발의 어려움, 이식성 부족 등 여러 기술적 문제점을 야기한다. 이러한 문제점은 서비스 환경의 다양화와 기술의 급격한 변화로 인해 더욱 심화된다. 기술의 복잡화로 인해 상호운영성이 결여되고 소프트웨어 개발이 어려워졌으며, 이식성이 부족해지는 문제가 발생했다. 또한 서비스 환경이 다양해지고 기술이 급격하게 변화하면서 모델 구동형 아키텍처의 필요성이 증대되었다. 소프트웨어 개발의 어려움, 상호운영성 결여, 이식성 부족 등 기술의 복잡화와 서비스 환경의 다양화는 기술의 급격한 변화에 대한 대응 필요성을 증대시켰고, 이는 모델 구동형 아키텍처의 중요한 배경이 되었다.

3. 1. 기술의 복잡화

3. 2. 서비스 환경의 다양화

3. 3. 기술의 급격한 변화

4. MDA의 구성 요소

모델 구동형 아키텍처는 다음과 같은 핵심 기술 요소들로 구성된다.

• MOF (Meta Object Facility)
• 모델 정보에 대한 표준적인 저장소를 제공하고 표준화된 방식으로 모델 정보를 접근하는 구조를 정의한다.
• MOF(Meta Object Facility)는 모델 정보를 저장하고 관리하는 역할을 한다.

• 통합 모델링 언어(UML)
• 객체 및 컴포넌트 시스템을 표현하기 위한 언어이다.

• XML (XML Metadata Interchange)
• UML로 기술된 모델정보의 XML 표현에 대한 표준이다.

• CWM (Common Warehouse Metamodel)
• 데이터 저장소 통합에 대한 표준을 정의하고 데이터베이스 모델과 스키마 변화 모델, OLAP, 데이터 마이닝 모델에 대한 표준화된 방법을 제공한다.

• 플랫폼 독립 모델(PIM: Platform Independent Model)
• 모델 구동형 아키텍처에서 플랫폼 독립 모델(PIM)은 기능적(유스 케이스) 요구 사항을 실현하는 개념 설계를 나타내며, 구현 기술과 소프트웨어 아키텍처의 변화 속에서도 유지될 것으로 예상된다.^[4] 설계는 기능적 요구 사항을 해결하고, 아키텍처는 확장성, 신뢰성, 성능과 같은 비기능적 요구 사항이 실현되는 인프라를 제공한다.^[4] 이러한 분리를 통해 시스템 개발자는 두 영역(설계/아키텍처) 모두에서 최고이자 가장 적합한 것을 선택할 수 있다.^[4]
• 모델 구동형 아키텍처에서 특히 중요한 것은 모델 변환의 개념이며, 모델 변환을 위한 표준 언어는 OMG에 의해 QVT라고 정의되었다.

• 플랫폼 종속 모델(PSM: Platform Specific Model)
• 모델 구동형 아키텍처에서 특히 중요한 것은 모델 변환의 개념이다.^[4] 모델 변환을 위한 특정 표준 언어는 OMG에 의해 QVT라고 정의되었다.

• 기술 매핑 자동화 기술
• 모델 구동형 아키텍처에서 특히 중요한 것은 모델 변환의 개념이다.^[4] 모델 변환을 위한 특정 표준 언어는 OMG에 의해 QVT라고 정의되었다. OMG는 모델 구동형 아키텍처를 순방향 엔지니어링, 즉 추상적이고 인간이 상세하게 만든 모델링 다이어그램으로부터 코드를 생성하는 데 중점을 둔다. 설계는 기능적(유스 케이스) 요구 사항을 해결하는 반면, 아키텍처는 확장성, 신뢰성 및 성능과 같은 비기능적 요구 사항이 실현되는 인프라를 제공한다. MDA는 기능적 요구 사항을 실현하는 개념 설계를 나타내는 플랫폼 독립 모델(PIM)이 구현 기술과 소프트웨어 아키텍처의 변화 속에서도 유지될 것으로 예상한다.

• 기타 구성 요소
• MDA 모델은 이외에도 메타-객체 시설(MOF), XML 메타데이터 교환(XMI), 엔터프라이즈 분산 객체 컴퓨팅(EDOC), 소프트웨어 프로세스 엔지니어링 메타모델(SPEM)을 포함한 여러 표준과 관련이 있다. MDA에서 "아키텍처"라는 용어는 모델링되는 시스템의 아키텍처가 아니라 MDA의 기술 기반 역할을 하는 다양한 표준 및 모델 형태의 아키텍처를 의미한다.
• 실행 가능한 UML은 MDA가 처음 등장했을 때 사용된 UML 프로파일이었다. 현재 OMG는 fUML을 대신 홍보하고 있다. (fUML의 액션 언어는 ALF이다.)

4. 1. 플랫폼 독립 모델(PIM: Platform Independent Model)

4. 2. 플랫폼 종속 모델(PSM: Platform Specific Model)

4. 3. 기술 매핑 자동화 기술

4. 4. MOF(Meta Object Facility) 기반 정보 저장소 기술

4. 5. 기타 구성 요소

5. MDA 개발 프로세스

OMG는 모델 구동형 아키텍처(MDA)를 순방향 엔지니어링, 즉 추상적 모델링 다이어그램으로부터 코드를 생성하는 데 중점을 두고있다.^[4] MDA의 주된 목적은 아키텍처로부터 설계를 분리하여 설계와 아키텍처가 각각 독립적으로 변경될 수 있도록 하는 기술을 확립하는 것이다. 설계는 기능적인 요구 사양(유스 케이스)의 구현에 대응하며, 아키텍처는 확장성, 신뢰성, 성능 등 기능과는 관계없는 요구 사양의 실현에 대응한다. MDA는 구현 기술이나 소프트웨어 아키텍처가 변화해도, 기능적 요구 사양의 개념 설계를 표현한 플랫폼 독립 모델(PIM)이 여전히 사용 가능하도록 하는 것을 의도하고 있다.^[4]

모델 구동형 아키텍처에서 특히 중요해지는 것은 모델 변환에 관한 부분이다. 모델 변환을 위한 특정 표준 언어는 OMG에 의해 QVT라고 정의되었다.^[4]

전형적인 방법론 접근법은 다음과 같다:

# UML을 이용해 구현 독립적인 모델(PIM)을 작성한다. 이때 기본 서비스나 각 문제 영역에 관련된 모델을 이용하여 작성한다.

# 자동화 도구(Mapping Tool)를 이용해 PIM을 PSM UML 로 변환한다.

# 자동화 도구(Code Generation Tool)를 활용, 구현환경에 적합한 프로그램을 만들어 내며 구체적인 기능 등은 직접 프로그래밍한다.

지식 발견 메타모델(KDM)은 다양한 자산(프로그램, 사양, 데이터, 테스트 파일, 데이터베이스 스키마 등) 측면에서 정보 시스템을 설명한다.^[4]

모델 구동형 아키텍처(MDA) 개발은 다음과 같은 단계로 진행된다.

1. 먼저 애플리케이션에 대한 비즈니스 요구사항을 수집한다. 이를 바탕으로 J2EE, 닷넷, CORBA와 같은 특정 기술에 종속적이지 않은 도메인 모델에 대한 UML 다이어그램을 작성한다. 이 UML 모델은 핵심 비즈니스 서비스와 컴포넌트(예: 가격 결정 엔진, 쇼핑 카트 모델, 주문 모델)를 나타내며, 이를 PIM(Platform-Independent Model)이라고 한다.^[4]

2. 특정 기술과 관련한 UML 모델을 작성한다. 이 모델을 PSM(Platform-Specific Model)이라고 한다. PSM은 직접 작성할 수도 있고, MDA 지원 도구를 이용해서 PIM으로부터 자동 생성하거나, 생성된 모델을 수정하는 방식으로 작업할 수 있다.

3. MDA 도구를 이용하여 애플리케이션 코드를 생성한다. 현재 J2EE의 경우, 대부분의 MDA 도구들이 서블릿, JSP, EJB와 관련한 코드를 자동으로 생성해준다. 그 후, 만들어진 코드를 바탕으로 수정 및 최적화 과정을 거쳐 프로젝트를 완성한다.

OMG는 모델 구동형 아키텍처를 순방향 엔지니어링, 즉 추상적 모델링 다이어그램으로부터 코드를 생성하는 데 중점을 둔다. 설계는 기능적(유스 케이스) 요구 사항을 해결하고, 아키텍처는 확장성, 신뢰성, 성능과 같은 비기능적 요구 사항이 실현되는 인프라를 제공한다. MDA는 기능적 요구 사항을 실현하는 개념 설계를 나타내는 PIM이 구현 기술과 소프트웨어 아키텍처의 변화 속에서도 유지될 것으로 예상한다.

모델 변환은 모델 구동형 아키텍처에서 특히 중요한 개념이다. 모델 변환을 위한 표준 언어는 OMG에 의해 QVT라고 정의되었다.^[4]

5. 1. 전형적인 방법론 접근법

5. 2. 단계별 스텝

6. MDA 적용의 장점

6. 1. 기술 플랫폼 및 기능 변화에 대한 신속한 대응

6. 2. 시스템의 지속성

6. 3. 개발 생산성 증진

6. 4. 용이한 문서 작성

6. 5. 품질 관리 비용의 감소

6. 6. 양질의 시스템 구축

6. 7. UML (Unified Modeling Language)

6. 8. MOF (Meta-Object Facility)

6. 9. XMI (XML Metadata Interchange)

6. 10. CWM (Common Warehouse Metamodel)

6. 11. QVT (Query/View/Transformation)

6. 12. SPEM (Software Process Engineering Metamodel)

7. MDA 도구

MDA 개발을 지원하는 다양한 도구들이 있다. MDA 도구는 모델(MOF 모델 또는 메타모델)을 입력으로 받아 다른 모델을 출력한다.^[18] 단, 문서와 모델 간의 변환 도구 등에서는 MDA의 범위를 벗어나는 파라미터의 입력이 필요할 수도 있다.

MDA 도구는 모델 또는 메타모델을 개발, 해석, 비교, 정렬, 측정, 검증, 변환하는 데 사용된다.^[5] 여기서 "모델"은 UML 모델, CWM 메타모델 등 모든 종류의 모델 또는 메타모델을 의미한다. MDA 접근 방식에는 두 가지 종류의 모델이 있는데, '초기 모델'은 사람이 수동으로 생성하고, '파생 모델'은 프로그램으로 자동 생성된다.^[17] 예를 들어, 분석가는 비즈니스 상황을 UML 초기 모델로 만들고, 모델 변환을 통해 이 UML 모델에서 자바 모델을 자동 생성할 수 있다.

MDA 도구는 모델의 완전성, 불일치 또는 오류 및 경고 조건을 확인하는 데 사용되는 도구일 수 있다.

일부 도구는 위에 나열된 기능 중 둘 이상을 수행한다. 예를 들어, 일부 생성 도구는 변환 및 테스트 기능을 갖추고 있을 수 있다. 생성만을 위한 도구, 그래픽 표현만을 위한 도구, 변환만을 위한 도구 등 다른 도구도 있다.

OMG 사양의 구현은 사기업 또는 오픈 소스 그룹에서 제공된다. OMG 사양의 구현을 위한 중요한 소스 중 하나는 이클립스 재단(EF)이다. OMG 모델링 표준의 많은 구현은 이클립스 모델링 프레임워크(EMF) 또는 그래픽 모델링 프레임워크(GMF)에서 찾을 수 있으며, 이클립스 재단은 GMT와 같은 다양한 프로파일의 다른 도구도 개발하고 있다. 이클립스의 OMG 사양 준수는 엄격하지 않은 경우가 많다. 이는 예를 들어 EMF가 Ecore 구현으로 근사하는 OMG의 EMOF 표준에 해당한다. QVT 표준을 구현하는 M2M 프로젝트 또는 MOF2Text 표준을 구현하는 M2T 프로젝트에서 더 많은 예를 찾을 수 있다.

UML 도구와 혼동하지 않도록 주의해야 하며, 전자가 훨씬 더 광범위하다. 이러한 차이는 '가변 메타모델 도구'와 '고정 메타모델 도구'를 구분함으로써 더욱 일반화할 수 있다. UML CASE 도구는 UML 메타모델의 특정 버전(예: UML 2.1)에서만 작동하도록 하드 와이어링되어 있기 때문에 일반적으로 '고정 메타모델 도구'이다. 반대로, 다른 도구는 임의의 메타모델 또는 특정 종류의 메타모델에 적응할 수 있도록 하는 내부 일반 기능을 가지고 있다.

일반적으로 MDA 도구는 기본적인 아키텍처 사양에 중점을 두지만, 어떤 경우에는 도구가 아키텍처 독립적(또는 플랫폼 독립적)이다.

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

• Java EE 또는 .NET과 같은 여러 지원되는 참조 아키텍처 중 하나를 선택한다.
• 프리젠테이션 계층 기술, 비즈니스 로직 계층 기술, 지속성 기술 및 지속성 매핑 기술(예: 객체 관계형 매퍼)의 선택을 포함하여 아키텍처를 더 세밀한 수준으로 지정한다.
• 메타데이터: 데이터에 대한 정보.

• 작성 도구: 초기 모델을 작성하고 도출 모델을 편집한다.
• 분석 도구: 모델의 완전성, 무모순성, 오류 및 경고 조건을 확인하고, 모델의 통계 정보를 계산한다.
• 변환 도구: 모델을 다른 모델, 코드 또는 문서로 변환한다.
• 합성 도구: 동일한 메타모델을 따르는 여러 모델을 합성한다.
• 평가 도구: 모델 기반 테스트와 같이 모델을 평가한다.
• 시뮬레이션 도구: 모델로 표현되는 시스템의 실행을 시뮬레이션한다.
• 메타데이터 관리 도구: 모델 내 메타데이터(작성자, 작성일, 업데이트 날짜, 사용 도구 등) 및 모델 간 상호 관계(모델 변환의 원본과 결과 관계, 메타모델 버전 관계 등)를 관리한다.
• 리버스 엔지니어링 도구: 오래된 정보 시스템을 MDA로 처리할 수 있도록 모델로 변환한다.

7. 1. 도구의 종류

• 작성 도구: 초기 모델을 작성하고 도출 모델을 편집한다.
• 분석 도구: 모델의 완전성, 무모순성, 오류 및 경고 조건을 확인하고, 모델의 통계 정보를 계산한다.
• 변환 도구: 모델을 다른 모델, 코드 또는 문서로 변환한다.
• 합성 도구: 동일한 메타모델을 따르는 여러 모델을 합성한다.
• 평가 도구: 모델 기반 테스트와 같이 모델을 평가한다.
• 시뮬레이션 도구: 모델로 표현되는 시스템의 실행을 시뮬레이션한다.
• 메타데이터 관리 도구: 모델 내 메타데이터(작성자, 작성일, 업데이트 날짜, 사용 도구 등) 및 모델 간 상호 관계(모델 변환의 원본과 결과 관계, 메타모델 버전 관계 등)를 관리한다.
• 리버스 엔지니어링 도구: 오래된 정보 시스템을 MDA로 처리할 수 있도록 모델로 변환한다.

7. 2. 도구 예시

8. MDA의 한계 및 쟁점

MDA 접근 방식(2001년에 시작)을 뒷받침하는 몇 가지 주요 개념은 1980년대 후반 Shlaer–Mellor 방식에 의해 처음 설명되었다. 실제로, MDA 접근 방식의 주요 부재 기술 표준(실행 가능한 UML에 대한 동작 언어 구문)은 원래 Shlaer–Mellor 동작 언어(UML에 맞게 수정됨)를 적용하여 일부 공급업체에 의해 해결되었다. 그러나 이 기간 동안 MDA 접근 방식은 주류 산업에서 받아들여지지 않았다. 가트너 그룹은 2006년 "Hype Cycle"에서 MDA를 여전히 "상승세" 기술로 식별했으며,^[6] 포레스터 리서치는 2006년에 MDA를 "D.O.A."라고 선언했다.^[7] OMG MDA 접근 방식과 관련하여 제기된 잠재적 우려 사항은 다음과 같다.

; 불완전한 표준

: MDA는 각종 기술 표준에 기반하지만, 그 일부는 아직 사양이 정해지지 않았거나(xtUML을 위한 언어 등), 표준적인 방법으로 구현되지 않았다(QVT 변환 엔진이나 가상 실행 환경에서의 PIM)^{[8][9][21][22]}.

; 공급업체 종속

: MDA는 (기술적) 플랫폼 독립성을 달성하기 위한 접근 방식으로 구상되었지만, 현재의 MDA 공급업체는 MDA 도구 세트를 상호 운용 가능하도록 설계하는 것을 꺼려했다. 이러한 결과는 MDA 접근 방식을 추구하는 사람들에게 공급업체 종속을 초래할 수 있다.

; 이상주의

: MDA는 동작 언어 프로그래밍을 통합하는 모델이 완전 또는 부분 자동화된 "생성" 단계를 통해 한 방향으로 구현 아티팩트(예: 실행 가능한 코드, 데이터베이스 스키마)로 변환되는 순방향 엔지니어링 접근 방식으로 구상되었다. 이것은 MDA가 UML(및 관련 표준)에서 문제 영역의 전체 복잡성을 모델링하고 이후 완전한 (실행 가능한) 응용 프로그램으로 변환할 수 있도록 해야 한다는 OMG의 비전과 일치한다.^[10] 그러나 이러한 접근 방식은 구현 아티팩트(예: 데이터베이스 스키마 튜닝)에 대한 변경 사항이 지원되지 않음을 의미한다. 이는 구현 아티팩트의 이러한 변환 후 "적응"이 필요한 것으로 간주되는 상황에서 문제가 된다. 전체 MDA 접근 방식이 일부 실제 배포에 너무 이상적일 수 있다는 증거는 소위 "실용적 MDA"의 부상에서 볼 수 있다.^[11] 실용적 MDA는 OMG의 MDA에서 나온 문자 그대로의 표준을 왕복 엔지니어링과 같은 보다 전통적인 모델 기반 접근 방식과 혼합하여 구현 아티팩트 적응을 지원한다(상당한 단점은 있지만).

; 전문 기술 세트

: MDA 기반 소프트웨어 엔지니어링 실무자는 (다른 도구 세트와 마찬가지로) 해당 분야에서 높은 수준의 전문 지식을 갖추어야 한다. 현재의 전문가 MDA 실무자(종종 모델러/아키텍트라고 함)는 전통적인 개발자의 가용성에 비해 부족하다.^[12]

; OMG의 실적

: MDA 접근 방식을 후원하고 MDA 상표를 소유한 OMG 컨소시엄은 널리 사용되는 표준으로 실현되지 못한 CORBA 표준을 도입하고 후원했다.^[13]

; 불확실한 가치 제안 (UVP)

: 설명했듯이 MDA의 비전은 특정 컴퓨팅 플랫폼(예: .NET)에 대한 구체적인 구현(프로그램)으로 실현될 수 있는 추상 모델로 시스템을 지정할 수 있습니다. 따라서 순수한 MDA 접근 방식을 통해 성공적으로 개발된 응용 프로그램은 이론적으로 더 새로운 릴리스 .NET 플랫폼(또는 Java 플랫폼)으로 결정론적인 방식으로 이식될 수 있습니다. 물론 변환 중에 실제적인 문제(예: 사용자 인터페이스 구현)에 대해서는 여전히 중요한 질문이 남아 있습니다. 이 기능이 중요한 가치 제안을 나타내는지 여부는 특정 채택자에게 달려 있습니다. 그럼에도 불구하고 "프로그래밍의 대안"을 통해 가치를 찾고 있는 MDA 채택자는 이 접근 방식을 평가할 때 매우 신중해야 합니다. 주어진 문제 영역의 복잡성은 항상 남아 있을 것이며, 비즈니스 로직의 프로그래밍은 다른 접근 방식과 마찬가지로 MDA에서 수행해야 합니다. MDA의 차이점은 사용되는 프로그래밍 언어(예: xtUML)가 주류 3GL 언어보다 더 추상적이며 기존 UML 아티팩트(예: 클래스 다이어그램)와 얽혀 있다는 것입니다. 주류 3GL 언어보다 더 추상적인 언어로 프로그래밍하는 것이 더 나은 품질, 더 저렴한 비용 또는 더 빠른 제공의 결과를 가져올지는 아직 충분히 답변되지 않은 질문입니다.

: MDA는 다양한 독립적으로 개발된 표준화된 솔루션을 함께 가져올 수 있는 가능한 방법으로 인식되었다. 시뮬레이션 커뮤니티의 경우, 또 다른 미국 국방부의 의무 표준 대신 비즈니스 및 산업 기반 대안으로 권장되었다.^[14]

8. 1. 불완전한 표준

8. 2. 공급업체 종속성

8. 3. 이상주의적 접근

8. 4. 전문 기술 세트 부족

8. 5. OMG의 과거 실적

9. 한국의 MDA 현황 및 전망

외부 아웃소싱 개발업체보다 기업의 현업 담당자가 직접 분석 및 설계도를 만들고 개발 업체에 제공해 호환성을 갖춘 IT 시스템을 개발하는 것이 옳다는 인식이 확산되고 있다. 다양한 컴포넌트 플랫폼에 맞는 SW를 자동으로 생산할 수 있도록 SW 모델 자동매핑과 변환기술을 중심으로 MDD 방법의 중요성이 부상하고 있다.

OMG에서 작업 중인 영역별(전자상거래, 재무, 의료, 생산, 통신, 교통, 우주항공 등) 7개 분야 아키텍처 표준화 작업도 MDD를 채택하여 진행 중이다.

미국은 국가 IT개발 프로젝트에서 모델 주도형 SW 생산 기술을 주요 분야로 채택하였고, 유럽은 SW 공학 연구 분야에서 모델 기반 공학(Model Driven Engineering, MDE) 프로젝트를 진행하고 있다.

9. 1. 향후 전망

참조

_[1] 웹사이트 OMG pursues new strategic direction to build on success of past efforts http://www.omg.org/n[...] 2006-09-24
_[2] 웹사이트 OMG MDA Guide rev. 2.0 https://www.omg.org/[...] The Object Management Group 2021-09-04
_[3] 웹사이트 OMG Trademarks | Object Management Group http://www.omg.org/l[...]
_[4] 웹사이트 adm website http://adm.omg.org
_[5] 웹사이트 MDA components: Challenges and Opportunities http://www.sciences.[...]
_[6] 웹사이트 Hype Cycle for Emerging Technologies, 2006 https://web.archive.[...]
_[7] 웹사이트 MDA Is DOA, Partly Thanks To SOA http://www.forrester[...] 2007-10-13
_[8] 웹사이트 UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes http://www.jot.fm/is[...]
_[9] 웹사이트 MDA: Nice Idea. Shame about the... http://www.theserver[...]
_[10] 웹사이트 Bringing MDA to Eclipse, using a pragmatic approach http://alt.java-foru[...]
_[11] 웹사이트 A Response to Forrester http://www.bptrends.[...]
_[12] 웹사이트 Are You Ready For the MDA? http://www.agilemode[...]
_[13] 웹사이트 The Rise and Fall of CORBA http://www.acmqueue.[...] 2008-12-02
_[14] 웹사이트 Avoiding Another Green Elephant https://arxiv.org/ft[...]
_[15] 웹사이트 OMG pursues new strategic direction to build on success of past efforts http://www.omg.org/n[...]
_[16] 서적
_[17] 간행물 MDA components: Challenges and Opportunities http://www.sciences.[...] 2003
_[18] 서적
_[19] 웹사이트 Hype Cycle for Emerging Technologies, 2006 http://www.gartner.c[...]
_[20] 웹사이트 MDA Is DOA, Partly Thanks To SOA http://www.forrester[...]
_[21] 웹사이트 UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes http://www.jot.fm/is[...]
_[22] 웹사이트 MDA: Nice Idea. Shame about the... http://www.theserver[...]
_[23] 웹사이트 Bringing MDA to Eclipse, using a pragmatic approach http://www.java-foru[...]
_[24] 웹사이트 A Response to Forrester http://www.bptrends.[...]
_[25] 웹사이트 Are You Ready For the MDA? http://www.agilemode[...]
_[26] 웹사이트 The Rise and Fall of CORBA http://www.acmqueue.[...]