ASSOCIAÇÃO EDUCACIONAL LEONARDO DA VINCI – ASSELVIFACULDADES INTEGRADAS DO VALE DO ITAJAÍ – FACIVI

CURSO: SISTEMAS DE INFORMAÇÃODISCIPLINAS: Análise de Sistemas

Apostila

Analise de Sistemas

BlumenauMarço de 2004

Analise de Sistemas

Introdução

O objetivo deste texto é auxiliar em algumas questões básicas para a compreensão da função do analista de sistemas em uma organização. Ele enfocará os conceitos de Sistemas de Informação, Engenharia de Software e Técnicas de Analise.

A formação de um(a) profissional para a função de analista de sistemas deve levar em conta que este profissional atuará na avaliação de sistemas e no desenvolvimento de sistemas automatizados, projetando, também, mudanças de procedimentos (inclusive aqueles realizados sem o uso de computador). Neste sentido, o desenvolvimento de sistemas é o foco central da atuação do analista de sistemas. Por isto, é fundamental compreender que este é um campo profissional, que deve ser trabalhado com a utilização de técnicas cientificamente desenvolvidas para que o processo de desenvolvimento de sistemas, bem como seus resultados, tenham qualidade.

Sistemas de Informação

Para compreender o processo de desenvolvimento de sistemas, é necessário ter claro o conceito de “sistema”. Muitas definições podem ser feitas de sistemas. Eles estão ao nosso redor e, até mesmo, dentro de nós (o nosso organismo é um sistema vivo). Na tentativa de fazer uma definição que tente ser simples e consensual, podemos dizer que sistema é um conjunto organizado de partes que atuam integradamente visando alcançar algum(ns) objetivo(s).

Desta forma, podemos afirmar que um sistema é definido a partir da identificação de suas partes e a constatação de que elas atuam numa mesma direção e sentido, resultando em algo que pode ser definido como sendo seu objetivo.

Exemplificando, nosso organismo é um sistema, formado por muitas partes, que tem por objetivo manter-nos vivo. Todas as ações e resultados gerados pelas partes deste sistema são empregados no objetivo de ter vida.

Podemos citar, também, uma empresa que registra toda a sua movimentação financeira e compromissos de pagamento em um sistema contábil. Este sistema tem uma série de funções, como a geração de lançamentos, a escrituração fiscal, a emissão de relatórios gerenciais. Este conjunto de funções delimita um sistema que tem como objetivo a contabilidade da organização.

Os sistemas, em uma das inúmeras classificações possíveis de serem feitas, pode ser naturais ou feitos pelo homem. Um sistema natural está relacionado às partes ordenadas que existem independente da ação humana. Como exemplo deste tipo de sistema, podemos citar o sistema solar, um ecossistema, sistema reprodutor, sistema digestivo, etc.

Os sistemas feitos pelo homem são aqueles gerados pela ação humana, através da organização de funções visando a um objetivo comum. Por exemplo, sistema mecânico de um carro, sistema de ventilação de um prédio, sistemas elétricos, sistemas hidráulicos, sistemas de informação, etc.

Os sistemas, de forma geral, são organizados em hierarquias. Ou seja, um sistema é geralmente parte de um sistema maior, da mesma forma como pode ser decomposto em sistemas menores. Como exemplo, podemos citar o ser humano como sendo um sistema composto por sistemas menores (chamados de sub-sistemas), como sistema respiratório, sistema muscular, dentre outros, ao mesmo tempo em que compõe outros sistemas como a família, a comunidade, etc. Da mesma forma, uma empresa faz parte de um sistema produtivo de uma comunidade, ao mesmo tempo em que possui sub-sistemas, como de recursos humanos, produção, contabilidade, compras, vendas, etc.

Considerando estes aspectos, um importante elemento na análise de sistemas é a delimitação do escopo do sistema a ser analisado. Isto significa definir a abrangência do mesmo e o seu grau de

- 2 -

Analise de Sistemas

detalhamento. Da mesma forma como é impossível analisar um sistema de saúde público de uma forma global, se nos detivermos a detalhes de funcionamento do sistema respiratório de cada indivíduo que faz parte da comunidade que está sendo avaliada, isto ocorre também no exercício da função de análise de sistemas. É importante que o(a) analista de sistema tenha clareza da hierarquia de sistemas e sub-sistemas envolvidos em seu trabalho para que possa ter a percepção correta dos objetivos, sem se perder em detalhes desnecessários, mas sem divagar exageradamente pela abstração do que está sendo trabalhado.

Como parte inerente à função de analista de sistemas, há uma categoria específica de sistemas onde este profissional atua. Trata-se dos chamados Sistemas de Informação. Muitas definições podem ser dadas para a expressão “Sistema de Informação”. Tentando contemplar as principais definições, podemos dizer que sistema de informação é o sistema que utiliza e gera informações para atender seus objetivos. Exemplificando, podemos dizer que o apontamento de mão-de-obra em uma fábrica é um sistema de informação, pois ele é alimentado com dados sobre o trabalho de cada funcionário na realização de tarefas específicas e gera informações consolidadas sobre o produto gerado pelo trabalho dos funcionários na fábrica.

Um sistema de informação é localizado em organizações, das mais distintas naturezas, levando em conta duas dimensões: os componentes da organização e o nível de decisão. A dimensão dos componentes da organização diz respeito às áreas funcionais, unidades organizacionais, setores ou departamentos, que realizam funções dentro do sistema ou o alimentam ou recebem informações.

O nível de decisão diz respeito à abrangência das informações geradas e para quais executivos da organização. Os níveis de decisão são classificados geralmente em nível estratégico, nível tático ou gerencial e nível operacional.

O nível estratégico corresponde às decisões do alto escalão administrativo da organização, correspondendo às grandes políticas institucionais, definindo rumos de longo prazo e de efeitos duradouros.

O nível tático ou gerencial corresponde às decisões intermediárias da organização, subsidiando ou emanando das decisões de nível estratégicos, relacionando-se basicamente ao controle gerencial de funções específicas.

O nível operacional está relacionado diretamente com o funcionamento da organização, no atendimento às políticas e diretrizes institucionais (emanadas no nível estratégico), dentro de padrões estabelecidos e regulamentados internamente (a partir de decisões de nível tático).

Quando tratamos de Sistemas de Informação, devemos observar cinco considerações básicas: objetivos do sistema; ambiente do sistema; recursos do sistema; componentes do sistema; e administração.

Os objetivos do sistema são fundamentais para que o mesmo possa ser analisado e desenvolvido. É um fator onde o(a) analista de sistemas deve deter-se com bastante cuidado sem cair na tentação de achar que os objetivos estão claros, pelo fato de que o usuário pode citar quais são eles, e partir para as demais tarefas da análise. Na verdade, se os objetivos não forem muito bem definidos, dificilmente o sistema atingirá seu sucesso. Muitas vezes ocorre que os objetivos declarados do sistema não corresponde aos objetivos reais. Neste sentido, o(a) analista de sistemas deve procurar ouvir o máximo de pessoas envolvidas com os sistemas, procurando assegurar-se de que os objetivos estão realmente estabelecidos para o desenvolvimento de determinado sistema. Para isto, ele(a) deve tentar entender não somente os fatos relativos ao sistema, mas também a lógica que está por trás dos fatos, avaliando a compreensão dos diferentes níveis e categorias de usuários sobre os objetivos, uma vez que os diferentes agentes envolvidos no sistema geralmente têm visões diferentes dos objetivos do sistema.

O ambiente do sistema envolve elementos que estão fora do sistema, mas influenciam ou podem influenciar o sistema. Isto significa que o sistema não tem controle sobre estes elementos, mas não pode desconsiderá-los, uma vez que uma mudança de comportamento em um destes

- 3 -

Analise de Sistemas

elementos pode provocar alterações ou, até mesmo, a destruição de um determinado sistema. Por exemplo, a legislação trabalhista não faz parte de um sistema de folha de pagamento, mas participa do ambiente do sistema. O sistema não pode mudar ou influenciar a legislação, mas qualquer mudança que ocorra nela, haverá conseqüências para o sistema. Conhecer o ambiente do sistema é um elemento fundamental para o(a) analista de sistemas possa realizar seu trabalho. Neste sentido ele(a) não pode e não deve ficar restrito apenas às variáveis que emergem do próprio sistema, como sendo os únicos elementos a serem considerados no desenvolvimento de um sistema.

Os recursos do sistema envolvem tudo aquilo que é necessário para que o sistema seja executado. Isto implica em pessoas, dinheiro, equipamentos, materiais, etc. Os recursos estão sob controle do sistema, uma vez que a falta deles implica no não-funcionamento do mesmo.

Os componentes do sistema são as partes que compõem o sistema e são responsáveis pela execução de suas funções.

A administração do sistema consiste na integração dos demais elementos considerados, uma vez que ela implica em planejar e acompanhar as funções do sistema, incluindo sua relação com o ambiente, a alocação de recursos, a atribuição aos componentes, para que os objetivos seja atingidos.

Um tipo específico de sistema de informação é o sistema baseado em computador, ou sistema de processamento de dados, ou, ainda, sistema automatizado. Este tipo de sistema é aquele que é organizado em termos de método, procedimento ou controle, realizando processamento de informações através de computador. O esquema básico de um sistema baseado em computador está representado pela Figura 1.1.

Figura 1.1 – Esquema básico do processamento de dados.

Um sistema baseado em computador possui os seguintes elementos básicos: software, hardware, pessoas, documentação, banco de dados e procedimentos.

O software corresponde aos sistemas operacionais, linguagens de programação, ambientes de desenvolvimento de software, ferramentas de programação, compiladores, sistemas gerenciadores de banco de dados, sistemas de rede, etc.

O hardware inclui os computadores, periféricos e ligações de rede e comunicação usados no sistema.

As pessoas envolvidas no sistema são usuários, desenvolvedores, pessoal de manutenção e alimentação de dados, gerentes, etc.

Por documentação compreende-se o conjunto de documentos gerados no processo de desenvolvimento do sistema, bem como instruções de uso, além dos documentos usados como base para a alimentação do sistema e os gerados por ele.

O banco de dados inclui o conjunto de dados armazenados permanentemente ou provisoriamente em meios magnéticos, recuperáveis pelo sistema computadorizado.

Os procedimentos incluem tanto aqueles necessários para a utilização do sistema, quanto aqueles que são realizados manualmente, mas possuem interface com o sistema informatizado.

A Figura 1.2 apresenta um resumo da interação entre os elementos básicos de um sistema baseado em computador. O sistema é o elo integrador entre os diferentes elementos que o constitui.

- 4 -

Analise de Sistemas

Figura 1.2 – Interação entre os elementos básicos de um sistema baseado em computador.

