Finalidade
  • Analisar os requisitos de simultaneidade, identificar processos, identificar os mecanismos de comunicação entre os processos, alocar recursos de coordenação entre os processos, identificar os ciclos de vida dos processos e distribuir elementos de modelo entre os processos.
Função:  Arquiteto de Software  
Freqüência: Uma vez por iteração, especialmente durante a fase de elaboração.
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   
More Information: 

Detalhes de Workflow:   

Objetos ativos (ou seja, instâncias de classes ativas) são utilizados para representar encadeamentos simultâneos de execução no sistema: imaginariamente, cada objeto ativo possui seu próprio encadeamento de controle e, por convenção, é a raiz de um quadro de pilha de execução. O mapeamento de objetos ativos para threads ou processos reais do sistema operacional pode variar de acordo com os requisitos de resposta e será influenciado considerando a carga de alternância de contexto. Por exemplo, diversos objetos ativos, combinados por um simples programador, podem compartilhar um único thread do sistema operacional, o que dará a impressão de estarem em execução simultânea. Entretanto, se algum objeto ativo exibir comportamento de bloqueio, por exemplo, ao executar operações síncronas de entrada e saída, outros objetos ativos do grupo não serão capazes de responder aos eventos ocorridos enquanto o encadeamento do sistema operacional estiver bloqueado.

Por outro lado, se cada objeto ativo tiver seu próprio thread do sistema operacional, a resposta será maior, desde que os recursos de processamento não sofram um impacto negativo causado pela carga decorrente da alternância de contexto.

Essa atividade define uma arquitetura de processo para o sistema em termos de classes ativas e suas instâncias, e do relacionamento delas com os threads e processos do sistema operacional.  

No início da fase de Elaboração, essa arquitetura é bastante preliminar. Mais adiante, os processos e threads já devem estar bem definidos.

Os resultados dessa atividade são capturados no modelo de design - em particular, na visualização do processos (consulte Conceitos: Visualização do Processos)

Analisar Requisitos de Simultaneidade Para o início da página

Finalidade  Definir a extensão da execução paralela de tarefas necessária ao sistema. Essa definição ajudará a modelar a arquitetura.  

Durante a Atividade: Identificar Elementos de Design, os requisitos de simultaneidade orientados principalmente por demandas corriqueiras de simultaneidade no domínio de problemas foram considerados. 

O resultado é a obtenção de um conjunto de classes ativas que representam encadeamentos lógicos de controle no sistema.  

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 do cálculo de 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 chegada dos eventos no sistema. Em sistemas com dispositivos ou sensores externos, os padrões de chegada 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 threads 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).

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.

Identificar Processos e Encadeamentos Para o início da página

Finalidade  Definir os processos e threads que existirão no sistema.  

A abordagem mais simples é alocar todos os objetos ativos em um thread ou processo comum e usar um programador simples de objetos ativos. Esse procedimento minimizará a carga decorrente da alternância de contexto. Entretanto, em alguns casos, pode ser necessário distribuir os objetos ativos em um ou mais threads ou processos.

Se um objeto ativo, que esteja compartilhando um thread do sistema operacional com outros objetos ativos, fizer uma chamada síncrona para outro processo ou thread, e essa chamada bloquear o thread 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 thread 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 threads 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 thread 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 thread ou processo separado para cada objeto ativo.

Como regra geral, nas situações citadas acima é melhor usar threads 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 threads 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 thread (processo leve). Um thread 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, podemos afirmar (não necessariamente por ordem de importância) que são necessários threads de controle para:

  • Separar os interesses 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 thread 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 threads de execução separados no próprio sistema de caixa eletrônico, como mostrado abaixo, com o uso de classes ativas em UML.

Ilustração dos processos do caixa eletrônico e encadeamentos

Processos e Threads no Sistema de Caixa Eletrônico

Identificar Ciclos de Vida de Processos Para o início da página

Finalidade  Identificar quando os processos e threads são criados e destruídos.  

Cada processo ou thread 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:

Ilustração do Processo de Inicialização do Sistema e Criação de Encadeamento

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

Identificar Mecanismos de Comunicação entre Processos Para o início da página

Finalidade  Identificar o meio pelo qual processos e threads se comunicarão.  

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 mensagens, ponto-a-ponto e ponto-a-multiponto
  • Caixas postais
  • RPC - Chamadas de procedimento remoto
  • Difusão de Eventos - utilizando um "barramento de software" ("arquitetura de barramento de mensagem")

A escolha do mecanismo IPC mudará 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.

Alocar Recursos de Coordenação entre Processos Para o início da página

Finalidade Alocar recursos escassos
Prever e gerenciar possíveis gargalos de desempenho 

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 houver excesso de solicitação pelos recursos escassos, será importante considerar várias estratégias:

  • 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.

Mapear Processos no Ambiente de Implementação Para o início da página

Finalidade  Mapear os "fluxos de controle" nos conceitos suportados pelo ambiente de implementação.  

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 threads 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 threads é 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 threads 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 threads e processos que já estiverem em execução em um nó-alvo precisarão ser considerados com os threads e processos propostos na arquitetura de processos. Os resultados da etapa anterior, Alocar Recursos de Coordenação entre Processos, precisam ser considerados quando for feito o mapeamento para verificar se um novo problema de desempenho não está sendo criado.

Mapear Elementos de Design para Encadeamentos de Controle Para o início da página

Finalidade  Determinar quais classes e subsistemas de encadeamentos de controle devem ser executados.  

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 thread 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 threads de controle distintos.
  2. Por outro lado, coloque as classes e os subsistemas que não interagem em threads 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 thread de controle separado para tratar de cada estímulo e um thread 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 threads 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 ajuste aceitável.

Exemplo

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

Ilustração da Distribuição de Classe de Caixa Eletrônico em Processos e Encadeamentos

Mapeamento de classes em processos para o caixa eletrônico



Rational Unified Process   2003.06.15