Tópicos

Introdução a Mecanismos de Análise Para o início da página

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 ../../glossary.htm#architectural_pattern -- This hyperlink in not present in this generated websitepadrões de arquitetura ou ../../glossary.htm#analysis_pattern -- This hyperlink in not present in this generated websitede 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 ../../glossary.htm#framework -- This hyperlink in not present in this generated websiteestrutura. 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 ../../glossary.htm#analysis_pattern -- This hyperlink in not present in this generated websitepadrõ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.

Exemplos de Mecanismos de Análise Para o início da página

  • 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

Descrevendo Mecanismos de AnálisePara o início da página

Este é o processo de descrição dos mecanismos de análise:

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

  2. Desenhar um mapa das classes de cliente para os mecanismos de análise
  3. Diagrama mostrando relacionamentos entreClasses e 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.

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

  5. 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 ../../glossary.htm#pattern -- This hyperlink in not present in this generated websitepadrõ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.

Aplicativo dos Mecanismos de Análise Para o início da  página

Padrões e Transformações Para o início da página

Segundo plano Para o início dapágina

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 ../../glossary.htm#transformation -- This hyperlink in not present in this generated websitetransformaçã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 ../../glossary.htm#UML_profile -- This hyperlink in not present in this generated websitePerfil 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 ../../glossary.htm#platform -- This hyperlink in not present in this generated websiteplataforma (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:

Este diagrama mostra uma transformação como algo que é derivado de um padrão ampliado (e pode então ser utilizado para implementá-lo).

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:

Este diagrama mostra a noção de padrão, na medida em que a restringimos, como uma subclasse da transformação de classe abstrata.

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 Para o início dapágina

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 ../../glossary.htm#transform -- This hyperlink in not present in this generated websitetransformações e ../../glossary.htm#pattern -- This hyperlink in not present in this generated websitepadrões . As definições oferecidas são as utilizadas pelo Rational Software Architect.

Transformar Para o início dapágina

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 Para o início dapágina

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:

Este diagrama inclui transformações como uma subclasse detransformação.

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

 

Rational Unified Process   2003.06.15