ThreadFactory: Uma simulação de semáforos para apoiar a disciplina de Sistemas Operacionais

Transcrição

1 ThreadFactory: Uma simulação de semáforos para apoiar a disciplina de Sistemas Operacionais José Raul B. Andrade, Josué S. Gomes Júnior Ana Liz Souto O. de Araújo Centro de Ciências Aplicadas e Educação Universidade Federal da Paraíba (UFPB) - Rua da Mangueira, s/n - CEP Rio Tinto PB Brasil {raul.andrade,josue.gomes,analiz}@dce.ufpb.br Resumo. Dentre os problemas de aprendizagem da disciplina de Sistemas Operacionais em cursos de Computação, tem se destacado a dificuldade de abstração e falta de maturação em programação, primordiais para entendimento do funcionamento de algoritmos. Uma pesquisa realizada com professores e alunos dos cursos de informática do campus IV-UFPB evidenciaram essas afirmativas e apontam que a maior dificuldade, tanto para entender quanto para ministrar, está no algoritmo semáforo. O semáforo é um algoritmo de sincronização de processos que tem por característica principal possuir uma zona crítica que funciona gerenciada por um semáforo (como o de transito), sinalizando quando a zona está ou não disponível para escalonar os processos da fila de execução. Entendendo a dificuldade de ensino/aprendizagem desse conteúdo, é proposta a ferramenta ThreadFactory que, de forma lúdica, permite ao professor ou aluno simular o funcionamento do algoritmo Semáforo. Tendo como base a teoria interacionista, a ferramenta permite a interação entre quem a utiliza e a analise e construção do conhecimento. A abordagem escolhida de semáforo foi produtorconsumidor, um algoritmo clássico. O cenário da simulação é uma fabrica fictícia de threads, composta por: caixas azuis (processos não escalonados), esteira á esquerda (fila de processos a ser escalonados), processador (área critica da CPU, responsável pelo processamento), caixas cor de rosa (processos já escalonados) e esteira à direita (fila dos processos escalonados). A cada ação executada, é apresentado o pseudocódigo, destacando a linha de código simulada no momento. A simulação é finalizada a pedido do usuário. Assim, espera-se que a ferramenta ThreadFactory, de forma lúdica, permita ao professor ou aluno observar e interagir com a execução do algoritmo. Palavras-chave: Objeto de aprendizagem. Sistemas operacionais. Ensino de computação. 1. Introdução

2 2 Para ensinar conteúdos nos quais se faz necessária a abstração do funcionamento de algoritmos, muitas vezes, é requerido do professor a utilização de artifícios e recursos no intuito de auxiliar o aluno a conseguir visualizar a execução do algoritmo. Atualmente, os artifícios mais adotados são a lousa (desenho do quadro) e a projeção de imagens. Mesmo assim, esses artifícios não veem se mostrando tão eficazes, devido a falta de interação com os dados, do controle da execução e da relação com a linguagem de programação. Na disciplina de Sistemas Operacionais são utilizadas analogias, com problemas do mundo real, para representar os erros que podem ocorrer durante a execução de determinado algoritmo. Estes são chamados de problemas clássicos de comunicação entre processos e ilustrados através de estórias para apresentar os algoritmos (TANENBAUM, 2003). Entre eles destacam-se: o semáforo, o produtor/consumidor, o leitor/escritor e jantar dos filósofos. No intuito de facilitar o entendimento destes conceitos e suas aplicações, foi verificado, através de uma pesquisa com ex-alunos e professores da disciplina de Sistemas Operacionais da UFPB, Campus IV, a necessidade de uma ferramenta, do tipo simulação, que auxiliasse no ensino e aprendizagem do conteúdo de sincronização de processos, mais especificamente o algoritmo de Semáforo. Nesse contexto, o presente trabalho descreve o processo de concepção e desenvolvimento da ferramenta ThreadFactory, um simulador do algoritmo de semáforo (TANENBAUM, 2003), no qual o usuário poderá interagir e observar os casos de erro que ocorrem durante o funcionamento. De forma simultânea, é apresentado o pseudocódigo equivalente ao momento de execução da ferramenta. O restante desse trabalho está dividido da seguinte forma: a seção 2 apresenta os trabalhos relacionados; a seção 3 descreve a metodologia utilizada; na seção 4 é descrita a ferramenta ThreadFactory; a seção 5 mostra a avaliação e os resultados obtidos a partir dela; e a seção 6 apresenta as considerações finais e as possibilidades futuras de continuação deste trabalho. 2. Simuladores como objetos de aprendizagem Mídias, como por exemplo, imagens, vídeos, áudios, quando utilizadas com a finalidade de apoiar nos processos de ensinar e aprender, são chamadas de Objetos de Aprendizagem - OA (WILLEY, 2000). O termo Objeto de Aprendizagem tem origem do termo em inglês learning object e, de acordo com IEEE Standard for Learning

