가이드라인: 디자인 패키지
디자인 패키지는 디자인 모델을 파티션하는 데 사용하는 구조입니다. 이 가이드라인은 디자인 패키지를 식별 및 지정하는 방법을 설명합니다.
관계
기본 설명

소개

쉽게 이해할 수 있도록 디자인 모델은 더 작은 단위로 구성할 수 있습니다. 디자인 모델 요소를 패키지 및 서브시스템으로 그룹화한 후 이 그룹을 서로 관련시키는 방법을 표시하면 모델의 전반적인 구조를 쉽게 이해할 수 있습니다. 디자인 서브시스템은 하나 이상의 인터페이스를 실현하는 컴포넌트로 모델링되었음에 유의하십시오. 자세한 정보는 중간 산출물: 디자인 서브시스템중간 산출물 가이드라인: 디자인 서브시스템을 참조하십시오. 반면 디자인 패키지는 그룹화에만 적합합니다.

패키지 컨텐츠 가시성

패키지에 포함된 클래스는 public이거나 private일 수 있습니다. Public 클래스는 다른 클래스와 연관될 수 있습니다. Private 클래스는 패키지에 포함된 클래스에서만 연관될 수 있습니다.

패키지 인터페이스는 패키지의 public 클래스로 구성됩니다. 패키지 인터페이스(public 클래스)는 다른 패키지에서 종속성을 분리한 후 구현합니다. 이 방법으로 초반에 인터페이스를 설정할 수 있고 개발자는 다른 패키지의 인터페이스에서 변경한 사항만 알면 되므로 병렬 개발이 단순화됩니다.

패키지 파티션 기준

다음과 같이 여러 가지 이유로 디자인 모델을 파티션할 수 있습니다.

  • 시스템을 완료한 경우 주문, 구성 또는 전달 단위로 패키지 및 서브시스템을 사용할 수 있습니다.
  • 자원 할당 및 다른 개발 팀의 역량에 따라 프로젝트를 다른 사이트의 다양한 그룹에 분배해야 할 수 있습니다. 잘 정의된 인터페이스를 포함하는 서브시스템은 팀 사이에서 통제 및 조정된 방식으로 작업을 배분하는 방법을 제공합니다. 따라서 디자인 및 구현을 병렬로 진행할 수 있습니다.
  • 서브시스템을 사용하여 사용자 유형을 반영하는 방식으로 디자인 모델을 구성할 수 있습니다. 많은 변경 요구사항은 사용자부터 시작됩니다. 서브시스템이 있으면 특정 사용자 유형의 변경이 해당 사용자 유형에 해당하는 시스템 파트에만 영향을 줍니다.
  • 일부 응용프로그램에서 특정 정보는 소수의 인원만 액세스할 수 있습니다. 서브시스템이 있으면 필요한 영역에 비밀을 보관할 수 있습니다.
  • 지원 시스템을 빌드하는 경우 서브시스템 및 패키지를 사용하여 지원되는 시스템 구조와 유사한 구조를 제공할 수 있습니다. 이 방법을 사용하면 두 개의 시스템에서 유지보수를 동기화할 수 있습니다.
  • 다음 여러 섹션에서 설명하는 대로, 시스템에서 사용하는 기존의 제품 및 서비스(예: COTS 제품 및 라이브러리)를 표시하는 경우 서브시스템을 사용합니다.

패키지 경계 클래스

경계 클래스가 패키지에 분배된 경우 경계 클래스는 적용할 수 있는 서로 다른 두 개의 전략이 있습니다. 선택사항은 시스템 인터페이스가 향후 크게 변경될 것인지, 아닌지에 따라 다릅니다.

  • 시스템 인터페이스가 바뀔 가능성이 크거나 많이 변경되는 경우 인터페이스는 나머지 디자인 모델과 분리되어야 합니다. 사용자 인터페이스가 변경되면 이 패키지만 영향을 받습니다. 이러한 주요 변화의 예제로 선 지향 인터페이스에서 창 지향 인터페이스로 전환되는 상황이 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

