24년 1회차

소프트웨어공학이 등장한 배경은 개발 기간 지연·비용 증가와 유지보수의 어려움이다.

1960년대 후반 소프트웨어 규모와 복잡도가 커지면서 일정·예산 초과, 품질 저하, 유지보수 부담이 누적된 이른바 소프트웨어 위기가 체계적인 공학적 접근을 요구하게 되었다.

• 개발 인력은 공급 과잉이 아니라 수요에 비해 부족했던 것이 위기의 한 원인이었다.
• 하드웨어는 빠르게 발전했고, 이를 소프트웨어 생산성이 따라가지 못한 것이 문제였으므로 하드웨어 발전 속도 저하는 배경이 아니다.

제시된 특징을 가진 방법론은 정보공학 방법론이다.

정보공학 방법론은 기업 전체의 정보 전략 계획부터 분석·설계·구축까지 데이터 중심으로 단계를 구조화하고, ERD 등 도형 중심 표기와 CASE 도구를 활용한 개발 자동화를 지향한다.

• 컴포넌트 기반 방법론은 재사용 가능한 컴포넌트를 조립해 개발하는 데 초점이 있다.
• 객체지향 방법론은 데이터와 기능을 묶은 객체를 중심으로 모델링하며 자료 중심 접근과 구별된다.
• 애자일 방법론은 문서와 단계 구조보다 짧은 반복과 변화 대응을 중시하므로 명확한 단계 구조 제시와 맞지 않는다.

옳지 않은 서술은 가, 다, 라이다.

프로세스는 소프트웨어 개발에서 무엇을 해야 하는지 작업과 순서를 정의한 틀이고, 방법론은 그 작업을 어떻게 수행할지 구체화한 것으로 프로세스의 구현에 해당한다.

• 가: 작업을 어떻게 수행하는지 정의하는 것은 방법론이므로 틀렸다.
• 나: 방법론은 조직이 상황에 맞게 선택할 수 있는 프로세스의 구현이므로 옳다.
• 다: 방법론은 구조적·정보공학·객체지향처럼 개발 패러다임에 따라 달라지므로 틀렸다.
• 라: 방법론이 프로세스를 구현하는 관계이므로, 프로세스가 방법론에 따라 결정된다는 설명은 틀렸다.

계획 단계에서 도출해야 할 핵심 요소는 비용과 일정이다.

프로젝트 계획은 규모를 추정해 그로부터 소요 비용과 개발 일정을 산정하는 것이 중심이며, 인력·자원 배분과 도구 선택은 이 두 값을 바탕으로 정해진다.

• 시간과 일정은 사실상 같은 범주로 비용 측면이 빠져 있다.
• 자원과 도구는 비용·일정이 산정된 뒤 결정되는 부수적 요소이다.
• 비용과 자원 조합에는 계획의 또 다른 축인 일정이 빠져 있다.

옳지 않은 설명은 전이 단계를 사용자 전달 전 내부 테스트의 마지막 단계로 본 내용이다.

전이 단계는 완성된 소프트웨어를 사용자 환경에 배포하고 베타 테스트와 사용자 피드백을 반영하는 단계로, 내부 테스트가 아니라 사용자에게 넘겨주는 과정이다.

• 도입 단계는 비즈니스 요구사항과 범위를 확인하고 개략적 아키텍처를 제안한다.
• 정련 단계는 예비 유스케이스를 구체화하고 아키텍처 모델을 확장·확정한다.
• 구축 단계는 유스케이스에 따라 컴포넌트를 개발하고 단위 테스트를 수행한다.

옳지 않은 설명은 적응적 소프트웨어 개발(ASD)의 생명주기에 분할 단계를 넣은 내용이다.

ASD의 생명주기는 추측(Speculation)·협업(Collaboration)·학습(Learning) 세 단계로 구성되며, 분할(Decomposition) 단계는 없다.

• XP는 고객이 개발팀에 상주하며 사용자 스토리와 시나리오를 함께 논의한다.
• 스크럼은 개략적 계획과 아키텍처 설계, 반복되는 스프린트 사이클, 프로젝트 마감 단계로 진행된다.
• 애자일은 요구사항 변화를 전제로 하고 고객 요구에 적극 대응해 반영한다.

옳은 서술은 외부 입력, 내부 논리 파일, 외부 인터페이스 파일에 대한 설명이다.

