projecto sileq - web.fe.up.ptmgi00012/docs/mgi_bd.pdf · proposta de projecto sileq 2 sumário...

Projecto SiLEQ

Sistema de Informação das disciplinas de

Laboratórios de Engenharia Química

Francisco Barbedo: [email protected] Jorge Meneses Freitas: [email protected]

Rui Pedro Correia: [email protected]

Mestrado em Gestão de Informação Bases de Dados

João Falcão e Cunha

Proposta de Projecto SiLEQ

2

Sumário Executivo O projecto, cuja proposta aqui é apresentada, surgiu no âmbito de um trabalho a realizar para a disciplina de Bases de Dados do Mestrado em Gestão de Informação, na Faculdade de Engenharia da Universidade do Porto (FEUP). O presente relatório constitui o corolário do processo inciado e prossegue a linha de rumo apresentada no relatório anterior. Pretende-se com este documento dar uma perspectiva detalhada do trabalho desenvolvido na segunda fase deste projecto bem como apresentar resultados conseguidos, e potenciais perspectivas de continuidade do desenvolvimento do sistema. Relembrando o conteúdo e objectivo do projecto diremos que este visa o desenvolvimento de um sistema de informação de suporte aos serviços académicos e administrativos das disciplinas de Laboratórios de Engenharia Química (LEQ) da licenciatura em Engenharia Química da FEUP. Inclui como valências funcionais a criação e gestão de grupos de alunos, inscrições nas turmas, calendário de aulas, trabalhos realizados pelos discentes e suas avaliações. A plataforma de desenvolvimento imposta pelo programa da disciplina e provavelmente mais adequada à dimensão sectorial do sistema a suportar, foi o Microsoft Access. O objectivo final restringe-se à elaboração de um protótipo, que será denominado de SiLEQ: Sistema de Informação das Disciplinas de Laboratórios de Engenharia Química. Prevê-se e aconselha-se veementemente a sua futura integração no sistema de informação da Faculdade de Engenharia da Universidade do Porto (SiFEUP). Para a concretização deste trabalho seguiram-se vários passos, de certa forma iterativos, alguns dos quais já apresentados em relatório anterior. Salientamos que se trata de procedimentos normalizados para o desenvolvimentos de sistemas de informação e que compreendem análise de processos organizacionais, definição de casos de uso , de requisitos funcionais/não-funcionais, e respectiva modelação através de diagramas UML de classes e Entidades/Associação. Considerando a natural alteração forçada pelas circunstâncias dinâmicas sempre presentes no desenvolvimento de um projecto, serão efectuados ajustes que adeqúem os diagramas anteriormente apresentados aos novos esquemas conceptuais criados nesta segunda e última fase de processo. A segunda fase consistiu na implementação dos modelos inicialmente propostos, ou seja, passou-se de uma fase de concepção análise para uma segunda fase directamente ligada ao à aplicação prática e desenvolvimento de trabalho na aplicação escolhida. O trabalho desenvolveu-se segundo três eixos: 1. A construção de tabelas no ACCESS respeitando o modelo proposto no modelo E/R e posteriormente a criação de associações entre as tabelas construídas segundo o modelo proposto e que pretende dar resposta aos requisitos funcionais definidos. 2. A construção de formulários de forma a viabilizar a interface gráfica com o utilizador. 3. A elaboração de um manual de qualidade e de um dicionário de dados que permitam complementar o sistema proposto e definir consistentemente os atributos utilizados no sistema. Estas 3 linhas condutoras serão detalhadas no cap. 4. As metodologias e normas seguidas são abordadas no Manual de Qualidade (ANEXO A)


3

Índice de Conteúdos

1. Introdução

1. Introdução........................................................................................................................................... 4 1.1. Apresentação da Organização...............................................................................................................4 1.2. O Projecto SiLEQ na Organização.........................................................................................................4 1.3. Estudo e Desenvolvimento do Protótipo SiLEQ.....................................................................................5 1.4. Definição dos principais termos utilizados .............................................................................................5 1.5. Organização e Temas Abordados no Presente Relatório ......................................................................5

2- Apresentação da plataforma tecnológica escolhida........................................................................... 6

3 Gestão do Projecto ................................................................................................................................ 8 3.1. Planeamento de actividades e resultados..............................................................................................8 3.2. Planeamento de recursos e orçamentação............................................................................................8 3.3. Planeamento do processo de controlo...................................................................................................9 3.4. Outros assuntos...................................................................................................................................10

4. Especificação do Sistema a desenvolver .......................................................................................... 11 4.1. Casos de Uso ......................................................................................................................................11 4.2. Requisitos Funcionais ..........................................................................................................................12 4.3. Especificação de suportes lógicos e interfaces externas.....................................................................14

Conclusões e perspectivas de trabalho futuro ...................................................................................... 16

Referências e Bibliografia ......................................................................................................................... 18

ANEXO A – Manual de qualidade ......................................................................................................... 19

ANEXO B – Plano de Actividades ......................................................................................................... 21

ANEXO C – Diagrama de Classes ........................................................................................................ 23

ANEXO D – Modelo Relacional ............................................................................................................. 24

ANEXO E – Exemplos de Formulários.................................................................................................. 25

ANEXO F – Esquema de Base de Dados ............................................................................................. 26

ANEXO G – Dicionário de Dados.......................................................................................................... 27


4

1. Introdução

