Desenvolvimento Ágil

Motivação

Vários projetos de software terminam em fracasso ou não possuem a qualidade dexigida pelo cliente.
Como resposta a isso, surgiu o movimento ágil que tenta descobrir melhores maneiras de desenvolver
um software e de ajudar a outras pessoas a fazer o mesmo.

O desenvolvimento ágil segue o conjunto de '''valores''' abaixo:

• Indíviduos e interações mais importantes que processos e ferramentas
• Software funcionando mais importante que documentação compreensiva
• Colaboração com o cliente mais importante que negociação contratual
• Responder às mudanças mais importante que seguir um caminho a risca

OBS: Embora o lado direito seja valorizado, o lado esquerdo possui mais ênfase.

A partir desses valores, '''12 princípios''' foram indentificados:

• Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais
• Softwares funcionais são entregues frequentemente (semanas, ao invés de meses)
• Softwares funcionais são a principal medida de progresso do projeto
• Até mesmo mudanças tardias de escopo no projeto são bem-vindas
• Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores
• Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança
• Design do software deve prezar pela excelência técnica
• Simplicidade
• Rápida adaptação às mudanças
• Indivíduos e interações mais importantes do que processos e ferramentas
• Software funcional mais do que documentação extensa
• Colaboração com clientes mais importantes do que negociação de contratos
• Responder a mudanças mais importantes do que seguir um plano

Metodologias

Baseadas nos princípios e valores do movimento ágil surgiram metodologias:

• XP - Extreme Programming (Programação Extrema)
• Scrum
• FDD - Feature Driven Development (Desenvolvimento Orientado a Recurso)
• Etc ....

Extreme Programming

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Valores

• Comunicação
• Simplicidade
• Feedback
• Coragem
• Respeito

Princípios Básicos

• Feedback rápido
• Presumir simplicidade
• Mudanças incrementais
• Abraçar mudanças
• Trabalho de qualidade

Regras

Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

Planejamento

• Estórias são escritas
• Projeto divido em interações (Cada interação produz uma versão FUNCIONAL do sistema)
• Planejamento da interação inicia cada interação
• Planejamento da versão cria um cronograma (Normalmente cada interação = 2 a 3 semanas)
• Fazer releases pequenas e frequentes (Assim o cliente pode detectar erros antecipadamente)

Gerenciamento

• Dar ao time um ambiente de trabalho aberto e dedicado
• Atribuir um ritmo sustentável (SEM HORAS EXTRAS!)
• Um standup meeting (reunião em pé) inicia cada dia de trabalho
• A velocidade do projeto é medida
• Trocar pessoas de lugar (significa revezar uma parte do sistema - todos os programares devem passar por todas as partes do sistema)
• Consertar (modificar) o próprio XP para adequar a realidade do projeto / empresa

Desenho

• Simplicidade
• Escolha uma metáfora para representar o sistema
• Utilizar cartões CRC para sessões de desenho (Ajuda no desenho de classes - CRC = Classe Reponsabilidade e Colaboração)
• Criar soluções de ponta para descobrir respostas para as difíceis problemas técnicos ou de desenho.
• NENHUMA funcionalidade é adicionar antecipamente (Nada de "Vai que o cliente pode sprecisar um dia ...")
• Refatore o código quando e onde for possível (Refatorar = organizar o código-fonte)

Codificação

• Cliente deve estar sempre disponível (em local próximo de preferência)
• Códigos devem seguir padrões (Assim todos os programadores podem compreendê-los)
• Codificar o testes unitário primeiro (O teste guiará a implementação da classe)
• Toda a programação de produção deve ser feita em par (Um deve ser o instrutor e o outro o aprendiz)
• Uma integração deve ocorrer por vez para cada par de programadores
• Integrar o código sempre
• Configurar um computador dedicado para integração
• Utilizar posse coletiva (Qualquer programador pode contribuir com novas idéias para alterar ou adicionar novas funcionalidades ao código. Assim não existirão gargalos)

Testes

• Todo o código deve ter testes unitários
• Todo o código deve passar por testes unitários antes de passar para a produção
• Quando um bug (erro) é encontrado, um teste unitário deve ser criado para simular essa situação
• Testes de aceitação devem ser rodados com freqüência e a pontuação publicada

Noções de Caso de Uso

1. Introdução

Casos-de-uso são uma maneira popular de expressar requisitos de software. Eles são populares porque eles são práticos. O caso-de-uso preenche o espaço entre as necessidades do usuário e a funcionalidade do sistema através da descrição da intenção do usuárioe da resposta do sistema para cada interação entre os dois.

