desenvolvimento de software como serviço através do uso de ... · software como serviço (saas)...
TRANSCRIPT
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.