타스크: 유스 케이스 디자인
이 타스크는 디자인 레벨 유스 케이스 실현(realization)을 개발하여 유스 케이스 분석 제품을 정제하는 방법을 정의합니다.
원칙: 분석 및 디자인
목적
  • 상호작용을 통해 유스 케이스 실현(realization) 정제
  • 디자인 클래스 오퍼레이션 요구사항 정제
  • 디자인 서브시스템 및/또는 해당 인터페이스 오퍼레이션 요구사항 정제
  • 캡슐 오퍼레이션 요구사항 정제
관계
기본 설명

시스템 동작은 협업 또는 상호작용과 같은 여러 기법을 사용하여 설명됩니다. 이 타스크는 상호작용, 특히 시퀀스 다이어그램을 사용하여 시스템 동작을 설명합니다. 시퀀스 다이어그램은 시스템 또는 서브시스템의 동작이 동기 메시지 전달로 주로 설명될 수 있는 경우 매우 유용합니다. 특히 이벤트 기반 시스템에서 비동기 메시지는 오브젝트 간의 가능한 상호작용을 정의하는 단순한 방법이 허용되는 상태 머신 및 협업을 통해 더 쉽게 설명되는 경우가 종종 있습니다. 비동기 메시지는 실시간 또는 반응 시스템에서 중요한 역할을 수행하며 중간 산출물: 캡슐 인스턴스 통신에 사용됩니다.

 UML 1.x 표시

프록시 클래스를 사용하여 시퀀스 다이어그램의 서브시스템을 표시할 수 있습니다. 프록시 클래스는 서브시스템에 포함되며 작동 요소로 패키지 및 서브시스템의 직접 사용을 지원하지 않는 다이어그램에서 서브시스템을 표시합니다. 특정 서브시스템이 메시지에 응답함을 표시하려는 경우에 프록시 클래스를 사용하십시오. 이 경우 서브시스템 프록시에서 기타 오브젝트로 송신 중인 메시지를 표시할 수 있습니다.

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

단계
유스 케이스 실현(realization) 작성

중간 산출물: 디자인 유스 케이스 실현에서는 디자인 모델 동작을 다시 유스 케이스 모델로 추적하는 방법을 제공하며 디자인 모델의 협업을 디자인 모델 개념으로 조직합니다.

디자인 모델의 디자인 유스 케이스 실현을 디자인할 각 유스 케이스에 대해 작성하십시오. 디자인 유스 케이스 실현의 이름은 연관된 유스 케이스와 동일해야 하며 "실현" 관계는 유스 케이스 실현에서 연관된 유스 케이스로 작성되어야 합니다.

디자인 오브젝트 상호작용 설명

각 유스 케이스 실현에 대해 하나 이상의 시퀀스 다이어그램을 작성하여 해당 참여 디자인 오브젝트의 상호작용을 설명해야 합니다. 초기 버전은 타스크: 유스 케이스 분석 중에 작성되었습니다. 유스 케이스 실현의 "분석 버전"은 분석 클래스의 상호작용을 설명합니다. 해당 버전은 디자인 요소의 상호작용 설명을 위해 발전해야 합니다.

