sgs - protÓtipo de um sistema de gerenciamento de salas para o campus universitÁrio do araguaia

UNIVERSIDADE FEDERAL DE MATO GROSSO

CAMPUS UNIVERSITRIO DO ARAGUAIA

INSTITUTO DE CINCIAS EXATAS E DA TERRA

BACHARELADO EM CINCIA DA COMPUTAO

MURILO HENRIQUE DA SILVA RIBEIRO

SGS - PROTTIPO DE UM SISTEMA DE GERENCIAMENTO DE SALAS PARA O


Barra do Garas - MT

2013

i








Orientadora: Prof. Dra. Lvia Lopes Azevedo.

Monografia apresentada ao Instituto de

Cincias Exatas e da Terra do Campus

Universitrio do Araguaia, da Universidade

Federal de Mato Grosso, como requisito

parcial para concluso do Curso de Graduao

em Cincia da Computao.

Barra do Garas - MT

2013

ii








Aprovada em ___/___/___

______________________________________

Prof. Dra. Lvia Lopes Azevedo

ICET/UFMT

(Orientadora)

______________________________________

Prof. Dr. Jos Marques Pessoa

ICET/UFMT

______________________________________

Prof. Me. Maxweel Silva Carmo

ICET/UFMT

iii

Este trabalho dedicado ao meu Senhor Deus,

que sem a tua presena eu no estaria

realizando este grande objetivo. Em especial

dedico esse trabalho a minha famlia: a minha

me por toda dedicao, ao meu pai por todo

empenho e a minha irm por sempre me

apoiar.

iv

AGRADECIMENTOS

Agradeo a Deus pela oportunidade de viver, pela f e fora que se renovam a cada

obstculo vencido. Sem a tua presena jamais teria chegado a viver o que estou vivendo nesse

momento.

A minha orientadora, Professora Lvia Lopes Azevedo a quem estimo, tanto como

profissional quanto pessoa. Muito obrigado pelos ensinamentos e pacincia em sempre me

ajudar nas atividades mais complexas e pelo tempo dedicado para que finalizssemos este

trabalho.

Aos profissionais da UFMT que, direta e indiretamente, contriburam para a realizao

deste trabalho, especialmente a Superviso de Administrao e Planejamento e aos docentes

do curso de Cincia da Computao, por todo aprendizado adquirido ao longo desses anos.

Aos meus colegas de curso e amigos, pelo conhecimento compartilhado e pelos

momentos de diverso. Agradeo em especial ao graduando Vinicius Fernandes Brito, por

todo apoio e suporte para que esse trabalho se tornasse realidade.

A Ana Clara Rodrigues de Souza, por ter-me feito enxergar a vida de uma forma

diferente a partir do momento em que comeou a fazer parte da minha vida e por todo

carinho, amor e companheirismo nestes ltimos anos ao meu lado.

E, por fim, agradeo minha famlia, cuja nunca saiu do meu lado e sempre me apoiou.

Sem eles no teria a chance de realizar este grande sonho de me graduar no curso de Cincia

da Computao, espero sempre retribuir a todo o sacrifcio feito.

v

RESUMO

Frente a algumas das dificuldades administrativas existentes na Superviso de Administrao

e Planejamento do Campus Universitrio do Araguaia - SAP, tanto no mbito administrativo

quanto pedaggico, com relao alocao de espao fsico para atividades pedaggicas, em

particular a alocao de salas de aula, surge necessidade de implantar um sistema de

gerenciamento de espao fsico. Este trabalho apresenta o prottipo de um sistema Web para

gerenciamento de salas SGS, que tem como objetivo principal atender necessidade da SAP

com relao alocao de espaos fsicos do Campus, alm de possibilitar o armazenamento

e disponibilizao das informaes referentes ao processo de distribuio de salas. Sendo um

sistema Web, permitir comunidade acadmica a visualizao das informaes de diferentes

locais atravs da Internet. Para proporcionar a melhor utilizao do sistema pela SAP foram

aplicadas tcnicas de Interao Humano Computador. O sistema permite a localizao e a

agenda dos espaos fsicos, com a descrio de horrios e dias de utilizao das salas. A

disponibilizao desses dados pela Internet possibilita o acesso remoto dos usurios e da

administrao, contribuindo com o aperfeioamento do processo de distribuio de salas. O

sistema foi testado e atendeu as expectativas propostas.

vi

LISTA DE ABREVIATURAS E SIGLAS

CUA Campus Universitrio do Araguaia

CSS Cascading Style Sheets

HTML Hypertext Markup Language

IHC Interao Humano Computador

MER Modelo Entidade-Relacionamento

PHP Hypertext Preprocessor

SAP Superviso de Administrao e Planejamento

SGBD Sistema Gerenciador de Banco de Dados

SGS Sistema Gerenciador de Salas

SIG Sistema de Informao de Gesto

SQL Structured Query Language

UFMT Universidade Federal de Mato Grosso

UML Unified Modeling Language

XML eXtensible Markup Language

vii

LISTA DE FIGURAS

Figura 1 - Atributos de aceitabilidade de sistemas (adaptado de NIELSEN, 1993) ............... 18

Figura 2 - Funcionalidade do SGS .......................................................................................... 24

Figura 3 - Atores do sistema .................................................................................................... 26

Figura 4 - Diagrama de caso de uso para o SGS. .................................................................... 27

Figura 5 - Casos de uso do ator usurio pblico ..................................................................... 27

Figura 6 - Casos de uso do ator coordenador .......................................................................... 28

Figura 7 - Casos de uso do ator SAP ....................................................................................... 29

Figura 8 - Diagrama de classe ................................................................................................. 31

Figura 9 - Classe sala ............................................................................................................... 32

Figura 10 - Diagrama de sequncia manter usurio ................................................................ 34

Figura 11 - Modelo entidade relacionamento (MER) do SIG ................................................. 35

Figura 12 - Representao dos dados do sistema no banco de dados ..................................... 37

Figura 13 - Funcionamento da tecnologia Web para acesso a um Website ............................. 38

Figura 14 - Esquema do funcionamento de uma pgina Web em PHP ................................... 40

Figura 15 - Pgina de acesso ao SGS ...................................................................................... 43

Figura 16 - Salas ocupadas pelo curso cincia da computao ............................................... 44

Figura 17 - Agenda da sala ...................................................................................................... 45

Figura 18 - Formulrio para usurio pblico solicitar reserva ................................................ 46

Figura 19 - Pgina inicial da rea de acesso da categoria coordenador .................................. 47

Figura 20 - Exemplo de cadastro de uma demanda. ................................................................ 47

Figura 21 - Pgina inicial da rea de acesso da categoria SAP ............................................... 48

Figura 22 - Pgina de cadastro de salas ................................................................................... 49

Figura 23 - Pgina das solicitaes de reserva eventual.......................................................... 50

Figura 24 - Visualizar uma solicitao .................................................................................... 51

Figura 25 - Localizar salas ...................................................................................................... 52

Figura 26 - Reserva fixa .......................................................................................................... 53

Figura 27 - Busca por salas ..................................................................................................... 54

Figura 28 - Exemplo de reserva fixa ....................................................................................... 55

viii

LISTA DE TABELAS

Tabela 1 - Documentao do caso de uso visualizar salas ...................................................... 60

Tabela 2 - Documentao do caso de uso solicitar reserva de sala ......................................... 60

Tabela 3 - Documentao do caso de uso manter demanda .................................................... 61

Tabela 4 - Documentao do caso de uso realizar login ......................................................... 61

Tabela 5 - Documentao do caso de uso visualizar demanda ................................................ 62

Tabela 6 - Documentao do caso de uso manter salas ........................................................... 62

Tabela 7 - Documentao do caso de uso manter reserva ....................................................... 63

Tabela 8 - Documentao do caso de uso manter usurios ..................................................... 63

Tabela 9 - Documentao do caso de uso realizar login ......................................................... 64

ix

SUMRIO

1. INTRODUO ................................................................................................................. 11

2. INTERAO HUMANO COMPUTADOR - IHC .......................................................... 14

2.1 Desafios de IHC ............................................................................................................ 15

2.2 Objetivos de IHC .......................................................................................................... 17

2.2.1 Aceitabilidade de Sistema...................................................................................... 18

2.3 Interface de Sistemas .................................................................................................... 19

2.4 Conceito de Interface .................................................................................................... 20

2.5 Usabilidade na WEB ..................................................................................................... 21

3. MODELAGEM E DESENVOLVIMENTO DO SISTEMA ............................................ 24

3.1 Diagramas de Caso de Uso ........................................................................................... 25

3.1.1 Atores ..................................................................................................................... 25

3.1.2 Casos de Uso.......................................................................................................... 26

3.2 Requisitos Funcionais do Sistema ................................................................................ 27

3.3 Diagrama de Classe ...................................................................................................... 30

3.4 Diagrama de Interao .................................................................................................. 32

3.4.1. Diagrama de Sequncia ......................................................................................... 32

3.5 Modelagem dos dados .................................................................................................. 34

3.6 Tecnologias Utilizadas na Implementao do Prottipo .............................................. 38

3.6.1. Linguagem de Programao PHP .......................................................................... 39

3.6.2. HyperText Markup Language - HTML ................................................................. 40

3.6.3. Cascading Style Sheet - CSS ................................................................................. 41

3.6.4. Javascript ............................................................................................................... 41

3.6.5. Banco de Dados - MySQL ..................................................................................... 41

4. FUNCIONALIDADES DO SISTEMA ............................................................................ 43

5. CONSIDERAES E TRABALHOS FUTUROS .......................................................... 56

6. REFERNCIAS BIBLIOGRFICAS .............................................................................. 57

x

7. ANEXO A ......................................................................................................................... 60

7.1 Documentao Casos de Uso ........................................................................................ 60

11

1. INTRODUO

O Campus Universitrio do Araguaia - CUA/UFMT oferece, atualmente 16

(dezesseis) cursos de graduao e 4 (quatro) cursos de ps-graduao distribudos entre duas

