Disciplina de Análise & Projeto

Disciplina de Análise & Projeto
PROSOFT Disciplina de Análise & Projeto Fevereiro/ 2011

Agenda Visão geral da disciplina de Análise e Projeto
Conceitos Básicos Fundamentais Uso do RUP e UML em Análise e Projeto Atividades da Disciplina Analisar Impacto Definir Arquitetura Definir Componentes Projetar Interface Visual Projetar Modelo de Dados Conceitos básicos de modelagem de dados Artefatos e Ferramentas Considerações Finais 2

Visão Geral Análise e Projeto 5 atividades 3

Visão Geral Análise e Projeto 4 papéis Projetista
Analista De Negócios / Sistema Arquiteto de Software Administrador de Dados 4

Visão Geral Análise e Projeto 8 artefatos Solicitação Mantis
Documento de Arquitetura de Software Modelo Lógico de Dados Modelo Físico de Dados Scripts (de BD) Protótipo da Interface Visual Especificação de Telas Documento de Arquitetura de Referência atualizado 5

Conceitos Básicos Visão geral da disciplina de Análise e Projeto

RUP Principais Problemas no Desenvolvimento de Software
Necessidades do usuário mal compreendidas Requisitos (Guiado por casos de uso) Falta de habilidade para tratar mudanças de requisitos Iterativo Incremental Descobrimento tardio problemas sérios Centrado na Arquitetura Baixa qualidade de software Guias, padrões e modelos. Problemas com papeis e responsabilidades Processo bem definido;

RUP Rational Unified Process – RUP
Criado por Booch, Jacobson e Rumbaugh, e implementado pela Rational. Em 2003 a IBM compra a Rational. RUP continua sendo, ate hoje, o principal framework de processos no qual as metodologias se baseiam.

RUP É uma plataforma de processos
Adaptavel Deve ser configurada para selecionar os elementos apropriados as necessidades da organizacao Fornece atividades, artefatos e guias ligados As ferramentas IBM/Rational A linguagem UML

RUP - Características Iterativo e Incremental Guiado por casos de uso
O ciclo de vida do produto e dividido em iterações, cada uma entregando incrementos (partes acabadas) do software Guiado por casos de uso Os casos de uso conectam todas as fases e visões, sendo utilizados por todos os stakeholders

RUP - Características Centrado na arquitetura Orientado a Objetos
Envolve aspectos estáticos e dinâmicos Evolui a partir das necessidades do produto Orientado a Objetos Componentes são construídos através de Objetos e estes colaboram entre si para realizar os casos de uso Planejado por riscos Os riscos são analisados continuamente e os de maior criticidade são tratados prioritariamente

RUP – Príncipios Fundamentais
Adaptar o processo O processo deve ser dimensionado e adaptado corretamente, de acordo com a necessidade da organização Balancear prioridades dos investidores Deve-se equilibrar necessidades conflitantes e reduzir a ”customização” Colaborar em equipe Ambientes de colaboração adequados devem ser criados para uma melhor comunicação da equipe

RUP – Príncipios Fundamentais
Demonstrar valor iterativamente Reduzir riscos precocemente Aumentar a confiança dos investidores Elevar o nível de abstração Ferramentas de modelagem de alto nível devem ser utilizadas para reduzir o nível de complexidade e aumentar a produtividade Focar continuamente na qualidade E preciso acompanhar a qualidade ao longo de todo o ciclo de vida de desenvolvimento

RUP - Gráfico das Baleias

RUP - Dimensões Eixo horizontal Eixo vertical
Representa o aspecto dinâmico do processo Expresso em termos de fases, marcos e iterações Eixo vertical Representa o aspecto estático do processo Expresso em termos de componentes, disciplinas, atividades, artefatos, papeis...

RUP - Componentes Metodologia Modelos, Padrões e Guias
CMMI MPS.BR PMBOK Equipes Treinadas Metodologia Linguagem Padrão Ferramentas Rational JUDE ERWin Processo de Desenvolvimento Conjunto de métodos e práticas bem definidas Com responsáveis Entradas/Saídas Ordem de precedência

RUP - Fases Cada fase termina com um marco Concepção Elaboração
Estabelecer o escopo, e estimar custos e riscos Elaboração Assegurar que os principais riscos foram diminuídos e definir uma arquitetura executável Construção Desenvolver de modo iterativo e incremental um produto completo para a Transição Transição Disponibilizar o Software para seus usuários finais

RUP - Iterações Cada passagem pela sequência de disciplinas do projeto se chama iteração

RUP – Fases e Iterações Cada fase pode ser dividida em iterações

RUP - Disciplinas São um conjunto de atividades relacionadas a uma “área de interesse” do projeto Cada disciplina possui um fluxo de trabalho

RUP - Disciplinas Cada disciplina está associada a um conjunto específico de modelos

RUP – Análise e Design Objetivos
Transformar os requisitos em um projeto do sistema a ser criado Desenvolver uma arquitetura refinada para o sistema Adaptar o projeto para que corresponda ao ambiente de implementação, considerando restrições de tecnologia

RUP – Visões Arquiteturais
No RUP a arquitetura é representada por uma serie de visões de arquitetura diferentes Em sua essência, as Visões são fragmentos que ilustram os elementos “significativos em termos de arquitetura” É conhecido como o modelo de visão 4+1

