정보보안 정보처리 기술사

문) SOA
답)
  1. 서비스 단위 재사용 위한 SOA개요
    가. SOA(Service Oriented Architecture)의 정의
      - 소프트웨어를 기업의 프로세스 관점에서 공유와 재사용이 가능한 "서비스"
        단위로 개발하는 아키텍쳐
    나. SOA의 특징
      - Reuse : 논리적 재사용단위인 SOA Service Block 구성
      - Integration : 표준 Interface (XML, SOAP, WSDL) 통한 통합
      - Agility : 서비스단위 조립을 통한 민첩성 제공
  2. SOA구축 방법론 및 관련 정보기술
    가. SOA 방법론
      1) SOA 전략수립 : 고객사현황분석, 요구사항 정의, SOA목표및 전략수립
      2) Biz 프로세스 수립 : Biz 프로세스 분석, 현행 App 분석
      3) 서비스 정의 : 서비스 식별, 서비스 명세화, 서비스 구현 분석
      4) 시스템 분석/설계 : Use Case Modeling, Component Modeling, Service Orchestration
      5) SW 아키텍쳐 : SW 아키텍쳐 설계, 프레임웍 개발
      6) SOA 거버넌스 수립 : 서비스 관리계획 수립
    나. SOA 관련 정보기술
      - BPM : Biz Process 모델링(BPMN), 시뮬레이션, 최적화, BPEL, BAM, BRE
      - ESB : 분산, 지능형 버스, 유연성(Loosely Coupled), 상호운영성, Open Standard
      - EII : Data Hub, Metadata, App-Data 독립성, 가상화
      - 웹서비스 : SOAP over HTTP(S), WSDL, UDDI, XML
  3. SOA 기대효과 및 문제점
    가. 기업 내외 애플리케이션간 통합, 유연성,확장성,가용성 보장
    나. 성공적인 SOA방법론 적용사례 및 전문가 부족, 지속적 교육/경험축적 필요
    다. 전자정부 프로젝트 등 적용범위 확대에 따른 서비스품질평가 기준마련 필요
    라. ITA/ISP통한 로드맵 구축으로 과다/중복 구축비용 지출 절감필요."끝"

문 )  데이터베이스 보안
1   데이터베이스의 외부 및 내부 침입 에 보호하기 위한 데이터베이스 보안개요
 가  데이터베이스 보안(DataBase Security)정의
  - 데이터베이스 및 저장된 데이터의 비인가된 접근, 변경, 파괴, 노출 등의
   행위로부터 보호하기 위한 조직, 기술적의 모든 활동
 나  데이터 보안관리 이슈(IT Compliance 증가로 이슈화)
  - 기밀성 : 개인정보, 기업정보 유출 방지, 탐지, 제시 하는 것
  - 무결성 : 데이터 손상및 훼손 방지, 탐지, 제시
  - 가용성 : 시스템이 제공하는 서비스 접근에 대한 부당한 거부 방지/탐지/제시
  - 인증성 : 정당한 사용자 확인, 인증을 통하지 않는 DB정보 누출 방지

2   데이터베이스 보안 구현기능 및 데이터베이스 보안 솔루션 유형
 가  데이터베이스 보안 구현기능
  1)접근통제 : DAC(주체, 객체신원기반), MAC(비밀등급 권한기반,객체지간) 접근권한,

                   RBAC(역할기반),Log Tracing
  2)허가규칙 : 허가 받지 않은 데이터 접근 방지
  3) 암호화 : IT Compliance, 비인가자 접근시 확인 불가
  4)가상 데이블(View) : 데이터베이스 사용자 권한별 접근, 조회

 나  데이터베이스 보안 솔류션

3   데이터베이스 보안 고려사항 및 기대효과
 가  데이터베이스 보안 솔류션 도입 시 연계 시스템 간 확장성, Failover 등 안정
   성을 고려한 선택이 필요
 나  보안 정책적용 및 기술적 적용 이후로 지속적 관리가 중요, ISMS 기업정보
   보안체계 ISO27000 인증을 통해서 내부통제 및 보안조직/프로세스 정립
 다  IT Compliance 를 준수하는 보안 시스템 구축