3 3 Object Metadata (IEEE, 2002), são recursos digitais que podem ser reutilizados para dar suporte ao aprendizado, auxiliando no ensino presencial e/ou à distância. Muitas das ferramentas de aprendizagem que existem atualmente na área de ensino de computação focam no desenvolvimento da habilidade de resolução problemas e do pensamento algorítmico. Para atingir esse objetivo, utilizam de uma linguagem própria, seja ela gráfica ou textual, para estimular os alunos a interagir com o material. Utilizando a simulação, encontram-se alguns exemplos de objetos de aprendizagem, são eles: Algoritmos de ordenação (ALGORITMOS DE ORDENAÇÃO, 2014) e o Simulador de Algoritmos de Classificação (RAMPANELLI E CANTO, 2007). Esse tipo de mídia tem por proposta apresentar ao estudante, de forma lúdica, a execução em tempo real de determinados algoritmos. A quantidade de OA na área de ensino de computação que utilizem da simulação é bem reduzida, principalmente quando a temática abordada é o conteúdo de Sistemas Operacionais. Dos poucos existentes se destacam o SimulaRSO (RODRIGUES et al., 2011), o qual é um aplicativo que simula o comportamento do escalonamento de processos, escalonamento de discos e paginação de memória. Outro de destaque é o SOsim (MAIA, 2001), que simula mecanismos de um Sistema Operacional multiprogramável e/ou multitarefa. Considerando os materiais, no formado de simulação, já existentes, não foi encontrado nenhum que trabalhasse o conteúdo de Semáforo (DIJKSTRA, 2002). Diante dessa limitação, o desafio de propor uma nova ferramenta estava em definir um enredo motivador, uma tecnologia adequada, e equilibrar diversão e aprendizagem, objetivando uma maior abstração e consequentemente um melhor desempenho na disciplina de Sistemas Operacionais. 3. Metodologia O desenvolvimento do corrente trabalho foi dado início com uma revisão bibliográfica a cerca do tema. Em seguida foi preparado um questionário, no intuito de realizar um levantamento sobre a percepção das dificuldades de ensino e aprendizagem na disciplina de Sistemas Operacionais. Participaram da pesquisa 2 professores da disciplina de Sistemas Operacionais, 15 alunos de Licenciatura em Ciência da Computação e 13 alunos de Sistemas de Informação, que ministraram e cursaram, respectivamente, a disciplina entre os semestres e , na UFPB, campus IV. Essas informações são apresentadas nos gráficos da Figura 1.

