relatorio final_es ii

Relatório Final do Projecto de Engenharia de Software II-Modelação da Escola de Condução A BENIGNA

Índice 1-Introdução.....................................................................................................................2

1.1-Visão geral..............................................................................................................31.2-Cliente.....................................................................................................................31.3-Objectivo.................................................................................................................3

2-Modelação do negócio(Business Modelling)..............................................................32.1-Caso de Uso Negócio (Business Use Case)............................................................32.2-Os Business Use Cases........................................................................................3-42.3-Diagrama de Business Use Case.............................................................................42.3.1-Descrição dos Business Use Cases...................................................................4-52.4-Actores de Negócio (Business Actors)...................................................................5

2.5-Trabalhadores de Negócio (Business Workers)…….………………..…………...6 2.6-Entidades de Negócio (Business Entity)….….…………………………………...6 2.7- Diagrama de Actividades ……….…………………..…………………………...6 2.7.1-Diagrama de Actividades do Business Use Case Inscrição ….………………...7 2.7.2-Diagrama de Actividades do Business Use Case Solicitar Exame ….….……...7 2.7.3-Diagrama de Actividades do Business Use Case Marcar Data Exame ..……...8 2.8-Diagrama de Sequência………………….…………………………. …….……...8 2.8.1-Diagrama de Sequência do Business Use Case Inscrição…….….. …….……...9 2.8.2-Diagrama de Sequência do Business Use Case Solicitar Exame ….….…...….10 2.8.3- Diagrama de Sequência do Business Use Case Marcar Data Exame ….…….103-Análise.........................................................................................................................11

3.1-Diagrama do caso de uso expandido................................................................12 3.2-Requisitos e funções do sistema.......................................................................12 3.3-Requisitos não funcionais para Inscrição (Atributos do sistema).................12

3.4-Caso de uso Expandido......................................................................................12 3.5-Fluxo de Operações............................................................................................13 3.6-Contrato de Operações (Inscrição)...................................................................13 3.7-Típica Sequência de Eventos.............................................................................14 3.8-Glossário de Termos do Sistema......................................................................14 3.9-Modelo Conceptual............................................................................................15 3.9.1- Diagrama de Sequência do Caso de Uso Inscrição Expandido.........................15 3.9.2- Diagrama de Colaboração do Caso de Uso Inscrição Expandido ……..164-Projecto e implementação..........................................................................................16

4.1-Caso de uso real....................................................................................................164.2-Diagrama de Classes..........................................................................................17

4.3-Geração do Código Java através do Diagrama de Classes.......................17-20 4.4-Esquema da Base de Dados...............................................................................21 4.5-Script da criação da Base de Dados.................................................................21-23 4.6-Desenho…………………………………………………………………….........24 4.6.1-Formulário de inscrição criado no DreamWeaver………………………….....245-Conclusão....................................................................................................................256-Bibliografia.................................................................................................................26

GRUPO VII-ESCOLA DE CONDUÇÃO “A BENIGNA”-2009 1


1-Introdução

O estudo difundido das tecnologias do ramo da engenharia tem levado a um aprofundar do estudo e da investigação por parte de vários órgãos de interesse na área, e não fosse a informática uma das áreas nucleares da engenharia moderna, não estaríamos aqui a dissertar sobre o assunto.

Vamos ao longo deste relatório, tocar na área de engenharia de software, que acima de tudo dá uma visão bem mais criteriosa de como se deve conceber um software de aplicação, para qualquer área, inclusive as que não são do ramo da engenharia. Desenvolver um software não é uma tarefa trivial, precisa-se de métodos de análise criteriosos com vista a atingir de forma plena o objectivo.

Como foi desenvolvido no âmbito académico, vamos ilustrar como se pode utilizar UML como ferramenta de análise para desenvolvimento de aplicações ou, para análise de um problema de software. Particularmente, apresentamos um problema específico, isto é, a modelação da Escola de Condução “A Benigna”. Não obstante se tratar do âmbito académico, o sistema foi criteriosamente modelado.