Os sistemas baseados em computador podem ser classificados em diversos tipos. A seguir veremos alguns tipos mais comuns. Convém ressaltar que esta classificação não é mutuamente exclusiva, ou seja, um mesmo sistema pode enquadrar-se em diversas categorias aqui elencadas.

Sistemas on-line: são sistemas em que há interação direta entre usuário e sistema e os dados de entrada são alimentados diretamente do local onde são criados e os dados de saída são direcionados diretamente para onde são usados. Estes sistemas têm as seguintes características: processamento remoto; dados organizados de maneira que permita a recuperação rápida; e interação com o usuário.

Sistemas batch (ou sistemas em lote): são aqueles que processam os dados seqüencialmente, a partir de lotes gerados por meio de digitação proveniente de documentos, gerando resultados que são disponibilizados para posterior utilização. Têm as seguintes características: grande volume de informações; não há interação com o usuário; e processamentos longos.

Sistemas distribuídos: são sistemas on-line que possuem usuários distribuídos em pontos geográficos diferentes, interagindo, através de linhas de comunicação, para ter acesso aos mesmos programas e dados.

Sistemas centralizados: são aqueles cujos usuários os utilizam a partir de um mesmo local geográfico, a partir de programas e dados armazenados dispostos em um mesmo local.

Sistemas de tempo real (ou real time): são sistemas que controlam um ambiente através do recebimento de dados e seu processamento, gerando resultados com rapidez suficiente para afetar o ambiente no mesmo momento. Suas características são: ocorrência de atividades de processamento simultâneas; prioridades diferentes para as diferentes tarefas; interrupção de tarefas menos prioritárias; e acesso simultâneo a dados.

Sistemas transacionais: são aqueles que baseiam-se em registro de transações para posterior recuperação. Podemos dizer que os sistemas transacionais automatizam procedimentos que, pelo volume e freqüência de dados, poderiam estar sujeitos a muitos erros se processados manualmente, mas não proporcionam, diretamente, elementos para uma tomada de decisão mais abrangente.

Sistemas de apoio à decisão (SAD) (ou Support Decision Systems – DSS): são aqueles que geram informações para tomada de decisões no nível tático ou gerencial, através de sínteses de transações e facilidades de consultas flexíveis, que são definidas em função da questão sobre a qual pretende-se tomar decisão.

Sistemas baseados em conhecimento (ou sistemas especialistas): são aqueles que simulam o conhecimento humano de um especialista para equacionar um problema e executar tarefas inteligentes.

Sistemas de Informação Executiva (ou Executive Information Systems – EIS): são sistemas de apoio à tomada de decisões aos executivos de nível estratégico de uma organização. Estes sistemas baseam-se em uma estrutura de dados corporativos altamente flexível do ponto de vista de

- 5 -

Analise de Sistemas

formulação de consultas, incluindo elementos referentes às estratégias de negócio da organização e dados da concorrência para obter-se um comparativo.

Sistemas integrados de gestão empresarial (ou Enterprise Resource Planning – ERP): são sistemas que integram todas as funções básicas de negócio de uma organização, gerando um alto grau de informações relativas ao funcionamento da empresa, permitindo tomada de decisões nos mais diferentes níveis da organização.

