A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Universidade de São Paulo

Apresentações semelhantes


Apresentação em tema: "Universidade de São Paulo"— Transcrição da apresentação:

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 Software de controle de Bilhetes Eletrônicos de Transporte (LPS-BET) Paula M. Donegan

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 verticais e horizontais
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 verticais e horizontais
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 Iteração 1 Apenas com as características do núcleo (Versão 1) Iteração 2 Versão 1 + características e variabilidades da aplicação de Fortaleza Iteração 3 Versão 2 + características e variabilidades da aplicação de Campo Grande Iteração 4 Versão 3 + características e variabilidades da aplicação de São Carlos Iteração 5 Versão 4 + todas as variabilidades + geração automática com um Gerador de Aplicação

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

9 Comparação de Requisitos
São Carlos Fortaleza Campo Grande Leitoras em ônibus (F1) Leitoras em ônibus e em terminais (F1) Integração temporal (F4) Não há integração temporal (F4) Tempo para integração: 90 minutos (F4) Tempo para integração: 60 minutos (F4) Sem restrição para quantidade de viagens de integração temporal (F4) Única integração temporal da viagem (F4) Não há terminais A entrada do ônibus em um terminal é feita por uma porta que dá acesso diretamente ao interior do ônibus, sem passar pela catraca (F5) Valor máximo de carga no cartão dependendo da categoria do cartão (F7) Não há valor máximo de carga para os cartões Desconto para alguns tipos de passageiros (F8) Desconto para alguns tipos de passageiros (F8, F9, F13) Desconto para alguns tipos de passageiros (F10, F11) Valor do desconto segue as seguintes categorias de passageiros: A) estudantes e B) empregados doméstica(o)s têm desconto de 50% sobre o valor da passagem; C) trabalhadores registrados têm 30% de desconto (F8) O vale-transporte operacional e gratuidade fornecem 100% de desconto (F8 e F9) A carteira de estudante permite o pagamento manual com 50% de desconto (F13) O cartão estudantil fornece 50% de desconto (F10) O cartão gratuidade fornece 100% de desconto (F11)

10 Casos de Uso - Resumido

11

12 Aquisição e Carga de Cartão
Rastreabilidade Subsistema Casos de Uso São Carlos Fortaleza Campo Grande Gerência Gerenciar Cartão F1, F4 F1 F1, F3, F4 Gerenciar Linha F12 F17 F18 Gerenciar Linha de Integração F4, F13 - F4, F19 Gerenciar Terminal F1, F5 Gerenciar Ônibus Gerenciar Validador F1, F2 Gerenciar Corrida Aquisição e Carga de Cartão Adquirir Cartão F9, F14 F7, F8, F9, F10, F12, F13 F8, F9, F10, F11, F12 Carregar Cartão F7 F11 F7, F13 Verificar Pagamento do Cartão F10 Verificar Tipo de Passageiro F8 F7, F8, F9, F10 Verificar Limite de Viagens F7, F8 Viagem Realizar Viagem F1, F2, F6, F16 F1, F2, F5, F19 F1, F2, F4, F5, F6, F22 Ler Cartão Verificar Situação do Cartão F2, F3 F2, F3, F4 Verificar Integração F4, F5 Verificar Quantidade de Viagens de Integração F4, F20 Registrar Corrida F12, F15, F16 F12, F18, F19 F19, F21, F22

13 Candidatos a Componentes Aspectuais
Caso de Uso Tipo de Requisito Motivo Gerenciar Cartão Funcional Incluído por 3 casos de uso (dois deles são núcleo) Gerenciar Limite Viagens Incluído por 2 casos de uso, mas depende do sistema da LPS (1 deles é opcional) Gerenciar Tipo Passageiro Incluído por 2 casos de uso, mas depende do sistema da LPS (1 é opcional) Gerenciar Política Desconto Incluído por 2 casos de uso (os dois são núcleo) Verificar Tipo Passageiro Verificar Situação do Cartão Autenticar Usuário Não-Funcional Estende 3 casos de uso (os três são opcionais) Ler Cartão Gerenciar Linha de Integração Estende 2 casos de uso (um deles é opcional)

14 Diagrama de Features Comuns

15 Diagrama de Features da LPS-BET

16

17 Features Adicionais dos sistemas BET
Fortaleza Campo Grande São Carlos Acesso Adicional Autent. Passageiro Forma de Integração - Terminal - Integração * Tempo * Linha de Integração * Número de Viagens de Integração Pagamento de Cartão Restrição de Cartões - Número de Cartões - Combinação de Cartões Empresas Usuárias Limite de Viagens

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

19

20

21 Componentes e Interfaces

22 Diagrama de Comunicação Parcial Realizar 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 Nova classe requerida Parte do diagrama de features
Parte do modelo de classes Devo colocar texto nas figuras do exemplo? Nova classe requerida

27 Componente composto LinhaTerminalMgr
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 Tem problema eu colocar essa figura mais completa aqui, diferente do paper em si? Por espaço lá?

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
FIM Dúvidas? Paula Donegan:


Carregar ppt "Universidade de São Paulo"

Apresentações semelhantes


Anúncios Google