컴포넌트
컴포넌트의 정의
- 컴포넌트에 대한 정의는 다양하다. 컴포넌트가 재사용 단위라는 의미로 많이 사용되기 때문이다.
재사용이라는 측면을 넓은 의미로 보면 소프트웨어 개발에 있어서 재사용되는 모든 단위들은 컴포넌트라고 보는 것이다.
이런 의미에서의 컴포넌트는 재사용되는 문서, 재사용 모델, 재사용 테이블, 재사용 코드, 재사용 라이브러리 등 다양하다.
그러나 소프트웨어 개발에 있어서 하드웨어 컴포넌트(예: RAM, HDD, CPU 등)처럼 실제 소프트웨어 시스템 작동에 필요한 런타임 모둘(Runtime Module)의 성격을 가진 재사용 단위로서의 컴포넌트를 다룬다.
이러한 좁은 의미에서의 컴포넌트에 대한 정의도 다양하게 표현되고 있다.
표현 방법의 차이일 뿐이지 개념에 대한 내용은 동일하다.
"컴포넌트는 잘 정의된 아키텍처 상에서 어떠한 기능을 수행하는 시스템의 독립적이면서 교체 가능한 부품이다"
"컴포넌트는 인터페이스들의 집합에 대한 물리적인 구현을 제공한다"
컴포넌트를 독립적 기능을 지닌 단위이면서, 물리적으로 구현이 완성된 형태로 제공이 되며, 이후에 언제든지 해당 컴포넌트를 다른 컴포넌트로 교체할 수 잇는 부품으로 정의하고 있다.
"컴포넌트는 동적으로 바인드 될수 있는 하나 이상의 모듈들을 하나의 단위로 관리하는 패키지로서, 실행 시간에 인터페이스를 통해 접근이 가능하다"
핵심 키워드는 동적 바인딩과 패키지이다.
컴포ㅓㄴ트가 동적으로 바인딩되기 위해서는 구현이 100% 완료된 상태를 말하며, 런타임 모듈이라는 뜻이다. 그리고 하나 이상의 모듈들에 대한 관리 패키지라는 표현은 컴포넌트 내에는 하나 이상의 클래스(모듈)들이 모여서 컴포넌트가 구성될 수 있는데 이를 재사용 단위로 배포할 때에는 하나의 독립적인 패키지 형태로 이루어지기 때문이다.
예) EJB경우 컴포넌트 하나에는 하나 이상의 클래스, 하나 이상의 인터페이스, 컴포넌트 스펙 등이 하나의 JAR 파일 형태로 합축한 후, EJB 컨터이너 및 서버에 배포하여 실행하게 된다.
이러한 의미에서 패키지라는 표현을 사용한 것이다.
"컴포넌트는 계약상으로 명시된 인터페이스들과 명확한 문맥 의존성을 가진 컴포지션의 단위로서 독립적으로 보급될 수 있다"
계약상으로 명시된 인터페이스라는 것은 표준화된 인터페이스 규정을 따른다는 것이다.
예) EJB 컴포넌트를 개발할 경우, 개발자들이 마음대로 컴포넌트를 개발하는 것이 아니라 EJB 컴포넌트를 개발하기 위해서는 홈 인터페이스와 원격 인터페이스 혹은 로컬 인터페이스를 정의해야 하고, 해당 이넡페이스를 정의하는 규칙도 EJB 스펙에 규정된 규칙에 따라 작성해야 한다.
"자발적인 비즈니스 객체 또는 비즈니스 로직을 소프트웨어로 구현한 것"을 컴포넌트로 정의하고 있다.
자발적인라는 의미는 독립적이라는 표현으로 대체 가능하다.
즉, 한 컴포넌트는 독립적인 업무 단위로 개발해야 이후, 교체를 하거나 재사용하기가 편리하기 때문이다.
여기서는 컴포넌트를 비즈니스 객체 또는 비즈니스 로직에 초점을 두고 정의를 내리고 있다.
그 이유는 실제 소프트웨어 시스템 개발에 있어서 재사용의 비율이 큰 부분이 비즈니스 로직 부분이다.
따라서 EJB 같은 경우에도 비즈니스 객체나 비즈니스 로직의 재사용 단위로 EJB 컴포넌트를 개발하도록 하고 있다.
물론 그렇다고 사용자 인터페이스와 과련된 컴포넌트들이 재사용 컴포넌트가 아니라는 뜻은 아니다.
컴포넌트의 특성
1. 100% 구현되어 있어야 한다.
- 컴포넌트는 실행 시간에 동적으로 플러그 인 되기 위해서는 100% 구현되어 있어야 한다.
여기서 말하는 재사용 컴포넌트는 원시 코드 기반의 재사용이 아니다. 바이트 코드 기반의 재사용을 말한다.
하드웨어 컴포넌트의 경우와 동일한 원리이다. 예) 컴퓨터 조립시 들어가는 부품들은 이미 제품이 완성된 형태의 부품들이다.
2. 스펙이 있어야 한다.
- 컴포넌트는 컴포넌트에 대한 스펙을 제공해야 한다.
즉, 컴포넌트 명세서를 말한다. 하드웨어 컴포넌트의 경우도 보면, 각각의 하드웨어 컴포넌트에 대한 설명서가 다 되어 있다.
마우스나 그래픽 카드 같은 컴포넌트들을 구매해보면, 각 컴포넌트에 대한 제품 설명서가 제공된다.
여기에는 해당 컴포넌트에 대한 인터페이스 설명, 하드웨어 플랫폼 등에 대한 설명들이 기술되어 있다.
이와 마찬가지로 소프트웨어 컴포넌트의 경우도, 해당 컴포넌트를 사용자들에게 배포하거나 혹은 서버나 컨테이너에 배포하기 위해서는 컴포넌트 스펙이 제공되어야 한다. EJB 경우 보면 해당 컴포넌트에 대한 스펙이 디플로이먼트 디스크립터라는 형태로 제공하게 되어 있다.
3. 표준을 따라야 한다.
- 컴포넌트 개발자들은 컴포넌트 개발시, 임의대로 컴포넌트를 개발해서는 안된다.
모든 컴포넌트는 컴포넌트 개발을 위한 표준 기술 아키텍처의 스펙에 따라 개발해야 한다.
따라서 컴포넌트 개발에 대표적인 기술 플랫폼으로 COM, EJB, CCM 등을 볼 수 있다.
각각의 기술 플랫폼에서 규정하는 개발 방식이 다르기 때문에 해당 기술에 기반을 둔 컴포넌트를 개발할 경우에는 해당 기술에 제시하는 규칙을 따라 개발해야 한다.
package ejb.examples;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
//홈인터페이스
public interface OrderHome extends EJBHome {
public IOrder create() throws CreateException, RemoteException;
}
package ejb.examples;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
//원격인터페이스
public interface Order extends EJBObject {
public void processOrder() throws RemoteException;
public void computeTotalFee() throws RemoteException;
}
예) EJB 컴포넌트를 개발하기 위해서는 홈 인터페이스와 원격 인터페이스 또는 로컬 인터페이스를 정의해야 하고, 각각의 인터페이스를 정의하기 위해서는 상속받아야 하는 인터페이스가 있다.
4. 패키징되어야 한다.
- 컴포넌트는 독립적으로 배포되기 위해서는 패키지 형태로 묶여서 제공되어야 한다.
컴포넌트 자체가 재사용 단위이며, 해당 ㅋ머포넌트를 구성하는 요소들은 하나의 형태로 배포되어야 하기 때문이다.
EJB 경우에 있어서도 EJB 컨테이너에 배포되는 컴포넌트의 단위는 JAR 파일로 형태로 제공된다.
해당 JAR 파일이 패키지인 것이다. 이 JAR 파일에는 컴포넌트의 인터페이스, 컴포넌트 구현 클래스, 컴포넌트 명세서 등이 포함되어 있다.
5. 독립적으로 배포 가능해야 한다.
- 각각의 컴포넌트를 별도로 구매 가능하며, 판매자 입장에서 독립적으로 판매 혹은 배포가 가능한 것이다.
이처럼 소프트웨어 컴포넌트도 독립적으로 배포가 가능해야 한다.
예) 전자 상거래 쇼핑몰에 구축에 필요한 컴포넌트들을 각각 구매 가능할 뿐만 아니라, 여러 다른 회사에서 개발한 컴포넌트들을 독립적으로 구매하며 조립이 가능해야 한다.
또한 컴포넌트는 컴포넌트 컨테이너 혹은 서버에 독립적으로 배포가 이루어져야 한다.
해당 컴포넌트 하나 자체 만으로는 전체 애플리케이션이 아니기 때문에 하나의 애플리케이션이 수행되기 위해서는 독립적인 컴포넌트들이 서버나 컨테이너에 배포되어야 애플리케이션이 실행된다.
UML
컴포넌트 설계는 컴포넌트와 인터페이스로 구성되며 인터페이스는 원으로 표기하지만 클래스 다이어그램에서 표기되는 인터페이스를 사전에 설계해야 한다.
컴포넌트의 정의에서 교체 가능한 부품으로 컴포넌트는 인터페이스와 동일하면 컴포넌트 교체가 가능하며 교체 가능하도록 인터페이스를 동일하게 설계할 수 있다.
이렇게 인터페이스가 동일한 컴포넌트는 해당 컴포넌트가 운영되는 아키텍처에서 동적으로 바인드되어 교체가 가능하다.
컴포넌트 내부 설계는 컴포넌트를 구성하는 하나 이상의 클래스들의 관계구조를 설계하는 것으로 하나의 컴포넌트 내부는 클래스 다이어그램을 통해 설계가능하다.
또한 컴포넌트는 외부에 제공하는 위한 인터페이스를 컴포넌트 내부에 설계한다.
이러한 컴포넌트 인터페이스는 컴포넌트 내부의 기능 중에 외부에 제공해야 하는 기능들을 인터페이스로 정의하여 외부에 공개하도록 설계할 수 있다.
컴포넌트 내부 로직의 설계는 복합구조 다이어그램을 이용하여 설계할 수 있다.
컴포넌트 내부 클래스들 간의 기능적인 관계를 설계할 수 있으며, 클래스들 간에 호출하는 기능 정보를 설계할 수 있다.
특히, 복합구조 다이어그램은 클래스에 대한 특정 시점의 객체 관계를 포트와 커넥터를 이용하여 설계할 수 있다.
이러한 컴포넌트 내부의 구조를 기반으로 순차도를 이용하여 기능 흐름을 설계할 수 있다.
컴포넌트 자바 구현은 EJB 아키텍처를 사용하지 않고도 일반 클래스 형태로 구현 가능하다.
//컴포넌트 인터페이스
public interface OnlineOrderIF {
public void order(String id);
}
//컴포넌트 내의 클래스들을 제어하는 제어 클래스
public class OnlineOrder implements OnlineOrderIF { //컴포넌트 제어 클래스는 교체 가능
public void order(String id) { ... }
}
public class OnlineOrderX implements OnlineOrderIF {
public void order(String id) { ... }
}
컴포넌트 인터페이스는 일반 자바 인터페이스를 이용하여 구현할 수 있으며, 내부 구조를 가지고 있는 컴포넌트 구현은 컴포넌트의 내부 클래스들을 패키징할 수 있는 클래스로 구현할 수 있다.
물론 물리적인 패키징은 JAR로 묶으며 컴포넌트 내부 클래스를 묶는 패키지 클래스는 내부 클래스들의 통합하여 제어하는 역할을 한다.
//컴포넌트 제어 클래스
public class OnlineOrder implements OnlineOrderIF {
// 컴포넌트 내부 클래스인 Order, Cart, Payment, Cash, CreditCard, Point를 제어함
}
//컴포넌트 패키징
Jar cvf OnlineOrder.jar OnlineOrderIF.class OnlineOrder.class Order.class Cart.class Payment.class Cash.class CreditCard.class Point.class
인터페이스와 컴포넌트 내의 클래스 단위로 패키지 하는 방법은 자바의 패키지 도구인 'jar'를 이용하여 컴포넌트 패키지를 할 수 있다. jar 뒤에 패키지 옵션 cvf로 설정한 후 컴포넌트 패키지명과 컴포넌트 내부에 구현되는 인터페이스와 클래스를 나열한다.
이렇게 구현된 OnlineOrder.jar는 하나의 독립적인 컴포넌트로 재사용될 수 있다.
정리
- 컴포넌트는 독립적이면서 물리적으로 교체 가능한 소프트웨어 부품이다.
- 컴포넌트는 동적으로 바인딩 될 수 있는 하나 이상의 모듈들에 대한 관리 패키지이다.
- 컴포넌트는 명시된 인터페이스들과 컴포지션의 단위이다.
- 컴포넌트는 독립적인 비즈니스 객체 또는 비즈니스 로직을 구현한 것이다.
- 컴포넌트는 100% 구현되어 있어야 하고, 스펙이 있어야 하고, 표준을 따라야 하며, 패키징되어 독립적으로 배포 가능해야 한다.
- 컴포넌트에 대한 설계는 UML의 컴포넌트 다이어그램과 내부 구조를 설계하기 위해 복잡 구조 다이어그램을 이용하여 설계할 수 있다.
- Java 언어에서 컴포넌트 인터페이스는 일반 자바 인터페이스를 이용하여 구현할 수 있으며, 내부 구조를 가지고 있는 컴포넌트 구현은 컴포넌트 내부 클래스들을 패키징할 수 있는 클래스로 구현할 수 있다.
출처-UML과 JAVA로 배우는 객체지향 설계 및 구현