주제

분석 클래스 스테레오타입 페이지 맨 위

분석 클래스의 스테레오타입은 다음 중 하나입니다.

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

클래스를 찾을 때 보다 특정한 프로세스 안내를 제공하는 것과는 별도로 모델에 대한 변경은 특정 영역에만 영향을 미치는 경향이 있기 때문에 이 스테레오타입은 강력한 객체 모델을 생성합니다. 예를 들어, 사용자 인터페이스의 변경사항은 경계 클래스에만 영향을 미칩니다. 제어 플로우의 변경사항은 제어 클래스에만 영향을 미칩니다. 장기 정보의 변경사항은 엔티티 클래스에만 영향을 미칩니다. 그러나 이 스테레오타입은 특히 분석 내의 클래스 및 초기 설계를 식별하는 데 도움이 됩니다. 구현 환경, 어플리케이션 유형 등을 더 잘 연관시키려면, 후반 단계에는 약간 다른 스테레오타입 세트를 사용하는 것을 고려할 수 있습니다.

경계 클래스 경계 클래스 아이콘 페이지 맨 위

경계 클래스는 시스템 환경과 해당 내부 작업 간의 상호 작용을 모델화하는 데 사용되는 클래스입니다. 이러한 상호 작용은 이벤트의 변환 및 변경과 시스템 프리젠테이션(예: 인터페이스)에 변경사항을 기록하는 것을 포함합니다.

경계 클래스는 해당 환경에 의존하는 시스템의 파트를 모델화합니다. 엔티티 클래스 및 제어 클래스는 시스템 환경에 독립적인 파트를 모델화합니다. 따라서 GUI 또는 통신 프로토콜을 변경하는 것은 엔티티 및 제어 클래스는 변경하지 않고 경계 클래스만 변경함을 의미합니다.

경계 클래스는 시스템 경계를 명확히 하기 때문에 시스템을 훨씬 쉽게 이해할 수 있게 합니다. 경계 클래스는 관련 서비스를 식별하기에 좋은 이탈 지점을 제공함으로써 설계를 지원합니다. 예를 들어, 설계 초기에 프린터 인터페이스를 식별할 경우 인쇄물의 포맷도 형식화해야 함을 알게 됩니다.

공통 경계 클래스는 윈도우, 통신 프로토콜, 프린터 인터페이스, 센서 및 단말기를 포함합니다. 단추와 같은 루틴 인터페이스 파트를 별도의 경계 클래스로 모델화해서는 안 됩니다. 일반적으로 전체 원도우는 가장 잘 다듬어진 경계 객체입니다. 경계 클래스는 비객체 지향 API(예: 레거시 코드)에 대한 인터페이스를 캡처하는 데에도 유용합니다.

이들이 표현하는 경계 유형에 따라 경계 클래스도 모델화해야 합니다. 다른 시스템과의 통신 및 사용자 인터페이스를 통한 액터(휴먼)와의 통신은 상당히 다른 목표를 갖고 있습니다. 액터(휴면)과 통신할 경우, 가장 중요한 관심사는 사용자에게 인터페이스를 표시하는 방법입니다. 다른 시스템과 통신할 경우, 가장 중요한 관심사는 통신 프로토콜입니다.

예를 들어, 두 개의 유스 케이스 실행 중간에 화면에 표시해야 할 경우, 경계 객체(경계 클래스 인스턴스)가 유스 케이스 인스턴스보다 수명이 오래 유지될 수 있습니다. 일반적으로, 경계 객체는 유스 케이스 인스턴스만큼만 수명을 유지합니다.

경계 클래스 찾기

경계 클래스는 시스템 외부에 대해 인터페이스를 제공하는 매개체입니다. 경계 객체는 환경 변경(다른 시스템에 대한 변경사항, 사용자 요구사항에 대한 변경사항)으로부터 시스템을 분리하여 이러한 변경사항이 나머지 시스템에 영향을 미치지 않게 합니다.

시스템은 여러 가지 유형의 경계 클래스를 가질 수 있습니다.

  • 사용자 인터페이스 클래스 - 시스템 사용자(휴먼)와 통신을 중개하는 클래스.
  • 시스템 인터페이스 클래스 - 다른 시스템과 통신을 중개하는 클래스.
  • 장치 인터페이스 클래스 - 내부 이벤트를 발견하는 장치(예: 센서)에 대한 인터페이스를 제공하는 클래스.
