개념: 모델 기반 개발(MDD) 및 모델 기반 아키텍처(MDA)
이 안내는 기본 원리가 소프트웨어 엔지니어링에서 모델 역할을 강조하는 것인 MDD 및 MDA를 소개합니다.
관계
관련 요소
기본 설명

소개

모델은 Rational Unified Process에서 중요한 중간 산출물 유형으로, 보통 UML(Unified Modeling Language)을 사용하여 도구 및 환경 중립 방식으로 표시되므로(RUP에서), RUP는 많은 환경에서 많은 도구 세트를 사용하여 배치 및 규정할 수 있습니다. 지원 자료: 비주얼 모델링은 다음과 같은 모델링 이유를 탐색합니다.

  • 복잡한 시스템을 쉽게 이해하기 위해
  • 구현 기반으로 저렴한 비용에 디자인 대안을 탐색 및 비교하기 위해
  • 요구사항을 정확히 캡처하기 위해
  • 결정을 명확히 커뮤니케이션하기 위해

모델은 시스템 동작(원하는 동작과 구현된 동작 모두) 및 구조에 대한 이유를 설명하는 방법으로 나타나며, 이러한 토의의 결과를 관심 있는 이해 당사자(stakeholder)에게 전달합니다. MDD 및 MDA는 모델 역할을 구현의 기반 요소로 강조합니다. 이 때 코드를 작성할 개발자에 따라 청사진 이상의 내용을 기대하지만 지원 도구 세트의 기능에 따르는 정도까지 실행 가능합니다. 이것은 추상 레벨을 휴먼 개발자가 작업하는 레벨로 높여주는 오래 전에 시작된 경향에 따른 것입니다. 우리가 알고 있듯이 코드에서 상위 레벨의 그래픽 언어로 표시된 모델로 관심이 옮겨집니다. RUP는 모델 그림을 포함하는 문서가 아닌 모델로 특정 아티팩트를 식별하여(예: 요구사항 및 디자인을 캡처하여) 이 가능성을 묵시적으로 지원합니다.

시점 및 보기 페이지의 맨 위로

시점은 그 이름이 암시하듯이 시스템(또는 시스템을 나타내는 모델 세트)에 대한 일부 측면이나 관심사항을 볼 수 있는 개념적 위치이며 개념적 필터를 형성하기 위한 개념 및 규칙 세트의 적용을 내포합니다. 용어 "관점"도 마찬가지로 다양한 이해 당사자(stakeholder)의 서로 다른 많은 방향 및 관심사항에 최상의 서비스를 제공하는 모델을 보고 이해하는 방법을 설명하는 데 사용됩니다.

보기는 모델을 투영한 것으로, 특정 시점 또는 관점에서 관련된 엔티티를 보여줍니다.

MDD에서 시점 및 보기는 관심사항을 분리시키는 데 사용됩니다. 예를 들어, 논리 구조를 실제 구조 및 프로세스 구조와 독립적으로 처리하는 데 사용됩니다. 모델이 문제점 도메인에 더 가까울수록 시점 또는 관점은 이해 당사자(stakeholder)의 비즈니스 관심사항에 보다 강하게 맵핑됩니다. 모델이 실행 가능한 양식에 가깝게 개발될수록 더 많은 계산적 관심사가 개입됩니다. 어느 경우에도 목표는 단지 소극적 예시를 생성하는 것이 아니라 적어도 잠재적으로 이런 별개의 관심사항을 만족시키는 구현을 생성하는 모델을 생성하는 것입니다.

정제(Elaboration) 및 변환 (Transformation) 페이지의 맨 위로

이들 용어는 수동으로 수행한 모델 변경사항(정제)과 도구를 사용하여 수행한 모델 변경사항(변환)을 구별하기 위해 비공식으로 자주 사용됩니다. RUP에서 정제(Elaboration)는 상당히 다른 형식적인 의미(라이프사이클 단계의 이름)를 가지지만, 이 섹션에서는 모델의 전개에 대한 접근 방식을 명백히 구분하기 위해 비공식적으로 사용됩니다.

