Finalidade
  • Estabelecer a estrutura em que a implementação residirá.
  • Atribuir responsabilidades para Subsistemas de Implementação e seu conteúdo.
 
Função:  Arquiteto de Software  
Freqüência: Pelo menos uma vez por iteração, conforme a descoberta de novos elementos de implementação. 
Etapas  
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   
Informações Adicionais: 

Detalhes de Detalhamento do Fluxo de Trabalho::   

Estabelecer a estrutura do modelo de implementação Para o início da página

Finalidade Estabelecer a estrutura do Modelo de Implementação. 

A transição do 'espaço de design' para o 'espaço de implementação' começa com o espelhamento da estrutura do Modelo de Design no Modelo de Implementação.

Pacotes de Design terão Subsistemas de Implementação correspondentes, que conterão um ou mais diretórios e arquivos (Artefato: Elemento de Implementação) necessários para implementar os elementos de design correspondentes. O mapeamento do Modelo de Design para o Modelo de Implementação pode mudar quando cada Subsistema de Implementação for alocado para uma camada específica da arquitetura.

Crie um diagrama para representar a Estrutura do Modelo de Implementação (consulte Diretrizes: Diagrama de Implementação).

Ajustar subsistemas de implementação Para o início da página

Finalidade Adaptar a estrutura do modelo para refletir a organização da equipe ou as restrições de linguagem da implementação.  

Decida se a organização de subsistemas precisa ser modificada, abordando pequenas questões táticas relacionadas ao ambiente de implementação. A seguir, são fornecidos exemplos dessas questões táticas. Observe que, se você decidir modificar a organização dos subsistemas de implementação, deverá também decidir se voltará e atualizará o modelo de design ou se deixará o modelo de design diferente do modelo de implementação.

  • Organização da equipe de desenvolvimento. A estrutura do subsistema deve permitir que vários implementadores ou equipes trabalhem paralelamente, sem muitas sobreposições e agitações. Recomenda-se que cada subsistema de implementação seja responsável por apenas uma equipe. Isso significa que talvez você precise dividir um subsistema em dois (se ele for grande) e designar duas partes dele para que sejam implementados por dois implementadores ou duas equipes de implementadores,  particularmente se os dois implementadores (ou equipes) tiverem diferentes ciclos de construção/liberação.
  • Declarações de tipos. Na implementação, você pode perceber que um subsistema precisa importar artefatos de outro subsistema, pois um tipo é declarado nesse subsistema. Geralmente, isso ocorre quando você utiliza linguagens de programação de tipo, como a C++, Java e Ada. Nesse caso e, em termos genéricos, talvez seja uma boa idéia extrair as declarações de tipo e inseri-las em um subsistema separado.

Exemplo

Você extrai algumas declarações de tipo do Subsistema D e as insere em um novo subsistema Tipos, a fim de criar o Subsistema A, independentemente das mudanças efetuadas nos artefatos públicos (visíveis) do Subsistema D.

Ilustração da Extração do Subsistema de Declaração de Tipo

As declarações de tipo são extraídas do Subsistema D

.

  • O código legado existente e os sistemas de componentes. Talvez seja necessário incorporar o código legado, uma biblioteca de componentes reutilizáveis ou os produtos prontamente disponíveis. Se eles não foram modelados na fase de design, é sinal de que os subsistemas de implementação deverão ser adicionados.
  • Ajuste das dependências. Suponha que um subsistema A e um subsistema B tenham dependências de importação entre si. No entanto, talvez você precise fazer com que B seja menos dependente no que diz respeito a mudanças no subsistema A. Extraia os artefatos de A que B importa e coloque-os em um novo subsistema A1 de implementação, em uma camada inferior.

Diagrama de Amostra da Transferência de Grupos de Artefatos

Os artefatos são extraídos do subsistema A e colocados em um novo subsistema A1.

Agora que os Subsistemas de Implementação não mapeiam mais um por um dos pacotes/subsistemas no Modelo de Design, será possível fazer uma alteração correspondente no Modelo de Design (se você decidiu manter o Modelo de Design estreitamente alinhado ao Modelo de Implementação) ou manter o controle do mapeamento entre os Modelos de Implementação e Design (por exemplo, através de dependências de rastreabilidade ou realização). Se e como tal mapeamento é feito é uma decisão processual que deve ser obtida no ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteArtefato: Diretrizes Específicas do Projeto.