기본 목적이 주요 인터페이스 변경을 단순화하는 것이면 경계 클래스를 하나 이상의 독립된 패키지에 배치해야 합니다.

  • 주요 인터페이스 변경이 계획되지 않은 경우 인터페이스의 변경이 아닌 시스템 서비스의 변경이 안내 원리가 됩니다. 이때 경계 클래스를 기능적으로 관련된 엔티티 및 제어 클래스와 함께 배치해야 합니다. 이 방법을 사용하면 특정 엔티티 또는 제어 클래스를 변경하는 경우 경계 클래스가 영향을 받는 정도를 쉽게 확인할 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

시스템 서비스의 변화를 단순화하도록 경계 클래스는 기능적으로 관련된 클래스와 패키지됩니다.

엔티티 또는 제어 클래스와 기능적으로 관련된 필수 경계 클래스는 동일한 인터페이스에 속한 경계 클래스와 함께 별도의 패키지에 배치되어야 합니다.

경계 클래스를 최적의 서비스와 관련된 경우 별도의 서브시스템에서 서비스를 제공하도록 협업하는 클래스와 함께 그룹화하십시오. 서브시스템은 선택적 기능을 주문한 경우 제공되는 선택적 컴포넌트로 맵핑됩니다.

기능적으로 관련된 클래스 패키지

패키지는 기능적으로 관련된 각 클래스 그룹에서 식별되어야 합니다. 두 개의 클래스가 기능적으로 관련되었는지를 판단하는 경우 적용할 수 있는 실제적인 기준이 여러 개 있습니다. 다음은 중요도를 내림차순으로 정렬한 것입니다.

  • 한 클래스의 동작 및/또는 구조를 변경하여 다른 클래스도 변경되는 경우 두 개의 클래스는 기능적으로 관련되어 있습니다.

예제

새 속성이 엔티티 클래스 주문에 추가된 경우 제어 클래스 주문 관리자도 갱신될 가능성이 높습니다. 따라서 동일한 패키지, 주문 처리에 속하게 됩니다.

  • 클래스(예: 엔티티 클래스)를 시작하고 시스템에서 제거할 클래스의 영향을 점검하여 하나의 클래스가 다른 클래스와 기능적으로 관련되었는지 알 수 있습니다. 클래스를 제거한 결과 불필요해진 클래스는 제거된 클래스와 어느 정도 연결되어 있습니다. 여기서 불필요하다는 의미는 이 클래스가 제거된 클래스에서만 사용되거나 제거된 클래스에 종속되어 있음을 뜻합니다.

예제

창고 관리 시스템의 두 개의 제어 클래스, 주문 관리자주문 등록자를 포함하는 주문 처리 패키지가 있습니다. 이 두 제어 클래스는 창고에서 주문 처리와 관련된 서비스를 모델링합니다. 모든 주문 속성 및 관계는 주문 처리에만 있는 엔티티 클래스 주문에서 저장됩니다. 엔티티 클래스를 제거하면 주문 관리자 또는 주문 등록자는 필요하지 않습니다. 이 두 클래스는 주문이 있는 경우에만 유용하기 때문입니다. 따라서 엔티티 클래스 주문은 이 두 제어 클래스와 동일한 패키지에 포함되어야 합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

주문 관리자주문 등록자주문과 동일한 패키지에 속합니다. 주문이 시스템에서 제거되면 불필요해지기 때문입니다.

  • 많은 수의 메시지를 통해 상호작용하거나 그렇지 않으면 복잡한 상호 통신을 사용하는 경우 두 오브젝트를 기능적으로 관련되었을 수 있습니다.

예제