Outrossim, a modelação foi realizada em RUP (Rational Unified Process) que é um processo de engenharia de software criado a principio pela Rational Software Corporation, portanto é um método de desenvolvimento de software proprietário, que dita técnicas a serem obedecidas por cada membro de uma equipe de desenvolvimento vislumbrando o aumento da produtividade. (Kruchten, 2001).

O RUP é fundamentado sobre a abordagem de Orientação a Objectos – OO e documentado usando Unified Modeling Language – UML.



1.1-Visão geral

O projecto apresentado tem o propósito de criar um sistema que permite a inscrição de um indivíduo na Escola de Condução “A BENIGNA”.

1.2-Cliente

Escola de Condução “A Benigna”, uma Entidade Privada.

1.3-Objectivos

O objectivo principal é diminuir o fluxo de alunos no guichet (recepção) no acto de inscrição; Mais especificamente:

Permitir o controle automático dos alunos inscritos, bem como as vagas existentes na escola;

Controlar as datas dos exames dos alunos inscritos que terminaram as aulas e solicitaram exame.

Atender alunos mais rapidamente.

2-Modelação do Negócio (Business Modelling)

Na primeira fase do projecto é descrito de forma detalhada o negócio, viabilizando a identificação dos casos de usos de negócio (Business Use Cases) para a modelação do software, identificação dos agentes externos ao sistema (Business Actors), sua interacção com sistema, agentes internos ao sistema (Business Workers) e os papeis que têm dentro do sistema.

A modelação significa o estudo de uma organização, ou seja, é o estudo prévio de como os papeis se interrelacionam, o fluxo de trabalho, o estudo dos principais processos – funcionamento, importância, entraves ao funcionamento, as entidades externas que interagem com o negócio e as suas implicações.

2.1-Caso de Uso Negócio (Business Use Case)

Caso de uso de negócio é um grupo relacionado de fluxo de trabalho que fornece valores aos actores de negócio (Business Actors). Descreve ainda o que a organização faz, no acto de inscrição do indivíduo (aluno).

2.2.1-Os Business Use Cases

Os Business Use Case para o nosso negócio são:



Inscrição: neste Business Use Case uso o aluno averigua as vagas, se houver solicita o formulário ao funcionário da escola, preenche-o, faz o pagamento e tem acesso as aulas (Código e condução).

Solicitar Exame: neste caso de uso, o aluno depois de terminar as aulas solicita o exame onde é avaliado o conhecimento do código e condução.

Marcar Data Exame: neste caso de uso a escola solicita data para a realização do exame do aluno e a seguir efectua-se a realização do referido exame.

2.3-Diagrama de Business Use Case

Figura 1-Diagrama de Business Use Case

2.3.1-Descrição dos Business Use Cases

Business Use Case: Inscrição

Objectivo: Fazer a inscrição do aluno para aulas de código e condução Business Actor envolvido: Aluno Business Worker: Funcionário Cenário Principal:

1. O aluno verifica a existência de vagas2. Se houver vagas solicita formulário de inscrição3. O aluno Recebe formulário de inscrição4. Preenche formulário 5. Entrega formulário e os documentos6. O funcionário recebe os documentos e o formulário



7. O funcionário verifica os documentos e o formulário8. O aluno efectua o pagamento da respectiva taxa de inscrição 9. O funcionário recebe o pagamento10. O funcionário passa recibo11. O aluno recebe o recibo de pagamento12. O funcionário valida inscrição

Pós-condição: gravar os dados e armazenar numa base de dados persistente.

Cenário alternativo:1. Se não houver vagas:

a. O funcionário diz que não e possível fazer inscrição.

Business Use case: Solicitar Exame

Objectivo: Solicitação de formulário para o exame Business Actor envolvido: Aluno Business Worker: Funcionário Cenário Principal:

1. Include Inscrição (Business use case deve ter sido executada)2. Aluno solicita formulário3. Funcionário apresenta formulário modelo de condução4. Aluno preenche formulário modelo5. Aluno entrega os documentos e formulário6. Funcionário verifica integridade do formulário e documentos7. Aluno efectua o pagamento8. Funcionário recebe o pagamento9. Funcionário entrega o recibo de pagamento10. Funcionário valida a solicitação de exame