나 항목이 설명한 계산·통계·그래프·보고서처럼 가공된 데이터를 밖으로 내보내는 것은 외부 출력(EO)이고, 외부 조회(EQ)는 가공 없이 입력에 대한 단순 조회 결과를 돌려주는 트랜잭션이다.

• 외부 입력은 내부 파일을 변경하는 사용자 데이터·제어 입력을 트랜잭션 단위로 센다.
• 내부 논리 파일은 시스템 내부에서 생성·유지·관리되는 논리적 데이터 그룹이다.
• 외부 인터페이스 파일은 다른 시스템이 관리하며 이 시스템이 참조·공유하는 데이터 그룹이다.

COCOMO의 프로젝트 유형은 조직형·반분리형·내장형 세 가지이다.

조직형(Organic)은 소규모 일반 업무용, 반분리형(Semi-detached)은 중간 규모, 내장형(Embedded)은 하드웨어와 밀접한 대규모 시스템으로 규모와 복잡도에 따라 구분한다.

혼합형(Mixed)은 COCOMO의 프로젝트 유형에 없다.

T4가 3일 늘어난 결과 프로젝트는 2일 지연된다.

계획 기준 가장 빠른 완료 시각: T1=1, T2=4, T3=3, T4=4+2=6, T5=4+3=7, T6=6+4=10, T7=7+3=10, T8=7+4=11 이므로 T9는 11일째에 시작한다.

T4가 5일이 되면 T4=4+5=9, T6=9+4=13, T7=9+3=12, T8=11 이 되어 T9는 13일째에 시작한다.

T9 시작이 11일에서 13일로 밀리므로 여유 1일을 제외한 2일만큼 전체 일정이 늦어진다.

옳지 않은 서술은 접근 범위가 private, protected, 수식자 생략, public 순으로 확대된다는 내용이다.

Java의 접근 범위는 private < 수식자 생략(default) < protected < public 순으로 넓어지며, default는 같은 패키지까지, protected는 같은 패키지에 더해 다른 패키지의 하위 클래스까지 허용한다.

• protected 멤버는 다른 패키지에 있어도 X를 상속한 클래스에서 접근할 수 있다.
• private 멤버는 선언된 그 클래스 내부에서만 접근할 수 있다.
• public 멤버는 다른 패키지의 어떤 클래스에서도 접근할 수 있다.

하향식 산정 방법은 델파이 기법과 전문가 판단 기법이다.

하향식 산정은 과거 경험이 있는 전문가가 프로젝트 전체 비용을 먼저 추정하는 방식이고, 상향식 산정은 작업 단위나 규모 지표를 세부적으로 측정해 합산하는 방식이다.

• LOC 기법은 원시 코드 라인 수를 추정해 비용을 계산하는 상향식 기법이다.
• COCOMO는 LOC 기반 규모에 수식을 적용하는 상향식 기법이다.
• 기능점수 기법은 기능 요소를 세어 규모를 산출하는 상향식 기법이다.

단계적(Staged) 모델의 특징은 가, 나, 다이다.

단계적 모델은 조직 전체에 1~5 성숙도 수준을 부여해 낮은 수준에서 높은 수준으로 차례로 올라가며 개선하고, 단일 등급으로 조직 간 비교가 가능하다.

• 개선할 프로세스 영역을 조직이 필요에 따라 선택하는 것은 연속적(Continuous) 모델의 특징이다.
• SPICE와 유사하게 프로세스 영역별 능력 수준을 평가하는 방식 역시 연속적 모델에 해당한다.

가용성은 개선 전 84%, 개선 후 90%이다.

가용성 = 가동 시간 / 전체 시간이며, MTBF는 MTTF와 MTTR의 합이다.
$A=\dfrac{MTTF}{MTTF+MTTR}=\dfrac{MTTF}{MTBF}$

개선 전: MTTF = 250 − 40 = 210시간
$A=\dfrac{210}{250}=0.84$ → 84%

개선 후: MTTF = 380시간, MTTR = 40시간
$A=\dfrac{380}{380+40}\approx 0.905$ → 반올림하여 90%

옳지 않은 설명은 유스케이스 분석이 시스템의 내부 기능을 파악한다는 내용이다.

유스케이스 분석은 액터와 시스템 사이의 상호작용을 사용자(외부) 관점에서 기술해 시스템이 제공할 기능을 도출하는 방법으로, 내부 구현을 다루지 않는다.