RUP - Visões

RUP – Visão de Casos de Uso
Contém Casos de Uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes ou riscos técnicos É uma visão obrigatória do documento de arquitetura de software

RUP – Visão Lógica Contém as classes de projeto mais importantes e sua organização em pacotes e subsistemas, e a organização desses pacotes em camadas É uma visão obrigatória do documento de arquitetura de software

RUP – Visão de Implementação
Contém uma visão geral do Modelo de Implementação e sua organização em termos de módulos em pacotes e camadas Detalha os pacotes e módulos da Visão Lógica (detalhes “fisicos”) E uma visão opcional do documento de arquitetura de software Deve ser usada apenas se a implementação não for derivada diretamente do modelo de projeto (isto é, há detalhes adicionais)

RUP – Visão de Processos
Contém a descrição das tarefas (processos e threads) envolvidas, suas interações e configurações e a alocação dos objetos e classes de projeto em tarefas E uma visão opcional do documento de arquitetura de software Só precisa ser usada se o sistema tiver alto grau de paralelismo

RUP – Visão de Implantação
Contém a descrição dos vários nós físicos do sistema e a alocação de tarefas atribuídas a eles É uma visão opcional do documento de arquitetura de software Só precisará ser usada se o sistema estiver distribuído em vários nós físicos

RUP – Análise e Design Marco da Fase de Elaboração :
Arquitetura do Ciclo de Vida Critérios de Avaliação (Checklist) : A arquitetura e estável e robusta, comportando requisitos atuais e futuros? Riscos críticos foram resolvidos? Riscos Arquiteturais O planejamento esta bem definido em termos de cronograma, orçamento e níveis de qualidade? Devemos fechar o contrato? Principal Artefato : Documento de Arquitetura de Software Realizações dos Casos de Uso

RUP – Análise e Design Relação com outras disciplinas
Modelagem de negocio Fornece o contexto organizacional para o sistema Requisitos Fornece a visão das funcionalidades criticas a serem implementadas Teste Testa o sistema projetado durante a disciplina de Analise e Design Ambiente, Gerenciamento de Projeto

UML – Unified Modeling Language
Linguagem de Modelagem Unificada Linguagem Usada para expressar e comunicar idéias Não é uma metodologia! Modelagem Descrever um sistema em um alto nível de abstração Unificada Booch(OOAD) + Jacobson(OOSE) + Rumbaugh(OMT) + Outros UML se tornou o padrão mundial para modelagem de sistemas -

UML – O que é? Linguagem gráfica para especificar, visualizar, construir e documentar os artefatos de software Vantagens Usa notação gráfica: mais clara que a linguagem natural (imprecisa) e código (muito detalhado) Ajuda a obter uma visão geral do sistema Não é dependente de tecnologia Diminui a fragmentação, aumenta a padronização (comunicação)

UML Diagramas

UML 2.2 - Diagramas Diagramas estruturais Diagramas comportamentais
Mostram a estrutura estática do sistema e suas partes em diferentes níveis de abstração e como elas se relacionam Não utilizam conceitos relacionados ao tempo Diagramas comportamentais Mostram a natureza dinâmica dos objetos do sistema, que pode ser descrita como uma serie de mudanças no sistema com o passar do tempo

UML 2.2 - Diagramas Diagramas Estruturais (estáticos)
Diagrama de Classes Diagrama de Objetos Diagrama de Componentes Diagrama de Pacotes Diagrama de Implantação Diagrama de Estrutura Composta Diagrama de Perfis (UML 2.2)

UML 2.2 - Diagramas Diagramas Comportamentais (dinâmicos)
Diagrama de Casos de Uso Diagrama de Atividade Diagrama de Máquina de Estados Diagramas de Interação Diagrama de Seqüência Diagrama de Comunicação Diagrama de Tempo Diagrama de Interação Geral

UML – Diagrama De Classes
É um diagrama estático da UML que reúne os elementos mais importantes de um sistema orientado a objetos Exibe um conjunto de classes, interfaces e seus relacionamentos As classes especificam tanto as propriedades quanto os comportamentos dos objetos

UML – Estrutura da Classe
Nome da Classe Atributos Operações

UML – Estrutura da Classe
Três Formas de Apresentação Nome Nome + Atributos Nome + Atributos + Operações

UML – Estágios do Modelo de Classes
Modelo de classe de análise Representa as classes de análise Foca a atenção sobre “o que” o sistema deve fazer Não leva em consideração restrições inerentes à tecnologia a ser utilizada na solução de um problema

UML – Modelo de Classe de Análise

UML – Estágios do Modelo de Classes
Modelo de Classe de Projeto Detalhamento do modelo de classe de análise Foca a atenção em “como” o sistema deve funcionar Normalmente, neste momento, descobre-se a necessidade de criação de novas classes Adição de detalhes em função da solução de software escolhida (linguagem, arquitetura, etc.)

UML – Modelo de Classe de Projeto

UML – Diagrama de Sequência
Captura o comportamento de um determinado cenário Mostra os objetos e as mensagens trocadas entre eles (interações) Enfatiza a ordem temporal das mensagens É o diagrama mais utilizado na etapa de Projeto OO (solucionar o problema)