1.1. Apresentação da Organização As disciplinas de Laboratórios de Engenharia Química (LEQ) estão inseridas no plano do curso da licenciatura em Engenharia Química, da Faculdade de Engenharia da Universidade do Porto. Estas disciplinas visam a demonstração (prática) de conceitos leccionados em outras disciplinas (teóricas) do curso de Engenharia Química. Por isso, são essencialmente laboratoriais e práticas. No curriculum do curso de Engenharia Química existem 4 disciplinas de Laboratórios de Engenharia Química, distribuídas pelos 4 semestres dos 3º e 4º anos do curso. Para além de objectivos mais específicos (relacionados com as experiências realizadas pelos alunos no âmbito de cada disciplina), as disciplinas de LEQ permitem que os alunos desenvolvam competências de manipulação de instrumentos, no uso de técnicas no âmbito da Engenharia Química e de discussão crítica dos resultados. As disciplinas visam ainda permitir o desenvolvimento de competências de trabalho em equipa, de cooperação, de disciplina, de comunicação escrita e oral, a interiorizarão duma base de conhecimento e a validação experimental de conhecimentos teóricos adquiridos (Mendes, 2000).

1.2. O Projecto SiLEQ na Organização Este projecto surge no seguimento do desejo manifestado pelos professores das disciplinas de Laboratórios, em disporem de uma ferramenta informática que lhes permita, de uma forma eficiente, fazer a gestão dos assuntos administrativos e académicos relacionados com as suas disciplinas. Esta ferramenta informática, que estará assente numa base de dados, aborda as seguintes áreas:

- Dados pessoais dos alunos - Classificações dos alunos - Gestão das inscrições dos alunos nos respectivos grupos e turmas - Calendário dos grupos e da disciplina


5

1.3. Estudo e Desenvolvimento do Protótipo SiLEQ Este trabalho consistiu no desenvolvimento de um protótipo, denominado SiLEQ que satisfaça os tópicos focados anteriormente. Nesta fase, foi apenas desenvolvido o protótipo, pelas seguintes razões:

- Numa perspectiva de utilização real, uma aplicação com este caracter deve ser desenvolvida através do sistema de informação transaccional existente actualmente na organização, ou seja, o SiFEUP. Desta forma, manter-se-á todo o repositório de dados, a lógica e todo o interface já existente, tanto para os alunos como para os professores.

- O contexto desta fase do projecto é um trabalho apenas para uma disciplina e deve ser encarado como tal.

1.4. Definição dos principais termos utilizados Ao longo deste documento serão utilizadas estas palavras e abreviaturas, com o seguinte significado:

- DEQ: Departamento de Engenharia Química - FEUP: Faculdade de Engenharia da Universidade do Porto - LEQ: Licenciatura em Engenharia Química - SiLEQ: Sistema de Informação das disciplinas de Laboratórios de

Engenharia Química - SiFEUP: Sistema de Informação da Faculdade de Engenharia da

Universidade do Porto -

1.5. Organização e Temas Abordados no Presente Relatório

Este documento tem como objectivo apresentar o projecto e descrever como é o seu planeamento.Os capítulos seguintes abordarão os seguintes assuntos:Apresentação da plataforma tecnológica escolhida e suas justificações

Estudo de necessidades técnicas e selecção da plataforma Gestão do Projecto e o seu planeamento Estruturas de acompanhamento, actividades, recursos, orçamento e processos de controlo Especificação do Sistema a desenvolver Descrição de quais e como os processos devem ser implementados


6

2- Apresentação da plataforma tecnológica escolhida

A aplicação a desenvolver irá gerir informação relativa à gestão das disciplinas de LEQ.

O sistema existente actualmente, que suporta alguns aspectos da actividade lectiva na organização é o SiFEUP, assente na seguinte tecnologia:

Base de dados: Tipo relacional de grande capacidade, Oracle

Interface: Páginas HTML dinâmicas que são visualizadas por browser WEB

O trabalho de que trata este projecto apresenta uma dimensão mais reduzida (pois apenas se restringe às disciplinas de LEQ), como se vê nos seguintes números:

- Número de disciplinas: 4

- Alunos inscritos em todas as disciplinas: 240

- Novos alunos por ano nas disciplinas: 60

- Número normal de turmas por disciplina: 5

- Número normal de grupos por turma: 6

- Número total de grupos: 30

- Número normal de alunos por grupo: 2

Optou-se, como indicado em relatório anterior, por uma tipologia relacional para a base de dados a desenvolver atendendo â vantagem em ser integrada com o SiFEUP o qual, relembra-se assenta em sistema de base de dados relacional de grande porte com tecnologia ORACLE.

Atendendo igualmente à característica sectorial e restrita do sistema a desenvolver, bem como à relativamente reduzida dimensão de informação a gerir pareceu lógica a opção por um sistema de pequena/média capacidade que garantisse todavia a capacidade de futura integração no SiFEUP.

Para aumentar a funcionalidade do sistema, a base de dados deverá estar disponível nos laboratórios informáticos da FEUP.

Foi concedida especial atenção à interface da solução aplicacional, que viesse a permitir uma utilização fácil e o mais intuitiva possível. A articulação com páginas HTML foi considerada como uma vantagem a incluir.

Resumindo a infomação sobre a plataforma tecnológica escolhida:

- Base de Dados: Microsoft Access 2000

- Interface com o Utilizador:

- Ecrãs: formulários da base de dados

- Mapas e Listagens: relatórios da base de dados

- Modelos de consultas


7

Considera-se o ACCESS uma ferramenta suficientemente robusta e facilmente utilizável tanto para quem desenvolve como para quem utiliza pelo que a sua utilização, considerando o contexto funcional e organizacional do projecto, se considera perfeitamente justificada


8

3 Gestão do Projecto

3.1. Planeamento de actividades e resultados O cronograma das actividades encontra-se no Anexo A.

3.2. Planeamento de recursos e orçamentação Os recursos necessários para o desenvolvimento deste projecto foram já apresentados no anterior relatório. Como não se verificou acréscimo de recursos quer humanos, quer técnicos, mantém-se a proposta apresentada.

Tipo Nome Fórmula Resultado

Humano Francisco Barbedo Jorge Meneses Freitas Rui Pedro Frias

