목적

  • 설계 일부(예: 클래스, 유스 케이스 구현 또는 데이터베이스 엔티티)에 대한 구현 생성 또는 하나 이상의 결함 수정. 일반적으로 구현 요소라고 하는 소스 코드 및 데이터 파일이 생성 또는 수정됩니다.
역할:  구현자 
빈도:  각 반복 동안에 반복됨(프로토타입이 필요하지 않은 경우 초기 반복의 가능한 예외와 함께) 
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

구현 준비 페이지 맨 위

타스크/문제점 이해

구현 활동을 시작하기 전에 구현자는 작업 지정 및 반복 계획에 지정된 대로 범위에 대해 명확해야 합니다. 구현 타스크는 일부 특정 기능(예: 설계 유스 케이스 구현을 전이 또는 결함 수정)을 완수하는데 초점을 맞출 수 있으며 이러한 특정 기능은 해당 기능에 공헌하는 여러 설계 요소의 구현과 연관됩니다. 또는 구현 타스크가 특정 설계 요소(예: 설계 서브시스템 또는 설계 클래스)에 초점을 맞춰 현재 반복에 필요한 범위까지 구현할 수 있습니다.

개발 환경 구성

이 활동으로 하나 이상의 파일(구현 요소)이 작성 또는 갱신되게 됩니다. 구현 준비의 일부로서, 구현자는 올바른 요소 버전을 사용할 수 있도록 개발 환경이 올바르게 구성되었는지 확인해야 합니다. 이 작업은 갱신할 요소와 컴파일 및 단위 테스트에 필요한 다른 모든 요소에 수행해야 합니다. 구현자는 프로젝트 구성을 이해하고 따르며 관리 프로시저를 변경해야 합니다. 이러한 프로시저는 변경사항의 제어 및 버전 지정 방법과 통합을 위해 전달되는 방법에 대해 설명합니다.

기존의 구현 분석

클래스를 구현하기 전에 재활용 또는 수정할 수 있는 기존의 코드가 있는지 고려하십시오. 나머지 시스템 설계 및 구조에 적합한 구현 위치를 이해함으로써 구현자가 재활용 기회를 식별하는 데 도움이 됩니다. 또한 나머지 시스템에도 구현이 적합한지 확인할 수 있습니다.

증분 구현

하루에 두 번 정도 회귀 테스트를 컴파일, 링크 및 실행하여 구현 횟수를 늘리도록 권장합니다. 모든 공용 조작, 속성 및 연관이 설계 중에 정의되지 않음을 인식하는 것이 중요합니다.

결함을 다루는 경우, 증상이 아닌 문제점을 수정했는지 확인하십시오. 코드의 근본적인 문제점을 수정하는 데 초점을 맞추어야 합니다. 오류 수정 자체가 오류를 발생시킬 수 있는 활동이므로 한 번에 하나씩 변경하십시오. 새 오류의 원인을 쉽게 찾을 수 있도록 수정을 더 구현해야 합니다.

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

설계를 구현으로 변환 페이지 맨 위

설계를 구현으로 변환시키기 위해 다음과 같이 다양한 기술을 사용할 수 있습니다. 몇 가지 예가 나와 있습니다.

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

그러나 모든 경우에 있어 일부 설계 추상이 일부 자동화된 변환을 적용하거나 수동 방식으로 구현이 됩니다.

구현 완료 페이지 맨 위

이전 단계에서 설명한 대로 구현으로 설계를 변환하는 경우 구현의 완성도는 매우 다양합니다. 완전하고 올바른 구현일 수도 있지만 일반적으로 구현을 완료하려면 상당한 노력이 필요합니다. 예를 들면, 다음과 같습니다.

  • 변환 결과 튜닝(예를 들어, 성능을 향상시키거나 사용자 인터페이스를 개선하기 위해)
  • 다음과 같이 누락된 세부사항 추가
    • 설계에서 설명하는 조작 완료
    • 지원 클래스, 조작 및 데이터 구조 추가

구현 평가 페이지 맨 위

구현이 목적에 적합한지 확인해야 하는 경우입니다. 일반적으로 테스트(다른 활동에서 설명) 외에도 다음과 같이 몇 가지 추가 확인 작업이 효과적입니다.

  • 코드를 읽으십시오. 구현 시 공통적인 실수에 대해 체크리스트를 작성하십시오.
  • 오류가 있는지 도구를 사용하여 코드를 확인하십시오. 예를 들어, 정적 코드 규칙 검사 프로그램 또는 컴파일러를 세부 경고 레벨로 설정합니다.
  • 코드를 시각화할 수 있는 툴을 사용하십시오. 코드 시각화를 통해 구현자가 과도한 결합, 순환 종속성 등과 같은 패턴을 식별하는 데 도움이 됩니다.

설계에 피드백 제공 페이지 맨 위

설계를 구현 및 테스트하는 과정에서 설계에 영향을 주는 오류가 반드시 발생합니다. 다음에 유지보수 노력이나 계약 또는 의사소통 이유로 설계 추상을 유지하는 경우, 설계를 갱신해야 합니다.

완료되는 방법은 프로젝트의 구성 및 변경 관리 프로세스에 따라 달라집니다. 일반적으로, 필요한 변경이 적고, 동일한 개인이 클래스를 설계 및 구현 중인 경우, 공적 변경 요청이 필요하지 않습니다. 개인이 설계 시 변경할 수 있습니다.

예를 들어, 공용 조작 변경과 같이 필수 변경이 광범위한 영향을 미치는 경우, 공식 변경 요청을 제출해야 합니다.



Rational Unified Process   2003.06.15