개요
이 도구 사용 도움말에서는 RSx에 대한 모델 구조 가이드라인에서 설명하는 대로 구현 모델의 최상위 레벨 구조를 정의한 것으로 가정합니다. 이 도구 사용 도움말의
단계에서는 이와 같은 초기 구조가 정제되는 것을 허용합니다.
이 도구 사용 도움말에서는 다음 단계가 수행됩니다.
권장되는 접근 방식은 모델 기반 개발(MDD)입니다(모델 기반 개발 및
모델 기반 아키텍처 참조). 개발 팀이 이 접근 방식을 따를 경우, 디자인 모델 구성에 의해 구현 모델이 강하게 구동됩니다. 구현 서브시스템이 식별되면 모델 디자인의 패키지 또는 서브시스템으로 모델링되어야
합니다. 일반적으로 말하면, 디자인 모델에서 패키지를 식별할 때 패키지를 도구 특정 프로젝트에 맵핑할 방법을 고려해야 합니다. 대형 서브시스템은 보통 자체의 고유 프로젝트에 맵핑되고 세분화된 패키지는 보통
프로젝트의 소스 폴더에 맵핑됩니다. 프로젝트 구조와 구현 및 디자인 모델의 내부 조직을 설명하는 RSx에 대한 모델 구조 가이드라인 섹션을 참조하십시오.
구현 보기는 서브시스템 사이의 종속성을 표시하는 다이어그램을 포함하여, <<Perspective>> 패키지를 사용하여 정의할 수
있습니다. 디자인 모델에 적용되는 변환 종류에 따라, 패키지/서브시스템 사이에 정의하는 종속성은 프로젝트 메타데이터에서 3GL 가져오기 선언과 프로젝트 종속성 선언에 맵핑될 수 있습니다.
코드가 생성되면 프로젝트에서 직접 클래스 다이어그램을 작성하고 구현 아티팩트를 끌어와 다이어그램을 채워서 구현 레벨 구조와 해당 관계를 보여주는 자세한 UML 다이어그램을 생성할 수 있습니다. UML Visual
Editor for Java에 관려된 온라인 도움말 항목을 참조하십시오.
구현 모델에서 코드 라이브러리의 특정 클래스, 인터페이스, 패키지 등에 대한 참조를 표시해야 하는 경우, 제품의 코드 시각화 기능을 사용하여 표시를 작성할 수 있습니다. 다음 jar 파일에는 사용자가 J2EE
응용프로그램을 디자인 및 개발할 때 관심이 갈 수 있는 파일이 있습니다.
-
j2ee.jar, jsf-api.jar, soap.jar, soap-sec.jar(모두 lib 디렉토리에 있음)
-
core.jar, xml.jar, security.jar(모두 java\jre\lib 디렉토리에 있음)
사용자 모델에 있는 해당 라이브러리 중 하나에서 요소를 참조해야 하는 경우 다음 단계를 수행하십시오.
-
새 Java 프로젝트를 작성하고 라이브러리에 참조를 추가하십시오.
-
시각화된 요소를 추가하려는 다이어그램을 여십시오.
-
Java Perspective로 전환하십시오.
-
모델을 추가할 요소(패키지, 클래스, 인터페이스 등)를 찾으십시오.
-
요소를 마우스 오른쪽 단추로 클릭하고 시각화 > 현재 다이어그램에 추가를 선택하십시오.
코드 및 관련 파일이 상주할 것으로 예상되는 실제 프로젝트 및 패키지를 표시해야 하는 경우, 코드 생성 이전에 구현 개요 모델이 유용할 수 있습니다. 자세한 정보는 RSx에 대한 모델 구조 가이드라인 백서에서 구현 모델 관련 항목을 참조하십시오.
다음은 구현 서브시스템을 조정하는 데 도움을 제공하는 일련의 단계입니다.
-
다음을 사용하여 문제점을 야기하는 서브시스템(예: 순환 종속성)을 식별하십시오.
-
-
토픽 및 브라우즈 다이어그램
-
아키텍처 발견
-
코드 검토/구조적 코드 분석
-
서브시스템을 새로 작성하십시오.
-
식별된 요소를 새 서브시스템으로 이동하십시오.
-
새 종속성을 그리십시오.
MDD 환경에서, 구현 모델의 종속성은 디자인 모델에서 명시적 또는 암시적으로 정의한 종속성과 아주 근접하게 미러링합니다. 특정한 것은 디자인 모델에 적용된 코드 생성 변환으로 판별됩니다.
입력 모델 외에도, 변환을 수행하는 데 필요한 다른 아티팩트가 있습니다. 변환 프로세스에서는 변환 정의와 해당되는 변환 규칙이 필요합니다.
변환 규칙은 변환 프로세스가 소스 모델의 한 요소를 대상 모델의 0개 이상의 요소로 변환하기 위해 사용하는 설명을 제공합니다. 특히, 한 추상 레벨의 요소를 더 낮은 추상 레벨에서 해당되는 자세한 요소로
맵핑합니다.
수동 변환을 사용하는 경우, 개발자가 디자인 모델을 코드로 변환할 때 개발자에게 충분한 안내를 제공하고 있는지 확인해야 합니다. 특히, 변환 규칙 세트를 포함하는 변환 정의를 제공해야 합니다. 이 추가 안내의
가능한 양식은 다음과 같습니다.
-
문서화된 프로파일의 요소
-
모델의 노트
-
소프트웨어 아키텍처 문서의 추가 정보
-
개발 가이드라인
구현 개요 모델을 사용하는 경우, 이 모델은 프로젝트와 패키지 사이의 예상 종속성을 표시할 위치가 됩니다. 이는 시스템 빌드 요구사항을 식별하는 데 유용할 수 있습니다(RSx에 대한 모델 구조 가이드라인 참조).
MDD 환경에서는 디자인 모델에 적용되는 변환 종류에 따라 다양한 유형의 배치 가능 아티팩트를 생성할 수 있습니다. 예를 들어, <<제어>> 및 <<엔티티>> 클래스와
같은 요소에서 J2EE 대상에 대해 세션 및 엔티티 EJB를 생성할 수 있습니다. 여기에는 구현 클래스의 코드, 인터페이스와, EJB를 EJB JAR에 할당하고 해당 JAR을 EAR에 맵핑하는 배치 설명자 컨텐츠가
포함됩니다.
배치 모델을 사용하여 개념적 레벨에서 배치 가능 아티팩트를 모델링하도록 선택할 수 있습니다. 이 경우 UML 노드 및 아티팩트를 사용하여 모델링합니다. 현재, 도구와 패키징된 변환은 배치 데이터를
생성하기 위한 이와 같은 다이어그램의 시맨틱을 활용하지 않으므로, 다이어그램은 순전히 개념적이며 문서로만 유용합니다.
선택적으로, 실제 구현 아티팩트를 캔버스에 놓고 다이어그램의 개념적 요소에 연결하여(종속성 사용) 이와 같은 다이어그램에서 실제 구현 아티팩트도 묘사할 수 있습니다.
테스트 자산 구조에 영향을 줄 핵심 고려사항은 테스트 자산 작성 방법에 대한 결정입니다.
자동화된 컴포넌트 테스트 기능을 사용할 것을 선택하여 고유 테스트를 작성할 수 있습니다. 이 경우, 작성 프로세스의 일부로 하나 이상의 독립 테스트 케이스 프로젝트가 설정됩니다. 이 기능을 사용할 경우
얻는 주요 이점 중 하나는 초기 코드 생성을 이용하고 코드 스텁을 사용하여 테스트 케이스가 작성되도록 할 수 있다는 것입니다.
프로젝트 저장소는 디렉토리 세트 또는 계층 구조로 구성된 상태로 보존하십시오. 테스트 자산은 다른 테스트 유형(유닛 테스트, 통합 테스트, 시스템 테스트)과 분리하여 독립 테스트 디렉토리에 보존하는 것이 좋습니다.
독립 구현 보기가 있는 경우 이 보기를 유지보수해야 합니다. RSx에 대한 모델 구조 가이드라인 백서에 제시된 일반 권장사항은 서브시스템 사이의 종속성을 표시하는 다이어그램을 포함하여,
<<Perspective>> 패키지를 사용하는 것입니다.
시스템이 발전하면서 사용자는 사용자 서브시스템 종속성(및 기타 종속성)이 우수 사례를 계속 따르고 있는지 확인할 수 있습니다. 이와 같은 이유로, 아키텍처 발견, 일반적인 코드 검토 및 특수한 구조 분석을 사용하여
모델이 우수 사례를 따르는지 확인하십시오.
이전에 언급한 것처럼, 식별한 종속성을 시행하기 위해 사용할 수 있는 사용자 정의 규칙을 도입하는 데 시간을 소모할 수도 있습니다. 검토의 수동 부분에서, 아직 개발되지 않은 규칙의 노트를 작성하여 다음 반복의
규칙 세트에 추가할 수 있습니다.
HTML 형식으로 모델을 공개하는 데 유용할 수 있습니다. 또한 Microsoft Word 및 기타 프로그램으로 다이어그램을 복사할 수도 있습니다.
자세한 정보는 모델 공개 및 웹에 모델 공개 학습서를 참조하십시오.
|