MDD The Pragmatics of Model-Driven Development Bran Selic, IBM Rational Software 서강대 정보통신대학원 소프트웨어공학 차우람 (A50014) 조용성 (A49012) 최종 수정

목차 MDD 소개 MDD 등장 배경 (The Challenge) MDD 필수 기술 요소 (The Essentials) MDD 모델 특성 (The Quality of Models) MDD 성공 요건 (The Pragmatics) 에필로그

MDD 소개

Model: – 라틴어 modellus (small measure) 에서 유래 – 기존 또는 계획 예정인 대상물 ( 실물 ) 의 입체적인 특성을 명시하기 위해 실물을 본떠 만든 것 ( 두산백과사전 ) Development: – 여러 방법을 통해 문제를 해결하는 능동적인 과정 (An active process of problem solving via analysis and synthesis of alternatives...) Mraidha_Part1.pdf

MDD 소개 Model Driven Development – 소프트웨어 개발 방법론 – 플랫폼 독립적인 SW 모델로부터 플랫폼 종속적인 SW 모델로 변환 ( 자동 ) 하고, 소스코드 및 산출물을 자동 생성하는 방법 – 원하는 플랫폼에 맞는 SW 를 쉽고 빠르게 개발 가능, SW 완성 전에 확인과 검증 가능 Shift to model driven development 출처 : 출처 : A4%ED%85%8D%EC%B2%98

MDD 등장 배경 The challenge

MDD 등장 배경 당시 기대에 미치지 못하는 SW 공학의 위치 – 참고 SW 공학 –Software Crisis 극복을 위한 방법으로 SW 공학 제안 (1968, NATO 소프트웨어공학 학회 ) – 미리 협의된 기간 ( 납기 ) 과 허용된 비용 ( 예산 ) 내에서 고객의 니즈를 만족시킬 수 있 는 품질을 갖춘 소프트웨어를 만들고, 유지보수하기 위한 ( 공학적인 ) 접근 방법 SW: 컴퓨터 프로그램과 관련 데이터의 모음이자 문서 ( 요구사항 스펙, 설계, 테스트 계획 도 포함 ) 신뢰성, 생산성 향상을 위한 새로운 방법이 필요 – 기존 방법 ( 프로그래밍 기술, 프로세스 개선 등 ) 만으로는 근본적인 향상, 해결 불가 능

MDD 등장 배경 생각을 표현하고, 이 표현한 것을 이용하여 개발하는 방법에 관심 – 핵심 개념 : 추상화 (abstraction) The first true generational shift in basic programming technology since the introduction of compilers. 필요한 부분만을 표현할 수 있고 불필요한 부분 을 제거하여 간결하고 이해하기 쉽게 만드는 작 업 [ 네이버 지식백과 ] 추상화 [abstraction] ( 컴퓨터인터넷 IT 용어대사전, , 일진사 )

MDD 필수 기술 요소 The essentials

MDD 필수 기술 요소 자동화 기술 (Automation technologies ) – 생산성과 신뢰성을 높이기 위한 가장 효과적인 기술 – 분야 모델로부터 자동으로 완전한 프로그램 생성 컴퓨터에서 모델 검증 (verifying) ( 예 : 실행 등 ) – 현실적인 어려움 불완전한 자동화 – 제한된 적용범위 : 다이어그램, 스켈레톤 (skeleton) 코드 생성 정도 –RTE 가 원활하지 않아서 유지보수에 어려움 : 자동으로 코드를 모델 형태로 변환하 는 것이 불가능 하기 때문 » 참고 : RTE(Round-trip engineering): 두 가지 이상의 artifact 간 synchronization 을 처리 – 현재 이전보다 성숙한 수준에 이르렀으며, SW 개발 환경과 프로세스에 통합되고 있음

MDD 필수 기술 요소 표준화 기술 (Standards) – 심도 있는 진전을 위한 방안을 제공 – 내용 Best practices 방법론, 프로세스 등 – 예 MDA (model driven architecture) by OMG(Object Management Group, 2003 년 ) –MDD 를 지원하는 표준을 정의한 개념적인 Framework 제안 ( 참고 ) 참고 – 주요 MDA 표준은 UML(Unified Modeling Language – 통합 모델링 언어 ) 웹 표준 –XML, SOAP 등 OMG's Model Driven Architecture

MDD 모델 특성 The quality of models

