apostila de AS - NOVA 2

Prévia do material em texto

AS – Análise de Sistemas		1
1. Conceito de Engenharia de Sistemas	3
2. Conceito de Análise de Sistema Estruturado	3
3.Estudo de viabilidade de um sistema de Informação	5
Viabilidade Organizacional	5
Viabilidade Técnica	5
Viabilidade Operacional	5
Viabilidade Econômica	5
Recursos tangíveis e intangíveis	5
4.Requisitos de um sistema de informação.	6
Quando usar:	11
O que gerar como protótipo?	11
Desvantagens	11
5 - MODELAGEM DE SISTEMAS DE INFORMAÇÃO	12
Ferramentas para Análise de Sistemas: DFD	17
DFD – Diagrama de Fluxo de Dados	17
Símbolos do DFD	18
Sintaxe do DFD	20
Dicionário de Dados	26
COMO DESCREVER FLUXOS DE DADOS	27
COMO DESCREVER DEPÓSITO DE DADOS	28
COMO DESCREVER PROCESSOS	28
RESOLUÇÃO DE EXERCÍCIOS	29
Exercícios variados	31
1 - Leia a descrição do caso Autopeças KW e elabore o levantamento de requisitos Funcionais e Não-funcionais	31
2 - Caso da Biblioteca Virtual	32
3 - Estudo de Caso: Supermercado ABC	33
1. Conceito de Engenharia de Sistemas 
A engenharia de sistemas é uma cadeira universitária que se encarrega do design (concepção), da programação, da implementação e da manutenção de sistemas. Ao contrário de outros ramos da engenharia, esta área não trata de produtos tangíveis (os engenheiros civis, por exemplo, constroem edifícios), mas sim de produtos lógicos.
Como tal, a engenharia de sistemas implica o uso de noções matemáticas que permitam concretizar a aplicação tecnológica das teorias dos sistemas. Trata-se de uma ciência interdisciplinar, que requer diversos conhecimentos para expor (ou retratar) os seus desenhos/projetos na vida prática.
A engenharia de sistemas permite transformar uma necessidade operativa numa descrição dos parâmetros do desempenho de um sistema, com a sua configuração correspondente. Por outro lado, possibilita a integração dos parâmetros técnicos relacionados de tal modo que as interfaces de programa e funcionais sejam compatíveis e seja garantido o funcionamento do sistema total.
Ao realizar o seu trabalho, o especialista desta área deve garantir que o sistema obedeça aos princípios de viabilidade, manutenção, segurança e eficiência, entre outros.
O engenheiro de sistemas encarrega-se das diferentes etapas de um projeto relacionado com os sistemas. Nesse sentido, analisa o rendimento económico, a efetividade dos recursos humanos e o uso tecnológico vinculado às suas criações.
Em termos concretos, o engenheiro de sistemas pode dedicar-se ao desenvolvimento e à implementação de redes complexas, à programação de aplicações informáticas e à manipulação de base de dados, por exemplo.
Os profissionais em engenharia de sistemas são muito requisitados atualmente face ao avanço da tecnologia e à necessidade de informatização que têm as empresas.
2. Conceito de Análise de Sistema Estruturado 
A crise do software aconteceu em meados da década de 1970, causadas pelo aumento da demanda e da necessidade de uso de softwares. Essa crise foi desencadeada a partir de um conjunto de problemas como: 
· Muitas descrições textuais de difícil compreensão e manutenção, ocorrendo ambiguidades.
· Prazos e custos extrapolados.
· Dificuldades envolvendo a construção, implantação e manutenção dos softwares.
Na tentativa de reverter à crise foram propostas metodologias de desenvolvimento de sistema, são elas:
· Análise Estruturada ( processos e dados);
· Análise Essencial (processos, dados e controle);
· Análise Orientada a Objetos (paradigma de objeto);
O que é análise?
Análise é o estudo de um problema, que antecede à tomada de uma ação.
A análise estruturada de Sistemas é um conjunto de técnicas e ferramentas cujo objetivo é auxiliar na análise e definição de sistemas, seu conceito fundamental é a construção de um modelo do sistema utilizando técnicas gráficas, que são:
Diagrama de Fluxo de Dados (DFD)
Dicionário de Dados (DD)
Análise estruturada.
Qualidades da Análise Estruturada
1. Ter uma representação gráfica de fácil entendimento.
2. Ser particionada em uma rede de mini - especificações.
3. De fácil manutenção
4. Interação permanente com o utilizador.
Problemas da Análise estruturada
1. Manutenção
2. Prazo de desenvolvimento
3. Comunicação
4. Custos elevados
5. Documentação inadequada
6. Dificuldades de teste
A análise essencial.
A Análise Essencial de Sistemas pode ser considerada uma evolução da análise estruturada, propondo o reparticionamento do sistema, utiliza-se das mesmas ferramentas de modelagem da análise estruturada, mas com mecanismos diferentes.
A análise orientada a objetos.
A Análise Orientada a Objetos surgiu do salto evolutivo do desenvolvimento de sistemas, gerado pela evolução tecnológica, mudanças de arquiteturas, prazos mais curtos, dentre outros. Sua meta é identificar o melhor conjunto de objetos para descrever um sistema de software.
3.Estudo de viabilidade de um sistema de Informação
Um fator importante do processo de desenvolvimento de sistemas é a sua viabilidade. Fazer um estudo de viabilidade é necessário para compreender se o projeto tem sustentação para ser desenvolvido.
O estudo de viabilidade deverá levar em conta fatores organizacionais, técnicos, operacional, econômicos, etc.
Viabilidade Organizacional
O objetivo é verificar se o sistema trará benefícios reais para a organização. Deverá ser levada em conta a cultura organizacional, objetivos estratégico, entre outros.
Viabilidade Técnica
A viabilidade técnica consiste em avaliar a infra-estrutura da organização: hardware, softwares, rede, comunicação, etc. É necessário compreender se a empresa terá suporte técnico para o novo sistema ou se haverá necessidade de novos investimentos em tecnologia.
Viabilidade Operacional
Um dos fatores mais críticos é o operacional, ou seja, como será a aceitação por parte dos usuários, quais os requisitos dos clientes, etc. Diz respeito ao que o cliente espera e o que o sistema será capaz de fazer.
Viabilidade Econômica
A viabilidade econômica diz respeito aos resultados financeiros. O sistema ajudará na redução de custos? Aumento de receitas? Impactará de alguma forma no lucro da empresa. O fator econômico é importante, pois ele é em muitos casos determinante para a aprovação do projeto.
Recursos tangíveis e intangíveis
No estudo de viabilidade podemos avaliar os custos e benefícios como: tangíveis e intangíveis
Quando os custos e benefícios puderem ser quantificados, serão tangíveis, caso contrário serão intangíveis.
Exemplos de benefícios tangíveis
· Aumento nas vendas;
· Redução de despesas;
· Maior produção;
· Diminuição no tempo de entrega;
· Melhora no tempo de atendimento.
Exemplos de benefícios intangíveis
· Melhor atendimento ao cliente;
· aumento da confiança na empresa;
· Melhor relação com  fornecedores;
· Melhor posição competitiva;
· Reputação.
4.Requisitos de um sistema de informação.
 requisitos: 
