목적
  • 동시성 요구사항 분석, 프로세스 식별, 프로세스 내 의사소통 메커니즘 식별, 프로세스 내 조정 자원 할당, 프로세스 라이프사이클 식별 및 프로세스 간 모델 요소를 분배하기 위함입니다.
역할:  소프트웨어 아키텍트 
빈도: 특히 구현화 단계 중에 반복당 한 번.
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

활성 객체(활성 클래스의 인스턴스)는 시스템에서 동시 실행 스레드를 표시하는데 사용합니다. 개념적으로, 각 활성 객체에는 고유 제어 스레드가 있으며 관례적으로 실행 스택 프레임의 루트입니다. 활성 객체를 실제 운영 체제 스레드나 프로세스에 맵핑하는 것은 응답 요구사항에 따라 달라질 수 있으며 오버헤드를 전환하는 컨텍스트의 고려사항에 영향을 받을 수 있습니다. 예를 들어, 단순 스케줄러와 공동으로 여러 활성 객체가 단일 운영 체제 스레드와 공유하여 동시에 실행 중인 것처럼 표시되는 것이 가능합니다. 그러나 예를 들어 임의의 활성 객체가 동기적 입/출력(I/O)을 수행하여 차단된 작동을 표시하는 경우, 해당 그룹의 기타 활성 객체는 운영 체제 스레드가 차단된 동안 발생한 이벤트에 응답할 수 없습니다.

반면, 각 활성 객체에 고유 운영 체제 스레드를 부여하는 것은 처리 자원이 추가 컨텍스트 전환 오버헤드에 불리한 영향을 받지 않는다는 가정 하에 보다 월등한 응답성을 초래합니다.

이 활동이 활성 클래스와 해당 인스턴스 및 이들의 운영 체제 스레드와 프로세스에 대한 관계 면에서 시스템의 프로세스 구조를 정의합니다.  

구현화 단계의 초기에 이 구조는 매우 예비적이지만 구현화 말기에는 프로세스와 스레드가 제대로 정의되어야 합니다.

이 활동의 결과는 설계 모델(특히, 프로세스 보기)에 캡처됩니다(개념: 프로세스 보기 참조).

동시성 요구사항 분석 페이지 맨 위

목적  타스크의 병렬 실행이 시스템에 필수인 정도를 정의하기 위함입니다. 이 정의가 구조 형성에 도움이 됩니다.  

활동: 설계 요소 식별 중에 자연스럽게 발생하는 문제점 도메인의 동시성에 대한 요구에 의해 주도되는 동시성 요구사항이 고려됩니다.  

이 결과는 시스템에서 제어의 논리 스레드를 표시하는 활성 클래스 세트입니다.  

이 단계에서 기타 동시성 요구사항의 소스(시스템의 비기능적 요구사항에 의해 부과된 사항)를 고려합니다.

동시성 요구사항은 다음에 의해 구동됩니다.

  • 시스템이 분배되어야 하는 정도. 작동이 프로세서 또는 노드에 걸쳐 분배되어야 하는 시스템은 사실상 멀티 프로세스 구조를 필수로 합니다. 트랜잭션 관리자 또는 데이터베이스 관리 시스템의 일부 종류를 사용하는 시스템도 해당 주요 서브시스템이 도입하는 프로세스를 고려해야 합니다.
  • 중요한 알고리즘의 계산 강도. 좋은 응답 시간을 제공하려면 고유 프로세스 또는 스레드에 컴퓨터를 집중적으로 사용하는 활동을 두어 컴퓨터를 계속 사용하는 중에도 시스템이 보다 적은 자원을 사용하여 여전히 사용자 입력에 대한 응답을 할 수 있도록 있습니다.
  • 환경이 제공하는 병렬 실행의 정도. 운영 체제 또는 환경이 스레드(경량 프로세스)를 지원하지 않는 경우 시스템 구조에 미치는 영향을 고려해야 할 점이 거의 없습니다.
  • 시스템에서 결함 허용치 필요. 백업 프로세서가 백업 프로세스를 필수로 하며 해당 요구사항을 기본으로 유지하고 백업 프로세스를 동기화하도록 구동합니다.
  • 시스템에서 이벤트의 도착 패턴. 외부 장치 또는 센서가 있는 시스템에서 들어오는 이벤트의 도착 패턴은 센서별로 다를 수도 있습니다. 일부 이벤트는 주기적(주기적으로 발생. 소량을 더하거나 뺄 수 있음) 또는 비주기적(비주기적인 간격)일 수 있습니다. 다른 이벤트 패턴을 생성하는 장치를 표시하는 활성 클래스는 일반적으로 다른 스케줄링 알고리즘이 있는 다른 운영 체제에 지정되어 이벤트 또는 처리 최종 기한을 놓치지 않게 합니다(시스템의 요구사항인 경우).

