Conceitos: Mecanismos de Análise
Tópicos
Os mecanismos de análise representam um padrão que constituem uma solução comum para um problema comum. Eles podem mostrar padrões de estrutura, padrões de comportamento ou ambos e são usados durante a análise para reduzir a complexidade da análise e melhorar sua consistência, fornecendo aos designers uma representação abreviada de um comportamento complexo. Os mecanismos permitem que o esforço de análise enfatize a conversão dos requisitos funcionais em conceitos de software, sem se aprofundar na especificação do comportamento relativamente complexo, que é necessário para suportar a funcionalidade, mas não é fundamental para o mesmo. Os mecanismos de análise freqüentemente resultam da instanciação de um ou mais padrões de análise ou de arquitetura.
Os mecanismos de análise são usados basicamente para representar 'espaços reservados' de tecnologia complexa nas camadas intermediária e inferior da arquitetura. Usando os mecanismos como 'espaços reservados' na arquitetura, será bem menos provável que o esforço de arquitetura seja perturbado pelos detalhes do comportamento do mecanismo. Como exemplo disso, a necessidade de ter casos de uso de vida útil de objeto, vida útil de processos ou momentos de encerramento e inicialização do sistema define a necessidade da persistência do objeto. A persistência é um mecanismo particularmente complexo e, durante a análise, não queremos ser perturbados por detalhes que nos informem como estamos nos saindo na conquista da persistência. Isso traz à tona um mecanismo de análise de 'persistência' que nos permite falar de objetos persistentes e capturar os requisitos que precisaremos cumprir no mecanismo de persistência, sem nos preocuparmos exatamente com o que esse mecanismo fará ou em como ele funcionará.
Os mecanismos de análise são geralmente, mas não necessariamente, dissociados do domínio do problema. No entanto, eles são conceitos da "ciência de computação" e, portanto, ocupam com freqüência as camadas intermediária e inferior da arquitetura. Eles fornecem comportamentos específicos a uma classe ou a um componente relacionado a domínio ou correspondem à implementação da cooperação entre classes e/ou componentes. Eles podem ser implementados como um framework. Para citar apenas alguns exemplos: os mecanismos que manipulam a persistência, a comunicação entre processos, o tratamento de erros ou falhas, a notificação e a transmissão de mensagens.
Entretanto, à medida que mais padrões de análise forem estabelecidos nos vários domínios, a instanciação parcial ou completa deles nos mecanismos de análise farão com que esses mecanismos apareçam nas camadas superiores da arquitetura.
- Persistência
Em todas as classes cujas instâncias podem se tornar persistentes, é preciso identificar os seguintes aspectos:
- Granularidade: intervalo de tamanho dos objetos para que a persistência seja mantida.
- Volume: número de objetos necessários para que a persistência seja mantida.
- Duração: o tempo durante o qual o objeto geralmente precisa ser mantido.
- Mecanismo de recuperação: como um determinado objeto é exclusivamente identificado e recuperado?
- Freqüência de atualização: os objetos são mais ou menos constantes? Eles são permanentemente atualizados?
- Confiabilidade: os objetos sobreviverão a uma pane no processo, no processador ou no sistema inteiro?
- Comunicação entre processos
Em todos os elementos de modelo que precisam se comunicar com objetos, componentes ou serviços que estão sendo executados em outros processos ou threads, precisamos identificar os seguintes aspectos:
- Latência: com que rapidez os processos devem se comunicar uns com os outros?
- Sincronismo: comunicação assíncrona
- Tamanho da mensagem: um espectro pode ser mais apropriado que um único número.
- Protocolo, controle de fluxo, armazenamento em buffer, e assim por diante.
Outros mecanismos comuns incluem:
- Roteamento de mensagens
- Controle e sincronização de processos
- Gerenciamento de transações
- Troca de informações
- Segurança
- Redundância
- Relatório de erros
- Conversão de formato
Este é o processo de descrição dos mecanismos de análise:
- Reunir todos os mecanismos de análise em uma lista
O mesmo mecanismo de análise pode aparecer com vários nomes diferentes em diversos casos de uso ou designers. Por exemplo, os termos armazenamento, persistência, banco de dados e repositório podem se referir a um único mecanismo de persistência. Os termos comunicação entre processos, transmissão de mensagens ou chamada remota podem se referir a um único mecanismo de comunicação entre processos.
- Desenhar um mapa das classes de cliente para os mecanismos de análise
As classes e os subsistemas componentes identificados precisam ser mapeados para os mecanismos de análise identificados: as setas indicam que a classe utiliza o mecanismo. É comum uma classe cliente exigir os serviços de vários mecanismos.
- Identificar Características dos Mecanismos de Análise
Para fazer a distinção em um intervalo de designs possíveis, identifique as características-chave utilizadas para qualificar cada mecanismo de análise. Essas características são, por um lado, consideradas funcionalidades e, de outro lado, consideradas tamanho e desempenho.
-
Modelar Usando Colaborações
Após ter identificado e nomeado os mecanismos de análise, eles devem, finalmente, ser modelados por meio da colaboração de uma 'sociedade de classes' (consulte [BOO98]). Algumas delas não oferecem diretamente funcionalidade de aplicativo, mas existem somente para suportá-la. Muito freqüentemente, essas 'classes de suporte' ficam nas camadas intermediária ou inferior de uma arquitetura em camadas, fornecendo, assim, a todas as classes de nível de aplicativo um serviço de suporte comum.
Se o mecanismo identificado for comum o suficiente, talvez os padrões estejam em um local em que o mecanismo possa ser instanciado, vinculando as classes existentes e implementando as novas conforme exigido pelo padrão. Um mecanismo de análise produzido dessa forma será abstrato e exigirá posteriormente um refinamento por meio do design e da implementação.
Os mecanismos de análise são documentados em Artefato: Documento de Arquitetura de Software. Quando a arquitetura de software expirar, a disciplina Artefato: Documento de Arquitetura de Software incluirá um relacionamento (ou mapeamento) entre os mecanismos de análise, de design e de implementação, e incluirá também os fundamentos associados dessas alternativas.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| |
|