Business Use case: Marcar Data Exame

Objectivo: Marcar data para realização do exame do aluno Business Actor envolvido: Viação Transito Business Worker: Funcionário Cenário Principal:

1. Funcionário da escola solicita data para o exame do aluno2. Viação e Transito verifica se há data disponível para exame3. Se houver:

a. Funcionário entrega os documentos do aluno4. Viação e Transito verifica a integridade dos documentos5. Viação e Transito marca e informa a data do exame6. Aluno comparece no exame7. Aluno realiza o exame8. Se aprovado:

a. Recebe cartas9. Se reprovado

b. Requerer e comparecer novamente no exame

2.4-Actores de Negócio (Business Actors)



O Business Actor é um elemento externo à escola de condução que interage com o funcionário. No caso particular do nosso negócio, o actor principal é o Aluno (indivíduo singular ou colectivo) e a Viação e Transito.

2.5-Trabalhadores de Negócio (Business Workers)

Business Worker é um agente interno ao sistema, que possui papeis dentro da organização. Modelamos os Business workers para compreender os papéis dentro da organização e como eles interagem entre si.

O Business Worker do sistema é: Funcionário

2.6-Entidades de Negócio (Business Entity)

Business Entities são os objectos usados pela organização para conduzir o negócio ou produzidos durante o curso do negócio. Os business entities encontrados são: Solicita Vagas, Verifica Formulário, Solicita Formulário, Caixa, Valida Inscrição, Exame, Resultado, Solicita Exame, Valida Solicitação Exame, Entrega Documentos.

2.7-Diagrama de Actividades

O diagrama de actividade representa uma sequência de actividades. Algumas das actividades podem ser concorrentes.

Uma actividade é interpretada como a tomada de uma acção e, por vezes, o referente estado. O diagrama permite representar condições para a tomada de decisões e permite representar comportamento paralelo de actividades.



2.7.1-Diagrama de Actividades do Business Use Case Inscrição

Figura 2- Diagrama de Actividades do Business Use Case Inscrição

2.7.2-Diagrama de Actividades do Business Use Case Solicitar Exame



Figura 3-Diagrama de Actividades do Business Use Case Solicitar Exame

2.7.3-Diagrama de Actividades do Business Use Case Marcar Data Exame

Figura 4-Diagrama de Actividades do Business Use Case Marcar Data Exame

2.8-Diagrama de Sequência

Um diagrama de sequência contém actividades, estados, eventos, transição entre actividades e anotações.

Um diagrama de sequência está associado à funcionalidade de um caso de uso. Este diagrama apresenta a funcionalidade de um caso de uso através de uma

sequência de eventos.



Este diagrama representa um cenário em que é ilustrado um conjunto de interacções entre objectos num determinado período de tempo.

2.8.1-Diagrama de Sequência do Business Use Case Inscrição

Figura 5- Diagrama de Sequência do Business Use Case Inscrição



2.8.2-Diagrama de Sequência do Business Use Case Solicitar Exame

Figura 6- Diagrama de Sequência do Business Use Case Solicitar Exame

2.8.2. Diagrama de Sequência do Business Use Case Marcar Data Exame



Figura 7- Diagrama de Sequência do Business Use Case Marcar Data Exame

3-Análise

Nesta fase vamos proceder da seguinte maneira: Definir os requisitos do sistema e as funções básicas; Escolher um caso de uso geral ou de alto nível, sobre o qual se vai trabalhar; a

seguir esse caso de uso transformar-se-á num caso de uso expandido, isto é, conterá uma especificação exaustiva do referido processo;

Fazer o diagrama de sequência e de colaboração do caso de uso escolhido; Fazer o modelo conceptual Transformar o caso de uso escolhido num caso de uso real Fazer do diagrama de classe que representa o projecto; Gerar o código da respectiva classe Definir os contratos de operação