Um ator especifica um papel que pode ser assumido por uma pessoa, parte de um hardware ou um componente de software. Cada ator tem uma certa responsabilidade operacional imposta pelos processos e as regras de negócio dentro do domínio. Para dar conta de suas responsabilidades, um ator deve desempenhar um certo número de operações. Para isso, um ator quer essas operações seja facilitda por uma aplicação de software. A partir daí são definidos os correspondentes objetivos a serem preechidos pelo sistema. Esses objetivos nos levam às funcionalidades do sistema expressos através de casos-de-uso onde cada caso-de-uso é responsável por atingir um objetivo.

Na figura acima, por exemplo, o ator Balconista, no caso uma pessoa, tem como objetivo o pagamento de contas de Pacientes.

Para um objetivo ser alcançado, alguma ação deve tomada para alcança-lo. Para um caso-de-uso, isso é feito através de uma interação com o sistema. A descrição da interação de um caso-de-uso se divide um duas partes: um curso básico que descreve uma sequência principal de interação onde tudo da certo e um curso alternativo onde qualquer alternativa e interrupção do curso báscio de interação como partes opcionais e alternativas, recuperação de erro do negócio ou tratamento de falha.

2. Exemplo Simples de Caso-de-Uso

Caso-de-Uso: Tirar dinheiro de um caixa eletrônico

Curso Normal: ( Curso Básico )

1. O usuário introduz o cartão no caixa eletrônico

2. O caixa eletrônico propõe varias operações

3. O usuário aperta o botão ``saque''

4. O usuário escolhe a conta (ex.: ``conta corrente'')

5. O usuário entra a valor do saque

6. O usuário entra sua senha

7. O caixa eletrônico verifica a senha com o banco e o saldo da conta caixa eletrônico da o dinheiro para o usuário

8. O caixa eletrônico imprime um recibo

3. Padrão de Caso-de-Uso

Por questões de organização uma estrutura de documento deve ser usada para a descrição de casos-de-uso. Abaixo podemos ver um template de caso-de-uso utilizado pela PMV.

___________________________Descrição de Caso de Uso

Projeto: SIAR

Sub-Sistema:

Pacote: XXXXXX

Sub-Pacote: XXXXX

Nome do Caso de Uso: XXXXXXX

Analista: XXXXX

Data de Criação: dd/mm/aaaa

Versão: 1.0

Data de Última Alteração: dd/mm/aaaa

Descrição: XXXXXXXX

Função/Método: XXXXX.XXXXXXXX(XXX,XXXX,XXX)

Pre-Condição: XXXXXXXXXXXX

Curso Normal:

Cenário 1 (c1)

1. XXXXXX.

2. XXXXXX.

3. Se XXXXXX, XXXXXXX ( a1, a2 )

4. XXXXXX

5. Se XXXXXX, retorna a linha 3

Cenário 2 (c2)

1. XXXXXX

2. XXXXXX

3. Se XXXXX, XXXXXXX ( a2 )

4. Para cada XXXXXXXX, fazer até XXXXXXXXX

   1. XXXXXXXX

   2. XXXXXXXX

5. XXXXX

6. XXXXX

Curso Alternativo:

Cenário Alternativo 1 (a1)

1. XXXXXX.

2. XXXXXX

Cenário Alternativo 2 (a2)

1. XXXXXX.

2. XXXXXX

Restrições de Integridade:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

UML Prático: Uma Introdução para Desenvolvedores

Referência: http://dn.codegear.com/article/31863

Abstract: Esse tutorial faz uma introdução rápida da UML

O centro da solução de um problema orientado-a-objetos é a construção de um modelo. O modelo abstrai os detalhes de um determinado problema de um mundo real geralmente complicado. Várias ferramentas de modelagem carregam o padrão UML que significa Linguagem de Modelagem Unificada ( Unified Modeling Language ).

O propósito desse tutorial é o de apresentar características importantes da UML.

No centro da UML, existem os tipos de diagramas de modelagem, descritos aqui:

• Diagramas de Caso de Uso

• Diagramas de Classe

• Diagrama de Pacotes

• Diagrama de Sequência

• Diagramas de Estado

Qual a importância da UML ?

Vamos olhar para essa pergunta pelo ponto-de-vista do negócio de construção. Arquitetos projetam construções. Construtores usam o projeto para criar edifícios. Quanto mais complicada a construção, mais crítica é a comunicação entre o arquiteto e o contrutor. “Esquemas” são a linguagem gráfica padrão que tanto os arquitetos quanto os contrutores devem aprender como parte do negócio.

Escrever software não é muito diferente de construir um edifício. Quanto mais complicado o sistema, mais crítica é a comunicação entre todos envolvidos na criação e deployment do software. Na última década, a UML emergiu como uma linguagem esquemática de software para analistas, projetistas e programadores. É agora parte do negócio de software. A UML oferece, desde o analista de negócio ao projetista até o programador, um vocabulário comum para falarem sobre projeto de software.