또한 변환 및 정제(Elaboration)는 단계 크기의 의미가 서로 다릅니다. 도구를 사용하거나 수동으로 코드를 생성하기에 충분한 세부사항(언어, 인프라스트럭처 또는 운영 체제 세부사항 포함)을 갖게 될 때까지 모델이 여러 개의 작은 단계로 구현된다는 의미입니다. '수동으로'란 사람이 모델을 보고 Java, C++ 또는 기타 언어를 작성하여 프로세스에서 정제할 수 있다는 의미입니다. 반대로 변환에서는 모델이 언어, 인프라스트럭처 또는 운영 체제 관심사항에 의해 훼손되지 않는 추상 레벨을 유지하면서 더 이상 정제하지 않고 원하는 결과를 실행 및 생성하는 것으로 변환됩니다. 원하는 결과에는 성능 및 기타 비기능적 특성이 포함되는 점을 참고하십시오. 따라서 이 접근 방식에서 그러한 공통적인 아키텍처 관심사항은 모델 생성 방법 및 자원 요구사항을 설명하는 방법으로 처리됩니다.

규칙 세트를 따르고 매개변수 세트에 따라 작업하여 소스 모델에서 대상 모델을 생성하는 프로세스를 설명하기 위해 또 다른 단어 용어 정의: 변환이 사용됩니다. 여기에서 용어 "모델"은 RUP와 같은 방식으로 사용되므로, 대상 모델은 구현 요소(예: 코드나 텍스트)가 될 수 있습니다. 물론 수동으로 변환을 수행하여 정제와 같은 변환(세부사항 추가)을 성공적으로 수행할 수 있습니다. 규칙은 매우 복잡할 수 있으며, 사용 가능한 기술과 도메인의 경험에 깊이 뿌리박고 있습니다. 그러나 기본적인 의미는 변환이 자동으로 수행되는 것인데, 이에 대해서는 MDA®에 관한 다음 섹션에서 다시 살펴 봅니다.

변환의 개념에는 단순히 소스 모델과 대상 모델만 관련되는 점을 참고하십시오. 대부분 대상 모델은 소스 모델에 비해 덜 추상적입니다. 즉, 대상이 소스보다 다소 구체적이긴 하지만 이것이 변환의 개념에 내재되어 있지는 않습니다. 또한 변환은 모델에 세부사항을 추가하여 대체로 동일 레벨의 추상을 유지하면서 다른 도메인과 관련된 정보는 소개하지 않는다는 점에서 보다 정제된 대상 모델을 생성할 수 있음을 참고하십시오. 이 점을 UML 모델로부터 코드를 생성하는 변환과 대조해보십시오. 필요한 동작 및 비기능적 특성이 유지보수될 경우 이 대상 모델에 많은 부분이 소개되어 있지만 비즈니스 이해 당사자(stakeholder)에게는 중요하지 않습니다.

이상적 변환을 구현할 수 있는 기능은 도구의 성능과 경험 많은 사람이 갖고 있는 지식을 체계적으로 정리하고 캡처 및 재사용할 수 있는 능력에 따라 다릅니다. 캡처하여 체계적으로 정리해야 하는 지식의 양은 변환 단계를 작성하는 추상 레벨에 따라 다릅니다. 일반적으로 레벨이 높을수록 지식의 양이 더 많아지고 도메인 종속성이 더 높아집니다.

MDD에서는 운영 시스템을 자동으로 생성할 수 있는 추상 레벨을 올리려고 노력합니다. 모델은 무언가를 생성하는 데 사용될 수 있는 정도까지 정제됩니다. 그러면 실행을 위해 산출물은 더 이상 구현하지 않아도 됩니다. 뿐만 아니라, 자동화된 변환을 통해 가능한 이전 정제를 작성하는 것을 목표로 합니다. 따라서 변환은 계속적인 변환 단계에 의해 실현되고 가능한 자동화되는 두 가지 접근 방식으로 모아집니다. 시스템 실행으로의 최종 변환은 여전히 상위 추상 레벨에서 모델 설명과 함께 및 변환 엔진에 인코딩된 기술, 인프라스트럭처, 대상 언어 선택사항 및 이에 제공된 규칙 및 데이터와 함께 발생합니다.

MDD의 추가적인 이점은 해당 도메인의 전문가가 작성함으로써 플랫폼 및 도메인 지식, 사례를 체계적으로 정리되게 하여 변환을 재사용할 수 있도록 하는 점입니다. 이와 같이, 기술이 부족한 개발자가 재사용하는 방법을 통해 각 새 응용프로그램에 대해 처음부터 재작성하지 않게 할 수 있습니다.

추상의 상위 레벨은 무엇입니까? 페이지 맨 위로

몇 가지 방법으로 이를 살펴볼 수 있습니다. 한 가지는 언어의 범위에 따른 방법인데, 예를 들면. 실행 가능한 UML 형식의 출현을 보는 것입니다. 또 다른 방법은 도메인 엔지니어링의 관점에서 보는 방법으로, 여기서 이 도메인에 대해 언어 및 모델링 개념을 전문화할 수 있습니다. 예를 들어, UML은 범용 언어이므로 이 차원에서 UML 사용을 전문화하는 용어 정의: UML 프로파일 사용을 찾게 됩니다. 또 다른 방법은 신기술을 받아들일 수 있도록 벤더 특정, 인프라스트럭처 특정 모델을 피해야 한다는 것입니다.

