Software Factories
들어가는 말
소프트웨어 개발방법론은 소프트웨어 공학이라는 학문으로부터 지금까지 꾸준히 제기되어 온 Issue다. 그만큼 포괄적이고 광범위한 내용이 다루어지고 있고 나날이 발전하는 개발툴과 개발 아키텍쳐 사이에서 소프트웨어 개발 접근방식에 따라 기능중심 개발방법론, 구조적 개발방법론, 객체지향 개발방법론 등이 제기되어 왔다.
여기서 소개하고자 하는 Software Factory 개발 방법론은 높은 수준의 재사용을 가능하게 하는 모델 기반 중심의 개발 방법론으로서 주요 개념에 대해서 알아보자.
1. 소프트웨어 개발의 문제점 (Chronic Problems)
▶ 전체적인 개발 (Monolithic Construction)
■ 아직까지 대다수의 소프트웨어 개발이 상업적으로 인정받을 만한 수준의 재사용에 의한 개발이 이루어지지 않고 있다.
■ 소프트웨어는 아직까지 처음부터 전체적으로 개발되고 있다.
■ 플랫폼 종속적인 프로토콜에 의존하는 컴포넌트는 플랫폼 경계에서의 조립을 어렵게 한다.
■ 현재의 컴포넌트 명세와 패키징 기술은 컴포넌트와 그들의 상호작용과 관련된 특성을 충분히 표현하지 못하여 조립에 의해 개발되는 소프트웨어 특성을 예측하기 어렵다.
■ 적극적인 캡슐화의 결과 컴포넌트의 경계가 너무 일찍 고정되어 변형하기 어렵다.
▶ 이유 없는 일반성 (Gratuitous Generality)
■ 전형적인 비즈니스 애플리케이션은 작은 부분에 한해 범용 3세대 언어가 필요함에도 불구하고 대부분의 소프트웨어가 해당 언어에 종속되어 개발되고 있다.
■ UML 과 같은 모델링 언어도 스케치를 위한 수단으로는 적합하지만 모델-기반 개발이나 실행언어로는 부적합하다.
■ UML은 특정 도메인에 관한 상세한 정보를 표현하기 어려우며, 확장 기능이 취약하여 특화하는 것도 어렵다.
■ CASE 도구들은 낮은 품질의 코드가 생성된다.
■ 메타데이터들은 소프트웨어 라이프 사이클의 자동화에 사용될 수 있으나 이들의 효과적인 통합 보다는 구현 형식을 단일화 하려고 한다.
▶ 일회성 개발 (One-Off Development)
■ 일회성 개발은 모든 소프트웨어 제품을 유일하게 한다.
■ 대부분의 개발 프로세스들은 일회성 개발을 지원하도록 설계되고 있다.
■ 대부분의 소프트웨어 개발에서 재사용 가능한 컴포넌트를 확인하고, 다시 사용할 수 있도록 문서화하고 패키지화하는 검토를 거의 하지 않는다.
▶ 프로세스의 미성숙 (Process Immaturity)
■ 소프트웨어 개발은 약속된 일정과 예산 내에서 만족할 만한 제품을 인도하지 못해 왔다.
■ 자동화는 잘 정의된 프로세스만이 자동화할 수 있기 때문에 재사용을 위해서는 프로세스 자체가 먼저 발달해야 한다.
2. Software Factory의 필요성
■ 특정 도메인을 위한 소프트웨어를 개발할 때 그 도메인과 관련된 지식이 개발되는 소프트웨어에 내포되어 이러한 지식이 소프트웨어 내에 감추어져 있어서 이를 포함하고 있는 소프트웨어의 원래 영역 밖으로 재사용할 수 없다는 문제가 있다.
■ 소프트웨어 팩토리는 특정 도메인에 관한 기존의 전문화된 지식과 도메인 내에서 개발된 프로그램을 수집하여 재사용이 가능한 생산자산으로 변환하기 위한 적극적인 방법론이다.
■ 소프트웨어 팩토리는 이러한 지식을 유사한 다른 형태의 프로그램을 위한 청사진을 생성하는데 사용할 수 있고, 특정 도메인 내에 존재하는 가치 있고 재사용이 가능한 생산 자산으로부터 프로그램을 생성하는 것을 목적으로 하고 있다.
■ 소프트웨어 팩토리는 소프트웨어가 모듈화되어 재사용 가능한 자산이 되도록 하는 프로세스를 규정하고 있다.
3. Software Factory 주요 개념
■ Software Factory
Software Factory는 확장 가능하게 만들어진 도구들과 프로세스, 그리고 자동으로 원형 제품을 적합하게 수정하고, 조립하며, framework-based 컴포넌트들을 구성함으로써 다양한 제품을 만들고, 유지 보수할 수 있도록 software factory schema에 기반한 software factory template을 사용하는 소프트웨어 생산라인이다.
■ Software Factory Schema
Software Factory Schema는 소프트웨어 제품군의 구성원들을 묘사하기 위한 틀인데, Architecture만이 아닌, 소프트웨어 제품군, 요구 사항들, 구현, 배포, 테스트, 사용, 디버깅, 관리, 유지, 성능과 같은 매우 많은 측면을 다루며, 개발 구조를 조직하고, 원형으로부터 어떻게 구성원이 다른지 표현하는 방법과 같은 family based 개발을 지원하는 메커니즘을 구체화한 것이다.
소프트웨어 팩토리 스키마라고 하는 관점 그래프는 한 수준의 추상화, 시스템의 한 부분 또는 수명 주기의 한 단계에서 수행된 작업을 다른 수준 또는 다른 부분 및 단계에서 수행된 작업과 관련시킵니다.
관점 그래프는 모델, 소스 코드, 구성 파일 등 항목을 전체 또는 부분적으로 생성하고, 개발 중 항목의 동기화를 유지하며, 직접 개발한 항목의 유효성을 검사하고, 결함의 영향이나 요구 사항의 변경 내용을 평가하고, 패턴과 기타 모범 사례를 구성 및 적용하며, 시스템 개발 중 메타데이터를 캡처하여 시스템 운영 및 관리를 지원하고, 다른 형태의 지침과 관리를 수행하는 데 사용될 수 있습니다
4. Software Factory 주요 요소
■ 모델과 패턴
1. 모델은 프로젝트의 여러 개념에 대한 일관성 있는 표현을 유지할 수 있다는 점에서 매우 중요하다.
2. 소프트웨어 시스템의 핵심 추상화와 개념을 표현하고 조작하는 역할 뿐만 아니라 그로부터 구현에 관한 구체적 결과물을 생성하는 작업에 효과적으로 사용될 수 있어야 한다.
3. 모델은 많은 항목의 정보를 추상화하고 집계할 수 있기 때문에 보다 신속하게 일관성 검사 및 다른 유형의 분석을 지원할 수 있습니다.
4. 생성된 결과물을 수정하면 그 내용이 모델에도 반영될 수 있도록 의미적 연관성과 상호작용이 가능해야 한다.
■ 도메인 특화언어(Domain Specific Languages)
1. 모델링 언어로서 도메인 특화언어(DSL)은 분석가, 설계자, 개발자, 테스터 또는 시스템 관리자가 고민해야 하는 몇 가지 분명하게 식별되는 문제를 해결하는 데에만 중점을 둔 작은 언어로 생각할 수 있습니다.
2. 개발자들은 이미 데이터 조작을 위한 SQL, XML 문서 구조 정의를 위한 XSD 등과 같은 DSL의 예에 익숙합니다.
3. 후보 DSL을 찾는 좋은 방법은 개발자가 사용하는 패턴을 확인한 후 모델링 언어로 캡슐화하거나 개념을 소프트웨어 프레임워크에 모델링 언어의 추상화로 나타내 프레임워크를 확장하는 소량의 코드를 생성하는 것입니다.
■ 소프트웨어 생산 라인(Software Product Line)
1. 소프트웨어 팩토리는 모델, 모델 기반 도구, 다른 유형의 도구(마법사, 템플릿, 유틸리티 등), 개발 프로세스, 구현 구성 요소(클래스 라이브러리, 프레임워크, 서비스 등), 콘텐츠 자산(패턴, 스타일시트, 도움말 파일, 구성 파일, 설명서 등)을 포함하여 다시 사용할 수 있는 자산을 패키지로 만들고 제공합니다.
2. 소프트웨어 팩토리 스키마는 모델이므로 팩토리는 도구를 사용하여 조작할 수 있습니다. 소규모 팩토리를 조합하여 대규모 팩토리를 만들 수 있으며 일반적인 팩토리를 사용자 지정하여 특수 팩토리를 만들 수도 있습니다.
3. 팩토리 빌드는 프레임 빌드와 매우 유사합니다. 팩토리 빌드에서는 개발자가 쉽게 적용할 수 있도록 패턴과 기타 모범 사례를 얻고 구현하는 과정을 수행합니다.
4. 다시 사용할 수 있는 구성 요소를 찾기 위해 카탈로그와 리포지토리를 검사하는 대신에 개발자는 팩토리를 사용하여 개발 중인 각 시스템에 적합한 다시 사용 가능한 구성 요소를 시스템 아키텍처 및 개발 프로세스에서 즉시 사용할 수 있도록 하기 때문에 팩토리를 사용하는 편이 처음부터 직접 시스템을 빌드하는 것보다 효율적입니다.
맺음말
현재까지의 소프트웨어 공학이나 개발방법론들은 모두 공통된 목적이 있다.
개발 생산성을 향상시키고 기존 자원의 재사용성을 높여 비용 측면뿐만이 아닌 변화의 요구에 얼마나 빨리 대응할 수 있는가가 아닌가 생각된다.
이런 측면에서 소프트웨어 팩토리는 기계적이고 단순한 작업을 자동화하여 개발자의 생산성을 높여 주며 팩토리에서 제공하는 프로그래밍 가능한 도구를 사용하여 개발자들은 문제 해결 방법을 생각하는 데 더 많은 시간을 할애하고 솔루션 생성, 빌드 및 배포에 필요한 모든 단순한 작업에는 시간을 덜 소비할 수 있는 개발방법론이라 생각된다.
점점 더 복잡해지고 있는 시스템과 대형화되는 프로젝트, 요구의 변화가 빠르게 전개되는 시대에서 적은 비용과 인력으로 양질의 프로그램을 제조공장처럼 빠르게 생산 할 수 있는 시기가 점점 현실로 다가오는 느낌이다.