타스크: 시스템 컨텍스트 정의
이 타스크는 시스템과 액터 간의 최상위 레벨 협업을 나타내는 시스템 컨텍스트 다이어그램 작성 방법을 정의합니다.
목적
  • 유스 케이스 모델을 토대로 시스템(최상위 레벨 서브시스템으로 모델링됨), 인터페이스 및 액터와의 관계(액터와 시스템 사이를 순환하는 외부 I/O 엔티티 포함)를 나타내는 최상위 레벨 협업을 작성합니다.
관계
역할기본: 추가: 지원:
입력필수: 선택사항:
  • 없음
외부:
  • 없음
출력
단계
소개

유스 케이스 모델은 시스템의 동작과 관련된 컨텍스트를 보여 주지만, 이 타스크에서는 다음을 보여 주기 위해 중간 산출물: 유스 케이스 모델 및 중간 산출물: 보충 스펙을 사용하여 컨텍스트 다이어그램에서 해당 환경에 시스템의 논리적 모델을 작성합니다.

  • 시스템에 의해 실현되는 인터페이스(시스템에서 사용하는 오퍼레이션, 지원되는 연관 프로토콜, 시스템에 의해 실현되는 상태 변수저장소기술 성능 척도라는 특징을 갖는 속성의 관점에서)
  • 시스템과 해당 액터 간에 전달되는 입출력 엔티티
  • 올바른 성능을 위해 시스템에 필요한 인터페이스(시스템과 상호 작용하는 액터에 의해 실현됨). 일반적으로 액터가 시스템이 통신해야 하는 기존 시스템을 나타내는 경우 이 필수 인터페이스는 다른 해당 시스템에서 적용하는 제한조건을 반영합니다.

컨텍스트 다이어그램은 시스템과 액터 간의 최상위 레벨 협업을 보여 주며, 이 다이어그램은 시스템의 유스 케이스 모델과 구조적으로 동일합니다. 이 협업은 분석 모델에 작성됩니다.

입출력 엔티티(모델링에서 속성은 있고 오퍼레이션은 없는 "I/O" 스테레오타입의 클래스로 표시)는 시스템에 들어오고 나가는 대상에 대해 설명하며 일반 시스템의 경우 데이터, 부피, 에너지 또는 실제 파트가 포함될 수 있습니다. 입출력 엔티티는 모델링 과정에서 액터-시스템 쌍과 연관됩니다. 즉, 이 특정 입출력 엔티티는 액터와 시스템 사이를 이동합니다. 이 엔티티는 선택적으로 액터와 연관되어 다이어그램에 표시될 수 있으며 플로우 방향은 연관에 대한 "send" 또는 "receive" 스테레오타입으로 표시되어 액터와 관련된 방향을 나타냅니다.

시스템 오퍼레이션은 동작에 영향을 주는 오브젝트에서 요청받을 수 있는 서비스입니다. 오퍼레이션은 연관된 동작을 호출하기 위한 이름, 유형, 매개변수 및 제한조건을 지정합니다. 오퍼레이션은 고려 중인 (서브)시스템의 기본 책임에 따라 인터페이스를 중심으로 그룹화됩니다. 시스템 오퍼레이션 호출은 유스 케이스 인스턴스보다 더 세분화된 시스템 상호작용을 나타냅니다. 유스 케이스 인스턴스는 오퍼레이션 호출과 응답으로 구성됩니다.

상태 변수와 저장소는 시스템에 의해 실현되는 인터페이스에 정의된 속성입니다. 이 속성은 추상적이므로 시스템에서 속성의 유형 및 다중성에 해당하는 정보를 유지보수해야 하며 해당 정보의 저장, 검색 및 수정을 허용해야 합니다. 시스템의 속성이 인터페이스에 정의된 속성과 직접 대응되지는 않습니다. 상태 변수와 저장소 간의 차이는 본질적인 것이 아닙니다. 단지 시스템의 (추상) 상태 머신 오퍼레이션을 제어하는 데 속성이 사용되는 방식을 반영합니다. "상태"는 특정 시점에 발생하는 이벤트(예: 신호 도착)와 달리 일정 기간 동안 지속됩니다. 여기서 언급된 상태 머신은 한정된 상태 머신이며, "상태"에 대한 설명은 일반적으로 상대적으로 적은 변수에 의해 결정됩니다. 예를 들어, 현재 상태는 열거 유형의 단일 속성 값에 의해 지정될 수 있습니다. 그러나 이벤트에 대한 시스템의 반응은 이벤트의 특성(및 전달되는 정보(예: 오퍼레이션 매개변수로)) 및 현재 상태뿐만 아니라 다른 다수의 속성 값에 따라 결정됩니다.

