도메인별 모델링

Domain-specific modeling

DSM(Domain Specific Modeling)은 컴퓨터 소프트웨어와 같은 시스템을 설계하고 개발하기 위한 소프트웨어 엔지니어링 방법론이다. 그것은 시스템의 다양한 면을 나타내기 위해 도메인 고유 언어의 체계적인 사용을 포함한다.

도메인별 모델링 언어는 범용 모델링 언어보다 더 높은 수준의 추상화를 지원하는 경향이 있으므로 주어진 시스템을 지정하기 위해 더 적은 노력과 더 적은 낮은 수준의 세부 정보를 필요로 한다.

개요

도메인별 모델링은 또한 종종 코드 생성 아이디어를 포함한다: 도메인별 언어 모델에서 직접 실행 가능한 소스 코드 생성을 자동화한다. 소스 코드의 수동 생성과 유지보수가 자유롭다는 것은 도메인별 언어가 개발자 생산성을 크게 향상시킬 수 있다는 것을 의미한다.[1] 수동 코딩 대비 자동 생성의 신뢰성은 또한 결과 프로그램의 결함의 수를 줄여 품질을 향상시킬 것이다.

도메인별 언어는 1980년대의 CASE 도구 또는 1990년대의 UML 도구에서 이전의 코드 생성 시도와는 다르다. 이 두 가지 모두, 코드 생성기와 모델링 언어는 도구 판매업자에 의해 구축되었다.[citation needed] 도구 벤더가 도메인별 언어와 생성자를 만드는 것은 가능하지만, 도메인별 언어는 하나의 조직 내에서 발생하는 것이 더 일반적이다. 한 명 또는 몇 명의 전문 개발자가 모델링 언어와 생성기를 만들고, 나머지 개발자들은 이를 사용한다.

모델링 언어와 생성기를 사용할 조직에 의해 구축된 모델링 언어와 생성기를 사용하면 도메인의 변경에 대응하여 정확한 도메인과 완벽하게 일치할 수 있다.

도메인별 언어는 일반적으로 특정 도메인의 다양한 추상화 수준을 포함할 수 있다. 예를 들어 휴대전화에 대한 도메인별 모델링 언어는 사용자가 사용자 인터페이스에 대한 높은 수준의 추상화뿐만 아니라 전화 번호나 설정과 같은 데이터를 저장하기 위한 낮은 수준의 추상화를 지정할 수 있게 한다. 마찬가지로 금융 서비스를 위한 도메인별 모델링 언어는 사용자가 주식 및 채권 거래 알고리즘 구현을 위한 하위 수준의 추상화뿐만 아니라 클라이언트를 위한 높은 수준의 추상화를 지정할 수 있도록 허용할 수 있다. 도메인별 모델링은 낮은 레벨의 소프트웨어 아티팩트에 대한 추론에도 도움이 된다.[2]

주제

도메인별 언어 정의

언어를 정의하려면 그 정의를 쓸 언어가 필요하다. 모델의 언어는 종종 메타모델이라고 불리는데, 따라서 모델 언어를 정의하는 언어는 메타메타모델이다. 메타메타모델은 기존 언어의 변형 또는 맞춤화에서 파생된 것과 메타메타모델로 특별히 개발된 것의 두 그룹으로 나눌 수 있다.

파생 메타메타모델에는 엔티티 관계도, 공식 언어, 확장 백커스-나우르 양식(EBNF), 온톨로지 언어, XML 스키마, 메타-객체 설비(Meta-Object Facility, MOF) 등이 포함된다. 이들 언어의 강점은 원어의 친숙함과 표준화에 있는 경향이 있다.

도메인별 모델링의 정신은 특정 작업에 대한 새로운 언어의 창조를 선호하기 때문에, 당연히 메타메타모델로 설계된 새로운 언어가 있다. 이러한 언어에서 가장 널리 사용되는 계열은 OPRR,[3][4] GOPRR,[5] GOPPPRR로 최소의 노력으로 언어 모델링에서 발견되는 것들을 지원하는 데 초점을 맞추고 있다.

도메인별 언어에 대한 도구 지원

많은 범용 모델링 언어는 이미 CASE 도구 형태로 도구 지원을 제공하고 있다. 도메인별 언어의 시장 규모는 너무 작아서 처음부터 맞춤형 CASE 툴의 구축을 지원할 수 없는 경향이 있다. 대신, 도메인별 언어에 대한 대부분의 도구 지원은 기존의 도메인별 언어 프레임워크를 기반으로 하거나 도메인별 언어 환경을 통해 구축된다.

