Normalização tem origem no estudo de base de dados relacionais de Edgar F. Codd, na década de 70.

Transcrição

1 Normalização tem origem no estudo de base de dados relacionais de Edgar F. Codd, na década de 70. É uma técnica que se aplica a qualquer estrutura de dados com o objetivo de evitar a ocorrência de duplicação de elementos de dados e, consequentemente problemas de atualização.

2 Analisando o problema do Sistema de Recepção de encomendas. Armazém ao receber uma solicitação de encomenda ( encomenda ), faz a verificação de existência de produto ( produto ). Para aceitar a encomenda, verifica-se os dados do cliente ( cliente ). Confirmado os dados do cliente e produto a encomenda é aceita, caso contrário é rejeitada. Destacamos nesse exemplo três entidades para o DER. Normalização: Primeira Forma Normal (ou 1FN) - A normalização para a primeira forma normal elimina grupos repetidos, colocando-os cada um em uma tabela separada, conectando-os com uma chave primária ou estrangeira.

3 Contém > Encomenda n n Produto n < está 1 solicita Cliente Entidades do DER: Cliente, Encomenda e Produto Cliente = nome + CPF + endereço + RG Encomenda = Número encomenda + nome cliente + endereço cliente +telefone +{nome produto + valor unitário + quantidade encomenda} + data encomenda + estado Produto = número produto + nome produto + valor unitário + quantidade encomendada

4 Instancias da estrutura Encomenda Nr Enc. Nome cliente End. fone Nome_ produto 100 Paulo R. C Calça leg Camisa pretea Cinto azul 101 Joana R. K Polo azul Polo verde 102 Rui R. A Calça leg Short bege 103 Joana R. K Short bege Algumas Instâncias da Estrutura Encomenda Valor unit Quant. Enc data MT MT GO MT estado Para a estrutura se encontrar na 1ª FN, não pode ter grupos repetitivos, cada elemento de dado, para cada ocorrência só pode assumir um único valor. Para colocar essa estrutura na 1ª FN é necessário eliminar os grupos repetitivos, criando uma nova estrutura para cada um desses grupos. É necessário selecionar um ou mais elementos de dados para chave, que permitirá identificar, de forma única, cada ocorrência e cada estrutura n 1ª FN.

5 Encomenda Produto 1 contém n Produto Encomendado 1 n < está Encomenda = Número encomenda + nome cliente + endereço cliente +telefone + data encomenda + estado Produto_Encomendado = número encomenda + nome produto + valor unitário + quantidade encomenda

6 Nr Enc. nome End. fone data estado 100 Paulo R. C MT 101 Joana R. K MT 102 Rui R. A GO 103 Joana R. K MT Instancias da estrutura Encomenda na 1ª FN Nr Enc. Nome_produto V. unit Quant. Enc. 100 Calça leg Camisa preta Cinto azul Polo azul Polo verde Calça leg Short bege Short bege Instancia da estrutura produto-encomendado na 1ª FN

7 Segunda Forma Normal (ou 2ºFN) requer que não haja dependência funcional de um atributo que não seja a chave. Para uma estrutura se encontrar na 2ª FN, tem que estar na 1ª FN e cada elemento não chave tem que depender inteiramente da chave como um todo e não somente da parte da chave (dependência funcional). Encomenda = Número encomenda + nome cliente + endereço cliente +telefone + data encomenda + estado Produto_Encomendado = número encomenda + nome produto + quantidade encomenda Detalhes_Produto = nome produto + valor unitário

8 Instâncias da estrutura Encomenda na 2ª FN Nr Enc. nome End. fone data estado 100 Paulo R. C MT 101 Joana R. K MT 102 Rui R. A GO 103 Joana R. K MT Instância da estrutura produto-encomendado na 2ª FN???? Nr Enc. Nome_produto V. unit Quant. Enc. 100 Calça leg Camisa preta Cinto azul Polo azul Polo verde Calça leg Short bege Short bege 50 10

9 Instâncias da estrutura produto _encomendado na 2ª FN Nr Enc. Nome_produto Quant. Enc. 100 Calça leg Camisa preta Cinto azul Polo azul Polo verde Calça leg Short bege Short bege 10 Nome_produto V. unit Calça leg 120 Camisa preta 60 Cinto azul 22 Polo azul 35 Polo verde 35 Short bege 50 Instância da estrutura Detalhes_Produto na 2ª FN

10 3ª forma Nominal Para uma estrutura se encontrar na 3ª FN, tem que estar na 2ª FN e não haver nenhuma dependência entre elementos não chave. As estruturas Detalhes_Produto e Produto_Encomendado, satisfazem a 3ª FN, não há nada mais a fazer. Com relação a estrutura Encomenda pergunta-se: Informado um determinado valor ao dado Nome_Cliente, há sempre um só valor possível para o dado Endereço? Para um determinado valor de dado Endereço_Cliente, só há um valor possível para o dado Nome_Cliente?

