가이드라인: J2EE 어플리케이션의 구현 모델 구조화

주제

소개To top of page

개념: J2EE 플랫폼 개요, 엔터프라이즈 JavaBean개념: 설계에서 코드로 맵핑에서 다루는 기술 플랫폼으로 J2EE에서의 일반 정보에 친숙하다고 가정합니다. 이 가이드라인의 일부 개념은 UML 1.4에 속하지만, UML 1.3 기반 플러그인의 컨텍스트에서 사용할 수 있습니다. 무언가 파악하기 어려운 경우, 두 개의 UML 스펙에서 해당 사항에 대해 무엇을 언급해야 하는지 검사하십시오.

구현 모델 구조화 To top of page

활동: 구현 모델 구조화에서는 설계 모델의 구조와 강력하게 일치되는 구현 모델 구조를 생성하는 방식을 설명하지만, 동시에 개발 환경 제한조건을 반영하며 병렬 개발 및 증분 통합을 지원합니다.

J2EE 어플리케이션의 구현 모델 구조는 개발 및 구현 환경에 의해 좌우되지만, 일반적으로 J2EE 구현 모델에는 4개의 잠재적인 구조가 있습니다.

  • 전개 지원(J2EE 모듈 및 전개 설명자)
  • 가상 디렉토리 구조(JSP, HTML 페이지)
  • 웹 서버에서 전개되는 요소의 Java 디렉토리(servlet, JavaBean)
  • EJB 어플리케이션 서버에서 전개되는 요소의 Java 디렉토리(EJB)

구현 서브시스템 모델링 To top of page

결과물: 소프트웨어 구조 문서의 구현 보기는 구현 모델의 상위 레벨 개요를 제공합니다. 이것은 구현 서브시스템 식별을 포함합니다. J2EE 어플리케이션에서 구현 서브시스템은 하나의 모델(예: JSP 및 HTML 페이지)에서 비Java 요소와 다른 모델에서 Java 요소를 포함할 수 있으므로, 구현 서브시스템은 파일 시스템의 단일 디렉토리나 모델의 단일 패키지로 맵핑될 수 없습니다. 이를 처리하는 하나의 전략은 각 모델에서 병렬 패키징 구조를 갖는 것입니다. 각 모델에서 동일한 이름을 가진 패키지가 내재적으로 연관됩니다.

전개 가능한 단일 구현 파일(JAR, WAR 또는 EAR 파일)의 구현을 제공하는 것이 구현 서브시스템에 일반적입니다. 이 경우, 전개 가능한 파일을 식별하는 것은 구현 서브시스템을 식별하게 할 수 있습니다.

구현 디렉토리 및 구현 파일로 구성되는 실제 요소의 표시가 각 구현 서브시스템에 있을 수 있습니다. 또한 결과물: 설계 모델 요소에 해당하지만 소스 코드의 정확한 모델(라운드 트립 엔지니어링 모델)인 클래스, 컴포넌트, 패키지 등으로 구성된 논리적 요소가 있을 수 있습니다. 설계 모델구현 모델 간의 관계에 대한 자세한 정보는 개념: 설계에서 코드로 맵핑을 참조하십시오.

라운드 트립 엔지니어링 모델은 소스 코드의 정확한 표시를 제공합니다. J2EE에서 Java 모델의 각 패키지는 Java 패키지를 표시하며, 각 클래스는 Java 클래스를 나타냅니다. 그러나 다음을 포함하여 추가 정보로 라운드 트립 엔지니어링 모델을 자주 보충할 필요가 있습니다.

  • 라운드 트립 엔지니어링의 일부분으로 자동 생성되지 않는 정보를 표시하는 다이어그램
  • 모델의 상위 레벨 추상화

설계 모델은 클래스, 컴포넌트, 패키지 등을 추상화합니다. 그러나 실제 요소(파일 및 디렉토리)에 대한 상위 레벨 추상화 또는 추가 다이어그래밍의 요구사항이 있을 수 있습니다. 이것은 차후 섹션에서 설명됩니다.

구현 디렉토리 모델링To top of page

라운드 트립 엔지니어링은 보통 개발 환경에서 필요한 디렉토리의 서브세트만을 처리합니다. 테스트 결과물, 전개 단위, 문서 등을 구성하는 데 자주 추가 디렉토리가 필요합니다. 일반적으로 디렉토리를 파일 시스템의 일부분으로 볼 수 있으면 모델링이 필요하지 않습니다.

구현 파일 모델링 To top of page

라운드 트립 엔지니어링 툴에서 일부 지원을 제공하거나 일부 명확하지 않은 관계를 표시할 필요가 있는 경우를 제외하고는 일반적으로 구현 파일이 모델링되지 않습니다.

일반적으로 각 Java 인터페이스 또는 클래스마다 하나의 .java 파일이 있으며, 각 .java 파일마다 컴파일된 하나의 .class 파일이 있습니다. 그러므로 이 파일을 모델링하는 것은 이득이 많지 않습니다.

J2EE에서 서브시스템은 보통 하나 이상의 아카이브 파일(JAR, WAR 또는 EAR 파일)을 포함합니다.

아카이브 파일은 대개 아카이브 파일에서 아카이브 파일이 포함하는 파일로의 구성 관계로 제대로 모델링됩니다. 그러나 컴파일된 .class 파일이 JAR 파일을 작성하도록 결합되면 JAR 파일에서 JAR 파일이 긍극적으로 구현하는 클래스 및 인터페이스로의 종속성을 표시하는 데 더 유용할 수 있습니다.

구현 서브시스템이 하나의 JAR 파일만을 생성하는 경우 모델링이 전혀 필요하지 않으며, 구현 서브시스템의 전개 가능한 모든 파일이 JAR 파일의 일부분으로 가정될 경우 특히 그렇습니다.

아카이브 파일 중복

동일한 요소 중 일부를 포함하는 두 개의 아카이브 파일을 정의하는 것이 가능하지만 권장되지는 않습니다. 예를 들어, 두 개의 EAR 파일은 동일한 EJB JAR 모두는 아니지만 일부를 포함하거나, 두 개의 EJB JAR이 동일한 EJB를 포함할 수 있지만, 다른 전개 설명자를 가질 수 있습니다.

구현 서브시스템 및 전개 가능한 아카이브 파일 간에 밀접한 대응을 유지하려면 아카이브 파일이 겹치지 않는 것이 최적입니다. 그러나 중복이 필요한 경우, 이러한 중복의 합리성과 함께 이를 모델링하는 것이 도움이 될 수 있습니다.



Rational Unified Process   2003.06.15