제어 클래스 타스크 수행자운송자 인터페이스에 메시지를 보내거나 해당 인터페이스에서 메시지를 수신합니다. 두 항목이 동일한 패키지, 타스크 처리를 포함해야 함을 다시 한 번 표시합니다.

  • 경계 클래스의 기능이 엔티티 클래스를 표시하는 것이면 경계 클래스는 특정 엔티티 클래스과 기능적으로 관련되었을 수 있습니다.

예제

창고 관리 시스템의 경계 클래스, 화물 운반대 양식은 사용자에게 전체 클래스 화물 운반대의 인스턴스를 표시합니다. 각 화물 운반대는 화면에서 식별 번호로 표시됩니다. 화물 운반대에 대한 정보가 변경되면(예: 화물 운반대의 이름도 지정) 경계 클래스도 변경될 수 있습니다. 따라서 화물 운반대 양식화물 운반대와 동일한 패키지에 포함되어야 합니다.

  • 동일한 액터를 통해 상호작용하거나 변경으로 영향을 받는 경우 두 클래스는 기능적으로 관련되었을 수 있습니다. 두 클래스가 동일한 액터와 관련되지 않은 경우 동일한 패키지에 배치될 수 없습니다. 더 중요한 이유가 있다면 최종 규칙도 무시될 수 있습니다.

예제

창고 관리 시스템에는 다른 항목 중에서 제어 클래스 타스크 수행자를 포함하는 패키지 타스크 수행자가 있습니다. 창고의 화물 운반대를 운송할 수 있는 실제 운송자에 해당하는 액터 운송자와 하나의 패키지만 관련되어 있습니다. 액터는 경계 클래스 운송자 인터페이스를 통해 제어 클래스 타스크 수행자와 상호작용합니다. 따라서 이 경계 클래스는 패키지 타스크 처리에 포함되어야 합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

운송자 인터페이스타스크 수행자 모두 운송자 액터의 변경으로 영향을 받으므로 동일한 패키지에 속합니다.

  • 연관, 집계 등과 같이 서로 관련이 있는 경우 두 클래스는 기능적으로 관련되었을 수 있습니다. 물론 함부로 이 기준에 따를 수는 없지만 적용 가능한 다른 기준이 없는 경우 사용할 수 있습니다.
  • 한 클래스는 해당 인스턴스를 작성한 클래스와 기능적으로 관련되었을 수 있습니다.

다음 두 기준은 두 클래스를 동일한 패키지에 배치할 수 없는 경우를 판별합니다.

  • 다른 액터와 관련된 두 클래스는 동일한 패키지에 배치할 수 없습니다.
  • 선택적 클래스 및 필수 클래스는 동일한 패키지에 배치할 수 없습니다.

패키지 응집 평가

먼저 패키지의 모든 요소는 선택사항이 동일해야 합니다. 즉, 필수 패키지에 선택적 모델 요소는 있을 수 없습니다.

예제

필수 엔티티 클래스 항목 유형에는 무엇보다 보충 임계값과 같은 속성이 있습니다. 그러나 보충 기능은 시스템에서 선택적입니다. 따라서 항목은 두 개의 엔티티 클래스로 분할되어야 합니다. 여기서 선택적 클래스가 필수 클래스와 관련됩니다.

필수로 간주되는 패키지는 선택사항으로 간주된 패키지에 종속되지 않을 수도 있습니다.

규칙에 따라, 단일 패키지는 두 개의 다른 액터에서 사용될 수 없습니다. 이 이유 때문에 한 액터의 동작이 변경되어도 다른 액터에는 영향을 주지 않습니다. 이 규칙에서는 예외가 있습니다. 예를 들어 패키지가 선택적 서비스를 구성합니다. 이 패키지 유형은 패키지를 사용하는 액터 수에 상관없이 분할할 수 없습니다. 따라서 패키지가 선택사항이 아닌 경우 여러 액터에서 사용하는 패키지 또는 클래스를 분할하십시오.

