가이드라인: 분석 클래스
경계, 제어 및 엔티티의 세 가지 분석 클래스 스테레오타입이 있습니다. 이 가이드라인은 해당 의미와 사용법에 대해 설명합니다.
관계
기본 설명

분석 클래스 스테레오타입

분석 클래스의 스테레오타입은 다음 중 하나로 지정될 수 있습니다.

  • 경계 클래스
  • 제어 클래스
  • 엔티티 클래스

클래스를 찾기 위해 보다 특정한 프로세스 안내를 제공하는 것과는 별개로, 이 스테레오타입을 사용하면 모델에서 변경된 사항이 특정 영역에만 영향을 주므로 오브젝트 모델이 견고하게 됩니다. 예를 들어 사용자 인터페이스에서 변경한 사항은 경계 클래스에만 영향을 줍니다. 제어 플로우에서 변경한 사항은 제어 클래스에만 영향을 줍니다. 장기 정보에서 변경한 사항은 엔티티 클래스에만 영향을 줍니다. 그러나 이 스테레오타입은 분석 및 초기 디자인에서 클래스를 식별하는 데 특히 유용합니다. 구현 환경, 응용프로그램 유형 등과 더 잘 상관시키기 위해 디자인의 후반 단계에서 조금 다른 스테레오타입 세트 사용을 고려해야 할 수도 있습니다.

경계 클래스 경계 클래스 아이콘

경계 클래스는 시스템 환경 및 해당 내부 작업 간 상호 작용을 모델링하는 데 사용하는 클래스입니다. 이 상호 작용은 이벤트의 변형 및 변환과 시스템 표시(인터페이스)에서의 변경 기록과 관련이 있습니다.

경계 클래스는 환경에 종속된 시스템 파트를 모델링합니다. 엔티티 클래스 및 제어 클래스는 시스템 환경과는 독립된 파트를 모델링합니다. 따라서 GUI 또는 통신 프로토콜 변경은 엔티티 및 제어 클래스가 아닌 경계 클래스만 변경하는 것을 의미합니다.

또한 경계 클래스는 시스템 경계를 명확히 하기 때문에 시스템을 이해하기 쉽게 해줍니다. 관련 서비스 식별의 좋은 시작점을 제공하여 디자인을 지원합니다. 예를 들어 디자인 초반에 프린터 인터페이스를 식별한 경우 인쇄 형식도 모델링해야 한다는 사실을 곧 알게 됩니다.

공통 경계 클래스로는 창, 통신 프로토콜, 프린터 인터페이스, 센서 및 터미널이 있습니다. 일반적인 인터페이스 파트(예: 단추)를 별도의 경계 클래스로 모델링하지 않아도 됩니다. 일반적으로 전체 창이 가장 세분화된 경계 오브젝트입니다. 경계 클래스는 비객체 지향 API(예: 레거시 코드)에 대한 인터페이스를 캡처하는 경우에도 유용합니다.

표시하는 경계 유형에 따라 경계 클래스를 모델링해야 합니다. 다른 시스템과 통신하고 휴먼 액터와 통신(사용자 인터페이스를 통해)하는 작업은 매우 어려운 목표입니다. 휴먼 액터와 통신하는 경우 가장 중요한 관심사항은 사용자에게 인터페이스를 표시하는 방법입니다. 다른 시스템과 통신하는 경우 가장 중요한 관심사항은 통신 프로토콜입니다.

예를 들어 두 개의 유스 케이스 성능 사이에서 하나의 유스 케이스 인스턴스가 화면에 나타나야 하는 경우 경계 오브젝트(경계 클래스의 인스턴스)는 해당 유스 케이스 인스턴스보다 수명이 더 길 수 있습니다. 그러나 보통 경계 오브젝트는 유스 케이스 인스턴스와 수명이 비슷합니다.

경계 클래스 찾기

경계 클래스는 인터페이스를 시스템 외부에 있는 항목과 매개합니다. 경계 오브젝트는 나머지 시스템이 변경으로부터 영향을 받지 않도록 보호하면서 주변 환경에서의 변경(다른 시스템에 대한 인터페이스 변경, 사용자 요구사항의 변경 등)으로부터 시스템을 분리합니다.

