Using Components for Rapid
Distributed 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


Ferramenta específica para executar as App’s


AgentSheets 7 e Geometer’s Sketchpad.
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.
2.
3.
4.
5.
6.
7.
B.Boehm and V.R. Basili, “Gaining Intellectual Control of Software
Development”, Computer, vol.33, no. 5, May 2000, pp.27-33.
M.D. McIlroy, “Mass Produced Software Components,” Software Engineering,
P. Naur and B. Randell, eds., NATO Scientific Affairs Division, Garmisch, Germany, 1968, pp. 138–155. B.Boehm and V.R. Basili, “Gaining Intellectual
Control of Software Development”, Computer, vol.33, no. 5, May 2000, pp.2733.
I. Jacobson, M. Griss, and P. Jonsson, Software Reuse: Architecture, Process,
and Organization for Business Success, ACM Press, New York, 1997.
J. Udell, “Componentware,” Byte, May 1994, pp. 46–56.
H.A. Simon, The Sciences of the Artificial, 2nd edition, MIT Press, Cambridge,
Mass., 1981.
K. Beck, “Embracing Change with Extreme Programming,” Computer, vol. 32,
no. 10, Oct. 1999, pp. 70–77.
A. Repenning and A. Ioannidou, “Behavior Processors: Layers between EndUsers and Java Virtual Machines,” Proc. 1997 IEEE Symp. Visual Languages,
IEEE CS Press, Piscataway, N.J., 1997, pp. 402–409.
Download

Using Components