Entender a Tarefa/Problema

Antes de iniciar uma tarefa de implementação, o implementador deve ser claro no escopo, como especificado nas designações de trabalho e nos planos de iteração. Uma tarefa de implementação pode visar a obtenção de uma funcionalidade específica (como implementar uma realização de caso de uso de design ou corrigir um defeito) que envolve a implementação de vários elementos de design que contribuem para essa funcionalidade. Como alternativa, uma tarefa de implementação pode ter como foco um elemento de design específico, como um Subsistema de Design ou uma Classe de Design, implementando-o até a extensão exigida pela iteração atual.

Configurar Ambiente de Desenvolvimento

Esta tarefa resulta na criação ou atualização de um ou mais arquivos (Elementos de Implementação). Como parte da preparação da implementação, o implementador deve garantir que seu ambiente de desenvolvimento seja configurado corretamente para que as versões de elemento corretas estejam disponíveis, os elementos sejam atualizados e os demais elementos requeridos para a compilação e o teste de unidade. O implementador deve estar ciente e seguir a configuração do projeto e os procedimentos de gerenciamento de mudanças, os quais descrevem como as mudanças são controladas e têm sua versão criada, e como elas são entregues para integração.

Analisar a Implementação Existente

Antes de implementar uma classe desde o início, considere se há código existente que possa ser reutilizado ou adaptado. Entender onde a implementação se ajusta na arquitetura e no design do restante do sistema pode ajudar o implementador a identificar tais oportunidades de reutilização, bem como a garantir que a implementação se ajuste ao restante do sistema.

Implementar Incrementalmente

É recomendável implementar incrementalmente; compile, vincule e execute alguns testes de regressão algumas vezes por dia. É importante saber que nem todas as operações públicas, atributos e associações são definidos durante o design.

Ao tratar defeitos, verifique se você corrigiu o problema, não o sintoma; você deverá focar a correção do problema básico no código. Efetue uma alteração de cada vez, pois a correção de falhas é em si uma tarefa propensa a erros. É importante implementar as correções gradativamente, para facilitar a localização da origem de novas falhas.

O implementador deve estar ciente e seguir todas as diretrizes de implementação específicas do projeto, incluindo as diretrizes de programação para as linguagens de programação específicas.

Há várias técnicas para transformação de design em implementação. A seguir são apresentados alguns exemplos:

• Os modelos visuais específicos da plataforma podem ser utilizados para gerar uma estrutura de código inicial. Essa estrutura de código pode ser ainda mais elaborada com código adicional não especificado no design.
  
• Os modelos podem ser detalhados e utilizados para gerar protótipos executáveis. Ambos os diagramas de estrutura (diagramas de classe e de pacote) e de comportamento (como o diagrama de estado e de atividade) podem ser utilizados para gerar código executável. Esses protótipos podem ser ainda mais aperfeiçoados, conforme necessário.
  
• Os modelos também podem ser detalhados até o ponto em que o modelo represente completamente a implementação. Nesse caso, em vez de transformar um design abstrato em uma implementação de código, você toma o design e inclui detalhes de implementação diretamente no modelo.
  
• O design pode ser independente de plataforma para variar graduações. Modelos específicos de plataforma ou mesmo códigos podem ser gerados através de transformações que aplicam-se a várias regras para mapear elementos específicos de plataforma de abstrações de nível alto. Este é o foco da iniciativa do OMG (Object Management Group) MDA (Model Driven Architecture) (http://www.omg.org).
  
• Também é possível aplicar modelos padrão para gerar elementos de design e de código a partir de design e implementação relacionados. Por exemplo, um modelo de transformação padrão pode ser aplicado a uma tabela de dados para criar classes java para acessar a tabela de dados. Outro exemplo é utilizar um modelo Eclipse Modeling Framework (http://www.eclipse.org/emf/), para gerar código para o armazenamento de dados que correspondam ao modelo e para gerar uma implementação de interface com o usuário para o preenchimento de dados.

Em todos os casos, no entanto, alguma abstração de design é detalhada para tornar-se a implementação, seja manualmente ou por meio da aplicação de alguma transformação automatizada.

Conforme descrito na etapa anterior, a transformação de design em implementação pode resultar em graus variados de abrangência de implementação. Ela pode ser uma implementação completa e aceitável. Normalmente, no entanto, há um esforço substancial para concluir a implementação, por exemplo:

• Ajustar os resultados da transformação (por exemplo, aprimorar o desempenho ou a interface com o usuário)
  
• Incluir detalhes ausentes, como:
  • a conclusão de operações descritas no design - escolhendo algoritmos e gravando o código.
  • a inclusão de classes de suporte, operações e estrutura de dados

É aqui que você verifica se a implementação se adequa à finalidade.  Além do teste (descrito em outras tarefas), algumas verificações adicionais são sempre úteis:

• Ler mentalmente através do código. Considere manter uma lista de verificação de erros comuns que são feitos nas implementações e procure por esses erros.
• Utilize ferramentas para verificar se há erros no código. Por exemplo, um verificador ou compilador de regra de código estático definido com o nível de aviso detalhado.
• Utilize ferramentas que possam visualizar o código. A visualização do código pode ajudar um implementador a identificar padrões, como acoplamento excessivo, dependências circulares, etc.

Conforme os designs são implementados e testados, é inevitável a descoberta de erros, muitas vezes, erros que afetam o design. Se uma abstração de design for mantida para tentativas de manutenção futuras ou por motivos contratuais ou de comunicação, o design terá então que ser atualizado.

Como isso é feito depende da configuração do projeto e do processo de gerenciamento de mudanças. Em geral, se a mudança exigida for pequena e a mesma pessoa estiver projetando e implementando a classe, não haverá necessidade de um controle de mudança formal. A pessoa poderá efetuar a mudança no design.

Se a alteração requerida tiver um impacto amplo, por exemplo, uma alteração em uma operação pública, então talvez seja necessário submeter um controle de mudanças formal.