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.