동일한 패키지에 있는 모든 클래스를 기능적으로 관련되어야 합니다. "기능적으로 관련된 클래스에서 패키지 찾기" 섹션의 기준에 따르는 경우 한 패키지의 클래스는 다른 크래스와 기능적으로 관련됩니다. 그러나 특정 클래스가 "너무 많은" 동작 또는 클래스에 속하지 않은 관계를 포함할 수 있습니다. 그러면 클래스 파트를 제거하여 완전히 새로운 클래스 또는 다른 패키지에 속하는 다른 클래스로 만들어야 합니다.

예제

한 패키지에 있는 제어 클래스 A의 동작은 다른 패키지에 있는 클래스 B에 지나치게 종속되어서는 안됩니다. B 특정 동작을 분리하려면 제어 클래스 AA'A"와 같이 두 개의 제어 클래스로 분할해야 합니다. B 특정 동작은 동일한 패키지 B에 있는 새 제어 클래스 A"에 배치됩니다. 새 클래스 A"A'에 대해 일반화와 같은 관계를 확보합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

B 특정 동작을 분리하기 위해 동종성이 결여된 제어 클래스 AA'A"와 같이 두 개의 제어 클래스로 분할합니다.

패키지 종속성 설명

한 패키지에 있는 클래스가 다른 패키지에 있는 클래스와 연관된 경우 이 패키지는 서로 종속되어 있습니다. 패키지 종속성은 패키지 사이의 종속성 관계를 사용하여 모델링되니다. 종속성 관계는 변화의 결과를 평가하는 데 도움이 됩니다. 많은 패키지가 종속된 패키지는 종속된 패키지가 없는 패키지보다 변경하기 더 어렵습니다.

패키지 스펙 중 이와 같이 여러 종속성이 발견되므로 이 관계는 작업 중 변경되어야 합니다. 종속성 관계에 대한 설명은 종속성을 야기하는 클래스 관계에 대한 정보를 포함할 수 있습니다. 이렇게 하면 유지보수하기 어려운 정보가 도입되므로 정보가 적절하고 중요한 경우에만 이를 수행해야 합니다.

예제

창고 관리 시스템에는 패키지 주문 처리부터 패키지 항목 처리 사이의 종속성 관계가 있습니다. 주문 처리의 엔티티 클래스 주문이 다른 패키지의 엔티티 클래스 항목 유형과 연관되었으므로 이 연관이 발생합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

패키지 주문 처리항목 처리에 종속되어 있습니다. 패키지에서 두 클래스가 서로 연관되었기 때문입니다.

패키지 결합 평가

패키지 결합에는 장점과 단점이 있습니다. 장점은 결합을 통해 다시 사용할 수 있다는 점이고 단점은 결합으로 시스템 변경 및 전개가 더 어려워졌다는 점입니다. 다음과 같이 몇 가지 일반 원리에 따를 수 있습니다.

  • 패키지는 교차 결합(즉, 상호 종속)될 수 없습니다. 예를 들어 두 개의 패키지는 서로 종속될 수 없습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

이 경우 패키지는 교차 종속성을 제거하여 재구성해야 합니다.

  • 하위 계층의 패키지는 상위 계층의 패키지에 종속될 수 없습니다. 패키지는 동일한 계층의 서브시스템 및 다음 하위 계층에 있는 패키지에만 종속될 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

이 경우 기능을 다시 파티션해야 합니다. 한 가지 솔루션은 인터페이스 관점에서 종속성을 진술하고 하위 계층에서 인터페이스를 구성하는 것입니다.

  • 일반적으로 종속성은 종속된 행동이 모든 계층에서 공통적이지 않으면 계층을 건너뛸 수 없습니다. 대안으로 계층에서 오퍼레이션 호출을 단순히 통과하는 방법이 있습니다.
  • 패키지는 서브시스템, 오직 다른 패키지 또는 인터페이스에 종속될 수 없습니다.