Os sistemas, de um modo geral, e os sistemas de informação, de forma específica, principalmente os sistemas baseados em computador, seguem os seguintes princípios (segundo Eduard Yourdon, em Análise Estruturada Moderna (Ed. Campus, 1990): quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias

diferentes; quanto maior for um sistema, maior o número de seus recursos que serão destinados à

manutenção diária; os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas

menores; os sistemas crescem.

Yourdon também cita que o desenvolvimento de sistemas é uma atividade que envolve muitos participantes. Estes participantes são: usuários; gerentes; coordenadores ou líderes de projeto; analistas de sistemas; projetistas de sistemas (normalmente o(a) próprio(a) analista de sistema); programadores; e pessoal de apoio e de produção.

Engenharia de Software

Roger S. Pressman, em seu clássico livro Engenharia de Software (Ed. Makron, 1995), traz a primeira definição para Engenharia de Software, feita por Fritz Bauer, que é “o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”. Outra definição complementar pode ser feita como sendo o conjunto de métodos, ferramentas e procedimentos que estabelecem o uso de princípios de engenharia (formalização), que, por sua vez, permite o gerenciamento e controle dos processos de desenvolvimento de software a fim de obter um produto final com maior qualidade, estabilidade, sendo desenvolvido de forma mais produtiva.

Nestas definições, encontramos palavras-chave como confiabilidade, produtividade, qualidade e estabilidade que, quando aplicadas ao software, significa uma nova maneira de produzir software, não de maneira artesanal ou amadora, mas de forma profissional, dentro de modernos e rigorosos princípios que tornam o produto final (software) melhor.

Os seguintes elementos são aplicados na Engenharia de Software: métodos; ferramentas; procedimentos. Os métodos correspondem ao como fazer. As ferramentas dão suporte aos métodos. Os procedimentos consistem em regras para a aplicação dos métodos e ferramentas.

A Engenharia de Software pressupõe o uso de uma Metodologia de Desenvolvimento de Sistemas. Metodologia de Desenvolvimento de Sistemas (MDS) é o conjunto de atividades a serem desenvolvidas para a geração de um sistema ou software. Ela deve envolver os elementos que são aplicados na Engenharia de Software.

A Figura 1.3 mostra a relação, proposta por Wasserman no artigo Automated Tools in the Information System Development Environments (Proceedings of the IFIP WG 8.1 Working Conference, 1982), entre os elementos da Engenharia de Software em uma Metodologia de Desenvolvimento de Sistemas.

Uma Metodologia de Desenvolvimento de Sistemas pressupõe a existência de um ciclo de vida para a realização das tarefas inerentes ao desenvolvimento de sistemas. Ciclo de vida é a seqüência e a interação em que as atividades de desenvolvimento de sistemas são executadas. O ciclo de vida deve envolver todos os passos desde a concepção do sistema até sua implementação

- 6 -

Analise de Sistemas

em termos de código executável testado e utilizável pelo usuário final.

Figura 1.3 – Relação entre os elementos da Engenharia de Software em uma

Metodologia de Desenvolvimento de Sistemas.

Os objetivos da adoção de um ciclo de vida pela organização podem ser definidos como: definir as atividades a serem executadas no desenvolvimento de sistemas; introduzir consistência entre muitos projetos de desenvolvimento de sistemas dentro da organização; e introduzir pontos de verificação para o controle gerencial de decisões.

Existem vários paradigmas de Engenharia de Software, cada um com ciclo de vida específico. Dentro do escopo proposto, analisaremos alguns ciclos de vida para as metodologias de desenvolvimento de sistemas estruturadas.

O ciclo de vida clássico é aquele que requer uma abordagem sistemática e seqüencial do desenvolvimento, envolvendo as seguintes fases: análise e engenharia de sistemas; análise de requisitos de software; projeto; codificação; testes; e manutenção. A Figura 1.4 ilustra este ciclo de vida.

Figura 1.4 – Ciclo de vida clássico.

A fase de análise e engenharia de sistemas consiste em estabelecer os requisitos para todos os elementos do sistema e atribuir alguns destes requisitos ao software a ser desenvolvido.

- 7 -

Analise de Sistemas

A fase de análise de requisitos de software consiste no detalhamento dos requisitos levantados na fase anterior, atendo-se mais especificamente aos elementos relacionados às partes informatizadas do sistema, buscando compreender o domínio da informação para o software, as funções, desempenho e interface necessários.

A fase de projeto consiste em definir a estrutura de dados a ser usada como suporte para o sistema, a arquitetura do software, detalhes de procedimentos para a utilização do sistema e a caracterização da interface. Esta definição deve ser avaliada antes de iniciar-se a codificação, para assegurar a qualidade exigida.

A fase de codificação consiste na geração dos programas correspondentes às funções do sistema.

A fase de testes consiste em avaliar se todas as instruções geradas na codificação estão corretas, bem como se o sistema responde adequadamente às entradas do sistema no que diz respeito a sua funcionalidade.

A manutenção corresponde à realização de mudanças no sistema provocadas pela descoberta de erros (manutenção corretiva), ou pela necessidade de adaptar-se a mudanças no ambiente ou na necessidade do usuário (manutenção adaptativa), ou, ainda, pela necessidade de introduzir-se novas funções para o usuário (manutenção evolutiva). No momento da manutenção, aplica-se as mesmas fases do desenvolvimento de um novo sistema, com a única diferença sendo a aplicação destas fases a um sistema já existente.

O ciclo de vida clássico possui os seguintes problemas: os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe; muitas vezes há dificuldades para que o usuário defina os requisitos do sistema de uma só vez, uma vez que o modelo não se adapta à incerteza natural que existe no início do processo de desenvolvimento de um sistema; e os primeiros resultados para o usuário somente serão percebidos nas fases mais avançadas do processo, quando muito tempo se passou, podendo ser inviável proceder alguma alteração, cuja necessidade é percebida tardiamente.

Outro paradigma é o do ciclo de vida semi-estruturado. Este ciclo apresenta duas características inexistentes no ciclo de vida clássico: substituição da seqüência bottom-up de codificação pela implementação top-down (os módulos de mais alto nível são codificados e testados antes dos de mais baixo nível); substituição do projeto clássico (desenho de lay-outs de arquivos, telas e relatórios) pelo Projeto Estruturado (que é uma abordagem formal de projeto de sistemas). A Figura 1.5 ilustra o ciclo de vida semi-estruturado.

Figura 1.5 – Ciclo de vida semi-estruturado.

- 8 -

Analise de Sistemas

A implementação top-down, muitas vezes, leva à realimentação entre o processo de implementação e o processo de análise.

Outro modelo é o ciclo de vida estruturado, que corresponde às fases do desenvolvimento de sistemas através da técnica conhecida como Análise Estruturada. A Análise Estruturada, juntamente com o Projeto Estruturado e a Programação Estruturada compõem um paradigma de Engenharia de Software, que é a Metodologia Estruturada de Desenvolvimento de Sistemas. A Figura 1.6 mostra as fases deste ciclo de vida e a Tabela 1.1 mostra os objetivos de cada fase.

Figura 1.6 – Ciclo de vida estruturado.

Há algumas vantagens em se adotar a metodologia estruturada, tais como: redução de custos de desenvolvimento, implantação e manutenção, em função da modularidade da metodologia; ganhos de produtividade, em função do aumento da velocidade de desenvolvimento; possibilidade de compreensão do sistema por diferentes analistas e usuários; boa parte da documentação do sistema é gerada a medida em que as atividades de desenvolvimento são realizadas; e a facilidade de manutenção, gerada pela possibilidade de ir direto ao ponto que precisa ser mudado, uma vez que as técnicas empregadas geram uma documentação eficiente e eficaz.

Dentre as características das metodologias estruturadas, destacam-se: particionamento (quebra da complexidade do sistema em módulos); funcionalidade (a análise é feita por função do sistema); abordagem top-down (partindo do geral para o específico); ênfase à modelagem conceitual ou lógica em relação à física (destaca-se o funcionamento do sistema e não quem executa e onde são executadas as funções do sistema); e ordenamento das questões “por quê?”, “o quê?” e “como” (parte da definição dos objetivos, passando pelas funções, até chegar na lógica dos processos).

Outros ciclos de vidas estão disponíveis na literatura sobre Engenharia de Software, particularmente no livro Engenharia de Software, de Roger S. Pressman, tais como ciclo de vida da prototipação; ciclo de vida em espiral de Boehm; dentre outros.

Concluindo, uma Metodologia de Desenvolvimento de Sistemas apresenta vários elementos como resultado, a partir da execução das fase de seu ciclo de vida. Estes elementos estão descritos na Tabela 1.2.

- 9 -

Analise de Sistemas

Técnicas Estruturadas

Segundo James Martin e Carma McClure, em seu livro Técnicas Estruturadas e CASE (Ed. Makron Books, 1991), as técnicas estruturadas representam uma busca de disciplina na análise de sistemas e programação. Com o desenvolvimento da metodologia estruturada, estas técnicas trouxeram uma melhora significativa na qualidade dos programas, além de tornar as atividades de análise e programação um pouco mais previsíveis.

Os principais objetivos das técnicas estruturadas, segundo Martin e McClure são: construir programas de alta qualidade que tenham comportamento previsível; construir programas que sejam facilmente modificáveis; simplificar os programas e o seu processo de desenvolvimento; conseguir maior previsibilidade e controle no processo de desenvolvimento; acelerar o desenvolvimento de sistemas; e diminuir o custo do desenvolvimento de sistemas.

Fase do ciclo de vida

Objetivos da fase

1. Levantamento de dados

identificar os usuários responsáveis; desenvolver um escopo inicial do sistema; identificar as atuais deficiências no ambiente do usuário; estabelecer metas e objetivos para um novo sistema; determinar se é possível automatizar o sistema e, se assim for, sugerir alguns

esquemas aceitáveis; preparar uma previsão do projeto que será usada para conduzir o restante do

projeto.2. Análise dos requisitos

transformar os dados obtidos no levantamento em especificações estruturadas;

fazer a modelagem do ambiente do usuário; fazer a análise custo x benefício dentro do estudo de viabilidade do projeto.

3. Projeto alocar as especificações geradas na análise aos respectivos processadores (homem ou máquina);

definir as tarefas relativas a cada especificação; transformar modelos de dados em projeto de banco de dados; definir os módulos a serem codificados.

4. Implementação

codificar os módulos definidos na fase de projeto; integrar os módulos codificados.

5. Geração do teste de acietação

avaliar se as especificações estruturadas são aceitáveis do ponto de vista do usuário.

6. Controle de qualidade

garantir que o sistema apresentará o nível apropriado de qualidade.

7. Descrição de procedimentos

gerar uma descrição formal das partes do novo sistema que serão manuais; gerar uma descrição de como os usuários deverão interagir com a parte

automatizada do novo sistema; gerar o manual do usuário.

8. Conversão de banco de dados

converter o banco de dados existente (informatizado ou não) em um banco de dados coerente com a especificação do projeto.

9. Instalação colocar o sistema gerado em funcionamento em consonância com o manual do usuário e o banco de dados projetado.

Tabela 1.1 – Objetivos de cada fase do ciclo de vida estruturado.

- 10 -

Analise de Sistemas

1. Elementos relativos aos procedimentos gerenciais e à organização do desenvolvimento: solicitação do sistema pelo usuário / pela organização; justificativa (problemas / oportunidades / necessidades atuais dos usuários ou da organização); missão e objetivos de negócio do sistema; recursos disponíveis e necessários; restrições; riscos; limites (escopo / abrangência); análise custo x benefício; alternativas de projeto; plano de projeto de software; relatório de acompanhamento / progresso; estimativas / métricas; alocação de pessoal; solução de implementação (desenvolvimento / aquisição); estratégia de desenvolvimento (lógica / impacto / tecnologia / metodologia); avaliação de pacotes; padrões de projeto; padrões de acesso físico de programas a banco de dados / arquivos; manuais do sistema (procedimentos informatizados e não informatizados); estimativas físicas de armazenamento de dados; estimativas de carga de processamento do sistema; aceitação do sistema pelo usuário / pela organização.2. Elementos relativos aos requisitos do sistema: documentação / funcionamento do sistema atual; requisitos do sistema (necessidades do usuário / ambiente do sistema); requisitos de desempenho; requisitos de controle (segurança / integridade / auditoria / recuperação); requisitos de hardware / software / rede (comunicação de dados); requisitos de armazenamento de dados; requisitos ambientais dos locais do sistema; entradas e saídas do sistema.3. Elementos relativos à modelagem do sistema: modelo físico do sistema (processos e dados / atual e proposto); modelo conceitual do sistema (processos e dados); interfaces do sistema (integração com outros sistemas / integração da parte manual com a parte

informatizada); modelo funcional do sistema (processos e dados); fluxo de tarefas do sistema; projeto de programas (lógica); projeto de banco de dados / arquivos; projeto de interface do sistema e fatores humanos (procedimentos / modelos).4. Elementos relativos às estratégias de desenvolvimento: estratégia de conversão de dados; estratégia de testes; estratégia de treinamento; estratégia de cópia de segurança / recuperação / reorganização de banco de dados e arquivos; estratégia de aquisição e instalação de hardware / software / rede; estratégia de manutenção do sistema.

Tabela 1.2 – Elementos de uma Metodologia de Desenvolvimento de Sistemas.

- 11 -

Analise de Sistemas

Martin e McClure definem, também, as características que consideram importantes nas técnicas estruturadas: devem ser de fácil uso; devem ser usadas diretamente com as linguagens de quarta geração ou geradores de código; devem ser tão rigorosas quanto possível; devem ser orientadas para banco de dados; e devem ser projetadas para operar com ferramentas automatizadas.

Os autores completam sua análise sobre técnicas estruturadas, através da definição de princípios, que se dividem em: princípios básicos da filosofia estruturada; outros princípios da Engenharia de Software; princípios da Engenharia da Informação; princípios de projetos de sistemas apoiados por computador; e princípios do envolvimento do usuário. A seguir descreveremos estes princípios.

Princípios básicos da filosofia estruturada

1. Princípio da abstração: para resolver um problema, deve-se separar os aspectos que estão ligados a uma realidade particular, visando representá-lo de forma simplificada e geral.

2. Princípio da formalidade: deve-se seguir uma abordagem rigorosa e metódica para resolver um problema.

3. Conceito de dividir para conquistar: deve-se resolver um problema difícil, dividindo-o em um conjunto de problemas menores e independentes que são mais fáceis de serem compreendidos e resolvidos.

4. Conceito de organização hierárquica: deve-se organizar os componentes de uma solução em uma estrutura hierárquica tipo árvore, de forma que ela possa ser compreendida e construída nível por nível, onde em cada novo nível acrescenta-se mais detalhes.

Outros princípios da Engenharia de Software

1. Princípio da ocultação de informações: deve-se ocultar informações não-essenciais, permitindo que o módulo veja apenas a informação necessária àquele módulo.

2. Princípio da localização: deve-se colocar juntos os itens relacionados logicamente.3. Princípio da integridade conceitual: deve-se seguir uma filosofia e arquitetura de projeto

coerentes.4. Princípio da completeza: deve-se checar tudo para garantir que nada foi omitido.5. Princípio da independência lógica: na análise e no projeto, deve-se concentrar a atenção nas

funções lógicas, para que sejam realizadas independentemente da implantação física.

Princípios da Engenharia da Informação

1. Princípio da análise rigorosa dos dados: os dados têm uma estrutura própria e a análise de dados, que identifica formalmente esta estrutura, deve ser feita antes de o processo lógico ser projetado.

2. Princípio da independência dos dados: os modelos de dados, representando a estrutura lógica própria dos dados, devem ser projetados formalmente, independentemente da utilização da estrutura física e da distribuição dos dados.

3. Princípio do planejamento estratégico dos dados: os dados requerem planejamento, definição e estruturação por toda a empresa, para que possam ser compartilhados entre processos.

4. Princípio do acesso pelo usuário final: os usuários finais devem receber ferramentas que eles mesmos possam usar, sem programação, para ter acesso aos bancos de dados.

- 12 -

Analise de Sistemas

5. Princípio da modelagem corporativa: os modelos de dados e modelos de processos são construídos em alto nível da empresa (ou da maior divisão de uma empresa) de tal forma que sistemas desenvolvidos independentemente ajustem-se a essa estrutura e trabalhem em conjunto.

Princípios de projetos de sistemas apoiados por computador

1. Técnicas poderosas de projeto necessitam de automação: o cérebro humano é muito limitado em sua capacidade de lidar com detalhes, complexidades, rigor matemático e ampla checagem cruzada sem cometer erros (o computador permite que os projetistas ultrapassem as fronteiras do cérebro humano).

2. Projeto apoiado por computador requer gráficos: todas as análises e projetos estruturados utilizam-se de gráficos e os diagramas tornam-se complexos e consomem muito tempo para serem modificados, necessitando de refinamento constante (uma ferramenta computadorizada facilita a construção, modificação, refinamento, expansão e extração de sub-conjuntos dos diagramas do projeto, possibilitando o tratamento da complexidade).

3. A ferramenta computadorizada deve orientar o usuário: as ferramentas CASE (Computer Aided Software Engineering – Engenharia de Softrware auxiliada por computador) devem incorporar as metodologias e orientar o projetista através de etapas que reflitam um bom projeto, solicitando informações a partir do qual gerará o código.

4. Deve ser evitada a programação, sempre que possível: os diagramas de projeto devem ser decomponíveis, sucessivamente, em mais detalhes, até o código poder ser gerado automaticamente.

5. Devem ser utilizadas estruturas básicas que resultem em projetos demonstráveis automaticamente: é conveniente que se atinja um rigor bem maior do que aquele fornecido pelas técnicas estruturadas atualmente conhecidas, priorizando as estruturas básicas que resultem em automação matematicamente rigorosa do projeto.

6. As linguagens devem ser feitas sob medida para as técnicas de projeto: as novas linguagens de programação estão evoluindo rapidamente e devem empregar estruturas básicas apropriadas, de forma que as melhores técnicas para projeto automatizado estejam refletidas na linguagem.

Princípios do envolvimento do usuário

1. Os usuários finais devem ter total envolvimento na análise, projeto e administração de dados: os usuários devem ser capazes de checar, a cada etapa, o que está sendo planejado e construído para eles.

2. As técnicas estruturadas devem ser projetadas para aumentar a compreensão e a criatividade do usuário: os usuários devem ser capazes de esboçar procedimentos que os ajudem a ler, discutir e modificar os esboços dos analistas, requerendo técnicas estruturadas fáceis de usar.

3. Esboços de fácil uso devem ser diretamente decompostos em projetos integralmente precisos: os esboços, que são de fácil entendimento, devem ser extensíveis, através de uma ferramenta computadorizada, para formar uma representação precisa, projetada para verificação axiomática tão completa e abrangente quanto possível.

4. Protótipos devem ser construídos, sempre que possível: a realidade deve ser testada o mais cedo possível em todos os sistemas.

Ferramentas para usuários finais devem ser usadas, sempre que possível: as ferramentas para os usuários finais, inclusive linguagens de consulta, geradores de relatórios, manipulação de planilhas e geradores de aplicação, devem ser utilizadas para permitir a máxima flexibilidade e para criar protótipos.

- 13 -

Analise de Sistemas

Diagrama de Fluxo de Dados

Dentre as técnicas estruturadas para análise orientada a processos, o Diagrama de Fluxo de Dados (DFD) é, com certeza, a mais clássica e a mais utilizada. A história da Análise Estruturada, como Metodologia de Desenvolvimento de Sistemas, se confunde com a do Diagrama de Fluxo de Dados, pois esta técnica caracteriza todo o desenvolvimento estruturado de sistemas.

Este texto pretende trazer os conceitos e notações relativos ao Diagrama de Fluxo de Dados, principalmente na visão dos grandes autores relacionados à Análise Estruturada: Tom DeMarco; Chris Gane & Trish Sarson; e Eduard Yourdon.

Considerações iniciais

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

Edward 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 e os documenta, ainda que de forma textual, para que estes 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 ser 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);

