Build é uma versão operacional de um sistema ou parte de um sistema que demonstra um subconjunto dos recursos a serem fornecidos no produto final. Uma versão é constituída por um ou mais elementos de implementação (geralmente executáveis), cada um construído de outros elementos, normalmente por um processo de compilação e link de código fonte.  
Função:  Integrador  
Opcionalidade/Ocorrência:  Para cada iteração.
Gabaritos e Relatórios: 
     
Exemplos: 
     
Representação em UML:  Pacote no modelo de implementação (pacote de nível superior ou um subsistema de implementação), estereotipado como <<build>>. 
Informações Adicionais:   
Entrada de Atividades:    Saída das Atividades:   

Finalidade Para o início da página

A finalidade de um build, construído de outros componentes na implementação, é liberar um subconjunto testável dos recursos e funções de tempo de execução do sistema. O RUP (Rational Unified Process) sugere que uma seqüência de builds seja construída durante uma iteração, incluindo recurso em cada um deles à medida que elementos de subsistemas de implementação forem incluídos ou aprimorados.   Os builds podem ser construídos em todos os níveis de um sistema, abrangendo um único subsistema ou vários mas, no RUP, o interesse particular está nos builds que são definidos no Artefato: Plano de Integração do Build, pois esse é o ponto de partida para a conclusão da iteração.  Se o tamanho ou a complexidade do sistema garantir isso, o plano de integração do build pode ser refinado em vários planos, abrangendo subsistemas individuais.

Observe que os builds informais podem ser construídos por um implementador por vários motivos - testes de unidade, por exemplo - utilizando elementos provenientes do espaço de trabalho de desenvolvimento privado do implementador e dos espaços de trabalho de integração do sistema e subsistema, conforme apropriado. Contudo, como o termo é utilizado aqui, os builds são construídos por um integrador, a partir de versões identificadas de elementos liberados pelos implementadores aos espaços de trabalho de integração do sistema ou subsistema, como definido no Artefato: Plano de Integração do Build.

Propriedades Para o início da página

Nome da Propriedade 

Breve Descrição 

Representação em UML 

Descrição  Uma descrição textual breve do build  Valor ativado, do tipo "texto curto" 
Subsistemas de Implementação  Os subsistemas representados no build  Adquiridos por meio da meta-associação "representa" ou recursivamente por meio da meta-agregação "possui" 
Elementos  Os elementos de implementação no build, pertencentes aos subsistemas  Adquiridos recursivamente por meio da meta-agregação "possui" 
Referência do Plano de Integração do Build  Referência à descrição detalhada do build no Plano de Integração do Build correspondente  Valor ativado 

Sincronização Para o início da página

Os builds serão construídos conforme definido no Artefato: Plano de Integração do Build para cada iteração. O RUP não exige qualquer freqüência ou cronometragem específica; isso é selecionado para a adequação às necessidades específicas de um projeto. Com o grau correto de automação, certamente é possível adotar uma estratégia de builds diários, utilizando um fluxo estável de elementos provenientes dos implementadores, integrando-os e testando o build resultante durante a noite. Esse procedimento não será adequado para todos os projetos, especialmente para os de grande porte, que requerem um teste de regressão demorado.

Responsabilidade Para o início da página

O Integrador é responsável pela produção de builds. Se o desenvolvimento for planejado com base em subsistemas (com equipes associadas), que depois são integrados ao sistema, pode ser que haja várias pessoas desempenhando o papel de Integrador. Talvez até mesmo uma em cada equipe de subsistema, para realizar a integração nesse nível, e outra para realizar a integração no nível do sistema.

Adaptação Para o início da página

Obviamente que os builds são obrigatórios; entretanto, os tipos de builds que um projeto produz serão alterados durante todo o ciclo de vida. Na fase de iniciação, a preocupação pode ser produzir protótipos como uma maneira de compreender melhor o problema ou de se comunicar com o cliente. Na elaboração, pode ser produzir uma arquitetura estável e, na construção, adicionar funcionalidade. Na transição, o objetivo é garantir que o software atinja uma qualidade apropriada.



Rational Unified Process   2003.06.15