타스크: 디자인 요소 구현
이 타스크는 디자인 파트(예: 클래스, 유스 케이스 실현(realization) 또는 데이터베이스 엔티티)에 대한 구현을 생성하거나 하나 이상의 결함을 수정하는 방법을 설명합니다. 그 결과는 대개 신규 또는 수정된 소스 코드와 데이터 파일이며 이를 일반적으로 구 현 요소라고 부릅니다.
원칙: 구현
관계
역할기본 수행자: 추가 수행자:
입력필수:
    선택사항:
      출력
        프로세스 사용법
        단계
        구현 준비
        타스크/문제점 이해

        구현 타스크를 시작하기 전에 구현자는 작업 지정 및 반복 계획에 지정된 범위에 대해 확실하게 알고 있어야 합니다. 구현 타스크는 해당 기능에 기여하는 여러 디자인 요소의 구현을 포함하는 어떤 특정 기능성(예: 디자인 유스 케이스 실현(realization) 구현 또는 결함 수정)을 달성하는 데 집중될 수 있습니다. 또는, 구현 타스크가 특정 디자인 요소(예: 디자인 서브시스템 또는 디자인 클래스)에 집중될 수 있고, 현재 반복에 필요한 범위까지 구현합니다.

        개발 환경 구성

        이 타스크의 결과, 하나 이상의 파일(구현 요소)이 작성 또는 갱신됩니다. 구현 준비의 일부로서, 구현자는 갱신될 요소 및 컴파일과 유닛 테스트에 필요한 다른 모든 요소에 알맞는 요소 버전이 사용 가능하도록 자신의 개발 환경이 올바르게 구성되었는지 확인해야 합니다. 구현자는 변경이 제어되고 버전이 지정되는 방법과 이들이 통합을 위해 전달되는 방법을 설명하는 프로젝트의 구성 및 변경 관리 프로시저를 인식하고 따라야 합니다.

        기존 구현 분석

        새로 클래스를 구현하기 전에 재사용하거나 채택할 수 있는 기존 코드가 있는지 고려하십시오. 구현이 나머지 시스템의 아키텍처 및 디자인에 맞는지를 이해하면 구현자가 그런 재사용 기회를 식별하고 구현이 나머지 시스템과 잘 맞도록 보장하는 데 도움이 될 수 있습니다.

        점진적으로 구현

        점진적으로 구현할 것을 권장합니다. 즉 몇몇 회귀 테스트를 하루에 여러 번 컴파일하고, 링크하고 실행하십시오. 모든 공용 오퍼레이션, 속성 및 연관이 디자인 중에 정의되지 않음을 인식해야 합니다.

        결함을 다룰 때는 증상이 아니라 문제점을 수정하십시오. 코드의 근본적인 문제점을 수정하는 데 초점을 둬야 합니다. 한 번에 하나씩 변경하십시오. 결함 수정이 그 자체로서 오류를 파생할 수 있는 타스크이기 때문에 새로운 결함이 발생하고 있는 위치를 찾기 쉽도록 수정사항을 점진적으로 구현해야 합니다.

        구현자는 특정 프로그래밍 언어에 대한 프로그래밍 가이드라인을 포함하여 프로젝트에 특정한 모든 구현 가이드라인을 인식하고 따라야 합니다.

        디자인을 구현으로 변환

        디자인을 구현으로 변환하는 다양한 기법이 있습니다. 다음은 몇 가지 예제입니다.

        • 플랫폼 특정 비주얼 모델링을 사용하면 초기 코드 프레임워크를 생성할 수 있습니다. 디자인에서 지정되지 않은 추가 코드를 사용해서 이 코드 프레임워크를 좀 더 정제시킬 수 있습니다.
        • 모델은 세부화될 수 있고, 실행 가능 프로토타입을 생성하는 데 사용될 수 있습니다. 구조(클래스 및 패키지 다이어그램)와 동작 다이어그램(예: 상태 및 활동 다이어그램) 둘 다 실행 가능 코드를 생성하는 데 사용될 수 있습니다. 이들 프로토타입은 필요에 따라서 추가로 정제될 수 있습니다.
        • 모델은 또한 모델이 구현을 완벽하게 표시하는 위치까지 세부화할 수 있습니다. 이 경우 추상 디자인을 코드 구현으로 변환하는 대신, 디자인을 가져가 모델에 직접 구현 세부사항을 추가합니다.
        • 디자인은 다양한 정도까지 플랫폼에 독립적일 수 있습니다. 플랫폼 특정 디자인 모델 또는 심지어 코드가 상위 레벨 플랫폼 특정 요소를 맵핑하기 위해 다양한 규칙에 적용되는 변환을 통해 생성될 수 있습니다. 이것이 OMG(Object Management Group) MDA(Model Driven Architecture) (http://www.omg.org) 이니셔티브의 초점입니다.
        • 관련 디자인 및 구현에서 디자인 및 코드 요소를 생성하기 위해 표준 패턴도 적용될 수 있습니다. 예를 들어 표준 변환 패턴을 데이터 테이블에 적용하여 데이터 테이블에 액세스할 Java 클래스를 작성할 수 있습니다. 또 다른 예제는 Eclipse Modeling Framework(http://www.eclipse.org/emf/) 모델을 사용하여 모델과 일치하는 데이터를 저장하기 위한 코드를 생성하고 데이터를 채우기 위한 사용자 인터페이스 구현을 생성하는 것입니다.

        그러나 모든 경우에 일부 디자인 추상이 수동으로 또는 일부 자동 변환의 적용을 통해 구현이 되기 위해 상세하게 설명됩니다.

        구현 완료

        이전 단계에서 설명한 대로, 디자인을 구현으로 변환하면 구현 완전성이 정도가 달라질 수 있습니다. 완전하고 허용 가능한 구현일 수 있습니다. 그러나 대개 구현을 완료하기 위한 중요한 노력이 있습니다. 예를 들면, 다음과 같습니다.

        • 변환 결과 조정(예: 성능을 개선하기 위해 또는 사용자 인터페이스를 개선하기 위해)
        • 다음과 같은 누락된 세부사항 추가:
          • 디자인에서 설명하는 오퍼레이션 완료 - 알고리즘 선택 및 코드 작성
          • 추가 지원 클래스, 오퍼레이션 및 데이터 구조 추가
        구현 평가

        구현이 목적에 맞는지를 확인하는 단계입니다. 테스트(다른 타스크에서 설명) 외에, 종종 다음의 추가 점검이 유용합니다.

        • 마음속으로 코드를 끝까지 읽으십시오. 구현에서 개인적으로 범하기 쉬운 일반적인 실수에 대한 체크리스트를 작성하여 해당 실수를 찾으십시오.
        • 도구를 사용하여 코드에서 오류를 검사하십시오. 예를 들어 정적 코드 규칙 검사기 또는 상세한 경고 레벨로 설정된 컴파일러를 사용하십시오.
        • 코드를 시각화할 수 있는 도구를 사용하십시오. 코드 시각화는 구현자가 과다한 결합, 순환 종속성 등과 같은 패턴을 식별하는 데 도움이 됩니다.
        디자인에 피드백 제공

        디자인이 구현되고 테스트될 때 필연적으로 오류가 발견되며, 종종 디자인에 영향을 주는 오류도 발견됩니다. 디자인 추상이 미래의 유지보수 노력을 위해, 계약상 또는 커뮤니케이션 이유로 유지보수되는 경우 디자인을 갱신해야 합니다.

        이 작업이 수행되는 방법은 프로젝트의 구성 및 변경 관리 프로세스에 의존합니다. 일반적으로 필요한 변경이 작고 동일한 개인이 클래스를 디자인하고 구현 중인 경우에는 정규 변경 요청이 필요없습니다. 개인이 디자인에서 변경을 수행할 수 있습니다.

        필요한 변경이 광범위하게 영향을 미치는 경우(예: 공용 오퍼레이션에서의 변경), 정규 변경 요청을 제출해야 할 수 있습니다.



        자세한 정보