6)Index

답)

1.데이터베이스 성능향상을 위한 인덱스의 개요

  가.인덱스(index)의 정의

   -연산 성능향상을 위해 테이블의 row의 키값과 물리적 주소를 저장하고 있는 공간

  나.인덱스 특징

   1)독립성:테이블과 독립된 공간에 저장

   2)Trade-Off: 조회성능 향상,등록/수정/삭제의 성능저하 발생

 2.인덱스 선정 기준 및 인덱스 종류

  가.인덱스 선정 기준

    1)기본키 및 외래키:

    2)접근 경로 분석

    3)분포도 파악

   4)인덱스 순서 선정

 나 인덱스 유형

3.데이터베이스 인덱스 선정시 고려사항

  가.Execute Plan(옵티마이저) 점검을 통해서 효율적인 사용이 필요

  나.과도하 인덱스 생성시 데이터 등록,수정,삭제시에 성능저하 유발

  다.인덱스는 hint를 활용하여 튜닝이 가능하지만, 기본적으로 SQL문의 효율적 작성을 해서 튜닝을 권고

5)OLAP

답)

1. 합리적 의사결정을 위한 다차원분석 솔루션 OLAP 개요

 가. OLAP(On-Line Analytical Processing)의 정의

    - 데이터를 다양한 차원에서 분석하여 효율적인 의사결정을 지원하는

      사용자(현업)중심의 데이터 분석 솔루션

 나. OLAP의 필요성

    -사용자 중심의 인터페이스를 통한 대화식 접근의 분석기능 요구

    -IT부서를 배제하고 사용자가 직접 원하는 데이터를 분석할수 있는 기능요구

------------------------------------------------------------------------------------

    - 과거 정보시스템(DSS,EIS)에서는 정해진 결과만 분석가능 및 프로그램 필요

    - 사용자 중심의 사용자가 원하는 분석정보로 의사결정 지원 필요성 제기

2. OLAP의 주요기능 및 종류 비교

 가. 주요기능

 나. OLAP의 종류 비교

3. OLAP의 적용 사례 및 현황

 가. 예측을 위한 BI, 위험개수(VAR)분석의 RMS, 고객마케팅을 위한 CRM,

     기업의 비전창출을 위한 BCS 등에 적용이 가능함    

 나. 구분해서 진행되어왔던 e-CRM, CRM, ERP 등이 일관된 뷰로써 구축되고 분석되어야 하는

     필요성에 따라 DW의 확장개념으로 EDW, GDW, EP 등으로의 구축 수요가 예상됨

8)정규화

답)

1.데이터베이스 중복 제거를 위한 정규화의 개요

  가.정규화(Normalization)의 정의

   - 베이스의 중복을 제거하기 위해 릴레이션을 수학적 원리에 의해 분해하는 일련의 과정

  나.정규화 가 필요한 이유(이상현상:anomaly)

   1)삽입이상(inserting anomaly): 불필요한 정보까지 삽입해야 하는 현상

   2)갱신이상(update anomaly) : 일부 속성만 갱신 시킴으로서 정보의 모순성 발생

   3)삭제이상(delete anomaly) : 삭제시 유지되어야 하는 정보까지 삭제되는 현상

2.정규화의 원칙 및 절차

 가.정규화의 원칙

  1)종속성 유지: 릴레이션 분해후에도 종속성 유지

  2)무손실 분해 : X->A,B로 분해후, A,B->X로 유추할수 있어야 함.

 나.정규화의 절차

  1)제1정규화(1NF): 모든 속성 값은 원자값이어야함

  2)제2정규화(2NF) : 부분함수 종속성 제거

  3)제3정규화(3NF) : 이행함수 종속성 제거

  4)BCNF : 결정자가 후보키가 아닌 종속 제거(제3 정규화 만족하고)

  5)제4정규화(4NF) : 다치 종속 제거(BCNF만족하고)

  6)제5정규화(5NF) : 조인종속 제거 (제4정규화를 만족하고)