시퀀스 다이어그램 갱신은 다음 단계와 연관됩니다.

  • 유스 케이스 플로우에 참여하는 각 오브젝트를 식별하십시오. 이 작업은 타스크: 디자인 요소 식별에 식별된 디자인 클래스 및 서브시스템을 인스턴스화하여 수행됩니다. 실시간 시스템에서는 유스 케이스 플로우에 참여하는 캡슐 인스턴스도 식별하게 됩니다.
  • 시퀀스 다이어그램에 각 참여 오브젝트를 표시하십시오. 시퀀스 다이어그램에 각 참여 오브젝트의 라이프라인을 작성하십시오. 디자인 서브시스템 표시 시 다음과 같은 선택사항이 제공됩니다.
    • 시퀀스 다이어그램에 서브시스템 인스턴스를 표시할 수 있습니다.
    • 서브시스템에서 실현된 인터페이스를 사용할 수 있습니다. 동일한 인터페이스를 실현하는 임의의 모델 요소가 인터페이스 대신 사용됨을 표시하려는 경우에 사용하면 좋습니다. 시퀀스 다이어그램에 인터페이스를 표시하도록 선택한 경우 인터페이스에서 기타 오브젝트로 메시지가 송신되지 않도록 합니다. 이는 인터페이스가 해당 오퍼레이션의 내부 실현을 완전하게 캡슐화하기 위해 필요합니다. 따라서, 인터페이스를 실현하는 모든 모델 요소가 실제로 동일한 방식으로 디자인되는지 확인할 수가 없습니다. 그렇기 때문에 시퀀스 다이어그램에 인터페이스에서 송신되는 메시지를 표시하지 않아야 합니다.
    • 컴포넌트를 사용하여 시퀀스 다이어그램에 서브시스템을 표시할 수 있습니다. 특정 서브시스템이 메시지에 응답함을 표시하려는 경우에 컴포넌트 사용하십시오. 이 경우 컴포넌트에서 기타 오브젝트로 송신하는 메시지를 표시할 수 있습니다.

    이는 시스템 레벨 시퀀스 다이어그램으로 최상위 레벨 디자인 요소의 인스턴스(일반적으로 서브시스템 및 서브시스템 인터페이스)가 상호작용하는 방법을 표시합니다. 서브시스템의 내부 디자인을 표시하는 시퀀스 다이어그램은 타스크: 서브시스템 디자인의 파트로 독립적으로 작성됩니다.

  • 활성 오브젝트 상호작용은 일반적으로 스펙 협업 및 상태 머신을 사용하여 설명됩니다. 여기에서 상호작용은 대규모 유스 케이스 실현(realization)의 시스템에서 기타 요소가 메시지를 활성 오브젝트로 송신하는 방법을 표시하기 위해 사용됩니다. 일반적인 사용 시 활성 오브젝트는 이 타스크를 위해 서브시스템에서 캡슐화되어 유스 케이스 실현이 상호작용 서브시스템 세트로 구성됩니다. 상호작용은 서브시스템의 책임 및 인터페이스를 정의합니다. 서브시스템에서 활성 오브젝트는 실행의 동시 스레드를 표시합니다. 서브시스템은 팀 간의 정규 계약으로 수행되는 인터페이스를 사용하여 작업을 개발 팀으로 나눌 수 있게 합니다. 실시간 시스템의 경우 중간 산출물: 캡슐을 사용하여 활성 오브젝트를 표시합니다.

    서브시스템에서 나오는 메시지 표시에 대한 추가 참고: 메시지를 인터페이스로 제한하면 모델 요소 간 결합이 줄고 디자인의 탄력성이 개선됩니다. 가능하면 이런 방식이 좋지만 서브시스템에서 나오는 메시지가 비인터페이스 모델 요소로 송신되는 경우 해당 메시지를 인터페이스로 변경하여 모델에서 결합되지 않도록 해야 합니다.

  • 액터로 수행하는 상호작용을 표시하십시오. 시퀀스 다이어그램의 라이프라인 옆에 참여 오브젝트가 상호작용하는 각 액터 인스턴스 및 외부 오브젝트를 표시하십시오.
  • 참여 오브젝트에서 송신되는 메시지를 표시하십시오. 이벤트 플로우는 다이어그램 맨 위에서 시작되어 아래 방향으로 계속되어 세로 방향으로 시간축이 표시됩니다. 라이프라인 사이에 메시지(화살표)를 작성하여 오브젝트에서 송신되는 메시지를 표시하십시오. 메시지 이름은 메시지에서 호출되는 오퍼레이션 이름이어야 합니다. 디자인 초반에는 그리 많은 오퍼레이션이 오브젝트에 지정되지 않으므로, 해당 정보를 생략하고 메시지에 "지정되지 않음"과 같은 임시 이름을 지정할 수 있습니다. 나중에 참여 오브젝트 오퍼레이션이 더 많아지면 메시지를 해당 오퍼레이션에 "지정"하여 시퀀스 다이어그램을 갱신해야 합니다.
  • 오브젝트가 메시지를 수신할 때 수행하는 작업을 설명하십시오. 이는 해당 메시지에 스크립트를 첨부하여 수행할 수 있습니다. 해당 스크립트를 다이어그램의 여백에 위치시키십시오. 구조화된 텍스트 또는 pseudo 코드를 사용하십시오. 의사 코드를 사용하는 경우 구현 언어에 구조를 사용하여 해당 오퍼레이션 구현이 쉬워지도록 하십시오. 오브젝트 클래스를 책임지는 사용자가 해당 오퍼레이션을 지정 및 정의하는 경우, 오브젝트 스크립트에서 해당 작업의 기초가 제공됩니다.

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

시퀀스 다이어그램 오브젝트에서 수행되는 유스 케이스 동작을 문서화합니다.

오브젝트에 동작을 분배하는 경우 플로우를 제어하는 방법을 고려해야 합니다. 풀로우가 유스 케이스 실현(realization)에서 특정 방식으로 상호작용하고 특정 역할이 지정되어 있다고 간주한 상태에서 오브젝트를 찾습니다. 동작을 분배하면서여 해당 가정을 테스트하기 시작합니다. 플로우의 일부 파트에서는 분산된 구조를 사용하고 다른 파트에서는 중앙 집중식의 구조를 사용할 수 있습니다. 해당 변형의 정의 및 두 유형의 구조 사용 시기에 대한 권장사항은 기법: 시퀀스 다이어그램을 참조하십시오.

