디자인 클래스는 시스템 구현 시 클래스 하나 이상의 추상을 표시합니다. 정확히 이에 해당하는
사항은 구현 언어에 종속됩니다. 예를 들어 객체 지향 언어(예: C++)에서 클래스는 일반 클래스에 해당할 수 었습니다. 또는 Ada에서 클래스는 패키지의 가시적 파트에서 정의되는 태그 처리된 유형에 해당할 수
있습니다.
클래스는 오브젝트를 정의하고 차례대로 유스 케이스를 구현(실현)합니다. 클래스는 시스템에 필요한 오브젝트에서 유스 케이스 실현으로 작성된 요구사항 및 이전에 개발한 오브젝트 모델에서 시작됩니다.
좋은 클래스인지 여부는 구현 환경에 따라 크게 달라집니다. 클래스 및 해당 오브젝트의 적절한 크기는 예를 들어, 프로그래밍 언어에 따라 다릅니다. Ada 사용 시 올바른 고려 사항이 Smalltalk 사용 시
잘못된 사항일 수도 있습니다. 클래스는 구현 언어의 특정 상황으로 맵핑되어야 하며 맵핑으로 좋은 코드를 작성하도록 클래스를 구성해야 합니다.
구현 언어의 특징이 디자인 모델에 영향을 주어도 클래스 구조를 쉽게 이해하고 수정하도록 유지해야 합니다. 구현 언어가 이 조건을 지원하지 않는 경우에도 클래스 및 캡슐화가 제공된 상황처럼 디자인해야 합니다.
다른 오브젝트가 한 오브젝트의 속성 또는 관계에 액세스하거나 영향을 줄 수 있는 유일한 방법은 해당 오퍼레이션을 사용하는 것입니다. 오브젝트의 오퍼레이션은 해당 클래스에서 정의됩니다. 오퍼레이션을 통해
수행할 수 있는 특정 동작이 있습니다. 이 경우 오브젝트가 보유하는 속성 및 관계에 영향을 줄 수 었으며 다른 조작이 수행될 수도 있습니다. 오퍼레이션은 C++의 구성원 함수 또는 Ada의 함수나 프로시저에
해당합니다. 오브젝트에 지정하는 동작은 유스 케이스 실현에서 맡은 역할에 따라 다릅니다.
오퍼레이션 스펙에서 매개변수는 정규 매개변수를 구성합니다. 각 매개변수에는 이름 및 유형이 있습니다. 코드를 시작할 때 구현 언어에 이미 지정될 수 있도록 구현 언어 구문 및 시맨틱을 사용하여
오퍼레이션 및 해당 매개변수를 지정할 수 있습니다.
예제:
재활용품 수집기 시스템에서 Receipt Basis 클래스의 오브젝트는 고객이 제공한 특정 유형의 보관 항목 수를 추적합니다. Receipt Basis 오브젝트의 동작으로
리턴된 오브젝트 수를 증가시키는 작업이 있습니다. 제공된 항목에 대한 참조를 수신하는 insertItem 오퍼레이션으로 이 목적을 달성합니다.
오퍼레이션을 지정하는 경우 구현 언어 구문 및 시맨틱을 사용하십시오.
오퍼레이션은 거의 항상 오브젝트 동작을 표시합니다. 오퍼레이션은 클래스의 동작도 표시할 수 있습니다. 이 경우 클래스 오퍼레이션이라고 합니다. 이 오퍼레이션은 해당 오퍼레이션의 범위를 입력하여
UML에서 모델링될 수 있습니다.
오퍼레이션에서 다음과 같은 가시성이 가능합니다.
-
Public: 오퍼레이션은 클래스 이외의 모델 요소에서 가시적입니다.
-
Protected: 오퍼레이션은 클래스 자체, 해당 서브클래스 또는 클래스의 동반자(언어에 종속됨)에서만 가시적입니다.
-
Private: 오퍼레이션은 클래스 자체 및 클래스의 동반자에서만 가시적입니다.
-
Implementation: 오퍼레이션은 클래스 자체 내부에서만 가시적입니다.
Public 가시성은 다른 클래스에서 오퍼레이션이 필요한 경우에만 매우 최소한으로 사용되어야 합니다.
Protected 가시성은 기본값입니다. 동작의 캡슐화 및 느슨한 결합을 촉진하는 외부 클래스의 사용으로부터 오퍼레이션을 보호합니다.
Private 가시성은 서브클래스에서 오퍼레이션을 상속하지 않도록 할 경우 사용해야 합니다. 이 경우 수퍼 클래스에서 서브클래스를 분리하고 사용하지 않는 상속된 오퍼레이션을 제거하거나
제외하려는 요구를 줄이는 방법을 제공합니다.
Implementation 가시성은 가장 제한적입니다. 클래스 자체만 오퍼레이션을 사용할 수 있는 경우 사용합니다. Private 가시성의 변형으로, 대부분의 경우 적합합니다.
오브젝트는 상태에 따라 특정 메시지에 서로 다른 반응을 보일 수 있습니다. 상태에 따른 오브젝트의 동작은 연관된 상태 차트 다이어그램에서 정의됩니다. 오브젝트가 입력할 수 있는 각 상태에서 상태 차트 다이어그램은
수신할 수 있는 메시지, 수행할 수 있는 조작 및 이후 오브젝트 상태를 설명합니다. 자세한 정보는 기법: 상태 차트
다이어그램을 참조하십시오.
협업은 오브젝트 세트가 서로 메시지를 송신하여 커뮤니케이션하는 오브젝트 상호작용의 동적 세트입니다. Smalltalk에서 메시지 송신은 간단합니다. Ada에서는 서브프로그램 호출로 수행됩니다. 메시지는
오브젝트에서 오퍼레이션을 호출하는 수신 오브젝트로 송신됩니다. 메시지는 필수 매개변수와 함께 수행할 오퍼레이션 이름을 표시합니다. 메시지를 송신하면 실제 매개변수(정규 매개변수 값)를 모든
매개변수에 제공합니다.
오퍼레이션을 호출하는 경우 오브젝트가 따라야 하는 제어 중심 및 유스 케이스 실현(realization)에서 오브젝트 사이의 메시지 전송은 상호작용 다이어그램에서 설명됩니다. 이 다이어그램에 대한 정보는 기법: 시퀀스 다이어그램 및 기법:
커뮤니케이션 다이어그램을 참조하십시오.
속성은 오브젝트의 이름 지정된 특성입니다. 속성 이름은 오브젝트와 관련하여 속성의 역할을 설명하는 명사입니다. 오브젝트를 작성하면 속성에 초기값이 들어 있습니다.
오브젝트를 쉽게 이해할 수 있도록 하는 경우에만 속성을 모델링해야 합니다. 해당 오브젝트 단독의 특성인 경우에만 오브젝트 특성을 속성으로 모델링해야 합니다. 그렇지 않으면 해당 오브젝트가 특성을
표시하는 클래스에 대한 연관 또는 집계 관계를 사용하여 특성을 모델링해야 합니다.
예제:
속성을 모델링하는 방법에 대한 예제입니다. 각 가족 구성원에는 이름 및 주소가 있습니다. 여기서 각각 Name 및 Address 유형의 my name 및 home
address 속성을 식별합니다.
이 예제에서는 속성 대신 연관을 사용합니다. my name 특성은 각 가족 구성원에 고유합니다. 따라서 속성 유형 Name의 속성으로 모델링할 수 있습니다. 주소는 모든 가족 구성원이
공유하지만 Family Member 클래스 및 Address 클래스 사이의 연관으로 가장 잘 모델링됩니다.
일부 개념을 별도의 오브젝트로 모델링할 것인지 다른 오브젝트의 속성으로 할 것인지를 바로 결정하기는 항상 쉽지 않습니다. 오브젝트 모델에 불필요한 오브젝트가 있으면 불필요한 문서 및 개발 오버헤드가 생깁니다.
따라서 시스템에 얼마나 중요한 개념인지를 판별할 때 특정 기준을 설정해야 합니다.
-
액세스 가능성. 오브젝트 대 속성 사이의 선택을 좌우하는 것은 실생활에서의 개념의 중요성이 아니라 유스 케이스 중의 액세스 필요성입니다. 단위에 자주 액세스하는 경우 오브젝트로 모델링하십시오.
-
실행 중 독립성. 모델 개념은 오브젝트로 유스 케이스를 실행하는 중 독립적으로 처리됩니다.
-
다른 개념과의 관계. 모델 개념은 특정 다른 개념과 엄격하게 연결되며 독립적으로 사용되지 않습니다. 하지만 항상 오브젝트 속성으로 오브젝트를 통해 사용됩니다.
-
관계에서의 요구. 어떤 이유로 두 방향에서 단위를 관련시키고 독립적인 오브젝트여야 하는지 확인하기 위해 다시 점검해야 합니다. 두 오브젝트는 속성 유형이 동일한 인스턴스를 연관시킬 수 없습니다.
-
발생 빈도. 단위가 유스 케이스 중에만 있는 경우 오브젝트로 모델링하지 마십시오. 대신 문제가 되는 동작을 수행하는 오브젝트에 대한 속성으로 모델링하십시오. 또는 단순히 영향을 받는 오브젝트의
설명에서 언급하십시오.
-
복잡도. 속성 때문에 오브젝트가 너무 복잡한 경우 독립된 오브젝트로 일부 속성을 추출할 수 있습니다. 그러나 오브젝트가 너무 많아지지 않도록 적당한 수준으로 추출하십시오. 반면 단위는 매우
간단할 수 있습니다. 예를 들어 (1) 구현 언어의 기본 유형으로 직접 지원할 수 있는 단위(예: C++에서 정수) 및 (2) 구현 환경의 응용프로그램과는 무관한 컴포넌트를 사용하여 구현할 수 있는
단위(예: C++ 및 Smalltalk-80에서 문자열)는 속성으로 분류됩니다.
다른 시스템에서 다른 방식으로 개념을 모델링할 수 있습니다. 하나의 시스템에서 개념이 매우 중요하여 오브젝트로 모델링할 수 있습니다. 다른 시스템에서는 중요하지 않으므로 오브젝트의 속성으로 모델링합니다.
예제:
예를 들어 항공 회사에서 출발을 지원하는 시스템을 개발합니다.
출발을 지원하는 시스템입니다. 공항 직원에게 출발을 지원하는 시스템이 필요한 경우를 가정해 보십시오. 모든 출발에서 출발 시간, 항공사 및 목적지를 정의해야 합니다. time of departure,
airline 및 destination 속성을 포함하는 Departure 클래스의 오브젝트로 모델링할 수 있습니다.
대신 여행사를 위한 시스템을 개발하는 경우 상황은 다소 달라질 수 있습니다.
비행 목적지 양식인 고유한 Destination 오브젝트입니다.
출발 시간, 항공사 및 목적지도 물론 계속 필요합니다. 그러나 여행사는 특정 목적지에서 출발을 찾는 데 관심이 있으므로 다른 요구사항이 있습니다. 따라서 Destination이라는 별도의 오브젝트를
작성해야 합니다. Departure 및 Destination 오브젝트는 물론 서로를 인식해야 합니다. 해당 클래스 사이의 연관으로 서로를 인식할 수 있습니다.
특정 개념의 중요성에 해당하는 인수는 속성을 클래스에서 정의해야 하는지 판별하는 경우에도 올바릅니다. Car 클래스는 해당 오브젝트가 자동차 제조업체 시스템의 파트인 경우와는 달리 자동차 등록 시스템의
파트인 경우 확실히 서로 다른 속성을 정의합니다.
마지막으로 오브젝트로 표시하는 작업 및 속성으로 표시하는 작업의 규칙은 절대적이지 않습니다. 이론적으로는 모든 사항을 오브젝트로 모델링할 수 있지만 부담이 됩니다. 경험에 따른 단순한 규칙은 일부 단계에서 기타
오브젝트와는 상관없이 사용하는 항목으로 오브젝트를 보는 것입니다. 또한 속성을 사용하여 모든 오브젝트 특성을 모델링하지 않아도 됩니다. 오브젝트를 이해하는 데 필요한 특성만 모델링합니다. 구현에 너무 특정하여
구현자가 더 잘 처리할 수 있는 세부사항은 모델링할 수 없습니다.
클래스 속성
속성은 거의 항상 오브젝트 특성을 표시합니다. 속성은 클래스의 특성도 표시할 수 있습니다. 이 경우 클래스 속성이라고 합니다. 이 속성은 해당 속성의 범위를 입력하여 UML에서 모델링될 수 있습니다.
오브젝트가 동작을 수행하지 않고도 오브젝트는 해당 값을 변경할 수 있는 항목을 캡슐화할 수 있습니다. 이 항목은 실제로 외부 단위일 수도 있지만 액터로는 모델링되지 않습니다. 예를 들어 센서 장비의 일부 양식이
경계 내부에 놓이도록 시스템 경계를 선택할 수 있습니다. 그러면 센서는 오브젝트 내부에서 캡슐화됩니다. 따라서 센서에서 측정한 값이 속성으로 구성됩니다. 이 값은 지속적으로 또는 시스템에 있는 기타 오브젝트의
영향을 받지 않는 오브젝트인 경우 특정 간격으로 변경될 수 있습니다.
예제:
온도계를 오브젝트로 모델링할 수 있습니다. 오브젝트는 온도를 표시하는 속성을 포함하며 환경의 온도가 변경되면 값을 변경합니다. 온도계 오브젝트에서 오퍼레이션을 수행하여 기타 오브젝트가 현재 온도를 물어볼 수
있습니다.
Temperature 속성 값은 Thermomether 오브젝트에서 자발적으로 변경됩니다.
이러한 방식으로 변경되는 캡슐화된 값을 일반 속성으로 계속 모델링할 수 있지만 오브젝트의 클래스에서 자발적으로 변경됨을 설명해야 합니다.
속성 가시성에서는 다음 중 하나의 값을 가정합니다.
-
Public: 속성은 클래스를 포함하는 패키지 내부 및 외부 모두에서 가시적입니다.
-
Protected: 속성은 클래스 자체, 해당 서브클래스 또는 클래스의 동반자(언어에 종속됨)에서만 가시적입니다.
-
Private: 속성은 클래스 자체 및 클래스의 동반자에서만 가시적입니다.
-
Implemenation: 속성은 클래스 자체에서만 가시적입니다.
Public 가시성은 다른 클래스에서 속성에 직접 액세스할 수 있는 경우에만 매우 최소한으로 사용되어야 합니다. Public 가시성 정의는 속성 값을 가져오고 설정하는 연관된
공용 조작에서 속성 가시성을 protected, private 또는 implementation으로 정의하는 경우 효과적인 속기 표기법입니다. Public 속성 가시성은 이 가져오기/설정 조작을 자동으로 생성하도록
코드 생성기에 대한 선언으로 사용될 수 있습니다. 그러면 클래스 정의 중 시간이 절약됩니다.
Protected 가시성은 기본값입니다. 동작의 캡슐화 및 느슨한 결합을 촉진하는 외부 클래스로부터 속성을 보호합니다.
Private 가시성은 서브클래스에서 속성을 상속하지 않도록 할 경우 사용해야 합니다. 이 경우 수퍼 클래스에서 서브클래스를 분리하고 사용하지 않는 상속된 속성을 제거하거나 제외하려는
요구를 줄이는 방법을 제공합니다.
Implementation 가시성은 가장 제한적입니다. 클래스 자체만 속성을 사용할 수 있는 경우 사용합니다. Private 가시성의 변형으로, 대부분의 경우 적합합니다.
일부 클래스는 복잡한 추상을 표시하고 구조가 복잡합니다. 클래스를 모델링하는 중 디자이너가 내부 참여 요소 및 관계를 표시할 수 있습니다. 그러면 이에 따라 구현자가 해당 클래스 내부에서 발생하는 협업을
구현합니다.
UML 2.0에서 클래스는 내부 구조 및 포트를 포함하는 기능이 있는 구조화된
클래스로 정의됩니다. 이후 클래스는 연결된 파트의 콜렉션(나중에 차례대로 분해될 수 있음)으로 분해될 수 있습니다. 선언된 인터페이스를 따르는 포트를 통과하도록 외부에서 커뮤니케이션을 강제 실행하여 클래스를
캡슐화할 수 있습니다.
따라서 디자이너는 클래스 관계(예: 연관, 구성, 집계) 및 속성을 표시하도록 클래스 다이어그램을 사용할 뿐만 아니라 컴포지트 구조 다이어그램을 사용할 수 있습니다. 이 다이어그램에서는 지정된 클래스의 인스턴스
내에서 해당 역할을 수행하는 내부 파트의 인스턴스 수를 표시하는 메커니즘을 디자이너에게 제공합니다.
컴포지트 구조 다이어그램의 예제 및 이 주제에 대한 자세한 정보는 개념: 구조화된
클래스를 참조하십시오.
|