3.정규화 수행시 고려사항

  가.데이터의 일관성 유지 수준까지 정규화 수행(BCNF수준까지 권장)

  나.많은 단계의 정규화는 많은 Join을 발생시켜 SQL성능저하 초래

  다.반정규화는 정규화를 끝낸후 물리모델 단계에서 고려.

1)무결성

2)정규화

3)인덱스

4)해쉬

5)OLAP

6)DW

7)DATA MINING

8)신경망

9)DB보안

10)튜닝

문)데이터 무결성

답)

1.데이터 품질 햐앙을 위한 데이터 무결성의 개요

  가.데이터 무결성(Data Integrity)의 정의

    - 데이터의 정확성,유효성,일관성,신뢰성을 위해 무효갱신으로 부터 데이터를 보호하는 개념

 나.무결성의 종류

   1)개체무결성(Entity Integrity) - 기본키(primary key)는 null값을 못가짐

   2)참조무결성(Referential Integrity) - 외래키값은 null 또는 기본 대응키 필요

   3)영역무결성(Domain Integrity) - 주어진 애트리뷰트값이 정의된 도메인에 속한 값이어야함

   4)비즈니스 무결성(Business Integrity) -업무규칙에 따른 비즈니스 제약 조건

2.무결성 확보 방안

  가.모델링 단계에서 무결성 확보 방안

나.DBMS 운용단계에서 무결성 확보방안

   1)동시성제어:병렬 트렌젝션에 대해 직렬성 보장(serialization)

    - 2PL(2 Phase Locking):Lock상태의 데이터는 UnLock발생시키기 전까지 접근/수정/삭제 불가

    - Timestamp : 수행순서 기준으로 제거 (???)

    - Validation:트래젝션 종료시에 검증

3.무결성 제약시 고려사항

  가.너무많은 무결성 제약 조건은 DBMS 에 Check작업이 증가되어 성능을저하시키는 요인이 될수있음

  나.프로젝트 수행시 테스트 수행의 편리성을 위해 무결성을 미지정하고 수행하면

      실운영환경에서 무결성 제약 위배 발생.

                                                                                "끝"

1.요구공학 개요

가.정의

-요구사항을 정의하고 문서화하는데 필요한 요구사항의 추출,분석,명세,검증,유지보수 및 관리의 제반공정에 대한 체계적 접근방법( IEEE standard)

나.요구공학의 특징

 -개발범위,각종테스트 기준(단위,통합,인수),감리,검수 등 프로젝트 수행의 중요한 기준으로 활용

 -사용자의 요구사항은 추상적,불분명 하므로 분석이필요,지속적으로 변화하는 특성 가짐

다.요구사항 문제점 및 해결방안

2.요구공학 프로세스 및  명세속성

가 요구공학 프로세스

3.요구사항 명세 기준

가. 요구사항 명세 속성

나.요구사항 명세기법 

다.요구사항 명세서 포함내용

라.요구사항 명세화의 기준(고려사항)

-명확한표현,일관된 용어,간결한 표현

-기술적 내용과 제약조건 언급 하지 않도록 한다

-RFP,제안서,상위요구사항에 기초하여 정확하게 작성

-비기능적 요구사항도 모두 포함 작성

-사용자별 중요도,난이도 고려하여 우선순위화

-요구사항간에 양방향 추적가능해야 한다.

4.요구공학의 기대효과 및 활용방안

가.업무측면:업무연속성 보장,환경변화 신속대응,개발비용 절감

나.개발측면:잠재적 위험 관리 기능,사용자간 의사소통 용이,업무이해도 향상

다.사용자 요구 해결하기 위해 도메인 및 정보시스템 지식을 겸비한 요구분석 전문가 양성필요

=======================================================================================================