사용자 인터페이스 클래스 찾기

각 유스 케이스 액터 쌍에 대해 하나의 경계 클래스를 정의하십시오. 이 클래스는 액터와의 상호 작용을 조정할 책임을 갖는다고 볼 수 있습니다. 기본 경계 클래스가 책임 중 일부를 위임할 보조 클래스를 나타내도록 추가 경계 클래스도 정의할 수 있습니다. 이는 특히 윈도우 기반 GUI 어플리케이션에 해당하며, 이 경우 각 윈도우마다 또는 각 양식마다 하나의 경계 객체를 모델화할 수 있습니다. 핵심 추상 시스템만 모델화하십시오. GUI 내의 모든 단추, 목록 및 위지트(widget)는 모델화하지 마십시오. 분석 목적은 모든 최종 세부사항을 설계하는 것이 아니라 시스템 구성 방법을 구성하는 것입니다. 즉, 시스템의 현상 또는 분석 유스 케이스 구현의 이벤트 플로우에서 언급한 것에 대해서만 경계 클래스를 식별하십시오.

경계 클래스의 작동 또는 모습을 표시하려면 스케치를 작성하거나 사용자 인터페이스 프로토타입에서 화면 덤프를 사용하십시오.

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

외부 시스템과 통신하는 경계 클래스는 외부 시스템과의 상호 작용를 관리하는 책임이 있습니다. 이는 시스템이 빌드되도록 해당 시스템에 인터페이스를 제공합니다.

현금 자동 지급기에서 예금 인출은 액터인 ATM 네트워크를 통해 확인되어야 합니다(그 다음에 은행 계좌 시스템에서 인출을 확인합니다). ATM 네트워크와의 통신을 제공하기 위해 ATM 네트워크 인터페이스라고 하는 객체를 식별할 수 있습니다.

기존 시스템에 대한 인터페이스는 이미 잘 정의되어 있습니다. 그럴 경우, 인터페이스 정의로부터 직접 책임을 도출해야 합니다. 공식 인터페이스 정의가 존재할 경우, 역으로 처리되었을 수 있으므로 여기에 공식적으로 정의할 필요는 없습니다. 설계 중에 기존의 인터페이스를 재사용한다는 점을 간단히 기록하십시오.

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

시스템은 센서 장비와 같이 외부에 있는 것처럼 작동하는 요소를 포함할 수 있습니다(시스템에 이들에게 영향을 미치는 객체 없이 자발적으로 값을 변경함). 액터를 사용하여 이러한 유형을 가진 외부 장치를 표현할 수는 있지만, 시스템 사용자는 시스템이 이렇게 하는 것이 "혼란"스럽다는 것을 알게 됩니다. 왜냐하면 시스템은 장치와 액터(휴먼)를 동일한 "레벨"로 놓는 경향이 있기 때문입니다. 그러나 일단 요구사항 수집을 하지 않게 되면, 모든 외부 이벤트에 대한 소스를 고려하여 시스템이 이러한 이벤트를 발견할 방법이 있는지를 확인해야 합니다.

유스 케이스 모델에서 장치를 액터로 표시할 경우, 장치와 시스템 간의 통신 매개체 역할을 하도록 경계 클래스를 사용하는 것을 정당화하는 것이 쉽습니다. 유스 케이스 모델이 이러한 "장치-액터"를 포함하지 않을 경우, 지금이 유스 케이스의 추가 설명을 갱신하여(적절한 경우) 이를 추가할 적절한 시기입니다.

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

제어 클래스 제어 클래스 아이콘 페이지 맨 위

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

제어 객체의 작동은 특정 유스 케이스의 구현과 밀접하게 관련되어 있습니다. 여러 시나리오에서 제어 객체가 분석 유스 케이스 구현을 "실행"한다고 볼 수 있습니다. 그러나 유스 케이스 타스크가 밀접하게 관련된 경우 일부 제어 객체는 둘 이상의 유스 케이스 구현에 관련될 수 있습니다. 게다가 다른 제어 클래스의 여러 제어 객체는 하나의 유스 케이스에 관련될 수 있습니다. 모든 유스 케이스에 제어 객체가 필요한 것이 아닙니다. 예를 들어, 유스 케이스의 이벤트 플로우가 한 엔티티 객체에 관련되어 있는 경우 경계 객체는 엔티티 객체와 협력하여 유스 케이스를 구현할 수 있습니다. 더 많은 분석 유스 케이스 구현이 식별되어 공통성이 발견되므로 분석 유스 케이스 구현당 하나의 제어 클래스를 식별하는 것부터 시작한 다음 이를 정제할 수 있습니다.

제어 클래스는 시스템의 역학, 기본 타스크 및 제어 플로우 처리를 나타내기 때문에 시스템을 이해하는 데 도움이 됩니다.

시스템이 유스 케이스를 수행할 때 제어 객체가 작성됩니다. 제어 객체는 일반적으로 해당 유스 케이스를 수행할 때 소멸됩니다.

제어 클래스는 유스 케이스에 필요한 모든 것을 처리하지는 않습니다. 대신, 이는 기능을 구현하는 다른 객체의 활동을 조정합니다. 제어 클래스는 기능에 대한 책임이 지정된 객체에게 작업을 위임합니다.

제어 클래스 찾기

제어 클래스는 시스템의 조정 작동을 제공합니다. 시스템은 제어 객체 없이(엔티티 및 경계 개체만을 사용하여) 일부 유스 케이스(특히 저장된 정보를 간단히 조작하는 것만 포함하는 유스 케이스)를 수행할 수 있습니다.

시스템의 다른 객체의 작동을 조정하려면 좀더 복잡한 유스 케이스에는 일반적으로 하나 이상의 제어 클래스가 필요합니다. 제어 객체의 예에는 트랜잭션 관리자, 자원 조정자 및 오류 핸들러와 같은 프로그램이 포함됩니다.

제어 클래스는 효율적으로 경계 및 엔티티 객체를 분리하여 시스템이 시스템 경계 내에서의 변경사항을 수용하게 합니다. 제어 클래스는 엔티티 객체로부터 유스 케이스 특정 작동을 분리하여 유스 케이스 및 시스템 간에 재사용을 더 늘릴 수 있게 합니다.

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

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

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

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

예: 타스크 큐 관리

저장소 핸들링 시스템의 타스크 수행 유스 케이스로부터 제어 클래스를 식별할 수 있습니다. 이 제어 클래스는 타스크 큐를 처리하여 타스크가 올바른 순서로 수행되게 합니다. 이는 적절한 전송 장비가 할당되는 즉시 큐의 다음 타스크를 수행합니다. 그러므로 시스템은 동시에 여러 타스크를 수행할 수 있습니다.

해당 제어 객체에 의해 정의된 작동을 두 개의 제어 클래스(타스크 수행자 및 큐 핸들러)로 나누면 기술하기가 훨씬 쉽습니다. 큐 핸들러 객체는 큐 순서 및 전송 장비의 할당만을 처리합니다. 전체 큐에 대해 하나의 큐 핸들러 객체가 필요합니다. 시스템은 타스크를 수행하자 마자 타스크를 수행하는 새로운 타스크 수행자 객체를 작성합니다. 그러므로 시스템이 수행하는 각 타스크마다 하나의 타스크 수행자 객체가 필요합니다.

"너무 복잡한" 클래스는 일치하고 관련된 책임을 가진 클래스로 나누어야 함

복잡한 클래스는 유사한 책임선을 따라 분할해야 합니다.

이렇게 나누는 기본적인 장점은 이 유스 케이스에 특정한 특정 타스크 관리 활동으로부터 큐 핸들링 책임(여러 유스 케이스에 공통적인 것)을 분리한다는 것입니다. 이렇게 하면 설계가 완성됨에 클래스를 이해하기도 더 쉽고 채택하기도 더 쉬워집니다. 워크로드를 처리하는 데 필요한 여러 타스크 수행자를 마음대로 작성할 수 있으므로 시스템의 로드 밸런스를 유지하는 데도 도움이 됩니다.

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

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

두 액터가 동일한 제어 클래스를 공유할 경우 제어 클래스 분할

여러 액터가 동일한 제어 클래스를 사용할 경우 제어 클래스를 분할해야 할 수 있습니다. 이를 수행함으로써 한 액터에서 발생한 변경사항을 시스템의 다른 액터로부터 분리할 수 있습니다. 변경 비용이 많이 들거나 결과가 좋지 않은 경우, 둘 이상의 액터에 관련된 모든 제어 클래스를 식별하여 이를 분할해야 합니다. 이상적인 경우, 각 제어 클래스는 한 액터와 상호 작용하거나(일부 경계 객체를 통해) 어떤 액터와도 상호 작용하지 말아야 합니다.

예제: 호출 관리

유스 케이스 로컬 호출을 고려하십시오. 초기에 제어 클래스를 식별하여 호출 자체를 관리할 수 있습니다.

여러 객체가 하나의 유스 케이스에 포함되어 있으면 별도의 제어 클래스가 필요함

전화 시스템에서 시외 통화를 처리하는 제어 클래스를 포함된 액터에 각각 하나씩, 두 개의 제어 클래스(A 작동B 작동)로 신속하게 나눌 수 있습니다.

시외 통화에는 두 개의 액터(통화를 시작하는 A 가입자와 전화를 받는 B 가입자)가 있습니다. A 가입자는 수신기를 들고 발신음을 들은 다음, 시스템이 저장하여 분석하는 숫자를 누릅니다. 시스템이 모든 숫자를 수신하면 A 가입자에게는 벨 소리를, B 가입자에게는 호출 신호를 전송합니다. B 가입자가 응답하면 발신음과 신호가 중단되고 가입자 간의 상호 작용가 시작됩니다. 두 가입자가 전화를 끊으면 호출이 완료됩니다.

두 작동에서 A 가입자 위치에서 발생하는 일과 B 가입자 위치에서 발생하는 일을 제어해야 합니다. 이러한 이유로 본래의 제어 객체를 두 개의 제어 객체(A 작동B 작동)로 나눕니다.

다음과 같은 경우에는 제어 클래스를 나누어서는 안됩니다.

  • 제어 클래스의 객체에 연관된 액터의 작동이 절대 변경되지 않거나 거의 변경되지 않는다는 것을 확신할 수 있는 경우.
  • 한 액터에 대한 제어 클래스 객체의 작동이 다른 액테에 대한 작동에 비해 훨씬 덜 중요하고 하나의 객체가 모든 작동을 보유할 수 있는 경우. 이런 방법으로 작동을 결합하면 가변성에 큰 영향을 미치지 않습니다.

엔티티 클래스 엔티티 클래스 아이콘 페이지 맨 위

엔티티 클래스는 저장해야 하는 정보 및 관련 작동을 모델화하는 데 사용되는 클래스입니다. 엔티티 객체(엔티티 클래스 인스턴스)는 이벤트, 개인 또는 동일한 실존 객체에 대한 정보를 보유 및 갱신하는 데 사용됩니다. 엔티티 객체는 일반적으로 지속적이고 장기간(종종 시스템의 일생 동안) 필요한 속성 및 관계를 갖고 있습니다.

엔티티 객체는 일반적으로 하나의 분석 유스 케이스 구현에 국한되지 않습니다. 종종 엔티티 객체는 시스템 자체에도 국한되지 않습니다. 속성 및 관계의 값은 종종 액터에 의해 제공됩니다. 엔티티 객체는 내부 시스템 타스크 수행을 지원하는 데 필요할 수 있습니다. 엔티티 객체는 다른 객체 스테레오타입의 작동과 마찬가지로 복잡한 작동을 가질 수 있습니다. 그러나 다른 객체와 달리 이 작동은 엔티티 객체가 나타내는 현상과 밀접하게 관련되어 있습니다. 엔티티 객체는 환경(액터)에 독립적입니다.

엔티티 객체는 개발 중인 시스템의 핵심 개념을 나타냅니다. 은행 시스템의 엔티티 클래스에 대한 일반적인 예제로는 계정고객이 있습니다. 네트워크 핸들링 시스템에서의 예제로는 노드링크가 있습니다.

모델화하려는 현상을 다른 클래스에서는 사용하지 않을 경우, 이를 엔티티 클래스의 속성으로 또는 엔티티 클래스 간의 관계로서 모델화할 수 있습니다. 한편, 다른 클래스에서 현상을 사용할 경우에는 이를 클래스로 모델화해야 합니다.

엔티티 클래스는 시스템이 사용자에게 제공하려고 하는 내용을 이해할 수 있게 도와주는 논리적 데이터 구조를 표시하기 때문에 시스템을 이해할 수 있는 또다른 관점을 제공합니다.

엔티티 클래스 찾기

엔티티 클래스는 시스템 내의 정보 저장소를 나타냅니다. 엔티티 클래스는 일반적으로 시스템이 관리하는 핵심 개념을 나타내는 데 사용됩니다. 엔티티 객체는 주로 수동적이며 지속적입니다. 엔티티 객체의 기본 책임은 시스템에 정보를 저장하고 관리하는 것입니다.

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

연관 스테레오타입 사용법 제한사항 페이지 맨 위

경계 클래스에 대한 제한사항 페이지 맨 위

다음 사항이 허용됩니다.

  • 두 경계 클래스 간의 연관을 전달하십시오(예: 특정 창과 다른 경계 객체를 연관시키는 방법 설명).
  • 경계 클래스에서 엔티티 클래스로의 연관을 전달하거나 등록하십시오. 이는 경계 객체가 경계 객체 내에 있는 조치 간의 특정 엔티티 객체를 추적해야하거나, 엔티티 객체의 상태 변경을 알려줘야하기 때문입니다.
  • 경계 클래스에서 제어 클래스로 연관을 전달하십시오. 따라서 경계 객체는 특정 작동을 유발할 수 있습니다.

제어 클래스에 대한 제한사항 페이지 맨 위

다음 사항이 허용됩니다.

  • 제어 클래스 및 엔티티 클래스 간의 연관을 전달하거나 등록하십시오. 이는 제어 객체가 제어 객체 내에 있는 조치 간의 특정 엔티티 객체를 추적해야하거나, 엔티티 객체의 상태 변경을 알려줘야하기 때문입니다.
  • 호출된 작동의 결과를 환경에 전달할 수 있도록 제어 및 경계 클래스 간의 연관을 전달하십시오.
  • 좀더 복잡한 작동 패턴을 구축할 수 있도록 제어 클래스 간의 연관을 전달하십시오.

엔티티 클래스에 대한 제한사항 페이지 맨 위

엔티티 클래스는 다른 엔티티 클래스에 대한 연관(통신 또는 등록) 소스이어야 합니다. 엔티티 클래스 객체는 비교적 수명이 길지만 제어 및 경계 클래스는 수명이 비교적 짧습니다. 구조적 관점에서 엔티티 객체가 환경에 대해 갖고 있는 가시성을 제한하는 것이 좋습니다. 그렇게 하면 시스템을 더 쉽게 변경할 수 있습니다.

제한사항 요약사항 페이지 맨 위

시작\끝
(탐색성)

경계

엔티티

제어

경계

통신

통신

가입자

통신

엔티티

통신

가입자

 

제어

통신

통신

가입

통신

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

강제로 일관성 유지페이지 맨 위

  • 새 작동이 식별된 경우, 클래스를 재사용하며 유사한 책임을 갖는 기존의 클래스가 있는지 확인하십시오. 작동을 수행할 수 있는 기존의 객체가 없는 경우에만 새 클래스를 작성하십시오.
  • 클래스가 식별되면 이를 검토하여 책임이 일치하는지 확인하십시오. 클래스 책임이 일치하지 않을 경우, 객체를 두 개 이상의 클래스로 나누십시오. 이에 따라 상호 작용 다이어그램도 갱신하십시오.
  • 분리된 책임이 발견되어 클래스를 나눌 경우, 클래스가 역할을 수행하는 협력을 검토하여 협력 요구사항을 갱신해야 하는지 여부를 판별하십시오. 필요한 경우 협력을 갱신하십시오.
  • 하나의 책임만을 가진 클래스는 별 문제는 아니지만 이 클래스가 필요한 이유에 대해 의문을 제기해야 합니다. 존재하는 모든 클래스를 조사하여 타당성을 입증할 준비를 하십시오.


Rational Unified Process   2003.06.15