시스템에는 다음과 같은 여러 유형의 경계 클래스가 있을 수 있습니다.

  • 사용자 인터페이스 클래스 - 시스템의 사용자(사람)와의 통신을 매개하는 클래스
  • 시스템 인터페이스 클래스 - 기타 시스템과의 통신을 매개하는 클래스
  • 장치 인터페이스 클래스 - 센서와 같이, 외부 이벤트에서 발견한 장치에 대한 인터페이스를 제공하는 클래스
사용자 인터페이스 클래스 찾기

각 유스 케이스 액터 쌍에 하나의 경계 클래스를 정의하십시오. 이 클래스는 액터와의 상호 작용을 조정할 책임이 있는 클래스로 표시될 수 있습니다. 또한 기본 경계 클래스가 책임 일부를 위임하는 보조 클래스를 표시하도록 추가 경계 클래스를 정의할 수도 있습니다. 특히 창 기반 GUI 응용프로그램인 경우에 그렇습니다. 이 경우 각 창 또는 각 양식에 대해 하나의 경계 오브젝트를 모델링할 수 있습니다. 시스템의 핵심 추상만 모델링하십시오. GUI의 모든 단추, 목록 및 위지트(widget)를 모델링하지 마십시오. 분석의 목적은 최신 세부사항을 모두 디자인하는 것이 아니라 시스템의 구성 방법에 대한 좋은 그림을 구성하는 것입니다. 즉, 분석 유스 케이스 실현의 이벤트 플로우에서 언급한 사항 또는 시스템에서 발생한 현상에 대해서만 경계 클래스를 식별하십시오.

경계 클래스의 동작 및 모양을 보여주는 사용자 인터페이스 프로토타입에서 화면 덤프를 사용하거나 스케치를 하십시오.

시스템 인터페이스 클래스 찾기

외부 시스템과 통신하는 경계 클래스는 외부 시스템과의 대화를 관리할 책임이 있습니다. 경계 클래스는 빌드할 시스템에서 사용할 시스템에 대한 인터페이스를 제공합니다.

예제

현금 자동 인출기(ATM)에서, 잔고 인출은 ATM 네트워크 액터를 통해 검증되어야 합니다(그 다음 은행 계정 시스템에서 인출을 검증함). ATM 네트워크 인터페이스라고 하는 오브젝트를 식별하여 ATM 네트워크와의 통신을 제공할 수 있습니다.

기존 시스템에 대한 인터페이스는 이미 잘 정의되어 있을 수 있습니다. 잘 정의된 경우 책임은 인터페이스 정의에서 직접 파생되어야 합니다. 정규 인터페이스 정의가 있는 경우 리버스 엔지니어링일 수 있으므로 여기서 정식으로 정의하지 않아도 됩니다. 단순히 디자인 중에 기존 인터페이스를 재사용하게 됨을 기록하십시오.

장치 인터페이스 클래스 찾기

시스템은 센서 장비와 같이 외부에 있는 요소처럼 작동(시스템의 어떤 오브젝트도 요소에 영향을 주지 않으며 자발적으로 값이 변경됨)하는 요소를 포함할 수 있습니다. 이 외부 장치 유형을 액터를 사용하여 표시할 수도 있지만 장치와 휴먼 액터를 동일한 "레벨"에 두려는 경향이 있으므로 시스템 사용자는 이 상황을 "혼란스럽다"고 생각할 수 있습니다. 그러나 요구사항 수집에서 벗어나면 모든 외부 이벤트의 소스를 고려해야 하며 시스템에서 이 이벤트를 발견하는 방법이 가지도록 해야 합니다.

장치가 유스 케이스 모델에서 액터로 표시되는 경우 장치 및 시스템 사이의 통신을 매개하는데 경계 클래스를 사용하는 것을 입증할 수 있습니다. 유스 케이스 모델에 이 "장치-액터"가 포함되지 않은 경우, 지금이 적절한 위치의 유스 케이스 보충 설명을 갱신하여 추가할 시점입니다.