3.1-Diagrama do caso de uso expandido

Figura 8- Diagrama do caso de uso expandido



3.2-Requisitos e funções do sistema

Os requisitos do sistema estão intrinsecamente ligadas as condições que devem se observadas para a efectivação do caso de uso inscrição

Caso de Uso Inscrição

Ref. # Função CategoriaR1.1 Registar (inscrever) alunos com idade igual ou superior a 18

anos e de qualquer sexoEvidente

R1.2 Registar alunos com idade igual ou superior a 21 anos para veículos pesados

Evidente

R1.3 Capturar informação dos alunos que cumprirem os requisitos via digitação manual

Evidente

R1.4 Atendimento célere e redução do número de alunos no balcão da escola

Evidente

R1.5 Processar pagamento com dinheiro, capturando quantia oferecida e calculando troco devido

Evidente

R1.6 Oferecer mecanismos para comunicação entre-processos e entre-sistemas

Escondida

R1.7 Mostrar descrição e preço de cada uma das categorias de condutor

Evidente

R1.8 Oferecer um mecanismo de armazenamento persistente Escondida

3.3-Requisitos não funcionais para Inscrição (Atributos do sistema)

Atributo Detalhes e Restrições de ContornoTempo de resposta Durante o registo de um aluno, depois de seleccionada a categoria do

condutor, preço da inscrição aparecerá em até 5 segundosDistribuição geográfica (detalhe) Sistema distribuído por todo pais



Metáfora de interface (detalhe) Janelas baseadas em forms e navegação via mouse e browser

Tolerância a falhasDeve registrar pagamento de inscrição com cartão de crédito autorizados junto ao sistema de contas a receber dentro de 24 horas, mesmo se houver falha de energia ou nos equipamentos

Plataformas de S.O. (detalhe) Microsoft Windows e Linux

3.4-Caso de uso Expandido

Caso de Uso: InscriçãoActor: AlunoProposito: Inscrição de alunos na escola de conduçãoDescricao: Um Aluno chega no balcão da escola, averigua a existência de vagas e solicita formulário de inscrição. No final sai com a inscrição feita e validada.Referencia: Funções: R1.1, R1.2, R1.3, R1.4, R1.5, R1.6, R1.7, R1.8

3.5-Fluxo de Operações

Fluxo Principal:1. O Aluno chega ao balcão com os documentos pessoais que deseja entregar e solicita

vaga;2. O Aluno pede informações sobre como proceder para inscrição;3. O Funcionário explica-o e faz a entrega do formulário para respectivo

preenchimento;4. O Aluno preenche e entrega ao funcionário;5. O Funcionário averigua os documentos e o formulário preenchido;6. O Aluno faz o respectivo pagamento referente à sua inscrição;7. O Funcionário recebe o valor e regista o nome do aluno; 8. O Funcionário termina o processo, entregando um comprovativo de sua inscrição e

lhe informa a data em que irá começar as aulas;9. O Aluno recebe o comprovativo da inscrição e o de pagamento;10. O Aluno vai embora.

Tratamento de Excepções: 1ª – (a). Quando não houver vaga:

1. Retorna ao Fluxo Principal no passo 10.

4ª - (a). Quando o factor idade não corresponde aos requisitos da Escola de Condução:

1. O Aluno deve aguardar até completar a idade requisitada;2. Retorna ao Fluxo Principal no passo 4.

5ª – (a). O Aluno possui pendência (o formulário foi mal preenchido ou falta algum tipo de documento pessoal):

1. O Aluno é obrigado a refazê-lo;2. Retorna ao Fluxo Principal no passo 3.



3.6-Contrato de Operações (Inscrição)

Escolheu-se como caso de uso a ser implementado, o caso de uso Inscrição. Assim o contrato de operações para este caso de uso é:

Actor: AlunoPropósito: Inscrição de alunos na Escola de Condução.Descrição: O Aluno chega ao balcão (guichet) da escola, averigua vagas e solicita o formulário de inscrição, preenche formulário, o funcionário verifica se os dados estão correctos, valida a inscrição e dá acesso aos alunos a sala aula.Tipo: Primário e essencial.