Cfc = Coeficiente: 1/6 (a) HS = Horas por semana: 48 (b) S = Semanas: 12 (c) P = Pessoas: 3 Cfc x HS x S x P = 1/6 x 48 x 12 x 3

Total de Horas do Projecto = 288 horas Horas / Homem = 96 horas Custo Hora RH = 217$0 (d) Custo em RH do Projecto = 62.496$0

Tecnológico PC’s, Impressora e Office

Total de Horas do Projecto x Custo Hora do Equipamento

Custo Hora do Equipamento = 33$0 (e) Custo do Equipamento no Projecto = 9.504$0

Total ... 288 horas, 72.000$0 Notas: (a): Coeficiente entre o tempo dispendido para a disciplina (e trabalhos para a mesma) e o tempo dispendido com todas as disciplinas do mestrado (e respectivos trabalhos) =1/6 (b): Horas por Semana disponíveis para o Mestrado:

- Segunda-feira: 12 horas (manhã, tarde e noite para o mestrado) - Terça-feira: 12 horas (manhã, tarde e noite para o mestrado) - Quarta-feira: 4 horas (noite para o mestrado) - Quinta-feira: 4 horas (noite para o mestrado) - Sexta-feira: 4 horas (noite para o mestrado) - Sábado: 12 horas (manhã, tarde e noite para o mestrado) - Domingo: 0 horas (descanso, dia religioso) - Total: 48 horas

(c): Número de Semanas possíveis para a realização do trabalho: - Meses de Março, Abril e Maio: 12 semanas


9

(d): Custo Hora RH do Projecto é calculado com o pressuposto do custo de uma hora de propina paga do Mestrado:

- Horas Disponíveis para o 2º Semestre do Mestrado - 3 meses x 4 semanas/mês x 48 horas/semana = 576 horas

- Custo do 2º Semestre: Propina: 125.000$0 - Custo / Hora -> 125.000$0 / 576 horas = 217$0

(e): Custo Hora do Equipamento: Com o pressuposto de custo de aquisição de 300.000$0 e período de amortização de 4 anos

- 300.000$0 / (48 meses x 4 semanas/mês x 48 horas/semana) = 33$0 É menosprezado o custo da electricidade e de área ocupada.

3.3. Planeamento do processo de controlo

O processo de controlo de execução do projecto foi continuamente realizado através de reuniões entre os vários elementos. O fluxograma de comunicação incluindo os diversos passos nas várias situaçãoes identificadas assim com os meios técnicos a utilizar foram definidos a apresentados no relatório anterior e foram mantidos segundo o esquema preconizado:

O método de marcação das reuniões foi baseado no contacto directo, via telemóvel ou através do correio electrónico. Neste último caso o formato das mensagens era o seguinte:

- “Para:” todas as pessoas que são convocadas a reunião; - “CC:” as pessoas do projecto que não têm que ir à reunião, mas assim

também ficam informados que determinadas pessoas vão-se juntar em determinada hora e local;

- “Assunto:” <Nome Projecto>: Reunião para <data, hora pretendida> no <local>;

- “Corpo”: Apresentação da agenda proposta e <data, hora limite> para confirmação de presença e da agenda;

- Exemplo - Para: [email protected], [email protected] - CC: [email protected] - Assunto: SiLEQ: Reunião para 2001.04.16 14:30 na B333 - Corpo:

Viva! Caros colegas, os objectivos da reunião são: Encerramento do modelo UML Esquematização do Caderno de Análise Distribuição de tarefas

Agradeço confirmação até dia 13, no máximo 17h00.

Cumprimentos a todos, Jorge Meneses

mailto:[email protected]




10

3.4. Outros assuntos

Conflitos Os conflitos que possam acontecer no decorrer do projecto, ficam com decisão remetida para a Direcção do Mestrado em Gestão de Informação.


11

4. Especificação do Sistema a desenvolver

4.1. Casos de Uso As disciplinas de LEQ são disciplinas laboratoriais que visam demonstrar (na prática) conceitos leccionados noutras disciplina (teóricas) do curso de Engenharia Química. Estas disciplinas são geridas por professores do departamento de Engenharia Química. Os casos identificador foram os seguintes: 1. Inscrever alunos: No início de cada ano lectivo o professor inscreve os alunos da

disciplina que lecciona nos grupos que são constituídos para a elaboração de experiências e aulas práticas. Para cada aluno existe a opção de “Nota Congelada”; Esta opção funciona quando um aluno se inscreve à disciplina com outras disciplinas em atraso. Nestas circunstâncias o professor pode admitir o aluno na disciplina com a reserva da nota não ser lançada (ser congelada) até que a situação relativamente às disciplinas atrasadas seja resolvida

2. Criar Grupos: O Professor cria grupos à medida que os alunos se vão inscrevendo nos

mesmos. Nestes casos os grupos têm identificação específica devendo funcionar como um objecto independente do conjunto dos alunos individuais

3. Constituir grupos: Os alunos formam grupos entre si e comunicam a sua intenção ao

docente, que os confirma, na base de dados. Estes grupos terão um número limite de alunos, que será definido pelo docente aquando da criação dos mesmos.

4. Criar ficha de aluno: O aluno cria a sua ficha de disciplina inserindo dados de carácter

identificativo como nome, morada, telefone, correio electrónico, página Web. O professor cria a ficha de cada aluno...

5. Criar ficha de disciplina: O Professor no início do ano lectivo cria a ficha da disciplina

