페이퍼요약 - 컴포넌트 기반 개발 프로세스와 컴포넌트 생명주기 by Crnkovic

제목: 컴포넌트 기반 개발 프로세스와 컴포넌트 생명주기(Component-based Development Process and Component Lifecycle)

저자: Ivica Crnkovic 외 2인, 스웨덴

문서유형: 저널 페이퍼(총 7페이지), 2005년

 

컴포넌트 기반 개발 프로세스와 비컴포넌트 기반 개발 프로세스의 주요 차이점을 기술한 자료

---

컴포넌트 기반 생명주기 프로세스 모델

• 다른 타입의 시스템에서 사용되는 소프트웨어 공학의 방법, 도구, 원칙이 컴포넌트 기반 소프트웨어 엔지니어링(Component-based Software Engineering: CBSE)에서도 동일하거나 유사하게 사용됨
• 한가지 차이점은 CBSE에서는 “컴포넌트 자체를 개발하는(component development)” 프로세스와 “컴포넌트를 이용하여 시스템을 개발하는(system development with components)” 프로세스가 구분된다는 점
• 컴포넌트를 이용한 시스템 개발은 적절한 컴포넌트를 찾고 이들을 검증하는데 중점을 두며, 컴포넌트 자체의 개발에서는 “재사용을 위한 설계(design for reuse)”가 주된 관심사

1) 컴포넌트를 이용한 시스템 구축(Building Systems from Components)

• 컴포넌트 기반 개발(CBD)에서는 이미 개발되었고 타 제품에서 사용되었을 수도 있는 컴포넌트(재사용가능한 엔터티)를 찾고 평가하는 신규 프로세스가 등장. 즉, 컴포넌트의 위치를 찾고, 가장 적합한 컴포넌트를 선정하고, 이를 테스팅 하는데 개발 노력이 소요됨
• 비컴포넌트 기반 방법에 비해 CBD 프로세스에서는 프로그래밍 노력이 크게 줄어드는 대신 검증 및 테스팅 노력이 증가된다.
• 아래 그림은 컴포넌트 기반 접근 방법에 적용된 V 개발 모델을 나타냄. 비컴포넌트 기반 방법에서 단위 설계/구현/테스트로 이어지는 프로세스가 CBD에서는 적절한 컴포넌트를 찾아 평가하고 이를 시스템으로 통합시키는 프로세스로 대체됨. 즉, 컴포넌트를 선정하고(select), 시스템에 알맞게 적응시키고(adapt), 테스트하는 활동이 수행된다.
• 물론 컴포넌트 자체의 개발 프로세스도 있어야 하지만 이는 그림 하단에 표현된 것처럼 시스템 개발 프로세스로부터 독립적이다(많은 경우 컴포넌트가 시스템 개발과는 별개로 제 3자에 의해 개발됨). 

[CBD를 위한 V 개발 프로세스]

위 그림의 V 개발 프로세스를 더 현실적인 CBD 프로세스로 표현하면 아래와 같다.

[CBD를 위한 상세한 V 개발 프로세스]

• 요구사항 분석과 명세(Requirements analysis and specification): 요구사항들이 가용한 컴포넌트로 충족될 수 있는지를 분석. 요구사항 엔지니어는 사용가능한 컴포넌트에 대해 반드시 알고 있어야 함. 적합한 컴포넌트가 항상 발견되는 것은 아니므로 신규 컴포넌트를 구현해야만 하는 리스크도 존재
• 시스템 설계와 소프트웨어 설계(System and software design): 여러 다른 컴포넌트 기술로 구현된 컴포넌트의 사용이 가능하다고 흔히 가정하지만 실제는 다른 컴포넌트 모델간의 상호운용성(interoperability)을 얻기가 매우 어려우므로 잠재적인 컴포넌트들은 특정 컴포넌트 모델을 준수해야 한다. 특정 컴포넌트 모델은 특정 아키텍쳐 프레임워크를 요구하며, 애플리케이션도 이 프레임워크를 사용할 것으로 여겨짐. 이는 아키텍쳐적인 의사결정에 직접적인 영향을 미치며(즉, 시스템 설계에 제약을 줌), 컴포넌트의 다른 속성들도 설계 의사결정에 직접적인 영향을 줄 수 있다. 이런 이유로 설계 프로세스도 컴포넌트 가용성과 밀접한 연관이 있다.
• 구현과 단위 테스팅(Implementation and unit testing): 컴포넌트 기반 시스템 구축 시 이상적인 경우는 컴포넌트의 직접 통합(즉, 컴포넌트들을 직접적으로 연결)에 의해 애플리케이션을 구축하는 것이며, ‘글루 코드(glue code)’는 이런 연결을 명세하는 코드이다. 현실에서 글루 코드의 역할은 컴포넌트 적응(adaptation)과 심지어 신규 기능의 구현 까지도 포함한다. 컴포넌트 자체가 이미 구축되고 테스트 되었다 하더라도 개별 컴포넌트의 독립적인 테스트만으로는 충분하지 않다. 종종 설계 단위가 여러 컴포넌트들을 조합한 어셈블리로 구현되므로 이 어셈블리도 따로 테스트 되어야 한다(어셈블리를 구성하는 컴포넌트 개개의 정확성이 어셈블리의 정확성을 보장 못함).
• 시스템 통합(System Integration): 특정 컴포넌트를 시스템으로 통합하는 것을 “컴포넌트 전개(component deployment)”라 함. 전체 시스템 통합과 달리 컴포넌트 전개는 특정 컴포넌트의 통합을 위한 메커니즘이다(컴포넌트를 다운로드하고 등록하는 것을 포함함).
• 시스템 검증 및 확인(System verification and validation): 표준 테스트 및 검증 기법이 사용됨. CBD에서는 ‘에러 위치’가 문제가 될 수 있음(특히 컴포넌트가 블랙박스 타입으로 외부 업체에 의해 공급된 경우). 에러가 특정 컴포넌트에서 모습을 드러내었어도 오작동 원인이 다른 컴포넌트에 있을 수도 있음. 계약상의 인터페이스(Contractual interfaces)는 컴포넌트의 적절한 입력과 출력을 체킹(데이터 정확성 확인)하는데 중요한 역할을 한다.
• 운영 지원과 유지보수(Operation support and maintenance): 유지보수 프로세스는 통합 프로세스와 유사한 일부 스텝을 포함한다(예, 신규/변경된 컴포넌트를 시스템으로 전개, 글루 코드를 변경). 대개의 경우 기존 컴포넌트가 변경되거나 또는 동일한 컴포넌트의 새로운 버전이 시스템으로 통합됨. 컴포넌트간 비양립성(incompatibility)이나 의존관계 끊김(broken dependencies)으로 인한 새로운 문제가 발생할 수 있으므로 시뮬레이션, 테스팅 등을 통해 시스템이 반드시 검증되어야 한다.

2) 재사용가능한 컴포넌트 구축(Building Reusable Components)

• 컴포넌트 구축 프로세스는 어떤 개발 프로세스 모델이든 따를 수 있지만 목표(예, 컴포넌트 기능성, 재사용성) 달성을 위한 특정한 변경이 요구될 수 있다.
• 재사용성(Reusability)은 일반성(generality)과 유연성(flexibility)을 의미하며, 이런 요구사항이 컴포넌트의 특징을 크게 변경시킬 수도 있음. 예를 들어, 이식성(portability) 요구사항은 특정 구현 솔루션(예, 프로그래밍 언어, 서비스 중간층 구현, 프로그래밍 스타일)이 선택되도록 영향을 미친다. 일반성 요구사항은 기능성(functionality) 이상의 것을 의미하며 따라서 더 많은 설계/개발 노력과 더 높은 수준의 개발자들이 요구된다.
• 컴포넌트 개발에서는 컴포넌트의 테스팅과 명세에 더 많은 노력이 요구됨. 컴포넌트는 독립적으로 테스트 되어야 하고 또한 여러 다른 구성(configurations)에서 테스트 되어야 한다. 컴포넌트의 이해를 증가시키는데 중요한 역할을 하는 문서화(documentation) 및 전달(delivery)에도 더 많은 노력이 요구된다.

컴포넌트 기반 프로세스 모델 사례 연구

• 실제 사례 연구로 컴포넌트 기반 방법을 적용하는 글로벌 가전제품 업체에서 사용되는 프로세스 모델을 조사함
• 4명의 연구자가 개발 프로젝트의 여러 이해관계자(시스템 아키텍트, 컴포넌트 아키텍트, 개발자, 프로젝트 리더, 경영자, 품질보증 및 테스팅 인력, 기타 핵심 전문가)와 집중 인터뷰를 통해 사례 연구를 수행함
• 이 회사의 개발 부서는 4개의 다른 나라에 위치하며, 여러 변형(variants)과 모델을 가진 다양한 제품을 생산함
• 회사는 제품 라인 아키텍쳐(product line architecture)를 사용한 컴포넌트 기반 개발을 도입함. 해당 도메인의 특정한 요구사항(낮은 리소스 사용, 높은 가용성, 소프트 리얼타임 요구사항)을 충족시키기 위해 컴포넌트 모델은 내부적으로 개발되었고 대부분의 도구도 내부적으로 개발됨

1) 컴포넌트 모델

이 컴포넌트 모델은 아래와 같이 CBSE의 기본 원칙을 따른다.

• 컴포넌트가 “require” 인터페이스와 “provide” 인터페이스를 구별하는 인터페이스에 의해 명세된다.
• 인터페이스는 기능적 명세(functional specification)에 더하여 인터액션 프로토콜, 적시성 속성(timeliness properties), 메모리 사용 같은 추가적인 정보를 포함한다.
• 컴포넌트 모델이 다수 인터페이스의 존재를 허용하므로 컴포넌트의 원활한 진화(a smooth evolution)를 가능하게 한다.
• 컴포넌트 모델이 계층적 조합(hierarchical compositions)을 허용한다. 조합된 컴포넌트(composite component)는 하나의 표준 컴포넌트로 취급되며, 또 다른 컴포넌트로 더 통합될 수도 있다.
• 컴포넌트도 회사 내부적으로 개발되지만 컴포넌트의 개발은 제품의 개발로부터 독립된다.

2) 제품 라인 아키텍쳐(product line architecture)

기본 아키텍쳐 프레임워크를 식별한 제품 라인 아키텍쳐는 아래 그림과 같다.

• 제품 라인 아키텍쳐는 i) 운영체제, ii) 도메인 특정 서비스와 운영 서비스간의 중간층인 컴포넌트 프레임워크, iii) 모든 제품 변형(product variants)에 포함되는 코어 컴포넌트, iv) 대개 제품 변형 마다 달라지는 애플리케이션 컴포넌트를 포함하는 계층적 아키텍쳐이다.
• 이 수평적 계층을 보완하기 위해 서브시스템 형태의 수직적 구조(a vertical structuring)도 존재함 서브시스템은 조직 구조와도 관련됨(특정 컴포넌트의 개발과 유지보수를 책임짐)

[제품 소프트웨어 아키텍쳐]

3) 전체 개발 프로세스

• 전체 프로세스는 아래 그림처럼 3개의 독립적인 병행 프로세스 집합으로 구성된다.
  i) 전반적 아키텍쳐 및 플랫폼 개발 프로세스: 새로운 플랫폼과 기본 컴포넌트 전달을 책임짐
  ii) 서브시스템 개발 프로세스: 여러 다른 서비스를 제공하는 컴포넌트의 집합을 전달함
  iii) 제품 개발 프로세스: 기본적으로 통합 프로세스임
• 이런 병행 프로세스가 매 6개월마다 신규 제품을 생산하는 것을 가능하게 함(서브시스템 컴포넌트 개발에는 대개 12~18개월이 소요됨)
• 이 프로젝트들의 특징은 모든 deliverable(컴포넌트로 정의된 소프트웨어 패키지)이 동일 형태를 가진다는 점이다. 각 deliverable에는 상호연결을 기술한 “컴포넌트 인터페이스 명세(component interface specification)”와 컴포넌트 내부를 기술한 “컴포넌트 시트(component sheet)”의 두 가지 문서가 따라 붙는다.

[전체 개발 프로세스]