TRIBUNAL DE JUSTIÇA DE PERNAMBUCO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO...

TRIBUNAL DE JUSTIÇA DE PERNAMBUCOTRIBUNAL DE JUSTIÇA DE PERNAMBUCO

SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃOSECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO

Disciplina de Análise & ProjetoDisciplina de Análise & Projeto

PROSOFTPROSOFT

Fevereiro/ 2011

TJPE.SETIC.AGTIC.NGP

Disciplina de Análise e ProjetoAgenda 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


Disciplina de Análise e Projeto Análise e Projeto

5 atividades

Visão Geral

3


Disciplina de Análise e ProjetoVisão Geral

Análise e Projeto 4 papéis

• Projetista• Analista De Negócios /

Sistema• Arquiteto de Software• Administrador de

Dados

4



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


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





6


Disciplina de Análise e ProjetoRUPRUP

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;

7



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.

8



É 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

9


Disciplina de Análise e ProjetoRUP - CaracterísticasRUP - Características

Iterativo e Incremental 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

10


Disciplina de Análise e ProjetoRUP - CaracterísticasRUP - Características

Centrado na arquitetura 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

11


Disciplina de Análise e ProjetoRUP – Príncipios FundamentaisRUP – 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

12


Disciplina de Análise e ProjetoRUP - RUP -

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

13

RUP – Príncipios FundamentaisRUP – Príncipios Fundamentais


Disciplina de Análise e ProjetoRUP - Gráfico das BaleiasRUP - Gráfico das Baleias

14


Disciplina de Análise e ProjetoRUP - DimensõesRUP - Dimensões

Eixo horizontal 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...

15


Disciplina de Análise e ProjetoRUP - ComponentesRUP - Componentes

16

Metodologia

Modelos, Padrões e GuiasCMMI

MPS.BR

PMBOK

Equipes Treinadas

FerramentasRational

JUDE

ERWin

Linguagem Padrão

Processo de Desenvolvimento Conjunto de métodos e práticas

bem definidas Com responsáveis Entradas/Saídas Ordem de precedência


Disciplina de Análise e ProjetoRUP - FasesRUP - Fases

Cada fase termina com um marco

17

Concepçã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


Disciplina de Análise e ProjetoRUP - IteraçõesRUP - Iterações

Cada passagem pela sequência de disciplinas do projeto se chama iteração

18


Disciplina de Análise e ProjetoRUP – Fases e IteraçõesRUP – Fases e Iterações

Cada fase pode ser dividida em iterações

19


Disciplina de Análise e ProjetoRUP - DisciplinasRUP - Disciplinas

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

20


Disciplina de Análise e ProjetoRUP - DisciplinasRUP - Disciplinas

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

21


Disciplina de Análise e ProjetoRUP – Análise e DesignRUP – 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

22


Disciplina de Análise e ProjetoRUP – Visões ArquiteturaisRUP – 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

23


Disciplina de Análise e ProjetoRUP - VisõesRUP - Visões

24


Disciplina de Análise e ProjetoRUP – Visão de Casos de UsoRUP – 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

25


Disciplina de Análise e ProjetoRUP – Visão LógicaRUP – 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

26


Disciplina de Análise e ProjetoRUP – Visão de ImplementaçãoRUP – 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)

27


Disciplina de Análise e ProjetoRUP – Visão de ProcessosRUP – 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

28


Disciplina de Análise e ProjetoRUP – Visão de ImplantaçãoRUP – 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

29



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 Uso30



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

31


Disciplina de Análise e ProjetoUMLUML

32


Disciplina de Análise e ProjetoUML – Unified Modeling LanguageUML – 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 - www.omg.org

33


Disciplina de Análise e ProjetoUML – O que é?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)

34


Disciplina de Análise e ProjetoUML 2.2 - DiagramasUML 2.2 - Diagramas

35



Diagramas estruturais 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

36



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)

37



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

38


Disciplina de Análise e ProjetoUML – Diagrama De ClassesUML – 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

39


Disciplina de Análise e ProjetoUML – Estrutura da ClasseUML – Estrutura da Classe

40

Atributos

Nome da Classe

Operações


Disciplina de Análise e ProjetoUML – Estrutura da Classe UML – Estrutura da Classe

41

Nome Nome + Atributos

Nome + Atributos + Operações

Três Formas de Apresentação


Disciplina de Análise e ProjetoUML – Estágios do Modelo de ClassesUML – 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

42


