도메인 엔지니어링

Domain engineering

도메인 엔지니어링(Domain Engineering)은 새로운 소프트웨어 시스템 생산에 도메인 지식을 재사용하는 전 과정이다.체계적인 소프트웨어 재사용제품군 엔지니어링의 핵심 개념이다.체계적인 소프트웨어 재사용의 핵심 아이디어는 영역이다.대부분의 조직은 몇 개의 영역에서만 작업한다.그들은 다른 고객 요구를 충족시키기 위해 변형을 가지고 주어진 도메인 내에 유사한 시스템을 반복적으로 구축한다.각 새로운 시스템 변형을 처음부터 새로 구축하기보다는 도메인의 이전 시스템 일부를 재사용하여 새로운 시스템을 구축함으로써 상당한 절감 효과를 얻을 수 있다.

도메인을 식별하고, 도메인을 경계하며, 도메인 내 시스템 간의 공통성과 가변성을 발견하는 과정을 도메인 분석이라고 한다.이 정보는 재사용 가능한 구성요소, 도메인별 언어 또는 도메인에서 새로운 시스템을 구축하는 데 사용할 수 있는 응용프로그램 생성기와 같은 아티팩트를 생성하기 위해 도메인 구현 단계에서 사용되는 모델에서 캡처된다.

ISO26550:2015에 정의된 제품 라인 엔지니어링에서 도메인 엔지니어링은 제품 라인에서 파생된 개별 제품의 수명 주기를 관리하는 애플리케이션 엔지니어링에 의해 보완된다.[1]

목적

도메인 엔지니어링은 소프트웨어 아티팩트의 재사용을 통해 개발된 소프트웨어 제품의 품질을 향상시키기 위해 설계되었다.[2]도메인 엔지니어링은 대부분의 개발된 소프트웨어 시스템이 새로운 시스템이 아니라 같은 분야 내의 다른 시스템 변종이라는 것을 보여준다.[3]그 결과, 도메인 엔지니어링의 활용을 통해, 기업은 이전 소프트웨어 시스템의 개념과 구현을 이용하고, 이를 대상 시스템에 적용함으로써 이윤을 극대화하고, 출시 기간을 단축할 수 있다.[2][4]비용 절감은 이행 단계에서도 확연히 드러난다.한 연구는 도메인별 언어의 사용이 방법 수와 기호 수 모두에서 코드 크기를 50% 이상 줄일 수 있었고, 코드 총 행 를 75%[5] 가까이 줄일 수 있다는 것을 보여주었다.

도메인 엔지니어링은 소프트웨어 엔지니어링 프로세스 중에 수집된 지식을 포착하는 데 초점을 맞춘다.재사용 가능한 유물을 개발함으로써, 부품들은 저비용과 고품질로 새로운 소프트웨어 시스템에서 재사용될 수 있다.[6]이는 소프트웨어 개발 주기의 모든 단계에 적용되기 때문에 도메인 엔지니어링은 또한 애플리케이션 엔지니어링과 병행하여 분석, 설계 및 구현의 세 가지 주요 단계에 초점을 맞춘다.[7]이는 도메인과 관련된 일련의 소프트웨어 구현 구성요소뿐만 아니라 재사용 가능하고 구성 가능한 요건 및 설계도 생산한다.[8]

웹 상의 데이터의 증가와 사물 인터넷의 성장을 고려할 때, 도메인 엔지니어링 접근법은 다른 분야와도 관련이 있다.[9]웹 서비스의 깊은 사슬의 출현은 서비스 개념이 상대적이라는 것을 강조한다.한 조직이 개발하고 운영하는 웹 서비스는 다른 조직이 플랫폼의 일부로 활용할 수 있다.서비스가 다른 맥락에서 사용될 수 있고 따라서 다른 구성을 요구할 수 있기 때문에, 서비스 제품군의 설계는 도메인 엔지니어링 접근방식의 혜택을 받을 수 있다.

단계

애플리케이션 엔지니어링과 비교한 도메인 엔지니어링.도메인 엔지니어링 피드의 각 단계의 출력은 애플리케이션 엔지니어링의 해당 단계뿐만 아니라 도메인 엔지니어링의 후속 단계 모두에 해당된다.

도메인 엔지니어링은 애플리케이션 엔지니어링과 마찬가지로 분석, 설계 및 구현의 세 가지 주요 단계로 구성된다.그러나 소프트웨어 엔지니어링이 단일 시스템에 초점을 맞추는 경우 도메인 엔지니어링은 시스템 제품군에 초점을 맞춘다.[7]좋은 도메인 모델은 프로세스의 후반부에 모호성을 해결하기 위한 참고자료, 도메인 특성과 정의에 대한 지식의 보고, 도메인의 일부인 제품 개발자들에게 명세서를 제공하는 역할을 한다.[10]

도메인 분석

도메인 분석은 도메인을 정의하고, 도메인에 대한 정보를 수집하며, 도메인 모델을 생성하는 데 사용된다.[11]형상모델의 활용(초기에는 형상지향적 도메인 분석법의 일부로 구상됨)을 통해 도메인 내 공통점과 도메인 내 다양한 포인트의 파악을 목적으로 한다.[12]도메인 분석의 사용을 통해, 전통적인 애플리케이션 엔지니어링 접근방식에 의해 생성될 정적 구성이 아닌 구성 가능한 요구사항과 아키텍처의 개발이 가능하다.[13]

도메인 분석은 요구사항 엔지니어링과 상당히 다르며, 따라서 요구사항을 도출하는 전통적인 접근방식은 도메인 모델에 존재하는 구성 가능한 요구사항 개발에 효과적이지 않다.도메인 엔지니어링을 효과적으로 적용하기 위해서는 소프트웨어 개발 수명 주기의 초기 단계에서 재사용을 고려해야 한다.개발된 형상모델의 형상선정을 통해 기술의 재사용에 대한 고려가 매우 일찍 수행되어 개발과정 전반에 걸쳐 적절하게 적용될 수 있다.[14]