요구사항특징,요구공학프로세스,정형및비정형명세기법

답)http://nexcore.skcc.com/alm/alcinous/manual/index.jsp?topic=/nexcore.tool.rm.help/manual/guide/deductionguide/analasysmethod/analasysmethod.html

1.지속적인 변화를 수용하기 위한 요구사항의 특징

1.     요구공학 프로세스

2.     정형 및 비정형 명세기법

https://moodle.shinhan.ac.kr/pluginfile.php/636/mod_resource/content/3/Chap%208.%20SW%20%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%20%EB%B6%84%EC%84%9D.pdf

요구사항 명세

I. 재사용성과 유지보수성 향상을 위한, 객체지향 설계의 개요

가. 객체지향(Object Oriented)의 정의

- 실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념,UML을 이용한 비주얼 모델링과 의사교환하는 SW개발방법론

나. 객체지향 의 등장배경

- 전통적 개발의 문제점 극복: 재사용,확장성,유지보수성 증대

- SW 위기 해결 대안 : 많은 개발시간,낮은 품질,높은 위험요소로 개발생산성 저하 발생

다. 객체지향 의 장점

라. 객체지향 의 특성

2. 객체지향 설계 5원칙
  1) 인퍼페이스의 분리 (I/F: Interface)
    - 의미: 하나의 I/F는 하나의 기능 갖음, (ex: 입력, 출력 I/F 각각 구성)
    - 방법: 명확한 I/F 성격 분리, 공유 I/F 재사용 극대화, 기 구현  Client 변경 최소화
    - 특징: Client는 사용하지 않는 I/F에 의존관계 맺지 않음(소스레벨 가독성 향상)

  2) 개방폐쇠 원칙 (Open-Closed Principle)
    - 의미: 소프트웨어 Entity(classes, Modules, Function)는 확장에는 열려있고

               수정에는 닫혀있어야 한다는 설계 원칙(상속기능,유연성확보)

    - 방법: 클래스간 공통속성 추출 추상클래스 디자인, 상속받아 세부구현, Adapter 통한 접근
    - 특징: Class 변경에 따른 클라이언트 코드 변경 및 영향 최소화
  3) 단일책임의 원칙 : SRP (Single Responsibility Principle)
    - 의미: 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 원칙(응집도향상)

    - 방법: Extract Class, Extract Method 이용, 책임별 Class로 분할, 같은 책임 통합.
    - 특징: 함수(I/F)가 아닌 객체에 초점. 산탕총 수술 (변경 전파 폭풍) 방지
  4) 리스코프 치환원칙 (Liskov Substitution Principle)
    - 의미: 자식들은 부모타입들이 사용되는 곳에 대체될 수 있어야 함.
    - 방법: Overriding, Overloading. 부모 Class와 동이란 I/F 이름 이용.
    - 특징: 파생 클래스는 확장이 주요 목적, 추가는 부가적 문제. 부모 클래스 책임을 넘지 않음.
  (5) 의존관계 역전의 원칙 (The Dependency Inversion Principle)
    - 의미: 의존 대상은 파생 클래스가 아닌 추상 클래스여야 함.(상위레벨 클래스 의존만 가능)
    - 방법: Interface에 의한 프로그래밍, 객체간 연동.
    - 특징: 참조는 부모 클래스 I/F에 의존. LSP 선행 필수.

                 (낮은결합도,확장성 높아져 유지보수성 햐상)

3. 객체지향 설계원칙의 활용 및 고려사항
  가. 설계 품질평가: Class Diagram, 참조도를 객체지향 원칙에 준하여 품질 평가
  나. 리팩토리 기준: Class 구성을 설계 원칙에 부합하도록 분해/통합 및 I/F 분리 수행
  다. 지나친 일반화 배제: Class의 비대화 및 기능 불명확 땨른 설계원칙 위해, 모호성 발생
  라. 디자인패턴 활용: 객체지향 설계원칙 적용의 Best Practice 도입으로 효과적인 적용.