UML – Diagrama de Sequência

Atividades Visão geral da disciplina de Análise e Projeto

Analisar Impacto Papéis Entrada Obrigatória Entradas Opcionais
Projetista [P] Time SCRUM [S] Analista [Negócios / Sistema] [S] Administrador de Dados [S] Entrada Obrigatória Solicitação do Mantis Entradas Opcionais Documento de Requisitos Modelo Conceitual de Dados Script de Banco Código Fonte 51

Analisar Impacto Saídas Etapas Solicitação do Mantis Atualizada
Analisar Solicitação Reunião de Repasse da Mudança Solicitada Analisar Modelo de Dados Analisar Código Fonte Analisar Interfaces Externas Atualizar Solicitação do Mantis Adicionar anotação com o resultado da análise Atribuir a solicitação para fábrica 52

Analisar Impacto Analisar Solicitação
Análise para verificar a extensão das mudanças solicitadas pelo Analista de Negócio. Participantes : Projetista e Analista de Negócio.

Analisar Impacto Reunião de repasse da mudança solicitada
O Analista de Negócios apresenta o sistema que será afetado e as mudanças solicitadas. pelo Mantis para o Projetista, o Administrador de Dados e a equipe da fábrica que desenvolverá a mudança. Participantes : Projetista, Desenvolvedores, Analista de Negócio e Administrador de Dados.

Analisar Impacto Analisar Modelo de Dados
O Administrador de Dados verifica as mudanças necessárias no modelo de dados do sistema. O Administrador de Dados refletirá as alterações do sistema no BD. Participante : Administrador de dados.

Analisar Impacto Analisar Código Fonte
Avaliar o impacto que as mudanças solicitadas causarão ao código fonte da aplicação. Participantes : Projetista e Desenvolvedores.

Analisar Impacto Analisar Interfaces Externas
Analisar os pontos de contato que serão afetados (interfaces) deste sistema com outros; Caso encontre algum ponto, o Projetista documentará e indicará como ocorrerá a integração (Web Services, Procedures, etc...) através do item “Projeto de Interfaces Externas”, do Documento de Arquitetura do Sistema (DAS). Participante : Projetista.

Analisar Impacto Atualizar Solicitação do Mantis
Adicionar anotação com o resultado da análise O Projetista descreverá o seu parecer sobre a análise e as possíveis sugestões de implementação para os desenvolvedores. Atribuir a solicitação para fábrica Liberação do caso para que a fábrica possa começar a trabalhar no desenvolvimento do caso. Participante : Projetista.

Definir Arquitetura Papéis Projetista [P],
Arquiteto de Software [S] , Administrador de Dados [S] Entradas Obrigatórias Documento de Visão do Negócio Documento de Visão do Sistema Especificação de Casos de Uso Especificação de Regras de Negócio Especificação de Telas Especificações Suplementares Modelo Conceitual de Dados Relação de Casos de Uso Solicitação do Mantis Arquitetura de Referência de Software 60

Definir Arquitetura Saídas Documento de Arquitetura de Software
Solicitação do Mantis Atualizada 61

Definir Arquitetura Desenvolver a Visão Geral da Arquitetura
Serve para transmitir para as equipes de desenvolvimento e outros envolvidos um entendimento inicial da estrutura de nível superior do sistema desejado; Descreve as hipóteses de trabalho e decisões iniciais sobre a implementação da Visão, bem como as decisões relativas à arquitetura física e lógica e aos requisitos não-funcionais do sistema. Elaborada pelo arquiteto de software, geralmente em colaboração com o patrocinador do projeto. 62

Definir Arquitetura Desenvolver a Visão Geral da Arquitetura 63

Definir Arquitetura Identificar Abstrações-Chave (Entidades)
Identificação das abstrações-chave (representação de conceitos identificados durante as atividades de modelagem de negócios e requisitos) a serem tratadas pelo sistema. Descrever a organização da aplicação em classes, pacotes, subsistemas e/ou camadas Utilização de figuras e diagramas para um melhor esclarecimento 64

Definir Arquitetura Identificar Abstrações-Chave (Entidades) 65

Definir Arquitetura Criar Realizações dos Casos de Uso Arquiteturalmente Significativos Descreve como um determinado caso de uso é realizado no modelo de análise em termos de objetos de colaboração (diagrama de sequência). Os diagramas de seqüência ilustram o fluxo de eventos de um caso de uso realizados por um conjunto de instâncias de classes (de projeto simplificadas) e de subsistemas. 66

Definir Arquitetura Criar Realizações dos Casos de Uso Arquiteturalmente Significativos 67

Definir Arquitetura Projetar Interfaces Externas (Opcional)
Descreve as interfaces Fornecidas para outros sistemas. Consumidas pelo sistema Os possíveis tipos de interfaces que podem ser projetados são: Layout de Arquivos Layout de Mensagens / Procedures Protocolos de comunicação 68

Antecedentes Web Cliente Antecedentes Web Admin
Definir Arquitetura Projetar Interfaces Externas (Opcional) Web Service BD Client Antecedentes Web Cliente Antecedentes Web Admin Sistemas Internos XML/SOAP 69

