UNIVERSIDADE DE SÃO PAULO

Instituto de Ciências Matemáticas e de Computação

Sistema para alocação de horários

de aulas nos cursos do ICMC

Otavio Antunes de Oliveira Neto

São Carlos - SP

1
 Sistema para alocação de horários de aulas nos
cursos do ICMC

Otavio Antunes de Oliveira Neto

Orientadora: Rosana Teresinha Vaccare Braga

 
 

Monografia de conclusão de curso apresentada ao

Instituto de Ciências Matemáticas e de Computação –
ICMC-USP - para obtenção do título de Bacharel em
Informática.

Área de Concentração: Engenharia de Software e

Sistemas de Informação

USP – São Carlos

Junho de 2009
2
"Mesmo uma jornada de milhares
de quilômetros começa com um
passo”. – Confúcio

i
 Agradecimentos
A meus pais, pela compreensão e apoio.

Aos meus amigos, pelas distrações improdutivas em momentos oportunos.

A Paula Marcondes, por ter sido, mesmo distante, o real motivo do meu esforço.

ii
 Resumo
A alocação de horários nos diversos cursos do ICMC é um processo que exige alto

grau de conhecimento específico, é desempenhado manualmente, por poucas pessoas,

demanda grande esforço e tempo e tem baixo grau de padronização. Nesse contexto, um

sistema computacional que auxilie tal alocação será de grande valor para melhor elaborar a

distribuição de horários. Este projeto analisa as particularidades envolvidas no problema e

propõe uma modelagem Orientada a Objetos para um sistema de informação que auxilie os

coordenadores de cursos do ICMC, enfocando em princípio as necessidades do curso de

Bacharelado em Informática que, por ser noturno, apresenta restrições adicionais que tornam

a alocação das disciplinas ainda mais complexa. Entretanto, com pequenas alterações, o

sistema proposto poderá atender a diferentes cursos, com vários graus de complexidade.

PALAVRAS-CHAVE: alocação de horários, distribuição de horários, modelagem de

sistemas, orientação a objetos, análise de sistemas, restrições de horário.

iii
 Sumário
CAPÍTULO 1: INTRODUÇÃO .................................................................................. 1

1.1. CONTEXTUALIZAÇÃO E MOTIVAÇÃO ..................................................................... 1

1.2. OBJETIVOS ............................................................................................................. 2

1.3. ORGANIZAÇÃO DO TRABALHO............................................................................... 3

CAPÍTULO 2: REVISÃO BIBLIOGRÁFICA .......................................................... 4

2.1. CONCEITUALIZAÇÃO E TERMINOLOGIA ................................................................. 4

2.2. TRABALHOS RELACIONADOS ................................................................................. 5

CAPÍTULO 3: DESENVOLVIMENTO DO TRABALHO ..................................... 6

3.1. PROJETO ................................................................................................................ 6

3.2. DESCRIÇÃO DAS ATIVIDADES REALIZADAS ........................................................... 8

3.2.1 – Modelagem de Negócio ................................................................................ 9

3.2.2 – Análise de Requisitos ................................................................................. 11

3.2.3 – Projeto do Sistema ..................................................................................... 15

3.2.4 – Implementação do Sistema......................................................................... 16

3.3. RESULTADOS OBTIDOS ........................................................................................ 19

CAPÍTULO 4: CONCLUSÃO .................................................................................. 20

4.1. ASPECTOS GERAIS ............................................................................................... 20

4.2. CONTRIBUIÇÕES .................................................................................................. 20

4.3. TRABALHOS FUTUROS ......................................................................................... 20

iv
REFERÊNCIAS .......................................................................................................... 22

APÊNDICE A – DOCUMENTO DE REQUISITOS .............................................. 24

APÊNDICE B – DESCRIÇÃO DE CASOS DE USO ............................................. 28

v
Lista de Figuras

Figura 1: O Processo Unificado e os Artefatos produzidos........................................................ 7

Figura 2: Diagrama de Casos de Uso. ...................................................................................... 12

Figura 3: Modelo Conceitual. ................................................................................................... 14

Figura 4: Diagrama de Sequência do Sistema da operação Alterar Disciplina. ....................... 16

Figura 5: Protótipo da visualização de alunos. ......................................................................... 17

Figura 6: Protótipo da visualização de disciplinas. .................................................................. 17

vi
CAPÍTULO 1: INTRODUÇÃO

1.1. Contextualização e Motivação

A alocação da grade horária dos cursos ministrados no Instituto de Ciências

Matemáticas e de Computação (ICMC), assim como em qualquer instituição de ensino, é
um problema complexo que admite várias soluções e abordagens diferentes de acordo com
as particularidades envolvidas [SCHAEFER, A. (1999)]. Uma alocação de horários melhor
realizada trará benefícios como: maior rendimento das aulas (por exemplo, colocando em
horários seguidos uma disciplina teórica e sua equivalente prática), melhor aproveitamento
e aprendizado dos alunos (por exemplo, alternando no mesmo dia disciplinas consideradas
difíceis com outras consideradas fáceis), menor número de conflitos de horários para os
alunos com reprovações, entre outros. Por esses motivos, o estudo e o aperfeiçoamento da
forma como o horário é feito atualmente mostram-se relevantes ainda que a alta
complexidade do problema [BRAZ, O. O. (2000)] normalmente acabe por impedir que esta
atividade de suporte seja estruturada e formalizada de maneira similar a outras como, por
exemplo, o processo de matrícula, que atualmente encontra-se bem estruturado e
formalizado no ICMC.

A principal motivação deste projeto é a constante dificuldade com a alocação dos

horários do curso de Bacharelado em Informática que, por ser noturno, apresenta diversas
restrições quanto ao arranjo das disciplinas. Um dos objetivos é promover aos alunos que
possuem matérias atrasadas, isto é “fora do perfil” (veja definição na pagina 4) a
possibilidade de cursar um número maior de disciplinas com o objetivo de se formarem
com o mínimo de atraso possível, porém sem violar restrições pré-estabelecidas. Alguns
requisitos específicos do curso de Bacharelado em Informática, tais como o fato de
algumas disciplinas serem oferecidas apenas em dias específicos da semana, alunos que só
possuem disponibilidade no período noturno e disciplinas que são ministradas em um
único dia da semana (duas aulas consecutivas) tornam a alocação de sua grade horária uma
tarefa de complexidade notavelmente maior que a dos outros cursos do ICMC.

1
 Além do curso de Bacharelado em Informática, outros cursos apresentam suas