11 3ª forma Nominal Encomenda = Número encomenda + nome cliente + data encomenda + estado Detalhes_Cliente = nome_cliente + Endereço_cliente + Telefone Produto_encomendado = número-encomenda + nome _produto + quantidade_encomendada Detalhes_produto = nome_produto + valor _unitário Nr Enc. nome End. fone data estado 100 Paulo R. C MT 101 Joana R. K MT 102 Rui R. A GO 103 Joana R. K MT Instâncias da Estrutura Encomenda

12 Estrutura Encomenda na 3ª FN Nr Enc. nome data estado 100 Paulo MT 101 Joana MT 102 Rui GO 103 Joana MT Estrutura produto-encomendado Nr Enc. Nome_produto quantidade 100 Calça leg Camisa preta Cinto azul Polo azul Polo verde Calça leg Short bege Short bege 10 Estrutura Detalhes_Cliente 3ªFN nome End. fone Paulo R. C Joana R. K Rui R. A Joana R. K Estrutura Detalhes_Produto Nome_produto V. unit Calça leg 120 Camisa preta 60 Cinto azul 22 Polo azul 35 Polo verde 35 Short bege 50

13 Diagrama de caso de uso Representa, segundo a perspectiva do utilizador, o que o sistema deve efetuar. Tem como objetivo representar funcionalidades que permitem satisfazer os requisitos funcionais do sistema. Elementos: Ator é o utilizador que interage com o sistema. Pode ser uma pessoa ou outro sistema. Caso de uso qualquer sequencia de ações que os atores podem realizar com o sistema para atingir seu objetivo.

14 Cada ator representa uma classe de usuários. Os atores modelam os papéis e não as pessoas dos usuários; por exemplo, o mesmo usuário físico pode agir como Gerente, Gerente de Estoque ou Gerente de Compras.

15 Havendo muitos atores representantes de características comuns e comportamento semelhante, deve agrupa-los em grupos genéricos. Atores genéricos e específicos são ligados por relacionamentos de herança. Ex. Gerente de Vendas e Gerente de Compras têm alguns aspectos em comum, que são abstraídos através do ator Gerente.

16 Um caso de uso realiza um aspecto maior da funcionalidade do produto. Ex. Caso de uso que representam as funcionalidades do SI de Recepção de Encomendas

17 Diagrama de Caso de Uso para SI de Recepção de encomendas

18 Fluxos dos casos de uso Os fluxos dos casos de uso são detalhados por meio de descrições textuais. A UML não impõe formatos obrigatórios para as descrições dos fluxos, mas a forma de descrição textual é semelhante às formas usadas pela maioria dos autores que utilizam os casos de uso. O detalhamento dos fluxos dos casos inclui as suas precondições, ou seja, as condições que supõem estejam satisfeitas, ao iniciar a execução de um caso de uso; o fluxo principal, que representa a execução mais normal da função; e os subfluxos e fluxos alternativos, que representam variantes que são executadas sob certas condições. A UML permite que diversas notações sejam utilizadas para descrever os detalhes dos casos de uso.

19 Fluxos dos casos de uso Nº Caso de uso Quem inicia a ação Descrição do caso de uso 01 Solicitar encomenda 02 Realizar encomenda 03 Elaborar guia transporte 04 Relatórios de vendas usuário Departamento venda Funcionário armazém Gerente venda O usuário entra em contato com sistema para solicitar encomenda Após validado existência de produto e referência cliente, solicitação de encomenda é processada e emitido solicitação fatura Após validado compra, consultado dados cliente, é emitido a guia de transporte. Consultado estoque e venda realizadas, gerar relatório venda

20 Exercício. Dar continuidade / Refazer o sistema de Recepção de encomendas.

21 4. Elaborar Relatórios Vol. venda Gerente de Vendas cliente Encomenda Situação encomenda Enc. rejeitada Diretor (Gerente) Enc. rejeitada Enc. cliente Enc. entregue Referencia 1. Validar encomenda Enc. aceita Existência produto Enc. aceita Produto vendido 2. Elaborar guia transporte Guia transporte Preço unitário 3. Elaborar fatrua Fatura cliente

22 Presença em 21/10/12 Luan, rodrigo, walas, danilo, antonio, guilherme, gustavo, vitor, luana, arthur, luciano, mathias No dia 16/10/12 não ministrei aula.

23 Classes são descrições de conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica. Janela Origem Tamanho Abrir ( ) Fechar ( ) Mover ( ) Exibir ( ) Nome da classe Atributos Serviços / métodos Diagrama de Classes exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos.

