객체지향 소프트웨어 개발 방법론 알아보기

 

객체지향 분석

객체지향 분석(OOA, Object-Oriented Analysis)은 새로운 제품이나 시스템을 구축할 때, 어떻게 객체지향 소프트웨어 공학(OOSE, Object-Oriented Software Engineering) 방법을 활용하여 그 특성을 정의하고 구체화할 수 있는지에 대한 기술적인 활동입니다. OOA는 다양한 질문에 대한 답을 통해 문제를 명확히 이해하고 효과적인 설계를 위한 기반을 마련합니다. 예를 들어, 관련된 객체는 무엇인지, 객체들 간의 관계는 어떻게 형성되는지, 객체들이 시스템 내에서 어떻게 작동하는지 등을 파악합니다.

객체지향 분석은 다음과 같은 기본 원칙에 근거하여 수행됩니다. 우선, 분석 모형을 구축하기 위해 다음 5개 원칙을 적용해야 합니다.

(1) 정보 도메인을 구체화합니다: 문제 영역에 대한 정보를 명확하게 정의합니다.

(2) 모듈 기능을 기술합니다: 개별 모듈의 기능과 역할을 명시합니다.

(3) 모형 행위를 표현합니다: 모델 내에서 객체들이 어떻게 상호작용하는지를 표현합니다.

(4) 모형들을 세부사항으로 나타내기 위해 분할합니다: 모델을 세부적인 요소로 분할하여 표현합니다.

(5) 초기 모형들은 문제의 본질을 나타내고 차후의 모형들은 구현의 세부사항들을 나타냅니다: 초기 모형은 문제를 이해하기 위한 핵심 요소를 나타내며, 이후의 모형은 구체적인 구현을 고려한 것입니다.

 

객체지향 분석의 목적은 해결하려는 문제와 관련된 클래스, 그들 간의 관계, 그리고 행위를 정의하는 것입니다. 이를 위해 다음과 같은 작업이 필요합니다.

(1) 사용자 요구사항은 고객과 소프트웨어 엔지니어 사이의 의견 교환을 통해 작성되어야 합니다.

(2) 클래스들은 식별되어야 합니다.

(3) 클래스 계층이 명시되어야 합니다.

(4) 객체들 사이의 관계(객체 대 객체)가 표현되어야 합니다.

(5) 객체 행위가 모델화되어야 합니다.

(6) 위의 (1)에서 (5)까지의 단계가 반복적으로 재적용되어 모델이 완성될 때까지 진행되어야 합니다.

 

객체지향 설계

객체지향 설계(object-oriented design)는 시스템 설계와 객체 설계로 구분될 수 있습니다. 시스템 설계는 분석 모형을 실제 시스템의 설계 모형으로 변환하는 작업으로, 하드웨어와 소프트웨어 플랫폼을 정의하고 시스템의 구조를 결정하며, 서브시스템으로 분할하여 정의합니다. 반면, 객체 설계는 분석 단계에서 생성된 응용 객체를 실제 구현 객체로 변환하는 작업으로, 객체들에 대한 더 자세한 서비스를 정의하고 구현하거나 재사용 가능한 객체 부품을 찾는 작업을 수행합니다. 시스템 설계의 결과는 서브시스템으로 분할된 모형이며, 이는 UML(Unified Modeling Language)의 배치 다이어그램을 통해 표현될 수 있습니다. UML은 객체지향 설계의 표현 방법으로 널리 인정받고 있으며, 사용사례 다이어그램, 클래스 다이어그램, 순서 다이어그램, 상태 다이어그램, 액티비티 다이어그램 등 다섯 가지 표현 방법을 제공합니다.

 

(1) 시스템 설계

시스템 설계는 알고리즘 설계와는 다른 개념입니다. 그러나 소프트웨어 구조를 표현하기 위한 전형적인 패턴이 경험을 통해 발전되었습니다. 시스템 설계 작업은 다음과 같은 작업으로 구성됩니다.

 