3.7-Típica Sequência de Eventos

Acção do Actor Resposta do sistema1. Este caso de uso começa quando o aluno chega ao balcão (guiché) da Escola de Condução, averigua a existência de vaga e solicita formulário para inscrição2. O funcionário verifica os dados3. O funcionário regista (valida) a inscrição

4. Regista a solicitação num SGBD

5. O aluno efectua pagamento 6. O funcionário emite um recibo

7. O aluno recebe o recibo que lhe dá acesso as aulas8. Depois das aulas feitas, solicita formulário para marcação de exame e espera a data do exame.

9. Regista solicitação de exame

Sequência alternativa

Se não houver vaga ou os, ou os dados forem inválidos e não cumprirem os requisitos então cancelar a operação.

3.8-Glossário de Termos do Sistema

Aluno: é um indivíduo colectivo ou singular que solicita o formulário de inscrição à escola de condução.



Funcionário: é uma entidade (pessoa) que recebe o formulário preenchido pelo aluno e verifica se o mesmo está conforme. Também é responsável pela recepção do pagamento.

Inscrição: é o processo que permite que o aluno se inscreva na escola de condução, caso haja vaga disponível.

3.9-Modelo Conceptual

Figura 9-Modelo Conceptual de domínios

3.9.1-Diagrama de Sequência do Caso de Uso Inscrição Expandido



Figura 10-Diagrama de Sequência do Caso de Uso Inscrição Expandido

3.9.2-Diagrama de Colaboração do Caso de Uso Inscrição Expandido

Figura 11-Diagrama de Colaboração do Caso de Uso Inscrição Expandido

4. Projecto e Implementação



4.1-Caso de Uso Real

Figura 12-Diagrama do caso de uso real

4.2-Diagrama de Classes

Figura 12-Diagrama de classes



4.3-Geração do Código Java através do Diagrama de Classes

//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\src\\Aluno.java

import java.util.Calendar;

public class Aluno { private String nome; private String endereco; private String telefone; private String bi; private char sexo; private Calendar dataNascimento; private String nomePai; private String nomeMae; private String nacionalidade; private String habilitacoes; /** * @roseuid 4A425F110057 */ public Aluno() { } /** * @roseuid 4A425F18021C */ public void verExames() { }}

//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\src\\Aula.java


public class Aula { private Calendar dataHora; private bool codigo; private String nomeInstrutor; private String[] nomeAlunosPresentes; /** * @roseuid 4A42617602D7 */ public Aula() { }



/** * @roseuid 4A42617C0326 */ public void Criar() { }}

//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\src\\Exame.java


public class Exame { private String enderecoVT; private bool apto; private String nomeExaminando; private Calendar dataCodigo; private Calendar dataConducao; /** * @roseuid 4A42609B0306 */ public Exame() { } /** * @roseuid 4A42607C0345 */ public void ver() { } /** * @roseuid 4A4260890354 */ public void marcar() { }}

//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\src\\Funcionario.java

public class Funcionario { private String nome; private String morada; /** * @roseuid 4A426208020C



*/ public Funcionario() { } /** * @roseuid 4A42620D025A */ public void verAulas() { } /** * @roseuid 4A42621A00F3 */ public void verAlunos() { }}

//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\src\\Inscricao.java


public class Inscricao { private String nomeFuncionario; private String nomeAluno; private Calendar data; /** * @roseuid 4A4262AA0345 */ public Inscricao() { } /** * @roseuid 4A42629800C4 */ public void ver() { } /** * @roseuid 4A4262A00383 */ public void criar() { }}



//Source file: C:\\Documents and Settings\\Paulo Menezes\\Os meus documentos\\Engenharia de Software 2\\Escola_Conducao_Benigna\\Código Gerado\\src\\Instrutor.java

public class Instrutor { private String nome; private char sexo; /** * @roseuid 4A42684602E7 */ public Instrutor() { }}

4.4-Esquema da Base de Dados