peculiaridades. Por exemplo, o curso de Bacharelado em Ciências de Computação possui
dificuldades como o fato de possuir duas ou mais turmas de cada disciplina. No curso de
Engenharia de Computação, o horário consecutivo das aulas deve levar em conta se a
disciplina é ministrada no campus I ou II, para haver tempo hábil do aluno chegar à sala de
aula.

A solução adotada atualmente pela coordenação de cada curso para alocação da

grade horária também é variável. Por exemplo, no curso de Bacharelado em Informática,
há alguns anos, os alunos preenchem uma planilha com as disciplinas que pretendem
cursar, ocorrem reuniões de alunos para discutir as possibilidades de alocação para
prejudicar o menor número possível de alunos e, em uma reunião final, os alunos elegem
um horário, em geral por meio de consenso. Entretanto, esse processo é cansativo e sujeito
a erros, não sendo possível garantir que o horário eleito é realmente o melhor.

Assim, um sistema computacional que auxilie e apoie a alocação da grade horária é

de grande valor para uma melhor elaboração e distribuição de horários dos cursos do
ICMC e, consequente, melhora do tempo de conclusão de curso dos alunos. Pode-se pensar
em soluções para o problema que atendam às necessidades comuns a todos os cursos, mas
que sejam factíveis de personalização para cada um deles em particular.

1.2. Objetivos

Este projeto tem o objetivo de estudar o problema de alocação de horários e as

particularidades apresentadas no ICMC, produzindo um modelo para solução do problema.
Pretende-se ainda caracterizar os problemas específicos de cada curso e documentá-los.
Futuramente um protótipo da solução proposta para o curso de Bacharelado em
Informática poderá ser implementado a fim de agilizar e melhorar a alocação da grade
horária. Esse protótipo poderá ser ainda estendido para atender outros cursos.

2
1.3. Organização do Trabalho

Esta monografia está dividida em 5 Capítulos. No Capítulo 1 é apresentada a

introdução, a motivação e os objetivos da monografia. No Capítulo 2 são citados alguns
trabalhos relacionados ao tema abordado e são descritos os conceitos envolvidos. No
Capítulo 3, o trabalho e as atividades desenvolvidos são apresentados, juntamente com os
resultados obtidos. No Capítulo 4 são apresentadas a conclusão e as propostas para
trabalhos futuros. Ao final são apresentadas as bibliografias citadas e, posteriormente dois
Apêndices.

3
CAPÍTULO 2: REVISÃO BIBLIOGRÁFICA

2.1. Conceitualização e Terminologia

Neste capitulo, são descritos conceitos específicos do domínio de alocação de

horários amplamente empregados nas explicações e descrições feitas no decorrer deste
trabalho. Portanto, o conhecimento destes é de vital importância para a compreensão das
metodologias adotadas e dos resultados alcançados.

A Carga Horária é o produto final da distribuição de disciplinas em horários pré-

estabelecidos, de acordo com diversas regras de escolhas, sendo também denominada
Grade Horária. O processo de distribuição da carga horária é também tratado como
alocação de horário ou alocação de disciplinas e nesta monografia tais termos são tratados
como sinônimos.

Uma disciplina é dita do perfil quando todos os alunos de um determinado período

letivo devem cursá-la. Duas ou mais disciplinas são equivalentes quando ambas são
igualmente aceitas pela Comissão de Graduação para a conclusão do curso.

Sobre os interessados no sistema, os coordenadores de curso serão os prováveis

usuários principais do sistema. Eles possuem o conhecimento de como é feita a
distribuição da carga horária, assim como, por meios objetivos ou subjetivos, a escala de
prioridades para alocação das disciplinas oferecidas. Os alunos formandos são todos e
quaisquer alunos que têm a possibilidade de se formar ao término do semestre corrente ou
do seguinte, ou seja, por a estrutura curricular ser semestral, é a última oportunidade destes
cursarem as disciplinas restantes antes de se formarem.

4
2.2. Trabalhos Relacionados

Em vários outros trabalhos referentes ao tema analisado, encontra-se uma grande

recorrência na adoção de abordagens inteligentes para a solução do problema da Alocação
de Horário em Escolas.

O problema de programação de horários em escolas foi estudado por Souza et al.

(2002) e propõe uma solução por uma técnica híbrida envolvendo Metaheurísticas,
Programação Genética, Busca Tabu e GRASP. Entretanto, a solução não pode ser
estendida ao contexto do ICMC por ser aplicável exclusivamente ao cenário de uma escola
de segundo grau que, diferentemente do ICMC, não considera os interesses individuais dos
alunos e pressupõe que não existem alunos fora do perfil.

O trabalho de Ribeiro Filho (2000) apresenta uma solução utilizando Algoritmos

Genéticos Construtivos para o problema da alocação de horários. Entretanto, tal
abordagem não utiliza Metaheurísticas, que geralmente sofrem muita influência da
condição inicial, isto é, uma boa solução inicial induz a um processo mais rápido e com
soluções melhores. Ainda assim, a solução apresentada considera turmas de alunos e não
considera interesses de alunos isoladamente e, portanto, também não pode ser aplicado ao
problema no cenário do ICMC.

No trabalho Skarabe (2007) é proposta uma solução por Algoritmos Genéticos

bastante geral que poderia ser adaptada ao cenário do ICMC. Entretanto, esse não
considera uma escala de prioridades, isto é, para os alunos algumas matérias têm maior
prioridade e, para os coordenadores de curso alguns alunos têm maior prioridade que
outros, por exemplo, alunos com média maior têm maior prioridade.

Ainda, Souza (2008) propõe, de forma simplificada, um modelo matemático para

otimização da alocação de horários que pode ser adaptado e aplicado às necessidades do
problema do cenário do ICMC.

5
CAPÍTULO 3: DESENVOLVIMENTO DO
TRABALHO
Neste capitulo são apresentados o projeto proposto, as atividades realizadas,
juntamente com os diagramas produzidos e os resultados obtidos.

3.1. Projeto

O projeto consiste no desenvolvimento de um sistema para apoio à alocação de

horários de aulas nos cursos do ICMC e visa auxiliar a melhor distribuição de horários para
que alunos fora do perfil consigam cursar o maior número de disciplinas possíveis,
minimizando os conflitos de horários, interesses e prioridades.

Desde o início, foi decidido que o projeto seguiria os métodos de análise e projeto
do paradigma de Orientação a Objetos, por apresentar vantagens quanto à abstração de
dados, a facilidade de estender o software futuramente devido à existência de herança e ao
acoplamento fraco mas, principalmente devido à maior dedicação à fase de análise
[PRESMAN, R. S. (2002) – pág. 266].