도메인별 언어 환경은 변형 도구, 즉 모델링 도구 또는 CASE 도구를 정의하는 데 사용되는 모델링 도구로 생각할 수 있다. 결과 도구는 도메인별 언어 환경 내에서 작동하거나 별도의 독립 실행형 프로그램으로 생산되는 경우가 적을 수 있다. 보다 일반적인 사례에서 도메인별 언어 환경은 기존의 CASE 도구와 비교할 때 추상화 계층을 추가로 지원한다.

잘 설계된 도메인별 언어 환경은 도메인별 편집자, 브라우저 및 구성 요소와 같이 처음부터 구축 비용이 많이 드는 프로그램 부품의 생성을 자동화하기 때문에 도메인별 언어 환경을 사용하면 도메인별 언어에 대한 도구 지원을 얻는 데 드는 비용을 크게 절감할 수 있다. 도메인 전문가는 도메인별 구성과 규칙만 지정하면 되고, 도메인별 언어 환경은 대상 도메인에 맞춘 모델링 도구를 제공한다.

기존의 대부분의 도메인별 언어는 MetaEdit+ 또는 Actifsource와 같은 상업적, GEMS와 같은 오픈 소스 또는 GME와 같은 학문적 언어 환경에서 이루어진다. 도메인별 언어의 인기가 증가함에 따라 도메인별 언어 프레임워크가 기존 IDE에 추가되었다(예: Eclipse Modeling). EMF 및 GMF 또는 Microsoft의 소프트웨어 공장용 DSL Tools로 프로젝트(EMP)

도메인별 언어 및 UML

UML(Unified Modeling Language)은 주로 객체 지향 프로그래밍을 지원하도록 설계된 소프트웨어 집약적 시스템을 위한 범용 모델링 언어다. 결과적으로, 도메인별 언어 언어와 대조적으로, UML은 광범위한 도메인 전체에 걸쳐 매우 다양한 용도로 사용된다. UML이 제공하는 원시적 요소는 객체 지향 프로그래밍의 것이고, 도메인별 언어는 그 도메인의 모든 실무자에게 의미론이 익숙한 원시적 요소를 제공한다. 예를 들어, 자동차 공학 분야에서는, 잠김 방지 제동계통, 또는 조향 휠 등의 특성을 나타내는 소프트웨어 모델이 있을 것이다.

UML은 특정 도메인 및 플랫폼에 대해 제약되고 사용자 정의될 수 있는 프로파일 메커니즘을 포함한다. UML 프로파일은 고정관념, 고정관념 속성(UML 2.0 이전에 태그가 지정된 값으로 알려져 있음) 및 제약조건을 사용하여 UML의 범위를 특정 영역으로 제한하고 확장한다. 아마도 특정 도메인에 대한 UML 사용자 정의의 가장 잘 알려진 예는 시스템 엔지니어링을 위한 도메인 특정 언어인 SysML일 것이다.

참고 항목

참조

  1. ^ Kelly, S.와 Tolvanen, J.-P. (2008) 도메인별 모델링: 뉴저지 주 John Wiley & Sons, 풀 코드 생성 활성화. ISBN978-0-470-03666-2[1]
  2. ^ Eichberg, Michael; Monperrus, Martin; Kloppenburg, Sven; Mezini, Mira (2010), "Model-Driven Engineering of Machine Executable Code" (PDF), Modelling Foundations and Applications, Lecture Notes in Computer Science, vol. 6138, pp. 104–115, doi:10.1007/978-3-642-13595-8_10, ISBN 978-3-642-13594-1, retrieved 2019-03-06
  3. ^ R.J. 웰키 CASE Repository: 다른 데이터베이스 애플리케이션보다 더 많이. W.W. Cotterman과 J.A.에서. Senn, 편집자, 1988년 INC 심포지엄 시스템 분석 및 설계: A Research Strategy, A Research Strategy, 1988년 조지아 주 애틀랜타. 조지아 주립 대학교. [2]
  4. ^ 스몰랜더, K, (1992) OPRR - 시스템 개발 방법 모델링 모델 인: 차세대 CASE 도구(edds. K) 리티넨, V.P. 타바나인엔) 네덜란드 암스테르담의 IOS 프레스, 224-239페이지.[3]
  5. ^ Kelly, S, Lytinen, K, Rossi, M, "MetaEdit+: 완전히 구성 가능한 다중 사용자 및 Multi-Tool CASE 환경", CAiSE'96, 8번째 Intl의 Procedures of CAiSE'96, 8번째 Intl. 고급 정보 시스템 엔지니어링 회의, 컴퓨터 과학 1080, Springer-Verlag, 페이지 1-21, 1996. (박사 논문 3mtools.pdf)

외부 링크