소프트웨어공학 - 컴포넌트 기반 소프트 웨어공학 그리고 재사용성

6. 컴포넌트 기반 소프트웨어공학

■ 배경
- 객체지향 개발 방법이 광범위한 재사용을 유도하지 못했다.
- 클래스 단위는 효과적으로 재사용하기에는 너무 크기가 작고 상세하고 구체적이었기 때문에 어려움이 있었다.
- 컴포넌트가 클래스보다 훨씬 추상적이었으며 개별적으로 재사용하기가 용이했다.
- CBSE는 느슨히 연결된 독립적 컴포넌트들을 정의하고 구현한 다음 통합하거나 조합함으로써 시스템을 만드는 프로세스로 중요한 소프트웨어 개발 방법이 되었다.

(1) 컴포넌트와 컴포넌트 모델

■ 컴포넌트란?

•  컴포넌트 모델을 따르는 소프트웨어 요소로서, 독립적으로 배포될 수 있고 컴포넌트 조합(composition) 표준에 따라 수정 없이 조합될 수 있는 것(Council & Heineman)
• 계약으로(contractually) 명세된 인터페이스와 분명한 컨텍스트 종속성만을 가지는 조합의 단위. 컴포넌트는 독립적으로 배포될 수 있고 제3자에 의해 조합되는 것을 가정한다. (Szyperski)

■ 서비자 제공자로서의 컴포넌트 특성

• 컴포넌트는 객체 클래스에 비해 훨씬 추상적(abstract)이며, 독립적으로 서비스를 제공한다고 볼 수 있다.
  
• 시스템이 서비스가 필요한 경우 컴포넌트를 호출한다. 이때, 호출자는 컴포넌트가 어떻게 구현되었고, 어떠한 식으로 동작하는지에 대해서는 알 필요가 없다.
  
• 독립적인 실행가능 개체로 하나 또는 여러 개의 클래스로 구현되어 있다. : 소스 코드가 제공되지 않기 때문에 다른 컴포넌트와 함께 사용되지 전에 컴파일될 수 없다.
  
• 모든 상호작용은 공개된 컴포넌트의 인터페이스를 통해 이루어진다.

■ 컴포넌트 인터페이스

 

□ 제공 인터페이스(Provides interface) - 해당 컴포넌트가 다른 컴포넌트들에게 제공하는 서비스들을 정의

□ 요구 인터페이스(Requires interface)
- 컴포넌트가 필요로하며 다른 컴포넌트에 의해 제공되어야 하는 서비스들을 정의
- 만약 요구 인터페이스가 제공되지 않으면 컴포넌트가 동작하지 않는다.

■ 컴포넌트와 객체의 비교

 

□ 유사점

- 메시지 기반 통신을 함 : 객체는 메시지, 컴포넌트는 이벤트와 메시지
- 인터페이스가 잘 정의됨
- 캡슐화, 정보은닉, 다형성, 특수화 등을 사용

□ 차이점
- 컴포넌트는 영속적 저장소를 사용하지만, 객체는 그렇지 않을 수도 있음.
- 컴포넌트가 일반 객체보다 큼.
- 컴포넌트는 제공 및 요구 인터페이스를 포함하지만 객체는 그렇지 않을 수도 있음.
- 컴포넌트는 아키텍처에 의존적임 : 객체는 동적인 경향이 있으며, 컴포넌트는 정적인 경향이 있음.
- 컴포넌트는 배포 가능한 개체임.
- 컴포넌트는 타입을 정의하지 않음.
- 컴포넌트의 구현은 감추어져 있음
- 컴포넌트는 언어 독립적임.
- 컴포넌트는 표준화되어 있음.

■ 컴포넌트 모델 - 컴포넌트 구현, 문서화 및 배포에 대한 표준을 정의해 놓은 것

 

□ 컴포넌트 모델의 예
- Sun의 EJB(Enterprise Java Beans)
- 마이크로소프트의 COM+ (.NET)
- OMG의 CORBA

 

□ 컴포넌트 모델의 기본 구성요소

• interfaces
  • 인터페이스의 정의 방법을 명세함. 인터페이스 정의에서 오퍼레이션 이름, 매개 변수,예외가 포함되어야 함.
    
  • 인터페이스를 정의하는데 사용하는 언어(IDL)을 명세해야 함
    
  • 보안과 트랜잭션 관리와 같은 표준화된 서비스를 제공하는 컴포넌트 모델 하부구조에 컴포넌트를 결합하기 위해 특정 인터페이스가 필요하기도 함
•  Usage Information
  
  • 분산 환경에서 컴포넌트의 원격 접근을 위한 컴포넌트의 고유 이름이 필요함
    
  • 메타데이터는 인터페이스 정보나 속성 정보와 같은 컴포넌트 자체에 관한 데이터로 사용자가 어떤 서비스가 제공되고 요구되는지를 찾기 위해 필요함
    
  • 컴포넌트는 일반적인 개체이므로 특정 환경에 맞게 어떻게 설정되는지 명세해야 함
•  Deployment and use
  
  • 독립적 실행가능한 개체로 배치하기 위해 컴포넌트들을 어떻게 묶는가를 정의해야 함

■ 미들웨어

- 컴포넌트 모델은 컴포넌트의 실행을 지원하는 미들웨어의 기초가 된다.
- 컴포넌트 모델의 구현을 통해 다음을 제공한다.
- 모델에 따라 작성된 컴포넌트는 서로 통신할 수 있도록 해준다. (플랫폼 서비스)
- 다양한 컴포넌트들이 공통적으로 사용하는 애플리케이션 독립적 서비스 ( 공통 서비스 또는 Horizontal Services)