Definir Arquitetura Atualizar Solicitação do Mantis
A solicitação do Mantis poderá ser quebrada em outras solicitações, de forma que a granularidade seja adequada para implementação. Atribuir a solicitação para fábrica.

Definir Componentes Papéis Projetista [P], Arquiteto de Software [S]
Entradas Obrigatórias Documento de Arquitetura Documento de Visão do Negócio Documento de Visão do Sistema Especificação de Casos de Uso Especificação de Regras de Negócio Especificação de Telas Especificações Suplementares Modelo Conceitual de Dados Relação de Casos de Uso Solicitação do Mantis 72

Definir Componentes Saídas Etapas Documento de Arquitetura de Software
Solicitação do Mantis Atualização do documento da Arquitetura de Referência (Opcional) Etapas Identificar Componentes da Arquitetura de Referência do TJPE Descreve os componentes definidos na Arquitetura de Referência e outros componentes próprios do TJPE que serão utilizados no projeto. 73

Definir Componentes Etapas Identificar Componentes Padrões de Mercado
Elenca os componentes padrões de mercado para cada necessidade, informa o componente selecionado para a referida necessidade e justifica a escolha do determinado componente. Identificar Componentes de Terceiro Em caso de utilização de componentes de terceiros (desenvolvidos por outros órgãos e empresas), deve ser descrita a necessidade e justificativa de utilização deste. 74

Definir Componentes Etapas Identificar Novos Componentes (Opcional)
Sendo identificada a necessidade de desenvolver um componente, nessa etapa, será descrita em detalhes esta necessidade, bem como reusabilidade do componente e funcionalidades esperadas. Atualizar Solicitação do Mantis (Opcional) Caso o Projetista julgue necessário, a solicitação do Mantis poderá ser quebrada em outras solicitações, de forma que a granularidade seja adequada para implementação. Atribuir a solicitação para fábrica. 75

Projetar Interface Visual
Papéis Analista [Negócios / Sistema] [P], Projetista [S] Entradas Obrigatórias Documento de Visão do Negócio Documento de Visão do Sistema Especificação de Casos de Uso Especificação de Regras de Negócio Especificações Suplementares Modelo Conceitual de Dados Relação de Casos de Uso Padrão de Interface Visual Solicitação do Mantis 77

Entradas Opcionais Arquitetura de Referência de Software (sistemas em Java) Saídas Protótipo da Interface Especificação de Telas Etapas Analisar Requisitos Identificar o fluxo de informações e de eventos Produzir o layout e alternativas em programa apropriado 78

Analisar Requisitos Verificar as informações consumidas e fornecidas; Verificar os atores que interagem com os processos descritos; Verificar o fluxo da informação (básico, alternativo e de exceção); Verificar as pré-condições e pós-condições; Verificar possíveis mensagens (positivas ou de sucesso; negativas ou de erro; advertência, notificação ou informação); Verificar as restrições do sistema (regras de negócio do sistema).

Identificar o fluxo de informações e de eventos Descreve como as informações (casos de uso) estão inter-relacionadas e como devem ser agrupadas; Identificação dos processos-chave do sistema que podem ser organizados como uma seqüência visual das etapas do processo. Navegação Identificar quais caminhos o usuário pode seguir dentro do sistema e a conseqüência (condições e restrições) dessas escolhas

Produzir o layout e alternativas Apresentar ao cliente a idéia do sistema com maior precisão Photoshop Layout em HTML com uso de CSS Uso de efeitos visuais que mudam sob a ação do usuário Uso de botões e recursos dinâmicos Mesmo que os elementos, a composição e a descrição sejam satisfatórias em papel ou na imagem estática, a demonstração do uso permite uma percepção completa da solução, tanto sob o ponto de vista visual como funcional.

Visão Geral 83

Projetar Modelo de Dados
Papéis Projetista [P], Analista de Negócio [S], Administrador de Dados [S] Entradas Obrigatórias Documento de Visão do Negócio Documento de Visão do Sistema Modelo Conceitual de Dados Entradas Opcionais Solicitação do Mantis 84

Saídas Modelo Lógico de Dados Modelo Físico de Dados Scripts Etapas Desenvolver o modelo lógico de dados Refinar o modelo lógico de dados com aplicação das regras normais Aplicar até a 3FN para identificar eventuais anomalias no modelo lógico de dados. Validar a nomenclatura dos objetos segundo a Padronização de Nomenclatura de Objetos de Banco de Dados do TJPE 85

Etapas Avaliar serviços da camada de dados canônicos Identificar se existem tabelas modeladas que possam ser mapeadas para tabelas canônicas existentes ou se existem tabelas modeladas que possam ser candidatas a serem tabelas canônicas. Avaliar também a disponibilidade dos serviços de dados existentes e a necessidade de desenvolver novos serviços. Desenvolver o modelo físico de dados Gerar scripts de criação / alteração das tabelas e colunas do banco de dados 86

Conceitos Atividades Conceitos básicos de modelagem de dados
Projetar Modelo de Dados Conceitos básicos de modelagem de dados 87

