목적
  • 상호 작용 관점에서 유스 케이스 구현을 정제하기 위함.
  • 설계 클래스의 조작에 관한 요구사항을 정제하기 위함.
  • 설계 서브시스템의 조작 및/또는 인터페이스에 관한 요구사항을 정제하기 위함.
역할:  설계자 
빈도:  결과물: 유스 케이스 구현 설계세트에 대해 각 반복당 한 번. 
단계
입력물:    결과물:   
툴 강좌:  
자세한 정보: 

워크플로우 세부사항:   

시스템 작동은 여러 기술(공동 연구 또는 상호 작용)로 설명할 수 있습니다. 이 활동은 상호 작용, 특히 순서 다이어그램을 묘사하여 시스템의 작동에 대해 설명합니다. 순서 다이어그램은 시스템 또는 서브시스템의 작동을 주로 동기적 메시지 전달로 설명할 수 있는 경우 가장 유용합니다. 특히 이벤트 구동 시스템에서 비동기 메시징은 상태 시스템 및 공동 연구 관점에서 종종 보다 쉽게 설명되어 객체 간 가능한 상호 작용을 정의하는 최소 설치 방법을 허용합니다.

유스 케이스 구현 작성 페이지 맨 위

결과물: 유스 케이스 구현 설계가 설계 모델의 작동에서 유스 케이스 모델로 역추적하는 방법을 제공하며 설계 모델의 공동 연구를 유스 케이스 개념을 중심으로 체계화합니다.

설계할 각 유스 케이스에 대해 설계 모델에서 유스 케이스 구현 설계를 작성하십시오. 유스 케이스 구현 설계의 이름은 연관된 유스 케이스와 동일해야 하며 관계 "구현"은 유스 케이스 구현에서 연관된 유스 케이스로 설정되어야 합니다.

설계 객체 간 상호 작용 설명 페이지 맨 위

각 유스 케이스 구현의 경우, 하나 이상의 순서 다이어그램을 작성하여 참여 설계 오브젝트 간 상호 작용을 설명해야 합니다. 이러한 다이어그램의 초기 버전은 활동: 유스 케이스 분석 중에 작성됩니다.  유스 케이스 구현의 이러한 "분석 버전"은 분석 클래스 간 상호 작용을 설명합니다.  설계 요소 간 상호 작용을 설명하도록 전개되어야 합니다.

