디자이너는 오퍼레이션 분석 타스크에서 초기 서브시스템 오퍼레이션 플레이스홀더를 생성하였습니다. 조사 표에는 시스템 유스 케이스 블랙 박스 단계로 돌아가는 추적성(회색 배경)이 나타나 있습니다. 이는 시스템 유스
케이스 블랙 박스 단계 <id 1> 및 <id 2> 모두 <시스템 오퍼레이션 이름 1>을 호출하여 수행된다는 것을 보여 줍니다.
서브시스템 <이름>
|
시스템 오퍼레이션
|
시스템 유스 케이스 블랙 박스 단계 ID
|
지역성
|
프로세스
|
작업자
|
서브시스템 화이트 박스 단계 설명
|
서브시스템 오퍼레이션
|
<시스템 오퍼레이션 이름1>
|
<id 1>
|
지역성 ID
|
프로세스 ID
|
조직 또는 시스템 작업자 ID
|
(화이트 박스 단계 ID): (블랙 박스 단계의 일부를) 입력, 처리, 출력의 형태로 수행하는 서브시스템에 의해
수행되는 조치에 대한 설명
|
(서브시스템
오퍼레이션 ID): 이 단계를 위해 호출되는 서브시스템 오퍼레이션의 이름. 예를 들면, "«서브시스템 오퍼레이션» 판매 목록 시작"(서브시스템 주문 처리의 경우)과
같습니다.
|
...
|
...
|
|
(화이트 박스 단계 ID):...
|
|
...
|
...
|
|
...
|
|
<id 2>
|
...
|
...
|
|
...
|
|
<시스템 오퍼레이션 이름2>
|
<id 3>
|
...
|
...
|
|
...
|
|
<id 4>
|
...
|
...
|
|
...
|
|
...
|
...
|
...
|
...
|
|
...
|
|
서브시스템 오퍼레이션 조사의 예
화이트 박스 단계 및 오퍼레이션 실현 작업이 끝나면 서브시스템 오퍼레이션 및 지정된 동작이 식별됩니다. 시스템 오퍼레이션 식별과 마찬가지로, 각각의 화이트 박스 단계에 대해 고유한 서브시스템 오퍼레이션이 없을
수도 있습니다. 즉, 화이트 박스 단계 세트 및 연관된 메시지 교환, 입출력(I/O) 엔티티 등을 조사하면 요구를 충족시키기 위해 더 작은 서브시스템 오퍼레이션 세트를 정의할 수 있다는 것을 알게 될지도
모릅니다.
조사 표를 지역성 또는 프로세스별로 다시 정렬하여 각각의 지역성이나 프로세스와 서브시스템 오퍼레이션 세트의 연관성을 표시할 수 있습니다. 지역성으로 정렬하면 지역성에서의 컴퓨팅 로드를 파악할 수 있으므로 지역성을
지원하는 실제 컴포넌트의 용량을 추론하는 데 유용합니다. 이러한 형태로 지역성별로 정렬된 조사는 배치 모델의 특성이 됩니다.
서브시스템 오퍼레이션이 여러 지역성에서 호스트될 경우 이는 적어도 서브시스템의 일부가 복제된다는 것을 나타냅니다. 이렇게 복제된 부분이 반드시 데이터를 공유하거나 동기화 상태를 유지하지는 않습니다.
이러한 사항은 응용프로그램 및 복제 이유에 따라 결정되는 디자인 선택사항입니다. 예를 들어, 필요한 처리가 동일하더라도 다른 비즈니스 세그먼트에 대해 발생할 수 있습니다. 극단적인 경우 모든 서브시스템의
오퍼레이션을 여러 지역성에서 호스트할 수 있습니다. 즉, 서브시스템 자체가 효율적으로 복제됩니다. 복제된 인스턴스를 고유하게 식별해야 하는지 여부는 또한 복제 이유에 따라 결정됩니다.
프로세스 정렬을 통해 디자이너는 동시성 문제를 추론할 수 있습니다. 서브시스템 오퍼레이션을 액터에게 제공되는 별개의 기능성으로 보는 경우 첫 번째 추정에서 동일한 프로세스와 연관된 오퍼레이션은 병렬로 수행될 수
없습니다. 따라서 디자이너가 프로세스 할당을 다시 고려하거나, 프로세스 복제를 고려하거나, 또는 낮은 세부화 레벨에서 파악된 대기 문제를 조사하여(예: 시간 배분 옵션을 조사) 오퍼레이션이 블록될 때(예:
입출력(I/O)을 위해) 공유를 처리해야 할 수도 있습니다. 이러한 기법은 적합한 응답성을 제공할 수는 있지만 오퍼레이션(엄격한 직렬화 오퍼레이션) 시작이 지연되는 문제를 피할 수 없습니다. 이러한 형태로
프로세스별로 정렬된 조사는 디자인 모델의 특성이 됩니다.
|