tudo são dados - php conference 2008

TUDO SÃO DADOS!

DIEGO THOMAZ FLÔRESwww.ecrayon.com.br

PHP Conference 2008

TUDO SÃO DADOSPHP Conference 2008

DIEGO THOMAZ FLÔRES

Analista e programador PHP há 6 anos, já desenvolveu projetos de médio e grande porte para clientes como o Ministério do Turismo, EMBRATUR, Fundação Getúlio Vargas - RJ, GMagazine, Telefonica e Agência Click.

Atua como Gerente de Projetos na Bolsoni Tecnologia & Turismo, desenvolvendo e coordenando os projetos Brasil.com.br e Boletim de Ocupação Hoteleira (EMBRATUR/FGV-RJ). É aluno do último ano do curso superior em Análise de Bancos de Dados no IBTA – São Paulo/SP.

Além disso, é responsável pela ECRAYON Tecnologia Criativa, estúdio de desenvolvimento de sistemas web-based.


ALGUNS CASES


AGENDA

Especificação de Requisitos

• Conceituação• Técnicas para captura de requisitos

Modelagem de Dados

• Conceituação• Projetando o Banco de dados• Normalização


“O modo mais provável do mundo ser destruído, como concorda a maioria dos especialistas, é através de um acidente. É ai que nós entramos. Somos profissionais de computação. Nós causamos acidentes.”

Nathaniel Borestein


Estudos mostram que 50% das falhas no setor industrial alemão são causadas por erros em software.

1977: Média de 7-20 defeitos por 1000 linhas de código1994: Média de 0,2-0,05 defeitos por 1000 linhas de código

A tolerância de um nível de defeito de 0,1% significa:

por ano: 20.000 medicamentos defeituosos300 falhas em marcapassos

por semana: 500 erros em operações médicas

por dia: 16.000 cartas perdidas nos correios18 quedas de aviões

por hora: 22.000 cheques descontados incorretamente


AS SETE QUESTÕES FUNDAMENTAIS PARA O PLANEJAMENTO DE SOFTWARE

1. Por que o sistema vai ser construído?

2. O que deve ser feito?

3. Como vai ser feito?

4. Quando vai ser feito?

5. Quem vai fazer? E quem são os responsáveis?

6. Onde se aplicam essas responsabilidades?

7. Quanto vai custar?


FASES DO PLANEJAMENTO DE SOFTWARE

Definição

Desenvolvimento

Manutenção

Análise do Sistema

Planejamento do projeto

Análise de Requisitos

Projeto de Software

Codificação

Realização de Testes

Correção

Adaptação

Expansão


FASE 1: DEFINIÇÃO ou ESPECIFICAÇÃO

Por quê?Identificação do problemaAnálise da situação atual

O quê?Definição conceitual de soluções

Como?Definição do escopo globalPlanejamento do projeto de softwareAnálise de riscos

Quando?Refinamento do escopoCronograma geralCronograma modular

Quem?Alocação de recursos

Onde?Definição de responsabilidades;Definição de ambientes de desenvolvimento, homologação e produção.

Quanto?Estimativa de custosCronograma específico


FASE 2: DESENVOLVIMENTO

Projeto de Software

Traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface.

Codificação

As representações do projeto devem ser convertidas numa linguagem artificial que resulte em instruções que possam ser executadas pelo computador.

Realização de Testes

Logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação.


FASE 3: MANUTENÇÃO

Correção

Mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software

Adaptação

Com o passar do tempo, o ambiente original para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente.

Expansão

À medida que o software é usado, o usuário reconhecerá funções adicionais que oferecerão benefícios.


MODELOS DE PROCESSO DE SOFTWARE

Consiste em uma série de atividades que garantem, técnica e administrativamente que o software pode ser desenvolvido de maneira organizada, disciplinada e previsível.

Um modelo de processo procura descrever formalmente e de maneira organizada todas as atividades que devem ser seguidas para a obtenção segura de um produto de software. É importante escolher um modelo apropriado às metas da organização e saber o grau em que esse modelo será implementado.

BENEFÍCIOS

• Estabelece uma linguagem comum;

• Constrói um conjunto de processos e procedimentos desenvolvidos com sugestões de uma ampla participação da comunidade de software;

• Oferece uma estrutura para se priorizar as ações.

RISCOS

• Não são suficientemente abrangentes;

• É necessário bom senso para se utilizar modelos corretamente e com visão.


MODELOS DE PROCESSOS DE SOFTWARE: LINEAR ou CASCATA

