DIAGRAMAS DE COLABORAÇÃO

SUMÁRIO

1.        INTRODUÇÃO        

2.        ARTEFATOS DESENVOLVIDOS        

2.1.        CONSIDERAÇÕES INICIAIS        

2.2.        DIAGRAMAS DE COLABORAÇÃO        

2.2.1.        liberarSaida(codigoGizmo, codigoAPSaída)        

2.2.2.        informarPassagemVeículo()        

2.2.3.        adicionarProprietátio(dadosPropriet)        

2.2.4.        adicionarVeículo(placa, numeroDeEixos)        

2.2.5.        adicionarGizmo(codigo, modelo)        

2.2.6.        realizarPagamento(valorFornecido)        

3.        CONCLUSÃO        

1. INTRODUÇÃO

O presente trabalho tem por objetivo desenvolver alguns diagramas de colaboração (ou comunicação) para o  Sistema Passe-Livre, um sistema automático de cobrança de pedágios. Para atingir tal objetivo, foram disponibilizados alguns artefatos, tais como: Documento de Requisitos, Casos de Uso, Modelo Conceitual, DSSs e Contratos de Operação.

Além das informações contidas nos artefatos acima mencionados, o desenvolvimento dos diagramas foi guiado também pelos padrões GRASP , que descrevem os princípios fundamentais de atribuição de responsabilidades a objetos. Dentre os principais padrões, estão: Especialista, Criador, Coesão Alta, Acoplamento Fraco e Controlador.

Como resultado, obtivemos diversos Diagramas de Colaboração, que abordam não apenas os cenários de sucesso, mas também alguns dos fluxos alternativos que possam vir a acontecer. Para elaborar tais diagramas, foi utilizada a ferramenta DIA Diagram Editor [1] .

[1] DIA Diagram Editor 0.97.2, disponível em http://projects.gnome.org/dia/ 

1. ARTEFATOS DESENVOLVIDOS

Baseando-se nos artefatos fornecidos, desenvolvemos um diagrama de colaboração para cada cenário de sucesso das seguintes operações, além de alguns fluxos alternativos:

• Liberar Saída
• Informar Passagem Veículo
• Adicionar Proprietário
• Adicionar Veículo
• Adicionar Gizmo
• Realizar Pagamento

1. CONSIDERAÇÕES INICIAIS

A seguir, serão apresentados tais diagramas, além de uma breve discussão sobre as opções de projeto adotas e a influência dos padrões GRASP nas mesmas. É importante ressaltar que o projeto desenvolvido baseia-se em apenas um corte do projeto final, e por este motivo diversas suposições foram levadas em consideração.

Para facilitar o entendimento dos diagramas desenvolvidos, apresentaremos também os Contratos de Operações fornecidos. É necessário enfatizar que algumas modificações foram realizadas para garantir o bom funcionamento do sistema, dado que há várias inconsistências entre os DSSs, os Contratos de Operações e os Casos de Uso.

Em todos os diagramas foi utilizado o Padrão Controlador, segundo o qual uma instância de uma classe trata um evento particular do sistema ao representar o funcionamento de um caso de uso. O uso de um controlador fachada que representasse o sistema como um todo foi rejeitado ao passo que este poderia ficar sobrecarregado por excesso de responsabilidade.

Além disso, consideramos que como há apenas uma concessionária, ela não foi incluída nos diagramas de colaboração, sendo incluída apenas na parte de codificação.

1. DIAGRAMAS DE COLABORAÇÃO

1. liberarSaida(codigoGizmo, codigoAPSaída)

Operação: liberarSaida

Parâmetros: codigoGizmo, codigoAPSaída

Referências Cruzadas: Caso de Uso: Sair da Autopista

Pré-Condições: O veículo possui um gizmo instalado em seu veículo. O veículo entrou na autopista (seja via Passe Livre ou via ticket).

Pós-Condições:

• Se o gizmo cujo código é codigoGizmo estiver habilitado no Sistema e o proprietário estiver adimplente então:

• O Registro_de_Uso reg correspondente à entrada do veículo na autopista foi associado à área de pedágio cujo código é codigoAPSaida.
• reg.data_saida recebeu a data do Sistema.
• reg.hora_saida recebeu a hora do Sistema.
• O valor correspondente ao uso do trecho da autopista foi calculado e atribuído a reg.valorCobrado.
• reg.emCirculacao recebeu false.
• cancela.aberta tornou-se true.
• semaforo.luzVerdeLigada tornou-se true.
• semaforo.luzVermelhaLigada tornou-se false.

• Cenário de sucesso principal [pic 1]

• Fluxos alternativos

• O proprietário não está adimplente (tornou-se inadimplente após a entrada)
• O sistema verifica que o cliente entrou pela entrada manual e está querendo sair pela automática.

• O Sistema não abre a cancela em menos de 3 segundos (representado no cenário principal).
• O sensor do gizmo não identifica o código do gizmo do Proprietário (representado no cenário principal).

[pic 2]

Comentários:

Nestes diagramas foi dada ao controlador a responsabilidade de conhecer apenas as classes e coleções de pistas de saída e de gizmos, reduzindo o acoplamento no controlador. A classe “Gizmo é responsável em conhecer um objeto da classe “Registro de uso para poder atualizar a data de saída do usuário e a situação de circulação na rodovia. Para aumentar a coesão de cada classe, a classe APSaída, é responsável por conhecer as classes “Semáforo” e “Cancela”, para ordenar as respectivas ações de apagar/acender luzes e levantar/abaixar cancela (Padrão Especialista).