도메인별 멀티모딩
Domain-specific multimodeling도메인별 멀티모딩은[1] 각각의 관점이 별도의 도메인별 언어(DSL)로 명시적으로 만들어지는 소프트웨어 개발 패러다임이다.
현대 기업 시스템의 성공적인 개발은 다중 관점의 융합을 필요로 한다.비즈니스 분석가, 도메인 전문가, 상호작용 설계자, 데이터베이스 전문가, 그리고 다른 종류의 전문지식을 가진 개발자들이 모두 그러한 시스템을 구축하는 과정에 참여한다.서로 다른 작업 제품은 관리, 정렬 및 통합되어 실행 시스템을 생산해야 한다.개발 과정의 모든 참가자는 시스템에 대한 관점에 특정한 문제를 해결하기 위해 맞춤화된 특정 언어를 가지고 있다.이러한 서로 다른 관점을 통합하고 여러 가지 다른 언어의 잠재적인 불협화음을 피해야 하는 과제는 조정 문제다.
단일 언어 프로그래밍 및 범용 모델링과 같은 전통적인 개발 패러다임과 비교할 때 도메인별 멀티모딩이[1] 유망하다.이 새로운 패러다임의 이익을 거두기 위해서는 조정 문제를 해결해야 한다.이 문제는 Global Model Management의 맥락에서 단편화 문제라고도 알려져 있다.
이 문제를 해결하기 위한 하나의 제안은 조정 방법이다.[1]서로 다른 관점을 통합하고 다국어를 조율하는 장애물을 극복하기 위한 3단계 방법이다.이 방법은 (1)을 식별하고 (2) 다른 언어 사이의 중복인 언어 경계에 걸친 참조를 지정하는 방법을 규정한다.마지막으로, 이 방법은 (3) 이 지식을 일관성, 탐색 및 지침의 형태로 실제 개발에 적용하는 방법에 대한 구체적인 제안을 제공한다.
동기부여 사례
다중 도메인별 언어에 기반한 엔터프라이즈 시스템이 풍부하다.XML(Extensible Markup Language)에 정의된 변형 언어를 사용하는 언어는 특히 널리 채택되고 있다.다국어로 개발을 설명하기 위해 사례 연구에서 예를 들어,Apache Open For Business(OFBIZ) 시스템.간단히 말하면, OFBIZ는 재고, 회계, 전자상거래 등과 같은 표준 구성 요소를 포함하는 기업 자원 계획 시스템이다.이러한 구성요소는 XML 기반 언어와 일반 자바 코드가 혼합되어 구현된다.예를 들어, 컨텐츠 관리 컴포넌트, 특히 관리 사용자가 아래 스크린샷과 같이 온라인 웹 설문조사를 작성하는 활용 사례에 초점을 맞추자.우리는 이 사례를 설문 조사 생성 사례로 언급할 것이다.
그림은 실행 중인 OFBIZ 인스턴스에서 콘텐츠 관리 애플리케이션의 관리 인터페이스 스크린샷을 보여준다.설문조사를 작성하기 위해 사용자는 입력 양식의 필드를 작성하고 업데이트 단추를 누른다.이것은 편집되어 나중에 OFBIZ의 프런트엔드 웹사이트에 게재될 수 있는 새로운 설문조사를 만든다.이 사용 사례는 여러 언어로 쓰여진 여러 공예품들과 관련된다.이 예에서는 기업, 서비스 및 양식 DSL의 세 가지 언어에만 초점을 맞추자.
이 3개 언어는 OFBIZ의 구조, 행동 및 사용자 인터페이스 문제와 대략 일치한다.기업 DSL은 기초적인 데이터 모델과 따라서 생성된 조사가 저장되는 방식을 설명하기 위해 사용된다.서비스 DSL은 사용자가 업데이트 버튼을 누를 때 호출되는 서비스의 인터페이스를 설명하는 데 사용된다.마지막으로 폼 DSL은 폼의 시각적 외관을 설명하기 위해 사용된다.비록 3개 언어가 서로 다른 것에 맞춰져 있지만, 완전히 분리될 수는 없다.사용자 인터페이스는 특정 애플리케이션 로직을 호출하고 이 애플리케이션 로직은 애플리케이션의 데이터를 조작한다.이것은 비직관적인 우려의 한 예다.언어가 중첩되는 것은 그들이 대표하는 관심사가 완전히 분리될 수 없기 때문이다.이 세 가지 언어를 상향식으로 살펴보고 중복되는 점을 지적해 보자.
엔티티 DSL
기업 DSL은 OFBIZ의 데이터 구조를 정의한다.아래 목록은 조사의 개념을 나타내는 사업목적인 조사실체의 정의를 보여준다.Listing의 코드는 스스로 설명할 수 있다.조사라는 실체는 10개의 필드로 정의된다.각 필드에는 이름과 유형이 있다.현장 surveyId가 기본 키로 사용된다.이 정의는 엔티티 엔진이라고 불리는 OFBIZ의 중심 구성요소에 의해 로드된다.엔티티 엔진은 해당 비즈니스 객체를 인스턴스화한다.엔티티 엔진의 목적은 모든 비즈니스 객체의 트랜잭션 속성을 관리하고 Java Database Connectivity, Enterprise JavaBeans 또는 일부 레거시 시스템과 같은 다양한 지속성 메커니즘과 상호 작용하는 것이다.
<< entity> 엔티티 이름="조사" ... 제목="조사 도면요소"> <밭> 이름을 붙이다"surveyId" 타자를 치다"id-ne"/> <밭> 이름을 붙이다"surveyName" 타자를 치다"이름"/> <밭> 이름을 붙이다"description" 타자를 치다"description"/> <밭> 이름을 붙이다"comments" 타자를 치다"comment"/> <밭> 이름을 붙이다"제출 내용" 타자를 치다"짧은 바카르"/> <밭> 이름을 붙이다"응답 서비스" 타자를 치다"롱바차르"/> <밭> 이름을 붙이다"IsAnonymous" 타자를 치다"indicator" .../> <밭> 이름을 붙이다"다중 허용" 타자를 치다"indicator" .../> <밭> 이름을 붙이다"업데이트 허용" 타자를 치다"indicator" .../> <밭> 이름을 붙이다"acroFormContentId" 타자를 치다"id-ne" .../> < 1차 키 들판="surveyId"/> </기호> 서비스 DSL
서비스 DSL은 OFBIZ에서 서비스의 인터페이스를 지정한다.각 서비스는 시스템의 애플리케이션 로직의 일부를 캡슐화한다.이 언어의 목적은 다양한 실행 메커니즘에 대해 통일된 추상화를 갖는 것이다.개별 서비스는 자바, 스크립팅 언어 또는 규칙 엔진을 사용하여 구현할 수 있다.아래 목록은 createSurvey 서비스의 인터페이스를 보여준다.
서비스 요소는 명칭과 별도로 본 서비스에 대한 구현의 위치 및 호출 명령어를 명시한다.default-entity-name 속성은 이 서비스가 이전 목록에 정의된 조사 엔티티를 참조한다고 명시한다.이것은 두 언어의 중첩, 특히 소위 부드러운 참고문헌이다.서비스 DSL의 모형은 기업 DSL의 모형을 가리킨다.이 참조는 서비스의 입력과 출력을 입력된 속성의 형태로 지정하는 아래의 두 개의 자동 속성 요소에 사용된다.입력 시, 서비스 기관은 조사실체의 모든 비주요 키(nonpk) 필드에 해당하는 속성을 받아들이고 이러한 속성은 선택사항이다.출력으로 서비스는 조사(즉, 이 경우 surveyId 필드)의 기본 키(pk) 필드에 해당하는 속성을 반환하며 이러한 속성은 필수 사항이다.언어에 걸친 참조의 목적은 이중화를 줄이기 위한 것이다.createSurvey 서비스의 속성은 조사실체의 필드에 해당하므로 한 번만 명시하면 된다.
<서비스명="설문 작성" default-entity-name="측량"...location="org/ofbiz/content/surveyServices.xml" 호출="Survey" 생성"...<permission-service service-name="contentManagerPermission" main-action="CREATE"/><auto-attributes clude="nonpk" mode="IN" 선택사항="참"/> <자동특성포함="pk" 모드="OUT" 선택사항="거짓"/> </서비스>양식 DSL
Form DSL은 사용자 인터페이스에서 입력 양식의 레이아웃과 시각적 외관을 설명하는 데 사용된다.언어는 Form과 Field와 같은 도메인 개념으로 구성된다.아래 목록은 EditSurvey 양식의 구현을 보여준다.이번에는 양식 DSL이 서비스 DSL과 겹친다.양식의 목표 속성과 알트 타겟 요소는 이 양식의 제출로부터의 입력을 updateSurvey 또는 createSurvey 서비스로 향해야 함을 명시한다.자동 필드 서비스 요소는 양식에 updateSurvey 서비스의 각 속성(createSurvey 서비스의 속성과 유사한)에 해당하는 필드를 포함하도록 명시한다.이는 이전 목록의 자동 속성 요소의 경우와 마찬가지로 다른 모델에서 정의를 가져오는 것과 유사한 효과를 산출한다.더 아래로, 우리는 isAnonymous와 같은 수입된 필드의 외관을 사용자 정의할 수 있다는 것을 알 수 있다.마지막으로, 사용자가 참조된 서비스에 데이터를 제출할 수 있도록 현지화된 제목과 함께 제출 버튼이 추가된다.
<형식명="EditSurvey" type="single" target="updateSurvey" title="updateSurvey"="updateSurvey" title="survey"="searvey"="surveyearch!=null" 이름="surveyId" ... /> ...<필드 이름="IsAnonymous"> <drop-down no-current-selected-key="N" allow-empty="false" > <옵션 키="Y"/><옵션 키="N"/> </drop-down> </field> ...<필드 이름="제출버튼" 제목=${uiLabelMap.CommonUpdate}" 위젯 스타일="SmallSubmit" > <제출 버튼 유형="버튼"/></field> </form>여기서 설명한 것처럼, 조사 생성 예는 3가지 언어로 된 모델을 사용하여 구현된다.완전한 구현에는 실제로 양식이 배치된 화면의 레이아웃을 명시하기 위한 화면 DSL과 서비스를 구현하기 위해 사용되는 데이터 조작 언어인 민일랑 DSL과 같은 훨씬 더 많은 언어가 포함된다.그러나, 이 3개 언어는 각각의 관심사를 구체화하려는 주요 생각을 잘 보여준다.그 예는 언어가 약간 겹치게 함으로써 중복성을 줄이는 간단한 방법도 보여준다.
다단계 사용자 정의
위에서 설명한 것과 같이 도메인별 언어는 표현력이 제한적이다.언어의 범위를 벗어난 전문적 기능성을 구현하기 위해서는 자바와 같은 범용 언어로 코드 스니펫을 추가해야 하는 경우가 많다.이 방법을 다단계 사용자 정의라고 한다.[2]이 방법은 다국어를 사용하는 설정에서 매우 흔하게 사용되기 때문에, 예제의 계속으로 설명하겠다.이것을 빌드 PDF 예라고 하자.
사용자가 생성하는 온라인 설문 조사에 대한 각 설문 조사 응답에 대한 PDF 파일을 만들려고 한다고 가정해 보십시오.PDF 파일을 만드는 것은 우리 언어의 범위를 벗어나기 때문에 우리는 이 전문 기능을 수행하기 위해 제3자 PDF 라이브러리를 호출할 수 있는 Java 코드를 써야 한다.다음 두 가지 아티팩트가 필요함:
첫째, 구체적인 서비스의 접점을 규정하는 서비스 DSL의 추가 서비스 모델은, 모델링 수준에서 접속할 수 있도록 하기 위함이다.서비스 모델은 구현의 위치와 입력 및 출력 속성이 무엇인지 설명한다.
<봉사. 이름을 붙이다"빌드PDfFromSurveyResponse" 엔진="java" 위치="content.ofbiz.content."survey.PdfSurveyServices" 호출하다="빌드PDfFromSurveyResponse"> << attribute> 이름을 붙이다"surveyResponseId" 모드="IN" 선택적="거짓말" .../> << attribute> 이름을 붙이다"outByteWrapper" 모드="OUT" 선택적="거짓말" .../> </서비스> 둘째, 본 서비스의 실제 구현을 포함하는 코드 조각이 아래와 같이 필요하다.서비스는 여러 개의 입력과 출력을 가질 수 있으므로 Java 메서드에 대한 입력은 인수 이름에서 인수 값까지 컨텍스트라고 불리는 맵이고 결과라고 불리는 다른 맵의 형태로 출력을 반환한다.
공중의 정태의 지도 빌드pdfPromSurveyResponse (디스패치콘텍스트 dctx , 지도 문맥) { 끈 id = (끈) 문맥.얻다("surveyResponseId"); 지도 결과. = 새로운 해시맵(); 해보다 { // ...데이터베이스에서 응답이 검색됨... // ...pdf는 응답으로부터 구축된다... // ...pdf는 bytearray로 연재된다... 바이트워퍼 outByteWrapper = ...; 결과..놓다("outByteWrapper",outByteWrapper ); } 잡히다 (예외 e) {} 돌아오다 결과.; } 이 다단계 사용자 정의 방법은 설문 조사 작성 예시와 유사한 소프트 참조를 사용한다.주요한 차이점은 여기서 참조가 모델과 모델 사이에 있는 것이 아니라 모델과 코드 사이에 있다는 것이다.이 경우 PDF 구축을 위한 제3자 자바 라이브러리를 활용할 수 있는 장점이 있다.또 다른 대표적인 애플리케이션은 Java 코드 스니펫을 사용하여 외부 웹 서비스를 호출하고 적절한 형식으로 결과를 가져오는 것이다.
조정문제
이 사례는 다국어를 발전시킬 때 얻을 수 있는 이점의 일부를 보여준다.그러나 이러한 종류의 개발과 관련된 어려움도 있다.이러한 어려움은 우리가 우리의 공정에 더 많은 종류의 유물을 도입할수록 개발자 노력 사이의 조율이 더 필요하다는 관찰에서 비롯된다.우리는 이러한 어려움을 조정 문제로 언급할 것이다.조정 문제는 개념적이고 기술적인 측면이 있다.개념적으로, 주요 문제는 다른 언어와 그들의 상호작용을 이해하는 것이다.다국어로 모델을 적절히 설계하고 조정하려면, 개발자들은 언어가 어떻게 상호작용하는지에 대한 충분한 이해를 가지고 있어야 한다.기술적으로 가장 큰 문제는 일관성을 강요하는 것이다.모순을 조기에, 즉 모델링 시간에 감지하고 개발자가 이러한 불일치를 해결하는 데 도움을 줄 수 있는 도구가 제공되어야 한다.다음에서는 이 두 가지 측면을 더 자세히 살펴볼 것이다.
개념적 과제로서의 조정
다국어로 개발을 시작할 때 개발자들이 겪는 첫 번째 문제는 언어 불협화음이다.서로 다른 언어를 배우고 그 상호작용을 이해하는 것은 유물의 복잡한 구성을 이해하는데 필요하다.예를 들어 OFBIZ 프레임워크는 17개의 다른 언어와 200,000개 이상의 도메인별 언어 코드를 가지고 있어 복잡성이 상당히 클 수 있다!개발자가 운영상의 이해에 빠르게 도달할 수 있도록 서로 다른 언어의 특성화 방법이 현재 확립되어 있지 않다.개발자들은 일반적으로 실험을 통해 학습하기 위해 도구를 사용하기 때문에 도구들은 학습과 탐구를 위한 특별 메커니즘으로서 중요하다.특히 도메인별 모델에 대한 도구가 도움이 되는 세 가지 영역이 있다.
- 언어 이해
- 언어 상호 작용 이해
- 언어 사용 방법 이해
첫째로, 언어를 이해하는 것은 어려울 수 있고 XML 기반의 도메인별 언어의 경우 자주 직관적인 반대는 구문에 반대한다.이 주장은 다음과 같은 방법으로 진술할 수 있다: "다른 언어는 이해하기 어렵고 XML 기반의 구문이 특히 장황하고 이해할 수 없기 때문에 혼란만 가중시킬 뿐이다.개발자들은 이미 알고 있는 구문에 의존할 수 있기 때문에 Java와 같은 하나의 범용 언어를 사용하는 것이 더 나을 것이다."이 반대는 분명히 중요하지만, 중심점을 놓친다.XML 또는 유사한 표현 형식이 개발자가 실제로 작업하는 구문이 아닐 수 있다.XML 기반 도메인별 언어를 사용할 때의 장점 중 하나는 도메인별 편집기를 제공할 수 있다는 것이다.아래 그림은 기업 DSL의 가상 편집자가 어떻게 생겼는지 보여준다.이 편집기는 단순하고 시각적으로 매력적인 방식으로 도메인을 표시하지만, 아래에서 XML 표현(및 아마도 레이아웃 구성)을 매우 잘 사용할 수 있다.
XML이 잘못된 선택이라고 불평할 수 있듯, 우리는 자바와 같은 범용 언어가 일부 업무에서는 좋지 않은 선택이라고 이의를 제기할 수도 있다.게다가, 개발자들은 XML이나 자바의 코드 리스트보다 그림의 편집자에 의해 덜 위축될 수 있다.만약 우리가 그 구문이 중요하다는 것을 받아들인다면, 맞춤 편집자와 함께 다른 언어의 사용은 합리적인 전략이 될 것이다.편집자의 단순성은 언어를 이해하기 쉽고 따라서 사용하기 쉽게 만든다.다시 말해서, 구문 문제는 우리가 도메인별 언어의 분야를 탐구하는 바로 그 이유일 수 있다.
둘째, 언어 상호작용이 언어간의 관계를 드러낸다.개발자는 서로 다른 공예품에서 관련 요소 사이를 이동할 수 있어야 한다.다양한 소프트웨어 아티팩트 간의 간편한 탐색은 전통적인 개발 환경에서 도구의 중요한 기준이다.이 분야에서 실증적 연구를 수행한 적은 없지만, 적절한 항법 시설은 생산성을 높인다는 가설을 세운다.이러한 주장은 오늘날 모든 주요 개발 환경은 유형 계층 브라우저와 같은 상당히 정교한 탐색 시설이나 방법 정의에 대한 참조를 신속하게 찾아 점프할 수 있는 능력을 제공한다는 관찰에 의해 뒷받침된다.개발 환경은 추상 구문 트리의 형태로 소스 파일의 지속적으로 갱신된 모델을 유지하기 때문에 이러한 탐색 시설을 제공할 수 있다.
다국어가 있는 개발 환경에서는 내비게이션이 훨씬 더 어렵다.기존 환경은 구문 분석에만 맞추어져 있지 않으며 DSL 모델을 임의의 언어에 대한 추상적인 구문 트리로 나타내며 심지어 이전 예에서 나온 언어와 같은 응용 프로그램 특정 언어에 대한 구문 트리로 표현한다.더욱이 이러한 내부 표현이 없다면, 기존 환경은 그러한 언어에 대한 내부 또는 언어 간 참조를 해결할 수 없으므로 유용한 내비게이션을 제공할 수 없다.이것은 개발자들이 그들의 시스템의 부분들이 어떻게 연관되어 있는지에 대한 개념 모델을 유지해야 한다는 것을 의미한다.다른 한편으로, 여러 언어에 맞춘 항해 설비를 갖춘 새로운 도구는 언어 간의 관계를 이해하는 데 큰 도움이 될 것이다.설문 조사 작성 예제의 관점에서, 그러한 도구는 소프트 레퍼런스를 네비게이션 포인트로 사용하여 3개 언어 사이의 관계를 표시해야 한다.
셋째, 언어 사용을 이해하기 위해서는 개발 환경에서 올바른 편집 작업과 잘못된 편집 작업을 구별할 수 있어야 한다.전통적인 개발 환경은 프로그램을 작성하는 동안 오랫동안 지침을 제공해 왔다.증분 컴파일을 통해 환경은 개발자에게 진술서 작성 방법과 같은 상세한 제안을 제공할 수 있다.문법에 맞는 입력만 입력할 수 있는 구문 지향 편집기 등 좀 더 침입적인 종류의 지침도 존재한다.언어의 문법으로 매개할 수 있는 일반적인 텍스트-편집자는 오랫동안 존재해왔다.[3]
기존 편집자들은 지침을 제공할 때 언어간 일관성 관계를 고려하지 않는다.앞의 예에서 이상적인 편집자는 예를 들어 개발자가 양식 정의에서 대상 속성을 편집할 때 유효한 값으로 createSurvey 서비스를 제안할 수 있어야 한다.다른 언어의 유물에 대해 논증할 수 있는 환경은 개발자가 지역적이기는 하지만 글로벌한 일관성이 없는 프로그램 상태를 식별하는 데 도움을 줄 수 있을 것이다.그러한 상황은 모델이 잘 형성되어 있고 따라서 국소적으로 일관되지만 동시에 언어간 제약조건을 위반할 때 발생할 수 있다.모델을 완성하는 방법에 대한 제안 형식의 지침 또는 지능형 지원은 다국어 및 복잡한 일관성 제약을 가진 설정에 유용할 것이다.도구에서 제안하는 편집 작업은 개발자가 언어 사용법을 배우는 과정을 더 쉽게 시작할 수 있도록 할 수 있다.
기술적 당면 과제로서의 조정
조정 문제의 기술적 측면은 본질적으로 일관성을 강화하는 문제다.모델링 시 여러 언어의 모델 간에 불일치를 어떻게 감지할 수 있는가?다국어에 기초한 시스템의 일관성 요구사항의 복잡성을 완전히 이해하려면 일관성 개념을 세분화하는 것이 유용하다.
일관성은 내부 또는 상호 일관성 중 하나가 될 수 있다.내부 일관성은 단일 모델 내에서 요소의 일관성에 관한 것이다.여기서 요구되는 것은 모델이 그것의 변형에 부합해야 한다는 것이다. 즉, 구문적으로 잘 형성되어야 한다.설문 조사 작성 예제의 관점에서, 예를 들어, 기업 모델은 기업 DSL의 XSD 스키마를 준수해야 한다.이 스키마는 기업 DSL의 변형이며, 요소들이 어떻게 구성될 수 있는지, 그리고 어느 정도 유효한 속성의 영역인지를 명시한다.
상호 일관성은 언어 경계에 걸친 참조가 해결될 수 있을 때 달성된다.이러한 종류의 일관성은 (1) 모델 대 모델 일관성과 (2) 모델 대 코드 일관성으로 더욱 세분화될 수 있다.모델 간 일관성은 참조 무결성뿐만 아니라 시스템의 높은 수준의 제약조건과도 관련이 있다.설문 조사 생성 예제에서 서비스 목록의 기본 엔터티 이름 속성은 엔티티 목록의 이름 속성을 가리킨다.이 값들 중 하나를 업데이트하지 않고 변경하면 참조가 깨진다.서로 다른 모델에 걸쳐 더 높은 수준의 일관성 제약도 나중에 논의한 바와 같이 존재한다.프로젝트는 모델 요소의 명칭과 관련성을 위한 일정한 패턴이나 규약을 가질 수 있다.현재의 개발 환경은 이전 사례의 언어와 같은 언어 사이의 일관성을 강화하기 위해 손으로 쓴 플러그 인이나 유사한 메커니즘으로 특정 언어에 맞춤화되어야 한다.
모델-대-코드 일관성은 다단계 사용자 정의에서 필수 요건이다.빌드 PDF 예와 같이 모델을 코드 스니펫으로 보완할 때는 모델과 코드가 실제로 맞는지 확인할 필요가 있다.이것은 모델과 코드 사이의 부드러운 참조가 깨지지 않도록 하는 부분적인 문제로서 모델 간 일관성에서의 참조 무결성과 유사하다.그러나 이 코드가 모델에 설정된 기대치를 위반하지 않도록 하는 것도 문제다.빌드 PDF 예에서 모델은 outByteWrapper가 항상 출력의 일부라고 명시한다. 즉, 결과 맵에 outByteWrapper 키가 삽입된다.코드의 분석에 따르면 10행 전에 예외가 발생하지 않는 경우에만 아웃바이트Wrapper가 출력의 일부가 될 것이다.즉, 코드의 일부 실행은 모델링 수준의 규격을 위반할 수 있다.좀 더 일반적으로, 우리는 다단계 사용자 지정이 관련 모델과 코드 스니펫에 매우 미세한 제약을 부과한다고 말할 수 있다.
조정 문제 해결
조정 문제는 여러 언어를 단일 시스템에서 사용한다는 사실에서 발생한다.앞의 두 하위절은 이 문제가 낮은 수준의 기술적 측면뿐만 아니라 개념적 측면도 가지고 있음을 보여준다.우리가 설명한 도전은 가상의 도전이라기보다는 현실의 도전이다.구체적으로, 우리는 두 가지 구체적이고 대표적인 사례 연구, 즉 기업 자원 계획 시스템, OFBIZ와 건강 관리 시스템인 지역 건강 정보 시스템(DHIS)에서 이러한 과제에 직면했다.두 경우 모두 실제 산업용에 쓰이는 중형 시스템이다.이러한 시스템으로 작업하는 동안 우리가 직면해 온 실제적인 문제에 대한 우리의 해결책은 일련의 지침서와 프로토타입이다.다음에서는 가이드라인과 프로토타입을 일관성 있는 방법인 조정 방법에 통합한 전체적인 개념 체계를 소개한다.
조정법
조정방식의[1] 목표는 조정 문제를 해결하여 다국어로 발전을 위한 더 나은 지원을 제공하는 것이다.그 방법을 제대로 감상하려면 개별 언어의 설계를 규정하지 않는다는 점을 이해하는 것이 중요하다.이를 위해 이미 많은 방법과 도구가 제안되었다.[4][5]이 방법은 다중 도메인 고유 언어를 사용하는 설정의 존재를 가정한다.이런 설정이 있으면 그 방법을 적용할 수 있다.방법은 아래 도표와 같이 3단계로 구성된다.각 단계는 다이어그램에 작은 상자로 표시된 두 개의 부품으로 구성된다.점선이 있는 상자는 자동 공정을 나타내고 실선이 있는 상자는 수동 공정을 나타낸다.다음 내용에서는 이러한 단계를 좀 더 자세히 설명하겠다.
1단계: 식별
식별 단계의 목표는 언어 중복 식별이다.예에서 설명한 것처럼 중복은 두 언어의 우려가 교차하는 영역이다.설문 조사 활용 사례에서 양식 DSL에서 서비스 DSL로, 서비스 DSL에서 기업 DSL로 이어지는 소프트 참조는 그러한 중복의 예들이다.또 다른 예는 모델을 확장하기 위해 사용자 정의된 코드 조각이 사용되는 경우다.이 같은 중복은 모델의 범위를 벗어난 전문요건을 구현하기 위해 범용언어의 표현력이 필요할 때 빈번하게 발생한다.식별 단계는 중복의 복잡성에 따라 수동 또는 자동 프로세스가 될 수 있다.중복이 식별되어 명시적으로 된 경우, 이 정보는 방법의 두 번째 단계인 사양 단계에 대한 입력으로 사용된다.
2단계: 사양
명세 단계의 목표는 언어가 상호작용하는 방법을 지정하는 조정 모델을 만드는 것이다.시스템의 언어 경계에 걸친 참조는 특정 시스템의 조정 모델을 구성한다.주요 소프트웨어 아티팩트를 공통 표현으로 매핑하여 생성한다.도메인 또는 애플리케이션별 제약 조건과 같은 추가 정보도 풍부한 표현을 제공하기 위해 암호화될 수 있다.조정 모델은 언어 문법 및 제약 조건과 같은 일반적인 정보와 함께 구체적인 모델과 적용 특정 제약 조건과 같은 적용 특정 정보에 기초한다.여러 제품에 걸쳐 동일한 언어가 사용되지만 각 제품마다 고유의 독특한 조정 모델의 사양이 있다는 뜻이다.조정 모델은 방법의 최종 단계인 적용 단계에서 다양한 형태의 추론을 위한 기초로 사용된다.
3단계: 적용
애플리케이션 단계의 목표는 조정 모델을 활용하는 것이다.조정 모델은 도구들이 유용한 정보의 세 계층을 도출할 수 있도록 한다.첫째, 조정 모델을 사용하여 여러 언어에 걸쳐 일관성을 시행할 수 있다.조정 모델은 서로 다른 언어의 요소들이 서로 참조할 수 있는 방식과 같은 일관성 관계를 명시한다.도구는 참조 무결성을 적용하고 배치 전에 최종 시스템의 정적 점검을 수행할 수 있다.둘째, 일관성 관계는 개발 설정에서 서로 다른 언어의 웹을 탐색, 시각화 및 매핑하는 데 사용된다.이 정보는 서로 다른 언어의 요소들을 신속하게 연결하고 관련시키고 서로 다른 모델들 간의 추적가능성을 제공하기 위해 사용된다.셋째, 요소들이 어떻게 연관되어 있는지에 대한 일관성 관계와 항법 정보에 기초하여 도구는 특히 완료 또는 지원을 제공하는 지침을 제공할 수 있다.예를 들어 모델 완료는 도메인별 도구 전반에 걸쳐 일반적인 방식으로 제공될 수 있다.
조정방법 평가
조정 방법은[1] 다국어로 작업할 때 일정한 작업흐름을 규정하는 개념적 프레임워크로 가장 잘 볼 수 있다.이 작업흐름을 구성하는 세 가지 연속적인 단계는 통합 작업대나 개발 환경에서 지원되지 않는다.오히려 (1) 식별, (2) 사양, (3) 응용에 대한 지원을 추가하기 위해 개발자의 기존 환경을 확장하는 데 초점을 맞추고 있다.이 접근법의 가장 큰 장점은 개발자들이 실제로 우리의 작업을 테스트하고 피드백을 제공했다는 것이다.이 방법에 대한 이런 식의 평가는 순전히 가상의 문제 해결의 위험을 줄여주기 때문에 가치가 있다.여러 논문에서 조정 방법의 다른 단계를 소개하고, 이 평가에 대해 보고하며, 각 개별 실험의 기술적 측면을 상세히 기술한다.전반적으로, 그 결과는 유망했다. 생산 시스템에서 상당한 수의 오류가 발견되었고 향후 도구 요구사항에 대한 개발자들과 건설적인 대화를 나누게 되었다.이러한 지침에 근거하고 도구에 의해 지원되는 개발 프로세스는 조정 문제를 해결하고 도메인별 멀티모딩을 실질적인 제안으로 만들기 위한 심각한 시도에 해당한다.
참고 항목
참조
- ^ a b c d e Hessellund, Anders (2009). "Domain-Specific Multimodeling". IT University of Copenhagen, Denmark. Retrieved 2009-02-09.
{{cite journal}}:Cite 저널은 필요로 한다.journal=(도움말) - ^ Czarnecki, Krzysztof; Antkiewicz, Michal; Peter Kim, Chang Hwan (2006). "Multi-Level Customization in Application Engineering". Communications of the ACM. 49 (12): 60–65. CiteSeerX 10.1.1.387.4900. doi:10.1145/1183236.1183267. ISSN 0001-0782. S2CID 16925677.
- ^ Nørmark, Kurt (1989). "Programming Environments - Concepts, Architectures and Tools". Aalborg Universitetscenter.
{{cite journal}}:Cite 저널은 필요로 한다.journal=(도움말) - ^ Clark, Tony; Evans, Andy; Sarmut, Paul; Williams, James. Applied Metamodelling - A Foundation for Language Driven Development.
- ^ Bentley, Jon (1986). "Programming pearls: little languages". Communications of the ACM. 29 (8): 711–721. doi:10.1145/6424.315691. ISSN 0001-0782. S2CID 12455883.