Engenharia de Engenharia de SistemasSistemas

Engenharia de Engenharia de SistemasSistemas

Análise de Análise de Requisitos Requisitos

Análise de Análise de Requisitos Requisitos

Projeto Projeto Projeto Projeto

Codificação Codificação Codificação Codificação

Testes Testes Testes Testes

Manutenção Manutenção Manutenção Manutenção


PROBLEMAS NA IMPLEMENTAÇÃO LINEAR ou CASCATA

Dificuldade em prever todos os detalhes de funcionamento e comunicação dos módulos logo no início do projeto;

O prazo de entrega do produto final é sempre maior, uma vez que a etapa seguinte só inicia quando a anterior estiver completamente finalizada;

Os custos do projeto aumentam devido à alocação desnecessária e ociosa de recursos, que ficam à espera das fases anteriores serem finalizadas para iniciarem suas atividades.


MODELOS DE PROCESSOS DE SOFTWARE: PROTOTIPAÇÃO

construa/reviseo protótipo

construa/reviseo protótipo

teste doprotótipo pelo

cliente

teste doprotótipo pelo

cliente

ouça o clienteouça o cliente


PROBLEMAS NA IMPLEMENTAÇÃO POR PROTOTIPAÇÃO

Cliente cria grande espectativa em cima do prótipo e na maioria das vezes não enxerga o mesmo como um modelo híbrido do produto final;

Desenvolvedor freqüentemente faz uma adaptação do modelo híbrido para o modelo final do produto, comprometendo a qualidade do código.


MODELOS DE PROCESSOS DE SOFTWARE: ESPIRAL

É um modelo iterativo, que integra as etapas características do desenvolvimento linear com a familiarização do cliente ao produto final, típicas da prototipação.

Nas primeiras iterações a versão incremental pode ser um modelo em papel ou um protótipo; nas iterações mais adiantadas são produzidas versões incrementais mais completas e melhoradas.

Dinamiza e facilita possíveis correções ou alterações de escopo a cada iteração, permitindo melhor execução e implementação do produto final sem comprometer o cronograma geral.

PlanejamentoAnálise de Risco

Engenharia

Construção e ReleaseAvaliação do Cliente

Adaptações


TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS

Entrevistas

É a técnica mais utilizada para captura de requisitos. A característica básica da entrevista é o diálogo entre o entrevistador e um entrevistado.

Questionários

Série de perguntas escritas para obter informações de indivíduos, usados quando há um grande número de pessoas de quem as informações e opiniões são necessárias. Também é muito utilizado para sistemas a serem implantados fora do cliente ou para sistemas com usuários espalhados em diversos locais.

JAD – Joint Application Design

Workshops de imersão, realizado em três etapas, onde reunem-se ao mesmo tempo usuários gerais, especializados, desenvolvedores e representantes do cliente.


ENTREVISTAS: boas práticas!

Apresente-se e deixe claro o seu objetivo; foco é essencial;

Garanta a confidencialidade das informações e anonimato das respostas;

Fique atento às emoções e expressões do entrevistado. Muitas informações são colhidas por meio de comunicação não-verbal;

Deixe o entrevistado à vontade, lembrando que uma ação provoca uma reação: ao se mostrar indiferente ao entrevistado, ele possivelmente desenvolverá uma reação de defesa, deixando de informar o que interessa;

Mantenha a imparcialidade durante as perguntas: é a opinião dele que interessa;

Encadeie os assuntos de forma lógica, criando ganchos na conversa que possibilitem a mudança de assunto;

Equilibre profundidade e superficialidade das perguntas.


QUESTIONÁRIOS: boas práticas!

Peça somente a informação que realmente pode ser fornecida;

Disponha as perguntas em uma seqüência lógica e defina suas prioridades;

Formule perguntas claras, evitando dupla interpretação;

Seja o mais breve possível: ninguém gosta de responder um questionário sem fim;

Informar na carta que acompanha o questionário o tempo estimado para o preenchimento;

Caso exista algum padrão com que se possa comparar as repostas obtidas, dê preferência a perguntas fechadas, oferecendo apenas as alternativas esperadas;

Evite abreviações, termos tendenciosos ou sugestivos;

Numere as perguntas para evitar confusão;

Ofereça anonimato aos entrevistados.


JAD: IMERSÃO E TRABALHO EM EQUIPE!

Existem três tipos básicos de reuniões de projeto:

sessões estratégicas, onde são discutidos o âmbito, objetivos, recursos, políticas e mudança organizacional;