각 "장치-액터"에서 경계 클래스를 작성하여 장치 또는 센서의 책임을 캡처하십시오. 장치에 이미 잘 정의된 인터페이스가 있는 경우 이후 디자인 중에 참조할 수 있도록 해당 인터페이스를 기록해 두십시오.

제어 클래스 제어 클래스 아이콘

제어 클래스는 하나 이상의 유스 케이스에 특정한 제어 동작을 모델링하는 데 사용되는 클래스입니다. 제어 오브젝트(제어 클래스의 인스턴스)는 종종 다른 오브젝트를 제어하므로 해당 동작은 조정 유형입니다. 제어 클래스는 유스 케이스 특정 동작을 캡슐화합니다.

제어 오브젝트의 동작은 특정 유스 케이스의 실현과 밀접한 관련이 있습니다. 많은 시나리오에서 제어 오브젝트가 분석 유스 케이스 실현을 "실행"한다고 말할 수도 있습니다. 그러나 일부 제어 오브젝트는 유스 케이스 타스크가 밀접하게 관련된 경우 둘 이상의 분석 유스 케이스 실현에 참여할 수 있습니다. 또한 서로 다른 제어 클래스의 여러 제어 오브젝트가 하나의 유스 케이스에 참여할 수 있습니다. 모든 유스 케이스에 제어 오브젝트가 필요한 것은 아닙니다. 예를 들어 유스 케이스의 이벤트 플로우가 하나의 엔티티 오브젝트와 관련된 경우 경계 오브젝트가 엔티티 오브젝트와 함께 협업하여 유스 케이스를 실현할 수 있습니다. 분석 유스 케이스 실현마다 하나의 제어 클래스를 식별하여 시작한 후 추가 분석 유스 케이스 실현을 식별하고 공통성을 발견하면서 해당 제어 클래스를 정제할 수 있습니다.

제어 클래스는 기본 타스크 및 제어 플로우를 처리하면서 시스템의 역학을 표시하므로 시스템을 이해하는 데 도움을 줄 수 있습니다.

시스템에서 유스 케이스를 수행하면 제어 오브젝트가 작성됩니다. 일반적으로 제어 오브젝트는 해당 유스 케이스를 수행하면 제거됩니다.

제어 클래스가 유스 케이스에 필요한 모든 사항을 처리하지는 않음에 유의하십시오. 대신 기능성을 구현하는 기타 오브젝트의 타스크를 조정합니다. 제어 클래스는 기능성에 대한 책임이 지정된 오브젝트에 작업을 위임합니다.

제어 클래스 찾기

제어 클래스는 시스템에서 조정 동작을 제공합니다. 시스템은 제어 오브젝트 없이도(엔티티 및 경계 오브젝트만 사용) 일부 유스 케이스를 수행할 수 있습니다. 특히 저장된 정보의 단순 조작에만 관련된 유스 케이스가 이에 해당합니다.

일반적으로 보다 복잡한 유스 케이스는 시스템의 기타 오브젝트 동작을 조정하는 데 하나 이상의 제어 클래스가 필요합니다. 제어 오브젝트의 예로는 트랜잭션 관리자, 자원 조정자 및 오류 핸들러와 같은 프로그램이 있습니다.

제어 클래스는 경계 및 엔티티 오브젝트를 효과적으로 분리하여, 시스템에서 시스템 경계에 발생한 변경을 더 많이 허용할 수 있게 합니다. 또한 엔티티 오브젝트에서 유스 케이스 특정 동작을 분리하여, 유스 케이스 및 시스템에서 이를 더 많이 재사용할 수 있게 합니다.

제어 클래스는 다음과 같은 동작을 제공합니다.

  • 환경에 독립적인 동작(환경이 변경되어도 변경되지 않음)
  • 유스 케이스에서 트랜잭션 및 제어 로직(이벤트 간 순서)을 정의하는 동작
  • 엔티티 클래스의 내부 구조 또는 동작이 변경되어도 거의 변경되지 않는 동작
  • 여러 엔티티 클래스의 컨텐츠를 사용하거나 설정하므로 이들 엔티티 클래스의 동작을 조정해야 하는 동작
  • 활성화될 때마다 동일한 방식으로 수행되지 않는 동작(이벤트 플로우가 여러 상태를 가짐)