Projeto de Banco de Dados
Processo de Análise dos Requisitos Organizacionais Desenvolvimento de um Modelo Conceitual que represente esses requisitos Realização do Modelo Conceitual num Modelo Lógico e Modelo Físico, utilizando uma tecnologia de Base de Dados

Projeto de Banco de Dados
necessidades de informação modelo de dados da empresa características hw/so Análise de requisitos Construção do modelo Conceitual especificação de requisitos Construção do modelo lógico estrutura Conceitual da informação Construção do modelo físico estrutura lógica dos dados e aplicações estrutura física dos dados necessidades de processamento características do SGBD

Modelo Entidade-Relacionamento – M.E.R.
O grande objetivo de um sistema de BD é oferecer uma visão “abstrata” dos dados aos usuários. Os detalhes referentes a forma como estes dados estão armazenados e mantidos não interessa aos usuários, mas a disponibilidade eficiente destes dados é que são fundamentais. Abstração Mundo real modelo Representação em computadores

O conceito de abstração está associado à característica de se observar somente os aspectos de interesse, sem se preocupar com maiores detalhes envolvidos. No contexto de abstração de dados, um banco de dados pode ser visto sem se considerar a forma como os dados estão armazenados fisicamente.

Um MER é um modelo formal, preciso, não ambíguo. Diferentes leitores de um mesmo MER devem sempre entender o mesmo modelo. O MER possui poder de expressão limitado. Empregado n 1 supervisor supervisionado Supervisão Algumas restrições precisam ser descritas à parte do MER.

Representação semântica das estruturas de dados mantidas num banco de dados Foi proposto por Peter Chen em 1976 Possui várias notações: Relacionamentos como objetos do Modelo (Chen) Relacionamentos apenas como simples ligações (Codd, Martin)

M.E.R. - ENTIDADE Uma entidade é tudo aquilo sobre o qual se deseja manter informações. Podendo representar: objetos concretos: pessoas, livros, carros, … conceitos abstratos: empresas, eventos, embarques, … Possui propriedades que a distingue de outras entidades. É um subconjunto de objetos (instâncias) que: desempenha o mesmo papel semântico possui os mesmos tipos de propriedades (atributos)

M.E.R. - ENTIDADE - Exemplos:
Conjunto de todas as contas correntes de um banco Conjunto de todos os empregados de uma empresa Conjunto de todos os processos do 1º Grau Representação de entidades no diagrama E-R (entidades e relacionamentos): Empregado Conta Corrente Designa o conjunto de todos os empregados sobre as quais se deseja manter informações no banco de dados Processo

M.E.R. - ENTIDADE Entidades devem ser descritas num
Dicionário de Dados

M.E.R. - ATRIBUTOS São as propriedades que caracterizam ou descrevem uma entidade ou um relacionamento. Ex.: A entidade EMPREGADO poderia ter os seguintes atributos: Matricula, Nome, Data_Nascimento, Endereço, , Telefone. Cada atributo possui um domínio que identifica o conjunto de valores permitidos para aquele atributo.

M.E.R. - ATRIBUTOS Atributos devem também ser descritos
no Dicionário de Dados:

M.E.R. - RELACIONAMENTOS São associações entre diversas entidades.
Ex.: “Um empregado trabalha num projeto” “Um cliente possui conta bancária” “Um filme possui vários atores” Empregado Projeto trabalha 1..N 1..N matricula salário horas nome Representado graficamente por um losango

M.E.R. – RELACIONAMENTOS - Exemplo
Pessoa Lotação Departamento Relacionamento A figura expressa que o BD mantém informações sobre: Um conjunto de objetos classificados como pessoas (entidade Pessoa). Um conjunto de objetos classificados como departamentos (entidade Departamento). Um conjunto de associações, cada uma ligando um departamento a uma pessoa (relacionamento Lotação).

M.E.R. - RELACIONAMENTOS Quando nos referirmos a associações particulares dentro de um conjunto, vamos nos referir a ocorrências ou instâncias de relacionamentos: No caso do relacionamento Lotação, uma ocorrência seria um par específico, formado por uma determinada ocorrência da entidade Pessoa e por uma determinada ocorrência da entidade Departamento. p1 p3 p7 p8 p2 p4 p6 p5 p1d1 p2d1 p4d2 p5d3 d1 d2 d3

M.E.R. - CARDINALIDADE de Relacionamentos
Propriedade importante de um relacionamento: Quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência através do relacionamento (Cardinalidade). PESSOA DEPARTAMENTO João Luiz Maria Afonso José Pedro A B C

M.E.R. - Especialização Representação gráfica:
Através deste conceito é possível atribuir propriedades particulares a um subconjunto das ocorrências (especializadas=subclasse) de uma entidade genérica (superclasse). Representação gráfica: superclasse código Processo n n Parte possui nome Pessoa Física Pessoa Jurídica subclasses Inscrição Estadual Nome Mãe CNPJ CPF

Construindo Modelos ER
Na construção de um MER não considerar um objeto isoladamente. É necessário conhecer o contexto. Modelagem sempre sujeita a alteração. O aprendizado sobre a realidade possibilita o refinamento e aperfeiçoamento do modelo.

Dúvida frequente: quando um objeto é Atributo e quando é uma Entidade? Automóvel Automóvel n OU Cor ? 1 Cor

