MDD (Model-Driven Development) 개요

MDD (Model-Driven Development)

Model-driven development (MDD) is a format to write and implement software quickly, effectively and at minimum cost. The methodology is also known as model-driven software development (MDSD), model-driven engineering (MDE) and model-driven architecture (MDA).

 

The MDD approach focuses on the construction of a software model. The model is a diagram that specifies how the software system should work before the code is generated. Once the software is created, it can be tested using model-based testing (MBT) and then deployed.

 

Abstraction and automation are key concept of MDD. 

 

In short, once the business model is created, the code is generated according to the business logic that created by modeling.

 

---

MDD (Model-driven Development) 란

Model-driven Development의 약자이며 모델을 생성하면 코드가 자동으로 생성되는 개발 방법 론이다. UML 모델을 Business logic 에 따라 생성하면 모델로 부터 소스코드를 자동 생성하게 된다. MDD는 성숙도에 따라서 level 2, 3로 나뉘는 데 100% 실행 가능한 소스코드를 생성할 수 있는 경우 성숙도 level 3 라고 하며 국내에서 level 3를 할 수 있는 곳은 LG CNS 이다. 

 

소프트웨어 개발의 역사는 추상화 수준을 끌어 올리는 방식으로 발전해 왔다. 소프트웨어 개발은 코드 중심의 개발 방식에서 추상화 수준을 한 단계 끌어올린 모델 기반 개발 방식으로 변화되고 있다.

---

MDD (Model-driven Development)  특징

• DevOn MDD는 모델로 부터 100% 실행 가능한 소스코드를 자동으로 생성한다. 즉 비즈니스 로직에 따라 생성한 UML 모델에서 자동으로 소스코드를 생성한다.
• MDD 의 성숙도에 따라서 소스코드가 일부만 생성이 될 수도 있고 100% 실행가능한 소스코드가 생성될 수도 있다.
• MDD는 개발 역량 중심에서 업무 역량 중심으로 변화를 주도한다.
• 개발 언어를 몰라도 업무를 잘 안다면 개발이 가능한 SW 개발 환경이다.
• 코딩 표준, 아키텍처 표준에 대한 자동 반영이 가능하다. 코딩 표준을 맞추지 않으면 코드 생성 자체가 되지 않도록 구조화 되어있기 때문에 설계 품질이 상향 평준화된다.
• 모델, 소스, 산출물이 항상 일치한다. 즉, 현행화가 자동화 되어있다. 
• 업무 흐름이 다이어그램으로 표현되어 있어서 텍스트 기반의 소스코드보다 업무 흐름 파악이 용이하며, 프로그램 언어에 대한 지식이 없어도 업무 흐름 파악이 용이하다.
• MSA 기반 프로젝트에도 MDD 적용이 가능하다.

---

MDD (Model-driven Development)  컴포넌트 기본 지식 

컴포넌트 논리 아키텍처

UI > PBI > CPBI/IBI > EBI > DAO

 

https://wikidocs.net/130219

컴포넌트 종류

1) PBI(Process Business Interface) :

• 사용자에게 결과를 제공하기 위한 완전한 비즈니스 처리 흐름을 가지는 컴포넌트이다.
• 다른 컴포넌트를 조합하는 상호작용을 통해 설계한다.
• 사용자가 요청한 거래를 프레임워크 입장에서 바라보는 것이 서비스이고, 서비스를 관리하는 것이 PBI 이다.

2) CPBI(Common Process Business Interface) :

• 업무 내에서 공통적으로 사용하는 비즈니스 처리 흐름을 구현하기 위해 설계한다.
• 재 사용성을 고려하여 식별한다.
• 업무에서 동일한 비즈니스 처리 흐름이 반복적으로 사용될 때, 이를 공통 비즈니스로서 식별한다.
• 여러 비즈니스에서 공통으로 재 사용하는 프로세스를 CPBI 라고 한다.

3) EBI(Entity Business Interface) :

• 비즈니스 정보를 관리하는 컴포넌트이다.
• 비즈니스 정보를 데이터베이스에 저장하거나 수정, 삭제, 조회하는 작업을 처리한다.
• 시스템의 DBMS 를 핸들링하는 비즈니스 인터페이스를 EBI 라고 한다.

4) IBI 연동 컴포넌트 :

• 자신의 업무 기능을 타 업무에게 제공하기 위한 컴포넌트이다.
• 타 업무 구분의 컴포넌트 상호작용 결과는 해당 업무의 연동 비즈니스 컴포넌트를 통해서 제공 받아야 한다.
• 업무 도메인 간의 서비스 호출 시(기능 사용 시) 다이렉트로 호출을 할 수 없으며 IBI 연동 컴포넌트를 통해서 만 호출이 가능하다. IBI 는 프록시 같은 인터페이스 역할을 한다.
• IBI 를 사용하는 경우 시스템을 물리적으로 분리하고 싶은 경우 IBI 로 되어 있기 때문에 접근 통제가 가능하게 된다. 즉 모듈 별 독립성을 높여준다. (현재는 논리적으로 만 독립이 되어 있는 경우이다. 실제로는 하나의 시스템 내에 업무 단위로 논리적으로 구분되어 있는 업무 도메인들이다.)

컴포넌트 상호 의존 관계

• PBI, CPBI, EBI 는 위에서 아래로 쭉 내려가는 폭포수 모델하고 같다고 생각할 수 있다. 즉 EBI 가 PBI 를 호출하면 안되고, EBI 가 CPBI를 호출하면 안된다. CPBI 가 PBI를 호출하는 것도 안된다.
• 동일 레이어 간에 호출도 불가능 하다. 예를 들어, EBI 에서 EBI 호출, PBI 에서 PBI 호출은 불가능하다. 단, CPBI 는 비즈니스 재 사용이 목적이기 때문에 CPBI 만 유일하게 CPBI 간의 호출을 허용한다. PBI 간  호출은 서비스 연동만 가능하다.

 

---

Reference 

https://www.youtube.com/watch?v=fY5jaSpT0Gc(MDD 소개)

https://www.youtube.com/watch?v=Q70A5lwVWF8(MDD 실습전 알면 도움되는 내용)