Disciplina de Análise e ProjetoUML – Modelo de Classe de AnáliseUML – Modelo de Classe de Análise

43


Disciplina de Análise e ProjetoUML – Estágios do Modelo de ClassesUML – 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.)

44


Disciplina de Análise e ProjetoUML – Modelo de Classe de ProjetoUML – Modelo de Classe de Projeto

45


Disciplina de Análise e ProjetoUML – Diagrama de SequênciaUML – 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)

46



47



48


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





49







50


Disciplina de Análise e ProjetoAnalisar Impacto

Papéis 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


Disciplina de Análise e Projeto

Saídas Solicitação do Mantis Atualizada

Etapas 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.

Analisar Impacto







59


Disciplina de Análise e ProjetoDefinir 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



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

61



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



Desenvolver a Visão Geral da Arquitetura

63

A p resen ta çã o – JS F , F a ce le ts , X H T M L , A ja x , C S S

N eg ó c io – E JB 3 .0

In teg ra çã o – JP A , W eb S erv ices

R ecu rso s – S G B D s, S is tem a d e A rq u ivo s



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



Identificar Abstrações-Chave (Entidades)

65



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



Criar Realizações dos Casos de Uso Arquiteturalmente Significativos

67



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



Projetar Interfaces Externas (Opcional)

69

Web ServiceWeb Service

BD

Web ServiceClient

Web ServiceClient

Antecedentes Web Cliente

Antecedentes Web Cliente

Antecedentes Web Admin

Antecedentes Web Admin

Sistemas Internos

Sistemas InternosXML/SOAP



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.

70







71


Disciplina de Análise e ProjetoDefinir 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



Saídas 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



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



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







76


Disciplina de Análise e ProjetoProjetar 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.







82



83


Disciplina de Análise e ProjetoProjetar 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


Disciplina de Análise e ProjetoConceitos

Atividades Projetar Modelo de Dados

Conceitos básicos de modelagem de dados

87



Projeto de Banco de DadosProjeto 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 DadosProjeto de Banco de Dados

Análise derequisitos

Construçãodo modeloConceitual

Construçãodo modelofísico

necessidades de informação

modelo de dadosda empresa

características hw/so

necessidades de processamento

características do SGBD

especificaçãode requisitos

estruturaConceitual

da informação estruturalógica dos

dados eaplicações

estruturafísica dosdados

Construçãodo modelológico



Modelo Entidade-Relacionamento – M.E.R.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.

Mundo real

modelo

Representação emcomputadores




• 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

Supervisão

supervisionadosupervisor

1 n

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

Processo

Conta Corrente

Designa o conjunto de todos os empregados sobre as quais se deseja manter informações no banco de dados



M.E.R. - ENTIDADEM.E.R. - ENTIDADE

Entidade: EMPREGADODescrição: Pessoa que mantém vínculoempregatício com a Empresa através deum contrato de trabalho de acordo com alegislação trabalhista

Entidade: ENCOMENDADescrição: Instrumento contratual deemissão unilateral pela empresa eaceitação, expressa ou tácita, pelofornecedor do material.

Entidades devem ser descritas num

Dicionário de Dados



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, Email, Telefone.

M.E.R. - ATRIBUTOS

Cada atributo possui um domínio que identifica o conjunto de valores permitidos para aquele atributo.



Atributos devem também ser descritos no Dicionário de Dados:

Entidade: EMPREGADOAtributo: Data de AdmissãoDescrição: data na qual foi assinado ocontrato de trabalho entre a empresa e oempregadoDomínio: data posterior a 03/01/78 (data decriação da empresa) e a data de nascimentodo empregado

M.E.R. - ATRIBUTOS



–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”

M.E.R. - RELACIONAMENTOS

Representado graficamente por um losango

Empregado Projetotrabalha

matricula

nome

salário horas

1..N

1..N



M.E.R. – RELACIONAMENTOS - Exemplo

Pessoa DepartamentoLotação

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).



Quando nos referirmos a associações particulares dentro de um conjunto, vamos nos referir a ocorrências ou instâncias de relacionamentos:

oNo 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.

p1p2

p4

p3 p7

p6p5

p8

p1d1 p2d1 p4d2 p5d3

d1 d2 d3

M.E.R. - RELACIONAMENTOS



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).

JoãoLuiz

MariaAfonso

JoséPedro

A

B

C

PESSOA DEPARTAMENTO



M.E.R. - Especialização

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:

Processo Partenn

PessoaFísica

PessoaJurídica

código

nome

NomeMãe