Dúvida frequente: quando um objeto é um Atributo ou Especialização? nome Empregado código Empregado OU ? código Motorista Engenheiro categoria funcional nome data_validade_hab CREA habilitação

Dúvida frequente: Atributo Multivalorado ou Entidades/Relacionamentos? nome Empregado Empregado código código nome Dependente* Dependente E telefone ? nome data de nascimento

Verificação do modelo ER
Após ser elaborado, o modelo ER deve ser verificado e validado. É importante verificar se: O modelo é correto O modelo é completo O modelo possui redundâncias O modelo reflete o aspecto temporal

O modelo é correto: Estabelecer associações incorretas: Órgão Emissor com Estado Civil. Utilizar uma entidade do modelo como atributo de outra entidade: Processo e Processo como atributo de Parte. Número incorreto de entidades em um relacionamento: ternários x agregação.

O modelo é completo: Todos os dados que devem ser obtidos do banco de dados estão presentes. Todas as transações de modificação do banco de dados podem ser executadas no modelo.

O modelo está livre de redundâncias:
Verificação do modelo ER O modelo está livre de redundâncias: Um modelo deve ser mínimo, ou seja, não deve conter conceitos redundantes. Em geral, a redundância pode existir através de relacionamentos redundantes e de atributos redundantes.

Atributos redundantes
Verificação do modelo ER Atributos redundantes lotação Empregado Departamento código nome número de empregados nome do departamento

O modelo reflete o aspecto temporal: Cliente Cliente 1 n locação locação data n n DVD DVD Estatísticas e Históricos

Modelo Relacional Representação tabular de uma relação R n-ária:
Cada linha representa uma n-tupla de R. A ordem das linhas não é significante. Todas as linhas são distintas. A ordem das colunas é significante: Corresponde à ordem S1, S2, ..., Sn dos domínios* sobre os quais R é definido. Cada tabela possui um nome. Cada coluna (também chamada de atributo ou campo) possui um nome. .

Modelo Relacional Um banco de dados relacional é composto de Tabelas ou Relações: Tabela – termo mais empregado na prática. Relações – termo mais empregado na literatura formal da área de BD. Matricula Nome Fone 12345 Gilberto 6481 12346 Sandra 6444 12347 Isabela 6333 12349 Jonas 6233 Domínio de um atributo: é o conjunto de valores permitidos para um atributo.

Modelo Relacional Termo relacional formal Equivalentes informais
Relação Tabela Tupla Linha Cardinalidade Número de linhas Atributo Coluna ou campo Grau Número de colunas Chave primária Identificador exclusivo Conjunto de valores válidos Domínio

Propriedades das relações
Modelo Relacional Propriedades das relações Não existem tuplas duplicadas: Duas linhas, em uma relação, não podem ser iguais. Esta propriedade é derivada do conceito de conjunto matemático (um conjunto não permite a existência de elementos repetidos) SQL não obriga que uma tabela não possua linhas duplicadas.

Modelo Relacional Propriedades das relações Tuplas não são ordenadas de cima para baixo: Não existe nenhuma seqüência entre as tuplas. Esta propriedade também é derivada do conceito de conjunto matemático (os elementos de um conjunto não são ordenados).

Modelo Relacional Propriedades das relações Atributos não são ordenados da esquerda para a direita: Não existe nenhuma seqüência particular entre os atributos de uma relação. Este conceito decorre do fato de que o cabeçalho de uma relação é também um conjunto (de atributos). Os atributos de uma relação são sempre referenciados pelo nome, nunca pela posição.

Modelo Relacional Propriedades das relações Cada tupla contém exatamente um valor para cada atributo: Cada valor em uma tupla é um valor atômico, ou seja, um valor que não pode ser dividido. Portanto, atributos compostos e multivalorados não são permitidos.

Modelo Relacional Chaves
Conceito básico de um banco de dados relacional que se aplica: Na identificação de linhas Estabelecimento de relações entre linhas de tabelas. Tipos de chaves: Primária (Primary Key – PK) Alternativa (Candidata) Estrangeira (Foreign Key – FK)

Modelo Relacional Chave Primária
Coluna ou combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela. Chave Primária Matricula Nome Fone 12345 Gilberto 6481 12346 Sandra 6444 12347 Isabela 6333 12349 Jonas Tabela: Alunos

Modelo Relacional Requisitos:
Chave Mínima: todas as colunas são realmente necessárias para garantir o requisito de unicidade de valores da chave. A conotação dada a chave no modelo relacional é diferente da usada em organização de arquivos: Chave em outros conceitos é entendido como um caminho de acesso No modelo relacional estamos definindo uma restrição de integridade: unicidade de valores nas colunas que compõem a chave.

Modelo Relacional Chave Estrangeira
Coluna ou combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela. Mecanismo que permite a implementação de relacionamentos em um banco de dados relacional.

Modelo Relacional Chave Estrangeira Aluno
Obs.: Através do relacionamento, evitamos a repetição de informações. MATRICULA NOME CURSOID 98765 João MAT 67765 José BIO 84562 Maria ENG 34256 Luis INFO Ana 34529 Luana Relacionamento Curso CURSOID TITULO DURAÇÃO INFO Informática Indust. 4 BIO Biologia ENG Engenharia Civil 5 MAT Licenciatura Mat.

Modelo Relacional Chave Estrangeira Observações:
Uma chave estrangeira não precisa ter o mesmo nome do que a chave primária correspondente na outra tabela (apenas o mesmo domínio).

Impõe restrições que devem ser garantidas ao serem executadas diversas operações no Banco de Dados: A inclusão de uma linha na tabela que contém a chave estrangeira: Garantir que o valor da chave estrangeira exista na coluna da tabela da chave primária. Alteração do valor da chave estrangeira: O novo valor deve aparecer na coluna da chave primária referenciada.

Exclusão de uma linha da tabela que contém a chave primária referenciada por uma chave estrangeira: Não se exclui a linha caso exista um valor na tabela com a chave estrangeira. Remove-se também a linha com o valor de chave estrangeira. Valor da chave estrangeira é ajustado como NULL. Alteração do valor da chave primária referenciada por alguma chave estrangeira: Propagar a modificação Não deixar que seja feita a modificação

Restrições de Integridade
Uma das funcionalidades básicas que todo SGBD deve oferecer, sendo um de seus objetivos também. Restrição de integridade: É uma regra de consistência de dados que é garantida pelo SGBD. Tipos de Restrições: Chave Integridade Referencial Semântica

Restrições de Integridade
Restrições de Chaves: cada atributo das chaves candidatas deve possuir valor único em todas as tuplas da relação. Restrição de Integridade de Entidade: uma chave primária não pode assumir valor nulo em qualquer tupla da relação. Restrição de Integridade Referencial: uma tupla em uma relação que se refere a outra relação, deve se referenciar a uma tupla existente nesta relação (chave estrangeira). Restrições de Integridade Semântica: se referem mais especificamente sobre valores ou características que determinados atributos podem assumir no contexto de uma determinada aplicação (por exemplo sexo).

Transformações entre Modelos
MER – Voltado para a Modelagem de Dados independente do SGBD – Adequado para construção do Modelo Conceitual Modelo Relacional – Modela os dados no nível de SGBD Relacional (Modelo Lógico) Transformação entre MER e Modelo Relacional Projeto Lógico: transformação de um MER em um modelo lógico que implementa, em um SGBD Relacional, os dados representados abstratamente no MER. (Para outros tipos de SGBD outras regras são necessárias).

Passos: Implementação de entidades e respectivos atributos 2. Implementação de relacionamentos e respectivos atributos 3. Implementação de generalizações especializações

Passo 1: Entidade = Tabela Atributo = Coluna Atributo identificador = Chave Primária Cliente Cliente (CodigoCli, Nome, Endereco, DataNasc) data de nascimento endereço nome código

Passo 2: Relacionamentos A tradução do relacionamento depende da cardinalidade (mínima e máxima) das entidades que participam do relacionamento. Formas básicas de tradução: Tabela própria Colunas adicionais dentro da tabela de entidade Fusão de Tabelas de entidades

Passo 3: Generalização/Especialização Alternativas de implementação: Uma tabela para toda hierarquia (generalização) Uma tabela para cada Entidade Especializada Subdivisão da Entidade Genérica

Normalização - Introdução
Introduzida por E.F.Codd em 1970 (1FN) Objetivo Gerar um conjunto de esquemas de relações que permita: Armazenar informações sem redundância desnecessária, e Recuperar informações facilmente. Em resumo... Evita anomalias de atualização e redundâncias no projeto do BDR Permite representar eficientemente os dados do mundo real, tornando o modelo mais estável e de fácil manutenção Visão geral: Converter progressivamente uma tabela em tabelas menores, até que pouca ou nenhuma redundância de dados exista Processo sistemático de geração de tabelas

Se a normalização é bem sucedida Economiza-se espaço de armazenamento A tabela pode ser atualizada mais rapidamente Pode ser usada para validação do modelo relacional gerado pelas transformações vistas anteriormente Seu benefício é melhor percebido quando aplicado em modelos relacionais obtidos por engenharia reversa de sistemas de arquivos Também pode ser usada para geração do modelo relacional a partir de documentos da organização Gerar tabelas a partir de notas fiscais, históricos escolar, relatórios, etc.

É baseada no conceito de formas normais (regras) Existem 5 formas normais, mas a 1, 2 e 3 são as mais aplicadas Do ponto de vista prático e de desempenho, sua aplicação nem sempre é ideal. Proliferação de tabelas Usar o bom senso ! Inicialmente, usa-se o conceito de dependência funcional para expressar fatos acerca dos dados.

Normalização/Teoria das Dependências
Dependência Funcional (DF) Dada uma tabela qualquer, diz-se que existe DF de uma coluna ou conjunto de colunas C1 sobre uma coluna C2, se para cada valor de C2 aparece o mesmo valor ou conjunto de valores de C1. Diz-se então: C1 depende funcionalmente de C2 ou C2 determina C1 (C2C1) EX: Empregado (CodEmp, Nome,DtNasc,Categoria,Salario) CodEmpNome CodEmpDtNasc CodEmpCategoria CodEmpSalario CodEmp(Nome,Categoria,Salario)