• 관찰은 사용자의 실제 업무 수행을 지켜보며 기록하는 방법이다.
• 인터뷰는 이해관계자를 직접 만나 준비된 질문으로 요구를 듣는 방법이다.
• 브레인스토밍은 이해관계자들이 자유롭게 아이디어를 내고 토론하는 방법이다.

옳지 않은 설명은 ISO/IEC 25010으로 개정하면서 ISO/IEC 14598이 포함되었다는 내용이다.

ISO/IEC 9126(품질 모델)과 14598(평가 절차)을 통합·정비한 것은 ISO/IEC 25000 SQuaRE 시리즈이며, 25010은 그중 9126의 품질 모델을 대체한 품질 모델 표준이다.

• 25010에서는 보안성과 호환성이 새로운 주특성으로 추가되었다.
• 주특성은 기존 6개에서 8개로 늘었다.
• 주특성 확대와 함께 부특성도 세분화되어 그 수가 늘었다.

컴포넌트 기반 개발방법론(CBD)에 대한 옳은 설명은 가, 다, 라이다.

CBD는 검증된 컴포넌트를 재사용·조립하므로 개발 기간이 단축되며, 컴포넌트는 인터페이스를 통해 다른 컴포넌트·모듈과 상호작용하고, 외부에서 구입하는 상용 컴포넌트(COTS)도 활용한다.

나는 틀렸다. 컴포넌트 통합은 CORBA, EJB, COM/DCOM 같은 미들웨어의 지원을 받아 이루어진다.

올바른 분류는 기능적 요구사항이 가, 라, 마, 비기능적 요구사항이 나, 다, 바이다.

비기능적 요구사항은 시스템이 무엇을 하느냐가 아니라 어떤 품질 수준으로 동작하느냐에 관한 제약으로, 응답 시간(성능)·보안성·가용성이 대표적이다.

• 3초 이내 결과 표시는 성능 요구이므로 기능적 요구사항으로 분류한 조합은 틀렸다.
• 보안성 요구 사양 만족은 품질 특성이므로 기능적 요구사항으로 분류한 조합은 틀렸다.
• 입력값의 범위·단위 설정과 권한별 분류 설정은 시스템이 수행할 기능이므로 비기능적 요구사항에 넣은 조합은 틀렸다.

모델링에 관한 옳은 설명은 가, 나, 다, 라, 바이다.

마는 틀렸다. 다중 상속은 이름 충돌 등 복잡성 문제로 Java처럼 지원하지 않는 언어도 많아 객체지향의 핵심 요소로 보지 않으며, 핵심 요소는 캡슐화·상속·다형성·추상화이다.

• 절차 중심 방법은 데이터 구조와 이를 처리하는 함수의 집합으로 구성된다.
• 객체 지향 방법은 객체 안에 데이터와 그 데이터를 다루는 함수를 함께 묶는다.
• 클래스는 객체들이 공통으로 갖는 속성과 연산을 정의한 템플릿이다.
• 캡슐화와 정보은닉으로 속성·오퍼레이션을 외부에 감출 수 있고, 다형성은 같은 이름의 메소드가 객체에 따라 다르게 동작하게 한다.

설계원칙에 대한 옳은 설명은 가, 나, 다, 라이다.

마는 틀렸다. 의존 관계 역전 원칙은 고수준 모듈과 저수준 모듈이 모두 추상화에 의존해야 하며, 추상화가 구체적 클래스에 의존해서는 안 된다는 원칙이다.

• 단일 책임 원칙은 한 클래스가 하나의 책임만 갖도록 한다.
• 리스코프 치환 원칙은 상위 타입 자리에 하위 타입을 넣어도 프로그램이 올바르게 동작해야 한다는 원칙이다.
• 개방 폐쇄 원칙은 기존 코드는 수정하지 않고 확장으로 새 기능을 추가하도록 한다.
• 인터페이스 분리 원칙은 범용 인터페이스 하나 대신 클라이언트별로 분리된 작은 인터페이스를 쓰도록 한다.

결합도가 약한 것부터 나열하면 다 → 나 → 라 → 가 → 마이다.

결합도는 자료 < 스탬프 < 제어 < 외부 < 공통 < 내용 순으로 강해진다.

