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.

Controle de versão

A cada dia sistemas de versão concorrente vem sendo utilizados para os mais diversos fins. No passado era realidade apenas em grandes ambientes de desenvolvimento paralelo, onde literalmente dezenas de desenvolvedores demandavam acesso simultâneo aos mesmos arquivos, e ter um sistema de versão concorrente era imperativo para garantir adequadamente um ambiente de trabalho concorrente, e principalmente, garantir segurança desses dados, de forma que se um desenvolvedor interferisse negativamente no trabalho de outro, as mudanças em questão pudessem ser facilmente revertidas ao estado anterior.

Então o controle de versões é visto como uma extensão natural do processo de desenvolvimento, permitindo que se possa paralelizar o desenvolvimento de forma coerente e padronizada.

Hoje existem dezenas de opções de sistemas de versionamento de projetos, esses sistemas são conhecidos com SCM ou apenas VCS (Version Control System). Alguns sistemas VCS comerciais, mais conhecidos são:

• Clear Case
• Microsoft Team Foundation

E alguns sistemas de controle de versão livre, mais conhecidos são:

• CVS
• Subversion
• GIT

Outros sistemas menos conhecidos:

• Visual Source Safe
• PVCS
• SVK
• HG
• BZR
• Perforce

Temos como preferência utilizar sistemas open source e pelo conhecimento do CVS e do Subversion iremos basear os estudos e comparações nos dois sistemas.

O sistema aberto mais conhecido é o CVS, exatamente por existir a mais tempo, e ser a primeira implementação livre com um número de recursos que o tornasse viável a ser utilizado em todo tipo de ambiente, de qualquer porte, de projetos pequenos a gigantescos. O CVS é a opção de escolha mais comum, entre livres e comerciais. Ao menos por enquanto.

Subversion é uma ferramenta open-source de controle de versão (veja o tutorial sobre controle de versão de software para mais informações). Segue a licença de software livre nos moldes da licença Apache/BSD.

O projeto do Subversion iniciou em 2000 com a idéia de se construir um CVS melhor, isto é, mantendo o mesmo modelo de trabalho, mas consertando as falhas e limitações que o CVS apresenta. Desde então, vem atraindo uma comunidade cada vez maior de colaboradores e usuários.

O Subversion tem a maior parte das funcionalidades do CVS. De modo geral, a interface do Subversion segue à do CVS. Isto facilita a transição dos usuários do CVS para o Subversion.

Controle de Diretórios, Renomeações e Meta-Dados

Esta era uma das maiores reclamações sobre o CVS. Subversion não só controla a versão do conteúdo dos arquivos, mas também de diretórios, cópias, renomeações e meta-dados.

Operações Atômicas de commit

Um conjunto de modificações a serem realizadas num commit é aceito como um todo ou nenhuma alteração é feita. Não há a possibilidade que apenas uma parte das alterações seja aceita quando enviadas ao repositório tal como acontecia no CVS. Além disso, os números de revisão estão atrelados a cada operação de commit e não aos arquivos.

Opções de Acesso à Rede

Subversion foi projetado para uma camada abstrata de acesso ao repositório, o que permite a implementação de novos mecanismos de rede. Um dos mecanismos existentes usa o protocolo WebDAV/DeltaV baseado em HTTP através do Apache 2. A outra opção é o servidor dedicado svnserve como opção ao Apache, e que pode ser combinado ao ssh.

Arquivos Binários e de Texto Tratados Consistentemente

Outro grande problema bastante conhecido é que o CVS que não funciona tão bem com arquivos binários. Por outro lado, o Subversion usa um algoritmo de diferenciação binário que funciona de modo idêntico tanto para arquivos texto (legíveis por humanos) quanto para arquivos binários (ilegíveis para humanos).

Ramificações e Rotulações em Tempo Constante

O tempo das operações de ramificação (branching) e rotulação (tagging) é constante, e não depende do tamanho do projeto no repositório. Esse resultado é obtido através da forma de implementação do Subversion para essas operações, que é feita como uma operação de cópia que resulta em links, ocupando pouco espaço e um intervalo de tempo constante.

Uso mais Eficiente da Rede

O protocolo de rede usa a largura de banda eficientemente enviando as diferenças entre cliente/servidor e servidor/cliente sempre que possível, ao contrário do CVS que envia as diferenças do servidor ao cliente, mas não do cliente ao servidor.