순서 다이어그램 갱신에는 다음 단계가 관여됩니다.

  • 유스 케이스의 플로우에 관련하는 각 객체를 식별하십시오. 이는 활동: 설계 요소 식별에서 식별된 설계 클래스 및 서브시스템을 예시화하여 완료됩니다.
  • 순서 다이어그램에 각 관련 객체를 표시하십시오. 순서 다이어그램에 각 관련 객체의 생명선을 작성하십시오. 설계 서브시스템을 표시하도록 다음과 같은 일부 선택사항이 있습니다.
    • 서브시스템의 인스턴스를 순서 다이어그램에 표시할 수 있습니다.
    • 서브시스템이 구현하는 인터페이스를 사용할 수 있습니다. 동일한 인터페이스가 인터페이스 대신에 사용될 수도 있음을 구현하는 임의의 모델 요소를 표시하고자 하는 경우 선호됩니다. 순서 다이어그램에 인터페이스를 표시하기로 선택한 경우 인터페이스에서 기타 객체로 메시지가 전송되지 않도록 확인해야 함을 숙지하십시오. 이유는 인터페이스가 해당 조작의 내부 구현을 완전히 캡슐화하기 때문입니다. 따라서 인터페이스를 구현하는 모든 모델 요소가 사실상 동일한 방식으로 설계됨을 확신할 수 없습니다. 그러므로, 순서 다이어그램에 인터페이스에서 전송 중인 메시지가 표시되지 않아야 합니다.
    • 컴포넌트를 사용하여 서브시스템을 순서 다이어그램에 표시할 수 있습니다. 특정 서브시스템이 메시지에 응답함을 표시하려는 경우 컴포넌트를 사용하십시오. 이런 경우, 컴포넌트에서 기타 객체로 전송 중인 메시지를 표시할 수 있습니다.

    이는 시스템 레벨 순서 다이어그램으로 최상위 레벨 설계 요소(일반적으로 서브시스템 및 서브시스템 인터페이스)가 상호 작용하는 방법을 표시함을 참고하십시오. 서브시스템의 내부 디자인을 표시하는 순서 다이어그램은 활동: 서브시스템 설계의 일부로서 별도로 생성됩니다.

  • 활성 객체 상호 작용은 일반적으로 스펙 공동 연구 및 상태 시스템을 사용하여 설명함을 참고하십시오. 보다 큰 유스 케이스 구현에서 시스템의 기타 요소에 의해 메시지가 활성 객체에 전송되는 방법을 표시하도록 여기에서 사용됩니다. 일반적인 사용법으로 활성 객체는 유스 케이스 구현이 상호 작용하는 서브시스템 세트로 구성되도록 이 활동의 용도로 서브시스템 내에서 캡슐화됩니다. 상호 작용이 서브시스템의 책임 및 인터페이스를 정의합니다. 서브시스템에서 활성 객체가 실행의 동시 스레드를 표시합니다. 서브시스템을 사용하여 팀 간 공적 계약 역할을 하는 인터페이스로 개발 팀 사이에 작업을 나눌 수 있습니다.

    서브시스템에서 나오는 메시지를 표시하는 짧은 참고사항: 인터페이스에만 대한 제한된 메시지가 모델 요소 간 결합을 감소시키며 설계의 유연성을 향상시킵니다. 가능한 경우, 이를 완수하도록 노력해야 하며 서브시스템에서 비인터페이스 모델로 나오는 메시지가 있는 경우 모델에서 분리를 향상시키도록 이러한 메시지를 인터페이스로 변경하는 기회를 찾아야 합니다.

  • 수행자에게 발생하는 상호 작용을 표시하십시오. 관련 객체가 sequence 다이어그램의 생명선에 의해 상호 작용하는 각 수행자 인스턴스 및 외부 객체를 표시하십시오.
  • 관련 객체 간 전송되는 메시지를 설명하십시오. 이벤트 플로우가 다이어그램의 맨 위에서 시작하여 아래 방향으로 계속되며 수직 연대기 축을 표시합니다. 생명선 간 메시지(화살표)를 작성하여 객체 간 전송되는 메시지를 설명하십시오. 메시지의 이름은 메시지가 호출하는 조작의 이름이어야 합니다. 설계의 초기 단계에서 그리 많은 조작이 객체에 지정되지 않으므로 해당 정보를 남겨두고 메시지에 임시 이름을 부여해야 할 수도 있습니다. 이러한 메시지는 "지정되지 않음"이 됩니다. 나중에, 추가 관련 객체 조작을 발견하는 경우 해당 조작으로 메시지를 "지정"하여 순서 다이어그램을 갱신해야 합니다.
  • 메시지 수신시 객체가 수행하는 사항을 설명하십시오. 스크립트를 해당 메시지에 첨부하여 이를 수행하십시오. 다이어그램의 여백에 이러한 스크립트를 두십시오. 구조화된 텍스트 또는 유사 부호를 사용하십시오. 유사 코드를 사용하는 경우, 구현 언어에서 construct를 사용하여 해당 조작의 구현을 보다 용이하게 하십시오. 객체 클래스에 책임이 있는 사람이 해당 조작을 지정 및 정의시, 객체 스크립트가 해당 작업의 객체를 제공합니다.

첨부된 텍스트에 표시된 다이어그램.

순서 다이어그램의 객체가 수행하는 유스 케이스 작동을 문서화합니다.

객체 간 작동을 분배한 경우, 플로우가 제어되는 방법을 고려해야 합니다. 오브젝트가 유스 케이스 구현에서 특정 방식으로 상호 작용하며 특정 역할이 있음을 가정하여 해당 오브젝트를 찾습니다. 작동을 분배함에 따라 이러한 가정의 테스트를 시작할 수 있습니다. 플로우의 일부 파트에서 분산 구조를 사용할 수도 있습니다. 기타 파트에서는 집중 구조를 선호할 수도 있습니다. 이러한 다양성의 정의 및 두 유형의 구조 사용시 권장사항은 가이드라인: 순서 다이어그램을 참조하십시오.

이 시점에서 새 객체가 필요할 수도 있습니다. 예를 들어, 집중 구조를 사용하고 플로우를 제어할 새 객체가 필요한 경우입니다. 설계 모델에 추가하는 임의의 객체는 객체 모델에 작성된 요구사항을 충족해야 합니다.

적용 가능한 설계 메커니즘 통합

활동: 구조 분석 중에 분석 메커니즘이 식별됩니다.  활동: 설계 메커니즘 식별 중에 분석 메커니즘이 설계 메커니즘으로 정제되며 분석 메커니즘에서 설계 메커니즘으로의 맵핑이 소프트웨어 구조 문서에 캡처되고 설계 메커니즘이 ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website프로젝트 특정 가이드라인에 문서화됩니다.   