A UML é aplicável a resolver problemas orientados a objeto. Qualquer um interessado em aprender UML deve estar familiarizado com a natureza da solução de um problema orientado-a-objeto. Tudo começa com a construção de um modelo. Um modelo é uma abstração de um determinado problema. O domínio é o mundo de onde o problema veio.

Modelos consistem em objetos que interagem enviando messagens uns ao outros. Pense em um objeto como algo “vivo”. Objetos possuem coisas que eles conhecem ( atributos ) e coisas que eles podem fazer ( comportamento ou operações ). Os valores dos atributos de um objeto determinam o seu estado.

Classes são os “esquemas” para objetos. Uma classe engloba atributos ( dados ) e comportamentos ( métodos ou funções ) em uma única entidade distinta. Objetos são instâncias de classes.

Diagramas de Caso de Uso

Diagramas de caso-de-uso descrevem o que um sistema faz do ponto-de-vista de um observador externo. A ênfase está em o que o sistema faz e não como ele faz.

Diagramas de caso-de-uso estão intimamente conectados a cenários. Um cenário é um exemplo do que acontece quando alguém interage com o sistema. Abaixo está um cenário para uma clínica médica.

“Um paciente chama a clínica para marcar uma consulta para um check-up anual. A recepcionista em encontra um tempo vago mais próximo no livro de consultas marcadas e agenda a consulta para essa vaga.”

Um caso-de-uso é um sumário de cenários para uma única tarefa ou objetivo. Um ator é quem ou o que inicia os eventos envolvidas nessa tarefa. Atores são simplesmente papéis que pessoas ou objetos desempenham. Na figura abaixo esta o caso-de-uso Marcação de Consulta da clínica médica. O ator é um Paciente. A conexão entre ator e caso-de-uso é uma associação comunicativa ( ou comunicação para abreviação ).

Atores são os bonecos. Casos-de-uso são ovais. Comunicações são as linhas que conectam o ator ao caso-de-uso. O diagrama de caso-de-uso é uma coleção de atores, casos-de-uso e suas comunicações. Nós colocamos Marcação de Consulta como parte de um diagrama com quatro atores e quatro casos-de-uso. Notem que um simples caso-de-uso pode ter múltiplos atores.

Diagramas de Caso-de-Uso são úteis em três áreas:

• Determinação de recursos ( requisitos ). Novos caso-de-usos geralmente geram novos requisitos a medida que o sistema é analisado e o projeto toma forma.

• Comunicações com clientes. A simplicidade da notaçãofaz com que o diagrama de casos-de-uso sejam uma boa maneira para os desenvolvedores se comunicarem com os clientes.

• Geração de casos-de-teste. A coleção de cenários para um caso-de-uso pode sugerir um conjunto de casos-de-teste para esses cenários.

Diagramas de Classe

O diagrama de classe oferece uma visão resumida de um sistema mostrando suas classes e os relacionamentos entre elas. Diagramas de classe são estáticos, ou seja, eles mostram o que interage mas não o que acontece quando interagem.

O diagrama de classe abaixo modela um pedido de um cliente para um catálogo de itens.A classe central é o Pedido. Associada a ela estão o Cliente fazendo a compra e o Pagamento. Um Pagamento pode ser de três tipos: Dinheiro, Cheque ou Crédito. O pedido contem DetalhesPedido, cada um associado a um Item.

A notação UML para uma classe é um retângulo dividido em três partes: nome da classe, atributos e operações. Nomes de classes abstratas como Pagamento estão em itálico, Relacionamentos entre classes são as linhas que as conectam.

Nosso diagrama de classes tem três tipos de relacionamentos:

• Associação – relacionamento entre duas instâncias de duas classes. Existe associação entre duas classes, se uma instância de uma classe deve saber sobre a outra para desempenhar uma tarefa. No diagrama, uma associação é uma conexão entre duas classes.

• Agregação – uma associação em que uma classe pertence a uma coleção. Um agregado tem um diamante em uma das extremidades para a parte que contém o todo. No nosso diagrama, Pedido tem uma coleção de DetalhesPedido.

• Generalização – uma conexão de herança indica que uma classe é superclasse da outra. A generalização tem um triângulo apontando para a super-classe. Pagamento é uma super-classe de Dinheiro, Cheque e Crédito.

Uma associação tem duas extremidades. Uma extremidade pode ter um papel para esclarecer a natureza da associação. Por exemplo, um DetalhesPedido é uma linha de item de um Pedido.