A seguir, é apresentado um pequeno quadro comparativo entre o CVS e o Subversion (SVN). Ressaltamos que este quadro não representa uma comparação completa.

Funcionalidade	CVS	SVN
Commit Atômico	X	V
Renomeações e cópias de arquivos e diretórios	X	V
Rastreamento de Fusões (Merge)	P	PF
Permissões de Repositório	P	V
Documentação Disponível	V	V
Portabilidade	V	V
Open Source	V	V
Interfaces Gráficas	V	V
Suporta Grande Repositório	V	V

Legenda:

(V) Possui tal funcionalidade

(X) Não possui tal funcionalidade

(P) Atende parcialmente o requisito

(F) Existe previsão para implementação da funcionalidade no futuro

(A) Informações insuficientes para classificação

Automação de testes de desempenho

O teste de desempenho mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo. Este tipo de teste é importante para verificar a disponibilidade do sistema sobre situações em que existe um grande número de transações. Este é normalmente um requisito não funcional muito importante em aplicações comerciais.

O software mais utilizado chama-se JMeter e é uma das ferramentas desenvolvidas dentro do projeto Jakarta. Ele esta disponível em http://jakarta.apache.org/jmeter. O JMeter permite testar diferentes componentes de um ambiente servidor, como servidores HTTP, FTP e SGBD.

Um de seus atrativos é o fato de permitir a execução de plano de testes que podem ser configurados graficamente. Outro atrativo é conseguir realizar os testes de desempenho com clientes distribuídos. Isto é importante, pois utilizando várias máquinas clientes consegue-se simular carga de maneira mais próximo do ambiente de produção.

Uma vez que o JMeter é uma ferramenta Open Source e consegue realizar os testes de desempenho de maneira simples e robusta esta será a ferramenta a ser utilizada.

Automação de testes funcionais e de aceitação

Testes funcionais são aqueles que encaram o sistema a ser testado como uma função que mapeia um conjunto de valores de entrada em um conjunto de valores de saída sem se preocupar com a forma como esse mapeamento foi implementado.

Um teste de aceitação (ou Story Test, ou Customer Test) descreve um cenário (de sucesso ou não) com uma expectativa do cliente em relação à história ou funcionalidade. Como o nome sugere, ele ajuda a equipe a entender quando uma história ou funcionalidade está completa ou aceita.

Diversas ferramentas e frameworks têm surgido para auxiliar sua vida. Entre as mais conhecidas temos o Selenium e o Watir podem facilitar sua vida no teste de aplicações web.

Percebemos que teremos um problema ao utilizar o Selenium quando o projeto funciona apenas no navegador internet explorer. Isto ocorre, pois o Selenion IDE que é uma ferramenta que facilita a gravação dos scripts é um addin para o mozilla firefox e quando o sistema não funciona no navegador mozilla não é possível o utilizar.

Situação ideal: Ter uma aplicação que funciona em ambos os browsers, gravar os scripts no Selenium e realizar os teste utilizando os navegadores.

Situação alternativa: Para aplicações que funcionam somente no navegador internet explorer, o que nos deixa como melhor opção a utilização do Watir que possui como facilidade o aplicativo IE Developer Toolbar.

O Watir é opensource e com seus comandos e funções particulares permite então que possamos controlar os objetos HTML e JavaScript presentes na aplicação Web, simulando os cliques em links, botões e os demais campos. Watir tem sido usado para testes de sistemas, testes funcionais e teste de aceitação do usuário. Como seu próprio nome diz (Web Application Testing in Ruby),

Para o uso do Watir torna-se necessário a instalação do interpretador Ruby e do pacote que contém o Watir. O Watir não utiliza da técnica conhecida como Record/Playback, onde o arquiteto de testes grava o script através do movimento do mouse e teclado.

Os scripts são escritos mesmo “na unha”, portanto o recomendado é que o responsável pelo uso do Watir tenha algum conhecimento de lógica de programação e dos atributos das tags HTML. Esse conhecimento em desenvolvimento se torna importante, visto que, estamos falando de programação de scripts e para que possamos ter um produto final de qualidade, podem ser aplicados todos os conceitos e boas práticas de programação.

Existe um facilitador que é a instalação do aplicativo IE Developer Toolbar que se integra na barra de ferramentas do Internet Explorer facilitando na identificação dos atributos utilizados na automação.