sessões de dados e processos, onde se constrói ou aperfeiçoa os diagramas de fluxo de dados e modelos de dados;

sessões de telas e relatórios, onde se definem as entradas e saídas dos sistemas.


JAD – IMERSÃO E TRABALHO EM EQUIPE!

A metodologia está dividida basicamente em três partes:

1.Reunião inicialSão estabelecidos os principais objetivos do projeto e planejado o trabalho.

2.Reunião de revisãoÉ feita uma revisão relativa à reunião inicial, avaliada a situação das tarefas previstas e identificados os problemas e suas possíveis correções, buscando atingir a terceira etapa dentro dos prazos estabelecidos.

3.Sessão de designSão desenvolvidos os projetos de interface da aplicação enfocada.

A sessão de design é a reunião mais importante do processo. Dela devem participar todas as pessoas escolhidas na reunião inicial e confirmadas na reunião de revisão. Normalmente, a cada atividade da sessão, são atribuídos tempos previstos, procurando determinar a quantidade necessária de reuniões.


E o que a MODELAGEM DE DADOS tem a ver com tudo isso?

TUDO!Assim como para o desenvolvimento de sistemas de software, também para a modelagem de dados o fator mais importante é a interação entre a equipe técnica e o cliente.

Sem a compreensão do problema e do contexto onde ele está inserido e sem a compreensão das soluções propostas durante a especificação do sistema, todo o esforço até aqui pode ser desperdiçado por um modelo de dados ruim.


TUDO SÃO DADOS!

DADOS

São valores brutos, registros que são armazenados. Dados são estáticos, ou seja: eles permanecem da mesma forma do início ao fim de qualquer processo, a menos que sejam modificados por algum usuário ou funcionalidade da aplicação.

INFORMAÇÃO

É o dado dentro de um contexto onde ele faça sentido e ganhe significado. Um único dado pode representar inúmeras informações diferentes - tudo depende do contexto onde ele é apresentado e do público a quem ele será exibido.

AQUILO QUE PARA O SEU CLIENTE É INFORMAÇÃO,PARA VOCÊ SEMPRE SERÁ DADO!


ANÁLISE E MODELAGEM DE DADOS

O processo de análise e modelagem de dados tem por objetivo principal definir um modelo claro, conciso e equilibrado da realidade, sem qualquer influência dos meios computacionais que utilizaremos para resolver o problema.

Os dados gerados para ou pelo produto em desenvolvimento a fim de resolver determinado problema devem ser absolutamente independentes da tecnologia que será utilizada para interpretá-lo, fornecê-lo ou consumí-lo.

Construir o modelo de dados é um processo evolutivo e se modifica à medida que a realidade é conhecida.

Uma modelo de dados representa uma visão parcial da realidade do cliente ou produto. Cada visão da realidade tem vocabulário e regras definidas, que representam as próprias regras do negócio.


BENEFÍCIOS DA MODELAGEM DE DADOS

O Modelo nasce no mundo do Usuário e do Negócio e, portanto, fornece um ponto focal para discussões sobre o que é importante para o desenvolvimento do produto em questão.

As fases iniciais do processo são oportunidade real para os profissionais de Negócios se depararem com discussões sobre seus assuntos com profissionais de outras áreas, numa situação nova de compartilhamento de interesses e solução de conflitos;

As reuniões de planejamento levam a uma linguagem comum para o assunto tratado e normalmente a fluidez de comunicação entre os participantes melhora;

As fases iniciais estruturam meios de troca de uma grande quantidade de informação entre as áreas envolvidas, além de uma enorme transferência de conhecimento de Negócios para os profissionais de TI. As fases finais levam resíduos dessa transferência aos profissionais que irão implementar a solução;

Os participantes acabam percebendo melhor como suas atividades se acomodam em um contexto mais amplo. Com o passar do tempo, há ganho em valores e reforço no senso de cooperação.


BENEFÍCIOS DA MODELAGEM DE DADOS

Discussões sobre as funções que serão executadas pelo sistema sempre mostram novos requerimentos de dados; discussões sobre os dados e sua estrutura sempre mostram novos requerimentos funcionais.

Dessa forma, é importante desenvolver simultaneamente o Modelo de Dados e o Modelo Funcional.

Enquanto os Modelos Funcionais descrevem "como" os requisitos serão atendidos pelo sistema, os Modelos de Dados descrevem "o quê" será atendido e "por quem".


MODELO DE PROCESSOS DE MODELAGEM DE DADOS

ENTIDADESTABLES

CHAVESPRIMARY KEY, FOREIGN KEYS,

INDEXES

ATRIBUTOSCOLUMN

TRANSFORMAÇÃOSQL DUMP

ESCOPO

MO

DELO

LÓG

ICO

FÍSIC

O


MODELO DE PROCESSOS DE MODELAGEM DE DADOS

NÍVEL 1: ENTIDADES

Identificam-se os principais atores do Modelo de Dados.

NÍVEL 2: CHAVES

Para cada entidade identificada, definem-se seus chaves de identificação e os relacionamentos entre elas. A partir desses relacionamentos, e com a especificação correta das cardinalidades entre eles, é que as regras de negócio são implementadas no Modelo de Dados.

NÍVEL 3: ATRIBUTOS

Pode ser dividido em dois sub-níveis: detalhamento e normalização. No primeiro, todas as estidades são qualificadas e descritas em detalhes; no segundo, os atributos são levados da 1ª à 3ª Forma Normal, garantindo a consistência do Modelo em questão.


CARDINALIDADE

É a regra do Modelo de Dados que estabelece quantas vezes um registro da entidade-pai poderá se relacionar com um único registro da entidade-filha. Esses relacionamento são chamados FOREIGN KEYS.

As cardinalidades possíveis de implementação são:

• UM para ZERO, UM ou mais;• UM para UM ou mais;• UM para ZERO ou UM;• ZERO para ZERO, UM ou mais;• ZERO para UM ou mais;• ZERO para ZERO ou UM.


EXEMPLO DE MODELO DE DADOS COMPLETO


REGRAS PARA A MODELAGEM DE DADOS: ENTIDADES

Unicidade e não nulificação das chaves primárias

Chaves primárias são os identificadores únicos de cada registro. Podem ser compostas por quantos atributos forem necessários para garantir a unicidade de identificação, sem, porém, conter valores nulos nos elementos que a compõe.

Processos

Define quais eventos e como os processos de negócio acessam, modificam, excluem e incluem as ocorrências das entidades. A partir dessas regras, em conjunto às Regras do Negócio, são definidas as estruturas de functions e stored procedures do Modelo de Dados.

Estado e Transição de Estado

Define os estados possíveis de serem assumidos pela entidade, aumentando o entendimento sobre a dinâmica de seu mecanismo. Define também as causas que motivam as mudanças de estado das entidades, permitindo identificar eventos temporais e mecanismos disparadores associados (triggers).


REGRAS PARA A MODELAGEM DE DADOS: RELACIONAMENTOS

Também chamada de “Integridade Referencial”, define o comportamento das entidades em relação as operações de inclusão, deleção e modificação nas entidades relacionadas. São opções de configuração para as regras de relacionamento:

CASCADE; RESTRICT; SET NULL; SET DEFAULT; NONE.


REGRAS PARA A MODELAGEM DE DADOS: ATRIBUTOS

Nomenclatura

O nome do atributo deve ser claro e suficientemente descritivo a fim de retratar a semântica de seu conteúdo.

Hierarquia e filiação

Os atributos devem ser definidos de forma coesa, pertencendo a uma ou mais entidades, dependendo da sua função (identificação, relacionamento ou qualificação).

Formatação e validação

Os atributos devem ser definidos dentro do conceito de domínio, onde são explicitados o seu formato, regras de derivação, validação e manipulação, valores iniciais, formatação e apresentação.


REGRAS PARA A MODELAGEM DE DADOS: DERIVAÇÃO

Definem os meios de obtenção de um registro. A partir delas é possível obter um dado a partir de outros dados, seus relacionamentos, domínios e máscaras.

Registros simples são obtidos de maneira direta em sua entidade de origem;

Registros complexos geralmente têm suas regras de derivação compostas por combinações de fórmulas de cálculo e lógicas de associação.


REGRAS PARA A MODELAGEM DE DADOS: NEGÓCIOS

São regras específicas que uma empresa estabelece para funcionamento do seu negócio. Objetivamente, estabelecem as regras validação das entidade identificadas, seus atributos e relacionamentos.

Além disso, são as regras de negócio que definem e especificam as interrelações do Modelo de Dados com a Aplicação, assim como da Aplicação com o Usuário.

Regras de Negócios bem definidas auxiliam ainda na interpretação semântica da aplicação e do banco de dados e seus componentes lógicos (classes, triggers, functions, stored procedures, etc.), garantindo melhores perspectivas para futuro reaproveitamento e encapsulamento de procedimentos comuns.


INTEGRIDADE REFERENCIAL

Uma vez que um banco relacional se apóia em entidades e seus atributos para implementar relacionamentos (FOREIGN KEY), a integridade dos dados nos atributos chave (PRIMARY KEY) é fundamental.

Após a definição das entidades e seus relacionamentos, o passo mais importante do processo é definir a regra de propagação destes. Para cada um deles é necessário definir qual ação deve ser tomada em caso de inserção, alteração ou deleção do registro pai.

O slide a seguir define cada uma das configurações possíveis para a propagação de alterações nas PRIMARY KEYS .


CASCADESempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha sofre a mesma ação, por cascata.

RESTRICTModificações na entidade-pai são proibidas caso existam instâncias de relacionamento em qualquer entidade-filha.

SET NULLSempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor NULL.

SET DEFAULTSempre que um registro da entidade-pai modificado, todas as instâncias de relacionamento com uma entidade-filha recebem o valor padrão definido para aquele atributo.

NONEIndependente da modificação na entidade-pai, nenhuma ação é realizada no registro da entidade-filha.


NORMALIZAÇÃO DO MODELO DE DADOS

É o conjunto de regras que objetiva o maior refinamento possível do Modelo de Dados inicial, garantindo que o resultado final não contenha qualquer redundância lógica.

Importante: um Modelo de Dados completamente normalizado não leva em conta considerações de performance, nem o SGBD onde o sistema será implementado. Durante o desenvolvimento do projeto, a análise de performance poderá provocar modificações do modelo canônico.


NORMALIZAÇÃO DO MODELO DE DADOS: 1ª FORMA NORMAL

1. Identificar todos os grupos repetitivos;

2. Atomizar os grupos repetitivos a partir do estabelecimento de dependências funcionais entre as entidades.



1. Aplicar a 1ª FORMAL NORMAL em sua totalidade;

2. Eliminar dependências parciais entre os atributos e a chave primária.



1. Aplicar a 2ª FORMAL NORMAL em sua totalidade;

2. Garantir a dependência exclusiva entre os atributos e a totalidade da chave primária.


MODELAGEM DE DADOS: boas práticas!

Em modelagem de dados em particular, assim como em desenvolvimento de sistemas em geral, é extremamente importante adotar e seguir padrões de nomenclatura de objetos. O dispêndio de tempo e esforço com esta preocupação rende um modelo conciso, claro e sem ambiguidades.

Definir as entidades de um modelo é mais do que criar sua estrutura, escolher chaves e criar relacionamentos. É preciso também criar informação que sirva para documentar a função da existência daquela entidade.

Assim como nas entidades, a definição de atributos deve ser feita de maneira clara, e valem as mesmas regras. Assim, as definições de atributos também pedem a mesma coisa: descrição, exemplo e comentários. Além disso, as definições devem ter, sempre que possível, regras de validação.


LEIS DE CONSISTÊNCIA DE DADOS

1. As tabelas componentes do modelo estarão na 3ªFN.

Se o modelo for desnormalizado posteriormente, controles procedurais adicionais deverão ser incluídos e documentados.

2. Não existirão duas tabelas com a mesma chave.

Se aparecerem, elas devem ser agrupadas e re-normalizadas

3. Se Y é um subconjunto da chave de uma tabela T1 e tem sentido isoladamente, deve existir uma segunda tabela T2 tendo Y como chave;

4. Se X, um atributo simples ou composto, é chave de uma tabela T1, ele é chamado atributo primário.

Nesse caso ele pode aparecer em outras tabelas, onde é chamado de chave estrangeira. Se X não é chave de nenhuma tabela, ele é um atributo secundário ou não primário e só pode aparecer em uma única tabela.


LEIS DE CONSISTÊNCIA DE DADOS

5. Se X, atributo simples ou composto, é chave de uma tabela T1 e aparece como atributo em uma outra tabela T2, existe uma relação hierárquica subordinando T2 a T1 segundo X;

6. Se X , atributo simples ou composto, é chave de uma tabela T1 e Y, um atributo cujo domínio é o mesmo de X, aparece em uma tabela T2, então:

a) Y não pode isoladamente ser chave de T2;b) Existe uma relação hierárquica subordinando T2 a T1, segundo T1.X <=> T2.Y


OBRIGADO PELA PRESENÇA!

DIEGO THOMAZ [email protected]

www.ecrayon.com.br

tudo são dados - php conference 2008

Technology