이 시점에 새 오브젝트가 필요할 수도 있습니다. 예를 들어 중앙 집중식 구조를 사용하는 경우 플로우 제어용 새 오브젝트가 필요할 수 있습니다. 디자인 모델에 추가하는 모든 오브젝트는 오브젝트 모델에 작성된 요구사항을 준수해야 합니다.

적용 가능한 디자인 메커니즘 통합

타스크: 아키텍처 분석 시에 분석 메커니즘이 식별됩니다. 타스크: 디자인 메커니즘 식별 시에 분석 메커니즘이 디자인 메커니즘으로 정제되고 분석 메커니즘에서 디자인 메커니즘으로의 맵핑이 소프트웨어 아키텍처 문서에 캡처되며 디자인 메커니즘은 프로젝트 고유 가이드라인에 문서화됩니다.  

유스 케이스 디자인 타스크를 수행하는 동안 적용 가능한 전체 디자인 메커니즘이 유스 케이스 실현(realization)에 통합됩니다. 디자이너는 사용 가능한 디자인 메커니즘을 조사하고 개발 중인 유스 케이스 실현에 적용되는 메커니즘을 소프트웨어 아키텍처 문서 및 디자인 가이드라인에 문서화된 권장사항 및 가이드라인을 참조하여 결정합니다.  
참고: 분석 클래스가 특정 분석 메커니즘으로 "태그" 처리되는 타스크: 유스 케이스 분석에서 적용 가능한 디자인 메커니즘이 식별되어, 기능의 특정 부분이 디자인에서 처리되어야 함을 나타냅니다. 이 경우 적용 가능한 디자인 메커니즘은 유스 케이스 실현에 참여하는 분석 클래스가 태그 처리되어 있는 분석 메커니즘과 연관된 메커니즘입니다.

디자이너는 필요한 디자인 요소 및 디자인 요소 상호작용을 디자인 가이드라인에 문서화된 사용 규칙에 따라 유스 케이스 실현(realization)에 포함시켜서 적용 가능한 디자인 메커니즘을 유스 케이스 실현으로 통합합니다.

이벤트 플로우의 모든 변형 처리

각 플로우 변형을 독립 시퀀스 다이어그램에서 설명해야 합니다. 시스템을 디자인할 때 다이어그램에 일반적으로 필요로 하는 세부사항 레벨을 포함시켜야 하는 경우 시퀀스 다이어그램이 더 읽기 쉬우므로 커뮤니케이션 다이어그램에서 선호됩니다.

이벤트 플로우에서 가장 공통적으로 사용되거나 가장 중요한 기본 플로우를 설명하면서 시작하십시오. 그런 후에 예외 플로우와 같은 변형을 설명하십시오. 참여 오브젝트의 모든 오퍼레이션을 사용 또는 예시하는 한 모든 이벤트 플로우를 설명할 필요는 없습니다. 이와 같이 하나의 오브젝트에만 연관되는 플로우와 같이 아주 사소한 플로우는 생략할 수 있습니다.

요구사항 캡처 및 분석에 이미 설명된 플로우 변형 이외의 플로우 변형이 있는지 유스 케이스를 분석하십시오(예: 구현에 따라 변경되는 플로우 변형). 새 플로우 식별 시 각 플로우를 시퀀스 다이어그램으로 설명하십시오. 예외 플로우 예제에는 다음이 포함됩니다.

  • 오류 처리. 예를 들어, 인터페이스에서 외부 통신 오류 발생을 보고하는 경우 유스 케이스가 해당 오류를 처리해야 합니다. 가능한 솔루션으로는 새 통신 통로를 여는 것입니다.
  • 제한시간 초과 처리. 사용자가 특정 시간 동안 응답하지 않는 경우 유스 케이스는 특수한 척도를 사용해야 합니다.
  • 유스 케이스에 참여하는 오브젝트에 잘못된 입력 처리. 이런 유형의 오류는 사용자의 잘못된 입력에서 발생할 수 있습니다.

유스 케이스의 선택적 파트 처리

플로우의 대체 경로를 변형 대신 선택적 플로우로 설명할 수 있습니다. 다음 목록에 선택적 플로우의 두 가지 예제가 포함되어 있습니다.

  • 액터는 신호를 송신하여 여러 옵션 중 유스 케이스가 다음에 수행할 작업을 결정합니다. 예를 들어 유스 케이스는 액터에게 질문에 예나 아니오로 대답하도록 요청하거나 액터에게 유스 케이스의 현재 상태에서 시스템이 수행 가능한 다양한 기능을 제공합니다.
  • 플로우 경로는 저장된 속성 값 또는 관계에 따라 달라집니다. 후속 이벤트 플로우는 처리되는 데이터 유형에 따라 달라집니다.

선택적 플로우 또는 복잡한 서브플로우를 확실히 눈에 띄게 하려면 독립 시퀀스 다이어그램을 사용하십시오. 각 독립 시퀀스 다이어그램은 선택적 플로우 또는 서브플로우 동작이 발생하는 위치를 표시하는 스크립트, 여백 텍스트 또는 노트를 사용하여 주 이벤트 플로우에 대해 시퀀스 다이어그램에서 참조되어야 합니다.