"끝"

======================================================

1.컴포넌트 재사용을 통해 생산성을 향상시키는 CBD 방법론 개요
가.CBD (Component Based Development)방법론의 정의
- 컴포넌트 개발, Repository에 저장, 컴포넌트 조립을 통해
재사용성과 비즈니스 적시성을 향상시키는 개발 방법론
나.CBD 방법론의 진화형태
- Porduct Line : 제품중심 Core Assets 식별, CBD 기반 개발
- SoA : 공유와 재사용 가능한 서비스를 컴포넌트와 조합
2.CBD 방법론의 주요 특징
가.CBD 방법론의 주요 특징
1) UseCase Driven : 사용자 요구사항 분석으로 컴포넌트 식별
2) Blackbox Reuse : I/F 기반의 컴포넌트 호출
3) Iteration : 개발단계 반복을 통해 위험을 취소화
4) Lossely Coupled : MVC 모델에 기반한 약결합 구현
나.CBD 방법론 절차
1) 컴포넌트개발(CD) : usecase로 컴포넌트 식별하고 개발, 저장소저장
2)컴포넌트조립(CBSD) : 기존 컴포넌트를 조립하여 SW 개발
다.CDB 방법론의 종류
1)UP(Unified Process) : UML 기반, 아키텍처중심, 2차원구조(동적, 정적)
2)마르미III : 한국형CBD, 분석강조, 미니프로젝트 반복, 프로토타입 후 진행
3)Catalysis : UML 표기기반 CBD, 분산시스템 모델링/구축
3.CBD 개발 SW의 평가 요소
가.응집도:컴포넌트 기능의 충실도, 높을 수록 좋음
나.결합도:컴포넌트간의 관련성, 낮을 수록 좋음
다.독립성:플랫폼 종속성 여부, 종속되지 않아야 함
라.Round Trip Engineering : 분석/설계/구현/테스트 자동화 도구 지원 여부
=======================================================
*** 추가사항
1.CBD 방법론의 장점
가.생산성 : 부품 조립을 통해 APP 개발시간 단축 및 개발 생산성 향상
나.변경용이성 : 요구사항 수용에 안정적이고 신속한 변경 가능
다.재사용성 : 바이너리 기반의 재사용 및 컴포넌트 대체 용이
라.관리용이성 : 독립적인 컴포넌트 단위로 복잡성 최소화
마.기술집약성 : 기술 숙련에 대한 검증, 아키텍처, 프레임워크, 분산 객체 기술 등

2.컴포넌트 식별 방법
가.유즈케이스 시나리오 분석을 통한 컴포넌트 도출
- include : 동일하게 반복되는 <> 관계의 유즈케이스 도출
- extend : 특정조건에 의해 수행되는 <>관계의 유즈케이스 도출
나.설계단계의 UI Layout 설계 혹은 UI 네비게이션 설계 시 도출
- 공통 UI (공통화면일 경우), 공통 UI 컨트롤(페이지 Up/Down 등 상/하위 컨트롤 도출)
다.<> 클래스 상관관계 분석을 통한 컴포넌트 도출 : Core클래스 + 종속클래스그룹핑
라.Usecase와 <> 클래스의 상관관계 분석으로 도출
마.전문가 판단

문) MDA

1. 설계모델의 재사용 극대화 MDA

 가. MDA(Model Driven Architecture)의 정의

  - 핵심 메타모델을 근간으로 구현환경에 독립적인 모델을

    자동으로 구현환경 종속적 모델로 변환하는 컴포넌트 기반 구조

 나. MDA의 필요성

  - CBD의 기술 종속적인 모델의 재사용 욕구 증대

  - 설계와 구현의 분리로 설계모델 재사용 극대화

2. MDA의 절차 및 구성요소

 가. MDA의 절차

    - PIM(Platform Independent Model) : 기술모델에 독립적모델

    - PSM(Platform Specific Model) : 기술모델에 종속적모델

