Atividade:
|
Finalidade
|
|
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:: |
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).
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.
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.
As declarações de tipo são extraídas do Subsistema D
.
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 Artefato:
Diretrizes Específicas do Projeto.
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.
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).
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.
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.
Consulte Pontos de Verificação: Modelo de Implementação.
Rational Unified Process
|