• 다: 매개변수로 값만 전달하는 자료 결합도로 가장 약하다.
• 나: 레코드·배열·구조체를 전달하는 스탬프 결합도이다.
• 라: 전달한 값으로 상대 모듈의 내부 제어 흐름을 결정하는 제어 결합도이다.
• 가: 전역 변수를 공유하는 공통 결합도이다.
• 마: 다른 모듈의 내부 데이터를 직접 수정하는 내용 결합도로 가장 강하다.

요구사항 분석 단계의 산출물로 보기 어려운 것은 프로세스 분해 다이어그램이다.

요구사항 분석 단계에서는 사용자가 시스템에서 무엇을 원하는지를 사용자·외부 관점에서 표현하는 산출물을 만든다. 프로세스 분해 다이어그램은 시스템 기능을 상위에서 하위로 계층적으로 쪼개 처리 단위를 구조화하는 도구로, 이 문항에서는 요구 분석보다 설계 쪽 산출물로 본다.

• 사용자 스토리는 애자일에서 사용자 관점의 요구를 짧은 문장으로 기술한 요구사항 산출물이다.
• 유스케이스 다이어그램은 액터와 시스템의 상호작용으로 기능 요구사항을 표현한다.
• 데이터 플로우 다이어그램은 구조적 분석에서 자료의 흐름과 처리를 모델링하는 대표적 분석 도구이다.

TaxDeduct()는 논리적 응집을 보인다.

매개변수 ftype 값에 따라 switch 문으로 미성년 부양가족·출산·미혼청년 공제처럼 유사한 성격의 서로 다른 처리 중 하나를 골라 수행하므로, 논리적으로 비슷한 기능을 한 모듈에 모아 둔 형태이다.

• 순차적 응집은 한 처리의 출력이 다음 처리의 입력으로 이어지는 경우이다.
• 시간적 응집은 초기화처럼 같은 시점에 실행될 처리들을 모은 경우이다.
• 절차적 응집은 정해진 순서에 따라 여러 처리를 차례로 수행하는 경우이다.

옳지 않은 설명은 휴리스틱 오라클이 모든 임의 입력값에 대한 결과를 제공한다는 내용이다.

모든 입력값에 대해 기대 결과를 제공하는 것은 참(True) 오라클이고, 휴리스틱 오라클은 특정 입력값에만 올바른 결과를 제공하고 나머지는 추정(휴리스틱)으로 처리한다.

• 테스트 오라클은 테스트 결과가 맞는지 판단하는 기준이다.
• 상태 기반 테스트는 상태와 상태 전이를 중심으로 테스트 케이스를 설계한다.
• 테스트 하니스는 드라이버·스텁 등을 갖춰 소프트웨어의 일부만 떼어 테스트할 수 있게 하는 환경이다.

자료 흐름도의 구성 요소가 아닌 것은 의사결정(Decision)이다.

자료 흐름도는 프로세스, 자료 흐름, 자료 저장소, 외부 엔터티(단말)로 구성되며, 제어 흐름을 다루지 않으므로 조건 분기 기호가 없다.

• 데이터 저장소는 자료가 보관되는 곳을 나타내는 구성 요소이다.
• 외부 엔터티는 시스템 밖에서 자료를 주고받는 대상을 나타낸다.
• 프로세스는 입력 자료를 출력 자료로 변환하는 처리를 나타낸다.

의사결정 기호는 순서도나 활동 다이어그램에서 쓰인다.

같은 단계에서 사용되는 짝은 나, 다이다.

자료 흐름도와 유스케이스 다이어그램은 분석 단계, 구조적 도표(구조도)와 클래스 다이어그램은 설계 단계에서 쓰여 각각 같은 단계에 속한다.

• 가: 자료 흐름도는 분석 단계, 시퀀스 다이어그램은 객체 간 메시지를 구체화하는 설계 단계 도구이다.
• 라: 구조적 도표는 설계 단계, 유스케이스 다이어그램은 분석 단계 도구이다.

MVC의 특징은 가, 다, 라이다.

MVC는 애플리케이션을 모델·뷰·컨트롤러로 나누어 비즈니스 로직과 사용자 인터페이스를 분리하므로, 한쪽을 고쳐도 다른 쪽에 영향이 적고 하나의 모델에 여러 뷰를 붙일 수 있다.

나는 틀렸다. MVC는 구성 요소 간 결합을 느슨하게 하려는 구조이다.

