Apresenta-se uma breve descrição dos requisitos do Sistema de Informação suportado por uma Base de Dados Relacional e com interface na Web, a desenvolver na disciplina de (LSGBD) da .
Serão referidos os requisitos de informação, os requisitos funcionais, os requisitos não funcionais e as tecnologias que deverão ser usadas no desenvolvimento da aplicação.
Refere-se ainda a entrega do trabalho e as demonstrações e discussões finais.
Os requisitos de informação, identificados na fase de Análise e representados num diagrama de Entidade/Relacionamento (E/R) [Che76], estão já suportados numa Base de Dados Relacional Oracle 8i.
Os requisitos funcionais foram identificados na fase de Análise e representados em Diagramas de Hierarquia de Funções (um para cada função de negócio). As funções atómicas, que foram identificadas como ``a automatizar'', devem ser agora implementadas.
Por forma a respeitar os requisitos não funcionais enumerados, foi imposta para os projectos a escolha de tecnologias apresentada de seguida.
A aplicação deverá ser implementada segundo uma arquitectura multi-camada com a interface com o utilizador na Web, lógica de negócio numa camada intermédia e o suporte para dados persistentes na Base de Dados desenvolvida anteriormente.
A interface com o utilizador deverá ser conseguida com recurso a páginas estáticas em HTML ou a páginas em JSP com conteúdo gerado dinamicamente. Adimite-se que, nos casos em que é necessária interactividade, sejam incluídos Applets.
Os dados introduzidos em formulários deverão ser validados, no cliente, através da utilização de Javascript.
Por forma a manter um estilo consistente em toda a aplicação e para este ser facilmente alterável, deverão ser usadas folhas de estilo CSS (Cascading Style Sheets). Para isso é necessário que cada página inclua, por exemplo:
<LINK REL="stylesheet" HREF="css/till04.css" TYPE="text/css">
As páginas JSP lidam exclusivamente com a interface e delegam em Beans a realização de todas as operações, nomeadamente a ligação à Base de Dados para procura ou actualização de informação.
Toda a lógica de negócio deve ser suportada em Beans, invocados pelas páginas JSP da interface, através de <usebean ...>.
Um Bean pode usar outros Beans para realizar uma dada função (por exemplo, um Bean que centraliza a ligação à Base de Dados através de JDBC).
Informação de estado deve ser passada entre páginas JSP ou Beans através da utilização de sessões. Por exemplo, uma vez introduzido o userid, a validação do utilizador deferá ser feita com recurso à sessão. Um outro exemplo de utilização de sessões é o da lização JDBC à Base de Dados que, uma vez estabelecida, pode ser usada por um mesmo cliente para aceder à Base de Dados.
Em alternativa ou cumulativamente à utilização de Beans que lidam directamente com a Base de Dados, podem ser usadas vistas (view) do JDeveloper construídas à custa de entidades (entities) que encapsulam, por exemplo, tabelas da Base de Dados. Neste caso será a camada do JDeveloper BC4J (Bussiness Componentes For Java) a tratar da ligação JDBC. A utilização ou não do BC4J é a única escolha tecnológica possível.
A Base de Dados, onde residem os dados persistentes do SI, deverá ser acedida, directa ou indirectamente, através de uma ligação JDBC para a máquina blaster.fe.up.pt, porta 1521, SID DEV.
A entrega do Relatório deverá realizar-se, em papel, até ao dia 13/12/2001 (Quinta-feira; ou, mais precisamente, até às 9:30 do dia seguinte, quando eu abrir a caixa do correio junto à sala I225).
A entrega do trabalho desenvolvido deverá realizar-se, através da
publicação no sítio Web do projecto, até ao dia 14/12/2001
(Sexta-feira; ou, mais precisamente, até às
9:30 do dia seguinte, quando eu procurar fazer uma cópia para o meu
arquivo pessoal, para avaliação).
O trabalho desenvolvido inclui os arquivos com o código, com as
páginas HTML estáticas (por exemplo, para a ajuda online)
etc., pronto a ser instalado nas várias máquinas envolvidas (tal como
descrito no Diagrama de Distribuição do Manual de Desenvolvimento) e
acompanhado de instruções de instalação adequadas (isto é, em que
local de cada máquina envolvida ficam os arquivos com código).
As demos e discussões decorrerão na sala I120 seguindo o calendário pré-estabelecido (ver demos.html). Para demontrar o produto desenvolvido deverá ser utilizado, exclusivamente, o JDeveloper da Oracle.
A fase final do projecto de instalação da aplicação e início de exploração, que habitualmente decorre nas instalações do cliente (no nosso caso, a máquina blaster), é adiada para Janeiro e deverá ser entendida apenas como valorização do trabalho apresentado (i.e. não entrará no cálculo da nota.
Os alunos interessados deverão contactar-me para que sejam obtidas as necessárias permissões.