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).

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 implementadas 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 produtos de trabalho de um 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 produtos de trabalho públicos (visíveis) do Subsistema D.

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 de mudanças no subsistema A. Extraia os produtos de trabalho de A que B importa e coloque-os em um novo subsistema A1 de implementação, em uma camada inferior.

Os produtos 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 capturada no Produto de Trabalho: Diretrizes Específicas do Projeto.

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 construção 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 gerenciador 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 implementação, a recomendação padrão é definir itens de configuração separados para conter os conjuntos de programas executáveis que podem ser implementados (quais programas executáveis que serão implementados em quais 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 programas executáveis que podem ser implementados e um item de configuração para conter 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 programas executáveis produzidos por um processo de construção pode ser representada como um Produto de Trabalho: Construção (que é um pacote) contido no subsistema de implementação associado (um pacote propriamente dito).  

Em geral, os produtos de trabalho e os subsistemas de teste não são tratados pelo Rational Unified Process de forma muito diferente de qualquer outro software desenvolvido. No entanto, produtos de trabalho 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 produtos de trabalho de teste pode ser representada como um Produto de Trabalho: 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 gerenciador de configuração, deve decidir se os produtos de trabalho 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.

A Visualização de Implementação é descrita no 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 Lista de Verificação: Modelo de Implementação.