동적 UML 다이어그램은 가, 다, 라이다.

UML 2에서 시퀀스·타이밍 다이어그램은 상호작용 다이어그램이고, 유스케이스 다이어그램도 액터와 시스템의 상호작용을 다루는 행위(동적) 다이어그램에 속한다.

나는 틀렸다. 배치 다이어그램은 노드와 산출물의 물리적 배치를 나타내는 구조(정적) 다이어그램이다.

옳지 않은 설명은 시퀀스 다이어그램으로 제어 흐름·동기화·병렬 수행을 분석한다는 내용이다.

시퀀스 다이어그램은 객체 간 메시지 교환을 시간 순서로 보여 주는 데 초점이 있고, 제어 흐름과 동기화·병렬 처리를 분석하는 것은 활동 다이어그램의 주된 용도이다.

• 유스케이스 시나리오를 시퀀스로 그리다 보면 참여하는 객체를 추가로 찾을 수 있다.
• 객체(생명선), 메시지, 활성 막대, 프레임 등으로 구성된다.
• 객체들의 생명선이 나란히 서고 그 사이로 메시지가 오가는 울타리 형태로 동작을 시각화한다.

옳지 않은 서술은 완전 유지보수를 동작성 시험과 완전성 확인으로 설명한 내용이다.

완전(완전화) 유지보수는 사용자의 요구에 따라 새 기능 추가나 성능 개선을 하는 유지보수로, 유지보수 활동 중 비중이 가장 크다.

• 수정 유지보수는 운영 중 발견된 결함을 고친다.
• 적응 유지보수는 하드웨어·운영체제 등 환경 변화에 맞춰 수정한다.
• 예방 유지보수는 잠재적 문제를 미리 찾아 보완한다.

옳지 않은 설명은 알파테스트를 인수자가 설치될 인수시스템 환경에서 수행한다고 한 내용이다.

알파테스트는 사용자가 개발자의 환경(개발 장소)에서 개발자와 함께 수행하는 통제된 테스트이고, 실제 사용 환경에서 개발자 없이 수행하는 것은 베타테스트이다.

• 인수테스트는 크게 알파테스트와 베타테스트로 나뉜다.
• 베타테스트는 다수 사용자가 각자의 실제 환경에서 수행한다.
• 인수테스트는 실제 사용자가 참여하는 현실적인 테스트이다.

설명하는 테스트는 회귀(Regression) 테스트이다.

회귀 테스트는 수정·변경 후 기존 기능에 새로운 오류(부작용)가 생기지 않았는지 확인하기 위해 이전 테스트 케이스를 다시 실행한다.

• 스트레스 테스트는 한계를 넘는 부하를 가해 시스템의 견딤과 복구를 확인한다.
• 신뢰성 테스트는 일정 기간 고장 없이 동작하는지를 확인한다.
• 인수 테스트는 사용자가 요구사항 충족 여부를 확인해 인수를 결정한다.

분류가 다른 것은 자료 흐름 테스트이다.

자료 흐름 테스트는 프로그램 내부에서 변수의 정의와 사용 위치를 추적하는 화이트박스 테스트이고, 나머지는 내부 구조를 보지 않고 입력 조합으로 케이스를 설계하는 블랙박스 테스트이다.

• 직교 배열 테스트는 직교 배열표로 입력 조합을 균형 있게 줄이는 블랙박스 기법이다.
• 페어와이즈 조합 테스트는 모든 변수 쌍의 조합을 최소 한 번씩 포함하는 블랙박스 기법이다.
• 결정 테이블 테스트는 조건과 행동의 조합을 표로 정리해 케이스를 만드는 블랙박스 기법이다.

통합 테스트 방법은 상향식, 연쇄식, 스모크, 빅뱅이다.

통합 테스트는 모듈을 결합하면서 인터페이스 오류를 찾는 단계로, 한꺼번에 결합하는 빅뱅, 하위 모듈부터 결합하는 상향식, 기능 흐름(스레드) 단위로 결합하는 연쇄식, 빌드마다 핵심 기능을 빠르게 확인하는 스모크 테스트가 이에 쓰인다.

스트레스 테스트는 통합 방법이 아니라 과부하 상황을 점검하는 시스템 테스트의 한 종류이다.