4 4 Estes questionários tinham por objetivo identificar quais dos conteúdos da disciplina de Sistemas Operacionais eram apontados como os que apresentam mais dificuldade, tanto em relação à aprendizagem, no caso do aluno, quanto para lecionar, no caso do professor. Outro objetivo foi identificar qual o tipo de mídia os entrevistados mais usam e/ou acreditam ser eficiente como material de apoio ao conteúdo. A partir desse levantamento foi possível definir que o assunto abordado na ferramenta seria o de sincronização de processos (Figuras 2 e 3), e o tipo de mídia, simulação (Figura 4). Ainda por esse levantamento, foi possível perceber que os professores e alunos têm por costume utilizar outras mídias, como games e vídeos para aprender/ensinar, e é unanime a opinião de que objetos de aprendizagem fazem diferença nesse processo. O passo seguinte foi definir o contexto e tecnologia. Tomando por base a abordagem de produtor e consumidor, já adotado como exemplo na disciplina, foi escolhido como abstração, uma fábrica, porém, com algumas características próprias. A narrativa resumida da simulação pode ser vista na tabela 1. Quanto à tecnologia, foi realizado um levantamento de arcabouços, analisando as necessidades da ferramenta, como portabilidade e adaptabilidade. Foi escolhida a linguagem HTML 5 usando o framework Panda.js, por possuir a possibilidade de portabilidade entre diferentes plataformas e poder se executado diretamente no navegador. Definido o tema e a tecnologia, a escolha da engenharia de desenvolvimento foi a próxima etapa. Decidiu-se adotar as formas de documentar propostas por Schuytema (2008) e, como metodologia, uma alusão ao Scrum, por ser ágil e caracterizado por feedbacks em curto espaço de tempo. Simultaneamente foi estudada a documentação do framework para o desenvolvimento da ferramenta. A Avaliação do ThreadFactory foi feita por uma professora que ministrou, durante três semestres, a disciplina de Sistemas Operacionais. Informações mais detalhadas sobre essa etapa podem ser encontradas na seção O simulador ThreadFactory O ThreadFactory está ambientado em uma fábrica fictícia de escalonamento de processos que, durante a execução, deverão ser escalonados. Cada processo é representado por uma caixa e quando o processo é escalonado, a representação é uma caixa processada, ou seja, características visuais da mesma são modificadas. O simulador funciona baseado no algoritmo de sincronização semáforo, cuja característica

5 5 principal é possuir uma zona crítica que funciona gerenciada por um semáforo (como o de transito), sinalizando quando a zona está ou não disponível para escalonar os processos da fila de execução. É utilizado como algoritmo de escalonamento de processos o FIFO First In Firts Out (o primeiro a entrar é o primeiro a sair). 4.1 Funcionamento O simulador apresenta as diferentes situações do funcionamento do algoritmo de semáforo, aplicados às caixas (processos) da fábrica. Os casos de erro que podem ocorrer durante a simulação e, simultaneamente, o pseudocódigo de semáforo referente a execução. A figura 5 apresenta a interface do simulador. 4.2 Componentes do simulador Na tabela 2 são apresentados os componentes do ThreadFactory com uma descrição resumida de cada um. 4.3 Casos de erro No decorrer da execução do ThreadFactory podem ocorrer 3 casos de erro: (i) esteira de produção vazia, (ii) esteira de produção cheia e (iii) estoque cheio. Estes casos são descritos a seguir. Caso de erro 1: Esteira de produção vazia: A esteira de produção aguarda por um tempo (5 segundos) caixas para processar. Ao fim desse período, se nenhuma caixa for adicionada, seja automaticamente ou pelo ou o usuário, a simulação exibirá uma mensagem de erro, fazendo assim com que seja necessário reiniciá-la. Esse caso representa o Starvation ou situação de inanição (processo morre de fome ). A figura 6 apresenta a simulação com esse caso de erro. Caso de erro 2: Esteira de produção cheia: O oposto do que ocorre na situação anterior. A esteira se encontra cheia de caixas e a simulação e/ou usuário insere uma nova. Esse erro representa o buffer da memoria RAM cheio. A figura 4 apresenta uma tela desse caso de erro. Caso de erro 3: Estoque de processos cheio: Quando o estoque de caixas processadas estiver cheio, não podendo assim armazenar novas caixas. Esse caso não se relaciona a conceitos de Sistemas Operacionais, apenas ao contexto aplicado na ferramenta. É apresentada na figura 5 uma tela desse erro

