Fundamentos de Sistemas Operativos Trabalho Prático PDF
Document Details
Uploaded by WellRoundedAgate6567
Instituto Superior de Engenharia de Lisboa
2024
Tags
Summary
This document is a set of practice assignments (trabalhos práticos) for a Systems Design course at Instituto Superior de Engenharia de Lisboa for the 2024-2025 academic year. The assignments involve creating graphical user interfaces (GUIs) in Java and managing tasks.
Full Transcript
INSTITUTO SUPERIOR de ENGENHARIA de LISBOA Licenciatura em Engenharia Informática e Multimédia 1º Semestre Letivo 2024/2025 Fundamentos de Sistemas Operativos 1º Trabalho Prático Objetivos: Dese...
INSTITUTO SUPERIOR de ENGENHARIA de LISBOA Licenciatura em Engenharia Informática e Multimédia 1º Semestre Letivo 2024/2025 Fundamentos de Sistemas Operativos 1º Trabalho Prático Objetivos: Desenho duma GUI em swing utilizando o editor gráfico WindowBuilder. Desenvolvimento de aplicações multitarefa em Java. Comunicação e sincronização entre tarefas Java. Pretende-se o desenvolvimento de uma aplicação para controlo de um robot constituído por 3 tarefas Java que permitam aplicar comportamentos a um robot: i) Comportamento Vaguear; ii) Comportamento Evitar; iii) Comportamento Fugir. A comunicação entre as tarefas (comportamentos) da aplicação é suportada por objetos partilhados e a sincronização é implementada com semáforos ou monitores. Como ponto de partida para este trabalho considere a interface gráfica desenvolvida nas primeiras aulas práticas. Adicione à interface três componentes gráficos do tipo JCheckBox: “Vaguear”, “Evitar” e “Fugir”, de modo a conseguir ativar/desativar de forma independente os 3 comportamentos (Vaguear, Evitar e Fugir). Figura 1 – Interface gráfica sugerida para o 1º trabalho O comportamento Vaguear é uma tarefa Java que quando ativa faz com que o robot vagueie pelo espaço. A definição de vaguear no espaço consiste no robot andar em frente, curvar à direita e curvar à esquerda de forma aleatória. 1 O comportamento Evitar é uma tarefa Java que quando ativa, testa o sensor de toque no robot e enquanto a leitura do sensor de toque devolver ativo (valor 1) então o robot deve parar, de seguida anda 15 cm para trás, depois faz um curvar à esquerda com raio de 0 cm e ângulo de 90 graus. Só no caso do comportamento Vaguear não estar selecionado, este comportamento deve parar o robot depois dos anteriores comandos. O comportamento Fugir é uma tarefa Java, que quando ativa, utiliza o sensor de ultrassons para medir uma distância à sua retaguarda, e enquanto a medida da distancia for inferior a 50 cm o robot deve de fugir de quem o persegue. A fuga consiste em fazer uma curva (gerada aleatoriamente à esquerda ou à direita) de 90 graus com raio de 20 cm, de seguida fazer uma reta de 20 cm e depois fazer a curva espelhada da primeira. Objetivos das aulas práticas Aula prática 1 – Instalação do WindowBuilder sobre o Eclipse. Instalação das bibliotecas do robot. Desenho da GUI da aplicação e controlo do robot. Aula prática 2 – Desenho do diagrama de estados da tarefa Vaguear e respetiva implementação e teste. Aula prática 3 – Desenho do diagrama de estados da tarefa Evitar e respetiva implementação e teste. Aula prática 4 – Desenho do diagrama de estados da tarefa Fugir e respetiva implementação e teste. Aula prática 5 – Desenho do diagrama de classes utilizando o MagicDraw das classes implementadas. Aula prática 6 – Sincronização entre a GUI da aplicação e as tarefas. Sincronização entre as várias tarefas no acesso ao robot. Aula prática 7 – Integração final e validação da aplicação. Avaliação O trabalho é realizado em grupo e está sujeito a avaliação. O trabalho começa na segunda aula prática do semestre. A duração do trabalho prático é de 7 aulas práticas. Por cada aula prática, cada grupo deverá entregar um relatório semanal que descreve o 2 trabalho desenvolvido na aula. Os relatórios podem incluir diagramas técnicos, por exemplo diagramas de classes UML ou diagramas de atividade e/ou estado de processo, para complementar as descrições das opções tomadas. Cada um destes relatórios corresponde a uma secção do relatório final relativo ao trabalho. O relatório final deve incluir uma capa, índices, uma introdução e as conclusões. A discussão do trabalho será realizada na(s) semana(s) seguinte(s) à entrega do relatório final após a última aula prática do trabalho. Os Docentes, Jorge Pais, Carlos Gonçalves e Carlos Carvalho 3 INSTITUTO SUPERIOR de ENGENHARIA de LISBOA Licenciatura em Engenharia Informática e Multimédia 1º Semestre Letivo 2024/2025 Fundamentos de Sistemas Operativos 2º Trabalho Prático Objetivos: Desenvolvimento de interfaces gráficas em Java Swing utilizando o editor gráfico WindowBuilder para o Eclipse; Gestão de processos Java; Comunicação entre processos Java com memória partilhada; Modelo Cliente-Servidor Gestão de Ficheiros. Pretende-se o desenvolvimento de uma aplicação multiprocesso composta por dois processos Java. Um dos processos é a aplicação desenvolvida no trabalho prático 1, designado TP1, que conhece a API do Robot. O segundo processo é outra aplicação que implementa os comportamentos Imitar e Gravar, designado IG, que também conhece a API do Robot. O processo TP1 comunica com o processo IG utilizando memória partilhada suportada pela classe JAVA MappedByteBuffer. A comunicação entre TP1 e IG acontece quando o comportamento Vaguear do TP1 está a enviar comandos para o robot. A especificação da sintaxe da mensagem de comunicação entre os dois processos é a que se apresenta na Tabela 1. Tabela 1 – Estrutura das mensagens trocadas entre os diferentes processos Número (int) Comando (int) Argumento 1 (int) Argumento 2 (int) Número: É um campo do tipo int e identifica a cardinalidade da mensagem enviada. Por exemplo, a primeira mensagem é identificada pelo número 1, a segunda pelo número 2 e assim sucessivamente. Comando: É um campo do tipo int com os significados apresentados na Tabela 2. Tabela 2 – Significado do valor comando Comando Ordem do robot 0 Parar 1 Reta 2 Curvar à direita 3 Curvar à esquerda Argumento 1 e Argumento 2: Argumentos para os comandos do robot. Por uma questão de simplificação todos os argumentos são do tipo int. Caso um dado comando apenas necessite de um argumento, exemplos do comando Reta e Parar, o segundo argumento deve ser preenchido com o valor 0 (zero). O processo IG é um processo Java consumidor de mensagens. Este processo lê as mensagens enviadas por TP1, guarda-as em memória local para depois as ir executando num outro robot pela mesma ordem. A GUI do processo IG deve ser dividida em quatro campos: um campo permite interagir com o robot; o segundo campo define o comportamento Imitar, no qual se define a abertura do canal de comunicação e também se o comportamento está ativo ou não; o terceiro campo define o ficheiro para gravação ou reprodução e qual a funcionalidade; o quarto campo define a consola tendo as opções de limpeza e de permissão para imprimir. A Figura 1 apresenta uma sugestão de interface gráfica para o processo IG. Figura 1 – Interface gráfica sugerida para o processo IG A interface gráfica sugerida permite ativar ou desativar o comportamento Imitar. Os comandos enviados do processo TP1 para o processo IG quando este está desativo, devem ser lidos pelo processo IG do canal de comunicação e serem eliminados não sendo enviados para o robot. A GUI do processo TP1 deve ser complementada com a identificação e também com a dimensão do canal de comunicação e também deve de ter a possibilidade de selecionar no sistema de ficheiros o processo IG a executar e ter uma opção explicita de execução do processo selecionado. Só após o lançamento ou execução do processo IG é que se deve dar início à comunicação entre processos. A alteração da GUI do TP1 fica ao critério de cada grupo de alunos. O canal de comunicação entre os processos TP1 e IG deve obedecer ao modelo apresentado nas folhas de apoio da Unidade Curricular tal como apresentado na Figura 2. buffer: MappedByteBuffer fc: FileChannel F: File Figura 2 – Modelo de comunicação entre os diferentes processos O buffer, do tipo MappedByteBuffer, implementa um ring buffer com uma dimensão entre 8 e 16 posições (mensagens). A dimensão e o nome do canal de comunicação são escolhidos na GUI do processo TP1 e passados ao processo IG quando este processo for lançado pelo processo TP1. Sugestões para o desenvolvimento do trabalho: 1. Defina uma hierarquia de classes para suportar as mensagens (classe base Mensagem) que são escritas no canal de comunicação. Sugere-se que esta hierarquia tire partido dos mecanismos de polimorfismo e herança; 2. Crie uma classe CanalDeComunicacao que cria o canal de comunicação e os métodos de leitura e escrita de objetos (do tipo Mensagem) no canal necessários à comunicação entre os processos. 3. Os dois processos devem ter objetos da classe CanalDeComunicacao para a concretização da comunicação entre processos ponto a ponto. Avaliação O trabalho é realizado em grupo e está sujeito a avaliação. A duração do trabalho prático é de 6 aulas práticas. Por cada aula prática cada grupo deverá entregar um relatório (no máximo de 4 páginas) que descreva as opções técnicas tomadas em cada uma das aulas. Os relatórios podem incluir diagramas técnicos, por exemplo diagramas de classes UML ou diagramas de atividade e/ou estado de processo, para complementar as descrições das opções tomadas. Cada um destes relatórios corresponde a uma secção do relatório final relativo ao trabalho. Os objetivos a cumprir em cada aula prática são os seguintes: Aula prática 1 – Desenho da GUI do processo IG e tratamento dos eventos. Complementar a GUI do processo TP1; Aula prática 2 – Desenho do diagrama de classes utilizando o MagicDraw do processo IG e do processo TP1 incluindo as classes sugeridas para comunicação Mensagem e CanalDeComunicacao; Aula prática 3 – Desenvolvimento das classes Mensagem e CanalDeComunicacao e respetivo teste; Aula prática 4 – Integração das classes Mensagem e CanalDeComunicacao no processo TP1; Aula prática 5 – Desenho do diagrama de estados do processo IG, implementação e teste; Aula prática 6 – Integração final e validação de toda a aplicação multiprocesso. O relatório de cada aula prática deve ser entregue, via Moodle, até ao dia da próxima aula prática. A discussão do trabalho será realizada na semana seguinte à entrega do relatório da última aula prática referente ao trabalho. Os Docentes, Carlos Carvalho, Carlos Gonçalves e Jorge Pais