Na etapa inicial do projeto estudou-se o problema da alocação de horários nos

diversos cursos do ICMC, a fim de investigar as particularidades e semelhanças entre eles,
assim como as diversas abordagens aplicadas ao problema de alocação de horários em
escolas em geral, o que evidenciou que este problema é recorrente na computação e não
apresenta uma solução simples tampouco genérica [ABRAMSON, D. (1991)]. Diante de
tal fato, decidiu-se que seria necessário estabelecer processos sistemáticos para o
desenvolvimento do projeto e optou-se pelo Processo Unificado (PU), que é um processo
de software iterativo, cujo conjunto de atividades executadas visa transformar um conjunto
de requisitos do cliente em um sistema de software, podendo ser personalizado de acordo
com as necessidades específicas e recursos disponíveis [LARMAN, C. (2004)]. Na Figura
1 tem-se uma representação das disciplinas e do momento em que os vários artefatos foram
produzidos, no qual as etapas estão grafadas em negrito, as elipses pontilhadas representam

6
os artefatos e as setas pontilhadas indicam em quais fases os artefatos são produzidos ou
utilizados.

Figura 1: O Processo Unificado e os Artefatos produzidos.

Ainda na etapa inicial, foram determinadas muitas das ferramentas que seriam
utilizadas para auxiliar o processo produtivo do projeto: como o software Rational Rose
[IBM Rational Software™] para a modelagem Linguagem de Modelagem Unificada (do
inglês Unified Modeling Language [Unified Modeling Language™]) (UML), que
possibilita a geração do código inicial das classes de software, e o software Eclipse [The
Eclipse Foundation™] para o desenvolvimento do protótipo do sistema, que é um
Ambiente de Desenvolvimento Integrado (do inglês Integrated Development Enviroment)
completo e gratuito que interpreta os dados exportados pelo Rational Rose.

Na etapa de Modelagem de Negócios foram determinadas as necessidades do

sistema como um todo, envolvendo usuários, recursos e funcionalidades esperadas. A
partir desses dados e com enfoque no curso de Bacharelado em Informática, foram
produzidos o Documento de Requisitos (APÊNDICE A) e uma primeira versão da
Descrição dos Casos de Uso (versão final no APÊNDICE B). Na etapa de Requisitos, o
processo de especificação dos requisitos do sistema foi intensificado e os artefatos já
produzidos foram revisados a fim de explicitar melhor o domínio do problema e
funcionalidades esperadas. De posse das novas informações e dos artefatos revisados,

7
chegou-se a uma versão mais completa e aprimorada da Descrição dos Casos de Uso
(APÊNDICE B). Como resultado, foi produzido um Modelo Conceitual (Figura 3), no qual
são representados os conceitos importantes no domínio do sistema e as associações entre
esses. Nas várias etapas de Projeto, com base nos Casos de Uso e no Modelo Conceitual
determinados anteriormente, os conceitos e associações mais importantes foram modelados
em Diagramas de Sequência do Sistema (Figura 4). Nas várias etapas de Implementação,
foram implementados protótipos de segmentos do sistema, com base nas especificações
dos artefatos anteriormente produzidos.

3.2. Descrição das Atividades Realizadas

O projeto teve início com a revisão bibliográfica e pesquisas sobre o tema da

alocação de horários em escolas (Timetabling) e as diversas abordagens ao problema já
apresentadas na Seção 2.2, evidenciando que o problema é recorrente na área da
computação e da matemática e para o qual não existem modelos genéricos ou soluções
simples [ABRAMSON, D. (1991)]. Diante de tais fatos, foi revisada a literatura referente à
Engenharia de Software e os conceitos do paradigma de Modelagem Orientada a Objetos e
ficou claro que seria necessário estabelecer um processo sistemático para desenvolvimento
a fim de garantir que resultados consistentes fossem alcançados. Optou-se então por um
Processo de Software Iterativo baseado no Processo Unificado, cujo conjunto de atividades
executadas visa transformar um conjunto de requisitos do cliente em um sistema de
software, por meio de desenvolvimento iterativo, fortemente baseado em Casos de Uso e
centrado principalmente na arquitetura. Neste projeto especificamente, o Processo
Unificado foi personalizado de acordo com as necessidades específicas e os recursos
disponíveis [LARMAN, C. (2004) – pág. 46]. Sendo assim, as etapas de Modelagem de
Negócio e de Requisitos foram todas concentradas em um único ciclo, desenvolvido de
forma mais extensa e completa. Tal decisão foi tomada devido à natureza do problema, à
disponibilidade de tempo, à facilidade de obter informações referentes à especificação dos
requisitos do sistema e por ser o enfoque principal do projeto desde a sua concepção. Já as

8
etapas de projeto e implementação foram divididas em 7 iterações, cada uma delas tratando
um caso de uso diferente.

3.2.1 – Modelagem de Negócio

O projeto teve início com a primeira e única etapa de Modelagem de Negócio, que
envolve a modelagem de objetos do domínio e a modelagem dos processos de negócio
envolvidos. Foram realizadas várias entrevistas com coordenadores de cursos do ICMC a
fim de identificar de forma mais clara possível como atualmente é feita a distribuição da
carga horária em cada curso e, assim, compreender melhor o domínio do problema,
funcionalidades e processos, para possibilitar uma especificação correta e completa das
regras de negócio. Métodos, técnicas e procedimentos utilizados pelos responsáveis pela
alocação da carga horária em cada curso foram identificados, buscando-se explicitar os
pontos onde há maior dificuldade, lentidão e ambiguidade no processo como um todo.
Nesse ponto, averiguou-se que, entre os cursos ministrados no ICMC, o de Bacharelado em
Informática possui grandes dificuldades para a alocação da carga horária, por apresentar
disponibilidade de alocação somente no período noturno, juntamente com restrições de
disponibilidade de professores, particularidades nos horários ou nas disciplinas. Por esse
motivo, no desenvolvimento de todo o projeto, o curso de Bacharelado em Informática foi
utilizado como padrão para a modelagem. Além das entrevistas com a coordenação do
curso, foram também analisadas as planilhas utilizadas para auxiliar a elaboração de
horários desse curso, na qual os alunos informam as disciplinas que desejam cursar e a
carga horária é então alocada manualmente e os conflitos encontrados são exibidos. Nesta
planilha é possível perceber algumas dificuldades que precisam ser tratadas pelo sistema,
como o processo manual de alocação de horários e a ausência de formalização do método
utilizado.