6 6 5. Resultado e avaliação A versão atual da ferramenta é um protótipo funcional, ou seja, apesar de executar, nem todas as suas funcionalidades foram implementadas. Desta forma, a avaliação foi focada na proposta e nas funcionalidades, até o momento, existentes. O simulador foi, nesta fase, inicialmente avaliado por 5 alunos do curso de Licenciatura em Ciência da Computação e um professor da disciplina de Sistemas Operacionais. No primeiro caso, foram levados em consideração os fatores de motivação e interação, já no segundo, foram avaliados aspectos mais voltados à interface com o usuário. 5.1 Avaliação preliminar realizada pelo professor Essa avaliação foi realizada por uma professora da UFPB, Campus IV, que, durantes três semestres, ministrou a disciplina de Sistemas Operacionais. Os aspectos avaliados foram derivados das heurísticas de jogabilidade descritas em Barcelos et al. (2011). A utilização destas foi motivada pela ausência de padrões de avaliação para simulações. A avaliação heurística é uma técnica originalmente proposta por Nielsen e Molich (1990), que tem a finalidade de identificar problemas relacionados à usabilidade em sistemas interativos através da inspeção de um conjunto de critérios heurísticos previamente definidos. As heurísticas utilizadas são apresentadas na Tabela 3. Por não serem originalmente desenvolvidas para simulações, algumas das heurísticas não se aplicam desta forma, não foram utilizadas (h4, h5, h7, h14, h15, h16, h17 e h18). As respostas da avaliação foram registradas de forma escalar, possuindo níveis de um a cinco, para medir se a ferramenta apresenta, ou não, as heurísticas de jogabilidade. De acordo com o resultado, o ThreadFactory foi bem avaliado, obtendo conceito 5 (máximo) em 3 critérios (h2, h6 e h8), conceito 4 em 5 critérios (h1, h3, h11, h13, e h19), conceito 3 em 3 critérios (h9, h10 e h12). Por meio da avaliação preliminar, têm-se indícios de que o ThreadFactory apresenta controles e objetivos de forma clara, apresentando dicas, e possuindo, além do objetivo geral, desafios mais específicos, sempre permitindo ao usuário acesso a informações sobre o estado em que se encontra a simulação. Além disso, a avaliação preliminar mostrou que ele possui uma interface intuitiva e organizada estrategicamente para proporcionar, ao usuário, uma melhor interação com as funcionalidades. 5.1 Avaliação preliminar realizada pelo aluno

7 7 Para essa avaliação, 5 alunos do curso de Licenciatura em Ciência da Computação, que cursaram a disciplina no semestre , utilizaram a versão protótipo do simulador ThreadFactory. Após a utilização, foi realizada uma entrevista semiestruturada no intuito de capturar a opinião desses estudantes sobre a ferramenta. Como resultado, segundo a opinião dos alunos entrevistados, apesar de não estar completamente pronto, o simulador é um material claro e estimulante, que facilita a abstração do funcionamento do algoritmo de Semáforo ao mesmo tempo em que prende a atenção devido a interação e ao enredo. 6. Considerações finais Dentre as contribuições já feitas na área do ensino de Sistemas Operacionais, é esperado que o ThreadFactory seja mais uma ferramenta que contribua para facilitar a abstração, interesse e, consequentemente, o entendimento dos conteúdos da disciplina de Sistemas Operacionais. A partir da avaliação preliminar realizada, tanto por parte do aluno como pelo professor, foram identificados pontos positivos e aspectos a serem melhorados. Considerando esses resultados, são propostos, para trabalhos futuros, (i) a criação de um site para disponibilização da ferramenta acompanhada de sua matriz instrucional, sugerindo uma forma de aplicá-lo ao contexto escolar, (ii) a utilização de outros algoritmos de escalonamento, já que atualmente é utilizado apenas o FIFO e (iii) adicionar/modificar funcionalidades para tornar a interface cada vez mais adequada ao usuário. Uma nova avaliação da ferramenta completa deverá ser realizada assim que uma nova versão da ferramenta estiver implementada, aprofundando mais nos critérios de avaliação dos estudantes. Referencias Algoritmos de Ordenação (2014). Simulação de Algoritmos de Ordenação. Disponível em: < Acesso em: 22 de outubro de Barcelos, T. S., Carvalho, T., Schimiguel, J., & Silveira, I. F. (2011, October). Análise comparativa de heurísticas para avaliação de jogos digitais. In Proceedings of the 10th Brazilian Symposium on on Human Factors in Computing Systems and the 5th Latin