24 Diagrama de classe Encomenda Número Data Valor_total Contém Produto Cód_produto Preço_unitário Quant_disponivel Validade Relação Classe

25 Tipos de relacionamento entre classes Generalização indica relacionamento entre um elemento mais geral e um elemento mais especifico (superclasse e subclasse). Também conhecido como herança ou classificação. (Ex. uma enfermeira é uma pessoa.) Agregação denota relacionamento todo / parte. (Ex. um item de compra é parte de um pedido) Associação denotar relações entre classes não correlatas (Ex. um cliente pode alugar vários filmes) Dependência relacionamento entre elementos, um independente e outro dependente. (Ex. cliente e fornecedor)

26 Tipos de relacionamento entre classes

27 Diagrama de classe para o sistema recepção encomenda

28 Metodologia de desenvolvimento de sistemas Método é definido como um conjunto de procedimentos, técnicas, ferramentas e documentação, a ser utilizada na resolução de um problema. Metodologia é definido como o estudo dos métodos ou como a arte de guiar o espírito da investigação. Técnica é um conjunto bem definido de procedimentos que pode ser usado num determinado domínio. Ferramenta é entendida como um conjunto de símbolos e caracteres usados para descrever determinado sistema. Método diz o que fazer e quando, recorrendo a técnicas que diz como ;

29 Tipos de métodos: Métodos estruturados e métodos orientado a objetos; Métodos orientados a processo, métodos orientado a dados e métodos híbridos; Métodos formais e semi-formais Métodos hard e métodos soft.

30 Métodos estruturados caracterizam-se por usar princípios de decomposição como meio de lidar o problema. Esse modelo vê, de forma separada, a representação do modelo de dados ou modelo de processos. Evoluído desse modelo surge: Métodos orientados a processos Método orientado a dados Métodos híbridos

31 Ferramenta Processo de desenvolvimento de sistema de informação - DSI Métodos orientados a objetos recorrem ao conceito de objeto como principal unidade de modelagem. Os objetos contem quer dados, serviços, operações que manipulam os dados. Diferença entre ME e MOO ME distingue dados dos processos OO o objeto encapsula esses dois conceitos Técnica Modelagem processo DFD, Actigramas, árvore decisão, Diagrama decomposição hierárquica, Diagrama pendência processos Modelagem dados DER, Diagrama de analise de dados

32 Métodos formais recorrem a princípios próprios da área de engenharia e defendem o uso de modelos matemáticos para a especificação e validação do SI. Método hard e método soft tornou-se mais popular devido ao fato de os SI estarem sendo encarados numa perspectiva sociotécnica e não meramente tecnológica. Método hard preocupa-se com os aspectos políticos sociais e culturais (defende uma descrição objetiva da realidade, desenvolvimento formal) Método soft preocupa-se com os processos, atividades, regras e produtos do SI, ou seja, aspectos estruturais (realidade é interpretada de forma diferente pelas pessoas envolvidas).

33 Métodos de DSI A escolha do método é uma tarefa difícil. Exemplos. SSADM Structured System Analysis and Designer Method Cobre as fases de estudo de viabilidade, engenharia de requisitos e modelagem do ciclo convencional de SI. Não abrange áreas como gestão de projeto ou a codificação, mas necessita de interfaces com estas, que são feitas através de documentos de input e output, de interação com outros métodos.

34 Métodos de DSI RUP Rational Unifiel Process Pode ser utilizado por grande número de processos e organizações. Suportado por ferramentas CASE, baseado em seis praticas: desenvolver o sistema interativamente; gerir requisitos; usar uma arquitetura baseada em componentes; modelar visualmente o sistema; verificar a qualidade do software e controlar a alterações ao software. O RUP desenrola segundo um processo interativo organizado em fases: Concepção, elaboração, construção e transição. Utiliza como ferramenta a UML Unified Modeling Language

35 Métodos de DSI SSM Soft System Methodology Visa resolver situações humanas, cujos problemas são não estruturados e incertos. A ideia principal desse método é que se pode mudar a forma de investigação em relação as metodologias tradicionais. A investigação passa a ser determinada por um conjunto de pessoas que trabalham de forma colaborativa com o investigador. Na pratica o analista terá que investigar,observar, ler material genérico para depois decidir em conjunto com o cliente uma forma aceitável de fazer a mudança e de como implementar.

36 Relação entre as fases do processo de desenvolvimento e dos métodos Métodos Fases SSADM RUP SSM Estudo da viabilidade X X ER X X X Modelagem x X Testes e implementação Manutenção Ferramentas utilizadas DFD, DER, DVE DCU, DC, DS, DA, DP, componentes e instalação x Diagrama de imagem rica

37 Presença em 23/10/12 Walas, luana, felipe, lucas, vitor, magnum, guilherme, gustavo, luan, mathia, danilo, rodrigo,