도메인 분석은 주로 도메인의 과거 경험에서 생성된 공예품에서 도출된다.[11]기존 시스템, 그 유물(설계 문서, 요건 문서사용자 설명서 등), 표준 및 고객은 모두 도메인 분석 입력의 잠재적 원천이다.[11][15]그러나 요구사항 엔지니어링과 달리 도메인 분석은 정보의 수집과 공식화로만 구성되는 것이 아니다. 창의적인 요소도 존재한다.도메인 분석 과정에서 엔지니어는 이미 알려진 것 이상으로 도메인에 대한 지식을 확장하고 도메인을 유사점과 차이점으로 분류하여 재구성성을 높이는 것을 목표로 한다.[11]

도메인 분석은 주로 도메인 모델을 생성하며, 도메인 내에서 공통적이고 다양한 시스템의 속성을 나타낸다.[11]도메인 모델은 이러한 요소들을 설계하는 기초의 역할을 함으로써 구성 가능한 방식으로 구조와 요소들의 창조를 돕는다.[16]효과적인 도메인 모델은 도메인의 다양하고 일관된 특징을 포함할 뿐만 아니라, 도메인에서 사용되는 어휘를 정의하고 시스템 내에서 개념, 아이디어, 현상을 정의한다.[11][17]형상 모델은 개념을 필수 및 선택적 특징으로 분해하여 구성 가능한 요구 사항의 완전 공식화된 집합을 만든다.[18]

도메인 디자인

도메인 설계는 도메인 분석 단계 동안에 생산된 도메인 모델을 취하며, 도메인 내의 모든 시스템이 준수할 수 있는 일반적인 아키텍처의 생산을 목표로 한다.[19]애플리케이션 엔지니어링이 기능적 요건과 비기능적 요건을 사용하여 설계를 생성하는 것과 같은 방식으로, 도메인 엔지니어링의 도메인 설계 단계는 도메인 분석 단계에서 개발된 구성 가능한 요건을 취하며 시스템 제품군을 위한 구성 가능한 표준화된 솔루션을 생산한다.도메인 설계는 요구사항 구성이 다르더라도 도메인 내의 시스템 전체에서 공통적으로 발생하는 문제를 해결하는 아키텍처 패턴을 생성하는 것을 목표로 한다.[20]도메인 설계 중 패턴 개발 외에도 엔지니어는 패턴의 범위와 문맥이 패턴과 관련이 있는 수준을 식별하기 위해 주의를 기울여야 한다.문맥의 제한은 매우 중요하다. 문맥이 너무 많으면 문맥이 많은 시스템에 적용되지 않으며 문맥이 너무 적으면 문맥이 충분히 강력하지 않아 유용할 수 없다.[21]유용한 패턴은 자주 반복되어야 하며 품질이 우수해야 한다.[22]

도메인 설계의 목적은 개발된 형상 모델이 제공하는 유연성을 유지하면서 가능한 많은 도메인 요건을 충족시키는 것이다.아키텍처는 도메인 내의 모든 시스템을 만족시킬 수 있을 만큼 충분히 유연해야 하며, 해결책의 기초를 확고히 할 수 있을 만큼 충분히 경직되어야 한다.[23]

도메인 구현

도메인 구현은 도메인에서 사용자 정의된 프로그램을 효율적으로 생성하기 위한 프로세스와 도구를 만드는 것이다.

비판

최근 도메인 엔지니어링은 개인의 세계관이나 언어, 또는 문맥이 소프트웨어 설계에 통합될 정도로 '엔지니어링용(engineering-for-use)'[24]에 집중하기보다는 일반 소프트웨어 기능의 '엔지니어링용(engineering-for-for-use)'이나 '엔지니어링-with-with-re-use)'에 지나치게 치중한다는 비판을 받고 있다.

참고 항목

참조

  1. ^ ISO 26550:2015 – Software and systems engineering — Reference model for product line engineering and management
  2. ^ a b 2007년 프레이크 & 강, 페이지 2
  3. ^ 프레이크스 & 강 2007 페이지 1
  4. ^ 체르네키 & 아이제네커 2000, 페이지 19
  5. ^ 바토리2002, 페이지 19
  6. ^ 체르네키 & 아이제네커 2000, 페이지 20
  7. ^ a b 체르네키 & 아이제네커 2000, 페이지 21
  8. ^ 하수 2002 페이지 8
  9. ^ 라인하르트-베르거2013년, 페이지 시이
  10. ^ 팔보, 구어 전어 & 두아르테 2002 페이지 2
  11. ^ a b c d e f 크자르네키 & 아이제네커 2000, 페이지 23
  12. ^ 체르네키 & 아이제네커 2000, 페이지 38
  13. ^ 캉 외 2004년 7월
  14. ^ 캉 외 2004년 3월
  15. ^ 캉 외 2004년 4월
  16. ^ 2007년 3월 3일자 프레이크 & 강
  17. ^ 체르네키 & 아이제네커 2000, 페이지 84
  18. ^ 체르네키 & 아이제네커 2000, 페이지 86
  19. ^ 크자르네키 & 아이제네커 2000, 페이지 24
  20. ^ 체르네키 & 아이제네커 2000, 페이지 25
  21. ^ 부슈만, 헤니 & 슈미트 2007, 페이지 42
  22. ^ 부슈만, 헤니 & 슈미트 2007, 페이지 31
  23. ^ 크자르네키 & 아이제네커 2000, 페이지 28
  24. ^ 메틀러 2017, 페이지 5

원천