Mentor de Ferramentas: Identificando
Elementos de Design Utilizando o Rational Software Architect
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.
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:
- Crie diagramas de classe conforme necessário. Consulte
Incluindo Diagramas de Classe aos Elementos do Modelo.
- Inclua sinais. Consulte
Criando e Modificando Diagramas de Classe.
- Inclua uma breve descrição para cada elemento de design. Consulte
Documentando Elementos de Modelo.
- 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.
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.
- Crie diagramas de classe conforme necessário. Consulte
Incluindo Diagramas de Classe aos Elementos do Modelo.
- Inclua subsistemas e classes. Consulte
Criando e Modificando Diagramas de Classe.
- Inclua uma breve descrição para cada elemento de design. Consulte
Documentando Elementos de Modelo.
- (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.
- 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.
As etapas a seguir aplicam-se aos subsistemas de grande granulosidade:
- 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.
- Inclua dependências de interface.
- Mapeie subsistemas para interfaces, incluindo um relacionamento de realização do
subsistema para a interface.
- Documente a interface, incluindo o comportamento necessário. Consulte
Documentando Elementos de Modelo.
- Inclua operações na interface. Consulte
Incluindo Operações em Classificadores nos Diagramas.
- Inclua uma descrição em cada operação. Consulte
Documentando Elementos de Modelo.
- Inclua parâmetros em cada operação. Consulte
Incluindo Operações em Classificadores nos Diagramas.
- 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.
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
| |
|