Ao final do processo, foram documentadas as possíveis restrições para a

distribuição da carga horária do curso de Bacharelado em Informática, que são:

9
1. Uma disciplina específica não deve ser alocada em um ou mais dias da semana
ou horários previamente determinados. Por exemplo: a disciplina SEP-584:
Contabilidade para Computação, que não pode ser ministradas às sextas-feiras.

2. Uma disciplina específica deve ser alocada em um ou mais dias da semana ou

horários previamente determinado. Por exemplo: a disciplina SCC-540: Bases
de Dados que deve ser sempre ministrada às quartas-feiras.

3. Uma disciplina específica deve ser alocada em dois ou mais dias consecutivos.
Por exemplo: disciplina do último ano em que muitos alunos realizam estágio
em outras cidades e, por isso, precisam concentrar as disciplinas para terem
mais dias livres.

4. Uma disciplina específica deve ter todos seus créditos oferecidos em horários
coincidentes na semana. Por exemplo: todas as aulas no último horário, das
21:00 as 22:40.

5. Uma disciplina específica deve ter todos seus créditos oferecidos em horários
alternados na semana. Por exemplo: se uma das aulas for alocada no último
horário, das 21:00 as 22:40, a outra deverá ser alocada no primeiro horário, das
19:00 as 20:40.

6. Uma disciplina específica deve ter todos seus créditos oferecidos em um mesmo
dia da semana. Por exemplo, a disciplina Laboratório de Banco de Dados que
deve ter seus 4 créditos ministrados em um só dia.

7. Uma disciplina específica deve ter todos seus créditos oferecidos em horários
consecutivos. Por exemplo, disciplina que precisam de aulas duplas, que é o
caso das disciplinas essencialmente práticas.

8. Uma disciplina específica pode ter uma ou mais disciplinas equivalentes.

9. As disciplinas do perfil têm preferência máxima de alocação, pois as matérias

obrigatórias precisam ser alocadas sempre sem conflito.

10
 10. Certos alunos possuem disponibilidade de cursar disciplinas apenas no período
noturno. Por ser um curso noturno, muitos alunos trabalham durante o dia.

11. Um aluno específico pode declarar ter disponibilidade de cursar disciplinas

específicas em outras turmas, unidades ou horários, que apresentem disciplinas
equivalentes disponíveis.

12. Um aluno formando tem preferência sobre outros alunos na alocação das
disciplinas de seu interesse, pois aos alunos formandos normalmente resta
apenas uma quantidade reduzida de créditos por cursar.

Nas entrevistas, constatou-se que os demais cursos ministrados no ICMC possuem

apenas partes das restrições impostas ao curso de Bacharelado em Informática ou variações
bastante similares. Por esse motivo, será possível que a modelagem apresentada nesse
projeto possa ser aplicada nos demais cursos de uma forma similar ou mesmo simplificada.

Analisando as informações obtidas com as entrevistas e seguindo as diretivas

apresentadas na bibliografia analisada, foi produzido um Documento de Requisitos do
Sistema (APÊNDICE A), que explicita quais são os requisitos do sistema quanto a alguns
aspectos do domínio do problema e às funcionalidades esperadas.

3.2.2 – Análise de Requisitos

Na etapa seguinte teve início o único ciclo de Requisitos, que envolveu a

intensificação da análise dos requisitos a fim de obter-se uma maior compreensão do
domínio do problema, funcionalidades e processos e, assim, aprimorar e refinar as
especificações. Com novas entrevistas e valendo-se do Documento de Requisitos do
Sistema (APÊNDICE A) produzido anteriormente identificou-se que, nos cursos do ICMC,
a distribuição da carga horária leva em consideração principalmente três conceitos: os
alunos e seus interesses, as disciplinas oferecidas e a estrutura curricular e as prioridades e
restrições de alocação.

11
 Figura 2: Diagrama de Casos de Uso.

Analisando os resultados das entrevistas, validando-os com os coordenadores de

curso e seguindo os procedimentos apresentados na bibliografia revista, foi produzido o
Diagrama de Casos de Uso (Figura 2) e a Descrição de Casos de Uso (APÊNDICE B), que
demonstra uma sequência de eventos realizados para completar um processo durante o uso
do sistema; por exemplo, a inclusão de disciplinas, a alteração das informações de aluno, a
impressão da lista de prioridades, a alteração das prioridades, a exibição dos conflitos
gerados, entre outros.

No documento do APÊNDICE B, os Casos de Uso foram representados na forma

textual, pois essa representação possui maior clareza para os Casos de Uso mais
complexos. Foi utilizada também a forma Abstrata Resumida, sendo que apenas os Casos
de Uso de maior importância ou complexidade foram apresentados na forma Abstrata
Completa [LARMAN, C. (2004) – pág. 67-104]. O Documento de Requisitos do Sistema e
a Descrição de Casos de Uso foram então confrontados (Tabela 1) a fim de evidenciar
como as necessidades do sistema estão relacionadas com a sua utilização pelo usuário e,
12
assim, garantir que tais necessidades sejam satisfeitas sem a implementação de
funcionalidades ambíguas ou redundantes.

Tabela 1: Requisitos do Sistema e Casos de Uso.

Requisito Caso de Uso

R9 Iniciar o Programa
R2 Incluir Disciplina
R2 Alterar Disciplina
R2 Excluir Disciplina
R1 Incluir Aluno
R1 Excluir Aluno
R1, R3 Alterar informações de Aluno
R3 Alterar Interesse de Aluno
R1, R3 Excluir Interesse de Aluno
R4 Alterar Prioridades
R10 Exportar Alunos
R10 Exportar Disciplina
R10 Exportar Prioridades
R1, R11 Importar Aluno
R11, R2 Importar Disciplinas
R11, R4 Importar Prioridades
R7, R8 Sugerir Horário
R5 Imprimir lista de Alunos
R6 Imprimir lista de Interesses
R7 Imprimir Horário Sugerido
R8 Imprimir lista de Conflitos

Após novas entrevistas, correções e validações dos Documentos de Casos de Uso e

dos Requisitos do Sistema com os coordenadores de curso, os conceitos importantes do
domínio do problema, assim como as associações entre esses, foram estruturados no
Modelo Conceitual do Sistema, visando maximizar a clareza do vocabulário e da

13
terminologia do domínio envolvido. O Modelo Conceitual passou por diversas correções e
validações até que se atingisse a proposta da Figura 3, que foi a forma mais completa e
coesa de representar as relações entre os conceitos do sistema, para possibilitar o
entendimento destes e seus relacionamentos.

