정보보안 정보처리 기술사

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)소프트웨어 아키텍처:

문)       유즈케이스 모델링
답)
1.        시각적 요구사항 분석표현 유즈케이스 모델링의 개요
    가.    유즈케이스 모델링(UseCase Modeling)의 정의
       -  행위자(Actor),유즈케이스(usecase),관계(relation)를 통하여 시스템
          의 기능이나 요구사항등을 시각적으로 표현한 모델링기법
    나.   유즈케이스 모델링의 구성요소
       -  행위자(Actor):시스템과 상호작용하는 사람 또는 사물
       -  유즈케이스(Usecase):시스템이 제공하는 서비스
       -  관계(Relation):행위자와 유즈케이스간,행위자간,유즈케이스간
           상호연관성
2.        유즈케이스 모델링의 절차 및 사용예제
    가,   유즈케이스 모델링 절차
       1) 행위자 식별
       2) 유즈케이스 식별
       3) 관계 설정:행위자,유즈케이스간 관계 및 제약조건 분석
       4) 유즈케이스 구조화:공통 서비스 및 제약,확장 관계 정의
       5) 유즈케이스 명세:업무흐름의 다양성 기록,대안흐름,선후행조건기술
나.    과목 수강신청 유즈케이스 모델링 예제

문) Usecase Modeling
답)
1. 객체지향 요구사항 분석 UseCase Modeling의 개요
 가. UseCase Modeling의 정의
  - 사용자의 시각에서 SW의 범위와 기능을 쉽게 정의하고, 기능적 요구사항을 나타내는 모델링기법
 나. UseCase Modeling의 구성요소
  - Actor : 시스템 외부에 독립적으로 존재하면서 시스템과 교류, 상호작용을 하는 것
  - Usecase : 시스템이 Actor를 위해서 수행하는 작업
  - Relation : Actor와 UseCase, UseCase간, Actor간의 상호연관성
  - 주요산출물 : Usecase Diagram, UseCase명세서, 부가기술서
2. Usecase 작성절차와 작성규칙
 가. UseCase 작성절차
  절차                                 내용
1. Actor 식별                    사용자의 역할, 상호작용하는 타 시스템, 연동HW식별
2. UseCase식별                Actor가 요구하는 정보, 서비스를 식별
3. 관계설정                      Actor, Usecase간 관계분석 및 정의
4. Usecase구조화             UseCase의 공통 서비스 추출
5. Usecase명세                 업무흐름다양성 기록, 대안흐름작성 등 UseCase명세서 작성
 나. Use Case 작성규칙
  - Actor 와 UseCase 명칭을 직관적으로 이해가 쉽도록 정의
  - 모든 UseCase는 하나이상의 Actor와 교류해야함
  - UseCase의 추상화 레벨은 일정한 수준 유지
  - UseCase의 크기 단위에 대한 일관성 정의
3. UseCase Model의 활용 시 고려사항
 가. 현업사용자 : 업무를 UseCase화 하는 교육, 훈련 참여
 나. 개발자 : 플랫폼 독립적 설계하여 재사용성을 높일 필요성 있음
 다. 관리자 : 정확한 요구사항 파악을 위한 반복적 분석 필요
끝.

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

요구사항 2교시

architecture view

나선형

유즈케이스모델링

공공 ipin 취약점

문) UML 2.0
답)
1. 객체지향 개발을 위한 통합 모델링 UML2.0의 개요
    가. UML2.0(Unified Modeling Language)의 정의
          - OMG에서 다양한 모델링 기법을 통합하여 개발. 실행 모델 기반
            MDA와 MDD등 OMG 표준간의 상호호환성 제공하는 모델링 언어
    나. UML2.0의 개선 사항
          - 자동화 강화 : 분석에서 개발 테스트까지의 과정을 자동화 지향
          - 정확성과 표현력 확장 : 추가 다이어그램 및 OCL 기능 추가
2. UML2.0의 주요 개선 사항 및 추가 다이어그램
    가. UML2.0의 주요 개선 사항
          - MDA 지원 : PIM, PSM 모델 통한 플랫폼 비 종속적 개발
          - BPEL 지원 : 비즈니스 서비스 오케스트레이션 지원
          - MDD : Round Trip Engineering의 전 개발과정 지원
          - 상부영역과 하부영역의 모델 구조
     나. UML2.0의 추가 디이어그램
            - Composite Diagram : [그림] 컴포넌트 상호 작용 및 내부 구조 표현
            - Package Diagram : [그림] 컴포넌트 그룹 관계 표현, 패키지 구조 표현
            - Timing Diagram : Sequence Diagram + State Machine Diagram, 시간 흐름
            - Interaction OverView Diagram : Activity Diagram + Sequence Diagram, 논리 흐름
3. UML2.0의 활용방안 및 기대 효과
    가. UML2.0을 통한 전체 개발 과정의 자동화 및 재사용성 향상
          개발자간 또는 사용자 간 가시적 모델링 통한 이해 용이성 향상.
    나. UML Profile 활용 : 개발 영역, 개발 언어, 개발 환경에 따른 Profile 활용
          자동화 도구 활용 : CASE 툴, UML 지원 IDE 등을 활용한 FrameWork 활용