타스크: 오퍼레이션 분석
이 타스크는 시스템 레벨의 동작적인 설명을 대략적인 시스템 구조로 변환하는 방법을 정의합니다.
원칙: 분석 및 디자인
목적
  • 구조적으로 중요한 각 유스 케이스의 각 시스템 오퍼레이션에 대한 블랙 박스 이벤트 플로우 텍스트를 (서브시스템 조치 및 협업 관점에서 볼 때) 일련의 화이트 박스 단계로 정제
  • 이러한 화이트 박스 설명을 지역성 결정, 프로세스 결정, 작업자 결정 및 화이트 박스 예산 요구사항을 통해 보강
  • 화이트 박스 단계를 기준으로 서브시스템 상호작용을 시퀀스 또는 협업 다이어그램으로 작성(분석 모델에서)
관계
기본 설명
이 타스크에서 디자이너는 시스템 레벨의 동작적인 설명을 대략적인 시스템 구조 및 서브시스템 레벨의 동작으로 변환합니다.
단계
블랙 박스 텍스트를 서브시스템 화이트 박스 단계로 정제

이 단계에서는 유스 케이스 모델을 사용하여 블랙 박스 이벤트 플로우 텍스트(각 유스 케이스의 특성)를 화이트 박스 단계의 시퀀스(시스템 아키텍처 분석의 요약된 협업 및 서브시스템을 사용하는 서브시스템 조치 및 상호작용 면에서 볼 때)로 정제합니다. 이 타스크가 오퍼레이션이 이미 지정된 서브시스템에 대해 수행될 경우 시작점은 오퍼레이션이며 초기 화이트 박스 단계 확장으로 바로 넘어갈 수 있습니다.

예를 들어, 다음의 '블랙 박스 이벤트 플로우의 예' 표와 같이 표 모양의 설명을 사용한 경우

시스템 유스 케이스 <이름>

단계 액터 조치 블랙 박스 단계 설명 블랙 박스 예산 요구사항 시스템 오퍼레이션
1 (액터 조치 ID): 액터가 수행하는 작업에 대한 설명. 예를 들면, "AA1: 이 유스 케이스는 판매원이 새 판매 단추를 누르면 시작됩니다."와 같습니다. (블랙 박스 단계 ID): 시스템 응답에 대한 설명(시스템의 내부 구조를 드러내지 않음). 예를 들면, "BBS1: 시스템은 새 판매원 및 고객의 화면을 불러오고 스캐너를 사용 가능하게 합니다."와 같습니다. (블랙 박스 단계 요구사항 ID): 시스템이 이 단계를 예를 들면, 응답 시간이나 속도 측면에서 얼마나 잘 수행해야 하는지에 대한 설명. 예를 들면, "SUP36.2: 총 응답 시간은 0.5초입니다."와 같습니다. (시스템 오퍼레이션 ID): 이 단계를 위해 호출되는 시스템 오퍼레이션의 이름. 예를 들면, "<<오퍼레이션>> 판매 새로 시작"(컨텍스트 다이어그램에 나와 있음, 타스크: 시스템 컨텍스트 정의에 정의되어 있음)과 같습니다.
2        
3        

블랙 박스 이벤트 플로우의 예

오퍼레이션만이 정의된 서브시스템에 대해 타스크가 수행되는 경우

그런 다음 시스템 오퍼레이션(블랙 박스 단계)이 하나 이상의 화이트 박스 단계로 확장됩니다. 화이트 박스 단계 각각은 이름이 지정된 서브시스템에 의해 수행됩니다. 디자이너는 화이트 박스 단계를 설명하는 데 사용되는 서브시스템 및 상호작용을 선택하는 데 있어 아키텍처 분석 단계에서 설계자가 수행한 작업에 따라 작업을 수행합니다. 이제 분석은 시스템 오퍼레이션에 의해 진행된다는 점에 유의하십시오. 즉, 다음 실현 단계를 추상적인 개념의 시스템 유스 케이스 블랙 박스 단계가 아닌 각 시스템 오퍼레이션 실현으로 취급하십시오.  