제어 클래스가 필요한지 판별

유스 케이스의 이벤트 플로우에서는 다른 타스크를 수행하는 순서를 정의합니다. 이미 식별된 경계 및 엔티티 클래스에서 플로우를 처리할 수 있는지 조사하는 것부터 시작하십시오. 주로 정보를 입력, 검색 및 표시 또는 수정하는 단순한 이벤트 플로우의 경우 일반적으로 별도의 제어 클래스를 필요로 하지 않습니다. 이 경우 경계 클래스에 유스 케이스를 조정할 책임이 있습니다.

이벤트 플로우가 복잡하고 시스템의 정보 저장소(엔티티 클래스) 또는 인터페이스(경계 클래스)와는 독립적으로 변경될 수 있는 동적 동작으로 구성된 경우, 이벤트 플로우를 별도의 제어 클래스에 캡슐화해야 합니다. 이벤트 플로우를 캡슐화하면 다른 인터페이스 및 다른 정보 저장소(또는 최소한 기본 데이터 구조)를 가질 수 있는 다양한 시스템에서 잠재적으로 동일한 제어 클래스를 재사용할 수 있습니다.

예제: 타스크 대기열 관리

창고 관리 시스템의 타스크 수행 유스 케이스에서 제어 클래스를 식별할 수 있습니다. 이 제어 클래스는 타스크 대기열을 처리하여 타스크가 올바른 순서대로 수행되도록 합니다. 적합한 운송 수단이 할당되면 바로 대기열에서 다음 타스크를 수행합니다. 따라서 시스템은 동시에 여러 타스크를 수행할 수 있습니다.

타스크 수행자 및 대기열 처리자와 같이 두 개의 제어 클래스로 분할한 경우 해당 제어 오브젝트에서 정의한 동작을 쉽게 설명할 수 있습니다. 대기열 처리자 오브젝트는 대기열 주문 및 운송 수단의 할당만 처리합니다. 전체 대기열에서 하나의 대기열 처리자 오브젝트가 필요합니다. 시스템에서 타스크를 수행하면 바로 새 타스크 수행자 오브젝트를 작성하여 타스크를 수행합니다. 따라서 시스템이 수행하는 각 타스크에 하나의 타스크 수행자 오브젝트가 필요합니다.

"너무 복잡한" 클래스는 책임이 서로 일관되고 관련된 클래스로 분할되어야 합니다.

복잡한 클래스를 책임의 유사 정도에 따라 구분

이 분할 작업의 기본 이점은 이 유스 케이스에 특정한 타스크 관리의 특정 타스크에서 대기열 처리 책임(많은 유스 케이스에서 일반적인 사항)을 분리한다는 점입니다. 그러면 클래스를 쉽게 이해할 수 있고 디자인이 성숙해감에 따라 쉽게 적응할 수 있습니다. 또한 워크로드를 처리하는 데 필요한 만큼 많은 타스크 수행자를 작성할 수 있으므로 시스템 로드의 밸런스를 조절하는 이점이 있습니다.

별도 제어 클래스에 있는 기본 이벤트 플로우 및 대체/예외 이벤트 플로우의 캡슐화

변경을 단순화하려면 다른 제어 클래스에 있는 기본 이벤트 플로우 및 대체 이벤트 플로우를 캡슐화하십시오. 대체 및 예외 플로우가 서로 완전히 독립적인 경우 서로 분리하십시오. 그러면 시간에 따라 시스템을 쉽게 확장 및 유지보수할 수 있습니다.

두 개의 액터가 동일한 제어 클래스를 공유하는 제어 클래스 구분

여러 액터가 동일한 제어 클래스를 사용하는 경우 제어 클래스를 구분해야 할 수도 있습니다. 제어 클래스를 나누면 액터 하나의 요구사항에서 변경된 사항이 나머지 시스템으로부터 분리됩니다. 변경 비용이 많이 들거나 결과가 좋지 않은 경우 둘 이상의 액터와 관련된 모든 제어 클래스를 식별하여 구분해야 합니다. 이상적으로 각 제어 클래스는 하나의 액터와 (일부 경계 오브젝트를 통해) 상호작용하거나 전혀 상호작용하지 않습니다.

