Process behavior lookup in Rational Team Concert 2.0
사용자가 프로세스 활용 오퍼레이션을 수행할 때는 만족해야 할 전제조건, 실행할 후속조치를 결정하는 데, 이를 일컬어 오퍼레이션 "동작"이라고 합니다. 동작은 사용자에게 지정된 역할, 오퍼레이션이 수행되는 프로세스 영역, 수행되는 시점에 따라 계산됩니다. 정확한 동작을 위해선 이런 여러 요소들을 정확히 조합해야 합니다.
프로세스 런타임에 의해 수행될 전제 조건과 후속 조치는 프로세스 XML에서 선택된 단일 "오퍼레이션" 요소로 부터 비롯됩니다. 이런 요소를 일컬어 "오퍼레이션 구성" 또는 "동작 구성" 이라 합니다. 각각의 오퍼레이션 구성은 하나의 유닛 단위로 제한하며, 여러 구성을 조합해서 전제 조건과 후속 조치를 만들지 않습니다. 팀 프로세스가 복잡해 지면, 여러 오퍼레이션 구성을 있게 됩니다. 오퍼레인션 동작은 프로젝트 영역과 각 팀 영역별로 다르게 구성할 수 있습니다. 프로젝트 영역이나 각 팀 영역 내에서도, 각 반복 유형별로 그리고 각 반복 인스턴스별로 동작을 구성할 수 있습니다. 그리고 이들 내에서, 같은 오퍼레이션는 각각의 역할별로 구성할 수 있습니다. 이런 요소들을 살펴보고 정확한 구성을 찾을 수 있습니다.
어떻게 검색하는 지 간단히 요약하면 다음과 같습니다. 아래에서는 각각을 분해해서 알고리즘을 상세히 알려드리겠습니다. 검색은 해당 오퍼레이션을 지배하는 프로세스 영역으로 부터 출발합니다. 사용자에게 지정된 각각의 역할에 대해, 오퍼레이션에 대한 구성을 지배하는 프로세스 영역에서 먼저 찾고 차례로 거슬러서 프로젝트 영역까지 검색합니다. 하나의 영역에서 여러 반복에 대해 구성을 한 경우에는, 현재 시점에 가정 적합한 구성을 선택합니다. 사용자의 역할들 중 가장 먼저 찾은 동작 구성를 사용합니다.
검색은 해당 오퍼레이션을 지배하는 프로세스 영역으로 부터 출발합니다.
각각의 오퍼레이션별로 오퍼레이션이 영향을 끼치는 산출물을 기초로 해당 오퍼레이션을 지배하는 프로세스 영역을 결정합니다. 예를 들면, 변경 세트를 스트림으로 전달할 때는, 대상 스트림을 소유한 프로세스 영역이 전달 오퍼레이션을 지배하는 프로세스 영역이 됩니다. 그리고 작업 항목을 저장할 때는, 작업 항목의 카테고리에 연관되어 있는 프로세스 영역이 작업 항목 저장 오퍼레이션을 지배하는 프로세스 영역이 됩니다.
시나리오 1:
어떤 개발자가 Cool Developer's Workspace로 부터 변경 세트를 Platform Core Stream으로 전달하고 있습니다. 대상 스트림은 Platform Core Team이 소유하고 있으므로, 이 팀 영역이 전달 프로세스를 지배하게 됩니다.
시나리오 2:
어떤 개발자가 Cool Developer's Workspace로 부터 변경 세트를 Cool Tools Stream으로 전달하고 있습니다. 대상 스트림은 Cool Tools Team이 소유하고 있으므로, 이 팀 영역이 전달 프로세스를 지배하게 됩니다.
해당 프로세스 영역에서 사용자에게 지정된 각각의 역할에 대해, 동작 구성 찾기를 시작합니다.
지배하는 프로세스 영역을 찾은 다음에는, 사용자에게 지정된 역할의 순서에 따라서, 동작 구성 찾기를 시작합니다. 예를 들어, team lead 역할과 developer 역할 순으로 지정된 경우에는, 먼저 team lead 역할에 대한 동작 구성을 찾습니다. team lead 역할에 대한 동작 구성을 찾지 못하면, developer 역할에 대한 동작 구성을 찾습니다. 마찬가지로 찾지 못하면, 모든 사용자(default 역할)에 대한 동작 구성을 찾습니다. 이런 순서로 찾은 첫번째 역할의 동작 구성이 효과를 발휘하며, 다수 역할로 부터 동작 구성을 조합해서 사용하지 않습니다.
사용자에게 지정된 모든 역할은 지배하는 프로세스 영역에서 지정된 역할과 프로젝트 영역에까지 이르는 부모 프로세스 영역에서 지정된 역할을 모두 합친 것입니다. 프로젝트나 팀 영역에서 지정된 역할의 순서에 따라서 동작 구성을 검색함으로, 이런 순서는 역할의 우선 순위를 나타냅니다.
사용자의 모든 역할을 계산하기 위해서는, 여러 팀과 프로젝트 영역으로 부터 역할을 조합해야 합니다. 검색 순서는 다음과 같습니다. 먼저, 지배하는 프로세스 영역에서 지정된 역할을 순서대로 검색합니다. 그 다음 부모 팀 영역에 있는 역할 순서에 따라 검색을 하고, 그 다음 프로젝트 영역에 있는 역할 순서에 따라 검색을 하고, 마지막으로 모든 사용자에 적용되는 default 역할을 검색합니다. 즉 팀 영역에 지정된 역할이 부모 팀 영역이나 프로젝트 영역에서 지정된 역할 보다 우선합니다. 부모 팀 영역에서 지정한 역할울 자식 팀 영역에서 사용하고자 한다면, 같은 역할을 자식 팀 영역에서 지정할 수 있습니다.
시나리오 1:
Cool SDK Project, Platform Team, Platform Core Team에서 새로운 역할이 지정되어 있습니다. Platform Core Team에서 동작 구성을 검색할 때는, 다음 역할 순서대로 검색합니다 : developer, buildmeister, team lead, project manager, project admin, default.
시나리오 2:
Platform Core Team에서 Cool SDK Project과 Platform Team에서 지정한 역할을 재지정해서 순위를 높였습니다. Platform Core Team에서 동작 구성을 검색할 때는, 다음의 역할 순서에 따라 검색합니다 : project manager, team lead, developer, buildmeister, project admin, default.
지배하는 프로세스 영역에서 먼저 동작 구성을 찾고, 부모 프로세스 영역들을 따라서 프로젝트 영역까지 검색합니다.
특정 역할에 대한 오퍼레이션 동작을 찾기 위해서, 지배하는 프로세스 영역과 부모 프로세스 영역 및 프로젝트 영역의 구성을 조사합니다. 먼저, 지배하는 프로세스 영역에서 해당 역할에 대한 동작 구성을 찾고, 동작 구성을 지배하는 프로세스 영역에서 찾을 수 없으면, 차례로 부모 프로세스 영역에서 프로젝트 영역(검색 순위가 가장 낮음)까지 찾아 봅니다. 만약 "final" 플래그가 오퍼레이션 동작에 설정되어 있으면, 설정된 팀 영역 또는 프로젝트 영역 아래에 있는 동작 구성은 무시됩니다.
시나리오 1:
개발자가 Cool Developer's Workspace으로 부터 Platform Core Stream으로 변경 세트를 전달할려고 합니다. 대상 스트림을 Platform Core Team이 소유하고 있으므로, "Platform Core Team" 팀 영역을 먼저 조사하고, 다음은 "Platform Team" 팀 영역을 조사하고, 마지막으로 "Cool SDK Project" 프로젝트 영역을 조사합니다.
시나리오 2:
개발자가 Cool Developer's Workspace으로 부터 Cool Tools Stream으로 변경 세트를 전달할려고 합니다. 대상 스트림을 Cool Tools Team을 소유하고 있으므로, 먼저 "Cool Tools Team" 팀 영역을 조사하고, 그 다음에 "Cool SDK Project" 프로젝트 영역을 조사합니다.
하나의 프로세스 영역에서 여러 반복에 대해 동작 구성을 한 경우에는, 현재 시점에 가정 적합한 구성을 선택합니다.
각각의 팀 영역에 대해서, 팀 사용자 정의를 조사함으로써 해당 팀 영역의 해당 역할에 대한 동작 구성이 있는 지 알 수 있습니다. 프로젝트 영역의 경우에는, 프로세스 구성 내의 "팀 구성" 섹션을 조사합니다. 팀 사용자 정의 또는 프로세스 구성에는, 특정 반복 또는 모든 반복에 대해 동작 구성을 할 수 있습니다. 동작 구성을 검색할 때는, "현재 반복"과 해당 반복의 부모 반복들의 사용자 정의를 고려합니다.
지배하는 프로세스 영역이 속하는 스케줄이 있는 지를 체크함으로써 현재 반복이 있는 지 알 수 있습니다. 각각의 프로세스 영역은 많아야 하나의 스케줄을 가질 수 있으며, 스케줄은 반드시 하나의 현재 반복만을 갖게 됩니다. 팀 영역의 스케줄은 팀 영역에 수동으로 지정된 스케줄이 있는 지를 먼저 체크해서, 알 수 있습니다. 팀 영역에 지정된 스케줄이 없다면, 프로젝트 스케줄을 찾습니다. 프로젝트 스케줄 마저도 없다면, 팀 영역에는 지정된 스케줄이 없으므로, 현재 반복도 없게 됩니다. 프로젝트 영역의 스케줄은 프로젝트 스케줄이 있는 지 체크해서 알 수 있습니다. 여기서는 팀 영역에 스케줄이 지정되어 있다고 가정을 하고 기술을 합니다. 반복은 스케줄 내에서 위계적으로 정의할 수 있으며, 위계상에서 하나의 반복만이 현재로 설정될 수 있습니다. 현재 반복과 스케줄에 이르는 경로 상의 부모 반복들이 고려 대상이 됩니다. 각 반복은 특정 유형에 속할 수 있고, 특정 유형은 사용자 정의될 수 있습니다.
먼저 현재 반복 상에서의 오퍼레이션 구성을 먼저 찾습니다. 현재 반복에서 동작 구성이 되어 있지 않다면, 현재 반복의 반복 유형에 동작 구성이 되어 있는 지 조사합니다. 현재 반복이나 현재 반복의 반복 유형에도 오퍼레이션 구성이 되어 있지 않다면, 부모 반복이나 부모 반복의 유형, 그리고 차례로 팀 사용자 정의 (프로젝트 영역의 팀 구성)까지 조사합니다. 이런 경로상의 검색을 통해서, 현재 반복에 가정 적절한 동작을 사용하도록 설계되어 있습니다.
프로젝트의 시간상 흐름에 따라 어떤 의미를 갖는 지 몇 가지 시나리오를 통해 알아보도록 하겠습니다. 아래 예에서는, 프로젝트가 다음과 같은 반복을 갖고 있고, 팀 영역 사용자 정의를 통해 다양한 지점에서 오퍼레이션을 구성했습니다. (아래 예에서는, 역할은 무시합니다. 다만, 사용자의 역할별로 그 순서에 따라 아래와 같은 검색이 일어난다는 점을 기억하세요.)
프로젝트 셋업:
Cool SDK Project는 두 개의 스케줄을 정의합니다 : Main Development, 1.x Maintenance. Main Development 스케줄은 여러개의 반복 구조와 "stabilization" 반복 유형을 정의합니다. 몇몇 반복은 stabilization 반복 유형으로 선언합니다. "Platform Team" 팀 영역은 Main Development 스케줄에 정의함으로써, 본 스케줄에 정의된 반복을 구성할 수 있도록 합니다. 사용자 정의를 통해서 "2.0 Development Phase" 및 "Milestone 2 Endgame" 반복에 대한 오퍼레이션 동작을 구성합니다(갈색과 오렌지색). 그리고 "stabilization" 반복 유형에 대한 구성을 합니다(자주색).
시나리오 1: Milestone 1
현재 반복이 "Milestone 1"일 때, 동작 구성에 대한 검색을 보여줍니다. 검색 과정은 다음과 같습니다: Platform Team은 Milestone 1에 대한 동작 구성을 가지고 있는 가? 아니오. Milestone 1은 반복 유형을 가지고 있는 가? 아니오. Platform Team은 부모 반복, 즉 2.0 Development Phase에 대한 동작 구성을 가지고 있는 가? 예. 결론적으로 현재 반복이 "Milestone 1"일 때, 2.0 Development Phase에 구성된 동작이 영향을 발휘합니다.
시나리오 2: Milestone 1 Endgame
현재 반복이 "Milestone 1 Endgame"일 때, 동작 구성에 대한 검색을 보여줍니다. 검색 과정은 다음과 같습니다: Platform Team은 Milestone 1 Endgame에 대한 동작 구성을 가지고 있는 가? 아니오. Milestone 1 Endgame은 반복 유형을 가지고 있는 가? 예,"stabilization"이죠. Platform Team은 stabilization 반복 유형에 대한 동작 구성을 가지고 있는 가? 예. 결론적으로 현재 반복이 "Milestone 1 Endgame"일 때, stabilization 반복 유형에 구성된 동작이 영향을 발휘합니다.
시나리오 3: Milestone 2 Endgame
현재 반복이 "Milestone 2 Endgame"일 때, 동작 구성에 대한 검색을 보여줍니다. 검색 과정은 다음과 같습니다: Platform Team은 Milestone 2 Endgame에 대한 동작 구성을 가지고 있는 가? 예. 결론적으로 현재 반복이 "Milestone 2 Endgame"일 때, Milestone 2Endgame에 구성된 동작이 영향을 발휘합니다. 반복 자체에 구성된 동작이 반복 유형("stabilization")에 구성된 동작보다 우선합니다.
요약각 부분에 대한 검색 과정의 이해를 통해 다음과 같이 정리할 수 있습니다. 수행할 전제 조건과 후속 조치를 계산하기 위해서는 다음과 같은 단계를 따라 오퍼레이션 동작에 대한 구성을 검색합니다:
- 오퍼레이션을 지배하는 프로세스 영역을 결정합니다.
- 지배하는 프로세스 영역에서 프로젝트 영역에 이르는 영역 상에서의 사용자의 역할을 계산합니다.
- 순서에 따라, 각각의 역할에 대해서:
- 지배하는 프로세스 영역에서 출발합니다.
- 지배하는 프로세스 영역 및 프로젝트 영역에 이르기까지의 각각의 부모 팀 영역에 대해서:
- 현재 반복 및 상위 부모 반복에서 대해서:
- 먼저, 반복 자체에 정의된 동작 구성을 찾습니다.
- 다음, 반복 유형에 정의된 동작 구성을 찾습니다.
- 해당 영역에서 동작 구성을 찾으면, 해당 구성을 기억합니다.
- 부모 영역에서 동작 구성을 찾고, final로 설정되어 있으면, 이 구성을 대신 기억합니다.
- 위계를 따라 모든 검색을 마친 후, 기억한 동작 구성이 있으면, 해당 동작 구성을 사용합니다.
- 현재 반복 및 상위 부모 반복에서 대해서:
마지막 예제로, 사용자가 변경 세트를 스트림으로 전달할 때의 동작 구성에 대한 검색과정을 알아보도록 하겠습니다.
먼저, 다음 세가지 정보를 수집합니다: 1) 지배하는 프로세스 영역, 2) 사용자에게 지정된 역할 목록, 3) 현재 반복. 지배하는 프로세스 영역을 계산하기 위하여, 전달 오퍼레이션을 지배하는 프로세스 영역을 알아 봅니다. 변경 세트를 전달할 대상 스트림인 "Platform Core Stream"을 소유하고 있는 "Platform Core Team" 팀 영역을 지배하는 프로세스 영역으로 합니다. 사용자에게 지정된 역할 목록을 계산하기 위해, Platform Core Team에서 지정된 역할부터 조사를 하고, 그 다음은 Platform Team을 조사하고, 마지막으로 Cool SDK Project을 조사합니다. 중간에 중복 지정되는 역할들은 배제를 합니다. project manager, team lead, developer, project admin, default 역할 목록을 작성할 수 있습니다. 현재 반복을 계산하기 위해, 프로젝트 영역을 조사합니다. 현재 반복으로 "Release Candidate 1"이 설정되어 있습니다.
역할을 순서에 따라, "project manager"부터 검색 시작을 합니다. Platform Core Team를 먼저 조사합니다. "Release Candidate 1" 반복에 project manager 역할에 대한 동작 구성을 찾아 봅니다. 다음으로 Release Candidate 1의 반복 유형(없음)을 조사합니다. 다음, 부모 반복인 "2.0 Stabilization Phase"에서의 동작 구성을 찾아 봅니다, 이어서 부모 반복에 대한 반복 유형,"stabilization"을 조사합니다. 최종적으로, 최상위의 팀 사용자 정의에 구성된 project manager 역할에 대한 동작을 조사합니다. 동작 구성을 찾을 땐, 기억을 하고, Platform Core Team에 대한 조사를 중단합니다.
다음으로, Platform Team에서의 동작 구성에 대한 조사를 합니다. 다시, 현재 반복에서 부터 출발합니다. Platform Team에서 동작 구성을 찾게되면, "final"로 설정되어 있는 지 조사합니다. 그렇다면, 이 구성을 기억을 하고, 그렇지 않다면 대신 Platform Core Team에서 찾은 구성을 계속 기억합니다. Platform Team을 조사한 뒤에는, Cool SDK Project로 옮깁니다. Cool SDK Project에서의 project manager에 대한 동작 구성 검색은 각 팀 영역에서 했던 것과 같습니다만 프로세스 구성 상의 팀 구성 섹션에만 제한됩니다. 마찬가지로, 구성을 찾게되면 final인지 체크합니다. 그렇다면, 이 구성을 사용하고, 그렇지 않다면, 팀 영역 구조 상에서 (있었다면) 기억해 둔 구성을 사용합니다.
프로젝트 영역까지 모두 조사를 하고도 동작 구성을 찾지 못한 경우에는, 순서상 다음 역할인 "team lead"로 이동합니다. 다시, Platform Core Team으로 시작해서 현재 반복 상에서의 동작 구성을 찾고, Platform Team과 Cool SDK Project에서 같은 조사를 계속합니다. 마마지막 default 역할에 이르기까지 다른 역할에 대해서 조사를 합니다.
"final" 플래그: final 플래그는 해당 영역내에서의 검색에 영향을 주지는 않습니다(영역의 일부분을 무시하도록 선언할 순 없습니다). 팀 영역 또는 프로젝트 영역에서 final과 non-final 구성을 혼합시킬 경우 혼란스러울 수 있습니다. 이런 경우, XML을 조사해서는 자식 팀 영역의 사용자 정의를 무시할 수 있는 지 알 수 없습니다; 현재 반복에 따라 실제로 달라질 수 있습니다.
예를 들어, 어떤 팀이 어떤 반복에서 어떤 오퍼레이션에 대한 구성을 final설정을 했다고 합니다. 다른 구성이 없다면, 분명히 해당 반복, 모든 자식 반복 동안에는 이 구성이 적용되고, 이 반복 동안은 모든 자식 팀 영역의 사용자 정의는 무시됩니다. 그렇다면, 자식 반복에서 non-final로 해당 구성을 설정하면 어떻게 될까요? 프로세스 런타임은 이를 다음과 같은 뜻으로 해석합니다 : "부모 반복 및 이 반복을 제외한 모든 자식 반복에서, 동작 구성은 final로 설정됩니다. 하지만 해당 특정 반복에서, 팀 영역들은 오퍼레인션 동작 구성을 사용자 정의할 수 있습니다." 구성된 자식 반복 기간동안, 모든 자식 팀 영역의 사용자 정의는 갑자기 생명을 얻게 되고, (현재 반복에 명시된 것 뿐아니라) 어떤 동작 구성도 부모의 구성을 정상적으로 겹쳐쓰게 됩니다.
댓글 없음:
댓글 쓰기