Atividade:
| |||||||||||||||||||||
Finalidade
|
|
Passos
|
|
| Artefatos Informados: | Artefatos Resultantes: |
| Papel: Arquiteto de Software | |
| Diretrizes: | |
| Mentor de Ferramentas: | |
| Detalhamentos do Fluxo de Trabalho: |
Finalidade
|
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.
Os Pacotes de Design terão Subsistemas de Implementação correspondentes, que conterão um ou mais componentes e todos os arquivos relacionados necessários à implementação dos componentes. 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. Observe que as classes e, possivelmente, os subsistemas de design do Modelo de Design são mapeados para componentes do Modelo de Implementação, embora essa não seja necessariamente uma relação um-para-um (consulte Conceito: Mapeamento para Código a Partir do Design e Artefato: Subsistema de Design).
Crie um Diagrama de Componentes para representar a Estrutura do Modelo de Implementação Diagrama. Um Diagrama de Componentes simples é mostrado a seguir:
Exemplo de Diagrama de Componentes para um Caixa Eletrônico Simples
Finalidade
|
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 componentes públicos (visíveis) do Subsistema D.
As declarações de tipo são extraídas do Subsistema D
.
Os componentes são extraídos do subsistema A e colocados em um novo subsistema A1.
Finalidade
|
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 do 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 implantados. Sendo assim, em um caso simples, para cada subsistema de implementação, haverá um item de configuração para os executáveis que podem ser implantados e um item de configuração para armazenar a fonte etc. usada 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 ativos de teste, por exemplo).
Do ponto de vista da modelagem, um conjunto de executáveis produzidos por um processo de build pode ser representada como um Artefato: Build (que é um pacote) armazenado dentro do subsistema de implementação associado (um pacote).
Finalidade
|
Em geral, os componentes 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, eles normalmente não são parte do sistema implantado e, em geral, não podem ser liberados ao cliente. Portanto, a recomendação padrão é alinhar os recursos de teste ao objetivo do teste (por exemplo, componente a teste unitário, subsistema de implementação a teste de integração, sistema a teste de sistema), mas manter esses recursos 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, um conjunto de componentes 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 componentes de teste neste nível devem ser configurados junto com os componentes 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
|
A visão de implementação é descrita na seção "Visã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.
|
Rational Unified Process
|