Figura 13-Esquema da Base de Dados

4.5-Script de criação da Base de Dados

CREATE TABLE Tb_Resultado (codResultado SMALLINT NOT NULL,apto BIT NOT NULL,CONSTRAINT PK_Tb_Resultado13 PRIMARY KEY NONCLUSTERED

(codResultado))

GO

CREATE TABLE Tb_Inscricao (codInscricao SMALLINT NOT NULL,dataInscricao INT NOT NULL,codFuncionario SMALLINT NOT NULL,codAluno SMALLINT NOT NULL,CONSTRAINT PK_Tb_Inscricao8 PRIMARY KEY NONCLUSTERED

(codInscricao))

GO

CREATE TABLE Tb_Funcionario (codFuncionario SMALLINT NOT NULL,nome VARCHAR ( 50 ) NOT NULL,morada VARCHAR ( 30 ) NOT NULL,categoria VARCHAR ( 30 ) NOT NULL,CONSTRAINT PK_Tb_Funcionario7 PRIMARY KEY NONCLUSTERED

(codFuncionario))

GO



CREATE TABLE Tb_Aulas (codAulas SMALLINT NOT NULL,codigo_Tipo_Aula BIT NOT NULL,horarioAulas DATETIME NOT NULL,codViatura SMALLINT NOT NULL,codInstrutor SMALLINT NOT NULL,codAluno SMALLINT NOT NULL,CONSTRAINT PK_Tb_Aulas9 PRIMARY KEY NONCLUSTERED (codAulas))

GO

CREATE TABLE Tb_Exame (codExame SMALLINT NOT NULL,dataExameCodigo DATETIME NOT NULL,dataExameConducao DATETIME NOT NULL,codResultado SMALLINT NOT NULL,codAluno SMALLINT NOT NULL,CONSTRAINT PK_Tb_Exame12 PRIMARY KEY NONCLUSTERED (codExame))

GO

CREATE TABLE Tb_Instrutor (codInstrutor SMALLINT NOT NULL,nome VARCHAR ( 30 ) NOT NULL,tipoInstrutor VARCHAR ( 20 ) NOT NULL,sexo BIT NOT NULL,CONSTRAINT PK_Tb_Instrutor10 PRIMARY KEY NONCLUSTERED

(codInstrutor))

GO

CREATE TABLE Tb_ViacaoTransito (codViacaoTransito SMALLINT NOT NULL,endereco VARCHAR ( 30 ) NOT NULL,codExame SMALLINT NOT NULL,CONSTRAINT PK_Tb_ViacaoTransito17 PRIMARY KEY NONCLUSTERED

(codViacaoTransito))

GO

CREATE TABLE Tb_Provincia (codProvincia SMALLINT NOT NULL,nomeProvincia VARCHAR ( 30 ) NOT NULL,codMunicipio SMALLINT NOT NULL,CONSTRAINT PK_Tb_Provincia15 PRIMARY KEY NONCLUSTERED

(codProvincia))

GO

CREATE TABLE Tb_Municipio (codMunicipio SMALLINT NOT NULL,nomeMunicipio VARCHAR ( 30 ) NOT NULL,CONSTRAINT PK_Tb_Municipio16 PRIMARY KEY NONCLUSTERED

(codMunicipio))

GO

CREATE TABLE Tb_Viatura (codViatura SMALLINT NOT NULL,marca VARCHAR ( 30 ) NOT NULL,modelo VARCHAR ( 20 ) NOT NULL,



cor VARCHAR ( 20 ) NOT NULL,chapaMatricula VARCHAR ( 20 ) NOT NULL,CONSTRAINT PK_Tb_Viatura14 PRIMARY KEY NONCLUSTERED (codViatura))

GO