여러 구조적 문제점과 함께 이러한 요구사항은 다소 상호 독점적일 수 있습니다. 적어도 처음에는 충돌하는 요구사항이 있는 것이 일반적입니다. 중요성 관점에서 요구사항의 등급을 매기는 것이 충돌을 해결하는데 도움이 됩니다.

프로세스 및 스레드 식별 페이지 맨 위

목적  시스템에 있는 프로세스 및 스레드를 정의하기 위함입니다.  

가장 단순한 접근법은 모든 활성 객체를 공용 스레드 또는 프로세스에 할당하고 단순 활성 객체 스케줄러가 컨텍스트 전환 오버헤드를 최소화하므로 해당 스케줄러를 사용하는 것입니다. 그러나 일부 경우에 하나 이상의 스레드 또는 프로세스에 활성 객체를 분배하는 것이 필요할 수도 있습니다.

기타 활성 객체와 운영 체제 스레드를 공유하는 활성 객체는 일부 기타 프로세스 또는 스레드에 동기적 호출을 합니다. 이 호출이 불러온 객체의 공유 운영 체제 스레드를 차단한 다음 호출 프로세스에 있는 기타 모든 활성 객체를 자동으로 일시중단합니다. 이제, 이 경우는 제거될 수 있습니다. 활성 객체의 관점에서 동기적인 호출이 활성 객체 그룹을 제어하는 단순 스케줄러의 관점에서 비동기적으로 처리될 수도 있습니다. 스케줄러가 호출하는 활성 객체를 일시 중단한 다음(동기적 호출의 완료를 기다림) 기타 활성 객체가 실행되도록 스케줄합니다.  

본래의 '동기적' 작업이 완료되면 호출된 활성 객체가 재개될 수 있습니다. 그러나 이 접근법은 언제나 가능하지는 않을 수 있습니다. 왜냐하면, 스케줄러가 모든 동기적 호출을 차단하기 전에 가로채도록 설계될 가능성이 없을 수도 있기 때문입니다. 일반적으로, 동일한 운영 체제 프로세스 또는 스레드를 사용하여 활성 객체 간 동기적 호출이 이러한 방식으로 스케줄러에 의해 처리될 수 있으며, 사실상 동기적 호출이 활성 객체 호출 관점에서 프로시저 호출과 동등함을 참고하십시오.

이로써, 활성 객체가 스레드를 차단하는 동기적 호출과 함께 동시적으로 실행되어야 하는 필요에 따라 프로세스 또는 스레드로 그룹화되어야 한다는 결론에 이르게 됩니다. 즉, 활성 객체가 스레드를 차단하는 동기적 호출을 사용하는 다른 객체와 함께 스레드 또는 동일한 프로세스에서 패키지되어야 하는 유일한 경우는 해당 객체와 동시적으로 실행될 필요가 없고 기타 객체가 차단된 동안에 실행되지 못하는 상황을 견딜 수 있는 경우입니다. 극단적인 경우로 응답성이 중요한 때, 각 활성 객체에 별도의 스레드 또는 프로세스가 필요하게 될 수 있습니다.

일반적인 규칙으로서, 위의 상황에서는 경량의 스레드가 오버헤드에 덜 관련되므로 완전히 발달된 프로세스 대신에 사용하는 것이 좋습니다. 그러나 여전히 일정 특수 경우에 프로세스의 일부 특성을 이용하고자 할 수도 있습니다. 스레드가 동일한 주소 공간을 공유하므로 프로세스보다 더 위험합니다. 우발적인 겹쳐쓰기 가능성에 관해서는 프로세스가 선호됩니다. 더우기, 프로세스가 대부분의 운영 체제에서 독립적 복구 장치를 표시하므로 서로 독립적으로 복구되어야 하는 필요를 기반으로 프로세스에 활성 객체를 할당하는 것이 유용할 수도 있습니다. 즉, 장치로서 복구되어야 하는 모든 활성 객체는 동일한 프로세스에서 함께 패키지되어야 할 수도 있습니다.

시스템에 필요한 별도의 각 제어 플로우에 대해 프로세스나 스레드(경량 프로세스)를 작성하십시오. 스레드는 제어의 중첩 플로우가 필요한 경우 사용되어야 합니다(프로세스 내에서 서브타스크 레벨의 독립적 제어 플로우가 필요한 경우).

예를 들어, 별도의 제어 스레드가 다음을 필요로 할 수도 있습니다(반드시 중요성 때문은 아님).

  • 다른 영역의 소프트웨어 간 관심사 분리
  • 분배 시스템에서 한 노드 또는 여러 노드의 여러 CPU 이용
  • 제어 스레드가 일시중단된 경우 기타 활동에 주기를 할당하여 CPU 이용 증대
  • 활동 우선 순위 지정
  • 여러 프로세스 및 프로세서에 걸쳐 로드 공유 지원
  • 백업 프로세스로 보다 높은 시스템 사용 가능성 달성
  • DBMS, 트랜잭션 관리자 또는 기타 주요 서브시스템 지원.

자동 예금 인출기에서는 다음 세 가지 다른 소스에서 시작되는 비동기 이벤트가 처리되어야 합니다. 시스템의 사용자, ATM 장치(예: 현금 자동 지급기에 정지가 생긴 경우) 또는 ATM 네트워크(네트워크에서 직접 시스템 종료하는 경우). 이러한 비동기 이벤트를 처리하도록 UML의 활성 클래스를 사용하여 아래 표시된 대로 ATM 자체에 세 가지 별도 실행 스레드를 정의할 수 있습니다.

ATM 프로세스 및 스레드 설명

ATM의 프로세스 및 스레드

프로세스 라이프사이클 식별 페이지 맨 위

목적  프로세스 및 스레드가 작성되고 파기되는 시기를 식별하기 위함입니다.  

각 제어 스레드 및 프로세스가 작성되고 파기되어야 합니다. 단일 프로세스 구조에서 어플리케이션 시작시 프로세스가 작성되고 어플리케이션 종료시 프로세스 파기가 발생합니다. 다중 프로세스 구조에서 새 프로세스(또는 스레드)가 일반적으로 어플릴케이션 시작시 운영 체제가 작성한 초기 프로세스에서 생기거나 분기됩니다, 이러한 프로세스는 또한 명시적으로 파기되어야 합니다.

프로세스 작성 및 파기까지 초래하는 이벤트의 시퀀스가 작성 및 삭제 메커니즘과 함께 판별되고 문서화되어야 합니다.

자동 현금 인출기에서 전체 시스템의 작동을 조정할 책임이 있는 한 기본 프로세스가 시작합니다. 차례로 제어의 여러 종속 스레드를 산출하여 다음과 같은 시스템의 여러 파트를 모니터합니다. 시스템 장치, 고객 또는 ATM 네트워크에서 나오는 이벤트. 이러한 프로세스 및 스레드 작성은 UML의 활성 클래스로 표시될 수 있으며, 이러한 활성 클래스의 인스턴스 작성은 아래에 표시된 대로 순서 다이어그램으로 표시될 수 있습니다.

시스템 시작 프로세스 및 스레드 작성 설명

시스템 시작 중 프로세스 및 스레드 작성

프로세스 간 의사소통 메커니즘 식별 페이지 맨 위

목적  ㅎ프로세스 및 스레드가 의사소통할 수단을 식별하기 위함입니다.  

IPC(Inter-Process Communication) 메커니즘이 별도의 프로세스에서 실행 중인 객체 간 메시지를 전송 가능하게 합니다.

일반적인 프로세스 간 의사소통 메커니즘에는 다음이 포함됩니다.

  • 공유 메모리, 동기화를 확인하는 세마포어 포함 또는 포함 안함.
  • 랑데뷰, 특히 Ada와 같은 언어가 직접 지원하는 경우
  • 세마포어, 공유 자원에 대하 동시 액세스를 차단하는데 사용
  • 메시지 전달, 지점간 및 지점 대 다지점 모두
  • 편지함
  • RPC - 원격 프로시저 호출(Remote Procedure Call)
  • 이벤트 브로드캐스트 - "소프트웨어 버스" 사용 ("메시지 버스 구조")

IPC 메커니즘의 선택이 시스템이 모델화되는 방식을 변경합니다. 예를 들어, "메시지 버스 구조"에서는 메시지를 전송하는데 객체 간 명시적 연관이 필요하지 않습니다.

프로세스 간 조정 자원 할당 페이지 맨 위

목적 드문 자원을 할당하기 위함입니다.
잠재적 성능 병목 현상을 예상하고 관리하기 위함입니다. 

프로세스 간 의사소통 메커니즘은 일반적으로 드문 경우입니다. 세마포어, 공유 메모리 및 편지함은 일반적으로 크기와 수가 고정되어 있므며 상당한 비용을 들이지 않고는 증가될 수 없습니다. RPC, 메시지 및 이벤트 브로드캐스트가 점점 더 드문 네트워크 대역폭을 흡수합니다. 시스템이 소스 임계값을 초과하면 일반적으로 비선형 성능 저하를 경험하게 됩니다. 드문 자원이 모두 사용되면 해당 자원에 대한 후속 요청이 불쾌한 효과를 일으킬 가능성이 큽니다.

드문 자원이 초과 등록되면 다음과 같이 고려할 여러 전략이 있습니다.

  • 프로세스의 수를 줄여 드문 자원의 필요를 줄임
  • 드문 자원의 사용법을 변경(하나 이상의 프로세스에 대해, IPC 메커니즘에 사용할 덜 드문 다른 자원을 선택)
  • 드문 자원의 수량을 증가(예: 세마포어의 수 증가). 이는 비교적 적은 변경사항으로 수행될 수 있으나 종종 부작용이나 고정된 제한사항이 있습니다.
  • 드문 자원 공유(예: 필요한 경우에만 자원을 할당한 다음 완료된 다음 할당을 해제). 이는 비용이 많이 들고 앞서 자원 위기를 초래할 수 있습니다.

선택한 전략에 상관없이 시스템은 안정되고 조용하게(고장을 내는 대신) 강등되어야 하며 시스템 관리자에게 적절한 피드백을 제공하여 시스템이 전개된 적이 있는 필드에서 문제점을 해결하도록(가능한 경우) 해야 합니다.

시스템이 주요한 자원의 사용 가능성을 증가시키기 위해 런타임 환경의 특수한 구성을 필수로 하는 경우(종종 운영 체제 커널의 재구성으로 제어됨), 시스템 설치가 이를 자동으로 수행하거나 시스템 관리자에게 이를 수행하도록 지시하여 시스템이 조작될 수 있도록 해야 합니다. 예를 들어, 시스템은 변경이 효력을 내기 전에 다시 재부팅해야 할 수도 있습니다.

프로세스를 구현 환경에 맵핑 페이지 맨 위

목적  구현 환경이 제공하는 개념에 "제어 플로우"를 맵핑하기 위함입니다.  

개념적 프로세스는 운영 환경의 특정 구조에 맵핑되어야 합니다. 여러 환경에서 프로세스 유형의 선택사항이 있습니다(최소한 일반적으로 프로세스와 스레드). 선택사항은 결합 정도(프로세스는 독립형임. 반면에 스레드는 포함된 프로세스의 컨텍스트에서 실행됨)와 시스템의 성능 요구사항(스레드 사이의 프로세스 간 의사소통은 일반적으로 프로세스 사이 해당 의사소통보다 빠르고 효율적임)을 기반으로 합니다.

여러 시스템에서 프로세스당 최대 수의 스레드 또는 노드당 프로세스가 있을 수 있습니다. 이러한 한계는 절대적이 아닐 수 있으나 드문 자원의 사용 가능성에 의해 부여된 실제적인 제한일 수 있습니다. 대상 노드에서 이미 실행 중인 스레드와 프로세스는 프로세스 구조에 제안된 스레드 및 프로세스와 함께 고려되어야 합니다. 이전 단계, 프로세스 간 조정 자원 할당의 결과가 맵핑이 작성되면 새 성능 문제점이 작성 중이지 않은지 확인하기 위해 고려되어야 합니다.

설계 요소를 제어 스레드에 맵핑 페이지 맨 위

목적  실행될 서브시스템 및 제어 클래스의 스레드를 판별하기 위함입니다.  

해당 클래스와 서브시스템의 인스턴스는 클래스 또는 서브시스템의 실행 환경을 제공하는 적어도 스레드에서 실행되어야 합니다. 해당 인스턴스는 사실 여러 다른 프로세스에서 실행할 수도 있습니다.

두 다른 전략을 동시에 사용하여 다음과 같이 "올바른" 양의 동시성을 판별하고 "올바른" 프로세스 세트를 정의합니다.

인사이드 아웃

  1. 설계 모델에서 시작하여 클래스와 서브시스템을 (a)서로 밀접하게 협력하며 (b)동일한 제어 스레드에서 실행해야 하는 협력 요소 세트로 함께 그룹화하십시오. 요소를 별도의 제어 스레드로 분리하기 전에 메시지 순서의 중간에 프로세스 간 의사소통을 도입하는 영향을 고려하십시오.
  2. 반대로, 전혀 상호 작용하지 않는 클래스와 서브시스템을 별도의 제어 스레드에 두어 분리하십시오.
  3. 이 클러스터링이 프로세스의 수를 여전히 분배 및 실제 자원의 사용을 허용하는 가장 작은 수로 감소될 때까지 진행합니다.

아웃사이드 인

  1. 시스템이 응답해야 하는 외부 자극을 식별하십시오. 각 자극을 처리할 별도의 제어 스레드와 각 서브시를 제공할 제어의 별도 서버 스레드를 정의하십시오.
  2. 실행 환경이 제공할 수 있는 수로 제어 스레드의 이 초기 세트를 줄이도록 데이터 무결성 및 일련화 제한조건을 고려하십시오.

이는 최적 프로세스 보기를 초래하는 선형의 결정적 프로세스가 아닙니다. 승인 가능한 절충안에 도달하도록 몇 개의 반복이 필요합니다.

다음 다이어그램은 ATM 내 클래스가 시스템의 프로세스 및 스레드 사이에서 분배되는 방법을 설명합니다.

프로세스 및 스레드에 걸친 ATM 클래스 분배 설명

ATM의 프로세스에 클래스 맵핑



Rational Unified Process   2003.06.15