•
통합이란 개별적인 소프트웨어 컴포넌트를 하나의 시스템으로 결합하는 소프트웨어 개발 행위를 말한다.
◦
작은 프로젝트라면 클래스를 연결하는 데 반나절 정도 걸릴 것이다.
◦
큰 프로젝트에서는 여러 개의 프로그램을 연결하는 데 몇 주 혹은 몇 달이 걸릴 것이다.
◦
그럼에도 작업의 크기에 상관없이 공통적으로 적용되는 원칙이 있다.
•
통합이라는 주제는 구현 순서라는 주제와 밀접한 연관이 있는데, 클래스나 컴포넌트를 작성하는 순서는 그것을 통합하는 순서에 영향을 미친다.
•
아직 만들어지지 않은 것을 통합할 수 없기 때문으로 통합과 구현 순서는 아주 중요한 주제다. 이 장에서는 통합이라는 관점에서 이 두가지를 다룬다.
1. 통합 접근 방법의 중요성
•
경기장이 완공되었을때 얼마나 튼튼한지는 구현에 있어서 중요한 가치가 아니다. 경기장은 각 단계를 버틸 수 있을만큼 튼튼해야 한다.
•
소프트웨어를 잘못된 순서로 구현하고 통합하면 코드를 작성하거나 테스트하거나 디버깅하는 것이 어렵다.
•
통합은 개발자가 개발자 테스트와 시스템 테스트를 마치고 난 다음에 수행되기 때문에 때때로 테스트 활동으로 여겨지기도 한다. 하지만 통합은 매우 복잡해서 개별 활동으로 다뤄야 한다.
•
통합을 신중히 잘 했다면 다음과 같은 이익을 기대할 수 있다.
◦
더 쉬운 결함 진단, 더 적은 결함, 더 적은 비계, 첫 번째 제품 완성 시간 단축, 전체적인 개발 일정 단축, 더 나은 고객과의 관계, 의욕 고취, 프로젝트 완성 기회 향상, 더 신뢰할 수 있는 일정 측정, 더 정확한 상황 보고, 향상된 코드 품질, 더 적은 문서
2. 통합 빈도-단계별 또는 점증적 접근 방법
•
프로그램은 보통 단계별 또는 점증적인 접근 방법으로 통합된다.
단계별 통합
•
단계별 통합은 다음과 같이 잘 정의된 과정 혹은 단계를 따른다.
1.
각 클래스를 설계하고 작성하고 테스트하고 디버깅한다. 이 단계를 단위 개발이라고 한다.
2.
클래스를 하나의 큰 시스템으로 결합한다. 이 단계를 시스템 통합이라고 한다.
3.
전체 시스템을 테스트하고 디버깅한다. 이 단계를 시스템 분해라고 한다.
•
단계별 통합이 가진 한 가지 문제점은 시스템에 있는 클래스가 처음 통합될 때 불가피하게 새로운 문제점이 발생하고 그러한 문제점의 원인이 발생한 곳을 찾기가 어렵다는 것이다.
◦
수많은 클래스가 이전까지는 함께 동작해본적이 잆기 때문에 문제의 원인이 제대로 테스트되지 않은 클래스 일수도 클래스 간의 인터페이스일 수도 상호작용으로 발생한 오류일 수도 있다. 모든 클래스를 의심해야 한다.
•
특정한 문제가 발생한 위치가 불확실성을 가지고 한 순간에 발생하므로 더 이는 더 심각해진다. 이러한 이유로 단계별 통합을 빅뱅 통합이라고도 한다.
•
아주 작거나 적당히 작은 프로그램에선 단계별 통합이 최고의 방법일 것이다. 하지만 대부분의 경우에는 다른 접근 방법이 더 나을 것이다.
점증적 통합
•
점증적 통합에서는 작은 단위로 프로그램을 작성하고 테스트한 다음, 한 번에 하나씩 코드를 결합한다. 다음과 같은 과정을 따른다.
1.
시스템에서 크기가 작고 기능적인 부분을 개발한다. 그것은 가장 작은 기능이 수행하는 부분이 될 수도 있고 가장 어려운 부분이나 핵심적인 부분 또는 몇 부분들을 결합한 것일수도 있다.
•
그러한 부분을 전체적으로 테스트하고 디버깅한다. 그것이 시스템의 나머지 부분을 구성하는 근육과 신경, 피부를 붙일 수 있는 뼈대 역할을 한다.
2.
클래스를 설계하고 코드를 작성하고 테스트하고 디버깅한다.
3.
새로운 클래스를 뼈대에 통합한다. 뼈대와 새로운 클래스를 결합한 것을 테스트하고 디버깅한다.
a.
새로운 클래스를 추가하기 전, 결합한 부분이 잘 동작하는지 확인한다.
점증적 통합의 이점
•
오류를 찾기가 쉽다.
◦
새로운 문제점이 발생하는 경우, 새롭게 통합된 클래스가 문제와 관련이 있을 확률이 높다.
•
시스템이 초기부터 작동한다.
◦
시스템을 사용할 수는 없더라도 코드를 통합하고 결과물이 작동하면 시스템도 정상적으로 작동할 것임이 분명해진다.
◦
진행 상황을 좀 더 잘 관찰할 수 있다.
◦
고객과의 관계가 향상될 것이다.
◦
시스템 요소를 더 완전히 테스트한다.
◦
더 짧은 개발 일정으로 시스템을 만들 수 있다.
•
점증적 통합은 다른 점증적인 전략을 지지하고 장려한다.
3. 점증적 통합 전략
•
단계별 통합에서는 프로젝트 컴포넌트를 만드는 순서를 계획할 필요가 없다. 모든 컴포넌트가 동시에 통합되므로 순서에 상관없이 통합이 가능하다.
•
점증적 통합에서는 좀 더 신중하게 접근한다. 대부분의 시스템은 다른 컴포넌트를 통합하기 전에 몇몇 컴포넌트가 미리 통합되어 있어야 한다. 따라서 통합 계획은 구현 계획에 영향을 미친다.
•
통합 순서 전략은 형태가 규모나 다양하고 모든 상황에 적합한 최고의 전략은 없다. 가장 훌륭한 통합 접근 방법은 프로젝트에 다라 다르며 최고의 해결책은 언제나 프로젝트에 특화된 요구사항을 충족하도록 만든 전략이다.
하향식 통합
•
하향식 통합에서는 계층 구조의 상위에 있는 클래스를 먼저 작성하고 통합한다.
•
클래스 사이의 인터페이스를 신중하게 명시해야 하는데, 디버깅하기 가장 어려운 오류가 어느 한 클래스에 영향을 미치는 오류가 아닌, 두 클래스 사이의 미묘한 상호작용으로 발생하는 오류기 때문이다.
•
시스템 제어 논리 구조를 비교적 일찍 테스트할 수 있다는 장점을 가지는 반면 계층 구조의 상위에 있는 클래스는 모두 많이 사용되기 때문에 크고 개념적인 설계상 문제점이 빨리 노출된다.
•
제대로만 계획한다면 프로젝트 초기 단계부터 부분적으로 작동하는 시스템을 완성할 수 있다.
상향식 통합
•
상향식 통합에서는 계층 구조의 맨 아래부터 클래스를 작성하고 통합한다.
•
상향식 통합 그대로 점증적 통합 전략이라고 할 수 있는 이유는 저수준 클래스를 한꺼번에 추가하지 않고 한 번에 하나씩 추가하기 때문이다.
•
상향식 점증적 통합에서 얻는 이점은 한정되어 있는데, 오류의 원인을 통합하고 있는 단일 클래스로 제한하기 때문에 오류를 찾기가 쉽다.
•
상향식 통합의 가장 큰 문제점은 마지막에 가서야 고수준 시스템 인터페이스를 통합할 수 있다는 점이다. 시스템이 상위 수준에서 개념적인 설계상 문제점을 갖고 있다면 모든 세부 작업이 처리되고서야 발견할 수 있다.
샌드위치 통합
•
순수 하향식, 상향식 통합들이 가지는 문제점 때문에 샌드위치 접근 방법을 권장하기도 한다.
•
우선 상위 수준에서 고수준 비즈니스 객체 클래스를 통합한다. 그리고 장치-인터페이스르 클래스와 하위 수준에서 널리 사용되는 유틸리티 클래스를 통합한다.
◦
여기서 고수준 클래스와 저수준 클래스가 샌드위치의 빵 역할을 한다.
•
중간 수준의 클래스는 나중까지 남겨두는데, 이 클래스가 샌드위치의 고기, 치즈, 토마토 역할을 한다.
•
이러한 접근법은 순수 하향식, 상향식 통합의 엄격함을 피해간다.
위험 지향적인 통합
•
어려운 부분 우선 통합이라고도 불리기도 하는 접근 방법으로 샌드위치 통합과 마찬가지로 최상, 최하위 클래스를 먼저 통합하고 중간 수준을 나중을 위해 남겨두는 경향이 있다.
기능 지향적인 통합
•
기능을 구성하는 작은 부분을 반복적으로 통합하고 나서 점증적으로 기능을 통합해 하나의 시스템을 구성할 수 있다.
•
다음과 같은 주요한 세 가지 장점을 제공한다.
◦
저수준 라이브러리 클래스를 제외하고는 어떠한 기능에도 테스트 더블이 필요하지 않다.
◦
새로 통합된 기능을 점증적으로 추가할 수 있다.
◦
객체지향 설계에서 잘 동작한다.
T-자형 통합
•
초기 개발과 통합을 위해 특정한 수직적인 부분이 선택되고 이를 먼저 구현하고 연관된 문제점이 수정되면 시스템의 전체적인 부분을 개발할 수 있다.
⇒ 해당 부분은 시스템을 구석구석 사용해야 하며 시스템의 설계 시 가정한 중요한 문제점을 제거할 수 있어야 한다.
통합 접근 방법 요약
•
한 가지를 독단적으로 따르기보다는 진행하는 프로젝트에 맞게 바궈 자기만의 전략을 만들어야 한다.
4. 일일 빌드와 스모크 테스트
•
소프트웨어를 통합하는 좋은 접근 방법의 하나는 일일 빌드와 스모크 테스트다.
◦
모든 파일을 매일 컴파일하고 링크하며 실행 프로그램으로 만든다. 그러고 나서 해당 프로그램을 실행했을 때 연기를 내뿜는지 확인하는 간단한 스모크 테스트를 거친다.
•
이는 커다란 장점을 제공해준다.
◦
우선 실패하거나 문제가 있는 통합 위험과 관련된 품질 저하 위험을 줄여준다.
◦
모든 코드를 매일 스모크 테스트하면 품질 문제가 프로젝트로 퍼지는 것을 예방할 수 있다.
•
더 쉽게 결함을 진달할 수 있게 해주는데, 제품을 매일 빌드하고 테스트하면 어떤 날에 왜 제품이 작동하지 않는지 확인하기 쉽다.
•
일일 빌드를 사용할 때의 장단점
•
매일 빌드한다.
•
깨진 빌드를 확인한다.
•
매일 스모크 테스트한다.
•
스모크 테스트를 최신으로 유지한다.
•
일일 빌드와 스모크 테스트를 자동화한다.
•
빌드 그룹을 만든다.
•
타당한 경우에만 빌드에 수정된 내용을 추가한다.
•
개발자가 작성한 코드를 시스템에 추가하기 전에 스모크 테스트하게 한다.
•
아침에 빌드를 배포한다.
요점 정리
•
구현 순서와 통합 접근 방법은 클래스를 설계하고 개발하고 테스트하는 순서에 영향을 미친다.
•
통합 순서를 신중하게 고려한다면 테스트하는 데 드는 노력을 줄일 수 있고 디버깅을 쉽게할 수 있다.
•
점증적인 통합은 다양한 형태가 존재하며 프로젝트가 아주 작지 않다면 이들 중 하나를 사용하는 것이 단계적 통합보다 나을 수 있다.
•
특정한 프로젝트에 대한 최고의 통합 접근 방법은 일반적으로 통합 접근 방법들을 조합한 것이다. T-자형 통합과 수직적인 부분 통합도 자주 적용되는 접근 방법이다.
•
일일 빌드는 통합에서 발생하는 문제를 줄여주고 개발자의 사기를 향상시키고 프로젝트 관리에 유용한 정보를 제공할 수 있다.
