Using Components for Rapid Distributed Software Development Alexander Repenning Andri Ioannidou Michele Payton Wenming Ye Jeremy Roschelle.

Apresentação em tema: "Using Components for Rapid Distributed Software Development Alexander Repenning Andri Ioannidou Michele Payton Wenming Ye Jeremy Roschelle."— Transcrição da apresentação:

1 Using Components for Rapid Distributed Software Development Alexander Repenning Andri Ioannidou Michele Payton Wenming Ye Jeremy Roschelle

2 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;

3 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.

4 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;

5 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.

6 Desenvolvimento Distribuído Estudo de Caso Projeto ESCOT (Educational Software Components of Tomorrow) mantido pelo US National Science Fundation. URL : www.escot.org;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á;

7 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?

8 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á;

9 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;

10 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;

11 Os Stakeholders

12 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.

13 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.

14 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 – gaps; Desenvolvedores podem facilmente acessar e criticar o HTML;

15 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;

16 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;

17 Fase 2: Implementação e Testes Componentes centrais de cada projeto remoto eram simulados e disponibilizados para outros times através de applets Java.

18 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 – wizards, 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;

19 Fase 2: Implementação e Testes Neste ponto, todos os componentes foram reunidos de maneira a produzir uma App completa.

20 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;

21 Ferramentas Algumas ferramentas foram citadas no artigo, dentre as quais: Geradoras de componentes AgentSheets 7 e Geometers Sketchpad. Ferramenta específica para executar as Apps ESCOT Builder Tool (mais tarde substituída pelo browser) Ambiente RAD CodeWarrior.

22 A Aplicação Final

23 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);

24 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 stakeholders; O uso de componentes (JavaBeans) permitiu maior flexibilidade – JDKs, IDEs, aplicativos e plataformas – aos times remotos; O lado negativo é que foram encontradas discrepâncias entre diferentes usos de JVMs – o que resultou na adição de testes;

25 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?

26 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.