CREATE TABLE Tb_Aluno (codAluno SMALLINT NOT NULL,nome VARCHAR ( 40 ) NOT NULL,pai VARCHAR ( 40 ) NOT NULL,mae VARCHAR ( 40 ) NOT NULL,endereco VARCHAR ( 40 ) NOT NULL,telefone INT NOT NULL,numeroBi VARCHAR ( 20 ) NOT NULL,dataEmissao DATETIME NOT NULL,arquivoIdentificacao VARCHAR ( 25 ) NOT NULL,dataNascimento DATETIME NOT NULL,habilitacoesLiterarias SMALLINT NOT NULL,nacionalidade VARCHAR ( 1 ) NOT NULL,sexo BIT NOT NULL,codProvincia SMALLINT NOT NULL,CONSTRAINT PK_Tb_Aluno11 PRIMARY KEY NONCLUSTERED (codAluno))

GO

ALTER TABLE Tb_Provincia ADD CONSTRAINT FK_Tb_Provincia0 FOREIGN KEY (codMunicipio) REFERENCES Tb_Municipio (codMunicipio) GOALTER TABLE Tb_ViacaoTransito ADD CONSTRAINT FK_Tb_ViacaoTransito9 FOREIGN KEY (codExame) REFERENCES Tb_Exame (codExame) GOALTER TABLE Tb_Aulas ADD CONSTRAINT FK_Tb_Aulas2 FOREIGN KEY (codInstrutor) REFERENCES Tb_Instrutor (codInstrutor) GOALTER TABLE Tb_Aulas ADD CONSTRAINT FK_Tb_Aulas1 FOREIGN KEY (codViatura) REFERENCES Tb_Viatura (codViatura) GOALTER TABLE Tb_Aulas ADD CONSTRAINT FK_Tb_Aulas10 FOREIGN KEY (codAluno) REFERENCES Tb_Aluno (codAluno) GOALTER TABLE Tb_Exame ADD CONSTRAINT FK_Tb_Exame11 FOREIGN KEY (codAluno) REFERENCES Tb_Aluno (codAluno) GOALTER TABLE Tb_Exame ADD CONSTRAINT FK_Tb_Exame3 FOREIGN KEY (codResultado) REFERENCES Tb_Resultado (codResultado) GOALTER TABLE Tb_Inscricao ADD CONSTRAINT FK_Tb_Inscricao8 FOREIGN KEY (codAluno) REFERENCES Tb_Aluno (codAluno) GOALTER TABLE Tb_Inscricao ADD CONSTRAINT FK_Tb_Inscricao7 FOREIGN KEY (codFuncionario) REFERENCES Tb_Funcionario (codFuncionario) GOALTER TABLE Tb_Aluno ADD CONSTRAINT FK_Tb_Aluno5 FOREIGN KEY (codProvincia) REFERENCES Tb_Provincia (codProvincia) GO

4.6-Desenho



Nesta etapa criamos formulário JSP (Java server Pages) com o Dream Weaver, que permitirá o armazenamento persistente da informação na base de dados.

4.6.1-Formulário de Inscrição criado no Dreamveaver

Figura 14-Formulário para inscrição de alunos



5. Conclusão

A grande importância para a integridade do modelo é que, tanto as mensagens como os eventos encontrem nas classes a operação que as implementa. Para um uso eficaz da UML é necessário se aprofundar no conhecimento dos diagramas e do que cada elemento representa.

Com esta modelagem de negócio a Escola de Condução “A Benigna” controla melhor os registos dos seus alunos, bem como os seus processos, o tempo de aulas do aluno, quais os alunos a espera do exame, e as vagas existentes dentro da escola, bem como os alunos que solicitaram novamente o exame.

Este projecto permitiu-nos aprender como é feita uma modelagem de negócio e máxime ter um contacto mais profundo com o Rational Rose, explorando o RUP.



6. Bibliografia

GILG, Tom. Principles of Software Engineering Management. Addison-Wesley, 1988.

KROLL, Per. The Spirit of the RUP. The Rational Edge, IBM. New York, McGraw-Hill, 2001.

KRUTCHEN, Phillipe. What Is The Rational Unified Process. The Rational Edge. New Yok, IBM, 2000.

FURLAN, José Davi. Modelagem de Objectos Através da UML. São Paulo, Makron Books,1998.