unidades, uma situada na cidade de Barra do Garas e a outra situada na cidade de Pontal do

Araguaia.

A administrao de um Campus equivale ao de uma cidade. No caso particular do

CUA, apesar de ser um nico Campus, mas com duas unidades distintas e distantes uma da

outra, surgem diversas dificuldades de gerenciamento. Entre essas, destaque ser dado s

dificuldades de comunicao, tanto no campo administrativo quanto no pedaggico. Com

relao a algumas das dificuldades administrativas de comunicao, sero apontadas quelas

relacionadas alocao de espao fsico para atividades pedaggicas, em particular a alocao

de salas de aula.

O controle da distribuio de salas de responsabilidade da Superviso de

Administrao e Planejamento - SAP. Atualmente este processo realizado por meio de

planilhas e tabelas, que so preenchidas e controladas manualmente. Desse modo os dados

relacionados aos espaos fsicos existentes no Campus e a distribuio das salas de aula para

as turmas de cada curso esto armazenados em arquivos de texto simples.

A SAP, por meio dos dados existentes e, contando com a experincia adquirida em

processos anteriores, distribui as salas de aulas entre os cursos existentes no CUA de forma

aleatria, mas procurando criar um padro de otimizao, ou seja, mantendo prximo as

disciplinas de um mesmo curso. Entretanto esse processo no possibilita uma comunicao

contnua entre as entidades de interesse: Administrao, Institutos e Cursos. Em geral, at o

encerramento deste processo, so geradas inmeras reclamaes, constante necessidade de

alteraes e morosidade no seu desenvolvimento, alm de discordncia com o resultado final

da distribuio de salas.

Outro fator que interfere no processo de distribuio/alocao das salas de aula que

as solicitaes dos espaos pelos coordenadores de curso e ou diretores de instituto1, na

maioria das vezes, no acontece com antecedncia necessria ao incio de cada perodo letivo.

Essa defasagem de tempo impe a SAP a necessidade de realizar a distribuio de salas de

forma inconsistente aos interesses do curso.

1 As solicitaes de alocao de sala de aula, em geral, so realizadas pelos coordenadores de curso,

mas no h impedimento de haver solicitao pelos diretores.

12

Analisando o processo de alocao de sala do ponto de vista da SAP, constatam-se as

seguintes dificuldades: falta de comunicao entre a administrao e os solicitantes; mau

armazenamento e divulgao dos dados e, principalmente, a falta de uma ferramenta

especfica para auxiliar no processo de alocao. Todas essas dificuldades contribuem para

que se torne difcil o controle da alocao e distribuio de salas medida que o crescimento

do Campus avana.

Tambm importante destacar que o processo de distribuio de salas gera uma

grande quantidade de dados que necessita ser armazenada, tratada e disponibilizada para toda

comunidade acadmica. O armazenamento local dos dados em arquivos simples (tabelas ou

arquivos textos, por exemplo) dificulta a anlises dos dados e as buscas, alm de colocar em

risco a integridade e a persistncia das informaes.

Sentindo a necessidade de melhorar o armazenamento, a manipulao e a divulgao

das informaes relacionadas ao processo de gerenciamento de salas realizado pela SAP no

CUA, foi proposta a implementao de um prottipo de Sistema de Informao, em particular

um Sistema de Informao Gerencial2 - SIG web. Esse prottipo, alm de dar suporte

administrao dever utilizar tcnicas de Interface Humano Computador - IHC, o que

possibilitar acessibilidade ao sistema e efetivo uso do mesmo. Tecnicamente, esse sistema

dever possibilitar o auxlio no armazenamento e na divulgao dos dados e, em se tratando

de um sistema web, o fcil compartilhamento e gerenciamento de informaes de diferentes

locais, bem como interfaces amigveis aos usurios.

O elemento principal de um SIG a informao. Segundo (LAUDON, et al., 1999) o

objetivo principal de um SIG consiste em armazenar, tratar e fornecer informaes de modo a

apoiar as funes ou processos de uma organizao. Segundo ele, a informao um fator

decisivo na gesto em escala de organizaes, por se tratar de um recurso importante e

indispensvel tanto no contexto interno como no relacionamento com o exterior. Nesse

sentido, a utilizao de um SIG prov inmeras vantagens tais como: otimizao do fluxo de

informao permitindo mais agilidade e organizao; reduo de custos operacionais e

administrativos e ganho de produtividade; integridade e veracidade; estabilidade e segurana

de acesso informao. Os SIGs so projetados para servir no monitoramento, controle,

tomada de deciso e atividades administrativas dos gerentes. O conceito para desenvolver

interfaces amigveis o da usabilidade.

2 Sistema de informao de gesto ou sistema de informaes gerenciais (SIG; do ingls, management

information system - MIS) um sistema de informao, tipicamente baseado em computadores, utilizado no seio

de uma organizao (LAUDON, et al., 1999).

13

De acordo com (MCGREGOR, 2001),

(...) usabilidade significa concentrar esforos para a facilidade do uso. Significa

transformar a tarefa de alcanar uma meta simples, direta e o mais objetiva possvel.

Ela significa criar um sistema transparente que seja fcil de entender e operar

instantaneamente. Usabilidade pensar no usurio no incio, no fim e sempre.

Para (NIELSEN, 1993) a usabilidade tem como objetivo elaborar interfaces capazes de

permitir uma interao fcil, agradvel, com eficcia e eficincia. Ela deve capacitar a criao

de interfaces transparentes de maneira a no dificultar o processo, permitindo ao usurio

pleno controle do ambiente sem se tornar um obstculo durante a interao.

Em resumo, Usabilidade o componente do Standard de ISO (9241-13, 1998) e

definido da seguinte forma: Usabilidade a eficincia, eficcia e satisfao com a qual os

pblicos do produto alcanam objetivos em um determinado ambiente. Entendendo que:

Eficcia: a capacidade de executar tarefa de forma correta e completa.

Eficincia: so os recursos gastos para conseguir ter eficcia, sejam eles tempo,

dinheiro, produtividade, memria.

Satisfao: o conforto e aceitao do trabalho dentro do sistema.

Caso a interface no seja baseada na necessidade do usurio acabar se tornando uma

interface difcil, ou seja, aumentaria a carga de trabalho do usurio, trazendo consequncias

negativas para a utilizao do SIG que vo desde a resistncia ao uso, passando pela

subutilizao, chegando ao abandono do sistema.

Sendo assim, o principal objetivo do SIG proposto facilitar as decises do usurio

atravs da manipulao correta das informaes; possibilitar a visualizao das salas com os

seus respectivos horrios de utilizao e, promover uma melhor comunicao entre o setor

administrativo e os usurios.

Acredita-se ainda que o uso deste SIG pela Superviso de Administrao e

Planejamento facilitar o armazenamento das informaes de forma confivel e a

manipulao dos dados relacionados ao processo de gerenciamento das salas, permitindo um

controle e uma disponibilizao eficaz e precisa dos dados.

Com esse propsito, este trabalho est organizado da seguinte forma. Alm dessa

introduo o captulo 2 apresenta os conceitos bsicos de interface humano computador; o

captulo 3 descreve a modelagem e desenvolvimento da proposta; no captulo 4 so

apresentados os detalhes de implementao; o captulo 5 traz as concluses e uma sntese dos

trabalhos futuros, seguido das referncias bibliogrficas. O apndice A apresenta detalhes da

documentao dos casos de uso.

14

2. INTERAO HUMANO COMPUTADOR - IHC

O Estudo da Interao Humano Computador IHC3 envolve conhecimento sobre o

humano por um lado, sobre a tecnologia por outro e sobre as maneiras como um influencia e

influenciado pelo outro.

O ser humano percebe o mundo ao seu redor por meio de um sistema sensorial. As

capacidades sensoriais do homem alargam-se a um leque de estmulos: dor, presso,

temperatura e vibrao. Para (PRESSMAN, 1995) quando considerada uma IHC,

predominam os sentidos visuais, ttil e auditivo. Atravs deles possvel que usurios de

sistemas computacionais percebam as informaes, armazene-as na memria e processe-as,

usando raciocnio indutivo ou dedutivo.

Para que os computadores pudessem ser amplamente aceitos e efetivamente usados

eles precisaram ser bem projetados. Isso no implica que o design fosse adequado a todas as

pessoas, mas os computadores deveriam ser projetados para atender as necessidades e

capacidades da maioria de um grupo alvo. Certamente, usurios em geral no devem ser

obrigados a pensar sobre como o computador funciona, da mesma forma que o funcionamento

mecnico de um automvel no preocupao da maioria das pessoas. Entretanto os designs

de sistemas computacionais tm efeito sobre seus usurios.

Empresas produtoras de software tm despertado para a ideia de que a melhora no

aspecto fsico da interface do usurio proporciona maiores chances de sucesso de mercado.

Por outro lado, pesquisadores estavam preocupados em como o uso de computadores poderia

efetivamente enriquecer o trabalho e a vida das pessoas. Em particular, eles estavam

estudando o lado humano da interao com sistemas computacionais. O intuito era procurar

compreender os processos psicolgicos das pessoas quando interagem com os computadores.

Com os avanos tecnolgicos, tornou-se claro que outros aspectos ligados ao usurio e ao uso

dos computadores precisavam ser includos: relaes sociais; sade; entre outros.

A IHC surgiu como um meio de descrever esse novo campo de estudo. Este termo

nasce da necessidade de mostrar que o foco de interesse mais amplo que somente design de

interfaces e abrange todos os aspectos relacionados com a interao entre usurios e

computadores.

IHC a rea da computao que se preocupa com a forma como os sistemas se

apresentam aos usurios e, nesse sentido, tem um importante papel no desenvolvimento de

3 O termo Interao Humano Computador ou Interface Humano Computador IHC, so usados de

modo equivalente.

15

todo tipo de sistema, variando dos sistemas de controle de trfego areo onde segurana