예를 들어 특정 이벤트가 발생할 때 실행되는 동작과 같이 선택적 또는 예외 플로우 동작이 어디서든 발생 가능한 경우, 이벤트가 발생할 때 선택적/예외 시퀀스 다이어그램에 설명된 동작이 실행됨을 표시하는 어노테이션을 주 이벤트 플로우에 대한 시퀀스 다이어그램에 추가해야 합니다. 대안으로, 명확한 이벤트 기반 동작이 있는 경우 상태 차트 다이어그램을 사용하여 시스템의 동작을 설명하십시오. 자세한 정보는 가이드라인: 상태 차트 다이어그램을 참조하십시오.

서브시스템을 사용하여 시퀀스 다이어그램 단순화(선택사항)

유스 케이스가 실현되는 경우 이벤트 플로우는 일반적으로 디자인 오브젝트의 상호작용과 같은 오브젝트 실행으로 설명됩니다. 다이어그램을 단순화하거나 재사용가능한 동작을 식별하기 위해 서브시스템에서 이벤트 서브플로우를 캡슐화해야 할 수도 있습니다. 이 작업이 완료되면 시퀀스 다이어그램의 큰 서브섹션은 서브시스템의 단일 메시지로 바뀝니다. 서브시스템에서 독립 시퀀스 다이어그램은 필수 동작을 제공하는 서브시스템의 내부 상호작용을 나타낼 수도 있습니다(자세한 정보는 타스크: 서브시스템 디자인 참조).

다음과 같은 경우 시퀀스 다이어그램의 메시지 서브시퀀스는 서브시스템에 캡슐화되어야 합니다.

  • 서브시퀀스는 다른 유스 케이스 실현(realization)에서 반복적으로 발생합니다. 즉, 동일한(또는 비슷한) 메시지가 동일한(또는 비슷한) 오브젝트로 송신되어 동일한 결과를 제공하게 됩니다. 동작을 재사용가능하게 하려면 약간의 디자인 작업이 필요할 수 있으므로 '비슷한'이라는 용어를 사용합니다.
  • 서브시퀀스는 하나의 유스 케이스 실현에서만 발생하지만 이후의 반복 또는 비슷한 시스템에서 반복적으로 수행될 것으로 예상됩니다. 동작은 재사용가능한 유용한 컴포넌트가 될 수도 있습니다.
  • 서브시퀀스는 하나의 유스 케이스 실현에서만 발생하며, 복잡하지만 쉽게 캡슐화되고, 한 명의 사용자 또는 팀의 책임으로 지정되어야 하며 제대로 정의된 결과를 제공합니다. 이런 상황에서는 일반적으로 복잡한 동작에 특별한 기술 지식 또는 특수한 도메인 지식이 필요하며 그 결과 서브시스템에 캡슐화하기에 적합합니다.
  • 서브시퀀스는 교체 가능한 컴포넌트에 캡슐화되도록 결정됩니다(개념: 컴포넌트 참조). 이 경우, 서브시스템이 디자인 모델의 컴포넌트를 나타내는 알맞은 표시 방식입니다.

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

필요한 경우 유스 케이스 실현은 서브시스템 계층 구조의 여러 레벨에서 설명될 수 있습니다. 중간 다이어그램의 라이프라인은 서브시스템을 나타내고 원 안의 상호작용은 메시지에 응답하는 서브시스템 구성원의 내부 상호작용을 나타냅니다.

이 접근 방식을 사용하는 장점은 다음과 같습니다.

  • 유스 케이스 실현이 덜 복잡해집니다(특히 몇몇 서브시스템의 내부 디자인이 복잡한 경우).
  • 유스 케이스 실현이 서브시스템의 내부 디자인 작성 전에 작성될 수 있으며, 이는 병렬 개발 환경인 경우 유용합니다("병렬 작업 방법" 참조).
  • 유스 케이스 실현이 더 일반적이며 변경이 쉬워집니다(특히 서브시스템이 다른 서브시스템으로 대체되어야 하는 경우).

예제:

시내 통화 유스 케이스 실현의 일부인 다음 시퀀스 다이어그램을 고려하십시오.

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

이 다이어그램에서 회색 클래스는 네트워크 처리 서브시스템에 속하며 다른 클래스는 가입자 처리 서브시스템에 속합니다. 이는 멀티 시스템 시퀀스 다이어그램, 즉 클래스가 다른 서브시스템에 포함되는지 여부와 상관없이 이벤트 플로우에 참여하는 모든 오브젝트가 포함되는 다이어그램입니다.

대안으로, 네트워크 처리 서브시스템에서 동작 호출 및 해당 서브시스템에서의 특정 인터페이스 연습을 표시할 수 있습니다. 가입자 처리 서브시스템이 사용하는 ICoordinator 인터페이스를 네트워크 처리 서브시스템에서 제공하는 것으로 가정해 보십시오.

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