이 활동 중에, 유스 케이스 설계, 임의의 적용 가능 설계 메커니즘이 유스 케이스 구현에 통합됩니다.  설계자가 사용 가능한 설계 메커니즘을 조사하여 개발 중인 유스 케이스 구현에 적용하는 사항을 판별하여 소프트웨어 구조 문서 및 설계 가이드라인에 문서화된 권장사항과 가이드라인에서 작업합니다.   
주: 분석 클래스가 특정 분석 메커니즘으로 "태그"된 동안에 적용 가능한 설계 메커니즘이 활동: 유스 케이스 분석에 식별되어 기능성의 특정 부분이 설계에서 처리되어야 함을 표시합니다.  이런 경우, 적용 가능한 설계 메커니즘은 유스 케이스 구현에 관련된 분석 클래스가 태그된 분석 메커니즘과 연관됩니다.

설계자가 설계 가이드라인에 문서화된 사용 규칙에 따라 필수 설계 요소 및 설계 요소 상호 작용을 유스 케이스 구현에 포함시켜 적용 가능한 설계 메커니즘을 유스 케이스 구현에 통합합니다.

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

별도의 순서 다이어그램에 각 플로우 변형을 설명해야 합니다. 다이어그램이 시스템 설계시 일반적으로 원하는 세부사항 레벨을 포함해야 하는 경우 보다 쉽게 읽을 수 있으므로 순서 다이어그램이 일반적으로 의사소통 다이어그램에 선호됩니다.

가장 일반적이거나 가장 중요한 이벤트 플로우인 기본 플로우의 설명으로 시작하십시오. 그런 다음, 예외 플로우와 같은 변형을 설명하십시오. 관련 객체의 모든 조작을 사용하여 예증하는 한 모든 이벤트 플로우를 설명할 필요가 없습니다. 이와 같은 경우, 한 객체에만 관여된 플로우와 같이 매우 사소한 플로우는 생략될 수 있습니다.

유스 케이스를 학습하여 요구사항 캡처 및 분석에 이미 설명된 사항(예: 구현에 종속적인 플로우 변형) 외에 플로우 변형이 있는지 확인하십시오. 새 플로우 식별시, 각 플로우를 순서 다이어그램에 설명하십시오. 예외 플로우의 예에는 다음이 포함됩니다.

  • 오류 처리. 예를 들어, 인터페이스가 일부 외부 시스템과 의사소통시 오류가 발생했음을 보고하는 경우, 유스 케이스가 이를 처리해야 합니다. 가능한 솔루션은 새 의사소통 라우트를 여는 것입니다.
  • 시간 종료 처리. 사용자가 특정 기간 내에 응답하지 않는 경우, 유스 케이스가 일부 특수 대책을 세워야 합니다.
  • 유스 케이스 관련 객체의 잘못된 입력 처리. 이와 같은 오류는 잘못된 사용자 입력에서 기인할 수도 있습니다.

유스 케이스의 선택사항 파트 처리

변형 대신에 선택사항 플로우로서 플로우의 대체 경로를 설명할 수 있습니다. 다음 목록에는 선택사항 플로우의 두 예가 포함됩니다.

  • 신호를 보냄으로써 수행자는 유스 케이스가 다음에 수행할 사항을 판별합니다(여러 선택사항으로 부터). 예를 들어, 유스 케이스가 수행자에게 질문에 대해 예 또는 아니오를 대답하도록 요청하거나 수행자에게 유스 케이스의 현재 상태에서 시스템이 수행할 수 있는 다양한 기능을 제공합니다.
  • 플로우 경로는 저장된 속성 또는 관계의 값에 따라 다양합니다. 이벤트의 후속 플로우는 처리될 데이터의 유형에 따라 달라집니다.

선택사항 플로우 또는 임의의 복잡한 서브 플로우가 특별히 주목되기를 원하는 경우, 별도의 순서 다이어그램을 사용하십시오. 각 별도의 순서 다이어그램은 선택사항 또는 서브 플로우 작동이 발생하는 위치를 표시하도록 스크립트, 여백 텍스트 또는 노트를 사용하여 기본 이벤트 플로우의 순서 다이어그램에서 표시되어야 합니다.

선택사항 또는 예외적 플로우 작동이 어디서든 발생할 수 있는 경우(예: 특정 이벤트 발생시 실행하는 작동), 기본 이벤트 플로우의 순서 다이어그램이 이벤트 발생 시기와 선택사항/예외적 순서 다이어그램에 설명된 작동이 실행될 시기를 표시하도록 주석 처리되어야 합니다. 대안으로, 중요한 이벤트 구동 작동이 있는 경우, 시스템 작동을 설명하는데 상태 차트 다이어그램의 사용을 고려하십시오. 자세한 정보는 가이드라인: 상태 차트 다이어그램을 참조하십시오.

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