A seta de navegabilidade em uma associação mostra em qual direção a associação pode ser percorrida ou consultada. Um DetalhesPedido pode ser consultado sobre seu Item, mas o caminho inverso não pode ser feito. A seta permite que você saiba quem “possui” a associação implementada. Nesse caso, DetalhesPedido tem um Item. Associações sem setas de navagabilidade são interpretadas como bi-direcionais.

A multiplicidade de uma extremidade de associação é um número de possíveis instâncias de uma classe associadas uma única instância da outra extremidade. Multiplicidades são números ou uma faixa de números. No nosso exemplo, só pode haver um Cliente para cada Perdido mas um Cliente pode ter vários Pedidos.

A tabela abaixo mostra as multiplicidades mais comuns:

Multiplicidades	Significado
0..1	Zero ou uma instância. A notação n..m indica de n até m instâncias
0..* ou *	Não há limite no número de instâncias. (incluindo um)
1	Exatamente uma instância
1..*	Pelo menos uma instância

Todo diagrama de classes possui classes, associações e multiplicidades. Navegabilidade e papeis são itens opcionais que podem ser informados para propõsitos de claridade da explicação.

Diagramas de Pacotes

Para simplificar diagramas de classe, você pode agrupar as classes em pacotes.

Uma pacote é uma coleção de elementos UML logicamente relacionados. O diagrama abaixo mostra um modelo de negócio onde as classes estão agrupadas em pacotes.

Pacotes aparecem como retângulos com uma pequena aba no topo. O nome do pacote aparece na aba ou dentro do retângulo. A setas pontilhadas são dependências. Um pacote depende do outro se as mudanças no outro pacote implicam em mudanças no primeiro..

Diagramas de Sequência

Diagramas de classe mostram uma visão estática do modelo. Diagramas de interação são dinâmicos pois descrevem como os objetos colaboram entre si.

Um Diagrama de Sequência é um diagrama de interação que detalha como as operações ocorrem, ou seja, que mensagens são enviadas e quando. Diagramas de sequência são organizados de acordo com o tempo. O tempo progride a medida que você desce a página. Os objetos envolvidos na operação são listados da esquerda para a direita de acordo com quando eles tomam parte em alguma sequência da mensagem.

Abaixo está um diagrama de sequência para fazer a reserva de um hotel. O objeto que inicia a sequência de mensagens é a janela Reserva.

A janela de Reserva envia uma mensagem FazerReserva( ) para um objeto CadeiaHoteis. O objeto CadeiaHoteis envia uma mensagem FazerReserva( ) para um objeto Hotel. Se o Hotel tem quartos disponíveis, então ele faz a Reserva e a Confirmacao.

Cada linha vertical pontilhada é uma linha de vida e representa o tempo que um objeto existe. Cada seta é uma chamada a uma mensagem. Uma seta vai do emissor para o topo da barra de ativação da mensagem no linha de vida do receptor. A barra de ativação representa a duração da execução de uma mensagem.

No nosso diagrama, o Hotel faz uma chamada a ele próprio para determinar se um quarto está disponível. Se estiver, então o Hotel cria a Reserva e a Confirmacao. O asterisco nessa chamada significa interação ( para garantir que existe quarto disponível para cada dia de estadia no Hotel). A expressão entre colchetes, [ ], é a condição.

O digrama tem uma nota de esclarecimento, que é um texto dentro de retângulo com uma ponta dobrada. As notas podem ser inseridas dentro de qualquer tipo de diagrama UML.

Diagramas de Estado

Objetos têm comportamentos e estados. O estado de um objeto depende de sua condição e atividades atuais. O diagrama de estado mostra os possíveis estados de um objeto e suas transições que causam uma mudança de estado.

Nosso exemplo de diagrama modela a parte lógica de um sistema bancário on-line. Logar consiste em entrar com um número de seguridade social válido e um número de identificação pessoal para depois submeter a informação para validação.

Logar pode ser fatorado em quatro estados: Aquisição de SSN, Aquisição de PIN, Validação, e Rejeição. De cada estado vem um completo conjunto de transições que determinam o estado subsequente.

Estados são retângulos arredondados. Transições são setas que vão de um estado a outro. Eventos ou condições que disparam transições são escritas do lado das setas. Nosso diagrama tem duas auto-transições, uma em Aquisição de SSN e outra em Aquisição de PIN.

O estado inicial ( círculo preto ) é um estado que serve apenas para mostrar onde inicia a ação. Estados finais servem apenas para mostrar onde termina a ação.

A ação que ocorre como um resultado de um evento ou condição é expressada na forma /ação.

Enquanto estiver em seu estado Validação, o objeto não espera por um evento externo para disparar a transição. Ao invés disso, ele desempenha uma atividade. O resultado dessa atividade determina o estado subsequente.