using components for rapid distributed software development alexander repenning andri ioannidou...
Post on 16-Apr-2015
109 Views
Preview:
TRANSCRIPT
Using Components for RapidDistributed Software Development
Alexander Repenning
Andri Ioannidou
Michele Payton
Wenming Ye
Jeremy Roschelle
Estrutura de Tópicos
Introdução; Componentes de software; Estudo de caso: Projeto ESCOT;
Características gerais; Metas a serem atingidas; Evolução de uma aplicação;
Processo CORD e suas fases; Ferramentas; Conclusões; Referências Bibliográficas;
Introdução
É ainda difícil produzir software de confiança, fácil de usar e de manter, dentro do prazo negociado 1; Evolução do desenvolvimento vs. disciplinas de
engenharia; Projetos centralizados e distribuídos.
Além disso, pequenos sistemas de software altamente específicos estão em crescente demanda; Requer uma abordagem diferente de desenvolvimento se
comparado ao dos grandes sistemas monolíticos. Pequenos times, ciclos menores e rápidos, estilo agressivo.
O quê fazer?
Com o advento da programação orientada a objetos, os desenvolvedores foram capazes de lidar com diversos problemas com um certo grau de sucesso;
No entanto, uma outra conduta bastante conhecida e recomendada por especialistas no projeto de sistemas em todo o mundo é o desenvolvimento baseado em componentes 2; Favorece decomposição, comunicação e
compreensão do problema;
Componentes de Software
O quê? São unidades de software altamente reutilizáveis,
dotadas de uma interface bem definida; Interconexões – evoluindo para sistemas de
software completos 3; Sustentam práticas de engenharia modular 4; Reduzem a complexidade do desenvolvimento; Todos preferem reutilizar a recriar 5; Ex: JavaBeans.
Desenvolvimento Distribuído
Estudo de Caso Projeto ESCOT (Educational Software Components
of Tomorrow) mantido pelo US National Science Fundation.
URL : www.escot.org; Biblioteca digital contendo softwares educacionais
(Apps) relacionados ao ensino da matemática e publicados na Web;
Estudantes do ensino médio interagem com o sistema; O web site coloca um novo problema a cada semana e
os problemas se relacionam com o tema do mês; Stakeholders geograficamente distribuídos nos Estados
Unidos e no Canadá;
Desenvolvimento Distribuído
Estudo de Caso Contexto baseava-se na criação de uma aplicação
focando geometria e estudo das probabilidades. “Se lançarmos dardos aleatoriamente em dois
círculos concêntricos, qual a probabilidade de acertarmos o menor círculo?”
Projeto ESCOT
Metas a serem atingidas: disponibilização de uma coleção de componentes e
de aplicações relacionados a produção de software educacionais;
explorar o ambiente distribuído e suas nuances na produção e entrega de sistemas completos de software rapidamente;
auferir novos colaboradores (partners) sobretudo no Canadá;
Projeto ESCOT
O Processo de desenvolvimento CORD (Component-Oriented Rapid Development); Duas fases macro:
análise e design (Fase1) e implementação e testes (Fase2).
Características: análise de design centralizados
com base nos requisitos, são gerados os “application mockups” além de especificações de interoperabilidade.
emprega o conceito de paralelismo - threads (subconjuntos de stakeholders) que trabalham de forma independente na produção de componentes pré-estabelecidos;
granularidade depende dos times e dos componentes;
O Processo CORD
Características (cont.): coordenação no desenvolvimento distribuído
Os componentes são produzidos e montados através de builds regulares;
foco no desenvolvimento de componentes Diversidade de times utilizando diferentes ferramentas e
plataformas no desenvolvimento; Flexibilidade na aquisição de componentes off-the-shelf; Natureza dos componentes sugerem um conjunto de tarefas
relativamente pequenas, altamente paralelas e interativas; o desenvolvimento é independente de plataforma
JavaBeans; assemelha-se com XP 6;
paralelismo e janelas de tempo curtas;
Os Stakeholders
Fase 1: Análise e Design
Brainstorming e as chamadas “mídias de baixa fidelidade” Encontro face-a-face inicial visando resolver
assuntos como: definição de papéis e distribuição de tarefas, design dos componentes pertinentes ao problema e assuntos relacionados a conexão entre os mesmos - interoperabilidade;
Elaboração de diversos mockups em rascunhos de textos e de imagens no papel;
Escolha de um mockup adequado entre os que foram apresentados.
Exemplo - Mockup
Três Grupos de Componentes: simulação (topo); botões; planilha contendo
dados;
A aplicação permite lançar dardos aleatórios e calcula a probabilidade desses dardos acertarem o centro do círculo.
Fase 1: Análise e Design
Formalizando o design com mockups em HTML Os esboços, textos e imagens do mockup inicial são
então mapeados para documentos HTML em uma representação mais adequada e formal;
Grupos de stakeholders podem engatilhar discussões de design que não foram exploradas no mockup anterior – gap’s;
Desenvolvedores podem facilmente acessar e criticar o HTML;
Exemplo – Mockup HTML
Os times agora poderiam dar início à implementação dos seus componentes;
Outros membros do time podiam com facilidade acessar e criticar o HTML relacionado a App;
Fase 2: Implementação e Testes
Transição de um ambiente de operação centralizado para um distribuído Os times agora trabalham de maneira paralela,
independente, geograficamente dispersa, sob um escopo local;
Vale lembrar ainda que a seleção dos times é feita sobretudo com base nos grupos de componentes encontrados na fase inicial – funcionalidades;
Uso de geradores de componentes e ferramentas de simulação para certificar “componentes centrais”;
Fase 2: Implementação e Testes
Componentes centrais de cada projeto remoto eram simulados e disponibilizados para outros times através de applets Java.
Fase 2: Implementação e Testes
Montagem dos componentes Os componentes eram conectados através de
eventos e valores; Algumas ferramentas permitiam que a montagem
feita pelos desenvolvedores fosse efetuada visualmente – wizard’s, ambientes RAD;
No entanto, alguns arranjos mais complexos necessitavam de alguns scripts de apoio;
Questões de incompatibilidade entre componentes gerados eram resolvidas neste ponto;
Fase 2: Implementação e Testes
Neste ponto, todos os componentes foram reunidos de maneira a produzir uma App completa.
Fase 2: Implementação e Testes
Coleções de componentes Utilização e gerenciamento de repositórios; Foi feita uma coleta de use stories de componentes;
Quem utilizou? Que contexto e como? Houve sucesso? Caso contrário, que modificações? Use stories eram compartilhadas no formato de texto.
As use stories dos componentes eram repassadas para o component framework coordinator;
E depois repassadas para todos os stakeholders;
Ferramentas
Algumas ferramentas foram citadas no artigo, dentre as quais: Geradoras de componentes
AgentSheets 7 e Geometer’s Sketchpad. Ferramenta específica para executar as App’s
ESCOT Builder Tool (mais tarde substituída pelo browser)
Ambiente RAD CodeWarrior.
A Aplicação Final
Entrega e Utilização
Antes que qualquer App fosse liberada, o MathForum realizou testes de aprovação; Testes Formais
Unidades de código presentes no repositório (performance, integração, compatibilidade, usabilidade, entre outros)
Testes Não-Formais Testes funcionais de modo geral (input-output);
Conclusão do Artigo
O processo CORD foi apropriado no domínio de aplicações educacionais; Denota um estilo “agressivo” no escalonamento; Acentuado paralelismo entre todos os stakeholder’s;
O uso de componentes (JavaBeans) permitiu maior flexibilidade – JDK’s, IDE’s, aplicativos e plataformas – aos times remotos;
O lado negativo é que foram encontradas discrepâncias entre diferentes usos de JVM’s – o que resultou na adição de testes;
Conclusão Pessoal
Desenvolvimento baseado em componentes é adequado para ambientes de desenvolvimento distribuídos; Decomposição, independência, flexibilidade;
Design incremental on-line favorece uma maior integração entre os times e controle da complexidade;
Desenvolvimento de componentes vs. Janelas de tempo tão pequenas?
Referências Bibliográficas
1. B.Boehm and V.R. Basili, “Gaining Intellectual Control of Software Development”, Computer, vol.33, no. 5, May 2000, pp.27-33.
2. M.D. McIlroy, “Mass Produced Software Components,” Software Engineering, P. Naur and B. Randell, eds., NATO Scientific Affairs Division, Garmisch, Ger-many, 1968, pp. 138–155. B.Boehm and V.R. Basili, “Gaining Intellectual Control of Software Development”, Computer, vol.33, no. 5, May 2000, pp.27-33.
3. I. Jacobson, M. Griss, and P. Jonsson, Software Reuse: Architecture, Process, and Organization for Business Success, ACM Press, New York, 1997.
4. J. Udell, “Componentware,” Byte, May 1994, pp. 46–56.5. H.A. Simon, The Sciences of the Artificial, 2nd edition, MIT Press, Cambridge,
Mass., 1981.6. K. Beck, “Embracing Change with Extreme Programming,” Computer, vol. 32,
no. 10, Oct. 1999, pp. 70–77.7. A. Repenning and A. Ioannidou, “Behavior Processors: Layers between End-
Users and Java Virtual Machines,” Proc. 1997 IEEE Symp. Visual Languages, IEEE CS Press, Piscataway, N.J., 1997, pp. 402–409.
top related