ICoordinator 인터페이스는 네트워크 처리의 Coordinator 클래스에 의해 실현됩니다. 따라서 네트워크 처리 인스턴스 대신 네트워크 처리 서브시스템 자체 및 시퀀스 다이어그램의 해당 ICoordinator 인터페이스를 사용할 수 있습니다.

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

Coordinator, Digit Information 및 Network 클래스 인스턴스는 포함하고 있는 서브시스템으로 대체됩니다. 서브시스템의 모든 호출은 대신 ICoordinator 인터페이스를 통해 수행됩니다.

라이프라인에 인터페이스 표시

동일한 인터페이스를 실현하는 서브시스템을 제대로 대체하려면 해당 인터페이스만 상호작용(및 일반적으로 다이어그램)에서 가시화되어야 합니다. 그렇지 않으면 서브시스템이 다른 서브시스템으로 대체될 때 상호작용(또는 다이어그램)이 변경되어야 합니다.

예제:

제공하는 서브시스템을 포함하지 않고 ICoordinator 인터페이스만 시퀀스 다이어그램에 포함시킬 수 있습니다.

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

인터페이스 라이프라인으로 메시지를 송신하면 인터페이스를 실현하는 모든 서브시스템이 다이어그램의 인터페이스로 대체될 수 있습니다. 인터페이스를 실현하는 다른 서브시스템이 다른 메시지를 송신하기 때문에 ICoordinator 인터페이스 라이프라인은 라이프라인에서 송신된 메시지를 포함하지 않습니다. 그러나 인터페이스를 실현하는 모든 서브시스템에서 송신되어야 하는(또는 송신 가능한) 메시지를 설명하려는 경우 해당 메시지는 인터페이스 라이프라인에서 송신될 수 있습니다.

병렬 작업 방법

어떤 경우에는 기타 서브시스템 개발과 다소 독립적이며 병렬로 서브시스템을 개발하는 것이 적합할 수도 있습니다. 이를 수행하려면 먼저 서브시스템에 종속된 인터페이스를 식별하여 서브시스템 종속성을 찾아야 합니다.

이는 다음과 같이 수행할 수 있습니다.

  1. 서브시스템 인터페이스에 영향을 주는 요구사항을 집중적으로 검토합니다.
  2. 서브시스템 경계를 통과하는 메시지를 표시하여 필수 인터페이스 아웃라인을 작성합니다.
  3. 각 유스 케이스 서브시스템의 시퀀스 다이어그램을 그립니다.
  4. 메시지를 제공하는 데 필요한 인터페이스를 정제합니다.
  5. 각 서브시스템을 병렬로 개발하고 인터페이스를 개발 팀 간에 동기화 인스트루먼트로 사용합니다.

서브시스템 시퀀스 다이어그램 또는 해당 인터페이스을 통해서만 시퀀스 다이어그램을 배열할 지 여부를 선택할 수도 있습니다. 어떤 프로젝트에서는 나머지 모델링 작업을 계속하기 전에 인터페이스를 제공하는 클래스를 구현할 필요가 있습니다.

지속성 연관 동작 설명

객체 지향 패러다임의 전반적인 목적은 구현 세부사항을 캡슐화하는 것입니다. 따라서 지속성 관점에서 지속적 오브젝트가 임시 오브젝트와 동일하게 보이게 하려고 합니다. 오브젝트가 지속적인지 인식하거나 기타 오브젝트를 처리하는 방법과 다르게 오브젝트를 처리할 필요는 없습니다. 최소한 이를 목적으로 합니다.

실제로는 응용프로그램이 다음과 같이 다양한 지속성의 측면을 제어할 필요가 있을 수 있습니다.

  • 지속적 오브젝트를 읽고 쓰는 시기
  • 지속적 오브젝트가 삭제되는 시기
  • 트랜잭션을 관리하는 방법
  • 잠금 및 동시 제어를 달성하는 방법

지속적 오브젝트 쓰기

여기에 연관된 두 가지 경우가 있습니다. 즉, 오브젝트가 지속적 오브젝트 스토어에 쓰는 초기 시기 및 응용프로그램이 오브젝트 변경에 따라 지속적 오브젝트 스토어를 갱신해야 하는 후속 시기가 그것입니다.

두 경우 모두 특정 메커니즘은 지속성 프레임워크에서 지원되는 오퍼레이션에 따라 달라집니다. 일반적으로 메시지를 지속성 프레임워크로 송신하여 지속적 오브젝트를 작성하는 메커니즘이 사용됩니다. 오브젝트가 지속적인 경우 지속성 프레임워크는 지속적 오브젝트의 후속 변경을 발견할 수 있고 필요한 경우 지속적 오브젝트 스토어에 필요한 변경을 작성합니다(일반적으로 트랜잭션이 확약될 때).

