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

Presentation on theme: "MDD The Pragmatics of Model-Driven Development Bran Selic, IBM Rational Software 서강대 정보통신대학원 소프트웨어공학 차우람 (A50014) 조용성 (A49012) 2015-06-11 최종 수정."— Presentation transcript:

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

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

3 MDD 소개

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

5 MDD 소개 Model Driven Development – 소프트웨어 개발 방법론 – 플랫폼 독립적인 SW 모델로부터 플랫폼 종속적인 SW 모델로 변환 ( 자동 ) 하고, 소스코드 및 산출물을 자동 생성하는 방법 – 원하는 플랫폼에 맞는 SW 를 쉽고 빠르게 개발 가능, SW 완성 전에 확인과 검증 가능 Shift to model driven development 출처 : https://www.research.ibm.com/haifa/projects/services/uml/index.shtml 출처 : http://ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8_%EA%B5%AC%EB%8F%99%ED%98%95_%EC%95%84%ED%82% A4%ED%85%8D%EC%B2%98

6 MDD 등장 배경 The challenge

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

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

9 MDD 필수 기술 요소 The essentials

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

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

12 MDD 모델 특성 The quality of models

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

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

15 MDD 성공 요건 The pragmatics

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

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

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

19 에필로그 마치며

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

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

22 감사합니다.