초기 화이트 박스 단계 확장

각각의 시스템 오퍼레이션에 대한 화이트 박스 단계(아래 표의 회색 배경)는 대응하는 시스템 오퍼레이션과 연관되어 초기에 분석 모델에서 캡처됩니다. 화이트 박스 단계는 시스템 유스 케이스(여기에는 예로서 간단히 보여짐)와 함께 저장되지 않지만 시스템 오퍼레이션을 통해 시스템 유스 케이스에서 추적할 수 있습니다.

시스템 유스 케이스 <이름>

시스템 오퍼레이션 단계 액터 조치 블랙 박스 단계 설명 블랙 박스 단계 예산 요구사항 서브시스템 화이트 박스 단계 설명 화이트 박스 단계 예산 요구사항 지역성 프로세스 작업자

(시스템 오퍼레이션 ID): 이 단계를 위해 호출되는 시스템 오퍼레이션의 이름. 예를 들면, "<<시스템 오퍼레이션>> 판매 새로 시작"(컨텍스트 다이어그램에 나와 있음)과 같습니다.

1 (액터 조치 ID): 액터가 수행하는 작업에 대한 설명. 예를 들면, "AA1: 이 유스 케이스는 판매원이 새 판매 단추를 누르면 시작됩니다."와 같습니다. (블랙 박스 단계 ID): 시스템 응답에 대한 설명(시스템의 내부 구조를 드러내지 않음). 예를 들면, "BBS1: 시스템은 새 판매원 및 고객의 화면을 불러오고 스캐너를 사용 가능하게 합니다."와 같습니다. (블랙 박스 단계 요구사항 ID): 시스템이 이 단계를 예를 들면, 응답 시간이나 속도 측면에서 얼마나 잘 수행해야 하는지에 대한 설명. 예를 들면, "SUP36.2: 총 응답 시간은 0.5초입니다."와 같습니다. (화이트 박스 단계 ID): (블랙 박스 단계의 일부를) 입력, 처리, 출력의 형태로 수행하는 서브시스템에 의해 수행되는 조치에 대한 설명. 예를 들면, "WBS1: POS(Point of Sale) 인터페이스에서는 트랜잭션을 지우고 새 판매 화면을 불러오고 주문 처리에서 판매 목록을 시작하도록 요청합니다."와 같습니다.        
(화이트 박스 단계 ID):...        
         
  2                
  3                

화이트 박스 이벤트 플로우의 예

지역성, 프로세스 및 작업자 결정으로 화이트 박스 단계 보강

이제 설명을 지역성 결정, 프로세스 결정 및 작업자 결정을 통해 더욱 보강합니다. 지역성 결정은 서브시스템 화이트 박스 단계가 수행되는 곳에서 위도(지역성의 추상 레벨 고려)를 사용하여 이루어집니다. 프로세스 결정은 (최소한 이 단계에 대해) 서브시스템이 "수동적", 즉 오퍼레이션이 서브시스템 외부의 프로세스에서 호출되기로 결정될 때만 필요합니다. "활성" 서브시스템은 서브시스템 내부의 프로세스를 사용하여 자체적으로 응답할 수 있습니다. 시스템 디자이너는 지역성 모델 및 프로세스 모델을 생성할 때 또 다시 시스템 설계자의 작업에 영향을 받습니다. 인적 자원에 할당하는 경우에 적합한 작업자 결정에서, 조직적 엔티티를 식별하고 시스템 오퍼레이션에 필요한 시스템 작업자 자원을 식별하게 됩니다.

화이트 박스 단계에서 둘 이상의 지역성(또는 프로세스)이 필요한 것으로 분석되면 이 단계를 세부 단계로 분해하여 각 세부 단계가 하나의 지역성(및 프로세스)과 연관되도록 하십시오. 이러한 분해를 통해 중요한 구조적 분기가 발생할 수 있으므로(이로 인해 서브시스템을 재분해해야 할 수도 있음) 시스템 설계자 역할을 하는 사람이나 팀과 함께 이 과정을 검토해야 합니다.

시스템 유스 케이스 <이름>

