Diagrama de componentes

O Diagrama de componentes da UML ilustra como as classes deverão se encontrar organizadas através da noção de componentes de trabalho. O diagrama tem por objetivo apresentar a disposição dos componentes físicos de um sistema.

O principal objetivo deste diagrama segundo Scott Ambler, é possibilitar a construção de artefatos para o perfil de arquitetura da solução, seja para a arquitetura técnica ou a de negócios.

O diagrama é composto normalmente por componentes, interfaces e portas. Os componentes são representados pelo estereótipo da uml <> ou um retângulo vertical de duas hastes. Interfaces são representadas através de uma linha com um círculo ou semicírculo ligado ao componente. Portas são representados através de retângulos saindo dos componentes.

Normalmente é utilizado para:

• Modelar os componentes do código-fonte, do código executável do software.
• Destacar a função de cada módulo para facilitar a sua reutilização.
• Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

Retirado de http://www.rnp.br

Diagrama de máquina de estados

O diagrama de máquina de estados era conhecido nas versões anteriores como diagrama de gráfico ou simplesmente como diagrama de estados, tendo então mudado para este novo nome após a versão 2.0. Este diagrama procura acompanhar as mudanças sofridas nos estados de uma instância de uma classe ao longo da execução de um caso de uso, subsistema ou mesmo sistema.

O Diagrama de máquina de estados muitas vezes se baseia no caso de uso e se apóia no Diagrama de Classes.

Retirado de http://www.comp.ita.br/~olany/State_Diag2.jpg

O diagrama acima mostra um diagrama de máquinas de estado. Este diagrama mostra como ocorrem as alterações nos estados de um objeto após terem sido realizados ações sobre este.

Diagrama de Comunicação

O diagrama de comunicação é o antigo diagrama de colaboração até a versão 1.5 da UML, tendo modificado seu nome a partir da versão 2.0. Este é um diagrama bem parecido com o diagrama de seqüência, mas não possui seu aspecto temporal.

Ele normalmente é utilizado como complemento do diagrama de seqüência, porem possui um enfoque diferente, concentrando-se em como os objetos estão vinculados através de mensagens. Pode ser gerado a partir do diagrama de seqüências por representar os mesmos dados. Outra característica do diagrama de comunicação é que as mensagens possuem numeração para designar seqüência.

Figura retirada de http://www.novatec.com.br

Nesta figura é mostrado o diagrama de comunicação do caso de uso realizar submissão. É mostrado as mensagens trocadas entre o Submissor, a página do congresso, o controlador do congresso, o tema e a Submissão.

Diagrama de estrutura composta

Olá pessoal,

Quis hoje começar a debater sobre alguns diagramas da uml 2.0 que são pouco utilizados. O primeiro da lista de diagramas pouco utilizados é o diagrama de estrutura composta.

O diagrama de estrutura composta é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica.

Então podemos dizer que o diagrama de estrutura composta reflete a colaboração interna das classes para descrever a funcionalidade. São bem similares aos diagramas de classes, exceto pelo fato de que eles modelam um uso específico da estrutura.

Retirado de http://www.novatec.com.br

O termo estrutura se refere à composição dos elementos estruturais interconectados de forma a atingir algum objetivo comum. O exemplo acima mostra como as instâncias das classes autor, submissão, tema e tipo colaboram entre si para submeter à submissão. As colaborações podem também possuir multiplicidade, se as regras seguidas pelas classes utilizarem múltiplas instâncias.

Este é um diagrama que não é muito utilizado na UML e provavelmente é mais um diagrama teórico do que um diagrama utilizado nos processos de desenvolvimento.

Ferramenta de integração contínua

Integração contínua consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de código permaneça consistente ao final de cada integração.

A este mesmo procedimento de construção podem ser adicionadas rotinas como:

• Execução de testes automatizados
• Geração de versões internacionalizadas de seu software
• Disponibilizar a versão atual em desenvolvimento para o cliente
• Criação de relatórios de código como:
• Cobertura de testes
• Inspeção de padrões de codificação
• Estatísticas de acoplamento

Todo o processo segue a arquitetura descrita na imagem abaixo:

O cenário acima pode ser descrito como: (Fonte: Continuous Integration)

1. O desenvolvedor envia o código para o controle de versão (SVN, CVS, etc). Enquanto isso a máquina de integração (servidor de Integração Contínua) está verificando o repositório buscando por modificações
2. Logo após um commit ser efetuado, o servidor ao verificar que alguma mudança ocorreu no repositório inicia o processo de build baixando os arquivos do Servidor de Controle de Versão. Assim, o script de build é executado, testes são realizados, relatórios gerados, e todo o projeto é integrado.
3. O Servidor de Integração envia por e-mail ou outros dispositivos o feedback sobre build para usuários específicos do projeto
4. O servidor volta ao estado de Poll buscando por mudanças no repositório

Com relação a ferramentas a serem utilizadas e a comparação entre elas temos 3 que se destacaram. Entre elas temos as ferramentas cruise-control, continuum e hudson.

Minha escolha pessoal é a utilização do Hudson. Entre as funcionalidades que mais me agradam estão:

• Permite a configuração de novos jobs através de interface web.
• Permite a realização de builds distribuídos.
• É um projeto mais ativo com mais desenvolvedores.
• Possui plugin para o eclipse.
• Possui instalador do windows.
• Utilização por parte de grandes projetos.
• Integração com o Maven, SVN, CVS e com outras ferramentas.
• Facilidade maior para configuração do que as outras ferramentas.