작성되는 지속적 오브젝트의 예제가 아래에 표시됩니다.

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

PersistenceMgr 오브젝트는 지속성 프레임워크인 VBOS의 인스턴스입니다. OrderCoordinator는 지속적 주문을 'createPersistentObject' 메시지의 인수로 PersistenceMgr에 송신하여 지속적 주문을 작성합니다.

이벤트의 어떤 시퀀스의 특정 위치에 오브젝트가 명시적으로 저장되는지 알아야 하는 경우가 아니라면 일반적으로 명시적으로 이를 모델링하지 않아도 됩니다. 서브시퀀스 오퍼레이션에서 오브젝트를 조회해야 하는 경우 오브젝트는 반드시 데이터베이스에 있어야 하기 때문에 오브젝트가 데이터베이스에 있음을 알아야 합니다.

지속적 오브젝트 읽기

지속적 오브젝트 스토어에서의 오브젝트 검색은 응용프로그램이 해당 오브젝트에 메시지를 송신하기 전에 수행해야 합니다. 객체 지향 시스템에서 해당 작업 재호출은 오브젝트로 메시지를 송신하여 수행됩니다. 그러나 메시지를 송신하려는 오브젝트가 데이터베이스에는 있지만 아직 메모리에는 없는 경우 문제가 발생합니다. 존재하지 않는 상황에서는 메시지를 송신할 수 없습니다.

다시 말해 데이터베이스에서 조회하는 방법을 아는 오브젝트에 메시지를 송신하고 올바른 오브젝트를 검색하며 이를 인스턴스화해야 합니다. 이렇게 해야만 원래 송신하려던 원본 메시지를 송신할 수 있게 됩니다. 지속적 오브젝트의 인스턴스를 작성하는 오브젝트는 팩토리 오브젝트라고도 합니다. 팩토리 오브젝트는 지속적 오브젝트를 포함하는 오브젝트의 인스턴스 작성을 책임집니다. 주어진 조회에 대해 팩토리는 조회에 일치하는 하나 이상의 오브젝트 세트를 리턴하도록 디자인될 수 있습니다.

일반적으로 오브젝트는 연관을 통해 서로 연결되므로, 일반적으로 오브젝트 그래프의 루트 오브젝트만 검색하면 됩니다. 나머지는 루트 오브젝트와의 연관을 통해 데이터베이스에서 필요한 오브젝트가 투명하게 '풀(pull)'됩니다. (유용한 지속성 메커니즘에서는 이를 현명하게 처리합니다. 즉, 필요한 경우에만 오브젝트를 검색하는데 이렇게 하지 않으면 많은 수의 오브젝트를 불필요하게 인스턴스화할 수 있습니다. 필요하기도 전에 오브젝트를 검색하는 것은 극단적으로 단순화된 지속성 메커니즘으로 발생하는 주요 성능 문제점 중 하나입니다.)

다음 예제에서는 지속적 오브젝트에서 오브젝트를 검색하여 모델링하는 방법을 보여줍니다. 실제 시퀀스 다이어그램에서 DBMS는 팩토리 오브젝트로 캡슐화되기 때문에 표시되지 않습니다.

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

지속적 오브젝트 삭제

지속적 오브젝트의 문제점은 지속성입니다. 임시 오브젝트를 작성한 프로세스가 종료되면 임시 오브젝트도 사라지는 것과 달리, 지속적 오브젝트는 명시적으로 삭제될 때까지 계속 존재하게 됩니다. 그렇기 때문에 더 이상 사용하지 않을 경우에는 해당 오브젝트를 반드시 삭제해야 합니다.

그렇지만 이를 결정하기가 쉽지 않습니다. 오브젝트를 사용하는 하나의 응용프로그램이 완료되었다고 해서 현재와 미래의 모든 응용프로그램이 완료되는 것은 아닙니다. 또한 오브젝트에는 오브젝트에서 인식하지 못하는 많은 연관이 작성되어 있기 때문에 해당 오브젝트를 삭제해도 되는지 결정하기가 쉽지 않습니다.

디자인 시 이 내용은 상태 차트를 사용하여 시맨틱으로 표시됩니다. 오브젝트가 종료 상태가 되면 해제됨으로 표시될 수 있습니다. 그러면 지속적 클래스 구현을 책임지는 개발자가 상태 차트 정보를 참조하여 올바른 지속성 메커니즘 동작을 호출하여 오브젝트를 해제합니다. 유스 케이스 실현(realization) 디자이너는 올바른 오퍼레이션을 호출하여 오브젝트가 삭제 가능한 상태가 되면 해당 오브젝트를 종료 상태가 되도록 해야 합니다.

오브젝트가 기타 오브젝트에 연결된 경우 오브젝트 삭제를 결정하기가 쉽지 않습니다. 팩토리 오브젝트는 오브젝트 구조 및 연결된 오브젝트를 알고 있으므로, 클래스의 팩토리 오브젝트를 특정 인스턴스 삭제 결정에 사용하면 유용한 경우가 있습니다. 지속성 프레임워크도 이 기능을 지원합니다.

트랜잭션 모델링

트랜잭션은 원자인 오퍼레이션 호출 세트를 정의하는데, 이는 모두 수행되거나 전혀 수행되지 않습니다. 지속성 관점에서 트랜잭션은 모두 수행되거나 전혀 수행되지 않는 오브젝트 세트의 변경 세트를 정의합니다. 트랜잭션은 일관성을 제공하여 오브젝트 세트가 하나의 일치된 상태에서 다른 상태로 이동하도록 합니다.

유스 케이스 실현(realization)에서 트랜잭션을 표시하는 여러 옵션이 있습니다.

  • 텍스트 사용. 시퀀스 다이어그램의 여백에 스크립트를 사용하여 트랜잭션 경계가 다음과 같이 문서화될 수 있습니다. 이 방법은 단순하며 얼마든지 많은 수의 메커니즘을 아용하여 트랜잭션을 구현할 수 있게 해줍니다.

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

텍스트 어노테이션을 사용하여 트랜잭션 경계 표시.

  • 명시적 메시지 사용. 사용 중인 트랜잭션 관리 메커니즘에서 명시적 메시지를 사용하여 트랜잭션을 시작하고 종료하는 경우 해당 메시지는 다음과 같이 시퀀스 다이어그램에 명시적으로 표시될 수 있습니다.

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

트랜잭션을 시작 및 중지하는 명시적 메시지를 표시하는 시퀀스 다이어그램

오류 조건 처리

트랜잭션에 지정된 모든 오퍼레이션이 수행 가능하지 않은 경우(일반적으로 오류가 발생한 경우) 트랜잭션은 중단되고 트랜잭션 중에 발생한 모든 변경이 취소됩니다. 예상 오류 조건은 주로 유스 케이스의 예외 이벤트 플로우를 표시합니다. 또는 시스템 장애로 인해 오류 조건이 발생하는 경우도 있습니다. 오류 조건도 상호작용에 문서화해야 합니다. 단순한 오류 및 예외는 발생한 상호작용에 표시 가능합니다. 복잡한 오류 및 예외는 자체 상호작용이 필요합니다.

특정 오브젝트의 실패 모드가 상태 차트에 표시될 수 있습니다. 해당 실패 모드 제어 처리의 조건부 플로우는 오류 또는 예외가 발생한 상호작용에 표시될 수 있습니다.

동시성 제어 처리

동시성은 트랜잭션 과정의 중요한 시스템 자원에 대한 액세스 제어를 설명합니다. 시스템을 일관된 상태로 유지하기 위해 트랜잭션에서는 시스템의 특정 핵심 자원에 대해 독점적인 액세스를 필요로 합니다. 독점적인 액세스에는 오브젝트 세트 읽기, 오브젝트 세트 쓰기 또는 오브젝트 세트 읽기 및 쓰기 둘 다를 지원하는 기능이 포함될 수 있습니다.

오브젝트 세트에 대해 액세스를 제한해야 하는 이유를 설명하는 단순한 예제를 살펴보겠습니다. 단순한 주문 입력 시스템을 실행 중이라고 가정해 보십시오. 고객의 전화 주문을 받으면 주문을 처리하고 주문을 배송합니다. 주문을 트랜잭션 유형으로 볼 수 있습니다.

동시성 제어의 필요성을 보여주기 위해, 하이킹 부츠를 전화로 주문했다고 가정해 보십시오. 주문이 시스템에 입력되면 시스템은 주문한 하이킹 부츠에 해당하는 재고가 있는지 있는지 확인합니다. 해당하는 제품이 있는 경우 그 제품을 예약해서 주문이 배송되기 전에 다른 사람이 해당 제품을 구매하지 못하도록 합니다. 주문이 배송되고 나면 부츠가 재고에서 제거됩니다.

주문이 제출되고 운송될 때까지 부츠는 특수 상태(즉 재고에는 있지만 주문용으로 "확약"되어 있음)에 있습니다. 어떤 이유로 주문이 취소되는 경우(변심 또는 카드 만기) 부츠는 재고로 다시 돌아옵니다. 주문이 배송되면 회사에서는 해당 부츠의 레코드를 보관하지 않는다고 가정해 보십시오.

트랜잭션과 마찬가지로 동시성의 목적은 시스템이 하나의 일관된 상태에서 다른 상태로 이동되도록 하는 것입니다. 또한 동시성은 트랜잭션에 작업 완료에 필요한 모든 자원이 포함되도록 합니다. 동시성 제어는 자원 잠금, 세마포어, 공유 메모리 래치 및 개인용 작업공간을 포함하여 다양한 여러 방식으로 구현됩니다.