CNPJ InscriçãoEstadual

possui

CPF

superclasse

subclasses



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

Cor

OU

Automóvel

Cor

1

n

?




Dúvida frequente: quando um objeto é um Atributo ou

Especialização?

Empregado

nome

códigocategoriafuncional

Empregado

OU

? Motorista Engenheiro

habilitação

data_validade_hab

CREA

códigonome




Dúvida frequente: Atributo Multivalorado ou Entidades/Relacionamentos?

Empregado

nome

código

Dependente*

Empregado

Dependente

nome data de nascimento

nome

código

E telefone E telefone ??



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.


Disciplina de Análise e ProjetoVerificação do modelo ER

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:

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.


Disciplina de Análise e ProjetoVerificação do modelo ER

Departamento lotação Empregado

número de empregados nome do departamento

nome

Atributos redundantes

código




Cliente

DVD

locação

n

1

Cliente

DVD

locação

n

n

data

O modelo reflete o aspecto temporal:

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..


Disciplina de Análise e ProjetoModelo 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.



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

Domínio Conjunto de valores válidos

Modelo Relacional



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

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

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

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

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)

Chaves


Disciplina de Análise e ProjetoModelo Relacional

Chave PrimáriaColuna ou combinação de colunas

cujos valores distinguem uma linha das demais dentro de uma tabela.

Chave Primária

Tabela: Alunos

Matricula Nome Fone

12345 Gilberto 6481

12346 Sandra 6444

12347 Isabela 6333

12349 Jonas 6481


Disciplina de Análise e ProjetoModelo RelacionalRequisitos:

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.



Chave Estrangeira

MATRICULA NOME CURSOID

98765 João MAT

67765 José BIO

84562 Maria ENG

34256 Luis INFO

3452672 Ana MAT

34529 Luana MAT

CURSOID TITULO DURAÇÃO

INFO Informática Indust. 4

BIO Biologia 4

ENG Engenharia Civil 5

MAT Licenciatura Mat. 4

Curso

AlunoObs.: Através do relacionamento, evitamos a repetição de informações.

Relacionamento

Modelo Relacional



Chave EstrangeiraObservaçõ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).

Modelo Relacional



Chave Estrangeira 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.

Modelo Relacional



Modelo Relacional

Chave Estrangeira 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


Disciplina de Análise e ProjetoRestriçõ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 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).

Restrições de Integridade



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:

1. 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

nomeendereço

data de nascimento

código

Cliente (CodigoCli, Nome, Endereco, DataNasc)




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



Disciplina de Análise e Projeto 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

Normalização - Introdução


Disciplina de Análise e ProjetoSe 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.



Disciplina de Análise e Projeto 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 (C2C1)

EX: Empregado (CodEmp, Nome,DtNasc,Categoria,Salario)• CodEmpNome

• CodEmpDtNasc

• CodEmpCategoria

• CodEmpSalario

• CodEmp(Nome,Categoria,Salario)

Normalização/Teoria das Dependências


Disciplina de Análise e Projeto 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)

Normalização


Disciplina de Análise e Projeto 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)




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)

Normalização


Disciplina de Análise e Projeto 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.




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)

Normalização


Disciplina de Análise e ProjetoArtefatos e Ferramentas Visão geral da disciplina de Análise e Projeto Conceitos Básicos Fundamentais





145


Disciplina de Análise e ProjetoArtefatos e FerramentasArtefatos e Ferramentas

Ferramentas Modelagem de Dados

• Indefinido (ERWin, DBDesigner, Visio, PowerDesigner, etc…) Acesso ao SGBD

• Oracle : SQLDeveloper• Sybase : SQLDBx

Modelagem de Sistemas• UML : JUDE

146


Disciplina de Análise e ProjetoArtefatos e FerramentasArtefatos e Ferramentas

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


Disciplina de Análise e ProjetoConsiderações Finais Visão geral da disciplina de Análise e Projeto Conceitos Básicos Fundamentais





148


Disciplina de Análise e ProjetoDúvidas | Sugestões

149

Núcleo de Gestão de Processos de TIC : [email protected] Unid. de Eng. de SW - Componentes e Servicos : [email protected] Unidade de Arquitetura de Dados : [email protected] Unidade de Arquitetura de SW : [email protected] Mantis: “Processo de Software”

TRIBUNAL DE JUSTIÇA DE PERNAMBUCO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO...

Documents

Transcript of TRIBUNAL DE JUSTIÇA DE PERNAMBUCO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO...