Finalidade

Essa seção fornece links às informações adicionais relacionadas ao mentor de ferramentas.


As etapas no mentor da ferramenta correspondem com as da atividade. Os links para os tópicos na Ajuda on-line do RSA estão marcados com .

Visão Geral

No mentor de ferramentas, as seguintes etapas são executadas para os casos de uso a serem projetados na iteração atual:

Informações de Ferramenta Adicional

Elementos de design arquiteturalmente significativos podem ser documentados em uma Visualização Lógica separada, que é mantida à medida que os elementos de design são identificados. A recomendação geral no RSA é utilizar pacotes de <<perspectivas>>. Consulte Diretrizes da Estrutura do Modelo para o Rational Software Architect para obter informações adicionais sobre este tópico.

Identificar Eventos e Sinais Para o início da página

As características dos eventos, também chamados de acionadores na UML 2.0, devem ser capturadas conforme necessário para conduzir a identificação dos elementos de design que as manipulam. Essas informações podem ser capturadas informalmente, como em um documento separado, em vez de como parte de um modelo RSA.

Eventos de comunicação assíncrona podem ser modelados como sinais para expressar os dados transportados ou as relações entre os sinais, como relacionamento de generalização. As subetapas a seguir descrevem como modelar sinais:

  1. Crie diagramas de classe conforme necessário. Consulte Incluindo Diagramas de Classe aos Elementos do Modelo.
  2. Inclua sinais. Consulte Criando e Modificando Diagramas de Classe.
  3. Inclua uma breve descrição para cada elemento de design. Consulte Documentando Elementos de Modelo.
  4. Inclua relacionamentos de generalização entre os sinais, se aplicável.

Para obter informações adicionais sobre diagramas de classe, consulte Modelando a Estrutura Estática com Diagramas de Classe.

Identificar Classes, Classes Ativas e Subsistemas Para o início da página

Os elementos de design são geralmente criados das três maneiras a seguir:

  • Expandindo um Padrão
  • Modelagem
  • Codificação e Engenharia Reversa

Essas abordagens são aplicadas nas seções a seguir.

Expandindo um Padrão

No RSA, um padrão é um tipo especial de transformação otimizada para elaboração interativa e criteriosa, principalmente em um metamodelo único e no mesmo nível de abstração e, muitas vezes, no mesmo modelo. Para obter informações adicionais, consulte Mecanismos de Análise.

Consulte Autoria de Padrões e Aplicando Padrões na Ajuda on-line do RSA.

Modelando

A ferramenta RSA suporta uma abordagem orientada a modelos para o desenvolvimento de software (consulte Desenvolvimento Orientado a Modelos e Arquitetura Orientada a Modelos e Mecanismos de Análise), na qual você constrói um conjunto de modelos que inclui eventualmente um modelo de design e gera artefatos de implementação (código 3GL, descritores, etc.) a partir do modelo de design, utilizando Transformações. Em alguns casos, as Transformações de geração de código utilizarão as classes de análise como entradas, mas fundamentalmente, elas serão orientadas por elementos de design. Para obter informações adicionais, consulte: Design: Transformar Modelo em Modelo e Design: Transformar Modelo em Código.

Em uma abordagem de desenvolvimento tradicional, você criará diagramas de classe no Modelo de Design para capturar elementos de design. Se optar por manter as classes de análise, você poderá estabelecer a rastreabilidade utilizando dependências de "rastreio" para as classes de análise.

  1. Crie diagramas de classe conforme necessário. Consulte Incluindo Diagramas de Classe aos Elementos do Modelo.
  2. Inclua subsistemas e classes. Consulte Criando e Modificando Diagramas de Classe.
  3. Inclua uma breve descrição para cada elemento de design. Consulte Documentando Elementos de Modelo.
  4. (opcional) Inclua rastreabilidade nas classes de análise utilizando dependências de "rastreio" dos elementos de design para as classes de análise nas quais eles se basearam. Consulte Incluindo Relacionamentos de Abstração.
  5. Organize os elementos de design em subsistemas e pacotes. Consulte o white paper Diretrizes da Estrutura do Modelo para o Rational Software Architect.

Para obter informações adicionais sobre diagramas de classe, consulte Modelando a Estrutura Estática com Diagramas de Classe.

Codificação e Engenharia Reversa

Uma abordagem diferente é uma abordagem "codificar primeiro": o código é o driver principal porque já existe (por exemplo, em um ciclo de desenvolvimento que não seja inteiramente novo) ou a equipe precisa manejar alguns riscos específicos do projeto codificando um protótipo para validar um conceito complexo. Como parte do suporte para Descoberta e Recuperação da Arquitetura (consulte as diretrizes de Descoberta, Análise e Controle da Arquitetura), o recurso de visualização de código do RSA pode preencher automaticamente os diagramas de tópico, como estrutura de pacotes, natureza interna da classe, árvores de herança e colaborações. A meta desta atividade é não apenas entender o código existente, mas também extrair um modelo do aplicativo, que poderia ser utilizado em conjunto com outros modelos específicos para gerar a nova versão do aplicativo, utilizando transformações.

Após a geração ou composição de um diagrama de UML de código existente, você tem estas opções para alavancar as representações de código como parte de seu modelo de design:

  • Utilizar uma representação de UML de um elemento de código em seu modelo de design, como um elemento de modelo de semântica real. Isso cria um novo elemento de UML no modelo de design que não tem conexão com o item de código que foi utilizado. Entretanto, ele possui propriedades (por exemplo, atributos e operações) que refletem as propriedades do item de código utilizado. Por ser um elemento de semântica de UML real, é possível gerar novo código a partir dele (ou seja, ele possui o mesmo status dentro do modelo de design que qualquer elemento de design que tenha sido definido por meio do processo de modelagem greenfield descrito anteriormente.)
  • Coloque uma referência visual para o elemento de código em um diagrama que resida em seu modelo de design. Essa referência, por si só, não possui significado semântico no modelo de design e nenhum novo código será gerado a partir dela. Como o próprio nome diz, é apenas uma referência para o elemento de código real. Entretanto, é possível desenhar relacionamentos entre a referência de código e os elementos de design da semântica no modelo de design. Esses relacionamentos possuem significado semântico no modelo de design e afetam a geração de código.

Para obter informações adicionais, consulte Modelagem da Estrutura Estática com Diagramas de Classe na Ajuda on-line do RSA.

Identificar Interfaces de Subsistema Para o início da página

As etapas a seguir aplicam-se aos subsistemas de grande granulosidade:

  1. Para cada subsistema, identifique um conjunto de interfaces candidatas. Se, anteriormente, você criou classes de análise e fez realizações de casos de uso no nível de análise, decidirá agora como essas operações devem ser agrupadas e expostas como as interfaces de determinados componentes ou serviços. Inclua interfaces em um diagrama de componente existente ou crie novos diagramas de componentes, conforme necessário. Consulte Incluindo Shapes.
  2. Inclua dependências de interface.
  3. Mapeie subsistemas para interfaces, incluindo um relacionamento de realização do subsistema para a interface.
  4. Documente a interface, incluindo o comportamento necessário. Consulte Documentando Elementos de Modelo.
  5. Inclua operações na interface. Consulte Incluindo Operações em Classificadores nos Diagramas.
  6. Inclua uma descrição em cada operação. Consulte Documentando Elementos de Modelo.
  7. Inclua parâmetros em cada operação. Consulte Incluindo Operações em Classificadores nos Diagramas.
  8. Organize as interfaces em pacotes.

Na UML 2.0, os subsistemas são componentes grandes e podem ser representados como classes estruturadas com portas e/ou interfaces. Consulte os tópicos da UML 2.0 específicos da ajuda on-line.

Informações da Ferramenta AdicionalPara o início da página

Tours:

  • RAS
  • Padrões

Tutoriais:

  • Aplicando o Padrão XYZ

Amostras:

  • Modelo para Aplicação de Padrões
  • Padrões

Folhas de Dicas:

  • Identificando Elementos de Design

Rational Unified Process   2003.06.15