예제: 통화 관리

시내 통화 유스 케이스를 고려하십시오. 처음에는 통화 자체를 관리할 제어 클래스를 식별할 수 있습니다.

유스 케이스와 관련된 서로 다른 액터에 별도의 제어 클래스가 필요합니다.

전화 시스템에서 시내 전화 걸기를 처리하는 제어 클래스는 각각 하나의 액터가 관련된 A-동작B-동작과 같은 두 개의 제어 클래스로 바로 나눌 수 있습니다.

시내 전화 걸기에는 전화를 거는 A-가입자 및 전화를 받는 B-가입자와 같이 두 개의 액터가 있습니다. A-가입자는 수화기를 들고 신호음을 들은 후 숫자를 누릅니다. 그러면 시스템에서 해당 숫자를 저장하고 분석합니다. 시스템에서 모든 숫자를 수신하면 A-가입자에게 신호음을 보내고 B-가입자에게 호출음을 보냅니다. B-가입자가 응답을 하면 신호음 및 호출음이 중단되고 가입자 사이에 대화가 시작될 수 있습니다. 전화는 두 가입자가 전화를 끊는 순간 끝납니다.

A-가입자의 위치에서 발생하는 내용과 B-가입자의 위치에서 발생하는 내용, 두 개의 동작을 제어해야 합니다. 따라서 원래 제어 오브젝트는 두 개의 제어 오브젝트, A-동작B-동작으로 분할됩니다.

다음과 같은 경우 제어 클래스를 구분하지 않아도 됩니다.

  • 제어 클래스의 오브젝트와 관련된 액터의 동작이 절대 또는 거의 변경되지 않습니다.
  • 하나의 액터에 대한 제어 클래스의 오브젝트 동작이 다른 액터에 대한 동작에 비해 중요하지 않습니다. 단일 오브젝트에서 모든 동작을 보유할 수 있습니다. 이 방식으로 동작을 결합하면 변경 가능성에는 거의 영향을 주지 않습니다.

엔티티 클래스 엔티티 클래스 아이콘

엔티티 클래스는 저장해야 하는 연관된 동작 및 정보를 모델링할 때 사용되는 클래스입니다. 엔티티 오브젝트(엔티티 클래스의 인스턴스)는 어떤 현상에 대한 정보(예: 이벤트, 사람 또는 일부 실생활 오브젝트)를 보유하고 갱신할 때 사용됩니다. 일반적으로 엔티티 오브젝트는 지속적이며 장기간, 때때로 시스템 수명 동안 필요한 속성 및 관계를 보유합니다.

일반적으로 엔티티 오브젝트는 하나의 분석 유스 케이스 실현에 특정하지 않습니다. 때때로 엔티티 오브젝트는 시스템 자체에도 특정하지 않습니다. 해당 관계 및 속성 값은 종종 액터가 제공합니다. 엔티티 오브젝트는 내부 시스템 타스크 수행을 돕는 데 필요할 수도 있습니다. 엔티티 오브젝트는 기타 오브젝트 스테레오타입의 동작처럼 동작이 복잡할 수 있습니다. 그러나 기타 오브젝트와는 달리 이 동작은 엔티티 오브젝트가 표시하는 현상과 강하게 관련되어 있습니다. 엔티티 오브젝트는 환경(액터)에 독립적입니다.

엔티티 오브젝트는 개발 중인 시스템의 핵심 개념을 표시합니다. 은행 업무 시스템에서 엔티티 클래스의 일반적인 예로는 계정고객이 있습니다. 네트워크 관리 시스템에서의 예로는 노드링크가 있습니다.

모델링하려는 현상을 다른 클래스에서 사용하지 않는 경우 엔티티 클래스의 속성 또는 엔티티 클래스 사이의 관계로도 모델링할 수 있습니다. 반면 디자인 모델의 다른 클래스에서 해당 현상을 사용하는 경우 클래스로 모델링해야 합니다.