옳은 설명은 확인(Validation)이 사용자 관점에서 발주자와 합의한 요구사항을 점검하는 작업이라는 내용이다.

검증은 개발자 관점에서 제품을 올바르게 만들고 있는지(각 단계 산출물이 명세에 맞는지)를, 확인은 사용자 관점에서 올바른 제품을 만들었는지(요구사항을 충족하는지)를 점검한다.

• 설계명세서와의 일치를 점검하는 것은 확인이 아니라 검증의 성격이다.
• 검증과 확인은 계획 단계만이 아니라 개발 전 과정에 걸쳐 수행된다.
• 검증은 계획서가 아니라 각 단계 산출물이 명세에 맞게 만들어졌는지를 점검한다.

요구사항 개발 순서는 도출 → 분석 → 명세 → 검증이다.

먼저 이해관계자로부터 요구를 도출하고, 이를 분석해 충돌·누락을 정리한 뒤, 문서로 명세하고, 마지막으로 명세가 올바르고 완전한지 검증한다.

• 명세를 맨 앞에 두는 순서는 무엇을 적을지 정해지기 전에 문서화하는 셈이라 틀렸다.
• 분석을 명세 뒤에 두는 순서는 정리되지 않은 요구를 문서화하게 되어 틀렸다.

옳지 않은 설명은 추출한 문서를 기반으로 시스템을 개선·변경하는 작업이라는 내용이다.

역공학은 기존 코드에서 설계 정보와 문서를 추출·복원해 이해하는 데까지이며, 이를 바탕으로 시스템을 개선·변경하는 것은 재구조화·재공학의 영역이다.

• 문서 없이 코드만 남은 레거시 시스템을 이해할 때 주로 적용한다.
• 코드 분석을 위해 역공학 도구가 필요하다.
• 소스 코드를 분석해 구조도·다이어그램 등 이해하기 쉬운 형태로 변환한다.

코드 스멜이 아닌 것은 주석이 명확히 처리된 프로그램이다.

코드 스멜은 당장 오류는 아니지만 리팩터링이 필요함을 알려 주는 코드의 나쁜 징후로, 명확한 주석은 오히려 이해를 돕는 요소이다.

• 중복된 로직은 대표적인 코드 스멜이다.
• 복잡한 조건문은 분기 단순화나 다형성 적용이 필요한 스멜이다.
• 읽기 어려운 코드는 유지보수성을 떨어뜨리는 스멜이다.

올바르게 짝지어진 것은 클라이언트-서버 스타일이다.

클라이언트-서버 스타일은 클라이언트가 네트워크로 서비스를 요청하고 서버가 처리 결과를 돌려주는 구조이다.

• 데이터 저장소 스타일은 여러 컴포넌트가 중앙의 공유 데이터를 읽고 쓰는 구조이며, UI와 처리 로직 분리는 MVC의 특징이다.
• 파이프 필터 스타일은 데이터 스트림이 필터를 차례로 거치며 변환되는 구조로, 컨트롤러와 이벤트를 주고받는 구조가 아니다.
• 계층형 스타일은 기능을 계층으로 나누어 각 계층이 바로 아래 계층의 서비스만 이용하는 구조로, 디스패처가 트랜잭션을 분배하는 구조가 아니다.

올바르게 분류되지 않은 묶음은 Flyweight – Composite – Memento – State – Mediator이다.

이 묶음에서 Flyweight와 Composite는 구조 패턴이고, Memento·State·Mediator는 행위 패턴이어서 유형이 섞여 있다.

• Command, Observer, Visitor, Iterator, Template method는 모두 행위 패턴이다.
• Bridge, Proxy, Facade, Adapter, Decorator는 모두 구조 패턴이다.
• Builder, Factory method, Prototype, Singleton, Abstract factory는 모두 생성 패턴이다.

제시된 내용에 부합하는 것은 MSA(Microservice Architecture)이다.

MSA는 시스템을 독립 실행·배포가 가능한 작은 서비스 단위로 나누는 아키텍처로, 전체를 하나로 묶는 모놀리식과 대비된다.

• ROA는 자원을 URI로 식별하고 REST 방식으로 다루는 자원 중심 아키텍처이다.
• MDA는 플랫폼 독립 모델에서 코드를 생성하는 모델 중심 개발 방식이다.
• Data-flow 아키텍처는 데이터가 처리 단계를 따라 흐르며 변환되는 구조이다.