시스템 오퍼레이션 

단계 액터 조치 블랙 박스 단계 설명 블랙 박스 단계 예산 요구사항 서브시스템 화이트 박스 단계 설명 화이트 박스 단계 예산 요구사항 지역성 프로세스 작업자

(시스템 오퍼레이션 ID): 이 단계를 위해 호출되는 시스템 오퍼레이션의 이름. 예를 들면, "<<시스템 오퍼레이션>> 판매 새로 시작"(컨텍스트 다이어그램에 나와 있음)과 같습니다.

1 (액터 조치 ID): 액터가 수행하는 작업에 대한 설명. 예를 들면, "AA1: 이 유스 케이스는 판매원이 새 판매 단추를 누르면 시작됩니다."와 같습니다. (블랙 박스 단계 ID): 응답에 대한 설명(시스템의 내부 구조를 드러내지 않음). 예를 들면, "BBS1: 시스템은 새 판매원 및 고객의 화면을 불러오고 스캐너를 사용 가능하게 합니다."와 같습니다. (블랙 박스 단계 요구사항 ID): 시스템이 이 단계를 예를 들면, 응답 시간이나 속도 측면에서 얼마나 잘 수행해야 하는지에 대한 설명. 예를 들면, "SUP36.2: 총 응답 시간은 0.5초입니다."와 같습니다. (화이트 박스 단계 ID): (블랙 박스 단계의 일부를) 입력, 처리, 출력의 형태로 수행하는 서브시스템에 의해 수행되는 조치에 대한 설명. 예를 들면, "WBS1: POS(Point of Sale) 인터페이스에서는 트랜잭션을 지우고 새 판매 화면을 불러오고 주문 처리에서 판매 목록을 시작하도록 요청합니다."와 같습니다.   지역성 ID 프로세스 ID 조직 또는 시스템 작업자 ID
(화이트 박스 단계 ID):...        
         
  2                
  3                

보강된 화이트 박스 이벤트 플로우의 예

화이트 박스 예산 요구사항 할당

다음으로 블랙 박스 단계 예산 요구사항을 화이트 박스 단계에 할당합니다. 이러한 할당을 통해 서스시스템 및 연관된 지역성 모두에 대한 성능 요구사항을 판별할 수 있습니다. 수동 서브시스템의 경우, 호출 프로세스의 지연 시간 분석에 대한 입력이 되므로 다른 책임이 발생할 수 있습니다.

시스템 유스 케이스 <이름>

시스템 오퍼레이션 단계 액터 조치 블랙 박스 단계 설명 블랙 박스 단계 예산 요구사항 서브시스템 화이트 박스 단계 설명 화이트 박스 단계 예산 요구사항 지역성 프로세스 작업자

(시스템 오퍼레이션 ID): 이 단계를 위해 호출되는 시스템 오퍼레이션의 이름. 예를 들면, "<<시스템 오퍼레이션>> 판매 새로 시작"(컨텍스트 다이어그램에 나와 있음)과 같습니다.

1 (액터 조치 ID): 액터가 수행하는 작업에 대한 설명. 예를 들면, "AA1: 이 유스 케이스는 판매원이 새 판매 단추를 누르면 시작됩니다."와 같습니다. (블랙 박스 단계 ID): 시스템 응답에 대한 설명(시스템의 내부 구조를 드러내지 않음). 예를 들면, "BBS1: 시스템은 새 판매원 및 고객의 화면을 불러오고 스캐너를 사용 가능하게 합니다."와 같습니다. (블랙 박스 단계 요구사항 ID): 시스템이 이 단계를 예를 들면, 응답 시간이나 속도 측면에서 얼마나 잘 수행해야 하는지에 대한 설명. 예를 들면, "SUP36.2: 총 응답 시간은 0.5초입니다."와 같습니다. (화이트 박스 단계 ID): (블랙 박스 단계의 일부를) 입력, 처리, 출력의 형태로 수행하는 서브시스템에 의해 수행되는 조치에 대한 설명. 예를 들면, "WBS1: POS(Point of Sale) 인터페이스에서는 트랜잭션을 지우고 새 판매 화면을 불러오고 주문 처리에서 판매 목록을 시작하도록 요청합니다."와 같습니다. (화이트 박스 단계 요구사항 ID): 서브시스템이 이 단계를 예를 들면, 응답 시간이나 속도 측면에서 얼마나 잘 수행해야 하는지에 대한 설명. 예를 들면, "SUP36.2.1: 경과 시간은 0.16초입니다."와 같습니다. 지역성 모델의 지역성 ID 프로세스 모델의 프로세스 ID 조직 또는 시스템 작업자 ID
(화이트 박스 단계 ID):... (화이트 박스 단계 요구사항 ID):... 지역성 ID 프로세스 ID 조직 또는 시스템 작업자 ID
         
  2                
  3                

