3-2. 개발방법

OAM Client Framework – 목차

■ 운용관리에 관한 이론적 고찰
1-1. OAM의 정의  1-2. EMS의 정의  1-3. OAM 표준화 동향  1-4. 3GPP 32 Series

■ OAM 프레임워크
2-1. OAM 프레임워크 필요성  2-2. OAM 시스템의 구성  2-3. OAM 요구사항  2-4. OAM 배포 아키텍쳐  2-5. OAM을 위한 Database의 구성 2-6. OAM 인터페이스  2-7. 구성 관리  2-8. 장애 관리  2-9. 성능 관리  2-10. 보안 관리

■ OAM 클라이언트 프레임워크
3-1. OAM Client 프레임워크 개요  3-10. 효과분석  3-2. 개발방법  3-3. 요구사항  3-4. 산출물 정의  3-5. 개발환경  3-6. 아키텍쳐 3-7. UI 정의  3-8. 프레임워크의 개발  3-9. 프레임워크를 사용한 개발

3-2. 개발방법

OAM Client Framework를 개발하기 위한 패턴은 랄프 존슨이 제시한 9가지 패턴을 기반으로 한다.[i] 대부분의 9가지 패턴들은 독립적인 공적으로서 순서에 상관없이 진행이 가능하지만, Three Example은 개발 초기에 적용하여야 하며 Black Box Framework, Visual Builder, Language Tools는 White Box Framework가 종료된 이후 진행하여야 한다. 랄프 존슨의 9가지 패턴에 따른 OAM Client Framework 개발 단계는 아래와 같이 진행한다.

사용자 삽입 이미지

[Framework가 발전되기 위해 적용하는 9가지 패턴]

  1. 세가지 어플리케이션 (Three Example ): 도메인 문제에 대한 지식이 해박한 전문가 집단이 없거나 개발하려는 어플리케이션을 구현한 적이 없을 경우 사용하는 방법이다. 어플리케이션을 만들고 이를 토대로 Framework를 만드는 과정을 3번 반복하면서 Framework를 사용하여 구현하게 될 어플리케이션의 기능과 요구사항을 파악하여 재사용 가능한 모듈을 파악할 수 있게 된다.
  2. 화이트박스(White-box Framework) : 세가지 어플리케이션 패턴을 사용하여 첫 번째 어플리케어플리 개발되었을 때 두 번째 Framework로 확장할 때는 객체지향의 상속을 사용하여야 한다. 상속을 사용하면 계약 기반의 인터페이스(Interface)를 구축함으로써 확장성과 유연성을 가져올 수 있으며, 자주 변하는 것과 자주 변하지 않는 것을 쉽게 구분할 수 있게 된다. 자주 변하는 것들은 인터페이스를 사용하여 하위 클래스로 만들어 동적 다형성을 구현할 수 있도록 하여 전체 Framework의 흐름을 일관성 있게 제어하여야 한다.
  3. 컴포넌트 라이브러리 (Component Library) : 화이트박스 패턴을 반복하면서 상속을 사용한 기능 확장이 계속 일어나면 하위 클래스가 많아져 Framework가 복잡해 진다. 이때 Framework에 포함되었지만 재사용하지 않는 클래스는 어플리케이션의 구현 클래스로 이동시켜 Framework가 비대해지는 것을 막아야 한다. 다양한 구현 클래스들은 취합하여 컴포넌트 라이브러리로 구성하여 재사용성을 높일 수 있다.
  4. 핫 스팟 (Hot Spots) : 화이트박스 패턴과 컴포넌트 라이브러리 패턴을 통해 Framework를 구성하면 유효한 클래스들이 Framework에 포함되지만 화이트박스 패턴을 반복할수록 클래스의 종류는 많아지고 클래스간에 중복되는 코드들이 증가하게 된다. 따라서 단순히 클래스를 Framework에 계속적으로 추가하기 보다는 디자인 패턴을 사용하여 기존 클래스와 추가될 클래스간의 관계를 정의하면서 확장하여 코드의 중복을 막아야 한다.
  5. 플러그러블 객체 (Pluggable Object) : 컴포넌트 라이브러리 패턴을 사용하여 컴포넌트를 추가할 경우 추가한 클래스가 기존 클래스와 약간만 다를 수 있다. 이때 클래스를 새로 추가하지 않고 기존의 클래스에 인자를 사용하여 객체를 생성하도록 하여 다양성을 높일 수 있다. 인자는 상수, 심볼, 클래스 레퍼런스, 인스턴스 변수, 함수 포인터 등이 될 수 있다.
  6. 파인-그레이드 객체 (Fine-grained Object) : 여러 가지 문제를 해결해 주는 복잡한 API일수록 반복되는 코드가 많아지고 도메인 문제를 직접적으로 다룰 경향이 많아진다. 따라서 커다란 API는 Small Objects Pattern에 따라 작은 API로 리펙토링하여 재사용성을 높여야 한다.
  7. 블랙박스 (Black-box Framework) : 핫 스팟 패턴으로 캡슐화된 클래스를 만들고, 파인-그레이드 패턴으로 재사용성이 높으며, 플러그러블 패턴으로 다양성을 지원하는 융통성있는 클래스를 만들 수 있다. 여기에 화이트박스 패턴의 상속을 통해 Framework를 상속하였다. 하지만 상속을 받는 클래스들끼리는 종속성이 생겨 미래에 발생할 수 있는 다양한 요구사항의 변경에 유연하게 대처하지 못할 수 있다. 따라서 화이트박스 패턴을 통해 만들어진 상속 관계로 구성된 여러 클래스에서 공통적으로 사용되는 변하지 않는 부분을 추출하여 컴포넌트 화(블랙박스 화)하여야 한다. Framework는 클래스의 확장에는 열려있고 클래스의 수정에는 닫혀 있는 구조여야 하며, 상속보다는 구성(Composition)을 사용한다.
  8. 비주얼 빌더 (Visual Builder) : 각 단계의 패턴을 사용하여 Framework를 구성하게 되면 이를 사용하여 어플리케이션을 개발할 때 도움을 주기 위한 문서와 도구를 제공하여야 한다. Framework 속의 많은 객체들을 쉽게 조합하여 어플리케이션을 구성할 수 있는 비주얼 툴을 제공한다면 프로그래머가 아닌 도메인 전문가들도 쉽게 어플리케이션을 만들 수 있다.
  9. 언어 도구 (Language Tools) : 비주얼 빌더 패턴으로 구현한 어플리케이션은 디버깅과 버그 추적이 어려울 확률이 높으므로 어플리케이션에 코드 점검 툴 또는 디버깅 툴을 제공하여 검증하여야 한다.
 
 

CC BY-NC-ND 2.0 KR

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스

저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.

댓글 남기기