Normalização 1a Forma Normal (1FN)
Cada ocorrência da ch. primária deve corresponder a um e somente um valor de cada coluna Não possui campos multivalorados Isto é, se todas as colunas da tabela são funcionalmente dependentes da ch. primária da mesma (CP  (C1,C2,C3,...,Cn)). Como transformar uma tabela para a 1FN: 1) Se a qtd. de valores é muito variável, desconhecida ou grande Transformar atributos multivalorados em tabelas relacionadas EX: Transformar Cliente (CodCli,Nome,Sexo,Carro,Cor,Tipo) em Cliente(CodCli,Nome,Sexo) Carro (CodCar,Carro,Cor,Tipo,CodCli) CodCli referencia Cliente 2) Se a qtd. de valores é pequena e conhecia a priori Transformar atributos multivalorados em uma lista definida de colunas, de mesmo domínio EX: Transformar Paciente (CodPac, Nome, GrausDeLente) em Paciente (CodPac, Nome, GrauLenteE, GrauLenteD)

Dependência Funcional Parcial (DFP) Ocorre quando uma coluna ou conjunto delas dependem apenas de parte das colunas da ch. primária composta EX:EngProj(CodEng,CodProj,DtInicio,Nome,DtNas,Gratificacao,Cargo) Dependência Funcional Total (DFT) É o oposto da DFP EX: (CodEng,CodProj)  (Gratificacao,Cargo)

Normalização 2a Forma Normal (2FN) Uma tabela esta na 2FN quando:
Está na 1FN e Não conter DFP. Ou seja, todas as colunas que não participam da ch. primária composta são dependentes da mesma (DFT) EX: EngProj(CodEng,CodProj,DtInicio,Nome,DtNas,Gratificacao,Cargo) Como transformar uma tabela para a 2FN Retira-se a(s) coluna(s) com DFP da tabela original A partir dessa(s) coluna(s) retirada(s), cria-se uma ou mais tabelas compostas pela parte da ch. primária e suas colunas dependentes A parte da ch. primária que gerou a dependência será a nova ch. primária da tabela criada. Verifica-se a 1FN para cada nova tabela EX:Engenheiro(CodEng,Nome,DtNasc) Projeto(CodProj,DtInicio) EngProj(CodEng,CodProj,Gratificacao,Cargo)

Dependência Funcional Transitiva (DFT) Dada uma tabela qualquer, diz-se que existe DFT quando uma coluna ou conjunto de colunas C1 dependem de uma coluna C2, que não é ch. primária, mas que depende funcionalmente da mesma (C3) Ou seja, se C1 depende de C2 e C2 não é ch. primária, mas depende de C3 que é ch. primária, então, C1 depende transitivamente de C3 EX: 1) CodEmp  (Nome,Categoria,Salario) Diz-se que Salario é dependente transitivo de Categoria. Então, se Categoria é determinada por CodEmp, este, indiretamente (transitivamente) também determina Salario.

Normalização 3a Forma Normal (3FN) Uma tabela esta na 3FN quando:
Está na 2FN e Não contém DFT. Ou seja, todas as colunas que não participam da ch. primária são exclusivamente dependentes da mesma. EX: Empregado(CodEmp,Nome,Categoria,Salario) Como transformar uma tabela para a 3FN Retira-se a(s) coluna(s) com DFT da tabela original A partir dessa(s) coluna(s) retirada(s), cria-se uma ou mais tabelas compostas pela coluna determinante (como ch. primária) + suas colunas dependentes Verifica-se a 1FN e a 2FN para cada nova tabela EX:Empregado(CodEmp,Nome,Categoria) Categoria(Categoria,Salário) OBS: Além de não conter DFT, as tabelas na 3FN não devem possuir colunas com valores calculados (derivados)

Artefatos e Ferramentas
Visão geral da disciplina de Análise e Projeto Conceitos Básicos Fundamentais Uso do RUP e UML em Análise e Projeto Atividades da Disciplina Analisar Impacto Definir Arquitetura Definir Componentes Projetar Interface Visual Projetar Modelo de Dados Conceitos básicos de modelagem de dados Artefatos e Ferramentas Considerações Finais 145

Modelagem de Dados Indefinido (ERWin, DBDesigner, Visio, PowerDesigner, etc…) Acesso ao SGBD Oracle : SQLDeveloper Sybase : SQLDBx Modelagem de Sistemas UML : JUDE 146

Artefatos Principais Documento de Arquitetura de Software Especificação de Telas Documento de Arquitetura de Referência Atualizado Outros Artefatos Gerados Solicitação Mantis Modelo Lógico de Dados Modelo Físico de Dados Scripts (de BD) Protótipo da Interface Visual 147

Considerações Finais Visão geral da disciplina de Análise e Projeto

Dúvidas | Sugestões Núcleo de Gestão de Processos de TIC : Unid. de Eng. de SW - Componentes e Servicos : Unidade de Arquitetura de Dados : Unidade de Arquitetura de SW : Mantis: “Processo de Software” 149

Disciplina de Análise & Projeto

Apresentações semelhantes

Apresentação em tema: "Disciplina de Análise & Projeto"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Disciplina de Análise & Projeto

Apresentações semelhantes

Apresentação em tema: "Disciplina de Análise & Projeto"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback