컴포넌트 기반 방법론(CBD) – 산출물

컴포넌트 기반 방법론(CBD) – 산출물

3. 산출물

CBD 방법론에서 작성해야 하는 다섯 가지 필수 산출물과 이에 대한 기술 방안을 정리해보면 다음과 같다.

1) 요구사항 정의서(Requirements Specification)

요구분석의 목적은 시스템이 무엇을 해야 하는지에 대한 관계자들의 이해와 의견을 일치시키고, 시스템 개발자가 시스템을 제대로 이해할 수 있게 하며, 시스템의 범위를 결정하고,
제약 사항을 파악하고, 향후 시험평가를 위한 기준선으로 사용하기 위한 것이다. 요구사항 정의서는 사용자와의 면담, 설문, 워크숍 등을 통해 컴포넌트로 구현할 시스템에 대한
개략적인 요구사항을 도출한 후, 이를 기술하기 위해 사용된다.

2) 유스케이스 모델 기술서(Use Case Model Description)

컴포넌트 개발 초기 단계에서 개발자들은 구현하고자 하는 도메인에 대한 이해가 필수적이다. 이를 위해 개발자들은 요구 분석결과를 토대로 행위자를 식별한다.
그리고 행위자간의 행위 모델을 토대로 유스케이스를 정의하고, 이들 간의 관계를 결정한다.
이처럼 구현 대상 컴포넌트가 제공하는 기능을 행위자와 유스케이스 간 의 관계로 묘사한 것이 바로 유스케이스 모델이다.

3) 클래스 모델 기술서(Class Model Description)

컴포넌트는 여러 클래스와 객체로 이루어져 있다. 클래스 모델은 클래스 내부의 정적 구조를 표현하기 위한 것으로 객체지향기법에서 가장 중요한 산출물이다.
클래스는 공통 속성, 공통 행위, 객체들 간의 관계, 그리고 공통 객체 그룹에 대한 개념적 또는 구현된 실체를 의미한다.
클래스는 이전 단계에서 작성된 유즈 케이스 모델을 토대로 정의한다.
실제 클래스 모델은 복잡한 절차를 거쳐 작성되지만 본 명세 표준에서는 세부 절차에 대해서는 언급하지 않고 이의 구성요소만을 정의한다.

4) 컴포넌트 아키텍처 정의서(Component Architecture Specification)

컴포넌트 아키텍처는 대상 컴포넌트의 구조를 상세화하고, 분석 관점의 모델을 구현 가능한 수준으로 발전시키기 위해 사용된다.
본 표준에서 컴포넌트 아키텍처는 개별적인 뷰로 표현된다.
이는 소프트웨어 컴포넌트를 관점에 따라 5개의 뷰, 즉 유스케이스 뷰(use-case view)를 중심으로 논리 뷰(logical view), 컴포넌트 뷰(component view), 프로세스 뷰(process view),
배포 뷰(deployment view)로 구분한다.
이를 “4+1뷰” 아키텍처 모델(4+1 view architecture model)이라 한다.

5) 용어사전(Glossary)

표준 산출물에 포함된 용어의 의미를 정의하고 명세하기 위해 사용된다.