상세한 역학적 표현의 관점에서 볼 때, UML 조치 시맨틱에 대해 수행된 작업은 실행 가능한 UML 형식을 가능하게 만들었지만 구체적 구문과 표기법이 표준화되지 않았으며 조치 시맨틱의 레벨은 기타 OO 언어와 유사합니다. 따라서 UML + 조치 시맨틱은 궁극적인 해답이 될 수는 없지만 그 방향은 나타내고 있습니다.

결론적으로 UML로 또는 UML 프로파일을 사용하여 표현되고 벤더 종속 요소를 포함하지 않은 모델은 특정 인프라스트럭처 플랫폼(예: J2EE 또는 Microsoft® .NET)에 종속되지 않고, 시맨틱적으로 구조가 완전하며, 특정 프로시저 언어(Java, C# 등)에 의지하지 않는 동작은 조치 시맨틱 레벨 문제가 남아 있긴 하지만 이 정의에 의하면 상위 추상 레벨에 있습니다.

문제점 도메인 관점에서 볼 때(사용자 또는 비즈니스 고객 관점에서 볼 때), 가능하면서 매력적인 솔루션은 도메인 특정 모델링 언어의 공식화입니다. 이러한 언어는 특정 도메인에서 작업자에게 친숙한 용어와 개념으로 표현된다는 점에서는 추상적이지만 UML 기반을 유지하면서 모델 역학 관계를 완전히 표현할 수 있습니다.

RUP에 관련되는 방법은 무엇입니까? 페이지 맨 위로

RUP 분석, 디자인 및 구현 모델의 관계를 설명하면 다음과 같습니다. 분석 모델은 유스 케이스에 표현된 동작이 구현되는 방법의 초기 보기를 표시합니다. 처리 중인 문제점의 도메인을 향해 자연스럽게 서술적으로 비스듬히 표시됩니다. 분석 모델에 포함된 분석 클래스는 필요한 책임과 동작을 개념적으로 그룹화한 것으로 간주됩니다. 분석 모델은 일반적으로 실행할 수 있을 정도로 완전하지는 않습니다. 단, 설명하지 않은 부분이 많기 때문에 사람이 모델을 읽고 간격을 채우면 사고 실험을 할 수 있습니다. 대신, 분석 모델은 정제 프로세스를 거쳐 세부사항 및 정밀도를 추가하여 디자인 모델로 진행되어야 합니다.

RUP를 사용하면 프로젝트에서 별도의 분석 모델을 유지보수하거나 분석 모델이 디자인 모델로 전개된다고 생각할 수 있습니다. 정제 프로세스는 소프트웨어 설계자 및 디자이너 열할을 하는 사람이 많은 도구 지원을 사용하여 이 전개를 성취할 것이라는 기본적인 판단 아래, RUP 타스크에서 상당히 자세하게 설명됩니다. 이 정제는 모델 변환 시퀀스로 간주할 수 있으므로, 일부는 자동화될 수 있습니다(예: RUP 타스크 아키텍처 분석디자인 메커니즘 식별에서 용어 정의: 분석 패턴용어 정의: 디자인 패턴 패턴 적용 시).

디자인 모델은 언제 완료됩니까?페이지 맨 위로

디자인 모델은 프로젝트가 진행되는 동안 줄곧 여러 반복을 통해 전개됩니다. 따라서 디자인 모델(또는 모델의 일부분)이 코드화되는 시기, 즉, 구현 요소를 생성하기 시작하고 이들을 흥미로운 시스템 빌드에 통합시킬 수 있는 시기는 언제입니까? RUP는 디자인에서 코드로 맵핑에 관한 일부 가이드를 제공하고 있지만 근본적으로 어렵고 빠른 답변을 할 수 없습니다. 검토를 통해 할 수 있다고 판단될 때 구현으로 이동하며, 그 시점은 조직과 프로젝트에 따라 상당히 다를 수 있습니다. RUP는 디자인에서 코드로 진행할 수 있는 여러 가지 방법을 제공하는데, 여기서는 이 중 두 가지 방법을 통해 디자인 완전성에 대한 결정을 내리는 방법을 설명합니다.

1. 스케치 및 코드
RUP에서, "디자인을 위한 하나의 공통 접근 방식은 상당한 추상 레벨에서 디자인을 간단히 설명한 후 바로 코드로 이동하는 것입니다. 디자인 모델의 유지보수는 수동적입니다."

이 접근 방식을 사용하여 성공하려면 개발자가 디자인 레벨과 구현 레벨 간의 추상 간격을 메울 수 있어야 합니다. 디자인 모델에 대한 유지보수는 2차적인 관심사항인 경우가 많으며, 코드가 초점이 됩니다.

2. 전개되는 디자인 모델이 하나인 RTE
RUP에서, "이 접근 방식에서는 단일 디자인 모델이 있습니다. 초기 디자인 요소 스케치는 코드와 동기화될 수 있는 지점으로 전개됩니다."

여기서 개발자들은 모델링 단계 순서로 추상 간격을 좁힐 수 있습니다. 이 접근 방식과 "스케치 및 코드" 사이의 차이점은 중간 단계가 Manifest이고 끝에서 디자인 모델의 추상 버전이 없어진다는 것입니다.

두 경우 모두에서, 추상 디자인 모델의 가능한 값은 유실됩니다. "스케치 및 코드"에서는 추상 디자인 모델이 보통 유지보수되지 않으므로 시간이 지나면서 코드 접촉이 없어지고, "단일 전개 디자인 모델"에서는 추상 버전이 없어지기 때문입니다. 초기 버전이 보존되더라도 일반적으로 스케치 및 코드 디자인 모델과 동일한 운명을 맞게 됩니다. RTE를 사용하는 디자인 모델의 종료점은 실제로 코드를 시각화하는 것이며, 적절한 툴링을 사용하여 스케치 및 코드에 생성된 코드로부터 유사한 시각화를 리버스 엔지니어링할 수 있습니다. RUP에서는 소프트웨어 구조 문서에 있는 중요한 아키텍처 보기와 디자인 근거를 임계점까지 캡처하여 추상적 디자인 모델의 손실을 완화시켜줍니다.

MDD는 추상적 디자인 모델이 코드 생성의 기본이 되고 오래 지속될 것이라는 희망을 줍니다. MDD는 유지보수의 기본 토대가 되고, 실제로 유지보수의 유일한 토대가 될 수 있습니다. 또한 MDD는 디자인의 종료점에 대한 명확한 정의를 제공합니다. 즉, 변환 엔진이 관계하는 한 이 종료점에서 모델은 완벽하고 일관적이고 명백하며 실행 가능한 시스템으로 바뀌어질 수 있습니다. 모델 추상화 방법은 사용 가능한 기술과 도구 세트(예: 도움말 서적 아이콘둘러보기: Rational Software Architect 개요 참조)에 의존하고 도메인의 영향을 받을 수도 있습니다. MDD에 관계되는 한, 이는 단순히 다른 변환(디자인에서 코드로의)일 뿐이지만 추상 레벨을 뛰어 넘는 중요한 변환입니다.

다음 섹션에서는 MDA®(Model Driven Architecture®)라고 하는 OMG(Object Management Group)의 이니셔티브인 MDD에 대한 최근 프레임워크 표준을 설명합니다.

모델 기반 아키텍처(MDA) 페이지 맨 위로

동기 페이지 맨 위로

MDA는 응용프로그램 개발을 위한 벤더 중립적인 공통 프레임워크를 제공하고 주요 하드웨어 및 소프트웨어 인프라스트럭처 플랫폼 간에 상호운영성을 제공하기 위한 표준 가이드라인 및 스펙 설정의 임무를 맡고 있는 800명에 달하는 구성원들의 업계 콘소시엄인 OMG의 이니셔티브입니다. UML은 OMG의 제품입니다. 현재 OMG는 MDA를 가장 중요한 스펙으로 장려하고 있습니다. 또한 OMG는 업계 IC, 프랙티스, 제품 및 도구가 지원하는 실제 표준의 보급자로서의 입장을 나타내며, UML, MDA의 성공은 연구할 만한 가치가 있습니다. 최신 MDA 안내서인 [OMG03]을 비롯하여 MDA에 대한 자세한 정보는 OMG의 웹 사이트를 참조하십시오. [FRA03], [KLE03] 및 [MEL04]와 같은 사용 가능한 서적과 많은 기사(예: MDA Journal에서 Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh 및 Bran Selic의 "An MDA Manifesto", May 2004)도 있습니다.

MDA의 핵심 아이디어 페이지 맨 위로

MDA는 보다 일반적인 MDD 접근 방식과 구별되는 일부 특정 개념과 용어를 소개하고 있는데, 이에 대해서는 다음 섹션에서 정의 및 설명됩니다.

기존 표준에 따라 빌드 페이지 맨 위로

MDA는 다음을 포함한 기존 OMG 표준에 의해 지원됩니다.

  • MOF - 메타 모델을 구축하기 위한 언어를 정의하는 것 외에도(예: UML 및 CWM) MOF는 모델 및 메타 모델에 대한 저장소를 구현하기 위한 프레임워크를 정의하고 MDA를 사용할 때 일관된 접근 방식을 사용하여 이들 모델을 조작할 수 있도록 합니다. 따라서 MOF는 MDA의 본질적인 기술입니다.
  • UML(Unified Modeling Language) - PIM, PMPSM은 MDA의 기반 표기법인 UML로 정의됩니다.
  • XMI - XMI는 XML을 기반으로 UML 모델 교환 형식을 정의합니다.
  • CWM - UML이 응용프로그램 모델링과 관련되듯 CWM은 데이터 모델링과 관련됩니다.

플랫폼 독립성 페이지 맨 위로

용어 정의: 플랫폼의 직관적 개념은 구현 세부사항을 숨기는 잘 정의된 인터페이스 세트를 사용하여 서비스 준비를 통해 상위의 아키텍처 계층을 지원하는 것입니다. MDA 안내서에 있는 플랫폼에 대한 OMG의 정의는 다음과 같습니다.

"플랫폼이 제공하는 기능을 구현하는 방법을 자세히 몰라도 플랫폼에 종속된 모든 서브시스템이 사용할 수 있는 인터페이스 및 지정된 사용 패턴을 통해 일관된 기능성 세트를 제공하는 서브시스템/기술 세트".

이는 RUP에서 사용되는 용어 정의: 계층 개념과 유사합니다.

플랫폼 독립성의 개념은 다소 애매한 편입니다. 플랫폼 독립성은 모델의 품질 또는 특성입니다. 예를 들면, 특정 플랫폼이 제공하는 서비스나 성능에 대한 참조가 모델에 포함되어 있지 않을 때 이 모델을 해당 플랫폼에 대해 독립적이라고 말할 수 있습니다. 그러나 플랫폼 독립성의 절대적 형태를 파악하기란 어려운 일이므로 이러한 말은 상대적입니다. MDA 안내서에서는 이 점을 인정하고 있으며, 모델이 특정 플랫폼에서 일반화된 형식의 기능을 사용하는 특정 플랫폼과 관련하여 플랫폼 독립성의 가능한 정도도 인정하고 있습니다.

플랫폼 독립성의 달성은 응용프로그램에 나타나는 추상 레벨을 늘리기 위한 J2EE, .NET, WebSphere와 같은 플랫폼의 발전으로 지원되어 왔습니다. 이로 인해 플랫폼 중립적인 구문을 쉽게 식별할 수 있게 되고 이를 변환하는 플랫폼 특정 변환이 훨씬 단순해지고 작성하기 쉬워집니다.

플랫폼 독립 모델(PIM) 페이지 맨 위로

모델은 특정 플랫폼 사용에 구속되지 않고 해당 유형의 모든 플랫폼과 함께 사용할 수 있을 경우에 해당 플랫폼에 관하여 PIM이라고 말할 수 있습니다. 이전 섹션에서 상위 레벨 추상 개념에 대해 설명하고 UML로 또는 UML 프로파일을 사용하여 표현된 벤더 종속 요소를 포함하지 않은 모델은 특정 인프라스트럭처 플랫폼에 종속되지 않고 구조면에서 시맨틱적으로 완벽하며, 특정 프로시저 언어에 의지하지 않는 동작은 최소한 개념적으로 실행 가능하고 상위 추상 레벨에 있다고 결론을 내렸습니다. 그러면 이러한 모델은 플랫폼 독립적입니까? 그럴 수도 있고 아닐 수도 있습니다. 상상의 UML 가상 시스템과 관련해서는 플랫폼 독립적이지 않고, 이러한 가상 시스템이 종속된 플랫폼의 전체 클래스와 관련해서는 플랫폼 독립적입니다.

플랫폼 모델 페이지 맨 위로

플랫폼 모델은 개념(파트 및 서비스를 표시하는), 스펙, 인터페이스 정의, 제한조건 정의 및 특정 플랫폼을 사용하는 데 응용프로그램이 필요로 하는 기타 요구사항 세트입니다. MDA에서 플랫폼 모델은 예를 들어 UML로 자세히 설명되고 형식화되며, MOF 호환 저장소에서 사용 가능합니다. 예를 들어, J2EE 또는 .NET 및 기타 플랫폼에 대해 플랫폼 모델을 빌드할 수 있습니다.

플랫폼 특정 모델(PSM) 페이지 맨 위로

PIM은 특정 플랫폼에 특정하게 하는 정보를 추가하여 하나 이상의 PSM으로 변환됩니다. PIM과 PSM은 여전히 동일한 시스템을 지정하지만, PSM은 특정 기술로 제한되며 플랫폼 특정 요소를 포함할 수 있습니다. 변환 단계(PIM에서 PSM 또는 연관된 플랫폼)가 대형 또는 소형이라는 암시는 없다는 점을 참고하십시오. 소형 패턴 세트의 적용을 포함하는 변환은 모델을 정제하며, 어떤 의미에서는 모델을 보다 특정하게 만듭니다. 이는 PIM과 PSM라는 용어의 상대성을 강조합니다.

시점 및 보기 페이지 맨 위로

이들 용어는 MDD에 대해 설명했듯이 MDA에서 동일한 방법으로 사용됩니다.

  • 시점은 그 이름이 암시하듯이 시스템에 대한 일부 측면이나 관심사항을 볼 수 있는 개념적 위치이며, 개념적 필터를 형성하기 위해 개념 및 규칙 세트의 적용을 내포합니다. 시스템에 관한 일부 정보가 억제될 경우, 이는 추상의 형태입니다. 용어 관점이 유사하게 사용됩니다.
  • 하나의 시점으로부터, 모델의 투영인 보기를 볼 수 있습니다. 보기는 해당 시점으로부터 관련되는 엔티티를 표시합니다.

MDA는 시스템에 세 가지 시점(컴퓨터 독립 시점, 플랫폼 독립 시점, 플랫폼 특정 시점)을 지정합니다.

컴퓨터 독립 시점 페이지 맨 위로

컴퓨터 독립 시점에서는 시스템의 컨텍스트, 시스템 운영 요구사항 및 제한조건, 상호 작용해야 하는 환경의 사항에 대해 관심을 갖습니다. 이 시점에서는 시스템 구조나 동작의 세부사항을 보지 못합니다.

CIM은 컴퓨터 독립 시점에서 시스템 또는 예비 시스템의 보기입니다. CIM은 개념에 있어서 RUP의 도메인 모델(타스크: 도메인 모델 개발(비즈니스 모델링에서)의 산출물인 비즈니스 용어집 및 비즈니스 분석 모델을 포함한 아티팩트 세트) 및 유스 케이스 모델(시스템의 동작과 컴퓨터 독립 설명)의 조합과 유사합니다. 주제 또는 도메인 전문가의 언어로 표시되는 CIM은 분석 및 디자인 중 만들어질 시스템의 주요 추상의 식별에 중요한 링크입니다.

플랫폼 독립 시점 페이지 맨 위로

플랫폼 독립 시점은 특정 플랫폼과 관계됩니다. 이 시점에서는 해당 플랫폼의 세부사항 없이도 시스템의 구조와 동작을 볼 수 있습니다. PIM은 플랫폼 독립 시점으로부터의 시스템 보기입니다.

플랫폼 특정 시점 페이지 맨 위로

특정 플랫폼과도 관계된 플랫폼 특정 시점에서는 플랫폼 독립 시점에서 볼 수 있는 내용을 볼 수 있지만 플랫폼 사용 세부사항이 나타납니다. PSM은 플랫폼 특정 시점으로부터의 시스템 보기입니다.

변환 자동화 페이지 맨 위로

변환 아이디어는 MDA의 기초로서 모델 변환은 단지 "하나의 모델을 동일 시스템의 다른 모델로 변환하는 프로세스"로 정의됩니다. 또한 MDA는 작은 패턴을 정의하여 변환을 시각화하고 지금까지 살펴본 일부 용어의 사용을 설명합니다.

변환에 대한 입력으로 PIM 및 기타 정보를 표시하고 출력으로 변환 레코드 및 PSM을 표시하는 MDA 패턴.

MDA 패턴

이 다이어그램의 목적은 변환이 최우선적임을 표시하는 것입니다. 변환은 PIM 및 기타 정보를 획득하고 이를 결합하여 PSM을 생성합니다.

물론 모델 변환을 수동으로 수행할 수 있습니다. 이는 소프트웨어 디자인이 항상 진행되어 온 방법과 거의 다르지 않습니다. 여기서도 MDA는 변환 개념, 프로세스 및 사용할 추가 정보를 설명하고 형식화하는 데 유용합니다. 또한 MDA는 변환 레코드를 생성할 것을 제안합니다. 이 경우, PIM 요소에서 PSM 요소로의 맵핑을 포함해야 하므로 PIM에서 PSM으로의 강력한 추적성을 제공합니다. 대부분 변환을 자동화할 경우에 효과가 나타나는데, 부분적이긴 하지만 고급 언어를 사용하는 어셈블러 프로그래밍을 대체할 때와 동일한 이점을 제공합니다.

변환은 어떻게 수행됩니까?페이지 맨 위로

MDA는 변환을 수행하는 방법을 한 가지로 규정하고 있지는 않습니다. 해당 플랫폼에 대해 PIM을 PSM으로 변환하는 방법에 대한 스펙을 제공하가 위해 플랫폼의 선택으로 구동되는 맵핑이 준비되어 있습니다. 이 맵핑으로 인해 변환 매개변수를 사용하여 변환 정의 언어로 작성된 변환 정의(변환 규칙 세트로 표현)가 발생됩니다. OMG에서는 모델 보기 작성을 위해 언어를 표준화하고(MOF에 대해) 모델을 조회하며 변환 정의를 작성하기 위해 RFP(MOF 2.0 조회/보기/변환 RFP)를 발표했습니다. MDA 안내서에서는 다음을 포함하는 여러 가지 변환 접근 방식을 설명합니다.

  • 메타 모델 변환 - 이 접근 방식은 PIM이 빌드된 언어로 된 PIM 레벨 MOF 메타 모델이 있다고 가정합니다. 마찬가지로, 선택한 플랫폼에 대해 PSM을 생성할 수 있는 언어로 된 PSM 레벨 메타 모델이 있습니다. 두 메타 모델 간의 맵핑을 사용하여 변환 정의를 생성할 수 있습니다. 그런 다음, 이를 사용하여 PIM을 PSM으로 변환합니다.
  • 표시 - 선택한 플랫폼에 대한 맵핑이 준비됩니다. 이 맵핑은 변환 정의를 생성하는 데 사용되는데, 변환 정의에는 PIM의 요소를 표시하여 '표시된 PIM'을 생성하는 데 사용되는 표시 세트 및 표시된 요소에 대해 수행할 작업에 대한 정의가 포함됩니다. 표시된 PIM은 계속 변환되어 PSM을 생성합니다. 표시는 일반적으로 수동 프로세스이지만 후속 변환은 자동으로 처리됩니다.
  • 모델 변환 - PIM은 플랫폼 독립 유형을 사용하여 빌드되며 모델에도 지됩니다. 모델에서 PIM의 요소는 플랫폼 독립 유형의 서브유형입니다. 특정 플랫폼이 선택되며, 이 플랫폼은 플랫폼 특정 유형 세트와 연관됩니다. 두 유형 세트 간 맵핑이 이루어져 변환 정의가 생성됩니다. 이 정의는 PIM에 적용되어 플랫폼 특정 유형의 서브유형으로 표시된 PSM을 생성합니다. 이 접근 방식은 메타 모델 변환과 다소 유사하지만 변환이 MOF 메타 모델의 개념이 아니라 모델의 유형으로 제한된다는 점이 다릅니다.
  • 패턴 적용 - PIM은 플랫폼 독립적인 유형 및 추상 패턴 세트를 사용하여 빌드됩니다. 선택한 플랫폼에 대해 플랫폼 특정 유형 및 패턴 세트가 존재합니다. 두 유형 및 패턴 세트 간에 맵핑이 이루어져 PIM에 적용할 변환 정의를 제공합니다. 이를 통해 추상 패턴이 플랫폼 특정 패턴이 되는 PSM이 생성됩니다.

자세한 내용은 MDA 안내서 [OMG03]을 참조하십시오.

변환 적용 방법 페이지 맨 위로

MDA 적용에 대한 가장 단순한 시나리오는 다음과 같습니다.

  1. PIM을 준비합니다.
  2. 플랫폼을 선택합니다.
  3. 맵핑을 준비합니다(아직 맵핑이 없을 경우).
  4. 변환을 적용하여 PSM을 생성합니다.
  5. PSM을 코드로 바꿉니다. PSM을 더 이상 정제할 필요가 없고 직접 구현할 수 있는 경우, 다음 섹션에 정의된 대로 PSM 자체가 구현입니다.

기타 플랫폼의 경우 동일한 방법으로 PSM을 생성할 수 있습니다.

MDA 패턴의 반복된 적용 페이지 맨 위로

MDA 패턴은 반복 적용할 수 있습니다. 한 레벨에서 생성된 PSM이 다음 레벨의 PIM이 됩니다. 즉, 다음 레벨의 경우 더욱 전문화된 플랫폼 선택사항이 됩니다. RUP에서 MDD를 설명하고 IBM Rational 도구 세트를 사용하여 이를 지원하고 있기 때문에, MDD에서는 정제 단계 수를 최소화, 즉, 고객의 문제점 진술에 근접한 표시에서 가능한 직접적으로 실행 가능한 양식으로 진행하는 것이 선호된다는 점을 참고하십시오.

서로 다른 세 플랫폼에 대한 MDA 패턴의 반복되는 세 적용

MDA 패턴 반복 적용

위 다이어그램의 의도는 MDA 패턴의 세 적용(초기 PIM은 플랫폼 1에 종속되는 PSM이 되고, 다시 플랫폼 2에도 종속되도록 변환된 후, 다시 플랫폼 1, 2 및 3에 종속되도록 변환됨)을 보여주기 위한 것입니다.

일반적인 모델에서 모델로 변환 페이지 맨 위로

일반적인 변환, 즉, 모든 모델 간의 변환에도 동일한 개념을 적용할 수 있습니다. 예를 들어, 해당 언어를 사용하여 모델을 표시하는 두 개의 메타 모델이 있는 경우에는 원칙적으로 맵핑을 작성하고 변환 정의를 생성할 수 있습니다. 이는 PIM에서 PSM으로의 변환에 대해 이미 살펴보았던 방법으로 적용됩니다.

구현 페이지 맨 위로

MDA 안내서는 RUP의 구현 모델과 유사한 방식으로 "구현"을 사용합니다. 시스템을 생성, 배치, 설치 및 조작하는 데 필요한 모든 구현 요소의 스펙입니다.

PSM 자체가 구현이 될 수도 있고 코드로 바꾸기 전에 추가 정제가 필요할 수도 있습니다. 구현 PSM의 생성은 PSM 표시 단계를 건너뛰고 직접 코드로 이동할 수 있다는 점을 참고하십시오. 이 경우, 변환 엔진을 사용하여 보다 추상적인 PIM을 직접 코드로 바꿀 수 있습니다. 개발자의 이해를 돕기 위해 코드 시각화가 여전히 제공되기는 하지만 코드에서 리버스 엔지니어링이 가능합니다.

추정적 이점 페이지 맨 위로

이식성 및 상호운용성 페이지 맨 위로

MDA는 어떤 신기술이 필요하든지 비교적 안정적인 PIM 세트로 목표를 변경할 수 있게 함으로써 발생되는 기술의 동요와 비용을 제어할 수 있다는 희망을 줍니다. MDA를 채택하는 경우가 늘어남에 따라 신기술의 개발자들이 맵핑도 제공하여 변환을 쉽게 수행할 수 있도록 하기를 기대합니다.

두 플랫폼에 대한 PIM-PSM 맵핑을 확장함으로써 MDA는 두 PSM 간에 '브릿지' 구축을 가능하게 하고 궁극적으로는 두 구현 간에 구축할 수 있게 하여 하나의 PIM을 전체 플랫폼에 분산될 수 있게 할 것을 제안합니다. 대부분의 기업은 현실적으로 신기술과 구기술을 혼합하여 이기종 환경에 맞게 개발해야 하는 문제에 직면하고 있으므로 상호운영성을 구현하기 위한 이 기능은 잠재적으로 상당한 이점이 있습니다.

감소된 라이프사이클 비용 페이지 맨 위로

생산성 페이지 맨 위로

MDA를 사용한 개발의 초점은 보다 추상적인 PIM이 되고 있습니다. PSM(또는 코드)을 생성하기 위해 강력한 도구 세트를 사용할 경우, 이러한 환경은 어셈블러로 작업하는 것보다 고급 언어로 작업하는 것이 보다 생산적인 것과 같이 훨씬 더 생산적이어야 합니다. 특히 PIM 또는 이와 유사한 것(예: RUP에서의 디자인 모델의 역할을 하는)이 개발된다면 더욱 그렇습니다. 변환 프로세스에서 수동 개입이 어느 정도 필요한지에 따라 생산성 수익이 결정적으로 달라집니다.

품질 페이지 맨 위로

MDA에서 유지보수의 대상은 PIM입니다. 따라서 PIM이 잘 구축되어 있다면 사람이 결함을 만들 수 있는 기회가 줄어들기 때문에 제품 수명에서의 결함이 적어야 하며, 자동화된 변환의 이점을 통해 발견된 결함을 수정하는 데 드는 비용이 적게 들어야 합니다. PIM에 대한 집중은 또한 도메인 문제와도 밀접하게 연관되어 있으므로 사용자의 요구를 보다 만족시킬 수 있어야 합니다.