Figura 3: Modelo Conceitual.

Os principais conceitos identificados na Figura 3 são explicados a seguir. Eles

merecem maior destaque e explicações por serem os que mais influenciam a distribuição
da carga horária.

 Lista de Interesses é uma característica individual de cada aluno e reflete o seu

interesse em cursar disciplinas específicas, optativas ou obrigatórias, oferecidas
pelo ICMC;

 Disciplinas são todas as disciplinas oferecidas pelo ICMC e suas

particularidades individuais como: código, quantidade de créditos, quantidade
de dias em que é ministrada na semana, existência de pré-requisitos, período em
que é oferecida, entre outros;

14
  Prioridades Gerais refletem a importância atribuída pelos coordenadores de
curso, com base em conhecimentos prévios sobre quais critérios são de maior
relevância para a alocação da carga horária, como: disciplinas que apresentam
maior índice de aproveitamento quando ministradas em determinados horários;
a importância da média do aluno para o seu aproveitamento; a importância em
atender os interesses de alunos fora do perfil; a importância em atender os
interesses de alunos formandos entre outros. Tais fatores, em sua maioria, são
determinados de forma subjetiva, com procedimentos não formalizados ou
estruturados; e

 Hora Disponível representa quais horários são disponíveis para alocação de

disciplinas, quando uma sugestão de horário for requisitada. Por exemplo, o
curso de Bacharelado em Informática tem duas aulas consecutivas, de segunda a
sexta-feira, das 19:00 às 20:40 e das 21:00 às 22:40. Tal disponibilidade consta
no conceito de Hora Disponível.

3.2.3 – Projeto do Sistema

Nas etapas de Projeto, concentrou-se principalmente em algumas características do

programa a ser construído, tais como a estrutura de dados, a arquitetura do software, as
interfaces e detalhes procedimentais. Utilizando os artefatos produzidos até então e
realizando novas entrevistas a fim de identificar os detalhes estruturais, procedimentais e
funcionais envolvidos na alocação de horário, foram produzidos os Diagramas de
Sequência do Sistema (Figura 4) referentes às sequências de sucesso principal dos Casos
de Uso mais relevantes. Neste são mostrados os eventos que atores externos geram e os
eventos do sistema, tratado como uma caixa preta, evidenciando a dinâmica das
informações [LARMAN, C. (2004) – capítulo 9].

15
 Figura 4: Diagrama de Sequência do Sistema da operação Alterar Disciplina.

3.2.4 – Implementação do Sistema

Nas etapas de Implementação, que é a etapa de programação e construção do

sistema, protótipos de algumas partes do sistema foram implementados separadamente
utilizando-se como base os artefatos disponíveis para orientar e viabilizar a produção.

O protótipo desenvolvido não utiliza um conjunto de regras fixas, sendo possível

que um conjunto de alunos, disciplinas ou prioridades diferentes sejam carregados ou
salvos a qualquer momento. Ainda, é possível visualizar alunos e disciplinas que foram
cadastrados na sessão atual.

16
 Figura 5: Protótipo da visualização de alunos.

Figura 6: Protótipo da visualização de disciplinas.

Entretanto, apenas algumas prioridades e disciplinas mais simples foram

cadastrados com caráter de teste, sendo que o processo de mapeamento das prioridades e
regras por si só pode desdobrar-se em um novo projeto por demandar grande quantidade de

17
trabalho manual para catalogar todas as disciplinas, e de otimização matemática para
calibrar os pesos de modo a representar melhor a realidade de cada curso.

Nas várias iterações das disciplinas de Projeto e de Implementação, as atividades

descritas anteriormente foram feitas de modo cíclico. Em cada nova iteração utilizaram-se
os artefatos e resultados produzidos nos ciclos anteriores, aperfeiçoando-os, integrando-os
e corrigindo-os quando necessário. Isso levou a um sistema que está sendo submetido a
várias etapas de refinamento e revisão e com alto grau de modularidade. As etapas de
Projeto e Implementação abordaram em cada iteração as seguintes funcionalidades:

Iteração 1: Especificações de Disciplinas;

Iteração 2: Especificações de Alunos;

Iteração 3: Especificações de Lista de Interesses;

Iteração 4: Especificações de Hora disponível;

Iteração 5: Especificações de Prioridades;

Iteração 6: Especificações de Sugestão de horário;

Iteração 7: Detalhes globais de funcionalidade e integração.

Ainda assim, a implementação do protótipo não se encontra totalmente concluída,

devido à alta complexidade do projeto e sua pequena disponibilidade de tempo, sendo que
atualmente apenas as duas primeiras iterações (referentes às Disciplinas e aos Alunos)
foram abordadas. Espera-se que até a data de apresentação desta monografia mais
funcionalidades estejam implementadas e em trabalhos futuros seja possível estendê-lo,
completá-lo e aperfeiçoá-lo a fim de desempenhar todas as funções esperadas, de uma
forma otimizada e condizente com a realidade de cada curso e suas particularidades.

18
3.3. Resultados Obtidos

Os resultados obtidos do trabalho desenvolvido nesse projeto são: a modelagem de

negócio e as especificações de requisitos para o problema da alocação da carga horária
para o curso de Bacharelado em Informática do ICMC, cujo processo foi descrito na Seção
3.2 e toda a documentação referente à modelagem pelo Processo Unificado adotado são
apresentadas nos APÊNDICES A e B. O trabalho apresenta também um protótipo do
sistema modelado.

Ainda que o protótipo necessite de aprimoramento e maior grau de funcionalidade,

o projeto atingiu os resultados esperados visto que a proposta desta monografia é a
documentação e modelagem das particularidades dos cursos do ICMC-USP, especialmente
do curso de Bacharelado em Informática, e toda a parte de modelagem e análise foi
concluída e documentada.

19
CAPÍTULO 4: CONCLUSÃO

4.1. Aspectos Gerais

As atividades deste projeto de graduação tiveram como objetivo analisar a forma

como atualmente é feita a alocação de horários no ICMC. Utilizando-se de um processo de
software já consolidado (Processo Unificado), seguindo literaturas conceituadas sobre o
tema [LARMAN, C. (2004), PRESMAN, R. S. (2002)] e por meio de entrevistas,
validações e correções, propôs-se um modelo de sistema administrativo para auxiliar a
distribuição da grade horária juntamente com um protótipo baseado nesse modelo.

4.2. Contribuições

O projeto desenvolvido fornece todo o embasamento documental e modelagem para