유스 케이스가 구현되면 이벤트 플로우가 일반적으로 오브젝트 실행(설계 객체 간 상호 작용) 관점에서 설명됩니다. 다이어그램을 단순화하고 재사용 가능한 작동을 식별하기 위해 서브시스템 내 이벤트의 서브 플로우를 캡슐화할 필요가 있을 수도 있습니다. 이 작업이 완료되면 순서 다이어그램의 대형 서브 섹션이 서브시스템에 단일 메시지로 대체됩니다. 서브시스템에서 별도의 순서 다이어그램이 필수 작동을 제공하는 서브시스템의 내부 상호 작용을 설명할 수도 있습니다(자세한 정보는 활동: 서브시스템 설계 참조).

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

  • 서브 순서가 다른 유스 케이스 구현에서 반복적으로 발생합니다. 즉, 동일한(또는 유사한) 메시지가 동일한(또는 유사한) 객체에 전송되어 동일한 최종 결과를 제공합니다. 일부 설계 작업이 작동을 재사용 가능하게 하도록 필요할 수도 있으므로 문구 '유사한'이 사용됩니다.
  • 서브 순서는 오직 한 유스 케이스 구현에서만 발생하지만 장래 반복 또는 향후 유사한 시스템에서 반복적으로 수행되도록 예상됩니다. 작동이 유용한 재사용 가능 컴포넌트를 작성할 수도 있습니다.
  • 서브 순서는 오직 한 유스 케이스 구현에서만 발생합니다. 이는 복잡하지만 쉽게 캡슐화되고 한 개인 또는 팀의 책임이 될 필요가 있으며 제대로 정의된 결과를 제공합니다. 이러한 종류의 상황에서 일반적으로 복잡한 작동은 특수 기술 지식 또는 특수 도메인 지식을 필수로 하며, 결과적으로 서브시스템 내에서 캡슐화하는 데 아주 적합합니다.
  • 서브 순서가 대체 가능한 컴포넌트에서 캡슐화되도록 판별됩니다(개념: 컴포넌트 참조). 이 경우, 서브시스템이 설계 모델의 컴포넌트에 대해 적절한 표시입니다.

첨부 텍스트에 설명된 다이어그램.

필요한 경우, 유스 케이스 구현이 서브시스템 계층 구조의 여러 레벨에서 설명될 수 있습니다. 중간 다이어그램의 생명선이 서브시스템을 표시합니다. 원의 상호 작용이 메시지의 응답하여 서브시스템 구성원의 내부 상호 작용을 표시합니다.

이 접근법의 이점은 다음과 같습니다.

  • 유스 케이스 구현은 특히 일부 서브시스템의 내부 설계가 복잡한 경우에 덜 흩어집니다.
  • 유스 케이스 구현은 서브시스템의 내부 설계가 작성되기 전에 작성될 수 있습니다. 예를 들어 병렬 개발 환경에서 유용합니다("병렬로 작업하는 방법" 참조).
  • 유스 케이스 구현은 특히 서브시스템이 기타 서브시스템으로 대체되어야 하는 경우 변경하기에 쉽고 일반적이게 됩니다.

예:

로컬 호출 유스 케이스 구현의 일부인 다음 순서 다이어그램을 고려하십시오.

첨부 텍스트에 설명된 다이어그램.

이 다이어그램에서 회색 클래스는 네트워크 처리 서브시스템에 속하며 기타 클래스는 신청자 처리 서브시스템에 속합니다. 이는 해당 다이어그램이 다중 서브시스템 순서 다이어그램, 즉 해당 클래스가 다른 서브시스템에 있는지 여부에 상관없이 이벤트 플로우에 관련된 모든 객체가 포함된 다이어그램임을 의미합니다.

대안으로서 네트워크 처리 서브시스템의 작동 호출 및 해당 서브시스템의 특정 인터페이스 수행을 표시할 수 있습니다. 네트워크 처리 서브시스템이 다음과 같이 신청자 처리 서브시스템이 사용하는 ICoordinator 인터페이스를 제공한다고 가정하십시오.

첨부 텍스트에 설명된 다이어그램.

ICoordinator 인터페이스는 네트워크 처리 내 조정자 클래스에 의해 구현됩니다. 이런 가정하에서 네트워크 처리 내 클래스의 인스턴스 대신 네트워크 처리 서브시스템 자체와 해당 ICoordinator 인터페이스를 순서 다이어그램에서 사용할 수 있습니다.

첨부 텍스트에 설명된 다이어그램.

조정자, 숫자 정보 및 네트워크 클래스 인스턴스가 포함하는 서브시스템으로 대체됨을 참고하십시오. 서브시스템의 모든 호출이 ICoordinator 인터페이스를 통해 대신 완료됩니다.

