타스크: 클래스 디자인
이 타스크는 서브시스템 또는 컴포넌트의 클래스 구조 디자인 방법을 정의합니다.
원칙: 분석 및 디자인
목적
  • 클래스가 유스 케이스 실현(realization)에 필요한 동작을 제공하도록 함
  • 클래스를 명확하게 구현하기 위해 충분한 정보가 제공되도록 함
  • 클래스 관련 비기능적 요구사항 처리
  • 클래스가 사용하는 디자인 메커니즘 통합
관계
기본 설명

클래스는 디자인 노력의 일꾼 역할을 합니다. 즉 클래스가 실제로 시스템의 실제 작업을 수행합니다. 서브시스템, 패키지 및 협업과 같은 기타 디자인 요소는 클래스가 그룹화되는 방법 또는 클래스가 상호작동하는 방법을 설명합니다.

캡슐은 또한 실시간 시스템에서 실행의 동시 스레드를 표시하는 데 사용되는 스테레오타입화된 클래스입니다. 그런 경우에 기타 디자인 클래스는 활성 캡슐이 제공하는 실행 컨텍스트 내에서 사용되는 수동 클래스입니다. 소프트웨어 설계자 및 디자이너가 캡슐에 기초하는 디자인 접근 방식을 사용하지 않도록 선택할 때도 활성 클래스를 사용하여 동시 동작을 모델링할 수 있습니다.

활성 클래스는 수동 클래스의 동작을 조정하고 추진하는 디자인 클래스입니다. 활성 클래스는 해당 인스턴스가 고유한 제어 스레드를 소유하는 활성 오브젝트인 클래스입니다.

단계
디자인 패턴 및 메커니즘 사용

디자인할 클래스 또는 기능에 맞게 그리고 프로젝트 디자인 가이드라인에 따라서 디자인 패턴과 메커니즘을 사용하십시오.

패턴 및/또는 메커니즘 통합은 이 타스크에 있는 많은 후속 단계(새 클래스, 오퍼레이션, 속성 및 관계 추가)를 패턴 또는 메커니즘에 의해 정의되는 규칙에 따라서 효율적으로 수행합니다.

패턴과 메커니즘은 일반적으로 디자인이 발전함에 따라서 통합되며 단지 이 타스크의 첫 번째 단계는 아님에 주의하십시오. 또한 이는 단일 클래스만이 아니라 클래스 세트 사이에 자주 적용됩니다.

초기 디자인 클래스 작성

이 타스크에 대한 입력으로 주어진 분석 클래스에 대한 하나 이상의 초기 디자인 클래스를 작성하고 추적 종속성을 지정하십시오. 이 단계에서 작성된 디자인 클래스는 분석 클래스가 디자인되는 방법을 설명하는 다양한 디자인 특성(예: 오퍼레이션, 메소드 및 상태 머신)이 지정되는 후속 단계에서 정제, 조정, 분할 또는 병합됩니다.

디자인되는 분석 클래스의 유형(경계, 엔티티 또는 제어)에 따라서 초기 디자인 클래스를 작성하는 데 사용할 수 있는 특정 전략이 있습니다.

경계 클래스 디자인

경계 클래스는 사용자 또는 다른 시스템에 대한 인터페이스를 표시합니다.

일반적으로 다른 시스템에 대한 인터페이스를 표시하는 경계 클래스는 종종 복잡한 내부 동작을 갖기 때문에 서브시스템으로 모델링됩니다. 인터페이스 동작이 단순한 경우(외부 시스템에 대한 기존 API의 통과(pass-through)로서만 동작하는 경우) 하나 이상의 디자인 클래스로 인터페이스를 표시할 수 있습니다. 이 라우트를 선택하는 경우 프로토콜, 인터페이스 또는 API별로 단일 디자인 클래스를 사용하고 클래스의 특별 요구사항에 사용한 표준에 대한 특별 요구사항을 기록하십시오.

사용자에 대한 인터페이스를 표시하는 경계 클래스는 일반적으로 사용자 인터페이스에서 각 창에 대해 하나의 경계 클래스 또는 각 양식에 대해 하나의 규칙을 따릅니다. 결국 경계 클래스의 책임이 상당한 상위 레벨에 있을 수 있으며 이 단계에서 정제 및 세부화되어야 합니다. 사용자 인터페이스의 추가 모델 또는 프로토타입은 이 단계에서 고려해야 하는 다른 입력 소스일 수 있습니다.

경계 클래스의 디자인은 프로젝트에 사용할 수 있는 사용자 인터페이스(UI) 개발 도구에 의존합니다. 현재 기술을 사용할 때 UI가 개발 도구에서 직접 시각적으로 구성되는 것이 일반적입니다. 그러면 제어 및 엔티티 클래스의 디자인과 관련되어야 하는 UI 클래스가 자동으로 작성됩니다. UI 개발 환경이 자동으로 UI를 구현하기 위해 필요한 지원 클래스를 작성하는 경우 디자인에서 이들을 고려할 필요가 없습니다. 개발 환경이 사용자를 위해 작성하지 않는 것만 디자인하십시오.

엔티티 클래스 디자인

분석 중에 엔티티 클래스는 조작되는 정보 단위를 표시합니다. 엔티티 클래스는 종종 수동이고 지속적이며, 지속성을 위해 식별되어 분석 메커니즘과 연관될 수 있습니다. 데이터베이스 기반 지속성 메커니즘의 세부사항은 타스크: 데이터베이스 디자인에서 다룹니다. 성능 고려사항 때문에 지속적 클래스의 몇몇 리팩토링이 시행될 수 있어서 역할: 데이터베이스 디자이너역할: 디자이너 사이에 공동으로 논의되는 디자인 모델이 변경될 수 있습니다.

지속적 클래스에 대한 디자인 문제의 폭넓은 논의는 지속적 클래스 식별 표제 아래에서 나중에 제공됩니다.

제어 클래스 디자인

제어 오브젝트는 유스 케이스의 플로우를 관리할 책임을 갖고 있으며 따라서 조치의 대부분을 조정합니다. 즉 제어 오브젝트는 사용자 인터페이스 문제(경계 오브젝트) 또는 데이터 엔지니어링 문제(엔티티 오브젝트)와 특별하게 관련되지 않는 로직을 캡슐화합니다. 이 로직을 때로는 응용프로그램 로직 또는 비즈니스 로직이라고 부릅니다.

제어 클래스를 디자인할 때 다음 문제를 고려하십시오.

  • 복잡도 - 경계 또는 엔티티 클래스를 사용하여 복잡하지 않은 제어 또는 조정 동작을 처리할 수 있습니다. 그러나 응용프로그램의 복잡도가 커지면 다음과 같이 이 접근 방식의 상당한 결점이 드러납니다.
  • 유스 케이스 조정 동작이 UI에 임베디드되어 시스템 변경을 더 어렵게 함
  • 서로 다른 유스 케이스 실현(realization)에서 동일한 UI를 어려움 없이 사용할 수 없음
  • 추가 기능성으로 인해 UI의 성능이 저하됨
  • 유스 케이스 특정 동작으로 인해 엔티티 오브젝트의 일반성이 축소됨

이러한 문제점을 막기 위해, 이벤트 플로우 조정과 관련된 동작을 제공하기 위해 제어 클래스가 도입됩니다.

  • 변경 확률 - 이벤트 플로우 변경 확률이 낮거나 비용을 무시할 수 있는 경우 추가 제어 클래스의 여분의 비용과 복잡도가 입증되지 않을 수 있습니다.
  • 분배 및 성능 - 서로 다른 노드 또는 서로 다른 프로세스 공간에서 응용프로그램 파트를 실행하기 위해서는 특수한 디자인 모델 요소가 필요합니다. 이 특수성은 종종 제어 오브젝트를 추가하고 경계 및 엔티티 클래스의 동작을 제어 클래스에 분배하여 수행됩니다. 이를 수행할 때 경계 클래스는 순수하게 UI 서비스를 제공하는 쪽으로 이주하고, 엔티티 클래스는 순수하게 데이터 서비스를 제공하는 쪽으로 이동하며 제어 클래스는 나머지를 제공합니다.
  • 트랜잭션 관리 - 트랜잭션 관리는 전통적인 조정 활동입니다. 트랜잭션 관리를 처리하는 프레임워크가 없이, 하나 이상의 트랜잭션 관리자 클래스가 트랜잭션의 무결성을 유지보수함을 보장하기 위해 상호작용해야 합니다.

후자의 두 경우에 제어 클래스가 별도의 제어 스레드를 표시하는 경우 활성 클래스를 사용하여 제어 스레드를 모델링하는 것이 보다 적합할 수 있습니다. 실시간 시스템에서는  중간 산출물: 캡슐의 사용이 선호하는 모델링 접근 방식입니다.

지속적 클래스 식별

영구 매체에 상태를 저장하기 위해 필요한 클래스를 지속적이라고 부릅니다. 상태를 저장해야 하는 필요성은 클래스 정보의 영구 기록, 시스템 실패 경우 백업 또는 정보의 변경을 위한 것일 수 있습니다. 지속적 클래스는 지속적 및 임시 인스턴스를 둘 다 가질 수 있습니다. 클래스를 지속적으로 레이블하는 것은 단순히 클래스의 일부 인스턴스가 지속적이어야 할 수 있음을 의미합니다.

분석 중에 발견되는 지속성 메커니즘에 따른 디자인 메커니즘을 통합하십시오. 예를 들어 클래스에 필요한 사항에 따라서 지속성을 위한 분석 메커니즘은 다음 디자인 메커니즘 중 하나에 의해 실현될 수 있습니다.

  • 인메모리 기억장치
  • 플래시 카드
  • 2진 파일
  • 데이터베이스 관리 시스템(DBMS)

지속적 오브젝트는 엔티티 클래스에서만 파생될 수 있지는 않습니다. 지속적 오브젝트는 또한 일반적으로 비기능적 요구사항을 처리하기 위해 필요할 수도 있습니다. 프로세스 제어 관련 정보를 유지보수하거나 트랜잭션 사이에서 상태 정보를 유지보수하기 위해 필요한 지속적 오브젝트가 예제입니다.

지속적 클래스 식별은 클래스가 실제 저장영역 특성에 대한 특별한 주의를 필요로 한다는 내용을 역할: 데이터베이스 디자이너에게 알립니다. 또한 역할: 소프트웨어 설계자에게 클래스가 지속적이어야 함을 알리고, 지속성 메커니즘을 책임지는 역할: 디자이너에게 클래스의 인스턴스가 지속적이어야 함을 알립니다.

조정된 지속성 전략에 대한 필요성으로 인해 역할: 데이터베이스 디자이너는 지속성 프레임워크를 사용하여 지속적 클래스를 데이터베이스에 맵핑할 책임이 있습니다. 프로젝트가 지속성 프레임워크를 개발 중인 경우 프레임워크 개발자도 디자인 클래스의 지속성 요구사항을 이해해야 합니다. 이들에게 필요한 정보를 제공하기 위해 이 시점에서는 클래스가 지속적임 또는 보다 정확하게는 클래스의 인스턴스가 지속적임을 표시하는 것으로 충분합니다.

클래스 가시성 정의

각 클래스에 대해 클래스가 상주하는 패키지 내에서 클래스 가시성을 판별하십시오. 포함하는 패키지의 외부에서 public 클래스를 참조할 수 있습니다. private 클래스(또는 해당 가시성이 implementation인 클래스)는 동일한 패키지 내의 클래스에 의해서만 참조될 수 있습니다.

오퍼레이션 정의

오퍼레이션 식별

디자인 클래스에 대한 오퍼레이션을 식별하려면 다음을 수행하십시오.

  • 각 책임에 대한 오퍼레이션을 작성하여 각 해당 분석 클래스의 책임을 연구하십시오. 책임의 설명을 오퍼레이션의 초기 설명으로 사용하십시오.
  • 유스 케이스 실현(realization)이 오퍼레이션을 사용하는 방법을 확인하기 위해 클래스가 참여하는 유스 케이스 실현을 연구하십시오. 오퍼레이션, 해당 설명, 리턴 유형 및 매개변수를 정제하여 한 번에 하나의 유스 케이스 실현씩 오퍼레이션을 확장하십시오. 클래스와 관련된 각 유스 케이스 실현의 요구사항이 유스 케이스 실현의 이벤트 플로우에서 텍스트로 설명됩니다.
  • 설명되는 오퍼레이션에 대한 내재적 요구사항을 놓치지 않도록 특별 요구사항 유스 케이스를 연구하십시오.

스크립트(아직 오퍼레이션에 지정되지 않은 임시 메시지 스펙)로 클래스가 수행할 것으로 예상되는 동작을 설명하므로 시퀀스 다이어그램에 나타나는 메시지를 지원하기 위한 오퍼레이션이 필요합니다. 그림 1은 시퀀스 다이어그램의 예제를 보여줍니다.

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

그림 1: 오퍼레이션 식별을 위한 기초를 형성하는 메시지

유스 케이스 실현은 모든 오퍼레이션을 식별하기에 충분한 정보를 제공하지는 않습니다. 나머지 오퍼레이션을 찾으려면 다음을 고려하십시오.

  • 클래스의 새 인스턴스를 초기화하는 방법이 있습니까(연관된 다른 클래스의 인스턴스에 연결 포함)?
  • 클래스의 두 인스턴스가 동일한지 확인하기 위해 테스트할 필요가 있습니까?
  • 클래스 인스턴스의 사본을 작성해야 할 필요가 있습니까?
  • 오퍼레이션이 사용하는 메커니즘으로 인해 클래스에 오퍼레이션이 필요합니까? 예를 들어 가비지 콜렉션 메커니즘에는 오브젝트가 다른 모든 오브젝트에 대한 모든 참조를 제거하여 사용되지 않는 모든 자원을 사용 가능하게 할 수 있어야 합니다.

단순히 공용 속성의 값을 가져오고 설정하는 오퍼레이션은 정의하지 마십시오(속성 정의연관 정의 참조). 대개 이들은 코드 생성 기능에 의해 생성되며 명시적으로 정의될 필요가 없습니다.

오퍼레이션 이름 지정 및 설명

오퍼레이션, 리턴 유형 및 매개변수와 해당 유형의 이름을 지정할 때 구현 언어에 대한 이름 지정 규칙을 사용하십시오. 이들은  프로젝트 가이드라인에 설명되어 있습니다.

각 오퍼레이션에 대해 다음을 정의해야 합니다.

  • 오퍼레이션 이름 - 오퍼레이션이 달성하는 결과를 나타내는 설명 형태의 짧은 이름을 유지하십시오.
    • 오퍼레이션의 이름은 구현 언어의 구문을 따라야 합니다. 예를 들어 find_location은 C++ 또는 Visual Basic의 경우 허용 가능하지만 Smalltalk(밑줄을 사용하지 않음)에서는 허용되지 않습니다. 모든 경우 더 좋은 이름은 findLocation입니다.
    • 오퍼레이션이 수행되는 방법을 의미하는 이름은 사용하지 마십시오. 예를 들어 Employee.wages()Employee.calculateWages()보다 낫습니다. 후자는 계산이 수행됨을 의미하기 때문입니다. 오퍼레이션은 단순히 값만 데이터베이스에 리턴할 수도 있습니다.
    • 오퍼레이션의 이름은 목적을 명확하게 표시해야 합니다. 오퍼레이션이 리턴하는 결과에 대한 설명이 아닌 불명확한 이름(예: getData)은 사용하지 마십시오. 예상되는 사항을 정확하게 보여주는 이름(예: getAddress)을 사용하십시오. 더 좋은 방법으로는 간단히 오퍼레이션 이름을 리턴되거나 설정되는 특성의 이름으로 하십시오. 매개변수가 있는 경우 특성을 설정합니다. 매개변수가 없는 경우 특성을 가져옵니다. 예를 들어 오퍼레이션 addressCustomer의 주소를 리턴하는 반면, address(aString)Customer의 주소를 설정하거나 변경합니다. 오퍼레이션의 getset 네이처는 오퍼레이션의 서명으로부터 내재적입니다.
    • 개념적으로 동일한 오퍼레이션은 서로 다른 클래스가 정의하는 경우, 완전히 다른 방법으로 구현되는 경우 또는 다른 매개변수 수를 갖는 경우에도 동일한 이름을 가져야 합니다. 예를 들어 오브젝트를 작성하는 오퍼레이션은 모든 클래스에서 동일한 이름을 가져야 합니다.
    • 여러 클래스의 오퍼레이션이 동일한 서명을 갖는 경우 오퍼레이션은 수신자 오브젝트에 적합한 동일한 종류의 결과를 리턴해야 합니다. 이것이 다형성(polymorphism) 개념의 예제이며 서로 다른 오브젝트가 동일한 메시지에 비슷한 방법으로 반응해야 함을 말합니다. 예를 들어 오퍼레이션 name은 이름이 저장되거나 파생되는 방법과 상관없이 오브젝트의 이름을 리턴해야 합니다. 이 원칙을 따르는 것이 모델을 보다 이해하기 쉽게 합니다.
  • 리턴 유형 - 리턴 유형은 오퍼레이션에 의해 리턴되는 오브젝트의 클래스여야 합니다.
  • 간단한 설명 - 가능한 의미있게 작성하십시오. 오퍼레이션의 이름은 종종 오퍼레이션이 수행하는 사항을 이해할 때만 약간 유용합니다. 오퍼레이션에 오퍼레이션 사용자의 관점에서 작성된 몇 개의 문장으로 구성된 간단한 설명을 제공하십시오.
  • 매개변수 - 각 매개변수에 대해 간단한 설명식 이름을 작성하고 해당 클래스를 결정하고 간략한 설명을 제공하십시오. 매개변수를 지정할 때 매개변수가 적을수록 재가용성이 더 좋음을 기억하십시오. 매개변수가 적으면 오퍼레이션을 더 이해하기 쉬워지며 따라서 비슷한 오퍼레이션을 찾을 가능성이 더 커집니다. 많은 매개변수를 갖는 오퍼레이션은 여러 오퍼레이션으로 구분해야 할 수 있습니다. 오퍼레이션은 해당 오퍼레이션을 사용하려는 사용자가 이해할 수 있어야 합니다. 간략한 설명은 다음을 포함해야 합니다.
    • 이름에서 명백하지 않은 경우 매개변수의 의미
    • 매개변수가 또는 참조에 의해 전달되는지 여부
    • 값이 제공되어야 하는 매개변수
    • 선택적인 매개변수 및 값이 제공되지 않는 경우 해당 기본값
    • 매개변수에 대한 올바른 범위(해당되는 경우)
    • 오퍼레이션에서 수행되는 내용
    • 참조별 매개변수가 오퍼레이션에 의해 변경되는 사항

오퍼레이션을 정의한 후 오퍼레이션이 각 메시지에 대해 호출되는 사항에 대한 정보로 시퀀스 다이어그램을 완성하십시오.

자세한 정보는 중간 산출물 가이드라인: 디자인 클래스라는 제목의 섹션을 참조하십시오.

오퍼레이션 가시성 정의

각 오퍼레이션에 대해 다음 선택사항에서 오퍼레이션의 내보내기 가시성을 식별하십시오.

  • Public - 오퍼레이션이 클래스 자체가 아닌 모델 요소에 가시적입니다.
  • Implementation - 오퍼레이션이 클래스 자체 내에서만 가시적입니다.
  • Protected - 오퍼레이션이 클래스 자체, 해당 서브클래스 또는 클래스의 동반자(언어 종속)에만 가시적입니다.
  • Private - 오퍼레이션이 클래스 자체와 클래스의 동반자에만 가시적입니다.

여전히 오퍼레이션의 목표를 수행할 수 있는 가능한 가장 제한된 가시성을 선택하십시오. 이를 수행하려면 시퀀스 다이어그램을 조사하고 각 메시지에 대해 메시지가 수신자 패키지의 밖에 있는 클래스(public 가시성 필요), 패키지의 내부(implementation 가시성 필요), 서브클래스(protected 가시성 필요) 또는 클래스 자체나 동반자(private 가시성 필요)로부터 오는지 여부를 판별하십시오.

클래스 오퍼레이션 정의

대부분의 파트에 대해 오퍼레이션은 파트 오퍼레이션입니다. 즉 클래스의 인스턴스에 대해 수행됩니다. 그러나 어떤 경우에는 오퍼레이션이 클래스의 모든 인스턴스에 적용되며 따라서 클래스 범위 오퍼레이션입니다. 클래스 오퍼레이션 수신자는 실제로 클래스의 어떤 특정 인스턴스가 아니라 메타클래스(클래스 자체의 설명)의 인스턴스입니다. 클래스 오퍼레이션 예제에는 클래스의 모든 인스턴스를 리턴하며 새 인스턴스를 작성(인스턴스화)하는 메시지가 포함됩니다.

오퍼레이션 문자열은 클래스 범위 오퍼레이션을 표시하기 위해 밑줄이 쳐집니다.

메소드 정의

메소드는 오퍼레이션의 구현을 지정합니다. 오퍼레이션에 필요한 동작이 오퍼레이션 이름, 설명 및 매개변수에 의해 충분히 정의되는 많은 경우에 메소드는 프로그래밍 언어에서 직접 구현됩니다. 오퍼레이션의 구현이 특정 알고리즘의 사용이나 오퍼레이션의 설명에 제공되는 것보다 많은 정보가 필요한 경우 별도의 메소드 설명이 필요합니다. 메소드는 오퍼레이션이 수행하는 내용과 오퍼레이션이 작업하는 방법을 설명합니다.

메소드는 다음을 수행하는 방법을 논의해야 합니다.

  • 오퍼레이션이 구현되는 방법
  • 속성이 구현되고 오퍼레이션을 구현하는 데 사용되는 방법
  • 관계가 구현되고 오퍼레이션을 구현하는 데 사용되는 방법

요구사항은 때에 따라 다르지만, 클래스에 대한 메소드 스펙은 항상 다음을 명시해야 합니다.

  • 요구사항에 따라서 수행되는 사항
  • 사용될 기타 오브젝트 및 해당 오퍼레이션

추가 특정 요구사항은 다음과 관계가 있을 수 있습니다.

  • 매개변수가 구현되는 방법
  • 사용될 특수 알고리즘(있는 경우)

시퀀스 다이어그램은 이를 위한 중요한 소스입니다. 이로부터 오퍼레이션이 수행될 때 기타 오브젝트에서 사용될 오퍼레이션이 명확해집니다. 기타 오브젝트에 사용될 오퍼레이션의 스펙은 오퍼레이션의 전체 구현을 위해 필요합니다. 따라서 완전한 메소드 스펙의 프로덕션을 위해 관련 오브젝트에 대한 오퍼레이션을 식별하고 해당 시퀀스 다이어그램을 조사해야 합니다.

상태 정의

일부 오퍼레이션의 경우 오퍼레이션 동작은 수신측 오브젝트가 있는 상태에 따라 다릅니다. 상태 머신은 오브젝트가 가정할 수 있는 상태와 오브젝트가 한 상태에서 다른 상태로 이동하게 하는 이벤트를 설명하는 도구입니다(기법: 상태 차트 다이어그램 참조). 상태 머신은 활성 클래스 설명에 가장 유용합니다. 상태 머신 사용은 특히  중간 산출물: 캡슐의 동작을 정의하는 데 특히 중요합니다.

단순 상태 머신의 예제가 그림 2에 표시되어 있습니다.

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

그림 2: 급유기에 대한 단순 상태 차트 다이어그램

각 상태 전이 이벤트를 오퍼레이션과 연관시킬 수 있습니다. 오브젝트 상태에 따라서 오퍼레이션은 다른 동작을 가질 수 있으며 전이 이벤트가 이 방법을 설명합니다.

연관된 오퍼레이션에 대한 메소드 설명은 오퍼레이션이 수행해야 하는 각 관련 상태에 대해 표시하는 상태 특정 정보로 갱신되어야 합니다. 상태는 보통 속성을 사용하여 표시됩니다. 상태 차트 다이어그램은 속성 식별 단계에 대한 입력으로 작용합니다.

자세한 정보는 기법: 상태 차트 다이어그램을 참조하십시오.

속성 정의

메소드의 정의와 상태의 식별 중에 클래스가 해당 오퍼레이션을 수행하기 위해 필요한 속성이 식별됩니다. 속성은 클래스 인스턴스에 대한 정보 저장영역을 제공하며 보통 클래스 인스턴스의 상태를 표시하는 데 사용됩니다. 클래스 자체가 유지보수하는 모든 정보는 해당 속성을 통해 수행됩니다. 각 속성에 대해 다음을 정의하십시오.

  • 이름. 이름은 구현 언어 및 프로젝트 모두의 이름 지정 규칙을 준수해야 합니다.
  • 유형. 구현 언어가 지원하는 기본 데이터 유형입니다.
  • 기본값 또는 초기값. 클래스의 새 인스턴스가 작성될 때 속성이 초기화되는 값입니다.
  • 가시성. 다음 값 중 하나를 갖습니다.
    • Public: 속성은 클래스를 포함하는 패키지 내부 및 외부 모두에서 가시적입니다.
    • Protected: 속성은 클래스 자체, 해당 서브클래스 또는 클래스의 동반자(언어에 종속됨)에서만 가시적입니다.
    • Private: 속성은 클래스 자체 및 클래스의 동반자에서만 가시적입니다.
    • Implemented: 속성은 클래스 자체에만 가시적입니다.
  • 지속적 클래스. 속성이 지속적(기본값) 또는 임시인지 여부를 표시합니다. 클래스 자체가 지속적일 수 있지만, 클래스의 모든 속성이 지속적일 필요는 없습니다.

모든 속성이 필요한지 확인하십시오. 속성을 필요성을 확인해야 합니다. 예상이 잘못되어 속성이 프로세스 초기에 추가되고 필요없게 된 후에도 오래 동안 남아있을 수 있습니다. 수천 또는 수백만 개의 인스턴스를 가지는 여분의 속성은 시스템의 성능 및 저장영역 요구사항에 해를 끼칠 수 있습니다.

속성에 대한 자세한 정보는 중간 산출물 가이드라인: 디자인 클래스에서 속성이란 제목의 섹션을 참조하십시오.

종속성 정의

오브젝트 사이의 커뮤니케이션이 필요한 각 경우 다음과 같이 질문하십시오.

  • 수신측에 대한 참조가 오퍼레이션에 대한 매개변수로 전달됩니까? 그렇다면 송신측과 수신측의 두 클래스를 포함하는 클래스 다이어그램에서 두 클래스 사이에 종속성을 설정하십시오. 또한 상호작용에 대한 커뮤니케이션 다이어그램 형식이 사용되는 경우 링크 가시성을 규정하고 이를 매개변수로 설정하십시오.
  • 수신측이 글로벌입니까? 그렇다면 송신측과 수신측의 두 클래스를 포함하는 클래스 다이어그램에서 두 클래스 사이에 종속성을 설정하십시오. 또한 상호작용에 대한 커뮤니케이션 다이어그램 형식이 사용되는 경우 링크 가시성을 규정하고 이를 글로벌로 설정하십시오.
  • 수신측이 오퍼레이션 자체 중에 작성되고 파괴되는 임시 오브젝트입니까? 그렇다면 송신측과 수신측의 두 클래스를 포함하는 클래스 다이어그램에서 두 클래스 사이에 종속성을 설정하십시오. 또한 상호작용에 대해 커뮤니케이션 다이어그램 형식이 사용되는 경우 링크 가시성을 규정하고 이를 로컬로 설정하십시오.

이 방법으로 모델링되는 링크는 임시 링크이며 협업의 특정 컨텍스트에서 제한된 지속 기간 동안만 존재합니다. 그런 의미에서 해당 링크는 협업에 있는 연관 역할의 인스턴스입니다. 그러나 클래스 모델의 관계(즉, 컨텍스트와 독립)는 앞에서 언급한 것처럼 종속성이어야 합니다. [RUM98]의 임시 링크의 정의에서 다음과 같이 설명합니다. "그런 모든 링크를 연관으로 모델링할 수 있지만, 그러면 연관에 대한 조건이 매우 광범위하게 명시되어야 하며 오브젝트의 제한 조합에서 상당한 정밀도를 잃습니다." 이 상황에서는 종속성이 관계를 완벽하게 설명하지 않기 때문에 종속성의 모델링은 협업에서의 관계 모델링보다 덜 중요합니다. 즉 단지 존재할 뿐입니다.

연관 정의

연관은 오브젝트가 서로 커뮤니케이션하는 메커니즘을 제공합니다. 오브젝트에 메시지가 이동할 수 있는 통로를 제공합니다. 또한 한 클래스에서의 변경을 많은 기타 클래스 사이에서 알 수 있음을 강조하여 클래스 사이의 종속성을 문서화합니다.

각 오퍼레이션에 대한 메소드 설명을 점검하여 클래스 인스턴스가 다른 오브젝트와 커뮤니케이션하고 협업하는 방법을 이해하십시오. 메시지를 다른 오브젝트로 보내려면 오브젝트가 메시지 수신자에 대한 참조를 가져야 합니다. 그림 3에서 커뮤니케이션 다이어그램(시퀀스 다이어그램의 대체 표시)은 링크의 형태로 오브젝트 커뮤니케이션을 보여줍니다.

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

그림 3: 커뮤니케이션 다이어그램 예제

연관 및 집계 정의

남은 메시지는 연관 또는 집계 중 하나를 사용하여 커뮤니케이션하는 두 클래스의 인스턴스 사이의 관계를 지정합니다. 적합한 표시 선택에 대한 정보는 기법: 연관기법: 집계를 참조하십시오. 이들 두 연관 모두에 대해 커뮤니케이션 다이어그램에서 링크 가시성을 필드로 설정하십시오. 기타 타스크에는 다음이 포함됩니다.

  • 연관 및 집계의 탐색성을 설정하십시오. 상호작용 다이어그램에서 링크 인스턴스화에서 필요한 탐색성을 고려하여 이를 수행할 수 있습니다. 탐색성은 기본적으로 true이기 때문에 연관에 있는 클래스의 모든 오브젝트의 모든 반대 링크 역할이 탐색성을 필요로 하지 않는 연관(및 집계)만 찾으면 됩니다. 해당하는 경우에 클래스의 역할에 대한 탐색성을 false로 설정하십시오.
  • 연관 자체(연관 클래스로 표시)에 대한 속성이 있는 경우 적합한 속성과 함께 연관 클래스를 표시하는 디자인 클래스를 작성하십시오. 다른 두 클래스 사이에 이 클래스를 삽입하고, 연관 클래스와 다른 두 클래스 사이에 적합한 다중성을 갖는 연관을 설정하십시오.
  • 연관 종료점정렬되어야 하는지 여부를 지정하십시오. 이는 연관의 반대쪽 끝에 있는 오브젝트와 연관된 오브젝트가 유지되어야 하는 순서 지정을 갖는 경우입니다.
  • 연관(또는 집계)된 클래스가 현재 클래스에 의해서만 참조되는 경우 클래스가 중첩되어야 하는지 여부를 고려하십시오. 클래스 중첩의 장점으로는 더 빠른 메시지 전달과 더 간단한 디자인 모델이 있습니다. 단점으로는 중첩된 클래스의 인스턴스가 있는지 여부와 상관없이 통계적으로 할당되는 중첩 클래스용 공간, 엔클로징 클래스와 별개인 오브젝트 ID의 부족 또는 엔클로징 클래스 밖에서 중첩된 클래스 인스턴스를 참조하지 못하는 기능이 포함됩니다.

연관 및 집계는 연관된 클래스를 보여주는 클래스 다이어그램에서 가장 잘 정의됩니다. 클래스 다이어그램은 연관된 클래스를 포함하는 패키지가 소유해야 합니다. 그림 4는 연관 및 집계를 보여주는 클래스 다이어그램의 예제를 표시합니다.

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

그림 4: 클래스 사이의 연관, 집계 및 일반화를 보여주는 클래스 다이어그램의 예제

분석 클래스 사이의 등록 연관 처리

분석 클래스 사이의 등록 연관은 클래스 사이의 이벤트 종속성을 식별하는 데 사용됩니다. 디자인 모델에서 사용 가능한 이벤트 핸들러 프레임워크를 사용하거나 사용자 자신의 이벤트 핸들러 프레임워크를 디자인하고 빌드하여 이러한 이벤트 종속성을 명시적으로 처리해야 합니다. 일부 프로그래밍 언어(예: Visual Basic)의 경우 해당 이벤트를 선언하고, 발생시키고, 처리하는 직접적인 방식으로 수행됩니다. 기타 언어에서는 등록 및 이벤트를 처리하기 위해 재사용가능 기능의 일부 추가 라이브러리를 사용해야 할 수 있습니다. 해당 기능성을 구입할 수 없는 경우 이를 디자인하고 빌드해야 합니다. 기법: 등록 연관도 참조하십시오.

내부 구조 정의

일부 클래스는 복잡한 추상을 표시하고 구조가 복잡합니다. 클래스를 모델링하는 중 디자이너가 내부 참여 요소 및 관계를 표시할 수 있습니다. 그러면 이에 따라 구현자가 해당 클래스 내부에서 발생하는 협업을 구현합니다.

UML 2.0에서 클래스는 내부 구조 및 포트를 포함하는 기능이 있는 구조화된 클래스로 정의됩니다. 이후 클래스는 연결된 파트의 콜렉션(나중에 차례대로 분해될 수 있음)으로 분해될 수 있습니다. 선언된 인터페이스를 따르는 포트를 통과하도록 외부에서 커뮤니케이션을 강제 실행하여 클래스를 캡슐화할 수 있습니다.

복잡한 구조를 갖는 복합 클래스를 찾을 경우 해당 클래스에 대한 컴포지트 구조 다이어그램을 작성하십시오. 해당 클래스 동작에 대한 역할을 수행할 파트를 모델링하십시오. 커넥터를 사용하여 파트가 함께 연결되는 방법을 설정하십시오. 해당 클래스의 여러 클라이언트가 해당 클래스가 제공하는 동작의 특정 부분에 액세스할 수 있게 하려는 경우 선언된 인터페이스를 가지는 포트를 사용하십시오. 또한 포트를 사용하여 해당 클래스의 내부 파트를 환경에서 완전히 분리하십시오.

이 주제에 대한 자세한 정보 및 컴포지트 구조 다이어그램에 대한 예제는 개념: 구조화된 클래스를 참조하십시오.

일반화 정의

클래스를 공통 동작 및 공통 구조를 반영하기 위해 일반화 계층으로 구성할 수 있습니다. 서브클래스가 동작과 구조를 둘 다 상속할 수 있는 공통 수퍼 클래스를 정의할 수 있습니다. 일반화는 한 위치에서 공통 구조 및 동작을 정의하고 반복되는 동작과 구조를 찾는 경우에 재사용할 수 있게 해주는 표기상의 편의성입니다. 일반화 관계에 대한 자세한 정보는 기법: 일반화를 참조하십시오.

일반화를 찾을 경우 공통 속성, 연관, 집계 및 오퍼레이션을 포함할 공통 수퍼 클래스를 작성하십시오. 공통 수퍼 클래스의 서브클래스가 될 클래스에서 공통 동작을 제거하십시오. 서브클래스에서 수퍼 클래스로의 일반화 관계를 정의하십시오.

유스 케이스 충돌 분석

이 단계의 목적은 잠재적으로 둘 이상의 유스 케이스가 일관되지 않은 방법으로 디자인 클래스의 인스턴스에 동시에 액세스할 수 있을 때 유발되는 동시성 충돌을 막는 것입니다.

디자인 프로세스를 통한 유스 케이스별 처리의 어려움 중 하나는 둘 이상의 유스 케이스가 충돌할 가능성이 있는 방법으로 디자인 오브젝트의 오퍼레이션을 동시에 호출하려고 할 수 있다는 점입니다. 이러한 경우 동시성 충돌을 명시적으로 식별하고 해결해야 합니다.

동기 메시지가 사용되는 경우 오퍼레이션을 실행하면 해당 오퍼레이션이 완료될 때까지 후속 호출이 차단됩니다. 동기 메시지는 메시지 처리 시 선입 선처리 순서를 의미합니다. 이를 통해 특히 모든 메시지가 동일한 우선순위를 갖거나 모든 메시지가 동일한 실행 스레드 내에서 실행하는 경우에 동시성 충돌을 해결할 수 있습니다. 다른 실행 스레드(활성 클래스로 표시되는)가 오브젝트에 액세스할 수 있는 경우 동시성 충돌을 막거나 해결하기 위해 명시적 메커니즘을 사용해야 합니다.

스레드가  중간 산출물: 캡슐로 표시되는 실시간 시스템에서 이 문제점은 여전히 수동 오브젝트에 대한 복수 동시 액세스를 위해 해결되어야 하는 반면, 캡슐 자체는 대기열 메커니즘을 제공하며 동시 액세스를 처리하기 위해 RTC(Run-to-completion) 시맨틱을 강제합니다. 권장 솔루션은 수동 오브젝트를 캡슐 안에 캡슐화하는 것이며, 이는 캡슐 자체의 시맨틱을 통한 동시 액세스 문제점을 피합니다.

동일한 오브젝트의 서로 다른 오퍼레이션이 동시성 충돌 없이 여러 실행 스레드에 의해 동시에 호출될 수도 있습니다. 한 고객의 이름과 주소 모두를 충돌 없이 동시에 수정할 수 있습니다. 충돌이 발생하는 경우는 두 가지 실행 스레드가 오브젝트의 동일한 특성을 수정하려 시도할 때 뿐입니다.

여러 실행 스레드가 동시에 액세스할 수 있는 각 오브젝트의 경우 동시 액세스로부터 보호되어야 하는 코드 섹션을 식별하십시오. 정제(Elaboration) 단계의 초기에 특정 코드 세그먼트의 식별은 불가능합니다. 보호되어야 하는 오퍼레이션으로 충분합니다. 다음으로, 동시 액세스 충돌을 막기 위해 적합한 액세스 제어 메커니즘을 선택하거나 디자인하십시오. 이러한 메커니즘의 예제에는 액세스를 직렬화하기 위한 메시지 대기열에 넣기, 한 번에 한 스레드만 액세스하도록 허용하기 위한 세마포어 또는 토큰의 사용 또는 잠금 메커니즘의 기타 변형이 포함됩니다. 메커니즘 선택사항은 구현에 종속되는 경향이 크며 일반적으로 프로그래밍 언어 및 운영 환경에 따라서 달라집니다. 동시성 메커니즘 선택에 대한 안내는  프로젝트 가이드라인을 참조하십시오.

일반적인 비기능적 요구사항 처리

디자인 클래스는 일반적인 비기능적 요구사항을 처리하도록 정제됩니다. 이 단계의 중요한 입력에는 이미 특별 요구사항 및 책임에 명시되었을 수 있는 분석 클래스에 대한 비기능적 요구사항이 포함됩니다. 그런 요구사항은 종종 클래스를 실현하기 위해 필요한 아키텍처(분석) 메커니즘의 형태로 지정됩니다. 이 단계에서 클래스는 이러한 분석 메커니즘에 해당하는 디자인 메커니즘을 통합하기 위해 정제됩니다.

사용 가능한 디자인 메커니즘은 소프트웨어 설계자에 의해 식별되고 특성화됩니다. 필요한 각 디자인 메커니즘에 대해 가능한 많은 특성을 규정하여 적당한 범위를 제공하십시오. 디자인 메커니즘에 대한 자세한 정보는 타스크: 디자인 메커니즘 식별, 개념: 분석 메커니즘개념: 디자인 및 구현 메커니즘을 참조하십시오.

다음과 같이 클래스를 디자인할 때 고려해야 하는 여러 가지 일반 디자인 가이드라인 및 메커니즘이 있습니다.

  • 기존 제품 및 컴포넌트 사용
  • 프로그래밍 언어에 적응
  • 오브젝트 분배
  • 허용 가능한 성능 달성
  • 특정 보안 레벨 달성
  • 오류 처리
결과 평가

이 단계에서 디자인 모델을 확인하여 사용자 작업이 올바른 방향으로 진행되는지 확인하십시오. 모델을 자세히 검토할 필요는 없지만 다음 체크리스트를 고려해야 합니다.



자세한 정보