엔티티 클래스는 논리적 데이터 구조를 표시하므로 시스템을 이해하는 또 다른 관점을 제공합니다. 따라서 시스템이 사용자에게 제공하려는 내용을 이해하는 데 도움이 될 수 있습니다.

엔티티 클래스 찾기

엔티티 클래스는 시스템의 정보 저장소를 표시합니다. 보통 이는 시스템이 관리하는 핵심 개념을 표시하는데 사용됩니다. 엔티티 오브젝트는 보통 수동적이고 지속적입니다. 기본 책임은 시스템에서 정보를 저장하고 관리하는 것입니다.

엔티티 클래스에 자주 사용되는 소스는 용어집(요구사항 중 개발됨) 및 비즈니스 도메인 모델(비즈니스 모델링을 수행하는 경우 비즈니스 모델링 중 개발됨)입니다.

연관 스테레오타입 사용법 제한사항

경계 클래스의 제한사항

다음이 허용됩니다.

  • 두 개의 경계 클래스 사이의 연관을 통신합니다(예: 특정 창이 다른 경계 오브젝트와 관련된 방법을 설명하기 위해).
  • 경계 클래스에서 엔티티 클래스로의 연관을 통신 또는 등록합니다. 왜냐하면 경계 오브젝트에서 경계 오브젝트의 조치 사이에 있는 특정 엔티티 오브젝트를 추적하거나 엔티티 오브젝트에서 상태 변경을 수신해야 하기 때문입니다.
  • 경계 오브젝트가 특정 동작을 트리거할 수 있도록 경계 클래스에서 제어 클래스로의 연관을 통신합니다.

제어 클래스의 제한사항

다음이 허용됩니다.

  • 제어 클래스에서 엔티티 클래스로의 연관을 통신 또는 등록합니다. 왜냐하면 제어 오브젝트에서 제어 오브젝트의 조치 사이에 있는 특정 엔티티 오브젝트를 추적하거나 엔티티 오브젝트에서 상태 변경을 수신해야 하기 때문입니다.
  • 제어 및 경계 클래스 사이의 연관을 통신합니다. 그러면 호출된 동작의 결과를 환경에 통신할 수 있습니다.
  • 제어 클래스 사이의 연관을 통신합니다. 그러면 보다 복잡한 동작 패턴을 구성할 수 있습니다.

엔티티 클래스의 제한사항

엔티티 클래스는 다른 엔티티 클래스에 대한 연관(통신 또는 등록) 소스여야만 합니다. 엔티티 클래스 오브젝트의 수명은 긴 편이고 제어 및 경계 클래스 오브젝트의 수명은 짧은 편입니다. 아키텍처 시점에서 엔티티 오브젝트가 해당 환경에서 가지고 있는 가시성을 제한하는 것이 합리적입니다. 그러면 시스템을 쉽게 변경할 수 있습니다.

제한사항 요약

시작/종료
(탐색성)

경계

엔티티

제어

경계

통신

통신

등록

통신

엔티티

통신

등록

 

제어

통신

통신

등록

통신

올바른 연관 스테레오타입 조합

일관성 강조

  • 새 동작이 식별된 경우 유사한 책임이 있는 기존 클래스가 있는지 확인하십시오(가능한 경우 클래스 재사용). 동작을 수행할 수 있는 기존 클래스가 없는 경우에만 새 클래스를 작성해야 합니다.
  • 클래스를 식별한 후 책임이 일관되는지 점검하십시오. 클래스 책임이 일관되지 않으면 오브젝트를 두 개 이상의 클래스로 분할하십시오. 이에 따라 상호작용 다이어그램을 갱신하십시오.
  • 일관되지 않는 책임을 발견하여 클래스를 분할한 경우 클래스가 역할을 수행하는 협업을 점검하여 협업을 갱신해야 하는지 확인하십시오. 필요한 경우 협업을 갱신하십시오.
  • 책임이 하나뿐인 클래스는 문제점이 되지 않습니다. 그러나 이 경우 왜 이 클래스가 필요한지에 대한 질문이 제기되어야 합니다. 모든 클래스의 존재 여부를 입증하십시오.