Uma metodologia para o desenvolvimento de aplicações de bases de dados

1. Uma metodologia para o desenvolvimento de aplicaçõesde bases de dados Modelos de Bases de Dados Juliana Planck VazTécnico em Informática – 1º Módulo Etec Professor Fausto Mazzola2013

2. Dados vs. Bases de Dados • Dados: elementos ou valores discretos, que isoladamente, não têm qualquer valor. • Base de Dados: um conjunto organizado de dados. • Base de Dados Relacionais: • Todos os dados são conceitualmente representados em tabelas: uma estrutura de linhas e colunas, definida como relação. • Todos os valores dos dados são escalares. Qualquer posição linha/coluna de uma relação existe somente um valor. • Todas as operações são realizadas de relação para relação. O que possibilita que o resultado de uma operação possa ser utilizado como entrada de outra operação.

3. Aplicações de bases de dados • As aplicações de bases de dados modelam um problema da vida real definido em um determinado domínio e incluem os seguintes componentes: • Modelo de dados • Estrutura da base de dados • Base de Dados (BD) • Administradores de dados (Sistemas de Gestão de Bases de Dados, SGBD) • Interfaces: um conjunto de formas e reportes com as quais o utilizador do sistema interage.

4. Bases de Dados: Componentes utilizador Domínio do problema no mundo real Aplicação de base de dados: um conjunto de formulários e relatórios Modelo de dados: representação conceitual do domínio do problema Domínio Administradores de dados:manipulam o aceso às bases de dados Estrutura da base de dados: descreve o modelo de dados Base de Dados:a implementação física da estrutura e os dados

5. Etapa 1: Definição da aplicação Definir o problema e o seu domínio Definir as especificações funcionaisdefinir o diagrama de use-cases Definir a plataforma tecnológica para desenvolvimento e para a implementação da aplicação.

6. Etapa 2: Modelação da aplicação 1º. Modelação dos dados persistentes 2º. Modelação da aplicação. Modelar os objetos que administram os dados Definir o Modelo de Dados:definir o diagrama de classes Modelar os objetos que processam os dados Definir a Estrutura: definir as tabelas e as suas relações. Modelar as interfaces implementação Aplicação de base de dados Base de Dados

7. Etapa 1: Definição da Aplicação. • 1. Definir o domínio e o problema: • Qual o problema a resolver pela aplicação? • Quais são os benefícios? • A aplicação é tecnicamente possível? • 2. Definir os requerimentos funcionais: • O que faz a aplicação desde o ponto de vista do utilizador? • Quais são as funções dos utilizadores e os diferentes cenários? Construir diagrama de casos de utilização. (Use-Case) • 3. Definir os requerimentos técnicos: • Escolha da tecnologia para desenvolvimento e implementação.

8. Exemplo: Um jornal on-line de Classificados • O jornal Aveiro-0n-Line pretende automatizar o processo de criação e fatura dos seus classificados: • Os clientes devem introduzir os classificados através de um site na Internet. O sistema automaticamente emite uma fatura. O cliente pode pagar imediatamente (via cartão de crédito) ou pode enviar um cheque ao departamento de Classificados do jornal. • Nos departamentos de Classificados e de Contabilidade será implementada uma aplicação para a edição e faturação dos classificados.

9. Cenário atual da introdução de um novo classificado. • O cliente preenche um formulário, calcula o custo do anúncio por palavras e o envia junto a um cheque ao departamento de Classificados do jornal. • O departamento de Classificados adiciona o classificado na base de dados. • Uma copia do texto do anúncio e o cheque é enviada ao departamento de Contabilidade. • O departamento de Contabilidade processa os dados sobre o classificado e o cliente. Obviamente a automatização deste processo possibilitará uma redução significativa no tempo de introdução, processamento e fatura dos classificados.

10. Exemplo: Definição da aplicação (1) • Definição do domínio e problema • Domínio da aplicação: • Um jornal de classificados com 2 departamentos: • Departamento de Classificados. • Departamento de Contabilidade. • O problema: • Automatizar o processo de introdução, processamento e faturação dos classificados.

11. 1.2. Requerimentos funcionais. • 1.2. Definir os requerimentos funcionais:O que tem de fazer a aplicação desde a perspectiva do utilizador? • Vamos utilizar diagramas de Caso de Utilização de UML para modelar os requerimentos funcionais da aplicação . • Através da definição dos casos de utilização, os atores internos que tem interesse no sistema são modelados de acordo com a funcionalidade que eles requerem do sistema. • Os atorese os casos de utilização são ambos descritos no diagrama de casos de utilização. (Use-Case) • Para cada caso de utilização é fornecida a sua descrição (um texto de um ou dois parágrafos).

12. Diagrama de Casos de Utilização (Use-Case). • O diagrama de use-case é utilizado para identificar o comportamento do sistema perante as várias situações que podem ocorrer durante a sua execução. • O diagrama de use-case está composto por: • atores: perfil ou papel que o utilizador desempenha perante o sistema. • use-case: uma descrição (sequência de ações) de uma funcionalidade (utilização específica) do sistema. • Notas: • Os atores realizam use-case. • Um atorpode desempenhar vários use-cases. • Um use-case pode ser desempenhado por mais de um ator.

13. Diagrama de Casos de Utilização (Use-Case). Use-Case 1 Use-Case 2 Use-Case 3 Ator Use-Case N

14. Exemplo: Requerimentos funcionais (1) 1.2.Definir os requerimentos funcionais: • Definir os atores do sistema: • Leitor • Cliente • Funcionário do Jornal • Funcionário do departamento de Classificados • Funcionário do departamento de Contabilidade