생명선에 인터페이스 표시

동일한 인터페이스를 구현하는 서브시스템의 진정한 대체성을 달성하기 위해 해당 인터페이스만이 상호 작용(및 일반적으로 다이어그램)에서 가시적이어야 합니다. 그렇지 않으면 상호 작용(또는 다이어그램)은 서브시스템이 서로 대체될 때 변경되어야 합니다.

예:

순서 다이어그램에 다음과 같이 ICoordinator 인터페이스만을 포함할 수 있으며 제공하는 서브시스템은 포함할 수 없습니다.

첨부 텍스트에 설명된 다이어그램.

인터페이스 생명선에 메시지를 전송하는 것은 인터페이스를 구현하는 모든 서브시스템이 다이어그램의 인터페이스에 대해 대체될 수 있음을 의미합니다. 인터페이스를 구현하는 다른 서브시스템에 다른 메시지를 전송할 수 있으므로 ICoordinator 인터페이스 생명선에는 해당 생명선에서 나오는 메시지가 없음을 참고하십시오. 그러나 인터페이스를 구현하는 모든 서브시스템에서 전송되어야 하는(또는 전송이 허용되는) 메시지를 설명하려는 경우, 해당 메시지는 인터페이스 생명선에서 나올 수 있습니다.

병렬로 작업하는 방법

일부 경우에 서브시스템을 기타 서브시스템의 개발과 동시에 다소 독립적으로 개발하는 것이 적절할 수 있습니다. 이를 달성하려면 우선 서브시스템 간 인터페이스를 식별하여 서브시스템 종속성을 찾아야 합니다.

작업이 다음과 같이 완료될 수 있습니다.

  1. 서브시스템 간 인터페이스에 영향을 주는 요구사항에 집중하십시오.
  2. 서브시스템 경계에 전달될 메시지를 표시하는 필수 인터페이스의 개요를 작성하십시오.
  3. 각 유스 케이스의 서브시스템에 관하여 순서 다이어그램을 그리십시오.
  4. 메시지를 제공하는데 필요한 인터페이스를 정제하십시오.
  5. 각 서브시스템을 병렬로 개발하고 인터페이스를 개발 팀 간 동기화 수단으로 사용하십시오.

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

지속성 관련 작동 설명 페이지 맨 위

객체 지향 패러다임의 전체 목적은 구현 세부사항을 캡슐화하기 위함입니다. 따라서 지속성에 관해서는 일시 객체와 똑같이 지속적 객체 보기를 하고자 합니다. 객체가 지속적인지를 인식하거나 기타 객체와 달리 처리할 필요가 없습니다. 최소한 이것이 목표입니다.

실제로 어플리케이션이 다음과 같은 지속성의 여러 면을 제어할 필요가 있는 경우가 때때로 있을 수 있습니다.

  • 지속적 객체를 읽기 및 쓸 시기
  • 지속적 객체를 삭제할 시기
  • 트랜잭션이 관리되는 방법
  • 잠금 및 동시성 제어가 수행되는 방법

지속적 객체 쓰기 페이지 맨 위

다음과 같이 고려해야 할 두 가지 경우가 있습니다. 객체가 지속적 객체 저장소에 기록되는 초기 시기. 어플리케이션이 지속적 객체 저장소를 객체의 변경사항으로 갱신하려는 후속 시기.

어느 경우에든 특정 메커니즘이 지속성 프레임워크가 지원하는 조작에 따라 달라집니다. 일반적으로, 사용된 메커니즘은 지속적 객체를 작성하도록 지속성 프레임워크에 메시지를 전송해야 합니다. 일단 객체가 지속적이면 지속성 프레임워크는 후속 변경사항을 지속성 객체로 발견하고 필요한 경우(일반적으로 트랜잭션 확약 시) 해당 변경사항을 지속적 객체 저장소에 기록할 만큼 영리합니다.

작성 중인 지속적 객체의 예가 아래에 표시됩니다.

첨부 텍스트에 설명된 다이어그램.

객체 PersistenceMgr는 지속성 프레임워크인 VBOS의 인스턴스입니다. OrderCoordinator가 PersistenceMgr로의 'createPersistentObject' 메시지에 인수로서 지속적 주문을 전송하여 해당 주문을 작성합니다 .

객체가 일부 이벤트 시퀀스의 특정 지점에 명시적으로 저장 중임을 아는 것이 중요하지 않은 경우 이를 명시적으로 모델화하는 것은 일반적으로 필요치 않습니다. 후속 조작이 객체를 조회해야 하는 경우, 객체가 데이터베이스에 있어야 합니다. 따라서 객체가 데이터베이스에 있는 것을 아는 것이 중요합니다.

지속적 객체 읽기 페이지 맨 위

어플리케이션이 해당 객체에 메시지를 보낼 수 있으려면 지속적 객체 저장소에서 객체 검색이 필수입니다. 객체 지향 시스템에서 해당 작업의 재호출은 메시지를 객체에 전송함으로써 수행합니다. 그러나 메시지를 전송하려는 객체가 데이터베이스에 있으나 아직 메모리에는 없는 경우, 문제점이 됩니다. 아직 존재하지 않는 것에 메시지를 전송할 수 없습니다!

간단히 말해, 데이터베이스를 조회하고 올바른 객체를 검색하며 이를 실증하는 방법을 아는 객체에 메시지를 전송해야 합니다. 그런 다음, 그리고 그런 후에야 원래 의도한 본래 메시지를 전송할 수 있습니다. 지속적 객체를 실증하는 객체는 때때로 팩토리 객체라고 합니다. 팩토리 객체는 지속적 객체를 포함하여 객체의 인스턴스를 작성하는 책임이 있습니다. 조회가 제공되면 팩토리는 조회에 일치하는 하나 이상의 객체 세트를 리턴하도록 설계될 수 있습니다.

일반적으로 객체는 해당 연관을 통해 서로 충분히 연결되므로 일반적으로 객체 그래프에서 루트 객체를 검색하는 것만이 필요합니다. 나머지는 본질적으로 루트 객체와의 연관에 의해 데이터베이스 밖으로 분명하게 '빠져나갑니다'. (좋은 지속적 메커니즘은 이를 현명하게 처리합니다. 해당 메커니즘은 객체가 필요할 때만 검색합니다. 그렇지 않으면 대다수의 객체를 불필요하게 실증하려는 노력을 종료할 수도 있습니. 필요하기 전에 객체를 검색하는 것은 극단적으로 단순화한 지속성 메커니즘으로 생긴 주된 성능 문제점 중 하나입니다.)

다음 예가 지속적 객체 저장소에서 객체 검색을 모델화하는 방법을 표시합니다. 실제 순서 다이어그램에서 DBMS는 팩토리 객체에 캡슐화되어야 하므로 표시되지 않습니다.

첨부 텍스트에 설명된 다이어그램.

지속적 객체 삭제 페이지 맨 위

지속적 객체에 있는 문제점은 해당 객체가 지속적이라는 것입니다!! 일시 객체는 자신을 작성한 프로세스 소멸시 단순히 사라지는 반면 지속 객체는 명시적으로 삭제될 때까지 존재합니다. 따라서 지속적 객체가 더 이상 사용되지 않는 경우 해당 객체를 삭제하는 것이 중요합니다.

문제점은 이를 판별하기가 힘들다는 것입니다. 객체가 있는 한 어플리케이션이 완료되었으므로 모든 어플리케이션(현재 또는 장래의)이 완료된 것은 아닙니다. 또한 객체가 알지조차도 못하는 연관이 있거나 있을 수 있다고 해서 객체를 삭제하는 것이 타당한지를 알아내는 것이 항상 쉬운 것은 아닙니다.

설계시, 상태 차트를 사용하여 의미론적으로 표시될 수 있습니다. 객체가 종료 상태에 다다르면 릴리즈됨으로 나타낼 수 있습니다. 그런 다음, 지속적 클래스 구현의 책임이 있는 개발자가 상태 차트 정보를 사용하여 객체를 릴리즈하는 적절한 지속성 메커니즘 작동을 호출할 수 있습니다. 유스 케이스 구현 설계자의 책임은 객체가 삭제되기에 적절한 경우 객체가 종료 상태에 다다를 수 있게 하는 적절한 조작을 호출하는 것입니다.

객체가 기타 객체에 충분히 연결되면 객체가 삭제될 수 있는지 여부를 판별하기가 어려울 수 있습니다. 팩토리 객체가 연결된 객체뿐 아니라 객체의 구조에 대해서도 알고 있으므로 클래스의 팩토리 객체에게 특정 인스턴스가 삭제될 수 있는지 여부를 판단할 책임을 부여하는 것은 종종 유용합니다. 지속성 프레임워크가 이 성능에 대한 지원을 제공할 수도 있습니다.

트랜잭션 모델링 페이지 맨 위

트랜잭션이 원자인 조작 호출 세트를 정의합니다. 모두 수행되거나 전혀 수행되지 않습니다. 지속성의 컨텍스트에서 트랜잭션이 변경 세트를 모두 수행되거나 전혀 수행되지 않는 객체 세트로 정의합니다. 트랜잭션이 지속성을 제공하여 객체 세트가 한 지속적 상태에서 다른 상태로 이동하는지 확인합니다.

유스 케이스 구현에서 트랜잭션을 표시하는 다음과 같은 여러 선택사항이 있습니다.

  • 텍스트로. 순서 다이어그램의 여백에 스크립트를 사용하여 트랜잭션 경계가 아래와 같이 문서화될 수 있습니다. 이 메소드는 단순하며 임의의 수의 메커니즘이 트랜잭션을 구현하는데 사용할 수 있게 합니다.

첨부 텍스트에 설명된 다이어그램.

텍스트로 된 주석으로 트랜잭션 경계 표시.

  • 명시적 메시지 사용. 사용 중인 트랜잭션 관리 메커니즘이 명시적 메시지를 사용하여 트랜잭션을 시작 및 종료하는 경우, 이러한 메시지는 아래에 표시된 바와 같이 순서 다이어그램에서 명시적으로 표시될 수 있습니다.

첨부 텍스트에 설명된 다이어그램.

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

오류 조건 처리페이지 맨 위

트랜잭션에 지정된 모든 조작이 수행될 수 없는 경우(일반적으로 오류가 발생하므로) 트랜잭션이 중단되고 트랜잭션이 역전되는 동안 모든 변경이 작성됩니다. 예상된 오류 조건은 종종 유스 케이스에 있는 이벤트의 예외적인 플로우를 표시합니다. 기타의 경우, 오류 조건이 시스템의 일부 실패로 인해 발생합니다. 오류 조건이 상호 작용에서도 문서화되어야 합니다. 단순 오류 및 예외가 발생하는 상호 작용에 표시될 수 있습니다. 복잡한 오류 및 예외가 고유 상호 작용을 필수로 할 수도 있습니다.

특정 객체의 실패 모드가 상태 차트에 표시될 수 있습니다. 이러한 실패 모드의 조건적 제어 처리 플로우가 오류 또는 예외가 발생하는 상호 작용에 표시될 수 있습니다.

동시성 제어 처리 페이지 맨 위

동시성이 트랜잭션 과정의 중요한 시스템 자원에 대한 액세스 제어를 설명합니다. 시스템을 일관된 상태로 유지하려면 트랜잭션에 시스템의 일정 중요한 자원에 대한 독점적 액세스가 있는 것이 필수일 수도 있습니다. 독점성은 객체 세트 읽기, 객체 세트 쓰기 또는 객체 세트 읽기 및 쓰기 모두의 능력을 포함할 수도 있습니다.

객체 세트에 제한된 액세스가 필요할 수도 있는 이유의 간단한 예를 살펴봅시다. 간단한 주문 입력 시스템을 실행 중이라고 합시다. 사용자가 주문하기 위해 전화를 하면 차례로 우리가 주문을 처리하고 주문을 배송합니다. 주문을 일종의 트랜잭션으로 볼 수 있습니다.

동시성 제어에 대한 필요를 설명하기 위해 한 켤레의 새 등산용 신발을 주문하도록 전화를 건다고 합시다. 주문이 시스템에 입력되면 원하는 올바른 크기의 등산용 신발이 재고 목록에 있는지 확인하도록 검사합니다. 재고가 있는 경우, 해당 신발 한 켤레를 예약하여 주문이 배송되기 전에 다른 사람이 구입할 수 없도록 합니다. 주문이 배송되고 나면 신발이 재고 목록에서 제거됩니다.

주문 시기와 배송 시기 사이의 기간 동안 신발은 특별한 상태&#151에 있습니다. 재고 목록에 있으나 나의 주문으로 "확약"됩니다. 나의 주문이 일정 이유로 인해 취소된 경우(마음이 바뀌었거나 신용 카드가 만기됨), 신발은 재고 목록으로 리턴됩니다. 주문이 배송되고 나면 우리의 작은 회사가 한 때 신발을 소유한 적이 있음을 나타내는 기록을 유지하고 싶어하지 않을 것으로 간주합니다.

트랜잭션과 같이 동시성의 목표는 시스템이 한 일관된 상태에서 다른 상태로 이동함을 확인하기 위함입니다. 또한 동시성은 트랜잭션에 작업을 완료하는데 필요한 모든 자원이 있음을 확인하기 위해 노력합니다. 동시성 제어는 자원 잠금, 세마포어, 공유 메모리 래치 및 개인용 작업공간을 포함하여 여러 다른 방법으로 구현될 수 있습니다.

객체 지향 시스템에서 단지 메시지 패턴으로부터 특정 메시지가 객체의 상태 변경을 유발할 수도 있는지 여부를 판단하기는 어렵습니다. 또한 다른 구현이 일정 유형의 자원에 대한 액세스를 제한할 필요를 제거할 수도 있습니다. 예를 들어, 일부 구현이 트랜잭션 시작에 시스템 상태 고유 보기로 각 트랜잭션을 제공합니다. 이 경우, 기타 프로세스가 임의의 기타 실행 트랜잭션의 '보기'에 영향을 미치지 않고 객체와 해당 상태를 변경할 수도 있습니다.