extremamente importante; sistemas de escritrio onde produtividade e satisfao so

parmetros mais relevantes; at jogos, onde o envolvimento dos usurios o requisito bsico.

A rea de IHC trata do design de sistemas computacionais que auxiliam as pessoas de forma a

que essas possam executar suas atividades produtivamente e com segurana.

Por outro lado IHC uma rea multidisciplinar que conforme (PREECE, et al., 1994),

envolve disciplinas como: Cincia da Computao; Psicologia Cognitiva; Psicologia Social e

Organizacional; Ergonomia ou Fatores Humanos; Lingustica; Inteligncia Artificial;

Filosofia, Sociologia e Antropologia; Engenharia e Design. Para (CARROL, 1991) a chave

principal para a IHC entender e facilitar a criao de interface de usurios.

Segundo (HEWETT, et al., 1992) IHC, :

uma disciplina que diz respeito ao design, avaliao e implementao de sistemas

de computao interativos para uso humano em contexto social e com os estudos

dos principais fenmenos que os cercam.

Assim, a IHC estuda e define mtodos para o projeto de sistemas ou dispositivos de

interao que sejam de mais fcil utilizao, eficientes, eficazes e que possibilitam conforto

aos indivduos que iro utiliz-los (AGNER, 2006).

No contexto de IHC, conforme (DIX, et al., 1993) apud (DE SOUZA, et al., 1999)

deve-se considerar quatro elementos bsicos: o sistema, os usurios, os desenvolvedores e o

ambiente de uso (domnio de aplicao). Segundo os autores, tais elementos esto envolvidos

em dois importantes processos: a interao usurio-sistema e o desenvolvimento do sistema.

Portanto, IHC uma rea com inmeros desafios.

2.1 Desafios de IHC

Com o rpido desenvolvimento da tecnologia, mais os conflitos e compromissos dos

objetivos de um design e mais as diferentes componentes que caracterizam IHC, sem dvida

uma rea com muitos desafios.

De acordo com (PREECE, et al., 1994) o desenvolvimento de mquinas mais rpidas e

com maior poder de processamento, em conjunto com melhorias de tecnologias de hardware e

software, trazem dois importantes desafios aos designers de IHC, a saber:

Como dar conta da rpida evoluo tecnolgica?

Como garantir que os designs ofeream uma boa IHC ao mesmo tempo em que

exploram o potencial e funcionalidade da nova tecnologia?

16

Estes desafios ficam aparentes quando se pensa em aparelhos do dia-a-dia, como um

telefone pblico. A necessidade da insero de um carto, o tom de discar, o som da chamada,

a srie rpida de sons para o telefone receptor ocupado, todos esses elementos fazem parte da

interface-usurio do aparelho.

Estes aspectos so familiares para os habitantes de uma cidade, mas completamente

desconhecidos e imprevisveis para pessoas que no tem acesso a esse tipo de recurso. O

mesmo acontece com relao aos aparelhos telefnicos atuais. Enquanto as funcionalidades

estavam restritas ao suporte de uma conversao tudo ia muito bem. Mas atualmente, a

tecnologia permite, por exemplo, conversas por vdeo chamada ou at mesmo entre duas ou

mais pessoas. Com isso, a mesma interface para dar conta de todas essas novas

funcionalidades ficou complexa. Em geral, muitas pessoas tm problemas quando tentam

operar essas funes e muitas acabam por desistir.

Convm observar que muitos sistemas computacionais foram projetados com

interfaces pobres. Entretanto, o ponto em questo que aumentar a funcionalidade no pode

ser desculpa para um design pobre. Deve ser possvel projetar boas interfaces cujos controles

tm operaes e efeitos relativamente bvios e que tambm provem um feedback imediato e

til.

Um bom exemplo relacionado a esse aspecto o dado por (NORMAN, 1988) com

relao aos carros. Segundo ele, observando os controles dos painis dos carros atuais

podemos ver que eles tm cerca de 100 controles ou mais. Desses, seleciona-se dez ou mais

para o equipamento de som, cinco ou mais para o sistema de ventilao, outros tantos para

acionar as janelas, os limpadores de para-brisa, as diferentes luzes, para abrir e fechar portas,

para dirigir o carro, etc. A maioria das pessoas, com pouca tentativa e erro, quase sempre

enquanto dirige ou aps uma rpida olhada no manual, tem poucos problemas em lidar com

todo o domnio dessas funes. Por que isso acontece, se no existe termo de comparao

entre o nmero de funes e controles de um carro? O que torna a interface do carro to boa?

Uma das razes que o feedback nos carros imediato e bvio. Tambm, as pessoas que j

dirigiram qualquer carro sabem o que esperar, pois, muito embora, os carros sejam diferentes,

a posio da maioria dos controles a mesma ou similar, e smbolos similares so usados para

indicar suas funes.

Fazendo analogia desse fato aos programas de computador, o grande desafio no s

desenvolver tecnologias que melhorem o dia-a-dia de milhares de pessoas, necessrio

explorar as suas potencialidades, usabilidade, ergonomia, ou seja, o desafio tornar as

tecnologias acessveis e disponveis aos utilizadores finais, a quem estas podero ser teis. O

17

desafio tambm se estende pela comercializao e pela relao preo / qualidade e

acessibilidade.

Portanto, os desafios de IHC so evidentes e a procura de solues estabelece os

objetivos da rea que ao serem centrados no humano e no na tecnologia so sempre atuais.

2.2 Objetivos de IHC

Sabemos que at bem pouco tempo atrs existia uma preocupao grande no

aprendizado e utilizao de um determinado software, mas no a preocupao se este software

oferecia condies para que o usurio, de forma lgica, compreendesse o que estava sendo

proposto a ele. comum encontrarmos usurios que no utilizam todos os recursos que um

determinado software oferece, e muitas vezes nem os conhecem.

Do ponto de vista de software, a IHC tem como meta a construo de sistemas que

interajam com o usurio atravs de uma maneira efetiva. Segundo (SHNEIDERMAN, 1998)

apud (LAUREL, 1990) proporcionando:

funes que sejam adequadamente desempenhadas pelos usurios;

minimizar as habilidades e o tempo de treinamento requeridos pelos usurios;

estimular a padronizao interna e externa entre sistemas.

Para (DE ROCHA, et al., 2000), o objetivo da pesquisa em IHC desenvolver

sistemas usveis, seguros e funcionais, de modo a oferecer maior segurana, usabilidade e

efetividade a todo o sistema que faz uso de recursos computacionais. Nesse contexto o termo

sistemas se refere no somente ao hardware e o software, mas todo o ambiente que usa ou

afetado pelo uso da tecnologia computacional.

Corroborando com essa ideia, (NIELSEN, 1993) engloba esses objetivos em um

conceito mais amplo que ele denomina aceitabilidade de um sistema, como mostra a Figura 1.

A aceitabilidade de sistemas est intimamente relacionada aceitabilidade social e a

aceitabilidade prtica. Sendo que a primeira diz respeito ao medo que a tecnologia pode trazer

aos usurios diante do novo ambiente empresarial despertando a seguinte dvida aos usurios

com a implantao do sistema: Afinal, vou ou no perder o emprego? Com relao

aceitabilidade prtica podemos discutir os custos, a compatibilidade, a confiabilidade, assim

como utilidade e usabilidade. Algumas perguntas relacionadas a esse item so: o sistema

fcil de aprender; eficiente; fcil de lembrar onde se encontram os botes, cones,

comandos e ajuda; os erros encontrados so constantes; os erros levam a uma perda

18

considervel de tempo para soluo de problemas e satisfao subjetiva como tambm da

categoria denominada usefulness.

Figura 1 - Atributos de aceitabilidade de sistemas (adaptado de NIELSEN, 1993)

O termo Usefulness refere-se ao sistema poder ser usado para atingir um

determinado objetivo. Novamente essa categoria uma combinao de duas outras: utilidade

e usabilidade. Utilidade deve verificar se a funcionalidade do sistema faz o que deve ser feito,

ou seja, se um jogo efetivamente diverte e um software educacional auxilia o aprendizado.

Usabilidade a questo relacionada quo bem os usurios podem usar a funcionalidade

definida.

2.2.1 Aceitabilidade de Sistema

Aceitabilidade de um sistema tem muitos componentes, e IHC tm de certa forma, que

atender os compromissos de todas essas categorias. Mas, o estudo de IHC sustenta-se na

crena de que o centro e o ponto bsico de anlise so as pessoas usando um sistema

computacional.

Os usurios de um sistema de acordo com suas necessidades, capacidades e

preferncias para executar diversas tarefas, devem informar os meios como os sistemas devem

ser projetados e implementados. As pessoas no devem ter que mudar radicalmente para se

adequar ao sistema, o sistema sim deve ser projetado para se adequar aos seus requisitos.

De acordo com (PREECE, et al., 1994), para atender as necessidades do usurio

relevante salientar fatores cruciais que devem ser trabalhados num sistema. Dentre os fatores

a serem observados, ateno deve ser dada aqueles relacionados ao usurio como: o conforto,

sade, ambiente de trabalho ou ergonomia do equipamento a ser utilizado. Analisar esses

19

fatores tarefa bastante complexa, pois eles no so independentes e interagem fortemente

uns com os outros.

Outro ponto que aumenta a complexidade da anlise dos fatores ao usurio que eles

no so homogneos em termos de requisitos e caractersticas pessoais. Humanos

compartilham muitas caractersticas fsicas e psicolgicas, mas so bastante heterogneos em

termos de qualidades, como habilidades cognitivas e motivao. Essas diferenas individuais

tm importncia fundamental no design da interface de um sistema computacional. De acordo

com (PREECE, et al., 1994) destacaremos alguns desses fatores:

Fatores Organizacionais treinamentos, polticas, organizao do trabalho,

etc.

Fatores ambientais barulho, aquecimento, ventilao, luminosidade, etc.

Sade e segurana estresse, dores de cabea, perturbaes musculares, etc.

Conforto posio fsica, layout do equipamento, etc.