객체 지향 시스템에서 메시지 패턴만으로 특정 메시지가 오브젝트의 상태를 변경했는지를 알기는 힘듭니다. 또한, 다른 구현은 자원의 특정 유형에 대한 액세스를 제한해야 하는 필요가 애초에 없어집니다. 예를 들어 몇몇 구현에서는 트랜잭션 초반에 시스템 상태에 대한 자체 보기를 각 트랜잭션에 제공합니다. 이 경우 기타 프로세스는 다른 트랜잭션 실행 '보기'에 영향을 주지 않으면서 오브젝트의 상태를 변경할 수도 있습니다.

구현 제한을 막기 위해 디자인 시 트랜잭션이 독점적으로 액세스해야 하는 자원을 표시할 수 있습니다. 위 예제의 경우, 주문한 부츠에 독점 액세스가 필요함을 표시하고자 할 수 있습니다. 단순한 대안으로, 송신 중의 메시지 설명에 어노테이션을 추가하여 응용프로그램이 오브젝트에 독점적으로 액세스해야 함을 표시합니다. 그러면 구현자는 이 정보를 참조하여 동시성 요구사항 구현의 최선책을 결정합니다. 독점적인 액세스를 필요로 하는 메시지의 어노테이션을 표시하는 시퀀스 다이어그램 예제가 아래 표시됩니다. 예제에서는 트랜잭션이 완료되면 모든 잠금이 해제되는 것으로 간주됩니다.

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

시퀀스 다이어그램에 어노테이션이 있는 액세스 제어 표시 예제.

트랜잭션에서 필요한 모든 오브젝트에 액세스를 제한하지 않는 이유는 소수의 오브젝트에만 액세스가 제한되는 경우가 있기 때문입니다. 트랜잭션에 참여하는 모든 오브젝트의 액세스를 제한하면 중요한 자원이 낭비될 수 있고 성능 병목 현상이 예방되는 것이 아니라 오히려 발생될 수 있습니다.

이벤트 플로우 설명 정제

유스 케이스 실현(realization) 이벤트 플로우에서 참여 오브젝트에서 송신되는 메시지 평가를 통해 이벤트 플로우를 명확히 할 수 없는 경우 시퀀스 다이어그램에 설명을 추가해야 할 수도 있습니다. 이런 경우에 해당하는 예제로는 외부 관찰자가 다이어그램을 읽기 쉽도록 타이밍 어노테이션, 조건부 동작 노트 또는 오퍼레이션 동작 설명을 작성해야 하는 경우가 있습니다.

이벤트 플로우는 초기에 타스크: 유스 케이스 분석에 아웃라인됩니다. 이 단계에서 필요에 따라 이벤트 플로우가 시퀀스 다이어그램을 명확히 설명하도록 정제해야 합니다.

때로는 오프레이션 이름만으로는 수행 중인 오퍼레이션의 목적을 완전히 이해하지 못하는 경우도 있습니다. 다이어그램 여백에 텍스트 형식의 노트 또는 스크립트를 추가하여 시퀀스 다이어그램을 명확하게 설명할 필요가 있을 수도 있습니다. 텍스트 형식의 노트 및 스크립트로 결정 단계, 루핑 및 분기 작성과 같은 제어 플로우를 나타내야 할 수도 있습니다. 또한, 텍스트 형식의 태그가 시퀀스 다이어그램 특정 위치의 유스 케이스에서 확장점을 연관시키는 데 필요할 수도 있습니다.

이 타스크의 위 예제에서 시퀀스 다이어그램에 어노테이션을 추가하는 다양한 방식을 설명했습니다.



디자인 클래스 및 서브시스템 통합

유스 케이스가 실현되면 식별된 디자인 클래스와 서브시스템이 디자인 모델에서 동질성 및 일관성을 유지하도록 통합해야 합니다.

다음을 고려하십시오.

  • 모델 요소 이름으로 기능을 설명해야 합니다.
  • 비슷한 이름 또는 동의어를 사용하면 모델 요소를 구별하기가 어려우므로 사용하면 안됩니다.
  • 비슷한 동작을 정의하거나 동일한 현상을 표시하는 모델 요소를 병합해야 합니다.
  • 동일한 개념을 표시하거나 동일한 속성을 포함하는 엔티티 클래스를 병합해야 합니다(정의된 동작이 다른 경우도 포함).
  • 상속을 사용하여 모델 요소를 추상화하여 모델을 더 견고하게 만들어야 합니다.
  • 모델 요소를 갱신하는 경우 해당 유스 케이스 실현(realization) 이벤트 플로우도 갱신해야 합니다.
결과 평가

이 단계에서 디자인 모델을 확인하여 작업이 올바른 방향으로 진행되고 있는지 확인해야 합니다. 모델을 자세하게 검토할 필요는 없지만 작업 동안 디자인 모델을 고려해야 합니다.

특히 타스크: 디자인 검토유스 케이스 실현(realization)을 참조하십시오.

자세한 정보