- 목표의 정의 : 설계의 목적과 목표를 명확히 정의합니다.

- 서브시스템 파악 : 시스템을 구성하는 서브시스템을 파악하고 정의합니다.

- 프로세서와 구성 요소 배정 : 시스템에 필요한 프로세서와 구성 요소를 할당합니다.

- 자료 저장소 정의 : 시스템 내의 데이터 저장소를 정의하고 구성합니다.

 

(2) 객체 설계

객체 설계는 응용 객체를 구현 객체로 변환하는 작업입니다. 분석 단계에서 생성된 응용 객체를 구현 가능한 객체로 변경하는 과정에서 기존에 개발된 부속 객체를 활용할 수도 있고, 서브시스템의 인터페이스에 맞게 클래스를 새로 작성해야 할 수도 있습니다. 객체 설계의 목적은 개발자가 클래스를 구현할 수 있도록 객체 설계 모형을 잘 정의하는 것입니다. 객체 설계는 다음과 같은 작업으로 구성됩니다.

- 서비스 정의 : 객체들의 서비스를 정의하고 구체화합니다.

- 구성 요소 선택 : 객체를 구성하는 요소들을 선택하고 정의합니다.

- 재구조화 : 객체들의 구조를 재조정하고 최적화합니다.

- 최적화 : 객체들의 성능을 최적화하기 위한 작업을 수행합니다.

 

(3) 객체지향 설계

전통적인 소프트웨어 개발 방법론에서는 설계의 개념을 소개하며, 아키텍처 설계, 모듈 설계, 데이터 설계, 인터페이스 설계 등의 네 가지 설계 층이 정의되고 논의되었습니다. 객체지향 시스템 개발도 설계 피라미드로 정의할 수 있습니다.

- 서브시스템 설계(subsystem design): 각 서브시스템의 표현을 포함하여 고객 요구사항을 달성하고 기술적인 기반 구조를 구현합니다.

- 클래스와 객체 설계(class and object design): 시스템에서 생성한 클래스 계층과 개별 객체의 설계 표현을 포함합니다.

- 메시지 설계(message design): 객체 간의 상호작용을 설계하며, 시스템의 외부 및 내부 인터페이스를 설정합니다.

- 책임 설계(responsibilities design): 각 객체의 데이터 구조와 알고리즘 설계에 대한 책임을 포함합니다.

 

객체지향 테스팅

객체지향 테스팅은 오류를 최대한 많이 발견하기 위해 가능한 노력을 기울이는 것이라고 간단히 설명할 수 있습니다. 객체지향 소프트웨어에서도 테스팅의 기본 목적은 동일하지만, 객체지향 프로그램의 특성으로 인해 테스팅 전략과 전술이 다소 다릅니다. 객체지향 시스템에서 테스팅은 다음 네 단계로 구분할 수 있습니다.

 

(1) 개별 객체와 관련된 연산의 개별적인 테스트 : 함수나 프로시저를 테스트하는 단계입니다. 화이트박스 테스트 또는 블랙박스 테스트와 같은 테스트 방법을 사용할 수 있습니다.

(2) 개별 객체 클래스의 테스트 : 원칙적으로 블랙박스 테스트를 사용하지만, 클래스 수준으로 테스트를 확장할 때는 관련 연산을 모두 포함한다는 의미입니다.

(3) 객체들의 클러스터 테스트 : 관련된 객체들이 모여 집합을 형성하는 것으로, 엄격히 말하면 상향식 통합이나 하향식 통합과는 다릅니다. 이러한 경우에는 시나리오 기반 테스트와 같은 새로운 접근 방식이 모색되고 있습니다.

(4) 객체지향 시스템 테스트 : 시스템 요구사항 명세서에 명시된 시스템이 개발되었는지 확인하거나 검증하는 작업으로, 다른 유형의 시스템과 크게 다르지 않습니다.

 