기술 성능 척도(TPM)는 보충 스펙 또는 유스 케이스 모델에서 시스템 효율성의 중요 지표로 선택되는 주요 기술 속성으로, 충족되지 않을 경우 시스템 개발이 비용, 스케줄 또는 성능 제한조건을 벗어날 위험이 있습니다. 프로젝트가 진행 중인 동안 새롭게 부상하고 있는 이러한 속성의 가치가 추적됩니다. 예를 들어, 시스템의 중량을 특정 한계 이하로 유지하는 것이 중요한데, 디자인 및 구현/구축(Construction)을 진행할 때 이러한 목표 달성을 추적해야 합니다. 시스템의 중량은 명백하게 시스템 인스턴스의 속성(다양한 방법으로 감지할 수 있음)이지만, 개발되는 동안 반드시 목표 중량과 동일하지는 않습니다(시스템이 제대로 실행되려면 이보다 적어야 함). UML 태그 값을 사용하여 성능 목표를 나타내도록 TPM 속성에 설명을 추가할 수 있습니다. 예를 들면 다음과 같습니다.

"TPM" 중량 {maximum_weight = 1000kg}

기술 성능 척도(TPM)는 오퍼레이션 응답 시간과 같은 다른 비구조적 특성에도 적용할 수 있습니다. 태그 값은 시스템 오퍼레이션 또는 이를 기록할 시스템 자체에 적용할 수 있습니다.

초기 컨텍스트 다이어그램 작성

다음 단계는 컨텍스트에 따른 시스템 세부사항의 전개 레벨을 보여 줍니다. 표시된 예는 무단 침입으로부터 재산을 보호하고 알람을 울리는 보안 시스템으로서, 특정 종류의 응답 서비스에 침입을 보고하는 기능이 있습니다.  

유스 케이스 모델을 전개하고 이 모델에 더 많은 세부사항(액터 발견 또는 비즈니스 모델링을 수행한 경우 액터와 오퍼레이션이 이미 식별되었으므로 이들의 상호작용을 자세하게 나타냄)을 추가할 때 초기 협업을 작성하고 이를 컨텍스트 다이어그램으로 표시할 수 있습니다. 컨텍스트 다이어그램은 다음과 같이 표시되는데, 처음에는 시스템 인터페이스가 보이지 않습니다. 시스템은 최상위 레벨 서브시스템("system"으로 스테레오타입화됨)으로 표시되는데, 결과적으로 여러 개의 인터페이스를 실현합니다. 액터와 연관이 다시 표시되는데 처음에는 세부사항이 없습니다.

컨텍스트 다이어그램(초기)

컨텍스트 다이어그램(초기)

연관 및 인터페이스 정제

다음으로 액터, 시스템, 시스템 인터페이스 간의 연관을 정제하십시오. 시스템 오퍼레이션과 시스템 속성이 타스크: 액터와 유스 케이스 찾기(이후: 타스크: 유스 케이스 세부화)에서 나타나면 이들에 대한 추론을 시작할 수 있습니다. 인터페이스를 표시함으로써 이제 시스템이 액터로 표시된다는 점을 유념하십시오. 원하는 경우 이러한 사항에 대한 실현을 표시할 수 있지만(다이어그램에서 점선으로 된 원으로 강조표시됨), 많은 정보 손실 없이 이를 생략할 수 있습니다.

이 단계에서는 이전에 엔터프라이즈 레벨에서 유스 케이스를 실행할 때 수행한 작업과 도메인 지식을 토대로, 일시적으로만 I/O 엔티티를 식별하십시오.  I/O 엔티티를 다이어그램에 표시할 필요는 없지만, 그럴 경우 액터-시스템 상호작용에 대해 추론할 때 유용할 수 있습니다.

