Atividade:
|
Finalidade
|
|
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)
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:
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.
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:
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.
Processos e Threads no Sistema de Caixa Eletrônico
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:
Criação de processos e threads durante a inicialização do sistema
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:
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.
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:
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.
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.
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:
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.
Mapeamento de classes em processos para o caixa eletrônico
Rational Unified Process
|