Interface do usurio dispositivos de entrada e sada, estrutura do dilogo,

uso de cores, cones, comandos, grficos, linguagem natural, 3D, materiais de

suporte ao usurio, multimdia, etc.

Tarefa fcil, complexa, nova, alocao de tarefas, repetitiva, monitoramento,

habilidades, componentes, etc.

Restries custos, oramentos, equipe, equipamento, estrutura do local de

trabalho, etc.

Funcionalidade do sistema hardware, software, aplicao.

Produtividade aumento da qualidade, diminuio de custos, diminuio de

erros, diminuio de trabalho, diminuio do tempo de produo, aumento da

criatividade, oportunidades para idias criativas em direo a novos produtos,

etc.

Portanto, um modo de tratar essa diversidade projetar sistemas flexveis que possam

ser customizados de forma a se adequar s necessidades individuais. Sistemas

computacionais, como editores de texto, por exemplo, oferecem atualmente uma srie de

opes para se adequar experincia e preferncia de usurios.

2.3 Interface de Sistemas

Outro aspecto de interesse da rea de IHC o de interface, uma vez que, os projetos de

interface para um sistema computadorizado devem, em primeiro lugar, considerar a percepo

20

sensorial do homem. Esses projetos, a partir do nvel de interao que se deseja estabelecer

entre o homem e o computador, adotam metforas que possibilitem o estimulo dos sentidos

visuais, ttil e auditivo, como forma de garantir o aproveitamento adequado do sistema pelo

seu usurio.

O desempenho humano no uso de computadores e sistemas computacionais tem sido

uma rea de pesquisa e desenvolvimento que muito se expandiu nas ltimas dcadas.

Sistemas computacionais e interfaces acessveis so tecnologias em grande ascenso e com

rpida disseminao.

Alm disso, sabido que as novas tecnologias possibilitam grandes oportunidades s

pessoas que dominam suas interfaces. Haja vista, o crescente interesse no projeto de interfaces

do usurio para os mais variados tipos de sistema: editores de texto, ferramentas de edio, e

softwares de manipulao de imagens entre outros. Este interesse fundamental para a

proliferao de interfaces amigveis entre os mais diversos tipos de sistemas.

Portanto, estamos vivendo um momento vital e estratgico para os desenvolvedores de

interfaces. Para (SHNEIDERMAN, 1998), a tecnologia est pronta. Tendo, portanto as pontes

e tneis construdos e agora as estradas precisam ser pavimentadas e as sinalizaes pintadas

para tornar possvel o pesado trfico da grande leva de usurios.

2.4 Conceito de Interface

Visualiza-se uma interface como um lugar onde o contato entre duas entidades ocorre

(por exemplo, a maaneta de uma porta). A forma das interfaces reflete as qualidades fsicas

das partes na interao. A maaneta de uma porta projetada para se adequar natureza da

mo que ir us-la. O que muitas vezes esquecido que a forma da interface tambm reflete

o que pode ser feito com ela.

Hoje em dia comum pensar na interface como a tela e o que nela mostrado. O

nome interface tomado como algo discreto e tangvel, uma coisa que se pode desenhar,

mapear, projetar e implementar, encaixando-a posteriormente a um conjunto j definido de

funcionalidades. De acordo com (LAUREL, 1993) uma interface uma superfcie de contato

que reflete as propriedades fsicas das partes que interagem, as funes a serem executadas e

o balano entre poder e controle.

No inicio o conceito de interface era geralmente entendido como o hardware e o

software com o qual o homem e computador se comunicavam. Com a evoluo do conceito,

esse passou a incluir os aspectos cognitivos e emocionais do usurio durante a comunicao.

Atravs dos novos aspectos inseridos no conceito, a criao de interfaces obteve uma grande

21

transformao. O planejamento das novas interfaces envolve um estudo profundo sobre o

comportamento humano atravs de seus sentidos, possibilitando a descoberta de novas formas

eficazes de interao entre o homem e a mquina, tornando a realizao de tarefas complexas

em o mais simples, direta e objetiva possvel.

Nos ltimos anos, a interface de aplicaes computacionais recebe cada vez mais

importncia. De acordo com (MORAN, 1981) apud (DE SOUZA, et al., 1999), a interface

de uma aplicao computacional envolve todos os aspectos de um sistema com o qual

mantemos contato.

As interfaces de usurio tm transformado a vida de muitas pessoas como: mdicos,

que esto tendo a possibilidade de fazer diagnsticos mais precisos; pilotos, ao possibilitar

maior segurana em seus vos; crianas esto expandindo os horizontes em ambientes de

aprendizagem e entre outros. No entanto, algumas transformaes so conturbadas e at

desastrosas; frequentemente usurios tm que lidar com frustrao, medo e falha quando

encontram designs excessivamente complexos, com terminologia incompreensvel e catica.

Portanto a usabilidade esta estritamente relacionada s interfaces.

2.5 Usabilidade na WEB

A Internet como ferramenta tecnolgica cria um espao universal para o

compartilhamento de informaes, servindo como alternativa comercial para empresas

virtuais, mudando todo o sistema de comunicao entre pessoas e empresas, de gesto

estratgica e o prprio comportamento do consumidor, por eliminar os limites territoriais

entre empresas e o mundo.

O nmero de pessoas que usa a Internet est crescendo sem parar. Esse crescimento

trouxe mudanas no perfil do usurio. No comeo predominavam os especialistas e agora

predominam os novatos, que mal sabem ligar o computador e que, algumas vezes, tem

rejeio a ele. Assim, deslumbrar-se com a tecnologia no tem mais razo de ser. Com a

enorme oferta de alternativas, usurios da Web tm uma notvel impacincia e insistncia em

gratificao imediata. Se no conseguem entender como usar um Website em poucos minutos,

eles concluem que no vale pena perder seu tempo. E ento o abandonam.

Dados estatsticos apontam que muitos bilhes de dlares j deixaram de serem

ganhos na Web norte-americana devido a designs mal feitos. Sabe-se que com a enorme oferta

de alternativas os usurios de internet tm uma notvel impacincia e insistncia em

gratificao imediata, portanto a usabilidade governa a Web, se o cliente no encontrar o

produto, ele no o comprar. O cliente detm o poder, uma vez que quem clica no mouse

22

decide tudo. Afinal, to fcil ir a outro lugar; todos os concorrentes do mundo esto a um

simples clique do mouse.

No design de produtos e de software tradicionais, os usurios pagam antes e

experimentam a usabilidade depois. Isto no acontece na Web onde os usurios experimentam

a usabilidade antes e pagam depois, ou seja, a m usabilidade equivale a nenhum cliente.

Portanto a usabilidade assume uma importncia substancial no design para a Web.

No design para a Web existem basicamente duas abordagens: uma artstica onde o

designer se expressa e outra dirigida a resolver o problema do usurio. Certamente existe a

necessidade da arte, da diverso e do prazer na Web, mas acredita-se que o principal objetivo

dos projetos para a Web deva ser o de tornar fcil para os usurios executarem tarefas teis.

Para garantir usabilidade em design para a Web estabelecido alguns princpios

bsicos (NIELSEN, 1999):

Clareza na arquitetura da informao essencial que o usurio consiga

discernir o que prioritrio e o que secundrio no site. Ou seja, preciso

chegar a um bom arranjo da informao. O site deve prover meios para eles

sejam ajudados, prover um senso de como a informao est estruturada e

como se localizada. Uma alternativa interessante a de menus de navegao

em todas as pginas, facilitando o acesso ao lugar pretendido de forma direta.

Facilidade de navegao O usurio deveria conseguir acessar a informao

desejada no mximo em trs cliques. Sentir-se perdido dentro de um site causa

a desmotivao no aprendizado.

Simplicidade Quem navega quer encontrar o mais rapidamente possvel o

objetivo da busca. A pirotecnia deve ser evitada, dando ao usurio paz e

tranquilidade para que possa analisar a informao. Cuidados devem ser

tomados para que a simplicidade no signifique ausncia de informao. O que

importa na Web a informao e ela no pode ser omitida em funo de uma

pretensa simplicidade.

A relevncia do contedo Informaes secundrias devero ser deixadas

para pginas de suporte. As pginas devero ser bem curtas e objetivas

enfocando o contedo atribudo.

Manter a consistncia Quando as coisas acontecem sempre do mesmo jeito,

os usurios no precisam se preocupar a respeito do que ir acontecer. Ao

contrrio, eles sabem o que vai acontecer baseado numa experincia anterior.

23

Tempo suportvel O tempo de carga das pginas deve ser curto, 15

segundos o mximo de tempo antes que as pessoas percam o interesse.

Foco nos usurios Todos os princpios podem ser embutidos em um s: o

foco deve estar nas atividades dos usurios.

Pessoas so extremamente dirigidas a um objetivo quando usam a Web. No toleram

nada que dificulte atingir esse objetivo. Portanto, o princpio mais importante para a Web

deixar o caminho livre de forma a que o usurio possa fazer o que quer da maneira mais

rpida possvel.

Sabendo da necessidade em criar mtodos que contribuam para o bom funcionamento

da distribuio de salas e que as tecnologias contribuem de forma satisfatria para a

realizao, os conceitos de usabilidade na Web discutidos anteriormente permitem o

planejamento e desenvolvimento do sistema proposto aos funcionrios da SAP.

24

3. MODELAGEM E DESENVOLVIMENTO DO SISTEMA

Considerando que a necessidade da SAP, em relao ao processo de distribuio de

salas, o armazenamento eficiente; a comunicao entre os usurio; a manipulao dos dados

com relao a alocao dos espaos, permitindo o registro e a visualizao das informaes

referentes distribuio de salas. Ainda considerando a preocupao com usabilidade, uma

vez que a forma de interao humano-computador influenciam na utilidade do sistema, o

Sistema de Gerenciamento de Salas SGS um SIG que tem como proposta atender aos

requisitos solicitados.

Segundo (FURLAN, 1998), a especificao de requisitos a fase destinada s

definies de funcionalidades (requisitos funcionais) e restries (requisitos no funcionais)

do sistema. Trata do levantamento e da modelagem de requisitos segundo uma perspectiva

externa, independente de paradigma.

A Figura 2 apresenta um esboo da funcionalidade do SGS.

Figura 2 - Funcionalidade do SGS

A modelagem do sistema tem como base o levantamento de requisitos, onde o usurio

final especifica as funcionalidades do sistema. Considerando as necessidades dos usurios e

com base nos dados referentes estrutura fsica do Campus, essa especificao fundamentou-

se naquilo que relevante no processo de distribuio de salas.

De modo geral a ideia inicial era que o SGS deveria:

armazenar informaes relacionadas aos espaos fsicos do campus e as

solicitaes desses.

permitir manipulao dessas informaes, de acordo com as disponibilidades.

25

possibilitar a comunicao entre os solicitantes (usurios) e a administrao do

campus com relao alocao e reserva de espaos.

possibilitar a visualizao das demandas de forma mais otimizada para o

usurio, de acordo com a busca solicitada.

possibilitar que apenas usurios previamente cadastrados no sistema pudessem

manipular os dados.

possibilitar um mtodo de solicitao de espao diferenciado para os

coordenadores de curso e diretores, ou seja, mediante programao acadmica

do semestre letivo.

possibilitar que as salas de uso comum auditrio, pudessem ser solicitadas e

agendadas em fluxo contnuo.

Com base nos requisitos levantados definiu-se as funcionalidades do sistema, as quais

sero representadas atravs da notao UML. Sendo apresentados, respectivamente, os

Diagramas de Casos de Uso, Diagramas de Classe e Diagrama de Sequncia, e tambm o

modelo de Banco de Dados, por meio do diagrama de entidade relacionamento.

3.1 Diagramas de Caso de Uso

Segundo (BEZERRA, 2002), o modelo de casos de uso uma representao das

funcionalidades externamente observveis do sistema e dos elementos externos ao sistema

que interagem com ele. Dessa forma, o diagrama de caso de uso descreve os requisitos que o

sistema dever ter de forma clara e concisa.

O Diagrama de Caso de Uso tem como objetivo expor um cenrio que mostra a

funcionalidade do sistema do ponto de vista do usurio. Portanto o Caso de Uso descreve as

funes de cada ator no sistema e suas especificaes com finalidade de permitir que o

analista de sistemas possa especificar seus limites e funcionalidades. Atravs dessa descrio

possvel que clientes e usurios validem o sistema e que os desenvolvedores construam o

que esperado do sistema (BEZERRA, 2004).

3.1.1 Atores

Os atores so quaisquer elementos externos que interagem de alguma forma com o

sistema. No caso do SGS, os atores sero Usurio Pblico, Coordenador e a SAP. A Figura 3

apresenta os atores do sistema.

26

Figura 3 - Atores do sistema

O ator Usurio Pblico representa o usurio que interage com o sistema pela rea de

acesso pblico. Nesta rea no necessria a realizao de cadastro e login no sistema. A

permisso de acesso somente a de realizar buscas no sistema por reservas, visualizar agenda

de salas e solicitar reserva de espao de uso comum4.

O ator Coordenador representa os coordenadores de Curso do CUA. Este usurio est

previamente cadastrado no sistema pela SAP e possui permisso de acesso atravs de login e

senha. Esse ator possui permisso de cadastrar, alterar, excluir e visualizar a demanda de salas

do curso que representa, podendo tambm alterar/atualizar seus dados cadastrais no sistema.

O ator SAP representa a administrao do CUA. Este usurio detm o domnio sobre

os outros usurios e de funcionalidades especiais do sistema. A sua funo especfica a de

gerir a distribuio de salas. Atravs do seu login e senha de acesso, o mesmo possui

permisso para realizar buscas no sistema; cadastrar, alterar, excluir e visualizar salas;

cadastrar, alterar, excluir e visualizar reservas de salas; e cadastrar usurios no sistema.

3.1.2 Casos de Uso

De acordo (BOOCH, et al., 2000), um caso de uso uma descrio de um conjunto

de seqncia de aes, inclusive variantes, que um sistema executa para produzir um

resultado de valor observvel por um ator

Para obter uma viso externa do sistema, os casos de uso so descritos atravs de

diagramas. O digrama de caso de uso representa graficamente o que os atores do sistema

podero fazer de acordo com cada funcionalidade. A Figura 4 apresenta o diagrama de caso

de uso geral para o sistema SGS.

4 No mbito do Campus considerado espao de uso comum os auditrios e laboratrios de uso geral

(laboratrio de informtica).

27

Figura 4 - Diagrama de caso de uso para o SGS.

3.2 Requisitos Funcionais do Sistema

Aps o levantamento dos digramas, deve-se fazer a descrio dos requisitos funcionais

de cada caso de uso. Essas informaes ajudaro no desenvolvimento do sistema para saber

quais mtodos devem ser realizados pelo sistema e quais passos sero seguidos para realizar

uma determinada funcionalidade.

Para cada caso de uso tem-se representado os seus relacionamentos e uma descrio

do seu comportamento. A seguir so apresentadas as especificaes dos casos de uso para o

SGS. A Figura 5 a representao do caso de uso referente ao ator Usurio Pblico. A

documentao de cada caso de uso ser apresentado no apndice A.

Figura 5 - Casos de uso do ator usurio pblico

o Visualizar Salas: O servio apresentado por este caso de uso refere-se visualizao

das salas e de suas respectivas informaes, por meio do qual o usurio poder

28

procurar por salas que satisfaam determinadas condies impostas por ele. Este

servio oferecido para o usurio pblico do sistema. A partir de uma busca vlida, ou

seja, uma pesquisa que retorne uma ou mais salas, o sistema ir apresentar ao usurio

as salas pesquisadas por meio de uma listagem, onde cada linha conter o cdigo da

sala, unidade, quadra, bloco, andar, tipo, lugares e observao, alm de um link que o

guiar para a visualizao da agenda da sala.

o Solicitar Reserva de Sala: Este um dos principais casos de uso do diagrama,

representando o servio de solicitao de reserva, por meio do qual o usurio poder

preencher um formulrio de solicitao. Aps o link de solicitao de reserva ser

acionado, o sistema ir apresentar ao usurio o formulrio contendo as seguintes

informaes: nome do solicitante, data, horrio, tipo de sala e unidade. Atravs do

preenchimento de todos os campos ser criada uma solicitao de reserva, que adiante

a SAP ser responsvel por atender.

A Figura 6 representa o caso de uso referente ao ator Coordenador.

Figura 6 - Casos de uso do ator coordenador

o Manter Demanda: O servio representado por este caso de uso s pode ser utilizado

pelo coordenador a partir do momento em que estiver autenticado no sistema. Este

caso de uso refere-se opo de que o coordenador poder realizar a demanda de salas

do seu respectivo curso por meio de um formulrio que o sistema ir apresentar ao

coordenador onde ser possvel cadastrar o horrio de aula de cada semestre existente

no curso, alm de informar a quantidade de alunos possveis de cada turma. O

coordenador tambm ter a opo de visualizar as demandas cadastradas alm de

poder exclu-las do sistema. Cada coordenador possui acesso somente a pgina

referente ao seu curso, no podendo visualizar as demandas dos demais cursos.

o Realizar Login: Este caso de uso refere-se ao servio de autenticao do usurio no

sistema. Isso ocorre a partir do momento em que informado o login e a senha do

usurio, se os dados existirem consistentes com os do banco de dados, o acesso ao

sistema liberado para sua respectiva rea de acesso e uma sesso registrada.

29

A Figura 7 representa o caso de uso referente ao ator SAP.

Figura 7 - Casos de uso do ator SAP

o Visualizar Demanda: O servio representado por este caso de uso s pode ser

utilizado pela SAP, a partir do momento em que estiver autenticada no sistema. Este

caso de uso refere-se visualizao da demanda de salas que foi anteriormente

realizada pelos coordenadores de curso. A SAP poder procurar pelas demandas que

satisfaam determinadas condies impostas por ela. A partir de uma busca vlida, ou

seja, uma pesquisa que retorne a demanda de um curso, o sistema ir apresentar ao

usurio a demanda de um semestre do curso por meio de uma tabela de horrio, onde

estar sendo especificados os horrios de aula e seus respectivos dias da semana, alm

de informar a quantidade de alunos existente naquela turma.

o Manter Salas: O servio representado por este caso de uso s poder ser utilizado

pela SAP, a partir do momento em que estiver autenticada no sistema. Este caso de

uso refere-se tarefa de manter os dados relacionados s salas pertencentes ao CUA.

Atravs deste servio a SAP ter a opo de cadastrar, alterar, excluir e visualizar

salas. Por meio da escolha da opo cadastrar, o sistema ir apresentar ao usurio um

formulrio contendo as seguintes opes para preenchimento: cdigo da sala, unidade,

quadra, bloco, andar, tipo, capacidade e observao. Na opo alterar, o sistema ir

apresentar ao usurio opes de busca para que o mesmo possa refinar a busca por

uma determinada sala que se deseja alterar os dados. O funcionamento da opo

excluir est relacionada com o da opo alterar, mudando-se somente o objetivo final

da ao, que neste caso excluir uma sala. Alm disso, o usurio poder visualizar

todas as salas e suas respectivas agendas a partir de buscas realizadas no sistema.

o Manter Reserva: O servio representado por este caso de uso s poder ser utilizado


uso refere-se tarefa de manter os dados relacionados s reservas de salas. Atravs

deste servio a SAP ter a opo de cadastrar, excluir e visualizar reservas. A partir da

30

escolha da opo cadastrar, o sistema ir apresentar ao usurio a opo de realizar uma

reserva fixa ou eventual. Aps a escolha de uma destas opes, o sistema apresentar

todas as informaes pertencentes s demandas existentes, atravs dos dados

visualizados o usurio poder realizar a tarefa de alocao de salas. Na opo excluir,

o sistema ir apresentar ao usurio opes de busca para que o mesmo possa refinar a

busca por uma determinada reserva que deseje excluir do sistema.

o Manter Usurios: O servio representado por este caso de uso s poder ser utilizado


uso refere-se tarefa de manter os usurios no sistema. Atravs desse servio a SAP

ter a opo de cadastrar, editar, excluir e visualizar os usurios. Por meio da opo

cadastrar, o sistema apresentar ao usurio um formulrio para preenchimento com os

seguintes campos: CPF (login), SIAPE, nome, email, categoria, curso e senha. Alguns

destes dados podero ser alterados pelo usurio aps o cadastro, por meio do acesso a

sua respectiva rea no sistema. Na opo alterar, o sistema ir apresentar ao usurio

opes de busca para que o mesmo possa refinar a busca por um determinado usurio

que se deseja alterar os dados. O funcionamento da opo excluir est relacionada com

o da opo alterar, mudando-se somente o objetivo final da ao, que neste caso

excluir um usurio. Alm disso, a SAP poder visualizar todos os usurios cadastrados

no sistema.

o Realizar Login: Este caso de uso refere-se ao servio de autenticao do usurio no

sistema. Isso ocorre a partir do momento em que informado o login e a senha do

usurio, se os dados existentes forem consistentes com os do banco de dados, o acesso

ao sistema liberado para sua respectiva rea de acesso e uma sesso registrada.

3.3 Diagrama de Classe

De acordo com (FURLAN, 1998), a modelagem de classes envolve a definio de

todas as classes, atributos e relaes relevantes para o problema a ser resolvido.

Os diagramas de classes representam apenas os elementos estticos de um modelo.

preciso analisar ainda, o comportamento dinmico da aplicao Para tal, devemos representar

o comportamento do sistema como uma funo do tempo e de eventos especficos, que ser

apresentado na sequncia. Um modelo de interao indica como o sistema ir responder a

eventos ou estmulos externos e auxilia o processo de descoberta das operaes das classes do

sistema. A Figura 8 apresenta o diagrama de classe do sistema.

31

Figura 8 - Diagrama de classe

32

A Figura 9 ilustra os atributos da classe Sala. O atributo cdigo refere-se

identificao da sala por meio de um numeral. O atributo capacidade descreve a quantidade de

lugares que a sala comporta. Andar o atributo que identifica o andar em que a sala esta

localizada em um determinado prdio e por fim o atributo observao refere-se a uma

descrio mais detalhada sobre a sala. Os mtodos correspondentes a classe sero omitidos

nesta etapa.

Figura 9 - Classe sala

3.4 Diagrama de Interao

Os diagramas de interao ilustram um conjunto de mensagens trocadas entre um ou

mais objetos para a realizao de um propsito. Esses diagramas so utilizados para

representar um sistema como um todo, partes dele ou para modelar casos de usos. So

importantes para modelagem de aspectos dinmicos do sistema e tambm para construo de

sistemas executveis. Os diagramas de interao podem conter objetos, vnculos e mensagens.

Dando continuidade a modelagem ser apresentado o diagrama de sequncia para um

caso de uso particular.

3.4.1. Diagrama de Sequncia

Diagramas de sequncia so utilizados para demonstrar a interao entre o usurio e o

sistema em uma sequncia de tempo dos objetos que participam de um caso de uso isolado. A

idia de utilizar este diagrama apresentar o passo a passo da interao do usurio com o

sistema (PRESSMAN, 1995).

A Figura 10 apresenta o diagrama de sequncia da tarefa manter usurio. A descrio

das aes na interao adicionar um usurio d se como segue:

33

o a SAP solicita a criao de novo usurio

o a interface retorna uma janela para insero dos dados.

o os dados so enviados para o sistema e h uma verificao de no duplicao de

usurio.

o se confirmada a no existncia do usurio, aberta uma janela de confirmao para a

SAP e, em seguida, o novo usurio salvo no banco de dados.

A descrio das aes na interao alterar um usurio d se como segue:

o a SAP solicita a edio de um usurio,

o a interface retorna uma janela para alterao dos dados.

o os dados so informados e enviados para o sistema.

o h uma verificao de no duplicao de usurio.

o se confirmada a no duplicao de usurio aberta uma janela de confirmao para o

usurio.

o se confirmada pelo usurio, o banco de dados atualizado com as novas informaes.

A descrio das aes na interao excluir um usurio d se como segue:

o a SAP solicita a excluso de usurio,

o a interface retorna uma janela de confirmao.

o se confirmada, uma operao de excluso efetuada no banco de dados.

34

Figura 10 - Diagrama de sequncia manter usurio

3.5 Modelagem dos dados

Para (SILBERSCHATZ, et al., 1999) o modelo entidade-relacionamento (MER) tem

por base a percepo de que o mundo real formado por um conjunto de objetos chamados

entidades e pelo conjunto dos relacionamentos entre esses objetos. A modelagem dos dados

do SGS apresentada na Figura 11 e a representao desses no banco de dados apresentada

na Figura 12.

Nessa viso, cada entidade possui propriedades particulares que so os atributos.

Tomando como exemplo a tabela USURIO, as informaes (nome, SIAPE, CPF, senha,

email) so os atributos, ou seja, os dados dos usurios que ocupam os campos da tabela da

entidade usurio.

A associao entre uma ou mais entidades chamado de relacionamento. Por

exemplo, a entidade USURIO associa-se com a entidade CATEGORIA.

35

Figura 11 - Modelo entidade relacionamento (MER) do SIG

36

As entidades consideradas neste modelo conceitual so: Usurio, Categoria, Curso,

Instituto, Turma, Demanda_fixa, Horrio, Dia_semana, Reserva, Demanda_eventual,

Demanda_eventual_horario, Sala, Bloco_campus_quadra, Bloco, Tipo, Campus_quadra,

Campus e Quadra.

A entidade Usurio representa os usurios registrados no sistema. Sobre o usurio o

Sistema Gerenciador de Banco de Dados - SGBD, dever guardar o seu nome, CPF (login),

SIAPE, email e senha. Em particular os usurios possuem uma categoria, esse relacionamento

definido pela entidade Categoria.

A entidade Curso representa os cursos existentes no CUA, em particular os cursos

pertencem a institutos, esse relacionamento definido pela entidade Instituto.

A entidade Turma representa as turmas de um curso, para essa entidade o SGBD

dever armazenar o semestre, quantidade de alunos e o curso a que ela se refere. A entidade

Demanda_fixa refere-se demanda de salas realizada pelos cursos, por sua vez esta entidade

se relaciona com duas outras entidades para que possa ser realizada a demanda do curso. Para

a entidade Demanda_fixa o SGBD dever armazenar todas as informaes referentes s

demandas de salas dos cursos do CUA. A entidade Horrio representa os horrios de aulas e a

entidade Dia_semana representa os dias da semana.

A entidade Reserva refere-se a todas as reservas realizadas pelo sistema. Sobre ela o

SGBD dever armazenar o tipo de reserva, semestre e ano. Atravs do tipo de reserva ser

possvel realizar reserva fixas e reservas eventuais.

A entidade Demanda_eventual representa a demanda referente a solicitaes de salas

espordicas. Sobre ela o SGBD dever armazenar o nome do solicitante, dia, ms e ano. O

horrio informado pelo usurio em que se deseja utilizar a sala armazenado na entidade

Demanda_eventual_horrio.

A entidade Sala representa todas as salas do CUA. Sobre ela o SGBD dever

armazenar o cdigo da sala, capacidade, andar e observao. Pelo relacionamento com a

entidade Tipo possvel estabelecer o tipo da sala.

A entidade Campus_quadra representa a quadra e o campus em que um determinado

bloco esta localizado. Atravs do relacionamento com a entidade bloco_campus_quadra

possvel localizar em qual bloco uma sala se encontra. O relacionamento entre as entidades

Sala e Reserva o responsvel por identificar e realizar as reservas para uma determinada sala

A partir deste modelo conceitual desenvolve-se o modelo lgico. A manipulao dos

dados no SGBD feita por meio desse modelo, sendo apresentado na Figura 12. Depois da

modelagem do SIG, a prxima etapa a implementao.

37

Figura 12 - Representao dos dados do sistema no banco de dados

38

3.6 Tecnologias Utilizadas na Implementao do Prottipo

O SIG proposto trata de uma Aplicao Web, termo empregado para designar, de

forma geral, sistemas de informtica projetados para utilizao atravs de um navegador, na

internet ou em redes privadas.

Esse tipo de aplicao utiliza a tecnologia cliente-servidor, que so responsveis pela

construo da interface com o usurio e por receber as informaes enviadas por este (atravs

do browser), process-las e enviar uma resposta com o recurso solicitado (um recurso pode

ser uma pgina com apenas texto, uma imagem, um vdeo, etc.) respectivamente. A Figura 13

apresenta a interao que ocorre nessa modalidade de aplicao.

Figura 13 - Funcionamento da tecnologia Web para acesso a um Website

Neste modelo de computao, o processamento dividido entre clientes e servidores.

Os clientes solicitam servios os quais so executados pelos servidores. Na Web, os clientes

so softwares genricos, chamados de navegadores, que proporcionam a interface com o

usurio. Os navegadores entendem os padres da tecnologia Web e so responsveis por

transformar as solicitaes dos usurios em pedidos aos servidores Web. Estes ltimos

recuperam os recursos (pginas) solicitados e os retornam aos clientes, que os interpretam,

formatam e disponibilizam aos usurios.

Na Web a comunicao entre navegador e o servidor Web foi concebida para funcionar

sem a manuteno de conexes, ou seja, aps o retorno de uma pgina, o servidor Web no

guarda informaes sobre quem solicitou nem qual pgina foi retornada. Portanto, cada

solicitao ao servidor independente das demais.

A tecnologia Web permite que ela seja utilizada como infra-estrutura de acesso a

sistemas de informao. Dessa forma, os usurios interagem com os sistemas atravs dos

39

prprios navegadores Web, fornecendo informaes aos servidores, os quais processam a

geram as respostas (pgina Web) dinamicamente. Assim, a troca de informaes entre

usurios e Web bidirecional de forma similar ao que ocorre com os sistemas de informao

baseado nas tecnologias tradicionais.

Alm da tecnologia Web, para a implementao do prottipo, foi necessria a

utilizao de algumas tecnologias que sero descritas na sequncia.

3.6.1. Linguagem de Programao PHP

Segundo (CONVERSE, et al., 2003) PHP, descrito como uma linguagem de

programao de computadores interpretada, livre e utilizada para gerar contedo dinmico na

Web. O PHP uma linguagem totalmente voltada Internet, possibilitando o

desenvolvimento de websites realmente dinmicos. Sites dinmicos so aqueles que retornam

para o cliente uma pgina criada em tempo real. Alm de ser uma linguagem de programao

server-side scripts (scripts executados no servidor). Sistemas de busca da internet como o

Google so exemplos de server-side scripts.

Quando o usurio acessa uma pgina PHP por meio de seu browser (navegador), todo

o cdigo PHP executado no servidor, e os resultados so enviados para seu navegador.

Portanto, o navegador exibe a pgina j processada, sem consumir recursos de seu

computador. De acordo com (CONVERSE, et al., 2003), a maior parte do que o PHP realiza

invisvel para o usurio final. Algum visualizando uma pgina em PHP no ser

definitivamente capaz de afirmar que ela no foi escrita em HTML, porque as linhas de

cdigo PHP so embutidas no cdigo HTML (HiperText Markup Language). A Figura 14

apresenta o funcionamento da linguagem PHP.

40

Figura 14 - Esquema do funcionamento de uma pgina Web em PHP

Uma das principais vantagens do PHP que ele pode ser executado em diversos

sistemas operacionais (multiplataforma), como Linux, Windows, Unix, OS/2, Macintosh, NT,

etc., alm de permitir mudanas de plataforma com nenhuma ou pouqussimas alteraes em

seus cdigos-fonte.

3.6.2. HyperText Markup Language - HTML

O HTML HyperText Markup Language ou Linguagem de Marcao de Hipertexto

uma linguagem padro de formatao usada para escrever pginas de documentos para web.

