Desenvolvimento de Software como Serviço através do uso de Metodologias Ágeis Regis Pires Magalhães (IFPI), Nécio de Lima Veras (IFCE)
Desenvolvimento de Software como Serviço através do uso de Metodologias Ágeis
Regis Pires Magalhães (IFPI), Nécio de Lima Veras (IFCE)
Agenda
• Introdução• Processos de Desenvolvimento• Arquitetura Orientada a Serviço (SOA)• Computação em Nuvem• Software como Serviço (SaaS)• Arquitetura Modelo-Visão-Controlador (MVC)• Testes• Integração Contínua• Implantação (Deploy) da Aplicação• Uso de sistemas de controle de versão
3
Introdução Sistemas computacionais estão em todo lugar
Qualidade é um item obrigatório Conceito atual
Computação em Nuvem
5
Introdução Engenharia de Software
Meta: criar software de qualidade com melhor custo-benefício Envolve Processos de Software (“Receita de bolo” para atingir a
meta) Geralmente aumenta o tempo de entrega do sistema Métodos Ágeis Processos menos prescritivos Desenvolvimento incremental do sistema (pequenas entregas)
6
Introdução Na indústria de software moderna demanda-se o
desenvolvimento de sistemas em menos tempo e com qualidade superior Alguns meios: Métodos Ágeis Testes (qualidade) Ferramentas de Suporte (ferramentas para controle de versão, IDE’s e
frameworks de desenvolvimento) Arquitetura MVC (Model-View-Controller) Implantação (deployment) das aplicações diretamente na nuvem
7
Produtos de software
Surge de ideias conceituais e reajustáveis; É intangível; Possui escopo variável; É dotado de incertezas constantes; Difícil visualização do produto final. Mas como obter um produto de software
com qualidade diante de todas estas peculiaridades?
10
Engenharia de software
A ideia foi incluir a disciplina de engenharia no desenvolvimento de software;
A E.S. engloba três elementos fundamentais:
11
Processos de desenvolvimento
Processos para construção de um software são como conjuntos de passos que irão trabalhar de forma ampla definições, desenvolvimento e manutenção;
São compreendidos por Paradigmas da Engenharia de Software ou Modelos de Ciclo de Vida de Software [Pressman 2005];
12
Evolução do modelo
Notou-se que quando o cliente visualiza um protótipo ele consegue entender melhor o que quer;
Isso fez com que fossem combinados:▫ O modelo Waterfall + Protótipos;▫ Existiria uma sequência de 4 fases até atingir um
protótipo mais apurado em relação ao anterior.
Eis que surge o modelo Espiral.
14
Interseção entre ambos os modelo?
Longo período de tempo para o desenvolvimento; Volume muito grande de documentação e
planejamento; Fases maiores ainda => Big Design Up Front
(BDUF); E agora, para onde vamos?
16
Agilidade Um grupo em fevereiro de 2001, chamado de Agile Alliance,
começou a descobrir maneiras melhores e mais leves de desenvolver software valorizando:
● pessoas e interações ao invés de processos e ferramentas;
● softwares funcionando no lugar de documentações abrangentes;
● colaborações com clientes do que negociações de contratos e respostas à mudanças por planos fechados.
Esses valores originaram o Manifesto Ágil com outros DOZE princípios que regem a filosofia de criar softwares com agilidade [Beck 2001].
17
Agilidade
O modelo é baseado em ● mudanças abrangentes e;● melhoria contínua de um protótipo incompleto;
Algumas práticas são enfatizadas tais como:● Test-Driven Development (TDD);● Test-Driven Behavior (BDD)
● User Stories;● Integração Contínua;● Dentre outras...
18
Contraste com os outros dois modelos
“É tão rápido que novas versões são disponibilizadas ao cliente a cada duas
semanas e novos recursos são adicionados continuamente ao mesmo protótipo até que
o cliente esteja satisfeito” [Fox e Patterson 2012].
19
Arquitetura Orientada a Serviço (SOA) SOA é uma arquitetura de software onde todos os
componentes são projetados para virarem serviços;
Os componentes de uma aplicação devem atuar como serviços interoperáveis e podem ser usados de forma independente e/ou recombinados com outras aplicações;
Uma implementação contrária a essa ideia é conhecida como “software silo”;
21
Arquitetura de uma livraria com software silo
Perceba:Os acessos aos
dados;Uma API externa
única contendo todos os subsistemas.
23
Arquitetura de uma livraria com SOA
PercebaSeparação e
independência de subsistemas;
Bases separadas por contextos;
Fatias verticais de camadas;
Fatias conectadas por serviços;
Reusabilidade.
24
Computação em Nuvem
• SOA está nos fundamentos de Computação em Nuvem.
• Provê infra-estrutura composta de:(i) Comunicação realizada através da Internet; (ii) Escalabilidade para lidar com flutuações na demanda, atendendo rapidamente ao crescimento do número de usuários; (iii) Confiabilidade para que o serviço e a comunicação estejam continuamente disponíveis.
26
Clusters• Antes:
▫ servidores de custo elevado mais confiáveis.▫ É mais fácil lidar com poucos servidores do que com
muitos computadores com menos recursos.• Clusters
▫ Permitiram a interligação de computadores de baixo custo.
▫ Vantagens:● mais escaláveis;● distribuição de software facilitada (uso de máquinas
virtuais);● mais confiáveis devido ao uso de redundância;● baixo custo do hardware;● distribuição geográfica dificulta indisponibilidade do
serviço.
27
Economia de escala
•Custos menores por máquina e de pessoal;
•Melhor aproveitamento do poder computacional de cada máquina.
28
Utility Computing• Serviço de nuvem pública capaz de oferecer poder
de processamento, armazenamento e comunicação a centavos por hora [Armbrust et al. 2010].
• Recursos pagos pelo uso (pay-as-you-go).▫ semelhante a serviços de distribuição de água, luz e
telefonia.• Objetivo:
▫ Fornecer armazenamento, CPUs e largura de banda como “mercadoria”, através de provedores especializados com um baixo custo por unidade utilizada [Sousa et al. 2010].
29
Utility Computing
• Usuários não se preocupam com:▫ Escalabilidade;▫ Backups.
• Exemplos: Amazon Elastic Compute Cloud (EC2), Google App Engine e Microsoft Azure.
30
Utility Computing – Farmville
• Serviço Amazon Elastic Compute Cloud (EC2).• 4 dias - 1 milhão de jogadores• 9 meses - 75 milhões de jogadores
31
Software como Serviço (SaaS)
• Fornece softwares e dados com propósitos específicos.
• Softwares ficam acessíveis a partir de vários dispositivos.
• Não exige instalação e execução de código binário na máquina cliente.
• Desenvolvedores focam em inovação e não na infra-estrutura [Sousa et. al. 2009].
34
Software como Serviço (SaaS)
• Disponibilidade em qualquer lugar e momento.• Atualizações transparentes para os usuários.
• Exemplos:▫ Aplicações Web relacionadas a busca, redes sociais
e vídeos.
35
Vantagens [Fox e Patterson 2012]• Não é preciso instalar a aplicação, nem se preocupar
com hardware ou sistema operacional;• Dados armazenados e gerenciados pelo próprio serviço.• Ambiente propício ao compartilhamento, edição e
manipulação coletiva dos dados.• Software servidor em ambiente controlado pelo
desenvolvedor.• Possibilidade de lançar versões de testes para parte dos
usuários.• Atualizações mais fáceis e freqüentes de hardware e
software.• Evita a pirataria.• Cobrança periódica e/ou pelo uso.
36
Crescimento de SaaS
• As vantagens impulsionam o rápido crescimento de SaaS.
• Versões SaaS para softwares tradicionais:▫ Microsoft Office 365
37
Desvantagens
• Necessidade de boa conexão com a Internet▫ Trabalho online
• Versão offline que sincroniza com versão online, acrescenta complexidade ao software.
38
Frameworks para desenvolvimento de SaaS• Alguns frameworks foram especificamente concebidos
para facilitar o desenvolvimento através de metodologias Ágeis.
• Alinham-se ao ciclo de vida ágil.• Aplicações podem ser facilmente disponibilizadas em
modelos de PaaS ou mesmo IaaS.• Exemplos:
▫ Play Framework▫ VRaptor▫ Grails▫ Django▫ Ruby on Rails▫ etc.
39
Testes
“A grande maioria das pessoas já teve alguma experiência com um software que não funcionou
como esperado. Softwares que não funcionam corretamente podem levar a muitos problemas,
incluindo financeiro, tempo e reputação das empresas. Podendo, inclusive, chegar a influenciar na integridade das pessoas”
[ISTQB 2011].
42
Testes Podemos associar a qualidade de um software à
quantidade de falhas percebidas no mesmo O teste de software ajuda a medir e/ou garantir essa
qualidade
Níveis de Teste Unidade (componente) Integração (interface entre componentes) Sistema (comportamento) Aceitação (apropriado para uso)
43
Testes Métodos de Testes;
No contexto de testes automáticos se sobressaem duas abordagens: TDD (Testing-Driven Development) ou Desenvolvimento
dirigido por testes
BDD (Behavior-Driven Design) ou Projeto guiado por comportamento
44
Testes Passo 1: Cria-se o teste! Mesmo SEM a classe principal.
47
public class TestaSorteio {
private Sorteio sorteio;
@Beforepublic void setUp() throws Exception {
sorteio = new Sorteio();}
@Testpublic void testTotalParticipantes() {
sorteio.setTotal(200);assertEquals(200, sorteio.getTotalParticipantes() );
}}
Testes Passo 2: Tenta-se executar o teste, mas o mesmo não funcionará porque o
código está incompleto.
48
Testes Passo 3: Cria os códigos de maneira que ele faça o teste funcionar.
49
public class Sorteio {
int total;
public void setTotal(int total){
}
public int getTotal(){return 200;
}
}
Perceba que o código
funcionará apenas para esse teste
Testes Passo 5: Refatora-se o código implementado de maneira que ele funcione
agora para outros testes.
51
public class Sorteio {
int total;
public void setTotal(int total){this.total = total;
}
public int getTotal(){return total;
}
}
Testes de comportamento Sobre BDD podemos fazer as seguintes considerações [Fox e
Patterson 2012]:
BDD faz perguntas sobre comportamentos antes e durante o desenvolvimento;
Requisitos são escritos como estórias de usuários.
BDD se concentra no comportamento da aplicação versus a implementação da aplicação e os testes são conduzidos utilizando TDD.
53
BDD – Estória 1 Uma narrativa simples: uma confirmação de inscrição para o ENUCOMP
faz o participante concorrer a um sorteio.
58
Integração contínua
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia.
Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível.
Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.”
Martin Fowler
63
Integração contínua
• Cada commit no servidor de integração contínua realiza um build da aplicação e executa todos os testes.
• Vantagem: Feedback instantâneo.• Após o processo bem sucedido de integração
contínua a aplicação está pronta para implantação no servidor de produção.
• Ferramentas:▫ CruiseControl, Hudson, Jenkins, Bamboo,
BuildMaster, AnthillPro e Teamcity.
64
Implantação (deploy)
• O processo de implantação é todo o conjunto de atividades necessárias para que o software esteja disponível para o cliente.
• O momento para a realização desse processo vai depender dos acordos feitos entre o desenvolvedor e o cliente.
66
Implantação (deploy)
● Basicamente três ambientes são bastante utilizados pela comunidade:● Desenvolvimento: Desenvolvida● Homologação: Testada● Produção : Podemos visualizar funcionando
67
Heroku
PaaS que permite fazer deploy automático da aplicação Utiliza GIT para enviar a aplicação para a nuvem. É gratuito com um determinado limite (vamos utilizar esse
limite) Bem simples para fazer deploy de aplicações com Play, Rails
e outros frameworks…
68
GIT: Comandos
git add .
git commit -m “Minha Mensagem do Commit”
git pull
git push origin master
Adicionando arquivos (que foram modificados ou arquivos novos)
Comitando as suas modificações
Recebendo as atualizações
Enviando as suas alterações para o origin (remoto)
70
Conclusão72
● Engenharia de software cada vez mais focada na qualidade e eficiência do software.
● Buscamos também rapidez na entrega.● Metodologias Ágeis aliam esses fatores.● A Internet revoluciona o modo como o software é feito e distribuído.
Conclusão● O modelo de SaaS e a arquitetura MVC viabilizam o
desenvolvimento de software mais dinâmico, colaborativo, eficiente e com feedback do usuário.
● Os testes de software e ambientes de integração contínua asseguram a qualidade do software de forma automatizada.
● Sistemas de controle de versão e modelos de fluxos de trabalho facilitam o desenvolvimento em equipe e possibilitam um gerenciamento mais efetivo sobre as modificações ocorridas no software.
73
Referências74
● Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., and Zaharia, M. (2010). “A view of cloud computing”. Commun. ACM, 53(4):50–58.
● Beck, K., et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. http://agilemanifesto.org/. Acessado em 18 de agosto de 2012.
● Fox, A., Patterson, D. (2012). “Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing”, Alpha Edition. Strawberry Canyon LLC, 2012.
● Hoelzle, U. and Barroso, L. A. (2009). “The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines”. Morgan and Claypool Publishers, 1st edition.
● ISTQB. (2011). Certified Tester Foundation Level Syllabus, version 2011.
● Pressman, R. S. (2005). “Software engineering: a practitioner’s approach”, 6 ed. New York: MacGraw-Hill, 2005.
● Serman, D. V. (2010). “Orientação a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a serviços”. JISTEM: Journal of Information Systems and Technology Management, Sin mes, 619-638.
● Sousa, F. R. C., Moreira, L. O. e Machado, J. C. (2009). “Computação em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios”. In: Santos Neto, P. (Org.). III Escola Regional de Computação Ceará - Maranhão - Piauí, ERCEMAPI 2009, 1 ed. SBC, Piauí.
● Sousa, F. R. C., Moreira, L. O., Macedo, J. A. F. e Machado, J. C. (2010). “Gerenciamento de Dados em Nuvem: Conceitos, Sistemas e Desafios”. In: XXV Simpósio Brasileiro de Banco de Dados, 2010, Belo Horizonte. SBBD 2010.