15. Exemplo: Requerimentos funcionais (2) 1.2. Definir os requerimentos funcionais: • Definir os casos de utilização: • Leitor: • Ler os classificados no Jornal on-line • Cliente: • Registar-se no sistema • Entrar no sistema (Log In) • Adicionar um classificado • Cancelar um classificado • Criar a sua conta • Funcionário do Jornal • Ver estado das contas dos clientes • Ver classificados

16. Exemplo: Requerimentos funcionais (3) 1.2. Definir os requerimentos funcionais : Definir os casos de utilização: (continuação) • Funcionário do Departamento de Classificados • Adicionar um classificado • Editar um classificado • Cancelar um classificado • Manutenção classificados • Funcionário do Departamento de Contabilidade • Adicionar um cliente • Editar um cliente • Apagar um cliente • Registar pagamento de um classificado • Manutenção contas clientes

17. Aveiro On-Line: Actores Leitor Cliente Funcionário Funcionário do Departamento de Classificados Funcionário do Departamento de Contabilidade Aplicação Aveiro-On-Line

18. Aveiro On-Line: Diagrama Use-Case (1) Leitor Cliente Ler os classificados Registar-se Entrar no sistema (Log In) Adicionar um classificado Cancelar um classificado próprio Criar a sua conta

19. Aveiro On-Line: Diagrama Use-Case (2) Adicionar um classificado Editar um classificado Funcionário do Departamento de Classificados Apagar um classificado Manutenção classificados Ver classificados Funcionário

20. Aveiro On-Line: Diagrama Use-Case (3) Adicionar um cliente Editar um cliente Funcionário do Departamento de Contabilidade Apagar um cliente Manutenção das contas dos clientes Registar pagamentos Ver estado das contas dos clientes Funcionário

21. Cenários de um use-case. • Um use-case deve ser descrito através de vários cenários. • Cenário é uma instância de um use -case. • Existem dois tipos de cenários: • cenário primário: são os cenários com uma sequência normal de ações. • cenário secundário: são os cenários onde a sequência normal de ações é interrompida.

22. Cenários de um use-case. • Use-Case:Adicionar classificado. • Cenário primário: Para um cliente já registrado. • Um cliente entra no sistema, fornecendo a sua senha de aceso. • O sistema valida a senha, permitindo a entrada ao sistema. • O cliente seleciona a opção adicionar classificado. • O sistema envia um formulário onde o cliente deverá introduzir o título e o texto do classificado. • O cliente também pode modificar os dados da sua conta como nome, telefone, etc. • O cliente tem de especificar o período no qual o classificado será publicitado (uma data de início e uma data final). • O cliente deverá especificar a categoria do classificado.

23. Cenários de um use-case. • Use-Case:Adicionar classificado. • Cenário primário: para um cliente já registrado • Uma vez completado o formulário, o cliente pode selecionar a opção Visualizar para comprovar que todos os dados estão corretos, incluindo além do classificado a informação sobre o seu custo e como e onde será enviada a fatura. • Se o cliente concorda com os dados expostos, então envia o classificado ao sistema. • O sistema automaticamente gera um ID para armazenar o classificado. • Se o cliente alterou a informação da sua conta pessoal estes dados são modificados no seu correspondente registro. • Uma fatura é gerada automaticamente. • O sistema envia ao cliente a confirmação que o classificado foi adicionada com êxito. • Cenário secundário: para um novo cliente • O cliente tem de registrar-se no sistema. • Para depois adicionar classificados.

24. Diagrama de sequência Log Formulário Gestor de Classificados Formulário Classificado Classificado Gestor de Faturas Fatura :Adicionar um classificado 1: LoginInfo 2: submit 3: Selecionar“AdicionarClassificado” 4: Enviar formulário 5: Entrar informação 6: Visualizar Classificado 7: Visualizar 8: Enviar 9: Adicionar Classificado 10: Novo classificado 11: Adicionarfatura 12: Nova Fatura 13: Criar novo ID 13: Display classificado ID, confirmação Os cenários são documentados utilizando diagramas de sequência. Os objetos são representados por linhas verticais e as mensagens entre os objetos são representados por linhas horizontais.

25. 1.3. Requerimentos Técnicos (1) 1.3. Definir os requerimentos técnicos: escolher as ferramentas e plataforma para desenvolvimento e implementação da aplicação • para definição de bases de dados (data definition environments): • Microsoft Access • Visual Database Tools • Microsoft Query • SQL Enterprise Manager • para desenvolvimento de aplicações (Front-End development): • Microsoft Access • Visual Basic • HTML • ASP

26. 1.3. Requerimentos Técnicos (2) • para aceso aos dados (data access object mode) • ADO (ActiveX Data Objects) • DAO/Jet • OLEDB • RDO (Remote Data Objects) • Bases de dados (database engines) • Microsoft Jet (Microsoft Access) • SQL Server • Oracle

27. DNA- Distributed Internet Applications Aplicações em 3 camadas (3-tier): interfaces (presentation layer) – Windows ou Internet Servidor para Internet: IIS componentes (bussiness layer) – Servidor para componentes: MTS (Microsoft Transactions Server) servidor de bases de dados (data access layer) –SQL Servidor A Plataforma Windows DNA

28. Aveiro On-Line: Requerimentos Técnicos • Desenvolvimento da aplicação (Front-End development): • Bases de dadosMicrosoft Access vs. Microsoft SQL • Administradores de Dados: ADO, OLEDB (data services) • Componentes: COM (bussiness services) • Interfaces: • Uma interface na Internet para leitores e clientes:HTML, ASP • Uma aplicação Windows para os funcionários do jornal: Visual Basic

29. Aveiro On-Line: Requerimentos Técnicos • Implementação: (Plataforma Windows DNA): • Bases de dados: SQL Servidor • Servidor de aplicação: MTS • Clientes • Cliente Internet (leitores e clientes) • Cliente Windows(funcionários)