8 8 American Conference on Human-Computer Interaction (pp ). Brazilian Computer Society. Dijkstra, E. W. (2002). Cooperating sequential processes (pp ). Springer New York. IEEE (2002) IEEE Learning Technology Standards Committee. Learning Object Metadata (LOM), Final Draft Standard, IEEE Maia, L. P. (2001). SOsim: Simulador para o Ensino de Sistemas operacionais. Rio de Janeiro. Nielsen, J. and Molich, R. (1990). Heuristic evaluation of user interfaces, in CHI 90: Proceedings of the SIGCHI conference on Human factors in computing systems, New York, pp Rampanelli, G. and Canto, F. H. (2007). Simulador de Algoritmos de Classificação. Disponível em: < Acesso em: 20 de outubro de Rodrigues, A. A., Pereira, C. R. and Pereira, A. L. V. (2011) SimulaRSO: Simulador de Recursos de Sistemas Operacionais. Disponível em: < Acesso em: 10 de outubro de Schuytema, P. (2008). Design de Games: Uma abordagem prática. Cengage Learning. Willey, D. (2000) The Instructional use of Learning Objects Available on Internet: Tanenbaum, Andrew S. Sistemas Operacionais Modernos. Pearson Prentice Hall Segunda edição. Título original: Modern Operating Systems Anexos Tabelas Tabela 1. Enredo resumido do ThreadFactory ThreadFactory é uma fabrica de processos, no qual cada um deles é representado por uma caixa. O objetivo da fabrica é processar as caixas. Porém, para que isso aconteça, não é tão simples assim. Podem ocorrer alguns casos de erro como, por exemplo: (i) a esteira de produção estar cheia, (ii) não haver caixas a serem processadas, ou (iii) o estoque de processos estar cheio.

9 9 Tabela 2. Componentes do simulador Possui caixas a serem processadas Caixa processada já Possui caixas a que já foram processadas Processa caixas as Caixa processada não Armazena as caixas processadas Tabela 3. Heurísticas de jogabilidade, extraídas de Barcelos et al. (2011). H1: Os controles devem ser claros, customizáveis e fisicamente confortáveis; suas respectivas ações de resposta devem ser imediatas. H2: O jogador deve poder customizar o áudio e o vídeo do jogo de acordo com suas necessidades H3: O jogador deve conseguir obter com facilidade informações sobre seu status e pontuação H4: O jogo deve possibilitar que o jogador desenvolva habilidades que serão necessárias futuramente H5: O jogador deve encontrar um tutorial claro de treinamento e familiarização com o jogo H6: Todas as representações visuais devem ser de fácil compreensão pelo jogador H7: O jogador deve ser capaz de salvar o estado atual para retomar o jogo posteriormente H8: O layout e os menus devem ser intuitivos e organizados de forma que o jogador possa manter o seu foco na partida H9: A história deve ser rica e envolvente criando um laço com o jogador e seu universo H10: Os gráficos e a trilha sonora devem despertar o interesse do jogador H11: Os atores digitais e o mundo do jogo devem parecer realistas e consistentes H12: O objetivo principal do jogo deve ser apresentado ao jogador desde o início H13: O jogo deve propor objetivos secundários e menores, paralelos ao objetivo principal. H14: O jogo deve possuir vários desafios e permitir diferentes estratégias H15: O ritmo do jogo deve levar em consideração a fadiga e a manutenção dos níveis de

10 10 atenção H16: O desafio do jogo pode ser ajustado de acordo com a habilidade do jogador H17: O jogador deve ser recompensado pelas suas conquistas de forma clara e imediata H18: A inteligência artificial deve representar desafios e surpresas inesperadas para o jogador H19: O jogo deve fornecer dicas, mas não muitas. Figuras Figura 1. Quantidade de alunos por curso e semestre que cursou a disciplina de SO Figura 2. Nível de dificuldade para ministrar e entender conteúdos na visão do professor Figura 3. Nível de dificuldade dos conteúdos na visão do aluno

11 11 Figura 4. Tipo de mídia auxiliaria o conteúdo de SO Figura 5. Interface do ThreadFactoty Figura 6. Caso de erro 1: esteira de produção vazia

12 12 Figura 7. Caso de erro 2: esteira de produção cheia Figura 8. Caso de erro 3: estoque de processos cheio