Conceitos: Mecanismos de Análise
Tópicos
Introdução a Mecanismos de Análise 
Os mecanismos de análise representam um padrão que constituem uma solução comum para um problema comum.
Os mecanismos de análise mostram padrões de estrutura, padrões de
comportamento ou ambos. Eles são utilizados durante a análise para reduzir a complexidade
da análise e aprimorar 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 arquitetura
ou de análise.
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 para uma classe ou subsistema relacionado ao domínio ou correspondem
à implementação de cooperação entre classes e/ou subsistemas. Eles podem ser
implementados como uma estrutura.
Exemplos incluem os mecanismos para manipular a persistência, a comunicação entre processos,
a manipulação de erros ou falhas, a notificação e o sistema de mensagens.
No entanto, à medida que mais padrões
de análise forem estabelecidos em vários domínios, a instanciação parcial ou
completa deles nos mecanismos de análise levarão esses mecanismos a
aparecerem nas camadas superiores da arquitetura.
- Persistência
Para todas as classes cujas instâncias podem se tornar persistentes, é necessário identificar:
- Granularidade: Intervalo de tamanho dos objetos para manter a persistência
- Volume: Número de objetos para manter a persistência
- Duração: Quanto tempo geralmente o objeto 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 um travamento do processo,
do processador ou do sistema inteiro?
- Comunicação entre Processos
Para todos os elementos de modelo que precisam se comunicar com componentes ou serviços
que estejam sendo executados em outros processos ou encadeamentos, precisamos identificar:
- Latência: Com que rapidez os processos devem se comunicar uns com os outros?
- Sincronização: 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:
- Coletar todos os mecanismos de análise em uma lista
O mesmo mecanismo de análise pode aparecer sob diferentes nomes
em diferentes realizações de caso de uso ou designers. Por exemplo,
armazenamento, persistência, banco de dados
e repositório podem se referir a um mecanismo de persistência.
OU comunicação entre processos, transmissão de mensagens
ou chamada remota podem se referir a um mecanismo de comunicação
entre processos.
- Desenhar um mapa das classes de cliente para os mecanismos de análise

As classes e os subsistemas identificados precisam ser mapeados
nos 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 as Características dos Mecanismos de Análise
Para fazer a distinção em um intervalo de designs possíveis, identifique as principais
características 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 Utilizando 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, ligando 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 no Artefato:
Documento de Arquitetura de Software. Conforme a arquitetura de software se desenvolve, o
Artefato: Documento de Arquitetura de Software
inclui um relacionamento (ou mapeamento) entre os mecanismos de análise, de design
e de implementação e os fundamentos associados a essas escolhas.
Padrões e Transformações 
Segundo plano 
Como um "gabarito de solução para um problema recorrente que é comprovadamente útil
em um determinado contexto" (extraído da definição do Glossário), a idéia de um padrão
é bem geral: o aplicativo (instanciação) de um padrão definido pode exigir
muitas mudanças de modelo, dependendo da especificidade e escala do problema
resolvido. O aplicativo de padrões e conseqüentemente a instanciação
de mecanismos, visualizados dessa maneira, ocorre pelo modelo
transformação
. Por exemplo, em um dos mecanismo definidos anteriormente, a segurança, qualquer padrão
que seja a base para um mecanismo de segurança é provavelmente penetrante e requer
mudanças que diferem do tipo de elemento modelo para o tipo de elemento. A definição do
padrão de segurança pode ser localizada em um
Perfil UML
, que é um modo padronizado de capturar estereótipos, valores marcados e restrições,
que definem e restringem uma tecnologia, disciplina e domínio ou outra área de preocupação de modelagem
específicos. Ou seja, em essência, o mesmo que uma
plataforma
(consulte
Conceitos: Desenvolvimento Orientado ao Modelo e Arquitetura Dirigida
ao Modelo®
); então a idéia de uma ou mais transformações implementando "padrões ampliados"
é aplicável aqui.
Nesta visualização, o relacionamento entre o padrão (ampliado) e a transformação
pode ser ilustrado da seguinte maneira:

No entanto, a experiência comum de muitos é que um padrão seja uma coisa mais restrita.
É, nesta visualização, um tipo de transformação (é aplicado a um modelo de origem
e sua aplicação resulta em um modelo alterado), mas a alteração é elaborativa,
é aplicada localmente (talvez em uma de várias etapas) e os modelos de origem e
de destino permanecem quase no mesmo nível amplo de abstração. Você pode até considerá-los
como o mesmo modelo. Por exemplo, você pode aplicar um padrão na forma de colaboração
parametrizada para um Modelo de Design e, já que o padrão não é específico para a
tecnologia, ainda alega que o resultado é um Modelo de Design. Isso é espelhado
no RUP ao falarmos de Padrões de Análise, Padrões de Design e Padrões de Implementação
(Idiomas). Nesta visualização, o relacionamento entre o padrão e
a transformação (agora mostrado como uma classe abstrata) é visualizado da seguinte maneira:

Esse uso mais específico dos padrões é explorado a seguir.
Como Arquitetos de Software, gostaríamos de continuar trabalhando em um alto nível de abstração e,
tendo identificado e caracterizado os mecanismos de análise requeridos e seus padrões de suporte
(pequenos e grandes), utilize a transformação automatizada para implementá-los. No final das contas, na medida em que progredimos pela análise e o design, nossa esperança é automatizar o máximo possível da transformação do modelo antes de
finalmente fazê-lo saltar para o código com nossos modelos de UML ainda em um nível alto de abstração, não simplesmente
as reflexões diretas do código.
Abordagens para a Transformação 
Em Conceitos: Desenvolvimento Orientado ao Modelo e Arquitetura
Dirigida ao Modelo®, esboçamos um número de abordagens para transformação
(consulte Como a Transformação é
Realizada?
). Para fornecer um exemplo concreto, o Rational Software Architect suporta uma abordagem
com base em uma combinação de mapeamentos de tipo (por exemplo, determinar como as classes de modelo
de origem, seus atributos, operações e relacionamentos afetam os elementos de destino), e a marcação do modelo de origem, ambos ativados por perfis.
Esta abordagem reconhece que o modelo de origem normalmente não contém informações
suficientes para guiar completamente a transformação por meio do mapeamento de tipo. O Arquiteto de
Software pode incluir marcas, como os estereótipos definidos em um perfil,
para que o modelo de origem especifique completamente a transformação. Essas marcas, que representam
conceitos da plataforma de destino, não fazem parte do modelo de origem, mas o sobrepõem. As regras que controlam a transformação são derivadas da definição da plataforma de destino, por exemplo, a partir de um perfil associado e
a partir do mapeamento de tipos utilizados na origem para os tipos utilizados no destino.
Tendo estabelecido as regras de transformação e marcado a origem, a transformação
pode prosseguir. O Rational Software Architect vai além e permite que os parâmetros
sejam fornecidos para a transformação, por exemplo, para especificar informações que
não podem ser derivadas do perfil ou das marcas associadas. Um benefício adicional
de fazer mudanças no modelo de modo sistemático é que um registro da transformação
é produzido e salvo. Isso preserva informações de forte rastreabilidade a partir do modelo de origem
para o modelo de destino.
Novamente, para fornecer alguns exemplos concretos, o Rational Software Architect transforma
o conceito geral da transformação de abstrato em concreto em
transformações
e padrões
. As definições oferecidas são as utilizadas pelo Rational Software Architect.
Transformar 
Uma transformação é "uma transformação otimizada para o processamento de batch, principalmente
em metamodelos, modelos e níveis de abstração". O aplicativo de uma transformação
normalmente resulta na produção de um modelo obviamente distinto, por exemplo,
um modelo de código textual a partir de um modelo UML. Isso é um salto significativo
com uma alteração notacional também.
Padrão 
Um padrão é "uma transformação que é otimizada para elaboração interativa
e criteriosa principalmente em um único metamodelo e dentro do mesmo nível de
abstração e freqüentemente dentro do mesmo modelo". Por essa definição,
o resultado do aplicativo de um padrão em um modelo de UML permanece um modelo de UML,
talvez de alguma forma um mais elaborado, mas um que é reconhecível no mesmo nível
de abstração.
O relacionamento entre a transformação e o padrão refina o diagrama anterior
da seguinte maneira:

Outra conseqüência dessa abordagem mais rigorosa é que os perfis e as transformações
que são derivados tornam-se entidades importantes em seu próprio direito. O Arquiteto de Software espera alavancar, por meio da reutilização, o trabalho feito na preparação de uma transformação. Espera-se que as bibliotecas de
transformações sejam criadas para que as transformações one-off sejam a exceção.
Essas bibliotecas devem ser pesquisáveis ou navegáveis pelas propriedades de transformação,
de modo que, por exemplo, o Arquiteto de Software possa facilmente compatibilizá-las às características
identificadas dos mecanismos de análise requeridos.
Informações adicionais sobre o desempenho da transformação utilizando o Rational Software
Architect podem ser localizadas em vários tutoriais do Rational Software Architect e amostras, incluindo:
Tutorial:
Aplicando o Padrão XYZ
Tutorial:
Estendendo Padrões
Amostra: Modelo
para o Aplicativo Padrão
Amostra: Padrão
Amostra: Padrão a
ser Estendido
Tutorial:
Design: Transformar Modelo em Código
Tutorial:
Design: Transformar Modelo em Modelo
Amostra: Aplicar
Transformação
Amostra: Construindo
uma Primeira Transformação
Amostra: Construir
uma Transformação Modelo a Modelo
Amostra: Criar uma
Transformação que Gera Texto
Amostra: Implementar
uma Transformação para outros Usuários do Rational Software Architect
| |
|