활동:
|
목적
|
|
역할: 소프트웨어 아키텍트 | |
빈도: 특히 구현화 단계 중에 반복당 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: |
워크플로우 세부사항: |
활성 객체(활성 클래스의 인스턴스)는 시스템에서 동시 실행 스레드를 표시하는데 사용합니다. 개념적으로, 각 활성 객체에는 고유 제어 스레드가 있으며 관례적으로 실행 스택 프레임의 루트입니다. 활성 객체를 실제 운영 체제 스레드나 프로세스에 맵핑하는 것은 응답 요구사항에 따라 달라질 수 있으며 오버헤드를 전환하는 컨텍스트의 고려사항에 영향을 받을 수 있습니다. 예를 들어, 단순 스케줄러와 공동으로 여러 활성 객체가 단일 운영 체제 스레드와 공유하여 동시에 실행 중인 것처럼 표시되는 것이 가능합니다. 그러나 예를 들어 임의의 활성 객체가 동기적 입/출력(I/O)을 수행하여 차단된 작동을 표시하는 경우, 해당 그룹의 기타 활성 객체는 운영 체제 스레드가 차단된 동안 발생한 이벤트에 응답할 수 없습니다.
반면, 각 활성 객체에 고유 운영 체제 스레드를 부여하는 것은 처리 자원이 추가 컨텍스트 전환 오버헤드에 불리한 영향을 받지 않는다는 가정 하에 보다 월등한 응답성을 초래합니다.
이 활동이 활성 클래스와 해당 인스턴스 및 이들의 운영 체제 스레드와 프로세스에 대한 관계 면에서 시스템의 프로세스 구조를 정의합니다.
구현화 단계의 초기에 이 구조는 매우 예비적이지만 구현화 말기에는 프로세스와 스레드가 제대로 정의되어야 합니다.
이 활동의 결과는 설계 모델(특히, 프로세스 보기)에 캡처됩니다(개념: 프로세스 보기 참조).
목적 | 타스크의 병렬 실행이 시스템에 필수인 정도를 정의하기 위함입니다. 이 정의가 구조 형성에 도움이 됩니다. |
활동: 설계 요소 식별 중에 자연스럽게 발생하는 문제점 도메인의 동시성에 대한 요구에 의해 주도되는 동시성 요구사항이 고려됩니다.
이 결과는 시스템에서 제어의 논리 스레드를 표시하는 활성 클래스 세트입니다.
이 단계에서 기타 동시성 요구사항의 소스(시스템의 비기능적 요구사항에 의해 부과된 사항)를 고려합니다.
동시성 요구사항은 다음에 의해 구동됩니다.
여러 구조적 문제점과 함께 이러한 요구사항은 다소 상호 독점적일 수 있습니다. 적어도 처음에는 충돌하는 요구사항이 있는 것이 일반적입니다. 중요성 관점에서 요구사항의 등급을 매기는 것이 충돌을 해결하는데 도움이 됩니다.
목적 | 시스템에 있는 프로세스 및 스레드를 정의하기 위함입니다. |
가장 단순한 접근법은 모든 활성 객체를 공용 스레드 또는 프로세스에 할당하고 단순 활성 객체 스케줄러가 컨텍스트 전환 오버헤드를 최소화하므로 해당 스케줄러를 사용하는 것입니다. 그러나 일부 경우에 하나 이상의 스레드 또는 프로세스에 활성 객체를 분배하는 것이 필요할 수도 있습니다.
기타 활성 객체와 운영 체제 스레드를 공유하는 활성 객체는 일부 기타 프로세스 또는 스레드에 동기적 호출을 합니다. 이 호출이 불러온 객체의 공유 운영 체제 스레드를 차단한 다음 호출 프로세스에 있는 기타 모든 활성 객체를 자동으로 일시중단합니다. 이제, 이 경우는 제거될 수 있습니다. 활성 객체의 관점에서 동기적인 호출이 활성 객체 그룹을 제어하는 단순 스케줄러의 관점에서 비동기적으로 처리될 수도 있습니다. 스케줄러가 호출하는 활성 객체를 일시 중단한 다음(동기적 호출의 완료를 기다림) 기타 활성 객체가 실행되도록 스케줄합니다.
본래의 '동기적' 작업이 완료되면 호출된 활성 객체가 재개될 수 있습니다. 그러나 이 접근법은 언제나 가능하지는 않을 수 있습니다. 왜냐하면, 스케줄러가 모든 동기적 호출을 차단하기 전에 가로채도록 설계될 가능성이 없을 수도 있기 때문입니다. 일반적으로, 동일한 운영 체제 프로세스 또는 스레드를 사용하여 활성 객체 간 동기적 호출이 이러한 방식으로 스케줄러에 의해 처리될 수 있으며, 사실상 동기적 호출이 활성 객체 호출 관점에서 프로시저 호출과 동등함을 참고하십시오.
이로써, 활성 객체가 스레드를 차단하는 동기적 호출과 함께 동시적으로 실행되어야 하는 필요에 따라 프로세스 또는 스레드로 그룹화되어야 한다는 결론에 이르게 됩니다. 즉, 활성 객체가 스레드를 차단하는 동기적 호출을 사용하는 다른 객체와 함께 스레드 또는 동일한 프로세스에서 패키지되어야 하는 유일한 경우는 해당 객체와 동시적으로 실행될 필요가 없고 기타 객체가 차단된 동안에 실행되지 못하는 상황을 견딜 수 있는 경우입니다. 극단적인 경우로 응답성이 중요한 때, 각 활성 객체에 별도의 스레드 또는 프로세스가 필요하게 될 수 있습니다.
일반적인 규칙으로서, 위의 상황에서는 경량의 스레드가 오버헤드에 덜 관련되므로 완전히 발달된 프로세스 대신에 사용하는 것이 좋습니다. 그러나 여전히 일정 특수 경우에 프로세스의 일부 특성을 이용하고자 할 수도 있습니다. 스레드가 동일한 주소 공간을 공유하므로 프로세스보다 더 위험합니다. 우발적인 겹쳐쓰기 가능성에 관해서는 프로세스가 선호됩니다. 더우기, 프로세스가 대부분의 운영 체제에서 독립적 복구 장치를 표시하므로 서로 독립적으로 복구되어야 하는 필요를 기반으로 프로세스에 활성 객체를 할당하는 것이 유용할 수도 있습니다. 즉, 장치로서 복구되어야 하는 모든 활성 객체는 동일한 프로세스에서 함께 패키지되어야 할 수도 있습니다.
시스템에 필요한 별도의 각 제어 플로우에 대해 프로세스나 스레드(경량 프로세스)를 작성하십시오. 스레드는 제어의 중첩 플로우가 필요한 경우 사용되어야 합니다(프로세스 내에서 서브타스크 레벨의 독립적 제어 플로우가 필요한 경우).
예를 들어, 별도의 제어 스레드가 다음을 필요로 할 수도 있습니다(반드시 중요성 때문은 아님).
예
자동 예금 인출기에서는 다음 세 가지 다른 소스에서 시작되는 비동기 이벤트가 처리되어야 합니다. 시스템의 사용자, ATM 장치(예: 현금 자동 지급기에 정지가 생긴 경우) 또는 ATM 네트워크(네트워크에서 직접 시스템 종료하는 경우). 이러한 비동기 이벤트를 처리하도록 UML의 활성 클래스를 사용하여 아래 표시된 대로 ATM 자체에 세 가지 별도 실행 스레드를 정의할 수 있습니다.
ATM의 프로세스 및 스레드
목적 | 프로세스 및 스레드가 작성되고 파기되는 시기를 식별하기 위함입니다. |
각 제어 스레드 및 프로세스가 작성되고 파기되어야 합니다. 단일 프로세스 구조에서 어플리케이션 시작시 프로세스가 작성되고 어플리케이션 종료시 프로세스 파기가 발생합니다. 다중 프로세스 구조에서 새 프로세스(또는 스레드)가 일반적으로 어플릴케이션 시작시 운영 체제가 작성한 초기 프로세스에서 생기거나 분기됩니다, 이러한 프로세스는 또한 명시적으로 파기되어야 합니다.
프로세스 작성 및 파기까지 초래하는 이벤트의 시퀀스가 작성 및 삭제 메커니즘과 함께 판별되고 문서화되어야 합니다.
예
자동 현금 인출기에서 전체 시스템의 작동을 조정할 책임이 있는 한 기본 프로세스가 시작합니다. 차례로 제어의 여러 종속 스레드를 산출하여 다음과 같은 시스템의 여러 파트를 모니터합니다. 시스템 장치, 고객 또는 ATM 네트워크에서 나오는 이벤트. 이러한 프로세스 및 스레드 작성은 UML의 활성 클래스로 표시될 수 있으며, 이러한 활성 클래스의 인스턴스 작성은 아래에 표시된 대로 순서 다이어그램으로 표시될 수 있습니다.
시스템 시작 중 프로세스 및 스레드 작성
목적 | ㅎ프로세스 및 스레드가 의사소통할 수단을 식별하기 위함입니다. |
IPC(Inter-Process Communication) 메커니즘이 별도의 프로세스에서 실행 중인 객체 간 메시지를 전송 가능하게 합니다.
일반적인 프로세스 간 의사소통 메커니즘에는 다음이 포함됩니다.
IPC 메커니즘의 선택이 시스템이 모델화되는 방식을 변경합니다. 예를 들어, "메시지 버스 구조"에서는 메시지를 전송하는데 객체 간 명시적 연관이 필요하지 않습니다.
목적 | 드문 자원을 할당하기 위함입니다. 잠재적 성능 병목 현상을 예상하고 관리하기 위함입니다. |
프로세스 간 의사소통 메커니즘은 일반적으로 드문 경우입니다. 세마포어, 공유 메모리 및 편지함은 일반적으로 크기와 수가 고정되어 있므며 상당한 비용을 들이지 않고는 증가될 수 없습니다. RPC, 메시지 및 이벤트 브로드캐스트가 점점 더 드문 네트워크 대역폭을 흡수합니다. 시스템이 소스 임계값을 초과하면 일반적으로 비선형 성능 저하를 경험하게 됩니다. 드문 자원이 모두 사용되면 해당 자원에 대한 후속 요청이 불쾌한 효과를 일으킬 가능성이 큽니다.
드문 자원이 초과 등록되면 다음과 같이 고려할 여러 전략이 있습니다.
선택한 전략에 상관없이 시스템은 안정되고 조용하게(고장을 내는 대신) 강등되어야 하며 시스템 관리자에게 적절한 피드백을 제공하여 시스템이 전개된 적이 있는 필드에서 문제점을 해결하도록(가능한 경우) 해야 합니다.
시스템이 주요한 자원의 사용 가능성을 증가시키기 위해 런타임 환경의 특수한 구성을 필수로 하는 경우(종종 운영 체제 커널의 재구성으로 제어됨), 시스템 설치가 이를 자동으로 수행하거나 시스템 관리자에게 이를 수행하도록 지시하여 시스템이 조작될 수 있도록 해야 합니다. 예를 들어, 시스템은 변경이 효력을 내기 전에 다시 재부팅해야 할 수도 있습니다.
목적 | 구현 환경이 제공하는 개념에 "제어 플로우"를 맵핑하기 위함입니다. |
개념적 프로세스는 운영 환경의 특정 구조에 맵핑되어야 합니다. 여러 환경에서 프로세스 유형의 선택사항이 있습니다(최소한 일반적으로 프로세스와 스레드). 선택사항은 결합 정도(프로세스는 독립형임. 반면에 스레드는 포함된 프로세스의 컨텍스트에서 실행됨)와 시스템의 성능 요구사항(스레드 사이의 프로세스 간 의사소통은 일반적으로 프로세스 사이 해당 의사소통보다 빠르고 효율적임)을 기반으로 합니다.
여러 시스템에서 프로세스당 최대 수의 스레드 또는 노드당 프로세스가 있을 수 있습니다. 이러한 한계는 절대적이 아닐 수 있으나 드문 자원의 사용 가능성에 의해 부여된 실제적인 제한일 수 있습니다. 대상 노드에서 이미 실행 중인 스레드와 프로세스는 프로세스 구조에 제안된 스레드 및 프로세스와 함께 고려되어야 합니다. 이전 단계, 프로세스 간 조정 자원 할당의 결과가 맵핑이 작성되면 새 성능 문제점이 작성 중이지 않은지 확인하기 위해 고려되어야 합니다.
목적 | 실행될 서브시스템 및 제어 클래스의 스레드를 판별하기 위함입니다. |
해당 클래스와 서브시스템의 인스턴스는 클래스 또는 서브시스템의 실행 환경을 제공하는 적어도 한 스레드에서 실행되어야 합니다. 해당 인스턴스는 사실 여러 다른 프로세스에서 실행할 수도 있습니다.
두 다른 전략을 동시에 사용하여 다음과 같이 "올바른" 양의 동시성을 판별하고 "올바른" 프로세스 세트를 정의합니다.
이는 최적 프로세스 보기를 초래하는 선형의 결정적 프로세스가 아닙니다. 승인 가능한 절충안에 도달하도록 몇 개의 반복이 필요합니다.
예
다음 다이어그램은 ATM 내 클래스가 시스템의 프로세스 및 스레드 사이에서 분배되는 방법을 설명합니다.
ATM의 프로세스에 클래스 맵핑
Rational Unified Process
|