O D.F.D é uma técnica usada na programação estruturada de diagramação de software que possui diversos tipos de diagramas, derivando-se em outros diagramas subsequentes.
Podemos ter diversos níveis de D.F.D de forma a representar o fluxo de dados da aplicação.
D.F.D nível 0 - Apresenta uma visão clara do produto com todos os macro-processos, com entidades externas, fluxo de dados e depósito de dados principais.
D.F.D nivel 1 - È uma expansão do nível zero com mais detalhes e mais completo incluindo o tratamento de exceções.
Simbologias usadas na representação D.F.D:
- Entidades Externas
São categorias lógicas de objetos ou pessoas que representam Origem ou destino de dados, e, que acionam um sistema e/ou recebem informações
- Fluxo de dados
São o Meio por onde os dados e as informações trafegam;
- Processos
Transformam fluxos de dados em uma atividade;
Depósito de Dados
São locais de armazenamento de dados (arquivos físicos);
Sugestão para as etapas de elaboração de um D.F.D:
Identificar e descrever os requisitos funcionais;
Identificar entidades externas(EE);
Associar o fluxo de dados que as entidades enviam, consomem ou recebem;
Identificar consultas
Como desenhar o primeiro DFD??
Iniciar no canto esquerdo com a entidade externa principal;
procurar deixar todas as entidades externas nos cantos;
na esquerda as EE de Origem e na direita as EE de Destino;
desenhe fluxos que surgem, processo e depósitos de dados;
verificar se todas as entradas e saídas foram incluídas;
A sigla significa Modelo Entidade-Relacionamento e tem o objetivo de representar as estruturas de dados da forma mais próxima do mundo real dos negócios.Usa -se o DER (Diagrama entidade -relacionamento).
Existem três conceitos no MER: Entidade, Atributo e Relacionamento.
Entende-se que Entidade são objetos do mundo real, as características dos objetos são os Atributos, e a relação entre os objetos são os relacionamentos.
ou seja :
Entidade => Serve tanto para depósito quanto para recuperação de dados. Ela representa substantivos, concretos ou abstratos. Atributo => Sãocaracterísticas que informam sobre a entidade. Relacionamento => é a interação entre os objetos que indicam a dinâmica dos negócios.
Os Relacionamentos são identificados por verbos porque representam as ações que uma entidade exerce sobre outra.
Diagrama Entidade-Relacionamento (DER)
O Diagrama Entidade-Relacionamento descreve toda estrutura lógica do banco de dados. É possível construí-lo a partir de um MER, identificando assim a partir de um conceito do mundo real como os dados serão armazenados de fato.
DER tem como ênfase os dados e os relacionamentos. Sua representação utiliza os símbolos:
Retângulos - representam as entidades;
Elipses - representam os atributos;
Losangos - representam os relacionamentos entre as entidades;
Linhas - unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de relacionamentos
CARDINALIDADE MÁXIMA
Duas cardinalidades máximas são relevantes:
- A cardinalidade máxima 1
- A cardinalidade máxima “muitos” representada representada pela letra N
CARDINALIDADE MÍNIMA
A cardinalidade mínima é anotada junto a cardinalidade máxima.
Especifica se a participação de todas as ocorrências das entidades no relacionamento éobrigatória ou opcional.
Em um projeto de BD é usadas somente duas cardinalidades mínimas são elas:
Cardinalidade mínima 0 => recebe a denominação de associação OPCIONAL;
Cardinalidade mínima 1 => recebe a denominação de associação OBRIGATÓRIA;
Hoje, é considerado errado ter um processo que gere um "big bang!", não se deve ter o software inteiro funcionando por inteiro no primeiro release, o risco é grande demais! Um processo de desenvolvimento deve ser:
Iterativo (ter várias iterações no tempo)
Incremental (gerar novas versões incrementadas a cada release)
Uma iteração dura entre 2 semanas e 2 meses: Motivos:
Sempre tem algo para entregar para o cliente apressado (a última iteração)
Os requisitos mudam com tempo e um processo iterativo mantém freqüentes contatos com o cliente o que ajuda a manter os requisitos sincronizados
Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
O que é feito a cada iteração?
Análise (refinamento de requisitos, refinamento do modelo conceitual)
Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
Implementação (codificação e testes)
Transição para produto (documentação, instalação, ...)
A análise
A análise gera um modelo paraentendero domínio do problema, e também trata em alto nível de como uma solução possível pode ser montada para atender aos requisitos . Acaba gerando uma especificação, mas sempre do ponto de vista do usuário e tratando apenas do domínio do problema.
Não trata de detalhes de implementação
Objetos tratados são sempre do domínio do problema (business objects) , muitos diagramas UML podem ser usados.
O modelo é para o cliente e não para o programador.
Atividades típicas durante a análise: Refinar use cases
Refinar modelo conceitual
Refinar glossário
Definir diagramas de seqüência (opcional)
Definir contratos de operação (opcional)
Definir diagramas de estado (opcional)
O projeto (design)
O projeto é uma extensão do modelo de análise visando sua implementação num computador. Novos objetos aparecem, mas não são do domínio do problema,O resultado é para o programador ver, não o cliente Objetos da análise são (geralmente) mantidos e são embutidos numa infra-estrutura técnica.
As classes técnicas ajudam os business objects a:
Serem persistentes
Se comunicarem
Se apresentarem na interface do usuário
Terem desempenho aceitável (usando caches ou threads, por exemplo)
As atividades de projeto incluem:
Fase de refinamento da arquitetura (high-level design)
Definição de pacotes (módulos), interfaces entre pacotes
Decisão sobre uso/criação de bibliotecas e/ou componentes
Priorizar a funcionalidade e distribuí-la entre as iterações
Planejamento, definição de requisitos, construção de protótipos
Construçãodo sistema (inclui codificação e testes)
Implantação(colocar em produção, treinar usuários, ...)
Detalhes sobre o levantamento de requisitos
Requisitos são "cortes" no espaço de solução
Entendimento do que o usuário quer
O resultado é uma promessa para o cliente
Não só requisitos funcionais, mas também:
Facilidade de uso necessária
Quem utilizará o produto
Hardware e software alvo para o produto
Qualidade/robustez
Desempenho
Segurança
Compatibilidade com outros produtos/versões e necessidades de migração
Necessidades de internacionalização do produto
Suporte
Preço da solução
Documentação necessária
Uso de padrões
Aspectos legais
Integração com outros produtos
etc.
Não se fala "como" as coisas serão feitas, "Use cases" descrevem cenários de funcionalidade desejada.Também chamados de "User Stories", pois é o usuário que decide o que deve ser feito.
Este processo basicamente consiste em identificar e detalhar o que deve ser feito do ponto de vista de negócios e recursos em um determinado sistema. Pode-se entender requisito como “uma coisa que o sistema deve fazer”.
Na etapa de levantamento de requisitos, o time de desenvolvimento se prende em entender o negócio que o sistema vai automatizar, esse levantamento compreende explorar as necessidades dos usuários. No caso de um sistema já existir, a dica é não se prender a estrutura antiga, e partir logo para um sistema novo,pois tempo gasto até entender o sistema antigo pode ser muito valioso depois no projeto.mas sempre começando o novo híbrido, ou seja fazendo parte do antigo.
Requisitos Funcionais Os requisitos funcionais abordam O QUE o sistema deve fazer. "Descreve as funções que o sistema deve executar" Exemplos: 1. O sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou. 2. O sistema deve permitir que o aluno realize a sua matrícula nas disciplinas oferecidas em um semestre.
Requisitos Não-Funcionais Esses requisitos declaram características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades. Temos algumas divisões dentro desse tipo de requisitos.
Confiabilidade => Nada mais do que medidas quantitativas da confiabilidade do sistema, como por exemplo, o tempo médio entre falhas, recuperação de falhas, erros por milhares de linhas de código.
Portabilidade => Aqui tratamos da facilidade de migrar o sistema para outras plataformas. Que devemos dar uma atenção, para que o sistema rode em qualquer lugar.
Segurança => Aqui são descritas as particularidades sobre acessos ao sistema, segurança extra em login, restringir acesso de algumas pessoas, entre outros.
Usabilidade => Aqui são descritos os requisitos que se relacionam ou afetam a usabilidade do sistema. Coisas relacionadas à facilidade de uso, sobre a necessidade de treinamentos para os usuários.
Documentos de Requisitos
Como resultado do processo de levantamento de requisitosé desenvolvido o documento de requisitos do sistema. Este documento contém a especificação de todos os requisitos funcionais e não funcionais do software, incluindo as capacidades do produto, os recursos disponíveis, os benefícios e os critérios de aceitação.
Nos deparamos com várias metodologias para o desenvolvimento de um projeto, mas temos os modelos de desenvolvimento, que são a idéia inicial de como vai ser tal software . Os modelos de desenvolvimento é dividido em partes principais, o desenvolvimento em Cascata, e o Iterativo e Incremental.
O desenvolvimento em cascata é o mais tradicional , por parecer ser mais simples e organizado, porém durante o desenvolvimento do projeto pode ocorrer inúmeras falhas decorrentes desse modelo Cascata, por isso veio os métodos Iterativo e Incremental, com a ideia de substituir o modelo Cascata e acabar com as suas falhas, mas como nada é perfeito eles também tem as suas falhas, mas vamos conhecer um pouco de cada e entender qual pode ser a melhor opção na hora de desenvolver um software.
O Modelo Cascata
Ou (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são:
Estudo de viabilidade -> Análise e especificação de requisitos -> Design da arquitetura -> Design detalhado->
Codificação e testes de unidades -> Integração e teste do sistema -> Entrega e instalação -> Manutenção
Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização.
Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software.
Quais as vantagens e desvantagens do modelo cascata??
Vantagens Torna o processo de desenvolvimento estruturado; Tem uma ordem sequencial de fases; Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte; Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; Esta abordagem é atualmente a norma e provavelmente permanecerá como tal nos próximos tempos;
Desvantagens Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores; Não suporta modificações nos requisitos; Não prevê a manutenção; Não permite a reutilização; É excessivamente sincronizado; Se ocorrer um atraso todo o processo é afetado; Faz aparecer o software muito tarde;
Entender qual o papel da análise orientada a objetos dentro do processo de desenvolvimento de software, visando a identificação de informações necessárias às decisões de projeto e modelagem de um sistema.
Em que situação é útil:
Identificação de informações que apoiam as atividades de modelagem, análise e projeto de sistemas de software.
Como nós todos ansiamos , precisaremos participar de algumas decisões de projeto, como selecionar a técnica de análise e modelagem, linguagem de programação e ambiente de desenvolvimento adequados.
É importante refletir sobre a ordem em que suas atividades são executadas. Por exemplo, antes de escolher uma linguagem de programação e ambiente de desenvolvimento, devemos definir a estratégia de análise e modelagem de sistemas.
Entretanto,sabe-se que os sistemas de software encontram-se, quase permanentemente, sendo modificados. Essas mudanças ocorrem devido à necessidade de corrigir erros existentes no software ou de adicionar novos recursos e funcionalidades.
Em razão disto, você pode questionar: Por que modelar um sistema? Porque à medida que o sistema cresce, também cresce o código, tornando mais difícil seu desenvolvimento e mais ainda sua manutenção. É mais fácil raciocinar e fazer a manutenção em um sistema para o qual você tem um modelo. Para tanto, a modelagem é essencial no desenvolvimento de qualquer sistema. A análise orientada a objetos serve para ajudar no entendimento e decisões de projeto .
A imagem abaixo representa os diversos tipos de diagramas que podem ser elaborados durante todo o desenvolvimento do sistema:
Antes de iniciar a modelagem com uma linguagem como a UML, você deve proceder a análise orientada a objetos, que compreende os seguintes passos:
Entender o problema do cliente e identificar e documentar os requisitos;
Descrever os requisitos funcionais usando diagramas de casos de uso da UML;
Identificar objetos e classes a partir das informações no documento de requisitos, descrição do sistema e especificação de casos de uso;
Identificar relacionamentos entre as classes ;
Identificar atributos e operações ;
Elaborar e analisar os diagramas de classes de sistema, adicionando e/ou corrigindo atributos e operações, bem como revisando os relacionamentos identificados.
"O primeiro passo, a partir do momento em que você já fez o levantamento de requisitos junto ao cliente, é identificar objetos e classes. Nesse momento, você é o projetista e, portanto, deve examinar a declaração do problema procurando identificar objetos."