De acordo com (O'BRIEN, 2004) HTML, uma linguagem popular de descrio de

pgina para a criao de documentos em hipertexto e hipermdia para a Rede Mundial de

Computadores e sites de intranets. Para (LAUDON, et al., 1999) HTML usado para

estruturar contedo de pginas divulgadas no World Wide Web permitindo indicar como deve

ser apresentado o documento e as relaes estabelecidas com outros documentos atravs dos

links.

Em resumo, o HTML utiliza os conceitos do Hipertexto e Hipermdia para apresentar,

num mesmo ambiente: dados, imagens e outros tipos de mdia, como vdeos, sons e grficos.

Sendo assim o HTML ainda um das principais linguagens de formatao na construo de

web sites principalmente por ser interpretada por qualquer browser em qualquer plataforma.

41

3.6.3. Cascading Style Sheet - CSS

Cascading Style Sheets (CSS) uma linguagem prpria, padronizada pela W3C5,

utilizada nos documentos escritos em linguagens de marcao como HTML ou XML,

responsvel para estilizar o contedo. Seu principal benefcio prover a separao entre o

contedo e a formatao, diminuindo o tempo de criao e alteraes dos estilos nas pginas.

Conforme (SOARES, 2006), CSS definido como um conjunto de regras ou

instrues que so dadas ao navegador para que ele apresente a forma que o contedo deve

ser apresentado, isto , permite que os estilos dos elementos da pgina (espaamento, cores,

fontes, margens, etc.) sejam especificados separadamente da estrutura do documento,

facilitando dessa forma, uma futura modificao no estilo da pgina. uma ferramenta

poderosa para deixar o site atrativo, permitindo desenvolver pginas harmoniosas, podendo

definir toda a aparncia do contedo atravs dos elementos CSS.

3.6.4. Javascript

Javascript uma linguagem de programao interpretada desenvolvida com o intuito

de criar aplicaes interativas, oferecendo ao usurio um ambiente mais sofisticado e

eficiente. Os comandos e funes Javascript so inseridos em pginas HTML e interpretados

pelo browser, no possuindo nenhum procedimento de compilao.

Para (SOARES, 2006), esta linguagem foi projetada para manipular e apresentar

informaes atravs de um navegador independente de plataforma. O Javascript enviado ao

cliente como parte como parte do cdigo HTML de uma pgina permitindo aos

desenvolvedores alterarem dinamicamente as tags de uma pgina.

O Javascript permite criar scprits pequenos programas embutidos, no cdigo de uma

pgina HTML, sendo capaz de gerar nmeros, processar dados, alterar e criar tags e verificar

formulrios, diretamente no computador do cliente, evitando a troca de informaes com o

servidor.

3.6.5. Banco de Dados - MySQL

O banco de dados um sistema de armazenamento de dados, cujo objetivo registrar,

manter e recuperar informaes. Na implementao do prottipo, foi utilizado o SGBD

MySQL que utiliza a linguagem SQL como interface.

5 W3C Consortium a entidade que cuida do desenvolvimento e padronizao das

tecnologias ligadas web.

42

O MySQL, tornou-se um dos bancos de dados open source mais populares do mundo,

pela consistncia, alta performance e confiabilidade. Amplamente utilizado por

desenvolvedores do mundo todo, por possuir alta compatibilidade com as linguagens Java,

Python, C#, Ruby, C/C++ e principalmente PHP para a criao de aplicaes web. Outro fator

que ajudou a popularizao do MySQL sua disponibilidade para qualquer sistema

operacional, como Linux, sistemas operacional baseados em Unix, Windows e Mac OS.

O servidor de MySQL controla o acesso aos dados para assegurar que mltiplos

usurios possam trabalhar com os dados ao mesmo tempo, fornecer acesso rpido aos dados e

assegurar que somente um usurio autorizado possa obter acesso (WELLING, 2001).

Conforme (LAUDON, et al., 1999), a SQL consiste na linguagem de manipulao de

dados dentro de um modelo relacional. Desenvolvida pela IBM e inspirada na lgebra

relacional, os comandos SQL podem ser usados junto com outras linguagens de programao

ou diretamente atravs de um gerenciador de banco de dados.

Tornou-se referncia para os bancos de dados relacionais, decorrentes pela

simplicidade e facilidade de uso. Porm cada fabricante de sistemas gerenciadores de banco

de dados possui suas variaes e particularidade que devem ser estudadas antes de iniciar um

processo.

Neste captulo procurou-se descrever a modelagem e o desenvolvimento do sistema

dando nfase a modelagem dos dados e as tecnologias utilizadas na implementao. O

prximo captulo apresenta as funcionalidades do sistema.

43

4. FUNCIONALIDADES DO SISTEMA

Durante o processo de desenvolvimento do prottipo alguns padres de usabilidade

foram seguidos. A usabilidade est diretamente ligada ao dilogo na interface e a capacidade

do prottipo em permitir que o usurio alcance suas metas de interao com o sistema, sendo

de fcil aprendizagem, permitindo utilizao eficiente e apresentando poucos erros. Esses so

os aspectos fundamentais para a percepo da boa usabilidade por parte do usurio.

O SGS proposto possui uma interface de acesso simples e de fcil entendimento do

usurio. Apresenta funes de armazenamento e manipulao de dados. O usurio tem acesso

a uma interface Web, onde ele pode registrar os dados referentes s salas. O SGS possui

funes que armazenam esses dados e os disponibilizam ao usurio posteriormente utilizando

tabelas. O modelo de apresentao em tabelas foi selecionado por apresentar as informaes

de modo visvel ao usurio.

Os dados cadastrados no presente trabalho pertencem a uma coleta de informaes

reais sobre o processo de distribuio de salas. A seguir sero descritas as principais

funcionalidades do SGS. A Figura 15 ilustra a pgina inicial, que tambm d acesso ao

sistema.

Figura 15 - Pgina de acesso ao SGS

Na pgina principal do SGS encontra-se uma opo de seleo para que o usurio

pblico visualize as salas e as suas informaes. Tambm encontra nesta pgina um link

referente solicitao de reserva de salas. O usurio ao clicar neste link a pgina ser

redirecionada para o formulrio de preenchimento dos dados obrigatrios para a solicitao.

Para tais tarefas o usurio no precisa estar registrado no sistema. Os usurios com permisso

de acesso ao sistema precisam informar o CPF (login) e senha para serem validados. A

44

autenticao feita pela busca e comparao dessas informaes previamente cadastradas no

banco de dados. Caso sejam iguais liberado o acesso e uma sesso registrada. O sistema

faz a distino entre dois tipos de usurios. O primeiro destinado a SAP, que tem acesso

total ao sistema e possui funes especficas de gerenciamento no sistema. J o segundo

destinado ao Coordenador, tendo acesso parcial ao sistema, apenas podendo realizar as

demandas e visualiz-las.

A Figura 16 apresenta a visualizao das salas a partir do usurio pblico por meio do

parmetro de busca Unidade e Curso. Existem vrios filtros que podem ser utilizados para a

busca de salas. Entre eles esto unidade, quadra, bloco, capacidade da sala, horrio livre e o

curso.

Figura 16 - Salas ocupadas pelo curso cincia da computao

Atravs das informaes da sala possvel o usurio pblico visualizar a agenda das

salas. Para isso o usurio deve acionar o link sobre o cdigo da sala. Aps o link ser acionado

a pgina redirecionada para a agenda da respectiva sala. Na agenda possvel visualizar as

informaes sobre as reservas existentes na sala como o perodo da reserva, curso e semestre

45

que a utiliza, horrios, dias da semana e a classificao de livre e ocupado. A Figura 17

apresenta a agenda da sala.

Figura 17 - Agenda da sala

A Figura 18 apresenta o formulrio para solicitao de reserva de salas atravs da rea

de acesso pblico do SGS. Os dados presentes no formulrio so: o nome do solicitante, a

data, o horrio, o tipo de sala e a unidade e so de preenchimento obrigatrio. A partir do

envio, a solicitao estar armazenada no banco de dados, com isso a SAP ter acesso a essas

informaes e atravs delas realizar a reserva da sala.

46

Figura 18 - Formulrio para usurio pblico solicitar reserva

A Figura 19 apresenta a pgina inicial da rea de acesso do usurio Coordenador.

Nesta pgina o menu est disposto por ordem de funcionalidades, assim a primeira opo

trata-se de um link para a pgina inicial do coordenador. A seguir tem-se um link para Alterar

Dados cadastrais, a partir desta opo o usurio ter acesso s suas informaes cadastrais

podendo alter-las quando necessrio. O link para Cadastrar Demanda, levar o usurio para a

opo de inserir os dados da demanda de salas de seu curso. A partir do link Visualizar

Demanda, o usurio ter acesso a demanda cadastrada por ele no sistema. Todos os dados

referentes demanda do curso estaro disponveis, alm de possibilitar a opo de excluso

de uma. As demandas so separadas por cada semestre existente no respectivo curso. Ao final,

o menu apresenta ao usurio a opo de Sair do sistema.

47

Figura 19 - Pgina inicial da rea de acesso da categoria coordenador

Baseando-se nos conceitos de usabilidade, que permite que o usurio alcance suas

metas de interao com sistema de uma maneira rpida e direta, a Figura 20 apresenta a tela

de Cadastrar Demanda.

Figura 20 - Exemplo de cadastro de uma demanda.

Nesta tela, o Coordenador realizar a demanda de salas por semestre do curso,

informando o semestre e a quantidade de alunos para que seja destinada uma sala a esta

turma. Por meio de uma grade de horrios, o coordenador poder cadastrar os horrios em que

aquela turma necessitar de uma sala de aula. Neste contexto a praticidade em que o usurio

ter para realizar tal tarefa foi levada em conta no desenvolvimento da interface, com isso

48

objetivo final do usurio poder ser alcanado com eficincia e o aprendizado para o uso ser

fcil e simples.

A Figura 21 apresenta a pgina inicial da rea de acesso do usurio SAP. Nesta pgina

o menu est disposto por ordem de funcionalidades contendo sub-menus como o Gerenciar

Salas. Atravs deste sub-menu, o usurio poder gerir todas as opes referentes s salas do

CUA. Outras opes so o Gerenciar Reserva e o Gerenciar Usurio, por meio destes o

usurio ter acesso s opes referentes s reservas e aos usurios. s opes de Gerenciar

Curso e Gerenciar Instituto so responsveis por manter os institutos e cursos existentes no

CUA. Ao final, o menu apresenta ao usurio a opo de Sair do sistema com segurana.

Figura 21 - Pgina inicial da rea de acesso da categoria SAP

A Figura 22 apresenta a pgina referente ao cadastro de salas, que pode ser acessada

atravs do menu Gerenciar Salas. Por meio dessa opo o usurio realizar o registro das

salas, preenchendo os seguintes campos: cdigo da sala, unidade, quadra, bloco, andar, tipo,

capacidade e observao. Essa possibilidade dar autonomia administrao em gerenciar o

crescimento do Campus. A interface foi desenvolvida de forma intuitiva, visando facilidade

no uso e a melhor interao entre interface e usurio. Ao passar o apontador do mouse sobre

49

algum campo, a interface mostrar uma pequena caixa de texto, informando ao usurio o que

se deve ser preenchido e apresentando uma explicao de cada item. Ao final da realizao do

cadastro, a interface responsvel por notificar o usurio se houve algum campo que no

ocorreu preenchimento, caso esteja em branco algum campo de preenchimento obrigatrio.

tambm de responsabilidade da interface, informar o usurio que o cadastro foi realizado com

sucesso ou se ocorreu algum erro no processo. Para que no haja duplicidade de informaes,

o sistema no permite o cadastro de duas ou mais salas com o mesmo cdigo de identificao.

Figura 22 - Pgina de cadastro de salas

A Figura 23 apresenta a pgina de visualizao das solicitaes de reservas eventuais.

Reservas eventuais so as reservas de salas especiais como o Anfiteatro, Laboratrio de

Informtica de uso geral, Sala de Audiovisual, Sala de Videoconferncia e o Planetrio. Estas

salas possuem solicitaes espordicas durante o semestre, pois podero no ser utilizadas

todos os dias. Mediante a este fato estas salas possuem uma reserva diferenciada das demais,

sendo assim, a reserva realizada em uma data e horrio especficos. Para realizar uma

reserva para esse determinado tipo de sala necessrio visualizar as solicitaes existentes

para estas salas. A Figura 23 ilustra um exemplo de solicitao destas salas. So informados a

50

SAP os dados referentes ao identificador da solicitao, o solicitante, o tipo de sala e da

unidade que a sala pertence. Para visualizar as demais informaes e atender a solicitao a

SAP dever clicar sobre o link existente no cdigo da solicitao.

Figura 23 - Pgina das solicitaes de reserva eventual

Atravs do acionamento do link para visualizar as informaes adicionais da

solicitao, a pgina ser redirecionada. A nova pgina mostrar ao usurio as informaes

referentes solicitao selecionada anteriormente. Entre as informaes mostradas estaro

presentes a data e o horrio de desejo do solicitante. Na mesma tela apresentado para a SAP

um link para Localizar Salas. Este link responsvel por abrir uma nova pgina, mantendo

assim a pgina anterior aberta ao usurio para que ela possa sempre ter, ao seu alcance, as

informaes da solicitao. Por meio desta opo, solicitaes de reservas eventuais, pode-se

visualizar todas as salas e suas respectivas agendas.

Aps o usurio visualizar a sala de interesse e sua agenda, ele ter condies de

realizar a reserva. A reserva realizada por meio de informar ao sistema o cdigo da sala em

que se deseja efetu-la. O sistema capaz de checar, por meio de consultas ao banco de

51

dados, se existe alguma outra reserva para aquela determinada sala, no dia e horrio

informados pelo solicitante. Caso a verificao apresente algum conflito de horrio, o sistema

informar ao usurio que no foi possvel realizar a reserva. Caso no ocorra nenhum

problema, a reserva ser efetivada no sistema. A Figura 24 apresenta a pgina de visualizao

de uma solicitao.

Figura 24 - Visualizar uma solicitao

A Figura 25 apresenta a visualizao das salas aps o link Localizar Salas ser acionado

pelo usurio. O desenvolvimento desta interface visa possibilitar ao usurio permanecer com a

pgina aberta com as informaes referentes solicitao e ao mesmo tempo ter a opo de

localizar uma sala que possa atender aquela solicitao. Este modelo visa otimizar o tempo e

o caminho gasto pelo usurio para se chegar ao objetivo final de reservar uma sala.

52

Figura 25 - Localizar salas

A Figura 26 apresenta a tela de realizar reserva fixa. Por meio desta tela, a SAP

capaz de visualizar a demanda de salas de um curso, isso ocorre por meio de filtros

disponveis ao usurio como Instituto, Curso e Semestre. Aps selecionar os dados de busca,

o sistema apresenta ao usurio a demanda. A demanda composta pela quantidade de alunos

de cada semestre do curso e pelo horrio de aulas. Com estes dados a SAP capaz de alocar

uma sala de aula para uma turma do curso durante aquele semestre, obedecendo aos horrios

informados pelo Coordenador. Inicialmente a sistema informa SAP se uma referida

demanda j foi atendida. Este fato mostrado ao usurio atravs de uma legenda posicionada

ao final da grade de horrios, onde esto identificados os dois possveis status da demanda

(demanda reservada (verde) e demanda no reservada (vermelha)). Por meio desta informao

o usurio poder prosseguir com a realizao da reserva ou escolher outros parmetros para a

busca da solicitao. Na parte inferior da tela mostrada ao usurio uma opo de Consultar

Sala e um link para Localizar Salas.

53

Figura 26 - Reserva fixa

O link para localizar Salas funciona como um atalho de busca para as salas. Ao

acionar o link, o sistema abrir uma nova janela para a realizao de uma busca. A Figura 27

apresenta uma busca informando os parmetros da Unidade Barra do Garas e a Capacidade

da Sala de 45 (quarenta e cinco) alunos. Atravs destes parmetros o sistema retorna ao

usurio uma relao com todas as salas referentes aos parmetros de busca informados. Por

meio dessa relao possvel ao usurio visualizar a agenda de uma sala antes de realizar uma

reserva.

54

Figura 27 - Busca por salas

O sistema, aps o usurio informar o cdigo da sala, na opo Consultar Salas,

mostrado na Figura 26, realiza uma verificao na base de dados pelo cdigo da sala

informado verificando se aquela sala possui reserva e, se caso possuir, verifica se possui

conflito de horrio. Ao trmino da verificao o sistema informar ao usurio o resultado por

meio de uma legenda. A Figura 28 apresenta o resultado de uma consulta pelo nmero da

sala, em particular a verificao para a Sala 107. Neste exemplo a sala no apresentou conflito

de horrio, sendo assim o usurio possui a opo de realizar a reserva ou buscar por outra

sala.

O desenvolvimento dessa interface aborda os conceitos de informao visual onde o

usurio, por meio de dados informados, pode ter o conhecimento sobre o que ocorreu aps a

execuo do sistema. Nesta interface foram utilizadas legendas ilustrativas.

55

Figura 28 - Exemplo de reserva fixa

Este captulo procurou descrever dois cenrios comuns no processo de gerenciamento

de salas. Com o auxilio de figuras, primeiramente efetuou-se reservas eventuais e,

posteriormente, uma reserva sobr

sgs - protÓtipo de um sistema de gerenciamento de salas para o campus universitÁrio do araguaia

Documents