따라서 액터와 시스템 간 연결의 특성을 나타내고(예: 필요한 프로토콜 기록) 액터와 시스템 간에 이동하는 엔티티를 기록할 수 있습니다.

컨텍스트 다이어그램(예비)

컨텍스트 다이어그램(예비)

시스템 오퍼레이션 및 기타 시스템 특성 설명

이 단계에서는 시스템 오퍼레이션(제공되고 필요함)을 설명할 수 있는 유스 케이스 시나리오(유스 케이스 인스턴스)를 생성합니다. 이 시나리오는 상호작용 또는 활동 다이어그램으로 나타낼 수 있습니다. 유스 케이스의 각 블랙 박스 단계는 시스템과의 세부 상호작용을 나타내며 오퍼레이션 호출로 맵핑됩니다. 이 때 오퍼레이션은 반드시 고유한 오퍼레이션은 아니어도 되며 다른 블랙 박스 단계에서 동일한 오퍼레이션을 사용할 수 있습니다. 컨텍스트 다이어그램(앞으로는 분석 모델)에서 시스템 오퍼레이션을 정의하는 것 이외에도, 유스 케이스는 추적성을 위해 호출된 오퍼레이션에 어노테이션으로 표시됩니다. 이 오퍼레이션은 또한 블랙 박스 단계에 할당된 성능 요구사항 또는 기타 비기능적 요구사항을 상속합니다. 시나리오에서 수행된 각 블랙 박스 단계를 확인하면 유스 케이스 시나리오 실행을 위해 시스템에서 유지보수해야 하는 상태 변수와 저장소를 제안하는 이름이 사용되었음을 발견할 수 있습니다. 또한 필요한 I/O 엔티티를 정제한 다음 이를 오퍼레이션 호출과 연관시켜 액터와 시스템이 주고 받는 신호를 생성할 수 있습니다.  

시스템 인터페이스를 보다 구체적인 인터페이스로 분할하면 이해하는 데 도움이 될 수 있습니다. 실제로 보충 스펙에 이에 대한 인터페이스 요구사항이 있을 수 있습니다. 아래 그림은 시스템 인터페이스가 각 액터 유형에 대해 "제공된 시스템 인터페이스"로 전개되는 과정을 보여줍니다. 이 내용은 수정될 수 있습니다. 액터는 인터페이스를 공유하거나 액터 한 명당 둘 이상의 인터페이스를 가질 수 있습니다.

이 분석은 또한 시스템에 필요한 인터페이스 즉, (시스템의 메시지를 처리하기 위해) 액터가 지원해야 하는 인터페이스도 식별할 수 있습니다. 이는 대칭적 방식으로 다이어그램에 추가할 수 있습니다. 예를 들어, 아래 다이어그램에서 Emergency Services 액터에 의해 실현되는 IE-services/ESS "필수 시스템 인터페이스"를 살펴 보십시오.  다시 한 번 말하자면, 다이어그램에 표시되지는 않지만 액터는 둘 이상의 인터페이스를 지원(실현)할 수 있습니다.

오퍼레이션, 저장소 등은 다음과 같이 확장된 형태의 인터페이스(속성 및 오퍼레이션 컴파트먼트)에 추가되어야 합니다. 이 다이어그램은 일부만 완성되었습니다(공간과 관련됨). 실제 환경 인터페이스, 액터 등은 확장되지 않았습니다. 다시 한 번 말하자면 제공된 시스템 인터페이스의 실현은 많은 정보 손실 없이 생략할 수 있습니다.

컨텍스트 다이어그램(최종)

컨텍스트 다이어그램(예비)

컨텍스트 다이어그램에 캡처된 이 최상위 레벨 협업에서는 인터페이스, 연결, 시스템 입출력(I/O) 및 연관된 성능 특성을 정확하게 지정할 수 있으므로, 시스템 컨텍스트에서 다른 요소의 영향을 받지 않으면 시스템 개발을 계속 진행할 수 있습니다.

특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함