### Compreender os Conceitos Fundamentais Primeiro, as tecnologias e paradigmas chave necessários para este projeto devem ser totalmente compreendidos. - **Processos vs. Threads:** O projeto especifica o uso de ambos. - **Processos (para Cruzamentos)** são programas independentes, cada um com o seu próprio espaço de memória. Em Java, cada cruzamento será provavelmente executado como uma aplicação Java separada (uma instância distinta da JVM). - **Threads (para Semáforos)** existem _dentro_ de um processo e partilham memória. Isto é adequado para os semáforos, pois eles precisam de ser coordenados e partilhar dados (como filas de veículos) dentro do mesmo cruzamento. - **Comunicação Entre Processos (IPC - Inter-Process Communication):** Como os cruzamentos são processos separados, é necessário um método para que eles comuniquem. **Sockets** são o método especificado. Quando um veículo sai de um cruzamento (ex: `Cr1`) e vai para outro (ex: `Cr2`), o processo `Cr1` precisa de enviar uma mensagem contendo os dados do veículo para o processo `Cr2` através de uma conexão por socket. - **Simulação de Eventos Discretos (DES - Discrete-Event Simulation):** Este é o paradigma de simulação que deve ser utilizado. Em vez de o tempo fluir continuamente, o relógio da simulação salta de um evento para o seguinte. - Um **evento** é um objeto que representa algo que acontece num ponto específico no tempo (ex: "Veículo A chega ao Cr2 no tempo 15.7s"). - Uma **lista de eventos** central, frequentemente uma fila de prioridades, será necessária para armazenar eventos futuros, ordenados pelo seu timestamp. O ciclo principal da simulação retira o próximo evento da lista, processa-o e adiciona quaisquer novos eventos que resultem dele. - **Processo de Poisson:** Para o modelo "mais realista" de chegadas de veículos, é especificado um processo de Poisson. A principal conclusão é que o tempo _entre_ chegadas consecutivas de veículos segue uma **distribuição exponencial**. Em Java, este intervalo pode ser gerado usando `Math.log(1 - Math.random()) / -lambda`, onde `lambda` (λi​) é a taxa de chegada especificada. --- ### Uma Sugestão de Arquitetura de Alto Nível Abaixo, é apresentada uma possível estrutura para a aplicação distribuída. Pode ser vista como um conjunto de programas independentes que comunicam através de uma rede. 1. **Processo Coordenador/Gerador (1 Processo):** - **Propósito:** Iniciar a simulação, gerar veículos e gerir o relógio global da simulação ou os critérios de paragem. - **Responsabilidades:** - Lê a configuração da simulação (ex: carga de tráfego λi​, tempos dos semáforos). - Gera veículos de acordo com o modelo selecionado (intervalo fixo ou processo de Poisson). - Atribui a cada novo veículo um percurso com base na distribuição uniforme especificada. - Injeta o veículo no sistema enviando uma mensagem para o primeiro processo de cruzamento no seu percurso (ex: de um ponto de entrada E1 para Cr1). 2. **Processos de Cruzamento (5 Processos):** - **Propósito:** Simular cada cruzamento (`Cr1` a `Cr5`) como um processo distinto. - **Responsabilidades:** - Escuta por veículos a chegar de outros processos. - Gere as filas de veículos para os seus semáforos. - Executa múltiplas **threads de Semáforo** internamente. - Coordena estas threads para garantir que apenas uma direção de tráfego está aberta a cada momento. - Quando um veículo atravessa, é encaminhado para o processo seguinte no seu percurso. - Envia periodicamente as suas estatísticas (ex: comprimentos atuais das filas) para o Servidor do Dashboard. 3. **Processo de Nó de Saída (1 Processo):** - **Propósito:** Representar o ponto de saída `S` e atuar como um coletor de dados para estatísticas globais. - **Responsabilidades:** - Recebe veículos que completaram o seu percurso. - Calcula métricas globais como o tempo total de viagem (tempo de permanência) para cada veículo. - Agrega e calcula as estatísticas finais (ex: tempo de viagem mínimo, máximo e médio por tipo de veículo). - Envia estas estatísticas globais para o Servidor do Dashboard. 4. **Processo do Servidor do Dashboard (1 Processo):** - **Propósito:** Agregar e exibir todos os dados da simulação em tempo real. - **Responsabilidades:** - Abre um socket de servidor e escuta por dados a chegar de todos os processos de Cruzamento e de Saída. - Armazena e atualiza as estatísticas à medida que chegam. - Apresenta os dados numa interface de utilizador, que deve exibir métricas e ser atualizada durante a simulação. --- ### Plano Nem tudo deve ser construído de uma só vez. Os seguintes passos incrementais são recomendados. #### **Passo 1: Modelação e Classes Principais (Não-distribuído)** Antes de escrever qualquer lógica complexa, as estruturas de dados devem ser definidas. Devem ser criados Plain Old Java Objects (POJOs) para: - `Veiculo`: Com atributos como um identificador único, tipo, tempo de entrada e o percurso realizado. Deve ser tornado `Serializable` para que possa ser enviado através de sockets. - `Evento`: Com atributos como um timestamp e o tipo de evento (ex: `VEHICLE_ARRIVAL`), bem como dados associados. - `Semaforo`: Para conter o seu estado (`VERDE`/`VERMELHO`) e a fila de veículos. - `Cruzamento`: Para conter os seus semáforos e a lógica operacional. #### **Passo 2: Construir um Protótipo de Processo Único** Este é um passo crucial. Sockets e processos devem ser deixados de lado por agora para construir toda a simulação numa única aplicação Java. - Deve ser criado um ciclo de simulação central baseado numa fila de prioridades para objetos `Evento`. - Todos os objetos `Cruzamento` e `Semaforo` devem ser instanciados. - A lógica principal deve ser tornada funcional: veículos a moverem-se entre filas, semáforos a mudar de estado e estatísticas básicas a serem recolhidas. - **Objetivo:** Uma simulação totalmente funcional e não-distribuída. Isto torna a depuração significativamente mais fácil. #### **Passo 3: Distribuir os Cruzamentos** O protótipo pode agora ser convertido num sistema distribuído. - A classe `Cruzamento` deve ser tornada executável como uma aplicação Java autónoma (com um método `main`). Serão lançadas cinco instâncias, uma para cada cruzamento. - Devem ser configurados sockets TCP para comunicação. Cada processo de cruzamento precisa de saber o endereço/porta dos vizinhos para os quais pode enviar veículos. - Um **protocolo de comunicação** claro deve ser definido. Por exemplo, quando `Cr1` envia um veículo para `Cr2`, o objeto `Veiculo` é serializado e escrito no socket conectado a `Cr2`. O processo `Cr2` terá uma thread dedicada para escutar estas conexões de entrada. #### **Passo 4: Implementar as Threads dos Semáforos** Dentro de cada processo `Cruzamento`, os semáforos devem ser implementados como threads. - O principal desafio aqui é a **sincronização**. As threads dos semáforos num único cruzamento partilham as filas de veículos. - As ferramentas de concorrência do Java (como `synchronized`, `ReentrantLock`, `Semaphore`) devem ser usadas para garantir que apenas um semáforo pode estar verde para um percurso conflituante e que o acesso às filas partilhadas é seguro (thread-safe). #### **Passo 5: Implementar o Dashboard** - O processo `DashboardServer` deve ser criado. Ele irá escutar numa porta específica por estatísticas a chegar. - Nos processos `Cruzamento` e `Saida`, deve ser adicionado um mecanismo para enviar periodicamente um resumo das suas estatísticas atuais para o Servidor do Dashboard. - A UI deve ser construída para exibir estes dados em tempo real. #### **Passo 6: Testes e Análise** Assim que o sistema completo estiver a funcionar, as experiências exigidas pela descrição do projeto podem ser realizadas. - A simulação deve ser executada com diferentes taxas de chegada de veículos para simular cargas baixas, médias e altas. - Diferentes políticas de temporização dos semáforos devem ser testadas para medir o seu impacto no congestionamento. - Diferentes algoritmos de seleção de percurso e o seu impacto no desempenho do sistema devem ser avaliados. - Para cada cenário, a simulação deve ser executada várias vezes para recolher estatísticas fiáveis (médias, desvios padrão, intervalos de confiança), conforme solicitado. #### **Passo 7: Escrever o Relatório** À medida que cada passo é concluído, deve ser documentado. Isto tornará a escrita do relatório final muito mais fácil. Todos os pontos mencionados nas secções "Entrega" e "Critérios de Avaliação" devem ser abordados. --- ### OBS: - **Começar de Forma Simples:** O protótipo de processo único (Passo 2) evitará grandes dificuldades mais tarde. - **Protocolo de Comunicação:** O protocolo de mensagens deve ser definido o mais cedo possível. A informação exata que um processo envia para outro deve ser clara//simples//consistente. - **Debugging:** Debugging de sistemas distribuídos podem ser difíceis. Uma framework de logging (como Log4j 2 ou SLF4J) pode ser usada para registar eventos//alterações de estado nos diferentes processos. - **Configuração:** Valores como endereços IP, números de porta ou parâmetros da simulação não devem ser "hardcoded". Um ficheiro de configuração (ex: um ficheiro `.properties` ou `.json`) torna a aplicação mais fácil de executar e testar.