화이트 박스 이벤트 플로우 예산 요구사항의 예

서브시스템별로 화이트 박스 단계 정렬

이 단계에서는 각각의 서브시스템에 대한 모든 화이트 박스 단계(즉, 해당 서브시스템에 속한 화이트 박스 단계)를 한데 모읍니다. 이는 서브시스템 화이트 박스 단계 설명을 조사하여 서브시스템 오퍼레이션(시스템 오퍼레이션이 시스템에 대응되듯이 서브시스템에 대응되는 오퍼레이션)을 식별할 준비를 하는 과정에서 이루어집니다. 시스템 오퍼레이션에 대한 식별과 마찬가지로 각각의 화이트 박스 단계에 대해 고유한 서브시스템 오퍼레이션이 없을 수도 있습니다. 또한 화이트 박스 단계는 시스템 오퍼레이션에 의해 그룹화된다는 점에 유의하십시오. 예를 들면 다음과 같이 서브시스템별로 그룹화하여 표 형식으로 나타낼 수 있습니다.

서브시스템 유스 케이스 조사의 예

서브시스템 <이름>

시스템 오퍼레이션 지역성 프로세스 작업자 서브시스템 화이트 박스 단계 설명 서브시스템 오퍼레이션

<이름>

지역성 ID 프로세스 ID 조직 또는 시스템 작업자 ID (화이트 박스 단계 ID): (블랙 박스 단계의 일부를) 입력, 처리, 출력의 형태로 수행하는 서브시스템에 의해 수행되는 조치에 대한 설명  
         
         
         
         
         

오퍼레이션 유스 케이스 조사의 예

유스 케이스 모델이 각각의 시스템/서브시스템에 대해 유지보수되는 "복합 시스템"인 경우, 이러한 그룹화는 서브시스템 유스 케이스를 식별하는 강력한 방법입니다. 처음에는 서브시스템이 참여하는 각각의 시스템 오퍼레이션에 대한 서브시스템 유스 케이스를 식별할 수 있습니다. 이 과정에서 화이트 박스 단계의 시퀀스가 이러한 유스 케이스의 일부와 같다는 것을 알게 될 것입니다. 이러한 시퀀스를 모으면 하나의 서브시스템 유스 케이스로 여러 시스템 오퍼레이션의 요구를 충족시킬 수 있습니다.

각 시스템 오퍼레이션에 대해 아웃라인된 협업 정제

화이트 박스 단계를 기준으로 서브시스템 상호작용을 (분석 모델에서) 시퀀스 또는 협업 다이어그램으로 작성합니다. 이렇게 하면 시스템 설계자가 앞에서 수행한 작업이 정제됩니다. 이 단계에서는 협업이 아직 추상적입니다. 일반적으로 링크만 식별되거나 메시지가 추상 레벨로 식별됩니다. 그럼에도 불구하고 이 작업을 통해 서브시스템의 결합과 응집도를 확인할 수 있으며 이전에 수행된 화이트 박스 단계 확장이 정제됩니다(초기 화이트 박스 단계 확장 참조).

분석 평가

시스템 디자이너는 이 타스크의 결과에 대한 비정규 검토 회의를 소집하여 발견된 모든 문제를 기록하고 해결책을 찾기 위한 스케줄을 잡아야 합니다.

자세한 정보