Linha de Produtos de Software de controle de Bilhetes Eletrônicos de Transporte (LPS-BET)

1. Paula M. Donegan donegan@icmc.usp.br Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Linha de Produtos de Softwarede controle de Bilhetes Eletrônicos de Transporte(LPS-BET)

2. Tópicos • LPS-BET • Requisitos • Casos de Uso • Diagrama de Features • Modelo Conceitual • Arquitetura da LPS-BET • Componentes e Interfaces • Especificação de Interfaces • Composição de Componentes

3. LPS-BET • Controle de Bilhetes Eletrônicos para Transporte municipal • Gerência de dados de passageiros, cartões, linhas, ônibus e viagens • Validador no ônibus lê um cartão e se comunica com o sistema central para debitar a passagem • Pode haver um sistema de integração de ônibus para o passageiro pagar uma única passagem fazendo várias viagens • Análise de 3 sistemas BET: • Fortaleza (CE) • São Carlos (SP) • Campo Grande (MS)

4. Processo de Desenvolvimento • Começar com a análise de domínio • Então existem 2 alternativas: 1) Elaborar o projeto do domínio inteiro e implementar em seguida (em uma versão ou em vários incrementos) 2) Projetar e implementar a LPS em uma versão apenas com as características básicas e então incrementar o projeto e a implementação com subgrupos de variabilidades opcionais e alternativas

5. Incrementos de LPSs Incrementos verticais e horizontais • Incrementos Horizontais • Subgrupo de características (features) que atendem a uma aplicação específica mas que não contém necessariamente todas as variabilidades de cada característica incluída

6. Incrementos de LPSs Incrementos verticais e horizontais • Incrementos Verticais • Implementam todas as variabilidades de um subgrupo de características escolhidas, mas que não necessariamente produzem uma aplicação específica

7. Desenvolvimento da LPS-BET • Consideramos importante ter um aplicação completa inicialmente: • Opção de usar ciclos iterativos horizontais gerando uma aplicação em cada incremento

8. Requisitos do sistema BET de Fortaleza Requisitos do sistema BET de Campo Grande Requisitos do sistema BET de São Carlos Requisitos

9. Comparação de Requisitos

10. Casos de Uso - Resumido

12. Rastreabilidade

13. Candidatos a Componentes Aspectuais

14. Diagrama de Features Comuns

15. Diagrama de Features da LPS-BET

17. Features Adicionais dos sistemas BET

18. Diagrama de Seqüência de Sistema - Realizar Viagem

21. Componentes e Interfaces

22. Diagrama de Comunicação ParcialRealizar Viagem

23. Especificação de Interfaces

24. Diagrama de Estados do subsistema do Ônibus

25. Decisões de Projeto para Features da LPS • Como decisões de projeto são influenciadas por: • Decisões tomadas relacionadas ao processo adotado de desenvolvimento da LPS • Tipo do componente (caixa preta ou caixa branca) • Forma de composição (manual ou automatizado) • Features (características) • Formas de Integração: usa novas classes • Pagamento Cartão: usa subclasses (com novos atributos e métodos)

26. Feature: Terminal Parte do diagrama de features Parte do modelo de classes Nova classe requerida

27. Feature: Terminal • Sem acesso interno à implementação dos componentes desenvolvidos • LinhaMgr é reusado sem alteração • Versão de Fortaleza: Componente composto LinhaTerminalMgr

28. Feature: Linha de Integração Nova classe requerida Parte do diagrama de features Parte do modelo de classes

29. Feature: Linha de Integração • LinhaTerminalMgr desenvolvido para Fortaleza é reusado • Versão de Campo Grande: Componente composto LinhaTerminalIntegraçãoMgr

30. Feature: Linha de Integração • LinhaMgr é reusado • LinhaIntegradaMgr desenvolvido para Campo Grande é reusado • Versão de São Carlos: Componente composto LinhaIntegraçãoMgr

31. Feature: Pagamento Cartão Parte do diagrama de features • Pontos de variação nas classes TipoPassageiro e Pagamento Cartão • Alterando atributos e operações dessas classes (não necessário inserir uma nova classe no modelo)

32. Feature: Pagamento Cartão Opção 1: Usar classes parametrizadas Opção 2: Usar classes com pontos de variação e separar a feature Pagamento Cartão em um novo componente chamado PagamentoMgr • Separação de interesses e componentes caixa-preta

33. Feature: Pagamento Cartão Parte do modelo de classes • Ambas as classes permanecem em um componente pois possuem o mesmo interesse e são sempre usadas juntas Novos atributos requeridos

34. Feature: Pagamento Cartão

35. Features: Pagamento Cartão • CartaoMgr é reusado sem alteração • Versão de Fortaleza: Componente composto CartaoPgtoCartaoMgr

36. Componentes e Interfaces • Versão de Fortaleza:

37. Componentes e Interfaces • Versão de Campo Grande:

38. Componentes e Interfaces • Versão de São Carlos:

39. Usando um Gerador de Código • Lista de features: esboço inicial da AML • Componentes Caixa-Preta: • Gerador age como um configurador • Começa com a arquitetura básica e substitui/inclui componentes necessários e gera “glue-code” para composição de componentes • Componentes Caixa-Branca: • Gerador realiza mudanças dentro de cada componente gerando classes adicionais e modificando outros elementos dentro desses componentes • O gerador fica bem mais complexo e atua como um compositor

40. Usando um Gerador de Código (II) • Automatizar o processo de composição influencia no projeto e no momento da introdução da automação na LPS • Se automação é usada a partir da primeira versão • Influencia no projeto de novas versões da LPS • Cada nova iteração horizontal requer retrabalho considerável no gerador • Pretendemos usar o Gerador de Aplicação Configurável Captor desenvolvido pelo noso grupo de pesquisa

41. Paula Donegan: donegan@icmc.usp.br FIMDúvidas?