que contém todos os elementos necessários para o funcionamento da mesma: (número de alunos inscritos, dados de cada aluno, número de turmas e respectivos horários, número de alunos por grupo, experiências a realizar e eventos quer da disciplina (exames, Tc)

6. Constituir turmas: Os alunos deverão inscrever-se nas turmas existentes e dentro delas

num determinado grupo seguindo as restrições impostas: Um número máximo de 3 alunos por grupo, um número de 6 grupos por turma. Estas restrições deverão poder ser modificadas consoante o critério de cada professor.

7. Definir avaliação: O professor determina quais os processos de avaliação escolhidos,

forma de aplicação dos mesmos e peso (na nota final) da classificação atribuída a cada objecto de avaliação determinado

8. Atribuir Avaliação: O professor atribui avaliação de acordo com regras por ele

determinadas ao grupo e a cada elemento do grupo individualmente. Para esta prática contribuem os resultados dos objectos de avaliação e a própria perspectiva pessoal do professor sobre o trabalho do aluno.


12

9. Marcar data de avaliação. O professor marca, de forma sincronizada com a administração das aulas e o bom desenvolvimento de experiências laboratoriais curricularmente definidas, o calendário de objectos de avaliação, ou seja de eventos a serem cumpridos pelos alunos e destinados a fornecer informação sobre o seu desempenho na aprendizagem dos programas curriculares leccionados. O professor pode adiar ou alterar data marcada de execução de objecto de avaliação por impedimentos de diversa ordem, quer por parte do discente ou da parte dele próprio.

10. Calendarizar ano lectivo e eventos: O professor estabelece a execução do programa da

sua disciplina de acordo com o calendário do ano lectivo em curso e atendendo a restrições verificadas por indisponibilidade de datas, por exemplo, a queima das fitas, feriados que coincidam com dias úteis, etc. Neste calendário são igualmente incluídos datas de avaliação. (Vt. ficha de disciplina)

4.2. Requisitos Funcionais 1. ALUNO Refª Requisito 1.1. Os alunos acedem à Base de Dados através da colocação da respectiva password

no campo destinado para o efeito. 1.2. A Base de Dados contém os dados pessoais dos alunos (nome, código, disciplina,

contactos. 1.3. Foi criado um campo “especial” destinado a alunos que tenham pedido para

“congelar” a nota 1.4. Os alunos apenas têm acesso, para consulta, aos seus dados 1.5. Os docentes têm acesso, para consulta e modificação, a todos os dados de todos os

alunos, respeitantes à disciplina leccionada 1.6. O sistema permite aos docentes a pesquisa de alunos através do parâmetro

identificativo <nome>. Deverá poder visualizar os nomes de todos os alunos inscritos

2. GRUPOS Refª Requisito 2.1. Um aluno, após aceder à sua área deve iniciar (caso ainda não o tenha feito) a

criação de um grupo escolhendo para tal o(s) colaga(s) com os quais se deseja agrupar (desde que nenhum dos elementos pertença já a um grupo). A constituição do grupo devcerá ser comunicada ao docente, que validará (ou não) o mesmo na base de dados.

2.2. Antes da validação do grupo, os alunos de um determinado grupo, deverão estar já todos inscritos numa mesma turma.

2.3. O docente pode cancelar a criação do grupo. 2.4. Quer o número de alunos por grupo, quer o número de grupos por turma são

fixados pelos docentes num campo especifico da base de dados. 2.5. Os alunos podem consultar as informações relativas aos trabalhos que devem

realizar no âmbito da disciplina (datas, classificações, etc.) 2.6. O professor pode consultar os dados correspondentes a qualquer grupo. Deverá ter


13

também a opção de consultar todos os grupos de determinada turma.

3. DISCIPLINA

Refª Requisito 3.1. No início de cada disciplina, o docente deve introduzir na base de dados todos os

dados necessários para o funcionamento da mesma (número de alunos inscritos, dados de cada aluno, número de turmas e respectivos horários, número de alunos por grupo, experiências a realizar e eventos quer da disciplina (exames, Tc) quer outros (queima das fitas, feriados, etc.).

3.2. A base de dados permite ao docente a manutenção dos dados relativos a alguns alunos ou a determinadas experiências que tenham sido adicionados à base de dados em outros anos ou em outras disciplinas.

4. CALENDÁRIO

Refª Requisito 4.1. A BD, após a inscrição do grupo em determinada turma, cria um calendário com as

datas (e horas) dos eventos (trabalhos, exames, Tc) de cada aluno e respectivo grupo.

4.2. É permitido permitida aos docentes a consulta (e alteração) do calendário de cada aluno, grupo ou turma ou mesmo de toda a disciplina (contendo os eventos mais importantes).

4.3. Os docentes podem consultar as datas de realização (para todos os grupos ou alunos) de determinado evento.

4.4. Os alunos apenas tÊm acesso, para consulta, ao seu calendário pessoal (indicando as datas dos trabalhos, exames, etc.).

4.5. Para cada data do calendário criado, é indicado qual o evento a realizar, por quem e deverá também existir uma sinalização indicando se o mesmo foi realizado.

5. CLASSIFICAÇÕES

Refª Requisito 5.1. A base de dados permite aos docentes registarem as classificações dos vários

objectos de avaliação. 5.2. Os alunos têm acesso, para consulta, às classificações atribuídas pelos docentes a

todos os alunos da disciplina. 5.3. Os docentes podem consultar as classificações de cada aluno, turma ou de todos os

alunos da disciplina. 5.4. A base de dados permite aos docentes a consulta de classificações específicas (ex.:

todas as classificações atribuídas a determinado trabalho). 5.5. A base de dados permite aos docentes a consulta da média das classificações

atribuídas (quer da nota final da disciplina, quer da classificação de determinados trabalhos).


14

4.3. Especificação de suportes lógicos e interfaces externas 4.3.1. O Esquema de Base de dados ou seja o planeamento e construção de tabelas a incluir seguiu o modelo E/R proposto e apresentado no relatório anterior. A necessidade técnica de estabelecimento de relações de cardinalidade “muitos-para-muitos” que implicou a criação de tabelas de ligação. Relativamente ao modelo inicialmente proposto verificou-se necessário criar mais 5 tabelas. Foram incluídos igualmente atributos que se julgaram necessários para o melhor funcionamento da BD As associações estabelecidas entre as tabelas criadas respeitaram igualmente o modelo E/R apresentado tendo sido feito o necessário ajustamento às novas tabelas criadas.

4.3.2. Os formulários foram criados a partir das tabelas respeitando uma lógica de facilidade de utilização e inserção de informação necessária ao seu manuseamento de forma imediatamente perceptível para o utilizador. Foi incluído no interface gráfico elementos lineares que ligando os botões representativos das funcionalidades da BD, representam a ligação explícita hierárquica existente entre essas mesmas funcionalidades. Não foi no entanto respeitado o interface concebido anteriormente e materializado nos desenhos de maquetas realizados. A razão para tal foi, admitimos, a dificuldade da nossa parte de criar no ACCESS um conjunto de formulários que obedecesse quer à mesma concepção gráfica, quer à estrutura de navegação aí proposta. Optou-se por criar formulários com os recursos convencionais do ACCESS que apesar de tudo oferecem capacidades gráficas que avaliámos como consideráveis. Julga-se que o resultado conseguido é um bom compromisso entre o possível e o desejável. 4.3.3. O Dicionário de Dados foi elaborado de forma a proporcionar duas perspectivas informativos sobre a BD. Por um lado uma estruturação por tabelas identifica os diversos atributos inclusos e suas propriedades principais, o que permite uma visualização orientada por tabela. Uma segunda perspectiva lista os atributos alfabeticamente, persistindo a informação sobre a tabela a que pertencem mas em que é dada informação adicional relativamente ao seu papel na tabela:

Se constituem ou integram chave primária Se constituem chave alheia Se são indexados Se são de preenchimento obrigatório

A sua descrição Exemplos de aplicação

O objectivo básico é criar um repositório de informação definidor e explicativo da estrutura e conteúdo da base de dados passível de permitir a funcionalidade de recuperação do próprio sistema, pelo menos ao nível dos seus elementos estruturantes, Informação adicional poderá ser encontrada noutros documentos como o Diagrama de classes e de Entidades/Relação O diagrama de classes UML proposto encontra-se no anexo C. O modelo relacional proposto encontra-se no anexo D. Os exemplos de formulários encontram-se no anexo E


15

O esquema de Base de Dados encontra-se no anexo F O Dicionário de Dados encontra-se no anexo G


16

Conclusões e perspectivas de trabalho futuro O trabalho desenvolvido neste projecto permitiu a criação de um protótipo de Base de Dados destinado a apoiar a actividade funcional da administração e gestão das disciplinas de LEQ. Como conclusão do trabalho efectuado considera-se que foi um processo a todos os títulos compensador na medida em que por um lado permitiu consolidar conceitos teóricos apreendidos e, simultaneamente, pôr em prática a construção do que, julgamos, poderá constitui uma solução efectiva para o objectivo proposto. Alguns dos benefícios alcançáveis a curto prazo do refinamento e aplicação deste protótipo serão:

Automatização de tarefas como a temporização do ano lectivo, contabilizando-se as diversas variáveis existentes, como feriados, actividades extracurriculares, exames. Esta funcionalidade permite a simplificação do trabalho dos docentes com as consequências que daí derivam de optimização da produtividade no trabalho

Constituição de um repositório de informação pesquisável passível de apoiar a gestão das diversas componentes administrativas e pedagógicas da disciplina controlo de actividades constituintes da gestão da disciplina de uma forma imediatamente perceptível o que permite a monitorização do processo e a realização de eventuais ajustamentos considerados necessários para a concretização dos seus objectivos da forma mais eficiente possível

Claramente que, estando no estágio de protótipo e não tendo sido testado, não é possível a sua aplicação imediata. No entanto os passos principais estão dados e o resultado conseguido permite encarar optimisticamente o seu desenvolvimento futuro, o qual inclui

Desenvolvimento de funcionalidades de gestão de ficheiros para além de dados unicamente. Esta valência funcional permitirá, por exemplo, o armazenamento de resultados experimentais e relatórios efectuados que serão pesquisáveis e recuperáveis de forma mais eficiente, dada a sua disponibilização em linha.

Implementação de ferramenta de verificação dos cálculos existentes nos trabalhos realizados pelos alunos e armazenados na Base de dados, através de simuladores programados para o efeito. Esta valência potenciará o processamento automatizado de uma actividade normalmente desempenhada de forma manual, com os consequentes benefícios no seu desempenho

Como foi referido, o SiLEQ, por se aplicar a uma unidade orgânica inserida num conjunto maior que é a FEUP deverá logicamente ser articulado com o seu sistema de informação dados os benefícios daí decorrentes. Considera-se portanto que todo o desenvolvimento futuro deverá ser pensado atendendo a esta prioridade. Neste contexto inclui-se como funcionalidade a desenvolver

A articulação do sistema SiLEQ com o SiFEUP permitindo assim a gestão e troca de informação comum, evitando potenciais redundâncias e incrementando a eficiência do sistema


17

.Como conclusão final, deve ser frisado que a execução de projectos tem de se reger por dois macrofactores que nos são dados pela realidade tal como ela é analisada e interpretada: O que é técnica e organizacionalmente necessário e aquilo que é efectivamente exequível! A solução aqui apresentada refere-se ao segundo factor, antecipando no entanto pistas e soluções para a concretização do primeiro.


18

Referências e Bibliografia

BARROS, Carlos - Gestão de projectos. Lisboa: Edições Sílabo. 1994 BENNET. Simon; McROBB. Steve; FARNER, Ray, 1999 - Object Oriented Systems Analysis and Design.. Londres: McGrawHill. 1999 MENDES, A., 2000, Laboratórios de Engenharia Química III – Reactores em Fase Homogénea, Reactores Catalíticos, Separações Não Convencionais e Tecnologia dos Sólidos Divididos, FEUP, DEQ. OBJECT MANAGEMENT GROUP- Unified Modeling Language Specification v.1.3, 1999. URL: http://www.rational.com/uml/resources/documentation/index.jsp (em 2001-07-07) SOMERVILLE, I., ; SAWYER, P., 1997, – Requirements Engineering: A good practice guide. England: Wiley and Sons, 1997

http://www.rational.com/uml/resources/documentation/index.jsp


19

ANEXO A – Manual de qualidade O manual de qualidade deste projecto não é um documento muito extenso pelo facto de: • Não ter sido exigida uma preocupação excessiva no desenvolvimento deste capítulo,

e • Se tratar de um projecto semi-fictício, i.e. , o cliente a quem é apresentado não é

uma organização contratante nem tão pouco foi de forma alguma estabelecido qualquer tipo de vínculo contratual.

Os elementos que se enumeram neste capítulo restringem-se a referência de fontes utilizadas para a produção de documentos técnicos que integram o projecto e explicações relativas a eventuais desvios conscientemente decididos relativamente a alguns aspectos do projecto. Atendendo a que os passos dados não corresponderam a um tratamento exaustivo de uma situação mesmo estes elementos serão todavia pouco numerosos 1. Modelação orientada a objectos O único modelo utilizado com esta técnica foi o diagrama de classes para o qual se utilizou a linguagem de modelação UML. O documento técnico seguido para para a sua concepção e desenho foi :

OBJECT MANAGEMENT GROUP. Unified Modeling Language Specification v.1.3, 1999. URL: http://www.rational.com/uml/resources/documentation/index.jsp (em 2001-07-07)

Dentro do diagrama de classes assumiu-se a notação {xor] a qual é definida no documento acima referido (p. 289) como uma restrição que indica

“...a situation in which only one of several potential associations may be instantiated at one time for any single instance. This is shown as a dashed line connecting two or more associations, all of which must have a classifier in common, with the constraint string “{xor}” labeling the dashed line. Any instance of the classifier may only participate in one of the associations at one time. Each role name must be different. (This is simply a predefined use of the constraint notation.)”

A aplicação da notação ao diagrama de classes proposta enquadra-se totalmente nesta definição na medida em que liga duas associações que apenas se podem verificar alternativamente. A pertinência da aplicação deste restrição é a nosso ver justificada. Optou-se no entanto, no primeiro diagrama apresentado, por “aportuguesar” a expressão através da utilização da partícula “ou”. Na nossa perspectiva e do ponto de vista semântico o significado manteve-se inalterado sendo preservado o significado e consequente validade da notação. Esta opção foi motivada pelo facto de que um diagrama, qualquer que seja o modelo ou técnica utilizadas, deve ser perfeitamente compreensível para o utilizador, o qual não tem obviamente que dominar técnicas de modelação ou sequer uma língua estrangeira.

http://www.rational.com/uml/resources/documentation/index.jsp


20

De resto nesta linha de raciocínio as próprias notações de multiplicidade utilizadas não são carateristicamente UML uma vez que a para a representação de “muitos” é utilizado um círculo cheio e não asteriscos e/ou indicação numérica como seria semanticamente correcto. O motivo para tal prática prende-se apenas com a maior facilidade de interpretação e compreensão por parte do utilizador a quem o projecto se destina. Na nossa perspectiva as duas situações equivalem-se já que para ambas se encontra subjacente idêntico critério. 2. Modelo Relacional Para a elabração deste modelo foi utilizada a ferrmanta Oracle Designer 2000. Para a sua escolha foram considerados os seguntes argumentos:

− É referida no manual da disciplina como uma ferrmante válidae sonsequentemente susceptível de ser utilizada

− Foi a ferramente utilizada na modelação do SiFEUP − É considerada uma ferramenta de referência no contexto de desenvolvimento de

bases de dados 3. Definição de requisitos funcionais: Para este processo não foi seguida de forma rigorosa qualquer norma. Indirectamente foram consultadas partes do livro referido na bibliografia geral: (SOMMERVILLE, 2000) 4. Desenvolvimento de maquetas de interface de utilizador Foi utilizado o Powerpoint 2000 5. Desenvolvimento de esquemas de base de dados, tabelas, associações entre tabelas, formulários, pesquisas e relatórios Tendo sido indicado que qualquer manual comercial do ACCESS 2000 seria adequado para o fim em vista, utilizou-se como referência o livro, VIESCAS, John – Running ACCESS 2000. Porto, 2000: McGrawHill


21

ANEXO B – Plano de Actividades

ID Task Name Start EndDurationM ay 2001

5-13 5-20 5-27 6-3 6-10 6-17 6-24 7-1 7-8

1 7w 02-07-200115-05-2001Desenvolvimento do protótipo

2 3w 04-06-200115-05-2001Definição de Base de Dados

3 4w 02-07-200105-06-2001Desenvolvimento dos ecrãs

4 2.40w 02-07-200115-06-2001Desenvolvimento de relatórios

5 1w 09-07-200103-07-2001Elaboração do relatório de projecto

6 0.80w 06-07-200103-07-2001Revisão do documento

Jun 2001 Jul 2001

7

Aug 2001

7-15 7-22 7-29 8-5

09-07-200109-07-20010.20wApresentação do projecto


22

#Pessoa_IdNome_PessoaPasswordE_MailWeb_PageTelefoneTipo_Pessoa

PESSOA

#Disciplina_IdNome_DisciplinaAno_Curricular

DISCIPLINA

#Turma_IdDia_SemanaHora_InicioHora_Fim

TURMA_DIAS_SEMANA

#Aula_IdDataHora_InicioHora_Fim

AULA

#Resultado_Avaliacao_IdAcontecimentoNova_DataNota_Atribuida

RESULTADO_AVALIACAO

#Grupo_IdFechadoN_Alunos

GRUPO

#Evento_IdData_InicioData_FimMotivoInterrupcao_Aulas

EVENTO

#Calendario_IdAno_LectivoData_InicioData_Fim

CALENDÁRIO

#Turma_Id

TURMA

#Objecto_Avaliacao_IdTituloDescricaoTipo_ObjectoPeso_Nota_Final

OBJECTO_AVALIACAO

TemAulas

Tem

ÉConstituídaPor

Produz

Tem

Tem

Tem

ProfessorLecciona

Inclui

ANEXO C - Diagrama de Classes

Assiste

AlunoFazParteDe

Baseia-seEm

#Inscricao_IdNota_Congelada

INSCRICAO

Realiza Recebe

{xor}


23

CALEN D Á R IO# AN O _LECTIVO*D ATA_IN ICIO*D ATA_FIM

P ESSO A# PESSO A_ID*N O M E_PESSO A*PASSW O RDO E-M AILO W EBPAGE*TIPO _PESSO A

O BJECTO _A VA LIA CA O# O BJECTO _AVALIACAO_ID*TITU TO*D ESCRICAO*TIPO _O BJECTO*PESO _N O TA_FINAL

G R U PO _ELEM EN TO

EVEN TO# EVENTO _ID*D ATA_IN ICIO*D ATA_FIM*M O TIVO*INTERRUPCAO _AULAS

IN SCR ICAO*N O TA_CO NG ELAD A

TU R M A# TU RM A_ID

AU LA# AU LA_ID*D ATA*H O RA_IN ICIO*H O RA_FIM

G R U PO# G RU PO _ID*FECHAD OO N _ALUN O S

R ESU LTA D O _A VA LIA CAO# RESU LTADO _AVALIACAO _ID*ACO N TECIM EN TOO N O VA_D ATA*N O TA_ATRIBU ID A

D ISCIP LIN A# D ISCIPLIN A_ ID*N O M E_D ISCIPLIN A*AN O _CU RRICULAR

TU R M A_D IAS_SEM AN A# TU RM A_ID*D IA_SEM AN A*H O RA_IN ICIO*H O RA_FIM

é professor

ANEXO D - M odelo Relacional Proposto


24

ANEXO E – Exemplos de Formulários


25

ANEXO F – Esquema de Base de Dados


26

ANEXO G – Dicionário de Dados

Nom

e_Tabela

Atributo

Tipo_Dados

Tamanho_C

ampo

Necessário

Chave_Prim

ária

Chave_A

lheia

Indexado

Acontecimento_ID Texto 3 N S S

Acontecimento Acontecimento Texto 35 N N

Disciplina_ID Texto 10 S S S

Turma_ID Texto 10 S S S

Aula_ID Número 10 S S S

Data Data/Hora Data abreviada

S N

Hora_Início Data/Hora Data abreviada

N N

Hora_Fim Data/Hora Data abreviada

N N

Objecto_Avaliação_ID Número Inteiro longo N N

Aulas

Quem(e_avaliado) Número byte N N

Ano_Lectivo_ID Texto 9 S S S

Data_Inicio Data/Hora Data abreviada

S N Calendario

Data_Fim Data/Hora Data abreviada

S N

Dia_ID Texto 1 S S S

Dias_Semana Dia_da_Semana Texto 10 N N

Pessoas

Pessoa_ID Texto 10 S S


27

Nome_Pessoa Texto 50 S S N

Password Texto 10 S N

E_Mail Texto 50 N N

Web_Page Texto 50 N N

Telefone Texto 9 N N

Tipo_Pessoa Texto 1 S S N

Foto Objecto Ole - -

Pessoa_ID Texto 10 S S N

Disciplina_ID Texto 10 S S S Inscricoes

Nota_Congelada Sim/Não Sim/Não S N


Nome_Disciplina Texto 40 S N Disciplinas

Ano_Curricular Texto 1 S N

Disciplina_ID Texto 10 N S S Turmas_Disciplina Turma_ID Texto 3 N S S



Sessao_semana_ID Numeração automática

Número inteiro longo

- S S

Dia_ID Texto 3 S S N

Turma_Dias_Semana

Hora_Inicio Data/Hora Hora abreviada

S No


28

Hora_Fim Data/Hora Hora abreviada

S N

Objecto_avaliacao_ID Numeração automática

Número inteiro longo

- S S

Disciplina_ID Texto 10 S S

Titulo Texto 20 S N

Descricao Texto 50 S N

Tipo_Objecto Texto 5 S S N

Objectos_Avaliacao

Peso_Nota_Final Numero Número inteiro

S N



Aula_ID Numero Numero inteiro

S S S

Resultado_Avaliacao_ID Numeracao automatica

Numero inteiro longo

- S N

Grupo_ID Texto 3 N S S

Pessoa_ID Texto 10 N S

Acontecimento_ID Texto 3 N S N

Nova_Data Data/Hora Data abreviada

N N

Resultado_Avaliacao

Nota_Atribuida Numero Numero inteiro

S N

Tipo_Objecto Texto 5 N S S Tipo_Objecto

Objecto Texto 200 N N

Disciplina_ID Texto 10 S S S Grupos



29

Grupo_ID Texto 3 S S S

Fechado Sim/Não Sim/Não S N

N_Alunos Numero Numero inteiro

N N

Disciplina_ID 10 Texto S S S

Turma_ID 3 Texto S S S

Grupo_ID 3 Texto S S S Grupo_Elementos

Pessoa_ID 10 Texto S S S

Tipo_Pessoa Texto 2 N S S

Tipos_Pessoa Tipo Texto 50 N N

Ano_Lectivo_ID Texto 9 S S S

Evento_ID Numeracao automatica

Numero inteiro longo

- S S

Data_Inicio Data/Hora Data geral S N

Data_Fim Data/Hora Data geral S N

Motivo Texto 50 S N

Eventos

Interrupcao_Aulas Sim/Não Sim/Não S N

Disciplina_ID Texto 10 S Sim N

Turma_ID Texto 3 S Sim N Turmas

Pessoa_ID Texto 10 N S N


30

Atributo Nome_Tabela Descrição Ex

Acontecimento Acontecimento Evento aleatório que, a ocorrer, determina a remarcação de um objecto de avaliação.

Adiado por Doença

Acontecimento_ID Acontecimento Código de um acontecimento 001

Ano_Curricular Disciplinas O ano curricular relativo à disciplina e que o aluno frequenta

1

Ano_Lectivo_ID Calendario; Eventos Identificação do ano lectivo 2001/2002

Aula_ID Aulas; Resultado_Avaliação

Identificação de código de aula 211

Data Aulas Data da aula 23-05-2001

Data_Fim Calendario Data do indicativa do fim do ano lectivo

30-07-2001

Data_Fim Eventos Data indicativa do fim de determinado evento

23-05-2001

Data_Inicio Calendario Data do indicativa do nício do ano lectivo

3-09-2000

Data_Inicio Eventos Data indicativa do início de determinado evento

23-09-2001

Descricao Objectos_Avaliacao Descrição de objectos de avaliação Relatório sobre experiência laboratorial realizada estruturado da seguinte forma: Introdução; passos da experiência;


31

baixas a relatar.

Dia_da_Semana Dias_Semana Indicação do dia em que há aulas quarta

Dia_ID Dias_Semana; Turma_Dias_Semana

Indicação do código de dia de semana

2=segunda-feira 3=terça-feira 4=quarta-feira 5= quinta-feira 6=sexta-feira

Disciplina_ID Aulas; Inscricoes; Disciplinas; Turmas_Disciplina; Turma_Dias_Semana ;Objectos_Avaliacao; Resultado_Avaliacao; Grupos; Grupo_Elementos; Turmas

Identificação de código de disciplina

22

E_Mail Pessoas Endereço de correio electrónico [email protected]

Evento_ID Eventos Número de código de evento 33

Fechado Grupos Indicação se um determinado grupo de trabalho se encontra cheio e portanto fechado a novas entradas

X

Foto Pessoas Inserção de fotografia digitalizada

Grupo_ID Resultado_Avaliacao; Grupos; Grupo_Elementos

Código de identificação de grupos de alunos que assistem às aulas

003

Hora_Fim Aulas; Turma_Dias_Semana

Hora de fim de aulas 17.00

Hora_Inicio Aulas; Turma_Dias_Semana

Hora de início de aulas de turmas 14.30


32

Interrupcao_Aulas Eventos Indicação de interrupção de aulas Sim

Motivo Eventos Motivo de interrupção de aulas Queima das fitas

N_Alunos Grupos Número total de alunos em cada grupo

2; 3

Nome_Disciplina Disciplinas Nome das disciplinas Laboratórios de Engenharia Química V

Nome_Pessoa Pessoas Nome de pesoas intervenientes no sistema (Alunos; professores)

João Pinho de Sousa

Nota_Atribuida Resultado_Avaliacao Notas atribuidas aos discentes 18

Nota_Congelada Inscricoes Indicação específica àcerca do lançamento da nota de uma disciplina ser retida até à realização no tempo de um evento pré-determinado.

SIM

Nova_Data Resultado_Avaliacao Indicação de outra data para realização de avaliação por motivos de impossibilidade por parte do aluno ou professor ter procedido à avaliação na data prevista (Vt. Acontecimento)

23-07-2001

Objecto Tipo_Objecto Indicação da forma porque a avaliação é realizada:

exame, trabalho, avaliação contínua, etc

Objecto_Avaliacao_ID

Objectos_Avaliacao; Aulas

Identificação de código de tipo de objecto de avaliação

ac= avaliação contínua r=relatório e=exame el=exame laboratorial rf=relatório completo

Password Pessoas Password a introduzir por cada actor do sistema

582/=*


33

Peso_Nota_Final Objectos_Avaliacao Peso atribuido pelo professor a cada objecto de avaliação. Representado por percentagem

12%

Pessoa_ID Pessoas; Inscricoes; Resultado_Avaliacao; Grupo_Elementos; Turmas

Identificação de código de pessoa 100

Quem(e_avaliado) Aulas Indicação de actor a ser objecto de avaliação

António Silva

Resultado_Avaliacao_ID

Resultado_Avaliacao Resultado global da avaliação expresso em número

14

Sessao_semana_ID Turma_Dias_Semana Identficação de código de sessão semanal de aulas

11

Telefone Pessoas Nº de telefone de cada actor do sistema

223395278

Tipo Tipos_Pessoa Designação do tipo de pessoa participante no sistema.

Aluno; Professor; Estagiário

Tipo_Objecto Objectos_Avaliacao; Tipo_Objecto

Título do tipo de avaliação a realizar

Relatório; Ãvaliação contínua

Tipo_Pessoa Pessoas; Tipos_Pessoa Código do tipo de pessoa

Titulo Objectos_Avaliacao Designação abreviada de cada objecto de avaliação

Exame

Turma_ID Aulas; Turmas_disciplina; Turma_Dias_Semana; Resultado_Avaliacao; Grupos; Grupo_Elementos; Turmas

Identificação de código da turma 1, 3

Web_Page Pessoas URL do sítio na Net do actor http://www.fe.up.pt/~zedosanzois


34

projecto sileq - web.fe.up.ptmgi00012/docs/mgi_bd.pdf · proposta de projecto sileq 2 sumário...

Documents