5.  princípios; 
6.  requisitos funcionais e não funcionais; 
7.  requisitos de usuário e sistema; 
8.  técnicas para levantamento de requisitos: 
9. o Brainstorm, entrevista, questionários, observação, análise de texto, aprendizagem com o usuário e reutilização de requisitos 
10.  prototipação; 
11.  modelos e padrões 
Análise de Requisitos.
É o 1º passo no modelo do processo. O que devo fazer e não a forma como será implementado. Serve como contrato entre desenvolvedor e comprador.
Os requisitos de um sistema de informação é o processo de aquisição, refinamento e verificação das necessidades do sistema. O objetivo é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do mesmo para elaboração do Documento de Requisitos.
	
O cliente queria isso .... 
	
Como ele explicou para o Lider de projetos.....
	
O Líder de Projetos entendeu assim.
	
O Analista especificou assim:
	
O Programador entendeu assim... e
	
... desenvolveu o aplicativo assim:
	
O resultado dos Testes!
	
Os beta testers receberam isto:
	
O Suporte instalou isto para o Cliente
	
E cobrou isso!!!
	
Como os patches devem ser aplicados
	
O Projeto foi todo documentado assim:
	
Os Consultores de Marketingdescrevem assim:
	
O software foi anunciado assim:
	
Quando ele foi entregue...
	
A solução do Suporte para “alguns problemas”...
	
Destino provável do projeto...
	
Enquanto isso... Uma versão Open Source...
Definição de Requisitos dos Sistemas
Obter os requisitos do sistema como um todo estabelecendo um conjunto de objetivos gerais que o sistema deve cumprir;
Características do que o sistema deve fazer e não o que deve ser implementados;
Utilizados pelos: usuários finais de sistemas, desenvolvedores de software e arquitetos de sistemas.
Requisitos Funcionais
São declarações de funções de como o sistema deve reagir a entradas específicas e como deve comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente. Algumas vezes, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer. A especificação deve ser completa e consistente.
Exemplo
· O sistema deve permitir a inclusão, alteração e remoção de funcionários com os seguintes atributos: nome, endereço, cidade,etc).
· O usuário deve ser capaz de buscar todo o conjunto inicial do BD ou selecionar um subconjunto a partir dele.
· O sistema fornecerá telas apropriadas para o usuário ler documentos
Cada pedido tem um único identificador.
Requisitos Não Funcionais
Organizacionais: refere-se a políticas e procedimentos nas organizações do cliente e do desenvolvedor.
· de entrega, de implementação, padrões de processo
Externos: refere-se a fatores externos ao sistema e ao seu processo de desenvolvimento. 
· Interoperabilidade (interação do sistema com outros), éticos, legais (privacidade e de segurança)
De produto: especificam o comportamento do produto.
· eficiência (desempenho, espaço, rapidez, memória), confiabilidade, portabilidade.
Exemplo
Organizacional: o processo de desenvolvimento de sistema e os documentos a serem entregues deverão estar de acordo com o processo e os produtos a serem entregues definidos em XYZKL.
Externo: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes.
De produto: toda comunicação necessária entre o ambiente X e o usuário deve ser expressa no conjunto padrão de caracteres ANSI.
Requisitos Não Funcionais - continuação
Ambiente físico: Onde o equipamento funcionará?
Interfaces: A saída vai para outro ou outros sistemas?
Funcionalidade: Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou a saída?
Os usuários e os fatores humanos: Haverá diversos tipos de usuários?
Documentação: Essa documentação deve ser on-line, no formato de livro, ou ambos?
Dados: Qual será o fluxo de dados do sistema?
Segurança: O acesso ao sistema ou às informações deve ser controlado?
Recursos: Quanto espaço físico será ocupado pelo sistema.
Análise de Requisitos como obtê-los
Técnicas existentes: 
· Entrevista
· Questionário
· Observação direta
· Sessões brainstorming
Entrevista 
Usado quanto poucas pessoas conhecem as informações necessárias para o desenvolvimento do sistema. Precisa ser preparada antecipadamente. Ter perguntas objetivas. Evitar constrangimento dos participantes.
Antes: planejar, identificar a posição e responsabilidade do entrevistado, marcar horário, escolher local sossegado.
Durante: apresente-se informando a finalidade da entrevista, explique as anotações que fizer, não demore mais do que 2 horas, agradeça a contribuição.
Depois: documente os pontos relevantes; envie a documentação ao entrevistado (aprovação final), envie os resultados para os usuários e seus gerentes.
Questionário
Usado quanto muitas pessoas conhecem as informações necessárias para o desenvolvimento do sistema. Preparar antecipadamente com questões objetivas.
Desvantagem: comunicação restrita com o usuário e não há troca de informação face a face. A preparação exige tempo.
Preparação: identificar o tipo de informação que deseja obter. Enviar carta acompanhando o questionário, enfatizando a sua importância. Identificar quem responderá: nome, função e localização. Distribuir com instruções detalhadas de como preencher e o prazo de devolução. Analisar e consolidar as informações recebidas, documentar as principais descobertas e enviá-las juntamente com cópia do relatório para todos os respondentes.
Observação Direta
Utilizada como processamento e confirmação de outros resultados (entrevista e questionário). Identificar documentos que devem ser coletados para posterior análise. Observar diretamente quem desenvolve o trabalho. Deve ter aprovação antecipada das gerências.
Brainstorming
Útil para obter rapidamente informações sobre a atual situação. Reunião pessoas com diferentes níveis de informação e conhecimento sobre o sistema desejado. A discussão em grupo é conduzida por um mediador. Conceito: diversas cabeças pensam melhor do que uma.
Análise de Requisitos- prototipação
Prototipação é uma abordagem baseada em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Envolve a produção de versões iniciais -protótipos (análogo a maquetes para a arquitetura) - de um sistema futuro com o qual é possível realizar verificações e experimentos, com o intuito de avaliar algumas de suas características antes que o sistema venha realmente a ser construído, de forma definitiva.
Quando usar:
Em muitos casos o cliente define somente um conjunto de objetivos gerais para o Sistema (Software), mas não foi capaz de gerar requisitos definidos, de entrada, processamento e saída, para o sistema (software).
Ou o desenvolvedor não tem certeza da eficiência de um algoritmo, ou como ele pode se comportar em um determinado Sistema Operacional, ou durante a comunicação com alguma interface, periféricos/componentes; 
Ou a interação homem-máquina pode não ser aceita pelo cliente, ou seja a interface de comunicação com o aplicação (Software) pode ser confusa ou não usual.
O que gerar como protótipo?
Para gerar o protótipo existem varias formas e ferramentas, sendo as mais usuais:
· Modelo de papel:
ilustra como o sistema (software) irá se comportar e interagir como o Usuário de forma a capacitar a todos entender como ocorrerão os processos de interação;
· Modelo de trabalho:
implementa algumas características do software, em sua maioria a interface de comunicação com usuário como a navegação em telas, entre outros subconjuntos de funcionalidades existentes no sistema;
Toda a funcionalidade existente será melhorada em um novo esforço de desenvolvimento, gerando um novo protótipo mais completo.
Desvantagens
· O cliente vê a versão em funcionamento e exige alguns acertos para colocar logo em uso;
· A codificação utilizada para apresentar o protótipo pode no final não ser a definitiva;
· O protótipo pode ser visto com perda de tempo para o cliente.
5 - MODELAGEM DE SISTEMAS DE INFORMAÇÃO 
Fundamentos
Modelagem um sistema de informação tem como objetivo melhorar a tomada de decisão.
● Em situação de decisão deve-se saber: 
○ Quais são as questões fundamentais. 
○ Quais alternativas devem ser investigadas.
○ Onde focar a atenção
Abordagem simples para tomada de decisão:
Abordagem no mundo real para tomada de decisão:
Abordagem sistemática para tomada de decisão:
Em resumo...
● Definição do modelo, interpretação e implementação:
○ São processos essenciais para a tomada de decisão.
● Perguntas que sempre devem ser respondidas:
○ Quais situações são passíveis de serem modeladas?
○ Qual é a disponibilidade de dados para análise do modelo e para obter resultados em tempo hábil e a custos coerentes.
● Modelos possuem funções diferentes, de acordo com o nível onde será implementado:
○ Alto nível: planejamento estratégico, planos contingência, tempo reação;
○ Médio nível: planejamento, coordenação, logística, adaptação;
○ Baixo nível: programação, operação, expansão, análise impacto.
Uso de modelos. Para que serve?
Modelos são ferramentas de análises lógicas consistentes:
● Forçam a explicitação dos objetivos.
● Identificam dos tipos de decisões que influenciam os objetivos.
● Forçam a identificaçãodas interações entre as decisões.
● Forçam raciocínio criterioso sobre variáveis e definições quantificáveis.
● Mostram a consideração de dados que são pertinentes para quantificação das variáveis e a determinação de interações entre elas.
● Identificam restrições ou limitações dos valores das variáveis.
● Facilitam comunicação e o trabalho em grupo.
● Podem ser ajustados e melhorados com a experiência e a histórica, isto é, aprendizagem adaptativa.
	Tipo de modelos
	Características
	Exemplos
	Físico
	Tangível