o desenvolvimento de um sistema de auxílio aos coordenadores de curso do ICMC. Tal
produto virá a facilitar, agilizar e otimizar o processo de alocação da grade horária no curso
de Bacharelado em Informática, podendo ainda ser utilizados por outros cursos com um
pequeno grau de modificações.

4.3. Trabalhos Futuros

Como principais trabalhos futuros espera-se que as regras das diversas disciplinas
ministradas no ICMC sejam amplamente estudadas, analisadas e descritas a fim de que
possam ser modeladas e utilizadas pelo sistema proposto neste projeto da forma mais
completa possível. A lista de prioridades, com que a cargas horárias são atualmente
determinadas, precisam também ser extensivamente estudadas, analisadas e modeladas
para que, futuramente, uma melhor calibragem dos pesos, mais condizente com a realidade
de cada curso e com os interesses de alunos e docentes envolvidos, possa ser determinada.
Tal calibragem envolverá grande esforço de otimização matemática dos pesos atribuídos às

20
diversas prioridades envolvidas juntamente com a relevância de cada prioridade para a
confecção de uma sugestão de horário.

O trabalho atual enfocou as particularidades do curso de Bacharelado em

Informática mas espera-se que, em trabalhos futuros, o protótipo apresentado possa ser
estendido, completado e aperfeiçoado a fim de desempenhar todas as funções da
modelagem proposta, assim como eventuais extensões para outros cursos do ICMC
juntamente com otimizações que garantam maior agilidade ao processo de alocação da
carga horária.

21
REFERÊNCIAS
ABRAMSON, D. (1991), “Constructing School Timetables Using Simulated
Annealing: Sequential and Parallel Algorithms”, Management Science, 37:98-113.
Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.17.302>.
Acessado em: 29/04/2009.

BRAZ, O. O. (2000), “Otimização de Horários em Instituições de Ensino Superior

Através de Algoritmos Genéticos.” Disponível em:
<http://biblioteca.universia.net/ficha.do?id=595224>. Acessado em: 02/04/2009.

IBM Rational Software™. Disponível em: <http://www-

01.ibm.com/software/awdtools/developer/rose/>. Acessado em 25/05/2008.

LARMAN, C., “Utilizando UML e Padrões – Uma Introdução à Análise e ao

Projeto Orientado a Objetos e ao Processo Unificado”, 2º ed., Bookman, 2004

PRESSMAN, R. S., “Engenharia de Software”, 5º ed., Mc Graw Hill, 2002

RIBEIRO FILHO, G. (2000), "Melhoramentos no algoritmo genético construtivo e

novas aplicações em problemas de agrupamento", p.85-100. Disponível em:
<http://www.lac.inpe.br/~lorena/geraldo/tese-geraldo.pdf>. Acessado em 22/05/2009.

SCHAEFER, A. (1999), “A survey of automated timetabling” Disponível em:

<http://www.teiser.gr/arximidis/pdf/kazarlis/PE1/1d.pdf>. Acessado em 01/05/2009.

SKRABE, M. S (2007), “Avaliação das Aplicação de Algoritmos Genéticos no

Problema da Grade Horária” Disponível em: <http://nead.feevale.br/tc/files/1013.doc>.
Acessado em 20/05/2009.

SOUZA, M. J. F. (2008), "Otimização Combinatória" p. 32. Disponível em:

<http://www.decom.ufop.br/prof/marcone/Disciplinas/OtimizacaoCombinatoria/Otimizaca
oCombinatoria.pdf>. Acessado em 01/05/2009.

22
 SOUZA, M. J. F.; GUIMARÃES, I. F.; COSTA, F. P (2002), "Um Algoritmo
Evolutivo Híbrido para o Problema de Programação de Horários em Escolas." -
Disponível em: < http://www.decom.ufop.br/prof/marcone/Publicacoes/ENEGEP-2002-
PHE.pdf>. Acessado em 05/05/2009.

The Eclipse Foundation™. Disponível em: <http://www.eclipse.org/>. Acessado

em 27/05/2008.

Unified Modeling Language™. Disponível em: <http://www.uml.org/>. Acessado

em 27/05/2008.

23
APÊNDICE A – Documento de Requisitos

A) VISÃO GERAL DO SISTEMA

O sistema para Sugestão de Horários visa auxiliar os coordenadores de curso do

ICMC-USP na distribuição da carga horária em cada semestre, a fim de melhorar e agilizar
a formulação da grade horária por meio de auxílio computacional, levando em
consideração possíveis conflitos de interesse, como alunos fora do perfil, disciplinas
oferecidas apenas em um dia da semana e outros.

A distribuição da grade horária leva em consideração o INTERESSE dos alunos

(estejam eles no perfil ou não), a estrutura curricular e as regras das DISCIPLINAs; todos
estes subordinados às PRIORIDADES determinada pelo usuário do sistema (que
normalmente será o coordenador de curso).

B) REQUISITOS FUNCIONAIS

Dados do Sistema

R1) O sistema deve permitir incluir, alterar e remover os ALUNOs interessados.

R2) O sistema deve permitir incluir, alterar e remover as DISCIPLINAs oferecidas.
R3) O sistema deve permitir incluir, alterar e remover as DISCIPLINAs da lista de
INTERESSEs de qualquer ALUNO.
R4) O sistema deve permitir alterar as PRIORIDADES desejadas.

Impressão de Relatórios

R5) O sistema deve permitir imprimir a lista dos ALUNOs cadastrados, que pode ou
não ter suas respectivas listas de Interesses anexada.
R6) O sistema deve permitir imprimir as listas de INTERESSEs cadastrados.

24
 R7) O sistema deve permitir imprimir o HORÁRIO SUGERIDO após o
processamento, tendo alocado em cada horário de cada período a uma
disciplina do período correspondente.
R8) O sistema deve permitir imprimir a lista de CONFLITOS resultantes do
HORÁRIO SUGERIDO em questão, que pode ou não estar anexado, mediante
escolha do usuário.

C) REQUISITOS NÃO FUNCIONAIS

Usabilidade

R9) Ao ser iniciado, o sistema deve oferecer a opção de utilizar as mesmas

configurações de DISCIPLINAs, PRIORIDADEs ou INTERESSEs da última
sessão ou iniciar uma sessão nova.
R10) O sistema deve fornecer meios para exportar DISCIPLINAs, PRIORIDADEs,
INTERESSEs para arquivo.
R11) O sistema deve fornecer meios para importar DISCIPLINAs, PRIORIDADEs,
INTERESSEs de arquivo.

D) Requisitos específicos do Bacharelado em Informática

 Uma DISCIPLINA específica não pode ser alocada em um dia da semana ou

horário previamente determinado.
 Uma DISCIPLINA específica deve ser alocada em dia da semana ou horário
previamente determinados.
 Uma DISCIPLINA específica deve ter todos seus créditos oferecidos em horários
coincidentes na semana.
 Uma DISCIPLINA específica deve ter todos seus créditos oferecidos em horários
alternados na semana.
 Uma DISCIPLINA específica deve ter todos seus créditos oferecidos em um mesmo
dia da semana.
 Uma DISCIPLINA específica deve ter todos seus créditos oferecidos em horários
consecutivos.
 Uma DISCIPLINA específica possui uma ou mais DISCIPLINAs equivalentes.

25
  As DISCIPLINAs do perfil têm maior PRIORIDADE de alocação.
 Os ALUNOs possuem disponibilidade de cursar DISCIPLINAs apenas no período
noturno.
 Um ALUNO específico pode declarar ter disponibilidade de cursar DISCIPLINAs
específica em outras turmas, unidades ou horários.
 Um ALUNO formando tem maior PRIORIDADE na alocação das DISCIPLINAs de
seu INTERESSE.

Glossário

Termo Descrição

ALUNO Informações referentes aos ALUNOs que irão cursar as

DISCIPLINAs oferecidas, como: nome, número USP, e-mail,
ano de ingresso, se é aluno formando, média, horários q tem
disponível, total de créditos pretendidos e lista de INTERESSEs.

PESO Valor numérico (diferente de zero) que é atribuído a cada item

da lista de PRIORIDADEs. Quanto maior o valor do peso
atribuído, maior será a prioridade dada ao item relacionado para
alocação na grade horária.

grade horária Tabela que mostra quais disciplinas são oferecidas em cada
horário, de cada período.

DISCIPLINA Informações referentes às DISCIPLINAs oferecidas, como:

nome, código, período a que pertence, quantidade de créditos
semanais, quantidades de dias em que é ministrada na semana,
se possui equivalentes (na mesma ou em outras unidades da
USP) e quais, se possui horários alternativos e quais e
observações adicionais.

exportar Salva informações cadastradas na sessão corrente para um

26
 arquivo (possivelmente texto ou XML).

HORÁRIO SUGERIDO Grade horária produzida pelo sistema após processamento dos
INTERESSEs e DISCIPLINAs, submetidos às PRIORIDADES.

importar Adiciona à sessão corrente informações salvas em um arquivo

existente (possivelmente texto ou XML).

INTERESSE Lista das DISCIPLINAS pretendidas por um determinado aluno.

CONFLITOS Lista com os INTERESSEs que não foram incluídos no

HORÁRIO SUGERIDO. Exemplo: aparecerão na lista de
CONFLITOs dos ALUNOs que cadastraram INTERESSE em
cursar DISCIPLINAs que tiveram seus HORÁRIO SUGERIDO
coincidem.

PRIORIDADES Lista contendo: todos os ALUNOs cadastrados, com cada item

de sua lista de INTERESSE, média, se é aluno formando, ano de
ingresso e total de créditos pretendidos; e os pesos relacionados
a cada item dessa lista. Os PESOs são utilizados para gerar o
HORÁRIO SUGERIDO.

27
APÊNDICE B – Descrição de Casos de Uso

Caso de Uso: “Iniciar o programa”

Visão Geral: o usuário inicia o programa. Ele é questionado se deseja utilizar as

mesmas configurações da última execução do programa. Ele escolhe que sim e as
disciplinas, interesses e prioridades utilizados na última execução são carregados.

Caso de Uso: “Incluir disciplina”

Visão Geral: o usuário deseja incluir manualmente uma nova disciplina. Ele acessa
a lista de disciplinas cadastradas e escolhe a opção de incluir uma nova. Uma nova tela é
exibida, com os campos correspondentes às informações da nova disciplina, para que seja
preenchida. Após ter preenchido as informações da nova disciplina, ele aprova a operação.
A nova disciplina é incluída na lista de disciplinas cadastradas.

Caso de Uso: “Alterar disciplina”

Ator Principal: usuário

Interessados e Interesses: Usuário: deseja alterar, adicionar ou excluir informações

de uma disciplina.

Pré-condições: ter pelo menos 1 disciplina cadastrada.

Pós-condições: as novas informações da disciplina são gravadas no sistema.

Cenário de Sucesso Principal:

1. O usuário seleciona a disciplina cujas informações deseja alterar.

28
2. O sistema exibe as operações que podem ser realizadas.
3. O usuário escolhe a opção referente à alteração de dados.
4. O sistema exibe uma planilha preenchida com as informações atualmente cadastradas e
estas podem ser livremente alteradas, adicionadas ou excluídas.
5. O usuário altera, adiciona ou exclui as informações desejadas.
6. O usuário seleciona a opção de salvar as modificações feitas.
7. O sistema avisa que as modificações são irreversíveis e confirma o desejo de salvar as
novas informações.
8. O usuário confirma a intenção de salvar as novas informações.
Fluxos Alternativos:

(1-8). Em qualquer momento o usuário pode escolher cancelar a operação e

descartar as alterações.

Caso de Uso: “Excluir disciplina”

Visão Geral: o usuário deseja excluir uma disciplina já cadastrada. Ele acessa a lista
de disciplinas cadastradas, escolhe qual disciplina deseja excluir e aprova a operação. Ele é
informado que a exclusão é irreversíveis e confirma a aprovação da exclusão. A disciplina
escolhida é removida da lista de disciplinas cadastradas.

Caso de Uso: “Incluir aluno”

Visão Geral: o usuário deseja incluir manualmente um aluno interessado em cursar

disciplinas. Ele acessa a lista de alunos e escolhe a opção de incluir um novo aluno. Uma
nova tela é exibida, com os campos correspondentes às informações do novo aluno, para
que seja preenchida. Após ter preenchido as informações do novo aluno, o usuário deve
adicionar pelo menos uma disciplina na lista de interesse desse. Após preencher todas as
informações requeridas ele aprova a operação. O novo aluno é incluído na lista de alunos
cadastrados e na tabela de prioridades juntamente com seus interesses.

29
 Caso de Uso: “Excluir aluno”

Visão Geral: o usuário deseja excluir um aluno já cadastrado. Ele acessa a lista de
alunos cadastrados, seleciona o aluno desejado, escolhe a opção de excluir e aprova a
exclusão. Ele é informado que a exclusão é irreversível e confirma a aprovação da
exclusão. O aluno escolhido é excluído da lista de alunos cadastrados e da tabela de
prioridades juntamente com seus interesses.

Caso de Uso: “Alterar informações do aluno”

Ator Principal: usuário

Interessados e Interesses: Usuário: deseja alterar, adicionar ou excluir informações

de um aluno.

Pré-condições: ter pelo menos 1 aluno e 1 disciplina cadastrados.

Pós-condições: as novas informações do aluno são gravadas no sistema.

Cenário de Sucesso Principal:

1. O usuário seleciona o aluno cujas informações deseja alterar.

2. O sistema exibe as operações que podem ser realizadas.
3. O usuário escolhe a opção referente à alteração de dados.
4. O sistema exibe uma planilha preenchida com as informações atualmente cadastradas
(a lista de interesses pode ser exibida ou escondida para facilitar a visualização e evitar
alterações acidentais) e estas podem ser livremente alteradas, adicionadas ou excluídas.
5. O usuário altera, adiciona ou exclui as informações desejadas.
6. O usuário seleciona a opção de salvar as modificações feitas.
7. O sistema avisa que as modificações são irreversíveis e confirma o desejo de salvar as
novas informações.
8. O usuário confirma a intenção de salvar as novas informações.

30
 Fluxos Alternativos:

(1-8). Em qualquer momento o usuário pode escolher cancelar a operação e

descartar as alterações.

5 O usuário exclui todos os itens da lista de interesses do aluno.

5.1 O sistema avisa que alunos sem interesses são automaticamente removidos
da lista de alunos cadastrados e oferece a possibilidade de restaurar o último item
excluído.

Caso de Uso: “Alterar interesse de aluno”

Visão Geral: veja caso de uso “Alterar informações de aluno”

Caso de Uso: “Excluir interesse de aluno”

Visão Geral: veja caso de uso “Alterar informações de aluno”

Caso de Uso: “Alterar prioridades”

Ator Principal: usuário

Interessados e Interesses: Usuário: deseja alterar as prioridades.

Pré-condições: ter pelo menos 1 item na tabela de prioridade.

Pós-condições: as novas informações das prioridades são gravadas no sistema.

Cenário de Sucesso Principal:

1. O usuário escolhe a opção referente à alteração das prioridades.

31
2. O sistema exibe uma planilha preenchida com as prioridades atuais e estas podem ser
livremente alteradas.
3. O usuário altera ou exclui as informações desejadas.
4. O usuário seleciona a opção de salvar as modificações feitas.
5. O sistema avisa que as modificações são irreversíveis e confirma o desejo de salvar as
novas informações.
6. O usuário confirma a intenção de salvar as novas informações.
Fluxos Alternativos:

(1-6). Em qualquer momento o usuário pode escolher cancelar a operação e

descartar as alterações.

Caso de Uso: “Exportar alunos”

Visão Geral: o usuário deseja exportar um aluno atualmente cadastrado. Ele

informa qual aluno cadastrado deseja exportar, o local para onde deseja exportá-lo, o nome
do arquivo que será criado com as informações do aluno e aprova a operação. Um arquivo
é criado, com as informações do aluno escolhido, no local especificado.

Caso de Uso: “Exportar disciplina”

Visão Geral: o usuário deseja exportar uma disciplina atualmente cadastrada. Ele
informa qual disciplina cadastrada deseja exportar, o local para onde deseja exportá-la, o
nome do arquivo que será criado com as informações da disciplina e aprova a operação.
Um arquivo é criado, com as informações da disciplina escolhida, no local especificado.

Caso de Uso: “Exportar Prioridades”

Visão Geral: o usuário deseja exportar a tabela de prioridades atual. Ele informa o
local para onde deseja exportá-la, o nome do arquivo que será criado com as informações e
32
aprova a operação. Um arquivo é criado, com as informações atuais das prioridades, no
local especificado.

Caso de Uso: “Importar aluno”

Visão Geral: o usuário deseja importar alunos de arquivo. Ele informa onde se
encontram os arquivos que deseja importar, escolhe os arquivos desejados e aprova a
operação. As informações dos alunos nos arquivos escolhidos são adicionadas à lista de
alunos cadastrados.

Caso de Uso: “Importar disciplinas”

Visão Geral: o usuário deseja importar disciplinas de arquivo. Ele informa onde se
encontram os arquivos que deseja importar, escolhe os arquivos desejados e aprova a
operação. As informações das disciplinas nos arquivos escolhidos são adicionadas à lista
de disciplinas cadastradas.

Caso de Uso: “Importar prioridades”

Visão Geral: o usuário deseja importar as informações da tabela de prioridades de

um arquivo. Ele informa onde se encontra o arquivo que deseja importar, escolhe o arquivo
com as informações desejadas e aprova a operação. Os valores atuais da tabela de
prioridades são substituídos pelos presentes no arquivo escolhido.

Caso de Uso: “Obter sugestão de horário”

Visão Geral: o usuário deseja obter uma sugestão de horário para as disciplinas e
interesses cadastrados. Tendo preenchido os pesos da tabela de prioridades, o usuário

33
escolhe a opção de sugerir horário. Uma sugestão de horário é apresentada após o
processamento.

Caso de Uso: “Imprimir lista de alunos”

Visão Geral: o usuário deseja imprimir a lista de alunos cadastrados. Ele escolhe
visualizar a lista de alunos cadastrados e, então, escolhe a opção de imprimi-la. Se ele
desejar, pode também adicionar à impressão as listas de Interesses dos alunos. Ele aprova a
operação de impressão e a lista de alunos (com ou sem os respectivos interesses) é
impressa.

Caso de Uso: “Imprimir lista de interesses”

Visão Geral: o usuário deseja imprimir a lista geral de interesses. Ele escolhe
visualizar a lista geral de interesses e, então, escolhe a opção de imprimi-la. Ele aprova a
operação de impressão e a lista geral de interesses é impressa.

Caso de Uso: “Imprimir horário sugerido”

Visão Geral: o usuário deseja imprimir o horário sugerido atual. Ele escolhe
visualizar o horário sugerido e, então, escolhe a opção de imprimí-lo. Ele aprova a
operação de impressão e horário sugerido atual é impresso.

Caso de Uso: “Imprimir lista de conflitos”

Visão Geral: o usuário deseja imprimir a lista de conflitos para o horário sugerido atual.
Ele escolhe visualizar a lista de conflitos e, então, escolhe a opção de imprimi-la. Se ele
desejar, pode também adicionar à impressão o horário sugerido que gerou a lista de

34
conflitos atual. Ele aprova a operação de impressão e a lista de conflitos (com ou sem o
horário sugerido) é impressa.

35