- 14 -

Analise de Sistemas

Depósito de 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 é chamada 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; DFD é uma especificação que possui algum formalismo, tal como proposto nos princípios da

Engenharia de Software; DFD permite registrar as necessidades e preferências do usuário; 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 permite que o mesmo instrumento de análise sirva também de

documentação; uso de 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 2.1 mostra estes símbolos nas duas versões mais utilizadas para se desenhar Diagramas de Fluxo de Dados. Por uma questão de padronização, a notação a ser utilizada na disciplina Análise de Sistemas I é a proposta por Yourdon e DeMarco. Na realidade, as duas notações atendem à sintaxe do DFD, não havendo, portanto, uma que seja melhor do que a outra. A notação proposta por Gane & Sarson é mais 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 2.1 – Símbolos do Diagrama de Fluxo de Dados.

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

- 15 -

Analise de Sistemas

recebe dados de um outro sistema ou fornece 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 pode ser 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 do 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 uma 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 identificador 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

- 16 -

Analise de Sistemas

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á-lo para algum lugar ou pegá-lo 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 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, deve-se marcá-la 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, como se um fluxo estivesse passando por cima do outro, ou uma fenda, deixando um pequeno espaço em branco nas proximidades do cruzamento, dando a

- 17 -

Analise de Sistemas

impressão de que o fluxo de dados está passando por baixo do outro.

Níveis de representação do DFD – técnicas de fracionamento da complexidade e expansão

Um DFD pode ser desenhado em vários níveis, dependendo da complexidade e grau de detalhamento do sistema. Pelo menos dois níveis ocorrem em qualquer sistema: o Diagrama de Contexto e o DFD nível 0.

Primeiramente, o sistema é modelado em termos de suas entradas e saídas de dados e as origens e destinos destes dados. Esta modelagem é chamada de Diagrama de Contexto e representa o sistema como sendo um único processo que troca informações com as entidades externas, sem representar os depósitos de dados do sistema.

Em seguida, é feita uma decomposição do Diagrama de Contexto em um DFD que mantém a coerência com o Diagrama de Contexto, ou seja, mantém as mesmas entradas e saídas e as mesmas origens e destinos de cada dado. Porém, neste novo nível, chamado de DFD nível 0, é acrescentado o detalhamento dos processos, que operam sobre os fluxos de dados, e os depósitos de dados, que representam o armazenamento de dados. Neste nível, novos fluxos de dados intermediários podem surgir, desde que mantenha a coerência com o Diagrama de Contexto. Os depósitos de dados são criados, no DFD nível 0, sempre que dados são armazenados para uso posterior ou quando não há seqüência imediata na execução de dois processos, onde um gera uma informação que é usada pelo segundo.

O detalhamento de processos do DFD nível 0 se dá no nível 1. Ao DFD nível aplica-se as mesmas regras do DFD nível 0. Porém, sua representação restringe-se ao detalhamento de um determinado processo daquele diagrama, apresentando coerência com o contexto daquel nível, ou seja, mesmas relações de entrada e saída e origens e destinos de dados representados no nível 0.

O detalhamento de processos do DFD nível 1 se dá no nível 2, da mesma forma. E assim sucessivamente, toda vez que um processo necessitar de detalhamento, este é feito no nível seguinte.

É importante destacar que, no Diagrama de Contexto, o único processo representado significa o sistema em foco. Portanto, não aplica-se, a este diagrama, a necessidade de que o processo tenha um identificador e de que o nome seja formado por verbo, pois o nome do processo representado no Diagrama de Contexto é o nome do próprio sistema.

A aplicação dessas técnicas de nivelamento permite um fracionamento da complexidade de sistemas grandes, bem como a expansão da compreensão de sistemas que são construídos na abordagem top-down, uma vez que é possível ir detalhando cada vez mais o funcionamento do sistema, tendo como ponto de partida uma visão geral das principais funções do mesmo.

É importante ter em mente que cada processo no nível superior do DFD de um sistema pode ser “expandido” ou “explodido” para tornar-se um novo diagrama. Cada processo no nível inferior tem que se relacionar com o processo de nível superior. É dado um número de identificação ao processo de níveis mais baixos, onde este número é um valor decimal do processo de nível superior, isto é, o processo 4, do DFD nível 0, é decomposto em 4.1, 4.2, 4.3, etc., no DFD nível 1, e, se for necessário um maior detalhamento, o processo 4.2, por exemplo, pode ser decomposto nos processos 4.2.1, 4.2.2, etc., no DFD nível 2, e assim por diante.

A maneira mais clara de representar o processo de expansão é desenhar DFDs de menor nível dentro da divisa que representa o símbolo do processo de nível superior. É óbvio que todos os fluxos de dados que entram e saem do processo de maior nível, devem entrar e sair da divisa. Os depósitos de dados só são mostrados dentro da divisa quando são criados e processados apenas por este processo.

- 18 -

Analise de Sistemas

Diretrizes para desenhar um DFD

Pode-se considerar resumidamente que os passos envolvidos no projeto de um Diagrama de Fluxo de Dados para um sistema proposto ou já existente são os seguintes:1. Identificar as entidades externas envolvidas. Isto envolve decidir sobre a fronteira ou divisa

preliminar de um sistema. Quando houver dúvida, deve-se incluir no sistema a primeira “camada” externa de sistemas manuais e automatizados, com a qual se irá lidar. Deve-se lembrar que fluxos de dados são criados quando alguma coisa ocorre no mundo externo, isto é quando uma pessoa decide comprar algo, quando ocorre um acidente, ou um caminhão chega ao ponto de carregamento. Se for possível, o fluxo de dados deve iniciar-se na fonte básica dos dados.

2. Desenhar o Diagrama de Contexto, identificando os dados que vêm e vão para as entidades externas identificadas.

3. Identificar as entradas e saídas programadas que podem ser esperadas no curso normal dos negócios. À medida que a lista aumenta, deve-se procurar descobrir agrupamentos lógicos de entradas e saídas. As entradas e saídas que estão associadas unicamente às condições de erro e exceção devem ser marcadas.

4. Identificar as consultas e os pedidos de informação que possam surgir. Devem ser especificados fluxos de dados que definam a informação “dada” ao sistema e aquela que diga o que é “requerido” do sistema.

5. Pegar uma grande folha de papel e, começando no canto esquerdo com a entidade externa que parece ser a principal fonte de entradas, desenhar os fluxos de dados que surgem, os processos logicamente necessários e os depósitos de dados que pareçam necessários.

6. Desenhar o primeiro esboço à mão livre e concentrar-se em anotar tudo, exceto erros, exceções e decisões.

7. Aceitar o fato de que serão necessários vários esboços do DFD nível 0. Não deve haver preocupação se o primeiro esboço se parece mais com um novelo. Este pode ser desvencilhado.

8. Quando o primeiro esboço estiver pronto, verificar se todas as entradas e saídas listadas foram incluídas, exceto aquelas que tratam dos erros e exceções. Deve-se observar, no esboço, quaisquer entradas e saídas normais que não puderam ser incluídas.

9. Produzir um segundo esboço mais claro, lembrando que o objetivo é um diagrama com processos únicos e um número mínimo de intersecções de fluxos de dados. Para minimizar os cruzamentos, primeiramente deve-se duplicar entidades externas, se necessário. Em seguida, duplica-se os depósitos de dados, se necessário. E, finalmente, se não houver uma forma de desenhar o diagrama sem que haja intersecção de fluxo de dados, deve-se permitir que haja o desenho de cruzamentos. Deve-se verificar se ainda é possível um novo esboço que seja mais claro, além de verificar, junto à lista de entradas e saídas, se há algo que ainda não se tenha conseguido incluir.

10. Rever o segundo esboço com um representante do usuário que esteja disposto a colaborar, ou com alguém que conheça a aplicação, explicando que é apenas um esboço e anotando qualquer mudança resultante da revisão.

11. Produzir uma expansão de nível inferior para cada processo definido no segundo esboço. Deve-se resolver o tratamento dos erros e exceções e, se necessário, incorporar as modificações no diagrama de nível superior.

Observação: se houver disponibilidade de ferramenta automatizada para desenhar o DFD, todas as versões podem ser feitas através da ferramenta.

- 19 -

Analise de Sistemas

Especificação de Processos: Português Estruturado, Tabela de Decisão e Árvore de Decisão

O Diagrama de Fluxo de Dados (DFD) representa a relação entre os processos através de fluxos de dados que entram ou saem, identificando suas origens e destinos, mas não representa a lógica interna de cada processo. Todo processo atômico do DFD, isto é, todo processo que não apresenta detalhamento em um diagrama de nível inferior, deve ser especificado, em termos de sua lógica interna. Esta especificação é chamada de Especificação de Processos.

