O resultado é a obtenção de um conjunto de classes ativas que representam encadeamentos lógicos de controle no sistema.   Em sistemas de tempo real, essas classes ativas são representadas pelo Produto de Trabalho: Cápsula.

Nesse passo, devemos considerar outras fontes de requisitos de simultaneidade - aquelas impostas pelos requisitos não-funcionais do sistema.

Os requisitos de simultaneidade são orientados por:

• O grau em que o sistema deve ser distribuído. Um sistema cujo comportamento deve ser distribuído entre processadores ou nós requer, virtualmente, uma arquitetura multiprocessos. Um sistema que utilize algum tipo de Sistema de Gerenciamento de Banco de Dados ou Gerenciador de Transações também deve considerar os processos introduzidos por esses principais subsistemas.
• A intensidade de computação dos algoritmos chave. Para garantir bons tempos de resposta, pode ser necessário colocar as atividades que exigem muitos recursos computacionais em um processo ou encadeamento próprio, de forma que o sistema possa continuar a responder às entradas do usuário enquanto a computação prossegue, embora com menos recursos.
• O grau de execução paralela suportado pelo ambiente. Se o sistema operacional ou o ambiente não suportam encadeamentos (processos leves), não há por que considerar o impacto causado sobre a arquitetura do sistema.
• A necessidade de tolerância a falhas no sistema. Os processadores de backup precisam de processos de backup e procuram manter os processos primários e de backup sincronizados.
• O padrão de recebimento de eventos no sistema. Em sistemas com dispositivos ou sensores externos, os padrões de recebimento dos eventos de entrada podem diferir entre um sensor e outro. Alguns eventos podem ser periódicos (podem ocorrer em intervalos fixos, com pouca diferença) ou não periódicos (em intervalos irregulares). As classes ativas que representam os dispositivos que geram diversos padrões de eventos geralmente são atribuídas a vários encadeamentos do sistema operacional, com algoritmos de programação distintos, a fim de garantir que os eventos ou que os prazos de processamento não sejam negligenciados (se esse for um requisito do sistema). Esse raciocínio se aplica também às cápsulas, quando elas forem utilizadas no design de sistemas de tempo real.

Como ocorre com muitos problemas relativos à arquitetura, esses requisitos podem, de alguma forma, ser mutuamente exclusivos. Pelo menos inicialmente, não é comum ocorrerem conflitos entre requisitos. A ordenação dos requisitos em termos de importância ajudará a solucionar o conflito.

Se um objeto ativo, que esteja compartilhando um encadeamento do sistema operacional com outros objetos ativos, fizer uma chamada síncrona para outro processo ou thread, e essa chamada bloquear o encadeamento do sistema operacional do objeto que fez a chamada, todos os outros objetos ativos localizados no processo de disparo serão suspensos automaticamente. Nesse momento, esse não precisa ser o caso: uma chamada síncrona, do ponto de vista do objeto ativo, pode ser tratada assincronamente pela perspectiva do planejador que controla o grupo de objetos ativos - o planejador suspende o objeto ativo que está fazendo a chamada (à espera da conclusão de sua chamada síncrona) e, em seguida, planeja a execução de outros objetos ativos. 

Quando a operação 'síncrona' original estiver concluída, o objeto ativo do disparo prosseguirá. Contudo, essa abordagem nem sempre é possível, pois pode não ser viável projetar o programador para interceptar todas as chamadas síncronas antes de serem bloqueadas. Observe que uma invocação síncrona entre objetos ativos que utilizem o mesmo processo ou encadeamento do sistema operacional pode, por questões genéricas, ser tratada pelo programador dessa maneira - e seu efeito sobre uma chamada de procedimento pode ser idêntico, do ponto de vista do objeto ativo que fez o disparo.

Sendo assim, podemos concluir que os objetos ativos devem ser agrupados em processos ou encadeamentos de acordo com a necessidade de serem executados simultaneamente com invocações síncronas que bloqueiam o thread. Em outras palavras, só há um momento em que um objeto ativo deve ser empacotado no mesmo processo ou encadeamento com um outro objeto que utilize chamadas síncronas que bloqueiam o thread. É quando ele não precisa ser executado com esse objeto e aceita não ser executado enquanto o outro objeto está bloqueado. Em casos extremos, quando a resposta é um fator crítico, essa situação pode exigir um encadeamento ou processo separado para cada objeto ativo.

Para os sistemas de tempo real, as interfaces de cápsulas baseadas em mensagens pretendem que é mais simples conceber um programador que garanta, pelo menos nas comunicações entre cápsulas, que os encadeamentos do sistema operacional de suporte nunca sejam bloqueados, mesmo quando uma cápsula se comunica sincronamente com outra. Porém, ainda assim, é possível que uma cápsula envie uma solicitação diretamente para o sistema operacional, como, por exemplo, para uma espera síncrona que pode bloquear o thread. É preciso estabelecer convenções para os serviços de nível inferior disparados pelas cápsulas que evitam esse comportamento, caso as cápsulas compartilhem um mesmo encadeamento (e usem um programador simples para simular simultaneidade).

Como regra geral, nas situações citadas acima é melhor usar encadeamentos leves do que processos completos, já que a carga é menor. Entretanto, ainda podemos aproveitar algumas características especiais dos processos em certos casos especiais. Como os encadeamentos compartilham o mesmo espaço de endereço, eles são naturalmente mais arriscados do que os processos. Se houver a preocupação com substituições acidentais, é melhor usar processos. Além disso, já que os processos representam unidades independentes de recuperação na maioria dos sistemas operacionais, pode ser útil alocar objetos ativos para os processos de acordo com sua necessidade de recuperação, independentemente um do outro. Isso quer dizer que todos os objetos ativos que precisam de recuperação podem ser incluídos no mesmo processo.

Para cada fluxo de controle separado exigido pelo sistema, crie um processo ou encadeamento (processo leve). Um encadeamento deve ser usado nos casos em que há necessidade de um fluxo de controle aninhado (isto é, se, em um processo, for preciso um fluxo de controle independente no nível de subtarefa).

Por exemplo, encadeamentos de controle separados podem ser necessários para ser feito o seguinte:

• Separar os problemas entre diversas áreas do software
• Tirar proveito de diversas CPUs em um nó ou em vários nós de um sistema distribuído
• Aumentar a utilização da CPU alocando ciclos para outras atividades quando um encadeamento de controle estiver suspenso
• Priorizar atividades
• Suportar o compartilhamento de carga entre diversos processos e processadores
• Obter maior disponibilidade do sistema por meio de processos de backup
• Suportar o DBMS, o Gerenciador de Transações ou outros subsistemas importantes.

Exemplo

No caixa eletrônico, eventos assíncronos devem ser tratados como provindos de três origens diferentes: o usuário do sistema, os dispositivos do caixa eletrônico (no caso de uma obstrução no caixa automático, por exemplo) ou a rede do caixa eletrônico (no caso de um encerramento originado na rede). Para tratar desses eventos assíncronos, podemos definir três encadeamentos de execução separados no próprio sistema de caixa eletrônico, como mostrado abaixo, com o uso de classes ativas em UML.

Processos e Encadeamentos no Sistema de Caixa Eletrônico

Cada processo ou encadeamento de controle deve ser criado e destruído. Em uma arquitetura com um único processo, a criação de processos ocorre quando o aplicativo é inicializado. A destruição de processos ocorre quando o aplicativo é encerrado. Em arquiteturas multiprocesso, os processos (ou threads) novos geralmente são desdobrados ou separados do processo inicial criado pelo sistema operacional quando o aplicativo é inicializado. Esses processos também devem ser destruídos explicitamente.

A seqüência de eventos que leva à criação e destruição dos processos deve ser determinada e documentada, como também o mecanismo de criação e exclusão.

Exemplo

No Sistema de Caixa Eletrônico, um processo principal é iniciado, e ele é responsável pela coordenação do comportamento de todo o sistema. Por sua vez, ele gera vários encadeamentos de controle subordinados para monitorar diversas partes do sistema: os dispositivos no sistema e os eventos originados do cliente e da rede do caixa eletrônico. A criação desses processos e encadeamentos pode ser mostrada com classes ativas na UML, e a criação de instâncias dessas classes ativas pode ser mostrada em um diagrama de seqüência como este:

Criação de processos e encadeamentos durante a inicialização do sistema

Os mecanismos de comunicação entre processos (IPC) permitem que sejam enviadas mensagens entre objetos em execução em processos separados.

Os mecanismos comuns de comunicação entre processos incluem:

• Memória compartilhada, com ou sem semáforos para garantir a sincronização.
• Rendezvous, principalmente quando diretamente suportado por uma linguagem como Ada
• Semáforos, utilizados para bloquear o acesso simultâneo a recursos compartilhados
• Transmissão de mensagem, tanto de ponto-a-ponto como de ponto-a-multiponto
• Caixas Postais
• RPC - Chamadas de procedimento remoto
• Difusão de Evento - utilizando um "barramento de software" ("arquitetura de barramento de mensagem")

A escolha do mecanismo IPC alterará a maneira como o sistema é modelado. Em uma "arquitetura de barramento de mensagem", por exemplo, não há necessidade de associações explícitas entre os objetos para o envio de mensagens.

Geralmente, os mecanismos de comunicação entre processos são escassos. Semáforos, memória compartilhada e caixas de correio normalmente têm tamanho fixo e o seu aumento é uma tarefa bastante dispendiosa. RPC, transmissão de mensagens e eventos aumentam larguras de banda de rede cada vez mais escassas. Quando o sistema excede o limite de um recurso, normalmente sofre uma diminuição não linear no desempenho; depois que um recurso escasso é totalmente utilizado, solicitações subseqüentes desse recurso podem provocar um efeito inesperado.

Se recursos escassos não estiverem disponíveis, há várias estratégias a considerar:

• redução da necessidade do recurso escasso diminuindo o número de processos
• mudança da utilização dos recursos escassos (para um ou mais processos). Escolha um outro recurso menos escasso para usar com o mecanismo IPC.
• aumento da qualidade do recurso escasso (por exemplo, aumente o número de semáforos). Isso pode ser feito em mudanças relativamente pequenas, mas com freqüência apresenta efeitos colaterais ou limites fixos.
• compartilhamento do recurso escasso (por exemplo, aloque o recurso somente quando ele for necessário e libere-o depois de utilizá-lo). Esse é um procedimento dispendioso e só evita uma crise.

Independentemente da estratégia escolhida, o desempenho do sistema deverá diminuir gradativamente (em vez de ocorrer uma pane) e oferecer um feedback adequado ao administrador do sistema para permitir a solução do problema (se possível) no campo em que o sistema está implantado.

Se o sistema precisar de configuração especial do ambiente de tempo de execução para aumentar a disponibilidade de um recurso crítico (controle por meio da reconfiguração do kernel do sistema operacional), o programa de instalação terá que fazê-lo automaticamente ou instruir o administrador do sistema para que o faça antes de o sistema entrar em operação. Por exemplo, o sistema talvez precise ser reinicializado para que a mudança seja efetivada.

Os processos conceituais devem ser mapeados para as construções específicas do ambiente operacional. Em muitos ambientes, há várias opções de tipos de processos, geralmente processos e threads. As opções se basearão no grau de acoplamento (os processos são independentes e os encadeamentos são executados no contexto do processo em que estão contidos) e nos requisitos de desempenho do sistema (comunicação entre processos estabelecida entre encadeamentos é geralmente mais rápida e mais eficiente do que a estabelecida somente entre processos).

Em vários sistemas, pode haver um número máximo de encadeamentos por processo ou de processos por nó. Esses limites podem não ser absolutos, mas podem ser limites práticos impostos pela disponibilidade dos recursos escassos. Os encadeamentos e processos que já estiverem em execução em um nó-alvo precisarão ser considerados com os encadeamentos e processos propostos na arquitetura de processos. Os resultados da etapa anterior, Alocar Recursos de Coordenação entre Processos, precisam ser considerados ao mapear para verificar se um novo problema de desempenho não está sendo criado.

As instâncias de determinada classe ou determinado subsistema devem ser executadas em pelo menos um encadeamento de controle que forneça o ambiente de execução para a classe ou o subsistema; de fato, elas podem ser executadas em diversos processos.

Com o uso simultâneo de duas estratégias diferentes, determinamos a quantidade "correta" de simultaneidade e definimos o conjunto "correto" de processos:

De Dentro para Fora

1. A partir do Modelo de Design, agrupe as classes e os subsistemas em conjuntos de elementos de cooperação que (a) cooperem intimamente entre si e que (b) precisem ser executados no mesmo encadeamento de controle. Considere o impacto da introdução da comunicação entre processos no meio de uma seqüência de mensagens, antes de separar os elementos em encadeamentos de controle distintos.
2. Por outro lado, coloque as classes e os subsistemas que não interagem em encadeamentos de controle separados.
3. Essa disposição em clusters prossegue até o número de processos ser reduzido a um mínimo que permita a distribuição e utilização dos recursos físicos.

De Fora para Dentro

1. Identifique os estímulos externos aos quais o sistema deverá responder. Defina um encadeamento de controle separado para tratar de cada estímulo e um encadeamento de controle para o servidor oferecer cada serviço.
2. Considere as restrições de integridade e serialização dos dados para reduzir esse conjunto inicial de encadeamentos de controle a um número que possa ser suportado pelo ambiente de execução.

Esse não é um processo linear, determinista, que conduz a uma visão de processos ideal. Ele requer algumas iterações até ser obtido um comromisso aceitável.

Exemplo

O diagrama abaixo ilustra como as classes do sistema de caixa eletrônico são distribuídas entre os processos e encadeamentos do sistema.

Mapeamento de classes em processos para o caixa eletrônico