나. MDA 구성요소

다. 모델 변환의 종류

3. MDA의 고려사항 및 활용

 가. PIM변환 명확화, 변환작업의 자동화/경량화 및 기술변화에 대한

     구현환경의 지속적 UML Profile관리가 필요함

 나. MDA기반 프로세스 정립을 위해 MOF호환을 위한 UML 2.0 지원이

     필요하고 기술변화에 대한 유연적 대처및 유지보수비용절감이 가능함

●  주요특징

효율성 : 기술 변화 상황에 효율적으로 대처할 수 있다.

이식성 : MDA 방식으로 개발된 시스템은 PIM을 통해서 변경된 기술 플랫폼으로 이식이

쉽게 이루어질 수 있기 때문이다.

유연성 : 시스템 인프라 변화에 유연하게 대처할 수 있다.

유지보수성,투자비용 :MDA 방식으로 개발된 시스템은 그 시스템의 유지 보수

비용이 적으며 시스템의 수명이 길다.

따라서 투자 비용이 보존된다.

● UML Profile 

MDA에서 UML 프로파일은 중요한 위치를 점하고 있다.

MDA에서 PSM은 UML로 표현되어야 한다. 하지만 특정 기술 플랫폼의 개념들이 UML로

어떤 식으로 표현되어야 하는지에 대한 것은 UML 자체에 포함되어 있지 않다. 예를 들면

이를 위해서 OMG에서는 해당 플랫폼에 따라서 UML 프로파일을 만드는 작업을 진행

-------------------------------------------------

문) MDA
1.디자인 패턴 활용 극대화 모델 MDA
가.MDA(Model Driven Architecure)의 개요
  - 메타모델을 기반, 구현환경독립적 시스템(PIM)개발,
    자동화 도구를 통해 구현환경종속모델(PSM) 변환 SW 방법론    
나.MDA 주요 특징
  - 구현자동화 : 메타모델 통한 CORBA, EJB, .NET, COM 구현
  - 상호운영성 ; UML 표준 사용으로 이기종 플랫폼에 독립
2.MDA 핵심기술와 구축 절차 및 변환도구
가.MDA 핵심기술
  1)) MOF(Meta-Object Facility) : 정보 모델의 저장소, 문법과 구조를 정의한 메타모델
  2) UML 2.0 : MOF와의 호환성을 위한 메타모델
  3) UML Profile : 사용자 정의 언어, UML 확장, 구현모델 자동 매핑  
  4) CWM : 메타 데이터 상호 교환을 위한 표준 저장소, DB 모델 변환
  5) XMI : MoF를 XML로 매핑하기 위한 표준 사양
나. MDA  구축절차(MDD 개발)
  1) CIM : 개념화 관점의 요구사항을 모델에 적용
  2) PIM :  요구사항 분석,설계 내용을 가지는 플랫폼 독립적 모델
  3) PSM : 구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
다.MDA의 변환 도구
  1) UMT : 중간모델기반, XML,XMI,XSLT를 이용한 모델변환 및 코드 생성
  2) MTL : 직접변환, 다중상속 지원,메타모델 저장소를 통한 메타모델 재사용
  3) ATL : 직접변환, ATL 변환 규칙 정의 언어를 사용해 UML->XMI->JAVA 변환
3.MDA의 주요 현황과 고려사항
가.재사용 관점 진화 : 구현 모듈 재사용에서 설계 재사용으로 변화
나.Round Trip Engineering : SDLC 전과정의 자동화 지원
다.UML 2.0 : UML 1.X의 MOF 와의 호환 미흡 완벽 지원
=====================================================
CIM : Computation Independent Model), PIM(Platform Independent Mode)
PSM(Platform Specification Model), CWM(Common Warehouse Model)

-----------------------------------------------------------------------