O objetivo deste texto é apresentar algumas das ferramentas mais usadas para especificação de processos. A principal ferramenta é o Português Estruturado, mas o texto detalhará outras duas ferramentas muito úteis para resolução de problemas que dependam de combinações de condições, que são a Tabela de Decisão e a Árvore de Decisão. Outras ferramentas podem ser usadas para especificar processos, porém não serão analisadas aqui. Entre estas estão: Condições Pré/Pós; Fluxogramas; Diagrama de Nassi-Shneiderman; e Diagrama de Ação (todas estas ferramentas podem ser encontradas na literatura, particularmente em: James Martin e Carma McClure: Técnicas Estruturadas e CASE – Makron Books; e Edward Yourdon: Análise Estruturada Moderna – Editora Campus).

1. Português Estruturado

O Português Estruturado é uma ferramenta para descrever a lógica de um processo utilizando a língua portuguesa através de uma estruturação pré-definida. Esta estruturação consiste em definir um conjunto de palavras-chave da língua portuguesa, sem ambigüidade, para representar as ações e condições que fazem parte da descrição do processo.

A ferramenta empregada na Análise Estruturada é a linguagem estruturada, onde a língua utilizada é a correspondente do país onde a especificação está sendo feita. Muitas vezes, por questão de padronização, muitas organizações utilizam o Inglês Estruturado, independentemente da língua utilizada no país. A linguagem estruturada também é chamada, muitas vezes, de PDL (Programming Design Language – Linguagem de Projeto de Programas), uma vez que seu formato aproxima-se ao de uma linguagem de programação, excluídos os detalhes de sintaxe.

O Português Estruturado é composto de frases e declarações imperativas e objetivas, representando ações e condições, dentro de estruturas básicas que são comum nas linguagens de programação procedimentais. O fato de usar o Português Estruturado como ferramenta para especificação de processos não significa que o processo será especificado através de uma narrativa ou um texto em formato livre da língua. Gane e Sarson, em seu livro Análise Estruturada de Sistemas (Editora LTC), apresentam um exemplo de como uma mesma declaração lógica pode ser feita de diversas formas utilizando-se a língua portuguesa de forma livre. As formas diferentes de fazer a mesma declaração lógica, apresentadas no livro são:1. “Somar A e B a menos que A seja menor que B onde, neste caso, subtrair A de B.”2. “Somar A e B. Entretanto, se A for menor que B, a resposta será a diferença entre A e B.”3. “Somar A e B, mas subtrair A de B quando A for menor que B.”4. “O total é obtido pela adição de B e A. Não obstante a frase anterior, no caso onde B for maior

que A, o resultado será a diferença entre B e A.”5. “O total é a soma de A e B: somente quando A for menor que B é que a diferença deve ser

usada como o total.”Se analisarmos as frases acima, veremos que há pelo menos cinco formas diferentes para

descrever o mesmo procedimento em língua portuguesa. Se pensarmos um pouco mais, com certeza

- 20 -

Analise de Sistemas

encontraremos outras formas de dizer a mesma coisa e, assim, podemos concluir que há inúmeras formas de descrever a lógica de um processo através da língua portuguesa.

Porém, quando se trata de descrever a lógica de um processo no contexto da Análise Estruturada de Sistemas, há a necessidade de seja adotado um padrão que permita declarar de forma estruturada e sem ambigüidades a lógica do processo. Neste sentido, o Português Estruturado consiste no estabelecimento de um conjunto de estruturas e de ações que permita declarar de forma eficiente qualquer processo relacionado a sistemas de informação. Este conjunto aproxima-se da sintaxe de uma linguagem de programação procedimental, porém sem incluir detalhes relacionados a comandos e compilação, uma vez que o objetivo não é fazer um programa, mas dizer a lógica do processo. Exemplificando, as cinco declarações apresentadas acima para descrever um processo, poderiam ser simplificadas para uma declaração do tipo:

SE a < btotal = b – a

SENÃOtotal = a + b

FIM-SE

Esta descrição permite compreender a ação que é executada em cada uma das condições do problema (por isto é utilizada uma estrutura de condição e declarações de ação). As declarações de ação nesta especificação poderiam ser “SUBTRAIR a DE b” (no lugar de “total = b – a”) e “SOMAR a E b” (no lugar de total = a + b”). Pode-se perceber, neste exemplo, que o conjunto de estruturas e palavras-chave (verbos) da língua são usados em letras maiúsculas, enquanto que as variáveis (dados) são descritos em letras minúsculas, mantendo coerência com a sintaxe do DFD para representar fluxo de dados.

Tom DeMarco, em seu livro Análise Estruturada e Especificação de Sistema, define que o Português Estruturado é formado por três tipos de construções:1. sentença declarativa simples;2. construção de decisão;3. construção de repetição.

Estas construções são basicamente aquelas encontradas em uma linguagem de programação procedimental. Ao se definir o conjunto de elementos da língua portuguesa a serem usadas nestas construções, é possível estabelecer que este conjunto servirá de base para declarar qualquer especificação de processo, de uma forma única, independentemente de qual linguagem de programação será usada para implementar o processo, se é que ele será informatizado (o Português Estruturado permite especificar processos realizados manualmente).

Antes de definirmos os sub-conjuntos relativos aos três tipos de construções propostas por Tom DeMarco, é importante estabelecer algumas convenções para a apresentação de uma especificação de processos:1. Toda especificação de processo em Português Estruturado deve conter, em sua primeira linha, a

declaração “Processo: nome-do-processo”.2. A descrição do processo é feita dentro de uma estrutura de seqüência iniciada pela declaração

“INÍCIO” e terminada pela declaração “FIM”.3. As estruturas de condição e repetição do Português Estruturado são encerradas com a declaração

“FIM-nome-da-estrutura”, com exceção de algumas estruturas de repetição que tem outras formas de encerramento.

4. Entre uma estrutura e outra há um espaçamento da margem, ou seja, as declarações da especificação que estão dentro de cada estrutura iniciada são apresentadas um pouco afastadas da margem em relação às palavras usadas para definir o início e o fim da estrutura.

5. As palavras-chave da língua portuguesa usadas no Português Estruturado são escritas com todas as suas letras em maiúsculo.

- 21 -

Analise de Sistemas

6. Os nomes de dados usados na especificação são escritos com todas as suas letras em minúsculo.7. Os nomes de processos que eventualmente são conectados ao processo que está sendo

especificado devem ser escritos com a primeira letra em maiúsculo e as demais em minúsculos.Estas convenções devem ser associadas às demais convenções que definirão as construções

permitidas no Português Estruturado.

Sentença declarativa simples

A sentença declarativa simples ou seqüência de instruções corresponde a uma ação específica dentro da lógica do processo. Esta declaração deve utilizar verbos no infinitivo, evitando-se o uso de verbos que não sejam precisos sobre a ação que está sendo executada, como, por exemplo, os verbos “verificar”, “validar”, “processar”, etc. Além do verbo, a sentença é completada com os argumentos (dados usados na ação descrita). Cada sentença declarativa é escrita em uma linha.

O conjunto de verbos a ser usado nas sentenças declarativas simples é um padrão adotado em cada organização, sendo comum a existência de variações a partir das diferentes experiências organizacionais. Por convenção, iremos adotar os verbos e significados descritos na Tabela 3.1 para expressar uma sentença declarativa simples.

Verbo SignificadoOBTER É usado para a obtenção de dados de entrada do processo, desde que venham de

entidades externas ou de outros processos (não se aplica para obtenção de dados de um depósito de dados).

LER É usado para a obtenção de dados de entrada cuja origem é um depósito de dados.

CRIAR É usado para o armazenamento de dados em um depósito de dados.ATUALIZAR É usado para a modificação do conteúdo de dados armazenados em um depósito

de dados.EXCLUIR É usado para a eliminação de dados armazenados em um depósito de dados.CLASSIFICAR É usado para a definição de uma ordem de classificação para os dados de um

depósito de dados.SELECIONAR É usado para a seleção de determinados dados de um depósito de dados que

satisfaçam a determinada(s) condição(ões).MOVER(o verbo pode ser omitido)

É usado para a atribuição de um valor a um determinado dado. Se o verbo for omitido, é usado o sinal de igual (“=”) para representar a atribuição.

CALCULAR(o verbo pode ser omitido)

É usado para a realização de um cálculo, através de uma sentença matemática. Se o verbo for omitido, é usado o sinal de igual (“=”) para representar a realização do cálculo.

SOMAR É usado para a realização de uma adição.SUBTRAIR É usado para a realização de uma subtração.MULTIPLICAR É usado para a realização de uma multiplicação.DIVIDIR É usado para a realização de uma divisão.EXIBIR É usado para a exibição de dados de saída, com exceção daqueles cujo formato é

impresso. Os dados de saída podem ser exibidos para outro processo ou para uma entidade externa (não se aplica aos dados de saída para um depósito de dados).

IMPRIMIR É usado para a impressão de dados de saída em papel. Os dados de saída impresso sempre destinam-se a entidades externas (não se aplica aos dados de

- 22 -

Analise de Sistemas

saída para outro processo ou para um depósito de dados).EXECUTAR É usado para a conexão com outro processo.ENCERRAR É usado para indicar o encerramento da execução do processo.Tabela 3.1 – Verbos usados nas sentenças declarativas simples e seus significados.

Construções de decisão

As construções de decisão ou seleção de instruções são aquelas que identificam caminhos a serem executados na lógica do processo a partir do teste de uma ou mais condições. As construções de condição, no Português Estruturado, são de dois tipos e estão descritas na Tabela 3.2.

Tipo de construção de decisão Forma de representaçãoCondição: aquela que indica o que é realizado se a condição for verdadeira e o que é feito se a condição é falsa (pode-se omitir o que é feito no caso de condição falsa, se esta não for necessária).

SE condição (...) declaração (...)SENÃO declaração (...)FIM-SE

Casos: é a estrutura que determina o que é executado para cada um de diversos casos possíveis no processo e o que é feito se nenhum dos casos previstos ocorrer (pode-se omitir o tratamento de execução para a não-ocorrência dos casos previstos, se este não for necessário).

FAZER EM CASO DE CASO condição (...) declaração (...) CASO condição (...) declaração (...) (...) OUTROS CASOS Declaração (...)FIM-CASO

Tabela 3.2 – Tipos de construções de decisão.

Construções de repetição

As construções de repetição ou repetição de instruções são estruturas que permitem identificar as iterações, ou declarações que são executadas dentro de laços, ou seja, repetidas vezes. As construções de repetição trazem embutidas, geralmente, condições de saída da iteração. Existem três estruturas básicas para as construções de repetição, baseadas na forma de inserção das condições de saída, que estão descritas na Tabela 3.3.

Pseudocódigo

O Pseudocódigo é usado muitas vezes como sinônimo de Português Estruturado. Porém, pode-se distinguir essas duas ferramentas pelo grau de formalismo usado nas notações. Enquanto o Português Estruturado possui uma flexibilidade maior na notação, visando ser um instrumento compreendido pelo usuário, o Pseudocódigo possui uma notação mais formal e rigorosa, sendo mais usado pelos profissionais de processamento de dados como uma forma de escrever algoritmos ou projetos de programa através de uma especificação mais técnica.

2. Tabela de Decisão

- 23 -

Analise de Sistemas

A Tabela de Decisão é uma ferramenta para especificação de processos que define as ações executadas para cada combinação possível de valores resultantes de condições atreladas. Como o próprio nome supõe, a Tabela de Decisão apresenta as ações e condições em forma de uma tabela.

A Tabela de Decisão é composta de três elementos:1. Condições: cada condição é descrita numa linha da Tabela de Decisão e deve ter seus possíveis

valores conhecidos e descritos.2. Ações: as ações também são descritas nas linhas da Tabela de Decisão e indicam declarações do

que é realizado no processo.3. Regras ou normas: as regras são as combinações dos valores das condições atreladas da Tabela

de Decisão. Cada regra consiste em um conjunto de valores possíveis das condições, envolvendo um único valor para cada condição. As regras devem esgotar todas as possibilidades de combinações de valores resultantes das condições da Tabela de Decisão. Cada regra é representada em uma coluna da Tabela de Decisão.

O projeto de uma Tabela de Decisão implica em formar uma tabela com quatro quadrantes, sendo um para a exposição das condições, outro para a exposição das ações, outro para a descrição das regras e o último para relacionar as ações que são executadas para cada regra. A Figura 3.4 mostra a disposição dos quadrantes na tabela.

Tipo de construção de repetição Forma de representaçãoRepetir até: é a estrutura onde um conjunto de declarações é executada antes de testar a condição de saída do laço. Se a condição de saída for satisfeita, o controle passa para as declarações seguintes. Caso contrário, o conjunto de declarações do laço continua a ser executado.

REPETIR declaração (...) declaração (...) (...)ATÉ condição (...)

Fazer enquanto: é a estrutura onde a condição de saída do laço é testada antes da execução do conjunto de declarações do laço. Se a condição de saída for satisfeita, o controle passa para as declarações seguintes ao laço. Caso contrário, o conjunto de declarações do laço é executado.

FAZER ENQUANTO condição (...) declaração (...) declaração (...) (...)FIM-FAZER

Fazer para: é a estrutura que inclui no laço um incremento automático de uma variável e as declarações do laço são executadas enquanto a variável não atinge um valor que esteja acima do máximo definido na condição de saída. Quando omitido, o incremento é considerado como sendo um.

PARA variável = início ATÉ fim POR incremento declaração (...) declaração (...) (...)PRÓXIMO

Tabela 3.3 – Tipos de construções de repetição.

1 - Condições 2 - Regras

3 - Ações 4 - Decisões (associação entre as ações executadas para cada Regra)

- 24 -

Analise de Sistemas

Figura 3.4 – Os quadrantes de uma Tabela de Decisão.

Edward Yourdon, em seu livro Análise Estruturada Moderna estabelece um conjunto de etapas para a construção de uma Tabela de Decisão, que é transcrito abaixo, com algumas adaptações:1. Todas as condições devem ser identificadas e descritas no primeiro quadrante da tabela (cada

condição deve ser descrita em uma linha).2. Para condição, deve ser identificado o número de valores possíveis para ela e estes valores

devem ser descritos na frente da variável da condição no primeiro quadrante.3. Todas as ações possíveis para o processo devem ser identificadas e descritas no terceiro

quadrante (cada ação deve ser descrita em uma linha). As ações devem ser descritas por sentenças que iniciam com verbo no infinitivo ou por fórmulas.

4. O número de regras deve ser calculado, sendo o resultante do número possível de combinações que podem ser feitas com os valores de cada condição. O cálculo do número de regras é feito multiplicando-se os números de valores possíveis das condições. Por exemplo, se todas as condições forem binárias, ou seja, puderem assumir apenas dois valores (por exemplo: verdadeiro ou falso; sim ou não; 0 ou 1; etc), o número de regras será 2N, onde o número 2 representa o fato das condições serem binárias e N representa o número de condições. Se houver uma Tabela de Decisões onde há três condições com dois valores possíveis e uma condição com três valores possíveis, o número de regras é obtido pela multiplicação de 23 (que representa as três condições binárias) por 3 (ou 31, que representa uma condição ternária). Neste caso, o número de regras será 24.

5. Para cada regra, uma coluna deve ser desenhada no segundo quadrante, sendo numerada na extremidade superior para identificar cada regra.

6. As linhas do primeiro quadrante (condições) devem ser prolongadas até o final do segundo quadrante.

7. O cruzamento entre linhas e colunas do segundo quadrante deve ser preenchido por todas as combinações de valores possíveis das condições que formam cada regra. Uma forma de evitar se perder neste preenchimento, quando há um grande número de regras, é começar pela última condição preenchendo, na seqüência, cada valor possível em uma coluna e repetindo este procedimento até o final da linha. Em seguida utiliza-se o mesmo procedimento para a penúltima condição, mas ao invés de repetir uma vez cada valor, ele é repetido seqüencialmente tantas vezes quanto for o número de valores possíveis da condição já representada na tabela. Depois, repete-se o procedimento para a antepenúltima condição, repetindo o mesmo valor da condição tantas vezes quanto for o resultado da multiplicação entre o número de valores possíveis das condições já expressas na tabela. E assim sucessivamente, até completar a linha da primeira condição.

8. As colunas do segundo quadrante devem ser prolongadas até o final do quarto quadrante.9. Para cada regra, deve(m) ser identificada(s) a(s) ação(ões) que são executadas no caso da

combinação respectiva de valores das condições ocorrer. As combinações impossíveis de acontecer ensejam a marcação de toda a coluna, no quarto quadrante, do símbolo “–“.

10. As omissões, contradições e ambigüidades devem ser identificadas e discutidas com o usuário para o aperfeiçoamento da especificação. Um omissão ocorre quando não há ação definida para uma regra possível. Uma contradição ocorre quando duas ações contraditórias são executadas para uma mesma regra. E uma ambigüidade ocorre quando há muitas regras diferentes definindo a execução das mesmas ações.

Estas diretrizes permitem que uma Tabela de Decisão possa ser feita para especificar

- 25 -

Analise de Sistemas

determinado processo de um sistema.

Árvore de Decisão

A Árvore de Decisão é uma ferramenta para especificação de processos semelhante à Tabela de Decisão, mas que descreve as ações a serem executadas através de ramificações de combinações.

A Árvore de Decisão é desenhada na horizontal, definindo-se um nó (um ponto) na extremidade esquerda de onde parte o desenho da árvore.

Em seguida, o nó é ramificado, através de linhas que são desenhadas em direção ao lado direito da árvore, onde cada linha corresponde a um valor possível de uma condição. Este valor é representado em forma de uma expressão do tipo “variável da condição = valor”.

A segunda condição atrelada é ramificada de cada valor pertinente da condição anterior, gerando uma representação de forma semelhante. Este procedimento repete-se até que todas as combinações possíveis de valores das condições tenham sido representadas.

Quando não houver mais condições para serem apresentadas na Árvore de Decisão, é feito um prolongamento da última condição expressa até uma declaração de ação, que deve começar com um verbo no infinitivo ou ser uma fórmula. O caminho a ser percorrido para chegar à ação, na árvore, demonstra a combinação de condições que deve ser satisfeita para que a ação seja realizada.

A representação de uma Árvore de Decisão está apresentada na Figura 3.5.

Figura 3.5 – Representação de uma Árvore de Decisão.

Fazendo uma comparação com a Tabela de Decisão, as condições, na Árvore de Decisão, são representadas pelos ramos que surgem do nó ou de outras condições; as ações são os ramos finais (de onde não surgem novos ramos); e as regras são os caminhos percorridos do nó até às ações.

Conclusão

Tanto a técnica do Português Estruturado, quanto as da Tabela de Decisão e Árvore de Decisão, são usadas para especificação de processos. Porém, há uma distinção sobre quando cada

- 26 -

Analise de Sistemas

ferramenta deve ser usada.O Português Estruturado aplica-se a qualquer especificação de processo em um sistema de

informação. Porém, em processos onde existam ações diferentes que são executadas a partir de diferentes combinações de resultados de condições atreladas, é importante que a especificação também seja feita utilizando-se uma Tabela de Decisão ou uma Árvore de Decisão.

Da mesma forma, se no processo que está sendo especificado, não houver uma combinação de condições que determine diferentes ações a serem executadas, não há benefícios no uso de Tabela de Decisão e Árvore de Decisão, devendo, o processo, ser especificado apenas pelo Português Estruturado.

- 27 -

Analise de Sistemas

Dicionário de Dados

O Dicionário de Dados é uma das ferramentas úteis para análise orientada a dados. Ela completa a modelagem de análise de um sistema, definindo os dados existentes num Diagrama de Fluxo de Dados.

Conceito

O Dicionário de Dados é uma ferramenta da Análise Estruturada que serve para descrever os dados de um sistema. Todos os dados citados nos Diagramas de Fluxo de Dados, nas especificações de processo e nos Diagramas de Descrição de Entidades são listados e definidos em termos de conteúdo e significado através do Dicionário de Dados. As decomposições dos itens de dado compostos do Dicionário de Dados também são definidos pela ferramenta.

O resultado final da aplicação desta ferramenta é uma lista em ordem alfabética, com entradas de nomes diferentes (ou seja, não pode haver dois itens de dado com o mesmo nome, mas com conteúdo ou significados diferentes) e seus respectivos conteúdos e significados.

Os dados são representados no Dicionário de Dados da mesma forma como são referenciados no Diagrama de Fluxo de Dados e nas especificações de processo. Isto significa que os fluxos de dados são representados em letras minúsculas e os Depósitos de Dados com a primeira (ou as primeiras) letra(s) em maiúsculo.

O Dicionário de Dados é uma ferramenta simples, em função de sua notação simples de ser usada e regras de fácil aplicação. Mas é uma ferramenta extremamente útil para definir os dados, evitando-se redundâncias, ambigüidades e contradições, além de proporcionar uma descrição compreensível e padronizada de todos os dados envolvidos no sistema.

Notação

O Dicionário de Dados utiliza, segundo padrões definidos por DeMarco, os seguintes símbolos para representar suas possibilidades de construção:= significa: é composto de+ significa: e( ) significa: opcional{ } significa: iteração ou repetição[ ] significa: alternativas possíveis de valores* * significa: comentário@ significa: identificador de um depósito de dados| significa: ou (usado exclusivamente para separar as alternativas dentro de [ ])- significa: faixa de valores (usado exclusivamente na construção [ ])

Regras para a construção do Dicionário de Dados

A construção de um Dicionário de Dados é uma tarefa simples. Basicamente, as seguintes regras podem ser aplicadas:1. Cada item de dados a ser definido (geralmente, fluxos de dados e depósito de dados do

DFD e atributos do Diagrama Entidade-Relacionamento e Diagrama de Descrição de Entidades) é listado e sua composição é definida em termos de itens de dados de nível menor.

- 28 -

Analise de Sistemas

2. Os itens de dados que fazem parte de outros itens também são definidos da mesma forma descrita no primeiro passo, até a definição de itens atômicos (não decompostos, ou seja, aqueles cuja definição é feita em termos de valores e não itens de dados).

3. Após a descrição de todos os itens de dados, os mesmos devem ser colocados em ordem alfabética.

4. Os depósitos de dados são descritos usando-se a construção de iteração ou repetição ({ }).

5. Os comentários, quando usados, devem ser colocados antes da composição do item.6. Os itens atômicos podem ser definidos como combinações de dados tipo estrutura, tais

como “número” ([ 0-9 ]), “caracter” ([ A-Z | 0-9 | | , | . | - | ’ ]) ou “data” (dia + mês + ano), ou ainda, por faixas ou alternativas de valores.

Exemplo

Considerando um talão de cheques convencional, o seguinte Dicionário de Dados poderia ser definido (supondo que vários talões de cheques façam parte de um depósito de dados):

Ano = {número}Caracter = [A-Z | 0-9 | | , | . | - | ‘ ]Dia = [1-31]Mês = [janeiro|fevereiro|março|abril|maio|junho|julho|agosto|setembro|outubro|

novembro|dezembro]Número = [0-9]

@ChequesCheque = número do banco + número da agência + número da conta + número do

cheque + valor do cheque + (favorecido) + data de emissão + nome do cliente + cpf + rg

Cidade = {caracter}Cpf = {número}data de emissão = cidade + dia + mês + anoFavorecido = {caracter}nome do cliente = {caracter}número da agência = {número}número da conta = {número}número do banco = {número}número do cheque = {número}Rg = {número}talão de cheque = *o talão de cheque é um conjunto de 20 folhas de cheque agrupadas, com

numeração seqüencial*{cheque}

valor do cheque = {número}

Uma notação alternativa para a representação de iteração ou repetição é o uso de valores mínimos e máximos de iteração. Por exemplo, poderia-se definir: ano = 1 { número } 4. Isto significa que o item de dados “ano” é composto de um até quatro números de 0 a 9.

- 29 -

Analise de Sistemas

Diagrama Entidade-Relacionamento, Diagrama Hierárquico de Entidades e Diagrama de Descrição de Entidades

A dimensão dos dados é fundamental na análise de qualquer sistema de informação. Os dados, para serem trabalhados em bancos de dados e arquivos, ou como entrada e saída dos sistemas, devem ter um tratamento de modelagem na fase de análise, visando à compreensão correta de como eles se relacionam entre si e com os demais componentes do sistema.

Dentre as ferramentas usadas para modelagem de dados na fase de análise de sistemas de informação, as que serão destacadas no contexto do estudo que está sendo realizado são: Diagrama Entidade-Relacionamento, Diagrama Hierárquico de Entidades, Diagrama de Descrição de Entidades e Dicionário de Dados. As três primeiras estão sendo detalhadas neste texto.

Diagrama Entidade-Relacionamento

O Diagrama Entidade-Relacionamento (DER) representa o modelo de dados de um sistema. Ele serve para demonstrar como os dados de um sistema se relacionam entre si. Várias notações foram criadas para este diagrama. As notações mais conhecidas são as de Peter Chen, de James Martin, de Merise, e a utilizada no Modelo Entidade-Relacionamento Estendido Binário (MEREB).

A notação a ser utilizada neste texto é o Modelo Entidade-Relacionamento Estendido Binário, em função de facilitar implementações que serão feitas na fase de Análise das Áreas de Negócio. Este modelo consiste, basicamente, dos conceitos de entidade, relacionamento, cardinalidade e atributos.

Entidade:

É todo objeto sobre o qual serão armazenadas informações. Uma entidade possui existência própria e dados a seu respeito. Para identificar-se uma entidade, três perguntas básicas devem ser feitas sobre o objeto em análise: Existe mais de uma unidade do objeto? objeto possui dados? objeto é identificado por um ou mais dos seus próprios dados?

Se a primeira pergunta for respondida com um "não", com certeza o objeto não é uma entidade, uma vez que para caracterizar-se uma entidade é preciso haver mais de uma ocorrência do mesmo objeto. Por exemplo, dificilmente cada setor ou departamento de uma empresa é considerado como uma entidade, uma vez que normalmente não existe mais de um setor ou departamento com o mesmo nome dentro da empresa. Assim, Setor de Compras ou Contabilidade não são entidades no modelo de dados do sistema.

Se a segunda pergunta for respondida com um "não", com certeza o objeto não é entidade, uma vez que não possui dados a serem armazenados sobre ele. Quando isto acontecer, deve ser verificado se o objeto é um relacionamento (já que relacionamentos podem não ter dados), ou um atributo, ou classe de dados.

Se a terceira pergunta for respondida com um "não", com certeza o objeto não é uma entidade, uma vez que a entidade possui existência própria, o que significa que possui identificador próprio. Quando isto acontecer, deve ser verificado se o objeto é um relacionamento, ou um

- 30 -

Analise de Sistemas

atributo, ou classe de dados.Existem quatro tipos de entidades, de acordo com seus relacionamentos e ligações com os

negócios da empresa. Estes quatro tipos de entidades são: entidade fundamental; entidade essencial; entidade associativa; e entidade atributiva.

Entidade fundamental é aquela que contém dados fundamentais, ou seja, alimentadores ou resultantes das transações de negócios da empresa. Exemplos: Nota Fiscal, Pedido de Venda, Cliente, Fornecedor, etc.

Entidade essencial é uma entidade fundamental que tem existência efetiva antes mesmo que o negócio da empresa comece a funcionar, gerando transações. Exemplos: Unidade da Federação, Moeda, Cliente, Fornecedor, etc.

Entidade associativa é a entidade que é gerada através do relacionamento entre outras duas entidades. Este tipo de entidade será útil durante a fase de projeto de banco de dados. Exemplos de entidades associativas: Subscrição de Disciplina do Aluno, Disciplinas do Curso, Recebimento de Material do Fornecedor, etc.

Entidade atributiva é uma entidade associativa que possui dados qualificadores, ou seja, dados que não são identificadores da entidade. Exemplos: Item da Nota Fiscal. Item do Pedido de Compra, etc.

Relacionamento:

É a associação entre duas ou mais entidades. No caso do Modelo Entidade-Relacionamento Estendido Binário, o relacionamento ocorre necessariamente entre apenas duas entidades.

Os relacionamentos podem ser de três tipos: relacionamento de um para um; relacionamento de um para muitos; e relacionamento de muitos para muitos.

O relacionamento de um para um é aquele onde uma ocorrência de uma entidade relaciona-se com, no máximo, uma ocorrência da outra entidade e vice-versa. Exemplo: Departamento-Chefe, onde cada departamento possui um único chefe e cada chefe chefia um único departamento.

O relacionamento de um para muitos é aquele onde uma ocorrência de uma entidade relaciona-se com, no máximo, uma ocorrência da outra entidade e esta pode relacionar-se com mais de uma (muitas) ocorrências da primeira entidade. Exemplo: Aluno-Curso, onde um aluno pode cursar um único curso, que por sua vez pode ter muitos alunos.

O relacionamento de muitos para muitos é aquele onde uma ocorrência de uma entidade pode relacionar-se com muitas ocorrências da outra entidade e vice-versa. Exemplo: Disciplina-Aluno, onde uma disciplina pode ser cursada por muitos alunos, que podem cursar muitas disciplinas.

O tipo do relacionamento é definido em função de sua cardinalidade.

Cardinalidade:

É o grau do relacionamento. No Modelo Entidade Relacionamento Estendido Binário, é representado pelo grau mínimo e máximo.

O grau mínimo significa se o relacionamento é obrigatório ou não. o relacionamento obrigatório possui cardinalidade mínima 1. O relacionamento não obrigatório possui cardinalidade mínima 0.

O grau máximo identifica o tipo do relacionamento, mostrando quantas ocorrências de uma entidade estão relacionadas à outra entidade. A cardinalidade máxima 1 identifica que uma ocorrência de uma entidade relaciona-se com, no máximo, uma ocorrência da outra entidade. A cardinalidade máxima N (ou, muitos) identifica que uma ocorrência de uma entidade pode

- 31 -

Analise de Sistemas

relacionar-se com muitas ocorrências de outra entidade.A cardinalidade é medida nos dois sentidos de um relacionamento.Exemplo: no relacionamento Aluno-Curso, existe uma cardinalidade mínima e máxima para

a relação entre aluno e curso (aluno faz curso) e outra cardinalidade mínima e máxima para a relação entre curso e aluno (curso é cursado pelo aluno). Neste exemplo um aluno faz no mínimo um e no máximo um curso, e um curso é cursado por no mínimo zero e no máximo muitos alunos.

Atributo:

É a decomposição da entidade em seus dados. A associação de dados de uma mesma entidade pode ser chamada de classe de dados.

Existem vários tipos de atributos, em função de sua existência dentro da entidade. Estes tipos são: Chave: é o atributo que identifica uma entidade. Obrigatório: é o atributo que deve existir para todos as ocorrências (registros ou tuplas) de uma

entidade. Facultativo: é o atributo que pode ser omitido. Classificador: é o atributo obrigatório, que distingue a entidade em dois ou mais tipos.

Exemplo: Sexo (M masculino, F - feminino). Derivado: é o atributo que é definido como o resultado de uma operação matemática sobre

outros atributos da entidade.Os atributos identificadores, ou chaves, também podem ser de vários tipos:

Chave primária: é o principal mecanismo de acesso a uma entidade. Chave candidata: é todo atributo, ou conjunto de atributos, capaz de identificar uma única

ocorrência em um conjunto de entidades do mesmo tipo. Chave secundária: é toda chave candidata que não é chave primária. Chave estrangeira ou transposta: é a chave primária de uma entidade que passa para outra para

fazer a relação entre duas entidades.Os símbolos que podem ser utilizados para demonstrar os elementos do Diagrama Entidade-

Relacionamento, segundo as notações citadas no início desta seção, estão representados na Figura 5.1.

Figura 5.1 - Notação do Diagrama Entidade-Relacionamento

Uma extensão possível de ser feita ao Diagrama Entidade-Relacionamento é a representação

- 32 -

Analise de Sistemas

da dependência de existência. Uma entidade é existencialmente dependente de outra quando ela necessitar da chave primária da outra entidade para identificar uma única ocorrência sua. Neste caso, a entidade existencialmente dependente é chamada de entidade fraca e aquela de quem ela depende, de entidade forte.

O(s) atributo(s) da entidade fraca que servem para identificar uma única ocorrência da entidade para uma mesma chave primária da entidade forte é(são) chamado(s) de discriminador(es).

O relacionamento onde há dependência de existência no Diagrama Entidade-Relacionamento é representado com um círculo cheio na extremidade do losango do relacionamento, voltado para o lado da entidade fraca.

Como exemplo, podemos citar o relacionamento entre as entidade Nota Fiscal e Item da Nota Fiscal. O Item da Nota Fiscal é existencialmente dependente da Nota Fiscal, uma vez que não existe item sem que a nota exista.

Em termos de chaves, não é possível identificar um único item no conjunto de itens de nota fiscal apenas usando-se o número do item (por exemplo, haverá vários itens de nota fiscal numerados como item 1). Porém, é possível identificar um único item de nota fiscal, utilizando-se o número do item, dentro de uma única nota fiscal (por exemplo, não há mais de um item, dentro de uma mesma nota fiscal, cujo número seja 1). Desta forma, o número do item é o discriminador e a chave primária é composta do número da nota fiscal (chave primária da entidade forte) e o número do item (discriminador da entidade fraca).

A Figura 5.2 mostra a representação deste exemplo.

Figura 5.2 - Exemplo de representação de dependência de existência no DER

Diagrama Hierárquico de Entidades

O Diagrama Hierárquico de Entidades é uma ferramenta que serve para descrever hierarquias de entidaes. Estas hierarquias são aplicadas quando uma entidade pode ser decomposta em vários tipos diferentes. Como exemplo, consideremos a existência de uma entidade chamada veículo. Um veículo pode ser de diversos tipos: veículos aquáticos, veículos terrestres e veículos aéreos. Neste caso temos uma hierarquia. Dizemos que veículo é uma generalização de veículo aquático, veículo terrestre e veículo aéreo. Da mesma forma, dizemos que veículo terrestre é uma especialização de veículo.

Neste sentido, uma significativa distinção pode ser feita entre os tipos de entidades que são subtipos de outras entidades. O tipo de entidade é representado normalmente como uma entidade comum. Os subtipos são tipos desdobrados de uma entidade genérica.

Quando acontece este desdobramento, a entidade desdobrada recebe o nome de supertipo. Chama-se generalização o fato de representar um supertipo como representante de dois ou mais subtipos que o compõem, e especialização o processo inverso.

O Diagrama Hierárquico de Entidades permite representar hierarquia de dados em termos de generalização e especialização. Ele pode ser desenhado como parte do Diagrama Entidade-Relacionamento ou separadamente, para ilustrar cada situação de generalização ou especialização.

A aplicação desta ferramenta está relacionada com o projeto de banco de dados. Só tem

- 33 -

Analise de Sistemas

sentido usar uma hierarquia de entidades se houver restrições diferentes para os diferentes tipos da entidade, ou seja, considerando o exemplo da entidade veículo, se os veículos aquáticos, terrestres e aéreos têm os mesmos atributos e os mesmos relacionamentos, não faz sentido defini-los como entidades específicas. Neste caso, a única entidade seria veículo. Esta definição se dá no contexto do sistema em análise.

O conceito mais relevante na representação da hierarquia de entidades é o da especialização. Uma especialização pode ser total ou parcial, quanto à abrangência de seus supertipos nos subtipos. Se todas as ocorrências de um supertipo estão representadas em pelo menos um supertipo, então é uma especialização total; caso contrário, é uma especialização parcial. Considerando o exemplo anterior, dizemos que a especialização da entidade veículo é total se, no contexto do sistema, não houver outro tipo de veículo além dos terrestres, aéreos e aquáticos. Se houver outro tipo de veículo (por exemplo, interplanetário ou agrário), então dizemos que a especialização representada é parcial.

Uma especialização também pode ser classificada como disjunta ou overlap, quanto à possibilidade de um supertipo estar em um ou mais subtipos. Quando um supertipo pode pertencer a um único subtipo, trata-se de uma especialização disjunta. Se o supertipo pode pertencer a mais de um subtipo, é uma especialização overlap. Ainda referindo-se ao exemplo anterior, se considerarmos que um veículo aquático não pode ser terrestre, nem aéreo e, da mesma forma, um veículo terrestre não pode ser aquático, nem aéreo, e, ainda, um veículo aéreo não pode ser terrestre, nem aquático, temos uma especialização disjunta, pois quando referenciamos um veículo específico, ou ele é aquático, ou é terrestre, ou é aéreo, não podendo estar em mais de uma categoria ao mesmo tempo. De outra forma, se considerarmos que é possível existir um veículo anfíbio (que pode se locomover tanto na água quanto na terra), ou um hidroavião (que voa e flutua sobre a água), estamos nos referindo a uma especialização overlap, pois uma mesma ocorrência pode existir em mais de uma categoria de tipos de entidade.

Considerando a combinação destas duas classificações, uma especialização pode ser de quatro tipos: disjunta total; disjunta parcial; overlap total; overlap parcial.

A seguir será analisado um exemplo de Diagrama Hierárquico de Entidades, ilustrando os conceitos de generalização, especialização, supertipo e subtipo. Em seguida serão detalhados os quatro tipos de especialização, que têm implicações profundas no projeto físico de banco de dados.

Exemplo de um Diagrama Hierárquico de Entidades

A Figura 5.3. mostra um exemplo, onde a entidade funcionário pode ser desdobrada e dois tipos de entidades: gerente e subordinado. Diz-se que funcionário é uma generalização de gerente e subordinado, e gerente, ou subordinado, é uma especialização de funcionário. Desta forma, funcionário é um supertipo e gerente e subordinado são subtipos. As setas indicam o sentido de especialização. Este diagrama representa a hierarquia das entidades decompondo-as. Cada subtipo poderá ter atributos adicionais e pode participar em relacionamentos diferentes de seu supertipo.

- 34 -

Analise de Sistemas

Figura 5.3 - Exemplo de um Diagrama Hierárquico de Entidades

O objetivo deste diagrama é apontar para uma análise especial das entidades que se enquadram nesta situação, visando uma definição da estrutura da base de dados, a ser estabelecida na fase de projeto, que incorpore os usos específicos das informações, acrescentando estabilidade ao modelo de dados.

Para que esta análise possa ser completa é necessário compreender os conceitos dos quatro tipos de especialização.

Especialização disjunta total

A especialização disjunta total existe quando todas as ocorrências de um supertipo possuem uma ocorrência em apenas um dos subtipos.

Este tipo de especialização é representada pela letra "d" (que significa disjunta) e a linha que liga o tipo de hierarquia com o supertipo é dupla (que significa total). A Figura 5.4. mostra um exemplo deste tipo de especialização.

Figura 5.4 - Exemplo de uma especialização disjunta total.

Especialização disjunta parcial

A especialização disjunta parcial acontece quando as ocorrências de um supertipo podem possuir uma ocorrência em apenas um subtipo, ou em nenhum deles.

- 35 -

Analise de Sistemas

Este tipo de especialização é representada pela letra "d" (que significa disjunta) e a linha que liga o supertipo ao tipo hierarquia é uma linha simples (que significa parcial). A Figura 5.5 mostra um exemplo deste tipo de especialização.

Figura 5.5 - Exemplo de uma especialização disjunta parcial.

Especialização overlap total

A especialização overlap total acontece quando todas as ocorrências de um supertipo possuem ocorrências em pelo menos um subtipo, podendo a mesma ocorrência existir em mais de um subtipo.

Este tipo de especialização é representado pela letra "o" (que significa overlap) e a ligação entre o supertipo e o tipo de hierarquia é feita por linha dupla (que significa total). A Figura 5.6 apresenta um exemplo de especialização overlap total.

Figura 5.6 - Exemplo de uma especialização overlap total.

Especialização overlap parcial

A especialização overlap parcial é aquela onde as ocorrências de um supertipo podem ocorrer em um, vários ou nenhum subtipo.

Este tipo de especialização é representado pela letra "o" (que significa overlap) e a ligação entre o supertipo e o tipo de hierarquia é feita com linha simples (que significa parcial). Um

- 36 -

Analise de Sistemas

exemplo deste tipo de especialização é mostrada na Figura 5.7.

Figura 5.7 - Exemplo de uma especialização overlap parcial.

Diagrama de Descrição de Entidades

Também conhecido como Diagrama de "L" Invertido, o Diagrama de Descrição de Entidades tem como finalidade descrever todas as entidades do modelo de dados do sistema em termos de seus atributos, identificando suas chaves primárias e os relacionamentos com outras entidades.

O símbolo do Diagrama de Descrição de Entidades é apresentado na Figura 5.8.

nome da entidade

cp atributo-1atributo-2atributo-3...atributo-n

Relacionamentos:nome-relacionamento <mín,máx> nome-entidade

[nome-relacionamento <mín,máx>]Figura 5.8 - Notação do Diagrama de Descrição de Entidades.

No modelo acima, pode-se perceber que o Diagrama de Descrição de Entidades relaciona todos os seus atributos, sendo que um ou mais deles podem compor a chave primária, que é ressaltada com a identificação "cp" na coluna à esquerda do nome do atributo.

Também pode-se perceber que todos os relacionamentos existentes no modelo de dados do sistema devem ser descritos na segunda parte do diagrama. Este relacionamento deve ser descrito da seguinte forma: na 1.ª linha, coloca-se o nome do relacionamento no sentido entidade que está sendo descrita

para a outra entidade, com cardinalidade mínima e máxima e o nome da outra entidade; na 2.ª linha, coloca-se o nome do relacionamento no sentido outra entidade para a entidade que

- 37 -

Analise de Sistemas

está sendo descrita, com cardinalidade mínima e máxima.

Exemplo

Considerando uma porção do modelo de dados de um determinado sistema, representado na Figura 5.9, e, a partir dele e das informações sobre cada uma das entidades, é possível descrever as entidades da forma demonstrada na Figura 5.10.

Figura 5.9 - Porção do modelo de dados de um determinado sistema.

Clientecp código

nomeendereçocidadeestadocep

Relacionamentos:

assina <1,N> Contrato[é assinado <1,1>]

Contratocp número

datavalordata de vencimento

Relacionamentos:

é assinado <1,1> Cliente[assina <1,N>]

Figura 5.10 - Diagramas de Descrição de Entidades para asentidades do modelo de dados da Figura 5.9.

- 38 -