타스크: 캡슐 디자인
이 타스크는 캡슐 디자인의 특성에 대해 설명합니다.
원칙: 분석 및 디자인
목적
  • 캡슐에 대한 설명을 정제합니다.
관계
역할기본 수행자: 추가 수행자:
입력필수:
    선택사항:
      출력
        프로세스 사용법
        기본 설명

        캡슐은 시스템의 동시 실행 스레드를 정의하는 데 사용되며, 디자인(수동) 클래스에 대한 연관을 가질 뿐 아니라 임의의 깊이까지 중첩될 수 있습니다. 이 활동은 각 캡슐당 한 번만 수행되며 이 타스크의 범위 내에서 식별된 새 캡슐을 포함합니다.

         UML 2.0 표시

        현재 캡슐의 RUP 표시는 UML 1.5 표기법에 기반함에 유의하십시오. 대부분은 개념: 구조화된 클래스를 사용하여 UML 2.0으로 표시될 수 있습니다.

        자세한 정보는 UML 1.x 및 UML 2.0의 차이점을 참조하십시오.

        단계
        포트 작성 및 프로토콜에 바인드

        초기 포트 클래스 세트를 작성하는 캡슐의 책임을 고려하십시오. 이러한 포트 클래스는 캡슐에 대한 '인터페이스'를 나타냅니다. 포트 클래스는 중간 산출물: 프로토콜을 실현(realization)한 것으로, 캡슐과 통신하는 데 사용되는 일련의 입력출력 신호를 차례로 나타냅니다.

        포트를 작성할 때 체크리스트: 프로토콜을 고려하여 프로토콜이 적합한지 여부를 판별하십시오. 포트는 한 개의 관련 책임 세트를 반영하므로 유사한 범위의 프로토콜이 있으면 여러 캡슐에서 이를 재사용할 수 있습니다. 적절한 프로토콜을 선택한 후에는 포트를 적절한 프로토콜에 바인드하십시오.

        캡슐 상호작용 유효성 검증

        포트가 프로토콜에 바인드된 후에는 캡슐의 외부 동작을 평가하고 이 동작의 유효성을 검증해야 합니다. 수동 둘러보기 기법이나 자동 시뮬레이션 도구로 캡슐 동작을 사용할 이벤트를 시뮬레이션하여 캡슐의 동작을 테스트하십시오. 유효성 검증은 또한 디자인 중인 캡슐과 상호작용할 캡슐도 고려합니다. 자동화된 도구를 사용하여 포트를 테스트할 수 있는 스텁 코드를 캡슐 내에 작성하십시오. 프로토콜/포트 정의 또는 캡슐 책임에서 오류가 발견될 경우 캡슐, 포트 및 프로토콜 정의를 적절히 변경하십시오.

        캡슐 상태 머신 정의

        캡슐 포트와 프로토콜의 유효성을 검증한 후에는 캡슐의 내부 동작을 정의하십시오. 캡슐의 동작은 상태 차트 다이어그램을 사용하여 정의되었습니다. 가이드라인: 상태 차트 다이어그램을 참조하십시오. 기타 캡슐 정보는 가이드라인: 캡슐 , 체크리스트: 캡슐에서 얻을 수 있습니다.

        상태 정의

        먼저 캡슐이 존재할 수 있는 상태를 식별하십시오. 상태는 고유해야 하며(한 캡슐이 두 개의 상태를 동시에 가질 수 없음) 설명적이어야 합니다. 자세한 내용은 해당 가이드라인과 체크포인트를 참조하십시오.

        상태 전이 정의

        상태를 정의한 후에는 상태 간 전이를 고려하십시오. 전이 코드는 상위 레벨 응용프로그램 의사 코드처럼 읽어야 하며, 주로 실시간 운영 체제 서비스 호출(예: 프레임 서비스, 시간 서비스, 포트 오퍼레이션, 캡슐 오퍼레이션, 수동 클래스 오퍼레이션)로 구성되어야 합니다.

        캡슐 전이에 세부 코드를 추가할 때 다음을 고려하십시오.

        • 코드가 다른 전이에 유용할 경우 해당 코드를 캡슐 오퍼레이션에 위임하는 것을 고려하십시오.
        • 코드가 캡슐의 책임을 준수하는 기능을 구현할지 여부를 고려하십시오.

        캡슐 오퍼레이션을 정의할 때 다음을 고려하십시오.

        • 캡슐 전이에서 언제든지 해당 기능을 사용할 수 있는지 여부 및 수행 중인 작업이 시스템의 다른 곳에서도 유용한지 여부를 고려하십시오. 그럴 경우 수동 클래스 기능으로 위임을 고려하십시오.
        • 코드가 너무 응용프로그램에 한정되어 있어서 특정 데이터 클래스에 저장할 수 없는 경우, 추가 데이터 클래스를 해당 코드에 대한 추상으로 작성할 것을 고려하십시오.
        • 코드가 데이터 구조 조작(예: 목록 유지보수)을 처리하거나 복잡한(여러 행) 계산을 수행하는 경우 해당 코드는 데이터 클래스로 분류되어야 합니다.
        수동 클래스에 대한 요구사항 정의

        캡슐 상태 머신을 기반으로 캡슐에서 참조하는 수동 클래스를 검사하십시오. 이러한 클래스에 대한 새 요구사항이 있을 경우 변경 요청을 생성하여 필요한 변경사항을 적용해야 합니다. 새 클래스가 식별된 경우, 이러한 클래스에 대한 요구사항(가장 명확하게 말하면 이러한 클래스에 대한 필수 오퍼레이션)을 함께 수집하여 클래스를 작성해야 합니다. 이러한 클래스는 타스크: 클래스 디자인에 자세히 설명되어 있습니다.

        캡슐 상속 도입

        캡슐 상속은 다형성을 사용하고 구현을 재사용하는 일반화/전문화를 구현합니다. 여기서 키워드는 '구현'인데, 이는 주로 캡슐의 외부 동작이 아닌 캡슐의 내부 구조를 재사용하는 데 사용되는 기법입니다.

        상속은 대개 단순 디자인 기법을 사용하여 보다 쉽게 얻을 수 있는 어떤 항목을 얻는 데 잘못 적용됩니다.

        일반화/전문화에 대한 상속 사용

        상속의 유형에는 세 가지가 있습니다. 복잡도가 가장 낮은 유형(가장 바람직함)에서 가장 복잡한 유형(가장 바람직하지 않음) 순서로 나열하면 다음과 같습니다.

        • 인터페이스 상속 - 가장 바람직한 상속 유형으로, 포트와 프로토콜만 상속합니다.
        • 구조적 상속 - 인터페이스와 구조적 포함 계층 구조를 포함합니다(프레임워크에 유용).
        • 동작 상속 - 인터페이스와 구조적 상속 이외에 동작 코드와 상태 머신도 재사용합니다.

        구조적 상속과 동작 상속의 몇 가지 문제점은 다음과 같습니다.

        • 상속이 제공하는 결합의 정도가 매우 강력하여 수퍼 클래스를 변경하면 서브클래스도 연쇄적으로 변경됩니다.
        • 서브클래스에서 수퍼 클래스의 동작과 구조를 대체하거나 삭제해야 한다는 것은 상속이 부적절하게 사용(일반적으로 전략적 코드 재사용)되었음을 나타냅니다. 보다 적절한 전략은 클래스와 캡슐을 리팩토링하고 위임을 적절하게 사용하는 것입니다.
        • 상속은 디자인 결정사항을 클래스 계층 구조 위쪽으로 이동하는 것을 의미하므로 디자인 및 컴파일 종속성이 바람직하지 않게 될 수 있습니다. 

        기타 문제점은 다음과 같습니다.

        • 모든 사용 상황에서 결정사항이 부적절할 수 있습니다.
        • 디자인 요소가 보다 밀접하게 결합되었기 때문에 상속 도입은 실제로 재사용을 더욱 어렵게 만듭니다.
        • 결정사항을 무효화하는 새 요구사항이 더 큰 문제점을 야기하기 때문에 디자인이 더 잘 깨집니다.
        • 디자인은 보상을 위해 매우 융통적이어야 하는데 이는 매우 어렵습니다. 이러한 노력이 디자인을 재사용이 가능한 프레임워크로 만듭니다.

        구조/동작을 포함하는 모든 디자인에는 명시적 또는 암시적으로 작성된 결정사항과 가정이 있습니다. 중요한 질문은 '결정사항/가정이 항상 올바르다고 절대적으로 확신합니까? 확신하지 않을 경우 이를 제거하기 위해 또는 이를 변경하기 위해 무엇을 할 수 있습니까?'입니다.

        캡슐 동작 유효성 검증

        마지막 단계로 캡슐의 동작을 평가하고 이 동작의 유효성을 검증해야 합니다. 수동 둘러보기 기법이나 자동 시뮬레이션 도구로 캡슐 동작을 사용할 이벤트를 시뮬레이션하여 캡슐의 동작을 테스트해야 합니다. 또한 캡슐 내부 구조의 유효성을 검증하여 외부 동작뿐 아니라 외부 동작의 내부 구현에 대한 유효성도 검증해야 합니다. 자동화된 도구를 사용하여 수동 데이터 클래스와 캡슐이 상호작용하는 외부 캡슐의 구현을 시뮬레이션하는 스텁 코드를 작성해야 할 수도 있습니다. 발견된 결함은 문서화하고 캡슐 정의는 적절하게 변경해야 합니다.

        자세한 정보