Fácil compreensão
Reprodução difícil
Manipulação difícil
Escopo uso: muito baixo
	Modelo aeronaves
Modelos de residências
Modelos de cidades
	Analógico
	Intangível
Compreensão difícil
Reprodução mais fácil
Manipulação mais fácil
Escopo de uso: baixo
	Mapas de estradas
Velocímetro
Gráficos
	Simbólico
	Intangível
Compreensão mais difícil
Reprodução muito fácil
Manipulação muito fácil
Escopo de uso: amplo
	Modelos simulação
Modelos algébricos
Modelos planilhas
exemplo
Eu gostaria de saber o tempo gasto em uma viagem. Preciso implementar isso em um 
computador de bordo, como fazer?
● Modelo: abstração (aproximação) cuidadosa (tratável) da realidade
● Detalhar o modelo o suficiente para que:
○ Os resultados satisfaçam as necessidades.
○ Seja consistente com os dados disponíveis.
○ Haja alta correlação entre o previsto pelo modelo e a realidade.
○ Possa ser analisado dentro das disponibilidades.
● Definir variáveis
● Modelo de alto nível
● Modelo de médio nível
● Modelo de baixo nível
Logo, um modelo é construído com:
1. Estudo de características da situação de decisão.
2. Formulação de uma representação da situação.
3. Analise do modelo simbólico.
4. Quantificação e alimentação do modelo com dados.
5. Validação e testes do modelo x realidade.
Uso de modelos: Tipos
● Modelagem dedutiva: Presume-se que o modelo pode desenvolver-se inicialmente focando nas variáveis, relacionando-as no modelo com suposições matemáticas. 
○ Resultado: Valoriza o conhecimento prévio do modelador em relação aos dados e suas aplicabilidades. Modelagem "de cima para baixo". Usa-se poucos dados.
● Modelagem inferencial: Presume-se que os dados refletem a realidade, relacionando as variáveis para estimar seus valores.
○ Resultado: Valoriza os dados exatos. Modelagem "de baixo para cima". Usa-se muitos dados.
Uso de modelos
● Representação limitada da realidade.
● Os resultados de um modelo não é, necessariamente, a solução para a situação original.
● A noção de "ótimo" é um conceito matemático em oposição a um conceito do mundo real.
● Um modelo formulado e implementado corretamente for cuidadosamente interpretado, ele fornecerá informações robustas para a tomada de decisão
Ferramentas para Análise de Sistemas: DFD
DFD – Diagrama de Fluxo de Dados
O Diagrama de Fluxo de Dados é uma ferramenta para modelagem de fluxo de dados, através da representação de processos que usam e geram dados. Tom DeMarco, um dos primeiros autores sobre Diagrama de Fluxo de Dados, define o DFD como sendo “uma representação em rede de um sistema (...)” que “(...) pode ser automatizado, manual ou misto. O Diagrama de Fluxo de Dados retrata o sistema em termos de suas partes componentes, com todas as interfaces entre os componentes indicadas” (Análise Estruturada e Especificação de Sistemas, Ed. Campus, 1989).
Eduard Yourdon, define o DFD como “uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por ‘dutos’ e ‘tanques de armazenamento’ de dados” (Análise Estruturada Moderna, Ed. Campus, 1990).
O DFD é um dos principais componentes da chamada “especificação estruturada”. No ciclo de vida estruturado, a fase de análise do sistema consiste em transformar os requisitos do usuário em especificação estruturada. Os requisitos do sistema incluem as necessidades do usuário (o que ele precisa do sistema para que seus objetivos sejam atingidos) e o ambiente do sistema (como o sistema funciona, seus problemas e suas oportunidades). Os requisitos do sistema são obtidos pelo analista de sistemas através de técnicas de levantamento de dados, das quais a mais utilizada e aplicada na maioria dos casos é a entrevista. 
O analista de sistemas entrevista os usuários do sistema para compreender os seus requisitos sirvam de base para uma das principais tarefas do ciclo de vida do desenvolvimento do software que é a análise. Na análise, os requisitos são transformados em especificação estruturada, que é composta basicamente pelo Diagrama de Fluxo de Dados, pelo Dicionário de Dados, pelo Diagrama Entidade-Relacionamento, pelo Diagrama de Descrição de Entidades e pelas Especificações de Processos (em Português Estruturado, Tabela de Decisão ou Árvore de Decisão). A especificação estruturada é a documentação da análise feita pelo analista ou grupo de analistas junto com os usuários, onde o sistema é visto em termos conceituais e funcionais (e, às vezes, até em termos físicos do sistema atual), e todos os componentes, que precisam ser conhecidos e representados sem ambigüidade, omissão ou redundância, são modelados para que o projeto do sistema possa ter feito.
O DFD possui apenas quatro elementos que são necessários e suficientes para modelar o sistema em termos conceituais e funcionais. Estes elementos são:
· Entidade externa (chamada assim por Gane & Sarson e chamada de terminador, por Yourdon, ou por ponto terminal, por Martin & McClure, ou ainda de fontes e destinos de dados, por DeMarco): de onde partem ou para onde chegam os dados (origem e destino);
· Fluxo de dados: indicam os dados e o caminho por onde percorrem no sistema;
· Processo ou função: ponto de processamento dos dados (tratamento, alteração ou manuseio de dados);
· Depósito da dados (assim chamado por Gane & Sarson e Martin & McClure e chamada de depósito, por Yourdon, ou arquivo, por DeMarco): indica qualquer tipo de armazenamento de dados.
A representação através de um DFD é feita em níveis ou camadas, partindo-se sempre de uma visão mais global para a visão mais detalhada ou específica. Esta abordagem de top-down.
As vantagens de utilizar o Diagrama de Fluxo de Dados para modelagem de sistemas são várias, dentre elas podemos citar:
· Representar o sistema através de um DFD é uma maneira sistemática de definição e especificação;
· O DFD é uma especificação que possui algum formalismo, tal como proposto nos princípios da Engenharia de Software;
· O DFD permite registrar as necessidades e preferências do usuário;
· O DFD permite uma visão gráfica do problema, evitando as ambigüidades, redundâncias e omissões próprias de uma especificação narrativa;
· A utilização do DFD facilita o controle de projeto.
Símbolos do DFD
A notação do DFD é gráfica e utiliza um símbolo para cada um dos quatro elementos que compõem o diagrama. A figura 1 mostra estes símbolos nas duas versões mais utilizadas para se desenhar Diagramas de Fluxo de Dados. Por uma questão de Análise de Sistemas é a proposta por Yourdon e DeMarco. Na realidade, as duas notações atendem à sintaxe do DFD, não havendo, portanto, uma que seja melhor que a outra. A notação proposta por Gane & Sarson é difícil de fazer “à mão” durante os primeiros momentos de definição, mas, em compensação, é mais fácil de ser feito no computador. A notação de Yourdon e DeMarco é facilmente feita “à mão” e mais difícil de ser computadorizada.
Figura 4: Símbolos do DFD
As entidades externas são, geralmente, categorias lógicas de coisas ou pessoas que representam uma fonte ou destino para as transações. Exemplos: cliente, empregado, fornecedor, contribuinte, segurado etc. Elas também podem ser uma fonte ou destino específico, como: Departamento de Contas, Receita Federal, Escritório do Presidente etc. Quando o sistema enfocado recebe dados a ele, aquele outro sistema é considerado entidade externa. Ao identificar alguma coisa ou sistema como entidade externa, estará sendo afirmado, implicitamente, que esta entidade está fora dos limites do sistema considerado.
O fluxo de dados podeser considerado como um tubo por onde passam pacotes de dados. Os fluxos de dados são os únicos elementos de ligação de um DFD. Isto significa que os outros elementos podem ligar-se entre si, a não ser que seja através de um fluxo de dados. Quando mais de um elemento de dados tem a mesma origem e o mesmo destino, eles podem ser representados por um único fluxo de dados, separando-se seus nomes pelo conector “+”. Por exemplo, se um cliente deve apresentar, a um sistema de vendas, seu nome e seu número de RG, esta representação pode ser feita num único fluxo de dados, com o nome “nome do cliente + rg”.
Os processos são definidos através de um identificador e um nome significativo. O identificador, geralmente é um número, que tem como único propósito, identificar o processo. Isto significa, que o número atribuído como identificador não deve se repetir e não indica ordem ou seqüência de execução. Não há razão para associar significados a números de processos, pois alguns deles serão subdivididos em dois ou mais processos (o que significa que novos números surgirão) ou que vários processos serão agrupados em um único (significando que alguns números desaparecerão), no decorrer do trabalho de análise. A partir do momento em que o processo recebe a identificação, esta não deve ser modificada, exceto para desmembramentos ou agrupamentos, pois serve como referência para os fluxos de dados e para decomposição do processo em níveis inferiores. A descrição da função deve ser um sentença imperativa, constituída por um verbo ativo no infinitivo seguido de um objeto direto. Esta sentença deve ser a mais simples possível, como: "extrair vendas mensais": "dar entrada de detalhes do novo cliente", "averiguar se cliente tem crédito" etc. Deve ser observado que, nestas frases, o sujeito é indeterminado. No momento em que um sujeito for introduzido, há um compromisso físico sobre o desempenho da função, o que pode ser útil quando estuda-se um sistema existente para denotar o departamento, ou o programa, que desempenha uma função. De forma semelhante, quando a análise está completa e o projeto físico do novo sistema está sendo desenvolvido, é conveniente observar como a função será fisicamente desempenhada.
Os depósitos de dados indicam armazenamento, sem o compromisso quanto ao aspecto físico (se é em computador, arquivo de uma sala, ou uma gaveta, por exemplo). Durante a análise, são detectados certos lugares onde haverá dados armazenados entre processos. Quando um processo armazena dados, a seta do fluxo de dados aponta para o depósito de dados; por outro lado, quando um processo efetua acesso a dados armazenados em um depósito (em forma de leitura), a representação é feita com a seta do fluxo de dados apontada para o processo e o nome do fluxo de dados englobando o grupo de elementos de dados que está sendo recuperado pelo processo.
Sintaxe do DFD
Ao se desenhar um Diagrama de Fluxo de Dados, algumas regras devem ser seguidas para que sejam válidas as especificações geradas pelo gráfico. Estas regras são as seguintes:
1. Todos os objetos do DFD devem ter identificadores. Entende-se por objetos do DFD as entidades externas, os processos e os depósitos de dados. Cada entidade externa deve ter um identificador representado por uma letra minúscula no canto superior esquerdo do símbolo (na notação de Yourdon e DeMarco, o identificado r de entidade externa pode ser omitido). Os processos são identificados por números, de acordo com o nível de detalhamento que representam. Os depósitos de dados são identificados apenas pela notação de Gane & Sarson e os identificadores devem respeitar o formato Dx, onde x é um número seqüencial usado para identificar o depósito.
2. Todos os objetos e fluxos de dados do DFD devem ter nome. Os quatro elementos do DFD devem ter nomes significativos. Os nomes dos fluxos de dados devem ser escritos com todas as letras em minúsculo. Os nomes dos processos devem começar com letra maiúscula e as demais letras minúsculas. As entidades externas devem ter seus nomes escritos com todas as letras em maiúsculo ou pela primeira em maiúsculo e as demais em minúsculo. Os nomes das entidades externas geralmente são representados no singular. Os depósitos de dados têm seus nomes representando plural ou coletivo e devem começar com letra maiúscula e as demais em minúsculo (em algumas notações, aceita-se utilizar todas as letras maiúsculas para nome de depósito "de dados).
3. Todos os processos devem ter pelo menos um fluxo de dados de entrada e um de saída. Os processos representam funções que são executadas sobre dados de entrada, transformando-os em dados de saída. Neste sentido, não é possível ter em um DFD processos do tipo "geração espontânea", onde não há nenhum fluxo de dados de entrada e um ou mais de saída. Também, não é permitido processo do tipo "buraco negro", que consiste em um ou mais fluxos de dados de entrada, sem gerar nenhum dado de saída.
4. Todos os fluxos de dados devem ter uma origem e um destino. Cada fluxo de dados deve ser gerado por um processo, entidade externa ou depósito de dados. Igualmente, todos os fluxos de dados devem ser usados por um processo, entidade externa ou depósito de dados. Portanto, não é permitido, no DFD, um fluxo de dados que comece no "nada" e vá para algum objeto do DFD, bem como um fluxo de dados que seja gerado por um objeto do DFD e vai para o "nada".
5. Todos os fluxos de dados devem começar ou terminar num processo. Não deve existir, no DFD, ligação entre dois depósitos de dados ou duas entidades externas ou, ainda, entre um depósito de dados e uma entidade externa, sem que haja um processo no meio para fazer esta ligação. Isto ocorre em função de que as ações do DFD são, todas elas, executadas pelos processos. Um fluxo de dados não tem a capacidade de mover-se sozinho no sistema. Há sempre a necessidade de um processo enviá-Io para algUm lugar ou pegá-Io de algum lugar. É possível, porém, haver um fluxo de dados cuja origem seja um processo e o destino, outro processo.
6. Todos os fluxos de dados devem ter uma única seta direcional. Um fluxo de dados caracteriza-se por uma única origem e um único destino. Portanto, nos casos em que a interface entre um objeto qualquer e um processo seja um mesmo dado que entra e que sai do processo, este dado deve ser representado em dois fluxos de dados, um em cada sentido.
7. Todos os objetos e fluxos de dados devem ter nomes significativos. Nome significativo quer dizer um nome relevante para o sistema. Como regras para a formação de nomes, deve-se respeitar: para entidade externa, o nome deve estar no singular; para depósito de dados, o nome deve estar no plural; para fluxo de dados, o nome não deve indicar ação, não contendo verbo em seu início; para processo, o nome deve representar ação, começando, portanto, com verbo. Os processos devem ter seu nome formado por verbo no infinitivo + objeto de direto.
8. Todos os depósitos de dados devem representar objetos de interesse para o sistema. Depósitos de dados, somente de leitura ou somente de escrita devem ser bem avaliados, pois podem significar algum armazenamento de dados fora do contexto do sistema.
9. A duplicação de símbolos e o cruzamento deve ser evitado. O desenho do DFD deve ser feito de forma a evitar a necessidade de representar um mesmo objeto duas vezes ou cruzar linhas para fazer as ligações entre os objetos. Quando não for possível, deve-se minimizar o uso destes recursos e, assim mesmo, tomar algumas providências. Se for necessário duplicar uma entidade externa, devese marcá-Ia com uma linha inclinada no canto inferior direito (formando uma espécie de triângulo na extremidade inferior direita do símbolo da entidade), para cada repetição. Se for necessário duplicar um depósito de dados, na notação de Gane & Sarson, deve-se acrescentar uma linha vertical entre o identificador e o nome do depósito para cada repetição que ocorrer. No caso de haver cruzamento de linhas (fluxos de dados), deve-se usar a estratégia de fazer um arco no cruzamento, comose um fluxo estivesse passando por cima do outro, ou uma fenda, deixando um pequeno espaço em branco nas proximidades do cruzamento, dando a impressão de que o fluxo de dados esta passando por baixo do outro.
	A seguir, é apresentada a construção do DFD de uma Revendedora dos Livros. Observe como a aplicação correta da técnica do Diagrama de Fluxo de Dados permite uma clareza e uma objetividade muito grande em relação ao funcionamento do mesmo.
Figura 5: 1º DFD da Revendedora de Livros
Figura 6: 2º DFD da Revendedora de Livros (Maior expansão)
Figura 7: DFD Completo
Figura 8: Expansão do Processo "Preparar Requisição para Editora" em outro DFD
Figura 9: Possíveis áreas de automação
Dicionário de Dados
À medida que ampliamos os detalhes dos conteúdos de fluxos de dados, de depósitos de dados, e de processos, torna-se necessário um local estruturado para manter todos esses detalhes. O dicionário de dados proporciona tal local. O nome Dicionário de Dados adquire um significado mais amplo quando começamos a incluir detalhes sobre processos que, estritamente falando, se refere à lógica e não a dados.
O interessante é descrever somente aquilo que tem interesse para nós, usando os 03 níveis seguintes:
· Elementos de Dados: são dados que não necessitam de uma maior decomposição para o fim a que se destinam. Por exemplo, “data” é um elemento de dado para a maioria dos casos de análise, embora possa ser considerada como uma estrutura composta de “mês, dia e ano”, para a codificação de uma rotina de conversão de data.
· Estruturas de Dados: são compostas de elementos de dados ou de outras estruturas de dados, ou de uma mistura de ambas. Por exemplo, no DFD exemplo, “Telefone” é uma estrutura de dados composta de quatro elementos: Código_DDD, Prefixo, Número e Ramal.
· Fluxo de Dados e Depósitos de Dados: como já sabemos, fluxos de dados são caminhos ou “tubos” ao longo dos quais viajam estruturas de dados; depósitos de dados são locais onde as estruturas de dados são armazenados até serem requisitadas. Fluxos de dados são estruturas de dados em movimento; depósitos de dados são estruturas de dados estáticas.
COMO DESCREVER FLUXOS DE DADOS
	Para expressar o conteúdo de um fluxo de dados é preciso definir os nomes de dados que a percorrem. (Para sermos mais exatos sobre isso, a partir do exemplo da Revendedora de Livros, o conteúdo de um fluxo de dados forma apenas uma grande estrutura de dados, como PEDIDOS ou DEVOLUÇÕES ou PAGAMENTOS, mas especificá-la como tal é desperdiçar uma entrada no dicionário de dados). Também queremos anotar:
· A origem do fluxo de dados;
· O destino;
· Os volumes de cada estrutura de dados ou transação (talvez com sua distribuição durante o dia ou mês);
· A implementação física atual do fluxo de dados (quando estivermos descrevendo um sistema existente.
Figura 10: Exemplo de Dicionário de Dados de Fluxo de Dados - Exemplo Revendedora de Livros
COMO DESCREVER DEPÓSITO DE DADOS
	Como um depósito de dados é uma estrutura estática, descreveremos o seu conteúdo em termos de estruturas de dados nele encontradas. Anotamos também os fluxos de dados que alimentam o depósito de dados e aqueles que dele são extraídos. Se realizarmos apenas algumas consultas definidas elas também poderão ser descritas no dicionário de dados, mas se forem complexas, deverão ser tratadas na seção de acesso imediato da especificação funcional. 
Figura 11: Exemplo de Dicionário de Depósito de Dados - Exemplo Revendedora de Livros
COMO DESCREVER PROCESSOS
	Em um dicionário de dados, a descrição de um processo deve ser sucinta, até pelo fato que o espaço possa não ser suficiente para registrar toda a descrição lógica. Em tais casos, é preciso especificar as entradas e saídas do processo, resumir a lógica e dar uma referência do trecho da documentação funcional onde a lógica será encontrada.
Figura 12: Exemplo de Dicionário de um Processo - Exemplo Revendedora de Livros
	É claro que se pudermos descrever toda a lógica de um processo no dicionário de dados, assim o faremos. Na Figura 12, a lógica está descrita em três níveis:
	1º O nome do processo do diagrama de fluxo de dados “VERIFICAR SE CRÉDITO É BOM” (quando a entrada do diagrama do fluxo de dados excede a 30 caracteres, devemos abreviá-la.
	2º A descrição resumida do processo, que deve estar contida no menor espaço suficiente para permitir que uma pessoa familiarizada com o negócio da empresa entenda o que o processo representa.
	3º O resumo lógico na coluna central, que deve definir as funções principais a um nível que permita que uma pessoa familiarizada com o negócio da empresa seja capaz de desempenhar a função (ou de programá-la). O resumo lógico não é uma declaração exaustiva, embora tem que ser escrita tão sem ambigüidade quanto o espaço possibilite.
RESOLUÇÃO DE EXERCÍCIOS
Atividades:
Elabore o Diagrama de Fluxo de Dados (DFD) e o Dicionário de Dados para as seguintes situações:
GUICHÊ DE UMA AGÊNCIA BANCÁRIA
O portador apresenta o cheque já preenchido. O caixa confere o preenchimento, depois, compara a assinatura com a registrada no cartão autógrafo do correntista e, se tudo estiver ok, lança os dados do cheque no terminal de caixa. O sistema pode acusar insuficiência de fundos; nesse caso, o caixa carimba o cheque e devolve-o ao portador. O sistema pode, também, acusar cheque roubado, devendo o caixa, nesse caso, levar o documento para o gerente que irá resolver a situação. Nos casos normais, o caixa efetua o pagamento do cheque, autentica-o no próprio terminal e guarda-o numa gaveta do guichê. 
Nos casos de erro de preenchimento ou problemas com a assinatura, o caixa devolve o cheque ao portador.
BIBLIOTECA UNIVERSITÁRIA
Uma biblioteca universitária deseja criar um Sistema de Empréstimo de Livros e está contratando você para desenvolver este sistema; e elaborou a seguinte especificação: a biblioteca só atende Usuários cadastrados. Os usuários são cadastrados por um Funcionário da biblioteca, que cadastra também os Livros disponíveis para empréstimo.
	O usuário pode solicitar um empréstimo informando seu código (que é verificado se é válido) e os códigos dos livros a serem emprestados (os quais são verificados se estão disponíveis, ou se estão reservados para este usuário); quando tudo estiver confirmado, o usuário recebe a confirmação do empréstimo e os dados do empréstimo são armazenados, e a situação do livro é armazenada como emprestado.
	Na devolução dos livros, o usuário informa o código do empréstimo e a data de devolução; confirmado a existência do empréstimo, os dados do mesmo são atualizados com a data de devolução e a situação dos livros é atualizada como disponível.
	O usuário ainda pode fazer reserva de livros, informando seu código de usuário (o qual é verificado se está cadastrado) e o código do livro para reserva (o qual é verificado se estará disponível para data da reserva). Se as informações estiverem de acordo para que a reserva seja feita, ela então é efetuada e a situação do livro é atualizada também como “reservado”.
	A Gerência recebe relatórios emitidos pelo funcionário sobre os usuários da biblioteca bem como dos empréstimos em aberto.
	Sempre que um dado for verificado e não for válido, uma mensagem deve ser enviada à entidade externa, informando-a de tal situação.
Exercícios variados
1 - Leia a descrição do caso Autopeças KW e elabore o levantamento de requisitos Funcionais e Não-funcionais
2 - Caso da Biblioteca Virtual
Deseja-se desenvolver um sistema para gerenciar uma biblioteca virtual, controlando e facilitando o acesso a documentos eletrônicos. A sistemática de funcionamento desta biblioteca é a mesma de uma biblioteca real.
Os títulos devem ser cadastrados no momento em que cada documento eletrônico for armazenado, com os itens: título, autor, editora, edição, número de paginas, local da publicação, código ISDN, numero de licenças, numero da licença e, um pequeno resumo da obra. A alteração, a exclusão e a pesquisa, são operações que o sistema também deve contemplar.
São usuáriosdeste sistema professores e alunos cujos cadastros já se encontram disponíveis no sistema acadêmico da escola.
A cada usuário deverá se associar certos privilégios ou direitos para operarem no sistema. Os usuários podem cadastrar a si mesmo, entretanto a autorização para operação dentro do sistema deve ser realizada por outro usuário com mais direitos ou privilégios. Assim, os itens de cadastro são: matrícula e senha.
Através deste sistema deverá ser possível pesquisar e visualizar os dados gerais de um usuário. Através deste sistema deverá ser possível pesquisar, visualizar um resumo da obra e ainda visualizar íntegra da obra. Alguns títulos são de domínio público, para estes será permitido ao usuário copiá-los para a sua máquina. O usuário poderá ainda sugerir novos títulos para aquisição referenciando-se apenas o título e autor da obra.
Por uma questão de direitos autorais, um determinado título só poderá ser consultado por um numero limitado de usuários, de acordo como o estabelecido em sua licença. Este sistema deverá ainda apresentar relatórios gerenciais tais como: usuários, títulos, títulos por autor, títulos mais consultados e usuários que mais utilizam o sistema. O sistema deverá ser implantado prevendo uma tecnologia que faculte a consulta remota.
3 - Estudo de Caso: Supermercado ABC
Você foi convidado a conhecer o funcionamento de um pequeno supermercado, a fim de propor uma solução de software para automatizar o seu processo de venda.
Imagine que após a visita ao supermercado e entrevista com usuários (proprietário, vendedores, empacotadores, operadores, etc) ficou claro que o processo de venda ocorre da seguinte maneira:
1. O cliente escolhe os produtos que deseja comprar e dirige-se ao guichê (caixa). Chegando lá, o mesmo, coloca os produtos em cima do balcão, o qual possui uma esteira que conduz os produtos em direção ao operador de caixa, dessa forma, o Sistema deve registrar cada produto comprado e suas respectivas quantidades. Para registrar os produtos o operador verifica o código do produto gravado numa etiqueta existente em cada produto, caso um produto esteja sem etiqueta, o operador chama um auxiliar de caixa e solicita o código do produto.
2. Quando os produtos escolhidos pelo cliente estiverem todos registrados, o Sistema calcula o valor total da venda e o operador o informa ao cliente para que escolha qual a forma de pagamento (dinheiro, cheque ou cartão). Caso o pagamento seja feito em dinheiro, o troco deverá ser calculado. Caso seja feito em cheque ou cartão o valor total será registrado, sendo que o operador deverá verificar se o cheque é realmente do cliente, conferindo a assinatura com documento de identidade e se o cartão é válido, verificando o mesmo junto à operadora. Deverá ficar registrado na venda qual o tipo de pagamento efetuado.
3. O supermercado possui 20 guichês, sendo que possivelmente outros serão adquiridos. Um outro detalhe é que as vendas deverão ser associadas ao equipamento caixa utilizado.
4. Todos os operadores de caixa são cadastrados e cada venda é associada ao operador que a realizou, pois o dono do supermercado deseja visualizar um relatório diário contendo o nome de cada operador e o total de vendas que o mesmo realizou no dia.
5. O dono do supermercado deseja também um relatório diário contendo cada equipamento de caixa e as vendas que foram realizadas neste.
6. Ao final do dia o dono do supermercado deseja obter uma lista quantitativa de todos os produtos vendidos, afim de que seja feita sua reposição pelo deposito central.
7. Para que um funcionário Caixa possa usar uma máquina Registradora o mesmo deverá realizar um login no mesmo informando o seu código e quando o mesmo encerrar suas atividades no equipamento irá realizar um logout.
1º Módulo de Informática	 	 Etec – Matão