체크리스트: 디자인 클래스
이 체크리스트를 사용하면 디자인 클래스가 올바르게 모델링되었는지를 확인할 수 있습니다.
관계
기본 설명


검사 항목
일반
  • 클래스 이름은 클래스가 수행하는 역할을 정확히 반영합니다.
  • 클래스 설명은 클래스의 목적을 명확히 나타냅니다.
  • 클래스는 잘 정의된 단일 추상을 나타냅니다.
  • 클래스 속성 및 오퍼레이션은 모두 클래스의 책임을 수행하는 데 필요합니다.
  • 각 클래스는 소규모의 일관적이고 고유한 책임 세트를 나타냅니다.
  • 클래스의 책임은 잘 정의되고 명확하게 내용을 설명하며 클래스의 목적과 밀접한 관련이 있습니다.
  • 각 클래스는 상대적으로 자체 구성을 갖추고 있으며 다른 클래스와 약한 결합 상태를 유지합니다.
  • 클래스 책임의 추상 레벨은 일관적입니다. (상위 레벨(응용프로그램 레벨)과 하위 레벨(구현 레벨) 책임은 혼합되지 않습니다.)
  • 동일한 상속 계층 구조의 클래스는 고유한 클래스 속성, 오퍼레이션 및 관계를 소유합니다. (모든 공통 속성, 오퍼레이션 및 관계를 상속합니다.)
  • 클래스 인스턴스의 전체 라이프사이클에 대해 설명합니다. 각 오브젝트는 하나 이상의 유스 케이스 실현(realization)에 의해 작성, 사용 및 제거됩니다.
  • 클래스는 유스 케이스 실현(realization)으로 설정된 동작 요구사항을 충족시킵니다.
  • 요구사항 스펙에 포함된 클래스에 대한 모든 요구사항을 처리합니다.
  • 클래스에 대한 수요(클래스 설명에 반영되며 시퀀스 다이어그램의 오브젝트에 의함)는 클래스의 상태 머신과 일치합니다.
  • 클래스의 모든 책임은 서로 관련이 있으며 해당 책임의 일부를 사용하고 나머지 책임을 사용하지 않는 시스템에 클래스가 존재할 수 없습니다.
  • 두 개의 클래스가 반드시 동일한 목적을 가질 필요는 없습니다.
일반화/전문화
  • 일반화 계층 구조는 밸런스가 조절되어 계층 구조가 비정상적으로 평평하거나 깊은 클래스가 없습니다.
  • 상속 계층에 분명한 공통성이 반영되었습니다.
  • 서브클래스 속성의 병합으로 보이는 수퍼 클래스는 없습니다.
  • 상속 트리의 양측에 중복 서브클래스를 포함하는 예제, 직각 특성이 있는 상속 계층 구조에 중간 추상 클래스가 없습니다.
  • 상속은 구현 고려사항이 아닌 공통 디자인 추상을 캡처하는 데 사용됩니다(예: 코드 또는 클래스 구조의 비트를 재사용하기 위해).
이름 지정 규칙
  • 클래스 이름은 목적을 표시합니다.
  • 클래스 이름은 프로젝트 디자인 가이드라인에 지정된 이름 지정 규칙을 따릅니다.
오퍼레이션
  • 각 오퍼레이션의 이름은 설명적이며 쉽게 이해할 수 있습니다.
  • 상태 머신과 오퍼레이션은 일치합니다.
  • 상태 머신과 오퍼레이션은 클래스 동작에 대해 완벽하게 설명합니다.
  • 각 오퍼레이션의 매개변수는 숫자, 이름 및 유형 면에 있어 정확합니다.
  • 각 오퍼레이션에 대한 구현 스펙은 올바릅니다(정의된 경우).
  • 오퍼레이션 서명은 대상 프로그래밍 언어의 표준을 준수합니다.
  • 각 오퍼레이션은 최소 하나의 유스 케이스 실현(realization)에서 사용합니다.
속성
  • 클래스의 모든 관계는 클래스의 특정 오퍼레이션을 지원하는 데 필요합니다.
  • 각 속성은 단일 개념 사항을 나타냅니다.
  • 각 속성의 이름은 설명적이며 속성에 저장된 정보를 정확하게 전달합니다.
관계
  • 집계 및 연관의 역할 이름은 연관 클래스 및 연관된 클래스 간의 관계에 대해 설명합니다.
  • 관계의 다중성이 올바릅니다.
상태 머신
  • 상태 머신은 필수 동작을 나타내면서도 최대한 단순합니다.
  • 상태 머신에는 불필요한 상태 또는 전이가 포함되지 않습니다.
  • 상태 머신에는 명확한 컨텍스트가 있습니다.
  • 모든 참조 오브젝트는 포함 오브젝트에서 볼 수 있습니다.
  • 상태 머신은 호율적이며 시스템이 디스패치하는 조치에서 정의되는 대로 시간 및 자원의 밸런스를 최적화하여 해당 동작을 수행합니다.
  • 상태 머신은 쉽게 이해할 수 있습니다.
    • 상태 및 전이 이름을 시스템 도메인의 컨텍스트에서 쉽게 이해할 수 있습니다.
    • 상태 이름은 이미 발생한 내용이 아닌 현재 발생하고 있는 내용 또는 대기 중인 내용을 표시합니다.
    • 상태 및 전이 이름은 상태 머신에서 고유합니다. (엄격한 요구사항은 아니지만 고유한 이름을 강제하는 디버깅에 유용합니다.)
    • 상태의 논리적 분류는 컴포지트 상태에 포함됩니다.
    • 컴포지트 상태를 효과적으로 사용하여 복잡도를 줄였습니다.
    • 전이 레이블은 전이의 기본 원인을 반영합니다.
    • 세부 코드가 25행이 넘는 상태 전이에 대한 코드 단편은 없습니다. 대신 함수를 사용하여 전이 코드 복잡도를 효과적으로 줄였습니다.
    • 중첩 깊이를 파악할 수 있도록 상태 시스템 중첩을 점검했습니다. 대부분의 복잡한 동작에도 일반적으로 하나 또는 두 가지 하위 상태 레벨이면 충분합니다.
  • 동시적 하위 상태 대신 활성 클래스를 사용했습니다. 활성 클래스는 대부분의 경우 동시 하위 상태보다 쉽게 이해할 수 있는 바람직한 대안입니다.
  • 실시간 시스템의 경우, 캡슐을 사용하여 논리적 제어 스레드를 나타냈습니다.
  • 오류 또는 유지보수 상태에 대해 설명했습니다.
  • 확장 상태 변수 대신 하위 상태를 사용했습니다. 몇 가지 변수를 테스트하여 전이가 발생해야 하는 상태를 판별하는 전이 보호 조건에 대한 증거가 없습니다.
  • 상태 머신은 플로우 차트와 다릅니다.
  • 상태 머신은 하위 상태가 단일 중첩 상태 머신으로 구성되어 구조가 많이 복잡하지 않습니다. 중첩된 하위 상태가 향후 디자인 작업 또는 서브클래스 작성을 위한 플레이스홀더이며, 이는 올바른 선택을 한 경우, 일시적으로 허용 가능할 수 있습니다.