I. MDA 기반의 PIM,PSM와 변환을 위한 도구의 개념
    -PIM:요구사항 분석,설계 내용을 가지는 플랫폼 독립적 모델
    -PSM:구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
    -MDA는 PIM을 PSM 형태로의 변환을 통해 요구분석->설계 또는 설계->
     구현 과정의 재사용성 향상,코드의 자동생성,개발속도 향상 개발 방법
    -모델변환과정:PIM --> (Intermediate Model) --> PSM
                          --------------------
     실체변환과정:UML -->        XMI           --> JAVA,C++ 등
II. PIM,PSM 변환 도구의 종류 및 선택 기준
  가. PIM,PSM 변환 도구의 종류
  --------------------------------------------------------------------
  구분 변환도구                 도구 특징 설명
  --------------------------------------------------------------------
  중간  UMT    -XML,XMI,XSLT를 이용한 모델변환 및 코드 생성
  모델         -UML->WSDL,XML Schema,Java Interface,EJB 등으로 변환
  기반         -Source Model->Intermediate Model->Transformer 변환
               -XMI Light Model 사용을 통한 양방향 모델 변환 매핑 지원
  --------------------------------------------------------------------
  직접  MTL    -모델변환 엔진과 모델변환 정의 언어 기능
  변환         -다중상속 지원,메타모델 저장소를 통한 메타모델 재사용
               -쉽고 명확한 명세가 어렵고 복잡한 변환규칙 미지원
        ATL    -ATL 변환 규칙 정의 언어를 사용해 UML->XMI->JAVA 변환
               -변환규칙 정의가 명확하고 이해하기 쉬움
               -변환모델에 대한 재사용,합성 지원
               -Header(목표모델정의),Helper(명세),Rule(변환규칙) 구성
  --------------------------------------------------------------------
  나. PIM,PSM 변환 도구 선택 기준
  --------------------------------------------------------------------
                ATL,MTL                           UMT
  --------------------------------------------------------------------
   -변환규칙 추상화레벨 제공               -명확한 변환 규칙 제공
   -변환모델의 재사용,합성제공(ATL)        -양방향 모델 변환 매핑 지원
   -Repository 활용한 변환모델 재사용(MTL)
  --------------------------------------------------------------------
    -변환 방식에 따른 특징이 존재하며 재사용성과 양방향 모델 변환 매핑
     측면에서 개발 조직에 보다 가치가 있는 방법을 선택 사용
III. MDA 효과성 향상 방안
    -Embedded SW:동일한 Logic의 Target 형태에 따른 서로 다른 구현에
     대한 개발 속도 및 품질 향상에 적용
    -AOP(Aspect Oriendted Programming) 기법의 적용을 통한 핵심,횡단
     관심사 구현 용이성,효율 향상 활용

================================================================

1.설계단위 재사용을 위한 MDA(Model Driven Architecture)의 개요

  가. MDA의 정의

    -SW 설계 모델을 명세하고 이를 상세설계 모델과 코드로 변환하여 프로그램을 자동으로       생성하는 새로운 기술 개발

  나.MDA의 활용의 장점

    1)재사용(reuse):시스템 분석,설계,구현,결과 관리등 프로젝트 전체 과정 재사용 가능

    2)구현 자동화: 메타모델을 이용하여 구현 정의 대부분을 자동화할수 있는구조.

    3)이식성(Portability):구현환경과 독립적으로 정의되므로 이식성 증가

    2)소프트웨어 품질(Quality):설계모델 재사용으로 품질 향상.

    -어플리케이션 개발비용,품질,생산성 향상을 가지고 옴

2.MDA 구성요소 및 활용분야

  가.MDA 구성요소

   1)MOF(Meta Object Facility):플랫폼에 독립적인

   2)CWM(common warehouse Meta)

   3)UML Profile:

   4)XMI(XMLmetadata interchange)

  나.mda적용시 기대효과 및 전망

   1)프로젝트 진행 과정 전체를 재사용 할 수 있다

   2)메타모델을 이용한 구현 공정 자동화 용이함

   3)공공 콤포넌트 개발:

   4)소프트웨어 아키텍처: