주제

정의페이지 맨 위

설계 클래스는 시스템 구현의 하나 또는 여러 클래스를 요약한 것입니다(정확히 구현 언어에 의존해 상응하는 것이 무엇인지). 예를 들어, C++와 같은 객체 지향 언어에서 클래스는 일반 클래스에 해당할 수 있습니다. 또는 Ada에서 클래스는 패키지의 가시적 부분에 정의되어 있는 태그화된 유형에 해당할 수 있습니다.

클래스는 유스 케이스를 실현(구현)할 수 있는 객체를 정의합니다. 클래스는 유스 케이스 구현이 시스템에 필요한 객체에 대해 요구한 사항과 이전에 개발한 객체 모델로부터 발생할 수 있습니다.

클래스가 좋은지 좋지 않은지 여부는 구현 환경에 따라 많이 다릅니다. 클래스 및 해당 객체의 적절한 크기는 프로그램 언어에 따라 많이 다릅니다. 예를 들어 다음과 같습니다. Ada를 사용할 때 고려한 것이 Smalltalk를 사용할 때에는 올바르지 않을 수 있습니다. 클래스는 구현 언어의 특정 현상에 해당하며 맵핑이 좋은 코드를 생성하도록 클래스를 구성해야 합니다.

구현 언어의 특징이 설계 모델에 영향을 미칠 수도 있지만 클래스 구조를 이해하고 수정하기 쉽게 유지해야 합니다. 구현 언어가 클래스 및 캡슐화를 지원하지 않더라도 마치 이런 기능이 있는 것처럼 설계해야 합니다.

조작 페이지 맨 위

다른 객체의 속성 또는 관계에 액세스하거나 영향을 미칠 수 있는 유일한 방법은 조작을 사용하는 것입니다. 객체의 조작은 해당 클래스에 의해 정의됩니다. 객체가 보유하는 속성 및 관계에 영향을 미치고 다른 조작을 수행할 수 있게 할 수 있는 조작을 통해 특정 작동을 수행할 수 있습니다. 조작은 C++로 된 구성원 기능 또는 Ada로 된 기능 또는 프로시저에 해당합니다. 객체에 지정된 작동은 유스 케이스 구현시 갖고 있는 역할에 따라 다릅니다.

매개변수 페이지 맨 위

조작 스펙에서 매개변수는 정규 매개변수를 구성합니다. 각 매개변수는 이름 및 유형을 갖고 있습니다. 코딩을 시작할 때 구현 언어에 이미 지정되어 있도록 구현 언어 구문 및 의미론을 사용하여 조작 및 매개변수를 지정할 수 있습니다.

예:

재활용 기계 시스템에서 영수증 기반 클래스를 가진 객체는 고객이 특정 유형의 적립 항목을 몇 개나 갖고 있는지를 알고 있습니다. 영수증 기반 객체의 작동에는 반품된 객체 수 증가도 포함됩니다. 갖고 있는 항목에 대한 참조를 받는 insertItem 조작이 이 목적을 달성합니다.

첨부 텍스트에 설명된 다이어그램

조작을 지정할 때에는 구현 언어 구문 및 의미론을 사용하십시오.

클래스 조작 페이지 맨 위

조작은 거의 항상 객체 작동을 표시합니다. 조작은 클래스의 작동(이 경우, 클래스 조작)도 표시합니다. 이는 조작을 type-scoping하여 UML로 모델화할 수 있습니다.

조작 가시성 페이지 맨 위

조작에서 다음과 같은 가시성이 가능합니다.

  • Public: 조작이 클래스 자체가 아닌 모델 요소에 대해 가시적입니다.
  • Protecte: 조작이 클래스 자체, 해당 서브클래스 또는 클래스(언어 종속)의 friend에 대해 가시적입니다.
  • Private: 조작이 클래스 자체 및 클래스의 friend에 대해서만 가시적입니다.
  • Implementation: 조작이 클래스 자체에 대해서만 가시적입니다.

Public 가시성은 다른 클래스에 조작이 필요한 경우에만 매우 신중하게 사용해야 합니다.

Protected 가시성은 기본값입니다. 이는 외부 클래스가 조작을 사용하지 못하게 하며 느슨한 결합 및 작동의 캡슐화를 증진시킵니다.

subclasses가 조작을 상속하지 못하게 할 경우에는 Private 가시성을 사용해야 합니다. 이는 수퍼클래스로부터 서브클래스를 분리하는 방법과 사용되지 않은 상속 조작을 제거 또는 제외시켜야 하는 필요성을 제거할 수 있는 방법을 제공합니다.

Implementation 가시성이 가장 제약이 많습니다. 이는 클래스 자체만이 조작을 사용할 수 있는 경우에 사용됩니다. 이는 Private 가시성의 변형으로서 대부분의 경우에 적당합니다.

상태 페이지 맨 위

객체는 어떤 상태에 놓여 있는지에 따라 특정 메시지에 대해 다르게 반응할 수 있습니다. 객체의 상태 종속 작동은 연관된 stechart 다이어그램에 의해 정의됩니다. 객체가 놓일 수 있는 각 상태의 경우, 상태 차트 다이어그램은 받을 수 있는 메시지, 수행할 수 있는 조작 및 객체가 이후에 놓일 수 있는 상태에 대해 설명합니다. 자세한 정보는 가이드라인: 상태 차트 다이어그램을 참조하십시오.

협력 페이지 맨 위

협력은 객체 세트가 서로 메시지를 서로 전송하여 통신하는 동적인 객체 상호 작용 세트입니다. 메시지를 보내면 Smalltalk로 보내집니다. Ada에서는 서브프로그램 호출로 수행됩니다. 메시지는 객체 내에서 조작을 호출하는 수신 객체로 보내집니다. 메시지는 필요한 매개변수와 함께 수행할 이름을 표시합니다. 메시지를 보내면 모든 매개변수에 대해 실제 매개변수 (정규 매개변수의 값)가 제공됩니다.

유스 케이스 구현 내의 오브젝트 간의 메시지 전송 및 조작이 호출되었을 때 객체가 따르는 제어의 초점이 상호 작용 다이어그램에 설명되어 있습니다. 이 다이어그램에 대한 자세한 정보는 가이드라인: 순서 다이어그램가이드라인: 의사소통 다이어그램을 참조하십시오.

속성 페이지 맨 위

속성은 객체의 이름 지정된 속성입니다. 속성 이름은 객체에 관련된 속성의 역할에 대해 설명하는 명사입니다. 속성은 객체가 작성되었을 때의 초기값입니다.

속성을 모델화하는 것이 객체를 이해하기가 더 쉬울 경우에만 속성을 모델화하십시오. 이 등록 정보가 해당 객체만의 등록 정보인 경우에만 객체의 등록 정보를 속성을 모델화해야 합니다. 그렇지 않으면 연관 또는 총계 관계를 가진 등록 정보를 해당 객체가 등록 정보를 나타내는 클래스로 모델화해야 합니다.

예:

첨부 텍스트에 설명된 다이어그램

속성을 모델화하는 방법에 대한 예제. 제품군의 각 구성원은 이름 및 주소를 갖고 있습니다. 여기서, 이름주소내 이름집 주소 속성을 각각 지정했습니다.

첨부 텍스트에 설명된 다이어그램

이 예제에서는 속성 대신 연관이 사용됩니다. 내 이름 등록 정보는 제품군 내의 각 구성원에 고유할 수 있습니다. 따라서 이를 속셩 유형 이름의 속성으로 모델화할 수 있습니다. 주소는 모든 제품군 구성원이 공유하기는 하지만 제품군 구성원 클래스 및 주소 클래스 간의 연관에 의해 최적으로 모델화됩니다.

일부 개념을 별도의 객체로 모델화할지 또는 다른 객체의 속성으로 모델화할지를 결정하는 것은 항상 어렵습니다. 객체 모델 안에 불필요한 객체가 있으면 불필요한 문서 및 개발 오버헤드가 생깁니다. 그러므로 개념이 시스템에 얼마나 중요한지를 판단하려면 특정 기준을 설정해야 합니다.

  • 액세스 용이성. 선택사항(객체 대 속성)을 관장하는 것은 실제 생활에서는 중요한 것이 아니지만 유스 케이스 중에 액세스해야 하는 것은 중요합니다. 장치에 자주 액세스하면 객체로서 모델화하십시오.
  • 실행 중에 분리. 모델 개념은 유스 케이스 실행 중에 객체로서 별도로 처리됩니다.
  • 다른 개념과 결합. 모델 개념은 다른 특정 개념에 완전히 결합되어 절대로 별도로 사용되지 않으나 항상 모델을 통해 객체의 속성으로서 사용됩니다.
  • 관계로부터의 요구. 어떠한 이유로 두 방향으로부터 장치를 관련시켜야 할 경우, 장치를 다시 검토하여 객체를 분리해야 할지를 판단하십시오. 두 객체는 하나의 속성 유형을 가진 동일한 인스턴스를 연관시킬 수 없습니다.
  • 어커런스 빈도. 유스 케이스 중에만 단위가 존재할 경우, 이를 객체로 모델화하지 마십시오. 대신 이를 질문 내의 작동을 수행하는 객체에 대한 속성으로 모델화하거나 영향을 받는 객체의 설명에 간단히 언급하십시오.
  • 복잡도. 객체가 속성 때문에 너무 복잡할 경우, 일부 속성을 별도의 객체로 추출할 수 있습니다. 그러나 오브젝트가 너무 많아지지 않도록 중간 수준으로 수행하십시오. 한편 이 단위는 매우 간단할 수 있습니다. 예를 들어, 속성으로 분류된 것은 (1) 구현 언어에서 기본 유형에 의해 직접 지원될 수 있을 정도로 간단한 단위(예: C++에서의 정수) (3) 구현 환경의 어플리케이션 독립 컴포넌트를 사용하여 구현될 수 있을 정도로 간단한 단위(예: C++ 및 Smalltalk-80의 문자열).

시스템이 다르면 개념을 다르게 모델화합니다. 한 시스템에서는 개념이 너무 중요하여 이를 객체로 모델화할 수 있습니다. 다른 시스템에서는 그리 중요하지 않아 객체의 속성으로 모델화할 수 있습니다.

예:

예를 들어, 항공사의 경우 출발을 지원하는 시스템을 개발합니다.

첨부 텍스트에 설명된 다이어그램

출발을 지원하는 시스템. 공항 직원이 출발 지원 시스템을 필요로 한다고 가정합시다. 각 출발마다 출발 시간, 항공사 및 목적지를 정의해야 합니다. 이를 클래스가 출발이고 속성이 출발 시간, 항공목적지인 객체로 모델화할 수 있습니다.

여행사를 위한 시스템을 개발할 경우에는 상황이 약간 달라집니다.

첨부 텍스트에 설명된 다이어그램

비행기 목적지가 자체 객체인 목적지를 구성합니다.

출발 시간, 항공사 및 목적지도 물론 필요합니다. 항공사에서는 특정 목적지를 가진 출발을 찾는 데 관심이 있기 때문에 아직도 다른 요구사항이 많이 있습니다. 따라서 목적지에 대해 별도의 객체를 작성해야 합니다. 물론 다른 클래스 간의 연관에 의해 사용 가능해진 출발목적지 객체도 서로 인식해야 합니다.

특정 개념의 중요성에 대한 인수도 클래스에 어떤 속성을 정의해야 하는지를 판별하는 데 올바릅니다. 클래스는 해당 객체가 자동차 제조 시스템의 일부인 경우보다는 자동차 등록 시스템의 일부인 경우에 당연히 다른 속성을 정의합니다.

마지막으로 객체로서 표현하려는 것 또는 속성으로서 표현하려는 것에 대한 규칙은 절대적이지 않습니다. 이론적으로는 모든 것을 객체로 표현할 수 있으나 부담스럽습니다. 실용적인 방법은 일부 단계에서 객체를 다른 객체와 상관없는 것으로 보는 것입니다. 또한 속성을 사용하여 모든 객체 등록 정보를 모델화해서는 안 됩니다. 객체를 이해하는 데 필요한 등록 정보만 모델화하십시오. 구현자에 의해 더 잘 처리되는 구현에 특정한 세부사항은 모델화해서는 안 됩니다.

클래스 속성 페이지 맨 위

속성은 거의 항상 객체 등록 정보를 표시합니다. 속성은 클래스의 등록 정보(이 경우, 클래스 속성)도 표시할 수 있습니다. 이는 속성 범위를 입력하여 UML로 모델화할 수 있습니다.

속성을 사용하여 외부 단위 모델링페이지 맨 위

객체는 객체가 아무런 작동도 수행하지 않고 값을 변경할 수 있는 것을 캡슐화할 수 있습니다. 이는 실제로 외부 단위이나 액터로서 모델화되지 않은 것일 수 있습니다. 예를 들어, 센서 장비의 일반 양식이 경계 내에 속하도록 시스템 경계를 선택할 수 있습니다. 그런 다음 센서가 측정하는 값이 속성을 구성하도록 센서를 객체 내에 캡슐화할 수 있습니다. 이 값은 객체가 시스템의 다른 객체의 영향을 받지 않고 계속해서 또는 특정 간격으로 변경할 수 있습니다.

예:

온도계를 객체로서 모델화할 수 있습니다. 객체는 온도를 나타내는 속성을 가지며 환경의 온도 변화에 대응하여 값을 변경합니다. 다른 객체는 온도계 객체에 대한 조작을 수행하여 현재 온도를 요청할 수 있습니다.

첨부 텍스트에 설명된 다이어그램

온도계 객체에서 온도 속성의 값은 임의로 변경됩니다.

계속해서 이 방법으로 변경되는 캡슐화된 값을 일반 속성처럼 모델화할 수 있습니다. 그러나 객체 클래스에 임의로 변경된다는 것을 기술해야 합니다.

속성 가시성 페이지 맨 위

속성 가시성은 다음 값 중 하나를 가정합니다.

  • Public: 속성은 클래스를 포함하는 내부 및 외부 패키지 모두에 가시적입니다.
  • Protected: 속성은 클래스 자체, 해당 서브클래스 또는 클래스의 프렌드에게만 가시적입니다(언어 종속).
  • Private: 속성은 클래스 자체 및 클래스의 프렌드에게만 가시적입니다.
  • Implementation: 속성은 클래스 자체에만 가시적입니다.

Public 가시성은 다른 클래스가 속성에 직접 액세스할 수 있는 경우에만 매우 신중하게 사용해야 합니다. Public 가시성을 정의하는 것은 속성 가시성을 속성값을 가져와 설정하는 공용 조작에 연관된 protected, private 또는 implementation으로 정의하기 위한 효율적이고 빠른 표기법입니다. public 속성 가시성은 set/get 조작을 자동으로 생성하는 코드 생성기에 대한 선언으로 사용하여 클래스 정의 중에 시간을 절약할 수 있습니다.

Protected 가시성은 기본값입니다. 이는 외부 클래스가 속성을 사용하지 못하게 하며 느슨한 결합 및 작동의 캡슐화를 증진시킵니다.

서브클래스가 속성을 상속하지 못하게 할 경우에는 Private 가시성을 사용해야 합니다. 이는 수퍼클래스로부터 서브클래스를 분리하는 방법과 미사용된 상속 속성을 제거 또는 제외시켜야 하는 필요성을 제거할 수 있는 방법을 제공합니다.

Implementation 가시성이 가장 제약이 많습니다. 이는 클래스만이 속성을 사용할 수 있는 경우에 사용됩니다. 이는 Private 가시성의 변형으로서 대부분의 경우에 적당합니다.

내부 구조 페이지 맨 위

일부 클래스는 복잡한 추상을 표현하며 복잡한 구조를 갖습니다. 설계자는 클래스를 모델화하는 중에 내부 파티셔닝 요소 및 해당 관계를 표현하고 구현자가 그에 맞게 해당 클래스 내부에서 발생한 협력을 구현하기를 원할 수 있습니다.

UML 2.0에서 클래스는 내부 구조 및 포트를 가질 능력이 있는 구조화된 클래스로 정의됩니다. 그런 다음, 클래스는 더 분해할 수 있는 연결된 파트 콜렉션으로 분해할 수 있습니다. 외부로부터의 통신이 강제로 선언된 인터페이스를 준수하는 포트를 통과하게 함으로써 클래스를 캡슐화할 수 있습니다.

설계자는 클래스 관계(예: 연관, 합성 및 총계) 및 속성을 표현하기 위해 클래스 다이어그램을 사용할 뿐 아니라 합성 구조 다이어그램도 사용하고자 할 수 있습니다. 이 다이어그램은 설계자에게 내부 파트 인스턴스가 제공된 클래스 인스턴스 내에서 역할을 수행하는 방법을 보여주는 메커니즘을 제공합니다.

이 주제에 대한 자세한 설명 및 합성 구조 다이어그램에 대한 예제는 개념: 구조화 클래스를 참조하십시오.

Rational Unified Process   2003.06.15