구현 제한을 예방하도록 설계시 트랜잭션에 독점적 액세스가 있어야 하는 자원을 간단히 표시하고자 합니다. 이전 예제를 사용하여 주문한 신발에 대한 독점적 액세스가 필요함을 표시하고자 합니다. 간단한 대안은 어플리케이션이 객체에 대해 독점적 액세스가 필요함을 표시하여 전송 중인 메시지의 설명에 주석 처리하는 것입니다. 그런 다음, 구현자가 이 정보를 사용하여 동시성 요구사항을 구현하는 가장 좋은 방법을 판별할 수 있습니다. 독점적 액세스가 필수인 메시지에 주석 처리하는 순서 다이어그램 예제가 아래에 표시됩니다. 가정은 트랜잭션 완료시 모든 잠금이 릴리즈된다는 것입니다.

첨부된 텍스트에 표시된 다이어그램.

순서 다이어그램의 주석 처리된 액세스 제어를 표시하는 예.

트랜잭션에 필요한 모든 객체에 대한 액세스를 제한하지 않는 이유는 종종 오직 적은 수의 객체에 액세스 제한이 있어야 하기 때문입니다. 트랜잭션에 관련된 모든 객체에 액세스를 제한하는 것은 귀중한 자원을 낭비하고 성능 병목 현상을 예방하는 것이 아니라 작성할 수 있습니다.

이벤트 플로우 설명 정제 페이지 맨 위

이벤트 플로우가 관련 객체 간 전송되는 메시지를 단지 조사하는 것으로 아주 명확하지 않은 경우, 유스 케이스 구현의 이벤트 플로우에서 순서 다이어그램에 추가 설명을 추가해야 할 수도 있습니다. 이러한 경우의 일부 예에는 타이밍 주석, 조건부 작동에 대한 참고 또는 조작 작동의 설명이 외부 관찰자가 다이어그램을 보다 쉽게 읽도록 해야 하는 경우가 포함됩니다.

이벤트 플로우가 처음에는 활동: 유스 케이스 분석에 개요됩니다. 이 단계에서 순서 다이어그램을 명백히 설명하는데 필요한 대로 이벤트 플로우를 정제합니다.

조작의 이름은 종종 조작이 수행 중인 이유를 이해하는데 충분하지 않습니다. 다이어그램 가장자리의 텍스트로 된 참고나 스크립트는 순서 다이어그램을 명확히 설명하는데 필요할 수도 있습니다. 텍스트로 된 참고나 스크립트는 제어 플로우(예: 결정 단계, 루프 실행 및 분기 작성)를 표시하기 위해 필요할 수도 있습니다. 또한 테스트로 된 태그는 유스 케이스의 확장 위치와 순서 다이어그램의 특정 위치를 상관시켜야 할 수도 있습니다.

이 활동의 이전 예제가 순서 다이어그램의 주석 처리하는 여러 다른 방법을 설명합니다.



설계 클래스 및 서브시스템 단일화 페이지 맨 위

유스 케이스가 구현됨에 따라 식별된 설계 클래스와 서브시스템을 단일화하여 설계 모델의 동질성 및 일관성을 확인해야 합니다.

고려해야 할 점은 다음과 같습니다.

  • 모델 요소의 이름이 해당 기능을 설명해야 합니다.
  • 모델 요소 간 구별을 어렵게 하므로 유사한 이름 및 동의어는 피하십시오.
  • 유사한 작동을 정의하거나 동일한 현상을 표시하는 모델 요소를 병합하십시오.
  • 정의된 작동이 다른 경우에도 동일한 속성이 있거나 동일한 개념을 표시하는 엔티티 클래스를 병합하십시오.
  • 상속을 사용하여 모델 요소를 추상화하십시오. 이는 모델을 보다 견실하게 하는 경향이 있습니다.
  • 모델 요소 갱신시, 유스 케이스 구현의 해당 이벤트 플로우 설명도 갱신하십시오.

결과 평가 페이지 맨 위

이 단계에서 설계 모델을 검사하여 사용자 작업이 올바른 방향으로 진행되고 있는지 확인하십시오. 모델을 자세하게 검토할 필요는 없으나 작업 중 설계 모델의 체크포인트를 고려해야 합니다.

특히 활동: 설계 검토유스 케이스 구현의 체크포인트를 참조하십시오.

UML 1.x 표시페이지 맨 위

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

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

Rational Unified Process   2003.06.15