상속이 사용될 때 객체 클래스의 테스트는 더 어려워집니다. 슈퍼 클래스가 제공하는 연산을 여러 개의 서브클래스가 상속한다면, 모든 서브클래스가 상속된 연산과 함께 테스트되어야 합니다. 상속된 연산은 다른 연산이나 속성에 대해 가정을 가지고 있는데, 이 가정은 상속 시에 변경될 수 있기 때문입니다. 게다가 슈퍼 클래스의 연산도 무시(override)될 수 있는데, 이 경우에도 테스트되어야 합니다.

 

객체지향 시스템이 개발될 때는 통합 단계가 비교적 명확하지 않습니다. 이는 연산과 데이터가 객체와 객체 클래스로 통합되기 때문입니다. 객체 클래스를 테스트하는 것은 단위 테스트의 한 부분으로 볼 수 있습니다. 객체지향 시스템에서는 모듈 테스트에 해당하는 테스트 단계가 없다고 볼 수 있습니다. 그러나 일련의 서비스를 제공하기 위해 결합하는 클래스들의 그룹을 함께 테스트하는 것을 클러스터 테스트라고 합니다.

 

객체지향 시스템에서는 상향식 통합이나 하향식 통합이 적절하지 않습니다. 왜냐하면 통합 정점(top)이 존재하지 않고, 객체 사이에도 명확한 계층 구조가 보이지 않기 때문입니다. 이러한 이유로 클러스터를 형성하고 테스트하는 것이 필요한데, 통합 테스트를 위한 세 가지 접근 방법이 있습니다.

(1) 사용 사례 또는 시나리오 기반 테스트 : 사용 사례 또는 시나리오는 시스템 사용의 각 모드를 설명하는 것입니다. 이러한 시나리오를 기반으로 객체 클러스터를 형성하여 테스트하는 것입니다.

(2) 스레드 테스트 : 스레드 테스트는 특정 입력 데이터나 일련의 입력 과정에 대한 시스템의 반응을 테스트하는 것을 기본으로 합니다. 객체지향 시스템은 종종 이벤트 중심으로 개발되기 때문에 이러한 방식의 테스트가 유용합니다. 이 접근 방식을 사용하기 위해서는 각 이벤트의 처리 과정이 시스템 내부에서 어떻게 진행되는지 이해해야 합니다.

(3) 객체 반응 테스트 : 상호작용하는 객체들을 그룹별로 테스트하는 방식입니다. 통합 테스트로 가는 중간 단계의 테스트로, 메서드-메시지 경로를 규명하는 것을 기본으로 합니다. 객체들의 상호작용을 추적하는 일은 객체 연산이 다른 객체의 서비스를 요청하지 않을 때까지 진행됩니다. ASF(Atomic System Function)는 입력 이벤트가 메서드-메시지 경로를 통해 출력 이벤트로 완료되는 것으로 구성되며, 이와 관련된 구조를 규명하면 됩니다.

 

시나리오 기반 테스트는 가장 효과적인 방법으로 알려져 있습니다. 이유는 테스트 과정에서 가장 빈번히 발생할 가능성이 높은 시나리오를 우선적으로 테스트하고, 가끔 발생하는 예외적인 시나리오는 나중에 고려해도 된다는 점입니다. 테스트의 기본 원칙은 가장 빈번하게 사용되는 부분을 우선적으로 테스트해야 한다는 것입니다. 객체지향 시스템의 테스트에서는 설계 패턴을 더 많이 재사용함으로써 과도한 테스트를 필요로 하지 않을 수도 있습니다. 그러나 재사용은 새로운 용도로 사용되기 때문에 재테스팅(retesting)은 신중하게 수행되어야 합니다. 모든 객체지향 시스템은 구문(syntax), 의미(semantics), 실용(pragmatics)적인 면에서의 정확성(correctness), 완전성(completeness), 일관성(consistency)이 테스트되어야 합니다.