■ 재사용성을 높이기 위한 작업 - 컴포넌트의 재사용성을 높이기 위해 컴포넌트 문서화, 컴포넌트 검증, 컴포넌트의 일반화 작업이 필요함

- 특정 애플리케이션에만 사용되는 메소드는 제거
- 일반적인 이름으로 명칭 변환
- 처리할 수 있는 범위를 넓힐수 있는 메소드 추가
- 예외 처리를 일관성이 있도록 통일
- 컴포넌트 적응(adaptation)을 위해 환경 설정(configuration) 인터페이스를 추가
- 독립성을 증가시키기 위해 필요한 컴포넌트들을 통합 ( 종속성 감소 )

(2) CBSE 프로세스

■ CBSE의 기초 - 규모가 커지고 복잡해지는 시스템 ... 그러나 신뢰성 있는 소프트웨어의 빠른 개발을 요구하는 고객을 생각할 때, 유일한 대처 방법은 재사용이다.

CBSE가 가능하려면 다음의 것들이 필요하다.
- 독립적 컴포넌트
- 컴포넌트 표준
- 미들웨어: 컴포넌트 통합을 위한 소프트웨어 지원, 분산된 컴포넌트들의 상호 작동을 위해 컴포넌트 통신을 담당하는 미들웨어 지원
- 개발 프로세스 : 컴포넌트 기반의 소프트웨어공학을 지원하는 프로세스

 

■ CBSE 프로세스 : 컴포넌트를 재사용할 때 요구사항과 컴포넌트가 실제로 제공하는 서비스 간에는 trade-offs가 생길 수 있다.

□ CBSE 프로세스의 특징
- 프로세스에 재사용 활동을 포함시킨다.
- 컴포넌트에 맞도록 요구사항이 수정되는 경우도 있다.
- 프로토타이핑 프로세스나 점진적 개발 프로세스가 포함된다.
- 프로토타이핑을 위해 컴포넌트 조합용 스크립트 언어를 사용하기도 한다.

 

■ CBSE의 문제점 : CBSE는 건전한 설계 원리에 기초하고 있고 소프트웨어 개발 방법의 주류가 되고 있으나 여러 문제점들이 남아 있다.

- 컴포넌트 신뢰성 : 소스코드가 제공되지 않는 컴포넌트를 어떻게 신뢰할 것인가?
- 컴포넌트 인증 : 컴포넌트의 품질은 누가 보증해주는가?
- 창발적 속성의 예측 : 컴포넌트를 조합했을 경우 발생하는 창발적 속성에 대해서는 어떻게 알 수 있는가?
- 요구사항들의 trade-offs : 컴포넌트가 제공하는 기능과 요구사항의 차이는 어떻게 처리할 것인가?

 

■ 컴포넌트의 재사용 단계

 

- 검색(Qualification): 재사용할 수 있는 적합한 컴포넌트를 찾아냄

- 적응(Adaptation): 실제 구현하여 재사용할 수 있도록 찾아낸 컴포넌트를 수정

- 조합(Composition): 컴포넌트를 조합하여 전체 시스템을 구축

 

□ 효율적 재사용을 위해 해결되어야 할 문제점

 

- 검색 단계
다양한 컴포넌트들의 집합(또는 저장소)으로부터 원하는 컴포넌트를 검색함에 있어서 의미론(Semantics)을 다루어야 하는 문제가 있다.
시멘틱 웹이나 온톨로지 등의 기술이 있으나, 컴포넌트 명세에 최적화된 형태로 의미를 찾을 수 있는 방법이 필요하다.

 

- 적응 단계
원하는 서비스를 찾았다고 하더라도, 시그너처의 차이, 플랫폼의 차이, 프로토콜의 차이 등으로 바로 재사용하여 조합시킬 수 있는 것은 아니다. 이질적인 여러 환경을 동일하게 맞추어 주거나 중개자 등을 통해 서로 의미적으로나 문법적으로 조합이 가능하도록 변경시켜 적응할 수 있어야 한다.

 

- 조합 단계
적응이 되었다면, 조합을 할 수 있다. 하지만, 이러한 작업이 동적으로 이루어지려면 서비스들이 자동적으로 환경을 설정할 수 있도록 기반 플랫폼과 연계되어야 한다.

정리하기
- 재사용의 장점은 비용 절감 및 위험 감소에 있다.
- 설계 패턴은 고수준으로 추상화된 지식을 재사용하기 위한 잘 정리된 문서이다.
- 애플리케이션 프레임워크는 구체 또는 추상 객체들을 모아놓은 것으로 특성화를 통해 재사용이 가능하다.
- COTS 재사용의 문제점은 기능, 성능 및 유지보수, 상호 연동 등에 대한 제어를 함에 있어서 제약이 있다는 것이다.
- 소프트웨어 제품 라인은 공유할 수 있는 공통적인 부분과 변경될 수 있는 부분을 구분하여 이를 독립적인 자산으로 관리하는 것이 핵심이다.
- 컴포넌트가 클래스보다 훨씬 추상적이고, 개별적이기 때문에 재사용이 용이하다.
- 컴포넌트는 제공 및 요구 인터페이스를 가진다.
- 컴포넌트 모델은 컴포넌트의 실행을 지원하는 미들웨어의 기초가 된다.
- 컴포넌트 재사용은 검색, 적응, 조합의 3단계를 거치게 된다.

 

출처 : http://i-bada.blogspot.com/2014/05/blog-post_3255.html