타스크: 런타임 아키텍처 설명
이 타스크는 활성 클래스와 활성 클래스의 인스턴스, 운영 체제 스레드 및 프로세스와 이들의 관계 측면에서 시스템의 프로세스 아키텍처를 정의합니다.
목적
  • 동시성 요구사항 분석
  • 프로세스 및 라이프사이클 식별 
  • 프로세스 간 통신 메커니즘을 식별하고 프로세스 간 조정 자원 할당 
  • 프로세스에 모델 요소 분배.
관계
기본 설명

활성 오브젝트(즉, 활성 클래스의 인스턴스)는 시스템에서 동시 실행 스레드를 나타내는 데 사용됩니다. 개념적으로, 각 활성 오브젝트마다 고유의 제어 스레드가 있으며 일반적으로 활성 오브젝트는 실행 스택 프레임의 루트입니다. 활성 오브젝트를 실제 운영 체제 스레드나 프로세스에 맵핑하는 것은 응답성 요구사항에 따라 다를 수 있으며, 컨텍스트 전환 오버헤드 고려사항의 영향을 받습니다. 예를 들어, 다수의 활성 오브젝트가 단순 스케줄러와 함께 단일 운영 체제 스레드를 공유하여 동시 실행되는 것처럼 만들 수 있습니다. 그러나 임의의 활성 오브젝트가 차단 동작을 보일 경우에는(예: 동기 입출력 수행) 운영 체제 스레드가 차단된 상태에서 발생하는 이벤트에 그룹의 다른 활성 오브젝트가 응답할 수 없습니다.

이와 반대로 각 활성 오브젝트에 자체 운영 체제 스레드를 제공하면 처리 자원이 추가 컨텍스트 전환 오버헤드로 악영향을 받지 않는 한 응답성이 대폭 향상됩니다.

실시간 시스템에서  중간 산출물: 캡슐이 권장되는 동시성 모델링 방법입니다. 활성 클래스와 마찬가지로 각 캡슐마다 고유의 개념적 제어 스레드가 있지만 캡슐에는 복잡한 실시간 문제점 모델링을 보다 용이하게 하는 추가 캡슐화 및 구성 시맨틱이 있습니다.

이 타스크는 활성 클래스와 활성 클래스의 인스턴스, 운영 체제 스레드 및 프로세스와 이들의 관계 측면에서 시스템의 프로세스 아키텍처를 정의합니다. 마찬가지로 실시간 시스템의 경우, 프로세스 아키텍처가 캡슐 및 운영 체제 프로세스와 스레드에 연관된 캡슐 맵핑 측면에서 정의됩니다.

정제(Elaboration) 단계 초반에는 이 아키텍처가 상당히 예비적이지만 정제 단계 후반에는 프로세스와 스레드가 잘 정의되어야 합니다. 이 타스크의 결과는 디자인 모델, 특히 프로세스 보기에 캡처됩니다(개념: 프로세스 보기 참조).

단계
동시성 요구사항 분석
목적  시스템에 필요한 병렬 실행 정도를 정의. 이 정의는 아키텍처를 형성하는 데 도움이 됩니다.  

타스크: 디자인 요소 식별 중에 주로 문제점 도메인의 동시성 요구로 인해 자연스럽게 발생하는 동시성 요구사항이 고려되었습니다. 

이 결과는 시스템의 논리적 제어 스레드를 표시하는 활성 클래스 세트였습니다. 실시간 시스템에서 이런 활성 클래스는  중간 산출물: 캡슐로 표시됩니다.

이 단계에서는 동시성 요구사항의 다른 소스(비기능적 요구사항으로 인한 요구사항)를 고려합니다.

동시성 요구사항은 다음에서 발생합니다.

  • 시스템을 분배해야 하는 정도. 사실상 프로세서나 노드에 동작을 분배해야 하는 시스템은 다중 프로세스 아키텍처를 필요로 합니다. 일종의 데이터베이스 관리 시스템 또는 트랜잭션 관리자를 사용하는 시스템은 해당 주요 서브시스템이 도입하는 프로세스도 고려해야 합니다.
  • 주요 알고리즘의 계산 강도. 우수한 응답 시간을 제공하려면 자체 스레드나 프로세스에 계산 집약적인 활동을 배치하여 계산이 이루어지는 동안 자원이 거의 없어도 시스템이 사용자 입력에 여전히 반응할 수 있게 해야 할 수도 있습니다.
  • 환경이 지원하는 병렬 실행의 정도. 운영 체제 또는 환경이 스레드(경량 프로세스)를 지원하지 않는 경우에는 시스템 아키텍처에 미치는 영향을 고려해도 별 의미가 없습니다.
  • 시스템에서 결함 허용의 필요성. 백업 프로세서는 백업 프로세스를 필요로 하며, 기본 프로세스와 백업 프로세스를 동기화할 필요성을 부각시킵니다.
  • 시스템에서 이벤트의 도착 패턴. 외부 장치나 센서가 있는 시스템에서는 수신 이벤트의 도착 패턴이 센서마다 다를 수 있습니다. 일부 이벤트는 주기적(즉, 약간의 차이는 있지만 고정 간격으로 발생) 또는 비주기적(즉, 불규칙한 간격으로 발생)일 수 있습니다. 서로 다른 이벤트 패턴을 생성하는 장치를 나타내는 활성 클래스는 일반적으로 서로 다른 스케줄링 알고리즘을 사용하여 서로 다른 운영 체제 스레드에 지정되어 해당 이벤트나 처리 최종 기한을 놓치지 않도록 합니다(이것이 시스템 요구사항인 경우). 이런 추론은 실시간 시스템 디자인에서 사용될 때 캡슐에도 똑같이 적용됩니다.

다른 많은 아키텍처 문제점의 경우와 마찬가지로 이런 요구사항은 다소 상호 배타적일 수 있습니다. 적어도 처음에는 요구사항이 충돌하는 것은 드문 일이 아닙니다. 중요성 면에서 요구사항의 등급을 매기면 충돌을 해결하는 데 도움이 됩니다.

프로세스 및 스레드 식별
목적  시스템에 존재할 프로세스 및 스레드 정의. 

가장 단순한 접근 방식은 공통 스레드나 프로세스에 활성 오브젝트를 모두 할당하고 단순한 활성 오브젝트 스케줄러를 사용하는 것입니다. 이렇게 하면 컨텍스트 전환 오버헤드가 최소화되기 때문입니다. 그러나 일부 경우에는 하나 이상의 스레드나 프로세스에 활성 오브젝트를 분배해야 할 수도 있습니다. 대부분의 실시간 시스템이 거의 이 경우에 해당하는데, 일부 경우에는 논리 스레드를 나타내는 데 사용되는 캡슐이 엄격한 스케줄링 요구사항을 충족해야 합니다.

다른 활성 오브젝트와 운영 체제 스레드를 공유하는 활성 오브젝트가 일부 다른 프로세스나 스레드로의 동기 호출을 작성하고 이 호출이 호출 오브젝트가 공유한 운영 체제 스레드를 차단하는 경우, 호출 프로세스에 위치한 기타 모든 활성 오브젝트가 자동으로 일시중단됩니다. 이제는 이렇게 할 필요가 없습니다. 활성 오브젝트의 관점에서 동기인 호출은 활성 오브젝트 그룹을 제어하는 단순 스케줄러 관점에서 비동기로 처리될 수 있습니다. 스케줄러는 호출하는(동기 호출이 완료되기를 기다리는) 활성 오브젝트를 일시중단한 후 다른 활성 오브젝트가 실행되도록 스케줄합니다.  

원래의 '동기' 작업이 완료되면 호출 활성 오브젝트를 재개할 수 있습니다. 그러나 차단하기 전에 모든 동기 호출을 인터셉트하도록 스케줄러를 디자인할 수 없을 수도 있으므로 이 접근 방식이 항상 실현 가능한 것은 아닙니다. 동일한 운영 체제 프로세스나 스레드를 사용하는 활성 오브젝트 간의 동기 호출은 범용성을 위해 스케줄러에 의해 이런 식으로 처리될 수 있으며, 호출 활성 오브젝트의 관점에서 프로시저 호출과 사실상 동일함에 유의하십시오.

따라서 스레드를 차단하는 동기 호출과 함께 동시에 실행해야 하는 필요성을 기반으로 활성 오브젝트를 프로세스나 스레드로 그룹화해야 한다는 결론에 도달합니다. 즉, 스레드를 차단하는 동기 호출을 사용하는 다른 오브젝트와 함께 활성 오브젝트를 동일한 프로세스나 스레드로 패키징해야 하는 유일한 경우는 해당 오브젝트와 함께 동시에 실행하지 않아도 되는 경우이며, 기타 오브젝트가 차단된 상태에서 실행되지 않도록 할 수 있습니다. 극단적인 경우로 응답성이 중요한 경우에는 각각의 활성 오브젝트에 대해 별도의 스레드나 프로세스가 있어야 한다는 결론에 도달합니다.

실시간 시스템의 경우, 캡슐의 메시지 기반 인터페이스는 적어도 캡슐 간 통신의 경우에는 지원 운영 체제 스레드가 절대로 차단되지 않도록 하는(캡슐이 다른 캡슐과 비동기로 통신하는 경우에도) 스케줄러를 구상하는 것이 더 간단함을 의미합니다. 그러나 캡슐은 여전히 운영 체제에 직접 요청을 발행하여 스레드를 차단할 수 있습니다(예: 동기 시한 대기의 경우). 캡슐이 공통 스레드를 공유하고 단순 스케줄러를 사용하여 동시성을 시뮬레이션할 경우, 캡슐이 호출하는 하위 레벨 서비스에 대해 이 동작을 방지하는 규칙을 설정해야 합니다.

일반적으로 위 상황에서는 완전한 프로세스 대신 간단한 스레드를 사용하는 것이 더 좋습니다(오버헤드를 덜 발생시키므로). 그러나 특별한 경우에는 여전히 프로세스의 특수 특성을 일부 활용하고자 할 수 있습니다. 스레드는 동일한 주소 공간을 공유하므로 본질적으로 프로세스에 비해 위험성이 더 많습니다. 우연한 겹쳐쓰기 가능성이 문제되는 경우에는 프로세스가 더 낫습니다. 더욱이 프로세스는 대부분의 운영 체제에서 독립적인 복구 단위를 나타내므로 서로 별개로 복구 필요성을 기반으로 프로세스에 활성 오브젝트를 할당하는 것이 유용할 수 있습니다. 즉, 단위로 복구해야 하는 모든 활성 오브젝트를 동일한 프로세스에서 함께 패키징할 수 있습니다.

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

예를 들어, 다음을 수행하려면 별도의 제어 스레드가 필요할 수 있습니다.

  • 서로 다른 소프트웨어 영역 간에 문제 분리
  • 분산 시스템의 하나의 노드 또는 다중 노드에서 다중 CPU 활용
  • 제어 스레드가 일시중단될 경우 다른 활동에 주기를 할당하여 CPU 이용률 증대
  • 활동 우선순위 결정
  • 여러 프로세스와 프로세서 간에 로드 공유 지원
  • 백업 프로세스를 통해 시스템 가용성 증대
  • DBMS, 트랜잭션 관리자 또는 기타 주요 서브시스템 지원

예제

현금 자동 인출기(ATM)에서는 세 개의 서로 다른 소스(시스템 사용자, ATM 장치(예: 현급 지급기에서 지폐가 걸릴 경우) 또는 ATM 네트워크(네트워크로부터 시스템 종료 지시가 있는 경우))로부터 수신되는 비동기 이벤트를 처리해야 합니다. 이런 비동기 이벤트를 처리하기 위해 UML의 활성 클래스를 사용하여 아래 표시된 바와 같이 ATM 자체 내에 세 개의 별도의 실행 스레드를 정의할 수 있습니다.

ATM 프로세스 및 스레드 그림

ATM 내의 프로세스 및 스레드

프로세스 라이프사이클 식별
목적  프로세스와 스레드 작성 및 소멸 시기 식별. 

각 프로세스 또는 제어 스레드가 작성 및 소멸되어야 합니다. 단일 프로세스 아키텍처에서는 응용프로그램이 시작될 때 프로세스 작성이 발생하고 응용프로그램이 종료될 때 프로세스 소멸이 발생합니다. 다중 프로세스 아키텍처에서는 응용프로그램이 시작될 때 운영 체제에 의해 작성된 초기 프로세스에서 새로운 프로세스(또는 스레드)가 일반적으로 스폰(spawn) 또는 분기 실행(fork)됩니다. 이런 프로세스는 또한 명시적으로 소멸되어야 합니다.

작성 및 삭제 메커니즘은 물론 프로세스 작성 및 소멸을 유도하는 이벤트 시퀀스를 결정하고 문서화해야 합니다.

예제

ATM에서는 전체 시스템의 동작 조정을 책임지는 하나의 기본 프로세스가 시작됩니다. 프로세스는 다수의 하위 제어 스레드를 스폰(spawn)하여 시스템의 여러 파트(시스템의 장치, 고객으로부터의 이벤트 및 ATM 네트워크로부터의 이벤트)를 모니터합니다. 이런 프로세스 및 스레드 작성을 UML의 활성 클래스를 사용하여 표시할 수 있으며, 이런 활성 클래스의 인스턴스 작성을 아래 표시된 바와 같이 시퀀스 다이어그램으로 표시할 수 있습니다.

시스템 시작 프로세스 및 스레드 작성 그림

시스템 초기화 중에 프로세스 및 스레드 작성

프로세스 간 통신 메커니즘 식별
목적  프로세스 및 스레드 통신 방법 식별. 

프로세스 간 통신(IPC) 메커니즘을 통해 독립된 프로세스로 실행되는 오브젝트 간에 메시지를 송신할 수 있습니다.

일반적인 프로세스 간 통신 메커니즘은 다음을 포함합니다.

  • 공유 메모리, 세마포어를 사용하거나 사용하지 않고 동기화 보장.
  • 랑데부, 특히 Ada와 같은 언어가 직접적으로 지원하는 경우
  • 세마포어, 공유 자원에 대한 동시 액세스를 차단하는 데 사용됨
  • 메시지 전달, 지점간 및 지점 대 다중 지점간
  • 편지함
  • RPC - 원격 프로시저 호출
  • 이벤트 브로드캐스트 - "소프트웨어 버스"("메시지 버스 아키텍처") 사용

IPC 메커니즘 선택은 시스템 모델링 방식을 변경합니다. 예를 들어, "메시지 버스 아키텍처"에서는 메시지 송신을 위해 오브젝트 간에 명시적 연관이 필요하지 않습니다.

프로세스 간 조정 자원 할당
목적 희소 자원 할당
잠재적 성능 병목 현상 예상 및 관리 

프로세스 간 통신 메커니즘은 일반적으로 부족합니다. 세마포어, 공유 메모리 및 편지함은 일반적으로 크기나 수가 정해져 있으며 상당한 비용을 치르지 않고는 늘릴 수 없습니다. RPC, 메시지 및 이벤트 브로드캐스트는 부족한 네트워크 대역폭을 많이 사용합니다. 시스템이 자원 임계값을 초과하면 일반적으로 비선형 성능 저하가 발생합니다. 일단 희소 자원을 다 써버리면 후속 자원 요청은 좋지 않은 영향을 미치기 쉽습니다.

희소 자원을 사용할 수 없는 경우, 고려할 몇 가지 전략이 있습니다.

  • 프로세스 수를 줄여 희소 자원 요구 축소
  • 희소 자원 사용법 변경(하나 이상의 프로세스의 경우, IPC 메커니즘에 사용할 덜 부족한 다른 자원을 선택)
  • 희소 자원 양 늘리기(예: 세마포어 수 늘리기). 비교적 적은 변경으로 이를 수행할 수 있지만 종종 부작용이나 고정 한계가 있습니다.
  • 희소 자원 공유(예: 자원이 필요할 때만 할당한 후 완료하면 해제). 이는 비용이 많이 들고 자원 위기만 발생시킬 수 있습니다.

어떤 전략을 선택하건 관계없이 시스템 성능은 갑자기 저하되지 말고 점진적으로 저하되어야 하며, 일단 시스템이 배치되면 현장에서 문제점을 해결할 수 있도록(가능하면) 시스템 관리자에게 적절한 피드백을 제공해야 합니다.

시스템이 핵심 자원의 가용성을 증가시키기 위해 특별한 런타임 환경 구성을 필요로 하는 경우(종종 운영 체제 커널을 재구성하여 제어), 시스템 설치 프로그램은 이를 자동으로 수행하거나 시스템 관리자에게 시스템을 작동하기 전에 이를 수행하도록 해야 합니다. 예를 들어, 변경사항을 적용하기 전에 시스템을 재부트해야 할 수도 있습니다.

구현 환경에 프로세스 맵핑
목적  "제어 플로우"를 구현 환경이 지원하는 개념에 맵핑. 

개념적 프로세스를 운영 환경의 특정 구조에 맵핑해야 합니다. 많은 환경에서 프로세스 유형 선택사항(적어도 프로세스 및 스레드)이 있습니다. 선택사항은 결합 정도(프로세스는 독립형인 반면 스레드는 엔클로징 프로세스의 컨텍스트에서 실행됨) 및 시스템의 성능 요구사항(스레드 사이의 프로세스 간 통신은 일반적으로 프로세스 사이의 통신보다 빠르고 효율적임)을 기반으로 합니다.

많은 시스템에서 프로세스당 최대 스레드 수 또는 노드당 최대 프로세스 수가 있을 수 있습니다. 이런 한계는 절대적이지는 않지만 희소 자원의 가용성으로 인한 실제 한계일 수 있습니다. 대상 노드에서 이미 실행되고 있는 스레드 및 프로세스를 프로세스 아키텍처에 제안된 스레드 및 프로세스와 함께 고려해야 합니다. 새로운 성능 문제점이 생기지 않도록 맵핑을 수행할 때 이전 단계(프로세스 간 조정 자원 할당)의 결과를 고려해야 합니다.

제어 스레드에 디자인 요소 맵핑
목적  클래스 및 서브시스템을 실행해야 하는 제어 스레드 판별. 

클래스 또는 서브시스템에 실행 환경을 제공하는 하나 이상의 제어 스레드 내에서 주어진 클래스 또는 서브시스템의 인스턴스를 실행해야 합니다. 실제로 여러 개의 서로 다른 프로세스에서 실행할 수 있습니다.

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

안에서 밖으로(Inside-out)

  1. 디자인 모델에서 시작하여 (a) 서로 긴밀하게 협력하고 (b) 동일한 제어 스레드에서 실행해야 하는 협력 요소 세트로 클래스 및 서브시스템을 함께 그룹화하십시오. 요소를 독립된 제어 스레드로 분리하기 전에 프로세스 간 통신을 메시지 시퀀스 중간에 도입할 경우의 영향을 고려하십시오.
  2. 반대로, 전혀 상호작용하지 않는 클래스 및 서브시스템을 분리하여 독립된 제어 스레드에 위치시키십시오.
  3. 이 클러스터링은 프로세스 수가 실제 자원의 분배 및 사용을 여전히 허용하는 가장 작은 수로 줄어들 때까지 계속됩니다.

밖에서 안으로(Outside-in)

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

이는 최적의 프로세스 보기를 유도하는 결정적 선형 프로세스가 아닙니다. 허용 가능한 타협점에 도달하려면 약간의 반복이 필요합니다.

예제

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

프로세스 및 스레드에 ATM 클래스 분배 그림

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



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