MDD 모델 특성 엔지니어링 모델이 유용하고 효과적이기 위한 5 가지 주요 특성 – 추상화 (abstraction) [ 가장 중요 ] 시스템의 축약된 형태 중요한 부분을 쉽게 이해할 수 있어야 함 – 주어진 관점에 상응하지 않는 자세한 부분을 숨기거나 제거 – 이해용이성 (understandability) 모델 이해를 위해 지적 노력의 양을 감소, 단축 시켜 제공해야 함 – 정확성 (accuracy) 시스템의 기능을 사실적인 표현 – 예측력 (predictiveness) 실험과 분석을 통한 결과의 예측 가능한 모델 – 저렴한 비용 (must be inexpensive) 모델은 시스템을 만들고 구축하는 것보다 충분하게 저렴해야 함

MDD 모델 특성 SW 모델링 테크닉은 제한적으로만 성공 – 이유 앞선 특성 중 하나 또는 두 가지 이상 충족 시키는데 실패 모델이 SW 구현과 직접적으로 연관되지 않음 모델의 변경 ( 주로, 모델 검증 과정 ) 로 인한 통합과 유지보수 어려움 SW 종사자의 불신 ( 불필요한 오버헤드로 인식 ) Incremental iterative 개발 스타일에 부분적으로 기여 – 모델이 정확한 것을 전제로, 여러 번의 재개선과 모델 적용이 용이함

MDD 성공 요건 The pragmatics

MDD 성공 요건 Model-level observability ( 모델 수준 관찰력 ) – 모델이 가지고 있는 모델 자체의 에러에 대해 확인 ( 리포팅 ) 이 가능해야 함 프로그래밍 언어의 컴파일러나 디버거에서 확인 가능한 것과 유사한 형태 모델로부터 생성된 코드와 모델 사이의 semantic gap 이 고려되어야 함 –Customizable transformation “template” 필요 – 모델 병합 및 비교 도구가 필요 ( 형상 관리 측면 )

MDD 성공 요건 Model executability ( 모델 실행력 ) – 모델을 통한 실행으로 이점을 가짐 ( 지식과 이해의 차이를 실험으로 확인 ) – 실행이 가능해야 검증이 가능 (MDD 에서는 중요 ) – 시뮬레이션 (simulation) 환경 – 실제 환경 (actual target) 환경 – 시뮬레이션, 실제 환경 조합 Efficiency of generated code ( 생성 코드의 효율성 ) –( 컴파일러에서 내부적으로 처리하는 것 같이 ) 효율성을 가진 코드가 모델 로부터 생성되어야 함 ( 오버헤드가 포함되기 때문 ) 주로, 성능 ( 처리량 ) 및 메모리 이용률  기술의 발전으로 점점 제한 이 완화되는 추세 – 특수한 경우에는 여전히 수작업 코드가 필요 ( 예 : safety critical 분야 등 )

MDD 성공 요건 Scalability ( 확장성 ) – 대규모 (large scale) 산업 응용프로그램에 가장 유리 작은 변경 (small chages) 에 대응하기 어려움이 있음 –Compilation time, System size 고려 Integration with legacy environments and systems ( 기존 환경 및 시스템과의 통합 ) –MDD 는 상대적으로 신기술이므로 기존의 툴과의 원활한 사용이 가능해 야 함 컴파일러, 빌드 유틸리티, 디버거, 코드 분석기, 버전 제어 시스템 등 ): 마이그레이션 = 리스크 – 기존 코드 라이브러리, 소프트웨어의 활동도 가능해야 함

에필로그 마치며

MDD 장, 단점 / 적용 예 비즈니스 설계를 최적화 함 복잡한 요구사항도 컴포넌트 분리 설계로 확장이 유리 시스템의 완성 전 조기 테스트가 가능 (  Model executability ( 모델 실행력 )) 생산성 향상, 시간 절약, 요구 사항의 정확한 설계가 가능 가시적인 설계 모델로 쉽고, 빠르게 유지보수 및 업무 인수인계 가능 비 프로그래머를 통해 설계 가능 모델링 언어 및 자동 코드 생성에 전제를 두지 않음 MDD 를 적용하는 개인의 경험과 프로젝트 관리의 관점을 허용하지 않는 한, 생산성의 신뢰성에 보장할 수 없다.

변화 대응 개발자의 수작업 프로그래밍 방식에서 자동화 도구로 변화 비 개발자도 MDD 접근 및 설계가 가능  현 개발자의 직무 전환이 필요할 수 도 있음 모델 설계자의 역할이 중요해짐 ( 도메인 전문가 ) MDD 도입에 따른 기존 개발 인력 비용보다 솔루션 구매 비용으로 흘러감 MDD 도입에 따른 기본 정책 변화와 교육 없을 경우, 기본 프로그래밍 개발자 의 실업 발생 가능성 있음

감사합니다.