Definir importações para cada subsistema de implementação Para o início da página

Finalidade Definir dependências entre subsistemas.  

Para cada subsistema, defina quais são os outros subsistemas que ele importa. Isso pode ser feito para conjuntos inteiros de subsistemas, permitindo que todos os subsistemas de uma camada importem todos os subsistemas de uma camada inferior. Geralmente, as dependências no Modelo de Implementação espelharão as dependências do Modelo de Design, a não ser onde a estrutura do Modelo de Implementação foi ajustada (consulte Ajustar subsistemas de implementação).

Apresente a estrutura em camadas dos subsistemas nos diagramas de componentes.

Decidir como tratar os executáveis (e outros objetos derivados) Para o início da página

Os executáveis (e outros objetos derivados) são o resultado da aplicação de um processo de build a um subsistema (ou a vários subsistemas) de implementação ou a uma parte dele e, portanto, pertencem logicamente ao subsistema de implementação. No entanto, o arquiteto de software, trabalhando em conjunto com o gerente de configuração, precisará decidir qual será a estrutura do item de configuração aplicada ao modelo de implementação.  

Para facilitar a seleção e a referência, particularmente na implantação, a recomendação padrão é definir itens de configuração separados para armazenar os conjuntos de executáveis que podem ser implementados (os executáveis que serão implementados em nós são capturados no Modelo de Implementação) Sendo assim, em um caso simples, para cada subsistema de implementação, haveria um item de configuração para os executáveis que podem ser implementados e um item de configuração para armazenar a origem etc. utilizada para produzi-los.  Pode-se considerar que um subsistema de implementação seja representado por um item de configuração composto que contenha esses itens de configuração (e talvez outros, como os recursos de teste).

Do ponto de vista da modelagem, uma coleção de executáveis produzidos por um processo de construção pode ser representada como um Artefato: Construção (que é um pacote) contido no subsistema de implementação associado (um pacote propriamente dito).   

Decidir como tratar os recursos de teste Para o início da página

Finalidade Adicionar os artefatos de teste ao Modelo de Implementação.  

Em geral, os artefatos e os subsistemas de teste não são tratados pelo Rational Unified Process de forma muito diferente que qualquer outro software desenvolvido. No entanto, artefatos e subsistemas normalmente não fazem parte do sistema implementado e, em geral, não podem ser liberados ao cliente. Portanto, a recomendação padrão é alinhar os recursos de teste com o objetivo do teste (por exemplo, o elemento de implementação para o teste de unidade, o subsistema de implementação para o teste de integração, o sistema para o teste de sistema), mas manter os recursos de teste em diretórios separados, por exemplo, caso o repositório do projeto seja organizado como um conjunto ou uma hierarquia de diretórios. Subsistemas de teste distintos (destinados a testes executados acima do nível de teste unitário) devem se tratados da mesma maneira que outros subsistemas de implementação - como itens de configuração distintos.

Para modelagem, uma coleção de artefatos de teste pode ser representada como um Artefato: Subsistema de Implementação (um pacote). Para teste unitário, esse subsistema de teste ficará normalmente armazenado no subsistema de implementação associado (testado). O arquiteto de software, em consultoria com o gerente de configuração, deve decidir se os artefatos de teste nesse nível devem ser configurados com os elementos de implementação que eles testam ou como itens de configuração separados. Para integração e teste de sistema, os subsistemas de teste podem ser parceiros dos subsistemas de implementação que estão sendo testados.

Atualizar a visualização da implementação Para o início da página

Finalidade Atualizar a visão de implementação do Documento de Arquitetura de Software.  

A Visualização de Implementação é descrita na seção "Visualização de Implementação" do Documento de Arquitetura de Software. Esta seção contém diagramas de componentes que mostram as camadas e a alocação dos subsistemas de implementação às camadas, bem como as dependências de importação entre os subsistemas.

Avaliar o modelo de implementação Para o início da página

Consulte Pontos de Verificação: Modelo de Implementação.

 

Rational Unified Process   2003.06.15